软件质量保障思考- 历史、演化、当前、未来

 

一、软件质量的历史

软件测试是伴随着软件的产生而产生的。早期的软件开发过程中， 那时软件规模都很小、复杂程度低，软件开发的过程混乱无序、相当随意，测试的含义比较狭窄，开发人员将测试等同于“调试”，目的是纠正软件中已经知道的故障，常常由开发人员自己完成这部分的工作。对测试的投入极少，测试介入也晚，常常是等到形成代码，产品已经基本完成时才进行测试。

 

　　直到1957年，软件测试才开始与调试区别开来，作为一种发现软件缺陷的活动。然后很长一段时间还存在正反两方观点。https://www.cnblogs.com/yronl/p/9028150.html

　　最终的结论是：测试是使用人工操作或者软件自动运行的方式来检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别的过程。

 

二、软件质量的模型演化（标准化演进）

　　值得注意的是，模型分成很多种，其中最重要的是质量模型和过程模型。分别解决不同的问题。

　　质量模型用于评估当前测试需要哪些，还差哪些能够达到交付目标。过程模型本质上是测试和整个软件生命周期研发过程的匹配。

　　

1）质量模型的演化

https://www.cnblogs.com/Leo_wl/p/3493206.html

https://www.jianshu.com/p/d880c41f3180/

通常测试经理或者架构师评估，当前软件需要做哪些方面的测试或者质量保障。评估的依据就可以是质量模型。可以根据实际情况裁剪，但是必须考虑到所有方面。

2）软件过程模型的演化

https://blog.csdn.net/GarfieldGCat/article/details/89892771

https://blog.csdn.net/Maestro_T/article/details/106492121

https://www.cnblogs.com/IvanChen/p/4487514.html

过程质量是在软件生命周期中不同的阶段和节点加入质量验证和控制的环节。以保证软件产出的质量稳定。

V模型。

 

W模型

 

其实不论瀑布模型，V模型，还是W模型。本质上是定义软件研发过程中哪些点需要测试介入，并且介入的方式是什么。演化到CMMI和ITIL 之后，除了介入的点，还有方法和结果都一并纳入了标准化。但是这些标准都还在不断的演进。

好吧，既然已经演进到敏捷方法了。有人会问，为什么我们还要用手工测试？每次发布之后还要线上回归。我们用TDD不就行了么？终极解决方案。

问题来了，TDD的代码谁来写？如果是开发写，那要测试做什么？开发写的能覆盖所有的测试内容么？如果是测试写，目前国内的测试普遍水平有这么高么？

 

三、软件质量的当下(国内现状）

　　目前互联网企业，大量采用敏捷团队，质量保障方法也偏向Devops体系。

　　Devops研发体系的优势是显而易见的，快速迭代，敏捷开发。大量的版本更新和部署。带来的质量挑战就是，版本更新太快测试跟不上，线上经常出问题。

　　理想：https://blog.51cto.com/u_13865122/3014038

　　现实：https://max.book118.com/html/2021/0624/6123140144003203.shtm

　　当前软件质量改进的总体思想是：

　　1）从粗放式的发展，到精细化管理。借助大量的自动化平台（自动化测试、压测、CI/CD、监控、大盘）来提升测试的效率和质量。

　　2）从单点介入，到参考国际化模型Devops，质量管理融入整个研发运维过程。标准化的同时减少文档过程，提升效率。

　　3）从历史问题中吸取教训，不断完善当前质量保障体系。

　　缺点：

　　1）单元测试推行依然困难，单测覆盖率低。

　　2）黑盒自动化测试维护成本高。

　　3）前置和后置兜底方案复杂，标准化层度低。

　　4）文档和实际脱节，无法有效管控。

 

四、软件质量的未来

　　根据当前的研发体系，不断完善模型和流程。跟随软件研发过程模型的演化而演化出相适应的过程模型。

　　TDD是终极目标。但是目前还很难一步达到。需要测试人员和整个行业的不断发展。集成测试和全链路测试，向标准化，自动化方向发展。