(12)产品测试方案设计

XXXXXXX产品测试方案

版本号 项目号 总页数 日 期

VXX XX XXXX-XX-XX

大全

Xxxxx产品测试方案

目 录

1

模板前言 .................................................................. 2

文档目的 ............................................................... 2 适用范围 ............................................................... 2 关键技术 ............................................................... 3 背景 ................................................................... 3

1.1 1.2 1.3 1.4 2

测试参考文档和测试提交文档 ................................................. 3

测试参考文档 ........................................................... 3 测试提交文档 ........................................................... 4

2.1 2.2 3 4

测试进度 .................................................................. 4 测试资源 .................................................................. 4

人力资源 ............................................................... 4 测试环境 ............................................................... 5 测试工具 ............................................................... 6

4.1 4.2 4.3 5 6

系统风险、优先级 .......................................................... 6 测试策略 .................................................................. 7

用户界面测试 ........................................................... 8 功能测试 ............................................................... 8 容错测试测试 ........................................................... 9 性能测试 ...............................................................10 稳定性测试 .............................................................11 兼容性测试 .............................................................11 安装测试 ...............................................................12

6.1 6.2 6.3 6.4 6.5 6.6 6.7 7

问题严重度描述 ........................................................... 12

第 1 页共 页

Xxxxx产品测试方案

测试方案和计划

项目经理: ___________ 项目: _________________ 项目阶段/决策评审点:

概念

计划

开发

验证

发布

生命周期

临时

1

模板前言

1.1 文档目的

＜项目名称＞的这一“测试计划”文档有助于实现以下目标： [确定现有项目的信息和应测试的软件构件。 列出推荐的测试需求（高级需求）。 推荐可采用的测试策略，并对这些策略加以说明。 确定所需的资源，并对测试的工作量进行估计。 列出测试项目的可交付元素]

1.2 适用范围

[描述测试的各个阶段（例如，单元测试、集成测试或系统测试），并说明本计划所针对的测试类型（如功能测试或性能测试）。 本次测试为系统测试，本计划针对的测试类型为： （如功能测试或性能测试） 被测对象 新增程序：（如： 通过模板配置的程序，新增非模板配置模块） 继承程序：（如：原有七号信令集中监测系统V5.0的部分程序）

应测试的特性 新增程序应测特性为：（如：功能。准确性） 继承程序：（ 如：功能）

不被测试的特性 新增程序：

继承程序：（如：准确性、界面一致性）

测试挂起的标准及恢复的必要条件 挂起测试项标准：

 暂无测试环境（由于测试方法中要求的测试环境复杂，现有的设备和技术无

法搭建此测试环境的）；

 暂无测试数据（测试程序中各个分支语句中符合条件的多种测试数据，现有

第 2 页共 页

Xxxxx产品测试方案

数据有局限性的）；

 暂无测试方法可验证（由于程序设计中没有考虑到程序的可测试性所引起

的）；

 被测试程序出现严重错误，无法运行或者生成重要数据。 恢复测试项的标准：

 因无测试环境而产生的挂起，在测试环境可搭建的情况下恢复测试项；  因无测试数据而产生的挂起，在测试数据完整到位的情况下可恢复测试项；  因无测试验证方法而产生的挂起，在程序经改造为具有可测试性之后可恢复

测试项；

 因被测程序无法执行等错误而产生的挂起，在被测试程序被修改为可实现基

本功能后恢复测试项。

1.3 关键技术

1.4 背景

[对测试对象（构件、应用程序、系统等）及其目标进行简要说明。需要包括的信息有：主要的功能和性能、测试对象的构架以及项目的简史。]

2

测试参考文档和测试提交文档

2.1 测试参考文档

下表列出了制定测试计划时所使用的文档，并标明了各文档的可用性：

[注：1.可适当地删除或添加文档项。但*文件为必须提供评审通过的文档。 2. 软件需求定义和软件需求跟踪矩阵产品人员必须提供，否则无法进行后续的测试方案的制定工作。 3.在需求明确后，产品人员需要提交需求对应的业务测试用例给测试人员进行参考。尤其在需求变更、开局，或者选型测试，必须由产品人员提交对应的业务测试用例和测试数据，做为测试人员的测试依据] 表 1 文档（版本/日期） 已创建或可用 已被接收或已经过复审 可行性分析报告 软件需求定义* 软件需求跟踪矩阵 需求变更单 业务测试用例 软件概要设计* 软件详细设计 是□ 否□ 是□ 否□ 是□ 否□ 是□ 否□ 是□ 否□ 是□ 否□ 是□ 否□ 是□ 否□ 是□ 否□ 是□ 否□ 是□ 否□ 是□ 否□ 是□ 否□ 是□ 否□ 作者或来源 备注 产品人员 产品人员 产品人员 产品人员 产品人员 研发人员 研发人员 第 3 页共 页

Xxxxx产品测试方案

软件测试需求 测试数据 测试时间表及人员安排 是□ 否□ 是□ 否□ 是□ 否□ 是□ 否□ 是□ 否□ 是□ 否□ 产品人员 2.2 测试提交文档

[下面应当列出在测试阶段结束后，所有可提交的文档] 测试方案及计划 测试用例 测试报告 3

测试进度

表 2

测试活动 制定测试方案及计划 评审测试方案及计划 设计测试用例 测试用例评审 功能测试 性能测试 回归测试 计划开始日期 计划结束时间 实际开始日期 结束日期 对测试进行评估 4

测试资源

4.1 人力资源

下表列出了在此项目的人员配备方面所作的各种假定。

[注：可适当地删除或添加角色项。] 表 3 角色 （人数） 测试负责人（1人） 职责 备注 判断待测试产品是否进入系统测试计划、测试报告文档需经过可测试状态； 评审，评审后的文档入PVCS库 书写系统测试方案计划； 跟踪测试计划执行进度、质量； 协调测试资源； 第 4 页共 页

Xxxxx产品测试方案

书写测试报告； 测试人员（1-2人） 搭建测试环境； 书写测试用例； 执行测试、做好测试记录； 进行缺陷跟踪； 回归测试； 总结个人测试报告； 产品负责人 提供需求文档、需求跟踪矩阵、需求变更等； 对测试人员进行产品业务的培训； 根据需求编制产品业务测试用例提供给测试人员做参考 测试用例入PVCS库； 错误入错误跟踪库； 个人测试报告以Email方式提交测试负责人； 需求文档需是评审通过的正式文档 研发负责人（1人） 提供并跟踪研发计划； 研发制度中需要定义错误修改机制及提供设计文档（含单元测时间限制 试计划和测试用例）； 根据产品状态制定研发制度； 按时提交可测程序给配置管理员（包括静态表）； 协助配置管理员编译程序 协调相关研发资源； 研发人员（2-3人） 进行单元测试； 在规定时间内修改错误； 对测试人员提出的需求和设计文档中未尽事宜给予必要的支持； 配置管理负责人（1人） 评审团负责人 即时编译程序提供测试； 做好基线管理； 协调相关配置管理资源； 根据公司制定的产品过程计划中评审日期按时参与评审； 提供评审意见； 4.2 测试环境

公司测试组网图： 现场测试组网图：（可选）

下表列出了测试的系统环境

表 4

软件环境（相关软件、操作系统、版本号等） 第 5 页共 页

Xxxxx产品测试方案

硬件环境（网络、设备等） 4.3 测试工具

此项目将列出测试使用的工具：

例：本次测试并无新开发的测试工具，主要使用的测试工具有以下2种： 1. SQL Explorer：BCB自带的工具，可通过数据源连接数据库，对数据库种的表、表结构、表中数据进行直观的查看，并可方便的输入SQL语句并查看查询结果； 2. 错误跟踪系统：根据本公司的实际情况，比较实用的缺陷跟踪系统，可进行简单的缺陷分析和统计功能。

表 5

用途 Bug库 工具 生产厂商/自产 地址：http:// 版本 5

系统风险、优先级

[简要描述测试阶段的风险和处理的优先级] 事项 风险 措施 需求文档和研发设计文档在此a) 加强对配置管理计划的执行， 任务开始时间之前没有到位或b) 与研发和产品人员沟通 按时到位但内容不完整 由于人为原因或外部原因造成a）在测试方案编制后，及时进行评审时的评审时间延迟 间的确定与评审方进行沟通，确定时间 1.调整测试计划和测试用例，并与研发和导致以前测试无效，或对变动的产品人员进行沟通 估计不准确，测试周期延长 2.调整测试重点 测试方案编制 测试方案评审 需求变更 1.调整测试计划和测试用例 导致以前测试无效，或对变动的数据库结构重大调整 2.如果导致测试无法进行，重新审定系统估计不准确，测试周期延长 进入验收测试的标准，决定是否返回研发 1.调整测试计划和测试用例 导致以前测试无效，或对变动的程序结构重大调整 2.如果导致测试无法进行，重新审定系统估计不准确，测试周期延长 进入验收测试的标准，决定是否返回研发 第 6 页共 页

Xxxxx产品测试方案

1.调整测试计划和测试用例 阶段反复次数太多 测试进度受阻，测试周期延长 2.如果导致测试无法进行，重新审定系统进入验收测试的标准，决定是否返回研发 1． 若测试无法正常进行，重新审定系统测试版本不稳定 进入验收测试的标准，决定是否返回测试人员变更 研发； 测试用例中所要求的测试数据2． 对测试人员的近期工作要及时沟通 不完整 3． 测试数据要求，要尽早与产品和研发人员沟通，确定测试数据 Bug修改不及时，延期交付回归1. 研发负责人对bug情况进行及时跟踪 测试版本 编译没有通过，延期提交 1.研发配合配置管理进行，对有编本编译造成的时间延误，需要进行测试时间变更的通报 执行测试 修改bug 版本编译 回归测试 变更后的可执行程序无法及时1. 加强与研发部门的沟通。 获取 2. 对由回归版本延期获得造成的测试时测试用例中所要求的测试数据间延误，需要进行通报。 不完整 测试任务无法根据《测试计划》测试计划发生变更，及时调整配置管理计按时完成 划，修正测试报告出具时间。 测试报告书写 6

测试策略

[测试策略提供了对测试对象进行测试的推荐方法。 对于每种测试，都应提供测试说明，并解释其实施的原因。 制定测试策略时所考虑的主要事项有：将要使用的技术以及判断测试何时完成的标准。 下面列出了在进行每项测试时需考虑的事项，除此之外，测试还只应在安全的环境中使用已知的、有控制的数据库来执行。] 注意：不实施某种测试，则应该用一句话加以说明，并陈述这样的理由。例如，“将不实施该测试。该测试本项目不适用”。

测试原理：

例：本次测试依据监测系统的实现原理；即平台部分程序负责采集和处理数据，并将数据进行分析后入数据库，应用部分程序根据需求呈现各种表现形式，从后台数据库中组合查询并将查询结果以固定的格式显示出来。 测试时根据每个程序运行后sqllog目录下的sqllog.txt中的SQL语句对查询结果的准确性进行测试。 被测试对象需求：  版本要求：每日根据研发负责人提供的最新可编译程序列表编译的最新程序版本；  文档要求：《需求规格说明书》、《详细设计文档》以及相关的协议规范；  接口/协议要求：每个程序执行后退出必须书写log信息；  可测试性要求：可执行程序必须可以保证基本运行，被测程序必须有相关输出。

第 7 页共 页

Xxxxx产品测试方案

测试代码设计：

如：本次产品测试无程序代码要求，有大量sql语句书写要求。SQL语句必须书写到相关的测试用例中。

测试规程设计：

本次测试要求严格按照测试用例执行测试，每个测试点后面都必须输入“测试结果”、每组测试用例下面必须输入“测试人员”和“测试时间”。其中“测试结果”需用：OK、POK、NG或者NT表示。

OK表示测试结果全部正确； POK表示测试结构大部分正确； NG表示测试结果有较大的错误； NT表示由于各种原因本次无法测试 测试用例的执行顺序：建议按照测试用例的模板至上而下的依次执行，先验证公共功能再验证准确性，最后测试性能。

6.1 用户界面测试

[用户界面（UI）测试用于核实用户与软件之间的交互。UI测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。另外，UI测试还可确保UI中的对象按照预期的方式运行，并符合公司或行业的标准。] 测试目标 [核实以下内容： 通过测试进行的浏览可正确反映业务的功能和需求，这种浏览包括窗口与窗口之间、字段与字段之间的浏览，以及各种访问方法（Tab键、鼠标移动、和快捷键）的使用 窗口的对象和特征（例如，菜单、大小、位置、状态、颜色和中心）都符合标准。] 测试范围： 技术： [为每个窗口创建或修改测试，以核实各个应用程序窗口和对象都可正确地进行浏览，并处于正常的对象状态。] 开始标准： 完成/通过标准： [成功地核实出各个窗口都与基准版本保持一致，或符合可接受标准] 测试重点和优先 级： 需考虑的特殊事项： [并不是所有定制或第三方对象的特征都可访问。] 6.2 功能测试

[对测试对象的功能测试应侧重于所有可直接追踪到用例或业务功能和业务规则的测试需求。这种测试的目标是核实数据的接受、处理和检索是否正确，以及业务规则的实施是否 第 8 页共 页

Xxxxx产品测试方案

恰当。此类测试基于黑盒技术，该技术通过图形用户界面（GUI）与应用程序进行交互，并对交互的输出或结果进行分析，以此来核实应用程序及其内部进程。以下为各种应用程序列出了推荐使用的测试概要：] 测试目标 [确保测试的功能正常，其中包括导航，数据输入，处理和检索等功能。] 测试范围： 技术： [利用有效的和无效的数据来执行各个用例、用例流或功能，以核实以下内容： 在使用有效数据时得到预期的结果。 在使用无效数据时显示相应的错误消息或警告消息。 各业务规则都得到了正确的应用。] 开始标准： 完成/通过标准： 测试重点和优先 级： 需考虑的特殊事项： [确定或说明那些将对功能测试的实施和执行造成影响的事项或因素（内部的或外部的）] 6.3 容错测试

[容错测试可确保测试对象能成功完成转移，并能从导致意外数据损失或数据完整性破坏的各种硬件、软件可网络故障中恢复。 故障转移测试可确保：对于必须持续运行的系统，一旦发生故障，备用系统就将不失时机地“顶替”发生故障的系统，以避免丢失任何数据或事务。 恢复测试是一种对抗性的测试过程。在这种测试中，将把应用程序或系统置于极端的条件下（或者是模拟的极端条件下），以产生故障（例如设备输入/输出（I/O）故障或无效的数据库指针和关键字）。然后调用恢复进程并监测和检查应用程序和系统，核实应用程序或系统和数据已得到了正确的恢复。] 测试目标 [确保恢复进程（手工或自动）将数据库、应用程序和系统正确地恢复到预期的已知状态。 测试中将包括以下各种情况： 客户机断电 服务器断电 通过网络服务器产生的通信中断 周期未完成（数据过滤进程被中断，数据同步进程被中断）。 数据库指针或关键字无效 数据库中的数据元素无效或遭到破坏] 测试范围： 技术： [应该使用为功能和业务周期测试创建的测试来创建一系列的事务。一旦达到预期的测试起点，就应该分别执行或模拟以下操作：  客户机断电：关闭PC机的电源。 第 9 页共 页

Xxxxx产品测试方案

 服务器断电：模拟或启动服务器的断电过程。  通过网络服务器产生的中断：模拟或启动网络的通信中断（实际断开通信线路的连接或关闭网络服务器或路由器的电源）。  一旦实现了上述情况（或模拟情况），就应该执行其他事务。而且一旦达到第二个测试点状态，就应调用恢复过程。  在测试不完整的周期时，所使用的技术与上述技术相同，只不过应异常终止或提前终止数据库进程本身。  对以下情况的测试需要达到一个已知的数据库状态。当破坏若干个数据库字段、指针和关键字时，应该以手工方式在数据库中（通过数据库工具）直接进行。其他事务应该通过使用“应用程序功能测试”和“业务周期测试”中的测试来执行，并且应执行完整的周期。] 完成/通过标[在所有上述情况中，应用程序、数据库和系统应该在恢复过程完成时准： 立即返回到一个已知的预期状态。此状态包括仅限于已知损坏的字段、指针或关键字范围内的数据损坏，以及表明进程或事务因中断面未被完成的报表。] 测试重点和优 开始标准： 先级： 需考虑的特殊事项：  [恢复测试会给其他操作带来许多的麻烦。断开缆线连接的方法（模拟断电或通信中断）可能并不可取或不可行。所以，可能会需要采用其他方法，例如诊断性软件工具。  需要系统（或计算机操作）、数据库和网络组中的资源。  这些测试应该在工作时间之外或在一台独立的计算机上运行。] 6.4性能测试

[核实所指定的事务或商业理由在不同的工作量条件下的处理能力等] 测试范围： 技术： [使用为功能或业务周期测试制定的测试。 通过修改数据文件来增加事务数量，或通过修改脚本来增加每项事务发生的次数。] 开始标准： 完成/通过标准： [多个事务或多个用户：在可接受的时间范围内成功地完成测试，没有发生任何故障。] 测试重点和优先 测试目标 级： 需考虑的特殊事[性能测试应该在专用的计算机上或在专用的机时内执行，以便实现 第 10 页共 页

Xxxxx产品测试方案

项： 完全的控制和精确的评测。 性能测试所用的数据库应该是实际大小或相同缩放比例的数据库。]

6.5稳定性测试

测试目标 测试范围： 技术： 开始标准： 完成/通过标准： 测试重点和优先级： 需考虑的特殊事项： [测试软件在长期测试情况下的，系统稳定性情况] [使用为功能或业务周期测试制定的测试。 在系统可正常工作的环境下，进行联系长时间的测试。] [在测试期间，系统能正常完成测试，没有发生任何故障。] [稳定性测试应该在性能测试之后，采用性能测试出的可正常工作的指标，在专用的计算机上或在专用的机时内执行，以便实现完全的控制和精确的评测。 文档行测试所用的数据库应该是实际大小或相同缩放比例的数据库。] 6.6兼容性测试

[兼容性测试的目的是确保该软件可在需求定义中定义的可运行的平台、软件、硬件等环境下正常运行] 测试目标 核实在以下环境下，待测试产品可正常运行：  需求中定义的操作系统；  需求中定义的软件（例如：数据库、此产品以前版本等）；  需求中定义的硬件（例如：机型、板卡等）  需求中定义的操作系统及软件、硬件的组合环境； 测试范围： 技术：  操作系统的安装  第三方软件的安装  待测试产品在以上操作系统及软件、硬件组合的环境下的安装； 开始标准： 完成/通过＜项目名称＞可实现在需求中定义的可运行的平台、软件、硬件等环 第 11 页共 页

Xxxxx产品测试方案

标准： 测试重点和优先级： 需考虑的特殊事项： 境下的正常运行] 把现场大规模使用的机型、操作系统及数据库等第三方产品的组合方式作为测试的重点和最优先考虑的部分 兼容性测试中搭建测试环境所需要的机器以及此工作带来的工作量导致的人员配置问题 6.7安装测试

[安装测试有两个目的。第一个目的是确保该软件在正常情况和异常情况的不同条件下 例如，进行首次安装、升级、完整的或自定义的安装 都能进行安装。异常情况包括磁盘空间不足、缺少目录创建权限等。第二个目的是核实软件在安装后可立即正常运行。这通常是指运行大量为功能测试制定的测试。] 测试目标 核实在以下情况下，测试对象可正确地安装到各种所需的硬件配置中：  首次安装。以前从未安装过＜项目名称＞的新计算机  更新。以前安装过相同版本的＜项目名称＞的计算机  更新。以前安装过＜Project Name>的较早版本的计算机 测试范围： 技术：  [手工开发脚本或开发自动脚本，以验证目标计算机的状况 首次安装＜项目名称＞从未安装过；＜项目名称＞安装过相同或较早的版本。  启动或执行安装。  使用预先确定的功能测试脚本子集来运行事务。] 开始标准： 完成/通过＜项目名称＞事务成功执行，没有出现任何故障。 标准： 测试重点 和优先级： 需考虑的特殊事项： [应该选择＜项目名称＞的哪些事务才能准确地测试出＜项目名称＞应用程序已经成功安装，而且没有遗漏主要的软件构件？。] 7

问题严重度描述

描述 响应时间 确定bug的级别，以及对不同级别的bug，程序员在多长时间内进行修改或回复 问题严重度 高 中 低 例如使系统崩溃 程序功能错误 一般错误，或建议性 程序员在多长时间内改正此问题 第 12 页共 页

第 13 页共页Xxxxx产品测试方案