关于持续交付:微软的软件测试之道作者Alan-Page-谈持续测试-IDCF

5次阅读

共计 3266 个字符，预计需要花费 9 分钟才能阅读完成。

当谈到采纳“继续测试”办法时，所有都与良好的设计无关。测试不再是开发的预先想法（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 还是客户，无论在哪里，还有很多须要改良的中央。

尽管听起来很现实，但咱们还没到那一步。然而，一直地抉择正确的测试，在正确的工夫运行，不论这些测试是手动的还是主动的，并且减速整个零碎的品质反馈，将加强咱们在所有阶段取得反馈的能力，交付也越来越快。