ソフトウェア ライフ サイクル (prdctrm)
企画段階（プランニング）→要件分析（要求）→設計段階（デザイン）→コーディング（コーディング）→テスト（テスト）→運用保守（メインマシンの実行）
テストケース
ユースケース番号 テスト項目 テストタイトル 重大度レベル 前提条件 入力データ 実行ステップ 期待される結果
1. 質問: テストでバグが見つかりましたが、開発マネージャーはバグではないと考えています。どのように解決すればよいですか?
まず、問題を提出するために欠陥管理ライブラリに送信します。
次に、判断の根拠と基準を取得するには、次のようにします。
要求仕様、製品説明、設計図書などに従って、実際の結果が計画と矛盾しているかどうかを確認し、欠陥を確認するための直接の根拠を提供します。
文書による根拠がない場合は、類似ソフトウェアの一般的な特性に基づいて欠陥があるかどうかを確認し、矛盾があるかどうかを説明できます。
ユーザーの一般的な使用習慣に従って、それが欠陥であるかどうかを確認するため。
設計者、開発者、顧客担当者などの関係者と協議し、欠陥であるかどうかを確認します。
合理的な議論を行い、判断の理由を試験監督に説明し、客観性と厳密さに注意を払い、個人的な感情を混ぜないでください。
テスト管理者が最終決定を下すのを待ちますが、それでも議論がある場合は、会社のポリシーで定められたルートを通じて上司に報告することができ、上司が決定を下します。
2. 質問: Web サイトがある場合、どのようにテストしますか?
まず、要件の説明や Web サイトのデザインなどの関連ドキュメントを見つけて、テスト要件を分析します。
テスト計画を作成し、テスト範囲とテスト戦略を決定します。これには通常、機能テスト、インターフェイス テスト、パフォーマンス テスト、データベース テスト、セキュリティ テスト、互換性テストが含まれます。
テスト ケースを設計します。
機能テストには次の側面が含まれますが、これらに限定されません。
リンクテスト。リンクが正しくジャンプするか、空のページや無効なページはないか、誤ったエラー メッセージが返されるかどうか。
関数のテストを送信します。
マルチメディア要素を正しくロードして表示できるかどうか。
多言語対応により、選択した言語が正しく表示されるかどうかなど。
インターフェイスのテストには次の側面が含まれますが、これらに限定されません。
ページのスタイルが統一されていて美しいかどうか
ページレイアウトは合理的か、キーコンテンツやホットコンテンツは目立つか
制御が正常に動作するかどうか
必須であるがインストールされていないコントロールについて、自動ダウンロードおよびインストールの機能を提供するかどうか
単語チェック
パフォーマンス テストでは通常、次の 2 つの側面が考慮されます。
応力試験; 荷重試験; 強度試験
データベースのテストは、実行する必要があるかどうかを具体的に判断する必要があります。データベースでは通常、接続、データ アクセス操作、データ コンテンツの検証を考慮する必要があります。
セキュリティテスト:
基本的なログイン機能をチェックします
システムクラッシュや権限リークを引き起こすオーバーフローエラーが発生したかどうか
SQL インジェクションなど、関連する開発言語の一般的なセキュリティ問題チェック。
高度なセキュリティ テストが必要な場合は、専門のセキュリティ会社の支援を受けるか、テストを外注するか、サポートを受けるようにしてください。
互換性テストでは、要件の説明の内容に従って、サポートされるプラットフォームの組み合わせが決定されます。
ブラウザの互換性。
オペレーティング システムの互換性。
ソフトウェアプラットフォームの互換性。
データベースの互換性
テストが実行され、欠陥が記録されます。テストスケジュールを合理的に調整および調整し、テストに必要なリソースを事前に取得し、管理システム (要件の変更、リスク、構成、テスト文書、欠陥レポート、人的リソースなど) を確立します。
定期的にテストを見直し、評価、要約し、テストの内容を調整します。
3. 検索エンジンに中国語の文字を入力すると、対応するドメイン名に解決されるかどうか、LoadRunner を使用してテストする方法。
テスト計画を策定し、テスト基準とテスト範囲を決定する
一般的なビジネス プロセスや珍しいビジネス プロセスなどをカバーする、典型的なシナリオのテスト ケースを設計します。
テスト ケースに従って、自動テスト スクリプトとシナリオを開発します。
テスト スクリプトの記録: 新しいスクリプト (Web/HTML プロトコル) を作成します。記録ボタンをクリックし、ポップアップ ダイアログ ボックスの URL に「about:blank」と入力します。開いているブラウザでの通常の操作プロセスの後、記録を終了します。スクリプトをデバッグして保存します。文字セットの関連付けに注意する必要がある場合があります。
テスト シナリオの設定: 主にシステムの平均トランザクション応答時間が通常の状況で標準を満たしているかどうかを判断するために、パフォーマンスのテスト シナリオを設定します。主に全負荷または長時間システムの耐荷重を超えた条件でシステムがクラッシュするかどうかを判断するために、ストレス負荷のテスト シナリオを設定します。テストを実行し、テスト結果を取得し、テスト結果を分析します。
4. 質問: 300 台のクライアントを持つクライアントと、サーバーに圧力をかける 300 台のクライアントを持つ 300 台のクライアントの違いは何ですか?
1 つのクライアント上に 300 人のユーザーがいると、クライアントのリソースがより多く占有され、テスト結果に影響します。スレッド間の干渉が発生し、一部の例外が発生する可能性があります。
1 つのクライアント上に 300 人のユーザーがいる場合は、より多くの帯域幅が必要です。
IP アドレスの問題の場合は、IP スプーフを使用して、単一の IP アドレスへの最大接続数に対するサーバーの制限を回避する必要がある場合があります。
すべてのユーザーは 1 つのクライアント上に存在するため、分散管理の問題を考慮する必要はありません。ユーザーが異なるクライアントに分散している間は、コントローラーを使用してユーザーを異なるクライアント全体に展開することを検討する必要があります。同時に、対応する権限構成とファイアウォール設定も与える必要があります。
5. ソフトウェアの概念と特徴、ソフトウェアの再利用の意味、どのようなコンポーネントが含まれているかを説明します。
ソフトウェアは、ハードウェア、コンピュータ プログラム、手順、ルール、およびコンピュータ システムの動作に関連する可能性のあるファイル、文書、データと相互依存するコンピュータ システムの別の部分です。
ソフトウェアの再利用（ソフトウェア再利用）とは、ソフトウェアの開発と保守のコストを削減するために、既存のソフトウェアに関するあらゆる種類の関連知識を利用して新しいソフトウェアを作成することです。ソフトウェアの再利用は、ソフトウェアの生産性と品質を向上させるための重要なテクノロジーです。初期のソフトウェアの再利用は主にコードレベルの再利用であり、再利用される知識はプログラムを指しますが、後にはドメイン知識、開発経験、設計上の決定、アーキテクチャ、要件、設計、コード、ドキュメントなどの関連するすべての側面を含むように拡張されました。
再利用可能なソフトウェアコンポーネントを一般に再利用コンポーネントと呼びます。
6. ソフトウェアのライフサイクルとそのモデルは何ですか?
ソフトウェアライフサイクル（ソフトウェアライフサイクル）は、ソフトウェアライフサイクル、生存期間とも呼ばれます。ソフトウェア開発の構想が形成され、開発されたソフトウェアが利用価値を失い消滅するまでの全過程を指します。一般に、ライフサイクル全体は計画（定義）、開発、運用（保守）の3つの期間で構成され、各期間はいくつかの段階に分かれています。各ステージには明確なタスクがあります。
周期モデル (典型的なタイプ):
ウォーターフォールモデル
ラピッドプロトタイピングモデル: ラピッドプロトタイピングモデルでは、要件分析段階での予備的ではあるが完全ではないソフトウェア要件の分析と定義、およびソフトウェアシステムのプロトタイプの迅速な設計と開発が可能になり、開発されるソフトウェアの機能とパフォーマンスのすべてまたは一部がユーザーに示されます。ユーザーはプロトタイプをテストおよび評価し、ソフトウェア要件を充実させ改良するための具体的な改善提案を提供します。開発者はそれに応じてソフトウェアを修正および改善します。
反復モデル: 反復には、製品リリース (安定した実行可能な製品バージョン) をもたらすすべての開発アクティビティと、そのリリースを使用するために必要なその他すべての周辺要素が含まれます。ある意味、開発イテレーションは、要件分析、設計、実装、テストのワークフローなど、すべてのワークフローを一度に実行するプロセスです。本質的には、小さなウォーターフォール プロジェクトのようなものです。RUP は、すべての段階を反復に細分化できると考えています。各反復では、最終製品のサブセットであるリリース可能な製品が生成されます。
ライフサイクルのフェーズ:
ソフトウェアの計画と実現可能性の分析
需要分析
ソフトウェア設計
コーディング
ソフトウェアテスト
運用・保守
7. ソフトウェア テストとは何ですか? ソフトウェア テストの目的と原則
指定された条件下でプログラムを動作させて、プログラムのエラーを発見し、ソフトウェアの品質を測定し、設計要件を満たしているかどうかを評価するプロセス。
ソフトウェアテストの目的:
テストとは、プログラムを実行してバグを見つけることです
成功したテストケースは、これまで発見されていないバグを発見することにあります。
成功したテストとは、これまで発見されていないバグを発見したものです
製品が約束や宣伝どおりの機能を果たし、ユーザーがアクセスできる機能が明確に文書化されていることを確認してください。
製品がパフォーマンスと効率の要件を満たしていることを確認する
製品が堅牢でユーザー環境に適応できることを確認する
ソフトウェアテストの原則:
テスト ケースの必須部分は、予想される出力または
プログラマーは自分が書いたプログラムのテストを避けるべきです
ソフトウェアを作成する組織は、作成したソフトウェアをテストしてはなりません
各テストの実行結果を徹底的に確認する必要がある
テスト ケースは、有効で予期される入力だけでなく、無効で予期しない入力に対しても作成する必要があります。
プログラムが「本来の動作をしていない」ことをチェックするのはテストの半分にすぎず、テストの残りの半分はプログラムが「本来の動作を行っていない」ことを確認することです。
ソフトウェア自体が使い捨てのソフトウェアでない限り、使い捨てのテスト ケースは避けるべきです
テスト作業を計画するとき、バグは見つからないと暗黙のうちに想定すべきではありません。
プログラムの一部にさらに多くのバグがある確率。その部分ですでに見つかっているバグの数に比例します。
ソフトウェアテストは非常に創造的で知的にやりがいのある仕事です
8. ソフトウェア構成管理の役割は何ですか? ソフトウェア構成には何が含まれますか?
ソフトウェア構成管理 (SCM) は、変更を特定、整理、および制御するための技術です。ソフトウェア構成管理は、ソフトウェア エンジニアリング プロセス全体に適用されます。ソフトウェアを構築する際には変更は避けられず、変更はプロジェクト上のソフトウェア開発者の混乱を悪化させます。SCM 活動の目標は、変更を特定し、変更を管理し、変更が正しく実装されていることを確認し、他の関係者に変更を報告することです。ある意味、SCM は、エラーを最小限に抑えて生産性を最大化するために、変更を特定、整理、および制御するための手法です。
ソフトウェア構成には、構成項目の識別、ワークスペース管理、バージョン管理、変更管理、ステータスレポート、構成監査が含まれます。
9. ソフトウェアの品質とは何ですか?
一言で言えば、ソフトウェア品質とは「ソフトウェアが明示的および暗黙的に定義された要件にどの程度準拠しているか」です。具体的には、ソフトウェアの品質とは、ソフトウェアが明示的に記載された機能およびパフォーマンス要件、ドキュメントに明示的に記載された開発標準、および専門的に開発されたすべてのソフトウェアが持つべき暗黙の特性にソフトウェアがどの程度準拠しているかを指します。ソフトウェアの品質に影響を与える主な要因は、管理の観点からソフトウェアの品質を測定することです。ソフトウェア製品を使用する際のユーザーの 3 つの視点をそれぞれ反映する 3 つのグループに分類できます。正確性、堅牢性、効率、完全性、使いやすさ、リスク（製品の運用）、理解性、保守性、柔軟性、テスト容易性（製品の変更）、移植性、再利用性、相互運用性（製品の移行）。
10. 現在の主なテストケース設計方法は何ですか?
ホワイトボックステスト: ロジックカバレッジ、ループカバレッジ、基本パスカバレッジ
ブラックボックステスト: 境界値分析、同値クラス分割、エラー推測、因果関係図、状態図、テスト概要、ランダムテスト、シナリオ
11. ソフトウェアのセキュリティはどのような側面からテストする必要がありますか?
ソフトウェア セキュリティ テストには、プログラムとデータベースのセキュリティ テストが含まれます。システムセキュリティ指標の違いに応じて、テスト戦略も異なります。
ユーザー認証セキュリティテストで考慮すべき問題: システム内の異なるユーザー権限を明確に区別するか、システム内でユーザーの競合が発生するかどうか、ユーザー権限の変更によりシステムが混乱を引き起こすかどうか、ユーザーのログインパスワードが表示され再現可能かどうか、絶対的な方法 (ユーザーがログインした後にリンクをコピーしてシステムに直接入る) でシステムにログインできるかどうか、ユーザーがシステムからログアウトした後にすべての認証マークが削除されるかどうか、パスワードを入力せずに戻るボタンを使用してシステムに入ることができるかどうかシステムネットワークセキュリティテストでは、問題を考慮する必要があります。テストで講じられた保護対策が正しくインストールされているかどうか、関連するシステムパッチが適用されているかどうか、不正な攻撃をシミュレートしているかどうか、保護システムが強力であるかどうかを確認し、成熟したネットワーク脆弱性検査ツールを使用してシステム関連の脆弱性を確認します（つまり、攻撃には最も専門的なハッキングツールを使用します。最も一般的に使用されているものはNBSIシリーズとIPhacker IPです）、さまざまなトロイの木馬検査ツールを使用してシステムのトロイの木馬を確認し、さまざまなプラグイン対策ツールを使用してプラグインを確認しますシステム内のさまざまなグループのプログラムの脆弱性
データベースのセキュリティに関する考慮事項：システムデータの機密性（例えば、銀行システムの場合は特に重要であり、一般的なWebサイトにはそれほど高い要件はありません）、システムデータの完全性（私が完成させたエンタープライズ実名認証サービスシステムにはデータの不完全性があり、このシステムの機能実現に支障をきたしていました）、システムデータの管理性、システムデータの独立性、システムデータのバックアップとリカバリ能力（データのバックアップは完了しているか、復元できるか、復元が完了できるか） )
12. テスト ケース、テスト スクリプトとは何ですか? 両者の関係は何ですか?
テストの実施のためにテスト対象システムに提供される、特定の入力データ、操作またはさまざまな環境設定、および期待される結果のセット。
テスト スクリプトは、自動テスト用に作成されたスクリプトです。
テスト スクリプトの記述は、対応するテスト ケースに対応する必要があります。
13. 静的テスト、動的テスト、ブラック ボックス テスト、ホワイト ボックス テスト、アルファ テスト、ベータ テストとは何かを簡単に説明します。
静的テストは、プログラム自体を実行せずに、プログラム コード内の潜在的なバグを見つけたり、プログラム コードを評価したりするプロセスです。
動的テストとは、テスト対象のプログラムを実際に実行し、対応するテストインスタンスに入り、実行結果と期待される結果の違いを確認し、実行結果が要件を満たしているかどうかを判断することで、プログラムの正確性、信頼性、有効性を検証し、システムの動作効率と堅牢性のパフォーマンスを分析します。
ブラックボックステストは、一般にソフトウェアの機能の正当性や操作性を確認するために行われ、ソフトウェアの各機能が実現可能かどうかを検出することを目的とし、テスト対象のプログラムを内部構造に関わらずブラックボックスとして扱い、プログラムの入出力関係やプログラムの機能が分かっている場合には、ソフトウェアの仕様に基づいてテストケースの正しさを判断し、テスト結果を推測します。
ホワイトボックス テストは、ソフトウェアの論理構造の分析に基づいて実行されます。コードベースのテストです。テスターは、プログラム コードを読み取るか、開発ツールのシングル ステップ デバッグを使用して、ソフトウェアの品質を判断します。一般に、ブラック ボックス テストは、プログラマの開発中にプロジェクト マネージャーによって実装されます。
アルファテストは、ユーザーが開発環境で実施するテスト、または社内のユーザーが実際の運用環境を模擬して実施する管理テストであり、プログラマーやテスターが行うことはできません。
ベータテストとは、ソフトウェアの複数のユーザーが、1人または複数のユーザーの実際の使用環境下で実行するテストです。通常、開発者はテスト サイトには存在せず、プログラマーやテスターがベータ テストを行うことはできません。
14. ソフトウェア品質保証システムとは何ですか? 品質保証管理に関する国家規格は何ですか? シリアル番号と正式名称は何ですか?
SQA は、(ソフトウェアの) 品質を保証するための一連のソフトウェア エンジニアリング プロセスと方法で構成されます。SQA はソフトウェア開発プロセス全体を通じて実行されます。それには、要件文書レビュー、コード管理、コードレビュー、変更管理、構成管理、バージョン管理、およびソフトウェアテストが含まれます。
ソフトウェア品質保証 (SQA-ソフトウェア品質保証) は、提案された標準、手順、実践および方法がすべてのプロジェクトに正しく採用されることを管理者が保証するための、計画的かつ体系的な方法を確立することです。ソフトウェア品質保証の目的は、ソフトウェア プロセスを管理者が見えるようにすることです。ソフトウェア製品と活動のレビューと監査を実施することにより、ソフトウェアが標準に準拠していることを検証します。ソフトウェア品質保証グループは、プロジェクトの開始時に計画、標準、プロセスの確立に関与します。これらにより、ソフトウェア プロジェクトが政府機関のポリシーの要件を満たすことが可能になります。
15. ソフトウェア製品の品質特性は何ですか?
機能: 適応性、正確性、相互運用性、コンプライアンス、セキュリティ。
信頼性: 成熟度、耐障害性、容易な回復。
ユーザビリティ: 理解しやすく、学びやすく、操作しやすい。
効率: 時間特性、リソース特性。
保守性: 分析の容易さ、変更の容易さ、安定性、テストの容易さ。
移植性: 適応性、設置の容易さ、コンプライアンス、交換の容易さ
16. ソフトウェアテストの戦略は何ですか?
ソフトウェア テスト戦略: 特定のソフトウェア テスト標準およびテスト仕様の指導の下、テスト プロジェクトの特定の環境制約に従って規定されたソフトウェア テストの原則、方法、方法の集合。
17. ソフトウェアのテストはいくつかの段階に分かれていますが、各段階のテスト戦略と要件は何ですか?
開発プロセスに対応して、テスト プロセスは、単体テスト、統合テスト、システム テスト、受け入れテストの 4 つの主要な段階を経ます。
単体テスト: 単体テストは、ソフトウェア設計の最小単位、つまり正確性をチェックするためのプログラム モジュールまたはコード セグメントのテスト作業であり、通常は開発者によって実行されます。
統合テスト: 統合テストは、テストの設計要件に従ってモジュールを組み立てることであり、主な目的はインターフェイスに関連する問題を見つけることです。製品をテスト部門に提出する前に製品開発チームは共同デバッグを実施する必要があるため、ほとんどの企業では統合テストは開発者によって行われます。
システム テスト: システム テストは、統合テストに合格した後に実行されます。目的は、システムを完全に実行し、各サブシステムが正常に動作し、設計要件を満たしているかどうかを確認することです。主にテスト部門で実施され、テスト部門の中で最も大規模かつ最も重要なテストであり、製品の品質に大きな影響を与えます。
受け入れテスト: 受け入れテストは、要求フェーズの「要求仕様書」を受け入れ基準とし、実際のユーザーの動作環境をシミュレートする必要があります。実際のプロジェクトの場合は顧客と一緒に実施できますし、製品の場合は最後のシステムテストになります。テスト内容は機能モジュールの総合テスト、特にドキュメントテストです。
単体テストのテスト戦略:
トップダウンの単体テスト戦略: 単独の単体テストよりもはるかにコストがかかるため、単体テストには適していません。
ボトムアップの単体テスト戦略: より合理的な単体テスト戦略ですが、テスト サイクルが長くなります。
単体テストの戦略: 最適な単体テスト戦略。
統合テストのテスト戦略:
Big Bang Integration: メンテナンス プロジェクトまたはテスト対象のシステムが小規模な場合に適しています
トップダウン統合: 製品制御構造が明確で安定している場合に適しています。上位レベルのインターフェイスはほとんど変更されません。下位レベルのインターフェイスは未定義または頻繁に変更される可能性があります。生産および港湾制御コンポーネントには大きな技術的リスクがあり、できるだけ早く検証する必要があります。製品のシステム機能の動作をできるだけ早く確認したい場合に適しています。
ボトムアップ統合: 最下位のインターフェイスは比較的安定していますが、高レベルのインターフェイスは頻繁に変更され、最下位のコンポーネントはより早く完成します。
進捗ベースの統合
利点: 高度な並列性があり、プロジェクトの開発進行を効果的に短縮できます。
短所: 杭とドライバーの作業負荷が大きい、一部のインターフェイス テストが不十分、一部のテストが繰り返し行われ無駄が多い。
システムテストのテスト戦略:
データおよびデータベースの整合性テスト、機能テスト、ユーザー インターフェイス テスト、パフォーマンス テスト、負荷テスト、強度テスト、容量テスト、セキュリティおよびアクセス制御テスト、フェイルオーバーおよび回復テスト、構成テスト、インストール テスト、暗号化テスト、ユーザビリティ テスト、バージョン検証テスト、ドキュメント テスト
18. ソフトウェア テストの各フェーズでは通常どのような作業が行われますか?各フェーズの結果ファイルは何ですか?何が含まれますか?
単体テスト段階: 独立した各単体モジュールをシステムの他の部分から分離してテストし、各プログラム モジュールの正当性をチェックして、各プログラム モジュールが指定された機能を正しく実装しているかどうかを確認します。単体テストレポートを生成し、欠陥レポートを提出します。
統合テスト段階: 統合テストは単体テストに基づいており、概要設計仕様の要件に従ってすべてのソフトウェアユニットがモジュール、サブシステム、またはシステムに組み立てられているかどうかをテストし、各部分の動作が対応する技術指標および要件を満たしているか、または実現しているかどうかを確認します。このフェーズでは、統合テスト レポートが生成され、欠陥レポートが送信されます。
システムテスト段階: 確認テストに合格したソフトウェアは、コンピュータハードウェア、周辺機器、一部のサポートソフトウェア、データ、人員などの他のシステム要素と組み合わせて、コンピュータシステム全体の要素として使用され、実際の動作環境におけるコンピュータシステムの機能を完全にカバーします。この段階では、テストの概要と欠陥レポートを提出する必要があります。
19. ソフトウェア開発プロセスにおけるテスターの仕事は何ですか?
1. システム内のバグをできるだけ早く発見します。
2. ソフトウェア開発プロセスにおける欠陥を回避します。
3. ソフトウェアの品質を測定し、システムの品質を保証します。
4. ユーザーのニーズに注意を払い、システムがユーザーのニーズを満たしていることを確認します。
全体的な目標は、ソフトウェアの品質を保証することです。
20. 以前の仕事では、ソフトウェア欠陥 (またはバグ) 記録には何が含まれていましたか? 高品質のソフトウェア欠陥 (バグ) 記録を提出するにはどうすればよいですか?
バグ記録には基本的に次の内容を含める必要があります。
バグ番号; バグの重大度レベル、優先度; バグが生成されたモジュール; まず第一に、バグの一般的な内容を説明するバグの概要、バグの対応するバージョン、いくつかのスクリーンショットやビデオなどを含むバグの詳細な説明、バグが発生したときのテスト環境、生成される条件は対応する操作手順、高品質のバグ記録:
1) 一般的な UI は統一され、正確である必要があります。欠陥レポートの UI は、簡単に見つけて見つけられるように、テストされたソフトウェアの UI と一致している必要があります。2) 業界で一般的に使用されている用語と方法を使用するように努めてください。正確な表現と専門性を確保するために、業界で一般的に使用されている用語と方法を使用してください。3) 各欠陥レポートには欠陥が 1 つだけ含まれます。各欠陥レポートには欠陥が 1 つだけ含まれます。これにより、欠陥修正者は欠陥を迅速に特定し、一度に 1 つの欠陥のみを修正することに集中できます。検証者は、一度に欠陥が正しく修正されたかどうかのみを検証します。4) 再現不可能な欠陥も報告する必要がある まず、欠陥レポートは欠陥を再現できることを証明する必要があります。再現できない欠陥は可能な限り再現する必要があり、あらゆる努力をしても再現できない場合でも、その欠陥を報告する必要がありますが、その報告には、再現できない欠陥の発生頻度を示す必要があります。5) 欠陥の種類を明確にする 欠陥の現象から欠陥の種類を総合して判断します。たとえば、機能上の欠陥、インターフェイスの欠陥、データの欠陥、合理化は、これが最も一般的な欠陥または欠陥のタイプであることを示唆しており、他の形式の欠陥または欠陥もいずれかの形式に従属していることを示しています。6) 欠陥の重大度と優先度を明確に示す 重大度と優先度の違いを常に明確にします。重大度の高い問題は修正する価値がない可能性があり、表面上の小さな問題は優先度が高いと考えられる場合があります。7) 簡潔、正確、完全な説明、欠陥の本質を明らかにし、欠陥または欠陥が発生した場所を記録する 説明は欠陥の本質を正確に反映し、短く明確でなければなりません。ソフトウェア欠陥管理データベース内の定式化されたテスト欠陥の検索を容易にするために、欠陥が発生したときにユーザー インターフェイス (UI) を含めることを習慣にしてください。たとえば、レコード ダイアログ ボックスのタイトル、メニュー、ボタン、その他のコントロールの名前などです。8) 短い行の間に自動デジタル シリアル番号を使用し、同じフォント、フォント サイズ、行間隔を使用する 各レコードの形式が一貫しており、標準化されたプロフェッショナルなものであることを保証するために、短い行の間に自動デジタル シリアル番号を使用し、同じフォント、フォント サイズ、行間隔を使用します。9) 操作ステップの簡潔さ、順序性、および簡単な繰り返しを確保するために、各ステップで操作を 1 つだけ記録するようにしてください。10) 欠陥を迅速かつ正確に繰り返すために、手順が完全、正確、短いことを確認します。「完全」とは漏れがないことを意味し、「正確」とは手順が正しいことを意味し、「短い」とは冗長な手順がないことを意味します。11) 欠陥に応じて、画像キャプチャを行うかどうかを選択できますが、欠陥や欠陥現象を目視で観察するには、通常、欠陥または欠陥が現れる界面を画像として添付し、記録の「添付」部分に添付する必要があります。スペースを節約し、欠陥または欠陥の本質を正確に反映するために、欠陥または欠陥が発生したときに全画面、アクティブウィンドウ、およびローカルエリアをキャプチャできます。欠陥や欠陥位置を迅速に特定して修正するには、通常、中国の管理マップを添付する必要があります。 必要な特別な文書と個人的な提案やコメントを添付する 特定の文書を開いたときに欠陥または欠陥が発生した場合、その欠陥または欠陥を迅速に再現できるように、その文書を添付する必要があります。場合によっては、欠陥または欠陥修正者に欠陥または欠陥のパフォーマンスをさらに明確にするために、個人的な修正提案やコメントを添付することができます。12) スペルと文法上の欠陥を確認する 各欠陥を送信する前に、スペルと文法をチェックして内容が正しいことを確認し、欠陥を正確に説明してください。13) 複雑な文型を避け、できるだけフレーズや短い文を使用する ソフトウェア欠陥管理データベースは、欠陥の発見を容易にすることを目的としているため、語彙や複雑な文型を変えることなく、操作手順を客観的に記述し、可読性を高めることが求められます。上記は、テストの欠陥を報告するための標準的な要件を要約したものですが、さまざまなソフトウェア テスト要件があり、テスターは長期間のテストの後、徐々に専門的な良い習慣を身につけ、対応するテスト経験を蓄積し、常に新しい仕様作成要件を追加します。さらに、他のテストエンジニアのテスト欠陥レポートを読んで研究したり、自分の過去のテスト欠陥レポートと比較して考えることで、常にスキルを向上させることができます。14) 欠陥の説明の内容 欠陥の説明の内容には、欠陥の操作手順、実際の結果、および期待される結果が含まれます。この操作手順により、開発者は欠陥の再現と修正が容易になります。開発者の中には、欠陥を再現する能力が低い人もいます。指摘されている欠陥は理解していますが、再現することができません。特に、システムに慣れていない新規開発者にとって、導入手順により再現が容易になります。実際の結果によって開発者は何が間違っていたのかを知ることができ、期待された結果によって開発者は正しい結果がどうあるべきかを知ることができます。複雑な文型を避け、できるだけフレーズや短い文を使用する ソフトウェア欠陥管理データベースは、欠陥の発見を容易にすることを目的としているため、語彙や複雑な文型を変更することなく、操作手順を客観的に記述し、可読性を高めることが求められます。上記は、テストの欠陥を報告するための標準的な要件を要約したものですが、さまざまなソフトウェア テスト要件があり、テスターは長期間のテストの後、徐々に専門的な良い習慣を身につけ、対応するテスト経験を蓄積し、常に新しい仕様作成要件を追加します。さらに、他のテストエンジニアのテスト欠陥レポートを読んで研究したり、自分の過去のテスト欠陥レポートと比較して考えることで、常にスキルを向上させることができます。14) 欠陥の説明の内容 欠陥の説明の内容には、欠陥の操作手順、実際の結果、および期待される結果が含まれます。この操作手順により、開発者は欠陥の再現と修正が容易になります。開発者の中には、欠陥を再現する能力が低い人もいます。指摘されている欠陥は理解していますが、再現することができません。特に、システムに慣れていない新規開発者にとって、導入手順により再現が容易になります。実際の結果によって開発者は何が間違っていたのかを知ることができ、期待された結果によって開発者は正しい結果がどうあるべきかを知ることができます。複雑な文型を避け、できるだけフレーズや短い文を使用する ソフトウェア欠陥管理データベースは、欠陥の発見を容易にすることを目的としているため、語彙や複雑な文型を変更することなく、操作手順を客観的に記述し、可読性を高めることが求められます。上記は、テストの欠陥を報告するための標準的な要件を要約したものですが、さまざまなソフトウェア テスト要件があり、テスターは長期間のテストの後、徐々に専門的な良い習慣を身につけ、対応するテスト経験を蓄積し、常に新しい仕様作成要件を追加します。さらに、他のテストエンジニアのテスト欠陥レポートを読んで研究したり、自分の過去のテスト欠陥レポートと比較して考えることで、常にスキルを向上させることができます。14) 欠陥の説明の内容 欠陥の説明の内容には、欠陥の操作手順、実際の結果、および期待される結果が含まれます。この操作手順により、開発者は欠陥の再現と修正が容易になります。開発者の中には、欠陥を再現する能力が低い人もいます。指摘されている欠陥は理解していますが、再現することができません。特に、システムに慣れていない新規開発者にとって、導入手順により再現が容易になります。実際の結果によって開発者は何が間違っていたのかを知ることができ、期待された結果によって開発者は正しい結果がどうあるべきかを知ることができます。
21. ソフトウェアテストの基本的な手法としてブラックボックステストとホワイトボックステストがありますが、それぞれのメリットとデメリットを教えてください！
ブラックボックステストの利点は、比較的簡単で、プログラムの内部コードや実装を理解する必要がないこと、ソフトウェアの内部実装とは無関係であること、ユーザーの観点からは、ユーザーがどの機能を使用するのか、どのような問題が発生するのかが容易にわかること、ソフトウェア開発ドキュメントに基づいて、ドキュメント内でソフトウェアがどのような機能を実装しているのかを知ることもできること、ソフトウェア自動化テストを行う際に便利であることなどである。
ブラックボックス テストの欠点は、すべてのコードをカバーすることは不可能であり、カバー率が低く、コード量全体の 30% に達するだけであること、自動テストの再利用性が低いことです。
ホワイト ボックス テストの利点は、ソフトウェア テスターがコード カバレッジを増やし、コードの品質を向上させ、コード内の隠れた問題を発見できるようにすることです。
ホワイトボックス テストの欠点は、プログラムの実行にはさまざまなパスがあり、すべての実行パスをテストすることは不可能であること、テストはコードに基づいており、開発者が正しいかどうかをテストすることしかできず、設計が正しいかどうかは分からないこと、一部の機能要件が欠落している可能性があること、システムが巨大な場合、テストのオーバーヘッドが非常に大きくなることが挙げられます。
22. 紙コップをテストするにはどうすればよいですか?
機能: 水カップに水を入れて、漏れているかどうかを確認し、水が飲めるかどうかを確認します。
安全性: カップの中に毒物や細菌はありませんか?
信頼性: さまざまな高さから落としたカップの損傷の程度
携帯性: カップがさまざまな場所、温度、その他の環境でも正常に使用できるかどうか
互換性: カップにジュース、白湯、アルコール、ガソリンなどを入れることができるかどうか。
使いやすさ：カップは熱いか、滑り止めはあるか、飲みやすいか
ユーザーマニュアル: ユーザーマニュアルには、カップの使用法、制限事項、および使用条件が詳細に記載されていますか?
疲労試験：カップに水を入れ（ケース1）24時間放置し漏れ時間と状況を確認、ガソリンを入れて（ケース2）24時間放置し漏れ時間と漏れ状況等を確認します。
ストレス テスト: 針を使用し、それに重りを加え続けて、どれだけの圧力が浸透するかを確認します
22. テスト計画作業の目的は何ですか? テスト計画書には何を含めるべきですか? そのうちのどれが最も重要ですか?
ソフトウェア テスト計画は、テスト プロセスをガイドするプログラム的な文書です。
リーダーはテスト計画に従ってマクロ管理を実施し、それに応じたリソース割り当てなどを実行できます。
テスターは、プロジェクトのテスト全体の状況や、プロジェクトのテストのさまざまな段階で実行すべき作業などを理解できます。
他の担当者がテスターの作業内容を理解し、関連する協力作業を実行するのに便利です
製品概要、テスト戦略、テスト方法、テスト領域、テスト構成、テストサイクル、テストリソース、テストコミュニケーション、リスク分析などが含まれます。ソフトウェア テスト計画の助けを借りて、テストに関わるプロジェクト メンバー、特にテスト マネージャーは、テスト タスクとテスト方法を明確にし、テスト実施プロセスでの円滑なコミュニケーションを維持し、テストの進行状況を追跡および管理し、テスト プロセスのさまざまな変更に対処することができます。
テスト計画の作成 6 つの要素 (5W1H):
Why - これらのテストが実行される理由。
何を - どのような側面をテストするか、さまざまな段階での作業内容。
いつ - さまざまなステージの開始時間と終了時間をテストします。
どこ - 対応する文書、欠陥の保管場所、テスト環境など。
誰 - プロジェクトの関連要員の構成、どのテスターがテストのために手配されるか。
どのようにするか、どのように行うか、テストに使用するテスト ツールとテスト方法
テスト計画とテスト仕様およびテスト ケースの間には戦略的および戦術的な関係があります。テスト計画は主にマクロの観点からテスト アクティビティの範囲、方法、リソースの割り当てを計画しますが、テスト仕様とテスト ケースはテスト タスクを完了するための具体的な戦術です。したがって、最も重要なことは、テスト戦略とテスト方法をテストすることです (最初に復習できることが最善です)。
23. ブラックボックス テストのテスト ケースの一般的な設計方法は何ですか? テスト ケースの設計におけるこれらの方法の適用を説明するために、具体的な例を使用してください。
1) 同値クラス分割: 同値クラスは入力フィールドのサブセットを指します。このサブセットでは、各入力データはプログラム内のエラーを明らかにすることに相当します。次のことを仮定するのが合理的です: 特定の同値クラスの代表値をテストすることは、このクラスの他の値をテストすることと同じです。したがって、すべての入力データは合理的にいくつかの同値クラスに分割でき、少量の代表テスト データを使用してより良いテスト結果を得ることができます。同値クラス分割には 2 つの異なる値があります。状況: 有効な同値クラスと無効な同値クラス。
2) 境界値解析法：同値クラス分割法を補足するものです。テスト業務の経験から、入出力範囲内ではなく、入出力範囲の境界で多くのエラーが発生することがわかっているため、さまざまな境界条件に合わせてテスト ケースを設計することで、より多くのエラーを検出できるようになります。
境界値解析手法を使用してテスト ケースを設計する場合は、最初に境界条件を決定する必要があります。通常、テストに重点を置く必要がある境界条件は、入力および出力の同値クラスの境界です。同値クラス内の典型的な値や任意の値ではなく、境界と完全に等しい、ちょうど大きい、または小さい値がテスト データとして選択される必要があります。
3) エラー推測方法: 経験と直観に基づいて、プログラム内で考えられるすべてのエラーを推測し、的を絞った方法でテスト ケースを設計します。
エラー推測手法の基本的な考え方: プログラム内で考えられるすべてのエラーと、エラーが発生しやすい特殊なケースをリストアップし、それに応じてテストケースを選択します。たとえば、単体テスト中にモジュールでよくあるエラーが多数リストアップされています。以前の製品テストで見つかったエラーなど。これらは経験の要約です。また、入力データと出力データが 0 です。入力フォームが空白または入力フォームが 1 行しかありません。
4) 因果関係図法: 上記で紹介した同値クラス分割法や境界値分析法は、いずれも入力条件の考慮に重点が置かれており、入力条件間の関係や相互の組み合わせなどは考慮されていません。入力条件の相互の組み合わせを考慮すると、新たな状況が生じる可能性があります。しかし、入力条件の組み合わせを確認することは容易ではありません。すべての入力条件を同値クラスに分割したとしても、それらの間の組み合わせは非常に多く存在します。因果関係図(ロジックモデル)を使用する必要があります。因果関係図法の最終結果は決定表であり、プログラムの入力条件のさまざまな組み合わせをチェックするのに適しています。
5) 直交テーブル分析手法: 多数のパラメータの組み合わせにより、テスト ケースの数が急激に増加する可能性がありますが、これらのテスト ケースには明らかな優先順位のギャップがなく、テスト担当者はそれほど多くのテストを完了することはできません。
6) シナリオ分析手法: ユーザーのシナリオに従ってユーザーの操作ステップをシミュレートすることを指し、特性特性図に似ていますが、実行の深さと実現可能性がより優れている可能性があります。
7) 状態図法: 入力条件とシステム要件の記述を通じてテスト対象システムのすべての状態を取得し、入力条件と状態を通じて出力条件を取得し、入力条件、出力条件および状態を通じてテスト対象システムのテスト ケースを取得します。
8) アウトライン法: アウトライン法は要件に着目した方法であり、さまざまなテスト条件を列挙するために、要件をアウトラインに変換します。アウトラインは、ルートと各リーフ ノードの間に一意のパスを持つツリー構造として表されます。アウトライン内の各パスは、テスト ケースの定義に使用される特定の入力条件のセットを定義します。ツリー内のリーフまたはアウトライン内のパスの数から、すべての機能をテストするのに必要なテスト ケースのおおよその数がわかります。
24. テストアクティビティの完全なプロセスを詳細に説明します。(参考までに、この回答は主にウォーターフォールモデルの実践です)
プロジェクトマネージャーは顧客とコミュニケーションをとりながら要件書を完成させ、開発者とテスターが共同で要件書のレビューを行いますが、レビュー内容としては、要件の記述が不明瞭な箇所や、明らかな矛盾や実現不可能な機能が存在する可能性がある箇所などがあります。プロジェクトマネージャーは、開発者、テスター、顧客の意見を統合してプロジェクト計画を完成させます。その後、SQA がプロジェクトに入り、統計と追跡を開始します。
開発者は要求書に従って要件分析書を完成させ、テスターは両者の認識漏れや認識の相違がないかを主なレビュー内容とします。テスターはテスト計画文書を完成させます。テスト計画に含まれる内容は上記で説明されています。
テスターは修正された要件分析書に従ってテストケースの作成を開始し、開発者は概要設計書と詳細設計書を完成させます。これら 2 つのドキュメントは、テスターがテスト ケースを作成するための補助資料になります。
テスト ケースが完了したら、テストと開発をレビューする必要があります。
テスターが環境を構築する
開発者は最初のバージョンを提出しますが、説明が必要な未完成の機能がある可能性があります。テスターはテストを実施し、バグを発見した後、BugZilla に送信します。
開発者はバグ修正や機能追加を含む第2版を提出し、テスターがテストを実施します。
上記の作業を繰り返すと、通常 3 ～ 4 バージョン後に BUG の数が減り、出荷要件が満たされます。
顧客から問題が報告された場合、テスターは再現と再テストを支援する必要があります。
26. BUG管理ツールの追跡プロセス（例としてBugZillaを使用）
テスターは BUG を見つけて Bugzilla に送信します。ステータスは新規です。BUG の受信者は開発インターフェイス担当者です。
開発インターフェースは該当モジュールの開発者にBUGを割り当て、ステータスを「割り当て済み」に変更し、開発者とテスターがBUGを確認し、自分のBUGであれば受け取るように設定し、他の開発者の問題であれば次の開発者に転送します。
開発者がバグを受け入れて変更した場合は、バグのステータスを修正済みに変更し、テストをテストできるバージョンを通知します。
テスターは新しいバージョンでテストを行い、問題がまだ存在することが判明した場合は検証が拒否され、問題が修正された場合はバグがクローズされます。
27. テスターと開発者の間のコミュニケーションのプロセスにおいて、コミュニケーションの効率と効果を高めるにはどうすればよいと思いますか? テスターと開発チームの他のメンバーの間で良好な人間関係を維持するための鍵は何ですか?
対面でのコミュニケーション、次に電話での直接コミュニケーションを心掛け、メールなどタイムリーでないコミュニケーションツールでしかコミュニケーションが取れない場合には、その特性を深く理解し、明確に表現できる必要性を強調しましょう。
また、TestDirector などのテスト管理ツールを使用して管理するとより効果的ですが、TestDirector には BUG に関する正確な記述があることに注意してください。
チーム内のテスターと開発者の間で良好なコミュニケーションを確立するには、次の点に注意してください。
1 つは誠実さ、2 つ目はチームスピリット、3 つ目は職業上の共通言語を持つこと、4 つ目は人ではなく物事について正しく、仕事を第一に行うことです。
もちろん、バグ追跡システムに入る代わりに、小さな問題を直接指摘することで、相手の好感度を高めることもできます。
28. テストに最も興味があるのはどこですか?その理由は何ですか?
この面接の質問に対する明確で統一された答えはありませんが、多くの企業で尋ねられる可能性があります。検討のために次の回答を提供してください。
最大の関心、これはやりがいのある仕事だと感じていること。
テストは経験産業であり、長く働けば働くほど、テストで良い仕事をすることの難しさと楽しさは増します。
自分の仕事を通じて、ソフトウェア製品をどんどん完成させ、その楽しさを体験することができます。
これらの質問に答えるときは、次の点に注意してください。
可能な限り採用企業の技術ルートに合わせて興味を表明し、例えばデータベースアプリケーション会社であればデータベースのテストに興味があり、テストを通じてデータベースの習熟度を向上させたいと考えています。
テストの目的は、あなたの能力を向上させ、より良いテストを行うことであることを示し、雇用主がそのような取り決めをしていない限り、能力の向上は将来の能力開発やその他の目的のためではありません。
求人企業の範囲を超えて興味を表明しすぎないでください。たとえば、人材紹介会社は金融関連のソフトウェアを扱っているが、あなたはゲーム ソフトウェアに興味を示している、または人材紹介会社は JAVA 開発を行っており、あなたは C 言語プログラムの開発に興味を示しているなどです。
29. テストの利点は何だと思いますか?
この面接に決まった答えはありませんが、以下の点を参考に自分の特徴を組み合わせてみてください。
回復力があり、忍耐強く、組織的で、課題に直面するのが好きで、すべてをうまくやる自信があり、強力なコミュニケーションスキルがあり、以前のマネージャーから良いコメントを受けており、私がうまくやっていることがわかります 33. これまでの仕事で何をしてきたか、そして何に精通しているかを簡単に説明してください
。参考回答は以下の通りです。
これまでの私の主な仕事は、システムテストと自動化テストでした。システムテストでは、主にBOSSシステムのビジネスロジック機能とソフトスイッチシステムのクラス5特性をテストします。パフォーマンステストでは主にストレステストを実施し、さまざまなリクエスト数におけるシステムの応答時間やシステムリソース消費量を取得します。自動テストは主に、自作のスクリプトといくつかのサードパーティ ツールを組み合わせてソフトスイッチの特性をテストすることです。
テストでは、ユーザーのニーズを正確に理解することが非常に重要だと感じています。さらに、BUG の管理は要件に基づいて行う必要があり、すべての BUG を変更する必要はありません。
新しいバージョンでは、最初に発見されたバグのほとんどは修正されていますが、本来の正しい機能が正しくなくなる可能性があるため、テスト作業には忍耐と細心の注意が必要です。したがって、反復テストと回帰テストに注意してください。
34. C/C++ における static の用途は何ですか? (少なくとも 2 つ説明してください)
1) 関数本体で、static として宣言された変数は、関数の呼び出し中にその値を維持します。
2) モジュール内 (ただし関数本体の外) では、static として宣言された変数は、モジュール内で使用される関数からアクセスできますが、モジュール外の他の関数からはアクセスできません。ローカルグローバル変数です。
3) モジュール内で、static として宣言された関数は、このモジュール内の他の関数からのみ呼び出すことができます。つまり、関数は、それが宣言されているモジュールのローカル スコープに制限されます。
35. 参照とポインターの違いは何ですか?
1) 参照は初期化する必要がありますが、ポインタは初期化しません。
2) 参照は初期化された後は変更できませんが、ポインタは指すオブジェクトを変更できます。
3) null への参照はありませんが、null へのポインタは存在します。
36. インターネットではどのネットワーク プロトコルが使用されていますか? プロトコルの主な階層構造は何ですか? インターネットの物理アドレスと IP アドレスの変換にはどのプロトコルが使用されていますか?
TCP/IP プロトコルの主な階層構造は、アプリケーション層/トランスポート層/ネットワーク層/データリンク層です。
ARP (アドレス解決プロトコル)
37. 統合テストにおけるトップダウン統合とボトムアップ統合という 2 つの戦略についての理解を教えてください。それぞれの長所と短所、および主にどのタイプのテストに適しているかについて話してください。
トップダウンの統合
利点: 主要な制御ポイントと判断ポイントがより早期に検証される; 完全なソフトウェア機能が最初に深さに従って実現および検証される; 機能がより早期に検証されるため、信頼性がもたらされる; 必要なドライバーは 1 つだけであり、ドライバー開発コストが削減される; 障害の分離がサポートされる。
短所: ピラーの大量の開発、低レベルの検証が遅れる、低レベルのコンポーネントが十分にテストされていない。
製品制御構造は比較的明確で安定しています。上位インターフェイスはほとんど変更されません。下位インターフェイスは未定義であるか、頻繁に変更される可能性があります。生産および港湾制御コンポーネントには比較的高い技術的リスクがあり、できるだけ早く検証する必要があります。製品のシステム機能の動作をできるだけ早く確認できることが望まれます。
2. ボトムアップの統合
利点: 基礎となるコンポーネントの動作を早期に検証できること、作業を最初に並行して統合できるため、トップダウンより効率的であること、スタブの作業負荷が軽減されること、障害の分離がサポートされていること。
短所: ドライバーの開発負荷が高く、高レベルの検証が遅れ、設計ミスの発見が間に合わない。
低レベル インターフェイスへの適応は比較的安定していますが、高レベル インターフェイスは頻繁に変更され、低レベル コンポーネントはより早く完了します。
38. ソフトウェア受け入れテストには、正式な受け入れテスト、アルファ テスト、ベータ テストが含まれます。
39. システム テストには、パフォーマンス テスト、負荷テスト、強度テスト、ユーザビリティ テスト、セキュリティ テスト、構成テスト、インストール テスト、ドキュメント テスト、障害回復テスト、ユーザー インターフェイス テスト、回復テスト、配布テスト、ユーザビリティ テストなど、多くの戦略があります。
40. システム テスト計画を設計するときに参照する必要があるプロジェクト ドキュメントには、ソフトウェア テスト計画、ソフトウェア要件成果物、および反復計画が含まれます
。特性要因図を使用してテスト ケースを生成する基本的な手順は次のとおりです。
§ 原因 (つまり、入力条件または入力条件の同等のクラス) であり、結果 (つまり、出力条件) であるソフトウェア仕様の記述を分析し、それぞれの原因と結果に識別子を割り当てます。
§ ソフトウェア仕様の記述の意味を分析し、原因と結果、原因と原因の対応関係を調べ、それらの関係に従って、因果関係図を描きます。
§ 文法的または環境的な制約により、原因と原因の組み合わせ、および原因と結果の間の組み合わせの中には不可能なものもあります。これらの特殊なケースを示すために、因果図上に制約または制限が記号でマークされます。§ 因果関係図を意思決定表に変換します。
§ 判定表の各列を基にしてテストケースを設計します。
43. これらのテストは誰が行うのが最も適しているのか、また何のためにテストされるのか教えてください。
コードおよび関数レベルのテストは通常、ホワイトボックス テスターによって行われ、各コードまたは関数の正確性をチェックして、指定された関数が正しく実装されているかどうかを確認します。
モジュールおよびコンポーネント レベルのテストの主な基礎は、プログラム構造設計とテスト モジュール間の統合と呼び出し関係であり、これは通常、テスターによって完了されます。
システムテストはモジュールテストと単体テストに基づいて行われます。システムの機能と性能を理解し、テストケースに基づいて総合的なテストを実施します。
44. テスト ケースを設計するときにどのような側面を考慮する必要がありますか。つまり、どの側面がさまざまなテスト ケースによってテストされますか?
テストケースを設計する際には、全体のプロセスや機能だけでなく、強度テスト、性能テスト、ストレステスト、境界値テスト、安定性テスト、セキュリティテストなどの側面にも注意を払う必要があります。(テストケースで考慮すべき基本要素は入力、出力、操作、テスト環境の4つ。さらにテストケースはテストの種類(機能、性能、セキュリティ...)を考慮する必要があるが、この部分はTPを参照することで解決できる。また、ユースケースの重要性や優先度も考慮する必要がある) 45. Windowsでテキストファイルを保存する際、保存ダイアログが表示される。ファイル名に対してテストケースを作成する場合、等価クラスはどのように分けるべきか
？
A などの半角文字、全角文字、AA、I I、特殊文字 /'。';、=- など、com などの予約語、ファイル形式が 8.3 形式である、ファイル名形式が 8.3 形式ではない、/、\、* などの 9 個の特殊文字。
46. 10文字の郵便番号の入力を必要とするテキストボックスがあると仮定すると、テキストボックスはどのように等価クラスに分割されるべきですか?
10 * や ¥ などの特殊文字、ABCDefghik などの英字、123 などの 10 文字未満の文字、11111111111 などの 10 文字を超える文字、123AAAAAAAA などの数字とその他の混合文字、空文字、予約文字 47. ソフトウェア テスト プロジェクトはいつ開始されましたか? なぜですか
?
ソフトウェアテストは、プログラムのコーディングだけでなく、ソフトウェアの開発過程で作られるすべての製品をテストする必要があるため、要件分析の段階で行う必要があり、ソフトウェアの欠陥は拡大する傾向があり、欠陥の発見が遅くなるほど修正コストが高くなります
。
回帰テスト: (回帰テスト): 回帰テストには、ユース ケース回帰とエラー回帰の 2 種類があります。ユース ケース回帰は、一定期間後に以前に使用したユース ケースに戻って再テストし、問題が再び見つかるかどうかを確認することです。バグリグレッションとは、以前のバージョンで発生し修正された不具合を新バージョンで再検証し、その不具合を核として該当する修正部分をテストする手法です。
49. 単体テスト、統合テスト、システムテストの焦点は何ですか?
単体テストは、ソフトウェア設計の最小単位であるプログラムモジュール（プロセス指向では関数や手続き、オブジェクト指向ではクラス）を対象とし、正確性検査のテスト作業は、各プログラムモジュール内で起こり得るエラーを発見することを目的としています。一般に、手動による静的検査と動的実行追跡の2つのステップがあります。
結合テストは、単体テストを通過した各モジュールに統合されたコンポーネントをテストすることを目的としており、主な内容は各単位モジュール間のインターフェースと統合後の各モジュールが実現する機能です。
システムテストは、コンピュータシステム全体の要素として、コンピュータハードウェア、周辺機器、一部のサポートソフトウェア、データ、人員など他のシステム要素と組み合わされた統合ソフトウェアシステムを対象とし、コンピュータシステムを実際の運用環境で一連の統合テストや確認テストを実施する必要があります
。
1. 責任感 2. コミュニケーションスキル 3. チームワークの精神 4. 忍耐力、気配り、自信 5. 常に懐疑的な姿勢を持ち、不具合防止の意識を持つ 6. 一定のプログラミング経験がある 53: ソフトウェアテストの種類を知っていますか、簡単に紹介します
。
テスト戦略によって分類されます。 1. 静的テストと動的テスト 2. ブラック ボックス テストとホワイト ボックス テスト 3. 手動テストと自動テスト 4. スモーク テスト 5. 回帰テスト。
テストフェーズによって分類: 単体テスト、統合テスト、システムテスト。
その他の一般的なテスト方法: 1. 機能テスト 2. パフォーマンス テスト 3. ストレス テスト 4. 負荷テスト 5. ユーザビリティ テスト 6. インストール テスト 7. インターフェイス テスト 8. 構成テスト 9. ドキュメント テスト 10. 互換性テスト 11. セキュリティ テスト 12. リカバリ テスト 54: 優れたテスト計画の鍵は何だと思いますか
?
テストの目的を明確にし、テスト計画の実行可能性を高める
ソフトウェア テスト計画を作成する重要な目的は、テスト プロセスでより多くのソフトウェア欠陥を検出できるようにすることです。そのため、ソフトウェア テスト計画の価値は、テスト プロジェクトの管理と潜在的なソフトウェア欠陥の発見に役立つ能力に依存します。したがって、ソフトウェア テスト計画のテスト範囲は機能要件を高度にカバーし、テスト方法は実用的で、テスト ツールは非常に実用的で使いやすく、生成されるテスト結果は直感的で正確でなければなりません。
「5W」ルールを遵守し、内容とプロセスを明確にする
「5W」ルールとは、「What（何をするか）」、「Why（なぜ行うのか）」、「When（いつ行うか）」、「Where（どこで）」、「How（どうやって行うか）」のことを指します。「5W」ルールを使用してソフトウェア テスト計画を作成すると、テスト チームはテストの目的 (Why) を理解し、テストの範囲と内容 (What) を明確にし、テストの開始日と終了日 (When) を決定し、テストの方法とツール (How) を示し、テスト文書とソフトウェアの保存場所 (Where) を示すことができます。
レビューと更新のメカニズムを採用して、テスト計画が実際のニーズを満たしていることを確認します
テスト計画書を作成した後、レビューされていない場合は、テストチームに直接送信され、テスト計画書の内容が不正確であったり、テスト内容が省略されていたり、ソフトウェア要件の変更によりテスト範囲が増減したりする場合がありますが、テスト計画書の内容の更新が間に合わず、テスト責任者を誤解させます。
テスト計画を作成し、詳細仕様書、テストケースをそれぞれテストします。
詳細なテスト技術指標は独自に作成したテスト詳細仕様書に含める必要があり、テストチームがテストプロセスを実行するようにガイドするために使用されるテストケースは、独自に作成したテストケース文書またはテストケース管理データベースに配置する必要があります。テスト計画とテスト仕様およびテスト ケースの間には戦略的および戦術的な関係があります。テスト計画は主にマクロの観点からテスト アクティビティの範囲、方法、リソースの割り当てを計画しますが、テスト仕様とテスト ケースはテスト タスクを完了するための具体的な戦術です。
55: テストケース設計で良い仕事をするための鍵は何だと思いますか?
ホワイトボックス テスト ケース設計の鍵は、より少ないテスト ケースでできるだけ多くの内部プログラム ロジックの結果をカバーすることです。
ブラックボックス ユース ケース設計の鍵は、より少ないユース ケースでモジュールの出力インターフェイスと入力インターフェイスをカバーすることでもあります。完全なテストを実行し、最小限の使用例で妥当な時間内に最大限の問題を見つけることは不可能です
。 56: テストのキャリア開発の目標は何ですか?
テスト経験が豊富であればあるほど、テスト能力は高くなります。したがって、私のキャリア開発には、上級テストエンジニアに向けて一歩ずつ積み重ねる時間が必要です。また、最初の 3 年間でテストの経験を積み、常に自分自身を更新および修正し、テスト タスクで良い仕事をするという予備的なキャリア プランもあります。
57: テスト終了の基準は何ですか?
ミクロな観点からは、テスト計画に定義され、例えば、一定の性能でシステムが72時間問題なく動作すること、現在、バグ追跡システムにおいて、このバージョンには一般的な重大なバグがなく、共通バグの数が3件以下、バグ修復率が90％以上であることを確認した上で、開発管理者、テスト管理者、プロジェクト管理者が連名でバージョンリリースを承認します。
マクロについて言えば、ソフトウェアが完全に消滅した時点でテストは終了します。
59. 完全なテストセットはどの段階で構成されなければなりませんか?
実現可能性分析、需要分析、概要設計、詳細設計、コーディング、単体テスト、結合テスト、システムテスト、受け入れテスト 61. あなたが過去に働いていた会社のソフトウェア開発プロセスを知っていますか? もし知っているなら、完全な開発プロセスでどのようなタスクを完了する必要があるかを説明してください? これらのタスクを完了するためにどのような役割が使用されていますか? 以前のテスト
作業でどのような具体的なタスクに従事していましたか?
開発プロセス・・・要求調査（要求担当者）、要求分析（要求担当者）、概要設計（設計者）、詳細設計（設計者）、コーディング（開発者）
テストプロセス---要件レビュー、システムテスト設計、概要設計レビュー、結合テスト設計、詳細設計レビュー、単体テスト設計、テスト実行
テスト作業の全プロセスを行っており、テスト設計が得意
品質を決めるのはプロセスであり、ソフトウェアのプロセス改善はあくまでもソフトウェアの品質を向上させ、過去のさまざまな経験や教訓を蓄積することです。
62. テストケース設計の原則は何ですか? 現在の主なテストケース設計方法は何ですか?
代表性: 合理的と不合理、合法と違法、境界と境界を越える、および制限を含む、あらゆる種類の入力データ、操作および環境設定を表現し、カバーできること。
決定可能性: つまり、テスト実行結果の正確性は決定可能であり、各テスト ケースには対応する期待される結果が存在する必要があります。
再現性: つまり、同じテスト ケースに対して、システムの実行結果は同じである必要があります。
メソッドには、等価クラス、境界値、因果関係図、状態図、直交メソッド、アウトラインメソッドが含まれます
63. オブジェクト指向テストケース設計にはメソッドがいくつありますか? それらを実装するにはどうすればよいですか?
クラス内の各コンストラクターのテスト ケースのセットを設計する
複合クラスのクラス変数、インスタンス変数
複合クラスのさまざまなメソッド
事前条件と事後条件に基づいてテスト ケースを設計する
コード 64 に基づいてテスト ケースを設計します
。LoadRunner はどの 3 つのモジュールに分かれていますか? 各モジュールの主な機能について簡単に説明してください。
仮想ユーザー ジェネレーター: 足音の記録用
Mercury LoadRunner コントローラ: シナリオの作成、実行、監視に使用されます。
Mercury LoadRunner 分析: テスト結果の分析に使用されます
65. テストに対する最大の関心は何ですか?その理由は何ですか?
最大の関心事は、テストが難しくて挑戦的であるということです!テストを長く続けるほど、うまくテストすることが難しくなります。以前、良いテスト エンジニアになる方法について、心配のないテスト ネットワークに関する記事を見たことがあります。合計 11 と 12 のポイントがリストされていますが、その中には人間の性格に関係するものもあれば、後天的な努力が必要なものもあります。しかし、性格に関する 1 と 2 の点を除けば、私には自信がありません。他の点ではうまくいくと確信しています。
私が初めてテスト業界に入ったとき、私のテストに対する理解は、Wuyou Test の Web サイトで学んだ情報に基づいていました。当時、テストはうまくやるには多くのスキルが必要だったからです。始めるのは簡単でしたが、うまくやるのは難しく、開発よりもさらに難しかったです。当時は本当に開発をやりたかったのですが (専攻が好きだったので、基本的に学校の専門コースを欠席しませんでした)、しかし、テストが開発よりも難しくてやりがいがあることを見て、テストで良い仕事をしたいという私の意志が強くなりました。
テストのプロセス全体で非常に難しいと感じる点は 2 つあると思います (私にとって、難しいことに非常に興味があります)。1 つ目はテスト ケースの設計です。テストの本質はテスト ケースの設計にあるからです。バージョンがリリースされる前に、ユース ケースをよく書く必要があります。どのようなテスト方法を使用するか (つまり、テスト計画またはテスト戦略)。基本はそれほど単純ではなく、意識的な学習能力が必要です。Web サイト、Web サイトが内部でどのように機能するかを知るために必要な最も基本的な技術知識、Web サイトの仕組みなど、意識的な学習能力が必要です。バックグラウンドでユーザーのリクエストに応答するか、テスト環境を構築する方法、これらすべてを早い段階で学習する必要があります。テストを始める前に最低限の準備はできている、何が難しいか、要件の詳細が決まっていない、といった問題はユースケースを設計するときに見つかります。
2 番目はバグを見つける時間です。これはテスターにとって最も基本的なタスクです。一般に、ほとんどのバグは、テスト ケースに従ってテストを開始することで見つけることができます。テスト対象のバージョンに関する詳細情報を取得し、テスト ケースを補足し、バグをテストするために、テストが必要なバグがまだいくつかあります。そして、バグを見つけるにはどうすればよいでしょうか? テスト ケースが有効な場合にバグを見つけるには、注意力と忍耐力が必要です。バグはあらゆるユース ケースで見つかる可能性があり、エラーはあらゆる場所で発生する可能性があるため、テスト プロセス中に考え方を明確にする必要があります (テスト プロセスのデータ フローと結果を注意深く読み、その中にバグが見つかる必要があります)。バグの説明方法も非常に特殊です。バグはどのような状況で発生しますか? 条件が少し変化すると、バグは存在しません。バグを再現するための最小限の手順は何ですか? バグの法則は何ですか? 十分な知識があれば、開発者が最初に問題を特定するのを手伝うことができます。
66. どのようなタイプのソフトウェア テストに精通していますか? これらのさまざまなテスト タイプ (機能テスト、パフォーマンス テストなど) の違いと関連性を比較してみてください。
テストの種類には、機能テスト、パフォーマンス テスト、インターフェイス テストがあります。
機能テストはテスト作業の中で最も大きな割合を占めており、機能テストはブラック ボックス テストとも呼ばれます。テストオブジェクトをブラックボックスとして扱うことです。ブラックボックステスト手法を動的テストに使用する場合、ソフトウェア製品の内部構造や処理プロセスをテストすることなく、ソフトウェア製品の機能をテストする必要があります。ブラックボックス技術を使用してテストケースを設計する方法には、同値クラス分割、境界値分析、エラー推定、因果関係図、および包括的戦略が含まれます。
パフォーマンス テストは、自動テスト ツールを使用して、さまざまな正常、ピーク、および異常な負荷状態をシミュレートすることにより、システムのさまざまなパフォーマンス指標をテストします。負荷テストとストレス テストはどちらもパフォーマンス テストであり、組み合わせることができます。負荷テストを通じて、さまざまなワークロード下でのシステムのパフォーマンスを確認します。目標は、負荷が徐々に増加したときのシステムのさまざまなパフォーマンス指標の変化をテストすることです。ストレス テストは、システムのボトルネックまたは許容できないパフォーマンス ポイントを特定することにより、システムが提供できる最大のサービス レベルを取得するテストです。
インターフェイス テスト。インターフェイスはソフトウェアとユーザー間の対話の最も直接的な層であり、インターフェイスの品質によってソフトウェアに対するユーザーの第一印象が決まります。さらに、適切に設計されたインターフェイスは、ユーザーが対応する操作を自分で完了できるようにガイドし、ガイドの役割を果たすことができます。同時に、インターフェイスは人間の顔のようなものであるため、ユーザーを引き付けるという直接的な利点があります。適切にデザインされたインターフェースは、ユーザーに安心感、喜び、成功感をもたらしますが、逆に、インターフェース設計が失敗すると、ユーザーは不満を感じ、どれほど実用的で強力な機能であっても、ユーザーの恐怖と放棄によって無駄になる可能性があります。
違いは、機能テストでは製品のすべての機能に焦点が当てられ、すべての詳細な機能とあらゆる考えられる機能上の問題が考慮されることです。パフォーマンス テストは主に、全体としてマルチユーザーの同時実行下での製品の安定性と堅牢性に焦点を当てています。インターフェーステストはユーザーエクスペリエンスに重点が置かれており、製品が使いやすいか、理解しやすいか、標準化されているか（ショートカットキーなど）、美しいか（ユーザーの注意を引くことができるか）、安全か（ユーザーが意図せずに無効なデータをフォアグラウンドで入力しないようにする。もちろん、エクスペリエンスを考慮して、警告をポップアップするのはあまりにも失礼ではない）、単体テスト、結合テスト、システムテスト、受け入れテストの差分と接続
。
ブラックボックステスト: 製品の機能設計仕様がわかれば、実装された各機能が要件を満たしているかどうかを証明するためにテストを実行できます。
ホワイトボックステスト: 製品の内部作業プロセスがわかれば、各内部動作が設計仕様を満たしているかどうか、およびすべての内部コンポーネントがチェックされているかどうかを証明するためにテストできます。
ソフトウェアのブラックボックス テストとは、ソフトウェアのインターフェイスでテストが実行されることを意味します。この方法は、テスト対象をブラックボックスとみなして、テスタはプログラムの論理構造や内部特性を全く考慮せず、プログラムの機能がプログラムの要求仕様に従った機能記述に適合しているかどうかだけをチェックするものである。したがって、ブラック ボックス テストは、機能テストまたはデータ駆動テストとも呼ばれます。ブラック ボックス テストは、主に次の種類のエラーを検出することを目的としています。
1. 誤った機能や不足している機能はないか 2. インターフェース上で、入力は正しく受け付けられるか? 正しい結果が出力されるか 3. データ構造の誤りや外部情報(データファイルなど)へのアクセスエラーはないか 4. 性能は要件を満たしているか 5. 初期化エラーや終了エラーはないか
ソフトウェアのホワイトボックステストは、ソフトウェアの手順の詳細を詳細に検査することです。この方法では、テスト オブジェクトをオープン ボックスとみなします。これにより、テスターはプログラムの内部論理構造と関連情報を使用して、テスト ケースを設計または選択し、プログラムのすべての論理パスをテストできます。さまざまな時点でプログラムの状態を調べることにより、実際の状態が期待される状態と一致しているかどうかを判断します。したがって、ホワイト ボックス テストは、構造テストまたはロジック駆動テストとも呼ばれます。ホワイトボックステストでは主に次のようなプログラムモジュールをチェックします。
1. プログラム モジュールのすべての独立した実行パスを少なくとも 1 回テストします。
2. すべての論理的判断について、「真」を取る場合と「偽」を取る場合の 2 つの状況を少なくとも 1 回テストできます。
3. ループの境界内および実行の境界内でループ本体を実行します。
4. 内部データ構造等の妥当性をテストする。
単体テスト (モジュール テスト) は、テスト対象のコードの非常に特殊な小さな機能が正しいことを検証するために開発者によって作成された小さなコードです。一般に、単体テストは、特定の条件 (またはシナリオ) の下で特定の機能の動作を判断するために使用されます。
単体テストはプログラマ自身によって行われ、最終的に恩恵を受けるのはプログラマです。プログラマは関数コードを書く責任があると同時に、自分のコードの単体テストを書く責任もある、と言えます。単体テストは、このコードの動作が期待と一致していることを証明するために実行されます。
統合テスト (アセンブリ テスト、ジョイント テストとも呼ばれます) は、単体テストの論理的な拡張です。最も単純な形式では、テストされる 2 つのユニットが 1 つのコンポーネントに結合され、それらの間のインターフェイスがテストされます。この意味で、コンポーネントとは、複数のユニットが統合された集合体を指します。実際のプログラムでは、多くのユニットがコンポーネントに結合され、これらのコンポーネントはプログラムのより大きな部分に集約されます。このアプローチは、フラグメントの組み合わせをテストし、最終的にプロセスを拡張して、モジュールを他のモジュール グループでテストすることです。最後に、プロセスを構成するすべてのモジュールが一緒にテストされます。
システムテストは、テスト対象のサブシステムをテスト用の完全なシステムに組み立てることです。システム方式仕様書で規定された機能をシステムが本当に提供できるかを検証する有効な方法です。（共通共同デバッグテスト）
システム テストの目的は、最終ソフトウェア システムに対して包括的なテストを実施し、最終ソフトウェア システムが製品要件を満たし、システム設計に従っていることを確認することです。
受け入れテストは、ソフトウェアを展開する前の最後のテスト操作です。受け入れテストの目的は、ソフトウェアの準備が整い、エンド ユーザーがソフトウェアの意図した機能やタスクを実行するために使用できることを確認することです。
受け入れテストは、システムが意図したとおりに動作することを将来のユーザーに実証します。統合テストの後、すべてのモジュールが設計に従って完全なソフトウェア システムに組み立てられ、インターフェイスのエラーが基本的に排除され、ソフトウェアの有効性がさらに検証される必要があります。これが受け入れテストのタスクです。つまり、ソフトウェアの機能性能がユーザーの期待どおりであるかどうかです。
68. 開発者がバグではないと言ったらどう対処しますか?
開発者はこれはバグではないと言いましたが、2 つの状況があり、1 つは要件が決まっていないのでこれを行うことができるという状況と、この時点でプロダクト マネージャーを見つけて変更が必要かどうかを確認することができるという状況です。2 つ目は、「そのような状況は起こり得ないので、修正する必要はありません。この時点では、まず、バグの根拠ができる限りわかります。それがユーザーに発見されたり、何か問題が発生した場合、どのような悪い結果が発生しますか? プログラマはさまざまな理由を説明するかもしれませんが、その説明に反論することもできます。」それでもダメならこの問題を上げて開発担当者とテスト担当者に確認して、修正するなら変更する、修正したくないなら変更しないでください。実際にはバグではなく、私が推奨する方法で TD に書き込むだけなので、開発者が修正しなければ大きな問題は発生しません。バグであると判断された場合は、自分の立場を貫き、問題が最終的に確認されるようにしなければなりません。
69. ソフトウェアのテスト作業をチームで実行する必要があるのはなぜですか?
テストが行われていないソフトウェアは、リリース前にソフトウェアの品質を知ることが難しいため、ISOの品質認証と同様に、テストにも品質保証が必要となるため、ソフトウェアテストをチームで実施する必要があります。テストの過程でソフトウェアの問題が発見され、開発者に通知されて修正され、リリース間近のテストレポートからソフトウェアの品質を知ることができます。
71. テスト計画には何を含めるべきですか?
背景、プロジェクト概要、目的、テスト範囲、テスト戦略、分業、リソース要件、スケジュール、参考資料、共通用語、提出書類、リスク分析。
72. ソフトウェア業界の背景に基づいて、ソフトウェアのビジネスをどのように理解しますか?
ソフトウェアの機能と操作プロセスを理解するためにユーザー マニュアルを読んでください。ビジネス知識を補うためにビジネス専門書を読んでください。実際のユーザー データがある場合は、実際のデータを参照として使用できます。以前の使用例やバグ レポートを参照してください。ソフトウェアの使用プロセスでさらに考えてください。製品マネージャーとより多くのコミュニケーションを行ってください。
74. テストケースの役割を見つけるにはどうすればよいですか?
組織: 執筆、構成、機能範囲、再現性、追跡、テスト確認
76. 互換性テストとは? 互換性テストリストをテストに使用する例を教えてください。
主に、ソフトウェア製品のバージョン間の互換性を検証します。下位互換性と相互互換性を含みます。下位互換性とは、新しいバージョンのテスト ソフトウェアが以前のバージョンの機能を保持している場合を指します。また、相互互換性とは、共存する、関連するが同一ではない 2 つの製品間の互換性を検証することです。
77. あるソフトウェアをテストした結果、WIN98 上で動作が非常に遅いことが分かりました。ソフトウェアに問題があるのか、ソフトウェアとハードウェアの動作環境に問題があるのかをどのように見分けるのですか?
ソフトウェアの動作環境をご確認ください。要件を満たしていればプログラムに問題があり、要件を満たしていなければハードウェアシステムに問題がある 78.
要件テストの注意点は何ですか？
是否使用了公司的模板、文档内容是否符合规范、所有的需求是分级是否清析适当、所有的需求是否具有一致性、需求是否可行(即，该需求组合有解决方案)、需求可否用己知的约束来实现、需求是否足够(即，可以把它送到一个规范的开发组织，并有一个生产出所需要产品的合理的可能性)、所有的其它需求是交叉引用是否正确、用户描述是否清楚、是否用客户的语言来描述需求、每个需求描述是否清楚没有岐义，可以移交给一个独立的组去实现时也能理解、是否所有的需求都是可验证的、是否每条需求都具有独立性，即使发生了变化也不会影响其它需求、性能指标是否明确、非功能性需求是否得到充分表现、是否完整列出适用的标准或协议、标准和协议之间是否存在冲突
81、主键、外键的作用，索引的优点与不足?
回答: 主キー: テーブル内で一意の識別キーです。機能: エンティティの整合性を確保し、データベースの操作を高速化します。新しいテーブル レコードを追加すると、データベースは新しいレコードの主キー値を自動的に取得します。この値は、他のテーブルに記録されている主キーと繰り返すことはできません。データベースは主キー値の順序でレコードを表示します。主キーが設定されていない場合、レコードは入力された順序で表示されます。
外部キー: 主キーに従属し、2 つのテーブル間の接続を表します。役割: 外部キーを使用すると、冗長性を回避できます。
インデクスのメリットとしては、1. 一意のインデクスを作成することでテーブル内のデータの一意性を保証できる、2. データの取得速度が高速化、3. テーブル間の接続が高速化、4. グループ化とソートによるデータ取得の場合、グループ化とソートの時間を大幅に短縮できる、6. テーブル間のデータ取得が高速化できる。
デメリット: 1. インデックスの作成に時間がかかり、データ量の増加に伴ってインデックスの作成量も増加します、2. インデックスが物理的なスペースを占有する必要があります。
3. テーブル内のデータを変更する場合、インデックスも動的に保守する必要があるため、データ保守の速度が低下します。
84. パフォーマンステストのプロセスは何ですか?
1. テスト要件の分析 2. テスト計画の策定とレビュー 3. テストケースの設計と開発 4. テストの実行とモニタリング 5. テスト結果の分析 6. パフォーマンステストレポートの作成 7. テスト経験の要約 88. バグのライフサイクルを簡単に説明しますか
？
1. BUG を効果的に記録する 2. BUG テンプレートを使用する 3. BUG の優先度と重大度を評価する 4. BUG の寿命 5. BUG データベースを維持する
89. 欠陥記録には何を含めるべきですか?
欠陥の識別、欠陥の種類、欠陥の重大度、欠陥の可能性、欠陥の優先順位、欠陥のステータス、欠陥の原因、欠陥の原因、欠陥の原因; 91 どのようなタイプのソフトウェア テストに精通していますか? これらの異なるテスト タイプ (機能テスト、パフォーマンス テストなど) の違いと関連性を比較してみてください
。
ユーザビリティテスト インターフェースの使いやすさ、操作のしやすさなど
機能テスト - システムの機能要件の実現
セキュリティテスト - システムにセキュリティリスクや脆弱性があるかどうか
パフォーマンス テスト - 大規模な同時実行下でのシステムの応答速度と堅牢性
93. テスト計画をうまく進めるための鍵は何だと思いますか?
プロジェクトまたはシステムのビジネス要件を理解する
和项目经理协调好，了解项目的进度计划安排情况
95、您认为做好测试用例设计工作的关键是什么?
对业务和软件需求非常清楚，可以根据需求不同选择不同的测试用例设计
96、.您以往的工作中是否曾开展过测试用例的评审工作?如果有，请描述测试用例评审的过程和评审的内容。
评审计划->预审->评审;
评审内容主要是测试用例对软件需求的覆盖程度，对于相关边界是否考虑，是否针对复杂流程准备多套测试数据，是否有专门针对非功能性需求的测试。
98、您认为性能测试工作的目的是什么?做好性能测试工作的关键是什么?
关键是测试脚本的录制，测试时候测试环境的干净。
100、.您以往所从事的软件测试工作中，是否使用了一些工具来进行软件缺陷(Bug)的管理?如果有，请结合该工具描述软件缺陷(Bug)跟踪管理的流程。
CQ，也可以使用BugFree等免费工具。
101、.您如何看待软件过程改进?在您曾经工作过的企业中，是否有一些需要改进的东西呢?您期望的理想的测试人员的工作环境是怎样的?
将先进的经验或思想固化到过程中，通过过程改进和能力提高来改进软件质量。
TCP/IP五层协议：应用层、传输层、网络层、数据链路层、硬件层
感谢每一个认真阅读我文章的人，看着粉丝一路的上涨和关注，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：
① 2000多本软件测试电子书（主流和经典的书籍应该都有了）
② 软件测试/自动化测试标准库资料（最全中文版）
③ 项目源码（四五十个有趣且经典的练手项目及源码）
④ Python编程语言、API接口自动化测试、web自动化测试、App自动化测试（适合小白学习）
⑤ Python学习路线图（告别不入流的学习）
在我的QQ技术交流群里（技术交流和资源共享，广告进来腿给你打断）
グループ番号953306497 (注「csdn111」)の無料情報は、著者の 10 年以上のテスト キャリアのエッセンスです。一緒に技術を交換するマスター仲間もいます。
