系统测试规范

系统测试规范(试行)
1.测试计划和方案
OBJECTIVE: 使系统测试真正起到对系统的质量控制的目的并保证测试计划的安排和实施。

1.1概要测试方案
OBJECTIVE：使测试方案基本定型。

概要测试方案内容包括：
1.模块架构（Module Hierarchy）、模块数据使用（Module Data Usage）及数
据流程描述；
2.每个处理模块的输入 / 输出数据的详细描述；
3.每个模块的测试要求，测试环境和测试方法；
4.每个模块测试的时间表安排，说明哪一步测试应在什么阶段完
成，完成的标志和评审方法；
5.边界值测试的 CASE，包括输入数据和输出数据；
6.标明哪些模块需要重点测试；
7.标明哪些处理模块有可能或必要做较严格的 Performance (Volumn)
Testing;
8.对于数据库的设计，要形成一个较完善的测试方案，对 Server
端表的定义、 Trigger 的定义和部分 Stored Procedure 定义有明确的测试目标和手段，提供测试用案例；
9.测试案例的编号规则和书写风格；
10.测试报告的形式
1.2详细测试方案
OBJECTIVE：使测试方案变为可操作。

详细测试方案内容包括如下内容：
1.模块架构（Module Hierarchy）、模块数据使用（Module Data Usage）及数
据流程描述；
2.每个处理模块的输入 / 输出数据的详细描述；
3.每个模块的测试要求，测试环境和测试方法；
4.每个模块测试的时间表安排，说明哪一步测试应在什么阶段完
成，完成的标志和评审方法；
5.边界值测试的 CASE，包括输入数据和输出数据；
6.操作功能的描述及其测试 CASE ；
7.每个输入域的测试方法、数据划分、边界约束条件和测试
CASE ；
8.与其他模块相关的数据输入、查询和报表打印方面的约束，并
有测试 CASE ；
9.对有特殊要求的界面，应有相应的特殊测试手段描述及 CASE 设
计；
10.性能测试的 CASE 设计；
11.详细、完善的 Server 端所有对象以及定义在这些对象上的约束
等的测试方法描述、测试数据以及测试用案例；
2.功能和性能测试
OBJECTIVE：发现系统在功能上的遗漏、欠缺、不合理或流程与设计描述不符等错误。

产生功能测试报告和集成测试报告。

1.1单元测试（UNIT TESTING)
OBJECTIVE：在程序模块提交给系统集成时，所有下列的项目应该全部测试通过 (Error Free)。

2.1.1输入界面
对输入界面而言，单元测试包括如下几方面：
1.记录添加、删除、存盘（更新数据库），记录刷新和界面退出的测
试；
2.输入域（输入字段）的测试；
3.Master - Detail 型输入界面的测试；
4.其他方面的测试；
记录添加、删除、存盘、刷新操作和界面退出
1.是否允许连续添加空记录，如果允许，则在删除其中某一条空
记录时会引起什么反应；
2.是否允许在数据输入不完全的情况下存盘；
3.删除记录时是否提醒用户；
4.已做了删除动作，界面上看起来记录也已删除，此时如不存盘
退出会出现什么情况？再进入后已删除的记录是否还在？
5.界面退出时如数据已发生修改，是否提醒用户存盘；
6.界面退出时如数据未发生修改，是否也在提醒用户存盘；
7.如设有数据刷新功能按钮或菜单，在执行该项功能时是否检测
数据的修改与否并给出提醒；
输入域
输入域测试的主要内容应包括：
1.字符串字段（输入域）的测试；
•如屏幕上显示的长度不够，输入时是否有自动前滚功能；
•是否有大、小写限制；
•有特殊要求的有效性检查是否起作用，何时起作用；
•是否有默认值？设置是否合理；
2.日期字段的测试；
•日期的输入格式；
•最大日期和最小日期的界定是否合理；
•是否有默认值？设置是否合理；
3.下拉列表输入字段的测试
•仅选和允许输入功能的测试；
•列表内容是否及时更新或配有相应的列表内容维护输入界面；
•是否有默认值？设置是否合理；
4.数值输入字段的测试；
•边界值的测试；
•小数位数测试；
•是否允许输入其他非数值字符；
•是否有默认值？设置是否合理；
5.关键输入字段的测试；
•所有关键字段在做完上述 1 － 4 严格测试后要测试非空限制和报错的合理性；
•重复数据输入是否报错；
Master - Detail 型输入界面
对于 Master - Detail 型输入界面的测试，除了上面两节提到的内容应分别对 Master 和 Detail 数据进行严格测试外，还应特别就以下方面进行严格测试：
1.删除 Master 数据对 Detail 数据带来的影响，除界面上体现的效果
外还要看数据表中数据的一致性；
2.修改 Master 中的关键字段对 Detail 的影响，检查数据表中的数据
是否一致；
其他方面
1.Mini Help 的测试；
2.提示、报错信息是否准确清晰而不罗嗦；
3.Toolbar 上是否有 Tip;
4.界面的名称是否合理、准确；
5.对那些暂时由于数据不完备而无法测试的功能，应详细记录并
设计好测试数据和方法，提交程序员经理和 / 或项目经理；
2.1.2查询（报表）界面
条件设置 / 输入
1.查询条件的输入是否方便（如有些查询条件可通过下拉选择确
定）；
2.对不合理输入是否检查，报错是否准确。

（参考 0 中有关输入域
的测试规范）；
数据显示
1.显示窗内容的刷新是否满足条件输入窗中的条件；
2.显示（打印）格式是否满足要求；
3.如果查询的目的是为下一步操作提供数据源，则数据显示窗中
的数据选择是否有明显标志；
其他
1.如有打印功能，则测试打印内容是否符合要求；
2.如果查询的目的是为下一步操作提供数据源，则下一步操作是
否能得到相关的数据；
3.对于冗长数据的查询是否有 Cancel 功能键，作用如何；
4.对统计查询，要验证计算是否正确，分组是否合理；
5.查询速度的自检，如发现明显慢，要及时报告程序员经理和 /
或项目经理；欢迎提出好的解决方案；
6.对那些暂时由于数据不完备而无法测试的功能，应详细记录并
设计好测试数据和方法，提交程序员经理和 / 或项目经理；
2.1.3其他程序对象
1.设计 CASE 测试 SERVER 端的 PROCEDURE， FUNCTION 和 TRIGGER 并填写测试报
告；
2.对那些暂时由于数据不完备而无法测试的功能，应详细记录并
设计好测试数据和方法，提交程序员经理和 / 或项目经理；
2.1.4文档
1.通过全部上面测试案例并附合编程规范的源程序文档；
2.所有测试案例 ( 包括测试通过、未通过、暂不能通过的 ) 整理
后的文档；
2.2集成测试 (INTEGRATION TESTING)
OBJECTIVE：发现子系统各模块之间相互衔接中的数据流程错误并提交项目组有关人员安排排错，保证子系统在提交时为 ERROR FREE 。

2.2.1任务
1.在充分理解设计文档和测试方案的基础上制定此阶段的测试计
划；
2.CASE BY CASE 对系统的各项功能进行测试 (BLACK BOX TESTING) 并分析输
入、输出结果；
3.重点测试那些在UNIT TESTING 阶段很难或无法完成的功能测试；
4.对测试方案中标明要重点测试的模块进行严格测试；
5.对测试方案中标明要进行性能测试的模块进行大数据量的性能
测试；
6.测试结果必须形成完整的测试报告以备存档；
7.此测试阶段如发现有由于UNIT TESTING 未做好而出现的 BUG，要详细
记录存档，作为对程序员考核的依据。

8.在项目组基本完成子系统功能测试后，可将系统移交项目组以
外的人员（模拟用户）对该子系统进行至少三天的功能测试（包括基本功能和数据流程测试）。

形成测试报告供项目组参考和存档。

2.2.2文档
1.模块功能测试报告 ( BLACK BOX TESTING REPORTS )
2.模块及子系统性能测试报告 ( PERFORMANCE TESTING REPORTS )
3.通过测试的 CASE 和未通过测试的 CASE 整理结果文档；
2.3系统测试 (System Testing)
OBJECTIVE：在模拟环境下测试整个系统的功能和性能，发现问题并改进。

2.3.1任务
1.建立和用户要求相当的测试环境 ( 包括硬件、网络和软件运行
平台 ) ；
2.当各子系统完成测试之后，可计划并实施系统功能及性能测
试；
3.要特别注意子系统之间数据传递和 / 或共享的正确性、合理性、
完整性和一致性；
4.网络硬件环境、CLIENT 端和 SERVER 端操作系统平台、本地化平台和
系统本身的运行性能及匹配性的测试在此阶段必须高度重视。

5.系统整体的可靠性测试；
6.多用户同时存取相同数据的测试；
7.异常情况下数据保护和恢复的测试；
8.系统安全性能的测试；
9.系统的可维护性以及配置适应性测试；
2.3.2文档
1.系统性能 ( 包括负载性能、网络传输性能、大数据量性能、安
全性能和可维护性能等方面 ) 测试报告；
2.通过测试和未通过测试的 CASE 整理后的文档；。