如何达到一定的覆盖度是个非常重要的问题，它是我们软件测试分析和测试设计工作的基础和出发点。在白盒测试中，我们可以用逻辑覆盖（语句覆盖、分支覆盖、条件覆盖、路径覆盖）等来指导我们的分析和设计，并用来评价我们测试工作的充分性，但在黑盒测试中，我们所追求的是需求要达到一定的覆盖度，那么如何衡量需求被覆盖的程度呢？又如何保证去达到一定的需求覆盖呢？请结合您的思考和实践，畅所欲言，希望各种观点在碰撞中产生火花。
主要要做好测试需求分析测试需求分析分两步：
1，测试需求的获取需求的来源：
显式需求
（1）原始需求说明书
（2）产品规格书
（3）软件需求文档
（4）有无继承性文档
（5）经验库
（6）通用的协议规范隐式需求：用户的主观感受，市场的主流观点，专业人士的评价分析
2，需求的分析 ，产生测试需求文档将不同的需求来源划分成一个个需求点，针对每一点进行测试分析
（1）界定测试范围
（2）利用各种测试设计的方法产生测试点。
目前测试对需求的覆盖程度已经作为判断测试质量的一个标准，但不同的测试类型和需求类型如何判断测试的覆盖程度？
1、一般来说，非功能性测试的覆盖程度比较好判断，如性能和压力测试，可根据需求中明确的性能指标进行测试分析和设计，另外也可通过分析系统在生产中实际使用情况，来分析一些隐含的需求，如系统是否需要连续运行、系统故障后恢复的级别、并发访问的程度等。
2、功能性测试的覆盖程度是比较难判断的，用例数不能完全说明对需求的覆盖，因为用例数和测试点的力度划分相关，测试点划分的越细，用例数量越大，但不能说明覆盖程度高。
我们的做法一般是先根据用户需求确定测试优先级，重点需求测试点划分的比较详细，测试用例要覆盖所有的情况，如正常值、边界值、特殊值等；一般性需求测试用例覆盖所有的正常等价类；测试用例设计上划分为单功能测试用例和测试场景设计，单功能测试覆盖的需求中的功能点，测试场景覆盖需求中的业务逻辑；另外测试设计全面与否，很大程度取决于需求的质量，取决用户是否真正明白自己想让系统做什么。
看了上面高手的分析，真是受益匪浅啊~！~我也同意首先要透彻理解需求文档，把不明白的地方与开发人员、设计人员沟通。
理解完需求后，我们就得开始写测试需求了，在测试需求了，我们将对软件或项目进行庖丁解牛的手法，将其功能模块细分出来，然后将模块中的功能点分解出来，我们得保证最后的功能点为最小分子，不能再进行下一步分解拉。（当然我们可以借助一些测试需求编写工具拉）测试需求细分出来后，剩下的就是编写测试用例了。每个最小分子需求对应写一个测试用例，用例中要将能想到的方法步骤全部写出来，大家开会讨论，不漏掉。执行“不抛弃任何一个方法、不放弃任何一个idea”。至于相关联的功能模块之间，我们也得考虑设计测试用例。（这些只针对黑盒测试的功能测试）
文本转载自51Testing软件测试网，查看全文：
阅读(524) | 评论(0) | 转发(0) |
