当测试计划完成之后,测试过程要进入软件测试设计和开发阶段。软件测试设计是建立在测试计划书的基础上,认真理解测试计划的测试大纲、测试内容及测试的通过准则,通过测试用例来完成测试内容与程序逻辑的转换,作为测试实施的依据,以实现所确定的测试目标。软件设计是将软件需求转换成为软件表示的过程,主要描绘出系统结构、详细的处理过程和数据库模式;软件测试设计则是将测试需求转换成测试用例的过程,它要描述测试环境、测试执行的范围、层次和用户的使用场景以及测试输入和预期的测试输出等。所以软件测试设计和开发是软件测试过程中一个技术深、要求高的关键阶段。
软件测试设计和开发主要内容有:
● 制定测试的技术方案,确认各个测试阶段要采用的测试技术、测试环境和平台,以及选择什么样的测试工具。系统测试中的安全性、可靠性、稳定性、有效性等的测试技术方案是这部分工作内容的重点。
● 设计测试用例,根据产品需求分析、系统设计等规格说明书,在测试技术选择的方案基础上,设计具体的测试用例。
● 设计测试用例特定的集合,满足一些特定的测试目的和任务,即根据测试目标、测试用例的特性和属性(优先级、层次、模块等)来选择不同的测试用例,构成执行某个特定测试任务的测试用例集合(组),如基本测试用例组、专用测试用例组、性能测试用例组、其他测试用例组等。
● 测试开发:根据所选择的测试工具,将所有可以进行自动化测试的测试用例转换为测试脚本的过程。
● 测试环境的设计,根据所选择的测试平台以及测试用例所要求的特定环境,进行服务器、网络等测试环境的设计。
软件测试设计中,要考虑的要点有:
● 所设计的测试技术方案是否可行、是否有效、是否能达到预期的测试目标。
● 所设计的测试用例是否完整、边界条件是否考虑、其覆盖率能达到的百分比。
● 所设计的测试环境是否和用户的实际使用环境比较接近。
其关键是做好测试设计前的知识传递,将设计/开发人员已经掌握的技术、产品、设计等知识传递给测试人员;同时,要做好测试用例的审查工作,不仅要通过测试人员的审查,还要通过设计/开发人员的审查。
在软件测试设计和开发阶段,按标准GB/T 9386-1988《计算机软件测试文件编制规范》的要求,要编写《测试设计说明》、《测试用例说明》、《测试规程说明》、《测试项传递报告》等文档。
1. 测试用例设计的方法和管理
软件测试用例设计的方法有“白盒”测试和“黑盒”测试相对应的设计方法。“黑盒”测试的用例设计,采用等价类划分、因果图法、边值分析、用户界面测试、配置测试、安装选项验证等方法,适用于功能测试和验收测试。“白盒”测试的用例设计有以下方法:
● 采用逻辑覆盖(包括程序代码的语句覆盖、条件覆盖、分支覆盖)的结构测试用例的设计方法。
● 基于程序结构的域测试用例设计方法。“域”是指程序的输入空间,域测试正是在分析输入空间的基础上,完成域的分类、定义和验证,从而对各种不同的域选择适当的测试点(用例)进行测试。
● 数据流测试用例设计的方法,是通过程序的控制流,从建立的数据目标状态的序列中发现异常的结构测试方法。
● 根据对象状态或等待状态变化来设计测试用例,也是比较常见的方法。
● 基于程序错误的变异来设计测试用例,可以有效地发现程序中某些特定的错误。
● 基于代数运算符号的测试用例设计方法,受分支问题、二义性问题和大程序问题的困扰,使用较少。
测试用例要经过创建、修改和不断改善的过程,一个测试用例具有以下属性:
● 测试用例的优先级次序,优先级越高,被执行的时间越早、执行的频率越多。由高优先级的测试用例组来构成基本验证测试,每次构建软件包时,都要被执行一遍。
● 测试用例的目标性,有的测试用例是为主要功能而设计,有的测试用例是为次要功能而设计,有的则为系统的负载而设计,有的则为一些特殊场合而设计。因此,需要根据不同的目标设计不同的测试用例。
● 测试用例所属的范围,属于哪一个组件或模块,这种属性被用来管理测试用例。
● 测试用例的关联性,测试用例一般和软件产品特性相联系的,多数情况下验证某个产品的功能。这种属性可以被用于验证被修改的软件缺陷,或对软件产品紧急补丁包进行测试。
● 测试用例的阶段性,属于单元测试、集成测试、系统测试、验收测试中的某一个阶段。这样对每个阶段,构造一个测试用例的集合被执行,并容易计算出该阶段的测试覆盖率。
● 测试用例的状态性,当前是否有效,如果无效,被置于Inactive状态,不会被运行,只有被激活的(active)测试用例才被运行。
● 测试用例的时效性,针对同样功能,可能所用的测试用例不同,是因为不同的产品版本在产品功能、特性等方面的要求不同。
● 所有者、日期等特性,测试用例还包括由谁、在什么时间创建,又由谁、在什么时间修改。
根据上述特性,再结合测试用例的编号、标题、描述(条件、步骤、期望结果)等,可以对测试用例进行基于数据库方式的良好管理。测试用例设计完之后,要经过非正式和正式的审查:非正式的审查一般在QA或测试小组(部门)内部进行,包括同测试组人员互相检查,或让人员、测试组长帮助审查;正式的审查一般通过正式文档将已设计好的测试用例分发给相应的系统分析人员、设计人员和程序员,让他们先通读一遍,将发现的问题记下来。然后由测试组长或项目经理召开一个测试用例审查会,由测试设计人员先对测试用例的设计思想、方法、思路等进行说明,然后系统分析人员、设计人员和程序员把问题提出来,测试人员回答,必要时做些讨论。
审查完的测试用例,经修改后,可以直接用于手工测试或用于测试脚本的开发。
2. 测试开发
根据所选择的测试工具脚本语言,如IBM Ratlonal SQABasic,编写测试脚本,将所有可以进行自动化测试的测试用例转化为测试脚本。其输入是基于测试需求的测试用例,输出是测试脚本和与之相对应的期望结果,这种期望结果一般存储在数据库中或特定的格式化文件中。
● 测试开发的步骤,首先要设立测试脚本开发环境,安装测试工具软件,设置管理服务器和具有代理的客户端,建立项目的共享路径、目录,并能连接到脚本存储库和被测软件等。然后执行录制测试的初始化过程、独立模块过程、导航过程和其他操作过程,结合已经建立的测试用例,将录制的测试脚本进行组织、调试和修改,构造成一个有效的测试脚本体系,并建立外部数据集合。
● 由于被测系统处在不完善阶段,在运行测试脚本的过程中,容易中断。所以在测试脚本开发时,要处理好这种错误,及时记录当时的状态,又能继续执行下去。处理这个问题,有一些解决办法,如跳转到别的测试过程、调用一个能够清除错误的过程等。
● 测试开发常见的问题。测试开发很乱,与测试需求或测试策略没有对应性;测试过程不可重用;测试过程被作为一个编程任务来执行,导致脚本可移植性差。这些问题应该避免,在脚本的结构、模块化、参数传递、基础函数等方面设计好。