常见问题

Bug探索书写规范及审核规则

1   目的
让测试人员更加清晰的了解Bug探索,发现更多高质量的Bug,统一报告编写的规范,以保证规范测试报告,保证质量,便于审查与质量控制,提升报告整体专业性。

2   适用产品
适用于Bug探索测试人员执行和报告编写。

3   什么是Bug探索
探索性测试可以说是一种测试思维技术。它没有很多实际的测试方法、技术和工具,但是却是所有测试人员都应该掌握的一种测试思维方式。探索性强调测试人员的主观能动性,抛弃繁杂的测试计划和测试用例设计过程,强调在碰到问题时及时改变测试策略。
探索性测试主要是对被测软件的一些重要功能进行复测,也包括测试那些测试用例中没有覆盖到的部分;另外,对于软件更新和新加的功能要重点测试,重点对一些特殊情况的错误处理,特殊的使用环境,并发性进行检查测试,尤其是对之前测试发现的重大bug进行再次测试,可以结合回归测试一起进行。
探索性测试没有书面测试用例、记录期望结果、检查列表、脚本或指令的测试。主要是根据测试者的经验对软件进行功能和性能抽查。探索性测试是根据测试说明书执行测试用例的重要补充手段,是保证测试覆盖完整性的有效方式和过程。


4   Bug探索的方法
     1.  基于需求进行测试(对照需求定义文档测试)探索性测试是在熟悉需求和能够熟练进行独立测试的基础上进行,在执行测试时多注意结合需求,深刻理解文档的内容,要明白测试的目的,这是基础;
     2.  基于测试案例case之上的探索性测试(不按照case顺序,混合交叉操作):由于测试测试案例编写是基于基本功能进行覆盖全面的,对于探索性测试没必要按照顺序测试,分析后把能够连贯的步骤颠倒顺序后进行测试有可能就会发现问题;
     3.  对于重点功能基于测试经验的探索性测试(假设怀疑测试):根据测试案例过程中遇到的问题或者其他的测试经验凭感觉产生怀疑精神,先假设认为在某一个功能上有问题,然后围绕着这个功能展开相关联的一系列测试步骤,这个假设并不是对于任一个功能都假设;
     4.  基于其他的类似功能软件或功能点的探索性测试(对比测试):对于有类似功能的软件和主流功能的其他软件要能够熟练使用并记住现象,方便和探索性测试地进行比较,对于需求不明确或易用性的问题上多和其他的软件进行比较,多和产品人员,组内的人员进行交流,同时注意和开发人员进行交流;
     5.  基于Bug Report的探索性测试(根据bug分析的探索性测试):经常看一下bug report的bug步骤和开发人员分析,尤其是开发人员的分析,启发一下思路测试后能够发现新的问题,这点对于测试人员的编码能力或者是分析能力要求较高,要求整体把握比较高;
     另外就是平时要注意记录探索性测试的步骤和方法,多和其他人员讨论,不断更新自己的探索性测试文档,活跃自己的思路。 只有不断的积累测试经验,包括具体的测试执行和对缺陷跟踪记录的分析,不断总结才能提高。

5   怎样更好的做好Bug探索
探索性测试有些小窍门,可以帮助测试人员更有效的发现bug。
窍门一,在以前发现很多bug的地方,一定可以发现更多的bug。我们在做探索性测试的时候,往往会先统计一下,上周哪些模块被发现的bug最多,那么这周一定要狠狠的在那个模块里发掘一下。
窍门二,做到知己知彼。知己就是要了解自己在哪些方面有特长,多发挥这些特长;知彼主要是了解两方面,一是程序本身哪些地方最复杂,最薄弱,这些地方最容易发生什么错误,二是程序员最容易在哪些地方犯哪些错误。前者通过对程序的熟悉可以比较好的掌握,后者可以通过以前BUG分析得到。
窍门三,多和开发人员沟通。在和开发人员沟通的过程中,你可以知道很多你前所未知的东西,你可以通过验证这些东西,来发现未知的bug,并且可以激发你运用更多的测试手段来测试。
窍门四,测试心态。做测试最重要的是心态,这里说的心态一方面指的是测试人员对程序的看法。作为测试人员,在拿到测试程序时,一定要保持悲观的心态,认定这个程序有很多缺陷和错误,甚至认定这个程序很垃圾,想象微软出来的程序都有很多缺陷,那我们的程序也一定需要我们去狠狠的去发掘缺陷。不能因为这个模块已经被测试过好多遍,或者这个模块非常小非常简单就忽略了对这个模块的测试。另一方面,要有足够的耐心。首先,在作探索性测试之前比较明显的缺陷和操作步骤比较简单的缺陷已经基本上被找到,探索性测试主要是挖掘深层次的缺陷。相对用例测试操作步骤相对复杂,因此探索性测试可能会出现长时间找不到缺陷的情况,如果心浮气躁可能放过对该模块的测试,这时需要耐心的测试才能找到缺陷。

6   Bug探索应该关注的重点
     在Bug探索测试开始之前,必须了解本次测试中,客户所关注的重点,在客户关注的重点区域,需要花费更多的精力来执行。
     1.  如果此次是一个小版本的迭代,只修改了部分功能,客户想了解的是修改的部分是否正确,对其他模块有没有影响,会不会影响整个业务逻辑,就要求测试人员更深层次的探索测试,不要停留在原来功能表面上的检查,更多的是三方交互、业务容错处理方向的探索。
     2.  如果此次探索是在用例测试后的补充测试,客户想了解的是更多在测试用例中看不到的Bug,就要求测试人员非常熟悉需求,跳出已有用例的框架,深层次的挖掘测试用例中没有的、非常规的测试场景下的功能是否正确。
     3.  探索过程中,需要根据APP的定位来安排测试重点,如:直播类的APP,客户更加关注的是直播质量、稳定性;电商类的APP,客户更加关注的是支付的逻辑运算,支付安全等。
     4.  Bug探索任务一般客户都有人数的要求,必须严格按照客户所要求的人数,设备大概需求安排测试人员,开始探索测试。

7   Bug探索报告编写规范
     找出Bug并给出报告是测试人员必须要面临的工作,那么如何写的更加规范,需要从以下方面来考虑。


     7.1   Bug有效性

     提交的Bug必须是有效的,就要求我们在提交Bug时,确认:需求是否明确、前提条件是否满足、输入数据是否正确、操作步骤是否清楚、Bug是否唯一性。避免提交设计如此、操作错误、重复的、已知的Bug;尽量少花时间在边界值、页面显示问题上,多提业务逻辑功能、交互测试方面的问题。
同时Bug探索中,需要多挖掘一些严重级别较高的Bug,不要停留在瑕疵级或者建议级的Bug层次上。


      7.2   Bug标题

      Bug标题很关键,要求简明扼要的阐述问题本质,使查看人员能快速了解Bug内容。需要写明在哪个页面执行什么操作出现什么现象。不明白的可以看一下下面的例子。
      正确举例:在我的设置页面不填写任何内容点击保存后,客户端崩溃。
      错误举例:1.设置页面保存问题(过于概括)。
                      2.设置页面崩溃(缺少导致现象的关键步骤)。
                      3.客户端崩溃(只有现象而无法定位问题位置)


       7.3   测试设备

       这一项主要包括测试使用的设备、设备操作系统版本、测试环境、网络类型等等。因为出现bug可能是因为设备不兼容,所以标明自己的测试设备能让查看人员知道运行的平台。


       7.4   前提条件

       进行测试的时候需要哪些设置或特殊条件,是在怎么样的情况下出现的bug。前提条件优势比较多,需要详细提供,这样有帮助于开发人员更快的去定位问题,有的bug要反复去测试,这个也要说明白。


       7.5   测试步骤

      要简明清晰分步骤描述如何复现bug问题,步骤用序号编排。要按照自己的操作的实际步骤写清楚每一步是怎么操作的,最后操作到哪个页面或者点击哪个按键。
      正确举例:
      1.“我的”页面点击用户头像进入个人资料页。
      2.个人资料页点击头像选择拍照,拍照后点击保存头像。
      3.从个人资料页返回 “我的”页面,查看头像是否更新。


      7.6   期望结果

      按照测试步骤应当得到的正确结果,按照产品需求的期望清晰准确的填写预期结果。而且结果必须是肯定无疑义,可判定性的结果。
      7.7   实际结果

      按照测试步骤实际出现的错误结果,避免使用“不正常”,“有误”等模糊词汇,需要直接描述实际现象。


      7.8   复现概率
      这一项一定要在多次测试的基础之上填写,若必定复现则填写100%,若偶现,请执行多次后统计概率填写。

      7.9   截图和附件
     有现象的Bug需要必要的截图证明;崩溃的Bug必须提供Log日志附件帮助定位问题,截图无法反应的问题需要上传操作视频文件。这样做是为了证明自己真的测试到的了bug,也能够让查看人员看到你测试的实际结果。

      7.10  备注
      其他有用信息,可以帮助修复Bug或更加全面了解软件当时的状况等。如果没有,该项可以不填写。

8   风险分析
     1.    探索性测试没有固定的用例,强调测试人员的主观能动性,容易出现功能点遗漏测试的情况,需要测试人员有很好的测试经验和对需求的了解。
    2.    Bug探索测试任务周期短,任务紧,需求沟通就要求及时反馈,探索性测试最好由具有丰富测试经验的且熟悉被测软件的测试人员进行测试。
    3.    Bug探索中发现的Bug大多是边界值类、页面显示等很浅显的问题,业务逻辑、三方交互、容错处理方面发现的问题较少。