持续集成
利用持续集成（Jenkins）平台，做到快速的构建开发代码，自动的单元测试化，来提高开发代码的效率和质量。
负责单元测试的开发人员，会收到失败构建的邮件；
负责集成测试的开发人员，会收到失败构建的邮件；
负责自动化测试（Selenium）的测试负责人员，会收到失败构建的邮件；
这种方式，确保单元测试、集成测试、自动化测试，有相关人员关注和维护。
图-9-持续集成
Sonar反馈
Sonar is an open platform to manage code quality. As such, it covers the 7 axes of code quality。
图-10-sonar分析结果
测试人员主要反馈问题如下：
Code coverage：团队要求代码覆盖率在80%以上；
Test success：团队要求测试成功率在100%；
Duplications：团队要求代码重复率在10%以下；
Violations：团队要求Major类别的代码规则缺陷在20以下；
开发团队必须保证每个环境的质量目标，才能够保证整个的质量目标。
小结：
测试人员与开发人员永远不是敌对关系，而是协助关系，确切来说是质量天枰的两边，任何一边的工作没有做好，都会失去平衡。
4、发布阶段测试
在发布阶段，开发人员、测试人员、QA人员主要做的事情，如下表所示：
作为测试人员的主要实践如下：
测试报告
完成验收测试，提供测试报告，给出测试数据度量，例如：
测试发现缺陷总数：测试过程中产生的去除状态为“无效”、“不用改”的缺陷数目。
测试发现严重缺陷数：测试过程中产生的并去除状态为“无效”、“不用改”的、且严重性为“Major”和“Critical”的缺陷总数目。
测试发现缺陷修复数：测试过程中产生的状态为“已关闭”的缺陷数量；
未解决缺陷数：去除状态为“无效”、“不用改”、“关闭”的缺陷总数。
缺陷修复率：（测试发现缺陷的修复数）÷（测试发现缺陷总数）×100％
严重缺陷率：（测试发现严重缺陷数）÷（测试发现缺陷总数）×100％
严重缺陷修复率：（已修复的严重缺陷数）÷（测试发现严重缺陷数）×100％
测试需求覆盖率：已测试需求个数÷需求总数×100%
缺陷统计分析报告
另外，测试人员还有一项重要工作，对当前版本的缺陷进行统计分析：
按缺陷级别统计：
按缺陷来源统计：
按缺陷状态统计：
测试进度和问题分析：
从BUG的严重级别分布来看，Major级别以上的BUG占12%，占的比重不高，说明大部分的主要功能已经实现了；
其中在sonar定义级别的缺陷，主要集中在代码规范和单元测试覆盖率，说明代码质量有待提高；
版本测试的前期时间较充足，后期随着开发提交完成的功能点增多，BUG数量增多，剩余测试时间变得紧张；
在版本测试期间，发现测试环境存在一次代码被覆盖、两次因开发人员操作失误影响测试执行的情况；
小结：
测试人员应当持续反馈、改进、总结每个版本发生的问题（不管是缺陷，还是过程中出现的），并对缺陷进行分析，总结出一些规律，帮助开发人员建立良好的习惯，改进代码的质量。
5、日常运营阶段测试
在日常运营阶段，开发人员、测试人员、QA人员主要做的事情，如下表所示：
日常运营阶段，并不是终止阶段，即便需求、开发、发布阶段暂停活动，只要产品提供服务，日常运营都存在着。
作为测试人员的主要实践如下：
版本问题反馈和改进提议
对日常运营发生的问题，总结反馈，提出改进建议，并且跟踪实施。
生产故障分析
协助开发排查生产故障，避免测试场景的遗漏。
6、总结
软件测试并不是保证产品质量的最后一道防线，测试人员也不是，测试人员的工作完全可以由更加资深的开发人员来完成，不过现实总是残酷的，目前测试与开发的比例为：1:3，在成熟的团队是这样子，另外一些还在持续改进的团队，由于资源不足，可能去到1:7。开发人员在相当长的一段时间内不可能完全替代测试人员，有个关键要素：思维方式不同，有句古话来形容：江山易改本性难移。当开发人员的思维方式改变的时候，那就成为测试人员了，倒不如把测试人员独立出来更好，并且培养给开发人员一定的测试素养，这个对保证产品质量都是有帮助的。
全程软件测试实践，强调的是贯穿每个阶段的测试活动，不论是开发、还是测试，要理解双方的活动价值，什么时候该做什么事情，什么事情该做到什么程度才算好，保证每个环节的质量，才能够保证产品的全程质量，另外产品质量不是测试出来的，而是构建过程中沉淀下来的，开发人员的素养、测试人员的素养、以及团队对开发测试过程的重视程度，决定了产品质量。产品质量就如同一块蛋糕，应当切分为小块，落实到每个人手里，让每个人尝到甜头，担当起来。
