软件测试BUG都修复了就结束了吗？

一般来说，当 Bug 跟踪系统上所有的 bug 都被关闭了以后，你会感到如释重负，终于可以松一口气了。

当项目成功交付后，你是否感到大脑进入了疲惫期，上网，聊天，写自己感兴趣的小程序，项目已经结束，对于上个项目你已不愿去想它。

既然距离下一个项目中间还有点时间，就找点轻松的活干吧，免得老板给你找些更受罪的事让你充分体会生活。“温故而知新”，这句古训总是不会错的，也可以帮你对项目的进行过程作个分析，总结，最好再将结果做个汇总或图标。老板一目了然，觉得你能够想到这点也实属难得，而且自己也能有些收获。 

这是在一个阶段项目结束后最容易忽略的地方。

开发阶段，最好寻找的依据就是 Bug 记录，Bug 管理系统已经记录下了所有的 Bug 的现象，分 类，所处模块，发生原因。虽然几乎所有的 Bug 管理系统都提供报表，分类汇总等功能。但是它也只是提供一个数据汇总功能。真正对这些信息作认真分析还需要人为干预，这就需要积极开动你的主观能动性了。

1、对bug范围做分析

对 Bug 的修正过程分析后，你可能发现绝大部分 Bug 都和少数几个关键的代码文件有关系， 而不是大部分文件都需要去修改。例如我有一个模块，共几十个代码文件，80%的 bug 在修正中只对其中两个代码文件有修改。也就是说，Bug 虽然表现形式可能不同，但是追溯其发生原因，大部分都在很有限的代码范围内。其实，这样缩小范围也有助于问题的定位与解决。

但是，这些代码都不是关键部分，而出乎意料的是它会放在一些不怎么重要的地方。原因是关键代码（比如数据库操作）在程序员开发时就多次运行，验证过了，或者都已统一做了封装，包含在某个框架中，可靠性高，出现 Bug 的机率不大。非关键的部分会常常会落在一些不太受重视的细节，比如焦点的移动，控件的对齐，特殊数据类型（时间，货币）的表示格式，字体， 颜色等等，又或者某些值的计算或精确度有误。而从这些细节再细分下去，一个模块又会集中在其中的几项上，比如，70％的 Bug 又属于焦点移动和表示格式的问题。

2、对bug原因做分析

对于 Bug 出现的原因也不容忽视，做好这一环甚至可以达到bug预防的效果。比较常见的有几种：

代码实现与需求设计不符；
单纯的实现错误或遗漏；
对某个点设计和实现同时实现出现逻辑相互冲突的情况，又或者两者都遗漏；
因为主观认为问题较小不重要或容易忽略没有人提出，直到测试时才发现；
没有遵守项目的规范， 本不是 Bug，但是测试人员和开发人员的理解不同。 
以上 Bug 出现的原因中对于需求，开发，测试不一致的问题，常常是由于三者之间对于模块要实现什么和要测试什么没有一个统一的标准，这也是很多不成熟小公司流程上所出现的问题。

所以首先必须有一份文档来作为参照，如果出现理解上的偏差或不一致，可以到这里找答案，如果找不到，需查缺补漏。 

对于实现阶段出现的问题，除过上面说到的标准不一致外，再主要就是人为因素造成的问题，比如程序员自己单纯的错误或粗心，遗漏了某个细节，或者是理解上的偏差，虽然实现了，但是不完全正确。

对于后者，可以是因为一个自己模块的特殊功能，代码就写的有问题，也可以是因为一个在多个模块中都要用到的功能，但是没有作统一的封装，大家按自己的思想各写各的，结果是实现方式上的差异使得Bug出现机率的增高。对于第二种情况，应当首先考虑将这个功能封装起来，统一调用，并且写下文档。对于测试，在保持和设计，主要功能实现一致的前提下，可以对次要测试点分为通用部分（焦点，字 体，控件大小，日期，货币的显示格式），非通用部分（除通用部分外该模块自身要实现的 功能），再进行正常情况，异常情况分类，进行测试。 

以上的分析都是基于单元测试的结果，并且只针对一个模块，虽然有很大的局限性，但是相信这样对于开发和测试会变得更有针对性，后面项目的开发也会有很有帮助。一方面可以减少 Bug， 一方面测试的效率也可以提高！
最后感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：

文档获取方式：

这份文档，对于想从事【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴我走过了最艰难的路程，希望也能帮助到你！

以上均可以分享，只需要你搜索vx公众号：程序员雨果，即可免费领取