6. 基本理论和开发规范

6.1. 概念陈述

目前软件测试行业的理论和细分领域层出不穷，主要包括以下几方面：

  1. 判定测试
  2. 压力测试
  3. 响应测试
  4. 安全测试

本文只讲 判定测试 这个领域的内容。

所谓的 判定测试 包括如下几类：

  1. 界面自动化
  2. 接口自动化
  3. 单元自动化

其实这就是 分层自动化金字塔 中的三层。

../_images/auto-test-by-layer.png

它们的共同点就是：对于一个定义数据和定义的执行过程通常会有一个预期输出，如果实际输出和预期输出不同，则定义为Flase，否则为True。

所以，基于以上特点，都可以归结到 “判定测试” 的概念里面来，可以生成一样的 测试报告产出物，都适用于本文提到的 x-utest系统 。

此处的 判定测试 的测试场景和类别包括且不限于：

  1. 单元测试
  2. 接口测试
  3. UI测试
  4. 环境测试

只要是涉及到：

  1. 测试用例
  2. 测试套件
  3. 测试结果
  4. 测试详情

都可以使用本系统生成报表并存储历史测试数据。

6.2. 开发规范

为了达到上述的预期效果，有一些基本的开发规范需要地团队共同遵守。

  1. 良好分层的软件系统架构
  2. 明确的版本管理体系
  3. 形成良好信息流的基础软件功能

6.2.1. 分层架构

前面提到了 软件的分层金字塔 结构，是目前主流互联网公司的所推崇的基本结构。 很多无法推进自动化测试的软件系统，大部分问题都出在这儿了，需要好好设计一下。

6.2.2. 版本管理

所谓的版本管理，其实目标就是：明确被测对象。

一个软件系统从开始到结束它的名字基本上是不会变的，但是每个时期，只要是任何代码的改变，其实它都是变化的。对外展现的是不变性，对内则一定要进行好的区分。

被测对象版本号的重要性。每次提测而且需要记录备案的软件系统必须是独一无二的，拥有唯一的代号，即： 版本号。

关于版本号的命名方式，业界有很我成熟的方法，在此不再赘述。只要满足如下要求即可：

  1. 保证版本号的唯一性
  2. 从字面意思可以看得到版本的演进和迭代顺序

6.2.3. 基础功能

形成流畅的信息流的前提是：所有的过程尽量能够自动化。

对于测试人员来说，有两样东西非常重要：

  1. 被测对象版本号及特性信息
  2. 运行相关环境及软件库依赖

以 服务端接口 作为被测试对象的 自动化测试 过程为例子，开发人员必须至少提供一个接口：

  • 显示应用程序内部信息的接口。

对于该接口的定义，下面给出一个示范：

  • 接口名称
    /app-info/
  • 请求方式
    GET
  • 输入参数
    无

返回值：

{
    "code": 200,
    "msg": "",
    "data": {
        "server": "tornado",
        "req_time": "2017-04-19 15:38:46",
        "app_version": "3.17.04.18.1"
    }
}

参数说明：

  • app_version 服务端接口应用程序版本号
  • server 服务器类型

如果有其它需要关注的信息，可以随时扩展上去。

本文最关注的内容是 app_version 所表示的被测对象版本信息 ，在上面的接口中有所体现。