数据库隔离级别（mysql+Spring）与性能分析
浏览数：31 /
时间：2015年06月12日
上一篇里我们讨论了测试的必需性，如果大家目前还在公司里做着测试的工作，那就说明还是落在必需的范围里面，或者至少一段时间是吧。那接下来我们看下既然需要做测试，需要做哪些事情。
基于我自己的一些理解和观察，我试图把测试工作的层次分成三个阶段，越到后面涵盖的范围越广。这里讨论的一些做法可能更偏向于互联网方面的测试，特别是第三个阶段。
首先我想先从一个例子开始，一个现实生活中的例子。
对于一个城市，假设我们的工作目标是提升环境的质量，减少垃圾。那么我们可以做什么？
首先，我们可以请很多环卫工人，出去打扫各个街道，这个马上就有了效果，环境变得更干净了。但是还不够好的地方是明天还是有很多东西需要打扫，治标不治本，只要一停下来立马回到之前的状况。
接下来，我们往前面想一想，为什么有那么多垃圾呢？其中一个方面是很多人乱扔垃圾。所以更进步一点的方案是，对于乱扔垃圾的人有些约束或者惩罚，比如抓到了曝光或者罚钱，这样扔垃圾的人会变少。
再然后，我们发现即使做到了上面，还是有不少垃圾，而且上面强制的方案也带来不少的反感。我们需要更深层次的思考，为什么会有那么多垃圾？是因为垃圾桶太少？设计得不合理？如果是这样，就需要从其他公共设施方面做一些改进了。
对于我们的测试工作，也是有类似的思路，只不过细节上要考虑更多。
第一个阶段：发现和解决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
粗略的列了这么多，其实可以有很多，比如配置文件改错的情况，漏提测文件的次数等等。
这里也许有很多的讨论，但是让我们看看一个实际的例子。下图是某个系统的编译失败的情况，在11月份的时候提出要统计并公开（并无惩罚条款）编译失败的情况，包含到开发的团队和个人等明显，12月份开始出现了明显的下降并稳定了。这个图隐藏了一些细节，如果剔除其他因素只看开发代码原因的编译失败则更明显，特别是后面有惩罚机制之后，进一步下降。
编译失败大幅的下降一方面是节省了大家的时间，另一方面其实也是提高了版本质量，想想如果有很多的编译失败，而且是到提交测试的阶段，这样的代码质量能好吗？是可能做过自测吗? 有了这样的机制，至少会更仔细一些。
对于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，砍掉测试团队也不是不可能。我们必须时不时的跳出我们自己的思维的圈子，站在整个事业部老大的角度来思考下测试的价值和意义。
在下一篇关于测试组织方面我们可以再讨论下这方面的内容。
还有一个体会：测试的水平反应整个研发体系的能力和水平。
如果我们的测试还专注在第一阶段，那说明整个研发还比较初级，开发和测试都是温饱的阶段。当我们的测试人员不再趴在地上盯着最基本的功能质量的时候，才有可能抬起来看看更多有价值，有帮助和有长远意义的工作，慢慢形成一个良性的循环。
基于我自己的一些理解和观察，我试图把测试工作的层次分成三个阶段，越到后面涵盖的范围越广。这里讨论的一些做法可能更偏向于互联网方面的测试，特别是第三个阶段。
首先我想先从一个例子开始，一个现实生活中的例子。
对于一个城市，假设我们的工作目标是提升环境的质量，减少垃圾。那么我们可以做什么？
首先，我们可以请很多环卫工人，出去打扫各个街道，这个马上就有了效果，环境变得更干净了。但是还不够好的地方是明天还是有很多东西需要打扫，治标不治本，只要一停下来立马回到之前的状况。
接下来，我们往前面想一想，为什么有那么多垃圾呢？其中一个方面是很多人乱扔垃圾。所以更进步一点的方案是，对于乱扔垃圾的人有些约束或者惩罚，比如抓到了曝光或者罚钱，这样扔垃圾的人会变少。
再然后，我们发现即使做到了上面，还是有不少垃圾，而且上面强制的方案也带来不少的反感。我们需要更深层次的思考，为什么会有那么多垃圾？是因为垃圾桶太少？设计得不合理？如果是这样，就需要从其他公共设施方面做一些改进了。
对于我们的测试工作，也是有类似的思路，只不过细节上要考虑更多。
第一个阶段：发现和解决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
粗略的列了这么多，其实可以有很多，比如配置文件改错的情况，漏提测文件的次数等等。
这里也许有很多的讨论，但是让我们看看一个实际的例子。下图是某个系统的编译失败的情况，在11月份的时候提出要统计并公开（并无惩罚条款）编译失败的情况，包含到开发的团队和个人等明显，12月份开始出现了明显的下降并稳定了。这个图隐藏了一些细节，如果剔除其他因素只看开发代码原因的编译失败则更明显，特别是后面有惩罚机制之后，进一步下降。
编译失败大幅的下降一方面是节省了大家的时间，另一方面其实也是提高了版本质量，想想如果有很多的编译失败，而且是到提交测试的阶段，这样的代码质量能好吗？是可能做过自测吗? 有了这样的机制，至少会更仔细一些。
对于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，砍掉测试团队也不是不可能。我们必须时不时的跳出我们自己的思维的圈子，站在整个事业部老大的角度来思考下测试的价值和意义。
在下一篇关于测试组织方面我们可以再讨论下这方面的内容。
还有一个体会：测试的水平反应整个研发体系的能力和水平。
如果我们的测试还专注在第一阶段，那说明整个研发还比较初级，开发和测试都是温饱的阶段。当我们的测试人员不再趴在地上盯着最基本的功能质量的时候，才有可能抬起来看看更多有价值，有帮助和有长远意义的工作，慢慢形成一个良性的循环。
郑重声明：本站内容如果来自互联网及其他传播媒体，其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享，并不代表本站赞同其观点和对其真实性负责，也不构成任何其他建议。
