随着敏捷开发模式的流行，版本交付周期缩短，测试工期压缩，一线测试工程师不仅工作节奏加快，而且工作量也在加大。但是，我们的成长速度似乎越来越慢。这是为什么呢？大环境下，我们都陷入了一个非成长型的恶性循环，随着项目迭代频率加快，循环的回归测试和发布执行等工作不断地消耗着我们的精力和成长动力，我们都想跳出这个循环，却并没有那么顺利。

图1-1 敏捷下的测试循环

那么，我们就这样躺平么？当然不行，我们必须继续探索跳出这个恶性死循环的方法。本文想从测试文档的整理说起，分享测试成长的探索之路。

一、 传统测试文档

传统的测试文档一般包括：测试计划、测试用例、测试缺陷和测试报告。测试计划文档整理了测试的排期，测试用例文档整理了具体的测试点，测试缺陷文档记录了测试过程的Bug，测试报告整理了测试结果。如图1-2，我们可以发现，整理这些文档其实还是局限于系统测试这个节点，我们的关注点还是停留在测试执行这个循环中。或许，我们可以尝试跳出这个传统思维，从整个软件生命周期来关注如何整理测试文档。

图1-2 软件生命周期

二、 探索型测试文档

如果从整个软件生命周期来关注测试文档的整理，我们可以关注哪些内容？关注这些内容能让我们有哪些成长？

2.1 文档内容

如图2-1所示，此测试文档包含以下六类信息：需求分析、需求开发方案设计、需求开发、需求测试、需求发布和其他需求信息。本文将此测试文档定义为探索型测试文档。探索型测试文档不再只是关注系统测试节点的相关文档，而是以整个需求开发生命周期的视角来收集所有有利于测试保障工作和测试能力提升的文档。具体细分内容可看下图，或者可从原文获取上述脑图文件。

图2-1 探索型测试文档脑图

2.2 关注理由

相对于以往关注的测试文档，探索型测试文档能够帮助我们逐渐了解到软件生命周期的全貌，知己知彼，百战不殆。只有了解别人在做什么，才能更好地与人沟通和协作。只有了解整个项目各个节点在做什么，才能从测试执行者的循环中跳出，提高对整个项目的质量意识和把控能力。

需求分析中，除了关注《需求文档》的内容，我们也可以关注《UI/UX设计文档》，界面和交互设计内容其实也是需求的一部分，我们需要关注并补充测试用例。同时，我们还可以关注《埋点设计文档》，埋点像是一个产品的眼睛，我们需要保障其合理且正确。关注埋点质量，也提高了我们关注产品最终业务质量的意识。

需求开发方案设计中，除了关注《接口设计文档》，我们还可以更深入了解《数据库设计文档》，这样能帮助测试工程师更深入学习到系统的数据流。如果我们还想更清晰学习需求的实现逻辑，我们可以了解《服务端需求实现方案文档》和《客户端需求实现方案文档》。了解这些内容不仅能提升我们的黑盒测试技巧，也能帮助我们学习和掌握灰盒测试和白盒测试。

需求开发阶段，似乎和我们测试工程师没什么关系，但是实际上我们可以关注项目代码仓库地址，开发的每一次代码提交都会记录在仓库中。我们可以关注提交记录和提交说明，当然我们也可以对着开发提交的信息说明试着熟悉代码，这样就可以提升我们的代码阅读能力。

需求测试中，《测试用例文档》、《测试缺陷文档》和《测试报告文档》是我们关注的基本内容，这里就不赘述。

需求发布中，我们可以关注需求相关的配置信息，避免后续自己或者他人出现配置错误。同时，我们也学习和掌握发布策略和回滚策略，这两部分其实包含很多优秀的思想，能够帮助我们了解到更巧妙的质量保障方案。

其他需求信息中，我们可以记录需求相关负责人，有利于快速找到对应负责人。我们可以补充需求的测试地址（资源）信息，帮助自己或者其他人员快速在测试环境进行验证。在需求启动前期，我们也可以从整个项目的维度整理好《需求排期表》，包括需求计划（实际）评审时间、（前端/服务端）开发计划（实际）提测时间、测试计划（实际）完成时间和项目结束时间等，这样一旦项目在测试前各个阶段出现延期风险时我们就能感知到并暴露风险。

三、 总结

对于探索型测试文档来说，其内容并不局限于上文，其内容可以根据具体业务动态变化。但是其核心思路可以是不变的，以需求为根节点，将整个项目过程中有利于测试保障工作和测试能力提升的信息汇总到一起。

如果你的团队并没有产出上述文档或者你对上述文档还并不熟悉，没有关系，你并不需求现在掌握或者要求你的团队产出所有。但是，你需要先有意识从项目维度去整理探索型测试文档是可以帮助你成长的，然后你只管尝试，或许，会有意想不到的收获。

作者简介：Chaofan，爱测角成员之一，专注探索和分享软件质量保障。

原文地址：《漫谈测试成长之探索——测试文档》

如果觉得本文对你有帮助，可以点个❤️支持一下。