目次
2. ユースケースのカバー範囲を改善し、テストの欠落を減らす方法
3. ブラウザに URL を入力した後のリクエスト プロセスはどのようなものですか?
4. 一般的な HTTP リクエスト ヘッダー フィールドについて説明します。
8. プロジェクトのテスト中にどのような種類のバグが検出されましたか? 最もバグが発生しやすい場所はどこですか?
9. フィドラーの動作原理は何ですか? プロジェクトのテスト中に主にどのようなシナリオで使用されますか?
10. APPのエラーログを確認するにはどうすればよいですか?
11. Xiao Ming が Douyin の閲覧中にコメントを投稿しましたが、APP インターフェイスにコメントが表示されませんでした。この問題のトラブルシューティング方法は?
1. インターフェイスをデバッグできない場合、原因をトラブルシューティングするにはどうすればよいですか?
2. オンラインにした後にバグが発生した場合はどうすればよいですか?
3. テストの欠落によるオンラインのバグを経験したことがありますか? どのような状況で漏れが検出されるのでしょうか?
4. プロジェクトに単独で責任を負う場合、何に注意する必要がありますか?
5. 職場で開発者と効果的なコミュニケーションを維持するにはどうすればよいですか?
1. /home/demo.txt ファイルを誰でも読み書きできるように設定します。
2. a.log ファイルで、Exception とそれに続く 10 行を含むログを検索します。
3. mysql プロセスが正常に開始されるかどうかを確認します
4. /home ディレクトリで mysql.log の保存ディレクトリを検索します。
5. Linux サーバー上には、ユーザーのアクセス ログを記録するファイル a.log があります。
1 つの名前を使用して、アクセス頻度が最も高い上位 3 人のユーザーをカウントします
6. ポート 3306 が占有されているかどうかを確認するにはどうすればよいですか?
7. ユーザー zhangsan の昨日の操作ログを a.log で表示する方法
1. 合計人数が 4 人を超える部門番号と部門内の人数を列挙します。
3. 給与の高い上位 3 名の従業員番号と従業員名を表示します。
4. 給与が 1000 ～ 2000 の従業員全員の名前をリストアップします。
5. Tテーブルに以下のデータがあるため、テーブル内の重複する名前のデータを削除するSQLを記述します。
1. 一般的に使用されるインターフェース自動化ツール/フレームワークについて話しましょう
4. 要素を配置できない場合、通常どのような理由が考えられますか
2. TPS が比較的低いのですが、その理由は何でしょうか?
4. 圧力テスト中に TPS を押すことができません。考えられる原因は何ですか?
6. アプリケーションサーバーの高CPUとデータベースサーバーの高CPUの分析考え方は何ですか?
1. インターフェイスのテストを行う必要があるのはなぜですか?
4. インターフェイスのテストと Web ページのテストの違いは何ですか?
テストの基本
1. 要件定義書なしでテストを行う方法
1. 要件文書がないからといって、要件がないわけではありません。
2. 製品マネージャーや開発者などの関連担当者と通信して要件を取得できます。
3. 同じ業界の競合製品を参照して、ニーズを要約して整理できます。
4. 一部の機能要件は、ユーザーの使用習慣と業界の仕様に基づいて要約できます。
2. ユースケースの範囲を改善し、テストの見逃しを減らす方法
1. ユースケースは、各要件が対応するユースケースでカバーされていることを確認するために、要件文書に従って作成する必要があります。
2. ビジネスを完全に理解し、隠れたニーズを発見し、対応するユースケースを作成する
3. 通常のビジネス シナリオに加えて、より異常なシナリオとデータを考慮します。
4. 機能、パフォーマンス、セキュリティなどの側面を考慮して、ソフトウェアを多面的にテストします。
5. ユーザーの視点で課題を考え、ユーザーの利用シーンをシミュレーションする
6. ユースケースのレビューを整理する
3. ブラウザに URL を入力した後のリクエスト プロセスはどのようなものですか?
1. DNSドメイン名解決
2. サーバーとの TCP 接続を確立します。
3. HTTP リクエストを開始してデータを送信します
4. サーバーは HTTP リクエストに応答し、データを返します。
5. ブラウザがデータを解析してレンダリングする
6. 接続を閉じます
4. 一般的な HTTP リクエスト ヘッダー フィールドについて説明します。
5. テストケースにはどのような要素が含まれますか?
ユースケース番号、属するモジュール、ユースケースタイトル、前提条件、操作手順、優先度、期待される結果など。
6. バグのライフサイクルは何ですか?
1.新規: 新しいバグを送信し、修正のために開発者に割り当てます。
2.オープン: バグを確認し、修正が必要であると考え、対応する開発者に割り当てます。
3.修正済み: 開発者が変更すると、修正済み状態としてマークされ、テスターの回帰テストによって検証する必要があります。
4.拒否: バグとみなされない場合、変更は拒否されます。
5.クローズド: バグの修正ステータスがテスターの回帰テストによって検証された場合、バグはクローズされます。
6.再オープン: 検証されたバグがまだ存在する場合、バグを再オープンする必要があり、開発者は再度修正することができます
。
7. プロジェクトのテストプロセスを書き留める
要件レビュー、テスト計画、技術レビュー、ユースケース作成、ユースケースレビュー、テスト実行、テストレポート、オンライン検証
証明書、プロジェクト概要
8. プロジェクトのテスト中にどのような種類のバグが検出されましたか? バグが最も発生しやすい場所はどこですか?
バグの種類: 主にコードロジックエラーと構成エラー
バグが発生しやすい場所: パラメーターの検証、境界条件、複雑なロジック、および一部の異常なシナリオは考慮されていません。
包括的な
9. フィドラーはどのように機能しますか? プロジェクトのテスト中に主にどのようなシナリオで使用されますか?
動作原理: fiddler は主にクライアントとサーバー間のプロキシとして機能します。fiddler を起動した後、
すべてのリクエストと応答は fiddler を経由します。
アプリケーションシナリオ:
1> フロントエンドとバックエンドのバグを特定する
2> データ分析のためにパケットをキャプチャする
3> ブレークポイントをリクエストします。主に、購入されたチケットの数など、クライアントによって送信された不正なデータをサーバーが検証するかどうかをテストします。
金額は 0、無効なアクティビティ時間などです。
4> ブレークポイントに応答します。
ブレークポイントのリクエスト: 主に、クライアントによって送信された不正なデータをサーバーが検証するかどうかをテストします。たとえば、購入されたチケットの数は次のとおりです。
0、無効なアクティビティ時間など。
応答ブレークポイント: 主に、サーバーが異常なデータを返した後のクライアントの処理方法をテストします。たとえば、サーバーは 500 を返します。
またはその他の異常なビジネス データ
5> 弱いネットワーク テスト。フィドラーで組み込みのネットワーク遅延時間を変更できます。デフォルトはアップロードで 300 ミリ秒、ダウンロードで 150 ミリ秒です。
これら 2 つの値が大きいほど、ネットワーク速度は低くなります。
10. APPのエラーログを表示するにはどうすればよいですか?
a. APP パッケージ名を確認します。
b. 登録を通じてAPPプロセス番号を確認します
c. adb logcat のエラー ログをプロセス番号でフィルタリングします。
11. Xiaoming が Douyin の使用中にコメントを投稿しましたが、APP インターフェイスが表示されません。この問題のトラブルシューティング方法を教えてください。
1.クライアントネットワークに問題があるかどうかを確認し、他のAPPが正常に使用できるかどうかを確認できます
2. バージョンに問題があるかどうかを確認し、オペレーティング システム (Android、iOS) を変更するか、別のソフトウェア バージョンを試してください。
3. 互換性の問題かどうかを確認し、別の携帯電話を試してみます。
4. パケット キャプチャ分析: APP がサーバーにリクエストを送信しない場合、またはリクエスト パラメーターが正しい場合は、APP に問題があります。
質問: サーバーの応答データが間違っている場合、それはサーバー側の問題です。
シナリオに関する質問
1. インターフェイスを調整できません。原因をトラブルシューティングするにはどうすればよいですか?
リクエストは失敗します。考えられる理由は次のとおりです。
- IP、ポート番号、または URL が間違っています
- クライアントとサーバー間のネットワークが接続されていない
- サーバー側プロジェクトがまったくデプロイされていない
- サーバーのファイアウォールがブロックしました
- サーバープログラム内でエラーが発生しました
- アクセス権がない（トークン、Cookie がないなど）
- クライアントにはネットワーク プロキシが設定されています
・ブラウザからアクセスした場合、正しくバインドされていませんか？
2.オンラインにした後にバグが発生した場合はどうすればよいですか?
これまでの経験に基づいて、私たちはまず開発チームと協力してバグの重大度と原因を最初に評価します。
比較的大きな影響を与える機能上の問題があり、当面は特定の原因を特定することが難しい場合は、最初にコードの回復を検討します。
ロールして、最後の安定したバージョンに戻します。次に、テスト環境で再テストし、問題の原因を特定します。
問題の原因がすぐに特定できれば、テスト合格後に開発チームが応急修理を行い、オンラインで緊急申請を行う。
パフォーマンスの問題の場合は、通常、問題を解決するために拡張または再起動され、その後開発でさらに問題の特定が行われます。
ビットサムの最適化。
問題がそれほど深刻でない場合は、通常は次のバージョンで解決されます。
最後に、オンラインのバグが解決された後、問題を確認し、プロセス全体を記録し、将来の問題を回避するために関連する分析と要約を実施します。
同様の問題は引き続き発生しています。
3.テストの欠落によるオンラインのバグを経験したことがありますか? どのような状況でテストの欠落が発生しますか?
基本的に、私がテストしたところ、P0 および P1 レベルにはバグはありませんでした。
時々小さな問題が発生することがありますが、主な理由は次のとおりです。
それはすべて互換性に関するものだからです。特に Android スマートフォンの場合、その断片化は深刻すぎます。
次に、主に、よくあるテストのバグの原因について説明します
。
⚫
要件仕様が不明確なため、テストケースを大雑把に書きすぎてしまう。
⚫
要件仕様が変更され、テストケースの更新が間に合わなかった
⚫テスト
ケースの範囲が包括的ではなく、シナリオが省略されている
⚫
テストプロセス中にテストケースに厳密に従わなかった場合
⚫
テスト時間が不十分なため、テストプロセス中にいくつかの機能ポイントが無視されました。
⚫
テスト環境やテストデータが限られているため、欠陥が見逃される
⚫
他のバグを修正する際に開発者によって導入された新しいバグ
4.あなたがプロジェクトに単独で責任を負う場合、何に注意する必要がありますか?
1. プロジェクトのテスト範囲とテストサイクル、および単独で完了できるかどうかを評価します。
2. 適切なテスト戦略と計画を立て、各リンクが時間通りに完了するように努めます
3. 自分で問題を解決できない場合は、すぐに問題を放棄し、リスクを明らかにし、助けを求めるべきです。
4. テスト効率を向上させるために、いくつかの技術的手段を使用してみます。
5. ユースケースに優先順位を設定し、優先順位に従って実行します。
6. タイムリーにバグを追跡し、できるだけ早くバグを解決するために開発を促進します。
7. 打ち上げ基準を管理し、試験報告書に打ち上げリスクを示す
5.職場で開発者と効果的なコミュニケーションを維持するにはどうすればよいですか?
1. 開発者とのコミュニケーションでは感情を持たず、ありのままに議論し、客観的かつ誠実にコミュニケーションする
2. 開発に頼りすぎず、問題が発生した場合はまず自分で分析し、基本的な判断ができたら開発者に相談します。
3. 現在何をしているか、どのような問題に遭遇したか、どのような開発が必要かなど、問題を簡潔かつ明確に説明します。
ヘルプ
4. 試験にはそれぞれの主義や立場があり、自分が正しいと思うことが正しいと考え、毅然とした態度で判断しなければなりません。
クアン・ティンシンの開発
5. 開発作業の頻繁な中断につながる可能性のあるコミュニケーションの断片化を避けるために、問題については可能な限り集中的な方法で伝達します。
6. 技術的能力と認知力を向上させ、より専門的な言語を使用して開発者とコミュニケーションをとる
7. 伝えることが非常に難しい展開に遭遇した場合、必要に応じてタイムリーにフィードバックを送り、助けを求める
リナックス
1. /home/demo.txt ファイルを誰でも読み書きできるように設定します。
chmod 666 /home/demo.txt
2. a.log ファイル内で Exception と次の 10 行を含むログを検索します。
grep -A 10 「例外」 a.log
3. mysqlプロセスが正常に開始されたかどうかを確認します
ps -ef | grep mysql
4. /home ディレクトリで mysql.log の保存ディレクトリを検索します。
/home -name mysql.log を見つけます
5. Linux サーバー上には、ユーザーのアクセス ログを記録するファイル a.log があります。
1 つの名前を使用して、アクセス頻度が最も高い上位 3 人のユーザーをカウントします
2022-07-04 11:11:11 張山 /index.html 192.168.2.2
2022-07-04 12:11:12 リシ /ログイン 192.168.2.2
2022-07-05 16:11:13 張三 /ショップ/購入 192.168.2.2
2022-07-06 09:11:18 ジャック /カート/ゴー 192.168.2.2
回答案：awk '{print $3}' a.log | 並べ替え | ユニック -c | ソート -rn | 頭-3
6. ポート 3306 が占有されているかどうかを確認するにはどうすればよいですか?
netstat -anp | グリップ 3306
または
lsof -i 3306
7. zhangsan ユーザーの昨日の操作ログを a.log で確認する方法
grep 'zhangsan' a.log | grep '昨日の日付'
8. ファイアウォールをオフにするコマンドは何ですか?
systemctl ファイアウォールを停止します
9. ログ内の例外の数を数える方法
grep '例外' a.log | トイレ -l
10. 一般的に使用される Linux コマンド
pwd は作業パスを示します
shutdown -h now システムをシャットダウンします。 /halt システムをシャットダウンします。
shutdown -r 今すぐ再起動/再起動再起動
systemctl stop firewalld ファイアウォールを閉じる
ip addr IP アドレスを表示
SQLの質問
部門テーブル部門 (dept_id、dept_name)
従業員テーブル従業員 (emp_id、emp_name、性別、dept_id、jobs)
給与テーブル給与 (salary_id、emp_id、money)
1.部門番号と部門内の合計数が4 人を超える人数をリストします。
従業員から dept_id、count(*) を選択し、count(*)>4 を持つ dept_id でグループ化します。
2. 開発部門とテスト部門の従業員番号と名前を列挙します。
e.emp_id、d.emp_nameを選択します
従業員からの内部結合部門 d on e.dept_id = d.dept_id
ここで、d.dept_name は ('開発部門'、'テスト部門')
3.給与の高い上位3 名の従業員番号と名前を表示します。
e.emp_id、e.emp_name、s.moneyを選択します
給与の内部結合従業員 e から s.emp_id = e.emp_id
s.money デスクで注文
限界3
4.給与
e.従業員名、s.給与を選択
給料から
内部結合従業員 e on s.empid = e.empid
ここで、s.salary は 1000 ～ 2000 の間です。
5. Tテーブルに以下のデータがあるので、テーブル内の重複した名前のデータを削除するSQLを書く
| ID | 名前 | 年齢 | 市 |
1、張三、18、北京
2、リー・シー、35、上海
3、張三、20、南京
4、ワン・ウー、31、天津
回答案：ID が含まれていない T から削除します (T グループから名前で max(id) を選択します)
オートメーション
1. 一般的に使用されるインターフェイス自動化ツール/フレームワークについて話しましょう
ジェイメーター、郵便配達員
リクエスト、pytest、unitest、HTTPClient、testNG、Junit
2. 自動スクリプトの安定性を向上させる方法
a. 固定データの使用は避け、テストケースで使用されている古いテストデータは、他人によって変更または削除される可能性があります。
したがって、スクリプトを実行する前に毎回、スクリプト内で新しいデータが構築され、スクリプトの実行後にデータが消去されます。
b. ユース ケース間の結合を減らします。各ユース ケースの完全なプロセスに従うようにしてください。回避するために他のユース ケースに依存しないでください。
これにより、他のユースケースが失敗して後続のユースケースに影響を与えるのを防ぎます。
c. 依存環境の安定性の向上 通常、一部のユースケースはサードパーティ システムの環境に依存します。
不安定な場合は、ユースケースの実行が不安定になります。モックを使用してサードパーティ環境を保護し、改善することができます。
環境の安定性を向上させます。
d. スクリプトでの例外処理については、スクリプト内でより多くの例外を考慮し、各例外に対応する応答を用意するようにしてください。
失敗後のプログラム終了を回避する処理方法
3. pytest でケースを組み立てる方法
1) デフォルトでは、test_ .py または **test.py という名前のファイル名がチェックされ、test で始まるファイル名がファイル内で検索されます。
メソッドまたは関数を実行して実行する
2) カスタム マーカー (デコレータ) を使用できます。たとえば、pytest が実行されている場合、このマーカーを持つマーカーのみが実行されます。
テストケース
3) pytest.ini 設定ファイルでは、pytest が実行される場合、たとえば特定のターゲットを実行する場合に対処できます。
記録されたユースケース、スクリプトファイルの実行など。
4. 要素を配置できない場合、通常どのような理由が考えられますか
1) 間違ったロケーターの選択
2) 文字列の位置決めエラー
3) 要素がフレーム内にネストされている
4) ページ要素が時間内にロードされない
5) 新しいウィンドウの要素
6) 脚本のプロセスが現実と一致しない
7) 要素は現在のページにありません
パフォーマンス
1. パフォーマンス テストの一般的な指標は何ですか?
a) tps: システムの処理能力を表す 1 秒あたりのトランザクション数 tps が高いほど、パフォーマンスが向上します。
b) 応答時間: リクエストを発行してからシステムの応答データを受信するまでにかかる時間で、応答時間が短いほどパフォーマンスが高くなります。
よりいい
c) スループット: ネットワーク上のアップストリーム トラフィックとダウンストリーム トラフィックの合計スループットは、ネットワークのボトルネックを特定するための重要な指標です。
d) エラー率: ストレス テスト プロセス中のシステム エラーの割合
e) オペレーティング システム: CPU、メモリ、ネットワーク、ディスク
2. TPS が比較的低いのですが、その理由は何でしょうか?
a) 印刷機自体のパフォーマンスのボトルネック
b) ネットワーク IO ボトルネック
c) ミドルウェア (tomcat/nginx/mysql) の接続制限
b) アプリケーション: メモリ、スレッドのブロック、待機
e) データベースのパフォーマンスの問題
f) このシステムのリソース (CPU、メモリ、ディスク、ネットワークなど) のボトルネック
g) 他の外部システムの応答時間が長すぎるため、このシステムの待ち時間が発生します。
3.自動テストの安定性を確保する方法
1. 固定データの使用を避ける テストケースで使用されている古いテストデータは、他人によって変更または削除される可能性があります。それで
各スクリプトが実行される前に、スクリプト内で新しいデータが構築され、スクリプトの終了後にデータが消去されます。
2. ユース ケース間の結合を減らします。各ユース ケースの完全なプロセスに従うようにしてください。他のユース ケースを回避するために他のユース ケースに依存しないでください。
他のユースケースの実行が失敗し、後続のユースケースに影響を与えました。
3. 依存環境の安定性の向上通常、一部のユースケースはサードパーティ システムの環境に依存します。サードパーティ環境が不安定な場合は、
修正しないと、ユースケースの実行が不安定になります。モックを使用すると、サードパーティ環境を保護し、環境の安定性を向上させることができます。
定性。
4. スクリプトでの例外処理については、スクリプト内でより多くの例外を考慮し、それに応じて各例外を処理するようにしてください。
失敗後のプログラム終了を回避する方法
4.耐圧テスト中に TPS を押すことができません。考えられる原因は何ですか?
a) 印刷機自体のパフォーマンスのボトルネック
b) ネットワーク IO ボトルネック
c) ミドルウェア (tomcat/nginx/mysql) の接続制限
b) スレッドのブロックと待機
e) データベースのパフォーマンスの問題
f) システムリソース (CPU、メモリ、ディスク、ネットワークなど) のボトルネック
g) 他の外部システムの応答時間が長すぎるため、このシステムの待ち時間が発生します。
5. パフォーマンス テスト シナリオの設計方法
一般的な基本シナリオには、ベンチマーク テスト、単一トランザクション テスト、混合テスト、安定性テストが含まれます。
ベンチマーク テストでは、1 ユーザーまたはベンチマーク ユーザー数を使用して
1 つのシナリオ テストを数分間実行し、同時ユーザー数が徐々に増加して推定値に達したら 10 分間実行します。
混合シナリオのテスト。さまざまなトランザクション設定と同時ユーザーの割合を変えて 30 分間実行します。
安定性テスト。最大同時ユーザー数の 80% をサポートする混合テストを選択し、12 時間実行します。
6. アプリケーションサーバーの高CPUとデータベースサーバーの高CPUの分析アイデアは何ですか?
1) アプリケーションサーバーの CPU が高く、まず TPS と応答時間に依存します。TPS が比較的高い場合は、通常の CPU であると考えられます。
消費量: tps が比較的低い場合、一部のコードは CPU を過剰に消費することが多いため、コード分析ツールの使用を検討できます。
分析する
2) データベース サーバーの CPU が高い。多くの場合、SQL ステートメントの実行効率が比較的低いためです。これは、データベースへのクエリが遅いことで実現できます。
実行計画と組み合わせて監視し、該当テーブルにインデックスが存在しないか、インデックスが有効になっていないかを分析します。
インターフェース
1. インターフェイスのテストを行う必要があるのはなぜですか?
A. 企業では、通常、クライアントとサーバーは別のチームによって開発されます。プロジェクト開発プロセスでは、クライアント
サーバサイドとサーバサイドの開発進捗が一致しない（例えば、サーバサイドの開発が先に行われる）このとき、サーバサイドを先に開発してもよい。
インターフェースのテストでサーバー側のロジックと戻りデータが正しいことを確認してから、クライアントをテストします。また、一部の試験部門では
このチームはサーバー側開発チームのテストを専門としているため、テスト オブジェクトはインターフェイスです。
B. 特定のサービスをテストする場合、ユーザー登録などのフロントエンドだけを介してテストすることはできません。フロントエンドはユーザー名を制限します。
空にすることはできませんが、ツールを使用してフロントエンドをバイパスし、サーバー インターフェイスを直接呼び出す人もいます。
関連する論理的判断により、データ エラーが発生します。インターフェースデータ送信中にキー情報が暗号化されるかどうかを含みます。
したがって、サーバー インターフェイスは個別にテストする必要があります。
Ｃ、
開発とテストの後、最初にツールを使用してサーバー側のインターフェイス テストを実行し、インターフェイスのテスト ケースがすべて適切であることを確認します。
合格した場合は、サーバー インターフェイスが期待を満たしているかどうかをすぐに判断できます。次に、UI インターフェイスを通じてテストします。それ以外の場合は受け入れる
フロントエンド ページにバグがある場合は、フロントエンド ページにもバグがあるはずです。
2. インターフェーステストの焦点は何ですか?
1) パラメータの正当性、パラメータの検証、パラメータの境界、空のパラメータ、欠落しているパラメータなどを含む入力パラメータ。
2) 各種状況下での応答内容が正常かどうかを含む戻り値
3) インターフェースのビジネスロジックや機能は正常か
4) データベースの検証
5) パフォーマンステスト (インターフェイス tps、応答時間など)
6) セキュリティ、機密情報の暗号化、権限制御など
7) 冪等性
3. get と post の違いは何ですか?
1) get リクエストのパラメータは URL に配置され、post リクエストのパラメータはリクエスト本文に配置されます
2) get リクエストはブラウザによってキャッシュできますが、post リクエストはキャッシュできません。
3) get リクエストのパラメータは URL 内に配置され、URL の長さには制限がありますが、post インターフェイスの長さには制限がありません。
4) get リクエストのパラメータは URL に配置されるため安全性が低く、post リクエストのパラメータは本文に配置されますが、これは安全性が低くなります。
した方が良い
5) get リクエストにはブラウザから直接アクセスでき、リフレッシュとバックがサポートされています。投稿リクエストでは参照を直接使用できません。
サーバーにアクセスした後は、データを更新してから再送信する必要があります。
4. インターフェイスのテストと Web ページのテストの違いは何ですか?
1) Web ページのテストはインターフェイス操作を通じて実行され、さまざまなデータを入力することでさまざまなシナリオがテストされます。
2) インターフェイスのテストでは、ツールを使用してテストのために HTTP リクエストをサーバーに直接送信し、さまざまなパラメーターを入力してさまざまなテストを行います。
シーン。
3) 通常、Web ページでは、必須項目やデータ形式など、特定の入力データが制限されています。インターフェーステストが可能
任意のデータを入力することで、より多くの異常なデータ シナリオをテストできます。
4) Web テストではブラウザの互換性を考慮する必要がありますが、インターフェイスのテストでは考慮されません
5) Web テストでは、テストを実行する前にフロントエンドとサーバーが完全に開発されている必要がありますが、インターフェイスのテストではサーバーを起動するだけで済みます。
リリースが完了したら、テストを開始できます