网络文明用语尽在我们指尖；知识的传递与共享也在我们指尖；
发布新日志
-
2008-10-07 16:24:29
首先测试发现Bug并提交bug（bug状态为new/Active），然后分配bug(bug状态为assigned)，开发人员接收并修改bug（bug状态为fixed/Resolved），最后测试人员验证bug(bug状态为Closed)
此时肯定有人会发现问题，这么简单的流程图是太理想化了，无法满足实际。这是当然，Bug是可以‘死而复生’的，也许在下个版本问题有再次出现，又或许从测试人员角度讲，问题验证不通过怎么办？从管理及开发角度想，这不是bug又怎么办。带着这些疑问，我们进一步完善流程图。
基本可以满足一般的使用。但是我们忽略了一点，bug是有分类的“严重程度（Severity）和优先级别（Priority）”。在实际的应用中，很多项目的bug都比较多，而此时由于bug只在非极端条件下产生或者修改需要牵动这个框架，会造成更多的潜在缺陷，在悲观点就是面对市场压力需要尽快发布的情况等。Bug是否被修改？什么时候修改？就是需要定夺的了。又想到一点，如果此项目是多个测试人员同时测试，那是否bug会提交重复呢？理清楚思路后，就可以在进一步完善我们的流程图啦！
查看(1079)
评论(2)
收藏
分享
管理
-
2008-01-10 15:21:56
序
开博不是第一天，但是突然想写什么还是第一天。平时工作就是工作，有什么想法，什么经验都是自己在脑海起点涟漪就是了。最近测试一个项目，由于设计就存在很多缺陷，所以测试工作开展的是一波三折，也有一点点看法。鄙人文采实在一般，不求写的引人入胜，但求语句通顺。
10个项目组，就有9.9个项目组的项目经理是开发的。我在的组也不例外。如果你所在的项目组经理是做测试，不做开发的，请一定让我能够联系你。
最早，很多公司喜欢做过开发的人转型做测试。后来，开始有公司亲昧懂得测试的人做开发。很值得庆幸的事，至少大家认识到了测试的重要性。最近测试的项目，很多突发性的问题让我措手不及。在测试后期，头脑清醒，错误终于渐少。但是仍旧没有放松，曾经在某处看见过一句话“测试遗留的问题和已发现问题成正比”。乍听有些偏激，但是还是有一定道理哦。首先，已发现问题的多少至少可以判断开发团队的开发质量；其次，不可能存在没有Bug的程序，只是时间、空间（泛指环境、操作等）问题而已。为了进度，发现问题也是先汇报在登记，对于必须的“Steps to Reproduce”也就是口述了。在口诉Bug的时候，我突然更深的感受到了开发和测试思维方式。
由于都是在用户环境的模拟测试了，每发现一个问题都会追溯为什么没有在测试环境发现。因此Descrīption过后，都要追究是开发还是测试的责任的，如果是特殊数据造成的，那开发人员和测试人员都才能偷着乐了。
那天正巧，测试负责人早上没来。我直接去给PM 汇报Bug。我们的对话大致如下：
Me：×××××有个问题。
PM：这个问题测试用例覆盖到没有？在测试环境测试过没有？
…………
下午，测试负责人来了。我又去汇报了一遍：
Me:×××××发现了一个问题。
TL：这个问题需求里面明确没有？
…………
好鲜明的对比，我相信这不是推卸责任的表现，而是习惯性思维。假如项目经理是做测试的，你能够想象到什么？回帖，我们一起分享吧。
查看(324)
评论(3)
收藏
分享
管理
