精品文档
软件产品测试过程
编写测试用例
测试用例是输入、 执行条件和一个特殊目标所开发的预期结
果集合。它按测试目的不同可分为以下几种类型:
A. 需求测试用例: 测试是否符合需求规范
B. 设计测试用例: 测试是否符合系统逻辑结构
C. 代码测试用例: 测试代码的逻辑结构和使用的数据
需求测试用例通常是按照需求执行的功能逐条地编写输入
数据和期望输出。 一个好的需求用例是可以用少量的测试用例就
能够覆盖所有的程序功能。
设计测试用例检测的是代码和设计是否完全相符。 是对底层
设计和基本结构上的测试。 设计测试用例可以涉及到需求测试用
例没有覆盖到的代码空间(例如界面的设计) 。
代码测试用例是基于运行软件和数据结构上的。 它要保证可
以覆盖所有的程序分支、最小的语句和输出。
以上三种用例所用的数据又可分为正常数据、边缘数据和错
误数据。
A、正常数据: 在测试中所用的正常数据的量是最大的,而且
也是最关键的。 少量的测试数据不能完全覆盖需求, 但我们要从中
精品文档
精品文档
提取出一些具有高度代表性的数据作为测试数据, 以减少测试时间。
B、边缘数据: 边缘测试是界于正常数据和错误数据之间的一
种数据。它可以针对某一种编程语言、 编程环境或特定的数据库而
专门设定。例如若使用 SQL Server 数据库,则可把 SQL Server
关键字(如: ';AS;Join 等)设为边缘数据。其它边缘数据还有:
HTML的 HTML;<>等关键字以及空格、 @、负数、超长字符等。边缘
数据要靠测试人员的丰富经验来制定。
C、错误数据: 显而易见,错误数据就是编写与程序输入规范
不符的数据从而检测输入筛选、错误处理等程序的分支。
由于执行测试用例的数据量巨大以及还要进行回归测试, 所以
可以考虑使用自动测试工具, 但提取测试数据仍要依靠编写测试用
例人员的经验。 并且,我们还要注意到自动测试也许不能找到程序
中所有错误,手动测试所找到的错误会比自动测试所找到的要多。
有了测试用例, 还要先进行代码的审议。 通过代码审议找到的
错误可以比测试用例测试所能找到的错误更加深入, 并且发现错误
的时间也比测试用例要早。 代码审议以代码标准为依据, 一般情况
下要检查以下几点:
a) 代码风格和规则审核
b) 程序设计和结构的审核
c) 业务逻辑的审核
精品文档
精品文档
代码风格和规则的审核是在每个程序员完成一个模块或类的
时候要进行编码规范的检查。 要召开审核会议让所有的项目组人员
都参加。在会前项目经理要做一个检查表, 以表的内容为检查依据,
检查表的内容主要是检查的要点。 在审核会上项目组的每一个人员
都能看到自己和其他人员的编码问题, 从而起到预防的作用。 这些
问题都要被解决,并且解决的结果要在审议会上被确认。
进行程序设计和结构的审议是因为开发工具的不同和项目时
间的限制而造成设计不详细。 比较深入的设计通常是在编码阶段完
成的,但由于程序人员和设计人员的经验是不同的, 所以会出现很
大的