1.基于需求的测试分析
这是最传统也是最经典的一种测试分析方法。分析对象是需求规格说明书(俗一点,此后就叫“需求”),即对需求进行分解,考虑需求本身,以及需求所影响的功能模块,从而得到测试范围。
分析的基础:
□ 对业务的熟悉。
□ 对用户使用场景的了解。
□ 产品功能矩阵。
分析的方法:
□ 业务流程分析:描述业务的正向流程。
□ 业务状态分析:描述业务对象的状态转换。
□ 测试范围分析:需求本身的功能模块/受影响的功能模块。
对于这个方法,有经验的人可以对需求本身的功能模块做到很准确的分析,但是对于受影响的功能模块,如果不了解开发的实现,则很难界定准确。
2.基于开发实现的测试分析
需要厘清两个方面的问题:厘清用户/需求价值方向、厘清架构/实现的细节。
(1)厘清用户/需求价值方向
重点解释一下这一点:这一点要求分析者对于需求要解决什么问题有清晰的认识,我们做的都是商业软件,每个需求应该都是为了解决商业目标上的某个问题。有人可能会问:那不应该放在基于需求的测分(测试分析)里面吗?答案是这样的:大家都知道测试是无穷尽的,如何在有限的时间内做最优的测试,需要平衡取舍(例如,支付类的应用安全是第一位的,通信类的应用性能是第一位的)。这就要求我们充分把握需求的价值方向,在测试策略和测试关注点方面做出正确的判断。
(2)厘清架构/实现的细节
万变不离其宗,所有的需求经过理解转化为代码,代码的实现架构、实现的细节就是产品上面的体现。测试在理解架构的实现之后编写的代码可以在测试策略与关注点上更加专一,在输入产出比上会大大的提升,转为测试效率与质量上的提升。当我们看清楚里面具体执行的逻辑,进行的操作,测试路径可以采用穷举路径测试来规避风险,提升我们的质量跟效率,甚至在架构上的不合理也可提出建议,做好迭代的基础。
分析测试关注点(界定内容、影响点)包含如下内容。
功能测试详细分析:
□ 涉及模块(文件)
□ 模块交互时序
□ 接口/类/函数设计
□ 实现细节
性能测试详细分析:
□ 基于系统资源的性能测试分析
〇 性能测试相关点
〇 开发相关实现细节
〇 关键指标
〇 性能测试场景设计(或已有的相关测试用例)
〇 性能测试脚本设计
□ 基于响应时间的性能测试分析
接口测试分析:
□ 针对本次功能需求,是否具备可测接口,需要描述清楚为什么要测以及测哪些
〇 接口测试覆盖的接口定义描述
〇 接口内部实现的相关逻辑细节
〇 接口测试涉及的实现方案
□ 针对本次功能需求,是否有接口变更,分析变更影响范围及测试内容
〇 变更接口修改实现的相关逻辑细节
〇 变更接口(函数)对模块内功能影响分析
〇 变更接口(函数)对模块外功能影响分析
稳定性测试分析:
□ 稳定性测试场景设计(用例)
□ 稳定性测试脚本设计
兼容性测试分析:
□ 兼容性测试相关点
□ 开发相关实现细节
□ 兼容性场景设计、测试环境说明(实验室或众测)