【转载】关于软件测试的几点思考

      无心中在csdn博客上看到邱鹏写的一篇博客，关于关于软件测试的几点反思 - 测试工做的三个阶段，发现和本身的想法不谋而合，整个思考模式和方向和我在某公司实习的时候是同样的，百度之，真的是该公司的高级测试人员。看来我有找到一位大神了。向大神学习，向大神看齐。关于测试的反思写的不错的，我想将齐摘录下来，固然也能够到原址去看。

测试的三个阶段

第一个阶段：发现和解决bug的阶段
     这个阶段的思路基本上尽量发现更多的bug，见一个灭一个，来两个灭一双。发现bug，解决后验证bug，没有任何根源性的推进，或者推进的效果很差。
     这个阶段，测试工做主要集中在发现bug，要作好这个，须要多个方面的努力，好比下面这些：
- 更高效的发现bug，考验测试设计的能力。
   这方面有很是多的方法和技巧，以及经验，这里不细说。
- 发现bug以后如何清晰的描述，定级，以及跟进和验证。 
   这个看似简单，可是你会发现不少测试工做作了几年的人这样的基本功仍是不够扎实。也可能没有受到过很好的训练或者一直没有人指导。
- 对业务和架构的理解能力。 
   没有这方面的能力，很难发现一些深层次的bug。而这样的能力对于快速学习和一些技术基础也有不低的要求。
- 发现bug以后若是触类旁通的尽早发现更多相似的bug。

     你们看到的不少经典的测试书籍讲的基本都是这个阶段作的事情，好比Software Testing，How We Test Software at Microsoft，以及探索性测试相关的书籍，都是专一在如何更高效的发现缺陷。

     上面这些东西都是一个业务测试人员的基本功。看似简单，可是作好并非一件容易的事情。也许这些事情一点都不cool，不sexy，甚至去作职级评审的时候不占优点，可是对于系统质量的提高，是切切实实带来很大帮助的，其工做的价值应该获得承认。可是若是一直停留在这个阶段，就陷入到上面例子中说的扫马路的阶段，由于若是没有其余方面的改变，每次都有那么多的bug。

不过不少时候，咱们的测试停留在这个阶段也是由于现状，考虑下这样的状况：
- 开发基本不自测，甚至没有自测的环境，特别是涉及多个系统的对接。
- 提测后不少基本的功能都不能正常使用
- 项目管理比较混乱，可是最终的发布日期又被老大们定死，因此测试时间经常被压缩
并且，并且没有对于开发人员的质量方面的考核，那么很长一段时间，咱们的测试将处于这个初级阶段。
（这也是该公司目前的一个现状啊）
我相信目前还有很多的团队是处于这样疲于应对的状况下，不仅是小公司，可能一些大公司的部分项目也是如此。随着整个研发体系的发展和深刻，咱们应该有更高的追求。

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

    最直接会想到的就是，怎么让别人少丢垃圾，让自己的bug就更少一些。若是咱们作的工做只是发现bug解决bug，那么就是一个消耗战。不能造成一个良性的循环，就不能持续的优化，工做的长期累积价值就体现不出来。
这个阶段核心的思路是对缺陷作分析和考核，并作研发流程中主要问题的梳理和改善。

    经常作的事情能够从下面几个方面来看（这里会是主管以上的人来负责）：
1. 作质量数据的统计和分析
    收集的数据不少，常见的有：
     - 外网的bug状况，包括事故，及影响的程度
     - 测试阶段的bug数量，分布（按系统，团队，开发我的），严重程度，bug的类别等维度
     - bug的横向跨团队和系统的对比，纵向的和历史状况对比
     - 版本发布的状况，代码变动行数的状况
   从这些数据的收集中就能发现不少问题，好比问题集中在哪里，哪些模块，哪些人，哪些类别等等，以及有没有改善。

2. 问题的追溯和对于开发的考核
     这个方面也许有一些争议，可是我仍是以为这个是一个很重要的方法。光靠观念和自觉是不够的，必须要有必定的反馈机制，就比如交规必定是配合着扣分和罚款等手段，不然记录闯红灯有什么意义呢？并且现实的来讲，这些方法起到约束的做用，也是一种心理暗示，要作本身作的东西负责，也便于养成好的习惯。
    一般的考核指标涉及这些方面：
    - 编译失败次数的考核
    - 外网事故和bug的数量
    - 测试阶段的bug，特别是基础功能bug和严重bug
  粗略的列了这么多，其实能够有不少，好比配置文件改错的状况，漏提测文件的次数等等。

对于bug方面其实也是同样，若是开发在意（或者被迫在意）外网bug或者被测试发现的bug数量，他写代码的时候必定会更仔细，也会作些简单的自测，让提测的质量更高，提升了整个研发系统的效率，同时也是提高了质量，由于quality must be built in。

我我的的经验，做为测试人员几乎同时面对过两个开发团队，一个有上述的考核，一个没有。表现出来的版本质量和对质量的关注彻底不同，并且前者也并无出现开发和测试的对立，以及测试不敢提bug等负面的状况。

3. 对于测试的考核
      除了对于开发的考核，一样也有对于测试的考核，这样也更加的公平。
测试的考核一般考虑下面的指标：
     - 漏测：绝对数量或者漏测率
     - 版本的工做量和测试效率
     - 发布延期的状况
若是测试有这样的压力，也须要不断努力去发现更多的bug。

      提及考核，总有人以为这不符合智力劳动的状况，或者互联网的做风，其实不太理解为何会这么以为，放眼望去，有什么工做不被考核呢，sales要背quota，为何软件开发和测试不能对本身的工做的质量负责呢？固然，具体的指标如何去定才更合理那是另外一个要去考虑的。
      换个角度来看，适当的压力（不该该致使焦虑和扭曲的作法），实际上是让一我的表现最好的状态。

4. 推进开发的自测
     这个问题一贯是个老大难问题。愿意自测的开发团队你不用太多的推进，不肯意作的推进也很难，或者你没法判断他有没有作自测。并且这方面，一般取决于开发负责人的观念和态度。
若是是介于之间的，咱们能够作一些事情，好比：
    - 统计测试阶段的bug中，属于开发可自测发现的比例。经过这个能够看有多少bug是不该该到测试阶段的，以及横行纵向的对比。固然这个标准要本身拿捏。
    - 给出一个自测的checklist。开发在提交前要完成这个list并正式的给出报告。这个方式咱们曾经在一个项目中用过，效果不错，基本功能都经过这个保证了，前提是开发负责人承认。
    - 有一套自动化验收的用例，能够挂接到自动部署以后或者daily build。前提是咱们的自动化要足够的问题，效果才会好。

     这个阶段除了业务测试的努力，也体现出了QA的价值。这里的QA是指质量管理，有的地方叫SQA，专一在质量度量和研发流程的管理上。

      到这个阶段，发现事情顺了不少，质量也有更大程度的提高，并有改善的趋势。

 

第三个阶段：推进全面的质量提高
      到上面第二个阶段，咱们发现质量有了必定的提高，可是仍是有很多的问题，并且有些问题须要咱们把思路和眼界拓宽来看。这里讨论的一些东西可能更适合互联网的产品。
      这里列一些咱们能够去作的事情，受限于我的的经验，可能还很片面。

1. 研发流程的梳理
其实在阶段2的时候也可能有些团队已经开始作这样的事情，由于在分析质量和效率问题的时候，咱们发现不少问题不单纯是代码的问题，可能还涉及研发流程的不少方面，好比：
  - 需求不清楚
  - 跨团队的配合问题 （这是一个老大难的问题）
  - 代码版本管理
  - 技术方面的评审和你们的理解
因此整个研发流程的规范和梳理，以及配合对应的需求和版本管理的系统也是很是的必要，实际中发现效果也是比较的明显。并且还有一点体会，在接手一个很混乱的情况时，这样角度的数量和调整比技术方案的引入更重要和切中要点，能从40分到60分，技术是往80分走的过程效果更明显。

2. 提交测试先后作的一些事情
  - 代码的静态扫描
     这个方法不少的团队都在作，可是实际的效果彷佛差异不少，并且ROI也很难说，不过从方法自己来讲仍是值得去作的，对测试人员也提出来更高的要求。
  - code review
     这个开发应该要作，特别是开发间的交叉review，很是的有帮助。不过这个也和自测同样，取决于开发负责人的态度。另外，测试也应该去作，特别是对于diff 代码的review，咱们检查作了大概两个月的时间，发现仍是很是的有收获。发现了一些黑盒难以发现的问题，以及开发的代码夹带，而且对于这个版本影响范围的评估也更准确。但问题是短时间会花费测试更多时间，以及须要测试人员有必定的技术能力。

3. 测试能力的提高
    测试阶段有不少的事情能够去作，以为最主要的仍是两个方面
     - 自动化。 愈来愈以为这个是绕不开的话题，要想尽办法去作，作得更高效更全面。前面有篇blog也提到了一些轻量级的作法，业务测试的团队能够参考 http://blog.csdn.net/superqa/article/details/20644285
     - 辅助手段，好比代码覆盖率，特别是差别的覆盖率。这个你们都比较容易理解就不展开了。
     - 拓展测试的类型
     这个方面提及来有些泛，须要结合团队和业务的状况，好比安全测试，性能测试，兼容性测试等，去发现一些对于产品来讲很重要的风险。
     这方面有两个前提，一是咱们的基本功能质量到了一个阶段，可让你们腾出手去拓展测试的面，另外一方面咱们测试人员的能力要跟得上。

4. 发布环节的质量把控
     这个方面和传统的测试不太同样，并且了解到不一样的组织作法不一样，执行发布的人员可能不一样，有开发，运维，专职的版本管理或者测试来作。
     在咱们的实践中，发布后来都逐步收到测试这边，回头来看以为仍是有很多有帮助的地方。固然也不绝对的必须测试来作。
      - DO分离，避免了随意的发布，特别是在开发手上的时候。全部的bugfix都通过测试发布，能够更准确的度量质量（除非这个问题能够不修复，不然确定要过发布环节）
      - 知道最近发了什么，可能的影响是什么，须要线上关注什么。
      - 灰度。 互联网产品经常使用的一个控制风险和节奏的手段。
      - 扩容的快速自动化检查，这方面也依赖于自动化的建设。
      - 发布过程支持灰度的控制，备份和快速的回滚。对发布系统有必定的要求，并且有可追溯性。

发布处在整个研发流程很是关键的节点，在这个点能够作不少的控制，也能发现不少的问题，对于测试团队来讲，从这里能够发现不少的问题，作不少的提高，对本身和相关的合做团队。

5. 外网的监控
    发现发布后的问题，持续运营过程当中的问题，推进优化。
    一般监控能够分几个层面，粗浅的能够分红几类：
    - 运维层面的监控，好比机器，链路，资源使用，主要组件是否正常等。
    - 业务指标的监控，好比来自点击率，BI系统等。
    - 集成在产品里面的监控代码，咱们称之为模块调用监控。这个是全量的，有次数，成功率，响应时间等角度。  
    - 测试层面的自动化监控，关于在接口和功能层面。这个是采样的，可是从用户的角度来监控。
      以上这些监控都有对应的告警机制，能够第一时间发现问题，避免形成更大的损失。为了实现上面的监控须要作大量的工做，可是这些对于整个外网运营的质量很是的重要。

6. 外网事故和问题的收集，跟进和反向推进
     和前面的思路同样，若是只是发现问题解决问题仍是稍显被动，那么对于外网事故和问题的分析，仍是有不少推进性的帮助。

7. 用户的问题反馈和满意度
     进一步的质量不仅是系统自己的质量，而是从用户角度看到的质量，有时候这个可能稍微超出一些系统层面的问题，可是由于最终的质量仍是用户说了算，因此咱们应该扩展下思路。收集这样的问题的渠道有不少
     - 外网问题反馈，好比来自客服系统的，用户直接的反馈，如今不少app上都有反馈的功能。
     - 论坛信息的统计收集。我了解的另外一个测试团队，他们还专门开发了一个自动收集外部反馈，以及过滤分析的系统来帮助他们及时的了解外包的问题反馈。

8. 运营层面的质量
  更进一步，关注运营方面的质量，跳出传统意义的质量的范畴，关注咱们的业务指标，不仅是作一个高质量的产品，而是作一个业务上成功的产品。
   好比下面这样的例子：
     - 商品详情页的图片的质量
     - 活动页面和详情页面价格不一致的状况
     - 运营配置的错误致使的问题，哪些是能够监控发现，哪些是能够推进运营平台的规则检查?

      每次咱们的思路跳出一些框框，都会有不一样的领域。有点点哲学上的意味，不少领域作到后面，其实会超出那个领域自己的范畴。就比如高性能的汽车，到后面就不得不研究空气动力学这个本来是和航空有关的东西。可是，这是否超出了本意，若是去看待，又是另外一个问题。

       其实这样的三个阶段也是一个粗略的划分，并不必定要逐步的来发展，其实都是一些具体的作法和实践。以我目前经历过的实践只想到这样的层次，应该还有更高级的阶段。
       咱们越到后面咱们发现进一步的努力带来的提高幅度其实不大。可是不少事情也是同样，从85分到90分付出的努力可能比50到80分的努力还要大。另外一个更有趣的是汽车的极速和马力的关系，家用车100马力开到180km/h是能作到的，可是超过期速300，每提高一点须要增长的马力要大得多，到400以上，车时速每再增长一千米，功率须要提高八马力。这篇文章读起来很是有意思，http://blog.sina.com.cn/s/blog_4d0109a301000ajz.html

       写到这里，咱们能够跳到整个公司或者业务的层面，来思考一些对于测试更深层次的问题：测试团队存在的价值和意义是什么？
       只有对业务有明确的价值，业务测试，或者说整个测试团队才有存在的意义。只要业务OK，砍掉测试团队也不是不可能。咱们必须时不时的跳出咱们本身的思惟的圈子，站在整个事业部老大的角度来思考下测试的价值和意义。
在下一篇关于测试组织方面咱们能够再讨论下这方面的内容。
  
      还有一个体会：测试的水平反应整个研发体系的能力和水平。
      若是咱们的测试还专一在第一阶段，那说明整个研发还比较初级，开发和测试都是温饱的阶段。当咱们的测试人员再也不趴在地上盯着最基本的功能质量的时候，才有可能抬起来看看更多有价值，有帮助和有长远意义的工做，慢慢造成一个良性的循环。