转:个人阶段性测试总结

上一篇 / 下一篇  2011-07-12 18:50:50

个人阶段性测试总结

电话短信是开发与测试团队的第一正面交锋,呵,严重了。两个队伍在不断的磨合中进步,逐渐达到融洽的状态。

下面针对在过程中遇到的问题,提出个人一点经验和建议,以供参考,希望能为后续开发与测试之间工作的顺利开展起一点帮助作用。都是为更好的工作,以提高工作效率为目的。

测试注意的问题:

1、 表面层次的测试。今后可能要深入了解开发人员对软件功能是怎么实现的,去了解整个平台的架构,只有这样才能站在整个项目的高度去测试。而之前测试出来的bug,总感觉只是给开发描述bug的出现现象,而不能提出一些本质上的问题。这点对测试要求比较高,难度确实也比较大。通过不断的学习去实现。

2、 寻找bug要准确定位,描述要清楚。如果测试人员每次发现的bug描述不清楚,并且多个问题潜在的错误原因是一个,虽然操作可能稍微有些变化,但开发人员在重现bug的时候就要调试跟踪判断,很花费时间,而且效率低。所以,提供给开发人员最精确的步骤和准确的描述,可以节省大家的时间。对于不好描述的bug,最好先找开发当面描述一下。

3、 与开发的关系整体还不是很协调。对于接口层次的问题,向开发反应时,开发会条件反射的说出:这不是我的问题,是什么什么的问题。事情虽小,但反应出来一个问题:开发对测试有排斥心理。这可能需要时间去解决,沟通真是一门学问,不是一朝一夕的事,心有所向,必可改进。

4、 复现率低的问题,如果开发不配合,比较棘手。特别是历史遗留下来的问题,开发解决都不怎么积极,再加上复现率低,在处理上有一定的难度。这是存在的一个现象,可能需要慢慢去寻找解决办法。

开发注意的问题:

1、 需要不停的更新版本,不停的做回归测试。并且不知道该版本解决的是什么问题,解决的问题会不会影响到什么模块,为了保证软件质量我们也只能做回归测试,电话短信还行,毕竟功能点少,也好做回归,但对于将来的大项目呢?肯定有办法!

2、 TD使用不规范,尤其是comment。comment的追加其实很重要。当分配一个new状态的bug时,先把其open,然后add comment:说明该bug是什么类型的bug,应该怎么解决,解决这一个问题,可能会连带出哪些问题,影响到哪些模块,给测试的建议是什么。这样测试在具体的回归测试中,有测试重点。

3、 bug评审时用时太长。无论是开发还是测试都应该对TD中的bug如数家珍,这可以通过平时多沟通去实现。

4、 对于不能定位的问题,应有开发提出测试方案,测试协助配合开发工作。因为如果开发从代码关联性方面更容易定位问题。

5、 版本控制问题。对于易改的,级别较低的bug,还是建议集中修改,统一做回归验证,毕竟开发、测试都是一个研发团体,效率是需要共同提高的。

以上,测试开发注意的问题,是我以后工作改进的重点方向。
总之,通过前一阶段工作,我体会到三点:一是对发现的bug,自己一定要非常熟悉,向开发描述时要有理有据,思路清晰。二是bug在流出之前,测试内部先要成熟。特别是对不容易复现的问题,在起争议时也有后盾啊。三是体现出了团队协助的重要。开发不能准时提交测试,测试就不能准时完成回归测试,就不能准时给客户提交版本。开发测试团队是个整体,时间是等量的,时间不在你身上浪费,就是在他身上浪费。因此有问题大家共同齐心去解决才是硬道理。


TAG:

 

评分:0

我来说两句

日历

« 2024-03-25  
     12
3456789
10111213141516
17181920212223
24252627282930
31      

数据统计

  • 访问量: 9420
  • 日志数: 19
  • 建立时间: 2011-02-14
  • 更新时间: 2011-09-13

RSS订阅

Open Toolbar