目次
4.1 Fiddler を使用して弱いネットワークをシミュレートする方法
4.4 Moments への Wechat 送信のテスト ケースの設計
1.テストケース要素（4つの重要要素）
テスト ケース (テスト ケース) は、テストを実装する目的でテスト対象のシステムに提供される一連のコレクションです.この一連のコレクションには、テスト環境、操作手順、テスト データ、期待される結果などが含まれます。
2.私たちにとってのテストケースの利点
1️⃣ テスト効率の向上とテスト時間の節約
2️⃣テストケースは自動化されたテストケースの前にあります
3.テストケースの設計方法
3.1 要件に基づくテスト ケースの設計
要件に基づいてテスト ケースを設計することは、テスト設計とテスト ケースの開発の基本です. 最初のステップは、テスト要件を分析し、要件が正しく、完全で、明確で、論理的に一貫性があるかどうかを検証することです. 正しい要件に基づいて、テスト要件を改良し、テスト要件から各テスト、各テスト ポイントに従ってテスト ケースを設計します。
例: WeChat アップグレード
朱肉の送付限度額：200元
WeChat での赤い封筒の受信制限時間: 24 時間
200元の金額は正常に送金できますか? 200元を超える金額でも正常に送金できますか?
テスト要件を分析する場合、一般的に機能テスト要件と非機能テスト要件に分けられます。
機能テストの要件:
機能テストでは、機能ブロック図を使用して、テストの要件を分析できます。要約すると、機能テストの要件には次のものが含まれ、通常は次の側面が含まれます。1 ) システムの各機能インターフェースの検証2) ビジネスを使用してテスト用の機能をつなぎ合わせる3) 機能整合性、双方向性（多機能相互運用性）試験４）システムの別入力、結果出力の業務データテスト。５）機能の誤作動、異常作動の検査（陰性検査に属する）6) 機能の実装に使用されるアルゴリズムの検証、場合によってはコード レビューを使用する必要があります7) ユーザー操作の使い やすさ 、ユーザー エクスペリエンス、多くの場合、機能テストと検証が同時に行われる特定のニーズに応じて、システムの機能は、ビジネス分類、ユーザーの役割 (レストランのメンバーシップ システム)、またはユーザーの操作領域に従って、いくつかの機能モジュールに分解できます。次に、機能モジュールに従ってテスト要件分析が実行されます。 . 機能モジュール区分によると、 ビジネスモジュール区分が 最も一般的です。
非機能テスト要件:
非機能テストの要件には、主に パフォーマンス 。テスト要件分析の観点から、各タイプの非機能特性テストは、要件に従って個別に分析する必要があります。それらの間には相互に影響があるかもしれません.例えば、セキュリティが高いほど、使いやすさやパフォーマンスに大きな課題をもたらす可能性が高くなります.
ここでは、要件に基づいてテスト ケースを設計する方法の例として、163 メールボックスを取り上げます。
3.2 特定の設計法の等価クラス
要件に従って、入力 (出力は特別な場合に考慮されます) をいくつかの同値クラスに分割し、同値クラスからテスト ケースを選択します.このテスト ケースがテストに合格した場合、表現された同値クラスと見なされますこれにより、より少ないテストケースで可能な限り多くの機能カバレッジを達成できるため、網羅的なテストを実行できないという問題が解決されます。
1️⃣有効な等価クラス:ユーザーのニーズの入力要件を満たすコレクション。
2️⃣無効な等価クラス:ユーザーの入力要件を満たしていないコレクション。
等価クラスの思考設計テスト ケースの手順
1️⃣ ニーズを完全に理解する
2️⃣有効な同値類の分割と無効な同値類の分割
3️⃣ 有効な等価クラスからデータの 1 つを抽出してテスト ケースを設計し、無効な等価クラスの 1 つを抽出してテスト ケースを設計する
例えば：
有効な等価クラス: 6~15 桁 無効な等価クラス: 6 桁未満 && 15 桁以上
3.2 境界値
境界値分析は、入力または出力の境界値をテストするためのブラック ボックス テスト手法です。通常、境界値分析法は同値類分割法を補完するものとして使用されますが、この場合、テストケースは同値類の境界に由来します。
境界値設計のテスト ケースの手順:
1️⃣ ニーズを完全に理解する
2️⃣境界点を見つける
3️⃣ 境界点のテスト ケースを設計する
境界点
上点：境界点
インライア: 境界内のポイント
開始点: 境界値に近い点 (閉区間の外側で上限点に最も近い点、開区間の上限点に最も近い点)
3.3 判定表
意思決定表は、論理的な判断を表現するためのもう 1 つのツールです。
- AND
条件がすべて真で、結果が真 条件の 1 つが偽で、結果が偽 - OR
条件の 1 つが true の場合、結果は true になります。すべての条件が false の場合、結果は false です。 - Not
条件が真、結果が偽 条件が偽、結果が真 - Identity
条件が true の場合、結果は true 条件が false の場合、結果は false
テスト ケースの設計方法:
1️⃣可能なすべての入力と出力を分析する
2️⃣入力と出力の対応を見つける
3️⃣設計決定表
4️⃣各テストケースに対応する決定表
例: ビジネス ドキュメントの処理ルールが次のとおりであるとします。
3.4直交表
✨2 つの重要な概念: factor: 入力変数 variable: 各入力変数の値
各数値は、各列に同じ回数表示されます。序数の各ペアは、任意の 2 つの列に同じ回数表示されます
3.4.1 直交表によるテストケースの設計方法
要件を完全に理解する ----> / 因子を決定する、レベルを決定する ----> 直交表を作成する ----> 直交表を補足する ----> 直交表をテストケースに変換する
ケース: 引き続き登録を例として取り上げます (同様のツールで Microsoft の PICT ツールを使用できます)。
要素: 名前、電子メール、パスワード、パスワードの確認、確認コード
レベル: 満たされた、満たされていない
allpairs 直交表を描く
1️⃣ 因子とレベルをエクセル表に入れる
2️⃣エクセルの表の内容を直接txtのテキストにコピーする
3️⃣CMDはallpairsのインストールパスの下に入ります
4️⃣ 直交表を生成する
この時点でのテスト ケース:
3.5 シナリオ設計法
現在のほとんどのソフトウェアは、イベント トリガーを使用してプロセスを制御します.イベントがトリガーされたときのシーンがシーンを形成し、同じイベントの異なるトリガーイベントのシーケンスと処理結果がイベント ストリームを形成します。このメソッドは、イベントがトリガーされたときの状況を鮮明に説明できます。これは、テスト デザイナーにとって有益です。テスト ケースを設計すると、テスト ケースの理解と実行が容易になります。典型的なアプリケーションは、ビジネス フローを使用して分離された機能ポイントをつなぎ合わせ、テスターに全体的なビジネス感覚を与え、機能に陥らないようにすることです。業務プロセスのポイントの詳細を無視して間違いを犯しがち
シナリオテスト方法によるテストケースの設計方法:
要件を完全に理解する ----> メイン イベント フローを決定する ----> セカンダリ イベント フローを決定する ----> 各イベント フローはテスト ケースです
例として、ATM を取り上げます。
3.6 エラー推測方法
エラー推測法は、テストされたソフトウェアの設計、過去の経験、および個人の直感を理解し、ソフトウェアの潜在的な欠陥を推測し、ターゲットを絞った方法でテスト ケースを設計する方法です。
この方法では、テスト対象のソフトウェアの要件、設計と実装の詳細、および個人的な経験と直感を理解することが重要です。
間違った推測方法は、現在人気のある「探索的テスト方法」の基本的な考え方と一致しています.このタイプの方法は、アジャイル開発モードでの入出力比が高く、テストで広く使用されています.
この方法の欠点は、システム化が難しく、個人の能力に頼りすぎることです。
登録を例に取ります1. 検証で特殊文字とスペースを処理する方法は?2. パスワードの確認はどのような場合ですか?3. 名前の特殊文字?4.パスワードがプレーンテキストで送信されているかどうか
4.過去のインタビューの質問
4.1 Fiddler を使用して弱いネットワークをシミュレートする方法
Fidder を開き、モバイル デバイスとノートブックの IP が同じネットワーク セグメントにあることを確認します。
1️⃣弱いネットワーク設定を開く
2️⃣ネットワークの伝送速度を確認します。
BeforeRequestを検索:
4.2 インターフェース試験
ページにはどのようなインターフェイスがありますか? F12を押すと、インターフェイスを直接見ることができます
1️⃣ブラウザを開き、直接 F12 を押します
2️⃣インターフェイスを右クリックしてコピーします
3️⃣Postman ソフトウェアを開き、インポートを開きます。
4️⃣ HTTP リクエスト メソッド、get、post、delete、パラメーターのテスト (すべてのパラメーターを渡す、いくつかのパラメーターを渡す、パラメーターを渡さない、他のパラメーターを渡す)
5️⃣ パフォーマンス:
4.3 カップテストケースの設計
4.4 Moments への Wechat 送信のテスト ケースの設計
