怎么在测试中提高自己？

liaoliao · 发表于 2005-4-12 15:08:44

我现在主要是在做功能测试，很想再提高自己，希望能做一些单元测试，但是JAVA从来没有学过，我看了一些资料，说不是光能看懂程序就可以做的测试，我现在迷茫的都不知道如何来制定学习计划。
测试中运用了tomcat,webphere,weblogic,jrun,但这些对我来说都是新鲜事物，也不知道如何去有效的学习，现在都在论坛上东看看西看看，找不到感觉。

我现在一直都很苦恼这此问题，希望大家能帮助我分析一下。

wuhuawu09 · 发表于 2006-12-8 16:58:34

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

liaoliao · 发表于 2006-12-8 15:02:17

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

littleqiang · 发表于 2005-5-5 17:46:44

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

sindy_yao · 发表于 2005-4-29 15:45:41

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

圣诞 · 发表于 2005-4-29 15:08:22

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

doiryice · 发表于 2005-4-27 11:19:47

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

Chenny · 发表于 2005-4-25 21:06:49

这对你更有用！！

霞子 · 发表于 2005-4-25 10:36:40

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

Nio · 发表于 2005-4-21 13:08:53

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

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

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

kpxl · 发表于 2005-4-21 12:35:31

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

Nio · 发表于 2005-4-21 11:36:56

楼上说得也有道理：

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

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

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

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

TestOrNotTest · 发表于 2005-4-21 11:03:13

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

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

wzb521 · 发表于 2005-4-21 10:31:33

呵呵，看看微软的补丁有多大、微软的测试比例有多少，你就对自己有信心了~~

：）

不要丧气，更不要颓废

Nio · 发表于 2005-4-21 09:51:48

"花18个人月找出10个bug的团队偶也见过的，没人敢说他们找bug的能力不强"
——我想说的是：老板如果能无视这种情况的存在，应该说是这个团队的幸运。

花18个月，这个团队才找到10个BUG，我很难接受这样的测试团队，更无法证明其能力。

专业软件测试公司，发现一个BUG的回报在50~200元之间，从价值观上讲工作日平均要发现2个BUG，一点也不为过。至于如果从没能在一日之内发现10个BUG，达到日平均2个BUG的要求的可能性不大。

证明自身测试能力的高低不在于其它，关键在于你发现了多少BUG？在整个项目中你的BUG总数所占的比重。我们排除所谓BUG的优先级，严重程度等因素——因为这些无法确切的定量考察。但我们不反对对发现BUG进行分析，不过公司是不会给那么多空闲时间让我们去做评定测试人员测试水平的BUG分析工作。

任何程序都存在无穷无尽的BUG，我们也没有必要去抱怨，说我测试的这个模块就是没什么BUG么！——为什么你没分到BUG多的模块，以便更好的证明你的测试能力？

——尽可能多而快的找到BUG，是测试工作的重心。

[ Last edited by Nio on 2005-4-21 at 09:53 ]

lyh668 · 发表于 2005-4-21 08:58:53

面向对象的一些测试方法

myang · 发表于 2005-4-21 08:36:13

说的很对阿

TestOrNotTest · 发表于 2005-4-20 15:40:06

Originally posted by Nio at 2005-4-18 11:40 AM:
个人的一些想法：
如果测试中从没有出现过一天发现10个BUG的经历，可能你找BUG的能力还需要提高。如果你日平均BUG数在2个以下，你找BUG的能力还是要提高。提高测试能力的途径有很多……“学会思考、学会总结、学 ...

这是什么理论，花18个人月找出10个bug的团队偶也见过的，没人敢说他们找bug的能力不强:|

loadRunner · 发表于 2005-4-20 14:11:36

怎样提高自己的测试水平的确值的大家进一步的思考?我现在对自己走测试这一条路也很迷茫!

云层 · 发表于 2005-4-20 13:31:22

比较支持nio的说法

		自动登录	找回密码
密码			(注-册)加入51Testing

怎么在测试中提高自己？

相关帖子

好久的贴子了

我也在疑惑

如果没事作，就编测试程序吧

多看些java资料

我也有这样的感觉!

站长推荐 /1