当然，如果希望可以进一步提高某个阶段测试工作的效率，还可以考虑应用“设计测试过程”的方法。这里所说的测试过程，指的是我们在执行测试时所设定的执行测试用例的先后顺序。之所以这样作，是因为可以充分的利用不同功能之间的耦合性，尽量通过一次操作来检查尽量多的内容，从而降低已完成工作的无效性或低效性，最终提高某个阶段的整体工作效率。不过，这项工作同样要求操作者必须对被测的系统所涉及的所有业务以及这些业务之间的关系都非常熟悉才行。
如果您正被测试工作的低效问题所困扰，那么建议您尝试一下上面的方法，希望会对您的工作有所帮助。
如何评价测试用例的好坏?
这部分内容的出现，完全是因为不久前同几个朋友的一次讨论。当时大家都认为对于一个测试用例好坏的评价，无外乎两个标准：是否可以发现尚未发现的软件缺陷?是否可以覆盖全部的测试需求?但是后来发现这两个标准对于一些问题是处理不了的。例如，对于一个质量非常好的软件产品，存在的软件缺陷异乎寻常的少，测试用例设计人员准备了大量的测试用例，已经完全覆盖了测试需求，但是只有很少一部分测试用例在执行时发现了缺陷，而其他用例都顺利通过了。那么是否就可以认为顺利通过的那部分测试用例不好呢?
对于这个问题，笔者认为不管是测试用例是否可以发现尚未发现的缺陷，还是测试用例对测试需求的覆盖度，都是用来评估测试设计人员工作能力和经验的标准，而对于如何评价测试用例的优劣，应该还有其他标准。当然，在不同的团队中可能存在不同的标准，但下面两条应该是适合于任何团队的。
1.易用性。对于一个即熟悉测试工作，又熟悉被测应用的测试人员，应当可以花费
很少的时间就可以理解测试用例中表达的测试思路，并可以很快的执行完这个测试用例。
2.易维护性。当开发过程中的某些因素影响了测试需求，测试用例的作者或其他测试设
计人员，应该可以花费很少的时间就完成定位并维护所有相关测试用例的工作。
一些题外话
曾经有朋友问：如果测试用例同软件的具体实现互相独立，怎么保证测试用例的可操作性呢?怎么保证任何一个人都可以一拿到测试用例就可以直接上机执行测试呢?笔者的回答是：尽量不要让这种事情发生。
首先，笔者一直不赞同那种让“任何人”都可以充当测试人员，按照手中测试用例执行测试的做法。因为对于被测应用的全面了解和熟悉，是作为一个测试人员最基本的要求——在前面的文字中对于软件需求的熟悉也多次被强调。我们无法预知让一个对软件以及软件所涉及的实际业务不够熟悉的人，依靠一份他同样不熟悉的操作步骤列表来执行测试会有什么样的结果。但是有一点可以明确，这就好像让一个没有医学背景的人，仅仅依靠一本七年制本硕连读的《内科学》教材来为患者检查是否患有心脏病，最终结果是患者承担了全部的风险。
其次，测试用例的本来目的是为了描述我们的“测试思想”——也就是“怎样测”，而是否可以熟练的操作被测应用，并不是在测试用例这个“对象”中所要考虑和保证的，应当剥离出来，作为独立的部分进行处理。而问题的关键，在于如何保证拿到测试用例的人有足够的能力和经验来执行测试，这完全可以通过公司内部对软件及软件所涉及的实际业务的培训，或者软件的操作手册。总之，还是尽量不要随意的加入“任何人”到测试工作中吧。
作者简介
网络ID ：jackei，长期活跃于“测试时代”、“中国软件测试社区”、“51testing”、“51CMM”、“CSDN”等测试网站和测试论坛。《测试时代期刊》杂志责任编辑及撰稿人。
学院派测试人员，坚信“实践是检验真理的唯一标准”。反对学术腐败、造假。坚信做一个好的测试人员，首先要为人正直、诚实、严谨、耐心、乐于助人。现供职于广州某软件公司，从事软件测试工作，致力于测试过程改进和测试基础理论方面的研究。
对于本文中已经包含的以及还未包含的内容，如果需要讨论，您都可以使用E-Mail：jackei_chan@hotmail.com 同笔者联系。
文章来源于领测软件测试网 https://www.ltesting.net/
