软件测试需求分析设计基本概念

2010-02-07  杨炯 

1.1. 测试规格 Test specifications

测试规格是产品测试规格和特性测试规格的通称,不管是产品测试规格还是特性测试规格,都需要基线化。一般而言,我们所说的测试规格都是指产品测试规格。

1.2. 产品测试规格 Product test specification

产品测试规格是对客户需求、产品包需求、设计需求、设计规格以及其他可能的需求进行综合测试分析,从测试角度(测试类型、功能交互等等)对以上需求分析并整合形成的测试需求集合,明确了测试应该测试什么。产品测试规格,经过了相关整理,相互之间没有重复,每条产品测试规格都有唯一的标识。

1.3. 测试特性 Test feature

逻辑上相关的产品测试规格集合,可以是功能性的产品测试规格集合,也可以是非功能性的产品测试规格集合。逻辑相关性,指的是按照一定的规则进行划分,这个规则是个广义的规则,区别于开发按照功能进行划分的特性。

测试特性需要在产品测试需求分析中进行设计和规划,建立产品的测试特性模型,这个模型要充分考虑产品总体结构、测试组织形态、测试人员技能以及产品Build划分计划。

测试特性和测试方案是一一对应的,测试方案设计的输入就是依据测试特性划分分配后的产品测试规格。

1.4. 分配后测试规格 Allocated test specification

分配后测试规格容易理解,就是经过测试规格分解分配后的产品测试规格,分配后测试规格集合就是测试特性。分配后测试规格是测试方案设计的SOW的一部分。

1.5. 特性测试需求 Feature test requirement

特性测试需求是分配后测试规格和测试方案设计的其他输入的通称。

1.6. 特性测试规格 Feature test specification

在测试特性这个层面,经过特性测试需求分析之后,影响该测试特性的相关业务规则、参数等等都已非常清晰,这些业务规则和参数的组合就是特性测试规格。一句话,特性测试规格清晰的描述了影响该测试特性的所有业务规则和相关的参数。

另外,特性测试规格要考虑测试效率因素,需要对产品测试规格进行组合,同时明确测试规则和参数,一般而言对于特性测试规格而言,操作步骤不同,类同于ACTION WORD

1.7. 测试用例 Test case title

这里提到的测试用例是指测试用例的标题,识别该测试用例的相关规则都不能再细分,是测试划分的最小单位。识别该测试用例的相关规则有变化或者顺序有变化,导致该测试用例的输入不同,会衍生为新的测试用例。

1.8. 测试类型 Test type

不同类型的测试会发现不同类型的Bugs。测试类型是从不同的角度来分析和测试产品,测试类型多用于设计系统测试。测试类型和系统测试阶段有关,比如:SDV阶段适合【功能测试】,SIT阶段适合【压力测试】。

1.9. 分解分配原则 Allocate principle

对于每个产品来说,都有一种划分各种测试特性的原则,这就是分解分配原则,用于测试规格的分解分配。

1.10. 测试技术 Test technique

一种具体的设计测试项的技术,比如:等价类划分,边界值,因果树、正交设计等等,用于特性测试设计。

1.11. 测试场景 Test scenario

测试场景的概念还没有完全统一,有多种说法。详细的定义需要和测试知识体系一起确定。

Ø 对于贯穿测试项的特定路径,称之为测试场景,比如缺少支付的订单到达,缺少送货地址的订单到达等等。

Ø 影响测试项的组网模型,这些测试项的组网模型相同,直接影响了测试环境搭建。

Ø 影响测试项的用户模型,不同的用户群有着不同的业务模式。

1.12. 操作概图 Operational profile

操作概图是对软件功能的风险分析的重要方法,通过风险分析,划分不同的用户群,分析用户功能频繁程度,以及有着特殊价值或者重要性(比如:安全性功能或者话单)。操作概图需要识别我们期望的客户和使用不同功能的频率。

另外,从操作概图中可以评估测试设计的质量,简单的说,依据操作频率,可以统计产品测试规格的频率和数量,如果频率高,而用例数量少,说明测试设计覆盖不到位,如果频率低,而用例数量多,说明测试设计过度,如果频率高,测试用例数量多,说明测试设计质量好。这只是一种简单的判断,如何使用操作概图是本项目的开发内容之一。

1.13. 测试需求跟踪 Test requirement trace

测试需求跟踪是测试分析设计的验证过程,区别于需求跟踪。由于测试规格的分解分配思路和开发设计规格的分解分配思路不同,最终的测试项很难和SRS建立跟踪关系,有必要按照测试的分解分配思路跟踪设计规格或者客户需求,这就是测试需求跟踪。

测试需求跟踪是在设计规格的基础上形成测试规格,按照产品测试规格-特性测试规格-测试项这条线进行跟踪。

1.14. 测试点 Test point

测试点从字面上理解就是需要测试的关键点,这些关键点也可以说是影响测试对象的各种业务原则,测试点应具有可控性,且相对独立,对于条件复杂的测试点就是有一定逻辑关系的独立测试点组合。测试点可以通过测试技术来划分子测试点,子测试点就是一个具体的业务规则,不能再分解。

1.15. 检查点 Check point

检查点不是预期结果,预期结果是每个测试项的最终预期输出,是对终端用户而言的,比如:MS呼叫MS,用户能够相互通话这就是预期结果。检查点是指测试项在执行中的过程输出,关注的是过程中的输出结果,而这些过程中的输出结果是产品内部为验证测试项执行的必要关键点,这是可测试性需求的一个方面。严格的说,对于每个测试项,每一个操作都有相应的检查点。

1.16. 测试用例 Test case

测试项的具体实现就是测试用例,一个完整的测试用例有几个部分组成:前置条件,测试步骤、测试数据、检查点,结束条件。测试用例可以有两种表现形式:自动化测试用例和非自动化测试用例,不同的测试用例在实现上也会不同。

1.17. 测试粒度 Test granularity

测试粒度是指一个测试焦点的精细度或粗糙度。一个高粒度的测试方案允许测试人员检查低级别的细节,一般是系统的内部;低粒度的测试方案为测试人员提供一般的系统行为信息。测试粒度可以被认为是沿着从结构(白盒)到性能(黑盒和实时)的谱排列行进

592°/5894 人阅读/3 条评论 发表评论

金鑫  2010-02-08

从产品需求评审结果到形成测试需求,是测试工作的关键。
总结的8错,收藏了


小窝  2010-02-08

从word直接copy过来的吧,字体和行距各具特色,呵呵。


杨炯  2010-02-08

小窝: 从word直接copy过来的吧,字体和行距各具特色,呵呵。
当然,这个是51testing的徐老师来我们公司培训时记录下来的.


登录 后发表评论