软件测试根本：功能测试知识详解

🍅 点击文末小卡片 ，免费获取软件测试全套资料，资料在手，涨薪更快  
  一、测试项目启动与研读需求文档

（一） 组建测试团队

1、测试团队中的脚色

2、测试团队的根本责任

• 尽早地发现软件步调、体系或产物中全部的标题。
  
• 督促和帮忙开辟职员尽快地办理步调中的缺陷。
  
• 资助项目管理职员订定公道的开辟和测试筹划。
  
• 对缺陷举行跟踪、分析和分类总结，以便让项目标管理职员和相干的负责人可以大概及时、 清晰地相识产物当前的质量状态。
  
• 资助改善开辟流程、进步产物开辟服从。
  
• 促历步调编写的规范性、易读性、可维护性等
  

3、测试团队与开辟团队的 3 种模式
（1）以开辟为焦点，测试只是开辟队伍的一部门，也就是开辟团队中有测试职员，但 没有形成独立的团队

（2）以项目司理为焦点，开辟小组和测试小组并存，附属于项目司理领导。

 （3）项目司理、开辟组长和测试组长“鼎足之势”，测试团队具有独立的、权势巨子的地 位。

（二）软件质量需求

1、软件质量需求的分类
软件质量需求用于确定测试目标。
测试目标包罗：功能、性能、界面、易用性、兼容性、安全性、可用性/可靠性、可维 护性、可扩展性等。
功能以外统称非功能。
2、功能

• 软件能做什么？
  
• 必要做什么？
  
• 怎么做是准确的？
  
• 哪些功能要测试、哪些功能不必要测试？
  
• 哪些功能告急，哪些不告急？
  
• 哪些功能先实现或先测试？
  

3、性能
反映软件运行时的服从和占用资源环境的本领。
时间特性：时间短、速率快、服从高。
资源特性：占用资源（CPU、内存、硬盘、网络）少。
4、界面（UI）

• 布局公道；
  
• 控件位置适当；
  
• 笔墨没有乱码、字体巨细符合；
  
• 颜色使用适当；
  
• 图片、表格适当、舒服、雅观。
  

5、易用性
在指定条件下使用时，软件产物被明确、学习、使用和吸引用户的本领。
6、兼容性/可移植性
指软件产物从一种环境迁徙到另一个环境的本领，反映一个软件与差别的硬件环境、操 作平台、其他软件的共同使用的本领

• 包罗与差别硬件、平台、软件自身差别版本、其他软件、数据的兼容。
  

7、安全性
指软件产物掩护信息和数据的本领。
8、可用性/可靠性
指体系正常运行的本领或程度，可用性=正常运行时间/（正常运行时间+非正常运行时 间）×100%

• 可用性指标一样平常要求到达 4 个 9 即 99.99%（整年 52 分钟不正常工作）或 5 个 9 即 99.999%（整年 5 分钟），对一些军事体系，可用性高达 7 个 9（99.99999%（整年 失效时间不凌驾两秒）。
  
• 一样平常测试时间不敷，可以接纳空间换时间的办法，如在高负载环境下进 活动期一周 或一个月的测试，以判断其可靠性。
  
• 关注 MTTF（匀称无端障时间）、MTTR（匀称规复时间）、MTBF（匀称失效间 隔时间）。
  

9、可维护性
指软件产物可被修改的本领

• 修改大概包罗修正、改进或软件对环境需求和功能规格阐明变革的顺应。
  
• 可维护性的软件应该是易改变的、稳固的、易测试的。
  

10、可扩展性/可伸缩性测试
通过很少的改动就能实现整个体系处理惩罚本领的增长

• 如在摆设两台服务器时测试体系性能（容量，即最大负载），再摆设四台、八台服 务器时分别举行体系容量的测试，看其容量是否为前次（两台、四台）实行值的两 倍或靠近两倍。假如是，体系就具有精良的可伸缩性。
  

（三）研读需求文档

1、测试需求分析的过程
网络与研读文档，提出并办理标题，整理需求信息
功能拆分、功能形貌/需求整理
编写测试点
需求评审
2、研读需求文档
2.1 研读文档重要使命
提取有用的需求信息
提出需求中不清晰、不明确、不明确的标题
 和用户、业务职员、产物司理或产物计划职员、开辟职员等沟通
2.2 怎么研读文档
分析思绪
 分析软件的用户群，分析用户的现实必要；
 分析软件的开辟环境、开辟语言、数据范例；
 分析软件架构、软件的运行环境清静台、数据库范例；
 分析软件要实现哪些目标（功能、性能、界面、易用性、兼容性、安全性）以 及详细的要求是什么；
 分析软件有哪些功能，每种功能要完成什么业务，这些业务应该怎么实现，业 务逻辑是什么，业务流程是怎样的，业务规则有何要求；
 分析功能或业务间的接洽，哪些业务更关键或告急；
 明确测试周期，测试目标，测试范围。
细节上
 分析每个模块或功能上实现的功能
 计划的开辟原理包罗数据范例
 从用户使用场景角度分析业务流程
 记载业务规则
实行
 以景象再现的情势写出需求信息。
2.3 研读需求文档案例
拿到一个项目，怎么入手？
即时贴步调部门需求阐明
便签的数目最多为 50 个
便签标题字数最多为 40 个字节
便签的正文笔墨数目最多为 200 个
年份只能设置在 1900－2100 之间
（四）需求评审

1、意义

• 对软件需求举行准确性的查抄。
  
• 包管软件需求的可测试性。
  
• 通过产物需求文档的评审，与市场、产物、开辟等各部门相干职员沟通，使得各人 熟悉划一，克制在后期产生差别的明确，引起辩论。
  
• 通过产物需求文档的评审，更好地明确产物的功能性和非功能性需求
  
• 在需求文档评审通过后，测试的目标和范围就确定了。固然以后会有需求的变更， 但可以得到有用的控制，如允许低沉测试的风险。
  

评审是否完成是以需求文档得到多方“邮件确认”或“具名”通过为标记的。这不 应该只体现在“具名”情势上，更告急的是到达下面的结果。

• 全部加入方告竣划一。
  
• 已发现的标题被叙述清晰、被修正。
  

2、需求评审的质量要求

• 准确性
  
• 完备性
  
• 易明确性
  
• 划一性
  
• 可行性
  
• 易修改性
  
• 可测试性
  
• 可追溯性
  

3、需求评审的到场职员

• 用户代表
  
• 需求职员
  
• 产物司理
  
• 项目司理
  
• 开辟职员
  
• 开辟司理
  
• 测试职员
  
• 测试司理
  
• 市场司理
  
• 质量包管职员
  

4、测试职员加入评审时的留意事项

• 明确本身的脚色和责任。
  
• 熟悉评审内容，为评审做好预备，做细做到位。
  
• 在评审会上，针对标题叙述观点，而不是针对个人。
  
• 可以分别讨论重要的标题和次要的标题。
  
• 在集会前或集会后可以就存在的标题提出本身建立性的意见。
  
• 进步本身的沟通本领，接纳适当的、机动的表述方式。
  
• 对发现的标题跟踪下去。
  
• 应该在需求形成的过程中举行分阶段的多次评审，而不是一次评审。
  
• 测试职员要善于提问，多思索
  

 这些需求都是用户提出来的吗？
 有没有多此一举的需求？没有遗漏什么需求吗？
 和竞争对手的产物做过比力吗？我们的产物上风体现在那里？
 是否准确地形貌了每个需求？这条形貌是否存在二义性的标题？
 我的明确和文档作者的明确划一吗？
同时，我也为各人预备了一份软件测试视频教程（含口试、接口、自动化、性能测试等），就在下方，必要的可以直接去观看，也可以直接点击文末小卡片免费领取资料文档
软件测试视频教程观看处：
   2024年Python自动化测试全套保姆级教程，70个项目实战，3天练完，永世白嫖...


二、测试需求分析与测试用例计划

（一） 界面中的控件知识

1、文本框和暗码框

2、单选按钮、组合列表框、数码框
 

3、复选框

4、列表框

5、下令按钮

6、其他界面元素

三、 测试需求分析与测试用例计划方法

1、场景法

1.1 测试点/查抄点
测试时应该思量可以测试的诸多方面。
1.2 场景法概述
场景法模仿用户操纵软件时的景象，重要用于测试体系的业务流程。
当拿到一个测试使命时，我们先要关注它的重要功能和业务流程是否准确实现，这 就必要使用场景法来完成测试。
1.3 场景的界说
场景用来形貌软件操纵的路径。
根本流
按照准确的业务流程来实现的一条操纵路径（模仿准确的操纵流程）。
备选流
导致步调出现错误的操纵流程（模仿错误的操纵流程）。
1.4 场景法的分析步调
分析软件需求
从用户使用景象角度，写出业务流程和业务规则
写出根本流场景和备选流场景
1.5 场景法案例：ATM 机取款
步调一：分析业务流程（可以绘制流程图）

步调二：形貌步调的根本流及备选流
1、根本流（准确的流程）
（1）插入银行卡：客户将银行卡插入 ATM 机的读卡器
（2）验证银行卡：ATM 机从银行卡的磁条中读取账户代码，并查抄它是 否属于可以继承的银行卡
（3）输入暗码：ATM 秘密求客户输入暗码
（4）验证暗码：确定该暗码是否准确 
（5）进入 ATM 主界面：ATM 表现在本机中可用的各种选项
（6）选择取款并输入金额：客户选择“取款”，并选择取款金额
（7）ATM 机验证：ATM 机举行验证账户余额是否满足以及总取款金额 是否满足要求，验证 ATM 机内现金是否够用
（8）更新账户余额、出钞：验证乐成，更新账户余额，输出现金，提示 用户收取现金
（9）返回主界面
2、备选流（各种错误环境）
（1）银行卡无效：提示错误并退卡
（2）暗码错误：提示错误，并判断是否 3 次错误
（3）暗码 3 次错误：吞卡
（4）账户余额不敷：提示错误并退卡
（5）总取款金额超出当日可取限额：提示错误并退卡
（6）ATM 机余额不敷：提示错误并退卡
步调三：根据根本流和备选流天生差别的场景

2、等价类分别

2.1 案例引入
测试两位数加法器（弟子思索、讨论、报告）

2.2 等价类分别焦点头脑
通过需求分析，找出步调的输入域。
将输入域分别成多少类。
每一类中选取代表性数据等价于这一类中的其他值。
2.3 等价类分别的步调
需求分析
分别等价类（根据需求，有用等价类、无效等价类）并细化（根据盘算机知识）
2.4 等价类分别案例
步调 1：需求分析
阅读文档 ：
 借助开辟知识
 与开辟或用户沟通
 相识用户群及行业知识
写出需求：
 -99~99 之间的整数
步调 2：分别等价类并细化
有用类
 -99 到 99 之中的整数
 细化 ：负数、0 、正数
无效类
 超范围 ：<-99 或 >99
 非法范例 ： 浮点数 、 字符（串）
2.5等价类分别留意事项
不但要思量有用等价类，也要思量无效等价类
两块划成一块（等价类分别过粗），结果？
 遗漏一种测试环境
一块划成两块（等价类分别过细），结果？
 冗余测试
过细分别，查察分别
 过于大抵大概会遗漏软件缺陷
 积累履历
3、界限值分析

3.1 界限值分析的头脑与步调
分析需求，找出界限。
写出界限值
 最小值
 小于最小值
 最大值
 大于最大值
3.2界限值分析案例
两位数加法盘算器的界限值 ： -99 、-100、99 、100
3.3 为什么分析界限值
看看下面的代码有错误吗？

 输入或输出的界限最容易产生错误。
4、决议表

前面测试两位数加法盘算器的测试没有思量输入组合。
4.1 决议表的分析步调
需求分析
分析输入和输出
 用等价类分别分析输入的各种环境、输出的各种环境
画判断表
分析与简化判断表
4.2 决议表案例
分析输入条件和输出条件
输入

输出
 准确盘算
 错误提示
原始决议表/判断表

优化决议表

优化计谋
 测试根本功能的保存；
 一个输入错误，别的输入无所谓，可以整合；
 全部输入都要错误过。
终极的决议表

4.3 决议表的范围性与优化计谋
导致测试量爆炸。
5、错误推测

5.1 测试多少原则回首
测试不是验证软件准确，而是攻击软件，发现错误。
测试要时间保持猜疑的态度，具有缺陷防备意识。
测试要寻求体系计划、功能计划的缺点。
计划负面的、非常的测试，如思量错误的大概非常的输入，通常可以发现更多的软件缺陷。
5.2 什么是错误推测
在测试步调时，人们可以根据履历或直觉推测步调中大概存在的各种错误，从而有针对 性地编写查抄这些错误的测试方法。
错误推测分类
 输入数据测试方面
 输出数据测试方面
 数据布局测试方面
 文件体系方面
5.3 输入数据方面的错误推测
输入非法数据
一样平常用于键盘输入数据时。
测试方法
 输入非法范例
 输入非法范围/长度
 输入非法格式
留意
错误信息的查抄：必要额外思量错误提示信息的内容
错误信息和错误要对应划一
错误信息不能为空
错误信息的内容不能只是错误代码，不能包罗开辟信息
错误信息不能中英文混淆
5.4 错误推测
输入非法范例
输入非法范围（数值）
输入非法长度（个数）
输入非法格式
输入默认值
输入特别字符
输入正当数据的非法组合
粘贴欺压输入
一个输入多个输出不要遗漏
输出结果（含数据库）要准确
上溢、下溢（含结果）
操纵数与操纵符不符
文件超载
文件权限不敷
介质忙或不可用
介质粉碎
输入默认值
实用于有默认值的地方。
测试方法
 继承软件的默认值
 键入空值
 将默认值改为别的一个值
 将默认值改为别的一个值，再变为空值
输入特别字符（集）
实用于不能输入有特别寄义的字符时。
测试方法
 根据被测软件所处的操纵体系、步调计划语言、配景数据库以及详细业务 等信息列出表格，举行讨论，标明哪些必要测试，哪些必要剔除。
 相识详细行业知识，详细标题详细分析。
案例
文件定名下列特别字符（33 个）
 不能使用：\ /<>|“😗?，com0-com9，lpt0-lpt9，prn、aux、nul、 con。
思索
 用户名有哪些特别字符？
 QQ 昵称、谈天内容有哪些特别字符？
输入正当数据的非法组合
实用于输入值之间存在依赖关系时。
测试方法
 输入大概是出现标题的组合值。
案例

 输出数据方面的错误推测
1)同一个输入产生多种输出
案例
输入：一个电话打来
输出：
 状态一：期待接听。
 状态二：占线。
 状态三：停机。
 状态四：无法接通。
 状态五：关机。
 状态六：空号。
测试方法
详细测试每一种输出，不要有遗漏。
熟悉被测软件业务知识，阅读各种步调文档，明确输入大概产生的输出， 列出关于步调输入于输出的一个列表，然后举行测试。
2)验证输出结果的准确性
测试方法
不但测试输入的准确性，还要查抄结果的准确性。
测试职员要尽大概多地学习所涉及标题的范畴。
数据布局方面的错误推测
1)数据布局溢出
实用于步调中存在变量、数组等数据布局时。
测试方法
变量 ：
上溢：值太大
下溢：值太小
数组
 上溢：数据量太多
 下溢：数据量太少
2)盘算结果溢出

测试方法
 输入非法值或很大与很小数据，欺压结果产生上溢或下溢。
3)操纵数和操纵符不符

实用于必要举行数值盘算步调和图形操纵步调的测试时，如加、减、乘、除等。
测试方法
 找到步调中容易引起操纵数和操纵符不符的盘算、表达式等
文件体系方面的错误推测
1)使文件体系超载
实用于数据存储到硬盘中时。
案例
 假设“软件测试工程师管理体系”要生存 10000 个工程师信息，则生存时 engineer.txt文件大概会有20M巨细，假云云时磁盘只有10M可用空间了， “软件测试工程师管理体系”会怎样动作呢？
测试方法
 创建满容量或近乎满容量的文件体系，然后欺压实行各种通过输入或输出 访问文件体系的操纵。
 打开富足多的文件，文件打开时会欺压创建备份副本，从而占用双倍的存 储空间。
 使用工具 CannedHeat，模仿文件体系超载。
 
2)更改文件访问权限
实用于对文件举行读写的应用步调。
测试方法
差别的用户对雷同文件具有差别的访问权限，必要思量登录同一台呆板的 多个用户操纵雷同文件的权限标题。
 打开一个文件，在操纵体系中修改该文件的访问权限。有些操纵体系 允许权限高的用户控制一样平常用户已经打开的文件。
两个应用步调打开，关闭同一个文件。
 如把同一应用步调的差别版本安装在同一呆板上，在差别版本的应用 步调中打开和关闭同一文件；
 试着在某个应用步调中打开在另一个步调中已打开的文件，这大概会 导致文件访问权限上出现辩论。
3)使介质忙或不可用
实用于应用步调的运行必要斲丧大量内存或运行时需求其他相干软件同时运 行的环境。
 大多数操纵体系能同时运行多个应用步调，但相互切换时会有耽误，但是 没有对错误相应。
测试方法
 通过启动大量应用步调，欺压它们都打开并生存文件来使文件体系处于忙 的状态；大概同时下载大量文件也可以使配景拥挤。
 使用一些测试工具来模仿磁盘的状态。
4)介质粉碎
使用场合
 粉碎的介质大概使操纵体系传回错误代码，这些错误代码大概没有在应用 步调中编程处理惩罚。
测试方法
 粉碎介质的方法使用不很多，只有少数公司接纳，大多是开辟操纵体系、 装备驱动步调以及以安全为主的应用步调的公司会接纳这种测试方法。确 定是否使用该方法，重要要思量数据对用户的告急性。
 该方法可以使用现实粉碎了的介质。查抄应用步调对错误的处理惩罚本领，应 用步调可以对错误举行处理惩罚大概将标题告诉用户，而且要确保用户数据文 件不丢失、不粉碎。
 也可以通过软件模仿。
6、编写测试点

将测试点写入测试需求分析阐明书，大概 XMind 等，留存下以供将来编写测试用例使
用。

四、编写测试用例

1、编写测试用例（一样平常公司都有固定模板）

2、测试用例的写作阐明

2.1 用例编号/序号
简朴、唯一。
2.2 用例阐明
也称测试点、查抄点、测试概述、用例概述、测试阐明；
用一句话对测试用例举行概述；
可以总结测试目标；
可以用疑问句表现；
可以用“查抄、验证、测试”等字眼（如验证 QQ 默认安装）；
最悦目到这句话就能知道怎样测试；
只管唯一（决议表大概会有重复的测试阐明）；
用例实行多轮时，越以后实行大概越快，假如用例写得好，直接看概述就行。
2.3 初始条件
也称预置条件、条件条件；
初始条件要是一个状态，而且是静态的，如管理员已登录配景；
初始条件是第一步操纵步调之前的状态，不能太远，不消重新写到尾
很多项目中不写预置条件。
2.4 操纵步调
若对数据要求高，必要把数据分离出来；
步调要都有序号；
每一步用分号分开，末了用一个句号；
每一步必须换行；
参数前加冒号（如用户名：admin）；
涉及按钮界面用【】、“”等成对符号隔断；
功能的详细用例步调 4-6 步左右；
末了一步肯定是个动作，不能写结果。
2.5 预期结果
是一个状态；
假如参考文档中有形貌，原封不动的抄过来；假如文档中没有详细要求，则点要一 致，可以有几个点，如 QQ 默认安装，应能启动、默认选项匹配等。
2.6 用例状态
通过、失败、壅闭、未实行、搁置、无效用例…
初始条件达不到时，一样平常用例状态设置为壅闭。
看怎样实行用例，实行完关心什么来定。
2.7 优先级
用例的实行次序。
3、测试用例的评审和管理

包管测试用例质量的方法
 起首，要对用户需求、服务质量要求、产物特性有深刻且全面的明确
 其次，接纳准确、适当的方法举行用例计划；
 再者，按照测试用例的标准格式或规范的模板来誊写测试用例；
 末了，对测试用例的查抄、评审，也是进步测试用例质量的重要且有用的本领。
五、提交缺陷陈诉

一） 软件缺陷的判断

1、什么是缺陷
软件存在着不符合质量需求或违背软件用户、客户、企业意愿的标题，这就是软件缺陷 （Defect），又叫“Bug（臭虫）”。
2、软件缺陷的判断准则
软件未到达产物阐明书标明的功能；
 产物阐明书简称为阐明（spec）或产物阐明（productspec），是软件开辟小组 的一个协定。它对开辟的产物举行界说，给生产物的细节、怎样做、做什么、 不能做什么。这种协定从简朴的口头阐明到正式的书面文档有多种情势。
软件出现了产物阐明书指明不会出现的错误；
 如金融软件 7*24 工作不能宕机
软件功能超生产物阐明书指明范围；
软件未到达产物阐明书虽未指出但应到达的目标；
 如软件在断电时的不测处理惩罚
软件测试员以为软件难以明确、不易使用、运行速率迟钝，大概终极用户以为不好。
 重要体现在易用性方面。
3、软件缺陷的表现情势
用户要求的功能、特性没有实现或部门实现。
运行堕落，包罗运行停止、体系瓦解、界面杂乱等。
数据结果禁绝确、精度不敷、不完备或格式差别一。
笔墨表现内容禁绝确或拼写错误。
体系性能低下、体系资源浪费。
4、分离和再现软件缺陷
发现缺陷后，应该做好分离和再现，排查发现的“缺陷”是不是软件本身的标题， 然后才华提交。
再现 3 次
 重现
 复现
5、克制提交缺陷的缺陷和重复缺陷
缺陷的缺陷
 是测试职员提交的不是缺陷的缺陷；
 是一种无效缺陷；
 此类缺陷常使测试职员遭受求全非难。
怎么办 ： 准确明确需求； 做好复现。
重复缺陷
 同一个缺陷 A 测试工程师提交后，B 测试工程师又提交大概本身提交的缺陷 与之条件交的缺陷雷同或雷同；
 是一种无效缺陷；
怎么办 ： 只管克制两个人同时测试同一模块； 本身提交的缺陷与本身的重复，提交前查找一下，增强开辟知识。
6、处理惩罚无法再现的缺陷
起首，对如许的缺陷举行详细的记载，使用差别办法去实行复现。
其次，要公道地安排时间，要思量到测试项目标团体进度，对一时难以再现的缺陷 可以临时搁置，以包管项目标正常进度，并尽快提交给开辟职员。
末了，在测试过程中对未再现缺陷予以关注。
7、处理惩罚有争议的缺陷
跟有关职员举行沟通、讨论；
搁置。
二） 提交缺陷陈诉

1、什么是缺陷陈诉
缺陷陈诉是对缺陷举行记载、分类和跟踪的文档。
2、缺陷陈诉的读者对象
软件开辟职员
 陈诉缺陷是为了缺陷得到修复。
 渴望得到缺陷的本质特性和复现步调。
质量管理职员、市场职员、技能支持职员
 渴望得到缺陷的严肃程度和分布环境，以及对市场和用户的影响程度。
3、缺陷陈诉的写作准则（5C）
Correct（正确）
 每个构成部门的形貌正确，不会引起误解；
Clear（清晰）
 每个构成部门的形貌清晰，易于明确；
Concise（轻巧）
 只包罗必不可少的信息，不包罗任何多余的内容；
Complete（完备）
 包罗复现该缺陷的完备步调和其他本质信息；
Consistent（划一）
 按照划一的格式誊写全部缺陷陈诉。
4、缺陷陈诉的构造布局
缺陷的标题/缺陷择要/缺陷概述/缺陷根本信息
预处理惩罚
复现步调
渴望结果
现实结果
缺陷的严肃程度
缺陷的优先级
测试的软件和硬件环境
测试的软件版本
缺陷的范例
表明笔墨和缺陷截图
5、缺陷陈诉的写作要求
5.1 缺陷标题
只管按缺陷发生的缘故原由与结果的方式誊写；
 实行完 A 后，发生 B；
 在什么地方，做了什么事变，出了什么结果；
使用“在…以后”，“在…时间”或“在…期间”等连结词有助于描 述缺陷的缘故原由和结果。
克制使用暗昧不清的词语；
为了方便搜刮和查询，只管使用关键字；
为了便于他人明确，克制使术语、俚语或太过详细的测试细节。
5.2 复现步调
提供测试的预备步调和信息；
步调完备，正确，简短，没有罅漏任何操纵步调，没有任何多余的步调；
将常见步调归并为较少步调；
简朴地一步一步地引导复现该缺陷；
每一个步调只管只记载一个操纵；
每一个步调前使用数字对步调编号；
只管使用短语和短句，克制复杂句型和句式；
 只记载各个操纵步调是什么，不要包罗每个步调的实行结果。
5.3 预期结果
 软件应该具有的结果，大概说准确结果应该是什么样子。
5.4 现实结果
现实结果的形貌要列出详细的表现活动，而不是简朴的指出“禁绝确”或“不起作 用”。
假如一个动作产生相互差别的多个缺陷结果，大概一个动作将产生一个结果，而这 个结果又产生另一个结果。为了易于阅读，这些结果应该使用数字列表分隔开来。 如现实结果：
 1.表现“下令代码行…错误”；
 2.表现“而且停止…服务”。
5.5 表明/截图
可以包罗以下各方面的内容：
 截取缺陷特性图像文件；
 测试过程所使用的测试文件；
 测试附加的打印机驱动步调；
 再次形貌重点，克制开辟职员将缺陷退回给测试职员增补更多信息；
 再次指明该缺陷是否在前一版本已经存在；
 多个平台之间是否具有差别表现；
 表明包罗缺陷的隔离信息，指出缺陷的详细影响范围。
如，缺陷的表明大概包罗下面的内容：
 能在 Win2000 和 WinXP 文本框中表现文本内容，但不支持 Win98
 屏幕革新后，征象会消散。
 使用二进制文件，不存在该错误。
 拜见附加的使用阐明书和测试文件。
6、怎么提交高质量的缺陷陈诉
尽早提交缺陷陈诉。
清晰地阐明此标题对用户代价的危害。  提供尽大概多的技能信息（如包罗复现该缺陷必要的环境变量或测试所用的数据文 件），方便步调员调试。
陈诉的软件缺陷举行了须要的隔离，陈诉的缺陷信息详细、正确。
易于搜刮软件测试陈诉的缺陷。
一个缺陷陈诉中只陈诉了一种缺陷。
缺陷陈诉中不要提标题。
克制常见的错误
 我（I）、你（You）、他/她（He/She）
 感情化的语言和夸大符号！！！
 似乎（Seems）、看上去大概（Appearstobe）
 以为比力幽默的内容  不确定的测试标题（Issues）/不确定是否是缺陷
三） 缺陷的分类

1、缺陷的分类标准

2、根据缺陷范例对缺陷分类
功能缺陷
界面缺陷
文档缺陷
代码缺陷
算法错误
性能缺陷
3、根据缺陷的品级对缺陷分类
A 类—致命缺陷，包罗以下各种错误：
 由于步调所引起的死机，非法退出；
 死循环；
 数据库发生死锁；
 因错误操纵导致的步调停止；
 功能错误；
 与数据库毗连错误；
 数据通讯错误
B 类—严肃缺陷，包罗以下各种错误：
 步调错误；
 步调接口错误；
 数据库的表、业务规则、缺省值未加完备性等束缚条件
C 类一样平常缺陷，包罗以下各种错误：
 操纵界面错误（包罗数据窗口内列名界说、寄义是否划一）；
 打印内容、格式错误；
 简朴的输入限定未放在前台举行控制；
 删除操纵未给出提示；
 数据库表中有过多的空字段
D 类—较小缺陷，包罗以下各种错误：
 界面不规范；
 辅助阐明形貌不清晰；
 输入输出不规范；
 长操纵未给用户提示；
 提示窗口笔墨未接纳行业术语；
 可输入地区和只读地区没有显着的区分标记
E 类—意见或发起
4、根据缺陷处理惩罚的优先级对缺陷分类

 5、根据缺陷状态对缺陷分类

四）缺陷陈诉的处理惩罚

1、缺陷陈诉的简朴处理惩罚流程/缺陷的生命周期

软件测试职员提交缺陷陈诉；
测试负责人稽核后将缺陷陈诉分配给相干的开辟职员修改；
缺陷被修改后由测试职员根据缺陷陈诉中的修改记载举行返测；
返测通过的缺陷陈诉由负责人关闭，返测未通过的缺陷陈诉直接返回开辟职员重新 修改，缺陷陈诉直到缺陷被修复以后才关闭；
关闭或已办理的缺陷陈诉大概会被阶段性的复审重新打开，这些陈诉一旦被再次打 开应该立刻处理惩罚。 
2、缺陷陈诉的标准处理惩罚流程
正常缺陷
重复缺陷
无效缺陷
推迟修改
验证不通过
形貌不清晰

3、缺陷跟踪管理体系/缺陷管理工具
3.1 缺陷管理工具的功能
缺陷提交
缺陷跟踪
缺陷分析
 有用的缺陷分析不但可以评价软件质量，同时可以资助项目组很好地把握和评 估软件的研发过程，进而改进研发过程，未对缺陷举行分析就无法对研发流程 举行改进。
 缺陷分析还能为软件新版本的开辟提供宝贵的履历，进而在项目开展之前，指 定正确、有用的项目控制筹划，为开辟高质量的软件产物提供保障。
3.2 常见缺陷管理工具

• Bugzilla
  
• Bugfree
  
• Mantis
  
• Jira
  
• ZenTao（禅道）
  
• QualityCenter/Application Lifecycle Management
  

六、总结

末了感谢每一个认真阅读我文章的人，投桃报李总是要有的，固然不是什么很值钱的东西，假如你用得到的话可以直接拿走：

​这些资料，对于做【软件测试】的朋侪来说应该是最全面最完备的备战堆栈，这个堆栈也伴随我走过了最艰巨的路程，渴望也能资助到你！凡事要赶早，特别是技能行业，肯定要提拔技能功底。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！qidao123.com:ToB企服之家，中国第一个企服评测及软件市场,开放入驻,技术点评得现金