软件测试

软件测试

• 1 项目概述

  • 1.1 背景介绍及目标

  • 1.2 名词说明

  • 1.3 Roadmap

• 2 需求分析

  • 2.1 功能需求

  • 2.2 非功能需求

  • 2.3 调研

    • 2.3.1 YApi

      • 2.3.1.1 接口测试流程

      • 2.3.1.1 变量参数

      • 2.3.1.2 断言脚本

    • 2.3.2 HttpRunner

      • 2.3.2.1 测试用例结构

        • 测试步骤 (testStep)

        • 测试用例 (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 传送门

1 项目概述

1.1 背景介绍及目标

image

1.2 名词说明

• 单元测试：纯代码的测试（白盒测试）。主要测试代码语句的正确性，如所有的代码是否都可以跑到，是否有冗余的代码等等。

• 集成测试：接口测试（灰盒测试，结合白盒和黑盒测试）。主要测试代码块之间的接口。看看数据的传输是否有问题。

  • 集中在各模块的接口是否一致、各模块间的数据流和控制硫是否按照设计实现其功能、以及结果的正确性验证等等

    • 业务功能测试

    • 参数组合测试: 参数有无，数值大小范围，字符串长短

    • 异常情况测试：重复提交

• 系统测试：黑盒测试。不接触代码，只对整个系统做功能的测试和性能的测试。

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

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

1.3 Roadmap

2 需求分析

需求分析重点是需求

2.1 功能需求

2.2 非功能需求

2.3 调研

2.3.1 YApi

2.3.1.1 接口测试流程

安装 chrome 插件

手册

流程

(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

测试步骤 (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
• 测试基础: 服务端接口测试指南