@Rays
2019-01-05T02:09:02.000000Z
字数 2472
阅读 1159
文化&方法
摘要： 在2018年秋季在线测试会议上，Brendan Connolly指出回归测试的自动化并非总是最佳的解决方案。由此，他提出了“手动回归测试宣言”（Manual Regression Testing Manifesto），并展示了如何利用该宣言区分功能测试和回归测试，以及决定测试是否需要自动化。
作者： Ben Linders
正文：
Brendan Connolly在2018年秋季在线测试会议（Online Testing Conference）上提出，回归测试的自动化并非总是最佳的解决方案。由此，他提出了“手动回归测试宣言”（Manual Regression Testing Manifesto），并展示了如何利用该宣言区分功能测试和回归测试，以及决定测试是否需要自动化。
手动回归测试宣言的提出，参照了敏捷宣言所给出的理念。它是针对测试目的的一部公开宣言，也是用于讨论测试质量、探索测试人员贡献方式的一种框架。
Connolly指出，人们通常认为“测试”问题，尤其是回归测试问题，似乎需要一些“银弹”（即某种极端有效的方式）才能解决，例如购买适用的工具、自动化全部测试、引入人工智能解决方法等。但在Connolly看来，此类做法并非完全没有价值，而是在按瀑布式软件开发方法整合的团队中，人们总是反对试图对测试应用同一类型的规范性方法。
手动回归测试宣言提出了以下五个理念：
Connolly指出，手动测试与自动回归测试间并不存在厚此薄彼的问题，只是该宣言类似于敏捷宣言，更侧重于阐明手动回归测试。
Connolly提及，敏捷这场革命展示了沟通和协作的价值，而不是让人们去采用更多的流程和工具。测试和QA同样需要具有一些侧重点。但Connolly指出，给出这些侧重点是一件具有难度的事情，因为测试过程是环环相扣的，难以用适当的用语描述每个部分。
Brendan Connolly任Procore Technologies公司的高级质量工程师。他在2018年秋季的在线测试大会上做了演讲。InfoQ就此演讲内容采访了Connolly。
InfoQ：为什么需要为手动回归测试提出宣言？
Brendan Connolly：宣言意在展示测试的价值，传达那些驱动人们担当测试人员的技能和意向。宣言中颇具挑战之处在于如何表达测试的原因和方法，以及如何表达整个软件开发生命周期中预期产出的变化情况。
回归测试是测试人员和管理人员常会产生误解的一个领域。通常的建议是通过自动化消除此类痛点，但并非所有的场景都能选择采用自动化，或是存在投资回报率不佳的问题。这是因为对于开展自动化而言，回归测试并不能立刻成为一个好的选项。由此，为了能清晰明了的地开展交流，我认为给出测试目的公开宣言是一种非常有帮助的做法。
InfoQ：如何解释“对软件缺陷采取的行为”（Behavior over Bugs）这一理念？
Connolly：如果测试人员未找出软件缺陷，他们就很难产生做出了贡献的成就感。对于测试新手尤为如此。
功能测试期间提供了深挖问题和错误的时间。回归测试旨在最大限度上降低中断，我们并不希望新功能对已有功能产生意外的中断。一旦测试人员启动回归测试查找错误，那么他最终需要花费大量的时间重新测试功能。根据我的经验，这更有可能发现的是一些与最新更改毫不相干的细微问题，也可能会重新发现一些团队曾经选择忽略的旧错误。
即便测试人员发现了一处软件缺陷，但除非这是一处关键缺陷，并与当前的更改切实相关，否则只会是切实地引入了一个干扰。任何在回归测试过程中发现的错误，都要与发布版本的压力做权衡。这可能会降低测试人员在团队中的信任程度，因为人们会认为测试人员似乎更专注于发现软件缺陷，而不是如何向客户提供新功能。
更为重要的是，我们应确保在对所发布的版本做出改进时，维持了其中客户所期望和依赖的行为。
InfoQ：如何解释“对完成达成共识”（ Common over Complete）这一理念？
Connolly：近乎所有的测试人员在其职业生涯中，都会被问及他们是否对全部内容做了测试。事实上对于任一项目，测试人员必定会做出一些权衡。测试人员所做的是尽量在可用的时间内在最大程度上降低风险。
回归测试并非要确保所有的边界条件都经过验证，也并非意在确保可用性、性能或安全性。虽然这些方面都是十分重要的，但对它们的测试并非版本发布前的优先事项。
一旦测试人员接受了完整测试这一重担，也就承担了各种的责难。作为测试人员，我们需要将讨论引导转向到如何制定一套完整的战略，即如何用回归测试组件去确保客户的核心体验能按设计运行的策略。
InfoQ：如何使用该宣言提升手动回归测试？
Connolly：手动回归测试宣言提供了多项内容。首先，它给出了区分回归测试和特征测试的明确界限，这通常是测试人员和管理层所面对的一个挑战。 宣言中的每个核心原则都聚焦于两个给出具体值的测试要素上。通过对比两个要素的相对值，我们就可以定义整个发布周期中的测试期望。我们并不是要区分两个要素间孰优孰劣，而是给予每个要素一定的时间和场合，让测试人员去指出其中的差异。
其次，宣言提供了用于讨论测试质量、探索测试人员贡献方式的一种框架。人们很容易将测试人员视为恶意的软件破坏者，而实际上人们可能会和编写者一样甚至更加喜欢自身所测试的软件。为确保软件正常运行，即便是与编写者毫无联系，我们也会花费大量时间测试代码。虽然团队的大部分时间是在讨论编写代码的标准和实践，但是代码本身比测试和质量更加真实，并可测定。测试人员间并不存在任何共同的语言，每个测试人员都必须发出能表达自身动机的声音。
我真正希望该宣言能激发测试人员去思考目前在做事宜，为自身及所在团队定义软件开发生命周期的每个阶段中的质量，进而能够更轻松地交流自身想要完成的事情。这样，测试人员可以更好地交流，更好地向团队提出问题。