软件测试过程中的痛点思考

前几天无意中看到了TesterHome发起的《2023年度软件质量保障行业调查报告》，文中提到了几点调查结果和分析结论让我很感兴趣。针对这份调查报告，我想就下述三点结论谈谈我的一些理解和思考。

 

一、测试参与度分析

在这一调查报告结论中，提到了需求评审、测试计划和测试评审是整个测试流程中的核心环节。当然除了这三项，静态代码扫描和项目回归复盘的占比也不低。

印象里在前几年，特别是2015-2019年，大家更多的认为在测试过程中技术实践更重要，比如自动化测试。而近几年大家开始回归本质，从更底层来思考质量保障和业务之间的关系。

对此我是这样理解的：国内的IT行业发展至今，主要经历了三个阶段，用几个词语概括则是按部就班、百花齐放、方法沉淀。

第一阶段：按部就班，大体对应04-10年。这个阶段国内的IT互联网技术领域并没有太多创新和应用空间，基本是照搬国外的方法来开展技术工作。

比如瀑布模型，比如QPT/LoadRunner等商业工具，比如用Jira进行需求和项目管理。虽然在整个研发测试流程中，也会遵循各种规范，但测试在其中的左右，更多的是QC角色，即质量检测。

这个过程中研发和测试的关系，更像是流水线的上下游，大家各行其是，没有很好的配合。

第二阶段：百花齐放，大体对应12-18年。伴随着移动互联网的爆发，业务场景越来越复杂，线上流量访问压力更大，系统架构也变得越来越复杂。

业务的复杂性和多样性对技术的要求更高，与之对应的则是各种各样的技术探索和工程实践落地，比如测试岗位出现了专职的自动化测试、性能测试、测试开发等岗位。

第三阶段：方法沉淀，大体对应19-22年。互联网狂奔猛进的势头放缓后，大家开始降本增效，更追求投入产出比，从以前的粗放式实践回归到思考本质。

且经过多年的技术实践和各种分享，大家逐渐积累了很多方法论，也有了更有普遍性认同的一些最佳实践，比如测试左移右移，而测试的角色也逐渐演变为质量保障(QA)。

要做好质量保障，就不能只在流程中所谓的测试环节下功夫，大家开始思考影响质量的因素并开展对应的防护措施。比如需求分析和评审，比如更合理可行的测试实施计划，比如系统上线后的复盘归因和持续迭代优化。

 

二、阻碍测试进度因素分析

影响测试进度的因素有很多，且大多数因素并不归属于测试环节，只是这些因素带来的风险在测试环节开始集中爆发，这也是为什么很多测试同学自嘲自己就是背锅的由来。

我们都知道质量是设计出来的，而不是测试出来的，测试动作更多的是验证研发实现的软件产品是否符合产品预期设计的各种标准。

如果产品需求在一开始定义不清楚，要求不明确，研发对需求的理解有误，会进一步影响到编码实现的功能，最后就是开发和测试的相爱相杀，提不完的BUG，测不尽的问题。

当测试同学开始肩负起质量保障的责任时，为了解决需求不明确的问题，就要主动去推进需求评审，提前暴露风险，将问题扼杀在初始阶段。

为了使研发的编码质量更好，就有了技术方案评审、静态代码扫描、和研发show case以及冒烟提测的各种实践。

每个项目或者版本迭代都有交付的deadline，需求和研发阶段预防还不够，还要想办法提升测试阶段的效率和质量，随之就有了自动化测试、精准测试、端到端测试各种方法和实践。

不仅如此，产品发布后的线上质量更能引起技术同学敏感的神经，因此线上巡检、业务防资损、完善的监控体系和应急响应机制以及项目复盘也成了质量保障的必备措施。

除了上述的部分因素，还有诸如需求频繁变更、项目排期压缩、测试资源不足、测试数据混乱、测试环境不稳定等因素也是影响测试进度和质量的真凶。

 

三、哪些原因导致了质量问题

上面第二部分提到了很多影响测试进度的因素，其实这些因素也是影响质量提升的罪魁祸首。

毕竟资源和精力有限，在倒排期的deadline和各种因素影响下，测试同学只能尽可能去保证核心的部分，加上各种各样的复杂因素和意外，质量的提升只能说是任重道远。

从软件工程的角度来说，软件产品质量有一个不可能三角，即成本、范围和时间最多满足两项，如下图。

降本增效大环境下，为了控制成本，自然而然投入的资源就降低了，如果能保证需求范围明确和时间因素不变，那质量理论上来说是可控的。

但在实际工作场景中，频繁的需求变更和不明确的需求依然是频发现象。

与此同时，很多时候影响质量的因素是归于管理者而非执行者的。

如果上述的不可能三角都可以满足，那一切都好说，但很多时候，管理者为了保住自己的饭碗或者获得晋升，会通过各种OKR/KPI来影响执行者，而OKR/KPI往往在落地执行过程中扭曲变形，最后一地鸡毛。