系统测试的实践与思考

这是测试活动过程详解系列的最后一篇文章。之前的想法，是对测试过程各重要环节进行拆解，然后介绍这个环节重点要做的事情，为什么要做这些事，以及注意事项。

前面几篇文章分别介绍了单元测试、集成测试、回归测试阶段要解决的问题和实践的注意事项，这篇文章，分享一些我对于系统测试的实践经验和思考。

系统测试要解决什么问题

以微服务架构下的电商业务为例，我们的被测系统大致是这样的：

在单元测试阶段，我们通过验证代码中的语句、分支和条件，确保研发实现的系统可以顺利通过冒烟，满足集成测试阶段的可测性。在集成测试阶段，我们采用接口测试的手段，尽可能验证单个模块或服务本身的数据处理逻辑和功能实现符合预期。到了系统测试阶段，我们要解决什么问题呢？

从上图可以看到，我们的测试对象，其实是一个很复杂的系统。为了保障最终的交付质量，我们要考虑很多因素，比如：

• 网关层：负载是否均衡、验签、限流、黑白名单等功能是否正常；
• 业务层：功能实现和页面跳转是否和设计一致、逻辑是否正确、页面是否美观；
• 服务层：数据交互和逻辑处理是否正常，对异常情况的处理是否优雅以及各组件的稳定性；
• 数据库：数据读写是否正常，表字段类型设计是否正确，是否创建了索引，分库分表的落库逻辑是否正确；

总结来说，系统测试阶段的主要目的是：验证整个系统范围内各应用和组件之间的调用依赖关系以及各种场景下的逻辑处理功能实现正确与否。

当然，这里仍然要说明几点前置条件：整个系统范围内一般默认是本次迭代或者某个发布节点要上线的所有需求对应的代码；实现是否正确主要包括两点：是否符合需求预期设计+是否满足交付质量标准。

系统测试的实践注意事项

系统测试阶段是软件产品从需求到上线过程中的重要环节，除了验证系统的功能、性能、安全以及可靠性之外，还要考虑用户使用体验和后续的维护便捷性。

在系统测试阶段，我个人的认为需要重点关注如下几项：

• 进度管理：该阶段测试活动已经大范围展开，要重点关注整体进度，抓大放小(如有延期风险，在交付的完整性和质量之间做平衡)。
• 测试效率：大范围的测试活动开展，最好是借助工具来提高测试过程效率(工具的建设是一个长期过程，切忌蒙头憋大招，也不要一味追求美观时尚，能运行起来提升效率解决问题就行)。
• 边界划分：系统是由很多个不同模块组成，且实际工作中由多个不同团队负责，彼此职责范围内的边界划分和交互部分的约定至关重要(AB模块各自由谁负责，交互依赖的上下游内容、标准以及如何配合)。
• 质量复盘：这里并不仅仅是测试出一份系统测试报告就完事，而应该和产品以及研发团队一起在这个阶段评估本次迭代部分的质量(即需求逻辑、编码质量、各自是否按时交付、影响质量和进度的风险因素）。可能很多人认为这个应该是上线后再进行的版本复盘，但上线后的质量已成定局，建议在系统测试阶段即将完成时就开展复盘，以便于回归测试和验收测试进行改进验证。
• 质量监控：这点是很多团队容易忽视的一点，即系统上线后才开始慢慢补上对应的各种业务监控、基础指标监控，但在上线和补上监控的这段时间内，也是线上故障的频发区。更好的方法是，在系统测试阶段，就由测试同学推动相关的研发或者运维同学，对本次要线上发布的部分相关监控提前构建好并且验证通过，随着需求代码一起发布。这样即使上线后出现问题，也能及时发现和修复。

以上注意事项仅供参考，在具体的工作场景中，应根据团队具体情况来合理制定方案并落地。