测试

Andy Kemp

ThoughtWorks的测试方法其他公司的测试方法有所不同。最主要的体现在时间投入和团队合作上。

我们所指的团队合作是测试人员作为ThoughtWorks技能多元化的团队的一部分，与开发人员和业务分析员紧密地协作。 在过去的十年里，我曾经和许多注重质量的出色的开发人员一起合作，但是我发现，分散的团队会经常出现目标不统一、协作程度不够的情况。 ThoughtWorks项目高度重视测试人员、开发人员、业务分析人员、以及最终用户间的高度协作，保证系统的高质量。

我们所指的时间投入是指无论何时，从最初的需求收集， 到最终的部署实施，测试人员参与整个过程。 我们的测试人员总会问一些令人难以应付的问题，尝试一些业务分析人员或开发人员不太可能想到的使用场景。 测试人员参与业务分析师捕捉业务需求并创建用户故事的过程，然后把这些故事转变为描述具体场景的验收测试用例。 测试人员的职责在于提供准确、有效、完整的测试用例，并确保测试完成，以帮助开发人员准确知道他们是否完整地实现了故事中所定义的功能。

我们通过保持较高的测试自动化程度，来确保新增功能不会破坏已被证实可工作的其他功能， 从而降低软件功能变更的成本。对于大型复杂的应用，测试自动化的难度比较大，这就是我们尽早和开发人员合作的原因。 我们从每一小块入手，将对用户故事的验收测试用例转化为自动测试。我们甚至在开发人员开始写代码之前就已开始设计自动测试。 如果所有测试都通过了，整个团队就会对功能是否正确完成心中有数。所有这些自动验收测试组成一套回归测试（Regression Test），在开发人员每次提交修改后的源代码时自动运行。除了建立一套完整的功能回归测试机制，在每次增加新功能的时候我们还对应用进行探索性测试，以在使用可工作的应用之前发现一些难以预测的缺陷。

如果所有测试都通过了，整个团队就会对功能是否正确完成心中有数。 所有这些自动验收测试组成一套回归测试（Regression Test）， 在开发人员每次提交修改后的源代码时自动运行。除了建立一套完整的功能回归测试机制， 在每次增加新功能的时候我们还对应用进行探索性测试，以在使用可工作的应用之前发现一些难以预测的缺陷。

及早、频繁的反馈是我们在所有项目中坚持的一个关键原则。 这意味着我们需要尽早地尽可能频繁地进行集成与性能测试，而不是在项目快结束时才测试。 因为所有项目都不一样， 我们不会每次都使用相同的过程。我们的测试策略随项目周期的转变而改变。 如果我们无法尽早地发现问题，我们会改变工作方法，确保能够更早地获得信息。我们在选择不同的测试工具的时候也是本着这样的原则。 像Selenium或Sahi这样的工具可能对某个项目有用，但是在某些项目需要时，我们也可能会使用像FIT这样的工具。

ThoughtWorks的测试人员并不是检验应用质量的看门人，而是项目健康程度等信息的提供者，帮助整个团队把注意力集中在项目质量上。

打印本页