软件测试——基础篇

软件测试的生命周期

软件开发的生命周期

需求分析—计划—设计—编码—测试—运行维护

软件测试的生命周期(软件测试的流程)

需求分析—测试计划—测试设计/测试开发—测试执行—测试评估

每个阶段需要做什么

1. 需求分析：验证需求的正确性，合理性，细化需求，找出测试项，写测试用例
2. 测试计划： 确定测试人数，测试环境，测试时间，测试设备
3. 测试设计/测试开发：根据需求写测试用例
4. 测试执行：开发已经完成，执行测试用例，验证功能，如果有BUG，提交BUG，验证BUG
5. 写了多少测试用例，执行了多少，剩余了多少测试用例，BUG数量以及解决的BUG数量，遗留的BUG以及解决方案

如何描述一个BUG

一个合格的BUG描述应该包括以下几个部分：

1. 测试版本号：开发人员需要知道出现问题的版本，才能够获取到对应版本的代码来重现故障，并且版本的标识也有利于统计和分析每个版本的质量
2. 测试环境：环境分为硬件环境和软件环境，如果是web项目，需要描述浏览器版本（哪一款浏览器，浏览器版本号…），客户机操作系统等，如果是app项目，需要描述机型，分辨率，操作系统版本等。详细的环境描述有利于故障的定位
3. 测试数据
4. 测试步骤
5. 测试实际结果
6. 测试预期结果
7. 附件，错误日志，错误截图等等

BUG的级别

注意：没个公司都不一样，这里只是普遍的情况

1. 崩溃：系统无法正常运行，出现崩溃，操作死锁，死循环，黑屏，阻碍测试人员的工作
   注意：这里有一个实际情况，如果线上出现了崩溃情况我们该如何去办？怎么补救？————》回退到上一个稳定的版本
2. 严重：系统运行，但是不稳定，继续运行下去会造成严重的损失，重要的功能没有实现，或者功能和需求不符合，数据库中用户数据存储错误，威胁到用户的安全（信息，财产）
3. 一般 ：次要的功能没有实现，或者有错误，系统可以稳定运行
4. 建议 ：功能全都实现，但会影响用户的体验，如：排版，颜色不符合大众审美，信息没有换行，或者提前换行

BUG的生命周期

因为BUG和开发人员冲突该怎么办？

1. 检测BUG是否描述清楚
2. 从用户的角度去说服开发人员修改
3. BUG定级要有理有据（根据公司的规范）
4. 作为测试人员要不断提升自己的业务水平和技术水平，不但能够发现BUG，并且能够定位，还能提出解决方案
5. 不要争吵，找产品经理讨论：三方会议，测试人员，开发人员，产品经理会讨论这个BUG的最终解决方案