完美的测试是不存在的，但是测试可以越来越完美。我们在文章一开始就提到了全面质量管理（TQM）的思路，TQM认为，产品生产的每个过程都会对最后的产品质量产生影响，每个人都需要对质量负责。对于软件开发也是一样，开发过程的任何步骤都会对软件质量产生影响，要提高软件质量，并不是加强测试力量就能够做到的，需要在整个过程中保证软件的质量。构建测试并不断改进测试的行为贯穿于整个开发过程，为质量提供了基础的保证。
自动化测试
自动化测试是XP测试活动的另一个优秀思路。在我们讨论迭代的时候，曾经简单讨论过回归和自动化测试。只有测试实现了自动化，回归测试才能实现，重构才能够贯彻，而迭代也才能够进行。所以XP一直强调它的实践就像是拼图，只有全部实现才能够完全展现其魅力。单单从这个角度，我们就能够体会到这句话的含义了。
对于一个自动化测试系统而言，有几个部分是特别重要的：
数据准备：对于一个简单的TestCase而言，数据准备的工作在Setup中就完成了处理（参见JUnit），但是现实开发过程中的测试数据通常比较复杂，因此有必要准备单独的数据提供类。对于一个完整的企业应用系统而言，往往包含数千的测试用例，而相应的测试数据量也极为庞大，这时候，我们还需要有专门的机制来生成和管理测试数据。
测试数据和特定的项目有关，因此不存在一个标准的建立测试数据的规范。所以我们在XUnit框架中看到，框架仅仅只是把建立数据这个活动给抽象出来，并未做额外的处理。但对于自动化测试而言，为各个单元测试建立独立的测试数据是很有必要的。测试数据的独立性是测试用例独立性的前提。测试数据大部分采用脚本的形式建立，包括输入数据和输出数据两个部分。例如，对于一个业务实体，就可以使用一个脚本来对它的属性赋值。脚本文件的形式有很多，例如配置文件、数据库数据脚本等。
验证：验证是将待测试的方法返回的结果值和预定的结果值进行比较，以判断该方法是否成功执行。结果值总是和输入值相匹配，因此，我们经常将结果值和输入值放在同样的脚本中处理。比较通用的验证方式是采用断言机制，此外，还包括错误记录、浏览测试结果，产生测试报告等功能。
桩：桩（Stub）是自动化测试中常用的一种技巧。在OO设计中，类和类之间往往都有关系，我们如何对一个依赖于其它类的类进行单独的测试呢？很多的软件设计中都存在难以模拟错误的现象。例如对磁盘出错、网络协议出错的情况就难以模拟。测试桩的思路就是为了解决这些问题，一个桩并不是真正的对象，但是能够提供待测对象感兴趣的数据或状态，这样，待测试对象就能够顺利的使用依赖对象，或是模拟事件。
(六)强化沟通
结对编程是本系列文章讨论的最后一个主题，也是备受争议的一个主题。为什么一个人的工作要两个人来完成，这对于老板来说简直就是犯罪。和前面的主题类似的，我们要学习和应用一项实践，关键的还是要把握其实质。
文章来源于领测软件测试网 https://www.ltesting.net/
