前書き
UIと比較すると、インターフェイスが開発されると、変更またはリファクタリングの頻度と規模は通常比較的小さくなります。したがって、インターフェースの自動化を行う方が費用効果が高く、通常、反復バージョンがオンラインになる前の回帰テストで使用されます。
手動インターフェーステストの場合、テストデータとパラメーターはテスターが手動で入力および更新できます。
したがって、インターフェースのユースケースの自動化を検討する場合、主なアイデアは、単一のインターフェースによって要求されたテストケースが完了していることを前提として、次の問題をどのように解決するかです。
- ビジネステストシナリオでは複数のインターフェイスが呼び出され、次のインターフェイスの要求は前のインターフェイスのデータに依存し、インターフェイスの依存関係の問題を解決する必要があります
- トークンなどの認証データには有効期限があります。複数のインターフェースがこのパラメーターを使用します。1つの変更が複数の場所で有効になるという問題を解決する必要があります。
- インターフェイスは複数のテストデータでカバーする必要があります
- バッチテストでは、インターフェイスから返されるパラメータ/データが期待を満たしているかどうかを知る必要があります
この記事で使用されている自動インターフェーステストツールは、公式WebサイトのダウンロードアドレスであるApifoxです。www.Apifoxは、直接ダウンロード、登録、およびインストールした後に使用できます。次に、apifoxを使用して上記の問題を順番に解決する方法を説明します。
文章
1.インターフェースパラメータ
一般的なシナリオの説明をします。クエリインターフェイスがデータの取得を要求する場合、access_tokenパラメータが必要であり、access_tokenパラメータは別の認証インターフェイスから取得する必要があります。したがって、認証インターフェースは取得したトークンパラメータをクエリインターフェースに渡す必要があり、クエリインターフェースはリクエストを開始できます。
もう1つの一般的なシナリオは、選択したアイテムをショッピングカートに追加する前に、ユーザーがログインする必要があることです。このインターフェースは、データを取得するための前のインターフェースに応じて、要求を正常に開始します。手動テストの場合は、手動で直接コピーできます。
解決策：前のインターフェースによって返されたデータからターゲットパラメーターを識別して抽出し、それらをグローバル変数として保存し、次のインターフェースによってパラメーターを直接呼び出す必要があります。
步骤： 1）在apifox的接口tab-后置操作tab，选择提取变量 2）填写变量名称，变量类型和提取的表达式。提取表达式符合json path 语法。在本接口数据中由于返回数据只有一层，因此采用$.目标参数的方式提取。 如果有多层参数，可以点击提取表达式旁边的问号，查看详细的json path语法。
获取到的参数以变量的形式存储，点击接口tab右上角的设置图标，可以查看到获取到的环境变量的值。 接着就可以在下一个接口，以参数的方式调用：
二. 外部数据源
一些post数据给后台处理的接口，需要对上传不同的数据来测试接口的返回和异常兼容，一个接口参数需要多次使用不同的数据。 手动情况下我们可以直接在参数里填数据，之后每次手动改。
但如果实现自动化的话，像上述的测试方式难以实现。 常用的解决方案是先编辑好csv文件，将测试数据一一写好保存，最后传入到接口请求参数中。 Apifox在这个问题上提供的解决方案为：a.对于少量的测试数据，可在界面内填好测试数据集供接口每次调用；如果是大量的数据，才使用csv文件；更少量的数据则可以直接写在全局变量中。
以全局变量的方式导入和上节讲到的接口传参类似，区别只在于测试数据不是从上一个接口获取到而是的我们自己填进去的。 若是使用外部测试数据集，在测试管理tab>用例界面右侧，有一个测试数据的开关项，打开即可导入测试数据。当然首先需要先把用例导入到测试步骤中来。
如图所示，我已经将OCRtest（文本识别接口，功能为识别图片上的文字）接口导入用例步骤中，启用了外部测试数据，
接着点击管理测试数据，跳转到测试数据tab： 在这个界面开始 新建/导入测试数据。此处数据集名称是给测试人员识别的，不会传入到接口里，一个数据集（1行）代表该次运行中所有需要传入的测试数据，列名作为接口参数，接口每次发起请求，会依次调用该列下的其中一个值。
运行时，每一条测试数据都会当成一条测试用例来运行。
在上面讲到的“接口参数传递”和“传入测试数据”两个的思路是一样的，依赖于apifox提供的参数化功能，上传的数据参数以外部数据集的形式与接口分隔开来，将关键字段，不断变化的数据抽取出来独立于单个接口；
配置完成之后，接口每次运行都能够自行生成，传递和导入关键数据，如果需要修改，只需要在一个地方，一个文件内批量修改就能够全局生效。 这其中有软件工程中的抽象和封装思想，而接下来会讲到的断言是另一种思路。
三. 测试断言
手工运行测试人员可以自行看接口请求是否成功，数据是否正常，但在自动化实践中，我们则需要代码帮我们判断实际返回和期望返回是否匹配。
http响应文本是高度结构化的，因此我们的期望返回无非是header和body中的响应状态码，关键字段，和关键值应该为某个值。只需要判断这些字段是否我们想要的即可。
断言是专门用来验证输出与期望是否匹配的工具，在测试实践中，我们一般通过比较实际输出值和输入值来校验的，即我们要判断返回数据“是否存在”“是否包含”“数据是否等于”“文本是否等于”。
因此判断用例请求结果的实现方案可分为三个要素：判断对象，校验方法，校验值与期待值。
思路明确了，接下来看如何用脚本/功能实现。Apifox的断言功能面板（路径：接口tab>运行>后置操作>断言）的可断言对象包括了响应数据中的JSON，html和xml，header，cookie，基本上可以满足我们的要求。
校验的方法为断言对象的值是否符合测试人员规定的值范围
被校验的值可通过json path 表达式提取
那么像对状态码的判断，某个确定返回值的校验这个，可以直接使用apifox提供的功能面板进行操作就行了。如果测试人员想要更加灵活的断言方式需要在后置操作里选择自定义脚本。
对于不太熟悉脚本的测试人员，可以使用Apifox右侧提供的代码模板，点击就会添加到左侧的脚本编辑面板里，基本上只需要修改断言的期望值就行了，难度不大。
如果是对单个接口做测试，断言结果会直接在响应tab返回
如果是批量测试，在测试结果里会显示断言结果：
这样我们构建接口自动化用例中的“结果判断”的问题就解决了。
四. 环境切换
接口在测试服测试通过之后还需要一轮线上验证，测试任务才算完成。
通常测试服和正式服的的区别只在于前置URL不同。为了让线上验证环节不耗费太多重复活动，我们这里可以在自动化项目开始构建的时候就先利用apifox提供的功能进行配置。 将项目里所有接口共用的http协议和域名配置到前置URL中，接口地址只填资源路径和参数。
进行线上验证时，将参数配置和数据配置同步更新/切换为线上数据配置之后，只需要在运行环境里切换环境，就可以进行线上验证。
五. 批量测试
1.用例组织形式 apifox里，用例是以测试用例--用例组--测试套件的形式组织的。 一个测试用例可容纳多个测试步骤，一个接口请求为一个步骤。 接口用例可直接从接口用例导入。如果设置和接口同步，那么接口一旦变更，测试用例这边也会同步变更。
一个常规用例步骤如下，涉及多个接口，接口之间存在参数传递，多个接口完成一个业务场景的测试。
接口用例导入完毕之后，进行测试参数配置，点击运行即可自动运行。
2.用例执行顺序
在一条测试用例里，接口请求的顺序由上到下依次执行，如果需要变更接口请求的步骤，只需要拖动接口移动到新的位置上去即可。
3.テストスイートは、インターフェイスのユースケースを実行して、ビジネスシナリオ/ビジネスプロセスのテストを完了します。テストスイートには複数のユースケースが含まれており、同じモジュールのユースケースを一緒に実行できます。このユースケース編成モードは、基本的に、テスターが一般的に使用するユースケース管理ソフトウェアtestlinkの編成方法と同じです。このように、クリックして実行する限り、ワンクリックでビジネスモジュールのインターフェイステストを完了することができます。
テストが完了すると、ユースケースのテスト結果が表示されます。上のパネルには全体的な実行ステータスが表示され、下のパネルには特定のユースケースの実行結果が表示されます。テストレポートをエクスポートする必要がある場合は、ボタンをクリックして、ワンクリックでhtml形式のファイルを生成します。
要約する
1.インターフェース自動化のツール思考とテスト思考
インターフェース自動化プロジェクトの構築と実行は、基本的にApifoxが提供する機能を中心に実行されます。郵便配達員と比較して、非常に使いやすいです。ユースケースの編成とテストの思考モードは、基本的にいくつかの大中規模の工場で使用されています。また、国内のテストグループのワークフローに準拠しています。チェンは、人に適応する人がツールに適応する代わりに、しきい値を理解し、切り替えを考えるコストが大幅に削減されます。
プロジェクトはずっと構築されており、基本的には機能的なインターフェースの操作です。スクリプトはほとんど必要ありません。スクリプトに慣れていないテスターは、スクリプトを使用して短時間でテストタスクをすばやく完了することができます。 。
このローカルインターフェイステストソフトウェアを使用して、これらの英語のテスト用語にあまり精通していない場合は、理解コストが低くなり、効率が高くなる可能性があります。
2.インターフェイス自動化プロジェクト全体で実行される3つの基本的なアイデア：
a。単一のインターフェイスのテストデータと変数がパラメーター化され、インターフェイスのテスト結果がアサート
されます。b。単一のインターフェイスのユースケースがビジネステストシナリオで構築されます。フレームワークとして、およびインターフェースの依存関係がパラメーターとインターフェースを介して渡される実行シーケンスソリューション
c。ユースケースの編成は、ビジネスモジュール、ビジネスプロセス、およびロジックをフレームワークとして持つテストグループとテストスイートに編成され、その後の反復と更新のメンテナンス
この記事では、APifoxを使用してインターフェース自動化テストを実行する具体的なプロセスとアイデアを紹介します。これがすべての人に役立つことを願っています。