|
例：下图看到的截图为以穿线测试为理论，产品化的工具ThreadingTest中的截图：
图中覆盖率ＳＣ０解释说明： 【 段 】 在二个连续的分支点之间的计算机程序语句序列被叫作段。 【可视段】 在一个控制层之内最大可能的非-条件语句序列被称为可视段。在二节点之间可视段的长度可能是零(没有可执行语句)。 SC0 基本段测试覆盖度量也称为块测试覆盖。如果程序的所有可见段(程序块)至少被执行一次，则该段程序的SC0覆盖率达到了100%。 SC0= 被执行的块个数/该段程序包含的块个数(即可见段个数)
在图中，我们清晰地看到该函数的覆盖率ＳＣ０，是如何被计算出，且显示出相关的代码，通过这种方式展示，可以使广大没有接触过代码的测试人员，通过黑盒的测是方式，找出覆盖率中代码的没有覆盖到的部分，进行测试用例的补充，从而提升测试用例的制作，以及提高测试质量。 在ThreadingTest中，还有关于其它覆盖率的划分说明，如TRUE（真条件的百分比）、BOTH（条件真假的覆盖率百分比）、Branch(分支覆盖率)、MC/DC等。 请关注官方技术网站www.threadingtest.com中的覆盖率分析，有详细地解释说明和计算。 测试覆盖率作用 测试覆盖率是测试结束标准中的一部分 测试覆盖率低的模块 和 重要模块的测试覆盖率。这些数据可以帮助我们快速定位需要更多测试的模块，可以帮助我们了解重要模块的测试情况，以此来衡量我们测试用例的质量乃至测试的质量。 在螺旋式开发模式中，如果我们没有控制好我们上一个迭代中的测试覆盖率，当一个版本 一个版本累加下来后，你就很难确定我们哪些模块在开发过程中没有给予足够的测试。 通过覆盖率，制定下阶段有效的测试计划 下图为测试覆盖率的报告 
通过上图的覆盖率展示，我们可以进行下一步测试的整体方向计划。 检查未使用的功能 检查前10个的最低覆盖率 测试用例的加强 穿线测试覆盖率与验证阶段 验证阶段可以分为单元验证（UT）阶段、集成验证（IT）阶段和系统验证（ST）阶段。 单元验证阶段，关心的是模块功能和模块质量，此时出口条件为代码覆盖率。一般业内常用的出口条件是：行覆盖率达到100％，分支覆盖率达到100％，条件覆盖率达到95％，对没有覆盖率的需给出合理的说明。 集成验证阶段，关心的系统的功能，以及模块与模块之间的接口，此时出口条件为功能覆盖率。一般业内常用的出口条件是：功能覆盖率达到90％，对没有覆盖率的需给出合理的说明。 • 功能覆盖率高、代码覆盖率低： 验证计划不充分，需要增加功能覆盖点。 • 代码覆盖率高、功能覆盖率低： 设计没有实现指定的功能。 穿线应对测试覆盖率，达到最佳实践 传统的白盒测试 路径覆盖率 > 条件覆盖 > 判定覆盖 > 语句覆盖 测试覆盖率100%是一个理想的情况，是很难达到的 测试覆盖率100%不能说明我们做了完全的测试 测试覆盖率达到多少要考虑到软件整体的覆盖率情况，以及项目成本，包括人力，时间等等。 因以上因素，所以传统的白盒测试都不建议公司特意的去满足覆盖率测试指标，为了测试而测试。 穿线测试对于传统的白盒测试结果进行了测试数据统一管理，实现各阶段累计，缩短反复测试的时间，从而保证了测试100%覆盖率高质量化。 从原有的测试来看，正常测试中单元测试阶段、集成测试阶段以及系统测试阶段的测试数据是相互分开的，但是在实际过程中，单元测试的充分程度程度，对后期的集成测试、系统测试等都起到了关联作用，在这部分中穿线测试使用了累计覆盖率的技术，把整个测试的各个阶段的测试结果进行沿用和累计，这样使得整个测试迭代起到了量化关联的作用，可以随时对各阶段的测试进行分析和改善。 相比于传统的单元级的白盒测试，穿线测试还提出了分布测试方法，对于中大型软件或网站来说，单个测试人员是不能够完成整个测试任务的，为了更好的相互配合，ThreadingTest采用了分布式测试设计，在测试过程中，测试人员可以在不同地点，同时对某个程序或网站的不同模块进行测试，测试结果在不相互干扰的情况下汇总到中央服务器，这样使得每天每个人的测试数据结果有了统一的管理，从而对整个测试进度进行了有效的量化管理。
穿线测试的出现对测试界的改革 商用测试工具产品ThreadingTest把穿线理念进行了实际的产品化，通过工具的方式，让黑盒测试人员也能进行代码级别的白盒测试，并对整个测试各阶段的流程进行了量化的管理，通过黑盒测试来实现白盒结果的展示，完成了测试界中最有效的70%黑盒+30%白盒相结合的测试方法。 穿线测试打破了传统白盒测试操作难度高，过于追求覆盖率等方式，通过黑盒与白盒的结合，使各阶段的测试人员，都能正确按照自己的需求进行测试，从而避免了盲目性、反复性、遗漏性等问题。
| 
/1 
关于我们
发表于 2014-10-18 10:21:41
置顶服务
换色服务
发表于 2017-1-18 17:02:55
