本节课开始的是一个全新的篇章,用例设计。 前言: 先来看一个问题:如何用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条: 然后看看控制台日志: 可以发现,只有一条,因为只差了一个字不同, 但这里就有个问题,这个过程是不可逆的,一旦弄的太小了,剩的用例太少了,想再返回就不太可能了。毕竟删掉了就是删掉 了。 所以我们下一节的任务就是,做好前端动态调节系数的同时,做一个可逆转的操作。
,给出评审意见和补充用例; 生成完成:打印基于生成+评审意见综合改进后的最终版用例; 2.2.4 查看生成的用例 用例生成页面分为三个部分: 实时生成内容:也就是调用AI用例编写模型+用例编写提示词生成的用例内容 ,与需求不一致---5条(后面会细分析为什么理解得有偏差); 黄色:表示有遗漏场景,是我手动补充的---5条(后面会细分析为什么有遗漏); 绿色执行通过的就不细分析了,下面重点来看红色执行失败(描述没问题 至此,也就是说在这个迭代版本下,AI 生成的用例一共发现了两个bug。 3.2 描述有问题的用例分析(蓝色) 蓝色标识用例不可采纳、描述有问题,一共出现了 5 条。 3 条执行不通过(可采纳,发现 2 个 bug) 5 条描述有问题(3 条是因为需求描述前后矛盾导致,2 条是 AI 胡咧咧导致) 手动补充 5 条用例; 至此,基于以上信息,我们可以得出一些简单的统计 如果计算AI生成+手动补充的、包括需求原因导致的,那么用例采纳率:(47+3)/(55+5)=83.33% 如果计算AI生成+手动补充的、不包括需求原因导致的,那么用例采纳率:(47+3)/(55+5-
#风格特点: 严谨务实的工程师思维模式 回复必须用列表数组 注重测试覆盖率与可执行性平衡 不做需求之外的事,让分解需求就只分解需求不生成用例,让生成用例就只生成用例 #输出要求: ✧ 使用数组列表来呈现分解后的需求功能点或测试用例 ✧ 每条用例都包含且只包含[测试标题][测试步骤][输入数据][预期结果] ✧ 单条用例不超过50字(中文) #能力限制: × 分解需求时不生成测试用例 × 生成用例时不直接执行测试用例 × 生成用例时按照指定方法生成 ---意图配置2--- ##意图名称:测试用例生成 ##意图描述:根据具体测试点联系上下文按照括号内规定的生成用例方法来生成测试用例 ##意图示例: 用户输入:"生成用例(边界值):登录功能-用户名输入框测试 " 输出:[{"测试标题":"边界值1长度","测试步骤":"输入单个字符","输入数据":"a","预期结果":"提示用户过短"},{"测试标题":"边界值正确长度","测试步骤":"输入5个字符", 而让AI模型去生成测试用例的过程中,我们也要反复强调全面,甚至多次让AI补充用例,尽量减少遗漏用例,多了不怕,反正后面有去重,就怕有漏掉的。
AI编写用例流程图AI编写用例架构图三、设计核心介绍本部分介绍如何使用AI辅助生成功能用例,详细讲解了从PRD文档->测试点->测试用例->Xmind用例->使用采纳,整条链路的核心设计与实现。 RAG提取架构设计核心代码逻辑模型设计测试点生成器测试点生成器为AI生成用例的核心,实现PRD到测试点的转换。 核心结构如下:结构组成设计实现方案详情模型设计测试用例生成器测试用例生成器为AI用例生成器,负责将AI测试点转换为Xmind测试用例,主要实现两个功能,第一步将AI测试点转换为markdown结构的测试用例 实现方案详情※ 测试点解析生成markdown格式用例:生成markdown格式用例解析结果※ AI markdown格式转换为Xmind结构用例转换Xmind结构生成结果模型设计知识库搭建LLM大模型有通用的推荐能力 ,实现了从 PRD自动解析->测试点生成-> Xmind用例生成->同步平台的完整流程。
英文 | https://betterprogramming.pub/5-use-cases-for-slice-in-javascript-13462f2e177f 翻译 | 杨小爱 slice() y = [1, 2, 3, 4, 5, 6] y.slice(2, -2) // will return [3, 4] 这意味着 y 会将数组从索引 2 切片到索引 -2 独占。 const midtermGrades = updatedGrades.slice(); 2、构造一个以n开头的子数组 slice() 方法的第二个用例是复制以 n 开头的子数组。 value + this.slice(index); }; var s = "Happy year"; alert(s.append(6,"new ")); 结论 学习 JavaScript 内置函数的用例可以帮助您提高编码技能 总结一下,本文中 slice() 的用例如下: 复制数组 构造一个从 n 开始的子数组 将类数组对象转换为数组 将 NodeList 转换为数组 替换字符串中的特定索引
扩展用例使用虚线箭头+关键字《extend》表示,箭头从扩展用例指向原用例。可以理解为翻译博客的用例扩展了阅读博客的用例。 ? 包含是指原有用例内部,存在更细致的子模块。 例如,博客的评论功能需要有登入、输入等包含用例。包含用例使用虚线箭头+关键字《include》表示,箭头从原用例指向子用例。可以理解为评论博客用例包含了登入和输入评论用例 ? 这也符合我们在2019-5-30-UML基础 - huangtengxiao中所说的less is more的原则 ? using multiplicity and collections in UML - lower and upper bounds, cardinality, order, unique. 2019-5- 30-UML基础 - huangtengxiao ---- 本文会经常更新,请阅读原文: https://xinyuehtx.github.io/post/UML%E7%94%A8%E4%BE%8B%E5%
自动生成用例 用例就在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风格。
一般来说,会把长篇大论的需求,找出所有的功能点,再对每个功能点写测试用例。所以AI生成用例的一大步骤,就是对需求进行分解。会分解成多个功能点。 5. 并且把返回来的分解后的需求赋值给另一个新的列表型变量:new_srs 接下来是把这个new_srs用循环的方式显示到上方分解结果中: 接下来,我们得去django后台去搞定这个接口srs_fj了。
script中的改动如下,data声明变量,methods存放获取函数,mounted自动调用函数。
const myChart = echarts.init(chart.value); const option = { title: { text: '本平台测试用例使用次数折线图
上节课我们设计了一个弹层,用来设置不同用例设计方法对应的需求功能点细分等。 这不,现在就要给填上不同用例的设计方案了。 这里我们有俩种方案来设计这个表。 1. 每个用例设计方法做一个字段,共13条,以后也会增多,但增多必须修改底层数据库增加新字段,何况项目以后还有很多其他重要字段,字段太多会很乱。所以不推荐。 2. 所有用例设计方法做一个列表,放在一个大文本字段中存储。以后增删改都比较方便,也不用修改底层数据库,所以我们采用这个办法。 于是,改成如下: 大家可以关注到,默认为空列表。 直接在函数中写上最初的列表和内部13个用例方法的键值对,就可以。那我们之前新建的这些项目就都算是脏数据了,可以删除,重新创建新项目来继续之后的开发。
随着多云存储技术成为市场主流,其用例正在迅速增长。因此组织需要考虑其备份、弹性、合规性、人工智能、软件开发的多云存储技术。 随着针对存储的多云用例数量正在迅速增长,人们需要了解以下五种可以使用多云环境增强其存储基础设施的方法。 1.数据备份和归档 其中最常见的多云用例是数据备份和归档。 2.弹性 另一个用于多云存储的用例是降低风险。 3.合规性 对于许多企业而言,合规性正成为有效的多云用例。数据必须越来越多地驻留在特定的地理区域,以满足数据治理和合规性法规。 5.软件开发 DevOps以及持续集成和持续交付是用于存储的最强大的多云用例。
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文件 ?
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回车 ?
3. 在methods中写出请求函数并在mounted中调用函数,这样可以让页面自动请求而无需用户手动触发:
本节课开始研发"进入项目"的功能。也就是用户一点击项目后进入的页面。实现起来是这样的思路。
生成成功的标志是: 1) 可以生成单元测试用例 2) 该用例可以被编译、执行通过 3) 被测方法被调用 4) 有断言 评估框架 类别 具体项 代码场景 对各种代码场景的覆盖 过程 用例的通过率和正确率% (Selection) 单测用例如果能自动生成,用例编写的成本就会极大降低,转而会对用例的维护带来压力。 jacoco貌似没有) 剔除没有新增覆盖率的用例。案例:某个用例执行之后,整个用例集的覆盖率并没有新增。 (可能受用例执行顺序的影响,每次筛选的结果会不一样) 4 用例集的执行耗时最小 在3的基础上,如果有多个用例可选,则选择耗时最短的(要考虑 setup/teardown) 方案局限性 就代码生成单测 ,属于后补用例的一种,只是将后补用例的成本极大降低了而已,但是并没有完全解决Test Oracle的问题,也就是说用例虽然生成了,但也可能是假阴性( False Positive)的。