# 软件测试

## 软件测试

* [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)


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://meetbill.gitbook.io/butterfly-project-doc/project-handlers/other/butterfly-software-test.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.