一、软件测试的生命周期

软件测试的生命周期：
1.需求分析：需求是否完整，需求是否正确
2.测试计划：确定软件是由谁来测试，测试从什么时候开始测试，什么时候结束测试，测试哪些模块
3.测试设计、测试开发：写测试用例(手工测试用例，自动化测试用例)，编写测试工具
4.测试执行：执行测试用例
5.测试评估：测试人员书写测试报告

二、BUG

BUG的描述

1.发现问题的版本：开发人员需要知道出现问题的版本，才能够获取对应版本的代码来重现故障。版本的标识也有利于统计和分析每个版本的质量
2.问题出现的环境：环境分为软件和硬件，比如web项目：浏览器版本，客户机操作系统等。app项目：机型、分辨率、操作系统版本等。详细的环境有利于故障的定位
3.错误重现的步骤：描述问题重现的最短步骤
4.预期行为的描述：让开发知道怎么样才是正确的，尤其要以用户的角度来描述程序的行为是怎样的，能够写明需求来源是最好的
5.错误行为的描述：描述错误的现象如：crash上传log，UI有问题传截图
6.其他：有时公司会有其他要求，例如：功能故障，界面故障，兼容性故障。优先级的分类，严重影响测试需要开发修改的，可以设置优先级为高
7.不要把多个bug放在一起：无法确认是同一段代码造成故障时，不要将bug一起提交

bug一般描述的越详细，开发进行改正越容易

BUG的级别

BUG每个公司的定义都略有差异，我们在这里以其中一种举例：
1.Blocker(崩溃)：
阻碍开发或测试工作的问题；造成系统崩溃、死机、死循环、数据库数据丢失、主要功能丧失。如：代码错误、死循环、数据库死锁等(该问题在测试中出现次数较少，一旦出现后应立即停止当前版本测试)
2.Critical(严重)：
系统主要功能丧失、数据库保存调用错误、用户数据丢失。功能设计与需求严重不符，模块无法启动或调用，程序重启、自动退出、安全问题等。如：软件中数据保存后数据库中显示错误，程序接口错误(该等级问题出现在不影响其他功能测试的情况下可以继续该版本测试)
3.Major(一般)：
功能没有完全实现但不影响使用。如：操作时间长，查询时间长，格式错误，删除没有确认边框(该问题实际测试中存在最多)
4.Minor(次要)：
界面、性能缺陷。如：错别字、界面格式不规范、不该显示的要隐藏、提示语丢失、用户体验感受不好(此类问题在测试初期较多，优先程度较低；在测试后期出现较少，应及时处理)

从上到下，BUG等级由高到低，危害程度由高到低，如果发现崩溃级别的BUG，就需要停止测试，测试将项目打回，开发进行修复，修复完之后自己先仔细的测试一下

BUG生命周期

每个公司、每一个工具对BUG生命周期的定义是不一致的，测试人员应该跟踪一个BUG的整个生命周期，从Open到Closed的所有状态

new：新发现的BUG，测试人员决定是否指派给开发进行修改
open：确认是BUG，并且认为需要进行修改，指派给相应的开发人员
Fixed：开发人员进行修改后表示成修改状态，有待测试人员回归测试验证
Rejected：认为不是BUG，拒绝修改
Delay：认为暂时不需要修改或者暂时不能修改，延后修改
Closed：如果修改状态的BUG经测试人员回归测试验证通过，关闭BUG
Reopen：如经过验证Bug仍然存在，需要重新打开BUG，开发人员重新改

大家需要注意当我们发现BUG交给开发之后，开发进行修改之后并不是就没有问题了，需要再次进行测试，开发修改了BUG，有可能会产生新的BUG

产生争执怎么办?

能让开发人员解决最多BUG的测试人员是最优秀的测试人员。
作为一名测试人员，会遇到以下几种问题：

这不是bug
这个bug的级别太高了
bug影响不大，暂时不修改

如果遇到了争执不要怕，记住批判性思维：清楚–准确、切题–深刻，有意义，有逻辑性–公正、全面
1.先检查自身，bug描述的是否清楚
2.站在用户的角度考虑问题，让开发人员了解到bug对用户可能造成的困扰，这样才能促使开发人员更加积极、高质量地修改bug
3.BUG定级有有理有据
4.提高自身的技术和业务水平。不光要提出问题，最好也能提出解决方案
5.开发人员不接受时，不要争吵

如何开始第一次测试

我们在第一次做测试时需要做许多准备：
1.阅读所有项目相关文档：需求文档、设计文档、用户手册
2.尽可能的参加各种项目会议，了解项目的背景、人员组成、尽可能的去了解需求和业务
3.熟悉项目所使用的测试管理工具、配置管理工具，获取相应地址和登陆方式
4.阅读已有的测试方案和测试案例
5.阅读旧的bug库，了解系统功能。重要的是和测试团队的协作
6.了解公司规范，特别是用户编写规范、用例执行规范、bug提交规范、测试工具的使用规范等

在准备了以上工作以后，我们需要与测试组长进行确认：
1.测试的计划是什么？
2.测试的内容是什么？test case有多少？安排的时间？
3.我要测试的内容开发人员是谁？需求人员是谁？

测试的执行和BUG的管理

如何发现更多的BUG
1.软件测试存在二八原则，百分之80的故障集中于百分之20的模块，如果某部分问题较多，加强测试的宽度和深度
2.开发人员也存在二八原则，百分之80的故障集中于百分之20的开发人员，如果某些开发人员的bug较多，加强他开发模块的测试广度和宽度
3.多进行逆向思维和发散性思维(没有测试经验，只能多写测试用例，多看看别人的测试用例)
4.不要局限于用例和需求文档
5.尽早介入项目(尽早介入需求，就会尽早理解需求)，千万不要等开发的差不多了再介入项目