序：写这一系列文章的动机来源于在部署Chanzhaoyu/chatgpt-web项目时发现，体验并不好，会存在多人同时提问时回答会夹断，上下文接不上的现象。同时希望搭建的项目能实现前后端分离。于是用webapi写了一套后端接口。我会把我在对接openai的接口开发的经验分享给大家。
目前我们用到最多的接口就是completions接口
POST https://api.openai.com/v1/chat/completions
官方给出的入参示例为：
curl https://api.openai.com/v1/chat/completions \
-H "Content-Type: application/json" \
-H "Authorization: Bearer $OPENAI_API_KEY" \
-d '{
"model": "gpt-3.5-turbo",
"messages": [{"role": "user", "content": "Hello!"}]
}'
header部分：
请求体：
**注意点：这里的messages 是接口的核心，分为三类：user、assistant、system **
同时，我们可以
返回参数官方示例：
{
"id": "chatcmpl-123",
"object": "chat.completion",
"created": 1677652288,
"choices": [{
"index": 0,
"message": {
"role": "assistant",
"content": "\n\nHello there, how may I assist you today?",
},
"finish_reason": "stop"
}],
"usage": {
"prompt_tokens": 9,
"completion_tokens": 12,
"total_tokens": 21
}
}
重点参数解析：
相信很多部署过chatgpt-web的同学都有遇到过上下文不连续，接不上的情况。其原因在于会话的数据是存在前端缓存里的，返回消息时出现了夹断，前端获取不到被夹断报错的上一次的聊天回复的内容。
看过chatgpt-web的源码的同学应该发现了，在发起聊天请求时，会传会话id给接口。我开始也是以为id是上下文的判断依据。后来在开发接口时才注意到OpenAI的接口并没有Id这样的参数。这说明会话的id并不是上下文的检索条件。
通过测试实现，我总结了下：
上下文的依据与会话id，还有你使用的key都是没有关系的，它只与你的message参数有关。
为了实现精确的上下文，你可以在发起请求时，将接口回复的内容一并带上。因为message 是一个集合，如下：
"messages": [{
"role": "assistant",
"content": "\n\nHello there, how may I assist you today?",
}{"role": "user", "content": "Hello!"}]
如果条件允许可以多加点（大于等于2），同时这肯定是消耗更多的余额的。
到此，你应该对completions接口已经有了充足的认识了。
本篇文章将详细讲解一下我们团队内部在遇到业务痛点时如何利用Httprunner框架进行接口自动化测试的。当最近邂逅chatGPT后又是如何将二者结合起来，实现"敏捷"自动化测试的。