ソフトウェアテストのまとめ

ソフトウェアテストについて知っておくべきこと

ソフトウェアテストのライフサイクル

要件分析 —> テスト計画 —> テスト設計、テスト開発 —> テスト実行 —> テスト評価

バグレベル

1. ブロッカー (クラッシュ)
   は、システムのクラッシュ、クラッシュ、無限ループ、データベースの損失、データベース接続エラーなどを引き起こします。
2. 主要なシステム機能の重大な (重大な)
   損失、データベースの保存および呼び出しエラー、ユーザー データの損失など。ただし、テストの他の機能には影響しません。
3. 主要な（一般的な）
   機能は完全には実装されていませんが、長い操作時間、長いクエリ時間など、使用には影響しません。
4. マイナー (二次)
   インターフェース設計、パフォーマンスの欠陥、勧告の問題

バグのライフサイクル

• new : 新しく発見されたバグ。レビューされ、変更のために開発者に割り当てられることが決定されました
• オープン: バグであることが確認されており、修正して該当する開発者に割り当てる必要があると考えられます
• 拒否: バグではないと見なされる場合は、変更を拒否します
• delay: 一時的に変更する必要がない、または一時的に変更できないと判断された場合、変更を遅らせます。
• fixed: 開発者が修正した後、修正された状態になり、テスターが回帰テストを実行します
• クローズ: 状態を変更するバグは、テスターに​​よる回帰テストに合格し、バグはクローズされます。
• 再オープン: 回帰テストでバグがまだ存在することが確認された場合、バグを再オープンする必要があり、開発者は再修正できます。

開発者との紛争を解決する方法

1. まず、バグの説明が十分に正確でないかどうか、およびバグの分類が正確かどうかを確認してください
2. ユーザーの観点から、開発者はバグによって起こりうる悪影響を理解しようとします。
3. コミュニケーションを何度も繰り返しても開発者がそれを受け入れない場合は、バグ レビューを開始して、
   バグの対処方法を決定し
   、欠陥の原因を分析し、防止戦略を見つけることができます。

アジャイル開発プロセス

アジャイル開発にはさまざまな種類がありますが、その中でもスクラムが人気があります

• まず、プロダクト マネージャーはユーザー ストーリー (ユーザー ストーリー) を整理して、左側のプロダクト バックログ (プロダクトの To Do アイテム) を形成します。
• リリース計画会議: プロダクト オーナー (プロダクト マネージャー) は、ユーザー ストーリーの説明、評価、分類を担当します. リリース計画会議のアウトプットは、最初のイテレーションで完了するストーリーのリスト、Spring バックログを策定することです.
• 反復計画会議: プロジェクト チームは、各ストーリーのタスクを分解します. 分解基準は、このストーリーのすべてのタスクを完了することです. 各タスクには明確なリーダーがいて、工数の初期評価を完了します.
• 日次会議：スクラムマスター（プロジェクトマネージャー）が毎日定例会議を招集し、チームメンバーは昨日のタスク完了、今日の計画、発生した問題を報告します
• デモンストレーション ミーティング: イテレーションが終了した後、デモンストレーション ミーティングが開催され、すべての関係者が参加するように招待されます. チームは、このイテレーションの結果を全員に示す責任があります. この期間中、全員のフィードバック記録が記録されます,プロダクトオーナーはそれらを整理して新しいストーリーを形成します
• レビュー会議: プロジェクト チームは、現在のイテレーションを要約し、欠陥を見つけ、改善計画を策定し、次のイテレーションで改善を続けます。

V型とW型

V モデルの

制限: コーディング後の段階としてのみテストを使用し、必要な段階でテストに入らないでください。

Wモデルの

特徴：開発とテストが並行して行われるため、問題の早期発見につながります

テストケース

テストケースは、テスト環境、操作手順、テストデータ、期待される結果などを含む、テストを実装する目的でテスト中のシステムに提供される一連のコレクションです。

テスト ケースの設計方法

• 等価クラス: 要件に従って、入力をいくつかの等価クラスに分割します

需要: スーパーで果物を買う
有効な同等クラス: リンゴ、モモ、ナシ
無効な同等クラス: 野菜、米、衣服

• 境界値: 入力と出力の境界値をテストします

1. 入力ボックスの長さは 1 ～ 11 で、境界値は 0、1、11、12 です。
2. 選手のエントリーは1～3項目、境界値は0項目、1項目、3項目、4項目
3. クエリ ページは 999 行あり、50 行ごとに 1 ページであり、境界値が取得されます: 出力 0 行、1 行、50 行、51 行、999 行、1000 行

• 因果図：プログラムの入力条件と出力アクションの相互関係を示します
  アイデンティティ：
  
  入力が真であれば、出力も真です

AND:

両方の入力が true の場合、出力は true

または:

入力の 1 つが true の場合、出力は true

否定:

入力が false の場合にのみ、出力が true になります。

ケース:
ビジネス ドキュメントの処理ルールが次のとおりであると仮定します。

1. このビジネス ルールでは、まず、可能なすべてのデータと可能な出力を分析することによって、次の結果が得られます
   。
   
2. 2番目のステップを実行して、入力と出力の対応関係を見つけます.分析を通じて、次の対応関係がわかりました.
   (1)注文が送信され、注文金額が300元を超え、封筒、割引
   (2) 注文が送信された場合、注文 金額が 300 元を超える場合、赤い封筒がない場合、割引が適用されます
   (3) 注文が送信された場合、注文が送信されます金額が
   300元以下の場合、赤い封筒がある場合は割引があります
   ）注文が提出されていない場合、割引はありません
3. 因果関係図と判定表を便利に描くために、すべての入力番号と出力番号に番号を付ける必要があります
   c1: 注文が送信されました
   c2: 注文金額が 300 元を超えて
   います c3: 赤い封筒があります
   e1: 割引
   e2:値下げなし
4. 因果図を描く
   
5. 判定表を描く：条件は3つ、出力は2つの値を持つので、表の列数は2×2×2=8
   
   最終テストケース1、2、3、4、5
   （6、7を含む） 、8)

• 直交配置
• シナリオ設計: テスト ケースを設計するための要件のシナリオを想像します。
• エラー推測方法: 直感に基づいて考えられるエラーを見つけ、的を絞った方法でテスト ケースを設計します。

テストの分類

開発段階別

1. 単体テスト
   テスト段階：コーディング後またはコーディング前
   テスト対象：最小モジュール
   テスト方法：ホワイトボックステスト テスト
   内容：モジュールインターフェーステスト、ローカルデータ構造テスト、パステスト、エラーハンドリングテスト、境界テスト

2. 統合テスト
   テストフェーズ: 単体テスト後
   テストオブジェクト: モジュール間のインターフェース
   テスト方法: ブラックボックステスト + ホワイトボックス
   テスト テスト内容: モジュール間のデータ転送、モジュール間の競合、モジュール アセンブリ関数の正確性、グローバル データ構造

3. システムテスト
   テスト段階：統合テスト後
   テスト対象：システム全体
   テスト方法：ブラックボックス
   テスト テスト内容：機能、インターフェース、信頼性、ユーザビリティ、性能、互換性、セキュリティなど

4. 回帰テスト
   回帰テストとは、コードが変更された後に再テストを行い、変更後に新しいエラーが導入されていないことを確認することです。

5. スモークテスト
   通常、開発者が開発完了後にテスターをテストする場合、テスターは最初にスモークテストを行います.スモークテストとは、製品を動作させ、正常に起動できるかどうかをテストすることです.

6. 受け入れテスト
   製品の準備ができていることを確認するテストの最終段階 テスト フェーズ
   : システム テストの後
   テスト対象: システム全体 テスト
   方法: ブラック ボックス テスト
   テスト内容: 機能、インターフェイス、信頼性、使いやすさ、パフォーマンス、互換性、セキュリティ

試験実施要領による

1. アルファ テスト
   アルファ テストは、開発環境でユーザーが実行するテストです。

2. ベータ テスト
   ベータ テストとは、ソフトウェアのエンド ユーザーが 1 つ以上の場所でテストすることです。

アルファ版テストとベータ版テストの違い:

• さまざまなテスト サイト: α テストは、ユーザーがテストのために開発者に招待されるサイトを指し、β テストは、さまざまなサイトでテストする 1 人以上のユーザーです。
• アルファテストの環境は開発者によって制御され、ユーザー数が少なく、時間が集中します; ベータテストの環境は開発者によって制御されません
• アルファ テストはベータ テストに先立つ

3. 第三者によるテスト
   開発者とユーザーの間の第三者によるテスト

走っているかどうかによる

1. 静的テストとは、
   テスト対象のプログラムを実行せずに、ソースプログラムの構文、構造、プロセスなどを分析して、プログラムの正しさを確認することを指します.コードの
   静的分析とドキュメントのテストは、両方とも静的テストです.
2. 動的テストとは、
   プログラムを実行して実行結果と期待される結果の違いを確認し、実行効率と正確性を分析することを指します

手動分類かどうかによると

1. 手動テスト
   テストケースを一つ一つ手動で入力し、結果を観察する
   メリット：考え方がバラバラ デメリット：実行効率が遅い

2. 自動化されたテストは
   、人間主導のテスト動作を機械実行に変換する単純なプロセスです

自動テスト手順:

1. 完全な機能テスト、バージョンは基本的に安定しています
2. プロジェクトの特性に応じて、適切なプロジェクト用の自動テスト ツールを選択し、環境を構築します。
3. 手動テストからテスト ケースを抽出し、自動テスト ケースに変換する
4. ツールとコードによる自動建設入力を実現し、出力結果が期待どおりかどうかを自動的に検出します
5. 自動テスト レポートの生成
6. 継続的な改善、スクリプトの最適化

コードを表示するかどうかによる

1. ソフトウェアテストとも呼ばれるブラックボックステストは
   、テスト対象のソフトウェアをブラックボックスとして扱い、内部構造は気にせず、ソフトウェアの入出力データのみを気にします
2. ホワイトボックステスト
   コードベースのテストでは、ボックスを開き、コードと実行結果を調べる必要があります
3. グレーボックステストは
   、ホワイトボックステストとブラックボックステストの間のテストであり、主に統合テスト段階で使用され、入力と出力の正確性だけでなく、プログラムの内部状態にも注意を払います。

セレン

セレンツールセット

selenium 1 (環境キリング): seleniumRC (webdriver に置き換え)、seleniumIDE (自動テスト スクリプトの記録)、selenium GRID (配布)

セレン2：webdriver(Google)

Selenium 3: 一部のブラウザー、safari (Apple)、edge (Microsoft) 用のネイティブ ドライバーを追加

ウェブドライバー

原理

ブラウザはタクシーに相当し、webdriver はドライバーに相当し、スクリプトは乗客に相当します。

スクリプト (パッセンジャー) は命令を Web ドライバー (ドライバー) に伝え、Web ドライバー (ドライバー) はブラウザーを駆動して、命令に従ってスクリプト コマンド (ドライブ) を実行します。

よくある質問

単体テスト、統合テスト、システムテスト、受け入れテスト、回帰テストのうち、最も重要なステップを答えてください

これらのテスト手順は、ソフトウェア開発のさまざまな段階でソフトウェアをテストします. ソフトウェアの完全な機能をテストするシステム テストは非常に重要であると思います.システムのすべてのジョイント コンポーネントは、システムが要件仕様の定義をグローバルに満たしているかどうかを検証できるため、システム テストは非常に重要です。

統合テストとシステム テストの違いとその適用シナリオに答える

違い:
1. ユースケースの設計の順序が異なります: w モデルの観点からすると、一般にシステムテスト計画のユースケースが最初に設計され、次に統合テストが設計されます. システムテストケースはより詳細であり
、 3.実行順序が異なり
、最初に結合テストを実行し、結合テストの問題がすべて修正された後にシステム テストを実行します。

アプリケーション シナリオ
統合テスト: 単体テストが完了した後、各モジュールの共同デバッグ テストでは、モジュール間で接続されたインターフェイスが一貫しているかどうか、モジュール間のデータ フローと制御フローが設計どおりに機能を実現しているかどうかに焦点を当てます。結果の正確性検証などは、製品全体の統合テスト、または結合された大きなモジュールの統合テストであり、統合テストは主にプログラムの内部構造、特にプログラム モジュール間のインターフェイスをテストします。テスト方法はブラックボックスとホワイトボックスが一般的 ボックステスト併用
**システムテスト**：各モジュールの検証テストと機能テストを含み、堅牢性、セキュリティ、保守性も含めた製品全体の包括的なテスト製品パラメータテスト全体のさまざまなパフォーマンス。システムテストは「要求仕様」の基準に厳密に従う必要があり、通常はブラックボックステストを使用します

ブラックボックステストとホワイトボックステストにはどのような方法がありますか?

ブラックボックステストの方法には、等価クラス分割、境界値分析、エラー推測、因果図法が含まれます

ホワイト ボックス テストの方法には、ロジック カバレッジ、プログラム インスツルメンテーション、基本パス、シンボリック テスト、エラー ドリブン テストが含まれます。

ブラックボックスとホワイトボックスのテスト方法について教えてください

ブラック ボックス テスト:
内部の論理構造に関係なく、主にプログラムの外部構造に焦点を当て、ソフトウェア インターフェイスとソフトウェア機能をテストします。「ブラックボックス」方式は網羅的な入力テストであり、可能なすべての入力がテストケースとして使用された場合にのみ、この方法でプログラムのすべてのエラーを見つけることができます。テスト ケースでは、すべての有効な入力をテストするだけでなく、有効ではないが可能性のある入力状況もテストする必要があります。

よく使われるブラックボックステスト法：等価クラス分割法、境界値分析法、因果図法、シナリオ法、直交実験計画法、決定表駆動分析法、誤差推測法、関数図分析法

ホワイト ボックス テスト:
構造テストまたはロジック駆動型テストとも呼ばれ、テスト対象のユニットが内部でどのように機能するかをテストします。プログラムの制御構造に従ってテストケースを設計し、主にソフトウェアやプログラムの検証に使用されます. ホワイトボックステスト法は、プログラムの内部論理構造をチェックし、すべての論理パスをテストする. 網羅的なパステスト法です. 、しかし、各パスがテストされたとしても、完全なパステストではプログラム自体が設計仕様に違反しているかどうかを確認できないため、エラーが発生する可能性があります

ホワイト ボックス テストで従うべき原則は次のとおりです: 1. モジュール内のすべての独立したパスが少なくとも 1 回テストされることを確認する; 2. すべての論理値が真か偽かをテストする必要がある; 3. 内部データをチェックする構造の有効性を確保するためのプログラムの構造; 4. 上限内および操作可能な範囲内ですべてのサイクルを実行する

一般的に使用されるホワイト ボックス テスト方法:
静的テスト: コード検査、静的構造分析、コード品質測定、ドキュメント テストなど、プログラムを実行しないテスト。またはソフトウェアツールの助けを借りて自動的に

動的テスト: コードを実行する必要があり、プログラムを実行して問題を見つけます。これには、機能の確認とインターフェイスのテスト、カバレッジ分析、パフォーマンス分析、メモリ分析が含まれます

ホワイト ボックス テストのロジック カバレッジには、ステートメント カバレッジ、判定カバレッジ、条件カバレッジ、判定/条件カバレッジ、条件組み合わせカバレッジ、およびパス カバレッジが含まれます。6 つのカバレッジ基準でエラーを検出する能力は、弱いものから強いものへと変化します。
1. ステートメント カバレッジ すべてのステートメントが少なくとも 1 回実行される
2. 決定カバレッジ 各決定のすべての分岐が少なくとも 1 回実行される
3. 条件がすべての決定をカバーする 条件がとるべきものさまざまな可能な値
4. 判定/条件カバレッジは、同時に判定カバレッジ条件カバレッジを満たす
5. 条件組み合わせカバレッジ 各判定における条件の各組み合わせは、少なくとも 1 回発生します
6. パス カバレッジは、プログラム パスで実行されるすべての可能なパスを作成します少なくとも一回

手動テストと自動テストのメリットとデメリットを教えてください

手動テストの利点：
1. テスターに​​は経験とエラーを推測する能力がある
2. テスターに​​は審美的能力と心理的経験がある
3. テスターに​​は正誤の判断力と論理的能力がある
手動テストの欠点：
1. 手動回帰テストの繰り返しはコストがかかりすぎる 大、エラーが発生しやすい
2. ソフトウェアテスターの能力に頼る

自動テストの利点:
1. プログラムの回帰テストはより便利です。これは、自動テストの最も重要なタスクである可能性があります。特に、プログラムが頻繁に変更される場合、その効果はより明白です。回帰テストのアクションとユースケースが完全に設計されているため、テストの期待される結果も完全に予測可能であり、回帰テストが自動的に実行されるため、テスト効率が大幅に向上します 2. 面倒なテストをどんどん実行できます3.手動でのテストが困難または不可能なテストを実行できます
。
たとえば、操作に同時にアクセスする多数のユーザーをシミュレートし
ます。
5. 自動化されたテストは一貫性と再現性があり、各テストの結果と実行内容の一貫性が保証されます. 6. テストの再利用性. 自動テストは通常​​スクリプト技術を使用するため、小さなことしか
実行できません.異なるテスト プロセスで同じユース ケースを使用するための変更の量
自動テストの欠点:
1. 手動テストを置き換えることができない
2. 手動テストは、自動テストよりも包括的であり、欠陥を検出する
3. テストの品質に大きく依存する
4. テスト自動化は有効性を改善できない
5. 自動化されたテストはソフトウェア開発を制限するかもしれない. 自動化されたテストは手動テストよりも壊れやすいので、すべてのメンテナンスが制限され、それによってソフトウェア開発が制限される. 6. ツール自体は思考を発散させる能力を持っていない
.

テストプロジェクトの具体的な作業は何ですか

テスト環境の構築
テスト ケースの作成 テスト ケース
の実行
テスト計画の作成、テスト レポートの作成、
テスト、およびバグ フォームの送信 バグ
修正の追跡
自動テストの実行、スクリプトの作成、実行、分析、およびレポート
パフォーマンス テスト、ストレス テスト、およびその他のテストの実行実行、分析、調整、レポート

テストケースの境界

境界値分析は、入力または出力の境界値をテストするためのブラック ボックス テスト手法です。

一般的に使用される境界値

1. 16 ビット整数の場合、32767 と -32768 が境界です。
2. 画面上のカーソルは左上と右下にあります
3. レポートの最初と最後の行
4. データ要素の最初と最後
5. サイクルの 0 番目、1 番目、最後から 2 番目、および最後の時間

ソフトウェア品質の6つの特徴

1. 機能的特性: 一連の機能に関連する一連の属性。ここで、機能とは、明示的または暗示的なニーズを満たすものであり、割り当てられたプロパティです。
2. 信頼性特性: ソフトウェアが特定の期間および条件下でパフォーマンスのレベルを維持する能力に関連する一連のプロパティ
3. 使いやすさの特性:特定のユーザーまたは潜在的なユーザーのセットがソフトウェアを使用するために必要な労力と評価に関連する属性のセット
4. 効率性：ソフトウェアの性能レベルと特定の条件下で使用されるリソースの量との関係に関連するプロパティのセット
5. 保守性特性:指定された変更を行うために必要な作業に関連する一連のプロパティ
6. 移植性特性:ある環境から別の環境にソフトウェアを転送する機能に関連する一連のプロパティ

テストケースを詳細に設計する方法

ブラックボックステスト

• 等価クラス分割
  等価クラス分割は、システムの入力ドメインをいくつかの部分に分割し、各部分から少量の代表的なデータを選択してテストします。等価クラスは、有効な等価クラスと無効な等価クラスに分けることができ、テスト ケースを設計する際に両方を考慮する必要があります。

• 境界値分析法は
  同値類の分割を補足するものである. 境界値分析法は入力条件の境界でほとんどのエラーが発生することを想定している. 有効な同値類と無効な同値類の境界値カバレッジはより効果的である.したがって、この方法は同値類分割法と組み合わせて使用​​する必要があります

・直交検定法
直交検定とは、多数の検定点から適切かつ代表的な点を選択することです。直交実験計画法は、多因子・多水準を研究するための計画法で、直交表に基づく高効率・高速・経済的な実験計画法です。

-状態遷移法
状態遷移法は、与えられた条件内で必要な状態変化を生成することです. 状態遷移法は、システムの状態、状態、条件の組み合わせ、および状態遷移パスをカバーするために十分なユースケースを設計することです.

・プロセス分析法
プロセス分析法は、主にテストシナリオ種別がプロセステストシナリオに属するテスト項目配下のテスト項目を対象としたもので、ホワイトボックステストにおけるパスカバレッジ分析法から借用した重要な方法である。

-出力ドメイン分析方法
出力ドメイン分析方法は、出力ドメインの等価クラスと境界値を分析し、カバーされる出力ドメインのサンプルポイントを決定し、入力する必要がある入力値を反転して、構築することです。テストケース

-意思決定表の分析方法 意思
決定表は、さまざまな入力条件の下でシステムのさまざまな動作を分析して表現するためのツールであり、さまざまな条件の複雑な論理関係と組み合わせを具体的かつ明確な方法で表現できます。

・因果図法 因果図
は、システムの入出力間の因果関係や制約関係を記述するために使用されます。因果図の描画プロセスは、テスト対象システムの外部特性をモデル化するプロセスであり、入力と出力の因果図に従って決定表を取得できます。テストケースを計画する

-間違った推測方法
間違った推測方法は、テストケースを設計するために、主に間違った操作の操作に対するシステムの推測方法を目的としています。

- 異常分析方法
異常分析方法は、システムの異常動作の可能性、ソフトウェアおよびハードウェアの欠陥による障害を分析し、システムのエラー処理能力とエラー送信時の回復能力を分析し、テストケースを設計します。

APP パフォーマンス テストの指標

1. メモリ: メモリ消費テスト ノードの設計目標は、アプリケーションがシステム リソースを占有しすぎないようにすることと、システム全体の安定性を確保するために時間内にメモリを解放することです。もちろん、メモリ テストに関しては、ここでいくつかの概念を紹介する必要があります。アイドル状態、ミディアム スペック、フル スペックです。

アイドル状態とは、アプリケーションを開いた後、ホームボタンをクリックしてアプリケーションをバックグラウンドで実行することを意味します.このときのアプリケーションの状態はアイドルと呼ばれます.ミディアム仕様とフル仕様は、アプリケーションの動作時間の長さの違いを指します.アプリケーション、ミディアム仕様はより長く、フル仕様はより長くなります. 仕様時間の短縮

メモリ テストには多くのテスト項目があります。
アイドル状態でのアプリケーション メモリ消費量、中仕様状態でのアプリケーション メモリ消費量、フル仕様状態でのアプリケーション メモリ消費量、アプリケーション メモリ ピーク値、アプリケーション メモリ リーク、アプリケーションがメモリに常駐、ストレステスト後のメモリ使用量

2. CPU:
Android が提供する view plaincopy を使用して CODE のコード スライスを表示し、自分のコード スライスから派生させます adbshel​​l dumpsys CPUinfo | grep packagename >/ address/CPU.txt を取得して、top コマンドの view plaincopy を使用して表示しますCODE でのコード スライスの派生 私のコード スライス adbshel​​l top | grep packagename >/address/CPU.txt に移動して取得します。

3. トラフィック:
ネットワーク トラフィック テストは、ほとんどのアプリケーション向けであり、アプリケーションによっては、ネットワーク速度や脆弱なネットワークなどのテストに焦点を当てる場合もあります。

フローテストには、
アプリケーションの最初の起動フロープロンプト、
バックグラウンドで 2 時間連続実行されたアプリケーションのフロー値、
高負荷で実行されたアプリケーションのフローピーク値、およびアプリケーションのフローピーク値が含まれます。

4.パワー

• ターゲットAPKを携帯電話にインストールする前と後で、待機電力消費に大きな違いがあるかどうかをテストします
• 一般的な使用シナリオでは、通常どおりスタンバイに入ることができ、スタンバイ電流は通常の範囲内です
• 長時間連続使用で異常な電力消費現象はありませんか？

5. 起動速度
第 1 のカテゴリ: 最初の起動 - アプリケーションの最初の起動に費やされた時間
第 2 のカテゴリ: アプリケーションの最初以外の起動に費やされた時間 第
3 のカテゴリ: アプリケーション インターフェイスの切り替え -アプリケーション インターフェイス時間内の切り替えに費やされた時間

6. 摺動速度、インターフェース切替速度

7. サーバーとやり取りするためのネットワーク速度

PC ネットワークがダウンした場合のトラブルシューティング方法

1. 最初に障害を排除します。つまり、ネットワーク ケーブルが正常に使用できることを確認してから、ネットワーク カードを無効にしてから有効にして、偶発的な障害を排除します。ネットワークと共有センター ウィンドウを開き、ウィンドウの左上にある [アダプターの設定の変更] をクリックし、[ローカル エリア接続] または [ワイヤレス ネットワーク接続] を右クリックして、ショートカット メニューの [無効にする] コマンドをクリックします。選択したネットワークを無効にしてから、ネットワークを再起動し、チェックします
2. Ipconfig を使用してコンピュータのインターネット アクセス パラメータを表示します
   1. [スタート | すべてのプログラム | コマンド プロンプト] をクリックして cmd ウィンドウを開きます
   2. ipconfig と入力し、Enter キーを押して確認します。マシンの構成情報を表示できます。ネットワーク カードの物理アドレスなど、IP アドレスと関連するネットワークの詳細を確認するには
3. ping コマンドを使用してネットワークの接続をテストし、障害の範囲を特定し、
   cmd に「ping 127.0.0.1」と入力すると、マシンがそれぞれ送受信した 4 つのデータ パケットがデータに表示されます。パケット損失率がゼロの場合、マシンのネットワーク プロトコルを判断できます 正常に動作していますが、「要求がタイムアウトしました」と表示された場合は、ローカル ネットワーク カードのインストールまたは TCP/IP プロトコルに問題があることを示します。ネットワーク カードと TCP プロトコル、アンインストールと再インストール
4. ローカル IP に Ping
   127.0.0.1 アドレスに ping できることを確認した後、引き続き ping コマンドを使用して、ローカル IP アドレスに ping できるかどうかをテストします. できない場合は、ローカル ネットワーク カードのドライバーが正しくないか、ネットワーク カードに問題があることを意味しますThere is a fault in the connection between the network cable, and it might also be that the local routing surface. このとき、ローカル ネットワーク カードのステータスが接続されているかどうか、およびネットワーク パラメータが正しく設定されている. 正しいが ping できない場合は、ネットワーク カード ドライバ. プログラムを再インストールする必要があります. ロス率ゼロで、ネットワークカードの搭載・構成に問題はないと判断できる
5. ping
   ゲートウェイ ゲートウェイ アドレスに ping を実行できる場合は、マシンのネットワーク接続が正常であることを意味します。コマンドが失敗した場合は、ゲートウェイ デバイスに問題があるか、マシンのネットワーク パラメータが設定されている可能性があります。ネットワークパラメータを確認してください。

Web テストとアプリ テストの違い

システム アーキテクチャの観点から:
Web プロジェクトは一般的に b/s であり、ブラウザ ベースの
アプリ プロジェクトは c/s. 顧客サービス ターミナルが必要であり、ユーザーはクライアントをインストールする必要があります. Web プロジェクトがサーバーを更新する限り、
、カスタマー サービス ターミナルは
アプリを同期的に更新します。このプロジェクトでは、クライアントとサーバーの両方を更新する必要があります。

パフォーマンスに関しては、
Web ページは主に応答時間に関連しています
が、アプリはトラフィック、電力、CPU、GPU、メモリなどにも注意を払う必要があります。

互換性:
Web はブラウザーに基づいているため、ブラウザーとコンピューターのハードウェアにさらに傾いています. コンピューター システムの方向性は
Web と互換性があります. クライアントのインストールとアンインストールを考慮する必要はありません.
アプリテストは、解像度、画面サイズ、およびデバイス システムに依存します
. クライアントの場合は、インストール、更新、およびアンインストールをテストする必要があります。通常のインストール、更新、およびアンインストールに加えて、インストール中の中断、弱いネットワーク、インストール後のインストール ファイルの削除など、異常なシナリオも考慮する必要があります。

ネットワーク プロトコルをテストする方法

主に 4 種類のテストが含まれます。
コンフォーマンス テスト: プロトコル実装自体とプロトコル仕様との間の適合度をチェックします
相互運用性テスト: 特定のプロトコルに基づいて、異なるプロトコル実装間の相互運用性と相互通信の能力を検出します
パフォーマンス テスト:プロトコル実装のパフォーマンス データ転送速度、接続時間、実行速度、スループット、同時実行性などの指標 堅牢性テスト
: 干渉メッセージの挿入、通信障害、チャネルなど、さまざまな過酷な環境でプロトコルが実行できる能力を検出しますカットオフ