测试理论与方法----测试流程的第四个步骤：执行测试，提出缺陷

8、执行测试—–>提交缺陷报告

测试流程：执行测试—–>提交缺陷报告

1、缺陷的概述（回顾）

结果角度：实际结果和预期结果不一致

需求角度：所有不满足需求或超出需求的，都是缺陷

2、缺陷的相关属性

1. 概述：指的是在执行测试时，一旦发现缺陷，可以从哪些角度来描述缺陷

2. 缺陷属性

   • 缺陷类型：根据缺陷的自然属性来划分缺陷类别

     参考：功能缺陷，性能缺陷，UI界面缺陷，文档缺陷，系统/模块接口之间的缺陷，代码缺陷…(参考禅道给出的BUG类型)

   • 缺陷的严重程度：指的是发现的缺陷对软件产品使用时产生的影响

     致命：主要功能完全丧失，用户的数据遭到破坏/泄露，死机，崩溃，闪退且不可恢复，甚至危及人身安全（S1）

     严重：主要功能部分丧失，次要功能完全丧失，数据不能及时保存，软件闪退但重启可以恢复（S2）

     一般：系统次要功能部分丧失，但是不影响用户的使用，提示信息不准确，等待时间长，界面差（S3）

     较小(建议型缺陷)：使用不太方便，错别字，排版重叠，设计不合理….（S4）

     扩展：其他的划分：致命P1 严重P2 一般P3 瑕疵P4 建议P5

   • 缺陷的优先级：指的是发现的缺陷被修复的紧急程度

     立刻修复P1：该缺陷导致系统主要流程走不通，测试工作无法进行，需要开发立刻修复

     高优先级P2：缺陷严重，影响测试，需要优先考虑修复

     正常排队P3：提交的缺陷按照顺序等待开发进行修复

     低优先级P4：提交的缺陷等开发有时间再进行修复

     还有一些简洁化分：高 中 低

     注意：一般情况下，缺陷的严重级别越高，修复的紧急程度也会高；但是，修复的优先级高，对应的严重程度不一定高。

   • 缺陷的状态：指的是在缺陷的生命周期中，不同阶段所处的不同状态，体现的是一个缺陷被跟踪修复的过程

   1. 缺陷的生命周期

      

   2. 缺陷状态

      激活或打开：指的是缺陷提交后，公开给开发以及相关人员看到

      已修复或已修改：开发认可了缺陷，并按照缺陷的描述在代码中进行了修改问题(测试人员还未验证)

      关闭：开发修复了缺陷，测试验证没有问题，就可以关闭缺陷

      重新打开：开发修复后，测试验证未通过，缺陷还存在，就把缺陷状态更新为打开

      推迟修复：该缺陷不在当前版本修复，放在下一个版本进行修复，但是必须要有相关的负责人进行确认，不能关闭，持续跟踪

      保留：缺陷是由于第三方导致的，公司无权限进行修复，缺陷一直要保留，等待第三方授权/帮助进行解决

      不能复现：指的是开发人员按照测试人员提供的复现步骤，不能重现该bug，原因可能是测试人员提供的缺陷描述或复现步骤不详细/不清楚，我们可以提供一些BUG截图，录制demo视频，日志文件(记录一些报错信息)，都能作为证据帮助开发人员进行复现

      重复：同一个缺陷被多个测试人员提交，可以合并或删除

      不是缺陷：直接删除

   • 缺陷的起源：指的是缺陷第一次被发现的阶段

     需求阶段

     架构设计阶段

     编码阶段

     测试阶段

     用户使用阶段

   • 缺陷的来源：引发缺陷的起因

     需求说明书：描述不清楚，错误

     设计文档：概要设计，详细设计与需求描述不符合

     数据库：约束规则，数据类型不合理

     代码：代码编写不严谨

   • 缺陷的根源：指的是发生错误的根本原因

     测试策略：错误的测试范围，未明确测试类型

     工具和方法：不适用的管理过程，工具和方法不匹配当前测试流程

     人员：人员安排不合理，工作职责不明确

     测试环境：硬件，软件，网络环境

3、缺陷报告编写

1. 概述：记录在执行测试过程中发现的缺陷，对缺陷进行相关的汇总和描述

2. 包含的模块

   缺陷编号	所属模块	优先级	严重程度	缺陷概述	缺陷描述	提交人	备注

   缺陷编号：给找到的每一个缺陷生成唯一的序列号

   参考写法：Bug_项目名称 _模块名称 _子模块名称 _0001

   所属模块：写上发现的bug所属的模块 一级模块/二级模块/三级模块…

   优先级：P1 P2 P3 P4

   严重程度：S1 S2 S3 S4

   缺陷概述：一句话总结或描述所发现的缺陷，用简洁清晰语言，把问题现象说清楚即可

   缺陷描述(最核心)：

   复现步骤：把缺陷产生的操作步骤写清楚（参考测试用例测试步骤）

   实际结果：按复现步骤操作产生的结果

   预期结果：按复现步骤应该会出现的结果

   提交人：写上提交缺陷人员名字

   备注：上传一些缺陷截图，demo视频，日志信息，测试用例编号…

3. 缺陷报告目的/作用

   1. 易于搜索查找缺陷的信息
   2. 描述的缺陷更为详细，准确
   3. 开发人员想获取缺陷本质和复现步骤
   4. 市场或其他人员想获得缺陷类型以及会对用户产生的影响

4. 预期读者：开发，市场，产品，运维，管理….

5. 缺陷报告编写准则：5C准则

   准确（correct）：每个模块组成部分的描述都是准确的，不能引起误解

   清晰（clear）：易于理解

   简洁（concise）：只包含必不可少的内容，多余的信息不用出现

   完整（complete）：复现步骤，预期结果，实际结果

   一致（consistent）：按照一致的格式来编写缺陷报告

4、禅道的使用

1. 了解模块：

   【后台】：部门组织，权限，用户管理

   【项目集】：创建项目集，创建项目
   【产品】：创建产品

2. 掌握操作模块：

   【BUG】：提bug，对bug进行跟踪和管理

   【用例】：创建用例，执行用例，转BUG

---

缺陷报告

模板：

• 缺陷编号
• 所属模块
• 缺陷概述(一句话描述发现的问题现象)
• 缺陷描述(复现步骤，实际结果，预期结果)
• 缺陷严重程度(S1-S4：致命，严重，一般，较小(建议))
• 缺陷优先级
• 备注

---

9、Web测试

1. WEB端应用程序测试点分析(掌握)

   1. 功能测试
   2. 性能测试
   3. 安全测试
   4. 配置兼容性测试
   5. 易用性测试

2. WEB功能测试

   1. 概述：WEB端应用程序—–>网站类型项目—–>B/S架构的软件——>浏览器

   2. 链接测试：实现页面之间的跳转

      测试点：

      • 链接是否正确
      • 链接是否存在
      • 是否有孤立的页面(没有链接能指向该页面)

   3. 表单测试：用于搜集用户的输入项

      测试点：

      • 表单控件的正确性
      • 提交数据信息的正确性、完整性
      • 是否有错误处理

   4. cookie和session测试

      1. 概述：用于记录用户的相关信息，一般cookie是在本地形成的记录文件，session是在服务器端生成的记录文件，最典型的场景：访问WEB程序，选择记录账号和密码

      2. 测试点：

         • 登录成功后，检查是否会生成相关的cookie和session文件
         • 考虑到cookie和session是否设置了过期时间，如果有设置，一旦过了时间，看是否会提示再一次输入
         • 退出登录时，系统是否会清除cookie和session文件
         • 考虑到cookie和session中是否存在敏感的数据，这些数据是否会被进行加密处理

         小总结：检查cookie和session是否可以正常工作，是否可以按照既定的时间来进行内容的保存

   5. 设计语言的测试

      测试点

      • 考虑用到的html版本

      • 允许使用的脚本语言以及版本

      • 允许能够使用的空间元素

3. 性能测试：依赖于测试工具

   1. 速度测试：响应时间，一般不超过5秒

      影响响应时间的因素有很多：①应用程序使用时所获取大量的数据；②硬件影响，比如设备老化；③网络环境的影响；④所访问页面的大小

   2. 负载测试：验证在一定的条件下，应用程序能够支持到的最大并发用户数量或单位数据的吞吐量，测试时，，增加用户的数量，平均响应时间就会增加，当达到用户的临界点时，就可以看成是系统能够接收到的并发用户数

   3. 压力测试：测试应用程序会不会崩溃，在什么样的场景下会崩溃，崩溃之后产生的结果(做一些破坏性质的操作)；在进行性能测试时，通常将压力测试和负载测试结合在一起使用：在负载测试的基础上，增大负载量，直到系统崩溃

4. 安全测试

   1. 操作系统方面：确认操作系统的安全性，避免因操作系统的漏洞，病毒等导致WEB应用程序的安全性问题

   2. 数据库方面：确认数据库的安全性，防止数据的丢失，对于敏感且重要的数据是否要考虑约束或进行加密处理

   3. 业务功能方面：确认业务场景和业务流程的安全性。以登录功能为例：测试点：

      ①用户名和密码的设计是否符合规范要求；

      ②登录成功后，用户是否可以自定义账号和密码；

      ③检查允许错误登录的次数限制；

      ④检查是否可以在不登录的情况下进行页面的访问操作；

      ⑤长时间页面未进行操作时，是否提示重新载入操作

   4. 系统设计方面：保证系统相关的日志文件是能够记录WEB端应用程序的主要操作；通过日志文件能够获取到相关的操作；保证日志文件相关信息的安全性和完整性，防止非法入侵或损坏；进行加密技术引入时，要保证加密和解密后的数据一致性，正确性。

5. 配置兼容性测试

   WEB应用程序主要考虑【浏览器】的兼容性，使用不同的浏览器对于WEB页面的显示，访问，操作等是否存在差异化；其次，考虑操作系统平台的兼容性，硬件资源，软件资源环境的兼容性等。

6. 易用性测试

   1. 概述：指的是用户在特定的环境下使用软件功能做操作时，所具备的有效性，效率，用户主观满意度

      有效性：软件功能操作达到最终目标所具有的正确性和完整程度

      效率：在有效性的基础上，还要考虑响应时间，处理速度等问题

      用户主观满意度：接受程度，用户体验，好不好用…

   2. 测试点：

      1. 功能是否可以成功的完成一个任务流程(功能的正确性)

      2. 完成任务时所需要的时间

      3. 完成任务时所需要的访问页面数

      4. 系统是否提供了层次结构清晰，表达清楚的导航功能

      5. 提示的信息是否准确

      6. 对整个系统的使用感受如何(形式)