读《RUP测试实践之测试用例与测试需求》的一点感想和收获

        测试用例的编写，作为一项软件测试人员的基本功，对我而言，仍然是个很难把握的工作。如何把握测试用例的粒度？如何保证测试用例的有效性和易用性？如何提高测试用例的复用性以减少维护测试用例带来的效率低下问题？如何在很短的时间内，完成测试思路明确，覆盖完全的测试用例？...一系列的问题困饶着我！
        看完了陈雷的《RUP测试实践之测试用例与测试需求》，我感触还是满多的，收获主要如下：
        1、测试应该更加偏重于对测试过程和方法的研究，而不是测试工具的使用。如果没有好的测试过程和测试方法，得到的工具只能帮你做简单的重复性劳动，工具自身的价值是随着使用者的使用方法体现的。
        2、软件需求是测试和开发工作的源头，所以要想提高测试工作的效率，不如多从测试开发流程开始，从需求的源头开始，在需求的源头越早的发现问题，就越能减少后期开发维护带来的资源消耗，越能体现QA价值。
        3、测试需求概念的引入，根据我的理解，测试需求就是需要测试的需求点。测试需求可以来源于软件开发的各个阶段，需求收集、设计编码甚至于软件发布后的用户反馈。同时，测试需求的收集也是个不断迭代的过程。对需求进行测试需要把握两点：一是需求的正确性和完整性，是否存在逻辑上的不正确，是否忽略和遗漏了部分需求。二是需求的可测试性，每条需求都必须具备意义明确的可以预知的结果，确保需求描述的正确性。
        4、把握测试用例的粒度，笔者建议方法是关注于有效功能和测试的思想而不是关注测试步骤。将主要的精力从设计“操作步骤”转移到设计测试数据上。
        5、逆项测试数据分析方法的引入，主要解决的问题是：当测试数据之间存在依赖关系时，我们常用的测试方法是先测试最前端的功能，这时引入了大量的无效数据（对后面的功能而言），同时这些数据还无法被后面的功能所使用，使得我们测试后面的功能时不得不重新维护相当数量的数据。
        6、为了提高测试效率，引入了“设计测试过程”的方法，利用不同功能之间的耦合性，通过一次操作来检查尽可能多的内容。
        7、测试用例的好坏主要体现在易用性和易维护性，不是测试用例写得越详细就越好，测试用例的编写必须要考虑成本、效率和后期可维护性。
        希望通过以上概念的学习，在实际工作中可以用起来，以提高测试用例的编写效率，降低维护测试用例的成本。

转载于:https://www.cnblogs.com/ericzhang/archive/2005/01/30/99516.html