实际情况是这样的:
在我们所在的单位,因为测试部门人手不够,所以对所要测试的软件,只能采用功能和性能上的测试...
可往往很多BUG在测试过程中都测不到,而且在局方工程实施的时候却暴露在客户面前...
这个项目做了近1年,这时候在做代码测试,单元测试,可能花的代价太大了...而且该软件基本趋于稳定....这样做的意义也不大
问各位测友 有什么比较好的解决途径?或者有其他优化测试的方法?请赐教
小弟在这拜谢各位

软件的质量不是测试出来的，开发决定了软件的质量。
建议对在局方发现的BUG做根源分析，查出漏测的原因，然后亡羊补牢，这是没有办法的办法。

那么说明了你们的黑盒测试离用户的需求太远了。考虑考虑自己的问题吧，那些是应该发现的那些是确实有困难的

先优化了这个问题再优化别的吧

建议做一次code base 的测试!

我是新手,帮不了你啊

外包！！

怎么总是觉得问题比较严重的情况下才有人去注意，为什么不在一开始的时候就重视一下呢？我觉得这是你们管理上的问题，要是在一开始的时候就重视一下，也不会这样！开发的注意点，测试的在一开始就着手测试也不会有这么多的问题，而且问题竟让客户都能见到，再说也向有位朋友说过，好的质量不是测出来的！

我觉得贵公司的测试流程应该改进,因为即使你们做了近1年的项目到头来却不被客户认可,其实也挺郁闷的,与其花时间做这些工作倒不如改进优化测试流程.测试部门人员少,那么可以考虑让开发人员来做单元测试,或者从开发部门调一些人到测试部门做测试先;测试部门的人可以直接做系统测试,在系统测试前先做系统测试预测试来保证系统测试能顺利进行,另外做测试前要将测试计划和方案做好,指导测试顺利执行.

分析一下以前所有的BUG，采用80-20原则，看问题出在大部分是出在哪些模块，分析出错的原因，是由于开发人员疏忽引起的，还是有其它原因。重点测试出错的地方，人员不够，优先测试优先级高的需求。

怀疑“软件的质量不是测试出来的，开发决定了软件的质量”这句话
那还要测试干嘛啊
都做开发了

我个人认为质量的保证是大家共同的责任 不能单指开发或测试某一方

我也这样觉得，同意刘洪鹏，软件的质量应该跟开发和测试都脱离不了关系的。

实际情况是这样的:
1在我们所在的单位,因为测试部门人手不够,所以对所要测试的软件,只能采用功能和性能上的测试...
解决：向你的上级说明实际情况
2可往往很多BUG在测试过程中都测不到,而且在局方工程实施的时候却暴露在客户面前...
解决：提高自己发现bug的水平
3这个项目做了近1年,这时候在做代码测试,单元测试,可能花的代价太大了...而且该软件基本趋于稳定....这样做的意义也不大
解决：问题越早发现也好，我估计是需求没做好 ，现在唯一的解决方式是用户发现的问题，及时解决。总结教训
4问各位测友 有什么比较好的解决途径?或者有其他优化测试的方法?请赐教
解决：假如需求很难界定的话，建议你们在项目的前期就要求客户参与进来，可以不定时的进行用户体验测试，弥补需求的不足之处

我是新手~看不太懂你们在讲什么~！？

团队决定一切！！

引用:

原帖由 刘洪鹏 于 2007-7-9 10:55 发表
实际情况是这样的:
1在我们所在的单位,因为测试部门人手不够,所以对所要测试的软件,只能采用功能和性能上的测试...
解决：向你的上级说明实际情况
2可往往很多BUG在测试过程中都测不到,而且在局方工程实施的 ...

很好
受益匪浅
学习了

都说了在中国，测试是不受到重视的，我这里业是，可以讲测试的地位确实是很低，能测出什么东西吗？

....

sdlkfj1 测试新手～～～还在模糊阶段

作为测试人员，一定要透彻的了解客户的需求，特别是在进行系统和功能测试时，不知道需求那还测什么！这也是BUG不能在测试中被发现的一个原因。
再有，个人感觉在软件开发的过程中，一定要有客户的参与，可以定期或不定期的请客户参与软件的评测，这样可以在开发的过程中，听取客户的意见和建议，及时对开发中的偏差进行纠正，保证开发能够一直沿着客户的要求进行。而对于客户的意见和建议，则可以根据实际情况补充到测试方案和测试用例中，以便丰富测试的内容，使测试更贴近客户的需求。