test到底是干啥的[From a MS Tester's blog]

上一篇 / 下一篇  2008-10-07 18:02:42 / 个人分类:测试生活

test到底是干啥的

这一趟去西雅图,回头想想,最大的收获就是弄明白了这两年一直想弄明白的事情.

 

这个事情就是,testms到底应该干什么

 

回答是,testintegration

 

这样说好了.先说那些事情dev,pm肯定不可能做,只有test才能做的

 

1.其它产品的改动导致了你产品的regression,test应该尽快发现.

 

比如说,你写了一个快速搜索文件的算法,一切ok.但是过了两个月,如果OS那边把打开文件的API改了一下,破坏了了你的程序,那无论是dev还是pm都不应该站出来在第一时间负责.test应该首先跳出来.如果test跳得不够早不够快抓得不够准确,就该去死.

换句话说,automation的主要目的是防止别人的改动,导致自己的regression.不要以为automation是为了防止自己dev的改动破坏了自己dev写的程序.(,都不知道怎么说好)

 

2.当所有的部件都好,不代表放在一起就好.test应该及早地做出评估,看看大家的东西放在一起后,是否如预期的那么好

 

比如说,有两个dev,还是写快速搜索文件算法.第一个写快速把文件从磁盘读入并且索引,第二个写快速排序.光看他们两个的程序都是一流的,所有的unit test跑下来都符合预期标准.但是放在一起后呢,发现第一个人读IO之所以快,是用内存换来的.第二个排序快,也是用内存换来的.放在一起后,内存就不够用了,或者就不满足整个程序的预期了.这种事情就应该让test来高效准确地评估出来.这就是为什么test要跑performance evluation,不是怀疑某一个dev写出来的东西perf不够好,而是怕大家perf都好的模块,放在一起后,整体程序的perf却不够好.

 

除此以外,feature也有类似问题.比如pm说客户喜欢拖拉,于是我们有拖拉.pm还说客户喜欢鼠标中键,于是我们有鼠标中键.后来在产品中,我们发现不仅仅有了拖拉和中键,我们还有用中键进行拖拉.但是偏偏客户从来就不用中键进行拖拉.所以test要搞清楚,我们预先想好的feature list,最后放在一起后,是否真正体现了客户需求.

 

所以说,test工作还是integration

 

接下来再说说那些事情不因该test去做

 

1.某一个具体方法的功能测试.比如做查询的时候是否考虑了星号感叹号,做文件操作的时候是否考虑了用户权限

 

这样的事情完全应该是dev自己搞定的.话说是,自己的代码自己负责.那里有说写了代码结果能让别人找出功能上的缺陷的.不管是手动测试还是unit test,反正都应该是dev自己搞定.而且以后如果有改动,自己的regression也要自己搞定,理想情况下test碰都不应该去碰.

 

有人可能会说,这肯定不行,完全是颠覆性的言论.听我解释.首先,test又不天天玩你的代码,你天天看都还不看出来,你觉得test何德何能比你能多看一点?其次,为什么要开销更多的人来做同一个事情,开销能省就省!最后,万一出了问题,责任人是谁?dev还是test?休想把责任给test,谁写代码谁负责,不然就把工资给test.指望test来帮dev的忙去提高代码的质量,如果不是dev太弱了需要test帮忙成长的话,这个dev不如去找板砖自杀了

 

可能还有人会说,人无完人,测试就是需要多个人一起来检查,如同会计和出纳要互相监督一样.,但是这并不代表test的工作.这个事情谁都可以做,最好让dev互相之间去做.或者,dev请求test来有针对性的做.

 

2. feature review.比如去检查pm定义的feature是否真正体现了客户需要.

 

这种事情如果让test来做的话,pm也可以把工资的一半给test.pm工作是否合格,应该由pm的老板去看,test来指手画脚干啥.你说你一个pm在外面天天跟客户嘻嘻哈哈,最后还要让test来说这个feature不好,没对某某类型的客户没有照顾周到,这个pm不是该拉去上吊么

还是同前面说的,test应该站在integration的角度,来确保pm定义的每一个美好而正确的需求,放在一起后不会造成相反的结果

 

当然还有一些是大家都要做的,比如coverage,比如如何把bug扼杀在checkin以前,如何高效的交流,这里就不偏题了......

 

当然啦,上面说的都是最最理想的情况,而且是我的个人理解.不要对号入座

 

最后就可以总结推导出test的要求了

 

1.知识面要广,不然怎么integration

2. Codedesign的能够要强.Automation要多快好省.必然你手动去跑regression

3.了解产品,了解客户.否则是无法站在客户的需求对产品的整体(feature和质量)作准确的评估.

4.灵活.毕竟这不是理想的世界,更多情况你还是补devpm的工作.

 

回头一看,4点里面有3(1,3,4),是刚刚做test时候一个principle test当面给我说的.结果花了我2年时间来想......


TAG: 测试生活

 

评分:0

我来说两句

日历

« 2024-04-01  
 123456
78910111213
14151617181920
21222324252627
282930    

我的存档

数据统计

  • 访问量: 2208
  • 日志数: 2
  • 建立时间: 2008-10-07
  • 更新时间: 2008-10-07

RSS订阅

Open Toolbar