自动化测试用例设计

1、了解自动化测试的目的和做用

　　自动化测试是为了让测试人员从繁琐重复的机械式测试过程当中解脱出来，把时间和精力投入到更有价值的地方，从而挖掘更多的产品缺陷。目前自动化测试更多的是定位在冒烟测试和回归测试；冒烟测试执行的是主体功能点的用例。回归测试执行所有或部分的测试用例。它的主要目的在于验证问题，而不是发现问题。因此对于自动化的设计，主要集中在功能正确性方面。

　　在自动化测试的流程中，其关键点在于自动化测试设计，包括测试用例设计、测试脚本架构及测试组织。

　　下面主要讲自动化测试用例的设计。

　　2、手工测试用例与自动化测试用例的区别

　　一、手工测试用例

　　a、能经过人为的逻辑判断校验当前步骤的功能实现是否正确。能较好的处理异常场景。

　　b、执行测试用例具有必定的跳跃能力。

　　c、人工测试能够步步跟踪分析，可以细致的定位问题。

　　d、主要用来发现产品缺陷。

　　二、自动化测试用例

　　a、全部的判断校验都须要编写脚原本实现。

　　b、测试用例步骤之间须要关联关系。

　　c、主要用来保证产品主体功能正确完整和让测试人员从繁琐重复的工做中解脱出来。

　　d、目前自动化测试阶段定位在冒烟测试和回归测试。

　　3、自动化测试用例设计原则

　　自动化测试用例设计决定自动化测试成败的关键。

　　一、设计误区

　　a、不编写测试用例直接编写测试脚本。

　　b、直接拿手工测试用例来编写自动化测试脚本。

　　二、设计原则

　　a、测试用例是一个完整的场景。从用户登陆系统到用户退出。

　　b、测试用例只验证一个功能点。不要试图用户登陆后验证全部的功能点再退出。

　　c、测试用例尽可能只作正向的逻辑验证，正向是指脚本可实现的而非主观操做。逆向逻辑的状况不少，验证比较复杂，须要编写大量的脚本，投入成本比较高。

　　d、测试用例之间不要产生关联，也就是说每一个测试用例是独立，不能依赖或影响其余测试用例，要求高内聚低耦合。

　　e、测试用例须要更多的关注功能逻辑的实现，而没必要纠结某些字段的限制。

　　f、测试用例的上下文必须有必定的顺序性，要可以互相链接起来；而且前置条件要清楚。

　　g、测试用例中检查点的设置（根据测试用例的侧重点设置检测点、设置检测点要全面和设置检测点要灵活）。

　　h、测试用例要对修改的数据进行还原操做。

　　i、测试用例必须是可回归的。

　　4、如何把手工测试用例和自动化测试用例相辅相成

　　一、自动化测试用例选型原则

　　a、不是全部的手工用例都要转为自动化测试用例。

　　b、考虑到脚本开发的成本，不要选择流程太复杂的用例。若是有必要，能够考虑把流程拆分多个用例来实现脚本。

　　c、选择的用例最好能够构建成场景。例如一个功能模块，分n个用例，这n个用例使用同一个场景。

　　d、选择的用例能够带有目的性，例如这部分用例是用例作冒烟测试，那部分是回归测试等，固然，会存在重叠的关系。若是当前用例不能知足需求，那么惟有修改用例来适应脚本和需求。

　　e、选取的用例能够是你认为是重复执行，很繁琐的部分，例如字段验证，提示信息验证这类。这部分适用回归测试。

　　f、选取的用例能够是主体流程，这部分适用冒烟测试。

　　二、自动化测试用例转型原则

　　a、当前的测试用例前置配置信息要写清楚。

　　b、每个步骤都要衔接好，错了，脚本要抛出异常。

　　c、每个步骤要作什么，验证什么要写清楚，写具体。有时一个检查点，你只需看一眼，可是脚本要写一堆代码去验证，这样的作法是不可行的。

　　d、用例之间不要有关联性，自动化测试开发一样是软件开发工程，脚本编写一样提倡高内聚低耦合的理念。

　　e、不是每个步骤都须要验证点。

　　f、别在多个地方重复相同的验证。脚本很忙！我没空。固然，除非有必要。

　　g、开门记得要关门，配置信息要回归原点，不然脚本要迷路。————————————————