No.9 bug讲解

1.bug的定义：

bug的定义可以很广泛，在软件使用的过程中所出现的任何一个可疑问题，或导致不满足消费者需求的问题或者不符合需求文档的都可以是bug，即使这个bug在实践中是可行的。

软件程序的漏洞或缺陷，还包括测试工程师或用户所发现和提出软件可改进的细节（一般不提），或需求文档存在差异的功能实现等。

我们测试的职责是找到尽可能多（高效地找bug）的bug。

2.bug的类型：

禅道中分类主要分为以下几种，bug的分类可以帮助我们在后续的测试报告中，对bug做一个总结和管理：

代码错误

设计缺陷

界面优化

配置相关

安装部署

性能问题

标准规范

测试代码

其他

其他分类划分：

功能类

性能类

界面类

易用性类

兼容性类

其他

在工作中我们也可以自定义分类

3.bug的等级：

致命bug：死机，数据丢失，主要功能完全丧失等错误，修改级别是最高的，该级别需要程序员立刻修改。

阻碍开发或测试工作的问题；

造成系统崩溃、死机、死循环、导致数据库数据丢失，与数据库连接错误；

主要功能丧失，基本模块缺失等问题；

严重的数值计算错误（涉及到金钱）；

功能与需求不符；

内存泄漏，严重花屏，模块无法启动或异常退出等；

如：代码错误，死循环，重要的一级菜单功能不能使用等（该问题在测试中较少出现，一旦出现应立即中止当前版本测试）；

严重bug：主要的功能丧失，导致严重的问题，或致命的错误声明，修改优先级为高，该级别需要程序员尽快修改。

系统主要功能部分丧失；

数据库保存调用错误、用户数据丢失；

一级功能菜单不能使用但是不影响其他功能的测试；

功能设计与需求不符；

模块无法启动或调用，程序重启、自动退出，关联程序间调用冲突，安全问题、稳定性等；

如：软件中数据保存后，数据库中显示错误，用户所要求的功能缺失，程序接口错误，轻微的数值计算统计错误（该等级问题出现在不影响其他功能的情况下可以继续测试该版本）。

一般bug：次要功能丧失，不太严重，如提示信息不太准确，修改优先级为中，该级别需要程序员修改。

功能没有完全实现但不影响使用；

功能菜单存在缺陷但不影响系统稳定性；

操作界面错误（包括数据窗口内列名定义，含义是否一致）；

边界条件下的错误；

功能存在错误，但出现概率很低；

如：操作时间长，查询时间长，格式错误，边界条件错误，删除没有确认框（但凡是删除功能，都要考虑到有没有二次确认框）、数据库表中字段过多等（该问题实际测试中存在最多，合理安排时间解决BUG，解决率关系版本的优化程度）。

轻微bug：提示信息格式不符合要求，违背正常习俗习惯，界面不美观，控件排列格式不统一。

辅助说明描述不清晰；

个别影响产品理解的错别字；

可输入区域和只读区域没有明显的区分标志；

功能性建议，功能使用性，方便性，易用性不够等；

注意：bug的严重等级并没有严格的界线划分，差不多即可；

我们作为测试人员，不只要提交bug，更多的是跟踪bug，提醒开发尽早修复，直到bug关闭。

4.bug的生命周期：

bug的生命周期就是从我们测试发现bug到最后关闭bug的整个过程。

从发现 ---》提交到缺陷管理平台 ---》指派开发 ---》已解决 ---》 待验 ---》关闭；

5.bug的状态处理：

①已经指派的bug -- 已指派开发，注意bug的走向，随时关注并进行跟踪，若一直未修复，提醒开发以免忘记，若已修复等待测试环境更新后进行验证；

②已解决的bug -- 等待测试环境更新后重新验证，通过则关闭，否则，指派开发；

③重复的bug -- 是否与开发指定重复，重复关闭，否则指派开发；

④不是缺陷 -- 确认开发环境是否与测试环境一致，确定不是缺陷后关闭，如果确认是bug和开发，产品沟通；

⑤无法重现（偶现性bug/无法重现的bug） -- 确认开发环境是否与测试环境一致，包括操作步骤、浏览器、特定账号等，若多个版本验证后，如开发所说无法重现，可依据bug严重程度跟产品、开发一起确认关闭；

⑥不予解决 -- 找产品经理确认，确认可不予解决的话则关闭，否则重新提交给开发；

⑦设计如此 -- 看产品需求规格说明书，找产品经理确认，确认设计如此的话关闭bug，否则重新提交给开发；

⑧延期修改 -- 查看bug严重程度，是否影响当前版本的发布，与产品经理确认。不予延期根据情况进行激活与情况说明；确认延期，做好记录，后续版本进行关注。

6.如何才能提交一个有效的bug：

①确保bug有效：

（1）不要因为环境问题或者是操作错误引起bug；

（2）不要提交一些重复的bug；

②写好bug描述：

（1）bug描述精确、没有歧义，详细简洁的测试步骤；

（2）保证各个字段内容与实际现象一致。比如：版本、复现率等；

（3）对于复现率低的问题，尽可能提供一些可参考的信息：截图、视频、日志、可能的步骤、可能的原因等（如果你能通过各种手段定位到问题的原因，开发大神也会对你刮目相看的）；

7.测试用例的特点：

①测试用例的代表性：能够代表并覆盖各种合理和不合理、合法和不合法的、边界和越界的、以及极限的输入数据、操作和环境设置等；

②测试结果的可判定性：即测试执行结果的正确性，是可判定的，每一个测试用例都应有相应的期望结果；

③测试结果的可再现性：即对同样的测试用例，系统地执行结果应当是相同的；

思考1：你在设计测试用例的时候，应该注意什么？

①一个测试用例一个功能点：每个用例都要有个测试点，找准一个测点即可，不能同时覆盖多个功能点（有效等价类除外），否则执行起来牵连太大；

②用例的易读性：从执行者的角度去写用例，最好不要有太多术语在里面，最好指明具体位置；

③测试用例的执行粒度：粒度越小越好（测试点越详细越好）；

④步骤清晰：一个用例多个步骤，重点只有一个，步骤指明人们应该怎么去操作，预期结果则指明这样操作之后应该看到什么样的结果，不要用是否，可能，大概，也许之类的含糊主观的字眼；

⑤总体设计：先正常，后异常，这样可以确保正常情况下功能能够走通；

总之：对于一个新来的测试人员，给他测试用例和我们的软件，他就能顺利地执行测试用例。

思考2：冒烟测试用例怎么设计的？

我们有详细设计功能测试用例的文档，没有专门去设计冒烟用例，每个功能的第一条都是正常的功能，用第一条作为冒烟测试。