怎样保证测试用例的覆盖率？切面设计

“不就是，按需求或概要设计，得到软件功能划分图，然后据此按每个功能，采用等价类划分、临界值、因果图等方法，来设计用例就好了么。”

但实际上，抛开测试数据的设计另说，仅测试项来讲，同一个项目，经验丰富的测试人员，在写用例或测试时总会有更多的测试考虑点，从而发现更多的问题；缺乏经验的人员，则还会遗漏了大量测试覆盖点，导致其测试出来的程序总是比较脆弱。

其原因，还是测试用例的撰写水平不到位。如果说系统用例做到100％覆盖，那是很难的。按设计中的功能划分，每个功能都写到了，这还远远不够。

因为还有大量的内部处理、转换、业务逻辑、相互影响的关系等，都是需求或设计中所不会点明的。而这些就需要靠测试人员对项目本身的了解和测试经验，来支撑完成了。

我们归纳了做设计用例的方法主要有三个方面，分别为：测试用例的切面设计、详细用例的设计、测试数据的设计，今天就测试用例的切面设计和大家详细讨论。

所谓测试切面设计

其实就是测试用例大项的划分

测试用例划分的经典方法是瀑布模型

也就是从上到下，逐渐细分，大模块包括小模块，小模块包括更小的模块

但仅仅如此是不够的

我们还要从更多的角度切入系统

从不同的角度把系统切分成一块一块的

来进行测试

从而确保测试大项的完整性

测试用例的切面设计主要有以下几点

1、功能点切面

2、特定切面

3、隐含切面

　1）、后台功能

　2）、完整业务流程的测试

　3）、某种特定情况下的系统运行

　4）、其它相关系统

　5）、除功能测试外的其它测试类型

功能点切面

这是最常见的切面，通常我们认为页面上的一个按钮就是一个功能点。

然后我们可以根据功能的复杂程度，按每个功能；或一个功能点分多页；或多个功能点合成一页来进行用例的撰写。

特定切面

所谓的特定切面，就是忽略掉表面上的功能点，而关注测试对象的某一个面。

比如：我们的内部管理系统提供了销售录入导入、注册录入导入等功能，从菜单划分上对应了七八个功能点。但这些功能处理后台有个共同的处理项就是授权记录的生成，这时我们就可以把“授权记录生成”单独拿出来做一个测试项，而在其它测试项中涉及这一部分的用例就不必再一一撰写。

此外象一些界面共通的操作用例单独写成一页，也是一种特定切面。所以如果说将用例按功能点划分是一种纵向划分法，那么特定切面就是从横向的角度分析所得到的切面。

在普通功能点划分上再根据实际情况设计特定切面，可以使我们的用例阅读性、理解性、操作性更强。

隐含切面

这类用例是最容易被忽略的。它往往不是明显的某个功能项，可能是功能项后台的隐含处理，也可能是多个功能项之间的关联处理，甚至可能是在某种特定情形下的处理。这都需要测试人员通过对软件的学习了解，来进行挖掘。

后台功能

常见的如一些定时自动启动的服务；以及某种特定情况下自动执行的操作等。它们在界面上往往是不体现的，但许多在需求设计中还是会提到，也有一些比较细小的功能可能会被忽略，就需要测试人员根据对项目的了解程度来进行挖掘。所以说一个熟悉项目的和一个不熟悉的测试人员，写出来的用例就完全是两个层次的。

完整业务流程的测试

我们都知道测试用例的设计是从点、线、面三个层次去考虑的。完整的一个功能项是线，其中的某个按钮是点，多个相关功能结合成完整业务流就是面。从实际来看这类用例往往被我们忽略。

事实上目前公司的软件本来都是业务型应用软件，将各种功能从业务流中切割出来单独写用例，肯定也会有涉及到整体流程的情况。若不加以区分，将细节与全局搅在一起，不仅思路混乱，也容易考虑不周。因此在系统测试阶段，建议用例设计要有分有合，针对具体功能的就只围着这个功能转：而在业务流程测试项中，再完全从整体的业务流角度出发去考虑用例，这样不仅不容易产生疏漏，用例阅读与执行也更清楚。

某种特定情况下的系统运行

这类用例的设计往往与系统实际业务情况密不可分。比如财务软件，通常需要在月尾一天、月头一天、年尾一天、年头一天，对所有相关功能中的日期处理进行测试；又比如WIN 2000环境开发测试的系统，要测试在98、XP、2003等操作系统下是否能运行自如；再有如存在大量动态图片视频等的 页，在普通 速下的展现速度等等。总之就是要尽可能从实际应用的角度出发考虑，来进行测试补充。

其它相关系统

即指在当前项目中直接使用的其它成果，包括公司自有的系统模块、组件、函数；以及购买或免费得到的一些功能组件。对这些内容需要预先与开发组长等讨论清楚，是否需要测试。若时间紧张或其它原因决定不测的，应在测试计划中说明。若需要测试的，则具体可根据实际情况来设计，可以是通过系统某个功能的测试来涉及，此时就不需要单独划分测试项；若相对比较独立的，也可以通过单独的测试项来对其专门进行测试。

除功能测试外的其它测试类型

包括可靠性、安全性、恢复性、配置安装测试等等，这些测试类型都是一个单独的测试项。

所谓好的开始是成功的一半，保证测试项划分的完整、合理、正确，会直接影响到本次测试的成效。通常建议该阶段工作要花1-2天的时间来考虑，并要在测试过程中随着对软件的深入了解，不断进行调整补充。可千万不要认为把分析设计中的功能模型图搬搬过来就可以了。

下期，我们将继续对怎样保证测试用例的覆盖率进行探讨，欢迎朋友们留言讨论，及分享。

另有2019最新测试用例方案等资料，可以关注我们乐搏软件学院（lebo1768）,获取更多学习资料