TestCafe总结

UI测试脚本编写成本中定位、操作页面元素和校验执行结果占很大比例，通过前面课程的介绍，可以看到TestCafe框架自身提供了丰富的api定位页面元素和模拟常见的web应用操作，无需引入任何三方插件即可覆盖几乎所有的UI层测试场景。但如果被测应用中很多场景需要在多个tab页窗口中切换，那么选择TestCafe会有局限性，因为目前TestCafe还不支持多窗口场景。下面列举了TestCafe框架已经支持和未来会支持的功能，通过这些信息可以更好的选择适合项目的测试框架。 

总结而言，如果被测应用需要覆盖IE浏览器，那么首选TestCafe，因为Cypress和Puppeteer都只支持chrome和firefox浏览器。如果被测应用无需覆盖IE浏览器，且无多tab页间切换场景，那么推荐选择Cypress，因为Cypress提供的test runner极大的提升了调试效率。如果存在多tab页间切换场景，或者存在同一个case访问不同域页面场景，那么可以考虑选择Puppeteer，因为Cypress对于第一种测试场景支持有限，对于第二种场景完全就不支持。

上面汇总了TestCafe框架目前已经支持和即将支持的功能，接下来再简单介绍下如果选用TestCafe框架，如何通过调用接口或者数据库准备和清理测试数据，以及如何通过读写配置文件管理配置信息。这个部分和Puppeteer章节中介绍的实现方式一致，故只做简单介绍。

• 使用TestCafe时调用数据库准备测试数据
• 使用TestCafe时调用接口准备测试数据
• 使用TestCafe时管理配置信息
• 通过retry机制提升脚本稳定性

使用TestCafe时调用数据库准备测试数据

调用封装好的获取数据库数据方法的测试脚本如下所示，从数据库获取登陆的用户名和密码。下面脚本是case层的脚本，执行“npm run test:loginWithDBData”即可运行下面的脚本，封装的方法都存放在db目录下，大家可以自己查看。注意:获取数据前，请在自己本地创建好table以及在table中放入正确的用户名和密码信息，否则脚本会运行失败。

const getDataFromDB= require('./getDataFromDB');
const initDB = require('./initDB');
fixture('get data from database demo');
    test('should login in web successfully',async(t)=> {
        await t.navigateTo("https://angular.realworld.io/");
        await t.click('app-layout-header li a[href="/login"]');
        const password = await getDataFromDB.getLoginUserPassword('[email protected]');
        //封装了一个只获取password字段值的方法

        const userInfo=JSON.parse(JSON.stringify(await getDataFromDB.getLoginUser('[email protected]')));
        //封装了一个获取整个loginUser表所有字段信息的方法

        await t.typeText('app-auth-page form input[formcontrolname="email"]', userInfo.username);
        //当需要用户名称时输入userInfo.username即可，因为已经把userInfo信息转换为了数据集

        await t.typeText('app-auth-page form input[formcontrolname="password"]', password);
        await t.click('app-auth-page button[type="submit"]')
        await initDB.closeConnection();
        //脚本最后关闭数据库连接，否则脚本不能自动全部结束
    });

 使用TestCafe时调用接口准备测试数据和配置信息管理

虽然TestCafe提供了".testcaferc.json"配置文件，但此文件中主要存放TestCafe框架自身支持的配置信息。如果需要管理不同环境的baseUrl、数据库连接等信息，建议创建单独的yml文件或者json文件进行管理，使用方式和Puppeteer章节讲解的完全一致。另外，TestCafe框架目前还未提供调用接口的方法，故如果需要调用接口也是引入request包，使用方式和Puppeteer章节讲解的内容一样。下面第一个脚本是在case层调用封装好的接口，第二个脚本是一个完整的UI层自动化案例，案例中通过调用接口准备测试数据，且接口中使用的baseUrl等信息从配置文件或者数据文件中获取。

执行“npm run test:callApi”即可运行下面的脚本。

const blogManage= require('../../../testdata/dataManage/blog-manage');
fixture('call api and read config file demo');
test('should call api and read config content successfully', async(t) => {
    await blogManage.addBlogToPrepareTestData();
});

执行“npm run test:favoriateBlog”即可运行下面的脚本，下面脚本完成了“点赞自己创建的blog”的测试场景。

const blogManage = require('../../../testdata/dataManage/blog-manage');
const loginPage = require('../../page/commonPage/loginPage');
const globalFeedPage = require('../../page/blogPage/globalFeedPage');
fixture("favorite blog test")
test("should favorite blog successfully", async (t) => {
    await blogManage.addBlogToPrepareTestData();
    //blogManage页面封装了添加blog测试数据的方法，通过调用接口方式完成创建blog

    await loginPage.loginWithUserData(t);
    //登陆用户，登陆的用户信息从测试数据文件中获取

    await globalFeedPage.gotoGlobalFeed(t);
    await globalFeedPage.favoriteBlog(t);
   //按照page object设计模式，分页管理该页的页面元素定位和操作 
});

对于读取配置文件，如果用json文件管理配置信息或者测试数据，除了调用fs对象读取内容外，还可以直接引入文件获取文件中的内容，两种方式差别不大，具体差别请看如下脚本。同样，执行“npm run test:getConfigsTwo”即可调用getConfigsTwo()，执行脚本后console中打印了配置文件中内容，说明第二种方式正确获取到了配置信息。

const fs = require('fs');
const configs = require('./config');
function getConfigs() {
    const allConfigs = JSON.parse(fs.readFileSync('./e2e/scenario/demo/config/config.json'));
    //通过调用fs.readFileSync读取json文件内容，并调用Json.parse()转换为数据集

    let activeEnv;
    let configs = allConfigs.dev;
    process.env['ACTIVE_ENV'] = 'st';
    process.env.ACTIVE_ENV ? activeEnv = process.env.ACTIVE_ENV : activeEnv = allConfigs.active;
    if (activeEnv == "dev") {
        configs = allConfigs.dev
    } else if (activeEnv == "st") {
        configs = allConfigs.st
    }
    return configs
}
//上面的代码实现通过环境变量“ACTIVE_ENV”的值判断读取哪个环境的配置信息


 function getConfigsTwo() {
    console.log(configs.dev);
    console.log(configs.active)
 //除调用fs.readFileSync读取json文件内容外，还可以引入configs.json文件，这样可以直接获取该文件的内容。 
}
getConfigsTwo();

module.exports={
    getConfigs:getConfigs
};

通过retry机制提升脚本稳定性

前面讲过retry机制分为三种，定位页面元素时进行retry，这个已内置在TestCafe框架中，无需在使用时添加额外的脚本。基于步骤级别的retry，这种retry机制的关键点是能找到retry的判断条件，且有retry的具体步骤，在讲解Cypress和Puppeteer时已介绍过案例，这里不再重复说明。基于案例级别的retry，即如果测试案例运行失败，能自动进行retry。使用TestCafe时要实现基于案例级别的retry机制非常简单，在配置文件“.testcaferc.json”中设置quarantineMode的值为true即可，默认是false。在配置文件中添加此配置是全局生效，即所有失败案例都会自动重试两次。如果只想对部分测试案例进行失败retry，那么可以在执行命令中添加“-q”参数。例如，在package.json文件中让favoriateBlog测试案例能在失败后自动进行retry。

  "test:favoriateBlog": "testcafe chrome e2e/scenario/demo/feature/case/blogManage/favoriateBlog_spec.js -L -q"

通过前面案例的讲解可以看到使用TestCafe框架时，在调用接口、操作数据库数据、读取配置文件或者数据文件方面都支持，故如果被测应用需要覆盖IE或者safari等，TestCafe是一款不错的UI层自动化测试框架。