1. 软件测试的生命周期

软件测试的生命周期：需求分析–》测试计划–》测试设计，测试开发–》测试执行–》测试评估

注意和软件开发的生命周期进行区分：
软件开发的生命周期：需求分析–》计划–》设计–》编码–》测试–》运维

2. 如何描述一个bug

首先要说清出错的版本号是多少（比如v1.0.0），测试环境（比如ios2.1 iphone 6s），出错时的操作步骤（操作步骤：1. 登录微信，2. 进入聊天界面，3.选中一条聊天记录，向左滑动，点击删除），预期结果（选中的聊天记录被删除），实际结果（被选中的未删除）

3. bug的级别

• 崩溃：系统无法正常运行，阻断。
  表现：死循环，死机，数据库发生死锁等
  解决：回退系统版本
• 严重：系统可以运行，但不稳定，会发生严重的后果。
  表现：数据泄漏，直播画面失真，密码明文显示
• 一般：系统可以稳定运行，但是缺少部分功能，影响用户体验。
  表现：比如说微信聊天记录无法删除，数据库查询错误
• 次要：系统稳定运行，属于建议性的bug，可能会稍微影响用户体验
  表现：比如图片不清晰，字体不一样

4. bug的生命周期（从bug创建到bug关闭，bug经历的一些状态）

当开发人员说这不是bug怎么办？

1. 首先不要慌，先检查自身是否bug描述的不够清晰

2. 让开发人员了解到这个bug对用户可能造成的困扰

3. 提高自身的技术和业务水平，不光要提出问题，最好也能提出解决方案

4. 开发人员还是不接受是此时可以发起bug评审
   bug评审需要注意，他应该包括两个层面：
   ① 决定如何处理bug
   这一方面评审需要项目组各个方面的代表参加，通常不可缺少的是测试代表，开发代表，产品代表。

   • 测试代表主要从Bug的具体表现、严重程度等方面提供信息，并提出自己对Bug的处理意见。需要注意的是，测试人员不应该一味地要求对Bug进行修改，因为修改可能带来回归的风险，同时带来的是回归测试的工作量，如果时间比较紧迫，修改后剩余的时间若不足以做一次有效的回归测试，可能不修改是个明智的选择。
   • 开发代表主要从修改缺陷的难度和风险出发，考虑缺陷修改需要付出的代价，以及可能影响的范围、可能引发的风险等，如果决定要修改，还要讨论出修改的初步方案。
   • 产品代表主要从产品的整体计划、用户的要求等方面对缺陷的修改必要性、缺陷修改的时间和版本提出自己的意见。 这在微软的做法叫“Bug三方讨论会”，参加者一般是测试人员、开发人员和项目经理。

   ② 分析缺陷产生的原因，找出预防的对策。
   缺陷评审还应该包括原因分析，找出Bug出现的原因，尤其是那些重复出现的Bug。应该找出出现错误的根源，并且制定出相应的预防措施，确保同类型的Bug不再出现。

   例如：有些Bug出现的原因不是简单的“引用为空”之类，而是开发人员的编码不规范或者编程习惯不好而导致，所以必须建立起正确的编程方式才能预防这些错误的出现，否则只是在玩无聊地重复发现相同的Bug的游戏。