文章转载链接：www.51testing.com/html/36/n-7…
什么是测试用例
测试用例的定义
测试用例是为项目需求而编制的一组包含测试输入、执行条件以及预期结果的文档，以便测试某个程序是否满足客户需求。
测试用例的作用
· 编写用例的过程中，可以帮助测试人员更好的理解系统的架构以及业务流程。
· 提高测试效率，测试用例写的准确，详细，执行起来的速度就很快；有时做交叉测试，别人看到你写的用例后理解、执行起来也很方便有一份用例来指导测试执行。在测试人员疲累的时候测试用例也可以起到一个牵引作用
· 防止漏测,测试用例覆盖的功能点全面，就能够尽量减少上线后出现Bug的几率
· 评估测试结果的度量标准,完成测试实施后需要对测试结果进行评估，并且编制测试报告是判断软件测试是否完成，衡量测试质量需要一些量化的结果。
· 防止测试背锅
怎么高效编写测试用例
测试用例的组成
每家公司的用例模板各有差异，大致由以下部分组成：
用例编号：非必填项，用例上传禅道后会自动生成
所属模块：功能或子功能模块
用例标题：组成为【APP端/管理后台】+【所属模块】+ 一句话总结当前测试的用意和目的
优先级：表示用例的重要程度或影响力P0~P4（P0最高，禅道上可以一键设置）
前置条件：执行此条用例，有哪些前置操作，否则用例无法执行。图中写的较为简略，详细一点还需写上如网络正常，用户已登录等等。（当时我的项目较急，整个测试也是我一个人测，所以我写的简略一点；如果是需要交叉测试建议写详细一些，避免别人还得跑过来问你这条用例什么意思）
测试数据：操作的数据，跟步骤结合起来一定要具有指导性意义，没有可为空。图中我将信息进行了打码处理，实际操作需要填写符合要求的信息。（禅道上的话是没有测试数据这一栏的，所以我是将测试数据融合到测试步骤里）
测试步骤：明确给出每个步骤的描述，执行人员可以根据该步骤完成执行工作（emm，如图我又偷懒了）
预期：期望达到的结果
用例类型：功能测试，兼容性测试等等。
用例编写形式
1. 直接去禅道上下砸Excel模版，用Excel编写
2. 在项目管理平台例如禅道上编写，不常用
3. 使用Xmind编写，再用Python脚本将Xmind文件转为Excel文件，调好格式后统一上传禅道
个人觉得使用Xmind编写更为方便，?Python脚本参考如下：
from typing import List, Any
import xlwt
from xmindparser import xmind_to_dict
def resolve_path(dict_, lists, title):
"""
通过递归取出每个主分支下的所有小分支并将其作为一个列表
:param dict_:
:param lists:
:param title:
:return:
"""
# 去除title首尾空格
title = title.strip()
# 若title为空，则直接取value
if len(title) == 0:
concat_title = dict_["title"].strip()
else:
concat_title = title + "\t" + dict_["title"].strip()
if not dict_.__contains__("topics"):
lists.append(concat_title)
else:
for d in dict_["topics"]:
resolve_path(d, lists, concat_title)
def xmind_to_excel(list_, excel_path):
f = xlwt.Workbook()
# 生成单sheet的Excel文件，sheet名自取
sheet = f.add_sheet("XX模块", cell_overwrite_ok=True)
# 第一行固定的表头标题
row_header = ["序号", "所属模块", "用例标题"]
for i in range(0, len(row_header)):
sheet.write(0, i, row_header[i])
# 增量索引
index = 0
for h in range(0, len(list_)):
lists: List[Any] = []
resolve_path(list_[h], lists, "")
# print(lists)
# print('\n'.join(lists)) # 主分支下的小分支
for j in range(0, len(lists)):
# 将主分支下的小分支构成列表
lists[j] = lists[j].split('\t')
# print(lists[j])
for n in range(0, len(lists[j])):
# 生成第一列的序号
sheet.write(j + index + 1, 0, j + index + 1)
sheet.write(j + index + 1, n + 1, lists[j][n])
# 自定义内容，比如：测试点/用例标题、预期结果、实际结果、操作步骤、优先级……
# 这里为了更加灵活，除序号、模块、功能点的标题固定，其余以【自定义+序号】命名，如：自定义1，需生成Excel表格后手动修改
if n >= 2:
sheet.write(0, n + 1, "自定义" + str(n - 1))
# 遍历完lists并给增量索引赋值，跳出for j循环，开始for h循环
if j == len(lists) - 1:
index += len(lists)
f.save(excel_path)
def run(xmind_path):
# 将XMind转化成字典
xmind_dict = xmind_to_dict(xmind_path)
# print("将XMind中所有内容提取出来并转换成列表：", xmind_dict)
# Excel文件与XMind文件保存在同一目录下
excel_name = xmind_path.split('\\')[-1].split(".")[0] + '.xlsx'
excel_path = "\\".join(xmind_path.split('\\')[:-1]) + "\\" + excel_name
print(excel_path)
# print("通过切片得到所有分支的内容：", xmind_dict[0]['topic']['topics'])
xmind_to_excel(xmind_dict[0]['topic']['topics'], excel_path)
if __name__ == '__main__':
xmind_path_ = r"\绝对路径\"
run(xmind_path_)
PS:xmind里编写内容如果有换行如
1.巴拉巴拉巴啦
2.巴拉巴拉巴拉
导出的Excel文件里面也是包含了换行符的，看不出来只是Excel单元格格式-对齐里没有勾选换行。如果你需要给别人展示，可以全选-右击选择设置单元格格式-对齐-文本控制里的自动换行打上√。
如何编写测试用例
测试用例主要分为三步，仅供大家参考
1. 通过需求说明文档划分功能模块。结合原型图（例如摹客RP），UI设计图（例如蓝湖）梳理业务流程，熟悉业务流程。
2. 按照业务流程，从最底层的业务开始编写测试用例。
3. 挖掘隐性需求，覆盖非功能测试层面。
通过需求说明文档划分功能模块
举个例子，这次的项目是在员工内部使用的APP中新打造一个商城模块，那根据需求文档可以先将整个项目划分为APP端和管理后端。
管理后端中分为福利管理，商品管理，主题管理和销售管理。那最基本的业务流程应该是： 先是添加商品，商品对应某个主题如中秋，国庆主题等，之后得发放对应主题的优惠券让员工兑换福利，兑换了之后才有销售数据。
那我们编写用例可以先从商品管理模块开始编写，之后再是主题管理，类推…
结合原型图（我们用的摹客RP），UI设计图（我们用的蓝湖），再将功能模块中的需求和操作对应起来。如下图，可售时间组件的默认展示应该怎么展示等等。
按照业务流程，从最底层的业务开始编写测试用例
接着开始编写用例了，测试用例的常用编写方法就不过多介绍了，如黑盒测试的对穷举场景设计测试点的等价类划分法，解决边界限制问题的边界值法，解决多条件有依赖关系测试的判定表法等等；白盒测试里有语句覆盖法等。这些方法我们都得熟悉。可参考这篇博文：
测试场景的编写
现在的AI发展这么迅速,可以将功能点提取出来让AI来帮我们写测试点(手动狗头)，不过AI写的终归是不全面的，我们还需在他的基础上进行补充。
挖掘隐性需求，覆盖非功能测试层面
除了功能测试，非功能测试也是测试用例编写中不可忽视的一部分。非功能测试主要包括性能测试、安全性测试、兼容性测试等。
图片引用自如何高效编写测试用例
举一个例子：
上文所述的商城模块APP端，前期我们使用一台手机测试可能没什么，压力测试时也没问题，但是到了真正上线后，在人流量最大的那段时间（刚宣布上线10min内）大量用户却加载不进去了。
可是我们看瞬时并发并不大：
最后原因是，大家都从服务器上下载图片，把兑换的商品先挂某鱼上，导致带宽太厉害了，所以得压缩下图片的大小，再申请一下服务网络资源。
总结
总结一下就是首先说了啥是测试用例，就是帮咱看看程序能不能满足客户需求的一组文档。作用可大啦，能让咱测试的人更好理解业务，提高效率，还能防止漏测和背锅。测试用例的组成呢，不同公司模板有点不一样，但大致就那些部分。编写形式也有好几种，像用 Excel、禅道，或者用 Xmind 再转 Excel。编写测试用例分三步，先划分功能模块，看看原型图啥的熟悉业务流程；接着从底层业务开始写，可以让 AI 帮忙但还得自己补充；最后可别忘了挖掘隐性需求，像性能、安全、兼容性这些非功能测试也很重要哦！
