软件测试基础

软件测试的生命周期

需求分析->测试计划->测试设计->测试开发->测试执行->测试评估

软件测试&软件开发生命周期

需求阶段-----测试人员了解需求、对需求进行分解，得出测试需求计划阶段根据需求编写测试计划/测试方案
设计阶段-----测试人员适当的了解设计，对于设计测试用例是很有帮助的，测试人员搭建测试用例框架，根据需求和设计编写一部分测试用例
编码阶段-----测试人员一般是不需要编码的，但已经编码的模块，专业的白盒测试人员可以计划执行单元测试，完善、细化测试用例以及调整测试计划和方案。
测试阶段-----测试阶段是软件测试人员最为重要的工作阶段，根据测试用例和计划执行测试，在执行的过程中记录、管理缺陷，测试完成后编写测试报告。
运行维护-----测试人员需要参与项目的实施工作。测试人员对项目产品的业务和操作非常了解，加上测试人员的沟通表达能力一般都比较强，所以测试人员可以参与用户使用软件的培训，在试运行项目时收集问题并及时反馈给相关负责人。

bug分类

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

bug级别

1、Blocker（崩溃）：系统无法正常运行，阻断。表现：死循环、死机、数据库发生死锁等。
2、Critical（严重）：系统可以运行，但是不稳定，如果继续运行会发生严重的后果。表现：数据泄露、直播画面失真、密码明文显示等

3、Major（一般）：系统可以稳定运行，但是缺少部分功能，影响用户体验。
4、Minor（次要）：系统稳定运行，属于建议性bug。

bug生命周期

2.软件测试基础

● New:（新建）新发现的Bug，未经评审决定是否指派给开发人员进行修改。
● Open：（确认）确认是Bug，并且认为需要进行修改，指派给相应的开发人员。
● Fixed:（已解决）开发人员进行修改后标识成修改状态，有待测试人员的回归测试验证。
● Rejected：（丢弃）如果认为不是Bug，则拒绝修改。
● Delay:（延期）如果认为暂时不需要修改或暂时不能修改，则延后修改。
● Closed：（关闭）修改状态的Bug经测试人员的回归测斌验证通过，则关闭Bug。
● Reopen：（重新打开）如果经验证Bug仍然存在，则需要重新打开Bug，开发人员重新修改。

问题：如果因为一个bug和开发产生冲突，测试人员应当如何恰当处理？

检查bug描述是否清楚
站在用户的角度去说服开发人员
bug定级一定要有理有据
作为测试人员要不断提升自己的技能水平
评审bug