每个软件开发人员和团队都在尝试解决一个熟悉的问题：“测试多少才能让软件版本获得发布资格？”这在很大程度上取决于软件的类型和质量目标。例如：在前东家负责的系统属于对内的一个内容生产平台，用于CQC团队录入内容，每次发布新版本的质量准出标准是不能影响核心录入链路，即整个录入链路不能有block缺陷。而当前团队则则要求在基本功能的覆盖上还要满足“三板斧”(可灰度、可监控、可应急)。
无论被测应用是什么，测试充分度的问题都很难明确回答，因此更好的方法应该是提供经验法则，来制定适合所在团队的测试流程和质量策略。具体总结如下：
1、记录测试流程
如果你正在进行项目测试，务必记录整个测试过程。这对于事后做项目分析以改进项目质量至关重要。当然，如果这个是你的第一个迭代版本，最好提前做一个文档形式的测试计划和策略。事实上，测试计划或策略是任何产发布都应该附带的东西。
2、充分单元测试
尽可能推进开发在编码的过程做单元测试。在写单测的时候所开发的服务依赖的外部服务可以使用Mock，它没有真正实现依赖的服务逻辑，只是根据契约返回测试预期值。
在包括谷歌、BAT在内的许多公司，都有要求任何代码的更改需通过相应单元测试用例才能合并到主分支。随着代码库代码量的递增，在代码提交之前执行大量单元测试是缺陷被引入代码库之前捕获缺陷的重要手段。这大大节省了以后编写集成测试、调试和验证代码修复的时间。
3、持续集成测试
集成测试是单元测试的逻辑扩展，集成是指多个单元的聚合，许多单元组合成模块，而这些模块又聚合成程序的更大部分，如分系统或系统。集成测试采用的方法是测试软件单元的组合能否正常工作，以及与其他组的模块能否集成起来工作。最后，还要测试构成系统的所有模块组合能否正常工作。集成测试所持的主要标准是《软件概要设计规格说明》，任何不符合该说明的程序模块行为都应该加以记载并上报。
通常，开发人员会认为集成测试可有可无，直接进行完整的端到端测试就行了。再者，后者确实会像用户一样测试(使用)产品。实际上并非如此，进行全面的集成测试与单元测试也非常重要。
由于集成测试相比于端到端测试所需外部依赖(服务、环境)更少。因此集成测试将比较多依赖的端到端测试更快、更可靠。
4、关键链路端到端测试
如上已经讨论了单元测试、集成测试，接下来毫无疑问要聊聊端到端测试了，因为端到端测试也是模拟用户真实的使用场景，所以非常重要。端到端测试测试的不仅是独立模块的功能，而且包含各模块功能的整个流程。Google称这个流程为用户核心流程（CUJ）。了解CUJ，通过端到端测试（当然希望以自动化方式）验证，即可完成测试金字塔需要覆盖的各个层级。（了解端到端测试，阅读《端到端测试详解》）
5、非功能性测试
单测、集成和端到端测试手段保障产品的功能质量。但是产品的非功能也同样重要，了解非功能的测试方法也很重要：
- 性能测试：测试应用程序或服务的响应时间和吞吐量。
- 负载和可扩展性测试：在越来越高的负载下测试应用程序或服务。
- 容错测试：测试应用程序在依赖服务失败时的表现。
- 安全测试：测试服务或应用程序中的潜在安全漏洞。
- 无障碍测试：确保产品对每个人都无障碍和使用产品，包括各种残疾人。
- 本地化测试：确保产品可以在特定语言或地区使用。
- 全球化测试：确保该产品可供世界各地的人们使用。
- 隐私测试：评估和减轻产品的隐私风险。
- 可用性测试：用户友好性测试。
6、了解代码和业务的覆盖率
从质量角度来看，我们已经从功能和非功能角度阐述了高充分度的前提。当然这还不够，还要从度量角度回答这个问题，这就不得不说代码覆盖技术了。
维基百科有一篇关于代码覆盖的文章，介绍了不同覆盖率类型的覆盖范围，包括语句、分支和条件覆盖率。当然，业界有很多开源工具可用于度量主流编程语言（如Java、C++、Go和Python）的覆盖率。部分工具包含在下表中：
7、持续复盘改进质量
了解和改进质量的一个非常重要的手段就是软件发布后获取线上用户的反馈，通过用户反馈不断提升产品质量。
源自公众号 软件质量保障