缺陷管理之测试新手

  Coness
阅读 50 次  0 条评论
初入测试,基本上算是在一个接一个测试任务的境况下度过的。 某一天任务比较轻松,迅速交付之后便些前辈们编好的用例学习学习,等待着下一个项目的发布。就在这难得的闲暇时间,部门的同事却发现了一个在平时根本想不到的BUG,这个情况迅速引起了大伙儿的好奇,纷纷 围观过去。 简单地形容一下这个BUG吧: 此BUG主要是在某种情况下,点击界面按钮并不会出现相应的跳转,而会直接回到登录页面,且无论你如何进行操作,用户不会被注销下线,但由于这个问题是需要特定的操作才会出现的,所以当同事进行复现沟通时,难以正常体现BUG的存在,导致开发不认缺陷,至此小小撕逼,回来当然和大伙吐槽。 既然复现困难(TestBird教你轻松复现BUG场景),同事只有放弃,但在私下讨论时,这点依然是我们比较热衷的话题,同事很长时间都没有放弃这个问题,每每休息时,他都会不断回忆发现这个BUG前的所有操作,然后按着操作步骤重新进行,功夫不负有心人,一天之后,他终于找到了所需要的特定操作。 你就是在特定的页面,查看一下这个页面关于一个特定的词汇的解释页面,然后再去其他页面做一些操作就会出现上面说的情况。而且从软件或是表面来看,这个词汇的解释页面跟那几个页面根本没有任何关联,代码上不知道开发是怎么处理的会导致这样的情况,当我再一次来到开发办公室告诉他们百分百复现的操作步骤时,他们也懵了,直到现在(2天前的事)也没有找到问题和解决办法。 因为这一次缺陷的发现,让我对软件测试、黑盒测试的看法有了更深刻的一些认识:    1、你往往认为没有关联的元素、操作和页面,在代码处理或者数据传输上却可能会产生干涉;    2、在测试时尽量多记住自己的每一个操作步骤,这样在发现缺陷后进行重现时才会少花很多时间;    3、测试用例设计的再好、覆盖率再高,也不能保证所有用例通过了系统就没问题了,一些问题是用例设计方法永远无法覆盖到的。 有了这些认识,我立马又上禅道查看下一期项目的需求和已经上传的测试用例,进一步提高用例的覆盖率,并在笔记本上单独设计一些看似前后没有关联,但与上面的缺陷较为相似的一些用例,因为这些用例的特殊性,所以我没有上传禅道,只是单独记到笔记本上。待到测试时,禅道上的用例测试完成后,也将这些一起执行,或许现在想到还不够全面,而且在不同的时间、不同的环境下还可能会想到更多的一些操作用例,我都会将其记录下来,或者立即执行以下(在可以执行的情况下)。

0条回复

主题回复:

(您需要 登录 后才能回复 没有账号 ?)
  • 支持 Markdown 格式, **粗体**、~~删除线~~、`单行代码`
  • 支持 @ 本站用户;支持表情(输入 : 提示),见 Emoji cheat sheet