> For the complete documentation index, see [llms.txt](https://meetbill.gitbook.io/butterfly-project-doc/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://meetbill.gitbook.io/butterfly-project-doc/project-handlers/other/butterfly-software-test.md).

# 软件测试

## 软件测试

* [1 项目概述](#1-项目概述)
  * [1.1 背景介绍及目标](#11-背景介绍及目标)
  * [1.2 名词说明](#12-名词说明)
  * [1.3 Roadmap](#13-roadmap)
* [2 需求分析](#2-需求分析)
  * [2.1 功能需求](#21-功能需求)
  * [2.2 非功能需求](#22-非功能需求)
  * [2.3 调研](#23-调研)
    * [2.3.1 YApi](#231-yapi)
      * [2.3.1.1 接口测试流程](#2311-接口测试流程)
      * [2.3.1.1 变量参数](#2311-变量参数)
      * [2.3.1.2 断言脚本](#2312-断言脚本)
    * [2.3.2 HttpRunner](#232-httprunner)
      * [2.3.2.1 测试用例结构](#2321-测试用例结构)
        * [测试步骤 (testStep)](#测试步骤-teststep)
        * [测试用例 (testCase)](#测试用例-testcase)
        * [测试用例集 (testSuite)](#测试用例集-testsuite)
* [3 总体设计](#3-总体设计)
  * [3.1 系统架构](#31-系统架构)
  * [3.2 模块简介](#32-模块简介)
  * [3.3 设计与折衷](#33-设计与折衷)
  * [3.4 潜在风险](#34-潜在风险)
* [4 详细设计](#4-详细设计)
  * [4.1 模块 xx](#41-模块-xx)
    * [4.1.1 交互流程](#411-交互流程)
    * [4.1.2 数据库设计](#412-数据库设计)
    * [4.1.3 接口形式](#413-接口形式)
* [5 传送门](#5-传送门)

## 1 项目概述

### 1.1 背景介绍及目标

![image](https://github.com/meetbill/meetbill_static/blob/master/software_engineering/software_flow.jpeg?raw=true)

### 1.2 名词说明

> * 单元测试：纯代码的测试（白盒测试）。主要测试代码语句的正确性，如所有的代码是否都可以跑到，是否有冗余的代码等等。
> * 集成测试：接口测试（灰盒测试，结合白盒和黑盒测试）。主要测试代码块之间的接口。看看数据的传输是否有问题。
>   * 集中在各模块的接口是否一致、各模块间的数据流和控制硫是否按照设计实现其功能、以及结果的正确性验证等等
>     * 业务功能测试
>     * 参数组合测试: 参数有无，数值大小范围，字符串长短
>     * 异常情况测试：重复提交
> * 系统测试：黑盒测试。不接触代码，只对整个系统做功能的测试和性能的测试。

以上的三中测试是在项目组中测试的。

> * 验收测试：是客户做的测试。客户对他提出的需求，对应要交付的软件看看是否达到其要求。

### 1.3 Roadmap

## 2 需求分析

> 需求分析重点是需求

### 2.1 功能需求

### 2.2 非功能需求

### 2.3 调研

#### 2.3.1 YApi

**2.3.1.1 接口测试流程**

[安装 chrome 插件](https://github.com/fjc0k/YApi-X/tree/master/chrome-extension)

[手册](https://hellosean1025.github.io/yapi/documents/case.html)

> 流程

```
(1) 创建接口
(2) 创建测试集合
(3) 测试用例，测试用例需要关联接口
    导入接口(path/params)
    设置环境配置(ip:port)
    设置请求参数
    设置断言脚本
```

**2.3.1.1 变量参数**

YApi 提供了强大的变量参数功能，你可以在测试的时候使用前面接口的`参数`或`返回值`作为 后面接口的参数，即使接口之间存在依赖

```
$.{key}.{params|body}.{path}

YApi 每个测试用例会自动生成一个 key id

例子(假设依赖的是 key 269 测试用例):
$.269.params.name # 269 测试用例 name 参数
$.269.body.data.count # 269 返回值中的 data object 中 count
```

**2.3.1.2 断言脚本**

```
# 断言 httpCode 等于 200
assert.equal(status, 200)

# 断言 body 是否等于 { stat: 'OK', str_info: 'ceshi' }
assert.deepEqual(body, { stat: 'OK', str_info: 'ceshi' })

# 断言返回数据 stat 为 OK
assert.equal(body.stat, 'OK')
```

#### 2.3.2 HttpRunner

<https://github.com/httprunner/httprunner>

**2.3.2.1 测试用例结构**

HttpRunner 之 step/case/suite

测试步骤 (testStep) -> 测试用例 (testCase) -> 测试场景/测试用例集 (testSuite)

![image](https://github.com/meetbill/meetbill_static/blob/master/httprunner/httprunner_case.png?raw=true)

**测试步骤 (testStep)**

对于接口测试来说，每一个测试步骤应该就对应一个 API 的请求描述。

**测试用例 (testCase)**

测试用例（testcase）应该是为了测试某个特定的功能逻辑而精心设计的，并且至少包含如下几点：

> * 明确的测试目的
> * 明确的输入
> * 明确的运行环境
> * 明确的测试步骤描述
> * 明确的预期结果

测试用例设计原则：

> * 测试用例应该是完整且独立的，每条测试用例都应该可以独立运行；
> * 测试用例由测试脚本和测试数据两部分构成。
> * 测试脚本：测试脚本只关注被测的业务功能逻辑，包括前置条件、测试步骤、预期结果等。
> * 测试数据：是对应测试的业务数据。
> * 测试数据和测试脚本分离：方便实现数据驱动测试。通过对测试脚本传入一组数据，实现同一业务功能在不同数据逻辑下的测试验证。比如：购买商品接口，会员和非会员的商品价格是不一样的，优惠券逻辑也不一样。所以通过不同的用户数据，可以测试会员和非会员购物逻辑。

**测试用例集 (testSuite)**

测试用例集是测试用例的无序集合，集合中的测试用例应该互相独立，不存在先后依赖关系。

如果确实存在先后依赖关系，例如登录功能和下单功能。正确的做法应该是，在下单测试用例的前置步骤中执行登录操作。

## 3 总体设计

> 总体设计重点是设计与折衷

### 3.1 系统架构

> 一般来说会有个简单的架构图，并配以文字对架构进行简要说明；

### 3.2 模块简介

> 架构图中如果有很多模块，需要对各个模块的功能进行简要介绍；

### 3.3 设计与折衷

> 设计与折衷是总体设计中最重要的部分；

### 3.4 潜在风险

## 4 详细设计

> 详细设计重点在“详细”

### 4.1 模块 xx

> (有了数据库+接口+流程，别的同学拿到详设文档，基本也能够搞定了)

#### 4.1.1 交互流程

> 简要的交互可用文字说明，复杂的交互建议使用流程图，交互图或其他图形进行说明

#### 4.1.2 数据库设计

#### 4.1.3 接口形式

## 5 传送门

> * [软件测试 wiki](https://zh.wikipedia.org/wiki/%E8%BD%AF%E4%BB%B6%E6%B5%8B%E8%AF%95)
> * [测试基础: 服务端接口测试指南](https://testerhome.com/topics/29928)