软件测试的存在的难处[2]

         软件测试的存在的难处[2]  软件测试　

    　体现测试的价值有很多的难点，下面我逐一说明：

　　1.测试的成果多是无形资产，很难衡量。产品质量和企业形象这类资产可以说是测试能产生的最直接结果，但是这种资产，将会很难度量。测试能产生的第二类成果是提高开发的能力，也同样属于难以衡量的结果。

　　2.被识别的测试成果很容易被忽略是测试的价值。一提到优秀的软件，很多人首先想到的就是高超的程序设计，娴熟的编程技巧，成熟的软件过程，很少人想到是经过了严格而全面的测试。测试总是生存在这个被遗忘的角落。

　　3. 过多的体现测试的价值会造成开发和测试的对立。测试能产生的最直观的结果就是缺陷，而缺陷恰恰是证明了开发的不足(虽然说是对事不对人，但是谁有能看到自己写的程序被人吹毛求疵，还拿结果来作为其工作成果而保证不大动肝火呢?)过多的强调测试价值，会让敌对的情绪滋生，所以明智的产品经理，往往会弱化测试的功效，而趋向于建立起一种平衡。所以，现阶段测试价值的体现，往往决定于领导者对测试的态度，测试的价值也只有在他的心中能有所体现。这种不能得到大多数人广泛认同的局面，明显是不利于建立测试的权威性和其它人员对测试活动的支持的。找到恰当的体现测试价值的方法，是困扰测试经理和对测试有良好认识的产品经理的一个大问题。

　　4.有关测试模式的思考对测试模式的想法完全起源于设计模式。既然能够把复杂的体系结构设计能抽象，总结成这么一套东西，为什么不能对测试活动也如是观之呢?

　　现在我对模式的理解还不是很深，也没有很多的测试经验，所以到现在为止，只能抽象成一种模式，我将其命名为包含模式(include)模块A中引用模块B作为A的子功能，这时的测试方法应该是先测试B模块，然后再将B模块中的任何一个路径作为A的一部分来测试A模块，这时B模块中的任何一条路径，已经被同化成等价类(虽然在B模块的测试中，它们可能不属于同一个等价类)

　　(这只是一种思维构想，希望能够抛砖引玉，能将这个体系完善起来)

　　5.测试与开发的关系测试到底和开发处在怎么样的一个关系下才能够较好的产生测试应该达到的效果呢?

　　测试部门独立于开发部门。这种模式可能源于传统制造行业的QC和生产部门的分开。其目的是为了保证测试过程和测试结果的客观性和有效性。这种模式相当于把测试和开发分成两个泾渭分明的活动，并没有过多的考虑两种活动之间的互为补益。在这种模式下，很可能演变成测试和开发之间的对立，或者增加测试和开发之间的沟通成本。边测试，边开发。这是XP的轻量级开发过程所倡导的，现在的测试驱动开发理论就是符合了这种模式。采用先设计测试，再进行开发，当开发的软件通过了所有的测试，软件就完成了。这种方式其实并没有规避自己测试自己代码所产生的局限性问题，只是将思维的顺序作了些改变，降低了思维定式对软件开发产生缺陷的影响。

　　测试部门属于研发中心，但独立于项目组。这种模式保证了测试与项目组之间的最终目标的一致性(高质量的软件产品)，能有效的降低沟通成本，又能保证测试人员有一定的独立性，不会过分的受产品经理的控制，避免测试失效现象产生。但在这种情况下，相比两个部门独立，测试的结果有可能不会被项目组所重视，需要频繁的进行协调，才能及时处理缺陷。

原文转自：http://www.ltesting.net