报bug和设计用例的步骤

上一篇 / 下一篇  2011-12-05 16:40:50 / 天气: 大风 / 心情: 平静

     初入测试职场,没有开发背景,没有培训背景,曾经想放弃这个专业工作的我只因为一次偶然进入了测试行业。初入此行业快1年了,却不经意间越来越喜欢上它。但是在职业素养方面尽管自己努力的在学习(不过目前因为准备在职研究生的考试,有些忽略了)但是还是觉得不够系统,不够深入,即使在很基本的工作环节也还需要更多的学习。
     最近做一项目两个多月了,只是做了需求分析和测试,没有设计测试用例。mantis上面报告了318个bug,最近比较郁闷。报告的一些业务流程上面的bug,有些步骤比较复杂,写的复杂了怕开发一看就晕到时候只能落个骂名,尽量写的简单了又不能完美的表述。总会有一些业务流程的问题,开发会跑过来跟我确认。来的次数多了,不仅仅影响工作进度还影响心情。开发也是刚工作的,他们对业务流程也不是特别熟悉,老是问我这么改行不行,要怎么改,我也是个新人,问题理解的也不是很到位,只能问问老大,琢磨琢磨需求。这也给老大发送一个讯息,我报的bug有问题。确实报bug的时候也纠结过,向前辈们请教过,学习过,但是还是困惑多多。今天我们项目组简单的讨论了下,我做了总结,我想这将会使我bug的能力能有一个提高。

   bug需要注意的地方:

1.  报告bug的时候通常不要有错别字

2.  报告bug的时候尽量详尽的写出各个步骤和提示便于开发更快速的解决问题

3.  再涉及到公式计算的bug的时候,预期最好写上公式,或者在描述bug的时候用公式说明这样更直观更简洁

4.  报告bug的时候截图很重要,在图上可以做一些标注

5.  报告bug的时候不要一味的固守简洁的原则,关键在于开发能够看懂自己的bug描述,能够帮助他们快速并准确定位问题所在。

6.  有些时候有些bug可能反应不同方面的问题,所以在描述它的时候要抓住bug的重点问题去描述,这样更容易抓住核心

7.  测试的时候要遵循快速、准确、全面的原则,不仅仅能够发现流程上面的大问题,还要快速、准确全面的发现和其有关的问题。

 如何让困倦疲惫的程序员更容易理解重现bug的步骤

1. 一次只走查该错误的一步

2. 为每一步编号

3. 不要跳过重现步骤的任何一个步骤

4. 列出读者能够重现bug的最少步骤集

5. 通过空行使报告更容易浏览

6. 使用简短的句子

7. 说明实际发生了什么,预期会发生什么

8. 如果后果很严重而有理由怀疑程序员不理解为什么严重,可以说明为什么自己认为严重

9. 如果便于程序员意识到问题或自己在问题修改后重新测试可以补充注释

10. 对于复杂的产品或问题,可以使用头三行来小结问题,然后给出问题细节

11. 要保持中立语气,不要开玩笑,让别人误解

   写测试用例的步骤:

1.  当你拿到一个用例编写任务的时候,首先要分析一下你负责的这个模块在整个系统中的位置,属于流程中的哪个节点..

2.  然后,在脑子里形成你认为比较合理的思路,可以在纸上先简单的列出来。在写的过程中,因为具体到细节可能很多时候你需要将之前的思路打破,重新规划。只有经过这样一个反复,写出的用例在比较缜密。

3.  在写测试用例的时候要遵循先流程和功能,后界面和输入框的验证问题,尽量把输入框验证问题放到最后。

 


TAG:

sandra111231的个人空间 引用 删除 sandra111231   /   2013-05-06 10:53:30
1
Jenny_zst的个人空间 引用 删除 Jenny_zst   /   2012-01-05 15:22:00
5
 

评分:0

我来说两句

Open Toolbar