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

软件测试需求分析设计基本概念 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建立跟踪关系，有必要按照测试的分解分配思路跟踪设计规格或者客户需求，这就是测试需求跟踪。 测试需求跟踪是