文章目录
- 1. 软件测试&软件开发生命周期
- 2. 如何描述一个 BUG
- 3. 如何定义 BUG 的级别
- 4. BUG 的生命周期
- 5. 如何进行第一次测试
- 6. 测试的执行和 BUG 管理
- 7. 产生争执怎么办（处理人际关系）
1. 软件测试&软件开发生命周期
软件测试的生命周期：
需求分析→测试计划→ 测试设计、测试开发→ 测试执行→ 测试评估
需求分析：判断用户的需求是否可以实现
测试计划：计划项目有谁做，什么时候测试开始，什么时候测试结束，什么时候上线
测试设计：设计测试用例
测试开发：开发可以支持测试，提高测试效率的测试工具
测试执行：执行测试用例，目的是为了发现 BUG，验收 BUG
测试评估：产出测试报告 （测试报告相当于邮件）
2. 如何描述一个 BUG
我们为什么要描述一个BUG 呢？不能直接告诉开发人员 呢？
这里我们举个小栗子：
在我们小时候写作业的时候，会产生错题
如果我们不对错题进行标记，老师发现一个错题告诉一个人
这样就会导致，老师花费的时间较长，错题同学也可能会忘记
测试项目的还是，往往会出现许多的 BUG，有些 BUG 非常难以复现
- 发现问题的版本
开发人员需要知道出现问题的版本，才能获取对应版本的代码来重现故障，并且版本的标识页 - 问题出现的环境
环境分为硬件环境和软件环境
如果是web项目，需要描述浏览器版本，客户机操作系统等，如果是app项目，需要描述机型、分辨率、操作系统版本等
详细的环境描述有利于故障的定位 - 错误重现的步骤
描述问题重现的最短步骤 - 预期行为的描述
要让开发人员指导怎么样才是正确的，尤其要以用户的角度来描述程序的行为是怎样的。
如果是依据需求提出的故障，能写明需求的来源是最好的。
要相信：测试人员是最懂需求的 - 错误行为的描述
描述错误的现象。crash等可以上传log，UI问题可以有截图 - 其他
某些公司会有一些其他的要求，例如故障的分类：功能故障，界面故障，兼容性故障等。
有些有优先级的分类，严重影响测试需要开发人员优先修改的，可以设置优先级为高 - 不要把多个bug放到一起
在无法确认是同一段代码造成的故障时，不要将bug放在一起提交
3. 如何定义 BUG 的级别
- Blocker（崩溃）
系统崩溃、死机、死循环，导致数据库数据丢失，与数据库连接错误，主要功能丧失，基本模块缺失等问题 - Critical（严重）
系统主要功能部分丧失、数据库保存调用错误、用户数据丢失，一级功能菜单不能使用但是不影响其他功能的测试。
功能设计与需求严重不符，模块无法启动或调用，程序重启、自动退出，关联程序间调用冲突，安全问题、稳定性等 - Major（一般）
功能没有完全实现但是不影响使用，功能菜单存在缺陷但不会影响系统稳定性 - Minor（次要）
界面、性能缺陷，建议类问题，不影响操作功能的执行，可以优化性能的方案等
BUG 级别提交的时候一定要有理有据
如果项目需要按时交付，还有很多 BUG，周知项目相关人，这些优先级是次要的，就可以放到下一个版本
开发在改 BUG 的时候，优先级较高的先修复，优先级较低的后修复
4. BUG 的生命周期
每个公司、每个工具的声明周期是不一样的
- New：新发现的Bug，未经评审决定是否指派给开发人员进行修改。
- Open：确认是Bug，并且认为需要进行修改，指派给相应的开发人员。
- Fixed：开发人员进行修改后标识成修改状态，有待测试人员的回归测试验证。
- Rejected：如果认为不是Bug，则拒绝修改。
- Delay：如果认为暂时不需要修改或暂时不能修改，则延后修改
- Closed：修改状态的Bug经测试人员的回归测斌验证通过，则关闭Bug。
- Reopen：如果经验证Bug仍然存在，则需要重新打开Bug，开发人员重新修改。
无效的bug：open->closed open-rejected-closed
Delay 的 BUG 不是说不修复，只是当前版本不修复，但是在将来是一定要修复的
如果出现了 Delay 和 Rejected 这种 BUG，QA 是一样要将这些 BUG 告知给相关人员，以及相关人的 leader
发送测试报告的时候，也一定要指出 Delay 和 Rejected 这种 BUG
5. 如何进行第一次测试
1、阅读所有项目有关的文档，包括：需求文档、设计文档（技术文档）、用户手册
2、尽可能参加各种项目会议，了解项目的背景、人员组成、尽可能的了解需求和业务。
特别针对业务专业性较强的项目，例如银行业务，需要了解各种业务知识，如高低柜、一二三类账户等、存款、贷款等。
3、熟悉项目所使用的测试管理工具、配置管理工具，获取对应的地址和登录方式
4、阅读已有的测试方案和测试案例
5、阅读旧有的bug库，了解系统功能。尤其重要的是和现有的测试团队保持一致的故障定级原则
6、了解公司的规范要求，特别是用例编写规范、用例执行规范、bug提交规范、测试工具工具使用规范等
第一次测试工作到来了，我们需要与测试组长确认具体的工作内容：
0、把软件部署到服务器上
1、测试的计划是什么？
2、测试的内容是什么？test case有多少？安排了几天执行？有没有自由测试的时间？
3、我要测试的内容开发人员是谁？需求人员是谁？
4、分配给我的测试内容是否需要特殊的测试资源？资源是否满足需要？
在我们确认了以上内容之后，就可以开始测试的执行了
测试人员测试工作不能拘泥于测试用例，所以测试人员需要探索性的测试
6. 测试的执行和 BUG 管理
1、软件测试同样存在二八原则，80% 的故障集中于 20% 的模块，如果某部分问题较多，加强测试广度和深度，测试的时候一定要上心
2、开发人员也存在二八原则，80% 的故障集中于 20% 的开发人员，如果某些开发人员的 bug 较多，加强他开发模块的测试广度和深度！
3、多进行逆向思维和发散性的思维
4、不要局限于用例和需求文档
5、尽早介入项目, 不要等到开发的差不多了再介入项目
7. 产生争执怎么办（处理人际关系）
作为一名测试人员，一般会遇到以下几种情况：
- 这不是 bug
- 这个 bug 的级别太高了
- bug 影响不大，暂不修改
遇到争执不要怕，记住批判性思维：清楚–准确、切题–深刻，有意义，有逻辑性–公正、全面
1、先检查自身，是否 bug 描述不清楚
2、站在用户角度考虑问题 应该让开发人员了解到 bug 对用户可能造成的困扰，这样才能促使开发人员更加积极地、高质量地修改 bug。
在争执时，可以问一句：如果你是用户，你可以接受么？
3、BUG定级要有理有据
4、提高自身的技术和业务水平. 不光要提出问题, 最好也能提出解决方案
5、开发人员不接受时，不要争吵
6、三方讨论会
在会议上干什么：
- 描述清楚我们的 BUG 是什么
- 当前我的解决方案是什么
- 指明 BUG 由谁修复
结论：
明确 BUG 导师改不改，如果不改发送测试报告的时候一定要标出来
如果 BUG 改，谁去改，什么时候改完，什么时候 QA 验收结束
