zoukankan      html  css  js  c++  java
  • 自动化用例设计原则

    前言:

    怎么设计自动化测试用例?是不是所有的手动用例都适合转成自动化测试用例?

    设计自动化测试用例需考虑的方面:

    1、并不是所有的手工用例都要转为自动化测试用例。

    • 考虑到脚本开发的成本,不要选择流程太复杂的用例。如果有必要,可以考虑把流程拆分成多个用例来实现脚本。

    2、选择的用例最好可以构建成场景。

    • 例如,一个功能模块,分多个用例,多个用例使用同一个场景。

    3、选择的用例可以带有目的性。

    • 例如,这部分是用例做冒烟测试,那部分用例是做回归测试等,当然,会存在重叠的关系。如果当前用例不能满足需求,那么唯有修改用例来适应脚本和需求。
    • 选取的用例可以是主体流程,这部分适用于冒烟测试。

    4、选取的用例可以是你认为是重复执行,很烦琐的部分。

    • 例如,字段验证、提示信息验证这类,这部分适用于回归测试。

    5、自动化测试也可以用来做配置检查、数据库检查。这些可能超越了手工用例,但也算用例拓展的一部分,项目负责人可以有选择地增加。
    6、平时在手工测试时,如果需要构造一些复杂的数据或重复一些简单的机械式动作,则告诉自动化脚本,让它来帮你,或许你的效率会因此而得到提高。

    在编写自动化测试用例过程中应该遵守以下几点原则:
    1、一个用例为一个完整的场景,从用户登录系统到最终退出并关闭浏览器。


    2、一个用例只验证一个功能点,不要试图在用户登录系统后把所有的功能都验证一遍。


    3、尽量少的编写逆向逻辑用例。一方面因为逆向逻辑的用例很多(例如,手号输错有几十种情况);另一方面自动化脚本本身比较脆弱,对于复杂的逆向逻辑用例实现麻烦且容易出错。


    4、用例与用例之间尽量避免产生依赖。


    5、一条用例完成测试之后需要对测试场景进行还原,以免影响其它用例的执行。

  • 相关阅读:
    SendMessage操作另一个EXE,存在这,以后也许用得着。
    六、Delphi 2009 泛型容器单元(Generics.Collections)[5]: TObject...<T> 系列
    闲扯原码、反码、补码
    限制edit只能输入数字
    动态创建TXMLDocument对XML文件进行读取和写入
    XML操作
    Ubuntu下配置lazarus开发环境
    C#结构体(二)
    【转】 如何有效減少Nios II EDS所編譯程式碼大小? (IC Design) (Nios II)
    关于NiosII和Win7系统兼容性的问题处理方式
  • 原文地址:https://www.cnblogs.com/cuitang/p/11636939.html
Copyright © 2011-2022 走看看