象限矩阵说明

敏捷测试象限矩阵主要从如下四个维度对测试进行划分：

  支持团队的测试    

  评价产品的测试    

  面向业务的测试    

  面向技术的测试    

  象限编号的顺序与不同类型的测试何时完成没有关系。例如，敏捷开发开始于客户测试，它告诉团队编写什么代码。不同类型的测试的时机依赖于每个项目的风险、客户对产品的目标、团队是否处理遗留代码或者是一个从零开始的项目以及什么时候有可以进行测试的资源。  

 

象限一：支持团队的面向技术测试

目的：

单元测试和组件测试通过帮助程序员准确理解代码需要做什么及提供正确设计的指导而保证质量。

 核心实践：

TDD

说明：术语测试驱动开发（TDD）误导了大家，人们不理解这种模式中的设计要大于测试。以测试先行的方式开发的代码自然地被设计为可测试的。第一象限的活动的目标就是生产出内部质量尽可能好的软件。

解读分享：

敏捷转型后某项目也开始推动TDD实践，团队专门抽调了两三名技术骨干使用CppUnit搭建好了单元测试的框架，然后让开发的同学采用TDD思路开发之前先写好相应的单元测试用例。    

 

一年之后，当我们复盘时发现该团队的质量并未提升很多。按理说尽早的测试，通过测试驱动开发，代码的质量应该有所提升才是，这是怎么了？    

 

我们通过沟通访谈发现：    

1    ）项目有时候为了赶进度，很多同学就忘记了编写相应的测试用例；    

2    ）单元测试的用例由开发同学自己编写，往往一个函数就是一个单元测试用例；    

3    ）合入故障代码变更后，不会有人再负责补充相应的单元测试用例；    

4    ）......    

 

估计很多同学看到这都感慨万千，是否有所共鸣呢？单元测试是很好的支撑团队开发质量的手段，我们有好的想法，我们也有很多好的工具可以支撑，但是如何使用在于人。用起来容易，但是如何用好，使其发挥真正的作用，需要我们去思考。也许测试人员协助开发人员一起完成单元测试用例的编写和维护是个不错的方式。    

 

象限二：支持团队的面向业务测试

目的：定义和验证外部质量，同时帮助我们了解何时完成。

 核心实践：ATDD、BDD

说明：面向业务的测试也称为“面向客户”、“故事”、“客户”和“验收”测试。术语“验收测试”特别具有迷惑性，因为它导致一些人只想到了敏捷开发中的“用户验收测试”。验收测试通常指面向业务测试，但是也包括第四象限的面向技术测试，如客户对系统性能或者安全的要求。

解读分享：现在做BDD的团队不是很多，目前了解到的情况是国内的BAT已经有团队正常尝试，具体实践情况如何还不是很清楚，这里就不讨论BDD了。

如何理解面向业务？    

所谓面向业务，也就是面向客户的需求，而客户的需求往往可能只是一句话，或者是一个模糊的感受。面对这样抽象的需求往往会让开发团队很难受，做出来的东西达不到客户的要求，经常面临返工。ATDD就是通过需求实例化的思想来避免抽象导致的理解偏差，从业务的层面来支撑团队的开发。    

 

最近，A团队正在实施ATDD，SM抱怨说通过需求实例化输出的验收条目很多很多，让人有点受不了，而且那么多验收条目评审起来很是痛苦。团队QA也提出疑问，都已经有那么多验收条目了，那我后面还需要测试设计吗？    

 

这里其实暴露了需求实例化实践过程中的两个问题：    

1）实例化出来的场景比较容易出现碎片化的趋势，在设功能层面需要通过领域建模来映射下一层的需求，这里做不好会导致下一层需求比较零碎，给下面的需求分析和方案设计都带来困难。    

2）跟原有的测试活动存在一定的冲突。

怎么办？    

我们测试的小伙伴是不是可以前移，与BA和DEV提前进行需求分析和测试分析，通过测试的手段来帮助团队进行需求实例化。通过测试分析进行功能划分和规整，将趋于碎片化的验收条目整合规整，输出一个方便大家理解的完整的验收条目，同时也是测试设计文档？  

 

也许只有通过实践，我们才能更深刻的去领悟其中的奥秘和解决方法，ATDD是一个非常非常实践化的方法，需要我们不断去实践摸索。

象限三：评价产品的面向业务测试

目的：

测试人员或业务用户通过实际接触软件，从业务整体的角度去评判产品。

核心实践：

探索性测试

说明：人总是会犯错误，只有通过真实的使用软件，进行交互，才能真实客观的去评价软件，避免想象带来的干扰。象限三大部分是手工测试，但是没有象限一和象限二种的测试，那么你根本没时间进行象限三的测试。

解读分享：

评价产品也就意味着软件已经完成，我们需要通过站在用户的角度对软件进行测试，通过测试来评价软件的质量。    

 

这个象限有很多实践：包括用户验收测试、可用性测试、探索性测试等等。这里我们就简单对近年来比较火的探索性测试进行简单的分享。    

 

探索性测试强调的测试人员通过不同的手段方法对软件进行测试，通过不断的测试来获取观察到的软件质量。探索性测试强调的是跟软件的实时交互和变化，测试人员可以根据上一次的测试结果进行分析，构造下一次的测试用例并进行测试，根据软件的反馈进行分析评估。这是一个动态的过程，很难完全提前都设计好，一般很难进行自动化。    

 

探索性测试更依赖于人，依赖于测试人员的能力、思维等等，所以一般都是手工方式，当然可以借助相应的工具来提高测试人员的测试效率。更多的故障，尤其是业务层面的故障往往需要探索性测试才能发现。    

 

象限四：利用面向技术的测试评价产品

目的：

从技术角度来评价用户不一定能关注到的那些非功能性需求，帮助交付高质量的产品。

核心实践：

性能测试、安全测试

说明：该象限的测试类型有很多，工具对于此象限至关重要，完成这项工作的人也很重要。

解读分享：

今年的XCodeGhost事件估计大家都还历历在目，软件的安全性越来越重要。淘宝每年的双11活动，瞬间的访问量都是上亿级别，系统的压力、性能都非常重要。这些潜在的性能和安全等需求直接影响了用户对于产品的评价。象限四，主要就是从这些非功能性的角度进行测试来评价产品。    

这一类测试实践需要有很强的技术支持，一般专业性都比较强，并且需要使用专业话的工具进行辅助分析。譬如我们要进行数据的性能测试，那么数据库容量是表征数据库服务器的一个重要标准，数据库存在大量数据时，系统的性能肯定会收到影响。例如，当数据库中存在几十万、几百万条记录时，进行数据库操作（记录更新、查询等），数据库表的索引定义、表空间、log大小将会直接影响到数据库的存储/检索性能和速度，包括CPU的使用率等等。  

 性能测试、安全测试、压力测试这些都是非常具有挑战性的工作。