软件测试
软件测试
1 项目概述
1.1 背景介绍及目标
1.2 名词说明
单元测试：纯代码的测试（白盒测试）。主要测试代码语句的正确性，如所有的代码是否都可以跑到，是否有冗余的代码等等。
集成测试：接口测试（灰盒测试，结合白盒和黑盒测试）。主要测试代码块之间的接口。看看数据的传输是否有问题。
集中在各模块的接口是否一致、各模块间的数据流和控制硫是否按照设计实现其功能、以及结果的正确性验证等等
业务功能测试
参数组合测试: 参数有无，数值大小范围，字符串长短
异常情况测试：重复提交
系统测试：黑盒测试。不接触代码，只对整个系统做功能的测试和性能的测试。
以上的三中测试是在项目组中测试的。
验收测试：是客户做的测试。客户对他提出的需求，对应要交付的软件看看是否达到其要求。
1.3 Roadmap
2 需求分析
需求分析重点是需求
2.1 功能需求
2.2 非功能需求
2.3 调研
2.3.1 YApi
2.3.1.1 接口测试流程
流程
(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 中 count2.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)
测试步骤 (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 传送门
Last updated