本节课开始的是一个全新的篇章,用例设计。 前言: 先来看一个问题:如何用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条: 然后看看控制台日志: 可以发现,只有一条,因为只差了一个字不同, 但这里就有个问题,这个过程是不可逆的,一旦弄的太小了,剩的用例太少了,想再返回就不太可能了。毕竟删掉了就是删掉 了。 所以我们下一节的任务就是,做好前端动态调节系数的同时,做一个可逆转的操作。
#风格特点: 严谨务实的工程师思维模式 回复必须用列表数组 注重测试覆盖率与可执行性平衡 不做需求之外的事,让分解需求就只分解需求不生成用例,让生成用例就只生成用例 #输出要求: ✧ 使用数组列表来呈现分解后的需求功能点或测试用例 ✧ 每条用例都包含且只包含[测试标题][测试步骤][输入数据][预期结果] ✧ 单条用例不超过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用例生成->同步平台的完整流程。
自动生成用例 用例就在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风格。
script中的改动如下,data声明变量,methods存放获取函数,mounted自动调用函数。
一般来说,会把长篇大论的需求,找出所有的功能点,再对每个功能点写测试用例。所以AI生成用例的一大步骤,就是对需求进行分解。会分解成多个功能点。 并且把返回来的分解后的需求赋值给另一个新的列表型变量:new_srs 接下来是把这个new_srs用循环的方式显示到上方分解结果中: 接下来,我们得去django后台去搞定这个接口srs_fj了。
const myChart = echarts.init(chart.value); const option = { title: { text: '本平台测试用例使用次数折线图
上节课我们设计了一个弹层,用来设置不同用例设计方法对应的需求功能点细分等。 这不,现在就要给填上不同用例的设计方案了。 这里我们有俩种方案来设计这个表。 1. 每个用例设计方法做一个字段,共13条,以后也会增多,但增多必须修改底层数据库增加新字段,何况项目以后还有很多其他重要字段,字段太多会很乱。所以不推荐。 2. 所有用例设计方法做一个列表,放在一个大文本字段中存储。以后增删改都比较方便,也不用修改底层数据库,所以我们采用这个办法。 于是,改成如下: 大家可以关注到,默认为空列表。 直接在函数中写上最初的列表和内部13个用例方法的键值对,就可以。那我们之前新建的这些项目就都算是脏数据了,可以删除,重新创建新项目来继续之后的开发。
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)的。
urls.py: 最后是后端views.py中: 好,到此完成,测试一下: 然后刷新页面: 可以看到,已经成功储存了,这种增删改查是最简的也是最常用的,小伙伴一定要牢记哦~ 好,本节结束,下一节开始用例生成篇章哦
Python测试框架pytest(20) 插件 生成html报告、重复执行用例、用例执行顺序、多重断言 目录 1、pytest-html(生成html报告) 1.1、安装 1.2、操作参数 1.2.1、 +报错截图) pytest-html 测试报告默认是不展示用例描述 Description 内容,可以修改生成的报告内容,添加或删除 html 报告的 table 内容。 ,再执行下一个用例。 (2)class:以类为用例集合单位,重复执行类里面的用例,再执行下一个。 (3)module:以模块为单位,重复执行模块里面的用例,再执行下一个。 ,每条用例执行2次,所以总共执行6次用例。
角色指令按这个写: #角色名称:测试用例生成专家 #角色概述:负责根据用户需求自动生成全面、规范的测试用例,确保覆盖功能、边界、异常等多种测试场景 #风格特点: 1️⃣ 严谨务实的工程师思维模式 2️⃣ 善用分层编号结构组织信息 3️⃣ 主动追问需求细节的沟通方式 4️⃣ 注重测试覆盖率与可执行性平衡 #输出要求: ✧ 使用Markdown表格呈现测试用例 ✧ 包含[用例编号][测试步骤][预期结果 × 不生成性能/安全专项测试用例 ---意图配置--- ##意图名称:测试场景解析与用例生成 ##意图描述:将用户提供的功能需求转化为可执行的测试方案,重点识别潜在测试维度 ##意图示例: 用户输入 (Web/APP) [等待用户确认后生成] 登录功能测试用例(示例节选) 用例ID 测试步骤 预期结果 优先级 类型 TC-AUTH-001 输入正确账号密码点击登录 跳转至用户主页 高 功能 也正因如此,才足够专业,能撑得起我面高度定制化的用例生成平台。 好,本节到此结束。
在系统分析阶段,我们一般用UML来画很多图,主要包括用例图、状态图、类图、活动 图、序列图、协作图、构建图、配置图等等,要画哪些图要根据具体情况而定。 其实简单的理解,也是个人的理解,UML的作用就是用很多图从静态和动态方面来 全面描述我们将要开发的系统。 二.用例建模简介 用例建模是UML建模的一部分,它也是UML里最基础的部分。 用例建模的最主要功能就是用来表达系统的功能性需求或行为。依我的理解用例建模可分为 用例图和用例描述。用例图由参与者(Actor)、用例(Use Case)、系统边界、箭头组成,用画图的方法来完成。 用例描述用来详细描述用例图中每个用例,用文本文档来完成。 1. 用例图 参与者不是特指人,是指系统以外的,在使用系 统或与系统交互中所扮演的角色。