QQグループ：529 063 263
GitHubの：https://github.com/yjlch1016/dapi
まず、インターフェイス関連のアイデア：
インタフェース試験において、
多くのシーンでは、
次のインタフェースへの参照としてインターフェイスを参照し、
即ち、次のデータインターフェースへの要求の結果に応じて、インターフェースの値、
内部のJMeterでは、
これは、協会と呼ばれています。
オンラインのオープンソースプロジェクトを読んで、
いくつかは、試験報告書、タイミングタスクに大きな長さを費やし、
しかし、これらは、セカンダリモジュールです
ないポイント、
インターフェイスのテストは、テストケース（基本的な流れ、代替フロー）を整理する方法に焦点を当てて、
どのようにインターフェース協会、それを明確にしないでください。
インターフェイスのパラメータの一部は、最初のパスを渡す必要があり、
次に、インターフェイスの裏に渡される前に、
インターフェイスが繰り返し実行される原因になりますそう、
それは友好的な解決策ではありません。
私の考えは、1対多の別々のテーブルを構築することである前に、
抽出されたデータを格納するための、
しかし、そうするためには、冗長データになります。
現在の慣行は、であるre.findall（、実際のインターフェースの結果を正規表現テンプレート）で抽出し、
グローバル変数として、
そして、置き換え抽出された値に正規表現を置き換える（旧、新新を）。
第二に、ページレイアウト：
図1は、インタフェースの送信後方側は、正規表現のパラメータ抽出（デフォルトでは開いていない）を開くために必要
変数名（軽視）を入力し、
正規表現を入力します（（+）のデータは約空いていない括弧やスペースの括弧内の一致を示します。）;？
2、動的インターフェイスに必要なパラメータは、メソッドの同じ種類が設けられている入力変数$ {名前}、これにJMetr内部あります。
第三に、質量参加の成功かどうかを確認します。
あなたは、応答コードを見ることができますし、実際の結果は、パラメータの値が成功を通過したことを示す、右です！