测试驱动

测试驱动，每一个做自动化的人都应该了解的内容。

• 数据驱动

在谈数据驱动之前，先聊一聊录制回访。一直以来，录制回访都不那么被认可，原因不外乎以下几个：1.应用程序必须达到一定的稳定性，才能开始录制测试脚本；2.录制的测试脚本和测试数据耦合得太紧密；3.维护自动化测试脚本的成本非常高。

数据驱动的核心思想就是测试数据和测试代码分离。

    public void login(String[][] accounts){
        for(int i = 0; i<accounts.length; i++){
            //do login
        }
    }

    public void test(){
        String[][] accounts = {{"test1", "password"}, {"test2", "password"}};
        login(accounts);
    }

    public void login(String userName, String password) {
        //login
    }

    public void test(String[] account) {
        login(account[0], account[1]);
    }

    public void executor(){
        String[][] accounts = {{"test1", "password"}, {"test2", "password"}};
        for (String[] account : accounts) {
            test(account);
        }
    }

对比上述两段代码，后者比前者更像数据驱动。数据驱动，是以数据来控制测试的业务流，测试数据不同所得到的测试结果也是不同的。在自动化测试框架中，数据驱动的意思是测试用例或测试套件是由外部数据集合来驱动的框架。比如上例中，我们可以把login()看作是测试实现，test()充作测试用例，而executor()则是用不同的测试数据来驱动不同的测试场景（假设test1、test2的登陆结果不同）。

优点：1.在应用程序开发的同时就可以同步建立测试脚本，当应用变动时，只需要修改业务功能部分的脚本；2.利用模型化的设计，避免重复的脚本，减少建立和维护脚本的陈本；3.测试输入数据、验证数据、预期的测试结果与脚本分开，利于修改和维护；4.自动化测试开发人员创建数据驱动的测试过程，测试人员可以创建测试数据。

缺点：1.每个脚本对应多个数据文件，这些数据文件需要根据脚本的功能类别存放在各自的目录中，增加了使用的复杂性；2.测试人员除了需要根据具体测试数据维护相应的测试计划，还要将这些数据写入各个需求不同的数据文件中；3.在编辑数据文件时，必须注意测试脚本所要求的传输格式。

在假设测试人员不懂开发代码的年代，数据驱动将自动化人员和测试人员的工作分开，自动化人员只负责测试的实现，而测试数据的设计准备工作是由测试人员完成的。在现在自动化测试中，自动化人员和测试人员不再进行区分，但是数据驱动的思想一直都在使用。

• 关键字驱动

关键字驱动，就是把代码映射成关键字。

在对登陆功能进行测试的时候，你需要做如下几件事情：

1) 准备相关数据

2) 发出登陆指令

3) 校验登陆结果

上述每一步都对应一段代码，它们都属于关键字。在关键字驱动的自动化测试中，很多人包括我都倾向于“将一个流程作为一个指令，将流程中所涉及的所有可变因素作为指令的参数暴露”。登陆URL、用户名、密码都是登陆指令的参数，流程封装好了，就可以反复的进行使用。

• 行为驱动

行为驱动中的行为，就是在一段时间内一直被炒热的BDD种的B(ehaviour)。它讲求的是根据用户的行为来驱动测试的实现，还是以登陆场景为例：用户打开页面，输入账号和密码，提交，然后校验登陆的结果。有了这些个场景（用例），测试人员就可以开始测试（手动测试或者实现测试代码）。

始终要遵循的两个准则：1.测试数据与测试实现分离；2.封装流程，将流程中涉及的所有可变因素作为参数暴露

关键字驱动 vs 行为驱动：描述文件的定义先后顺序问题。行为驱动是先定义描述文件，然后产品人员与测试人员审核，脚本开发人员根据描述文件实现代码；关键字驱动，是脚本开发人员先去写好代码，然后把代码方法的关键字给定义后，再给产品人员和测试人员审核。