本节课开始的是一个全新的篇章,用例设计。 前言: 先来看一个问题:如何用deepseek来生成测试用例呢? 本来在最初的很多同学眼里,无非就是直接把原始需求发给AI,然后让其生成测试用例就完事了。 还比如想到不同的功能点适用的用例设计方案也不同,可以针对不同功能点单独配置用例设计方案。 等等等等... 越改越多,越来越复杂,于是乎,自动化的AI用例生成平台就为此而诞生了,也就是本教程。 生成前:在需求上下功夫 2. 生成中:生成测试用例 3. 生成后:对用例进行整理和使用等 那么,现在本教程进入到了哪个阶段了呢?当然是第二阶段了。 于是本节将正式开始做这个用例生成模块: 正文: 先来看看现在的平台样子: 我们首先,可以先对这个用例生成页面进行设计开发: 首先,我们先要获取到有多少个生成任务? 看一下: 也就是有13个生成任务。 所以,我们这个用例生成页面,首先先应该给基本信息获取并展示出来,这样在漫长的生成过程中,使用者也可以有个数。 先来生成用例生成子页面吧: 新建:CaseMake.vue 内容如下:复制后需自行换行。
上节课我们做了简单的第一版的 用例生成功能。结果展示到了界面上。 本节课来处理下后续的工作之一:去重。 生成的用例的确很多。 这里再插一嘴,在进行了不同用例生成方法为主的分类后,重复的概率很低,而且即便重复了,也可能是不同侧重的用例。 比如侧重边界值的和侧重判定表的某条重复了:拿登录功能举例 1. 用户名最大长度/密码正确:a123456789 pwdpwd2. 用户名正确/密码正确:a123456789 pwdpwd 所以,虽然这算重复用例,但很明显,测试目的是不同的。 然后我们来找到前端这个按钮,先做前端的功能: step1 : 先给按钮加个点击事件: step2: 在methods中新建这个函数quchong 思考,这个函数要干点啥? 无非就是: 把生成后的用例传送给后端 接收后端新的去重后的用例 把新用例展示 所以: step3: 写完整这个函数: 好,到此前端部分就结束了。 下节课我们搞定后端就实现了这个功能咯~
本节课继续开发以下内容: 【当点击开始生成按钮后,发送一个生成请求给到后台,后台通过函数通过调用并发线程,开始对这13个任务同时生成。每一个结果将独立发给汇总模块处理。】 汇总模块负责对结果进行进一步的筛选审核去重等功能,并返回给前端,后续前端可对结果进行人工修改,导出,永久存储等功能) 所以打开CaseMake.vue,进行如下开发: 然后在Myapp下创建一个专门用来处理用例生成的文件模块 :views2.py 然后做一个对应开始生成的引导函数: 最后是urls.py: 然后刷新页面,测试一下,点击开始生成按钮后能否在不报错的情况下成功显示提示: 然后来看一下为了生成用例,我们要提取的额该项目的信息有 然后重新分解下: 结果如下: 然后点击【后保存】按钮后,再执行下最新的 用例生成按钮: 可以看到结果已经更正过来了: 但是这个结果很显然,并不是很工整,为了更好的给AI智能体使用,我们还需要进行一个简单小优化
urls.py中新建这个链接映射: 然后打开:views.py2 文件,写好这个算法。 注意,我们在排查重复的时候,是优先删除后面用例的哦~ 就比如说 等价类出现了用例1 ,判定表也出现了用例1, 算法会删除判定表中的用例1 ,保留等价类的用例1 这里会提示删除了什么在后台控制台中: 我们来做个测试 ,按照我写死的用例数量生成后,是固定的39条: 点击去重后:生下来33条: 控制台显示删除了这6条重复的: 前端界面也可以看到,有些设计方法去重后不足3条了: 这个算法暂时算是完成了。 ,所以我们改一下之前写死的生成代码: 现在开始测试一下,先点击生成: 看下生成的用例:39条 然后点击去重按钮: 可以看到只去除了1条: 然后看看控制台日志: 可以发现,只有一条,因为只差了一个字不同, 但这里就有个问题,这个过程是不可逆的,一旦弄的太小了,剩的用例太少了,想再返回就不太可能了。毕竟删掉了就是删掉 了。 所以我们下一节的任务就是,做好前端动态调节系数的同时,做一个可逆转的操作。
@allure.attachment() 附件 报告添加附件 Allure2 报告中添加用例标题应用场景:为了让生成的测试报告便于阅读 生成的报告展示用例时,就会以设置的标题名展示出来。 Allure2 报告中添加用例标题通过使用装饰器 @allure.title 可以为测试用例自定义一个可阅读性的标题。 :通过占位符的方式传递参数,可以实现测试用例标题参数化,动态生成测试用例标题。 Allure2报告中添加用例步骤Allure2 报告中添加用例步骤应用场景:编写自动化测试用例的时候经常会遇到需要编写流程性测试用例的场景,一般流程性的测试用例的测试步骤比较多,我们在测试用例中添加详细的步骤会提高测试用例的可阅读性 Allure2 报告装饰器添加用例步骤方法一:使用装饰器定义一个测试步骤,在测试用例中使用。
写在前面 最近在群里看到很多同学在讨论“AI生成的用例到底能不能用”、“用例生成质量”、“哪个模型适合生成用例”这些话题,觉得挺有意思的,今天就结合我自己用 TestHub 从“需求->用例->执行”的项目实战案例 ,给出评审意见和补充用例; 生成完成:打印基于生成+评审意见综合改进后的最终版用例; 2.2.4 查看生成的用例 用例生成页面分为三个部分: 实时生成内容:也就是调用AI用例编写模型+用例编写提示词生成的用例内容 3.1 执行失败的用例分析(红色) 执行不通过的一共有3条用例,发现了2个bug。前两条属于第1个bug对应的场景,后1条属于第二个bug对应的场景。 需求文档中写的很清楚,有个“优先级排序”的字段最多支持3位数字,此时AI生成出来覆盖了2个场景,一个是输入999的最大三位数场景,一个是输入1000的四位数场景。所以两条用例是没问题的。 3 条执行不通过(可采纳,发现 2 个 bug) 5 条描述有问题(3 条是因为需求描述前后矛盾导致,2 条是 AI 胡咧咧导致) 手动补充 5 条用例; 至此,基于以上信息,我们可以得出一些简单的统计
测试用例格式 HttpRunner 的测试用例支持两种文件格式:YAML 和 JSON。 JSON 和 YAML 格式的测试用例完全等价,包含的信息内容也完全相同。 对于选择哪种格式取决于您的心情。 测试用例结构 在 HttpRunner 中,测试用例组织主要基于三个概念: 测试套(testsuite):对应一个文件夹,包含一个或者多个测试用例文件(YAML/JSON) 测试用例(testcase config:作为整个测试用例的全局配置项 test:对应单个测试步骤(teststep),测试用例存在顺序关系,运行时将从前往后依次运行各个测试步骤 对应的yaml格式如下: config: teststeps: - name: demo step 1 ... - name: demo step 2 ... 运算符的方式,例如headers.Content-Type、content.success; 响应结果为 text/html 结构,可采用正则表达式的方式,例如blog-motto\">(.*)</h2>
#风格特点: 严谨务实的工程师思维模式 回复必须用列表数组 注重测试覆盖率与可执行性平衡 不做需求之外的事,让分解需求就只分解需求不生成用例,让生成用例就只生成用例 #输出要求: ✧ 使用数组列表来呈现分解后的需求功能点或测试用例 ✧ 每条用例都包含且只包含[测试标题][测试步骤][输入数据][预期结果] ✧ 单条用例不超过50字(中文) #能力限制: × 分解需求时不生成测试用例 × 生成用例时不直接执行测试用例 × 生成用例时按照指定方法生成 ---意图配置2--- ##意图名称:测试用例生成 ##意图描述:根据具体测试点联系上下文按照括号内规定的生成用例方法来生成测试用例 ##意图示例: 用户输入:"生成用例(边界值):登录功能-用户名输入框测试 让AI模型先不考虑太多复杂的冲突,而是专注于按照单一的用例生成方法来生产测试用例,然后再把这大量的测试用例融合到一起,让AI去重。等去重之后,再让其去掉不符合常理或无法实现的用例。 而让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生成用例的一大步骤,就是对需求进行分解。会分解成多个功能点。 2. 自己在比如腾讯云中部署一个专属智能体,可以有训练,有性格还比较私密,但同样的,虽有免费额度也要花钱,并不多。效果A+。推荐公司落地时购买。 3. 并且把返回来的分解后的需求赋值给另一个新的列表型变量:new_srs 接下来是把这个new_srs用循环的方式显示到上方分解结果中: 接下来,我们得去django后台去搞定这个接口srs_fj了。
2.
自动生成用例 用例就在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: '本平台测试用例使用次数折线图
上节课我们设计了一个弹层,用来设置不同用例设计方法对应的需求功能点细分等。 这不,现在就要给填上不同用例的设计方案了。 这里我们有俩种方案来设计这个表。 1. 每个用例设计方法做一个字段,共13条,以后也会增多,但增多必须修改底层数据库增加新字段,何况项目以后还有很多其他重要字段,字段太多会很乱。所以不推荐。 2. 所有用例设计方法做一个列表,放在一个大文本字段中存储。以后增删改都比较方便,也不用修改底层数据库,所以我们采用这个办法。 于是,改成如下: 大家可以关注到,默认为空列表。 直接在函数中写上最初的列表和内部13个用例方法的键值对,就可以。那我们之前新建的这些项目就都算是脏数据了,可以删除,重新创建新项目来继续之后的开发。
思维导图的问题 测试用例难以量化管理、执行情况难以统计; 测试用例执行结果与 BUG 管理系统难以打通; 团队成员用思维导图设计用例的风格各异,沟通成本巨大; 小结 所以现在采用XMind2TestCase 来将思维导图转化为禅道用例进行导入 环境搭建 Xmind安装 https://www.xmind.cn/xmind8-pro/ 需要安装Xmind8 update3或更新版本 XMind2TestCase 找到用例模块 进入禅道用例页面:http://testcase.guahao-test.com/zentao/testcase-browse-56--byModule-4243.html 打开F12, 以门户改版-记录仪为例找到它的「模块ID」为「4244」,这样创建用例的时候它的节点应该为门户改版-记录仪(#4244) 用例模块 如果不指定模块ID,那么就会放在根路径下,建议先点击「维护模块」创建好自己用例所属的模块 ,然后开始用例编写 用例Demo demo 下载 生成用例 生成用例 导出禅道CSV 禅道CSV 导入禅道 导入禅道 由于禅道有一部分定制化,所以「优先级」、「适用阶段」、「适用阶段」导入失败
上一次分享的如何通过代码分析精简用例主要是针对WEB侧逻辑复用,从而精简冗余用例的案例。 本次的案例分享是希望通过对SVR代码的分析,完成用例执行的精简。 customer_profile_processor.cpp [1504062498587_3645_1504062498834.png] 用例精简: 拿两个用例来举例: 登录工号A,拨打B2C 网络电话同一号码n次,同一天内尝试再次拨打 登录工号A,拨打B2C网络电话不同号码n次,同一天内尝试再次拨打 通过这两个用例我们可以得出写用例同学是希望校验同一号码是否会被“去重”。 通过代码分析后,我们的执行则可以变成: (前提:拨打一次B2C后),拨打同一号码,用户画像使用次数是否增加。 (前提:拨打一次B2C后),拨打不同号码,用户画像使用次数是否增加。 2852199351, kfext=2852997014, quota result=0, use=5, max=5 至此,我们就完成了从耗时较长的多次电话拨打转变为拨打少量电话检查日志,从而完成了用例执行的精简
点击回到首页那个路由 改成如下: 2.
2. 通过命令安装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、安装完后,安装目录如下 ? 三、PICT的使用 1、在安装目录C:\Program Files (x86)\PICT下新建case.txt文本 ? 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、创建用例文档 ? 4、执行指令:pict 用例文档名称(pict LoginCase.txt) A:当执行出现乱码时,可做如下操作 ? 三,导出用例 执行导出命令:pict LoginCase.txt > LoginCase.xls 会在Pict工具根目录下生成.xls文件 ?