如何保障你的被测系统覆盖度是全的？这个大家有什么好的方法论或者实践吗
1
根据需求，设计整理测试用例， 只要三方评审觉得完整就是全的。
PS 没有绝对意义上的百分百覆盖，只有基于需求和修改范围和风险评估来整理合理的覆盖范围。
- 让干系人相信你覆盖全了，哪怕一个用例，你能做到相信
- 不会出生产问题
- 如果出了生产问题，让大家觉得怪不了你
一层一层的包裹，第一层对需求规格进行测试，保证需求的覆盖度
第二层对需求进行拆解，按测试的维度进行大的测试规划
第三层 对每种测试 (功能 性能 可用性 安全) 再进行第二层规划
第四层 就是测试用例，用例要保证覆盖测试策略
第五层 用例的执行是否到位，问题是否记录
每一层出问题都会影响被测系统覆盖度，量力而行就好
软件测试原则：完全测试是不可能的
你这给自己挖了个大坑啊？为啥会有这样的诉求呢？
这个问题区分是向别人证明覆盖性和向自己证明覆盖性。
不少项目并没有可靠的测试依据材料，都是参考性资料和大量测试人员探索确认的功能内容。如果你去看各种黑盒功能测试方法的描述，它的前提就是存在这种理想化的东西。
如果只是对外证明测试工作的专业性，那么基本上把你现在的测试内容总结提炼一下就可以了，比如什么根据产品文档、需求手册、会议记录等等提取测试点外加业务回归之类一通描述就够了。这个有很多评论都是这样的，通常你对外做说明只需要确保对方信服即可。
而你自己思考覆盖是否完善，国家软考有一个软件测评师证书相关的书，从软件质量测评的角度提出了几个衡量软件质量的维度。包括功能、安全、兼容性等等，虽然这些都是测试行业老生常谈的用词，但是我觉得这是一个很好的角度。既然要谈覆盖，那肯定得基于某个标准/定义选择不同挡位对应精细程度来执行的不是麽。
软件产品和硬件一样，不一样的标准对应不同的产品。军工的民用的，高端的低端的各有不同，那么你的产品需要怎么样的质量标准呢？
测试充分性包含三个层次的：代码层次的测试充分性、系统（功能/非功能）层次的测试充分性、业务层次的测试充分性，而 “业务层次的测试充分性” 最具决定性的。
代码层次：这一层次在很长一段时间内，是被测试人员忽略的（能力不够）。万丈高楼平地起，测试人员需要花一部分精力去关注代码层的交付质量：代码静态分析、覆盖率验证、全链路测试、契约测试等，可以快速提升测试效率。同时，这个层次也是最适合做自动化的层次。
系统（功能/非功能）层次：大部分测试人员的主要精力都会花在这里（自称点工）。根据现有的需求文档或者 Story 描述，结合业务特点和自己的经验，通过测试用例的设计，验证功能点的正确性。并适当地开展一些非功能性测试。只关注这层，往往会忽略很多上下游业务依赖的错误，或者是底层代码在特定场景下的问题。
业务层：这里指的是需要有端到端的业务视野，从全流程的角度去验证复杂场景。这需要测试人员对业务非常熟悉，同时也熟悉业务关联的上下游系统。这类测试人员其实非常难得（在制造业的某个领域，曾经半年招不到一个，但这类人其实就业面也比较窄，因为对口的业务公司也不会太多，所以专注业务的同学需要慎重选择深入哪个业务）。
在做测试策略和测试设计时，需要针对以上三个层次都有所覆盖，才能提升测试的充分性。