根据统计表面,在软件开发生命周期早期引入的错误占软件过程中出现所有错误(包括最终的缺陷)数量的50%~60%。此外,缺陷存在放大趋势,如需求阶段的一个错误可能会导致N个设计的错误。因此,越是测试后期,为修复缺陷所付出的代价就会越大。所以,软件测试人员要尽早且不断地进行软件测试(测试左移思想),以提高软件质量,降低软件开发成本。
一般需求分为业务需求、用户需求、功能需求:
测试需求通常是以功能需求为基础,通过对功能需求的细化和分解,形成可测内容。
测试需求应尽可能全部覆盖已定义的业务需求,以及功能和非功能方面的需求。
测试需求用于解决“测什么”的问题,即指明被测对象中什么需要测试。测试需求分析主要用于:
功能需求:系统应该做什么。例如ATM取款机的业务需求:每次取款额度在100-2000之间;取款金额为100的倍数;每日取款总额不得超过20000,这是功能需求。
测试需求:系统应该做什么、系统不应该做什么、发现系统设计中存在的问题。例如取款金额可选在100-2000之间且为100倍数可取;小于100或者大于2000不可取;在100-2000之间但不是100倍数不可取;当日取款总额必须小于等于20000;取款金额必须小于等于账户余额等等,这是测试需求。
开展测试需求分析的前提是要明确业务需求、用户需求、功能需求以及需求的背景、场景。测试流程各环节都应该与此保持一致。
测试需求采集是将需求规格说明书(不限于)中具有可测试性的需求或特性提取出来,形成原始测试需求。(可测试性:指提取的需求或特性必须存在一个明确的期望结果,通过某种方法可以对期望结果进行验证是否符合文档中的要求。)
测试需求采集方法:
需求项整理:可通过上方需求采集方法进行需求项的整理,测试方还需要与项目组确认功能需求的优先级或重要程度,并对其达成一致,此为产品质量等级目标的重要依据之一。但不是所有项目需求都是清晰的、有需求说明书的,可能会遇到以下几种情况:
测试点整理:测试点的提取主要依据的是前面我们讲到的六大质量模型以及测试类型和测试方法,结合功能需求被测对象(功能点)进行测试需求分析,就可以知道我们需要从哪些方面进行测试,从而提取出测试点。测试点优先级划分一般分为高中低,功能场景为高,异常功能场景为中,非功能场景为低。后续测试用例可延用测试点的优先级划分。
测试需求跟踪矩阵明确功能点与测试点的对应关系,列出所有整理需求项的功能点与之对应的测试点,同时需要包括测试类型以及优先级&重要程度。
测试需求分析产出的需求跟踪矩阵需要与项目组进行评审,需要各方达成一致。