代码中使用的是讯飞spark3.0版本,其中版本在的控制已经封装到了langchain对应的讯飞的iflytek的类中，可以在调用的时候显示控制，默认是spark2.0版本
讯飞星火的Langchain封装
因为在Langchain中没有讯飞spark的类，因此基于langchain的问题做了如下的封装（如下代码可以直接用）
#!/usr/bin/env python
# -*- coding: utf-8 -*-
'''
@File : iflytek.py
@Time : 2023/10/27 17:28:58
@Author : CrissChan
@Version : 1.0
@Site : https://blog.csdn.net/crisschan
@Desc : 通过Langchain的customerLLM的方式，把讯飞的spark介入Langchain，按照Langchain的https://python.langchain.com/docs/modules/model_io/models/llms/custom_llm进行改写
'''
import logging
from typing import Any, List, Optional,Mapping
from langchain.callbacks.manager import CallbackManagerForLLMRun
from langchain.llms.base import LLM
from spark_middlerware import SparkMiddleware
class SparkLLM(LLM):
#domain 代表需要调取spark的版本其中有三种值可选 "general"是v1.5版本，"generalv2"表示v2.0版本， "generalv3"表示v3.0版本，当前讯飞的星火就有三个版本
domain :str = "generalv2"
# temperature 代表调取spark模型的结果的随机程度，这个数值越小表示随机性越差，也就是输出的越单一，大部分取值在0.1到1.0之间。
temperature:float=0.5
@property
def _llm_type(self) -> str:
return "Spark"
@property
def _identifying_params(self) -> Mapping[str, Any]:
"""Get the identifying parameters."""
# _model_kwargs = self.model_kwargs or {}
return {
**{"domain": self.domain},
**{"temperature": self.temperature},
}
def _call(
self,
prompt: str,
stop: Optional[List[str]] = None,
run_manager: Optional[CallbackManagerForLLMRun] = None,
**kwargs: Any,
) -> str:
if stop is not None:
raise ValueError("stop kwargs are not permitted.")
# return prompt[: self.n]
smw = SparkMiddleware(domain=self.domain,temperature=self.temperature,role='user',content=prompt)
try:
logging.debug("spark response :"+smw.response())
return smw.response()
except Exception as e:
logging.debug(f"spark middlerware error :{e}")
return "error"
其中实例化sparkLLM的时候有两个参数，一个是domain可以选择 "general"是v1.5版本，"generalv2"表示v2.0版本， "generalv3"表示v3.0版本。目前测试中发现3.0确实是相对最好用，但是免费额度也不多，大家自己按需选择啊。
temperature就是大模型中相对使用比较多的超参，这个数值越小表示随机性越差，也就是输出的越单一，讯飞星火要求temperature取值在0.1到1.0之间。
SparkLLM调用的中间层
spark_middlerware是调取讯飞提供的spark的访问类的封装的sparkLLM的中间层，这里加入了一下spark本身自己的约束，包含了秘钥的读取(从.env中读取，使用了dotenv类完成），三个版本spark的方位地址，以及一些模型的约束，类似token长度等。
#!/usr/bin/env python
# -*- coding: utf-8 -*-
'''
@File : spark_middlerware.py
@Time : 2023/11/01 18:44:52
@Author : CrissChan
@Version : 1.0
@Site : https://blog.csdn.net/crisschan
@Desc : 链接sparkapi的中间件，中间控制版本，token上限等
'''
import SparkApi
import os
from dotenv import load_dotenv, find_dotenv
#以下密钥信息从控制台获取
class SparkMiddleware(object):
_=load_dotenv(find_dotenv())
appid = os.getenv("SPARK_APP_ID")
api_secret=os.getenv("SPARK_APP_SECRET")
api_key=os.getenv("SPARK_APP_KEY")
domain_url = {"general":"ws://spark-api.xf-yun.com/v1.1/chat",
"generalv2":"ws://spark-api.xf-yun.com/v2.1/chat",
"generalv3":"ws://spark-api.xf-yun.com/v3.1/chat",
}
text =[]
'''
@des :spark middlerware的构造函数，创建一个和封装sparkapi调用的参数的中间层
@params :
domain 代表需要调取spark的版本其中有三种值可选 "general"是v1.5版本，"generalv2"表示v2.0版本， "generalv3"表示v3.0版本，当前讯飞的星火就有三个版本
role 代表角色，星火的有两个角色“user”表示是用户的问题，“assistant”表示AI的回复
@return :None
'''
def __init__(self,domain,temperature,role,content) -> None:
self.text.clear
self.__getText(role,content)
SparkApi.main(self.appid,self.api_key,self.api_secret,self.domain_url[domain],domain,temperature,self.text)
pass
'''
@des :拼装成访问参数中的text需要的格式
@params : role 代表角色，星火的有两个角色user表示是用户的问题，assistant表示AI的回复
content是用户输入的问题
@return :None
'''
def __getText(self,role,content) -> None:
jsoncon = {}
jsoncon["role"] = role
jsoncon["content"] = content
self.text.append(jsoncon)
# return self.text
self.__checklen()
'''
@des :获取这次传递给llm的prompt的长度
@params :None
@return :None
'''
def __getlength(self)-> None:
length = 0
for content in self.text:
temp = content["content"]
leng = len(temp)
length += leng
return length
'''
@des :参数长度检查，如果全部的prompt的长度超过了8000，那么就删除这次拼装好的prompt
@params :None
@return :None
'''
def __checklen(self)-> None:
while (self.__getlength() > 8000):
del self.text[0]
# return self.text
'''
@des :获取LLM的反馈
@params :None
@return :string
'''
def response(self)-> str:
return SparkApi.answer
利用Langchain的一些能力实现测试用例设计方法
实现了一个测试用例设计方法的枚举类型，目前包含了等价类测试用例设计方法和因果图测试用例设计方法（明显的使用spark3.0效果最优）
# 定义测试用例设计方法的枚举类型
class DesignType(Enum):
EP = "等价类测试用例设计" # 等价类测试用例设计方法
CE = "因果图测试用例设计" # 因果图测试用例设计方法
设计了测试用例的运行方式，通过输入被测系统的业务逻辑，生成测试用例。
#测试用例设计方法
class TestCase():
def __init__(self):
self.llm = SparkLLM(temperature=0.1,domain="generalv3")
self.memory = ConversationBufferMemory()
self.conversation = ConversationChain(llm=self.llm, memory=self.memory,verbose = True)
def run_ep(self,input:str="")-> None:
'''
@des :等价类测试用例设计方法设计测试用例
@params :input是被测试的业务逻辑
'''
delimiter :str = "###"
ep_message :str =f"""{delimiter}{DesignType.EP.value}是把输入的参数域划分成若等价类,这些等价类包含了有效等价类和无效等价类，
有效等价类是指对于程序的规格说明来说是合理的,有意义的输入数据构成的集合，利用有效等价类可检验程序是否实现了规格说明中所规定的功能。
无效等价类是指对于程序的规格说明来说是不合理的,无意义的输入数据构成的集合，利用无效等价类可检验程序是否有效的避免了规格说明中所规定的功能以外的内容。
然后从每个等价类中选取少数代表性数据作为测试用例，每一类的代表性数据在测试中的作用等价于这一类中的其他值。
特别注意，一条测试用例可以覆盖多个有效等价类，一条测试用例只能覆盖一个无效等价类{delimiter}
使用等价类测试用例设计方法需要经过如下几步：{delimiter}
step1：{delimiter}对输入的参数进行等价类划分，在划分等价类的时候，应该遵从如下的一些原则：{delimiter}
在输入条件规定了输入值的集合或者规定了必须满足的条件的情况下,可确立一个有效等价类和一个无效等价类。
在输入条件是一个布尔量的情况下,可确定一个有效等价类和一个无效等价类。布尔量是一个二值枚举类型, 一个布尔量具有两种状态: true 和 false 。
在规定了输入数据的一组值（假定n个）,并且程序要对每一个输入值分别处理的情况下,可确立n个有效等价类和一个无效等价类.例：输入条件说明输入字符为:中文、英文、阿拉伯文三种之一，则分别取这三种这三个值作为三个有效等价类，另外把三种字符之外的任何字符作为无效等价类。
在规定了输入数据必须遵守的规则的情况下,可确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）。
在确知已划分的等价类中各元素在程序处理中的方式不同的情况下,则应再将该等价类进一步的划分为更小的等价类{delimiter}
step2：{delimiter}将等价类转化成测试用例，按照[输入条件][有效等价类][无效等价类] 建立等价类表,等价类表可以用markdown的方式给出，列出所有划分出的等价类，为每一个等价类规定一个唯一的编号。
{delimiter}设计一个测试用例覆盖有效等价类的时候，需要这个测试用例使其尽可能多地覆盖尚未被覆盖地有效等价类,重复这一步。直到所有的有效等价类都被覆盖为止。
{delimiter}设计一个新的测试用例,使其仅覆盖一个尚未被覆盖的无效等价类,重复这一步.直到所有的无效等价类都被覆盖为止，测试用例用markdown 的的表格形式输出。{delimiter}
输出按照如下步骤输出：{delimiter}
step1:{delimiter} <step 1 reasoning >
step2:{delimiter} <step 2 reasoning >
测试用例：{delimiter} <response to customer>
最后一定要输出一个 markdown 的表格形式测试用例，其他都不用了。
"""
self.memory.save_context({"input": f"{delimiter}是分隔符.你是一个一名资深的测试工程师，对于测试用例设计有着丰富的经验。"}, {"output": f"是的，我非常精通{DesignType.EP.value}。"})
input_message : str = f"用等价类测试用例设计方法完成{input}业务逻辑的测试用例设计。{delimiter}{ep_message}。"
self.conversation.predict(input=input_message)
def run_ce(self,input:str="")-> None:
'''
@des :因果图测试用设计方法设计测试case
@params :input是被测试的业务逻辑
'''
delimiter :str = "###"
ce_message :str = f"""
{delimiter}因果图测试用例设计方法是从需求中找出因（输入条件）和果（输出或程序状态的改变），
通过分析输入条件之间的关系（组合关系、约束关系等）及输入和输出之间的关系绘制出因果图，再转化成判定表，从而设计出测试用例的方法。{delimiter}
该方法主要适用于各种输入条件之间存在某种相互制约关系或输出结果依赖于各种输入条件的组合时的情况，
在使用因果图测试用例设计方法的时候重点分析出所有输入和输出条件的相互制约关系及组合关系，输
出对于输入的依赖关系也就决定了什么样的输入组合产生什么样的输出结果。{delimiter}
因果图中条件和结果，也就是输入和输出之间有四种关系分别是恒等、非、或、与。{delimiter}
因果图中条件和条件之间有五种关系，也就是输入和输入之间有五种关系分别是互斥、包含、唯一、要求、屏蔽。{delimiter}
用因果图测试用例设计方法需要经过如下几步：{delimiter}
step1：分析业务逻辑中设计的系统中各个组件、模块，其中各个组件、模块就是因果图的因素，使用因果图来描述系统中各个因素之间的因果关系，因果关系主要是组件、模块之间的关系，画出因果图。{delimiter}
step2：根据因果图识别的因果关系，建立判定表，输出判定表。{delimiter}
step3：将判定表中的每一个因素转换成原始被测试业务中代表的内容，然后按照一行是一个测试用例的格式输出。测试用例应该涵盖各种输入、条件和场景，以确保系统的全面测试。{delimiter}
输出按照如下步骤输出：{delimiter}
step1:{delimiter} <step 1 reasoning >
step2:{delimiter} <step 2 reasoning >
step3:{delimiter} <step 3 reasoning >
测试用例：{delimiter} <response to customer>
最后一定要输出一个 markdown 的表格形式测试用例，其他都不用了。
"""
self.memory.save_context({"input": f"{delimiter}是分隔符.你是一个一名资深的测试工程师，对于测试用例设计有着丰富的经验。"}, {"output": f"是的，我非常精通{DesignType.CE.value}。"})
input_message : str = f"用{DesignType.CE.value}完成{input}业务逻辑的测试用例设计。{delimiter}{ce_message}。"
self.conversation.predict(input=input_message)
def run(self,type : DesignType= DesignType.EP,input:str="")->None:
'''
@des :测试用例设计的统一入口
@params : type 测试用例设计方法（是一个枚举值 DesignType）
input是被测试的业务逻辑
'''
if type == DesignType.EP:
self.run_ep(input=input)
elif type == DesignType.CE:
self.run_ce(input=input)
调用举例
if __name__ == '__main__':
testcase = TestCase()
input:str = f"""被测系统是地铁车票自助购票软件系统需求，系统只接收 5元或10元纸币，一次只能使用一张纸币，车票只有两种面值 5 元或者 10 元。其中：
若投入5元纸币，并选择购买5元面值票，完成后出票，提示购票成功。
若投入5元纸币，并选择购买10元面值票，提示金额不足，并退回5元纸币。
若投入10元纸币，并选择购买5元面值票，完成后出票，提示购票成功，并找零5元。
若投入10元纸币，并选择购买10元面值票，完成购买后出票，提示购买成功。
若输入纸币后在规定时间内不选择票种类的按钮，退回的纸币，提示错误。
若选择购票按钮后不投入纸币，提示错误."""
testcase.run(type = DesignType.CE,input=input)
