RUP测试过程实践(8)

　　如何评价测试用例的好坏?

　　这部分内容的出现，完全是因为不久前同几个朋友的一次讨论。当时大家都认为对于一个测试用例好坏的评价，无外乎两个标准：是否可以发现尚未发现的软件缺陷?是否可以覆盖全部的测试需求?但是后来发现这两个标准对于一些问题是处理不了的。例如，对于一个质量非常好的软件产品，存在的软件缺陷异乎寻常的少，测试用例设计人员准备了大量的测试用例，已经完全覆盖了测试需求，但是只有很少一部分测试用例在执行时发现了缺陷，而其他用例都顺利通过了。那么是否就可以认为顺利通过的那部分测试用例不好呢?对于这个问题，笔者认为不管是测试用例是否可以发现尚未发现的缺陷，还是测试用例对测试需求的覆盖度，都是用来评估测试设计人员工作能力和经验的标准，而对于如何评价测试用例的优劣，应该还有其他标准。当然，在不同的团队中可能存在不同的标准，但下面两条应该是适合于任何团队的。 1.易用性。对于一个即熟悉测试工作，又熟悉被测应用的测试人员，应当可以花费 很少的时间就可以理解测试用例中表达的测试思路，并可以很快的执行完这个测试用例。 2.易维护性。当开发过程中的某些因素影响了测试需求，测试用例的作者或其他测试设 计人员，应该可以花费很少的时间就完成定位并维护所有相关测试用例的工作。

　　一些题外话

　　曾经有朋友问：如果测试用例同软件的具体实现互相独立，怎么保证测试用例的可操作性呢?怎么保证任何一个人都可以一拿到测试用例就可以直接上机执行测试呢?笔者的回答是：尽量不要让这种事情发生。首先，笔者一直不赞同那种让“任何人”都可以充当测试人员，按照手中测试用例执行测试的做法。因为对于被测应用的全面了解和熟悉，是作为一个测试人员最基本的要求——在前面的文字中对于软件需求的熟悉也多次被强调。我们无法预知让一个对软件以及软件所涉及的实际业务不够熟悉的人，依靠一份他同样不熟悉的操作步骤列表来执行测试会有什么样的结果。但是有一点可以明确，这就好像让一个没有医学背景的人，仅仅依靠一本七年制本硕连读的《内科学》教材来为患者检查是否患有心脏病，最终结果是患者承担了全部的风险。其次，测试用例的本来目的是为了描述我们的“测试思想”——也就是“怎样测”，而是否可以熟练的操作被测应用，并不是在测试用例这个“对象”中所要考虑和保证的，应当剥离出来，作为独立的部分进行处理。而问题的关键，在于如何保证拿到测试用例的人有足够的能力和经验来执行测试，这完全可以通过公司内部对软件及软件所涉及的实际业务的培训，或者软件的操作手册。总之，还是尽量不要随意的加入“任何人”到测试工作中吧。

原文转自：http://www.uml.org.cn/Test/200908281.asp