企业持续集成成熟度模型ECIMM (4)----测试

3.3 测试

 

持续集成和不同等级的自动化测试是紧密相关的，这在Martin Fowler具有影响力的文章（译注：Continuous Integration ，http://martinfowler.com/articles/continuousIntegration.html，）和Steve McConnell更早期关于每日构建和冒烟测试实践的文章中都有提及。在企业持续集成的范围内，多种类型的自动测试和手工测试都会被考虑到，尽管这样，许多团队在测试方面依然十分薄弱。他们执行一个构建，然后进行一些基本的操作后就进行了发布；这些导致应用程序总是出现同样的错误，新功能只进行了简单的测试。团队在测试方面比较成熟的话，就会很快发现问题，这样在生产率和信心方面都会有所提升。

 

 

 

大部分团队都有一定形式的自动化测试，也许是一些小的单元测试套件或者一些测试脚本来确保应用程序基本的功能能够运行。这些基本的自动回归测试可以较早的、容易的发现基本问题。入门级别的团队通常都是刚刚开始适应自动化测试。

 

要达到初级等级，就必须在每次构建时都执行一系列的快速测试。这些测试使得团队有信心相信在任何时间应用程序都是可以工作的，当测试失败时，开发团队可以接到通知以便其在遗忘相关问题前修复缺陷。对于失败的响应对于这个成熟度等级是很重要的：一个团队如果对失败不能及时响应，他们就不能达到测试成熟度的初级等级。

 

中级等级的团队会扩展这种快速、构建时的测试。成熟的测试有一个显著特征就是有不同形式的测试集合。一个中级等级的团队不但有快速的构建时测试，而且也有自动的功能测试，他们也会在持续集成系统上运行一些静态的源代码分析。静态分析不必在每个构建时运行，但是可以在发布前周期性的进行，并修复发现的严重问题。

 

高级等级的特征是能够进行完整的测试。每个类型的测试其提供的信息都是有限的，单元测试提供系统中所有较复杂代码的覆盖度；功能测试覆盖系统中所有重要的功能点；边界和随机测试也会被使用。静态代码分析频繁运行，由工具进行的动态分析和安全扫描则可以对测试缺失的部分提供有效补充。为了便于得到尽快的反馈，根据范围和要求，测试可以分布在多个系统上并行运行。

 

达到高级等级需要极大的投入，但对一个缺陷成本比较高并需要高速前进的团队来说仍然是值得的。对于没有这些需求的项目来说，中级等级更合适于他们。

 

极端情况下，一些团队追求100%的测试覆盖度，尽管100%覆盖度的定义在变化，但是其意味着至少每一行都要被测试到是不变的。在多数应用中，存在一个收益平衡点（译注：按原意是“收益递减点”，即经济学中的“收益递减规律”造成的转折点，这是一个比较有意思的话题，简单的理解可以看看这里：http://zhidao.baidu.com/question/75514610.html?si=4），在这里对某些晦涩的代码行进行自动化测试的收益远小于对其创建自动化测试的成本。团队追求100%的覆盖度听上去似乎在做一些浪费的测试，但是设定一个极端的界限却可以消除“创建测试是有价值的，但是很困难”这样的借口。达到并保持100%覆盖度的目标也会成为一个自豪和动力的源泉。对于发现他们忽略了某些重要测试的高级等级团队来说，追求100%的覆盖度也许是可行的，但是对于大多数团队来说，这有点疯狂。

 

原文：www.urbancode.com    Enterprise Continuous Integration Maturity Model（ECIMM）

翻译：OscarYang（原始发表于http://hi.baidu.com/cmmi/），转载请注明