版本发布后大部分测试人员的意识里面都会认为该要好好休息一下了，放几天羊，作作其它和已发布版本没有相关的事情。其实版本发布后测试人员还有不少事情须要去处理，须要去总结、归类、反思、分享。我这里主要探讨几个问题：版本发布后用户反馈如何；版本测试过程当中碰到了那些问题；版本测试发现的缺陷状况如 何；测试过程当中有没有漏测；javascript
第一：版本发布后用户反馈如何。前端
通常的系统须要都须要提供一个用户反馈入口给到用户，这个功能在互联网企业基本上都会有，当用户在使用过程当中发现问题时用户会提交问题到公司的support系统，客服人员 会跟踪用户反馈的问题。并且客服人员会按期推送系统的质量报告给到相关人员。那么除了客服人员跟踪用户反馈以外，测试人员要怎么对待用户反馈呢？java
一、用户反馈的问题是否是一个bug？若是是的话就要分析为何在测试环境下没有发现，而到了用户那边就出现了：是咱们的测试场景覆盖不够吗；是用户的环境太复杂了，和测试环境有多大的区别；仍是测试人员偷懒、过于自信轻松放过了bug；web
二、用户反馈的是之前系统有的功能如今没有了，操做习惯改变很大。那测试人员就要反思，为何我测试的时候以为系统操做起来很方便，并且操做习惯改变也 不大。是否是测试人员的思惟习惯和用户差距很大，文化差别也大；那测试人员要总结如何站在用户的角度上去思考问题，更多的学会换位思考；体验测试如何要作 得更好。缓存
三、软件在用户那出现crash了。为何在测试环境下没有出现相同的crash呢？是用户环境复杂，仍是开发人员在测试环境下系统根本就没有接入crash上报模块，即便软件出现了crash也没法得知。工具
四、用户反馈改版后的系统和竞争对手的比差太大了，很垃圾。测试人员要反思的问题是：在测试的时候有没有关注竞争对手的软件，有没有作竞品分析，产品人员作的竞品分析是否靠谱；有没有关注竞争对手软件的相关非功能性表现如何（性能，体验，内容丰富度）深刻测试性能
第二：版本测试过程当中碰到了哪些问题。学习
因为在测试时任务比较多，时间少，测试过程当中发现的问题只是记录了bug，测试的知识点也是粗略的记录，没有造成系统的文档。测试人员应该利用版本发布后空出的相对充裕的时间来总结本身记录的信息，造成文档，而且分享出去。测试
一、测试过程当中碰到系统中所使用的新技术点本身不清楚的，须要在这时候进行学习总结。spa
二、测试环境是否准备充分？
三、测试时间估算是否准确，误差有多大，为何会出现这种缘由。
四、测试用例的粒度是否过粗仍是过细？
五、测试人员的配备是否合理？新老员工比例如何？
六、测试辅助工具的使用有碰到什么问题？
七、在测试过程当中是否感受到重复的操做不少，是否考虑能够自动化，自动化的成本如何衡量？
第三：版本测试发现的缺陷状况如何。
缺陷记录是测试人员的宝库，可是不少测试人员甚至包括测试leader对缺陷记录的利用一直停留在很初级的水平上，没有进入深刻的挖掘，没有能 够总结出一套属于本身组内的缺陷模式，致使每一个版本发布时老是出现相同的缺陷，并且不一样人接手不一样项目的测试老是会犯一些之前犯过的错误。针对这种状况， 测试人员是否要思考下有没有什么方法来改善，来充分的利用缺陷？
一、缺陷产生的缘由分析。缺陷找到后，须要弄清楚为何这里会出现问题，其它地方没有问题。缺陷产生的根本缘由是开发人员的经验欠缺呢？仍是系 统比较复杂，涉及到的交互和协议不少，单个开发人员不可能彻底掌握？仍是产品的需求定义不明确？甚者是开发人员的懒惰找出代码对异常状况的考虑不周？
二、缺陷是否可以归为一类，是否能够抽象出共性的问题，好比缺陷生成的功能点、场景、业务，测试业界是否有相似的缺陷模式来定义，若是没有的 话，咱们本身是否能够明肯定义这类问题，而且分享给业界。这类缺陷是否在不一样项目下出现过，且出现的频率很高。测试人员对这类缺陷应该进行抽象和总结而且 分享给开发人员和管理层，减小他们再次产生同类缺陷的成本。
三、对于比较难重现的缺陷测试人员是否能够经过编写自动化工具来复现，创造特定的环境来使bug现身。
四、bug严重等级分布。致命、严重、通常、建议类的bug分别如何，是否符合正态分布。
五、缺陷密度如何。那些模块比较容易产生bug；那些开发人员的bug数比较多，且bug严重等级高；那位产品提的需求不够严谨，常常出现需求 变更致使bug，需求定义不许确致使bug；那类环境下出现的bug多（好比web的兼容性测试，是ie6环境下bug多呢？仍是firefox下等）。
第四：版本漏测缘由分析。
随着计算机软件的复杂度增长，系统内部各模块之间的交互通讯、系统与系统之间的交互愈来愈复杂，可是开发人员的能力提高水平倒是比较缓慢的，而 且优秀的开发人员更加少，合格的开发人员也很少，致使编写的代码存在不少缺陷。咱们测试过的一个web系统，开发周期大概1多月，可是测试时间才2周，发 现了300多个bug。即便这样发出去后仍是会出现一些漏测的状况。针对这种状况，咱们有什么办法来分析而且减小漏测呢？
一、测试用例覆盖度如何？有没有覆盖到用户经常使用的场景、操做习惯、用户数据真实度模拟。
二、代码覆盖率有没有至少作到行覆盖，对于未覆盖到的代码有没有进行风险评估。千万不能认为用户的环境不会这么特殊而放弃测试。咱们有一个版本 特性是测试软件给用户开辟一块硬盘缓存的特性，开发想固然的直接划分了1G的空间给到程序，没有考虑到若是用户的虚拟内存是分配在系统盘，且若是系统盘的 剩余空间小于1G时程序会不会出现crash。测试人员在作代码差别覆盖时已经发现这个问题，可是在和开发确认后就轻易的放过去了。
三、测试人员的测试思惟是否狭窄，对被测系统的各个底层理解不够深刻，所检查的测试点都是比较简单，致使系统会出现漏洞。好比在测试文件上传功 能时，程序不容许上传exe等可执行文件。若是只是简单的检查是否文件名后缀，而且只是前端javascript来作检查，后台不作二次检查的话，就很容 易被用户使用fiddler等抓包调试工具轻松构造条件绕过。
四、测试人员的经验是否不足，测试leader在人员安排方面是否有疏忽，没有进行新老同事搭配，没有对重要且风险高的功能安排资深的测试工程师辅助进行把关。
五、测试时间不够，致使计划测试的内容结果没有测试到。针对这种状况测试人员在版本发布前是否有进行风险分析而且知会到相关的owner。