引言
编号
|
确定项目
|
描述
|
1
|
确定测试范围
|
确定被测项目中功能模块,子功能模块等需要测试的范围
|
2
|
确定测试需求
|
确定每个功能结果定义,确定此功能是否存在缺陷
|
3
|
确定测试策略
|
确定对项目做哪些测试。如:功能测试,性能测试等
|
4
|
确定测试方法
|
确定对每个策略是用哪些方法。如:边界值,等价类等
|
5
|
确定测试工具
|
功能测试使用Jmeter或者Postman、性能测试使用Jmeter、自动化测试(接口和web)使用Python或者Java等
|
6
|
确定测试资源
|
测试需要的设备,服务器、参与测试的人员、测试任务的分工,测试工作的进度
|
7
|
确定测试交付文档
|
确定测试工作中生成哪些文档,可提交文档有哪些。比如测试计划、测试案例、评审记录、测试报告等
|
项目名称:
使用背景:
开发者:
项目简介:
编号
|
目的
|
1
|
软件测试是为了发现错误而执行程序的过程
|
2
|
测试是为了证明程序有错,而不是证明程序无错
|
3
|
一个好的测试用例在于它发现至今未发现的错误
|
4
|
一个成功的测试是发现了至今未发现的错误的测试
|
编号
|
人员
|
原因
|
1
|
产品设计人员
|
明确说明测试范围,方法,工作周期信息。
|
2
|
产品研发人员
|
明确说明测试范围,方法,工作周期信息。
|
3
|
产品测试人员
|
明确说明测试范围,方法,任务分工,预计完成时间。
|
4
|
备注
|
此为内部开发文档,不做外部参考。
|
编号
|
文档名称
|
作用
|
1
|
需求文档
|
确定项目功能模块,功能运行结果
|
2
|
设计文档
|
确定项目中使用开发语言,数据库数据限制
|
3
|
原型图
|
初步了解项目页面内容,方便编写用例
|
4
|
UI图
|
明确页面的排版、字体颜色、间距、弹窗显示等页面的样式
|
编号
|
文档名称
|
作用
|
1
|
测试计划
|
明确说明测试范围,方法,工作周期信息
|
2
|
测试用例
|
明确说明测试工作的细节测试工作
|
3
|
缺陷报告
|
明确说明项目中的缺陷描述,与修复情况
|
4
|
测试报告
|
明确说明测试结果,测试模块,缺陷分布,系统风险,测试建议情况等等信息
|
术语
|
定义
|
需求分析
|
需求分析是确定系统功能-性能、组成、接口、进度、成本和设备配置的优化过程
|
软件设计
|
是将用户需求转化为软件的功能-性能、结构、组成、接口、质量和成本的优化过程。
|
概要设计定义
|
是根据需求规格书,进行功能分解,确定程序结构、数据结构的优化过程。概要设计从宏观角度解决软件“怎么做”的问题,把系统按功能分界成各个模块,明确各模块的功能以及它们之间的接口,即各模块之间的相互关系以及相互间传递的信息。
|
详细设计定义
|
详细设计是根据开发工具,把概要设计逐级细化成能在运行环境上进行编程的过程。详细设计将详细描述模块内部的处理过程,即给出每个模块的详细说明、流程图、一些典型或重要方法的结构化说明或伪代码等。
|
产品
|
|
项目定义
|
项目是在规定时间、成本、资源(含人力资源)内,按照某种标准和规范去生产某种新产品或提供某项新服务的过程。
|
软件配置管理
|
软件配置(software configuration)是指开发过程中,构成软件产品的各种文档、程序及其数据的集合。该集合中的每一个元素称为配置中的一个配置项(configuration item)。
|
|
|
软件测试类型
|
解释
|
单元测试
|
开发者编写的一小段代码,检验被测代码的一个很小的、很明确的功能是否正确。
|
集成测试
|
开发者编写的多个段代码单元,组合到一起形成集成测试,检查多个单元组合功能是否正确。
|
冒烟测试
|
针对产品的基本功能进行测试。
|
功能测试
|
又称正确性测试,它检查软件的功能是否符合规格说明。
|
可靠性测试
|
对服务器施加一定压力,测试服务器是否可以长期稳定运行。
|
压力测试
|
对服务器施加一定压力后进行功能测试,测试服务器在一定压力下是够可以正常计算。
|
负载测试
|
对服务器施加压力,测试服务器可以容纳多少人访问,多少人访问后出现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
|
编写测试报告
|
|
|
|
|
|
|
|
|
- 计划的测试时间,不能满足测试组的要求,主要是功能冻结后的系统测试的时间可能不够。
- 测试资源的及时到位(设备和人员)。
- 需求不明确可能导致开发的产品与目标不一致。
- 测试人员对测试工具的使用熟悉程序不够;
- 被测试产品存在重大错误,以至于测试无法继续,需要开发组进行额外的调试和修改才能继续;
- 硬件、软件或网络环境出现故障等。
- 如果上述潜在的可能事件发生,则通过适当加班来保证计划的按时完成。
- 如果是由于被测试产品存在重大错误而严重影响测试进度,则考虑按照测试暂停标准来暂停该测试。
- 如遇到功能需求不明确,需要沟通协商解决。
- 人员不足,则加班、或者进行不同组人员调动,按照测试进度完成测试任务。
测试的完成标准
- 按照单元测试计划完成了所有规定单元的测试
- 达到了测试计划中关于单元测试所规定的覆盖率的要求
- 软件单元功能与设计一致
- 在单元测试中发现的错误已经得到修改,各级缺陷修复率达到标准
- 按照集成构件计划及增量集成策略完成了整个系统的集成测试
- 达到了测试计划中关于集成测试所规定的覆盖率的要求
- 被测试的集成工作版本每千行代码必须发现至少2个错误(不含优化级别错误)
- 集成工作版本满足设计定义的各项功能、性能要求
- 在集成测试中发现的错误已经得到修改,各级缺陷修复率达到标准
- 功能测试用例设计已经通过评审
- 按照功能测试计划完成了功能测试
- 达到了功能测试计划中关于功能测试所规定的覆盖率的要求
- 系统达到详细设计定义的各项功能,性能
- 在功能测试中发现的错误已经得到修改,各级缺陷修复率达到标准
- 兼容测试用例设计已经通过评审
- 按照兼容测试计划完成了兼容测试
- 达到了兼容测试计划中关于兼容测试所规定的浏览器的要求
- 在兼容测试中发现的错误已经得到修改,各级缺陷修复率达到标准
- 系统测试用例设计已经通过评审
- 按照系统测试计划完成了系统测试
- 达到了测试计划中关于系统测试所规定的覆盖率的要求
- 被测试的系统每千行代码必须发现至少1个错误(不含五级错误)
- 系统满足需求规格说明书的要求
- 在系统测试中发现的错误已经得到修改,各级缺陷修复率达到标准
- 软件需求分析说明书中定义的所有功能已全部实现,性能指标全部达到要求。
- 在验收测试中发现的错误已经得到修改,各级缺陷修复率达到标准
- 所有测试项没有残余紧急、严重级别错误。
- 需求分析文档、设计文档和编码实现一致。
- 验收测试工件齐全(测试计划、测试用例、测试日志、测试通知单、测试分析)
- 性能测试用例设计已经通过评审
- 按照性能测试计划完成了性能测试
- 达到了性能测试计划中关于性能测试所规定要求
- 在性能测试中不通过的用例已经得到修改,性能达到预计标准
- 紧急、严重级别错误修复率应达到100%
- 普通级别错误修复率应达到95%以上
- 优化级别错误修复率应达到60%以上
- 注:项目紧急时,普通级别错误修复率达60%以上;优化级别错误修复率达20%即可。
- 测试用例执行覆盖率应达到100%(功能测试用例均以执行)
- 测试需求执行覆盖率应达到100%(业务测试用例均以执行)
软件测试--测试计划相关推荐
- 软件工程生命周期模型对比分析
软件工程生命周期模型对比分析 2018年3月29日2018年3月28日 由 xyjisaw 本文共1515个字,预计阅读时间需要5分钟. 文章目录 迭代-递增生命周期模型 增量模型 进化树模型 编码- ...
- 测试计划的范围_【新书连载05】软件测试流程设计—系统测试计划
第2章 系统测试计划系统测试是指将已集成好的软件系统作为计算机系统的一个元素,与计算机硬件.外设.支持软件.数据和人员等其他元素结合在一起,在实际运行环境下对计算机系统进行一系列的组装测试和确认测试 ...
- 做好软件测试的关键是什么,做好测试计划和测试用例的工作的关键是什么?
每周一问:测试的流程中,测试计划是对整个测试活动的安排,而则是测试执行的指导,但是,现在仍然有很多的测试人员没有认识到测试计划和测试用例的重要性,在项目时间比较紧张的情况下,计划和用例往往成了形式上的 ...
- 软件测试自学英语计划,软件测试计划,software testing plan,音标,读音,翻译,英文例句,英语词典...
补充资料:软件测试 软件测试 software testing 配置项测试和系统测试. 加强测试管理对于保证测试可靠性十分重要,应按系统化的流程做好4步工作:①制定测试计划,确定总方针.资源及进度:② ...
- 超市收银软件测试自学,超市收银系统测试计划.doc
文档介绍: <超市收银系统>测试计划:张润学号:12740125班级:软件工程(1)班指导老师:路飞目录1.引言 31.1编写目的 31.2背景 31.3定义 31.4测试目标 32.计划 ...
- 软件测试生命周期——需求分析、测试计划、测试用例设计、测试执行和测试评估
一.需求分析 1.测试人员要充分了解需求,得出测试点和测试需求. 2.需求评审会议 在需求评审会议上,测试人员要确认每个功能的异常状态.数量以及如何转化,要多问为什么(用户是谁,软件的整体框架,要解决 ...
- 软件测试计划重点事项,软件测试的重点内容和测试计划
因此需要分析子项目差别:时间阶段.方法学.目标.听众(相关利益者),编制多个子项目测试计划时,需要有一个主测试计划说明公共主题. 对于不太清楚的工作内容,可以利用草案激发讨论?标注多待定事项,引起注意 ...
- 理财软件测试招聘信息,个人理财软件设计软件测试计划报告.pdf
个人理财软件设计软件测试计划报告 QR-D-010 软件测试计划 软件测试计划 软软件件测测试试计计划划 1 QR-D-010 1 1 11 概述 1.1 测试目的 1.1 测试目的 11..11 测 ...
- 软件测试计划与实施,软件测试实施计划书模板(通用版).doc
软件测试实施计划书模板(通用版).doc (14页) 本资源提供全文预览,点击全文预览即可全文预览,如果喜欢文档就下载吧,查找使用更方便哦! 19.9 积分 .软件测试计划书目录1. 订票系统简介 ...
最新文章
- 办公室“暧昧”的几种结局。
- ubuntu 安装deb_Ubuntu不完全小坑指南
- PHP 自学教程之MySQL数据库
- 驼峰设计 PPT设计网站
- 启动tomcat遇到的问题整理
- Git的多人协作和分支处理测试
- SQLServer学习笔记系列4
- lucene详细说明文档
- Python代码实操:详解数据清洗
- PHP判断浏览器类型和浏览器语言(附各国语言简写代码)
- 【iOS】Image图片属性之Render as Template Image
- mysql服务启动成功后卸载_安装,启动与卸载Mysql系统服务(MYSQL常见问题)
- win11系统怎么样 Windows11系统好用吗
- JSON.stringify方法详解
- 告别手机自带浏览器,分享2022年好用的手机浏览器
- 荣之学:关于跨境电商shopee平台,你了解多少?
- 迅雷9下载down.php,迅雷9-文件下载工具-迅雷9下载 V9.1.49.1060测试版-完美下载
- [ARM 的高级命名术 A32 T32 A64 Thumb Thumb2 AArch32 AArch64]
- linux kobject 原理,Linux设备驱动模型 - kobject原理与实例分析_Linux编程_Linux公社-Linux系统门户网站...
- 微信中怎么打开apk下载链接 微信跳转打开外部浏览器打开apk文件
热门文章
- 这些信用卡小知识,你get到了吗?
- 图片转c语言工具bin2c.exe,Image2Lcd(图片转换LCD)
- 【浏览器】众浏览器内核区别
- 布尔运算符的结果false true !非运算 -o或运算 -a与运算
- [SSD核心技术:FTL 3] 固态硬盘SLC缓存技术详解
- rabbitmq_delayed_message_exchange 安装
- android系统流畅度排行,最新手机性能/流畅度排名:黑鲨锁定性能之王,一加9R最流畅...
- Intel 基辛格:每家科技公司都应该有一位技术CEO
- java设计模式例题
- 【文档熟肉】spring cloud官方文档の中文熟肉之eureka