关于测试的一些看法和争论

luming

在csdn回答一个问题的过程中，我和一位叫可战的网友发生了冲突，我个人认为他的一些观点有问题，对测试人员的态度不够友好。不过最后我们经过几轮的回复，发现是一些环境和地位的不同造成的误会，大家的实际情况是否和我们两个有类似的情况，欢迎大家进行讨论。
原帖地址在http://community.csdn.net/Expert/TopicView3.asp?id=3867252，看最后的部分就可以，我转载的也只是最后的内容。
下面的内容经过部分的修改和整理。


doer_ljy(可战)：        
我测试没做多长时间，一年多的测试负责人吧，后面就是项目控制的时候做过结合测试。肯定不如你经验丰富。
我们这里所有的测试都要有文档，测试数据。
我不是贬低你的工作，可是你那样实在没有效率。也没有办法很好的保证程序的质量。
也许我太理论化了，不过几十个人合作没有文档简直是灾难。这一点却深有体会。
同时，我不喜欢你的工作态度。这样好像没有办法让别人信任你的工作结果。
不过你说的测试时间不足等等，确实存在。有时会很严重。
但这个问题可能是你们PM需要解决的吧。
在时间紧的时候有些做法可以谅解，但是不能拿出来作为理论讨论是吧？


pyp(鹿鸣)：        
理论是理论，实际是实际，理论方面我看的应该也不少了，还有各个测试论坛也常去，但大家说的都很好听，但实际至少在我们这里用不上。
所以我这里说的只是经验而不是理论。
虽然你做过测试，但看来对测试你并不很满意，否则就不应该用那种口气说话。
不清楚你说的测试文档和测试数据说的是什么，即使再好的文档和数据，也只能起一个指导的作用，真正发现问题的还是干活的人。
我并不认为我的观点和想法有什么问题，文档我也写，测试计划是我们经理写，但用例和总结基本都是我写以后我们经理进行确认。
也许是因为我们的规模小，所以并不很正规，但实际就是实际，我不会用好听的理论去告诉别人，我只会说我的经验而已。
对于测试人员辅助开发的想法，一直都存在，最新的《测试员》上面也说到了这个问题。
我个人不是很赞同这种观点，本来也想写东西进行反驳，但后来看到有人说的已经很好了，下面是一位叫“叶子”的朋友的回复，观点我完全赞同。
叶子的话：“非常赞同前面‘不要给开发建议怎么改错来限制他的思路’。这个很重要，而且，实际中也碰到一些，毕竟测试人员对程序构架及内部结构没有开发人员那么熟悉，比较有深度或关联比较复杂的bug，测试人员其实是很难定位到的，而测试人员能够定位到的，也不过是些相对独立或简单的问题，而这些问题开发人员是很容易定位到的。（这并不强调测试人员水平不如开发人员，只是强调，测试人员对内部结构和关联并不清楚），所以并没有起到太多作用。这样做除了限制开发人员的思路，还有比较大的一个负面效果是：容易引起开发人员的反感 -------他会觉得你有点指手划脚的意思，当然如果某次定位正确了，他没什么话说，但如果一旦定位错了，他就有我刚才提到的想法了，几次不正确的定位描述下来，很容易降低开发人员对测试人员的重视和信任。也有同学说，开发，测试是一个整体，应该协调合作，不分彼此。。。。。这话我觉得对一半，错一半，作为一个项目团队来说，的确是一个整体的，需要协调合作，但并不意味着就不分彼此，否则也就不用分职责分类了，所谓的协调合作应该是各尽其责任，而不是不分彼此。虽然目的一样，但责任还是不一样的，工作重点也是不同的。---------为了累计经验，比较有意思的bug，测试人员自己可以定位，自己记录，等开发人员回复之后，看看跟自己当初的想法是否一样，长期积累，也许以后碰到类似的问题就可以提点有建设性的意见了，也能让别人信服。所以我的建议是不太确定的就不要轻易给定位了，如果能明确当然定位最好了。
无需定位问题，并不等于测试人员发现问题就一锅端上去，描述也不是越多越好，有时候可能操作很多步骤或输入很多内容后出现某个bug，但真正引起bug的却只是其中一步和一项内容不对，测试人员要做的应该是，尽量精炼步骤和输入内容，找出那一条，精准描述问题是对开发人员最好的帮助。”


doer_ljy(可战)：        
声明一下我对测试的态度。我自认从未对测试工作有过任何偏见。不知道我的发言中哪一点让你觉得“看来对测试你并不很满意”。我觉得这里面有一个问题，就是看问题的角度。从工程的角度（我在这里说的也是经验，既然你并不喜欢谈理论，我也不再谈理论。虽然我一直认为理论不一定都是无聊的人编出来骗人的），任何一个项目管理者都虚妄自己的项目是：有序的、易于调整的、可评估的。这首先需要项目进行的计划足够细化，这个细化的程度，我个人认为是一个最小的可评估单位。一个项目经过几次划分，最终成为若干个这样的单位。对于每个单位，我们有它的设计者、实现者、质量保障者。他们各司其职，但协同工作。那我我们如何保证“质量保障者”的工作质量呢？从项目管理者的角度，两点：一、他必须有完备的测试计划（这里包括测试者自己编制的、以及从设计者那里引用的若干文档）。二、他要有准确的测试实施报告。这两份东西都是可以评估的，同时具有责任的约束力。你提到的前面提到过测试人员自己的发挥，我的感觉很有效但是不保险。也就是说我不能靠测试人员的即兴发挥来保证我的系统的质量和稳定性。因为里面有太多的不确定性。比如测试者经验会参差不齐，比如他们的技术能力和对BUG的预见能力不一样，甚至他们的心情等等。我相信他们能做好，但是这不能作为我保证自己系统质量的手段。
写到这里我忽然有点明白PYP为何觉得我“不尊重” 测试者了。的确，我的口气可能有点重了，但是不是对测试者而是对软件工程（这里不是指软件工程理论，而是指它本身）不重视的人。任何事情，想要完成好必然要有他一套成型的方法和思路。不只是软件测试，简单一点，一块饼干我们测试质量是否合格首先要做什么？无论是厂家还是食品监督局，他们检验者有自己的标准和检验流程。你说他们是通过流程和方法来保证的质量还是通过人来把握的质量？对于一个工程，我们要努力作的是弱化个人在其中的作用，而强调团队和科学管理。我们中国软件业铺天盖地，却难成大气跟这个很有关系。谁都喜欢英雄力挽狂澜，但是在“没有英雄的年代”我们不是还得好好的活下去嘛。
然后关于“辅助开发的想法”的问题，我觉得可能是个误会。你说得挺好，我觉得也是应该做到那一步就足够了。我觉得让测试人员帮开发人员发现“BUG是在哪句代码里出现的”这事儿是万万不能的。毕竟大家各司其职。如你所说的，提供线索也就足够了！
最后，有个有点失礼的问题：你所在的公司对测试人员是怎么看的呢？
我先说我们公司，项目组中测试人员有统一的专注测试的leader，他们只对测试Leader和自己负责的程序负责，不受开发组的任何“领导”指挥。在选人上，基本用两种人：1、“工作仔细”，这是女生的特性。2、思维严谨，有时候是技术也要比较好的。所以，没有人“瞧不起”测试工作和作测试的人。

luming

pyp(鹿鸣) ：
我做测试也三年多了，从工作就开始做测试，做到现在。理论我一向都很关注，所以市面上有什么测试书籍，我都会买来看，网上的测试资料和测试论坛也每天都要看的，测试有什么新东西我想第一时间我就会去注意。
现在我发现自己到了一个瓶颈，工作成为了一种习惯，很久没有太大的提高。所以才努力的总结自己已有的经验，希望能找到一条出路。
你说项目管理者希望项目是有序的、易于调整的、可评估的。但这些对需求、设计、编码阶段都比较容易，到测试这一块，却容易发生一些问题。
说说测试的一些事情。按照习惯上的测试理论，测试应该早期介入软件开发过程，并进行详细的测试计划和写测试用例。这里其实隐含这很多的东西，主要是人力、时间还有开发流程的问题。
好像国外的大公司，对测试比较的重视，测试和开发的比例都很高，当然了，他们的测试要深入代码级，所以需要的人也多一些。现在国内测试和开发的比例能有1： 10我想就很不容易了，而且测试需要有小组的形式，单人做的效果和效率都不一定太好，所以一般正规点的测试都独立于开发。我想这是一个基本的共识。这样实际涉及项目组间配合的问题，现在国内的测试部门，由于水平能力等关系，实际大部分都在黑盒阶段。这样如果要写测试用例，就必须需要想当长的时间和详细的文档。我想没有文档，光想像软件会是什么样子，应该没有人能写出测试用例来的吧。特别是详细的带数据的测试用例。
这样就涉及到一个前期文档的问题。现在中国的软件工程程度，我想做过开发的都知道，文档在哪里？在程序员的脑子里。很遗憾的是，测试人员无法把程序员的脑子橇开看里面到底有什么，也许程序员在没有开发出来之前，对程序本身也可能只有一个模糊的印象而已。在这种情况下，要求测试人员写用例，好像困难些了吧。
这样一般来说，用例的编写就需要在程序开发到差不多的时候进行。现在开发的产品，实际时间都不多，3个月、半年，能成年的软件很少吧。除去需求、设计，给程序员写代码的时间都不多，留给测试人员的时间能有多少呢？
真正详细的测试用例，写几万条是很正常不过的事情，因为要覆盖很多的情况。但这样的一个问题就是需要很多的人去写，周期也比较长，还需要花很多的时间维护（需求变动、程序修改，用例可能也要修改，而且可能几百上千的修改用例，很容易进去几个工作日），这些人和时间去哪里找？
当然了，我不否认有做的好的公司，大家的文档都做的很好，测试人员很早就可以进入，很早就可以规划和写用例，但我想这样的公司应该是凤毛麟角吧。
现在软件工程的一个趋势其实是弱化文档，比如XP，追求快速开发，对编码有利，到测试这里是很麻烦的。
我同意一种观点，做到最后，应该是不需要测试，也就是说，程序本身没有问题，问题的关键在业务流程上，换句话，测试最后需要的是业务专家，而不是测试人员。但现在至少我测试过的程序还无法达到这种程序，软件本身的问题还是成堆，所以还是需要我们测试员的。
在现阶段，可度量的测试过程还很不容易，因为无法用bug数去考核测试人员，测试用例也不可取，因为要评审，所以会很麻烦。
你的观点我明白，像CMM一样，弱化人，强化流程和管理，一切要求可控。但实际执行太不容易了。
我们公司是CMM2，测试部门是完全独立的。我们公司的集团下面分为两个公司，测试部有两个部分，软件测试和硬件测试，分属两个公司，但是都是一个经理在领导。我们软件测试这边，算上我们经理4个人，一般大的程序给的测试时间是2周左右，小的就2、3天，嗯，测试都不够（因为要算上提交缺陷、修改、再验证等时间），所以用例有时间就去补，没有时间就算了。写了也是很简单的，可以说只是测试思路和流程而算不上具体的用例。可以看看这个帖子（http://community.csdn.net/Expert/TopicView3.asp?id=3671025），就知道我的工作大概是什么样子的了。
我们的人么，呵呵，1个原先做配置管理、1个原先做QA的，所以小活一般都我自己做了，也有人多的时候，但公司给的money太少（500～700），全部跑掉了。
对于测试，我认为男女不重要，最关键的是想做测试。现在测试待遇不很好，所以很少想做测试的人。只要有心做测试，所有的都可以学习，不会有什么问题。


doer_ljy(可战)：
看了你提到的帖子，发现我的认识确实以偏概全。不过我想你我可能都是从自己所在的为基准看待这个问题的。最多加上我们身边的一些公司。所以，不能代表全部的情况。
说说我所在公司的情况吧，客户往往是外国人他们不但会要求提交完整的代码。也会要求提供完整的文档。当然包括测试用例和测试结果报告，有时甚至是每一张 BUG票。所以我们在做项目安排的时候都给测试留有相对充分的时间，所以我认为测试是可以XXXX样的。但是看了你的工作状况，我发现这个想法确实有点偏颇。实际上，我所做过的项目很少针对国内，不过我想在理论与实践的结合上。我们还应该有探讨的余地。
很多时候我都提到了领导对测试工作的认识。为什么要提这个，因为这个决定了测试工作的可利用资源的厚薄。这个不是一个测试者自己利用自身的技术理论能力所能解决的。
我们打个比方吧，一座大楼的质量控制：当你发现地基不牢的时候，像盖楼的资方（我们的boss）提出，这个楼的地基不牢，以后会出问题。结果她不以为然。然后根据你说“你不是搞质量检验的吗？楼盖好了再来吧”。OK，楼盖好了，你来了，被告知随便看看，给你一天的时间。我要验收合格的报告（呵呵，说实话归根到底你敢提交一份测试不合格的报告吗？）。你能怎样，纵你三头六臂你又能怎样？没有办法，还是那句话测试是一个系统工程，应该和软件开发的过程有机的融合起来。这需要上至PM下到tester都对测试工作有一个全面的认识才可以。所以，你说的"实际当中很难实现"我能明白。
最后谈点感想，随着中国软件开发能力的提高和规模的扩大。很多公司的已经开始对QA的重要性有所认识，并逐渐重视。我还是觉得这条路走下去，最终会走到测试理论中描述的那样。当然会比理论灵活和复杂的多。

[ Last edited by luming on 2005-6-1 at 11:17 ]