最新产品测试方案.docx

最新产品测试方案.docx

《最新产品测试方案.docx》由会员分享，可在线阅读，更多相关《最新产品测试方案.docx（20页珍藏版）》请在冰豆网上搜索。

最新产品测试方案

加拿大ｂｅａｄｗｏｒｋｓ公司就是根据年轻女性要充分展现自己个性的需求，将世界各地的珠类饰品汇集于“碧芝自制饰品店”内，由消费者自选、自组、自制，这样就能在每个消费者亲手制作、充分发挥她们的艺术想像力的基础上，创作出作品，达到展现个性的效果

据上述部分的分析可见，我校学生就达4000多人。

附近还有两所学校，和一些居民楼。

随着生活水平的逐渐提高，家长给孩子的零用钱也越来越多，人们对美的要求也越来越高，特别是大学生。

他们总希望自己的无论是衣服还是首饰都希望与众不同，能穿出自己的个性。

但在我们美丽的校园里缺少自己的个性和琳琅满目的饰品，所以我们的小饰品店存在的竞争力主要是南桥或是市区的。

这给我们小组的创业项目提供了一个很好的市场机会。

我们熟练的掌握计算机应用，我们可以在网上搜索一些流行因素，还可以把自己小店里的商品拿到网上去卖，为我们小店提供了多种经营方式。

调研课题：

我们从小学、中学到大学，学的知识总是限制在一定范围内，缺乏在商业统计、会计，理财税收等方面的知识；也无法把自己的创意准确而清晰地表达出来，缺少个性化的信息传递。

对目标市场和竞争对手情况缺乏了解，分析时采用的数据经不起推敲，没有说服力等。

这些都反映出我们大学生创业知识的缺乏；

在我们学校大约有4000多名学生，其中女生约占90%以上。

按每十人一件饰品计算，大概需要360多件。

这对于开设饰品市场是很有利的。

女生成为消费人群的主体。

4．WWW。

google。

com。

cn。

大学生政策2004年3月23日

据了解，百分之八十的饰品店都推出“DIY饰品”来吸引顾客，一方面顺应了年轻一代喜欢与众不同、标新立异的心理；另一方面，自制饰品价格相对较低，可以随时更新换代，也满足了年轻人“喜新厌旧”的需要，因而很受欢迎。

营销环境信息收集索引

300元以下□300～400元□400～500□500元以上□XXXXX产品v1.0.0测试方案

文档版本控制

文档版本号

日期

作者

审核人

说明

V1.0

1项目简介部分

1.1文档编写目的

＜项目名称＞的这一“测试方案”文档有助于实现以下目标：

[确定现有项目的信息和应测试的软件构件。

列出推荐的测试需求（高级需求）。

推荐可采用的测试策略，并对这些策略加以说明。

确定所需的资源，并对测试的工作量进行估计。

预估项目的风险和成本，对制定应对措施。

列出测试项目的可交付元素]

1.2测试项目背景描述

[对测试对象（应用程序、模块、子模块、系统等）及其开发设计目标进行简要说明。

需要包括的信息有：

主要的功能和性能、测试对象的构架以及项目的简史、测试对象的设计开发初衷和目标。

]

1.3测试工作内容和范围

[简要描述测试所需的阶段（例如，评审、测试设计、单元测试、冒烟测试、手工测试、回归测试、自动化测试、性能测试、交叉自由测试等）。

简要地列出测试对象中将接受测试或将不接受测试的那些性能和功能。

如果在编写此文档的过程中做出的某些假设可能会影响测试设计、开发或实施，则列出所有这些假设。

列出可能会影响测试设计、开发或实施的所有风险或意外事件。

列出可能会影响测试设计、开发或实施的所有约束。

]

2测试文档[可裁减]

2.1测试所需参考文档

下表列出了制定和实施该测试方案时所需要使用的相关文档，并标明了各文档的可用性：

[注：

列表中为文档项，需要具化，可适当地删除或添加文档项。

]

文档[具体的文档名称和列表（版本/日期）]

已创建或可用

已被接收或已经过复审

作者或来源[角色和姓名]

备注

软件产品背景相关资料[业务简介、名词解释、操作说明、系统资料、访问环境等]

是□否□

是　否□

PM/RD

软件产品调研相关资料[前期调研资料等]

是□否□

是　否□

PM/RD

MRD

是□否□

是□否□

PM/RD

概要设计

是□否□

是□否□

RD

详细设计

是□否□

是□否□

RD

产品性能要求

是□否□

是□否□

PM/RD

产品常规检查checklist

是□否□

是□否□

PM/RD

产品升级检查checklist

是□否□

是□否□

PM/RD

运维部署文档

是□否□

是□否□

RD/OP

上线步骤

是□否□

是□否□

RD/OP

单元测试设计（单元测试报告）

是□否□

是□否□

RD

代码行diff分析

是□否□

是□否□

RD

产品总测试方案（性能）

是□否□

是□否□

QA

产品测试框架

是□否□

是□否□

QA

产品testcase

是□否□

是□否□

QA

相关流程文档和模板

是□否□

是□否□

QA/PM/RD

相关工作指南和规范（checklist）

是□否□

是□否□

QA

测试工具参考文档

是□否□

是□否□

QA

测试陷阱tips、经验总结文档、casestudy文档、项目成长记录等参考资料

是□否□

是□否□

QA

2.2测试需提交文档

下表列出了制定和实施该测试方案时测试所需要提交的相关文档，并标明了各文档的可用性：

[注：

列表中为文档项，需要具化，可适当地删除或添加文档项。

]

文档[具体的文档名称和列表（版本/日期）]

已创建或可用

已被接收或已经过复审

作者或来源[角色和姓名]

备注

MRD、详细设计等评审批注意见

是□否□

是　否□

QA

单元测试设计（单元测试报告）

是□否□

是□否□

QA

测试方案（性能）

是□否□

是□否□

QA

测试计划

是□否□

是□否□

QA

测试开发需求货设计（关键字、工具等）

是□否□

是□否□

QA

测试设计

是□否□

是□否□

QA

测试报告（功能、性能、自动化）

是□否□

是□否□

QA

项目总结

是□否□

是□否□

QA

缺陷分析和测试设计补充

是□否□

是□否□

QA

项目投入和时间数据

是□否□

是□否□

QA

测试陷阱tips

是□否□

是□否□

QA

casestudy文档

是□否□

是□否□

QA

项目成长记录

是□否□

是□否□

QA

3测试安排和计划

3.1测试难点和重点[可裁减]

[注本小节描述项目测试中预计的测试重点和测试难点，撰写者可根据需要对下列的表格进行修改]

3.1.1测试重点[可裁减]

编号

重点项

重要性说明

备注

1

多用户并发读写操作

作为一个分布式系统，并发读写实必须要支持的关键功能；另外这部分功能只要正确，顺序读写正确性一定能保证

由于需要考虑自动化工具支持。

2

异常测试

作为一个基础平台项目，系统要能够容忍各种软硬件异常。

可以参照之前整理的分布式异常体系进行异常模拟

3

Xxxx

Xxxx

3.1.2测试难点[可裁减]

编号

难点项

困难性说明

备注

1

相关数据并发读写的正确性验证

由于存在执行不确定性，无法事先获得期望的结果；另外这种不确定性也导致了bug难以复现

可以考虑利用系统的checkpoint功能进行功能回放。

2

Xxxx

3.2项目整体计划

项目阶段

时间段

参与人员

测试工作内容安排

产出

备注

调研阶段

参与调研讨论

需求评审阶段

1.了解项目背景资料

2.阅读mrd

3.反馈评审问题

4.参与需求评审

5.确认评审结论

6.初步评估测试计划

Ø评审批注反馈

Ø初步测试计划

详细设计阶段

1.分析产品功能，确认测试需求

2.进行测试点拆分

3.反馈评审问题

4.参与设计评审

5.确认设计评审结论

6.确定测试初步方案

Ø评审批注反馈

Ø测试框架

Ø功能点拆分文档

Ø测试点拆分文档

Ø初步测试方案

Ø测试计划调整

RD开发阶段

1.确定测试方案

2.确定自动化测试点

3.撰写测试case和相关关键字

4.准备测试数据

5.自动生成自动化case

6.FE提交页面后获取页面对象

7.开发测试工具

8.测试方案和测试设计评审

Ø关键字列表

ØCase书写规范

Ø测试case文档

Ø自动化case

Ø测试工具和程序

准入测试阶段

1.环境部署

2.准入测试

3.完善自动化case

Ø测试环境

Ø准入测试结论

Ø部分自动化case及执行结果

第一遍全面测试

1.执行手工测试

2.执行自动化case

3.性能测试

4.完善自动化case

Ø手工测试结论

Ø部分关键字

Ø完善或新补充的自动化case

Ø性能测试结果

Ø自动化case结果

Bug回归测试

1.确认bug修复情况

2.执行自动化case

3.完善自动化case

4.性能测试

ØBug确认结论

Ø部分关键字

Ø完善或新补充的自动化case

Ø自动化case结果

Ø性能测试结果

全面回归测试

1.执行手工回归测试

2.执行自动化casee

3.性能测试

Ø测试结论和测试报告

交叉自由测试

1.PM、RD、QA交叉自由测试

2.常规检查自动化case执行

Ø测试结论和测试报告

上线阶段

1.上线辅助

2.线上检查

3.Bug回灌

ØBug回灌

项目总结阶段

1.相关总结；

2.Case和框架合并；

3.自动化case管理

详细测试计划请参加《xx项目v0.0.0_测试计划》文档

3.3测试资源安排

3.3.1人力资源分工

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

[注：

可适当地删除或添加角色和人员项。

]

角色

人员

所推荐的投入

主要职责或注释[需要具化]

项目负责人

80%—100%

Ø处理插入事务

Ø协调项目安排

Ø分析测试需求

Ø制定测试方案和测试计划

Ø负责管理文档资料、case、程序、工具

Ø测试全程参与

测试工程师

50%—100%

Ø测试全程参与

Ø分析测试需求

Ø撰写测试case（即自动化case）

Ø提出关键字和自动化工具需求

Ø完善补充自动化case并执行测试

Ø测试分析和测试报告

辅助测试开发工程师

10%—30%

Ø参与测试工作

Ø辅助关键字、工具开发、执行问题修复

Ø辅助自动化框架制定和实施

3.3.2测试环境安排和使用

[网络硬件，如拓扑图、硬件设备、规格、数量、配置等信息；

网络软件，如协议、通讯和连接方式等信息。

]

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

硬件环境（服务器、网络、虚拟机等需求）

软件环境（相关操作系统、软件及环境配置等）

3.3.3所需的合作方配合

配合方

配合人员

希望提供的资源

希望的配合工作

配合阶段

配合时间

备注

PM

Ø人员

Ø资源协调和推动

Ø交叉自由测试安排

全程

RD/FE

Ø利于测试的程序、页面及其部署安装文档

Ø分阶段提供被测程序

Ø在开发周期的后20%前提供页面

测试设计和测试执行

XX产品QA

ØXx服务器的xx服务、xx数据

Ø人员

Ø联调环境准备；

Ø联调资源提供

Ø联调问题辅助定位

测试执行（联调测试）

3.3.4测试所需工具

下表列出了在此项目的使用工具方面所作的各种假定。

[注：

可适当地删除或添加工具项。

]

工具

获取和访问地址

用途

支持人员

使用阶段

使用时间

备注

Case管理工具

[url]

Ø导出case框架和可复用case

测试准备

Word

-

Ø撰写方案、case

测试准备

Project

-

Ø撰写测试计划

测试准备

Git/cvs

[环境]

Ø代码、文档、工具管理

测试准备

测试执行

测试总结

Atp

[url]

Ø测试报告

Ø测试数据

测试执行

Opensta

[环境]

Ø性能压力测试

性能测试

Myab

[环境]

Ø性能压力测试

性能测试

4风险预估和应对[可裁减]

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

[注：

可适当地删除或添加风险项。

]

风险类型

风险责任方

风险内容

相应处理优先级

可能发生的阶段

可能发生的时间段

应对所需资源

应对措施[只是建议，需要具化]

备注

时间计划

Ø合理计划

Ø及时调整

人员风险

Ø充分估计

Ø预留buffer

Ø及时调整

资源协调

Ø充分估计

Ø预留buffer

Ø及时调整

插入事务

Ø预留buffer

Ø及时调整

任务超预期

Ø及时调整

……

[注：

各个风险类型解释如下。

时间计划：

关键milestone无法匹配的延期风险。

诸如项目存在deadline、计划受到客观条件限制、非己方责任导致地被动延期等等；

人员风险：

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

资源协调：

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

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

插入事务：

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

任务超预期：

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

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

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

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

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

]

5准入测试方案[可裁减]

[本节可根据是否做准入测试进行裁减]

说明准入测试中各测试内容的LIST和预期结果，其它内容可选

]

分类

测试内容（可分级描述）

输入（可选）

操作步骤（可选）

预期结果

辅助工具（可选）

环境搭建

依据上线步骤成功搭建测试环境

环境搭建成功

功能测试

测试数据加载成功

准备线上词表

加载成功、日志记录准确

***脚本

6功能测试方案

6.1Case开发和管理的规范

[描述case的模板以及管理方式]

6.2测试需求分析和策略制定

6.2.1分功能测试需求分析

[

根据测试框架中的各个部分，进行测试需求分析，确定测试内容和测试方法。

]

6.2.1.1XX功能模块

1.主要功能描述

[

根据需求和设计，将该部分的功能做简要描述。

]

2.测试点分析

测试点

所需回归的相关测试点

测试方法类型

测试方法详述

A[依据该功能分析可以测试的点]

[依据测试框架所选择的复用case的测试点列表]

手工测试

自动化测试

自动化辅助测试

新旧版本对比测试

[描述依据测试类型而选择的测试策略，包括需要准备的数据，需要使用的辅助工具，需要使用的自动化方法，以及需要抽象的关键字等等]

[注：

各个测试方法类型解释如下。

手工测试：

采用人工操作，并人工观察确认测试结果的测试方法。

如无特别的创新方法，诸如数据准备和场景描述策略等，此方法可以一笔带过。

自动化测试：

使用提前准备好的自动化case完全无人工干预的测试。

该方法如果需要特别的工具、关键字开发，需要注明。

自动化辅助测试：

使用工具，将测试的部分过程，比如结果保存（抓图）、数据上传、结果验证等用程序自动化实现，但是部分过程还需要人工验证的测试。

该方法可以提高部分效率，但是或许需要人工去分析严重结果。

新旧版本对比测试：

在版本升级测试中，如果有两套环境，可以通过同样的输入和操作来对比验证结果的方式来进行测试和自动化测试，自动化测试可以使用coco2.0工具，常用与规避数据计算逻辑复杂的结果对比测试。

]

6.2.2测试工具需求

[

测试工具需求的列表，可以单独文档进行描述

]

7性能测试方案[可裁减]

[本节可根据是否做性能测试进行裁减]

7.1性能测试工具需求

[

测试工具需求的列表，可以单独文档进行描述

]

7.2场景名xxx1

7.2.1场景概述

[

此处概要说明此场景对应的业务流程，如果多个场景业务流程一致，只是数据方面的差异，可将场景概述提前在所有场景前进行统一描述。

例如：

用户登录系统->进入系统->退出系统

]

7.2.2执行策略设计

[

此处描述对于这一场景的执行策略，如并发用户数量、重复次数、性能测试执行时间等内容，同时说明性能测试过程中重点监控的性能指标。

为便于说明，可采用如下表格的形式，例如：

]

性能场景

执行策略（并发数、时长）

备注

登录系统，进入考场

10用户并发，登录系统，进入系统，重复操作15分钟，退出。

●得到不同并发数下系统的性能指标

●对系统的容量做出估计

●列出测试的数据指标项有哪些，值在什么区间内

20用户并发，登录系统，进入系统，重复操作15分钟，退出。

40用户并发，登录系统，进入系统，退出。

重复操作15分钟

7.2.3测试数据需求

[

测试数据准备需求说明

]

7.2.4性能测试结果分析方法和预期

[

性能测试结果分析方法和预期的整体目标

]

7.3压力测试场景设计

[

说明压力测试目的

]

7.3.1场景名XXX

[

同性能测试场景设计

]