参考学习资料

书籍：《软件测试》[美] 罗恩 佩腾（Ron Patton）著 张小松 王钰 曹跃 等译 机械工业出版
视频： ① B站 – 软件测试全套白嫖：零基础转行精品课，自学完拿不到8K，你找我！https://www.bilibili.com/video/BV13Q4y127ac=16&spm_id_from=333.1007.top_right_bar_window_history.content.click
② B站 – B站最强软件测试教程=软件测试基础+软件测试面试+软件测试项目实战+测试https://www.bilibili.com/video/BV14v411B7p5=78&spm_id_from=333.1007.top_right_bar_window_history.content.click

笔记内容摘要

• 该总结笔记根据上方【参考学习资料】整理而成，部分内容存在删减，不足之处欢迎批评指正，谢谢！

• 笔记中部分图片源自 络搜索，若侵权，请联系博主自删，感谢！

• 笔记内容以【软件测试流程】为主干，其间穿插相关知识要点，总体思维导图如下：
  

1.1 瀑布模型

• 定义： 采用瀑布模型的项目从最初的构思到最终产品要经过一系列步骤。每个步骤结束时，项目小组组织审查，并决定是否进入下一步。如果项目未准备好进入下一步，就停滞下来，直到准备好。

• 内容： 计划→需求分析→设计→编码→测试→运行维护
  

• 优点： 每个阶段都有相应的开发文档支持
• 缺点： ①测试介入太慢，放置在编码之后，忽视了测试对需求分析、系统设计的验证 ②测试的对象只有程序，不包括需求等其他文档内容

1.1.2 W模型

1.1.4 X模型

• 优点： ①发现问题早、成本低；②测试全程参与

• 缺点： 工作量大

1.3 敏捷开发与测试模型

• 定义： 敏捷开发与测试模型主要是为了适应现代互联 公司“短平快”的开发节奏而设计的一种开发和测试模型

• 内容：
  ①迭代：每次迭代叫做一个sprint，每个sprint里面选出来要实现的需求会安排到sprint backlog里面，每个sprint一般是以一个月作为周期；
  ② Product Owner：相当于是产品经理。整理出整个项目的所有需求，并且按照需求的优先级来将需求排列到Produce Backlog；
  ③ Daily Meeting：每日会议，一般是站会形式。每个人发言一般不会超过1分钟，主要内容包括三点：昨天完成的工作、今天准备开展的工作、面临的风险和问题；
  ④ sprint burndown：迭代燃尽图，记录剩余的工作量；
  ⑤ sprint review meeting：迭代回顾会议，主要是去回顾在本轮迭代中存在的问题有哪些、如何改进等；
  ⑥ scrum master：相当于组长，由他来统一管理组员；
  

问题：如何测试一个水杯的质量br> 参考：

1. 互斥 E（exclusive）：表示a、b 2个原因不会同时成立，最多有1个可能成立。
2. 包含 I（include）：表示a、b、c 3个原因中至少有1个必须成立。
3. 唯一 O（only）：表示 a 和 b 当中必须有1个，且仅有1个成立。
4. 要求 R（request）：表示当 a 出现是，b 必须也出现。也就是说 a 出现时不可能 b 不出现。

7.2.2 判定表法

• 定义： 判定表是分析和表达多种输入条件下系统执行不同动作的工具，它可以把复杂的逻辑关系和多种条件组合的情况表达得既具体又明确。判定表通常由四部分组成：条件桩、动作桩、条件项、动作项

  1. 条件桩：列出系统所有输入，列出的输入次序没有影响
  2. 动作桩：列出系统可能采取的操作，这些操作的排列顺序没有约束
  3. 条件项：列出针对它左列输入条件的取值，在所有可能情况下的真假值
  4. 动作项：列出在输入项的各种取值情况下应该采取的动作

• 综合例子： 某嵌入式系统中，将待发送的数据打包为符合CAN协议的帧格式后，便可写入发送缓冲区，并自动发送。该发送子程序的流程如下：

  1. 进入发送子程序
  2. 系统判断是否有空闲发送缓冲区，如果没有则返回，显示发送失败信息
  3. 如果有空闲缓冲区，将数据包写入空闲发送缓冲区
  4. 系统判断是否写入成功，如果不成功则返回，显示发送失败消息
  5. 如果写入成功，则启动发送命令

  6. 作用：

     1. 方便进行用例需求覆盖率统计
     2. 如果需求发生变更，可以根据需求跟踪矩阵快速定位哪些测试用例需要更新

在执行完测试之后，接着进行软件测试流程的第五步：提交缺陷 告之前，我们需要知道：什么是软件缺陷、缺陷的生命周期、缺陷 告的编写以及缺陷管理中常见的问题如何解决

十、软件缺陷

• 定义：

  1. 软件没有实现产品规格说明所要求的功能模块；

     以计算器开发为例。计算器的产品规格说明定应能准确无误地进行加、减、乘、除运算。如果按下加法键，没什么反应，就是第一种类型的缺陷；若计算结果出错，也属于该缺陷

  2. 软件中出现了产品规格说明指明不应该出现的错误；

     产品规格说明书还可能规定计算器不会死机，或者停止反应。如果随意敲键盘导致计算器停止接受输入，这就是第二种类型的缺陷

  3. 软件实现了产品规格说明没有提到的功能模块；

     如果使用计算器进行测试，发现除了加、减、乘、除之外还可以求平方根，但是产品规格说明没有提及这一功能模块。这是第三种类型的缺陷

  4. 软件没有实现虽然产品规格说明没有明确提及但应该实现的目标；

     在测试计算器时若发现电池没电会导致计算不正确，而产品说明书是假定电池一直都有电的，这为第四种类型的缺陷

  5. 软件难以理解，不容易使用，运行缓慢，或从测试员的角度看，最终用户会认为不好

     软件测试员如果发现某些地方不对，比如测试员觉得按键太小、“=”键布置的位置不好按、在亮光下看不清显示屏等，无论什么原因，都要认定为缺陷。而这正是第五种类型的缺陷

• 出现的原因：

  1. 产品说明书：①说明书没有写；②说明书不够全面、经常更改；
  2. 设计：产品需求随意、易变、沟通不足

十一、缺陷的生命周期

• 很多情况下，软件缺陷生命周期的复杂程度仅为：软件缺陷被打开（open），解决（resolved）和关闭（closed）
  

• 软件缺陷生命周期的通用模型如下

  1. 审查状态（review）是指：项目经理或者委员会决定软件缺陷是否应该修复。注意，从审查状态可以直接进入关闭状态。如果审查决定软件缺陷不应该修复——可能是软件缺陷太小，不是真正的问题或者属于测试错误——就会进入关闭状态
  2. 推迟状态（deferred）是指：审查可能认定软件缺陷应该在将来的某一时间考虑修复，但是软件在该版本中不修复
  3. 从解决状态回到打开状态的附加线涉及软件测试员发现软件缺陷没有被修复的情况，缺陷重新打开，重复新的生命周期
  4. 从关闭状态和推迟状态绕回打开状态的两条虚线表明：由于软件测试员永远不会放弃，因此原来认为已经修复、测试和关闭的缺陷可能会再次出现。此类软件缺陷一般称为【回归缺陷】。推迟修复的软件缺陷以后也可能被证实很严重，要立即修复。

12.2 缺陷严重程度分类

1. 致命： 例如，软件的意外退出甚至操作系统崩溃，造成数据丢失
2. 严重： 例如，由于单功能的失效导致多个相关功能均失效
3. 一般： 例如，软件的单功能失效
4. 提示： 软件界面的细微缺陷，如某个控件没有对齐，某个标点符 丢失等

12.3 缺陷状态分类

1. New： 缺陷的初始状态
2. Open： 开发人员开始修改缺陷
3. Fixed： 开发人员修改缺陷完毕
4. Closed： 回归测试通过
5. Reopen： 回归测试失败
6. Postpone： 推迟不修改
7. Rejected： 开发人员认为不是程序问题，拒绝缺陷
8. Duplicate： 与已经提交的缺陷重复
9. Abandoned： 被Rejected和Duplicate的缺陷，测试人员确认后的确笔试问题，将缺陷置为此状态，Abandoned是一种特殊的Closed

十三、缺陷管理中常见的问题

1. 提交的缺陷开发人员不认可怎么办/p>

   依据需求，找产品经理或项目经理介入解决问题

2. 如何处理不能重现的缺陷/p>

   ①一定要将缺陷提交到缺陷管理库

   ②一定要详细描述遇到缺陷的过程和相关的配置环境

   ③如果有日志，一定要附上相关操作日志或系统运行日志

   ④不可重现的缺陷一定要尽量描述清楚复现率（操作几次出现几次缺陷）

   ⑤不可重现的缺陷，当开发人员将缺陷设置为fixed后，在验证修复时不能只在一个版本上验证，必须至少在3个以上版本验证后都没有重现过，才能将缺陷关闭

3. 如何处理好与开发人员及其他相关人员的关系

   提高自身业务能力，提交缺陷专业点，将问题表达清楚，帮助开发人员快速定位问题

4. 缺陷太多怎么办/p>

   ①系统开发中，不稳定，缺陷多是正常的

   ②开发人员能力不行

5. 找不到缺陷怎么办/p>

   ①系统成熟，后期无缺陷，是正常现象

   声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！