个人测试架构体系

个人测试架构体系

软件测试全流程

健全的测试流程有助于规范测试各阶段活动的进行。本文主要描述测试全流程中各阶段活动的出入口条件、工作重点。

测试需求分析

责任主体：所有测试人员，测试经理负责组织

入口条件：客户需求说明书已完成签字。

工作重点：参与版本的所有测试人员熟悉所有交付需求，可以通过测试需求反串讲确认测试人员对需求的理解程度，可以安排产品经理或者架构师答疑。

出口条件：没有明确的文档承载，可以是疑问的澄清列表、重点需求或者易忽略需求描述记录的文档。

测试策略和测试计划

责任主体：测试经理，其他人参与评审、熟悉策略

入口条件：客户需求说明书已完成签字、产品经理完成需求传递、项目经理完成开工会。

工作重点：根据项目组通用的测试策略和测试计划模板完成测试策略，编写责任人通常是测试经理。完成后发起测试策略评审，参与人为项目中核心角色，包括项目经理、开发leader、产品经理、所有测试人员等。评审完成后对评审问题确认、修改，基线后归档到指定目录下。

出口条件：基线的测试策略文档

用户验收测试用例设计

责任主体：负责设计客户验收测试用例测试人员

入口条件：客户需求说明书已完成签字

工作重点：根据验收手册设计规范和签字的用户需求设计测试用例，设计原则基本是最小覆盖原则。用例模板参考项目组要求。完成后需评审、修改、基线。

测试用例基本概念

测试用例是为特定的目的而设计的一组测试输入、操作步骤和预期结果。每个测试用例都是用户实际可操作的步骤，通过测试用例的执行去

验证交付给客户的软件的功能是满足的用户的要求。测试用例不局限于功能测试用例，同时包括性能测试用例、安全测试用例及可靠性、可服务性等测试用例。

测试用例组成元素

1、用例序号。唯一标识用例。

2、用例标题。该测试用例的验证的主要概括，也就是描述该测试验证系统的功能点。

3、预置条件。条件描述清晰、无二义性，同时要考虑运行状态。预置条件包括修改标志位、预置和清除数据、修改配置文件等

4、操作步骤。步骤描述清晰、完整、精炼。步骤主要包括各种输入动作、控件按钮操作等。

5、预期结果。完整性（列出所有检查点）、正确性（检查点可检查）、需要包含过程打印日志的验证。

6、用例优先级。标志用例执行的优先级，Level0/Level1/Level2。考虑版本进度、质量目标、成本等因素影响，优先级高的用例优先执行。

7、测试类型。通常类型包括功能、兼容性、性能、安全、可靠性、可服务性等。

8、是否自动化。标识用例是自动执行还是手工测试

9、设计人员。

高质量测试用例要素

1、完整性，确保用例集覆盖所有功能点无遗漏。

2、有效性，尽量减少冗余用例，提供用例命中率。

3、准确性，能够正确反映系统的行为和状态。

黑盒测试用例设计方法

1、等价类。不仅要考虑输入等价类，也要考虑输出等价类进行覆盖。

2、边界值。考虑边界5点（上点、离点、内点）

3、因果图。考虑元素间的依赖、约束关系的用例设计。

4、判定表

5、错误推测

6、功能图

7、场景图

测试用例设计综合策略

前面我们已经分析讨论过了等价类、边界值、因果图、判定表、错误猜测等测试用例设计方法，但是我们知道，每一种方法都可以提供一组具体的有用的测试用例，但是都不能提供一个完整的、覆盖全面的测试用例集。因此，我们需要组合这些已知的测试用例设计方法、发挥各项测试设计方法的优点，设计出用例数少且覆盖全面的测试用例集。一组合理的策略如下：

用例设计测试策略

下述组合测试用例设计测试策略并不能保证可以发现程序所有的bug，但实践证明一个合理的折中方案。具体的方法如下：

（1）如果规格说明中包含输入条件组合的情况，应该首先使用因果图分析方法。

（2）在任何情况下都应该使用边界值分析方法。一定要记住，需要同时对输入和输出的边界进行分析。边界值分析可以产生一系列补充的条件。这些补充条件通常可以整合到因果图分析中。

（3）应为输入和输出确定有效和无效等价类，在必要情况下对上面确认的测试用例进行补充。

（4）使用错误猜测技术增加更多的测试用例。

（5）针对上述测试用例集检查程序的逻辑结构。应使用判定覆盖、条件覆盖、判定/条件覆盖或多重条件覆盖准则（最后的一个最为完整）。如果覆盖准则未能被前四个步骤中确定的测试用例所满足，并且满足准则也并非不可能（由于程序的性质限制，某些条件的组合也许是不可能实现的），那么可以增加足够数量的测试用例，以使覆盖准则得到满足。

业务特性测试策略

用例设计的结果是业务能力和测试能力、团队能力结合的综合体现。上述主要针对测试用例设计组合的测试策略的方法，这里，也谈谈个人对业务特性测试设计的测试策略：

（1）针对单特性考虑测试用例设计，单特性内可以考虑采用分而治之策略划分特性。不同的产品开发团队的组成方式可能不同。我经历过的有按照产品模块划分的、也有按照特性划分的。不管是以哪种形式划分，在分析规格时，先拆分业务特性（按业务模块或子特性）理解进行用例设计。业务颗粒度不大情况下会分析的更透彻，也就可以更有针对性的进行用例设计。

（2）考虑新特性（新增或修改）与产品其他特性的关联性，补充测试用例设计。这里最重要的一点是测试设计人员必须非常熟悉业务。同时，最好有产品特性矩阵。否则，很难完整的分析出特性间的影响关系。

（3）组织用例评审。邀请SE、TSE、MDE、TM等核心成员评审，利用团队的力量保证用例覆盖全面性。

（4）根据代码覆盖率执行结果重新设计测试用例去覆盖未覆盖到的测试逻辑。某些异常场景确实无法构造，也必须安排开发MDE进行代码走读确保逻辑无问题。这一条通常有要求执行代码覆盖率操作的产品才会实施。

测试用例执行规范

测试执行在测试工作中占了很大比重，有效的测试执行可以将测试用例发挥最大的价值。因此，测试用例规范执行有助于更好的发现代码中存在的缺陷。根据个人测试工作经验，好的测试执行应该包含如下内容：

1、测试执行中评估测试执行时间不足，需及时上报风险。满足质量优先，进度其次原则。

2、测试用例按优先级顺序执行，通常是基本、详细和异常顺序执行。

3、未执行用例、标志为删除或者无效的用例，需注明原因。

4、执行过程中有疑问的测试用例（场景、操作步骤、检查点等）需找测试设计人员澄清。

5、测试执行需对用例描述的检查点逐一检查，避免遗漏。

6、重视不易重现的缺陷场景，可能是一个bug。

7、执行过程中发现有前期设计遗漏用例需补充到用例文档并执行验证。

8、建议测试人员交叉执行重复测试用例，用例执行对相同测试人员有免疫性。避免可能的缺陷一直遗漏到现网。

9、如有需要，建议保留测试结果，结果可视。也便于不同版本间的测试结果对比。

10、已确认问题需及时按照问题单提单要求（规范和缺陷定级）提单。

11、跟踪问题单修复情况并回归验证问题单。

12、每轮次测试结束，find一下是否有core文件产生。

13、测试结束，将最终测试用例文档上传到归档目录，实现用例重用。

启发式测试策略模型(HTSM)

什么是HTSM

启发式测试策略模型（Heuristic Test Strategy Model，简称HTSM）是测试专家James Bach提出的一组帮助测试设计的指南（Guide line）。HTSM由一组指导性词语组成，它们构成一个

层次结构，让测试人员从高层抽象到底层细节对产品和测试进行思考。

为什么需要HTSM

HTSM中指导性词汇是测试的指南，其作用不是教导如何具体地测试，而是启发测试人员的思维，发掘测试对象和测试策略，重点在于"启发式"。HTSM对于测试设计的意义：

（1）测试设计以风险驱动。测试人员分析质量标准、项目环境、产品元素中的风险，设计有针对性的测试策略。

（2）在测试设计时，质量标准启发测试先知（Oracles），项目环境启发测试过程（Procedures），产品元素启发测试覆盖（Coverage），观察到的质量启发测试报告（Reporting）。

（3）对于测试，HTSM强调测试策略的多样性（Diversification），平衡代价和收益（Cost vs. Value），利用启发式方法（Heuristics）充分发挥测试人员的技能（Skill）。

HTSM的内容

上图是HTSM的概要描述，测试人员利用质量标准（Quality

Criteria）、项目环境（Project Environment）、产品元素（Product Element），指导测试技术（Test
Techniques）的选择与应

用，并产生观察到的质量（Perceived Quality）。

HTSM是层次结构，其顶层元素（质量标准、项目环境、产品元素、测试技术）可以分解为次层元素，而次层元素可进一步分解为第三层元素。本文只概要介绍次层元素，更多的细节请参考James Bach的文档。

测试技术：生成测试的策略。有效地选择和实施测试技术，需要综合分析项目环境、产品元素和质量标准。

功能测试(FunctionTes