一、概述
质量和效率是提高项目质量的两个维度。
质量在易用性上，有一些优化被“老师”提出来，其他的基本还行。
效率上，由于自动化实施早，自动化部署也上了，测试只专注功能和接口的测试，测试是非常快的。甚至有很多时间去摸鱼，有更多的思考时间。
项目快一年了，目前情况：
- 完整的项目流程，明确说明了项目每个阶段的具体产出；
- 开发和测试产出的归档；（需求文档、组件依赖、部署方案及资源要求、提测文档、测试方案、测试文档、前后端镜像、接口用例与接口自动化用例）
- 完成了接口自动化用例；（总接口覆盖100%、接口中参数的等价类覆盖100%、功能流程覆盖100%、其他的用例暂时没有）
- 完成了自动化环境部署；（直接登录k8smaster机器，执行部署的。暂时就先这样，后续还是要优化成“直接创建jenkins任务的镜像，执行部署完成后，直接自动销毁”）
但是：
-
对测试来说，虽然完成了接口自动化和自动化环境部署，但是，接口用例的覆盖率是多少，没有标准的专业的数据去说明。不能够专业的说出“项目接口自动化用例覆盖接口100%，代码覆盖xxx%”的情况，没有数据支撑。
-
对开发来说，完成代码后的单元测试，单元测试覆盖率是多少，没有数据支撑。单元测试报告和报告的归档是空的，也不合适。
-
上线发布的模式，灰度发布、回滚策略、数据库数据清理和更新策略。
-
线上监控、线上数据回传测试环境，模拟线上数据测试、数据脱敏。
举例可能不恰当或者不适用，但是目标是对标互联网大厂的项目 。不是普通公司的普通项目。所以，这也是写提高测试质量长期计划的一个原因。
二、阶段一：提升代码覆盖率
覆盖率统计的使用级别：
- 第一个级别 ：只是去统计，统计得出一个数字；
- 第二个级别 ：看未覆盖的代码，从而丰富我的测试用例；
- 第三个级别 ：我的用例开始细化了，我清楚的知道每个用例对应的代码覆盖；然后可以利用这个关系进行反推，根据代码变更找到要测那些测试用例，测测试用例的时候，我可以知道哪些东西没有测试完全。
- 第四个级别 ：对流程进行建模，你现在看到的只是代码是否覆盖，在它之前，走的代码流程是什么样子的？我们要把这个控制流以链路的形式分析出来，类似于分布式的一个链路追踪。比如“zipkin”这个工具，有这个东西，系统的运行就可以一目了然（能分析到函数级别），根据trace id能做到，哪个人，操作了什么，他测试过程的覆盖率是多少，类似这样的结果。当然，执行的自动化用例+单元测试用例，在整体覆盖率占比多少，也是一清二楚。
目前，利用覆盖率去完成第二、第三级别的要求，就达到阶段一的需求。第四级别，属于精准化测试，需要掌握的技术栈会很多，对测试人员能力要求也更高。目前行业中还没有开源的精准化测试的工具。只能通过jacoco等覆盖率统计的工具，自己去实现精准化测试平台。python语言就更少了，利用coverage模块，获取覆盖率统计数据。可以作为长久目的去一步步走。
2.1 要求
- 单元测试，补充单元测试用例，得到单元测试的代码覆盖率。
- 已有的接口测试用例，在执行后，代码的覆盖率是多少？功能的覆盖率是多少？有没有工具去展示覆盖率？然后用例去查漏补缺。
2.2 单元测试
单元测试，xx同学在xx做过单元测试，我感觉非常棒。
利用mock技术、unittest框架编写单元测试用例，最后利用python的coverage模块，完成项目单元测试覆盖率的统计。生成的html报告，也非常直观的展示了覆盖情况。
虽然，报告展示的只是语句覆盖率 的数据，但是在写的单元测试用例中，依旧看到有分支覆盖 的测试用例。也就达到了条件覆盖 的测试标准。条件覆盖它综合了“语句覆盖（行覆盖）”和“分支覆盖”。已经达到了单元测试的目的，测试最小单元。
白盒测试 的执行手段涵盖单元测试、集成测试。一般用代码覆盖率作为白盒测试的主要度量指标 。
覆盖率常见概念如下：
- 语句覆盖：每行代码都要覆盖至少一次（最基础，不能保证完整度）
- 判定覆盖：判定表达式的真假至少覆盖一次
- 判定/条件覆盖：判定覆盖与条件覆盖都必须覆盖
- 条件组合覆盖：判定表达式中的所有条件组合都需要覆盖
- 分支覆盖：控制流中的每条边都要被覆盖一次
- 路径覆盖：所有的路径都要尽量覆盖
- 指令覆盖：一行代码会被编译为多条指令，尽可能的覆盖所有指令
- 方法覆盖：每个方法至少要被覆盖一次
- 类覆盖：每个类至少被覆盖一次
总结：
- 单元测试，能达到90%语句覆盖、100%分支覆盖的要求，单元测试就很不错。但是并不做强制指标。
开发同学需要花时间去写单元测试用例，增量代码优先。然后完成单元测试的测试覆盖率的报告。作为数据，也进行单元测试的归档。（测试写单元测试也不是不行，能力是一个原因，还有就是代码熟悉的时间成本是另一个原因。这也就是单元测试通常都是开发同学自己去做的一个情况。）《Google软件测试之道》中：“you build it ,you break it ,you fix it”,解铃还须系铃人，开发对自己写的代码负责，比专职的测试更适合做测试工作。
2.3 接口测试
接口测试包括了集成测试和功能测试，甚至性能、安全等都可以在接口测试中做。所以，如何保证接口测试的覆盖率呢？（在这里我们先不考虑性能、安全等，只看集成和功能）
这个文章，我认为写的非常全面：如何保证接口测试的覆盖率？ - 知乎
想要提高接口测试的覆盖率，首先要知道代码覆盖率低的原因，才能更好的采取措施来提高代码的覆盖率
大白话来说，影响点有这些：
- 代码覆盖率：度量代码的覆盖度，一般通过行覆盖、分支覆盖进行度量。
- 功能点覆盖率：根据被测业务的接口数进行统计，使用已调用接口数/总接口数度量.
- 参数组合覆盖率：根据接口的可能参数组合度量。使用参数的测试范围/总的组合测试范围度量
- 流程的覆盖，部分接口比如订单，并不是仅仅只调用一个接口，那么需要多接口调用的情况下就要考虑各种接口的不同情况
接口测试中，但是无论是自动化还是手动测试，都会执行程序，然后看代码运行，得到覆盖率的一个情况。利用运行的情况，看代码覆盖率，这样的场景需要去看下，搜索下。
总结：
- 开发同学：提高和保持提供的接口文档的质量；
- 开发同学：在做一个功能的时候，更清晰的将每一步表达出来，流程图方式。（这一点我们项目就特别好
）； - 测试同学：写的用例，无法实施的过程，找大佬帮忙；
- 测试同学：测试人员加强学习，深入理解业务，用例或者测试方案写出时，项目组成员多注意、多发表意见。（我们项目贼棒）
- 开发和测试多沟通，毕竟都是为了共同的目标：“质量”。《Google软件测试之道》第一章就非常明确的说出了这样一句话：质量不等于测试，当你把开发过程和测试放到一起，就像在搅拌机里混合搅拌那样，直到不能区分彼此的时候，你就得到了质量。还有一句骚话：测试是开发过程中必不可少的一部分，当开发过程和测试一起携手联姻时，即是质量达成之时。
2.4 todo：给出接口测试的覆盖率
问题：
-
怎么，利用自动化用例和功能执行的手动操作，得出有效的覆盖率？（类似于精准化测试平台那种？）
-
代码能力一般、coverage.py模块，了解太浅。精准测试python代码覆盖率（下）--- coverage.py api_理论上python接口测试可以覆盖多少比例_小生测试的博客-CSDN博客
-
怎么像做项目一样，慢慢给出一个最初的版本，然后去迭代出牛比的覆盖率报告？
三、阶段二：精准化测试
xxx
。
