实在是怒了，混乱中的测试
今天实在是怒了，无法入睡，在床上用手机发贴。不知道有多少同行和我有相同的处境，还是这就是我公司的特色。我目前负责测试的项目，是在一个现有系统的基础上进行功能扩展。测试需要检查功能扩展后，是否会影响原有的功能。但客户只是描述了需要扩展的功能，却没有提供原有功能的说明。于是我向PM反应了这个问题。你猜怎么着，PM说大家谁都不知道原来功能的逻辑，都是看代码研究的。还要求我们测试组要读代码，并和开发组探讨需求。
我一时无语，回过神来说，我们测试组不像开发组那么熟悉代码，让我们研究有点困难。PM认为这不是理由。我真是没想法了，谁都知道术业有专工的道理。而且谁来确保我们研究出来的就是正确的呢？我们花时间研究代码了，谁补偿我们用例写作的时间呢？PM不该负责和客户沟通，获取信息吗？
但人家是PM，我也没办法。先看数据库表结构，再看存储过程，有些眉目后，写了用例，并要求评审。结果一直没音讯，只好作罢。
等版本提交测试了，我们开始执行用例。结果发现用例中少检查了一张表。开发人员抱怨了，说怎么不检查。我说我并不知道这张表的逻辑，怎么检查。开发认为我们研究了代码了，应该知道。我回复说我们按照我们的研究情况，写了用例，要求评审了，你们为何不在那时提出。开发人员说看不懂我们的用例。我心想是你不好好看吧，我们都看代码了，你还看不懂用例呀。此时PM发话了，说我不该谴责他们不评审用例，因为一来没时间，二来也找不出问题。还做了个比喻，说如果叫测试组评审代码，能发现所有问题吗？
这叫什么事呀！难道做测试的要全才？即会开发，又会分析需求，更要会测试？
不光这个项目，我们公司所有项目都如出一辙，没有像样的需求。但这是可以通过沟通来弥补的。只是我那个团队的PM特别的狠，发明了这么新颖的理论。或者说这种理论早已问世，是我孤陋寡闻？ 这样的测试要求测试人员比开发人员还牛，目前这样小项目一般只有NB的项目经理和开发组长可以。
做为测试人员，比较难。如果我能做，可以给我PM的开发组长的工资吗？？？ 呵呵。达到这个水准的测试人员不是没有，不过测试已经不是他的主要工作了。
一个能够支撑开发团队，提供对需求、设计、代码逻辑等各方面达到一定水准的测试人员，很难找，也很贵。。。
另外，如果感觉有困难，还是请pm另觅高人吧。当然，还得在项目预算之内。
关于需求，不断沟通，不断确认，不断存档，不断跟踪，只能这样。如果在和客户及技术团队沟通之前，最好是提供原型，这样讨论起来比较实际。否则基本上都是纸上谈兵。没什么搞头，最后大家的认知很可能风马牛不相及。 我挺喜欢你们的工作内容的，我们现在的测试根本与代码及数据库沾不到边，感觉特没意思，做了一段时间都快把以前的编程知识及数据库知识给丢了，面对这种情况应该赶快加强自身的知识水平，没有压力就没有动力啊！ 我觉得自动化测试蛮好一方面可以做测试执行方面的一方面还可以写代码不至于那么无聊 一句话说的好 自动化测试可以把注意力转移到测试用例的设计上而不是执行上 有些问题需要别人的支持，而我们只能尽量做好自己的本份工作。
回复 5# 的帖子
自动化在需要重复执行的情况下确实好。但也有前提。整个项目必须要考虑到自动化测试的需求。而且自动化要求版本是稳定的，需求是明确的，预期结果和实际结果都是很明确的才行。以我目前的项目，算了吧。。。回复 4# 的帖子
这位兄弟说的也有几分道理。如果不和代码打交道，不和数据库打交道，确实会在代码能力上不断退步。作为测试人员，学习这些知识是为了了解开发技术，从而提高测试用例的设计能力。现在我的情况是，即使我会，也不敢让PM知道我还会写代码，不然以后再也得不到需求了，直接一堆代码扔过来。 我们测试组不像开发组那么熟悉代码，让我们研究有点困难。PM认为这不是理由。
开发人员说看不懂我们的用例。此时PM发话了，说我不该谴责他们不评审用例，因为一来没时间，二来也找不出问题。
唉。。。。。
[ 本帖最后由 千里 于 2009-6-9 11:45 编辑 ] 那就更简单了，既然不评审，那么测试出来的结果必须接受。因为不评审，有很多需求导致的差异化认知就必须要由开发组承担最后的责任。我给你机会纠正我的错误，你不要。那么后面进度上的滞后必须由开发组承担后果。
评审粗看是加大了工作量和工作内容，但最主要的是，评审可以规避显而易见的错误和问题。不知道你们的开发组和TL是否意识到了这一点。
无语
没有明确需求就不能开展测试，否则得出的结果也是不准确的。宁愿什么也不做，也不要基于假设去做什么，否则费力又不讨好。另外公司流程对测试的工作的开展来说是非常重要的，和客户确认好需求是PM的职责，和你们的老大好好沟通一下。:) 很多的PM都是拿工期啊，客户注重什么的来说事的，需要你的时候就说：“辛苦一下怎么怎么样的”，等项目完了就是没时间改了，放到以后吧，这个对客户不重要云云。PM的不作为使我们很难啊…… 碰上一个好的PM比碰上一个好单位都难。现在很多人都是在混。没办法。不正规的公司没发展。 你们pm完全是偏向开发那边，你们基本算是调试组，而不是测试组了 测试的目的就是为了验证需求....... 说的好，我们就是调试组，炮灰组。 我觉得可以让测试人员和开发人员坐在一起工作。开发完成一点，就测试一点。这样沟通效率高，而且不会把测试压力全部留到项目后期。还可以让整个团队来承担质量责任，而不仅仅是测试人员。
更好的做法是进行测试驱动开发。在代码开始之前，由测试和开发人员一起确定每个功能的通过标准。这样的话，测试起来好坏一目了然。开发也不会有意见。 遇到这样的项目其实开发人员也是很茫然的，所以我们要相互理解，多沟通。
可以像楼上说的可以和开发一起制定通过的标准，但是这个标准一定要得到客户的确认。
要不然就产生了一个误区：我们很可能被开发误导，认为开发的实现就是对的，从而不能很好的达到测试目的。
我现在的工作好多都是这种升级的项目，情况和楼主描述的差不多:) ls说的很对。通过标准应该是开发测试已即客户一起制定的。如果要修改，也要大家一起同意。 有压力会有成长的
页:
[1]
2
