文章目录
软件测试的生命周期
有人看完上面这个图就会想，这不是和前面说过的软件生命周期差不多吗？没错，就是因为软件测试贯穿软件的整个生命周期，所以在软件开发的每个阶段，对应的都有测试需要干的工作
软件测试的各个阶段
| 阶段 | 内容 |
|---|---|
| 需求分析 | 看看软件需求设计上是否存在业务逻辑错误、冗余、冲突等问题 |
| 测试计划 | 制定测试计划：什么时候开发测试，什么时候结束测试，耗时多久 |
| 测试设计与开发 | 编写测试用例 确定测试方法，测试工具，测试形式等等 |
| 测试执行 | 充分利用测试用例和测试工具对项目尽可能做到全方面的测试覆盖 |
| 测试评估 | 产出一个测试报告 |
| 上线 | 测试线上环境 |
| 运行维护 | 由于测试人员对项目产品的业务和操作非常了解，加上测试人员的沟通表达能力一般都比较强，所以测试人员可以参与用户使用软件的培训，在试运行项目时收集问题并及时反馈给相关负责人 |
线上环境
实际在工作中，上线要分成多个步骤：沙盒、小流量、全流量、全线上。
为什么又要细分这几个阶段呢？因为上线的过程中也可能会存在问题，即使线下测试没有问题，如果直接推到线上可能会发现问题。
- 沙盒：企业内部的线上环境，可以供内部人员进行测试；
- 小流量：部分线上真实的用户可以使用到，测试人员要在线上手动测试，还要观察有没有错误日志，还要接收用户在使用过程中发现的问题；
- 全线上：所有的真实用户都可以使用到
线上环境和线下测试环境并不是完全一样的，因此每一步都需要跟进测试。
测试中的BUG
测试中的BUG和我们开发中的BUG有些不一样
- 首先，如果你程序中实现的功能和软件需求中提到的功能不一样，那不管它有没有报错，它就是BUG！
- 如果用户用的不舒服，即使程序完全符合软件需求，这也是BUG
比如下面这个例子，软件需求中没有规定按钮的大小，但是用户看着不好看，这也算BUG
描述测试BUG
描述bug的基本要素：问题出现的版本、问题出现的环境、问题出现的步骤、预期结果、实际结果
举个例子，看下面的网页，在谷歌浏览器上呈现出来，它的二维码会被登录界面遮住。这个问题应该怎么描述呢？
BUG的级别
为啥要定义BUG的级别？
- 同时存在多个BUG，我要优先修复级别更高的BUG
- 评价一个程序员的绩效，不仅要看他工作中出现BUG的数量，还要看他搞出来的BUG的级别，搞出BUG越严重，那他就越菜
BUG有哪些级别呢？
bug级别一般分为：崩溃、严重、一般、次要
BUG的生命周期
测试与开发发生争执怎么办？
测试与开发会发生啥争执？
- 测试说：你这个BUG的级别是崩溃级别
- 开发说：我觉得我这个BUG不至于级别那么高
为啥会发生这样的争执？
- 测试找的BUG越多，绩效越高
- 开发出现的BUG越多，绩效越少
测试与开发发生争执怎么办呢？
- 先反思自己BUG描述得清不清楚
- 从用户使用感受的角度说明问题
- 根据公司BUG定级文档，给出自己BUG定级的依据
- 不仅指出问题，最好还要给出解决方案
- 如果前面四条不管用，就发起BUG评审，让第三方来评判
BUG评审
BUG评审的三个代表
- 测试代表
- 开发代表
- 产品代表
BUG评审要解决的两个问题
- 如何解决这个BUG
- 如何预防这个BUG