● 测试评估总结

　　测试评估总结意味着对每个迭代中进行的测试进行评估与总结。与传统的测试相同，敏捷测试中评估的主要目的同样是获得被测产品质量与测试质量的度量，但在具体方法上与传统软件测试有一定的差别。

　　在系统测试层面上，在传统的软件测试中，我们通常定义从测试需求到测试用例的跟踪矩阵，基于这个矩阵计算测试覆盖率，据此获得测试质量度量，但在敏捷测试中，一方面，敏捷测试并不鼓励建立完整的从测试需求到测试用例的跟踪矩阵，因此很难的到一个精确的测试覆盖度量；另一方面，敏捷测试大量使用探索性测试的方法，由于探索性测试在覆盖方面的随意性，也很难准确度量得到覆盖率。因此，我倾向于通过“保证验收测试的完备性”和“在更低层次衡量测试覆盖率”作为测试质量评估的标准。由于一个迭代的周期很短，因此一个迭代中能够被添加和修改的功能较少，在这种情况下，维护完备的验收测试应该不是非常困难；而在更底层的测试中，通过接口或是代码覆盖率来衡量已建立的测试的完备性是更合理的方式。

　　对于被测产品的质量评估则完全依靠为产品建立的各种不同层次的测试。与传统软件测试相比，敏捷测试有两个主要的不同：首先，敏捷测试中的质量评估遍布整个开发过程，代码评审、持续集成、开发测试、接口测试等各种测试遍布在整个开发过程中，通过这些评审和测试，能够在各个维度上建立针对产品的质量评估；其次，敏捷测试通常非常看重产品的可测试性，因此，在整个质量评估体系中，对产品可测试性的评估是一个不能被忽略的因素。对产品可测试性的评估通过代码评审、代码测试覆盖率（通常具有好的可测试性的代码更容易达到更高的测试覆盖率）或是使用其他相关工具进行评估。

　　敏捷中的测试总结工作则主要是收集整理各次迭代中可复用的测试资源，从探索性测试中总结发现缺陷的模式，以及从缺陷分析中获得预防缺陷的信息。

　　当然，除了在每个迭代中针对迭代的目标建立和执行测试外，敏捷测试还意味着对产品质量和生产率的不断促进和提升。我个人倾向于使用任务列表来描述敏捷测试中的相关任务：

　　● 建立和维护持续集成，建立基于持续集成的质量控制和发布规则

　　● 持续改进产品的自动化测试框架，提高自动化测试的稳定性，降低自动化测试成本，不断提高测试覆盖率

　　● 发现值得关注的测试切入点

　　● 持续推动可测试性的提高

　　● 通过缺陷成因分析获得避免缺陷的信息，设立规则和实践避免缺陷引入

　　● 提高探索性测试应用能力，通过探索性测试发现更多的缺陷

　　● 创建更高效的工具，尽量将测试推动到上游

　　围绕提高生产率和提高质量这两个目标，敏捷测试是一个持续的自改进过程，这意味着敏捷测试中的测试工程师必须采用与传统测试中不同的方式，持不同的测试理念和对待测试的态度。敏捷测试并非是一个面向过程的活动，一言以蔽之，在敏捷测试中，我们需要尽一切可能去考虑、去推动生产率的提高和质量的提升，将目光从单纯的关注发现缺陷本身移出来，去发现更多、更远、更有价值的需要去推动的事情。