一、软件测试的生命周期（软件测试流程）

• 需求分析：分析设计的正确性和合理性；细化需求找出测试项
• 测试计划：测试人数；测试环境；测试时间；测试设备
• 测试设计/测试开发：根据测试需求，写测试用例
• 测试执行：开发已经完成，执行测试用例，验证功能；找BUG，提交BUG，验证BUG
• 测试评估：写了多少测试用例，执行了多少，剩余的测试用例数；BUG数量，解决的BUG数量，遗留的BUG及解决方案，测试范围和测试功能

二、BUG的描述

• 测试版本号（代码版本信息）

  开发人员需要获取对应版本的代码来重现BUG，版本的标识有利于统计和分析每一个版本的质量

• 测试环境

  Web系统：

  • 硬件设备（电脑品牌，型号）
  • 软件设备（操作系统，浏览器即版本号）

  APP：

  • 硬件设备（手机品牌，分辨率）
  • 软件设备（操作系统及版本号）

• 测试数据

• 测试步骤

  描述问题重现的最短步骤

• 测试实际结果

• 测试预期结果

  以用户的角度描述程序应有的行为是怎样的，可以的话写明需求的来源

• 附件，错误日志，错误截图，优先级等

三、BUG的级别

以下对BUG级别的描述只是典型情况，实际中的BUG级别的划分需看公司的定义

• 崩溃

  严重阻碍到测试人员的工作，系统无法正常运行，出现崩溃，操作死锁，死循环，黑屏，导致数据库数据丢失，数据库连接错误等（遇到这类情况应立即中止当前版本的测试）

• 严重

  系统能运行，但是不稳定，继续运行下去会造成严重损失，重要的功能没有实现，或者与需求不符合，数据库中的用户数据存储出现了错误，威胁用户的安全

• 一般

  系统可以稳定运行，次要的功能没有实现，或者与需求不符合，比如加载时间过长，格式错误，数据库表中字段过多等

• 建议

  影响用户的体验，界面格式不规范，排版不符合大众审美，描述不清晰，提示语丢失，文字排列不整齐等优先级较低的BUG

四、BUG的生命周期

• New：发现新的BUG，未经评审决定是否指派给开发人员进行修改
• Open：确认是BUG，并且认为需要进行修改，然后指派给相应开发人员
• Fixed：开发人员进行修改后标示成修改状态，待测试人员进行回归测试验证
• Reopen：验证后BUG仍然存在，则回到上一步，让开发人员重新修改
• Closed：通过验证，关闭BUG
• Rejected：认为不是BUG，不修改（找产品经理确认）
• Delay：暂时不需要或者不能修改，延迟修改（找产品经理确认）

五、当因为 BUG 和开发人员产生冲突时

• 检查自身，看对BUG的描述是否清楚

  一个描述清晰的BUG信息，使得解决问题的效率大大提高。当BUG的信息无法书面描述清晰时，应当主动找到开发人员进行沟通

• 从用户的角度去说服开发人员修改

  一个项目最后面向的对象的是用户，引导开发人员站在用户的角度思考问题，可以促进开发人员修改BUG

• BUG的定级要严格按照公司的规范

• 不断提升自己的业务技术水平

  不仅能发现BUG，还能够对BUG进行定位，甚至提出解决方案，建立权 威，有较高的可信度

• 拒绝大声争吵，拒绝扯头花

  进行三方会议，测试人员、开发人员、产品经理一起讨论BUG的解决方案

六、菜鸟如何开始自己的第一次测试

进行第一次的测试前需要做好充分的准备

1. 拿到一个项目，我们需要阅读所有项目相关的文档，需求文档，设计文档，用户手册。这些是之后写测试用例，进行测试的根本依据所在

2. 多多参加项目相关会议，了解项目的背景，人员组成，进一步了解项目需求和业务，针对专业性较强的项目，要了解各种相关知识

3. 熟悉项目使用的测试管理工具，配置管理工具

4. 阅读已有的测试方案，测试用例以及BUG，和团队保持一致的故障定级原则

5. 编写代码前还需要了解公司的规范要求，比如用例编写的规范，用例执行的规范，BUG 提交的规范，测试工具使用的规范等

6. 在真正进行测试前，还需要向自己的小领导确认具体的工作内容：

   测试的计划

   测试的内容

   任务限制几天完成

   我要测试的内容的开发人员、需求人员

   测试的内容是否需要其他特殊的测试资源

至此，就可以开始执行测试任务

完~~