摘自http://blog.csdn.net/xia_xia0919/article/details/50600374

我在这里讨论的方法主要是针对互联网企业的测试，可能对传统企业的测试来说会有点不同，但是大体上是适用所有公司的测试情况的。

版本发布后大部分测试人员的意识里面都会认为该要好好休息一下了，放几天羊，做做其它和已发布版本没有相关的事情。其实版本发布后测试人员还有很多事情

需要去处理，需要去总结、归类、反思、分享。我这里主要探讨几个问题：版本发布后用户反馈如何；版本测试过程中碰到了那些问题；版本测试发现的缺陷情况如

何；测试过程中有没有漏测；

第一：版本发布后用户反馈如何。

一般的系统需要都需

要提供一个用户反馈入口给到用户，这个功能在互联网企业基本上都会有，当用户在使用过程中发现问题时用户会提交问题到公司的support系统，客服人员

会跟踪用户反馈的问题。而且客服人员会定期推送系统的质量报告给到相关人员。那么除了客服人员跟踪用户反馈之外，测试人员要怎么对待用户反馈呢？

1、用户反馈的问题是不是一个bug？如果是的话就要分析为什么在测试环境下没有发现，而到了用户那边就出现了：是我们的测试场景覆盖不够吗；是用户的环境太复杂了，和测试环境有多大的区别；还是测试人员偷懒、过于自信轻松放过了bug；

2、用户反馈的是以前系统有的功能现在没有了，操作习惯改变很大。那测试人员就要反思，为什么我测试的时候觉得系统操作起来很方便，而且操作习惯改变也

不大。是不是测试人员的思维习惯和用户差距很大，文化差异也大；那测试人员要总结如何站在用户的角度上去思考问题，更多的学会换位思考；体验测试如何要做

得更好。

3、软件在用户那出现crash了。为什么在测试环境下没有出现相同的crash呢？是用户环境复杂，还是开发人员在测试环境下系统根本就没有接入crash上报模块，即使软件出现了crash也无法得知。

4、用户反馈改版后的系统和竞争对手的比差太大了，很垃圾。测试人员要反思的问题是：在测试的时候有没有关注竞争对手的软件，有没有做竞品分析，产品人员做的竞品分析是否靠谱；有没有关注竞争对手软件的相关非功能性表现如何（性能，体验，内容丰富度）。深入测试

第二：版本测试过程中碰到了哪些问题。

由于在测试时任务比较多，时间少，测试过程中发现的问题只是记录了bug，测试的知识点也是粗略的记录，没有形成系统的文档。测试人员应该利用版本发布后空出的相对充裕的时间来总结自己记录的信息，形成文档，并且分享出去。

1、测试过程中碰到系统中所使用的新技术点自己不清楚的，需要在这时候进行学习总结。

2、测试环境是否准备充分？

3、测试时间估算是否准确，偏差有多大，为什么会出现这种原因。

4、测试用例的粒度是否过粗还是过细？

5、测试人员的配备是否合理？新老员工比例如何？

6、测试辅助工具的使用有碰到什么问题？

7、在测试过程中是否感觉到重复的操作很多，是否考虑可以自动化，自动化的成本如何衡量？

第三：版本测试发现的缺陷情况如何。

缺陷记录是测试人员的宝库，但是很多测试人员甚至包括测试leader对缺陷记录的利用一直停留在很初级的水平上，没有进入深入的挖掘，没有能

够总结出一套属于自己组内的缺陷模式，导致每个版本发布时总是出现相同的缺陷，而且不同人接手不同项目的测试总是会犯一些以前犯过的错误。针对这种情况，

测试人员是否要思考下有没有什么方法来改善，来充分的利用缺陷？

1、缺陷产生的原因分析。缺陷找到后，需要弄清楚为什么这里会出现问题，其它地方没有问题。缺陷产生的根本原因是开发人员的经验欠缺呢？还是系

统比较复杂，涉及到的交互和协议很多，单个开发人员不可能完全掌握？还是产品的需求定义不明确？甚者是开发人员的懒惰找出代码对异常情况的考虑不周？

2、缺陷是否能够归为一类，是否可以抽象出共性的问题，比如缺陷生成的功能点、场景、业务，测试业界是否有类似的缺陷模式来定义，如果没有的

话，我们自己是否可以明确定义这类问题，并且分享给业界。这类缺陷是否在不同项目下出现过，且出现的频率很高。测试人员对这类缺陷应该进行抽象和总结并且

分享给开发人员和管理层，减少他们再次产生同类缺陷的成本。

3、对于比较难重现的缺陷测试人员是否可以通过编写自动化工具来复现，创造特定的环境来使bug现身。

4、bug严重等级分布。致命、严重、一般、建议类的bug分别如何，是否符合正态分布。

5、缺陷密度如何。那些模块比较容易产生bug；那些开发人员的bug数比较多，且bug严重等级高；那位产品提的需求不够严谨，经常出现需求

变动导致bug，需求定义不准确导致bug；那类环境下出现的bug多（比如web的兼容性测试，是ie6环境下bug多呢？还是firefox下等）。

第四：版本漏测原因分析。

随着计算机软件的复杂度增加，系统内部各模块之间的交互通信、系统与系统之间的交互越来越复杂，但是开发人员的能力提升水平却是比较缓慢的，而

且优秀的开发人员更加少，合格的开发人员也不多，导致编写的代码存在很多缺陷。我们测试过的一个web系统，开发周期大概1多月，但是测试时间才2周，发

现了300多个bug。即使这样发出去后还是会出现一些漏测的情况。针对这种情况，我们有什么办法来分析并且减少漏测呢？

1、测试用例覆盖度如何？有没有覆盖到用户常用的场景、操作习惯、用户数据真实度模拟。

2、代码覆盖率有没有至少做到行覆盖，对于未覆盖到的代码有没有进行风险评估。千万不能认为用户的环境不会这么特殊而放弃测试。我们有一个版本

特性是测试软件给用户开辟一块硬盘缓存的特性，开发想当然的直接划分了1G的空间给到程序，没有考虑到如果用户的虚拟内存是分配在系统盘，且如果系统盘的

剩余空间小于1G时程序会不会出现crash。测试人员在做代码差异覆盖时已经发现这个问题，但是在和开发确认后就轻易的放过去了。

3、测试人员的测试思维是否狭窄，对被测系统的各个底层理解不够深入，所检查的测试点都是比较简单，导致系统会出现漏洞。比如在测试文件上传功

能时，程序不允许上传exe等可执行文件。如果只是简单的检查是否文件名后缀，并且只是前端javascript来做检查，后台不做二次检查的话，就很容

易被用户使用fiddler等抓包调试工具轻松构造条件绕过。

4、测试人员的经验是否不足，测试leader在人员安排方面是否有疏忽，没有进行新老同事搭配，没有对重要且风险高的功能安排资深的测试工程师辅助进行把关。

5、测试时间不够，导致计划测试的内容结果没有测试到。针对这种情况测试人员在版本发布前是否有进行风险分析并且知会到相关的owner。