软件测试的一些基础知识

1. 什么是软件？

• 软件 = 程序 + 数据 + 文档
• 软件包括系统软件和应用软件
• 应用软件是我们测试的主要对象 ,
  应用软件有两种架构 :
  B/S(浏览器/服务器) 如淘宝,京东
  C/S(客户端/服务器) 如 : qq , 微信

1. 什么是软件测试?

AI答 : 软件测试是软件开发过程中的一个重要环节 , 其目的是确保软件产品满足预定的要求 , 并尽可能地发现和修复缺陷 , 以提高软件的质量和可靠性

搜罗的:
在规定的条件下 对程序进行操作 , 以发现程序的错误 , 衡量软件质量 , 并对其是否能满足设计要求进行评估的过程

规定条件 --> 测试用例
发现程序的错误 --> 找bug
衡量软件质量 --> 根据各项指标评估软件的质量
满足设计要求 --> 是否满足用户需求 , 需求规格说明书 , 概要设计 , 软件设计等

2. 软件测试分类?

1. 按阶段进行划分 : 单元测试 , 集成测试 , 系统测试 (冒烟测试/回归测试), 验收测试(α测试/β测试)
2. 按测试技术进行划分 : 黑盒测试 , 白盒测试 , 灰盒测试
3. 按被测对象是否运行划分 : 动态测试 , 静态测试
4. 按是否手工执行划分 : 手动测试(点点点) , 自动测试(工具/写代码)
5. 按测试对象划分 : 功能测试 , 界面测试 , 安全测试 , 兼容性测试 , 易用性测试(用户体验测试) , 性能测试 , 安装测试 , 文档测试
6. 冒烟测试 , 回归测试

详述 :

一. 按阶段进行划分 :

1. 单元测试 : (一般由开发人员或白盒测试工程师完成 , 主要测试的是程序代码) , 又称模块测试 , 测试的对象是软件测试中最小的单位 : 模块

2. 集成测试 : (一般由开发人员或白盒测试工程师完成 , 把多个模块/函数组装到一起进行的测试) 主要目的是 : 检查软件单位之间的接口是否正确

3. 系统测试 : (一般由黑盒测试工程师完成 , 根据测试用例进行完整的系统测试) 包括 冒烟测试 和 回归测试
   ===> 有严格的顺序 : **先冒烟 , 再系统 , 后回归**
   测试内容 : 功能 , 界面 , 可靠性 , 易用性 , 性能 , 兼容性 , 安全性等
   (1) 冒烟测试 : 在进行正式测试之前 , 对主要的核心功能进行测试 , 一般由测试组长或开发人员来完成 , 如果冒烟测试通过 , 再交由测试人员继续其他测试
   (2) 回归测试 : 开发人员对有问题的部分进行修改之后 , 再一次进行测试(一般不止要测试修改部分 , 还要测试相关联的部分)
   (3) 探索性测试 : 根据经验进行的随意测试

4. 验收测试 : 是用户为主的测试
   (1) Alpha测试 : 测试人员 , 用户 , 公司内部人员 进行的较为集中的对软件进行的测试
   (2) Beta测试 : 正式发型一个Beta版本的软件 , 用户直接下载使用 , 从而进行的软件测试

二. 按测试技术(是否查看代码)进行划分

1. 黑盒测试 : (只看输入,输出) 也是功能测试 , 测试中把被测软件当成一个盒子 , 不关系盒子内部结构是什么 , 只关心软件的输入数据和输出数据
2. 白盒测试 : (看代码的内部逻辑) 又称结构测试 , 透明盒测试 , 逻辑驱动测试等 , 白盒测试是接口测试的一种
3. 灰盒测试 : 结合黑盒测试和白盒测试 , 也就是测试 功能+接口

三. 按被测对象是否运行划分
4. 动态测试 : 运行被测系统时 进行的测试
5. 静态测试 : 界面检查 , 文档检查 , 代码走查等

3. 软件生命周期的各阶段

一. 问题的定义及规划
主要确定软件的开发目的及其可行性 , 制定项目总体开发计划
二. 需求分析
在确定软件开发可行的情况下 , 对软件需要的各个功能进行详细分析 , 明确客户的需求 , 输出需求规格说明书(原型图) , 提交评审
三. 设计
概要设计和详细设计
四. 编码
按照详细设计好的模块功能表 , 编程人员编写出计算机可运行的程序代码
五. 软件测试
单元测试 --> 集成测试 --> 系统测试 --> 验收测试
六. 运行与维护

4. 几个模型—瀑布模型 , V模型 , 敏捷开发模型

一. 瀑布模型----按照固定的顺序 按部就班的 执行流程]
缺点 : 不灵活 , 不适合现代软件开发 (该模型现在基本不被使用)

二. V模型

三. 敏捷开发模型
以人为主的模型 , 简单来说就是通过有计划地会议 , 快速传达需求以及要做的事情 , 从而提高软件开发效率

5. 软件测试基本流程

大框:
需求分析 -> 测试用例的编写及设计 --> 测试执行 --> bug及bug跟踪 --> 通过
口述:
不同类型的软件产品测试的方式和重点不一样 , 测试的流程也会不一样 , 同类型的产品 , 不同公司所制定的测试流程也会不一样 , 但是它们所遵循的最基本的测试流程是一样的 : 分析测试需求 --> 指定测试计划 --> 设计测试用例 --> 执行测试用例 --> 编写测试报告
软件测试流程图

（1）需求分析

• 什么是测试需求分析？

1. 根据需求规格说明书 明确测试内容，去细分需求（提取测试点）
2. 什么是测试点？–》软件包含多个功能点，每个功能点包含多个子功能（测试点），测试点是软件功能细分的最小单元

• 需求分析的目的？

1. 测试需求分析是编写测试用例的依据
2. 有助于保证测试的质量与进度
3. 测试需求是衡量测试覆盖率的重要指标

简单的说就是 ：只有明确了测试需求，才能知道怎么去测试；什么时候开始测试；要多少人测试；在什么环境上测试

• 测试需求分析具体怎么来进行分析？

需求分析的步骤

查阅需求规格说明书（原型图）–》初步熟悉被测软件的核心业务流程–》再针对某个功能，细化需求，列出测试点

一个页面如何进行测试需求分析

测试思路：

1. 进行界面检查–》参考原型图，查看界面是否一致
2. 依次分析每个输入项，按照从上到下，从左到右的顺序来进行分析–》分析那些方面？
3. 分析哪些方面？
   （1）正常功能：是否可以正常提交
   （2）单个功能项验证（正常+异常）
   规则：按顺序从上至下，对每一个输入项进行验证
   a. 数据长度、数据类型验证、必填项验证、重复
   b. 限制约束验证
   c. 隐形需求（一些需求说明书中没写的，按照经验，充分熟悉产品业务，挖掘隐形需求）
4. 按钮 （功能交互验证）
   a. 根据业务逻辑的先后顺序来进行依次分析 一般要考虑 ：什么条件可以操作成功？什么条件导致操作失败？验证操作结果（b中是详述）？
   b. 需要验证按钮操作结果–》验证交互功能（验证关联功能）–》比如验证登录成功 是需要进入首页，能够展示个人信息；比如验证注册成功 是需要注册的账号能登录成功
5. 非功能性测试
   界面、易用性、兼容性、安全性、性能压力

• 一些面试题

1. 遇到隐形需求怎么办？
充分熟悉产品，参考成熟产品，站在用户的角度，从而挖掘需求
2. 给你一个带有logo的水杯，你会如何去测试？
这个主要考察 测试思维 可能会随便让你说一个东西或者什么东西怎么测–》比如口罩，耳机，笔等等

功能 ： 装水–》是否漏水；装热水，冰水，茶水，饮料是否保温
非功能
界面：logo是否与原型图一致，是否美观，是否掉色，材质如何
易用性：防滑，防烫，带手把，会不会刺到嘴巴，携带是否方便
兼容性：是否能装其他的液体
安全性 ：装热水的时候，会不会有毒
性能：防摔，挤压

3. 你会如何去测试朋友圈，购物车等熟知的软件产品（支付，优惠券，二维码）？

（2）编写测试用例

测试用例八大要素

1. 测试标题

特点：言简意赅

2. 测试项目
所属用例模块 --》也就是测试的是什么项目（细分功能）

eg. 所属用例模块：灰度-视图配置

3. 用例编码
格式 ：产品名-测试阶段（it st uat）-测试项-xxx 【必须是唯一的】

it 集成测试（接口测试） st 系统测试 uat 验收测试 

4. 优先级（重要级别）

级别 ：高/中/低  
各个企业可能有自己的优先级规定，比如：P1,P2,P3,P4 

5. 前置条件

需要满足的一些条件
比如：我要验证一个按钮好不好用，那前置条件就是 ：在页面上添加这个按钮

6. 操作步骤
就是咋给这个需求搞出来，怎么做的，一步一步 挨个写出来（虽然，企业里有一些用例根本不会写操作步骤，也有很多写的很简单）
7. 期望结果
按照上面的操作步骤，应该有什么样的结果
8. 执行结果
一般会有 ：成功、失败、阻塞
可能还会有：跳过、删除、编辑等等

成功和失败很好理解 ---》一般当一个用例测试**失败**的时候--》可能会让你写个备注--》表示清楚bug是啥样的，为啥失败等等

有一些关于用例设计的问题我们需要去思考一下

1. 用例是根据测试点进行编辑的 , 是不是要针对每一个测试点 都要编辑一条用例?

肯定不是 , 因为一些测试点可能是重复的 , 测试效率低

2. 具体是怎么来编写测试用例 , 多个测试点对应一个用例 ?

怎样不重复测试? 	避免重复测点的覆盖

3. 编写测试用例的时候 , 如何选择测试数据进行测试 , 怎么达到最大的覆盖情况 , 用最少的测试数据 , 来获取更多的bug?

编写测试用例 需要的方法及技巧 -->看下面的测试方法

6. 用例的设计方法

等价类
边界值
场景法
错误推断法
因果图判定法

一些面试题

1. 用例需要评审吗？紧急情况也需要评审吗？
2. 如果被测项目很紧急，来不及写用例，怎么办？
   xmind列出测试点—随后补充完善用例
3. 遇到隐形需求如何写用例？
   熟悉功能，参考成熟铲平，站在用户的角度挖掘需求
4. 用例有没有优先级？如果一定要有优先级，依据什么来确定呢？
5. 如何编写测试用例？
6. 编写测试用例会用到什么方法？

灰度测试和A/B测试

灰度测试：先发布部分功能，然后看用户的反馈，再去发布另一部分的功能的更新
A/B测试：先发布的功能先让A部分的用户进行更新，再根据用户的反馈，再更新B部分的功能

区别就是 
灰度测试是 按功能发布 就是先发布一部分功能 看看咋样，然后再发布另一部分功能
A/B测试是 先发布所有的功能给A用户群体 看看咋样，然后再给B部分的用户发布