参考学习资料
书籍：《软件测试》[美] 罗恩 佩腾（Ron Patton）著 张小松 王钰 曹跃 等译 机械工业出版社
视频： ① B站 - 软件测试全套白嫖：零基础转行精品课，自学完拿不到8K，你找我！https://www.bilibili.com/video/BV13Q4y127ac?p=16&spm_id_from=333.1007.top_right_bar_window_history.content.click
② B站 - B站最强软件测试教程=软件测试基础+软件测试面试+软件测试项目实战+测试https://www.bilibili.com/video/BV14v411B7p5?p=78&spm_id_from=333.1007.top_right_bar_window_history.content.click
笔记内容摘要
-
该总结笔记根据上方【参考学习资料】整理而成，部分内容存在删减，不足之处欢迎批评指正，谢谢！
-
笔记中部分图片源自网络搜索，若侵权，请联系博主自删，感谢！
-
笔记内容以【软件测试流程】为主干，其间穿插相关知识要点，总体思维导图如下：
在进行软件测试流程的第一步：获取测试需求之前，我们需要知道：软件开发的生命周期以及需求的来源
一、软件开发的生命周期
- 定义： 软件产品从最初构思到公开发行的过程
- 内容： 需求分析（产出：需求规格说明书Software Requirement Specification，SRS）→概要设计（产出：架构文档）→详细设计（产出：详设文档）→编码（产出：源代码）→测试（产出：测试报告）→验收（产出：最终产品）
1.1 瀑布模型
-
定义： 采用瀑布模型的项目从最初的构思到最终产品要经过一系列步骤。每个步骤结束时，项目小组组织审查，并决定是否进入下一步。如果项目未准备好进入下一步，就停滞下来，直到准备好。
-
内容： 计划→需求分析→设计→编码→测试→运行维护
-
优点： ①非常强调产品的定义；②各步骤是分立的，没有交叉
-
缺点： ①无法回溯，一旦进入某个步骤，就要完成该步骤任务，然后才能向下继续；②无法适应用户需求的快速变化；③将测试放在编码之后，无法发现早期的致命缺陷
1.1.1 V模型
- 内容： 用户需求→需求分析→概要设计→详细设计→编码和实现→单元测试→集成测试→系统测试→验收测试
- 优点： 每个阶段都有相应的开发文档支持
- 缺点： ①测试介入太慢，放置在编码之后，忽视了测试对需求分析、系统设计的验证 ②测试的对象只有程序，不包括需求等其他文档内容
1.1.2 W模型
- 内容： 由两个“V”字组成，其中一个V为Verification（确认功能有没有实现），另一个V为Validation（验证符不符合用户需求）；分别代表测试和开发过程，表示出测试和开发的并行关系
开发过程： 用户需求→需求分析与系统设计→概要设计→详细设计→编码→集成→实施→交付
测试过程： 验收测试准备→系统测试准备→集成测试准备→单元测试→集成测试→系统测试→验收测试
- 优点： ①测试的活动和开发同时进行；②测试对象不仅仅是程序，还包括需求和设计；③尽早发现软件缺陷可降低开发成本
- 缺点： 无法支持灵活的版本迭代
1.1.3 H模型
- 内容： H模型常见于外包测试，表明测试是一个独立的流程。只要某个测试达到准备就绪点测试执行活动就可以开展，并且不同的测试活动可按照某个次序先后进行，也可反复进行
1.1.4 X模型
- 内容： X模型定位了探索性测试，这是不进行事先计划的特殊类型的测试，能够帮助测试人员在计划之外发现更多的软件缺陷
1.2 螺旋模型
-
定义： 螺旋测试的总体思想是一开始不必详细定义所有细节。从小开始，定义重要功能，努力实现这些功能，接受客户反馈，然后进入下一阶段。重复上述过程，直至得到最终产品
-
内容： ①确定目标、可选方案和限制条件；②明确并化解风险；③评估可选方案；④当前阶段开发和测试；⑤计划下一阶段；⑥确定进入下一阶段的方法
-
优点： ①发现问题早、成本低；②测试全程参与
-
缺点： 工作量大
1.3 敏捷开发与测试模型
-
定义： 敏捷开发与测试模型主要是为了适应现代互联网公司“短平快”的开发节奏而设计的一种开发和测试模型
-
内容：
①迭代：每次迭代叫做一个sprint，每个sprint里面选出来要实现的需求会安排到sprint backlog里面，每个sprint一般是以一个月作为周期；
② Product Owner：相当于是产品经理。整理出整个项目的所有需求，并且按照需求的优先级来将需求排列到Produce Backlog；
③ Daily Meeting：每日会议，一般是站会形式。每个人发言一般不会超过1分钟，主要内容包括三点：昨天完成的工作、今天准备开展的工作、面临的风险和问题；
④ sprint burndown：迭代燃尽图，记录剩余的工作量；
⑤ sprint review meeting：迭代回顾会议，主要是去回顾在本轮迭代中存在的问题有哪些、如何改进等；
⑥ scrum master：相当于组长，由他来统一管理组员；
-
优点： 适应短平快的开发节奏
-
缺点： 容易偏离开发需求主题而造成混乱
二、需求的来源
2.1合同型项目
- 合同型项目通常有甲乙方，包括外包项目
- 需求源自用户业务需求
2.2 产品型项目
- 产品型项目通常没有明确的用户
- 需求源自：①协议、标准、规范；②继承性需求（版本迭代）；③竞品分析
在进行软件测试流程的第二步：编写测试计划之前，我们需要知道：什么是软件测试、编写计划前要思考的问题以及软件质量模型，帮助我们在编写计划前能全面思考问题
三、软件测试
3.1 定义
- 正向思维： 使自己确信产品是能够正常工作，并确定它是否达到期望的结果（系统让你干啥就干啥）
- 反向思维： 测试是为发现错误而执行程序的过程，怀疑一切（系统让你干啥就不干啥）
- IEEE定义： 软件测试是使用人工或自动手段来运行或测定某个系统的过程，检验它是否满足规定的需求或是弄清预期结果与实际结果之间的差别（要点：①人工或自动的手段；②过程；③满足规定的需求；④弄清预期结果与实际结果之间的差别）
举例：
- 用手机打游戏（不是测试，需求不明确）
- 把一个app应用安装到手机以后再卸载（不是测试，需求不明确）
- 在一个不知道怎么用的软件上随便点点点，看看会不会出现什么问题（不是测试，没有弄清预期结果与实际结果之间的差别）
- 找一个类似于按键精灵的工具录制操作步骤，自动化地帮我抢红包（不是测试，只是自动化操作）
3.2目的
- 软件测试的目的是尽可能早地找出软件缺陷，并确保其得以修复
3.3原则
- 所有测试的标准都是建立在用户需求之上
- 软件测试必须基于“质量第一”的思想去开展工作
- 要事先定义好产品的质量标准，只有有了质量标准，才能根据测试的结果，对产品的质量进行分析和评估
- 穷举测试是不可能的
- 第三方测试会更加客观
- 测试用例是设计出来的，要根据测试的目的，采用相应的方法去设计测试用例
- 要重视文档，妥善保存一切测试过程文档（测试计划、测试用例、测试报告等）
- 对测试结果要有一个确认的过程
3.4 分类
- 按照阶段划分： 单元测试、集成测试、确认测试、系统测试、回归测试、验收测试
- 按照代码运行： 静态测试、动态测试
- 按照软件特性： 功能测试、性能测试、安全测试
- 按照测试技术： 黑盒测试、白盒测试、灰盒测试
- 按照测试运行主体： 手工测试、自动化测试
- 其他测试分类： 随机测试、猴子测试
3.4.1 按照阶段划分
- 单元测试： 一般要读程序和代码。大多数时候由开发人员自己去完成，是底层测试
- 集成测试： 单元经过测试，底层软件缺陷被找出并修复之后，就集成在一起，对模块的组合进行集成测试，较多涉及接口测试
- 确认测试： 也叫冒烟测试，确认基本功能是否实现，一般不作为正式的测试环节
- 系统测试： 系统所有功能的测试，模拟所有软件用户的操作
- 回归测试： 对软件新版本测试时重复执行之前的测试用例，目的：①验证之前缺陷已修复；②确认修复缺陷没有引发新缺陷
- 验收测试： 供求双方以及第三方的测试，依据运行主题的不同可分为ɑ测试、β测试、γ测试
- 回归测试的流程：
①在测试策略制定阶段，制定回归测试策略
②确定需要回归测试版本，哪个版本上缺陷被修改了就在哪个版本上回归
③回归测试版本发布，按照回归测试策略执行回归测试
④回归测试通过，关闭缺陷报告单
⑤回归测试不通过，缺陷报告单返回开发人员重新修改，之后再次提交测试人员回归测试- 回归测试的策略：
①完全回归：重新执行所有在前期测试阶段建立的测试用例。工作量大
②选择性回归：即有选择地重新执行部分在前期测试阶段建立的测试用例来测试被修改的程序
- 覆盖修改法（只针对被修改的部分）
- 周边影响法（在覆盖修改法的基础上分析修改的扩散影响部分，选择测试用例去验证，较为常用）
- 指标达成法（基于要求选择一个最小的测试用例集合，如修改部分代码100%覆盖，与修改有关的接口60%覆盖等）
- 验收测试的分类：
①ɑ测试：软件开发商自己进行交付前的测试
②β测试：软件需求商进行的测试，在该过程中软件分发给选定的潜在客户群，让它们在实际环境中使用软件
③γ测试：除软件供需双方外的第三方测试
3.4.2 按照代码运行
- 静态测试： 指测试不运行的部分——只是检查和审核，可分为代码测试（是否符合标准和规范）、界面测试（与需求说明是否相符）和文档测试（是否符合用户的实际需求）
- 动态测试： 指通常意义上的测试——使用和运行软件
3.3.3 按照软件特性
- 功能测试： 是黑盒测试的一方面，它检查实际软件的功能是否符合用户需求，包括：①逻辑功能测试；②界面测试；③易用性测试；④安装、卸载测试；⑤兼容性测试
- 性能测试： 关注软件中某一功能在特定时间、空间内能否正常使用（打开多块？占多大内存？）
- 安全性测试： 验证是否在实际应用中对系统进行保护（用户信息是否会泄露？多地同时登录是否会报异常提示？）
3.4.4 按照测试技术
- 黑盒测试： 在黑盒测试中，软件测试员只需要知道软件要做什么，而无法看到盒子里的软件是如何运行的，只要进行一些输入，就能得到某种输出结果。他不知道软件如何运行、为什么会这样，只知道程序做了什么
- 白盒测试： 软件测试员可以访问程序员的代码，并通过检查代码来协助测试。测试员根据代码检查结果判断可能出错的数目，并据此定制测试
- 灰盒测试： 灰盒测试关注输出对于输入的正确性，同时也关注内部表现，但这种关注不像白盒测试那样详细、完整
3.4.5 其他测试
- 随机测试： 基于经验和直觉的测试，发现一些边缘性错误
- 猴子测试： 把自己当成小动物随便乱点，让一些意想不到的操作造成错误结果
四、计划前要思考的问题
- 你知道要测试的系统是干什么的吗
- 你了解系统有哪些特点吗
- 你知道系统有哪些功能吗
- 你知道系统的业务流程是什么吗
- 系统在这个版本上，哪些需要测试，哪些不需要测试
- 系统对性能、安全有没有要求
五、软件质量模型
- 定义： 软件质量模型提供了从不同维度考量产品质量属性的依据
- 内容： 功能性、可靠性、易用性、性能效率、兼容性、安全性、维护性、可移植性
问题：如何测试一个水杯的质量？
参考：
在进行软件测试流程的第三步：设计测试用例之前，我们需要知道：测试用例的模板内容有哪些、常用测试用例的设计方法、测试点的提取思路以及如何建立需求跟踪矩阵
六、测试用例模板
6.1 测试用例的定义
- 设计一个情况，软件程序在这种情况下，必须能够正常运行并且达到程序所设计的预期结果，检查程序有无缺陷
6.2 测试用例的内容
- 测试用例编号： 一般命名规则为：TestCase_项目名称_模块名称_功能名称_0001
- 测试项： 描述被测试的详细特性、代码模块等，表明测试用例的测试目的，一般用一句话说明（测试模块+对象+方法），如：使用谷歌浏览器打开百度首页
- 依赖用例： 如果一个测试用例依赖于其他用例，或者受其他用例的影响，应该在此说明
- 测试步骤： 用最朴实的语言写出软件的操作步骤，尽量详细，标号分步说明
- 输入数据： 列举送到软件执行测试用例的所有输入内容或条件
- 预期结果： 进行正确的操作步骤后期望达到的结果
- 实际结果： 执行测试用例后的结果，一般为 通过（pass）、失败（fail）、NA（表明当前用例不适用）
- 测试人： 执行测试用例的人员
- 备注： 其他补充情况说明，帮助他人理解测试用例
6.3 测试用例的作用
- 有效性、可复用性、易组织性、可评估性、可管理性
七、常用测试用例的设计方法
7.1 基本方法
等价类划分法和边界值分析法的使用场景：
把输入条件分成多个不同的子条件，条件与条件之间相对独立，没有制约关系
7.1.1等价类划分法
-
定义：
①把程序的输入域划分为若干部分，然后从每个部分中选取少数代表性数据作为测试用例的测试对象
②每一类的代表性数据在测试中的作用等价于这一类中的其他值，如果某一类中的例子发现了错误，这一等价类中其他例子也会有同样错误 -
划分原则：
-
如果输入条件规定了取值范围或值得个数，则可以确定一个有效等价类和两个无效等价类
①要求输入年龄在18（含）岁至25（含）岁之间，则有效等价类：18（含）岁至25（含）岁，无效等价类：大于25岁、小于18岁
②要求一个函数有3个参数，则有效等价类：3个参数，无效等价类：大于或小于3个参数
-
输入条件规定了输入值得集合，或是规定了必须如何的条件，则可以确定一个有效等价类和一个无效等价类
要求输入学历值，学历包含大专、本科、硕士、博士，那么学历中的这些值为有效等价类，凡是不属于这个学历集合中的值为无效等价类
-
在输入条件是一个布尔值的情况下，可以确定一个有效等价类和一个无效等价类
要求输入性别为女，那么有效等价类为女，无效等价类为男
-
如果我们确知，已经划分的等价类中各个元素在程序中处理方式不同，则应该将此等价类进一步划分
-
在规定了输入数据必须遵守的规则的情况下，可确立一个有效等价类（遵守规则）和若干个无效等价类（从不同角度违反规则）
要求输入的数据必须是一个正整数，那么有效等价类为一个正整数，无效等价类可以是0、负数、小数等
-
-
综合例子：
-
如果当前时间等于12点或17点，闹铃响，请根据条件划分出其等价类
有效等价类：12点、17点；无效等价类：除12点和17点以外的其他点
-
现有一个档案管理系统，容许用户通过输入年月对档案文件进行检索，系统对查询条件的年月输入限定为1990年1月至2049年12月，并规定：日期由6位数字组成，前4位表示年，后2位表示月
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-u1hAhIm6-1643606125706)(E:\知识储备2号机_软件测试\软件测试的基础理论\等价类划分法.png)]
-
-
一定要考虑建立处理默认值、空白、空值、零值或者无输入 等条件的等价类划分
7.1.2 边界值分析法
- 定义： 边界条件是指软件运行在计划操作界限的边界情况。提出边界条件时，一定要测试靠近边界的有效数据，即测试最后一个可能有效的数据，同时测试刚超过边界的无效数据
- 操作原理： 越界测试的做法通常简单地对于最大值加一，对于最小值减一
- 综合例子：
- 如果文本输入域允许输入1-255个字符，就尝试输入1个字符和25个字符代表合法划分的数据。还可以输入254个字符作为合法输入。输入0个字符和256个字符作为非法划分的数据
- 如果测试飞行模拟程序，尝试控制飞机正好在地平线上以及最大允许高度上飞行。尝试在地平线和海平线之下飞行，以及在外太空飞行
7.2 有制约前提的方法
7.2.1 因果图法
-
定义： 根据输入条件的组合、约束关系和输出条件的因果关系，分析输入条件的各种组合情况，从而设计测试用例的方法，它适用于检查程序输入条件设计的各种组合情况
-
执行步骤：
- 分析哪些是原因，哪些是结果。原因是输入条件或输入条件的等价类，结果是输出条件
- 分析原因与结果之之间、原因与原因之间的对应关系，画因果图
- 标明约束条件，因为有些原因和结果的组合情况是不可能出现的
-
原因和结果之间的因果关系(状态)：
- 恒等：若原因出现，则结果出现；若原因不出现，则结果也不出现
- 非 ~：若原因出现，则结果不出现；若原因不出现，则结果出现
- 或 /：若几个原因中有1个出现，则结果出现；若几个原因都不出现，则结果不出现
- 与 /\：若几个原因都出现，结果才出现。若其中有1个原因不出现，则结果不出现
- 输入状态之间的依赖关系(约束)：
- 互斥 E（exclusive）：表示a、b 2个原因不会同时成立，最多有1个可能成立。
- 包含 I（include）：表示a、b、c 3个原因中至少有1个必须成立。
- 唯一 O（only）：表示 a 和 b 当中必须有1个，且仅有1个成立。
- 要求 R（request）：表示当 a 出现是，b 必须也出现。也就是说 a 出现时不可能 b 不出现。
- 强制 M（mask）：表示当 a 是1时，b 必须是0。而当 a 为0时，b 的值不定。
-
局限性： 当原因和结果很多的时候可读性变差
-
综合例子： 有一个处理单价为 2.5 元的盒装饮料的自动售货机软件。若投入 2.5 元硬币，按“可乐”、“啤酒”或“奶茶”按钮，相应的饮料就送出来，若投入的是 3 元硬币，在送出饮料的同时退还 5 角硬币。
分析：
原因：1) 投入 2.5 元硬币；2) 投入 3 元硬币；3) 按“可乐”按钮；4) 按“啤酒”按钮；5) 按“奶茶”按钮。
中间状态：1) 已投币；2)已按按钮。
结果：1) 退还 0.5 元硬币；2) 出可乐；3) 出啤酒；4) 出奶茶画因果图和标明约束条件：
7.2.2 判定表法
-
定义： 判定表是分析和表达多种输入条件下系统执行不同动作的工具，它可以把复杂的逻辑关系和多种条件组合的情况表达得既具体又明确。判定表通常由四部分组成：条件桩、动作桩、条件项、动作项
- 条件桩：列出系统所有输入，列出的输入次序没有影响
- 动作桩：列出系统可能采取的操作，这些操作的排列顺序没有约束
- 条件项：列出针对它左列输入条件的取值，在所有可能情况下的真假值
- 动作项：列出在输入项的各种取值情况下应该采取的动作
-
操作步骤：
- 确定规则的个数。如果有N 个条件，那么规则一共有 2^N 个，如N 为3时，规则数为2×2×2=8 个
- 列出所有的条件桩和动作桩
- 填入条件项和动作项。对各条件项进行标识，一般使用 1 和 0 来标识，当该条件选中时使用 1 来标识，当条件不选中时使用 0 来标识。
- 简化、合并相似规则。简化的过程为，首先找到判定表中输出完全相同的两列，观察它们的输入是否相似。例如只有一个输入不同时，说明不管该输入取何值，输出都是一样的。也就是说，该输入对输出是无影响的，因此可以将这两列合并为一列
- 将每条规则转化为测试用例
-
综合案例：
- 有一个处理单价为 2.5 元的盒装饮料的自动售货机软件。若投入 2.5 元硬币，按“可乐”、“啤酒”或“奶茶”按钮，相应的饮料就送出来，若投入的是 3 元硬币，在送出饮料的同时退还 5 角硬币。
- 修改Notes系统账户密码时，要求首先输入原密码，原密码输入正确后输入两次新密码，要求两次输入的新密码一致，且新密码达到复杂度要求（8-15位，包含字母大小写、数字、字符），密码修改成功后提示用户修改成功，否则提示用户操作失败
- 有一个处理单价为 2.5 元的盒装饮料的自动售货机软件。若投入 2.5 元硬币，按“可乐”、“啤酒”或“奶茶”按钮，相应的饮料就送出来，若投入的是 3 元硬币，在送出饮料的同时退还 5 角硬币。
7.3.3场景法
-
定义： 场景法一般包含基本流和备选流，从一个流程开始，通过描述经过的路径来确定的过程，经过遍历所有的基本流和备用流来完成整个场景。场景法适用于检查程序输入条件涉及的各种组合情况
- 基本流：通常一个业务仅存一个基本流，且基本流仅有一个起点和一个终点
- 备选流：除了基本流之外的各支流，包含多种不同情况
-
综合例子： 某嵌入式系统中，将待发送的数据打包为符合CAN协议的帧格式后，便可写入发送缓冲区，并自动发送。该发送子程序的流程如下：
- 进入发送子程序
- 系统判断是否有空闲发送缓冲区，如果没有则返回，显示发送失败信息
- 如果有空闲缓冲区，将数据包写入空闲发送缓冲区
- 系统判断是否写入成功，如果不成功则返回，显示发送失败消息
- 如果写入成功，则启动发送命令
- 返回发送成功消息
-
推荐画流程图的网站：
- https://app.diagrams.net/（或输入网址draw.io)
- 在线流程图https://www.processon.com/
7.3 补充方法——错误猜测法
- 错误猜测法是根据经验猜想可能有没有什么问题并依次涉及测试用例
- 该方法只能作为测试设计的补充，而不能作为单独用来设计测试用例的方法
八、测试点提取思路
- 首先检测界面元素的显示是否正确
- 测试页面的基本功能。如果页面既有表单（既有输入域又有提交按钮的页面）也有列表，则优先测试表单功能是否正常
- 针对表单在测试时，需要依据表单里面的每个字段依次进行测试。凡是用户可输入的输入域，都要使用等价类和边界值根据字段的约束来进行考虑
- 如果多个字段自建有关联关系和制约关系，那么在测试完单个字段后，应该继续使用判定表、因果法等测试方法进行组合测试
- 表单测试完后，在测试列表中的其他功能
- 当单个页面的内容都测试完毕后，再结合场景法测试流程的相关内容
- 流程分析测试完后，最后再使用错误猜测法来确保没有遗漏的测试点
九、建立需求跟踪矩阵
-
内容（示例）：
-
作用：
- 方便进行用例需求覆盖率统计
- 如果需求发生变更，可以根据需求跟踪矩阵快速定位哪些测试用例需要更新
在执行完测试之后，接着进行软件测试流程的第五步：提交缺陷报告之前，我们需要知道：什么是软件缺陷、缺陷的生命周期、缺陷报告的编写以及缺陷管理中常见的问题如何解决
十、软件缺陷
-
定义：
-
软件没有实现产品规格说明所要求的功能模块；
以计算器开发为例。计算器的产品规格说明定应能准确无误地进行加、减、乘、除运算。如果按下加法键，没什么反应，就是第一种类型的缺陷；若计算结果出错，也属于该缺陷
-
软件中出现了产品规格说明指明不应该出现的错误；
产品规格说明书还可能规定计算器不会死机，或者停止反应。如果随意敲键盘导致计算器停止接受输入，这就是第二种类型的缺陷
-
软件实现了产品规格说明没有提到的功能模块；
如果使用计算器进行测试，发现除了加、减、乘、除之外还可以求平方根，但是产品规格说明没有提及这一功能模块。这是第三种类型的缺陷
-
软件没有实现虽然产品规格说明没有明确提及但应该实现的目标；
在测试计算器时若发现电池没电会导致计算不正确，而产品说明书是假定电池一直都有电的，这为第四种类型的缺陷
-
软件难以理解，不容易使用，运行缓慢，或从测试员的角度看，最终用户会认为不好
软件测试员如果发现某些地方不对，比如测试员觉得按键太小、“=”键布置的位置不好按、在亮光下看不清显示屏等，无论什么原因，都要认定为缺陷。而这正是第五种类型的缺陷
-
-
出现的原因：
- 产品说明书：①说明书没有写；②说明书不够全面、经常更改；
- 设计：产品需求随意、易变、沟通不足
十一、缺陷的生命周期
-
很多情况下，软件缺陷生命周期的复杂程度仅为：软件缺陷被打开（open），解决（resolved）和关闭（closed）
-
在有些情况下，生命周期变得更复杂一些
-
软件缺陷生命周期的通用模型如下
- 审查状态（review）是指：项目经理或者委员会决定软件缺陷是否应该修复。注意，从审查状态可以直接进入关闭状态。如果审查决定软件缺陷不应该修复——可能是软件缺陷太小，不是真正的问题或者属于测试错误——就会进入关闭状态
- 推迟状态（deferred）是指：审查可能认定软件缺陷应该在将来的某一时间考虑修复，但是软件在该版本中不修复
- 从解决状态回到打开状态的附加线涉及软件测试员发现软件缺陷没有被修复的情况，缺陷重新打开，重复新的生命周期
- 从关闭状态和推迟状态绕回打开状态的两条虚线表明：由于软件测试员永远不会放弃，因此原来认为已经修复、测试和关闭的缺陷可能会再次出现。此类软件缺陷一般称为【回归缺陷】。推迟修复的软件缺陷以后也可能被证实很严重，要立即修复。
- 一旦记录了软件缺陷，就要跟踪其生命周期，不要跟丢了，并且提供必要的信息驱使其得到修复和关闭
十二、缺陷报告的编写
12.1 报告内容
- 一份完整的缺陷报告一般包含以下内容：
①缺陷编号；②预置条件；③缺陷标题；④测试步骤；⑤严重程度；⑥优先级；⑦重现率；⑧缺陷状态 - 内容示例：
12.2 缺陷严重程度分类
- 致命： 例如，软件的意外退出甚至操作系统崩溃，造成数据丢失
- 严重： 例如，由于单功能的失效导致多个相关功能均失效
- 一般： 例如，软件的单功能失效
- 提示： 软件界面的细微缺陷，如某个控件没有对齐，某个标点符号丢失等
12.3 缺陷状态分类
- New： 缺陷的初始状态
- Open： 开发人员开始修改缺陷
- Fixed： 开发人员修改缺陷完毕
- Closed： 回归测试通过
- Reopen： 回归测试失败
- Postpone： 推迟不修改
- Rejected： 开发人员认为不是程序问题，拒绝缺陷
- Duplicate： 与已经提交的缺陷重复
- Abandoned： 被Rejected和Duplicate的缺陷，测试人员确认后的确笔试问题，将缺陷置为此状态，Abandoned是一种特殊的Closed
十三、缺陷管理中常见的问题
-
提交的缺陷开发人员不认可怎么办？
依据需求，找产品经理或项目经理介入解决问题
-
如何处理不能重现的缺陷？
①一定要将缺陷提交到缺陷管理库
②一定要详细描述遇到缺陷的过程和相关的配置环境
③如果有日志，一定要附上相关操作日志或系统运行日志
④不可重现的缺陷一定要尽量描述清楚复现率（操作几次出现几次缺陷）
⑤不可重现的缺陷，当开发人员将缺陷设置为fixed后，在验证修复时不能只在一个版本上验证，必须至少在3个以上版本验证后都没有重现过，才能将缺陷关闭
-
如何处理好与开发人员及其他相关人员的关系
提高自身业务能力，提交缺陷专业点，将问题表达清楚，帮助开发人员快速定位问题
-
缺陷太多怎么办？
①系统开发中，不稳定，缺陷多是正常的
②开发人员能力不行
-
找不到缺陷怎么办？
①系统成熟，后期无缺陷，是正常现象
②测试人员能力不行
-
如何处理缺陷跟踪中的扯皮现象？
找需求依据，弄清定义，找人处理
在执行完测试分析与评审之后，接着进行软件测试流程的第七步：提交测试总结之前，我们需要知道：如何编写测试报告
十四、测试报告的编写
-
定义： 测试报告是测试阶段最后的文档产出物。优秀的测试经理或测试人员应该具备良好的文档编写能力；一份详细的测试报告包含足够的信息，包括产品质量和测试过程的评价，测试报告基于测试中的数据采集以及对最终的测试结果分析。
-
基本内容（仅供参考）：
- 引言（目的、背景、缩略语、参考文献）
- 测试概要(测试方法、范围、测试环境、工具)
- 测试结果与缺陷分析（功能、性能）
- 测试结论与建议（项目概况、测试时间 测试情况、结论性能汇总）
- 附录（缺陷统计）
**/================ 我是华丽丽的分割线 ========================================/ **
碎碎念专场╰(￣ω￣ｏ)：
最近放寒假了，除了放飞自我+日常葛优躺以外，其他时间都在狂刷知识点，都是因为自己太菜了(´。＿。｀)
这篇博客是自己刷了好几天的视频+看书总结出来的知识要点，果然刷视频一时爽，整理笔记火葬场o(￣┰￣*)ゞ
作为一名刚入行的新人小白（白敬亭分分分白），写这篇总结笔记是为了自己方便复习，如果能够顺手帮助到其他人，那我会超开心的哦~（小小小得意.jpg）§(￣▽￣)§
写这篇笔记我还发现了一个超好用的MarkDown编辑器：Typora ，墙裂推荐 \ (@ ^ 0 ^ @) /
对辣，今天是农历牛年的最后一天——除夕夜，在此祝路过的各位兄弟虎年大吉鸭ヽ(✿ﾟ▽ﾟ)ノ
