软件测试计划_编程技术网-程序员技术内容聚合平台

（在说正事之前，我要推荐一个福利：你还在原价购买阿里云、腾讯云、华为云服务器吗？那太亏啦！来这里，新购、升级、续费都打折，能够为您省60%的钱呢！2核4G企业级云服务器低至69元/年，点击进去看看吧>>>)

引言：

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

测试项目：

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

测试目的：

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

文档受众：

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

测试参考文档

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

测试提交文档：

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

术语定义：

项目术语：

编号	缩写、术语	解释
1	?	?
2	?	?

测试专业术语：

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

缺陷优先级：

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

严重程度定义：

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

用例优先级定义：

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

测试策略：

1、单元测试

?	单元测试
测试目标	开发者编写的一小段代码，检验被测代码的一个很小的、很明确的功能是否正确。
测试范围	测试整个项目中的每一行代码进行测试。
完成标准	代码的一个很小的、很明确的功能都正确。
需要考虑的特殊事项	//
使用工具	Python + Selenium + unittest

2、集成测试：

?	集成测试
测试目标	开发者编写的多个段代码单元，组合到一起形成集成测试，检查多个单元组合功能是否正确。
测试范围	开发者编写的多个段代码单元，组合到一起形成的集合。
完成标准	多个单元组合功能正确。
需要考虑的特殊事项	//
使用工具	?

3、冒烟测试：

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

4、功能测试：

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

易用性测试：

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

7、兼容测试：

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

8、可靠性测试：

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

9、压力测试：

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

10、负载测试:

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

11、数据完整性测试：

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

12、回归测试：

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

13、功能测试范围：

模块	功能	应用策略	备注
?	?	?	?
?	?	?	?

四、测试规则：

1、准入规则

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

2、暂停/退出规则

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

测试资源：

硬件资源

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

测试人力资源：

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

测试工作进度：

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

系统风险

1、系统风险：

（1）、计划的测试时间，不能满足测试组的要求，主要是功能冻结后的系统测试的时间可能不够。

（2）、测试资源的及时到位（设备和人员）。

（3）、需求不明确可能导致开发的产品与目标不一致。

（4）、测试人员对测试工具的使用熟悉程序不够；

（5）、被测试产品存在重大错误，以至于测试无法继续，需要开发组进行额外的调试和修改才能继续；

（6）、硬件、软件或网络环境出现故障等

2、应急措施：

（1）、如果上述潜在的可能事件发生，则通过适当加班来保证计划的按时完成。

（2）、如果是由于被测试产品存在重大错误而严重影响测试进度，则考虑按照测试暂停标准来暂停该测试。

（3）、如遇到功能需求不明确，需要沟通协商解决。

（4）、人员不足，则加班、或者进行不同组人员调动，按照测试进度完成测试任务。

测试的完成标准

完成标准

单元测试完成标准:

(1)、按照单元测试计划完成了所有规定单元的测试

(2)、达到了测试计划中关于单元测试所规定的覆盖率的要求

(3)、软件单元功能与设计一致

(4)、在单元测试中发现的错误已经得到修改，各级缺陷修复率达到标准

2、集成测试完成标准

（1）、按照集成构件计划及增量集成策略完成了整个系统的集成测试

（2）、达到了测试计划中关于集成测试所规定的覆盖率的要求

（3）、被测试的集成工作版本每千行代码必须发现至少2个错误（不含优化级别错误）

（4）、集成工作版本满足设计定义的各项功能、性能要求

（5）、在集成测试中发现的错误已经得到修改，各级缺陷修复率达到标准

3、功能/易用测试完成标准

（1）、功能测试用例设计已经通过评审

（2）、按照功能测试计划完成了功能测试

（3）、达到了功能测试计划中关于功能测试所规定的覆盖率的要求

（4）、系统达到详细设计定义的各项功能，性能

（5）、在功能测试中发现的错误已经得到修改，各级缺陷修复率达到标准

4、兼容测试完成标准

（1）、兼容测试用例设计已经通过评审

（2）、按照兼容测试计划完成了兼容测试

（3）、达到了兼容测试计划中关于兼容测试所规定的浏览器的要求

（4）、在兼容测试中发现的错误已经得到修改，各级缺陷修复率达到标准

5、系统测试完成标准

（1）、系统测试用例设计已经通过评审

（2）、按照系统测试计划完成了系统测试

（3）、达到了测试计划中关于系统测试所规定的覆盖率的要求

（4）、被测试的系统每千行代码必须发现至少1个错误（不含五级错误）

（5）、系统满足需求规格说明书的要求

（6）、在系统测试中发现的错误已经得到修改，各级缺陷修复率达到标准

6、验收测试完成标准

（1）、软件需求分析说明书中定义的所有功能已全部实现，性能指标全部达到要求。

（2）、在验收测试中发现的错误已经得到修改，各级缺陷修复率达到标准

（3）、所有测试项没有残余紧急、严重级别错误。

（4）、需求分析文档、设计文档和编码实现一致。

（5）、验收测试工件齐全（测试计划、测试用例、测试日志、测试通知单、测试分析）

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

（1）、性能测试用例设计已经通过评审

（2）、按照性能测试计划完成了性能测试

（3）、达到了性能测试计划中关于性能测试所规定要求

（4）、在性能测试中不通过的用例已经得到修改，性能达到预计标准

8、缺陷修复率标准

（1）、紧急、严重级别错误修复率应达到100%

（2）、普通级别错误修复率应达到95%以上

（3）、优化级别错误修复率应达到60%以上

注：项目紧急时，普通级别错误修复率达60%以上；优化级别错误修复率达20%即可。

9、覆盖率标准

（1）、测试用例执行覆盖率应达到100%（功能测试用例均已执行）

（2）、测试需求执行覆盖率应达到100%（业务测试用例均已执行）

；原文链接：https://blog.csdn.net/grl18840839630/article/details/101264120