测试用例设计

测试用例的意义

测试用例（Test Case），是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。

测试用例的意义在于：

1、 理清测试思路

有的系统本来就是一个大而复杂的项目，因此需要把项目功能细分，根据每一个功能通过编写用例的方式来整理测试系统的思路，避免遗漏掉要测试的功能点。

2、 明确测试任务

编写完用例后，可以明确自己需要执行的用例总数，以便预估测试工作量。并且可以很清楚的知道实际测试执行的进度，还很容易统计和跟踪我们的剩余工作量和回归工作量。

3、 规范测试行为

每个人对于功能和开发原理的理解都是不同的，同一条案例，每个人的理解程度和扩展都是不一样的。对于没有测试经验的新人来讲，更是需要详细明确的用例来规范，以减少遗漏。

4、避免出现漏测

QA的职责是保证质量，案例的覆盖面直接影响着产品的质量，也能够减少漏测。 

 

测试用例的要素

a)      测试环境

测试的系统是什么？硬件软件的要求是什么？

b)      测试数据

测试执行的输入值

c)      测试步骤

提供测试执行过程的步骤。一般控制在三个步骤完成。否则需要考虑用例是否需要拆分，因为每条用例对应的测试目的应该是具有唯一性的。

d)      预期结果

预期结果根据软件需求中的输出得出。那么实际测试过程中，实际测试结果如果与预期结果不符，则就测试不通过；反之则测试通过。

e)      用例标题

用例标题是对测试用例主旨的描述，既要言简意赅，也要能够清楚表达测试用例的目的

f)       用例编号

定义测试用例编号，用来标示每个用例的唯一性，进行测试用例的跟踪和维护。

g)      用例级别

一般分为四个等级，P0、P1、P2、P3。

级别	定义	占比
P1	基本功能核心业务流程	15%—20%
P2	非核心基本功能	30%—35%
P3	深入逻辑规则	35%—40%
P4	边界值、交互操作及中断等、异常测试内容	10%—15%

 

测试用例的来源

测试分析上：需求，隐性需求，系统架构，技术方案，业务流程

设计方法上：边界值，路径覆盖，等价类、正交法、错误推测法、场景法（流程图法）等

覆盖面上：UI，功能，性能，兼容，接口，数据库，安全，安装卸载，用户体验

设计分层上：数据层，接口层，UI层

 

如何做测试分析

a) 分析需求文档

需求文档是编写测试用例的第一依据，需求分析的目的一般是：

• 了解需求的背景；
• 分析需求的合理性；
• 明确需求的范围；
• 挖掘隐含需求；

怎么挖掘隐性需求，即在每一个需求点上进行拓展思考，比如在什么平台环境，基于什么条件，做怎样的操作，什么类型的数据，达成怎样的效果。

举个例子来说：要实现一个推送信息的功能，面向指定的用户推送内容。

平台：android和ios平台的处理机制，以及怎么获取设备的信息，判断应该是不一样的。

条件：语言、版本号、地区等都是条件，还可能有交叉。拿语言来说，系统语言和app的语言是两回事

操作：自动推送给用户，还是需要用户什么行为触发。是否和用户的配置项有关

数据：推送的内容，内容有效期、长短等等，是单纯的文字，还是富媒体内容等

效果：如何展示

b) 了解开发架构

• 确定开发的实现框架；
• 明确输入输出代码规则；
• 减少测试方向偏差；

关于如何针对开发原理，来完善案例设计可以参考这一篇文章，举的例子很典型：https://blog.csdn.net/alice_tl/article/details/79601697

c) 挖掘隐含需求

任何系统都有大的业务背景，比如测试金融 APP，要了解金融业务，基金、理财产品的业务流程和逻辑，要了解什么是结算、账户、和支付几个系统的差异以及作用。熟悉被测的业务和系统，才能更准确的把握好测试重点写好用例。

另外站在用户的角度分析：也就是客户的可能使用场景。甚至可以拉上几个同事来体验下产品，看看他们的操作行为和顺序是怎样的。

 

测试用例设计方法

结合一个需求来讲讲不同方法的应用：

a)      等价类划分

将输入值分为有效等价类和无效等价类。如果输入规定了输入区间，可划分出一个有效等价类，两个无效等价类；

b)      边界值

任何测试场景下都可以使用边界值法做设计，输入类型可以数值、字符等，要测试的边界包括上点、下点、离点。

c)      错误推测法

错误推测法，即猜测可能和常出现的错误，来提前制定用例，规避风险。错误推测法很受设计人员的测试经验影响，测试经验不同，设计出来的测试用例区别会很大。

d)      因果图法

罗列出所有的输入和输出，将输入和输出整理出因果图和依赖关系，根据每一个依赖做设计。因果图方法考虑输入的组合，特别适用于多个输入条件相关有关联又相互约束的情况。

e)      判定表驱动法

判定表适合于解决多个逻辑条件的组合，将各种逻辑的组合罗列出来，避免遗漏。列出每个对应条件所有可能情况下的取值，不需要考虑条件和顺序，再列出结果动作项，对每个条件进行结果判定。最后可以适当的进行规则简化和合并。

f)       正交法

    当输入条件很多时，因果图等设计方法设计出来的用例数往往多的惊人，用正交法可有效减少用例数。正交法的核心思想是从大量测试数据中选取有代表性的点来测试，从而减少测试用例数。

g)      场景法

画出程序流程图，再把流程图转换成控制流图，根据控制流图设计出场景，再根据场景设计测试用例。

结合这样一个需求：

需求	判断当前版本是否要强制升级到新版本，ios设备则不管本地装的是什么版本，均强制升级。如果是 Android 设备，则本地 V5.0以下的版本强制升级，V5.0及以上的版本不必强制升级。历史发过的版本从 V1.0、V1.1至 V6.0
等价类方法	对于 Android系统而言，本地版本可以划分为 三个等价类： V5.0以下（从 V1.0到 V4.9版本）、V5.0、V5.0以上（V5.1到 V6.0） 对于 iOS系统而言，本地版本只有一个等价类： V1.0到 V6.0
边界值方法	边界值：V5.0 向下无效类最小值：V5.1 向上无效类最大值V4.9
错误推测法	推测开发不够严谨， iOS 的逻辑实现的同 Android 一致，增加测试 iOS V4.9版本

场景法：

 

判定表：

平台 系统	强制升级	列1
	Android	ios
> V5.0	否	是
＝V5.0	否	是
< V5.0	是	是

 

经常有开发或者同行会问到你认为可以从那些方面提升案例设计的质量，这是我一般会给新人的答复。

 

测试设计工具

最常用到的工具是思维导图，即XMind，Excel，以及案例管理平台，结合一些图形类软件使用，比如processon，Visio。

Xmind：Xmind建立结构树，支持一键折叠和展开，能够快速的梳理清晰要测试的模块、测试点、以及结构关系。因此一般在分析需求和梳理测试思路的时候用，提高效率，也方便案例评审。

Excel：一般在写详细的案例时使用，主要体现的是案例的完整性，需要包含案例的所有要素，重点在测试环境、测试数据、测试步骤，和预期结果。

测试管理平台：一般和Excel有着相同的案例管理作用，只是一个好的平台，可以同时承载案例管理、层级结构、案例分配执行及报告输出的作用。

 

一般情况下，我们的案例设计及执行阶段为：

1、使用Xmind进行需求分析和测试思路梳理

2、组织测试思路评审

3、根据评审修改Xmind

4、根据Xmind转化Excel，进行案例细化

5、对转化后的Excel，操作步骤、预期结果、案例级别等进行评审

6、导入到案例管理平台

7、案例分配和执行、结果标记

8、结果统计报表输出

前5个阶段是大部分中小项目普遍在用到的，而大公司通常会根据自己公司的需求定制开发一些测试管理平台，能够达到阶段8。