软件测试的时代 － 软件测试思想、软件测试技术新体验
 
　案例分析

 
 
 


　　测试时代工作室推出“案例分析”栏目，主要搜集过程改进、质量管理、测试等多方面的案例，之后邀请相应方面的专家来点评这些案例。主要采取以下的方式：
方式一：设立各行业软件测试解决方案案例分析，对于行业的测试项目进行做案例分析。
方式二：按照测试管理，测试技术，过程改进分类，对于测试组织中的管理案例和技术实施以及优化工作方式方法的案例做分析。
方式三：按照测试时代论坛的栏目分类方式，把相关的技术案例分类进行做分析。
方式四：按照不同类别的软件，如，应用类的，游戏类的，驱动类的，工具类的，防火墙类等等软件测试案例分析，主要分析测试技术的正确应用。
　　案例和案例专家分析的文章由测试时代论坛上的各版主来维护，过客可以以评论的形式发言。预计一个月到一个半月搞一期。

案例分析第六期（2005-08）

你在日常的工作中没有遇到问题吗？如果有，你也可以提交案例。【我要提交案例】
案例分析
   
本期案例
题目：覆盖率如何计算？
所属主题：软件质量度量
作者：Green
案例内容：
　　有谁知道如何知道测试用例对需求的覆盖率？
　　测试的覆盖率又是如何计算的？
相关分析
    
分析一：
　　作者：ggwemail
　　分析内容：
　　不知道你们用什么分析方法。一般如果用用例的话，用例都可能映射出测试用例，他们可能是多对多的关系。你也可以用需求跟踪矩阵来跟踪、检查测试用例的需求覆盖率。
　　但是只是需求覆盖是远远不够的，还要进行例如：语句、判定、条件、组合等等的覆盖。如果测试力量较弱就只做到语句、判定吧！
　　不过这些覆盖率一般是用自动测试工具自动统计的，如果用手工统计太繁琐，复杂的系统也是没法办到的。嵌入式系统要更复杂些。
分析二：
　　作者：小颖
　　分析内容：
　　我觉得计算测试覆盖率是考核测试人员的工作质量，达到高的覆盖率，软件质量也许就会提高吧，但是目前大多数公司也没有引入自动化测试工具，根本无法去计算路径、语句、判定、条件、组合等等的覆盖。目前我们只能从测试人员的测试记录中可以查看到需求功能的测试覆盖率，只能说目前保证了功能测试全面性。
分析三：
　　作者：越中女儿
　　分析内容：
　　我也觉得也是，如果是一个很庞大的项目，你根本就没有指望通过语句、判定、条件、组合等等的覆盖来进行。关于如何确定覆盖率，如何编写出有效合适的用例，这个问题我也一直在思考，但是，对于一个没有白盒测试的公司而言，是相当困难的。但是如果我们的QA连覆盖率都不知道，又谈何对于项目整体品质的监控呢？
分析四：
　　作者：戴金龙
　　分析内容：
　　测试覆盖率包括功能点覆盖率和结构覆盖率。功能点覆盖率大致用于表示软件已经实现的功能与软件需要实现的功能之间的比例关系。一般地，软件需要实现的功能由软件需求规格说明给出，由设计规格说明细化。在实际操作中，计算某软件功能点覆盖率的最佳时机宜选在功能测试阶段，具体结果由功能测试人员汇总后给出。也有一些企业选择在单元测试阶段做功能点覆盖。笔者认为，这样效果并不很好。如果功能点粒度很细，确有必要提前进行，笔者建议在集成测试阶段进行。因为集成阶段涉及模块组装以及分系统集成。
　　结构覆盖率一般包括语句覆盖率和路径覆盖率。所谓语句覆盖率，是指程序代码经编译后形成的指令在测试过程中实际被执行的比例数。注意：这里已经排除了“死语句”，即不要把冗余语句和永远无法到达的语句放在语句覆盖率的计算中。一般意义上，语句覆盖率百分之百是指编译后形成的指令在实际测试过程中均被执行过，而没有强调必须在一次测试中全部覆盖所有指令。因此，语句覆盖率具有较好的可操作性，测试成本也不高。一般，计算语句覆盖率可以选择在单元测试阶段进行。
　　与语句覆盖率相对应的是路径覆盖率。路径覆盖率百分之百是指测试过程必须遍历程序所有可能的执行路径。显然，在面向对象时代，百分之百的路径覆盖率是难以实现的。运用简单的排列组合知识，不难可以发现，语句覆盖率用的是加法法则，而路径覆盖率用的是乘法法则，要遍历程序所有可能的执行路径大多数情况下是不现实的。然而，路径覆盖率的诱惑太大了，路径覆盖率远比语句覆盖率更有意义，因此，针对于路径覆盖，不少人作了更进一步的算法优化，有些使乘法运算的某些乘法因子变小，有些使乘法运算的次数变少，取得了不少成果。但整体来看，目前突破并不大，并没有彻底改变路径覆盖率乘法运算的根本属性。
　　结构覆盖率除了上面讲的语句覆盖率和路径覆盖率，还有一些杂七杂八的概念，比如分支覆盖率、循环覆盖率、条件覆盖率、线程覆盖率、模块覆盖率等等等等。笔者觉得太复杂，不实用。如果是写学术文章，可能有点意思；但如果要用来指导工程实践，基本帮不上忙。
　　最后，从企业应用的角度，笔者推荐在单元测试阶段做好语句覆盖，在集成与系统测试阶段做好功能点覆盖，一般商用软件这样做就够了。至于路径覆盖，在没有充足的理由和必要的准备的情况下尽量不要去提，如果条件不具备，提了也难以保证测试效果。实践告诉我们，针对整个软件的路径覆盖率往往是一句口号；如果资源真的很充足，而且确有必要，那么，建议在模块内部踏踏实实做好路径覆盖测试就够了。模块与模块间的路径测试往往是很不容易的。
测试时代工作室分析
    

　　测试用例对需求的覆盖率是指所有的测试用例对全部需求的覆盖率。而这种大而全的概念无法体现出软件测试的特点，即测试类型。只有按测试类型统计覆盖率，才能体现出“覆盖率”的价值。
测试覆盖：指测试用例对同类型需求的覆盖率。
　　总的需求覆盖计算方法为：各类型测试的覆盖率的加权平均值；其中，各类型的加权值由测试负责人或质控负责人给出。
　　做法思路：将大目标划分成多个小目标，对小目标的实现最终汇总为对大目标的实现。这种思路适合绝大多数的目标、计划等等。
关注案例  
焦点5：在软件项目规划和开发阶段，如何考虑与测试配合？
焦点7：如何进行滚动测试？
焦点8：嵌入式软件的测试设计应该如何做？
焦点9：怎么搭建测试环境。
案例分析
你在日常的工作中没有遇到问题吗？如果有，你也可以提交案例。【我要提交案例】

 
测试时代首页 | 测试时代论坛 | 测试交流会 | Blog社区 | 测试时代工作室 | 测试时代刊物 | 软件测试资料