前端测试 测试方法论——数据驱动测试

点点寒彬 · 2018年01月01日 · 最后由 点点寒彬 回复于 2018年05月11日 · 4201 次阅读

背景

最近手头上需要新接一个 UI 测试的工作,抽空研究了一下,发现现在网上所有流传的方式都是用Selenium来执行,这个本身我觉得没什么毛病,但是测试思想还是太陈旧了,依然是使用findElementById等方法来执行,这种情况下,前端的维护成本高,稳定性差等问题都非常明显,因此有了著名的测试三角形。

历史

说明这个问题的时候,需要了解整个前端技术的发展过程。

  • Web1.0 时代

那个时候压根没有 JS 什么事,基本上都是静态页面,数据交互以表单的形式为主。

  • Web2.0 时代

出现了Ajax技术,整个前端的发展有了一个质的飞跃,异步加载的机制让前端衍生了非常多的场景,js逐渐进入大家的视线,产生了神器jQuery,整个前端的交互变得丰富多彩。

  • Web3.0 时代

出现了Angular,React,Vue等数据驱动的框架,前端开始向后端看齐。

测试现状

按照现有的测试方式,都是使用Selenium进行测试,而Selenium的产生时间,是在 Web2.0 时代,那个时代,大部分网页的编写方式都是靠jQuery来处理,而jQuery的开发思维是操作DOM结构,因此使用Selenium来测试非常的方便,因为开发要实现某个元素的变化,就必须用jQuery的选择器来选中这个元素,然后再进行对应的操作,比如下面的代码:

$('#id').on('click', function({alert('hello')}))

那么测试的时候用Selenium来操作也没有问题,因为开发要选中某个元素,开发的时候必定会留下方便选中的方式,比如写一个id,或者某些其他的标记,那么这些标记测试也是可以用的。

但是近几年来,用Selenium来测试为什么越来越麻烦和困难了呢?原因就是开发已经不使用jQuery来开发了,他们已经变为数据驱动了,不需要留标记来让代码选中元素了,那么自然的,使用Selenium来测试,就有缺陷了,选中元素变得特别的困难,而且通过Xpath来选择特别不稳定,再加上前端的元素变动频繁,导致 UI 测试的成本特别大。

而基于数据驱动开发则与以前的开发方式完全是两个维度。数据驱动开发的时候只需要关心数据,比如有一个表格,那么只要在html中定义好表格的元素,数据定一个一个空列表就行了,需要加载的数据的时候,只要赋值给列表,前端的框架会自动把数据渲染成表格,比如这样的代码:

<template>
    <el-table
      :data="tableData"
      style="width: 100%">
      <el-table-column
        prop="date"
        label="日期"
        width="180">
      </el-table-column>
      <el-table-column
        prop="name"
        label="姓名"
        width="180">
      </el-table-column>
      <el-table-column
        prop="address"
        label="地址">
      </el-table-column>
    </el-table>
  </template>

  <script>
    export default {
      data() {
        return {
          tableData: [{
            date: '2016-05-02',
            name: '王小虎',
            address: '上海市普陀区金沙江路 1518 弄'
          }, {
            date: '2016-05-04',
            name: '王小虎',
            address: '上海市普陀区金沙江路 1517 弄'
          }, {
            date: '2016-05-01',
            name: '王小虎',
            address: '上海市普陀区金沙江路 1519 弄'
          }, {
            date: '2016-05-03',
            name: '王小虎',
            address: '上海市普陀区金沙江路 1516 弄'
          }]
        }
      }
    }
  </script>

要改变表格里面的内容,只需要修改tableData的数据就行,而不需要选中表格的某一行某一列的某个值进行替换。

改善方法

既然前端框架已经让开发者可以忽略html的结构,只需要玩转数据。那么我们测试也应该跟着开发的框架走,只关心数据即可,其他的渲染交给框架处理,我们校验数据。

举个例子,业务场景是这样的:点击一个按钮,程序会向后台请求数据,请求数据成功后显示一个提示框,提示框中显示后台返回的数据,如果请求失败,则提示请求失败。我们的测试方式则是关注提示框的选项的显示属性是否为true,提示框的类型是否为successerror,提示文案是否正确即可,无需关注页面的展示,因为那是框架做的事。

测试代码

下面是我自己写的一个简单的测试代码,前端框架用的是基于Vue.jsElement

<!DOCTYPE html>
<html>

<head>
    <title>标题</title>
    <meta charset="UTF-8">
    <script src="https://unpkg.com/vue/dist/vue.js"></script>
    <link rel="stylesheet" href="https://unpkg.com/element-ui/lib/theme-chalk/index.css">
    <script src="https://unpkg.com/element-ui/lib/index.js"></script>
</head>

<body>
    <div id="test">
        <el-alert :title=wenan :type=alert_style v-show=alert>
        </el-alert>
        <el-input v-model="input" placeholder="请输入内容"></el-input>
        <el-button @user1='clicktest'>成功按钮</el-button>
        <el-button @user2='clickfail'>失败按钮</el-button>
    </div>
    <script type="text/javascript">
    var app = new Vue({
        el: '#test',
        data: {
            input: '',
            wenan: '123',
            alert_style: "",
            alert: false
        },
        methods: {
            clicktest: function() {
                this.alert = true
                this.wenan = 'succeed'
                this.alert_style = 'success'
            },
            clickfail: function() {
                this.alert = true
                this.wenan = 'failed'
                this.alert_style = 'error'
            }
        }
    })
    </script>
</body>

</html>

下面是对应的测试代码,只是一个非常简单的示例:

# ecoding=utf-8
# Author: Sven_Weng
# Email : sven_weng@wengyb.com
# Web   : http://wybblog.applinzi.com
import time
from selenium import webdriver

option = webdriver.ChromeOptions()
option.add_argument('disable-infobars')
browser = webdriver.Chrome(chrome_options=option)
browser.get("file:///Users/SvenWeng/Desktop/demo.html")
js = 'app.input = "ceshiwenan"'
js1 = 'app.clicktest()'
js2 = 'return app.alert_style'
js3 = 'return app.alert'
js4 = 'return app.wenan'
time.sleep(1)
browser.execute_script(js)
time.sleep(1)
browser.execute_script(js1)
time.sleep(1)
rs2 = browser.execute_script(js2)
time.sleep(1)
rs3 = browser.execute_script(js3)
time.sleep(1)
rs4 = browser.execute_script(js4)
time.sleep(1)
print rs2, rs3, rs4
assert rs2 == 'success'
assert rs3 == True
assert rs4 == 'succeed'
browser.quit()

最后

这是我个人一个大胆的想法,还没有具体应用到实际的项目中,所以我只称他为方法论,写出来的目的也就是希望大家在测试的时候,不要被已有的技术或者框架局限了,测试代码的结构和思维方式应该跟开发同步,这样才能最大效率的进行测试。

这个想法不仅仅应用在 WEB 端,移动端的 H5 页面如果也是基于数据驱动开发的框架写的话,依然可以用这个思想进行测试。

如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
共收到 8 条回复 时间 点赞

思路很赞~确实随着前端框架的流行,开发人员已经逐步不直接控制 dom 了。

有个小想法,既然前端已经用了专业的前端框架,其实也可以采用前端框架对应推荐的集成测试方式(例如 这篇文章 里测试 react 的方式),确保逻辑的正确性,测试起来也更聚焦。不过代价就是和前端代码耦合性提高。

很赞👍

陈恒捷 回复

是的,这块我也在思考,这样测试对前端框架的依赖太大了,有没有大的遗漏点目前也还不清晰,下个月项目开工我要按照这样测一遍试试水

这样是直接调用 js 来执行功能,就像平常调用 js 去拖动滚动条一样

木子李 回复

是的,这样其实对测试人员要求非常高,至少开发的框架必须要有一定程度的熟悉,而且测试的时候,基本上要把开发的代码通读一遍。

我感觉你说这些,更偏向单元测试。
Selenium 其实接近黑盒测试,这两个在方向和收益上是不太一致的。。。

edsion 回复

确实是的,主要是基于 DOM 元素的 Selenium 方案测试起来脚本的维护成本太高,收益低。
而这种方式稳定,但是确实需要测试人员有较高的技术水平

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册