转载

西门子医疗的持续测试经验

Marco Achtziger分享了西门子医疗在大规模敏捷项目中开展持续测试的经验。在德国举办的 OOP 2015 大会上，他谈论了他们遇到的陷阱以及克服他们的方法。

InfoQ采访了Achtziger，谈论了持续测试和持续集成、持续测试中基础架构与社会性挑战、测试流程与工具以及改进持续测试。

InfoQ：您可否解释一下持续测试与持续集成是如何关联的？

Achtziger ：持续测试是持续集成的一部分。在大型项目中，持续集成的测试部分是非常复杂的，必须分别处理。但我认为他们互不分离。

InfoQ：在您的演讲中，您谈到持续测试在基础架构方面的一些挑战，可否详细阐述一下？

Achtziger ：你使用的工具非常重要，尤其是对于大型项目来说。作为产品软件本身，你也必须意识到这一点。例如基础架构的可扩展性或者可靠性。所以需要考虑的典型事情是：

工具的可用性。理想情况下，测试执行的时候，开发人员不必做任何额外的东西。
你是否必须并行地运行测试？如果是，基础架构是否支持？
你的工具可否扩展？由此可以处理多台测试机器，并且能够简单地增加机器的数量？
测试执行的瓶颈在哪里？例如，在我们的例子中，如果我们使用了工具提供的默认机制，那么虽然测试的执行不会有问题，但部署测试所需的二进制文件将会决定测试执行的时间。

InfoQ：您也谈到了持续测试所面临的社会性挑战。您都经历过哪些问题，以及如何解决的呢？

Achtziger ：你会发现这方面的主要问题就是“在我机器上好用”的老开发人员。在我看来，敏捷概念之前的软件开发流程支持了这样的思维模式（没有持续集成、测试仅在集成后运行，…）。不幸的是，并没有什么银弹来解决这个问题。在某种程度上必须做的就是改变开发人员的思维模式。在我们的环境中，有帮助的就是建立我们所谓的测试到处运行（TRA（Tests run anywhere））原则。通过给他们一些他们可以提供的帮助（“所有的测试到处都可以运行不是很好吗？”），就可能不会谈论负面的事情（“你做错了，因为它只在你的机器上工作”）。

InfoQ：您提到在测试流程中有多个阶段：团队整合、资源（Assets）整合以及系统整合。您可否分别描述一下不同的阶段，以及他们是如何在这个测试链中一起工作的？

Achtziger ：这是切分你的测试框架的一种简单方法。资源整合对我们来说就是工作在同一领域的几个团队的聚合。所以，如果你有这样的一个结构，你可以把你的测试按照这种方式划分：让团队执行单元测试，并且可能已经做了一些整合测试。下一阶段就是执行主要的整合测试，确保不同的团队不会互相影响，然后，作为最终的整合，所有资源的变化聚合到一起就称为所谓的系统整合。这样你就可以决定：是否要基于这些变化执行测试，或者是否想要建立一组静态测试，在其中包含所有的系统，并且确保它仍然工作。

InfoQ：对不同的阶段和构建，您是使用什么机制来选择那些必须执行的测试呢？

Achtziger ：原则上我们使用简单的XML文件，它与我们所编译的每个程序集文件共同放置在源代码控制系统中。该文件是可配置的，如果某些东西在那个地方做了更改，就应该执行什么样的测试。所以没有什么花哨的东西。非常简单有效。

InfoQ：当由于缺陷原因导致测试失败的时候，你们使用一种测试隔离的流程，它是如何工作的呢？

Achtziger ：首先应该清楚的是，测试的失败并不仅仅是由产品代码中的缺陷所造成的。当然有时测试代码本身也需要改进。但如果测试偶尔失败了，隔离流程就有效果了，你应该检查原因是什么。如果是一个严重的产品缺陷，接下来当然要修复缺陷了。如果缺陷不是很严重、问题出在测试代码本身，或者很难修复这个测试以使其重新回到绿色状态，你可以决定暂时关掉这个测试（例如使用NUnit的Explicit属性）。这样可以让你的编译回到绿色状态，他们再也不会被一系列的失败的测试用例所破坏。隔离测试的数量必须得到监控，应该尽可能地接近于0。所以整个的隔离是一个特例，用来处理偶发的测试失败，从而避免开发人员开始忽视编译结果，那样甚至会比偶发的测试失败更严重。

InfoQ：如果人们采用持续测试并且想要改进，您可否给一些建议？

Achtziger ：我认为首要的事情永远都是与系统的用户交谈。然后告诉开发人员并找出他们现有的痛点，以及在你的工具基础架构中如何支持。最好再看看其他一些事情：