|
浅谈测试方案设计
众所周知，测试方案设计是测试流程中的第一个设计环节。在项目测试过程中，测试方案制定的好坏，会直接影响到项目的的质量。测试方案是从测试目的、测试计划、测试范围、测试策略、风险分析、测试内容等方面对版本内的交付内容进行细化分析，从而能够提前识别风险，制定合理的测试策略与交付计划，最大程度上保障整体的交付质量，达到测试目的。测试方案设计的关键在于对测试对象的分析过程，以及基于此分析过程得到的合适的测试方法与测试点，从而能够更好的指导测试人员进行用例的设计与输出。
以下从测试方案包含的几个方面来讲述整体的方案该如何设计。在进行方案设计前需要明确一个概念：测试方案不等于测试计划，也不等于测试用例。
(一) 项目背景/背景简述
-
项目概要
主要描述该交付版本的具体情况，其中包含：系统名称、发布版本、质量级别、测试工时、测试投入开始/结束时间、测试负责人、测试参与人员 -
项目背景
主要描述此次测试方案设计涉及的需求及项目的应用背景
(二) 测试策略
一般来说，测试策略描述了软件开发过程中进行测试方法，用来告诉测试过程中所有可能的参与者，测试活动应该如何进行。其中主要会包括测试目标，测试新功能的方法，不同阶段的测试策略、执行过程中的策略、测试重难点分析、测试项目的时间和资源，以及基于需要达到的目的和现有的资源可能产生的风险分析及规避策略以及测试环境与内容等等。制定测试策略时我们可以采用经典的“四步策略制定法”，即
Step1：明确测试范围与目标
Step2：进行基于目的与范围的风险分析
Step3：确定测试策略
Step4：进行测试分层及对分层的具体分析 -
测试目标
明确测试目标是整个方案设计中最为关键的一个步骤，测试目标就是让产品在发布的时候能够满足事先约定的质量目标；因此，我们需要：
a. 明确此次测试的范围（要测哪些功能）
b. 明确范围内各个内容的质量等级（中级？演示版？高级）
c. 分解每个测试对象的具体目标（每个功能要满足什么要求）
d. 从质量特性的八大方面明确测试内容需要满足的其他测试需求（性能、安全、易用性等） -
测试方法分析
基于对测试内容的分析，我们需要对测试过程中涉及的测试方法进行分析，明确测试过程中针对不同特性的测试思路及方法
a. 明确此次需求涉及的特性
b. 针对特性与目标进行方法的确定
（功能–手工，接口–自动化，性能–加压/并发压测等）
c. 明确方法的具体执行策略
手工测试：设计高覆盖率测试用例，手工执行
加压测试：设计加压脚本，在数据库中加压含业务逻辑的数据
接口测试：编写jmeter脚本 -
测试风险分析
在明确了测试的目的、范围、方法之后，我们需要从项目的整体角度进行风险分析，提前识别风险并调整策略并且依据风险明确测试的强度和投入，风险分析主要包括风险识别与风险评估以及风险应对三部分。
3.1风险识别
Step1：首先分析测试设计需要关注哪些内容（资源、范围、时间）
例如：
需要对某个重要的特性进行深入的测试，需要能够通过场景法来对开发人员的设计流程进行全面的覆盖，不遗漏基本的流程。
需要能够进行压力、稳定性和性能方面的测试
Step2：分析上述内容都能够保质保量顺利地进行，需要哪些条件
例如：
开发能够提供相关的设计材料（如相关的概要设计文档），并且能够保证材料的内容是正确的，需求是经过评审的，测试人员是对业务背景熟知的
测试人员能够理解并掌握压力、稳定性和性能方面的测试方法，有能力结合测试方法和产品实现来进行测试设计
Step3：逐一分析这些条件是否能够满足，无法满足即为风险
例如：
开发可能会缺失重要的设计文档，或者一些设计文档更新不及时，需求是未经过评审的，测试人员是对业务背景不熟知的，导致测试有遗漏风险
测试人员对压力、稳定性和性能方面的测试方法掌握不足，可能会出现测试设计遗漏，也可能出现人员缺口
除此之外，我们需要从需求、设计、流程、变更、人员等方面对项目进行整体的风险分析
3.2风险评估
风险评估就是对风险进行优先级的划分，由于测试工作开展受时间、人员等资源的限制，所以我们需要基于风险发生的频率，明确风险的优先级以及整体交付目标，确定主要风险并想出应对方法
3.3风险应对
常见的风险应对办法： -
测试策略制定
基于目的、范围以及可能出现的风险，我们就能够确定测试策略了，策略分为总体策略、阶段测试策略、执行策略
4.1制定总体测试策略
确定产品质量目标，进行项目整体的风险识别，从产品层面来确定测试重点和测试难点、测试深度和测试广度，是测试策略的总纲，进行总体策略分析时我们需要做到以下几点：
使用功能分析对特性进行分类
例如：全新功能、老功能变更、老功能优化、老功能回归等
基于目标与风险明确测试的深度与广度
深度：使用的测试方法
广度：测试范围
基于质量等级与需求的优先级明确测试的优先级
质量等级越高，优先级越高
质量等级相同时，全新功能优先级高于老功能
改动变更大的老功能优先级高于回归、优化的老功能
需求优先级越高，则优先级越高
基于优先级，确定测试投入策略
明确测试总体框架
策略：总体、阶段、执行
动作：包含哪些阶段，每个阶段要怎么干
保证：怎么保证每个阶段的质量
（测试设计评审、抽测、每日跟踪执行过程、缺陷检查）
4.2制定阶段测试策略
** 原则：阶段测试策略的制定需要能够指导具体阶段的测试执行**
4.2.1测试设计策略
测试需求分析：显性需求、隐性需求、继承需求
测试验证点分析：从用户、业务、需求三个角度分析正向、反向、异常测试点
测试用例设计：场景法、判定表、边界值、状态迁移、错误推测等
4.2.2研发阶段策略
需要结合具体的研发模式，明确各测试阶段测试策略
例如：GitFlow研发模式
4.2.3集成/系统测试策略
主要包含以下三方面：
入口准测：何时开始？（用例评审完毕、资源到位、环境就位）
用例执行：怎么选取，怎么执行？（功能/系统交互分析，优先级）
出口准则：怎么算结束？（用例执行完毕、缺陷收敛、达到目标）
4.3制定执行测试策略
执行测试策略是实际测试执行中，最为重要的阶段，直接影响着测试交付的质量，项目开始进入测试执行阶段时，进入测试执行策略中。执行策略是基于总体策略而展开的，有以下几个方面：
4.3.1确定测试轮次
常规版本需要经过3轮测试：初测、第二轮测试（含发散测试）、稳定阶段测试
初测：在Dev环境中，对新功能进行测试，执行全量用例，提交问题并回归问题
二轮测试：在Dev环境中，对重要需求项与缺陷集中模块进行二轮测试，对回归功能展开回归测试，执行部分用例，提交问题并回归问题
发散测试：在Dev环境中，进行一些异常测试与探索式测试
稳定测试：在release环境中，对发布包（脚本、程序包、文档）进行测试，对重要需求项主要功能进行测试
4.3.2确定每个轮次中的测试策略
主要包含以下几个方面：
（1）准入准出条件：依据项目实际判断准入准出条件
a.准入
初测：实现交底、需求验证通过，达到提测标准
二轮测试：问题解决率>XX%，问题关闭率>XX%
稳定测试：发布包准备完成、问题收敛、缺陷遗留
b.准出
计划执行的测试的用例已经完成
缺陷分析的结果符合预期
达到了系统测试阶段的测试目标
（2）用例执行范围：依据项目实际判断用例执行范围
例如：
新功能：全量用例
回归功能：高优先级用例
（3）用例执行优先级：与总体策略中的优先级保持一致，总体优先级原则如下：
原则
特性优先级从高到低
用例优先级从高到低：重点功能模块、用户使用度高的模块，实现复杂的模块优先执行
（4）模块测试策略：每个阶段具体完成那些工作，每个模块该怎么开展测试，怎么跟踪每个阶段？出现异常怎么处理
测试形式
主要涉及外部对接的模块，是家里测试/内部联调（公司内不同系统间）还是现场测试/外部联调
验证内容
功能检查、日志检查、发布包（脚本、文档、程序、version）等
异常处理
二轮对于一轮问题集中的模块怎么处理？–增加发散测试/重新测试；
问题不收敛的模块怎么处理？–增加收敛测试
跟踪执行策略
跟踪用例执行（执行效率、执行顺序、被阻塞用例）
跟踪缺陷检出（缺陷优先级、缺陷趋势、修改引入）
遇到变更及时调整测试策略
（5）其他事项
缺陷解决
达成一致的目标，每个阶段每天解决多少？关闭多少？遗留的怎么处理？
收敛时间
收敛时间多久？怎么样代表收敛？
稳定阶段缺陷分析跟踪
分析是否漏测？是否修改引入？对应的解决办法？能否达到发布要求等
(三) 测试内容分析
测试内容的分析其实就是对需求的重点和难点的甄别与分析，测试需求分析越详细精准，表明对所测软件的了解越深，对所要进行的任务内容就越清晰，就更有把握保证测试的质量与进度。方案设计中我们重点需要关注测试重点与难点的分析并得到有效的测试方法与测试策略
1.需要考虑的分析维度
功能需求
显性的需求分析点：占据系统80%左右的内容，是软件的主体。
系统包含哪些主要的功能，每个功能的期望值是什么？–最小化原则
业务需求
隐性的需求分析点：需要细化分析–场景法/业务水平
实际的业务场景可能有哪些？分别通过什么解决方案来实现，比如XX功能，这个功能做了什么？要达到什么目的？
性能需求
隐性需求分析点：分析是否存在性能瓶颈？大数据量？大用户量？
易用性需求
隐性需求分析点：功能的设计是否符合用户的使用需求？是否简单易用易理解？
兼容性需求
是否需要兼容不同的环境？—基于客户现场环境的分析
分类：浏览器、操作系统、终端、数据等
安全性需求
敏感信息传输是否有保障机制？
2.如何区分重难点
实际测试执行中，资源和时间是有限的。因此，我们想要在有限的资源和时间下，保障基本的质量目标，并尽可能提升质量目标，就需要在分清测试内容中的重点与难点，依据重难点划分优先级。以下是几个考虑原则：
（1）测试重点
被测功能在系统中的地位
一般多集中于大功能，为需求中的重要需求项，客户较为关注
非核心功能，但对核心功能影响较大的模块
被测功能在系统中的使用频率
使用频率高的功能需重点关注
客户能够容忍哪些问题
能接受错误的模块—次要
不能接受错误的模块—重要
被测功能出现问题造成的结果带来的影响
致命（数据丢失、功能不可用、宕机）–重要
被测功能出现问题的几率
容易出问题、不健壮—重要
（2）测试难点
被测功能设计实现复杂
分析不清楚影响范围，分析不清楚当前实现，对系统有什么影响
测试场景构造复杂
无法模拟用户场景，或者模拟的场景跟真实场景有差异
牵涉业务复杂
分析不清楚业务
3.分析方法
（1）分析来源
用户故事—第1重要
功能需求文档—第2重要
研发设计文档—次要，可参考挖掘一些测试点
（2）怎么分析
以下为大家介绍我常用的两种分析方法：
（a）三层架构模式分析法–需要了解功能设计与系统架构
原理
三层架构模式法是说在分析一个功能时通常把被分析对象划分为3个层次，包括功能应用层、模块接口层、系统接口层；从这三个方面着手分析测试对象本身的业务功能，与其他模块间、系统间的关系，由外向内，逐层深入进行全链路析
三层架构
功能应用层：直接面对用户上层应用，用户可感知的，输入输出用户能够看到的
模块接口层：为上层应用提供数据输入，同时传输数据到系统接口层，起桥梁作用
系统接口层：底层代码设计，与外部系统/内部资源交互的对外接口/功能
数据流向（依赖关系）
系统接口层—>模块接口层—>功能应用层
业务流向
功能应用层—>模块接口层—>系统应用层
关注点
功能应用层：关注功能应用结果
例如：输入输出结果是否正确？上层应用展示效果是否正确？
模块接口层：关注数据传输与获取是否正确，例如：
获取：①请求频率设置②接口请求过程③数据获取情况（正确性、完整性）
传输：①传输数据是否正确（正确、完整）②传输过程是否安全（加密、备份
系统接口层：关注对外接口的健壮性、正确性、以及是否符合业务逻辑
其他：数据库检查、日志检查、异常情况的处理
(b) 多叉树节点分析法—需要熟知业务背景与用户的使用场景
原理
站在用户的角度，以用户的使用场景为主线（即主流程），在模拟用户场景的过程中找出沿途各节点的测试点，接着再以测试点为起点，扩展使用场景；分析过程中，可以分为主流程和分支流程、异常流程，基于每个流程都以这种方式对测试内容进行分析
关注点
业务流程：业务流处理是否正确
数据处理：数据流向是否正确
其他：流程中涉及的其他功能设计是否合理正确
(四) 其他（可选）
除了上述涉及内容之外，方案中我们也可以加入对现场用户环境，功能测试环境的分析，加入测试整体的计划安排，以及基于测试目标的结束准则
测试环境
测试计划
结束准则
|