如何保证测试质量，或者测试覆盖率？

1. 从需求分析来说，

1）需求要理解、明白

2）有哪些关联的模块，数据库有哪些关联的点

3）做完需求分析，要进行需求评审，防止遗漏的地方或者理解不正确的地方

4）站在用户角度去分析，有疑问的地方要跟产品和开发进行沟通。

2. 从测试用例来说，

1） 设计测试用例要认真，预期结果要检查以确保正确

2）进行交叉测试，多个人覆盖不同的测试点，

3）按照公司的测试规范去执行（测试流程），一定要执行冒烟测试。

3. 从bug regression来讲，

1）根据开发评估出的修改related的关联模块要进行回归

2）bug本身要回归

3）根据自己的测试经验，考虑一些开发没有考虑到的模块

-----------------------------------------------------------

1. 测试上线标准

1）测试用例是否执行完成

覆盖产品需求点的用例，要达到100%执行

2）剩余的bug和严重等级要达到标准

（什么标准？比如说不存在1，2级严重程度的一个bug，且剩余bug需要经过产品经理、开发经理、测试经理三方讨论决定）

3）上线前的最后一轮回归测试是否完成

2. 测试覆盖率

作用：用来监控测试质量，量化评估测试是否覆盖了所有的内容，哪里有没有测试到的。

Test coverage helps monitor the quality of testing, and assists testers to create tests that cover areas that are missing or not validated.

Product coverage – What aspects of the product did you look at?

Risk coverage – What risks have you tested for?

Requirements coverage – What requirements have you tested for?

代码覆盖率

覆盖率给研发带来的价值：

• 分析未覆盖部分的代码，从而反推在前期测试设计是否充分，没有覆盖到的代码是否是测试设计的盲点，为什么没有考虑到？需求/设计不够清晰，测试设计的理解有误，工程方法应用后的造成的策略性放弃等等，之后逐步补充测试用例。
• 代码覆盖率高不能说明代码质量高，但是反过来看，代码覆盖率低，代码质量不会高到哪里去，可以作为测试自我审视的重要工具之一。
• 分析变更代码的覆盖情况，从而保证对变更的测试充分，增强发布成功率与信心。

Jacoco插件，opensource，代码覆盖率工具。即行覆盖率，分支覆盖率等

-最好的实践，增量代码覆盖率，变化的代码=被测分支的代码与目标对比分支的 diff（通常目标对比分支是我们最终会合入的分支）。

增量覆盖率=变化的被覆盖的代码行/变化的代码行。

增量代码覆盖率 意义：

• 发布之前是否存在漏测
• 针对漏测完善用例集
• 增强变更发布的成功率与发布信心
• 通过追求增量覆盖率进而提高被测应用的整体测试充分度

3. test report

持续集成