美文网首页
三、测试需求分析

三、测试需求分析

作者: Rannio | 来源:发表于2018-08-18 21:11 被阅读0次

    1.测试需求分析

    测试需求分析就是分析我们测试什么、如何测试的过程。通过完备的测试需求

    分析可以输出高质量的软件测试计划、软件测试方案、软件测试用例

        测试需求来源

        测试项分析

        测试子项分析

    2.软件需求来源分析

    • 开发需求

    • 协议/标准/规范

    • 用户需求(用户经验)

    • 测试案例库(测试经验)

    • 竞争分析

    3.原始测试需求提取

    • 原始测试需求提取针对需求来源分析确定的测试需求来源范围,分别提取原始测试需求(原始测试项)。不同来源范围提取出来的原始测试需求可能存在重复和冗余,需要进行整理,整理后的原始测试需求(原始测试项),作为后续原始测试需求分析活动的输入。

    - 开发需求

    - 协议/标准/规范

    - 用户需求(用户经验)

    - 测试案例库(测试经验)

    - 竞争分析

    4.需求来源是开发需求

    • 对于输入是开发需求的情况,可以考虑直接将一条开发需求做为一条原始测试需求来提取,然后参考设计规格,检查提取出来的原始测试需求是否存在遗漏。当然,如果觉得开发需求的粒度不合适,可以考虑拆分成多条或者合并为一条原始测试需求。为明确测试和开发需求的对应关系,要建立原始测试需求和开发需求的跟踪关系,明确提取的原始测试需求对应的开发需求标识,如果有合并的情况,则对应多个开发需求标识;

    5.需求来源是协议/规范/标准

    • 对于来源范围是协议标准规范的情况,因为协议标准规范,同时也是做为开发需求的输入,两者实质上是保持一致的,所以如果两者分别提取原始测试需求会存在大量重复。实际操作中,通常是将开发需求和相关的协议标准规范分配给同一个人,以其中一个为主另一个为辅来进行原始测试需求的提取。比如以开发需求为主提取出原始测试需求后,再针对协议、标准、规范来分析补充,可补充的原始需求通常包括如下情况:开发文档未详细说明,而是参见某某协议标准规范;开发文档未充分考虑到相关协议标准规范的要求,存在遗漏或者错误;除开发文档要求外,还存在其它需要遵循的协议规范和标准等情况;

    6.需求来源是用户需求

    • 单独从用户需求和开发文档中提取原始测试需求,也会存在大量的重复,所以通常也是将开发文档和相关的用户需求文档分给同一个人,以其中一个为主另一个为辅来进行原始测试需求的提取。因为开发需求往往是对用户需求的细化分解,所以一般情况是以开发需求为主提取出原始测试需求后,再通过对用户需求的分析验证看提取的原始测试需求是否全面正确。同时,为了让测试更直接面向用户,可以以用户需求为主线,将从开发需求提取出来的原始需求进行整理,因为实际上将这些开发需求还原后,真正的需求来源就是用户需求。而质量较高的用户需求通常是从用户实际使用的角度来描述和划分的(可以称之为用户使用场景),这比较符合测试的习惯或要求,这样可以把它们直接作为原始测试需求核心内容。但由于用户考虑问题并没有参考系统实现的知识,所以对应到具体的系统上信息不完整,所以需要结合开发需求、设计规格和产品知识进行补充,使得其更加完整和准确。另外部分用户需求是没有体现在开发需求中的,但却可能提取做为原始需求。

    7.需求来源是测试案例库

    • 测试案例库中保存了通过测试执行、缺陷分析、用户应用反馈、相关系统同步等途径提取出来的原始测试需求。这些原始测试需求可以作为测试分析设计的直接输入;

    8.需求来源是竞争分析

    • 从竞争分析报告之类的原始测试需求来源中可以直接提验一些功能规格、性能指标、操作规范等作为所测试系统的原始测试需求。

    9.测试项分析

    • 测试项分析可以参考的工程方法:质量模型分析、功能交互分析、用户场景分析等等,每个工程方法都要独立的输出初始测试项,也就是说初始测试项是从不同测试角度进行分析输出的结果。

    10.质量模型分析

    • 软件质量由功能性、可靠性、效率、易用性、可维护性、可移植性等特性角度来衡量,其中每个质量特性又可分为若干子特性角度,质量模型分析就是从软件质量因子角度来分析的。从不同的测试目的出发、以不同的角度来分析和测试产品,确定不同的测试类型来检测质量,不同测试类型的测试会发现不同类型的Bug。

    11.功能交互分析

    • 软件功能不是独立的,功能之间存在交互、顺序执行等影响因素,这就是功能交互分析的角度。将被测功能和软件其他相关功能进行交互分析,根据影响点可以得出初始测试项。被测功能,也可以代指原始测试项或一组有逻辑关系的原始测试项集合,软件其他相关功能包括所有需要进行交互分析的新增和继承功能特性。通过分析功能间的相互影响,能非常有效的提升测试完备性。

    • 例如:电子商务系统,购物流程是一组有逻辑关系测试项集合。

                    注册-》登录-》查询-》添加购物车-》填写订单-》支付-》评价商品。

    12.用户场景分析

    • 从用户角度出发(注意这里的用户是泛指,而不仅仅指人)来关注每个用户是如何使用和影响被测功能特性的,更能从基于用户的角度来分析 。 分析用户存在哪些使用可能的场景,每一个场景都可能是测试项。

    13.测试子项分析

    • 测试子项分析活动是针对测试项的进一步分析、细化,形成为测试子项的活动过程。

    • 测试子项分析主要是对测试项进行处理。对测试项的处理存在以下几种情况:

    - 对粒度小的测试项不处理,直接进行特性测试设计;

    - 对粒度大的测试项进一步细化,形成为测试子项,然后对测试子项进行特性测试设计。

    - 将测试项分析细化为测试子项所采用的工程方法有逐级细分法。

    - 分析出每个测试子项的输入、输出、处理过程输出测试重点,作为测试方案或测试用例设计的参考。

    14.测试用例设计

    • 测试用例规划是根据特性测试设计分析确定的各测试用例规格,实现测试用例;按照测试用例的模板将测试用例的输入和预期输出参数具体化,并且将测试用例的执行步骤、观察点、预置条件等明确化。

    相关文章

      网友评论

          本文标题:三、测试需求分析

          本文链接:https://www.haomeiwen.com/subject/ghbvbftx.html