项目不需要测试人员的原因是什么
解释一下，我说的不需要测试人员不是说这个项目不需要测试直接上线，而且说项目不需要“专职的测试人员”来对系统进行测试。一些项目直接在开发后，就由项目组的内部人员（可能是开发人员自己，可能是项目经理，但没有真正意义上的“专职测试人员”）来完成测试。那么他们不需要专职测试人员的原因是什么，我想了以下几点，不知道是不是这样：1 项目可能时间紧迫，需要赶在某一节点前上线，如果此时安排测试人员进来，那么首先他要先熟悉系统，了解需求，然后才能测试，那么这样一来，时间不够。
2 对测试人员的“不信任”。一些人会认为测试只是表面功夫，随便点点，最多也就能找到一些界面，功能上的问题，但是更深层次的问题，恐怕测试人员难以发现。
3 项目经理对测试观念的淡化。认为测试只是走一个形式，不需要安排专门的人来测试。忽略测试这一环节在项目中的作用。
4 考虑项目成本。多安排一个人，那么项目的成本支出上必然会多一份的支出，对于利润相对较小对的项目来说，找个专门的测试人员不合算
大概写了以上4点，可能还有很多种原因，大家也可以发表意见。
其实以上这些，都是不了解测试，或对测试不重视而产生的原因。作为测试人员，我们知道测试后的系统和没测试过的系统是有本质的区别的，对降低项目的风险也是很有必要的，甚至和以后对该项目的维护服务也是有必然关系的。那么，我们应该如何来体现测试的价值，或者说如何能让项目经理，开发团队了解到测试的重要性呢。换句话说，我们如何来推销自己？希望看到该帖子的朋友都能说说看自己的想法，我们的目的都是希望测试能得到越来越多的重视，能被项目所接受。谢谢 劝LZ一句，如果公司不重视测试，那就别费这个工夫了。凡事都是靠利益推动的。如果测试工作无法为公司带来利益，那自然不会被重视，怎么推销都没有用的。只有重视质量的公司，或者说只有质量能够给公司带来利益的时候，测试才会被重视。 现在有个问题是这样的。目前部门的一些项目已进入初验阶段，新的一些项目的项目经理都在喊缺人，缺人，然后开会的时候讨论了一下，结论是，为什么一些进入初验阶段的项目，开发人员还是全都扑在里面改bug，按照常理来说，项目进入初验阶段，意味着系统应该没有什么大的问题，可以交付给用户试用了。如果按照这样的理想情况的话，一个处于初验阶段的项目的开发人员应该不会有很多，最多留下1，2个改改小Bug，其余开发人员可以释放资源，那么新的项目就不会造成缺人的情况。之所以所有开发人员还再改Bug，那就说明项目本身在验收之前没有经过仔细认真的测试。那么从利益的角度来说，是不是可以认为由于没有经过完善的测试工作，导致开发人员一直在改bug，资源无法释放，从而新的项目无法顺利展开，进而使公司利益受损。
我会把上面分析的原因发给领导看一下，希望领导看到这个能把测试工作重视起来，谢谢“woza”提出的建议 自己顶 LZ思路不错。但是真正做起来还是有困难的。
你试图通过增加测试来减少后期开发（其实就是维护）的投入。如果开发方式不改变的话，在增加了测试投入之后，后期开发的投入未必会减少。因为测试增加之后，会发现更多问题，可能需要修复的BUG反而更多。
所以，增加测试投入虽然必要，但是更重要的是预防BUG发生，或者说一旦发现BUG，就要快速修复，防止在错误的基础上构建更多错误的功能。要达到这个目的，非的改变开发模式不可。建议采用持续集成以及测试并行。 谢谢woza的建议，所谓持续集成及测试，是不是理解为，开发完几个模块以后，马上进行集成测试，将问题扼杀在摇篮之中，这样的话，就会减少后面的修改bug的工作量，这样理解是否正确？ 测试是一门很深的学问。
就像LZ所说，可能因为项目回报低，可能缺人，但我认为测试是必要的，即使公司的软件团队已经到达一定的高度，也不可能保证软件没有BUG，就像Microsoft。
可能你可以找一些适用于本公司现状的一些方法，否则早晚要出问题的。 原帖由 ffwithvv 于 2010-1-12 10:28 发表 http://bbs.51testing.com/images/common/back.gif
谢谢woza的建议，所谓持续集成及测试，是不是理解为，开发完几个模块以后，马上进行集成测试，将问题扼杀在摇篮之中，这样的话，就会减少后面的修改bug的工作量，这样理解是否正确？
举个持续集成的例子：我们公司差不多每个小时都有人会check in代码。一旦check in事件发生，持续集成系统将会编译所有最新的代码，自动执行所有的单元测试；单元测试通过后，会接着执行模块测试；模块测试通过后，会自动部署Build，自动执行系统测试。最多一个小时，程序员就会知道自己写的代码有没有问题。
当然，要做到这一步不是一蹴而就的。一般先做单元测试。没有模块以及系统自动测试之前，可以由QA手动部署环境，并执行测试。尽可能做到，只要有代码变更，就做测试。这样比几个模块集成后再做，效果更好。 我觉得你们公司这样的模式很好，非常值得借鉴！但是我们这边的情况略有不同，我们的项目很分散，开发人员一般都在客户现场开发，很少一部分是在公司里面开发，这样分散的局面，我觉得测试管理起来会更困难。 能做到woza公司的这种模式的，国内公司应该没有多少家吧。。。大部分应该是楼主说的那种。。。 个人觉得是老板或者总经理这些领导不重视软件测试，其次是项目经理不懂管理这个团队，以及提高项目质量。
个人发展来说，你可以尽量按照规范来测试，并向相关人员提出测试流程，同时强调没有正规周期性测试的产品维护后果的严重程度；
补充一点，还是前期的计划没有做好，需求——设计——编码——测试——发布在立项初期都考虑周到
[ 本帖最后由 283017152 于 2010-1-20 11:36 编辑 ]
页:
[1]
