软件测试之自动化测试用例设计

软件测试之自动化测试用例设计

　　一、理解自动化测试的目的和作用

　　自动测试就是将测试人员从繁重、重复性、机械的测试过程中解放出来，投入更多的时间和精力，去发现更多的产品缺陷。现在的自动化测试更多的是定位于冒烟测试和回归测试，冒烟测试执行主体功能点用例。回归测试执行全部或部分测试案例。其主要目的是确认问题，而非发现问题。因此，对于自动化设计，主要关注于功能正确性。

　　自动测试设计过程中，关键点在于自动测试设计，包括测试用例设计、测试脚本结构和测试组织。

　　以下重点是自动测试用例的设计。

　　二、手动测试案例与自动测试案例的区别

　　1、手动测试用例

　　a、通过人为逻辑能够判断当前各步校验的功能实现是否正确。可以很好地处理异常情况。

　　具有一定的跳跃能力，能执行测试用例。

　　人工测试可以逐个逐个进行分析，可以精确定位问题。

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

　　2、自动测试用例

　　所有判断校验都需要用脚本来执行。

　　b、测试用例步骤之间需要有一个关联。

　　主要用于确保产品主体功能正确、完整，并让测试人员摆脱繁重繁重的工作。

　　目前的自动测试阶段定位于冒烟测试与回归测试。

　　三、自动测试用例设计原则

　　自动测试用例设计是自动测试成败的关键。

　　一、设计误区

　　不要直接编写测试用例，直接编写测试脚本。

　　把手工测试用例拿出来直接写自动测试脚本。

　　二、设计原理

　　a、测试案例是一个完整的场景。在系统中登录到用户退出。

　　测试用例仅验证一个功能性点。在退出之前，不要尝试验证在用户登录后所有的功能点。

　　测试用例尽量只做正向逻辑验证，前向表示脚本能够实现，而非主观运算。反向逻辑的情况很多，验证也比较复杂，需要编写大量的脚本，投入成本较高。

　　测试用例之间不要产生联系，也不要说每个测试用例都是独立的，不能依赖或影响其他测试用例，需要高内聚、低耦合。

　　测试用例需要更多地集中在功能逻辑的实现上，而不需要纠缠于某些字段的限制。

　　测试用例的上下文必须具有一定的次序，并能相互联系;前置条件必须清晰。

　　在测试用例中设置检查点(根据测试用例的侧重点设置检测点，设置检测点要全面，设置检测点要灵活)。

　　h、测试用例要对修改过的数据进行恢复操作。

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

　　四、如何使手动测试用例与自动测试用例互补

　　1、自动测试用例选择原则

　　并非所有手动用例都转换成自动测试用例。

　　鉴于脚本开发的成本，不要选择过程过于复杂的用例。在必要的情况下，考虑将该流程分割成多个用例以实现脚本。

　　c、选择好的用例会被构建为场景。比如一个功能模块，它包含了 n个用例，使用相同的场景。

　　(d)所选择的用例可能带有目的性，比如这一部分用例是用例做冒烟测试，一部分是回归测试，等等，当然，有重叠的关系。若当前用例不能满足需求，则只有修改用例以适应脚本和需求。

　　e、所选择的用例可能是你认为是重复执行，非常繁琐的部分，比如字段验证，提示信息验证这类。此部分用于回归测试。

　　所选择的用例可能是主体流程，这部分适用于烟雾测试。

　　2、自动转换测试用例原则

　　请清楚地写出当前测试用例前置配置信息。

　　每一步都要接好，错的是，脚本要抛出异常。

　　c、每一步要做什么，核实什么要写清楚，写具体。有时候，你可以浏览一眼检查点，但脚本需要编写一堆代码以进行验证，这种方法并不可行。

　　用例之间不需要相互关联，自动化测试开发同样属于软件开发工程，脚本编写也同样提倡高内聚、低耦合的理念。

　　e、并非每个步骤都需要验证点。

　　不要在多处重复进行相同的验证。剧本繁忙!没有时间。除非有必要，否则

　　g、关闭开门时记得关闭，配置信息要返回原点，否则脚本会丢失。

以上是关于软件测试的知识，由多测师亲自撰写，全网独家提供!   https://www.duoceshi.com/