怎么在测试中提高自己？

TestOrNotTest

偶只是说你在某种程度上误导别人，软件的复杂程度是不同的，bug数与代码行数增长之间的关系并不是线性的，bug的数目还和编码人员的编码水平有关系，此外在软件生命周期中的不同阶段发现bug的数量也是不同的。同样做不同测试找到bug所花费的代价是不同的，举个简单的例子，从银行的数据库系统中查找一个死锁的原因和你纠正一个GUI上的字符错误所花费的时间精力是不同的，当然这只是个极端的例子.仅仅从单位时间内的数量而不考虑质量的测试量化标准是很令人遗憾的，尽管我不想扣帽子，但你这确实是在误导新人。给楼主的建议是学习些基本知识，数据库，操作系统等等，尤其是编程语言如果你想做单元测试的话还是要有一定功底的。楼主之所以觉得没有系统，是因为自己什么都想学，所以觉得头绪很多，人的精力是有限的，不可能样样都精通的，确立自己的发展方向有目标的学习就不会有那种感觉了。

PS：To Nio:
偶举的是IBM 多伦多试验室的一个压力测试团队的例子，ibm的产品db2,louts, Tivol, websphere,rational,都是业界响当当的东西，如果你决的Sam Palmisano是个白痴，花那么多钱给一个测试团队，那偶也无话可说的。

Nio

楼上说得也有道理：

1、从银行的数据库系统中查找一个死锁的原因和你纠正一个GUI上的字符错误所花费的时间精力是不同的
查找BUG产生的原因与直接去找GUI的BUG花费的时间肯定是不同的。前者属复现BUG的问题，后者属找BUG的问题。

2、仅仅从单位时间内的数量而不考虑质量的测试量化标准是很令人遗憾的
这确实是不尽意的事，不过其它的大都无法量化，说服力更加不足。

3、压力测试团队
将测试能如此细分化，可见IBM对测试的重视。


另：
就中国国内的测试环境来说，很多同行都在为中小型软件公司服务，在这种情况下公司关注更多的是可以拿出来说事的数据，而不是空口白说呀。
我还是希望大家能关心起你每天发现的BUG数以及总BUG数在项目中的比重，这是证明自已非常有力的数据。

kpxl

不明白怎么又扯到报多少的Bug 上面了，如果单纯的追究bug的数量，那这样的公司，我觉得大家可以不用考虑了，同样一个问题，有人会进行总结，并且发现这个问题是由某一相同原因导致的，但是如果什么都不管，追求bug的数量，就可以报成很多个，你觉得这样有意义和价值吗？
还有，请不要动不动就说“专业的测试公司”，“国内的测试环境”这样的大话，好像你已经脱胎换骨，羽化成仙了。难道你非得用这样的词才能让别人信服你的话？可悲，可怜，从你的帖子中能看到你是有一定的测试经验，但是还远没有达到能指点测试行业这个江山的程度，做人要厚道！

Nio

——又来了一个吵架的！
回应kpxl的一个问题：

同样一个问题，有人会进行总结，并且发现这个问题是由某一相同原因导致的——find bug和debug还是有区别的。如果测试人员有机会参与BUG产生原因的分析，那再好不过。不过不是每个人都会参与BUG的调试。
从程序上讲，程序上的一个错误确实会产生很多不同的表象。不过要通过不同的表象，总结成是由同一个程序错误所产生的并非易事，需要时间并了解程序。
——软件本身是一个大程序，我可不可以归结为，所有发现的BUG都是由于这个大程序有问题而不必再写那么多的CASE和BUG了呢？也不能这么偏激。同样楼上的话是否过于偏激了呢？

[ Last edited by Nio on 2005-4-21 at 13:12 ]

霞子

彼此彼此了，正处于困惑阶段！！

Chenny

这对你更有用！！

doiryice

请教各位“大虾”，作测试不一定要精通各种编程语言吧？

圣诞

[所有的测试者肯定都有同感，不知道该怎么去做，说找不到北一点都不夸张 ]
有相同的感受啊!!!!!!!!!相见恨晚!!!!!!

sindy_yao

多学点编程语言知识对测试肯定是有好处的，如果做单元测试，你最起码要看得懂程序

littleqiang

不是在乎数量，而是在乎质量

liaoliao

今天看到了很熟悉
其间经过磨练，对软件工程都有了一些掌握，慢慢的偏向QA了，其实我还是蛮喜欢做有技术含量的测试。

wuhuawu09

LZ这一年内有什么收获,和我们新手分享一下.....谢谢