测试技术方案模板Word文档格式.docx

测试技术方案模板Word文档格式.docx

《测试技术方案模板Word文档格式.docx》由会员分享，可在线阅读，更多相关《测试技术方案模板Word文档格式.docx（16页珍藏版）》请在冰点文库上搜索。

设计针对XX市XX中心业务系统的系统测试—功能测试方案。

通过上述方案用以验证：

●产品功能是否满足需求规定并能够正常运行——功能测试；

●用户界面是否与需求保持一致，保证用户界面的友好性、易操作性——用户界面测试；

●产品性能是否满足需求规定并能够正常运行——性能测试；

1.4目标读者及阅读建议

目标读者

阅读建议

项目经理及评审人员

全文档仔细阅读

测试负责人及测试工程师

开发工程师

仔细阅读“章节2”-“章节4”，其他部分了解性阅读

1.5参考文档

文档

参考内容

作者或来源

使用备注

GBT-8567-2006计算机软件文档编制规范：

软件测试计划（STP）

文档格式

确定文档格式及涉及内容

需求规格说明书

项目组

确定测试需求及策略

大/中日程计划

测试计划

确定测试计划及人员安排

2软件测试环境

2.1测试环境

硬件用途

客户端

硬件

配置信息

数量

软件分类

软件名称

版本

操作系统

浏览器

数据库客户端

服务器

操作系统

WEB中间件

数据库

2.2参与组织

参与方

人员

提供资源

参与工作

参与阶段

参与时间

∙

2.3人员角色

下表列出了在项目内部测试工作过程中的人员配备：

角色

职责

项目经理

∙提供技术指导并获取适当资源

∙负责整个项目中的协调工作

测试负责人

∙编写测试方案、计划

∙项目测试的日常管理工作

∙监控测试工作，规避风险

∙编写系统测试报告等

测试工程师

∙编制和维护测试用例

∙执行测试并记录结果

∙缺陷跟踪

∙对程序缺陷进行修改

∙程序新版本发布

∙必要时参加进行功能测试

2.4测试工具

工具类型

工具名称

用例管理工具

缺陷管理工具

项目管理

3计划

3.1总体计划

该系统测试的策略有功能测试、用户界面测试和性能测试，功能测试要覆盖系统中的每个功能。

在功能测试时既要输入正确的数据，测试功能是否满足，也要对每个功能中的每个数据输入域故意输入错误的数据，测试系统的健壮性。

用户界面测试核实各个窗口风格（包括颜色、字体、提示信息、图标、Title等）都与需求保持一致，或符合可接受标准，保证用户界面的友好性、易操作性，而且符合用户操作习惯。

性能测试往往针对软件的一部分功能，进行专项测试。

执行完一组工作后，及时检查是否已达到预定目标，是否已执行完该过程所有的步骤等，如实际情况与计划出入较大，应及时调整计划。

考虑到各种因素和条件的限制，采用黑盒测试方案，即根据软件所需要的输入数据的格式以及应该完成的功能，设计一些合法的测试用例和不合法的测试用例，特别是根据边界条件设计一些边界测试用例，以检查系统是否能正确地完成预期功能，得到希望的输出；

或者是对不合法的输入和操作能够正确地识别和防御。

3.1.1测试级

执行的测试级别为系统级。

3.1.2测试准备

●测试方案编写完成并邮件告知项目组成员；

●测试组根据需求规格说明书完成测试内容确认和重点交易列表，需项目经理或开发人员确认；

●项目经理安排相关人员完成内部测试环境的配置；

●测试开始前将与开发人员配合将“测试相关信息.xls”文档整理完成，包括测试环境配置、Bugfree用户信息，柜员信息等；

3.1.3测试类别

3.1.3.1功能测试

功能测试侧重于可以被直接追踪利用例或业务功能和业务规则的所有测试需求。

这些测试的目标在于核实能否正确的接受、处理和检索数据以及业务规则是否正确实施。

这种类型的测试基于黑盒方法，即通过图形用户界面（GUI）与应用程序交互并分析输出结果来验证应用程序及其内部进程。

以下列出测试方法概要：

测试范围：

验证数据精确度、数据类型、业务功能等相关方面的正确性

测试目标：

核实所有功能均已正常实现，且与需求一致。

方法：

利用有效的和无效的数据来执行各个用例或功能，以核实以下内容：

∙在使用有效的数据时得到预期结果；

∙在使用无效的数据时显示相应的错误信息或警告；

∙各业务规则都得到了正确的应用；

依据：

测试用例

完成标准：

∙所计划的测试已全部执行

∙所发现的缺陷已全部解决（无1,2级遗留缺陷）

需考虑的特殊事项

3.1.3.2用户界面（UI）测试

用户界面（UI）测试用于核实用户与软件之间的交互。

UI测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。

另外，UI测试还可确保UI中的对象按照预期的方式运行，并符合公司或行业的标准。

1、导航、链接、Cookie、页面结构（包括菜单、背景、颜色）、字体、按钮名称、Title、提示信息的一致性等

2、友好性、可操作性、易用性

核实各个窗口风格（包括颜色、字体、提示信息、图标、Title等）都与需求保持一致，或符合可接受标准，能够保证用户界面的友好性、易操作性，而且符合用户操作习惯。

WEB非功能性通用测试方法，手工测试

UI符合可接受标准，能够保证用户界面的友好性、易操作性，而且符合用户操作习惯

重点测试网上业务平台、政务网站等对外门户的用户界面。

3.1.3.3性能测试

性能测试对响应时间、事务处理速率和其他与时间相关的需求进行评测和评估。

性能测试的目标是核实性能需求是否都已满足。

实施和执行性能测试的目的是将测试对象的性能行为当作条件（例如工作量或硬件配置）的一种函数来进行测试和微调。

多用户长时间在线操作时性能方面的测试

核实系统在大流量的数据与多用户操作时软件性能的稳定性，不造成系统崩溃或相关的异常现象。

使用loadrunner工具进行测试

系统满足用户需求中所要求的性能要求

3.2计划执行的测试

3.2.1测试范围

序号

分类

核心

用例来源

用例编写人员

测试策略

功能测试、用户界面测试、性能测试

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

注：

具体各核心内容下的交易见“交易测试情况一览表”，此处不逐一列出。

3.2.2测试重点

测试重点主要从以下几个方面考虑，针对测试重点，在用例的编写与评审、人员安排、测试轮次、Bug解决要求等方面都应高于其他部分。

●需求中，优先级高的重点功能或用户的常用功能；

●开发过程中，重点关注的模块、功能及特性（此项通过交易的代码修改量等内容确定，由项目经理提供）；

●相关领导的关注点和意见；

●开发人员的能力和水平差异；

●以往版本或其他项目中的常见问题；

此项内容由项目经理配合进行确认，具体交易列表及重点测试交易，见“交易测试情况一览表”，此处不逐一列出。

3.2.3测试入口准则

●在提交测试组进行系统测试前，开发工程师需要经过自测试以及开发组组内互测；

●测试组接收测试，且通过冒烟测试后，方可进行系统测试。

3.2.4测试通过标准

●系统无业务逻辑错误和二级缺陷，经确定的所有缺陷都已得到商定的解决结果；

●设计的测试用例全部执行完成，由于其他因素导致未能执行的用例有相应记录；

●2.1节中规定的所有功能点，测试覆盖率=100%，有效Bug的关闭率>

=90%；

●满足联合测试和第三方测评要求。

3.3测试用例

1测试用例分类

●测试用例与测试类型对应：

功能测试用例、用户界面测试用例及性能测试用例

●重点用例通过用例中的用例级别进行标记：

A-关键业务正常流测试

B-功能点详细测试

C-交互测试：

主要测试界面、易用性等内容

D-异常测试

2测试用例评审

●组内评审：

测试组内部采用交叉评审方式，对已做成测试用例进行评审；

●组外评审：

开发组的相关人员（由项目经理或部门经理指定），对测试一览表中重点交易的用例进行评审；

4测试实施

4.1轮次执行

轮次

内容

第一轮

1、

第二轮

第三轮

1.

其他注意事项：

1测试工程师根据测试用例进行测试，并将测试中发现的Bug，记录到Bugfree中；

2开发工程师对Bug进行修改，并说明Bug产生的原因及产生阶段；

3如果对需要修改的Bug意见不统一，则由项目经理确认修改意见；

4第二轮系统测试开始，测试工程师首先对第一轮测试中遗留的问题进行回归验证，即验证上一轮发现的Bug是否已经全部得到解决。

回归测试完成后，测试工程师再根据测试用例，开展新的系统测试工作；

5第三轮系测试，结合核心系统进行测试，同时加强对业务系统中重点交易的测试。

4.2测试计划

项目

里程碑

任务

开始时间

结束时间

输出物

执行人员

制定测试方案

编写测试方案

设计测试

测试用例编写

测试用例评审

测试用例评审记录表

执行测试

内部测试第一轮

缺陷记录、轮次测试报告

内部测试第二轮

内部测试第三轮

评估测试

测试总结

内部测试报告

轮次测试的具体内容会根据各子系统开发进度做适当调整。

4.3缺陷管理

参见《03Bugfree填写规范V1.0.4.doc》。

5测试评价

系统测试完毕，提供以下度量指标结果用以评估项目质量并输出测试报告：

度量指标名称

定义/计算公式

指标目的

数据主要来源

测试功能点总数（个）

测试功能点总数＝各级测试功能点数之和；

统计测试规模

“附件1：

交易测试情况一览表.xls”

功能点测试生产率（个/人月）

功能点测试生产率=测试功能点总数/测试组实际总工作量；

衡量测试组的生产率

系统功能测试轮次（轮）

指测试组实际进行的系统功能测试轮数；

预估类似项目的平均测试轮数

Bugfree

测试覆盖率（100%）

功能点测试覆盖率=测试功能点总数/功能点总数；

衡量测试的覆盖程度

功能点测试通过率（100%）

完全通过功能点数/测试功能点总数

由此指标，可衡量代码开发的质量。

Bug关闭率（100%）

Bug总关闭率=已关闭Bug总数/有效Bug总数*100%

1、衡量开发人员对Bug的解决程度；

2、判断产品交付时的遗留Bug数

BugFree

测试密度（个/功能）

测试密度=实际测试用例数/功能点总数

衡量测试用例颗粒度是否适当

Bug密度1（个/功能）

Bug密度1=实际Bug数/功能点总数

衡量bug产出是否在合理范围内

Bug密度2（个/功能）

Bug密度2=实际Bug数/代码变动数

衡量代码变动产生的bug数是合理

6风险预估和应对

下表列出了在项目测试工作中存在的各种风险的假定，需要考虑项目测试过程中可能发生的具体事务，分别分析并加以应对，然后体现到测试计划中。

风险类型

风险责任方

风险内容

处理优先级

应对措施

时间计划

人员风险

资源协调

插入事务

任务超预期

各个风险类型解释如下：

Ø

时间计划：

关键MileStone无法匹配的延期风险；

人员风险：

测试人员和需配合方的人员的变动导致的工作任务无法按计划完成或者完成质量无法保证的风险，包括新人风险、人员变化、投入不足、投入质量不高等；

资源协调：

包括所需资源不能如期到位，或者资源质量低于预期等风险。

比如测试工具开发的风险、各个阶段交付物的质量风险等；

插入事务：

包括临时插入高优先级的事务，打乱原有计划等风险；

任务超预期：

实际执行时的工作复杂程度、结果的质量同预期不符所带来的风险。

属于不可预期的风险，只能待出现时及时合理地调整。

风险分为可预期的和不可预期的，对于可预期的风险，可以要求资源，制定提前的应对措施。

但是对于不可预期的风险，只能待出现时，充分考虑各方因素，及时调整。

所以，对于可预期的风险，需要的能力是充分预估，对于不可预期的风险，需要的是及时察觉并调整应对。

7测试输出物

1内部测试方案

2测试用例

3测试报告

●轮次测试报告

●内部测试报告

●测试总结——邮件发送

●附件1：

交易测试情况一览表

●附件2：

交易品质分析数据

4缺陷列表