python自动化测试（2）

自动化基本技术原理

1 概述

在之前的文章里面提到过：做自动化的首要本领就是要会 透过现象看本质 ，落实到实际的IT工作中就是 透过界面看数据。

掌握上面的这样的本领可不是容易的事情，必须要有扎实的计算机理论基础，才能看到深层次的本质东西。

2 应用软件逻辑结构

数据库应用系统 可能是最典型的网络应用程序了，关于它的软件架构如下：

一般在逻辑上分为4层：

用户界面层 UI
为终端用户提供交互的人机界面

业务逻辑层 BLL
将数据库抽象出来的对象进行拼接成具体的业务逻辑对象，并对之进行流程组织

数据访问层 DAL
对DB层做的ORM，让上层应用程序以对象的方式操控数据库

数据持久层 DB
存储数据，对数据进行持久化，不同的客户端进行数据共享

在传统的 C/S 架构下应用程序（例如，Windows下的客户端应用程序），一般都是一台中央数据库服务器（ DB ），然后对应N台客户端（DAL-BLL-UI ）。

对于 初级测试人员 来说，可能对软件的理解只能停留在 UI 层，于是在测试时候能做到的事情就是：日复一日，年复一年地用鼠标 点点点了。

3 互联网软件架构

在前一部分里面提到的应用软件的基本架构，虽然是在 “C/S” 时代提出来的，但是后面却一直延续到现在。直到今天最普遍的 “ABC/S” 模式：

App/Server
Browser/Server
Client/Server

其实本质上就把UI这一层放在客户端，把UI以下放在Server端。

客户端在不同的平台下面有不同的表现形式，就形成了现在流行的所谓的 “ABC/S” 模式的架构，这个基本上已经成为目前的互联网产品的标配了。具体的架构如下：

服务器端和客户端之间采用 Http/Https 的通讯协议，数据交换的格式为 Xml/Json 格式。

基于以上模式之后，软件测试的方法论就发生了一些变化：

有了 性价比 最高的“基于于通讯编码格式的接口测试”，属于花20%就能解决80%的工作
接口测试完全可以进行自动化，而且不必强制和开发项目使用相同的语言，可以统一使用效率较高的脚本语言
接口天然就具有稳定性的需求，所以自动化测试项目不会存在反复折腾的现象
接口测试人员成为了众多平台之间的 裁判员
接口规范来自设计文档，可以实行 设计产生测试，测试驱动开发 的规范模式

有了抽象成数据的能力之后，那么很多看到的东西就可以进行合理的等价转换了：

web页面背景的是红色
等价于：背景元素的background的颜色属性是 #FF0000

按钮上显示的字为"Submit"
等价于：按钮元素的value值为 Submit

用户执行一次充值活动充了20块钱，他的账号上就多了20元
等价于：以20为参数调用充值接口，再对比前后两次调用账号查询的接口，相差刚好是充值的参数值

在数据层次编程进行比较就变得很容易了，因为这些都是计算机擅长处理的领域了，自动化也很自然地实现了。

4 更底层的原理

前面讲到了对把软件项目从看到的具体的界面往底层一点抽象成数据的方法。其实还有一些更底层，更绝的，对软件的数据还可以更底层一点和物理世界建立关联（这已经不好用“抽象”或者“具象”来描述了）。

本部分的内容，已经和应用软件的测试的话题有点扯远了，纯粹就当科普吧。

从更广泛的角度来看一个计算机系统，它给人的体验上本质上是做了如下的处理：

人的所有的直观体验都是来自于对模拟量（物理量）的体验，人的交互输入也是来自于模拟量的输入。

人敲击键盘向计算机系统输入文字，键盘将不同一键位产生的脉冲电流传入计算机系统，计算机系统通过芯片和驱动，将这些电流信号转化成数字信号，然后交付数字芯片处理。这样人就完成了 信息的输入 。

计算机系统对这些数据进行计算，存储，传输等等，最后在LCD显示器上通过点亮不同位置的点阵，以形成光学的模拟量输出，传送到人的眼睛里面，人就完成了 信息的获取 。

以上的例子可以简化为：力学物理量产生电学物理量进行输入，计算机数字系统处理后，光学物理量进行输出。

对于计算机系统，输入和输出都是多样的：

输入装置
各种传感器都可以作为输入的主力，比如现在蓬勃发展的智能硬件，以及炒得火热的 物联网。

输出装置
除了光学的LCD显示器，还有声学的扩音器，还有滚动的轮式机械力学，还有人形走路的机械手臂力学设备。

这些东西都已经是现在互联网行业很流行的元素了。

由于电子技术和通讯领域往往检测的都是物理量，肉眼是很难量化的，所以测试门槛会很高，但是各种检测仪器反而发展得相当好，自动化程度相当高。反观IT行业的上层的应用软件层，人却都过多的依赖于人工去操作，肉眼去观察了，反而忽视了自动化，导致测试行业一直人员素质不高，技术实力太弱，这显然是很不可取的，至少是很不符合目前软件工程行业的时代需求的。