测试理论与方法

一、软件测试流程

1、软件测试定义

软件：程序+数据+文档：不仅仅包含应用程序，还应该包含和这个程序相关的数据，文档
软件测试：测试的对象：应用程序，数据，文档
软件分类（了解）：
1. 按照应用范围划分：系统软件（各种操作系统windows、Linux、ios…）应用软件（QQ，微信…）
2. 按照组织(授权)划分：开源软件(免费)，闭源软件(商业，收费)
3. 按照架构划分：单机软件(不依赖于网络)，分布式软件(B/S架构软件，C/S架构软件)
  
  B/S：浏览器/服务器，指的是这一类软件都依赖于【浏览器】—–>WEB端应用程序—–>各种网站类型的项目，比如：学员后台管理系统
  
  C/S：客户端/浏览器，指的是这一类软件都是有专属的【客户端】，比如：QQ，微信…
4. 缺陷判定
  1. defect：缺陷；bug：原意“臭虫，虫子”，现在更多指向“错误，缺陷”
  2. 缺陷(判定方式一)：软件操作的实际结果和预期结果不一致。(掌握)
    
    例：多边形判定小程序：点击三变形按钮：预期结果：图案显示三边形，实际结果：显示五边形；输入3,4,5三条边：预期结果：提示“直角三角形”，实际结果：提示“普通三角形”
  3. 缺陷(判定方式二)：
    
    ①产品说明书：产品需求说明书，指明了一个软件应该包含哪些功能，以及不能出现的功能。
    
    ②软件未实现产品说明书的功能
    
    例：设计计算器小程序：实现加减乘除四个功能，但测试：只有加减乘，少了除的功能—–>提出bug
    
    ③软件出现了产品说明书上指明不应该出现的功能
    
    例：计算器小程序可以实现任意数据的加减乘除操作，但测试：输入过大的数据进行计算，小程序突然闪退、崩溃…
    
    ④软件实现了产品说明书上未提到的功能
    
    例：计算器实现加减乘除四个功能，但测试：多了一个开平方功能—–>提bug
    
    ⑤软件未实现产品说明书虽未明确提及，但是也应该实现的目标（隐式需求）
    
    例：手机——>相机——>闪光灯功能：当电量过低，该功能无法使用——>虽然说明手册没有过多描述，但大部分手机都存在的情况
    
    ⑥软件难以理解，不太好用，运行缓慢或从测试的角度来看，最终用户会认为不好的—–>提BUG
    
    小总结：
    
    结果角度：实际结果≠预期结果
    
    需求角度：所有不满足需求或超出需求的，都是缺陷
5. 软件测试的定义：
  1. 正向思维：—–>开发
    
    使自己确信产品能够正常工作的，来评价(测试)一个软件或系统(被测软件)的功能或特性，并确定它是否可以达到预期结果，测试就是以此为目的。
  2. 反向思维：—–>测试原则
    
    测试是为了发现错误而执行一个程序或系统的过程，测试是为了证明程序是有错的，而不是无错的，一个成功的测试在于发现了之前未发现的错误
  3. IEEE(电气电子工程师协会)：
    
    在规定条件下(测试环境)下，运行系统或构件(被测软件)：观察和记录结果(实际结果)，并对系统或构件(功能)的某些方面给出评价。（实际结果和预期结果）
  4. 广义的软件测试：——>工作经验总结
    
    ①软件测试是对软件形成过程中所有的工作产品(应用程序+数据+文档)进行的测试，不仅仅只是应用程序
    
    ②软件测试的工作应该贯穿于【软件的生命周期】中，只要软件不被淘汰，测试的工作就要一直进行。
    
    例：软件的生命周期：从无到有，再到淘汰的过程
    
    ③软件测试的工作是对整个软件产品进行【确认】和【验证】的活动过程。(掌握)
    
    确认V：validation，提供客观的证据证实软件需求中的功能是否都已经实现。（证实需求）
    
    验证V：verification，提供客观的证据证实功能结果的正确性或合法性。（证实结果）
    
    例：开发计算器小程序：确认：证实加减乘除四个功能都实现；验证：证实加减乘除四个功能操作结果的正确性
    
    一句话总结：确认就是确保自己做了对的事情，验证就是确保自己把事情做对了

2、软件测试目的（掌握）

①以最少得人力，物力，时间的投入，尽可能早的和不断地发现软件中潜藏的错误和缺陷，并保证得以修复。

②同时利用测试过程中产出的数据和信息，作为后续项目版本进行测试时的重要参考依据，避免再发生同样的问题。（妥善保存好测试产出物）

问题：软件测试的工作是否可以提高软件产品的质量？

软件测试可以保障软件产品的质量，想要提高产品质量，还得依赖于开发。（软件开发—–>代码的编写）

3、测试与调试的区别（了解）

在软件开发过程中，经常会遇到两种操作行为：

调试：debug，主要针对开发工作而言，调试的对象：代码—–>调试代码
测试：test/testing，是全过程的，是针对整个项目开发过程来进行的，测试的对象：应用程序，数据，文档
调试的目标：零错误，没有错误（毕竟调试的是代码，代码有错是不会运行），调试的方式：比较依赖于工具
测试的目标：“零”缺陷，并不是数字0，指的是发布后的软件，虽然有缺陷，但是用户可以接受和容忍。测试的方式：手工，工具

4、软件测试的流程（掌握）

从【项目立项】开始，软件测试的工作就要进行开展了

软件生命周期：项目立项—–>需求分析—–>设计，编码，测试——>产品发布—–>运行维护——>淘汰

测试流程：

获取测试需求—–>编写测试计划—–>制定测试方案—–>设计测试用例—–>执行测试——>提交缺陷—–>缺陷分析与评审——>提交测试总结报告——>准备下一个版本的测试

面试问法：请说一下你在上一家的工作流程是什么样的？

5、软件测试工作流程第一个环节：提取测试需求—->测什么

软件测试工作流程第一个环节：提取测试需求

软件需求的定义：
1. 用户解决问题或实现目标时，所需要的条件或权能
  
  例：用户实现QQ注册操作：需要的条件：输入昵称，密码，手机号，勾选协议条款
2. 系统或系统部件要满足的合同，标准，规范所需要的条件或权能。
  
  备注：系统或系统部件：指的是软件中的每一个功能，操作该功能时，它的每一个输入项或输入条件需要遵守的规则或限制
  
  例：QQ注册功能：昵称：不能为空，长度限制，组合形式；密码：不能为空，长度限制，组合形式
1.1和1.2中提到的这些条件或权能，整理成文档，就形成了【软件需求】，包含了功能方面的需求和非功能方面的需求
软件需求分类：
1. 业务需求：指的是从软件的【业务层面】来进行内容分析，包括业务场景，业务流程，要实现的业务目标和需要的约束条件。
2. 系统需求：指的是功能，非功能的需求点
  
  功能方面的需求：指的是开发人员要实现的软件功能
  
  非功能需求：一般指向性能方面的需求（除功能以外的其它需求）
  
  例：微信：上传头像—–>功能性需求；上传头像的快与慢—–>非功能性需求
3. 测试需求（test requirement）：
  1. 测试需求和软件需求关系：
    
    为了实现软件的目标，通常掌握了软件需求之后会开展一系列的测试活动，而测试需求的提取往往来源于（业务需求和系统需求=软件需求）软件需求
  2. 定义：测试需求是测试人员在【需求阶段】，经过【多方渠道】收集的需求，会进行【可测性分析】，最终产生的这些需求点，才被称为“测试需求”
    
    多方渠道：主要是产品需求说明书/需求规格说明书，还可以参考项目合同书、计划书、沟通纪要等等
    
    可测性分析：指的是提取出来的这些需求，将来一定是可以测试的，会有预期结果的产生。
4. 测试需求分析意义：
  1. 明确测试范围：测什么
  2. 明确测试类型，测试阶段
    
    测试类型：功能测试，非功能测试
    
    测试阶段：一般指向是按照开发阶段来划分测试流程：单元测试，集成测试，确认测试，系统测试，验收测试
  3. 识别需求的优先级：优先级的确定，可以清楚项目的核心功能，以及客户最为关注的模块点，由此也可以确定测试的工作重心

回顾

反向思维软件测试定义
验证和确认
缺陷定义
软件测试的目的
软件测试的流程
软件的生命周期
测试需求

测试需求阶段的输入与输出

第一个小阶段：收集测试需求

输入：参考文档，主要的是需求文档：需求规格说明书SRS，产品需求说明书PRD

输出：原始测试需求列表(相当于第一版整理出来的测试需求)

第二个小阶段：分析测试需求

输入：原始测试需求列表

输出：测试需求跟踪矩阵或 Xmind整理测试需求 ——>“测什么”

第三小阶段：需求评审

输入：测试需求跟踪矩阵或 Xmind整理测试需求 ——>“测什么”

输出：评审结果

评审的意义/目的：将产出物中有遗漏的，不一致的，错误的地方给审查出来。

6、测试需求的提取

Xmind，测试需求跟踪矩阵—–>提取测试点

案例：提取163邮箱注册功能的需求点

Xmind：tab键生成子模块，enter键生成同级别模块

提取测试需求的参考思路：

①把软件中每个功能模块先划分出来

②再看每个功能模块所需要的条件(输入项/输入条件)

③分析出每个输入项/输入条件的约束规则(既要考虑正向规则，也要考虑反向的规则)

④测试需求的提取，不仅要关注好正向需求(满足规则下的需求)。还要关注好反向需求(违反规则的)，而且在进行测试需求提取时，多来关注反向测试需求点，但是对应的条件没有反向就不用考虑。

测试需求跟踪矩阵：

需求编号	功能点名称	需求描述	需求拆分	测试类别	测试要点	测试负责人	优先级

需求编号：给提取的每一个需求生成的唯一序列号 0001-9999

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

注意：名称：英文单词或汉语拼音首字母比如：注册——ZC；如果模块名称发生了改变，编号要重新开始0001

功能点名称：写的是分析出来的功能点

例：注册功能，登录功能，借贷功能…

需求描述：就是把找到的功能点的作用描述出来

例：实现新用户注册操作，实现用户的登录操作，实现用户的借款操作

需求拆分：把该功能点的输入项写出来

例：手机号快速注册：手机号密码协议条款

测试类别：

正向（满足规则的需求）

反向（违反规则的需求）

测试要点：每个输入项要遵守的约束规则

例：手机号：不能为空存在为空不存在

测试负责人：写上测试人员的名字

优先级：需求的优先级高中低

7、评审

需求评审的意义：
1. 将需求中不合理，不完善，遗漏的，不一致的，错误的找出来，进行修复或完善
2. 缺陷往往在需求阶段(需求规格说明书)比代码阶段发现的更多。为什么？
  
  ①需求大部分来源于客户/用户，客户基本上也都不懂技术，相关的技术人员和客户沟通会存在困难
  
  ②在需求阶段软件还没有进行编码实现，只能依靠于想象来进行分析，所有有些特性不是很明确
  
  ③需求不断变更，也没有及时同步
  
  ④需求阶段的工作没有得到重视
  
  ⑤不同的角色对需求的理解不一致
3. 缺陷在需求阶段修复的成本最低。为什么？
  
  因为需求阶段修复的大部分都是文档
需求评审的方式：
1. 相互评审，交叉评审
2. 轮查
3. 走查
4. 小组评审
5. 审查
评审记录表：把评审过程中发现的问题记录在该表中