测试用例设计进阶(下)

场景分析法设计测试用例 — 场景分析相关概念

场景

应用软件一般都是用事件触发来控制流程的,事件触发时的情景便形成了场景。

事件流

同一事件不同的触发顺序和处理结果就形成事件流,事件流分为基本流和备选流。

基本流

程序从开始执行直到成功结束所经过的最短路径。

备选流

一个备选流可能从基本流开始,在某个特定条件下执行,然后重新加入基本流中;也可能起源于另一个备选流,执行后加入基本流或者终止用例。

一个典型的场景分析图

场景分析法设计测试用例 — 使用场景分析设计测试用例

场景分析法

通过分析事件流设计测试用例的方法。

场景分析法的使用场景

场景分析一般在分析业务流程或流程化处理功能时使用。

场景分析法的优点

场景分析法可以比较生动地描绘出事件触发时的情景,有利于测试设计者设计测试用例,同时使测试用例更容易理解和执行。

场景分析法设计测试用例的步骤:

1、分析软件规格说明描述,整理出基本流和备选流。

2、根据基本流和备选流组合关系生成场景。

3、分析所有场景,合并测试内容重复的场景。

4、根据场景逐一设计测试用例。

例、在用信用卡网上支付时,输入信用卡卡号、查询密码和实时短信验证码,信息全部正确且账户金额充足的情况下可以完成付款。如果相关信息不正确则给出对应提示信息;多条信息不正确时按输入顺序提示;短信验证码一分钟内有效,出错三次则退出本次支付。

1)整理基本流和备选流

基本流:正常支付

备选流1:账户不存在;

备选流2:查询密码不正确;

备选流3:短信验证码不正确;

备选流4:短信验证码失效;

备选流5:账户余额不足;

备选流6:退出支付

2)根据事件流生成场景

场景1:基本流

场景2:基本流-备选流1

场景3:基本流-备选流2

场景4:基本流-备选流3

场景5:基本流-备选流4

场景6:基本流-备选流5-备选流6

场景7:基本流-备选流1-备选流2-备选流3-备选流6

场景8:基本流-备选流3-备选流4-备选流5-备选流6

3)合并重复场景

场景1:基本流

场景2:基本流-备选流5-备选流6

场景3:基本流-备选流1-备选流2-备选流3-备选流6

场景4:基本流-备选流3-备选流4-备选流5-备选流6

4)根据最终的场景逐一设计测试用例

测试用例总结 — 测试用例设计策略

1、任何情况下都要使用边界值分析法设计测试用例,经验表明这种测试用例发现程序错误的能力最强。

2、使用等价类划分法补充必要的测试用例。

3、如果程序规格说明中多个条件决定多个动作,每个条件的取值只有两种,并且条件和动作之间的逻辑关系明确,那么使用判定表法设计测试用例。

4、针对程序规格说明中含有多个条件的组合,输入与输出关系比较复杂的情况,使用因果图法设计测试用例。

5、针对程序规格说明中的复杂业务流程、操作流程等,使用场景分析法设计测试用例。

6、对照程序实现逻辑,检查已设计出的测试用例的逻辑覆盖程度,如果没有达到覆盖要求,应当分析具体情况,补充足够的测试用例。

7、分析程序规格说明,使用错误推测法补充一部分测试用例。

8、测试过程中针对具体实现,将已有测试用例未覆盖的部分,选用合适的测试用例设计方法再补充一些必要的测试用例。

测试用例总结 — 测试用例编写策略

1、功能测试用例覆盖的功能点需要尽量小,方便测试执行时提取用例。

2、对于常用控件的测试可以整理出针对控件的通用测试点,在具体的功能测试用例中就可以不再编写通用测试点已经覆盖的内容了。

3、对于系统相关流程的测试用例,可以提取出来,编写有针对性的流程测试用例。

4、对于业务关联性比较强的功能,可以提取出来,针对存在的业务场景编写功能测试用例。

测试用例总结 — 测试用例的维护管理

测试用例伴随着软件产品的整个生命周期,随着软件功能的日渐完善,测试用例也在不断改进、扩充和完善。在这个过程中,如何维护和管理测试用例将是直接影响软件测试质量的重要工作内容。

维护测试用例的原因

软件需求变更

需求分析错误

测试需求误解或遗漏

测试用例遗漏

测试用例的维护

日常维护主要有测试用例修改、测试用例删除和测试用例增加。

用例修改

测试设计人员在设计测试用例时考虑不够全面,对测试需求的理解偏差或误解,功能实现和设计存在出入等都是造成测试用例修改的直接原因。

用例删除

测试用例的删除主要是因为软件相关功能发生较大变化或已去掉,对应测试用例已不适用时,就需要删除对应用例;冗余的测试用例也需要删除。

用例增加

测试人员在测试过程中发现有测试用例未覆盖的功能,用例评审时发现有未覆盖的测试需求,需求分析错误或收到新的需求时都需要新增对应功能的测试用例。

用例维护注意事项

用例的维护都需要保留维护记录。

同一软件不同现场功能出入较大的话,需要根据现场维护不同的测试用例。

同一软件多版本共存的话,需要在测试用例中标注不同版本的用例差异。

测试用例的管理

测试用例根据公司代码和文档管理体制的不同采用对应的管理方式。如果公司资料文档使用同一个管理软件的话,将测试用例直接纳入管理软件测试相关目录即可;如果测试是作为一个完全独立的部门,相关资料文档有自己的管理软件的话,则将测试用例纳入自己软件的相关目录。

管理测试用例的作用

保护测试人员工作成果。

测试人员变动不会影响测试工作的正常进行。

用例管理注意事项

用例设计人员只有上传和更新用例文档的权限,不具有删除用例文档的权限,删除用例文档需经过相关人员核准。

用例文档更新的人员、日期等历史信息需要能够查询。

用例执行人员不具有编辑用例文档的权限。

所有的用例评审结论文档都需要纳入文档管理系统。

×

谢谢你请我吃辣条

扫码支持
扫码打赏,你说多少就多少

打开支付宝扫一扫,即可进行扫码打赏哦

文章目录
  1. 1. 场景分析法设计测试用例 — 场景分析相关概念
    1. 1.1. 场景
    2. 1.2. 事件流
    3. 1.3. 基本流
    4. 1.4. 备选流
    5. 1.5. 一个典型的场景分析图
  2. 2. 场景分析法设计测试用例 — 使用场景分析设计测试用例
    1. 2.1. 场景分析法
    2. 2.2. 场景分析法的使用场景
    3. 2.3. 场景分析法的优点
    4. 2.4. 场景分析法设计测试用例的步骤:
      1. 2.4.1. 1、分析软件规格说明描述,整理出基本流和备选流。
      2. 2.4.2. 2、根据基本流和备选流组合关系生成场景。
      3. 2.4.3. 3、分析所有场景,合并测试内容重复的场景。
      4. 2.4.4. 4、根据场景逐一设计测试用例。
    5. 2.5. 1)整理基本流和备选流
      1. 2.5.1. 基本流:正常支付
      2. 2.5.2. 备选流1:账户不存在;
      3. 2.5.3. 备选流2:查询密码不正确;
      4. 2.5.4. 备选流3:短信验证码不正确;
      5. 2.5.5. 备选流4:短信验证码失效;
      6. 2.5.6. 备选流5:账户余额不足;
      7. 2.5.7. 备选流6:退出支付
    6. 2.6. 2)根据事件流生成场景
      1. 2.6.1. 场景1:基本流
      2. 2.6.2. 场景2:基本流-备选流1
      3. 2.6.3. 场景3:基本流-备选流2
      4. 2.6.4. 场景4:基本流-备选流3
      5. 2.6.5. 场景5:基本流-备选流4
      6. 2.6.6. 场景6:基本流-备选流5-备选流6
      7. 2.6.7. 场景7:基本流-备选流1-备选流2-备选流3-备选流6
      8. 2.6.8. 场景8:基本流-备选流3-备选流4-备选流5-备选流6
    7. 2.7. 3)合并重复场景
      1. 2.7.1. 场景1:基本流
      2. 2.7.2. 场景2:基本流-备选流5-备选流6
      3. 2.7.3. 场景3:基本流-备选流1-备选流2-备选流3-备选流6
      4. 2.7.4. 场景4:基本流-备选流3-备选流4-备选流5-备选流6
    8. 2.8. 4)根据最终的场景逐一设计测试用例
  3. 3. 测试用例总结 — 测试用例设计策略
    1. 3.1. 1、任何情况下都要使用边界值分析法设计测试用例,经验表明这种测试用例发现程序错误的能力最强。
    2. 3.2. 2、使用等价类划分法补充必要的测试用例。
    3. 3.3. 3、如果程序规格说明中多个条件决定多个动作,每个条件的取值只有两种,并且条件和动作之间的逻辑关系明确,那么使用判定表法设计测试用例。
    4. 3.4. 4、针对程序规格说明中含有多个条件的组合,输入与输出关系比较复杂的情况,使用因果图法设计测试用例。
    5. 3.5. 5、针对程序规格说明中的复杂业务流程、操作流程等,使用场景分析法设计测试用例。
    6. 3.6. 6、对照程序实现逻辑,检查已设计出的测试用例的逻辑覆盖程度,如果没有达到覆盖要求,应当分析具体情况,补充足够的测试用例。
    7. 3.7. 7、分析程序规格说明,使用错误推测法补充一部分测试用例。
    8. 3.8. 8、测试过程中针对具体实现,将已有测试用例未覆盖的部分,选用合适的测试用例设计方法再补充一些必要的测试用例。
  4. 4. 测试用例总结 — 测试用例编写策略
    1. 4.1. 1、功能测试用例覆盖的功能点需要尽量小,方便测试执行时提取用例。
    2. 4.2. 2、对于常用控件的测试可以整理出针对控件的通用测试点,在具体的功能测试用例中就可以不再编写通用测试点已经覆盖的内容了。
    3. 4.3. 3、对于系统相关流程的测试用例,可以提取出来,编写有针对性的流程测试用例。
    4. 4.4. 4、对于业务关联性比较强的功能,可以提取出来,针对存在的业务场景编写功能测试用例。
  5. 5. 测试用例总结 — 测试用例的维护管理
    1. 5.1. 维护测试用例的原因
      1. 5.1.1. 软件需求变更
      2. 5.1.2. 需求分析错误
      3. 5.1.3. 测试需求误解或遗漏
      4. 5.1.4. 测试用例遗漏
    2. 5.2. 测试用例的维护
    3. 5.3. 用例修改
    4. 5.4. 用例删除
    5. 5.5. 用例增加
    6. 5.6. 用例维护注意事项
      1. 5.6.1. 用例的维护都需要保留维护记录。
      2. 5.6.2. 同一软件不同现场功能出入较大的话,需要根据现场维护不同的测试用例。
      3. 5.6.3. 同一软件多版本共存的话,需要在测试用例中标注不同版本的用例差异。
    7. 5.7. 测试用例的管理
    8. 5.8. 管理测试用例的作用
      1. 5.8.1. 保护测试人员工作成果。
      2. 5.8.2. 测试人员变动不会影响测试工作的正常进行。
    9. 5.9. 用例管理注意事项
      1. 5.9.1. 用例设计人员只有上传和更新用例文档的权限,不具有删除用例文档的权限,删除用例文档需经过相关人员核准。
      2. 5.9.2. 用例文档更新的人员、日期等历史信息需要能够查询。
      3. 5.9.3. 用例执行人员不具有编辑用例文档的权限。
      4. 5.9.4. 所有的用例评审结论文档都需要纳入文档管理系统。
,