1.3.2 缩写语
缩写语:全名,(中文名称,解释)
1.4 参考资料
[本小节应完整地列出此测试指南中其他部分所引用的任何文档。每个文档应标有标题、报告号(如果适用)、日期和出版单位。列出可从中获取这些参考资料的来源。这些信息可以通过引用附录或其他文档来提供。]
[格式:作者,版本,出版日期,[出版社名],”文件名称”,比如:
廖洪涛, V1.0, 2005/10/11,“媒体烽火台系统-数字电视机顶盒设计需求参考规范” ]
1.5 概述
[本小节应说明此测试指南中其他部分所包含的内容,并解释文档的组织方式。]
[1.1-1.4应该描述而没有描述的部分]
2. 测试目标
[陈述组织执行和使用测试的原因。][测试应该达到那种目标? 为什么要进行该测试?]
3. 测试标准
[本节确定并说明将在计划、设计、实施、执行和评估等活动中使用的所有指南和标准。这些指南和标准包括:[测试指南的主体部分]
· 测试用例标准:确定应该为测试而开发的测试用例的类型,例如有效测试用例、无效测试用例、边界测试用例等。[比如java API测试中应该包括功能性测试,完整性测试,监听测试以及稳定性测试,并且简单描述每项测试的功能]
· 命名约定:说明应该如何给各种实体(如测试用例和测试过程)命名。[测试用例编号应该按照何种规则命名? UI中的名称应该用啥符号引起来? …]
· 设计指南:说明测试过程和脚本模块化在复用和维护方面的目标。[如果测试需要书写测试脚本,对测试脚本进行架构设计,可用图及文字进行描述,注明模块与模块之间的关联和依赖关系,必要的时候加上数据流向说明。
测试用例的设计大纲,以及哪些测试用例可以被其他模块复用,比如软件启动功能测试用例是其他功能测试用例的前提条件;时间输入检验测试用例可以在EPG时间设定,系统设计时间设定测试用例中复用。
如果需要有测试脚本支持,如何使用测试软件,即测试脚本的界面设计?可以引见附录]
4. 测试数据
说明如何为支持测试而选择(或创建)和恢复数据。] [完成该测试需要何种测试数据? 测试数据信息是什么? 应该如何配置这些测试数据? 可以引见附录]
5. 主要评测方法
[指定将采用何种评测方法来确定测试活动的进展,例如将要使用哪种缺陷计数,如何评测已成功执行的测试用例等。]
[比如通过查看测试代码运行后的测试报告文件来判断测试用例是否通过。通过按照测试用例的步骤进行操作是否达到预期效果来评定测试用例是否通过等]
6. 测试完成标准
[说明推荐使用的完成及评估标准。]
[什么条件算测试完成? 比如每一条测试用例测试结果与测试计划中描述的希望结果一致。测试结束产品发布的标准是什么:比如>99.995%的测试用例通过测试;所有重要的缺陷得到解决,总的测试缺陷控制在百分之多少以内?]
7. 缺陷管理指南
[说明将如何管理缺陷。]
[测试中发现的缺陷应该如何进行管理?比如通过Bugzilla, 还是书写测试报告单。发现缺陷后开发人员与测试人员应该如何进行交流,什么级别的缺陷应该尽可能在多长时间解决。本版本不解决的缺陷应该如何控制?]
8. 变更管理标准
[确定将如何管理和维护测试工件。]
[描述如何管理此文档的变更及其发生变更应该告诉那些人员以及如何告知?
比如:文档变更应该在头部历史记录中详细注明变更内容,并且将变更文字变更为红色,另外重新建立文件,文件格式为:文件名+YYYYMMDD.doc。通过Email告诉测试计划设计师,测试开发人员。同时也应该告诉测试部门经理,技术总监,以及文档版本管理人员]