软件测试三阶段，你在哪一步？

╰半橙微兮° 2023-09-29 15:39 8阅读 0赞

首先我想先从一个例子开始，一个现实生活中的例子。

对于一个城市，假设我们的工作目标是提升环境的质量，减少垃圾。那么我们可以做什么？

首先，我们可以请很多环卫工人，出去打扫各个街道，这个马上就有了效果，环境变得更干净了。但是还不够好的地方是明天还是有很多东西需要打扫，治标不治本，只要一停下来立马回到之前的状况。

接下来，我们往前面想一想，为什么有那么多垃圾呢？其中一个方面是很多人乱扔垃圾。所以更进步一点的方案是，对于乱扔垃圾的人有些约束或者惩罚，比如抓到了曝光或者罚钱，这样扔垃圾的人会变少。

再然后，我们发现即使做到了上面，还是有不少垃圾，而且上面强制的方案也带来不少的反感。我们需要更深层次的思考，为什么会有那么多垃圾？是因为垃圾桶太少？设计得不合理？如果是这样，就需要从其他公共设施方面做一些改进了。

对于我们的测试工作，也是有类似的思路，只不过细节上要考虑更多。

### 第一个阶段：发现和解决bug的阶段 ###

这个阶段的思路基本上尽可能发现更多的bug，见一个灭一个，来两个灭一双。  
发现bug，解决后验证bug，没有任何根源性的推动，或者推动的效果不好。

这个阶段，测试工作主要集中在发现bug，要做好这个，需要多个方面的努力，比如下面这些：

*  更高效的发现bug，考验测试设计的能力。  
    这方面有非常多的方法和技巧，以及经验，这里不细说。
 *  发现bug之后如何清晰的描述，定级，以及跟进和验证。  
    这个看似简单，但是你会发现很多测试工作做了几年的人这样的基本功还是不够扎实。也可能没有受到过很好的训练或者一直没有人指导。
 *  对业务和架构的理解能力。  
    没有这方面的能力，很难发现一些深层次的bug。而这样的能力对于快速学习和一些技术基础也有不低的要求。
 *  发现bug之后如果举一反三的尽早发现更多类似的bug。

上面这些东西都是一个业务测试人员的基本功。但是如果一直停留在这个阶段，就陷入到上面例子中说的扫马路的阶段，因为如果没有其他方面的改变，每次都有那么多的bug。

我相信目前还有不少的团队是处于这样疲于应对的情况下，不只是小公司，可能一些大公司的部分项目也是如此。随着整个研发体系的发展和深入，我们应该有更高的追求。

### 第二个阶段：质量的管理 ###

在第一个阶段中，可能有一些人会停下来想：我们一直这样下去也不是个办法？有没有更好的做法呢?

这个阶段核心的思路是对缺陷做分析和考核，并做研发流程中主要问题的梳理和改善。

常常做的事情可以从下面几个方面来看：

1.  做质量数据的统计和分析

常见的有：

*  外网的bug情况，包括事故，及影响的程度
 *  测试阶段的bug数量，分布（按系统，团队，开发个人），严重程度，bug的类别等维度
 *  bug的横向跨团队和系统的对比，纵向的和历史情况对比
 *  版本发布的情况，代码变更行数的情况  
    从这些数据的收集中就能发现很多问题，比如问题集中在哪里，哪些模块，哪些人，哪些类别等等，以及有没有改善。

1.  问题的追溯和对于开发的考核

这个方面也许有一些争议，但是我还是觉得这个是一个很重要的方法。光靠观念和自觉是不够的，必需要有一定的反馈机制，就好比交规一定是配合着扣分和罚款等手段，否则记录闯红灯有什么意义呢？而且现实的来说，这些方法起到约束的作用，也是一种心理暗示，要做自己做的东西负责，也便于养成好的习惯。

通常的考核指标涉及这些方面：

*  编译失败次数的考核
 *  外网事故和bug的数量
 *  测试阶段的bug，特别是基础功能bug和严重bug

粗略的列了这么多，其实可以有很多，比如配置文件改错的情况，漏提测文件的次数等等。

1.  对于测试的考核

除了对于开发的考核，同样也有对于测试的考核，这样也更加的公平。  
测试的考核通常考虑下面的指标：

*  漏测：绝对数量或者漏测率
 *  版本的工作量和测试效率
 *  发布延期的情况  
    如果测试有这样的压力，也需要不断努力去发现更多的bug。

### 第三个阶段：推动全面的质量提升 ###

到上面第二个阶段，我们发现质量有了一定的提升，但是还是有不少的问题，而且有些问题需要我们把思路和眼界拓宽来看。这里讨论的一些东西可能更适合互联网的产品。

1.  研发流程的梳理

其实在阶段2的时候也可能有些团队已经开始做这样的事情，因为在分析质量和效率问题的时候，我们发现很多问题不单纯是代码的问题，可能还涉及研发流程的很多方面，比如：

*  需求不清楚
 *  跨团队的配合问题
 *  代码版本管理
 *  技术方面的评审和大家的理解

所以整个研发流程的规范和梳理，以及配合对应的需求和版本管理的系统也是非常的必要，实际中发现效果也是比较的明显。而且还有一点体会，在接手一个很混乱的状况时，这样角度的数量和调整比技术方案的引入更重要和切中要点，能从40分到60分，技术是往80分走的过程效果更明显。  
图片  
2. 测试能力的提升

*  自动化  
    越来越觉得这个是绕不开的话题，要想尽办法去做，做得更高效更全面。
 *  辅助手段  
    比如代码覆盖率，特别是差异的覆盖率。这个大家都比较容易理解就不展开了。
 *  拓展测试的类型  
    这个方面说起来有些泛，需要结合团队和业务的情况，比如安全测试，性能测试，兼容性测试等，去发现一些对于产品来说很重要的风险。

在这里还是要推荐下我自己建的Python学习Q群: **746506216**，群里都是学Python的，如果你想学或者正在学习Python ，欢迎你加入，大家都是软件开发党，不定期分享干货（只有Python软件开发相关的），包括我自己整理的一份2022最新的Python进阶资料和零基础教学，欢迎进阶中和对Python感兴趣的小伙伴加入！