测试计划模板

引言

编写目的

编号	确定项目	描述
1	确定测试范围	确定被测项目中功能模块，子功能模块等需要测试的范围。
2	确定测试需求	确定每个功能结果定义，确定此功能是否存在缺陷。
3	确定测试策略	确定对项目做哪些测试。如：功能测试，性能测试等。
4	确定测试方法	确定对每个策略是用哪些方法。如：边界值，等价类等。
5	确定测试工具	如: 功能测试使用Seleium，性能测试使用Jmeter等。
6	确定测试资源	测试需要的设备，服务器、参与测试的人员、测试任务的分工，测试工作的进度。
7	确定测试交付文档	确定测试工作中生成哪些文档，可提交文档有哪些。

测试项目

项目名称： 某某系统
使用背景： // 用户 协会分会负责人、期刊客户
开发者： 中文集团 测试版本 2.0
项目简介：
        学术专著出版平台” 定位是一家图书产品联合创建、销售、返利的平台；平台联合各专业协会、学会、出版社等机构，组织大批专家人才建立“专家指导委员会”，为图书进行策划、上报、审校、出版、运营等服务；主要业务情景是：策划人寻求参编人，共同创建图书及销售，参编人支付参编图书的预购款，该笔资金作为公司运营图书的成本，等待图书出版后，让消费者以个人名片或链接的形式进行购买图书，参编人员不仅可以通过图书评职称、扩大知名度、传播学术价值，另外让参编人通过销售，实现“0”元出书并且获得额外收入；策划人在发展参编和策划人同时，获得相应奖励。

测试目的

编号	目的
1	软件测试是为了发现错误而执行程序的过程。
2	测试是为了证明程序有错，而不是证明程序无错。
3	一个好的测试用例在于它发现至今未发现的错误。
4	一个成功的测试是发现了至今未发现的错误的测试。

文档受众

编号	人员	原因
1	产品设计人员	明确说明测试范围，方法，工作周期信息。
2	产品研发人员	明确说明测试范围，方法，工作周期信息。
3	产品测试人员	明确说明测试范围，方法，任务分工，预计完成时间。
4	备注	此为内部开发文档，不做外部参考。

测试参考文档

编号	文档名称	作用
1	需求文档	确定项目功能模块，功能运行结果。
2	技术文档	确定项目中使用开发语言，数据库数据限制。
3	项目模型文档	初步了解项目页面内容，方便编写用例。

测试提交文档

编号	文档名称	作用
1	测试计划	明确说明测试范围，方法，工作周期信息。
2	测试用例	明确说明测试工作的细节测试工作。
3	缺陷报告	明确说明项目中的缺陷描述，与修复情况。
4	测试报告	明确说明测试结果，测试模块，缺陷分布情况等等信息。

术语定义

项目术语

缩写、术语	解释

测试专业术语

	软件测试类型
单元测试	开发者编写的一小段代码，检验被测代码的一个很小的、很明确的功能是否正确。
集成测试	开发者编写的多个段代码单元，组合到一起形成集成测试，检查多个单元组合功能是否正确。
冒烟测试	针对产品的基本功能进行测试。
功能测试	又称正确性测试，它检查软件的功能是否符合规格说明。
可靠性测试	对服务器施加一定压力，测试服务器是否可以长期稳定运行。
压力测试	对服务器施加一定压力后进行功能测试，测试服务器在一定压力下是够可以正常计算。
负载测试	对服务器施加压力，测试服务器可以容纳多少人访问，多少人访问后出现BUG。
易用性测试	主要从使用的合理性和方便性等角度对软件系统进行检查。用户来测.主观。
兼容测试	测试Web页面是否支持所有浏览器，访问后页面所有功能无异常。
安全测试	服务器数据安全性，用户数据安全性，用户操作安全性，用户财产安全性、公司财产安全性。
数据完整性测试	对数据及数据库能否正常运行访问的测试。
回归测试	开发修改后的BUG在测试一遍。

缺陷优先级

	缺陷的优先级
P0	严重级别比较高的，影响测试进行或者系统无法继续操作，立即修复，1天。
P1	基本功能没有实现，对系统操作有影响，2－3天。
P2	一般性功能，页面缺陷，4－5天。
P3	准备在下一轮测试前修改完毕，准备在下一版本中修改。

严重程度定义

	缺陷的严重程度
S0	数据丢失，数据计算错误、数据传递错误、对数据库造成破坏，造成操作系统或其他支撑系统崩溃、非正常关闭和非正常死机。
S1	应用系统崩溃、非正常关闭和无响应，但没有造成数据丢失。系统的主要功能不能正确实现或不完整。
S2	规定的非主要功能没有实现或不完整、影响系统的运行；设计不合理造成性能低下。
S3	不影响业务运行的功能问题。
S4	软件设计和功能实现等不完全合理之处提出建议。

用例优先级定义

	用例优先级
P0	确保系统基本功能及主要功能的测试用例
P1	确保系统功能的完善方面的测试用例
P2	关于用户体验，输入输出的验证；较少使用或辅助功能的测试用例。

测试策略

单元测试

	单元测试
测试目标	开发者编写的一小段代码，检验被测代码的一个很小的、很明确的功能是否正确。
测试范围	测试整个项目中的每一行代码进行测试。
完成标准	代码的一个很小的、很明确的功能都正确。
需考虑的特殊事项	//
使用工具	Java + TestNG + eclipse + 程序相关依赖Jar 包。

集成测试

	集成测试
测试目标	开发者编写的多个段代码单元，组合到一起形成集成测试，检查多个单元组合功能是否正确。
测试范围	开发者编写的多个段代码单元，组合到一起形成的集合。
完成标准	多个单元组合功能正确。
需考虑的特殊事项	//
使用工具	java + TestNG + eclipse + 程序相关依赖Jar 包。

冒烟测试

	冒烟测试
测试目标	版本是否值得系统测试。
测试范围	1、返测上一版本提交的测试报告。 2、测试系统的基本功能。
完成标准	基本功能通过，并继续测试。
需考虑的特殊事项	此阶段不超过1天。

功能测试

	功能测试
测试目标	确保测试计划中所列出的测试范围，保证其功能正常。
测试范围	1、按照测试计划所规定的测试范围。 2、利用有效的和无效的数据来执行各个用例、用例流或功能 3、以核实以下内容： 1）在使用有效数据时得到预期的结果。 2）在使用无效数据时显示相应的错误消息或警告消息。
完成标准	按照测试计划的测试通过标准，完成测试。
需考虑的特殊事项	确定或说明那些将对功能测试的实施和执行造成影响的事项或因素。（内部的或外部的）
使用工具	Seleium + python + 火狐

易用性测试

	易用性测试
测试目标	模拟真实用户，无经验用户，测试系统的易用性。
测试范围	前台
完成标准	成功地核实出前台各个网页符合可接受易用性标准。
需考虑的特殊事项	无

兼容测试

	兼容测试
测试目标	测试Web页面是否支持所有浏览器，访问后页面所有功能无异常。
测试范围	前台页面
完成标准	使用多个不同浏览器访问后界面无异常即为通过。
需考虑的特殊事项	浏览器版本；浏览器类型是否都测到。

可靠性测试

	可靠性测试
测试目标	使用LR模拟真实用户对服务器施加一定压力。
测试范围	项目服务器。
完成标准	持续运行特定时间不出现问题。
需考虑的特殊事项	测试机是否满足需求。

压力测试

	压力测试
测试目标	使用LR模拟真实用户对服务器施加压力。
测试范围	项目服务器。
完成标准	直到服务器卡死。获得服务器资源，最大与链接数等数据。
需考虑的特殊事项	测试机是否满足需求。
使用工具	Jmeter + fiddler + 火狐

负载测试

	负载测试
测试目标	使用LR模拟真实用户对服务器施加一定压力，对服务器进行主要功能测试。
测试范围	项目服务器&前台界面。
完成标准	对服务器施加一定压力后前台功能正常，访问时间3-8之内。
需考虑的特殊事项	测试机是否满足需求。
使用工具	Jmeter + fiddler + 火狐

数据完整性测试

	数据和数据库完整性测试
测试目标	确保数据库设计完整性。
测试范围	数据库及表结构。
完成标准	数据库约束、完整性等设置达到需求标准。
需考虑的特殊事项	数据遭到破坏，易恢复性。

回归测试

	回归测试
测试目标	确保BUG修复的完整性。
测试范围	项目中出BUG 的部分。
完成标准	项目中出现的BUG完成修复，并将缺陷保存下来。
需考虑的特殊事项	出BUG的功能和BUG相关的功能都需要回测。

功能测试范围

模块	功能	应用策略	备注

测试规则

进入准则

编号	测试策略	进入准则
1	单元测试	项目编码阶段，开发人员每编写完一个单元时进入测试。
2	集成测试	项目编码阶段，开发人员每编写完多个单元时进入测试。
3	功能测试	项目系统测试阶段，开发人员根据需求开发完成时，进入测试。
4	易用测试	功能测试完成后进入测试。
5	兼容测试
6	可靠测试	功能测试完成后进入测试。
7	压力测试
8	负载测试
9	数据完整性	性能测试完成后进入测试。
10	回归测试	提交的缺陷报告修改后。

暂停/退出准则

编号	暂停标准
1	软件系统在进行单元、集成、确认、系统、安装、验收测试时，发现缺陷达到一定数量或出现重大错误导致无法测试时，暂停测试返回开发。
2	发生其他未知因素需要暂停时，测试应随之暂停，并备份暂停点数据。

退出标准
1|软件系统通过验收测试，并已得出验收测试结论，退出测试。

测试资源

硬件资源

编号	CPU	内存	硬盘	系统	软件
1	2.5	4+	100+	Win7	Jmeter，seleium，AppScan

人力资源

编号	角色	人员	具体职责
1	确认需求		明确需求
2	定制测试计划		决定测试策略，人员分工，测试周期等。
3	准备测试环境		测试工作开始前准备工作。
4	执行测试工作		编写用例，执行用例，提交缺陷报告，回测等。
5	编写测试报告		编写项目的测试结果。

测试工作进度

编号	任务	范围	人员	时间
1	确认需求			2019-12-10 - 2019-12-15 = 5 天
2	定制测试计划
3	准备测试环境
4	单元测试
5	集成测试
6	冒烟测试 功能测试 兼容测试 易用性测试
7	可靠性测试 压力测试 负载测试
8	安全测试
9	数据完整性测试
10	回归测试
11	编写测试报告

系统风险

系统风险

1. 计划的测试时间，不能满足测试组的要求，主要是功能冻结后的系统测试的时间可能不够。
2. 测试资源的及时到位（设备和人员）。
3. 需求不明确可能导致开发的产品与目标不一致。
4. 测试人员对测试工具的使用熟悉程序不够；
5. 被测试产品存在重大错误，以至于测试无法继续，需要开发组进行额外的调试和修改才能继续；
6. 硬件、软件或网络环境出现故障等。

应急措施

1. 如果上述潜在的可能事件发生，则通过适当加班来保证计划的按时完成。
2. 如果是由于被测试产品存在重大错误而严重影响测试进度，则考虑按照测试暂停标准来暂停该测试。
3. 如遇到功能需求不明确，需要沟通协商解决。
4. 人员不足，则加班、或者进行不同组人员调动，按照测试进度完成测试任务。
   测试的完成标准

单元测试完成标准

• 按照单元测试计划完成了所有规定单元的测试
• 达到了测试计划中关于单元测试所规定的覆盖率的要求
• 软件单元功能与设计一致
• 在单元测试中发现的错误已经得到修改，各级缺陷修复率达到标准

集成测试完成标准

• 按照集成构件计划及增量集成策略完成了整个系统的集成测试
• 达到了测试计划中关于集成测试所规定的覆盖率的要求
• 被测试的集成工作版本每千行代码必须发现至少2个错误（不含优化级别错误）
• 集成工作版本满足设计定义的各项功能、性能要求
• 在集成测试中发现的错误已经得到修改，各级缺陷修复率达到标准

功能/易用测试完成标准

• 功能测试用例设计已经通过评审
• 按照功能测试计划完成了功能测试
• 达到了功能测试计划中关于功能测试所规定的覆盖率的要求
• 系统达到详细设计定义的各项功能，性能
• 在功能测试中发现的错误已经得到修改，各级缺陷修复率达到标准
• 兼容测试完成标准
• 兼容测试用例设计已经通过评审
• 按照兼容测试计划完成了兼容测试
• 达到了兼容测试计划中关于兼容测试所规定的浏览器的要求
• 在兼容测试中发现的错误已经得到修改，各级缺陷修复率达到标准

系统测试完成标准

• 系统测试用例设计已经通过评审
• 按照系统测试计划完成了系统测试
• 达到了测试计划中关于系统测试所规定的覆盖率的要求
• 被测试的系统每千行代码必须发现至少1个错误（不含五级错误）
• 系统满足需求规格说明书的要求
• 在系统测试中发现的错误已经得到修改，各级缺陷修复率达到标准

验收测试完成标准

• 软件需求分析说明书中定义的所有功能已全部实现，性能指标全部达到要求。
• 在验收测试中发现的错误已经得到修改，各级缺陷修复率达到标准
• 所有测试项没有残余紧急、严重级别错误。
• 需求分析文档、设计文档和编码实现一致。
• 验收测试工件齐全（测试计划、测试用例、测试日志、测试通知单、测试分析）

可靠/压力/负载测试完成标准

• 性能测试用例设计已经通过评审
• 按照性能测试计划完成了性能测试
• 达到了性能测试计划中关于性能测试所规定要求
• 在性能测试中不通过的用例已经得到修改，性能达到预计标准

缺陷修复率标准

• 紧急、严重级别错误修复率应达到100%
• 普通级别错误修复率应达到95%以上
• 优化级别错误修复率应达到60%以上
• 注：项目紧急时，普通级别错误修复率达60%以上；优化级别错误修复率达20%即可。

覆盖率标准

• 测试用例执行覆盖率应达到100%（功能测试用例均以执行）
• 测试需求执行覆盖率应达到100%（业务测试用例均以执行）

本文转载于： https://blog.csdn.net/weixin_43664254/article/details/89239052