《微软的软件测试之道》作者Alan Page 谈“持续测试” | IDCF

来源：软件质量报道

作者：DZone

当谈到采用“持续测试”方法时，一切都与良好的设计有关。测试不再是开发的事后想法（afterthought）。“先写代码再做测试(write-first-test-later )”的心态已经过时了。为了在您的组织内实现高质量和持续的测试，您在编写代码时必须采用“测试优先（test-first）”的思维方式。

为了更好地理解组织在持续测试方面所经历的技术和文化转变，最近我们（DZone）采访了Alan Page (《微软的软件测试之道》作者、行业专家、微软前工程总监和现任Unity Technologies总监，@alanpage / angryweasel.com) ，就持续测试（Continuous Testing，CT）进行了交流，讨论了测试驱动开发的重要性、持续测试常见问题、持续测试的原则、以及AI/ML应用于测试的未来等。

Alan对开发者的建议：

• 测试优先的心态。一旦开发人员在编写代码时开始考虑测试，他们就会倾向于编写更易于测试的代码。
• 聘请测试专家。不要让测试人员进行测试，而要雇用能够在开发团队中指导并影响测试文化的测试专家（编者注：相当于测试教练，和我之前说的 Test Owner）。
• 100%的测试可自动化。这是最大的测试设计挑战:弄清楚要自动化什么。在UI测试之外，绝大多数测试（编者注：特别是单元测试、集成测试）都可以自动化。
• 避免不稳定的测试。这些测试提供不一致或意外的测试结果。
• 保持简单。“如果很难进行测试，那么很可能代码不具有可测试性，这才是真正的漏洞。” 建立软件质量责任。明确开发人员的职责和责任，允许团队应用持续改进和持续测试原则，这样测试文化就会随着时间的推移而改进。

1、团队实现持续测试（CT）的主要挑战之一是组织内部的技能和人才短缺。您将如何指导团队解决围绕测试的人才短缺问题?

Alan：在我职业生涯的过去六七年里，我所做的就是解散测试团队。不是因为我不喜欢测试员——我曾经是一名职业测试员。我发现，特别是在持续交付的团队中(通常是服务组织)，在没有专用测试人员的瓶颈的情况下，软件研发更加高效。但我所做的不是消除（测试人员）而是分解和减少（测试人员）。我的团队中通常有一些非常优秀的测试员，但他们的工作并不是测试，而是为了帮助开发人员更好地进行测试。

我们需要解决测试专业化不足的问题，需要在团队的通才中培养测试技能，因此，在我工作的团队中，开发人员要对他们自己的质量和至少90%～95%的测试负责，同时还要对项目管理和交付的其他方面负责。

因此，我的方法是依靠开发人员扩展他们的测试技能，并在一些测试专家的帮助下进行大量的测试。

2、另一个常见的挑战是确定哪些测试要自动化，哪些测试要保持手动。您的测试自动化的方法是什么，以及决定何时进行手动测试的方法是什么?

Alan：我至少在10年前就开始说，应该将 “应该自动化的测试” 100%自动化。这里的逻辑解决测试设计的挑战：找出什么应该被自动化。例如，UI测试不需要做到100%，通常来说，在UI级别和web级别上更难以自动化的。

我通常建议团队尽可能少地进行手工测试。为了做到这一点，在开发软件时，测试就是软件设计的一个选项，以一种易于使用自动化工具测试的方式创建软件架构。如果软件设计的方式是只能通过手工测试来完成大量的验证，那么我们可能会陷入极大的困境。

设计好软件系统，以便它的绝大多数可以通过低级测试（单元测试）进行验证。此外，对于必须手动测试的事情，还需要适当地进行一些检查和平衡，以便能够快速和轻松地完成测试。我所注意到的，以及我现在教给成千上万的开发人员的，是如何进行良好的测试，一旦开发人员在编写代码时开始考虑测试，他们就会倾向于使其所编写代码更具可测试性。

3、我们发现，“测试文化的变化” 被证明是组织的主要障碍。对于团队如何克服这些文化障碍，有什么建议吗?

Alan：归根结底，作为一名开发人员，需要明确自己的职责和义务。我喜欢用团队中为数不多的测试专家来参与研发，目的就是是让他们在团队的质量和测试文化中扮演重要角色。

我们可以帮助推动或驱动这件事，但我和我的开发主管一起做的一件事是：确保每一个开发人员深知他们要对软件的质量和交付负责。我会让公司里有这种专长的人来推动这种文化，然后我们就尝试并进行持续的改进、持续的实践验证，基于这样的原则，测试文化应该一直变得越来越好。

但我们必须对人们拥有质量的各个方面有一个期望和责任，这样才能开始建立一种文化，就像其他任何企业文化一样，你要鼓励那些你想看到的行为。在这样做的过程中，我积累了一些动力，在整个组织中创造了一种共享的文化。

4、根据您在自动化测试和持续测试方面的经验，您看到过的团队所犯的最大错误是什么？

Alan：

• 试图在UI级别实现过多的自动化。这在今天仍然是一个问题——尤其是在web空间。我知道一些主要的应用程序是在web级别完全使用Selenium进行测试的;只是效率低下。这些测试需要很长时间;它们是片状;团队总是花时间调试坏掉的测试。这是个很容易掉进的陷阱。
• 测试不稳定。五、六年前，我参加了一个测试自动化会议，似乎每个演讲都提到了不稳定测试的概念——运行中的测试会给您带来不一致或意外的结果。
• 测试代码试图过于聪明。如果很难使测试脚本正常运行，那么很可能是代码不具有可测试行，人们喜欢尝试测试脚本中玩一些小动作，这才是真正的Bug。在编写测试时，为了测试而编写复杂或难以处理的代码，您可能已经发现了真正的Bug：这些代码永远不会被维护。重要的是要注意类似的情况，不要为了测试脚本能运行而竭尽全力。

5、令人惊讶的是，非常小比例的受访者(只有8%)表示，他们目前正在使用AI（人工智能）或ML（机器学习）进行CT，回归测试和用户测试用例是主要的部分。在测试中，你认为团队应该在哪里扩展AI/ ML实现?

Alan：据我所知，所有使用AI和ML技术的测试工具都在（我之前抱怨过的）UI测试领域表现出色。导致传统的UI自动化测试不稳定的原因是UI可以移动、id可以改变，所有的东西都可以改变，破坏你的测试。

在未来的五年里，我们可以使用AI或ML为我们生成大量的测试用例。更进一步，如果你能收集实际的客户使用模式——许多公司收集客户如何使用软件的数据——然后将这些数据输入AI/ML模型中来创建变异，就能产生额外的测试用例或测试运行。测试人员痴迷于端到端用户体验测试，比如这个用户工作流是如何工作的，这些测试往往是不稳定的。

但是，如果我们能够摆脱这些新工具中的脆弱，结合AI/ML的能力，基于客户数据生成真实场景的测试用例，我们就能得到一些非常有价值的东西。最后，如果我的疯狂计划进展顺利，测试人员就不会花任何时间或很少时间来编写这些UI测试，而编写测试用例占用了太多的时间，最后我们就能得到了更高质量的产品。这就是我希望的AI和ML方向。

6、在接下来的6-12个月里，你会在哪继续进行测试?你认为对于团队、开发者和管理者来说，为了获得成功，什么是最重要的?

Alan：持续测试、持续集成、持续一切都是关于加强反馈循环。持续部署就是要确保我们能尽快得到关于我们所构建的东西的反馈。

持续测试确保了我们所做的每一步都是正确的测试。为了交付任何东西，无论是CI还是客户，无论在哪里，还有很多需要改进的地方。

虽然听起来很理想，但我们还没到那一步。但是，不断地选择正确的测试，在正确的时间运行，不管这些测试是手动的还是自动的，并且加速整个系统的质量反馈，将增强我们在所有阶段获得反馈的能力，交付也越来越快。

5月【冬哥有话说】质量与测试专场，今晚8点，施慧斌老师分享《DevOps实践之持续测试》，关注公众号回复“质量”可获取直播地址