9.4.1 测试策略
测试策略如表9-13所示。
表9-13 测试策略
序号 |
章节 |
内容 |
1 |
概述 |
² 目的:描述文档的目的; ² 范围:描述文档所包括和不包括的内容。同时应当描述本测试策略所覆盖的模块、项目和子项目 |
2 |
测试综述 |
² 测试活动:列出了所有与测试相关的活动,从中选择将要执行的活动,生成并执行单元/集成/系统测试计划和测试用例; ² 风险因素:可能影响到测试进度的因素,包括与其他产品、项目甚至第三方软件或设备间的依赖关系,关键路径的可实现性,质量目标的可实现性,人员到位情况,关键技术成熟性等。分析风险级别并针对每个高风险制定规避措施及应急计划; ² 折中方案:描述在特殊情况下需要采取的折中方案。例如在进度拖延的情况下,如果98%的测试例都通过了测试,则认为测试已经完成 |
3 |
系统测试 |
² 质量目标:确定测试活动预期的质量目标,如覆盖策略、覆盖率、千行代码缺陷数等; ² 测试重点:确定本次测试的侧重点,包括需要关注的特征,需要进行的测试类型(例如兼容性测试、性能测试、稳定性测试等); ² 测试对象依赖关系:描述被测对象间的关系、被测对象与软件其他部分间的关系,并且注明各个元素之间的依赖关系,以确定其测试顺序,在集成测试计划中需要明确集成策略; ² 回归测试策略:在下一轮测试中,用本轮测试的所有测试用例重新测试,确认所有缺陷都已改正,在最终的交付版本中执行所有的测试用例,验证所有已发现的缺陷和功能; ² 停止准则:项目成功地通过了所有的测试用例,或者所有已发现的所有缺陷都已完成回归测试 |
4 |
人力资源及工作量 |
进度、职责和测试人员的工作量在项目计划中指定,需要的硬件、软件和其他设备 |
5 |
质量过程 |
遵循标准,测试用例格式包括测试用例ID、测试重要级别、测试标题、预置条件、输入、预期输出 |
9.4.2 测试计划
测试计划如表9-14所示。
表9-14 测试计划
序号 |
章节 |
内容 |
1 |
概述 |
² 基本情况介绍:简单介绍产品,并说明单板的正式名称和PCB版本号; ² 测试范围:简要描述调试、测试的范围,并加以说明,可以用列表加说明的方式,列出所有将被作为测试目标的测试项目(包括功能测试项目和非功能测试项目,后者包括性能测试、兼容性测试等)。确定测试项目中应测试的所有特性和特性组合 |
2 |
测试准备 |
² 测试组网图,简单描述调试测试的组网图; ² 资源需求:软件需求,描述测试所需要的支撑软件的名称、数量、版本,例如操作系统、数据库、编译器、预处理器、测试工具等,应描述每一项的用途及应用范围。硬件需求,描述测试所需要的硬件环境的名称、数量、版本,例如硬件设备、计算机、打印机、接口设备、测试仪器,以及各种软件运行所需的硬件设备等,应描述每一项的用途及应用范围。人员需求,表述人员相关的其他信息,包括特殊要求、关键技能、领域经验、外部支持等。如果需要,还应描述人员相关的其他信息,如轮班制度等。特殊测试环境要求,简单描述其他调试测试环境需求,如网络、接口、工具及其他专有环境 |
3 |
测试计划 |
² 进度计划:测试时间需求,简要描述不同调试项目的时间、人员计划安排,以及时间估计,可以黏贴、引用三级计划或者其他相关文件; ² 过程条件:启动条件,测试执行活动开始所应具备的条件。结束条件,测试结束的条件或标准。挂起条件,测试过程无法继续时应挂起测试,本节描述会导致测试挂起的各种因素。这些因素可能包括测试依赖因素不具备、进入某项风险临界区、管理决策等。恢复条件,测试挂起后恢复测试的条件,与挂起条件相对应; ² 测试风险分析:分析调试测试过程中的关键路径,分析调试测试过程中的风险、风险严重程度、可能性、防范措施 |
4 |
测试用例 |
记录本测试计划需要的测试用例,如功能部分调试用例、性能调试用例等 |
5 |
培训计划 |
描述测试前或测试中需要进行的指导、培训工作,这些培训可以包括用户指引、操作指引、维护控制组指引,对成员的指导简报,如果需要提前进行大规模培训,将培训计划作为项目计划一个独立的部分,并在此处引用 |
6 |
其他 |
其他关键内容,如风险管理 |
9.4.3 测试方案
测试方案一般包括产品的测试环境、测试内容、测试方法及测试用例,如表9-15所示。
表9-15 测试方案
序号 |
章节 |
内容 |
1 |
概述 |
基本情况介绍,简单介绍产品,术语和缩略语,参考资料 |
2 |
需求跟踪 |
² 需求编号应与用户需求说明编号一致,每一条需求应至少被一条(但不限于一条)测试用例所覆盖; ² 对测试方案所涉及的被测试特性进一步展开描述。如有必要,描述被测试特性与“需求规格说明书”或“设计说明书”中的需求或功能之间的对应关系,即描述测试的需求跟踪情况 |
3 |
测试内容 |
简略说明测试的内容、功能、需要达到的技术指标 |
4 |
测试环境 |
验证平台结构,各模块功能 |
5 |
测试用例 |
测试用例1、测试用例2…… |
6 |
测试通过准则 |
² 定义每个测试项目测试通过或失败的准则,测试通过或失败的准则是客观的陈述,该陈述指明了判断和确认测试何时结束及测试项目的质量; ² 所有要求的测试用例和测试程序都已经执行,所有的缺陷都已经定位。所有要求的测试用例和测试程序都已经被重新执行一次,并且没有发现新的缺陷,测试通过准则满足验证工作规程的要求 |
7 |
主管应及时组织对测试方案的评审,按照测试方案的评审要素文档,进行审核,并将评审报告记录在这里 |
9.4.4 测试用例
测试工作和开发通常是并行的,一般在完成测试计划编写后就可以进行用例的编写工作,如表9-16所示。
表9-16 测试用例
序号 |
名称 |
描述 |
1 |
用例编号 |
对此用例进行编号,如子系统名、模块名、编号 |
2 |
用例名称 |
用例的名称 |
3 |
需求描述 |
对需求项进行描述 |
4 |
测试目的 |
测试所要验证的内容,说明本测试用例的设计目的、设计思路,以使测试人员在实施测试过程的时候目标更加明确 |
5 |
测试类别 |
单元测试、功能测试、性能测试、机械测试等 |
6 |
测试对象 |
测试的具体对象,硬件如FLASH的读写,软件如汉字输入函数等 |
7 |
用例级别 |
表明该用例的重要性,用例的重要性并不对应用例可能造成的后果,而是对应用例的基本程度,一个可能导致死机的用例未必是高级别的,因为其触发条件可能相当生僻,一般分为基本、重要、详细和生僻 |
8 |
测试工具 |
测试需要使用的专用工具、软件等 |
9 |
前置条件 |
测试用例执行需要的测试环境 |
10 |
测试步骤/测试方法 |
测试操作过程描述,说明执行本测试子项目时所需的输入,以及由此而产生的输出和需进行的一系列顺序执行的操作,包括测试所需的外界条件 |
11 |
测试预期结果 |
根据理论得出正确的结果 |
12 |
测试结果 |
结论,包括测试中发现的问题,可以是附图 |
13 |
测试结论 |
通过、不通过 |
14 |
测试工程师 |
填写该测试用例拟安排的测试工程师 |
15 |
测试日期 |
填写计划测试的日期 |
16 |
备注 |
如极限条件测试 |
9.4.5 测试报告
测试报告如表9-17所示。
表9-17 测试报告
序号 |
章节 |
内容 |
1 |
概述 |
² 编写目的:说明这份测试分析报告的具体编写目的; ² 背景:被测试产品的名称,指出测试环境与实际运行环境之间可能存在的差异,以及这些差异对测试结果的影响 |
2 |
测试概要 |
用表格的形式列出每一项测试的标识符及其测试内容,并指明实际进行的测试工作内容与测试计划中预先设计的内容之间的差别,说明做出这种改变的原因 |
3 |
测试结果及发现 |
测试1:把本项测试中实际得到的动态输出,包括内部生成数据输出,结果同对于动态输出的要求进行比较,陈述其中的各项发现 |
4 |
测试结论 |
功能1:简述该项功能,说明为满足此项功能而设计的产品能力,以及经过一项或多项测试已证实的能力。说明测试数据值的范围,包括动态数据和静态数据,列出就这项功能而言,测试期间在该产品中查出的缺陷、局限性 |
5 |
分析摘要 |
² 能力:陈述经测试证实了的本产品的能力; ² 缺陷和限制:陈述经测试证实的产品缺陷和限制,说明每项缺陷和限制对产品性能的影响; ² 建议:对每项缺陷提出改进建议,如修改方法、紧迫程度、工作量等; ² 评价:说明该项产品的开发是否已达到预定目标,能否交付使用 |
6 |
测试资源消耗 |
总结测试工作的资源消耗数据,如工作人员的水平级别数量、机时消耗等 |
9.4.6 测试总结
测试总结如表9-18所示。
表9-18 测试总结
序号 |
章节 |
内容 |
1 |
测试主要版次 |
填写此项目所有测试过的产品版本 |
2 |
测试内容 |
填写每一版本所做测试内容,并分析测试覆盖情况和充分性,示例:第一次测试,为某产品的功能测试、性能测试、结构测试、可靠性测试和电磁兼容测试。针对某产品的所有模块进行了测试,测试比较充分,基本上硬件模块的很多细节都测试到,覆盖面很全,发现的问题也很多 |
3 |
测试遗留问题 |
填写每一版本所做测试中出现的问题,并对问题的严重性和后续做描述。示例:第一次测试遗留问题较多,一共30多项,严重或者致命的有10项,是一个很不稳定、不可靠的版本,不过问题都已定位并且在后续版本更改 |
4 |
测试结论 |
填写所有测试完成后的总结分析,示例:从上面测试中可以看出,问题的收敛性是比较好的,基本趋向稳定,本版本是一个质量比较可靠的机型,可以导入生产 |
5 |
建议 |
填写在此项目测试后发现的通用型问题,提供建议和意见。对于每一次升级,无论改动多少都要求走正规的流程,不能升级不提交测试就直接导入生产,建议在出量产版本的时候一定要有测试报告等资料 |