【软件测试-3】& 基础篇

文章目录

• • 1.软件测试的生命周期
  • • 1.1软件测试&软件开发生命周期
  • 2.如何描述一个BUG
  • 3.BUG的级别
  • 4.BUG的生命周期
  • 产生争执怎么办（处理人际关系）

1.软件测试的生命周期

常见面试题

• 软件开发的生命周期：用户需求——计划分析——设计——编码——测试——运行
• 软件测试的生命周期(软件测试的流程)： 需求分析→测试计划→ 测试设计/测试开发→ 测试执行→ 测试评估

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

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

2.如何描述一个BUG

举例描述 易邮箱的Bug

3.BUG的级别

在开发和测试的争执中，一部分是究竟是不是bug部分是bug的级别有点高吧么如何定义bug的级别/p>

bug的定义每个公司都不一致，在定义级别之前需要查看公司规范。

以下为样例：

1、Blocker（崩溃）

阻碍开发或测试工作的问题；造成系统崩溃、死机、死循环，导致数据库数据丢失，与数据库连接错误，主要功能丧失，基本模块缺失等问题。如：代码错误、死循环、数据库发生死锁、重要的一级菜单功能不能使用等（该问题在测试中较少出现，一旦出现应立即中止当前版本测试）。

2、Critical（严重）

系统主要功能部分丧失、数据库保存调用错误、用户数据丢失，一级功能菜单不能使用但是不影响其他功能的测试。功能设计与需求严重不符，模块无法启动或调用，程序重启、自动退出，关联程序间调用冲突，安全问题、稳定性等。如：软件中数据保存后数据库中显示错误，用户所要求的功能缺失，程序接口错误，数值计算统计错误等（该等级问题出现在不影响其他功能测试的情况下可以继续该版本试）。

3、Major（一般）

功能没有完全实现但是不影响使用，功能菜单存在缺陷但不会影响系统稳定性。如：操作时间长、查询时间长、格式错误、边界条件错误，删除没有确认框、数据库表中字段过多等(该问题实际测试中存在最多）

4、Minor（次要）

界面、性能缺陷，建议类问题，不影响操作功能的执行，可以优化性能的方案等。如：错别字、界面格式不规范，页面显示重叠、不该显示的要隐藏，描述不清楚，提示语丢失，文字排列不整齐，光标位置不正确，用户体验感受不好，可以优化性能的方案等（此类问题在测试初期较多，优先程度较低；在测试后期出现较少，应及时处理）

4.BUG的生命周期

每个公司、每一个工具对bug生命周期的定义都是不一致的，下面仅是一个常见的例子

测试人员应该跟踪一个Bug的整个生命周期，从Open到Closed的所有状态

BUG状态转换图

● New:新发现的Bug，未经评审决定是否指派给开发人员进行修改。

● Open：确认是Bug，并且认为需要进行修改，指派给相应的开发人员。

● Fixed:开发人员进行修改后标识成修改状态，有待测试人员的回归测试验证。

● Rejected：如果认为不是Bug，则拒绝修改。

● Delay:如果认为暂时不需要修改或暂时不能修改，则延后修改。

● Closed：修改状态的Bug经测试人员的回归测斌验证通过，则关闭Bug。

● Reopen：如果经验证Bug仍然存在，则需要重新打开Bug，开发人员重新修改。

无效的bug：open->closed open-rejected-closed

缺陷状态变更流程每个项目团队的实际做法可能不大一样。并且需要结合实际的开发流程和协作流程来使用。

Bug的跟踪以及状态变更应该遵循一些基本原则：

• 测试人员对每一个缺陷的修改必须重新取一个包含更改后的代码的新版本进行回归测试，确保相同的问题不再出现，才能关闭缺陷。
• 对于拒绝修改和延迟修改的Bug，需要经过包含测试人员代表和开发人员代表、用户方面的代表（或代表用户角度的人）的评审。

面试常见：测试人员提了一个bug,开发人员修复了，但是测试人员验证回归的时候发现这个bug依然存在，问可能是什么原因导致的/p>

原因1：可能是因为开发人员没有修复正确；

原因2：测试人员没有拉取最新的代码（拉取的还是以前有问题的代码）进行发布测试

产生争执怎么办（处理人际关系）

能让开发人员解决最多Bug的测试人员是最优秀的测试人员。在测试工作中，最常遇到的是和开发人员的PK，作为测试经理还会和项目经理、产品经理的PK进度、质量。

作为一名测试人员，一般会遇到以下几种情况：

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

遇到争执不要怕，记住批判性思维：清楚–准确、切题–深刻，有意义，有逻辑性–公正、全面

1、先检查自身，是否bug描述不清楚

如果能正确地、高质量地录入一个Bug，那么基本上已经成功地与开发人员沟通了一大半的关于Bug的信息。但是总有“书难达意”的耐候，这时就需要测试人员主动与开发人员进行沟通了。 如果测试人员发现在写完一个缺陷后，好像还有很多关于Bug的信息没有表达出来，或者很难用书面语言表达出来时，就应该在提交Bug后，马上找相关的程序员解释刚才录入的Bug，确保程序员明白Bug描述的意思，而不要等待开发人员找自己了解更多的信息。

2、站在用户角度考虑问题 应该让开发人员了解到Bug对用户可能造成的困扰，这样才能促使开发人员更加积极地、高质量地修改Bug。在争执时，可以问一句：如果你是用户，你可以接受么/p>

案例：

例如：需求要求可以上传图片作为头像，但是没有定义格式。开发人员在上传时限制为只能传png格式的。

站在用户角度考虑一下：png，jpg那种格式更多否要用户自己进行格式转换再上传/p>

发散一下:

如下图，当选择了1.png，2.png，2-2.png,时，任意点击一个删除按钮，所选的三个都被删除

3、BUG定级要有理有据

BUG定级时，不仅要参考BUG级别，还要考虑BUG是否会影响到流程，往往用户的BUG级别和我们的是有区别的，需站在用户的角度定考虑定位级别。

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

提高自身的业务和技术水平，不但要做到能提出问题，还能够提出解决问题的思路。这样才能更让人信服。

在工作中，你会发现同一个bug，资深测试工程师提出和初级测试工程师提出，两者的结果完全不同，两者最大的差别是资深测试工程师往往会提出解决方案。而长此以往，权威性逐渐的建立起来，那么开发人员看到bug的第一反应，就是这是一个bug，而不是这是一个bug吗/p>

案例：

某 站经常隔几天访问时会出现500错误，但是之后就不会复现。

测试人员会提出问题： 站偶发性出现500错误。

开发人员回答：不常见，不影响使用，暂不修改

资深测试人员提出问题： 站偶发性500错误，查看日志，是由于mysql数据库8小时超时问题造成。需要修改连接池配置定期校验连接

开发人员处理：修改xml，增加校验配置项

5、开发人员不接受时，不要争吵

可能你已经经过了多轮沟通，但是开发人员仍然拒不接受。此时可以发起Bug评审。

Bug评审要注意的问题 缺陷的评审应该包括以下两个层面
●决定如何处理Bug。
● 分析缺陷产生的原因，找出预防的对策。

(1) 决定如何处理Bug。 这一方面评审需要项目组各个方面的代表参加，通常不可缺少的是测试代表、开发代表、产品代表。

测试代表主要从Bug的具体表现、严重程度等方面提供信息，并提出自己对Bug的处理意见。需要注意的是，测试人员不应该一味地要求对Bug进行修改，因为修改可能带来回归的风险，同时带来的是回归测试的工作量，如果时间比较紧迫，修改后剩余的时间若不足以做一次有效的回归测试，可能不修改是个明智的选择。

开发代表主要从修改缺陷的难度和风险出发，考虑缺陷修改需要付出的代价，以及可能影响的范围、可能引发的风险等，如果决定要修改，还要讨论出修改的初步方案，产品代表主要从产品的整体计划、用户的要求等方面对缺陷的修改必要性、缺陷修改的时间和版本提出自己的意见。 这在微软的做法叫“Bug三方讨论会”，参加者一般是测试人员、开发人员和项目经理。

(2) 分析缺陷产生的原因，找出预防的对策。 缺陷评审还应该包括原因分析，找出Bug出现的原因，尤其是那些重复出现的Bug。应该找出出现错误的根源，并且制定出相应的预防措施，确保同类型的Bug不再出现。 例如：有些Bug出现的原因不是简单的“引用为空”之类，而是开发人员的编码不规范或者编程习惯不好而导致，所以必须建立起正确的编程方式才能预防这些错误的出现，否则只是在玩无聊地重复发现相同的Bug的游戏。