标签：需求 覆盖 覆盖率 边界值 等价 用例 测试用例 测试
软件测试覆盖率
覆盖率=(至少被执行一次的item数)/item的总数
语句覆盖率=(至少被执行一次的语句数量)/(可执行的语句总数)
判定覆盖率=(判定结果被评价的次数)/(判定结果总数)
条件覆盖率=(条件操作数值至少被评价一次的数量)/(条件操作数值的总数)
判定条件覆盖率=(条件操作数值或判定结果至少被评价一次的数量)/(条件操作数值总数+判定结果总数)
路径覆盖率=(至少被执行一次的路径数)/(总的路径数)
需求覆盖率=(被验证到的需求数量)/(总的需求数量)
继承上下文判定覆盖率=(累加每个上下文内执行到的判定分支数)/(上下文数*上下文内的判定分支总数)
基于状态的上下文入口覆盖率=(累加每个状态内执行到的方法数)/(状态数*类内方法总数)
函数覆盖率=(至少被执行一次的函数数量)/(系统中函数的总数)
指令块覆盖率=(至少被执行的一次指令块的数量)/(系统中指令块总数)
DDP覆盖率=(至少被执行的一次的判定路径数量)/( 系统中判定路径总数)
分支条件组合覆盖率=(被评测到的分支条件组合数)/(分支条件组合数)
PPP覆盖率=(至少被执行的一次的PPP数量)/( 系统中PPP总数)
测试的基本流程：
获取测试需求–编写测试计划–制定测试方案–设计和开发测试用例–执行测试--提交缺陷–测试分析和评审–测试总结–准备下一版本的测试
一、获取测试需求是测试工作的重点，也是第一步。通过需求的分析，了解和掌握测试的方向和内容，例如：
（1）分析出系统的模块和组织结构
（2）分析出软件的基本功能和运行流程。（业务分析）包括可能会有哪些人或者哪些角色要用。
（3）识别出软件的重要功能和次要功能
获取测试需求的过程中，测试人员就要有相应的分析成果。一般用xmind这样的思维导图工具进行分析，或者使用需求跟踪矩阵来完成测试需求的获取和分析。
二、设定测试中需求的正、反向和优先级。
当有了测试需求之后，就开始对每一个需求点进行测试用例的设计。也就是，每一个需求点，都要被测试。
因此测试的过程中，衡量需求的覆盖程度，就非常的重要。使用：
需求的覆盖程度=被测试用例覆盖的需求数/需求点总数
进行计算和说明。
如果需求覆盖度＜100%，那一定说明了测试的覆盖度不够。
三、测试中，最能体现测试人员工作量的指标就是缺陷的数量和用例的数量。
（1）设计的测试用例总量 TC
（2）执行的测试用例数量 EC
（3）未执行的测试用例总量 WC
（4）执行通过的测试用例总量 SC
（5）执行失败的测试用例总量 FC
（6）提交的缺陷的总量 BC(Bug Counts)
以上5个数据，他们要符合如下的数量关系。
- TC≥EC
- TC=EC+WC
- EC=SC+FC
- BC≥FC 提交的bug数量，多于执行未通过的用例数。一条用例的预期结果数量是固定（甚至是唯一的）。说明了测试过程中发现的缺陷，除一部分是用例执行失败带来的，还有一部分应该是测试人员自身的经验和直觉（其他知识）带来的。
- 通过 SC/EC 可以表现出系统的质量是否合格
- 通过 EC/TC 可以表现出系统的需求是否得到满足
三、测试覆盖率对于黑盒测试
测试覆盖率对于黑盒测试来说主要标识的两个方面，一个是需求覆盖，一个是用例覆盖。
1、需求覆盖从需求覆盖角度上讲定义很简单，就表示在测试过程中，有哪些需求方法，有哪些函数被测试到了，他被测试到的概率（频率）到底有多大，这些函数在系统所有函数中的占比是多少。并且还要制定一个标准，有多大的概率，多大的通过率，才能够叫做这一版本的测试完成，这是需求覆盖的内容。
2.需求覆盖本质上在计算的时候，是根据需求文档为依据的。需求文档里会有一些需求点的拆解，根据这些点来决定来判断测试需求覆盖率。也就是说哪些需求是被验证到的，哪些需求没有被被验证到。我一共有100个需求，但是其中可能有一个需求的点我没有测试到，当然这其中的原因有很多，有可能是开发没有提交，有可能是这方面就完全忽视了，用例也没有涉及到，所造成的需求遗漏。
用下面公式计算需求覆盖率是多少。
计算公式：需求覆盖=（被验证到的需求数量）/（总的需求总数）
3.一般来说一个程序在第一次发布的时候，发布到线上给其他客户使用时候的需求覆盖率一定要达到百分之百。如果是后续迭代的时候，就要去考量每一次代码修改所影响到的范围。通过分析这个影响范围来决定到底应该覆盖哪些需求，这个时候的覆盖率就不一定是百分之百。但是仍然需要有一定的覆盖率，即便其他的模块可能跟这次修改没有任何影响，那我也需要从测试角度去考虑。在有条件的情况下，去完成更多需求方面的基本覆盖。
四.用例覆盖
用例覆盖就很明显，它主要体现的就是在每轮测试验证的过程中，通过用例数在总用例数中的比重计算得出。
计算公式：用例覆盖=（验证通过的用例数量）/（总的用例总数）
验证过的用例是包含两方面，除了手工测试的用例，还包含自动化测试的用例。测试覆盖率不是说用例覆盖越高越好，还是要经过判断之后，在得出结论。但是用例覆盖是一个非常关键的度量因素，尽量的保证覆盖要全面。一般情况下，每一次上线要求自动化加手动测试的用例覆盖，要高到80%以上，才能够教这一轮测试的完成。
————————————————
版权声明：本文为CSDN博主「程序员二黑~」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/weixin_53519100/article/details/111996350
标签：需求,覆盖,覆盖率,边界值,等价,用例,测试用例,测试 来源： https://www.cnblogs.com/cmd-11/p/16542223.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。