内容摘自：http://www.cnblogs.com/jshtest/p/6362677.html
 
一、自动化测试存在的真正意义：
 
主要用来保证产品主体功能正确完整和让测试人员从繁琐重复的工作中解脱出来。它的主要目的在于验证问题，而不是发现问题。所以对于自动化的设计，主要集中在功能正确性方面。
 
目前自动化测试阶段定位在冒烟测试和回归测试。冒烟测试执行的是主体功能点的用例，回归测试执行全部或部分的测试用例。
 
二、自动化测试用例的设计原则：
 
1、一个脚本是一个完整的场景，从用户登陆操作到用户退出系统关闭浏览器。
 
2、一个脚本只验证一个功能点，不要试图用户登陆系统后把所有的功能都进行验证再退出系统
 
3、尽量只做功能中正向逻辑的验证，不要考虑太多逆向逻辑的验证，逆向逻辑的情况很多（例如错误的登录账号有很多情况），验证一方面比较复杂，需要编写大量的脚本，另一方面自动化脚本本身比较脆弱，很多非正常的逻辑的验证能力不强。（我们尽量遵循用户正常使用原则编写脚本即可）
 
4、脚本之间不要产生关联性，也就是说编写的每一个脚本都是独立的，不能依赖或影响其他脚本。
 5、如果对数据进行了修改，需要对数据进行还原。
 
6、在整个脚本中只对验证点进行验证，不要对整个脚本每一步都做验证。
 
三、用例选择注意事项：
 
1、不是所有的手工用例都要转为自动化测试用例。
 
2、考虑到脚本开发的成本，不要选择流程太复杂的用例。
 
3、选择的用例最好可以构建成场景。例如一个功能模块，分n 个用例，这n 个用例使用同一个场景。这样的好处在于方便构建关键字测试模型。
 4、选择的用例可以带有目的性，例如这部分用例是用例做冒烟测试，那部分是回归测试等，当然，会存在重叠的关系。
 5、选取的用例可以是你认为是重复执行，很繁琐的部分，例如字段验证，提示信息验证这类。这部分适用回归测试。
 
6、选取的用例可以是主体流程，这部分适用冒烟测试。
 
7、测试用例需要更多的关注功能逻辑的实现，而不必纠结某些字段的限制。
 
8、自动化测试也可以用来做配置检查，数据库检查。这些可能超越了手工用例，但是也算用例拓展的一部分。项目负责人可以有选择地增加。
 
9、如果平时在手工测试时，需要构造一些复杂数据，或重复一些简单机械式动作，可以让自动化脚本来帮你。
 
四、自动化测试用例转型原则
 
1、当前的测试用例前置配置信息要写清楚。
 
2、每一个步骤都要衔接好，错了，脚本要抛出异常。
 
3、每一个步骤要做什么，验证什么要写清楚，写具体。有时一个检查点，你只需看一眼，但是脚本要写一堆代码去验证，这样的做法是不可行的。
 
4、用例之间不要有关联性，自动化测试开发同样是软件开发工程，脚本编写同样提倡高内聚低耦合的理念。
 
5、不是每一个步骤都需要验证点。
 
6、别在多个地方重复相同的验证。脚本很忙！我没空。当然，除非有必要。
 
7、开门记得要关门，配置信息要回归原点，否则脚本要迷路。

介绍 
 　　每个实行持续交付的项目，都有生产流水线的元素，如持续集成和自动化测试。这些测试是在不同层面进行的，从单元测试到冒烟测试再到功能测试。自动化功能测试的优点之一是可重复性和可预测的执行时间。出于这个原因，它应该作为软件质量的每一个构建之后的指标。功能测试自动化往往会成为一个瓶颈，所以你应该熟悉一下如何创建这样的测试的基本原则。 
 　　 
 　　首先设计你的测试 
 　　测试集合可以比作盆景树。 
 　　最初的时候，我们照顾树根和树干。我们选择会成长的主要分支，我们每天都细心照料这棵树并等待它长出健康的叶子。 
 　　我们可以以类似的方式继续测试。 
 　　我们建一个将负责应用程序主要功能（例如：开启）的基类。 
 　　根据说明，我们先明确将被测试覆盖的应用程序的主要功能，然后每天我们在执行测试的时候都添加更多平行测试。 
 　　每一个支持测试（例如创建一个新的用户）的方法都需要与测试分离——让我们在单独的类里面来实现。 
 　　你应该在包括了应用程序主要功能的目录里保持类。 
 　　去建一个规定很多功能共有方法的抽象类是很好的做法。 
 　　如果你正在测试Web应用程序，就用页面对象设计模式。该模式里，一个类及其方法对应了单个页面的功能或一个大型网页里单个页面上的一个元素。 
 　　 
 　　 
 　　无需事事自动化 
 　　自动化花费很多，所以你应该主要测试应用程序的主要功能。 
 　　某些测试可以快速轻松地手动完成，且潜在脚本可能难以实现。 
 　　值得用到自动化的是那些繁琐的需要被重复很多次的，和那些需要大量数据验证的测试工作。 
 　　 
 　　写短测试 
 　　在一个或多个测试失败的情况下，开发团队的任何成员都应该能够轻松地找到错误的原因。 
 　　出于这个原因，每个测试方法里应该最多有5个断言，并且每个方法都必须提供的测试操作的完整记录。 
 　　明智的做法是使用BDD（行为驱动开发）技术，但是当你没有用一个特定的测试框架时，你应该把接下来的测试步骤放在comments //given //when //then下。 
 　　 
 　　创建独立测试 
 　　在测试类中的每个方法应该是一个独立的实体，而不是依赖于其他测试。我们应该能够在任何时间运行单个测试。否则，这样的测试用例集将来维护起来就会很贵——必须定期跟踪和更新测试之间的联系。 
 　　很多时候，测试需要一定的前提条件来满足。这些条件不应该用外部方法，应该在试验开始时运行。如果这些条件和测试类的所有方法一样，它们就可以被放在一开始进行的方法里（例如：在JUnit中被标记为@ BeforeClass）。 
 　　　 
 　　关注可读性 
 　　源代码应该是自我记录的，而写下以下几行代码的每个利益相关者应该明白测试在做什么，为什么它被这么写。尽量避免在源代码注释，因为它也必须被更新。这值得花比平常多一点的时间来命名方法，从而使你的代码更易读。 
 　　再看看行为驱动开发技术，每个测试方法都应以单词“应该”开始，而不是“测试”。 
 　　根据这一惯例，我们马上就可以明白一个特定的方法测试什么内容了，它在分析测试报告时特别有用。 
 　　 
 　　测试必须要快 
 　　正如在本文开头所提到的，自动化功能测试应该是应用程序质量的一个指标。连续传递过程中的每一步都应指明最长持续时间；并且根据这个概念，开发团队应该尽快获得有关软件质量的反馈。自动化功能测试的持续时间应不超过几分钟。 
 　　对一个非常全面的测试集来说，有必要并行运行测试（经常在不同的机器上）。虚拟化在这里可能是非常有帮助的。 
 　　 
 　　创建抗变测试 
 　　最常提及自动化功能测试的缺点是其对应用程序中变化的低抵抗性，尤其是在GUI中。 
 　　在Web应用程序中，测试应该能抵抗网站的内容的变化。测试应该只验证功能，这就使得它可以在不同的位置运行测试。这并不意味着我们不应该编写自动化测试来检查网页的内容。 
 　　 如果你已经想创建这样的测试，你应该遵循DDT（数据驱动测试）技术。这意味着，检查内容是与源代码分离开的。 
 　　Web应用程序的页面布局变化非常频繁，这已经影响到了用户界面。 
 　　当你设计一个界面时，每个区段和每个页面你都应该有一个你可以用来测试的唯一标识符，即使一个网站的层次结构发生了变化。 
 　　 
 　　自动化测试无法取代人类 
 　　功能自动化测试可以是项目中的主要测试技术，但绝不是唯一的一个。 
 　　自动化测试是可重复再生的，他们的覆盖范围总是相同的。 
 　　另一方面，虽然探索性测试是低再生的，但是它们能够覆盖自动化测试未触及的区域。 
 　　你还应该记住，自动化测试的“绿色”状态并不意味着你的应用程序是没有错误的。 
 　　这种情况往往会让测试员分心，而且有可能会影响测试的准确性。

　一、了解自动化测试的目的和作用
 
　　自动化测试是为了让测试人员从繁琐重复的机械式测试过程中解脱出来，把时间和精力投入到更有价值的地方，从而挖掘更多的产品缺陷。目前自动化测试更多的是定位在冒烟测试和回归测试；冒烟测试执行的是主体功能点的用例。回归测试执行全部或部分的测试用例。它的主要目的在于验证问题，而不是发现问题。所以对于自动化的设计，主要集中在功能正确性方面。
 
　　在自动化测试的流程中，其关键点在于自动化测试设计，包括测试用例设计、测试脚本架构及测试组织。
 
　　下面主要讲自动化测试用例的设计。
 
　　二、手工测试用例与自动化测试用例的区别
 
　　1、手工测试用例
 
　　a、能通过人为的逻辑判断校验当前步骤的功能实现是否正确。能较好的处理异常场景。
 
　　b、执行测试用例具备一定的跳跃能力。
 
　　c、人工测试可以步步跟踪分析，能够细致的定位问题。
 
　　d、主要用来发现产品缺陷。
 
　　2、自动化测试用例
 
　　a、所有的判断校验都需要编写脚本来实现。
 
　　b、测试用例步骤之间需要关联关系。
 
　　c、主要用来保证产品主体功能正确完整和让测试人员从繁琐重复的工作中解脱出来。
 
　　d、目前自动化测试阶段定位在冒烟测试和回归测试。
 
　　三、自动化测试用例设计原则
 
　　自动化测试用例设计决定自动化测试成败的关键。
 
　　1、设计误区
 
　　a、不编写测试用例直接编写测试脚本。
 
　　b、直接拿手工测试用例来编写自动化测试脚本。
 
　　2、设计原则
 
　　a、测试用例是一个完整的场景。从用户登录系统到用户退出。
 
　　b、测试用例只验证一个功能点。不要试图用户登录后验证所有的功能点再退出。
 
　　c、测试用例尽量只做正向的逻辑验证，正向是指脚本可实现的而非主观操作。逆向逻辑的情况很多，验证比较复杂，需要编写大量的脚本，投入成本比较高。
 
　　d、测试用例之间不要产生关联，也就是说每个测试用例是独立，不能依赖或影响其他测试用例，要求高内聚低耦合。
 
　　e、测试用例需要更多的关注功能逻辑的实现，而不必纠结某些字段的限制。
 
　　f、测试用例的上下文必须有一定的顺序性，要能够互相连接起来；并且前置条件要清楚。
 
　　g、测试用例中检查点的设置（根据测试用例的侧重点设置检测点、设置检测点要全面和设置检测点要灵活）。
 
　　h、测试用例要对修改的数据进行还原操作。
 
　　i、测试用例必须是可回归的。
 
　　四、如何把手工测试用例和自动化测试用例相辅相成
 
　　1、自动化测试用例选型原则
 
　　a、不是所有的手工用例都要转为自动化测试用例。
 
　　b、考虑到脚本开发的成本，不要选择流程太复杂的用例。如果有必要，可以考虑把流程拆分多个用例来实现脚本。
 
　　c、选择的用例最好可以构建成场景。例如一个功能模块，分n个用例，这n个用例使用同一个场景。
 
　　d、选择的用例可以带有目的性，例如这部分用例是用例做冒烟测试，那部分是回归测试等，当然，会存在重叠的关系。如果当前用例不能满足需求，那么唯有修改用例来适应脚本和需求。
 
　　e、选取的用例可以是你认为是重复执行，很繁琐的部分，例如字段验证，提示信息验证这类。这部分适用回归测试。
 
　　f、选取的用例可以是主体流程，这部分适用冒烟测试。
 
　　2、自动化测试用例转型原则
 
　　a、当前的测试用例前置配置信息要写清楚。
 
　　b、每一个步骤都要衔接好，错了，脚本要抛出异常。
 
　　c、每一个步骤要做什么，验证什么要写清楚，写具体。有时一个检查点，你只需看一眼，但是脚本要写一堆代码去验证，这样的做法是不可行的。
 
　　d、用例之间不要有关联性，自动化测试开发同样是软件开发工程，脚本编写同样提倡高内聚低耦合的理念。
 
　　e、不是每一个步骤都需要验证点。
 
　　f、别在多个地方重复相同的验证。脚本很忙！我没空。当然，除非有必要。
 
　　g、开门记得要关门，配置信息要回归原点，否则脚本要迷路。

测试用例设计的最基本要求：覆盖住所要测试的功能。这是再基本不过的要求了，但别看只是简单的一句话，要能够达到切实覆盖全面，需要对被测试产品功能的全面了解、明确测试范围（特别是要明确哪些是不需要测试的）、具备基本的测试技术（如：等价类划分等）等。那么满足了上述这条要求是不是设计出来的测试用例就是好的测试用例了呢？答案：在理论上是，但在实际工程中还远远不是。之所以理论和实际会有这样的差别，是因为在理论上不要考虑的东东，而在实际工程中是不得不考虑的 - 成本。这里的成本包括：测试计划成本、测试执行成本、自动化测试用例、测试自动化成本，测试分析成本，以及测试实现技术局限、测试环境的Bug、人为因素和不可预测的随机因素等引入的附加成本等。 
      由于成本因素的介入，决定了工程中设计好的测试用例原则不只有“覆盖住所要测试的功能”这一条，下面是我根据自己的工作经验总结出的其它四条原则，在这里抛砖引玉，希望大家拍砖和指正。这些原则特别是针对那些需要被自动化，并且是要被经常执行的测试用例。
 
 
 
 
 
1. 单个用例覆盖最小化原则。
 
       这条原则是所有这四条原则中的”老大“，也是在工程中最容易被忘记和忽略的，它或多或少的都影响到其它几条原则。下面举个例子来介绍，假如要测试一个功能 A，它有三个子功能点 A1，A2 和 A3，可以有下面两种方法来设计测试用例：
 
方法1 ：用一个测试用例覆盖三个子功能 -Test_A1_A2_A3， 
方法2 ：用三个单独的用例分别来覆盖三个子功能 - Test_A1，Test_A2，Test_A3
 
方法1适用于规模较小的工程，但凡是稍微有点儿规模和质量要求的项目，方法2则是更好的选择，因为它具有如下的优点：
 
测试用例的覆盖边界定义更清晰 
测试结果对产品问题的指向性更强 
测试用例间的耦合度最低，彼此之间的干扰也就越低 
 
       上述这些优点所能带来直接好处是，测试用例的调试、分析和维护成本最低。每个测试用例应该尽可能的简单，只验证你所要验证的内容，不要“搂草打兔子”捎带着把啥啥啥啥都带进来，这样只会增加测试执行阶段的负担和风险。David Astels在他的著作《Test Driven Development：A Practical Guide》曾这样描述 : " 最好一个测试用例只有一个Assert语句"。此外，覆盖功能点简单明确的测试用例，便于组合生成新的测试，很多测试工具都提供了类似组合已有测试用例的功能， 例如:　Visual Studio中就引入了Ordered Test的概念。
 
 
 
 
 
2. 测试用例替代产品文档功能原则。
 
       通常我们会在开发的初期（Scrum每个Sprint的头两天）用Word文档或者OneNote的记录产品的需求、功能描述、以及当前所能确定的任何细节等信息，勾勒将要实现功能的轮廓样貌，便于团队进行交流和细化，并在团队内达成对将要实现的产品功能共识。假设我们在此时达成共识后，描述出来的功能为A，随着产品开发深入，经过不断地迭代之后，团队会对产品的功能有更新的认识，产品功能也会被更具体细化，在一个迭代或者Sprint结束的时候最终实现的功能很可能是A+。如此往复，在不断倾听和吸收用户的反馈，修改产品功能，多个迭代过后，原本被描述为A的功能很可能最终变为了Z。这是时候再去看曾经的Word文档和OneNote页面，却仍然记录的是A。之所以会这样，是因为很少有人会去（以及能够去）不断更新那些文档，以准确反映出产品功能当前的准确状态。不是不想去做，而是实在很难！这里需要注意：早期的Word或者OneNote的文档还是必要的，它至少能保证在迭代初期团队对要实现功能有一致和准确的认识。
 
       就没有什么东西能够一直准确地描述产品的功能了吗？答案：当然有，那就是产品代码和测试用例。产品代码实现了产品功能，它一定是准确描述了产品的当前功能，但是由于各种编程技术，如：面向对象、抽象、设计模式、资源文件等等，使得产品代码很难简单地就能读懂，往往是在知道产品功能的前提下去读代码，而不是反过来看代码来了解功能。好的代码会有详细的注释，但这里的注释是对实现代码的解释和备注，并不是对产品功能的描述。这里有一篇很老的博客Reading Code Is Hard，介绍了如何能够使代码更可读一些编写技巧。
 
       那么就只有测试用例了，测试也应该忠实反映了产品功能的，否则的话测试用例就会执行失败。以往大家只是就把测试用例当作测试用例而已，其实对测试用例的理解应该再上升到另一个高度，它应该是能够扮演产品描述文档的功能。这就要求我们编写的测试用例足够详细、测试用例的组织要有调理、分主次，单靠Word、Excel或者OneNote这样通用的工具是远远无法完成的，需要更多专用的测试用例管理工具来辅助，例如 Visual Studio 2010引入Microsoft Test Manager。
 
       此外，对于自动化测试用例（无论是API或者UI级别的）而言，代码在编写上也应该有别产品代码编写风格，可读性和描述性应该是重点考虑的内容。在测试代码中，当然可以引入面向对象、设计模式等优秀的设计思想，但是一定要适度使用，往往面向过程的编码方式更利于组织、阅读和描述。
 
 
 
 
 
 
3. 单次投入成本和多次投入成本原则。
 
       与其说这是一条评判测试用例的原则，不如说它是一个思考问题的角度。成本永远是任何项目进行决策时所要考虑的首要因素，软件项目中的开发需要考虑成本，测试工作同样如此。对成本的考虑应该客观和全面地体现在测试的设计、执行和维护的各个阶段。当你在测试中遇到一些左右为难的问题需要决策时，尝试着从成本角度去分析一下，也许会给你的决策带来一些新的启发和灵感。
 
       测试的成本按其时间跨度和频率可以分为：单次投入成本和多次投入成本。例如：编写测试用例可以看作是单次投入成本，因为编写测试用例一般是在测试的计划阶段进行（Scrum每个Sprint的开始阶段）的，虽然后期会有不断的调整，但绝大多数是在一开始的设计阶段就基本上成型了；自动化测试用例也是如此，它也属于是一次性投入；测试用例（包括：手工和自动化测试用例）的执行则是多次投入成本，因为每出一个新版本Build时都要执行所有的测试用例（或者进行BVT测试仅执行高优先级的测试用例）、分析测试结果、调试失败测试用例、确定测试用例的失败原因（产品缺陷、测试用例缺陷、测试框架缺陷还是随机问题导致了测试用例的失败），以验证该版本整体质量是否达到了指定的标准。
 
       之所有要引入单次和多次成本的思考，是希望能够通过区分测试中不同活动对测试成本的影响，从而进行帮助我们合理布局在不同阶段的投入和做出正确的决策，以保证在有限可负担测试成本的前提下，最大限度地有效开展测试工作。例如，当我们意识到了，测试用例的设计和自动化属于是一次性投入，而测试用例的执行则是反复多次的投入时，就应该积极思考如何能够提高需要反复投入的测试执行的效率，在一次投入和需要多次活动需要平衡时，优先考虑多次投入活动的效率，其实这里是有很多工作可以做。
 
       例如：第一条原则－单个用例覆盖最小化原则 - 就是一个很好的例子，测试A功能的3个功能点A1，A2和A3，从表面上看用Test_A1_A2_A3这一个用例在设计和自动化实现时最简单的，但它在反复执行阶段会带来很多的问题：
 
首先，这样的用例的失败分析相对复杂，你需要确认到底是哪一个功能点造成了测试失败；
其次，自动化用例的调试更为复杂，如果是A3功能点的问题，你仍需要不断地走过A1和A2，然后才能到达A3，这增加了调试时间和复杂度；
第三，步骤多的手工测试用例增加了手工执行的不确定性，步骤多的自动化用例增加了其自动执行的失败可能性，特别是那些基于UI自动化技术的用例；
第四，（Last but not least）将不相关功能点耦合到一起，降低了尽早发现产品回归缺陷的可能性，这是测试工作的大忌。例如：如果Test_A1_A2_A3是一个自动测试用例，并按照A1->A2->A3的顺序来执行的，当A1存在Bug时，整个测试用例就失败了，而A2和A3并未被测试执行到。如果此时A1的Bug由于某些原因需要很长时间才能修复，则Test_A1_A2_A3始终被认为是因为A1的Bug而失败的，而A2和A3则始终是没有被覆盖到，这里存在潜在的危险和漏洞。当你在产品就要发布前终于修复了A1的Bug，并理所当然地认为Test_A1_A2_A3应该通过时，A2和A3的问题就会在这时爆发出来，你不得不继续加班修复A2和A3的问题。不是危言耸听，当A2/A3的代码与A1的Bug修复相关时，当你有很多如此设计的测试用例时，问题可能会更糟… …，真的！:(  
 
       综上所述，Test_A1_A2_A3这样的设计，减少地仅是一次性设计和自动化的投入，增加地却是需要多次投入的测试执行的负担和风险，所以需要决策时（事实上这种决策是经常发生的，尤其是在设计测试用例时）选择Test_A1_A2_A3还是Test_A1、Test_A2和Test_A3，请务必要考虑投入的代价。
 
 
 
 
 
4. 使测试结果分析和调试最简单化原则。
 
       这条原则是实际上是上一条 - 单次投入成本和多次投入成本原则 - 针对自动化测试用例的扩展和延续。在编写自动化测试代码时，要重点考虑如何使得测试结果分析和测试调更简单，包括：用例日志、调试辅助信息输出等。往往在测试项目中，测试用例的编写人和最终的执行者是不同的团队的成员，甚至有个能测试的执行工作被采用外包的方式交给第三的团队去进行，这在当下也是非常流行的。因为测试用例的执行属于多次投入，测试人员要经常地去分析测试结果、调试测试用例，在这部分活动上的投入是相当可观的。有时候，测试框架提功能的一些辅助API等就可以帮助很好实现这个原则。例如：Coded UI Test就提供了类似的API，详见 -  VS 2010 测试功能学习(18) – Coded UI Test三个必知的函数，来辅助基于Coded UI框架实现的自动化测试用例有更好的调试体验。
 
 
 
       测试理论为测试工作指明了大的前进方向，在实际工程中还需要我们不断地“活化”这些理论，使理论和实践更好的契合在一起。在我看来，软件工程项目不论成败和好坏，对我们每个参与者都是无比宝贵的。作为有心人，从中我们体会到很多书本上不曾提到过的东西，只要不断地去观察、体会和总结，你会有更多自己的认识、理解和发现。有很多人写书称赞，代码之美、测试之美，其实工程项目也是很美，只是看你能不能更客观地去看待它