你的测试写全了吗？

QA设计的测试用例大部分都是面向业务的端到端测试，怎么能保证从DB来的数据通过层层service能顺利的到达前端并被正确的展示出来呢？我们可以尝试以UI和DB作为data flow的两端串起所有的测试。

场景

想象一个典型的场景，一次 sign off 接近尾声：

QA：这个些case都有测试吗？

DEV：打开各种IDE，UT cover了case A，JT cover了case B，API test cover了case C

Sign off 结束了，但是代码里的测试真的覆盖了 QA 预期的全部用例吗？

假设一个系统的数据都存储在 DB 中，而 UI 是系统与终端用户交互的部分，那么数据在 DB 和 UI 之间通过各种 service 的互相调用而展示或存储的过程就是一种 data flow。

QA 设计的测试用例大部分都是面向业务的端到端测试，怎么能保证从 DB 来的数据通过层层 service 能顺利的到达前端并被正确的展示出来呢？我们可以尝试以 UI 和 DB 作为 data flow 的两端串起所有的测试。

举个例子

某项目有一个叫 FileSharing 的 website，用户可以在上面共享文件。

系统的设计是 FileSharing Frontend 向 FileSharing Backend 发请求获取 file 和 user 信息，FileSharing Backend 向 File Service 发请求获取 file 信息，File Service 从 DB 读取 file 信息。

其中一个需求是当前用户可以看到自己和其他用户上传的文件，而他人上传且未被该用户下载过的文件名应该显示为粗体。

根据这个需求设计出两个 test case：

• User should see new file in bold

• User should see downloaded(or upload by himself) file not in bold

以这两个 case 为例，下图展示了数据在代码中的流动过程:

数据的流动方向是从 DB 到 UI，检查测试代码可以先从数据消费终端的 UI 开始，目的是期望测试可以证明每一步正确处理和返回信息。

第一步：FileSharing Frontend

在 file-store 的测试文件里找到两个相关测试

• should _be _shown _as _new _file

• should _not _be _new _file _after _download

并且通过 file-store 的代码：

get isNew() {    return !!this.isNewDocumentFromOthers;}

可以知道需要后端返回 isNewDocumentFromOthers

结论 ： 查看代码已知 file-store 是前端页面的数据源，这个测试是在 file-store level，没有测试保证 html 画出来相应的 item

第二步：FileSharing Backend

打开 user 的 file 页面时，前端发了 3 个请求：

/files/user/types/user/verified

根据上一步得到的信息可以知道/files 就是要找的请求

{    "id": "9a4af273-2d4e-4491-8f10-a93d2ba15e42",    "country": "US",    "fileName": "Instruction of FileSharing System",    "documentType": "Message",    "isNewDocumentFromOthers": true,    "uploadedAt": "12/16/2019",    "uploadedBy": "ad77d3fc-e0af-499e-8a71-ab020073db34",    "year": 2000  }

在 FileController 的测试文件里找到一个测试

• should<em> flag</em> new<em> files</em> uploaded<em> from</em> others

并且通过 FileController 的代码：

public bool IsNewDocumentFromOthers(Guid userId){    return IsUploadedFromOthers() && DocumentType != DocumentType.Consent &&           (DownloadHistories == null ||            DownloadHistories.ToList()                .TrueForAll(HasNotDownloadedByUser));}

可以知道 FileSharing Backend 需要 File Service 传来 IsUploadedFromOthers/DocumentType 和 DownloadHistory 的信息

结论 ：这个测试是在 API level，基本可以覆盖当前测试用例，不过根据测试金字塔，API 更多应该关注是否返回了需要的 property，而 property 的值可以被下层的 UT 验证

第三步：File Service

在 FileController 的测试文件里找到一个测试，但是只验证了 file 的 name/year/country

• should _get _by _user _id

结论 ：没有验证返回 FileSharing Backend 需要的 IsUploadedFromOthers/DocumentType 和 DownloadHistory 信息

测试覆盖分析

整理以上的步骤可以得到下面的图（标出了现有/缺失测试的部分）

如果从改善当前测试的角度出发，能得到当前测试结构下的测试用例覆盖表：

(绿色表示测试基本可以覆盖用例，黄色表示有测试但是覆盖不全，在这个例子里 File Service 需要验证能返回正确的 Uploadby/DocumentType 和 DownloadHistory 的信息）

再从 data flow 的角度看可以发现更多问题：

• UI层面没有对html做测试（风险较大）

• 现有的测试大部分集中在API层面，service层以下的UT测试比较少

• 服务之间缺乏契约测试导致修改一个API的时候只能人工检查被影响的范围

• 测试使用的内存DB可能跟实际DB有差别（风险较小）

理想情况下，所有 data 经过的地方都需要有测试保证 data flow 不会断（数据被正确的处理和传输）。

改进

基于以上项目现状，可以得出几个投入产出比较高的 action：

• 在signoff的时候DEV可以试着给QA说明现有代码的结构，解释数据流动的方式，帮助QA理解目前测试覆盖的范围，评估没有测试的部分风险有多大，找出manual test的重点

• 后端service数据传递时如果是靠API测试验证，则需要保证每个property都被测到

• 保证前端每个view model的行为和状态都有JT cover

敏捷项目中开发写测试所依据的理论主要是测试金字塔，但是测试本身该写到哪一层并没有明确的标准可以遵循，当试着跳出测试金字塔的理论，从数据这个根源沿着 data flow 去看现有的测试，就会有一些新的发现，从根本上找出缺失或冗余的测试，确保测试做到更有效的覆盖。

作者介绍：

王蕾 ，ThoughtWorks 测试工程师，有多年大型复杂系统质量保证经验。

本文转载自 ThoughtWorks 洞见。

原文链接：

你的测试写全了吗？