软件测试相关内容第三弹--软件测试基础
写在前：在前篇的两篇博客介绍中我们主要学习软件测试的相关概念，对软件测试进行了初步的了解，本篇博客将进一步进行学习。重点内容包括：软件测试的生命周期、如何描述一个bug、如何定义bug的级别、bug的生命周期以及在实际工作中如果产生争执如何办。
目录
1. 软件测试的生命周期
2. 如何描述一个BUG
2.1 发现问题的版本
2.2 问题出现的环境
2.3 错误重现步骤
2.4 预期行为的描述
2.5 错误行为的描述
2.6 其他
2.7 不要把多个bug放到一起
3. bug的级别定义
4. bug的生命周期
5. 人际关系
6. 如何开始第一次测试
6.1 充分理解需求
6.2 确定测试计划
6.3 执行测试
6.4 项目上线+维护
7. 测试的执行和BUG管理
7.1 进行测试
7.2 如何发现更多的bug
1. 软件测试的生命周期
需求分析 - 测试计划 - 测试设计 - 测试开发 - 测试执行 - 测试评估
需求分析：需求是否完整、需求是否正确。
测试计划：确定软件由谁测试、开始和结束时间、测试的模块有哪些。
测试设计：写测试用例（手工测试用例、自动化测试用例），编写测试工具。
测试执行：执行测试用例。
测试评估：测试人员产生测试报告。
2. 如何描述一个BUG
合格的bug描述主要应该包括以下几个部分。
2.1 发现问题的版本
开发人员需要知道出现问题的版本，才能获取对应版本的代码来重现故障，并且版本的标识也有利于统计和分析每个版本的质量。
2.2 问题出现的环境
环境分为硬件环境和软件环境，如果是web项目，需要描述浏览器的版本，客户机操作系统等，如果是app项目，需要描述机型、分辨率、操作系统版本等。详细的环境描述有利于故障的定位。
2.3 错误重现步骤
描述问题重现的最短步骤。
2.4 预期行为的描述
要让开发人员指导怎么样才是正确的，尤其是要以用户的角度来描述程序的行为是怎样的，如果是依据需求提出的故障，能写明需求的来源是最好的。
2.5 错误行为的描述
描述错误的现象，crash等可以上传log，UI问题可以有截图。
2.6 其他
某些公司会有一些其他的要求，例如故障的分类：功能故障，界面故障，兼容性故障等。有些有优先级的分类，严重影响测试需要开发人员优先修改的，可以设置优先级为最高。
2.7 不要把多个bug放到一起
在无法确认是同一段代码造成的故障时，不要将bug放在一起提交。
3. bug的级别定义
| 级别 | 描述 | 举例 |
| Blocker（崩溃） | 阻碍开发或测试工作的问题，造成系统崩溃，死机、死循环，导致数据库丢失，与数据库连接错误，主要功能丧失，基本模块缺失等问题。 | 代码错误、死循环、数据库发生死锁、重要的一级菜单功能不能使用等。 |
| Critical（严重） | 系统主要功能部分丧失、数据库保存调用错误、用户数据丢失，一级功能菜单不能使用但是不影响其他功能的测试。功能与设计需求严重不符，模块无法启动，程序重启、自动退出、关联程序间调用冲突、安全问题、稳定性等。 | 软件中数据保存后数据库中的显示错误，用户所要求的功能缺失，程序接口错误，数值计算统计错误等。 |
| Major（一般） | 功能没有完全实现但是不影响使用，功能菜单存在缺陷但不会影响系统的我呢定性。 | 操作时间长、拆线呢时间长、格式错误、边界条件错误、删除没有确认框、数据库表中字段过多等。 |
| Minor（次要） | 界面、性能缺陷，建议类问题，不影响操作功能的执行，可以优化性能的方案等。 | 错别字、界面格式不规范、页面显示重叠、不该显示的要隐藏、描述不清楚、提示语丢失、文字排列不整齐，光标位置不正确、用户体验感受不好，可以优化性能的方案等。 |
4. bug的生命周期
每个公司，每一个工具对bug的生命周期定义都是不一致的，测试人员应该跟踪一个Bug的整个生命周期，从Open到Closed的所有状态。
5. 人际关系
确保操作没有问题，确保自己对需求理解没有问题，站在客户的角度考虑问题，不仅发现问题，还要提出解决问题的方案，最后还可以进行第三方会议（开会之前需要明确问题产生的原因，问题是什么，解决方案是什么；开会之后需要明确问题是否需要解决，谁什么时候解决）。
6. 如何开始第一次测试
6.1 充分理解需求
文档（产品文档+技术文档），项目功能问题问产品，模块底层如何实现问开发。
6.2 确定测试计划
6.3 执行测试
BUG开发修复之后一定要验收。
6.4 项目上线+维护
7. 测试的执行和BUG管理
7.1 进行测试
打开待测试的系统；打开测试管理工具用例模块，开始执行用例；发现bug，进行复现并确认bug复现步骤；记录bug；沟通bug；验证以前提交的bug；确认本次测试完成；编写测试报告。
执行测试时处理要做到测试用例和需求的覆盖外，还有临时发挥的能力，根据经验对测试的感悟以及随机测试可以发现很多根据测试用例无法发现的缺陷。
7.2 如何发现更多的bug
（1）软件测试同样存在二八原则，80%的故障集中于20%的模块，如果某部分问题较多，加强测试广度和深度。
（2）开发人员也存在二八原则。80%的故障集中于20%的开发，如果某些开发人员的bug较多，加强她开发模块的测试广度和深度。
（3）多进行逆向思维和发散性思维
依赖于测试人员的经验，对于初学者而言，只能多写测试用例，多看别人的测试用例。
（4）不要局限于用例和需求文档。
（5）尽早介入项目，不要等到开发差不多再介入。
QA：测试
RD：开发
PM：产品