3. 测试

先来一张大图：

3.1 测什么

whaterver 这个叫 U 型理论还是 V 型理论（W 理论也是 V 理论的衍生，多个迭代交错而已），反正说的是测试和开发之间的关系。这个关系是很清楚的：

• 首先是需求 PRD，这个描述的是整个系统（业务）的目标，针对这个，需要有针对业务需求的测试用例来 cover，我们叫验收测试，UAT。

• 其次是设计，对应的产出是架构文档，其中部分章节描述了端到端的系统交互流程（用例）。对应的测试是系统测试，是端到端的。

• 第三个阶段是详细设计。在阿里，设计的产物是系分文档。集成文档是系分文档的一部分，描述了系统和外部的交互关系。对应的是集成测试。

• 最后就是编码了。这个对应的是单元测试，测试代码实现的逻辑和编码前的设计是否一致。

3.2 谁来测

知道了测试的方位，那每种测试分别由谁来做？这个每个公司都不一样，在 Google：

• TE（Test Engineer）：负责端到端测试

• SET（Software Engineer in Test）：负责测试工具

• SWE（Software Engineer）：负责代码、单元测试、集成测试（小、中、大测试）

在蚂蚁，或者说在国际，我们有如下岗位：

• 业务线测试：和业务线研发配合。业务线研发负责端到端设计，业务线测试负责端到端的业务用例。

• 平台测试：和平台开发配合，负责 IPAY 平台内部的集成测试。

• 开发：负责单元测试。

• 工具组：负责提供自动化工具。

3.3 怎么测

搞清楚了要测试什么谁来测，下面看一下怎么测。

前面说到了互联网快速迭代的特性，就要求极度的自动化，除了 UAT 之外（UAT 部分 case 无法固化），应该不允许手工测试：

• CI，单元测试自动化，负责 UT 的自动化验收。

• 自动化集成测试。测试根据系分（集成文档）产出，测试接口契约。这部分 case 需要在系分后产出 case，和研发编码同时完成用例编写，在研发交付后就可以持续 run。

• 自动化端到端用例。这部分对于有 UI 的，可能会比较麻烦，但是对于没有 UI 的后端服务，这个是必须的。case 在 PRD、架构宣讲后就可以产出，在系分阶段可调整；也是和研发编码同时开发，在验收测试阶段可能需要调整 case 代码，在 SIT 阶段使用。

最后，针对互联网多变的特性，可以采用业界最近提出的混沌测试理论，产出一些特殊的异常用例。混沌测试是为了测试特殊异常用例的，并不是前几类测试的替代。

3.4 如何评判测试质量

评判测试质量的一个重要标准技术测试覆盖率，业界常用的有如下集中测试覆盖率：

• 代码行覆盖率：测试执行到的可执行语句数/总可执行语句数

• 分支覆盖率：用于度量代码中判定的覆盖程度

• 条件覆盖率：用于度量代码中条件的覆盖程度。比分支覆盖率更强。例如如下判断：

if (conditionA && conditionB) { 	;} else {	;}

对于分支覆盖率，只要 conditionA&&conditionB 为 true 和为 false 都被覆盖，覆盖率就是 100%。

对于条件覆盖率，需要 conditionA 为 true 和 false，conditionB 为 true 和 fase 都被覆盖，覆盖率才是 100%。

• 路径覆盖率：分支笛卡尔积的覆盖。

上述的覆盖率，从上往下逐级增强。

那覆盖率是不是越高越好？是不是需要每项覆盖率都到 100%，代码才能 on-live？

回答是否定的，因为这中间有一个 ROI 的问题。覆盖率越高，代码质量一定越好，但是覆盖率越高，发现 bug 的效率会边际下降。基本是如下的曲线：

所以，覆盖率和测试工作量中间应该有一个平衡。同时对于不同的系统，这个平衡点可能不一样：对于越关键的系统，出 bug 的损失越大，这个平衡点就越往覆盖率高走。

所以，国际测试覆盖率指标：A1A2 应用 90%以上。

另外，测试质量的考量除了覆盖率之后，还有一个有效率的指标。意思是说 case 能真正测试出问题。case 需要做充分的校验，并且可以识别出代码的逻辑问题：比如一个把代码里面的==改成!=之后，case 是能挂的。这个怎么衡量呢？一直以来，都是靠价值观保障的，但是最近有了黑科技：代码扰动，将代码里面的逻辑改掉，看 case 会不会挂。这个其实也不是啥新玩意，我们写 case 的时候不就会先将 case 里面判断写反或者把代码逻辑写反看 case 是否有效么。