本节课开始的是一个全新的篇章,用例设计。 前言: 先来看一个问题:如何用deepseek来生成测试用例呢? 本来在最初的很多同学眼里,无非就是直接把原始需求发给AI,然后让其生成测试用例就完事了。 还比如想到不同的功能点适用的用例设计方案也不同,可以针对不同功能点单独配置用例设计方案。 等等等等... 越改越多,越来越复杂,于是乎,自动化的AI用例生成平台就为此而诞生了,也就是本教程。 生成前:在需求上下功夫 2. 生成中:生成测试用例 3. 生成后:对用例进行整理和使用等 那么,现在本教程进入到了哪个阶段了呢?当然是第二阶段了。 于是本节将正式开始做这个用例生成模块: 正文: 先来看看现在的平台样子: 我们首先,可以先对这个用例生成页面进行设计开发: 首先,我们先要获取到有多少个生成任务? 看一下: 也就是有13个生成任务。 所以,我们这个用例生成页面,首先先应该给基本信息获取并展示出来,这样在漫长的生成过程中,使用者也可以有个数。 先来生成用例生成子页面吧: 新建:CaseMake.vue 内容如下:复制后需自行换行。
上节课我们做了简单的第一版的 用例生成功能。结果展示到了界面上。 本节课来处理下后续的工作之一:去重。 生成的用例的确很多。 我们看上节课的结果例子中其实是有重复的,这主要是我写的智能体假返回值,用了一个简单的随机数,以模仿可能出现的重复用例。 这里再插一嘴,在进行了不同用例生成方法为主的分类后,重复的概率很低,而且即便重复了,也可能是不同侧重的用例。 比如侧重边界值的和侧重判定表的某条重复了:拿登录功能举例 1. 而用例是否算重复,绝对不能简单的看字符串是否一致。必须要更加灵活的进行比对,比如切割成词组,余铉相似等理论。 无非就是: 把生成后的用例传送给后端 接收后端新的去重后的用例 把新用例展示 所以: step3: 写完整这个函数: 好,到此前端部分就结束了。 下节课我们搞定后端就实现了这个功能咯~
本节课继续开发以下内容: 【当点击开始生成按钮后,发送一个生成请求给到后台,后台通过函数通过调用并发线程,开始对这13个任务同时生成。每一个结果将独立发给汇总模块处理。】 汇总模块负责对结果进行进一步的筛选审核去重等功能,并返回给前端,后续前端可对结果进行人工修改,导出,永久存储等功能) 所以打开CaseMake.vue,进行如下开发: 然后在Myapp下创建一个专门用来处理用例生成的文件模块 :views2.py 然后做一个对应开始生成的引导函数: 最后是urls.py: 然后刷新页面,测试一下,点击开始生成按钮后能否在不报错的情况下成功显示提示: 然后来看一下为了生成用例,我们要提取的额该项目的信息有 然后重新分解下: 结果如下: 然后点击【后保存】按钮后,再执行下最新的 用例生成按钮: 可以看到结果已经更正过来了: 但是这个结果很显然,并不是很工整,为了更好的给AI智能体使用,我们还需要进行一个简单小优化
注意,我们在排查重复的时候,是优先删除后面用例的哦~ 就比如说 等价类出现了用例1 ,判定表也出现了用例1, 算法会删除判定表中的用例1 ,保留等价类的用例1 这里会提示删除了什么在后台控制台中: 我们来做个测试 ,按照我写死的用例数量生成后,是固定的39条: 点击去重后:生下来33条: 控制台显示删除了这6条重复的: 前端界面也可以看到,有些设计方法去重后不足3条了: 这个算法暂时算是完成了。 jieba from sklearn.metrics.pairwise import cosine_similarity 然后下面新建这个函数和修改红圈部分:注意,此时设置分数大于0.8 这里因为写死的用例都太过相似 ,所以我们改一下之前写死的生成代码: 现在开始测试一下,先点击生成: 看下生成的用例:39条 然后点击去重按钮: 可以看到只去除了1条: 然后看看控制台日志: 可以发现,只有一条,因为只差了一个字不同, 但这里就有个问题,这个过程是不可逆的,一旦弄的太小了,剩的用例太少了,想再返回就不太可能了。毕竟删掉了就是删掉 了。 所以我们下一节的任务就是,做好前端动态调节系数的同时,做一个可逆转的操作。
在搞懂了这个问题后,才能有针对性地提高用例生成质量。 像上面截图中同学所讨论的,有同学说和模型关系不大。那如果我说,千问3 VS ChatGPT5.4,你觉得哪个生成出来的质量高? 这个版本的迭代需求一共生成了55条用例,通过实际执行、标记后: 绿色:表示用例可采纳、且执行通过---47条; 红色:表示用例可采纳、但出现了bug,执行不通过---3条; 蓝色:表示用例不可采纳、描述有问题 : 如果只计算AI生成的、包括需求原因导致的,那么用例采纳率:(47+3)/(55)=90.91% 如果只计算AI生成的、不包括需求原因导致的,那么用例采纳率:(47+3)/(55-3)=94.34% 如果计算AI生成+手动补充的、包括需求原因导致的,那么用例采纳率:(47+3)/(55+5)=83.33% 如果计算AI生成+手动补充的、不包括需求原因导致的,那么用例采纳率:(47+3)/(55+5- 3)=87.72% 反正不管怎么理解吧,至少从我用的 TestHub + 综合能力强一点的生成模型组合 + 项目真实迭代需求的实战结果来看,AI 生成用例采纳率至少有 83.33%,至高是 94.34%
#风格特点: 严谨务实的工程师思维模式 回复必须用列表数组 注重测试覆盖率与可执行性平衡 不做需求之外的事,让分解需求就只分解需求不生成用例,让生成用例就只生成用例 #输出要求: ✧ 使用数组列表来呈现分解后的需求功能点或测试用例 ✧ 每条用例都包含且只包含[测试标题][测试步骤][输入数据][预期结果] ✧ 单条用例不超过50字(中文) #能力限制: × 分解需求时不生成测试用例 × 生成用例时不直接执行测试用例 × 生成用例时按照指定方法生成 ##意图示例: 用户输入:"分解需求:测试一个登录功能,包含用户名输入框(3-8位)、密码输入框(隐藏为*)" 输出:["登录功能-用户名输入框测试","登录功能-密码输入框测试"] ##意图实现: 用数组列表来回复 ---意图配置2--- ##意图名称:测试用例生成 ##意图描述:根据具体测试点联系上下文按照括号内规定的生成用例方法来生成测试用例 ##意图示例: 用户输入:"生成用例(边界值):登录功能-用户名输入框测试 而让AI模型去生成测试用例的过程中,我们也要反复强调全面,甚至多次让AI补充用例,尽量减少遗漏用例,多了不怕,反正后面有去重,就怕有漏掉的。
AI编写用例流程图AI编写用例架构图三、设计核心介绍本部分介绍如何使用AI辅助生成功能用例,详细讲解了从PRD文档->测试点->测试用例->Xmind用例->使用采纳,整条链路的核心设计与实现。 RAG提取架构设计核心代码逻辑模型设计测试点生成器测试点生成器为AI生成用例的核心,实现PRD到测试点的转换。 核心结构如下:结构组成设计实现方案详情模型设计测试用例生成器测试用例生成器为AI用例生成器,负责将AI测试点转换为Xmind测试用例,主要实现两个功能,第一步将AI测试点转换为markdown结构的测试用例 实现方案详情※ 测试点解析生成markdown格式用例:生成markdown格式用例解析结果※ AI markdown格式转换为Xmind结构用例转换Xmind结构生成结果模型设计知识库搭建LLM大模型有通用的推荐能力 ,实现了从 PRD自动解析->测试点生成-> Xmind用例生成->同步平台的完整流程。
一般来说,会把长篇大论的需求,找出所有的功能点,再对每个功能点写测试用例。所以AI生成用例的一大步骤,就是对需求进行分解。会分解成多个功能点。 3. 自己购买云服务器部署deepseek,接口调用简单,可以有更深度的自定义设置,但收费按小时计算,开销巨大。推荐更专业的中大型团队落地时使用。 4. 并且把返回来的分解后的需求赋值给另一个新的列表型变量:new_srs 接下来是把这个new_srs用循环的方式显示到上方分解结果中: 接下来,我们得去django后台去搞定这个接口srs_fj了。
script中的改动如下,data声明变量,methods存放获取函数,mounted自动调用函数。
自动生成用例 用例就在tests/mitm实时生成好了,用例文件名为当前时间: 每录制一个请求,就能在测试用例中看到实时添加了一条测试步骤: # 接口描述 # 数据 # 请求 /usr/bin/python # encoding=utf-8 # mitmproxy录制流量自动生成用例 import os import time from mitmproxy import time.strftime("%Y%m%d_%H_%M_%S", time.localtime()) + ".py" case_file = os.path.join(mitm_dir, filename) # 生成用例文件 =============命令说明结束================================== """ 通过mitmproxy命令启动代理后,获取当前时间作为文件名在tests/mitm下生成用例文件 自动生成的用例只支持tep风格。
const myChart = echarts.init(chart.value); const option = { title: { text: '本平台测试用例使用次数折线图 { color: '#409EFF', // 折线颜色 }, lineStyle: { width: 3,
上节课我们设计了一个弹层,用来设置不同用例设计方法对应的需求功能点细分等。 这不,现在就要给填上不同用例的设计方案了。 这里我们有俩种方案来设计这个表。 1. 每个用例设计方法做一个字段,共13条,以后也会增多,但增多必须修改底层数据库增加新字段,何况项目以后还有很多其他重要字段,字段太多会很乱。所以不推荐。 2. 所有用例设计方法做一个列表,放在一个大文本字段中存储。以后增删改都比较方便,也不用修改底层数据库,所以我们采用这个办法。 于是,改成如下: 大家可以关注到,默认为空列表。 直接在函数中写上最初的列表和内部13个用例方法的键值对,就可以。那我们之前新建的这些项目就都算是脏数据了,可以删除,重新创建新项目来继续之后的开发。
本节课开始研发"进入项目"的功能。也就是用户一点击项目后进入的页面。实现起来是这样的思路。
通过命令安装axios插件,用来发出具体http请求: npm install axios --save 3.
PICT工具一键生成正交试验用例 作用: 1、解决手动设计大量测试用例、或覆盖不全面问题,提高测试效率 2、读取excel,将生成的参数组合自动带入脚本,进行接口自动化测试 一、PICT简介 PICT工具是在微软公司内部使用的一款承兑组合的命令行生成工具,现在已经对外提供,可以在 http://download.microsoft.com/download/f/5/5/f55484df-8494 PICT可以有效地按照两两测试的原理,进行测试用例设计。在使用PICT时,需要输入与测试用例相关的参数,以达到全面覆盖的效果。 二、PICT的安装 1. 2、在安装目录下cmd打开命令框,输入pict case.txt回车,生成正交试验用例 ? 3、安装目录下生成excel用例文件,输入pict case.txt>case.xls回车 ?
PICT是一个测试用例生成工具,可以有效地按照两两测试的原理,进行测试用例设计。在使用PICT时,需要输入与测试用例相关的参数,以达到全面覆盖的效果。 它可以生成测试用例和测试配置,其理论基础是成对测试技术(Pairwise Testing)。 下载地址:http://www.pairwise.org/tools.asp ? 二、工具安装使用 1、使用讲解 以以下登录页面进行用例设计,使用PICT来设计测试用例 ? 2、创建用例文档 ? 3、使用工具执行,进入打开pict工具根目录,在目录栏输入cmd,打开cmd窗口 ? 三,导出用例 执行导出命令:pict LoginCase.txt > LoginCase.xls 会在Pict工具根目录下生成.xls文件 ?
保存接口 3. 后端保存函数 说起保存按钮,这个设计我一直不是很喜欢,因为人家辛苦写好或者粘贴好原始需求后,很容易转头就忘了点击保存按钮,那么页面只要一刷新,那就都没了。 urls.py: 最后是后端views.py中: 好,到此完成,测试一下: 然后刷新页面: 可以看到,已经成功储存了,这种增删改查是最简的也是最常用的,小伙伴一定要牢记哦~ 好,本节结束,下一节开始用例生成篇章哦
生成成功的标志是: 1) 可以生成单元测试用例 2) 该用例可以被编译、执行通过 3) 被测方法被调用 4) 有断言 评估框架 类别 具体项 代码场景 对各种代码场景的覆盖 过程 用例的通过率和正确率% (Selection) 单测用例如果能自动生成,用例编写的成本就会极大降低,转而会对用例的维护带来压力。 3 最少用例实现最大覆盖率(行覆盖、分支覆盖、判定? (可能受用例执行顺序的影响,每次筛选的结果会不一样) 4 用例集的执行耗时最小 在3的基础上,如果有多个用例可选,则选择耗时最短的(要考虑 setup/teardown) 方案局限性 就代码生成单测 ,属于后补用例的一种,只是将后补用例的成本极大降低了而已,但是并没有完全解决Test Oracle的问题,也就是说用例虽然生成了,但也可能是假阴性( False Positive)的。
Python测试框架pytest(20) 插件 生成html报告、重复执行用例、用例执行顺序、多重断言 目录 1、pytest-html(生成html报告) 1.1、安装 1.2、操作参数 1.2.1、 +报错截图) pytest-html 测试报告默认是不展示用例描述 Description 内容,可以修改生成的报告内容,添加或删除 html 报告的 table 内容。 (2)class:以类为用例集合单位,重复执行类里面的用例,再执行下一个。 (3)module:以模块为单位,重复执行模块里面的用例,再执行下一个。 ,输入执行命令: pytest -s --count=2 --repeat-scope=class test_repeat3.py 重复执行类里面的用例,再执行下一个类里面的用例。 3、pytest-ordering(用例执行顺序) pytest-ordering 插件可以控制用例的执行顺序。
做测试的你,是不是也常陷入这些内耗:用例设计漏测边界场景,面试被问“如何设计高覆盖用例”卡壳;缺陷报告写得模糊,总被研发打回补充;排查Bug只知复现,不懂深挖根因,同类问题反复出现;时间不够时,不知道如何合理排序测试优先级 (解决漏测、冗余问题) • 输入指令:“帮我对登录功能进行用例分层设计,覆盖核心、边界、异常场景” • Skill输出:自动拆分3类用例——核心用例(账号密码正确登录)、边界用例(验证码过期、多设备同时登录 )、异常用例(账号为空、密码错误),并标注优先级,避免漏测或用例冗余,面试时可直接用这个框架说明“如何实现高覆盖用例”。 这款Skill专为测试场景设计而生,是测试用例的“前置助手”,能帮你快速梳理完整场景,覆盖正常、异常、边界所有情况。 核心用法 用法极简,只需输入待测功能,无需复杂配置,3步就能生成完整场景: 1. 输出结果:结构化场景清单,包含3类场景——正常场景(完整结算流程)、异常场景(库存不足、支付失败、地址无效)、边界场景(最大商品数、最小支付金额),可直接基于场景补充测试用例,面试时按这个框架答题,逻辑清晰