文章目录
MC/DC（修正条件/判定覆盖）
MC/DC虽然是软件测试中的一个通用术语，但是它的正确用法以及安全相关的角色仍然需要在整个行业中澄清。
因为对所有变体进行100%的测试基本上是不可能的，所以在测试中总存在妥协。由于时间和预算都是有限的，测试人员几乎无法对一个软件进行完尽的测试。然而，测试才能为软件质量创造信心。测试中的挑战是资源的分配和资源使用的最优化。解决方案在于通过精心选择的“对测试完成的定义”来计划和确定测试目标的优先级，这样测试才更有可能成功。
计划是基于测试目标来制定的。它们可以有不同的颗粒度。从测试组织的一般定义开始，并在每个测试层级给出每个测试对象的详细信息。本质上，测试目标的定义涉及到平衡，即决定测试什么，不测试什么。而产品的开发状态和边界条件对测试目标确定的影响最大。
同时，必须遵守安全标准。标准在软件测试中扮演着重要的角色，特别是在与安全相关的产品中。他们对安全相关软件的验证提出了很高的要求。ISO26262-6规定，要求覆盖和结构覆盖必须通过适当的覆盖度指标来收集。这是对验证完整性的评估。对于具有最高安全等级(ASIL D)的软件，我们强烈建议在单元级别上加入MC/DC（修正条件/判定覆盖）。
有人可能会认为这样MC/DC会成为测试目标。实际上并不会。根据定义，测试目标应该证明被测软件的特性。单元的正确功能应该总在测试目标列表的顶部。MC/DC显示是否所有可能的决定和条件都已通过。然而，它本身不能证明系统是否正确运行。因此，覆盖率不适合作为测试目标。
事实上，覆盖率指标只应该视作测试的最终标准。测试完成的标准定义了什么时候被测系统被认为是经过充分测试的。测试目标和测试完成标准是在测试概念中的定义。然而在在每个迭代/发布中，都应该根据已实现的变更及其可能的影响来更新测试概念。
一个测试需求结构的成功方法
从定义基于需求的测试用例开始。将需求表示为用例和使用方法，例如考虑边界值或构建等价类。这将有助于验证软件的理想功能的完整性。无论如何，这是测试的一个可靠起点。通过测量代码覆盖率，您可以发现尚未测试的潜在漏洞，并编写相应的测试用例。
覆盖率的目标值必须总是100%。ISO 26262要求对偏差值进行解释。如果有测试不到的程序部分，例如调试或并行软件配置，我们建议在报告中解释减少的覆盖率，而不是提前为覆盖率设置较低的目标值。这样将会提高整体效率，因为这样在每次改变单元时，无需通过复杂的计算来检查和调整那些被减少的覆盖值。
如果你通过上述程序却没有达到100%的覆盖，可能是由于以下几个原因:
- 需求缺失或不完整
- 测试用例不够
- 测试用例识别了无效的、不可访问的或禁用的代码，或者非预期的功能
ISO 26262要求对每一个偏差进行合理解释，将相关的代码段可视化(见图1)可以快速地将预期的原因从问题中分离出来。
测试在很大程度上依赖于需求的质量以及所选择的软件架构和设计。为了尽可能降低测试工作量，最好提前了解软件架构和软件设计对测试过程的影响从而选择合适的架构和设计模式。因此，沟通是成功的关键——软件架构师和设计师的任务是观察整个软件产品的生命周期，并有机会通过重组和分离对对冲活动施加重大影响。
TPT与MC/DC
TPT希望帮助客户轻松快速地满足所需的指标。为了实现这一目标，我们将在TPT 18中包含了两个MC/DC特性：
- 测量C/ C++和Simulink的MC/DC覆盖率；
- 使用TPT自动生成测试用例:通过这种方式，您可以快速且轻松地将覆盖率提高到100%。
我们对算法进行了调整，用尽可能少的测试用例来做MC/DC测试。无需自己创建测试用例，只需要执行和维护最小数量的测试用例即可，也不需要购买额外的测量工具来确定覆盖率，会为您节省大量的时间和金钱。
敬请期待即将发布的TPT18。
欢迎联系我们申请免费试用：info@polelink.com。
作者：北汇信息-贪玩的皮卡球
喜欢本篇文章的话记得💬评论💖点赞⭐收藏 ➕更多技术文章直播课程，敬请持续关注北汇信息➕ ⬇️业务咨询请私信北汇信息或在官网留言⬇️
📩📩📩
版权归原作者 Polelink北汇信息 所有， 如有侵权，请联系我们删除。