测试用例的设计

需求管理

第一章 需求工程过程

 

可行性分析

 

 

需求导出和分析过程

 

 

 

需求检查：

1.有效性检查

2.一致性检查

3.完备性检查

4.显示性检查

5.可检验性检查

 

 

需求管理：

 

 

1.获得对需求的理解

2.获得需求承诺

3.管理需求变更

4.在需求变更后维护对需求的双向可追溯性

 

 

需求评审

参与人员：

 

 

需求评审的过程

 

 

 

 

（会议记录重点是记录核心的讨论点以及讨论结果）

 

 

（跟踪每一个人是否完成安排的工作）

第二章 测试需求分析

测试需求分析

了解软件质量特性，测试工程师与记性测试需求分析

定义测试范围，明确测试项及测试子项，便于后续设计测试用例

 

 

（考虑软件的功能模块，接受什么样的输入，能怎么样处理，最终能给出什么输出）

分析过程：

 

 

三步法：

原始测试需求分析>测试项分析>测试子项分析

原始测试需求分析：

测试需求来源：SRS（software requirements specification）、开发需求、协议/标准/规范、用户需求、继承性需求、测试经验库、同行竞争分析等。

 

 

 

 

第三章测试项、测试子项概念

测试项分析（定义测试什么和验证什么）

测试子项分析（对测试项的细分）

Counter实例

第四章 需求跟踪矩阵

需求跟踪矩阵（RTM：requirements traceability matrix）：

是一种主要管理需求变更和验证需求是否得到了实现的有效工具，可以跟踪每个需求的状态。

RTM作用：

1.在需求变更、设计变更、代码变更、测试用例变更时，需求跟踪矩阵是目前经过实践检验的进行变更搏击范围影响分析的最有效的工具，如果不借助RTM，则发生上述变更时，往往会遗漏某些连锁变化。

2.RMT也是验证需求是否得到了实现的有效工具，借助RTM，可以跟踪每个需求的状态：是否设计了，是否实现了，是否测试了。

需求跟踪矩阵表

 

 

缺陷管理

第一章 缺陷的基本概念

Debug：调试

Bug和Defect

Bug：电脑系统或者程序中存在的任何一种破坏正常运转能力或者缺陷，都可以叫做“bug”；有事也被繁殖因软件产品内部的缺陷引起的产品最终运行时和预期属性的偏离。

Defect：既指金泰存在于软件工作产品（文档、代码）中的错误，也指软件运行时由于

这些错误被激发引起的和软件产品预期属性的偏离现象。

了解：失误（mistake)：导致软件包括故障的人的行为

缺陷（defect)：软件的异常情况

故障（fault）：引起一个功能组件不能完成所要求的功能的一种意外情况

失效（failure）：功能组件执行其规定功能的能力丧失

缺陷的定义：

1.缺陷也叫做BUG

2.计算机软件或程序中存在的某种破坏正常运行能力的问题、错误，或者隐藏的功能缺陷。

3.从产品内部看，缺陷是软件产品开发或维护过程中存在的错误、毛病等各种问题。

4.从产品外部看，缺陷是系统所需要实现的某种功能的失效或违背。

缺陷来源

缺陷来源于软件生命周期各个阶段。

产生原因

1.铲平说明书不全，不完整和不准确，修改频繁，沟通不畅和理解不同；

2.软件设计过程考虑不周到，片面，多变，理解和沟通不足；

3.文档不足，压时间，赶进度，设计和编码错误都会引入缺陷；

4.测试和试试过程中安装环境配置错误等。

缺陷的评价标准

 

 

第二章 缺陷的属性

缺陷报告的相关属性：

 

 

缺陷类型

1.遗漏：missing

2.错误：error

3.额外改进：extra

4.改进：enhancement

严重程度的划分

指因缺陷引起的故障对软件产品的影响程度。

 

 

 

 

优先级的划分

表示处理和修改软件缺陷的先后顺序的指标：

 

 

 

缺陷跟踪的交付物

缺陷报告单：也叫做缺陷跟踪单。测试执行过程中，发现软件失效

缺陷管理工具中的BUG Report

 

 

（Description需要测试人员自己完成，写明缺陷的重现情况）

第三章 缺陷的生命周期

缺陷的生命周期就是指缺陷从开始提出到最后完全解决，并通过验证和确认的过程。在这个过程中缺陷报告的状态不断发生着变化，记录着缺陷被处理的过程。

BUG的流程（掌握）：

 

 

状态说明：

1.新建：测试人员提交新问题标识的状态

2.打开：已经确认为是BUG的状态

3.已修复：为开发人员修改问题后所表示的状态，等待测试验证

4.重新打开：测试人员对修改问题进行验证后没有通过所标志的状态或者已经修改正确的问题又重新出现错误，由测试人员改变。

5.已关闭：为测试人员对修改问题进行验证后通过所标志的状态。

6.拒绝：开发人员认为不是bug、描述不清、重复、不能重复、不采纳所提意见建议、或虽然是个错误单还没到非改不可的地步故可忽略不计、或者测试人员提错，从而拒绝的问题。由bug分配人或者开发人员来设置。

7.重复：表示该bug已经被其它测试人员找出来了，或者开发认为原因是相同的（但从测试来看，认为出现的地方有所不同、表现有所不同等）

8.延期：由于时间、进度、重要程度或者技术/需求等方面的原因，认为不能解决、须延期解决、或者本版不做留待到后续版本解决的bug.

缺陷沟通

 

 

一个简单的BUG跟踪流程（掌握）

 

 

缺陷报告的状态

 

 

缺陷状态迁移矩阵

 

 

软件测试缺陷管理流程

 

 

缺陷管理中的常见问题

1.提交的缺陷开发人员不认可怎么办（提交的BUG都是有依据的）

2.如何处理不能重现的缺陷（也需要记录，发现BUG先截图）

3.如何处理好与开发人员及其他相关人员的关系（注意语气）

4.缺陷太多怎么办

5.找不到缺陷怎么办（测试的点是否覆盖全面，测试用例是否完善）

6.缺陷得不到及时修复怎么办（及时上报）

7.如何处理缺陷级别定义之争（需要有理由）

8.如何处理缺陷跟踪中的扯皮现象

第四章 缺陷报告的书写

缺陷报告单写作准则（5C）

1.准确（correct）

2.清晰（clear）

3.简洁（concise）

4.完整（complete）

5.一致（consistent）

缺陷报告的写作要点

1.再现：一般是尽量三次再现故障，如果问题是间接的，那要报告问题发生频率。

2.初步定位：可能影响再现的变量，例如配置变化、工作流、数据库，这些都可能改变错误的特征。

3.推广：确认系统其它部分是否可能出现这种错误，以及使用不同的数据时是否存在着这种问题等等，特别是那些可能存在更加严重特征的部分。

4.压缩：精简任何不必要的信息，特别是荣誉的测试步骤。

5.去除歧义：使用清晰的语言，尤其是避免使用那些有多个不同或相反含义的词汇。

6.中立：公正的表达自己的意思，对错误及其特征的试试进行陈述，避免夸张、幽默或讽刺。

7.评审：至少有一个同行，最好的是一个有经验的测试工程师或测试经理，在递交错误报告之前自己先阅读一遍。

缺陷报告单接基本内容

 

 

缺陷描述举例

 

 

第五章 常用的管理工具

缺陷管理的目的

1.保证信息的一致性

2.保证缺陷的到有效的跟踪，缩短沟通时间，解决问题更高效

3.利于缺陷分析、产品氟利昂，使项目情况可视化加强

常用的缺陷管理工具

1.QC

2.禅道

第六章 缺陷分析

识别BUG

1.BUG是由于软件开发者的疏忽和失误造成的。

2.BUG是软件生命周期内发现和违背发现的所有问题总和。

全面质量管理和全程软件测试：

 

管理BUG

 

 

分析BUG

 

 

重点：软件的处理流程，编写BUG报告单（有哪些基础信息）

测试用例设计

第一章 测试用例的概念

随机测试存在的问题：

 

 

测试用例的概念

测试用例是测试工作的指导，是软件测试必须遵守的准则，更是软件测试质量稳定的根本保障。

测试用例是指为实施测试而向被测试系统提供的输入数据，操作或者各种环境设置以及期望结果的一个特定集合。

第二章 属性与特征

测试用例的属性：

1.用例ID

2.用例名称

3.测试目的

4.测试级别

5.参考信息

6.测试环境

7.前提条件

8.测试步骤

9.预期结果

10.编写人员

测试结论（通过、不通过、阻塞）、实际结果、bug信息(bug id)、测试数据

测试用例的特征

1.最有可能抓住错误的

2.不是重复的、多余的

3.既不是太简单

4.也不是太复杂

第三章 设计原则

用例设计的原则

1.测试用例对需求覆盖的完整性

2.测试用例的有效性

3.测试用例的可理解性

4.测试用例的清晰性

5.测试用例的可维护性

需求覆盖的完整性

 

 

 

 

测试用例的有效性

测试用例应该包含清晰的输入数据以及预期输出，如果环境或者业务发生变更后，测试数据必须进行更新维护，用例给予数据驱动。

测试用例的可理解性

测试用例步骤必须描述清晰，不能出现模棱两可，以及重复的话语。

测试用例应该按照一定的顺序进行编写，这样执行的时候效率比较高。

测试用例的清晰性

测试用例的验证点必须明确清晰重点突出。

测试用例的可维护性

测试用例因为业务需求发生变更的时候，需要及时更新

测试用例的可维护性

测试用例因为业务欲求发生变更的时候，需要试试更新维护测试用例，做到测试用例的实时性和有效性。

测试用例需要细化和不断地完善，是个循序渐进的过程。

第四章 设计方法

测试用例设计方法

 

 

等价类方法

等价类定义：

把所有可能的输入数据，即程序的输入域划分成若干部分（子集）。然后从每一个子集中选取少数具有代表性的数据作为测试用例。

划分等价类原则：

1.在输入条件规定了取值范围或值得个数的情况下，则可以确定一个有效等价类和两个无效等价类

2.在输入条件规定了输入值的集合或者规定了“必须如何“的条件的情况下，可确立一个有效等价类和一个无效等价类。

3.在输入条件是一个布尔值的情况下，可确定一个有效等价类和一个无效等价类。

4.在规定了输入输入数据的一组值（假定n格），并且程序要对每一个输入值分别处理的情况下，可确定n个有次奥等价类和一个无效等价类。

5.在规定了输入数据必须驯兽的规则的情况下，可确定一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）

6.在却只已划分的等价类中个元素在程序处理中的范式不同的情况下，则应再将该等价类进一步的划分为更小的等价类。

等价类方法

等价类划分

等价类划分作为一种最为典型的黑盒测试方法，它完全不考虑程序的内部结构，而只是根据程序的要求和说明进行测试用例的设计。

 

 

 

 

等价类方法-举例

 

 

 

 

等价类方法小结

 

 

运用等价类方法的步骤是：

1.划分等价类（依据是需求）

2.建立等价类表（有效等价类和无效等价类）

3.设计测试用例

边界值分析

边界值分析也是一种黑盒测试方法，是一种和等价类相关的技术，它具有很强的发心程序粗糙无的能力。

定义：

边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。

 

 

 

原则：

 

 

边界值分析

找点原则：

 

 

判定表法

判定表驱动法：是分析和表达多逻辑条件下执行不同造作的情况的工具。

判定表组成：

 

 

第一步：确定规则的个数。假如有n个条件，每个条件有两个取值（0，1），故有2的n次方种规则。

 

 

使用判定表法条件：

 

 

 

 

 

因果图法

定义：是哟中利用图解法分析输入的各种组合情况，从而设计测试用例的方法，它适合于检查程序输入条件的各种组合情况。

因果关系：

4中符号分贝表示规格说明中4中因果关系

 

 

约束

输入状态互相之间还可能存在某些依赖关系，称为约束。

 

 

因果图法步骤：

 

 

因果图法-案例：

 

 

 

 

根据因果图建立判定表：

 

 

在判定表中，阴影部分表示因违反约束条件的不可能出现的情况，删去。第16列与第32列因什么动作也没做，也删去。最后可根据身下的16列作为确定测试用例的依据。

正交实验法

又称组合实验法，利用因果图来设计测试用例时，作为输入条件的原因与输出结果之间的因果关系

 

 

用正交表设计测试用例的步骤：

1.有哪些因素（变量：输入条件）

2。每一个因素有哪些水平（变量的取值）

以下不用自己思考：

 

 

 

 

举例：

 

 

 

 

利用正交表：

 

 

再补充一条：

 

 

（正交法的特点：每一列、每一个取值出现次数都是相同的，被验证的频率是相同的）

优点：节省测试工作时间；可控制生成的测试用例数量；测试用例有一定的覆盖率。

状态迁移法

它是一种依据产品规格分析的黑盒测试技术。

测试强度：

覆盖所有状态、条用所有的函数、覆盖所有的路径

状态迁移方法步骤：

1.根据需求提取全部方法

2.绘制状态迁移图

3.根据状态前意图推到测试路径

4.选取测试数据，构造测试用例

举例：

 

 

绘制状态迁移图：

 

 

绘制状态迁移树，获取测试路径：

 

 

场景法

基本流及时按照正确的事件流来实现的流程。

备选流就是出现故障或缺陷

方法简介

 

 

场景设计

场景1：基本流

2.基本流备选流1

3.基本流备选流1备选流2

4.基本流备选流3

5.基本流备选流3备选流备选流3备选流

设计步骤：

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

2.根据基本流和

实例：

 

 

 

 

软件测试又两种基本方法：通过测试和失败测试。

 

 

测试方法的选择

 

 

{1.基于业务操作流程分析，首先采用场景法设计相关用例（状态迁移、因果图、判定表）

2.根据输入过程中每一个输入项，采用边界值、等价类设计用例

3.涉及到查询条件找功能，条件之间组合关系的检查，采用正交表进行用例设计}

 

转载于:https://www.cnblogs.com/luchun/p/8645354.html