软件测试测试用例的设计

Posted 2023-05-21 testing-xjq

一. 针对没有需求的案例来设计测试用例

针对没有需求的案例，我们可以从如下几个方面思考来设计测试用例

功能测试 + 界面测试 + 性能测试 + 安全测试 + 兼容性测试 + 易用性测试

案例一：针对一个水杯来设计测试用例

 案例二：针对一个登陆系统来设计测试用例

 

二. 针对有需求的案例来设计测试用例

大概设计思路如下： 

需求分析

概括出需求有哪些功能

设计测试点

设计测试用例

1. 穷举法

假如说给定的软件需求是：提示姓名长度为6~15位。

测试时数据我们设定为6、7、8 … 14、15，这样通过穷举法来设计测试用例，若测试用例通过，则认为功能符合需求要求。

假如说，给定的长度不是6~15位，而是6 ~ 500位，这时应该如何设计测试用例呢？这样测试用例通过穷举法肯定是不现实的。

2. 等价类

概念：针对需求把输入范围内的所有测试用例划分成若干个等价类，从其中一个等价类里取出一个用例，若该测试用例测试通过，则认为该测试用例所在的等价类通过。

等价类的核心是对测试数据进行分区分块，使用较少的测试用例达到符合的系统测试覆盖率。

等价类又划分成有效等价类和无效等价类：

有效等价类：针对需求来说是有效且有意义的数据构成的集合。

无效等价类：针对需求来说是无效且没有意义的数据构成的集合。

根据等价类划分测试用例的步骤：

确定有效等价类和无效等价类

编写测试用例

举例

需求：姓名可输入6~200位的字符，应该如何来设计测试用例呢？

第一步：确定有效等价类和无效等价类

有效等价类：6~200

无效等价类：小于6大于200

PS：其实在设计时还需要发散性的根据需求考虑更多情况，比如还可以针对字符的类型（数字、字符串、特殊字符）来设计有效等价类和无效等价类，这里只是简单的举例，只考虑长度。

第二步：编写测试用例

 

3. 边界值

边界值法通常是对等价类的补充。注意设计边界值测试用例时需要加上：边界值 + 次边界值

 

还是继续用等价类的例子，这次我们补充上边界值的测试用例：

4. 判定表法

判定表法的核心是要考虑输入输出之间的组合关系，根据这个这个关系画出判定表然后设计测试用例。

 

判定表设计测试用例的步骤：

 

确定输入条件和输出条件

找出输入条件和输出条件之间的关系

画判定表

根据判定表编写测试用例

举例

需求：订单已提交，且订单总金额大于300元或订单有红包，则认为该订单属于有优惠的订单，否则属于没有优惠的订单。

 

step1：确定输入条件和输出条件

 

输入条件：金额大于300元、有红包、订单已提交

输出条件：有优惠、无优惠

step2：找出输入条件和输出条件之间的关系

 

step3：画判定表

 

step4：根据判定表来编写测试用例

金额大于300元，没有红包，没有提交订单，结果为无优惠

金额不大于300元，有红包，没有提交订单，结果为无优惠

金额不大于300元，没有红包，提交了订单，结果为无优惠

金额大于300元，有红包，没有提交订单，结果为无优惠

金额大于300元，没有红包，提交了订单，结果为有优惠

金额不大于300元，有红包，提交了订单，结果为有优惠

金额大于300元，有红包，提交了订单，结果为有优惠

金额不大于300元，没有红包，没有提交订单，结果为无优惠

 

5. 场景设计法

5.1 简介

现在的软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。该方法可以比较生动地描绘出事件触发时的情景，有利于测试设计者设计测试用例，是测试用例更容易理解和执行。

 

典型的应用是是用业务流把各个孤立的功能点串起来，为测试人员建立整体业务感觉，从而避免陷入功能细节忽视业务流程要点的错误倾向。

 

5.2 基本设计步骤

根据说明，描述出程序的基本流以及各项备选流

根据基本流和各项备选流生成不同的场景

对每一个场景生成相应的测试用例

对生成的所有测试用例重新复审，去掉多余的测试用例

测试用例确定后，对每一个测试用例确定测试数据值

5.3 基本流和备选流

基本流：也叫有效流或正确流，模拟用户正确的业务操作流程。

备选流：也叫无效流或错误流，模拟用户错误的业务操作流程。

5.4 使用场景

主要用来测试软件的业务逻辑和业务流程。一般先采用等价类划分、边界值分析、错误推断法、因果图及判定表法等对单点功能进行验证，验证通过后再采用场景法进行业务流程的验证。

 

5.5 优缺点

优点：涉及到业务场景，使用场景法有利于测试设计者设计测试用例，使测试用例更容易理解和执行。

缺点：只验证业务流程，不验证单点功能。

5.6 实例

场景介绍

 

用户进入网上购物系统网站进行购物，选好物品后进行购买。

这时需要使用账号登录，登录成功后付款，交易成功后生成订单，完成此次购物活动。

第一步：分析需求，确定基本流和备选流事件

 

第二步：根据基本流和备选流来确定场景

 

第三步：设计用例

 

第四步：设计测试用例中所需的数据

 

6. 错误猜测法

错误猜测法是基于对被测试软件设计的理解、过往经验以及个人直觉，推测出软件可能存在的缺陷，从而去针对性地设计测试用例。

 

这个方法强调的是对被测试软件的需求理解以及设计实现的细节把握，还有个人的经验和直觉。

 

错误推测法和目前流行的“探索式测试方法”的基本思想一致，这类方法在敏捷开发模式下的投入产出比很高，被广泛应运于测试。

 

这个方法的缺点是难以系统化，并且过度依赖个人能力。

 

以注册为例，我们可以对这个场景直接进行错误猜测，从而设计测试用例：

 

校验中特殊字符空格的处理？

密码校验中的大小写？

姓名中的特殊字符？

密码发送是否明文？

 

 

 

 

 

 

 

 

优秀测试用例的设计策略

测试工作最为基础核心的内容就是设计测试用例，什么样的测试用例是好的测试用例？我们一般会认为数量越少，发现缺陷越多的用例就是最好的用例。

那么我们如何才能设计出好的测试用例呢？

一份好的用例是设计出来的，是测试人员思路和方法的集合，而非测试逻辑和需求的罗列。

测试用例设计的几个准则

1、用例设计=思路。

强调测试的场景，测试方法。

2、测试步骤化。

此处说的测试步骤，不是说每条测试用例都要写明测试步骤，而是指那些通过测试步骤的调整会出现缺陷的地方需要重点关注测试步骤，比如添加操作，单纯的添加功能是OK的，但是先删除一条数据，再添加相同的数据就失败了，这个就涉及到操作步骤了。

3、用例流程化。

此过程依托于完整的业务流程图，每个分支就是一条支流，通过业务端发起的请求，最终都会流向一条分支，而流程化就是将这些分支梳理为测试场景，通过覆盖测试场景来覆盖业务逻辑。

测试用例设计的步骤

1、明确原始需求。

原始需求是软件的使用者（客户）的需求，在需求文档基础+本质理解才能真正理清楚需求要实现什么样的目的，以此为出发点才能不偏离需求本质；

2、拆分原始需求。

在需求测试阶段，如果按照需求测试策略对需求梳理一遍之后，对于所有的需求点应该都已经很清楚了，将这部分的需求点罗列出来，就可以作为需求粗的测试点；

3、梳理业务逻辑。

现在比较多的前端业务都来源于接口所返回的数据，前端最多的时候也就是根据返回数据做一些相应的显示和计算，所以如果对页面设计测试用例，那么需要关注接口数据的完整性和正确性对页面的影响，而接口本身的测试则要归纳到接口测试用例设计环节。

?  接口没有返回数据时，页面如何处理；

?  接口返回的参数不完整，比如返回包有list结构，此作为前台展示列表数据的依据，但是list为空；

?  接口返回包中没有需求的参数名称

 

这个地方有一个原则，需要注意，即前后端分离和前后端测试集合。

?  前后端分离，有专门的接口测试人员来保证接口功能的正确性。此时作为前端测试人员，只需要保证接口返回数据正确时，页面显示正确；接口返回数据异常时，页面显示正确；调用接口的数据正确即可；

?  前后端半分离，接口也做测试，但是是使用自动化工具，保证基本的参数正确性与通畅性，而对于接口的逻辑需要前端配合测试。

此时作为前端测试人员，就需要了解接口的实现逻辑，如数据的处理逻辑，存储结构等。据此来设计前端测试用例，必要时也要绕开前段，直接调用接口模拟前段测试。

综上所述，对业务逻辑的理解程度，取决于业务的结构，在理解了业务逻辑后，补充对应需求点的业务逻辑测试点。

4、区分页面测试和业务逻辑类测试

页面层级的测试遵循以下的方法：

?  整体界面测试：就是去验证整体的界面是否和设计图一致；

?  界面元素测试

?  控件操作验证：如对控件能否操作、操作是否正常的验证；

业务逻辑（功能）等级的测试遵循以下方法：

?  任何情况下都必须使用边界分析法，出问题最多的就在边界值；

?  必要时用等价类划分方法补充一些测试用例；

?  用错误推测法再追加一些测试用例；

?  对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程度，如果没有达到要求的覆盖标准，应当再补充足够的测试用例

 

现在的软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的出发顺序和处理结果就形成事件流。