001. ソフトウェアライフサイクル(prdctrm)
企画段階（プランニング）→要件分析（要求）→設計段階（デザイン）→コーディング（コーディング）→テスト（テスト）→運用保守（メインマシンの実行）
テストケース
ユースケース番号 テスト項目 テストタイトル 重大度レベル 前提条件 入力データ 実行ステップ 期待される結果
0002. 質問: テストでバグが見つかりましたが、開発マネージャーはバグではないと考えています。どのように解決すればよいですか?
まず、問題を提出するために欠陥管理ライブラリに送信します。
次に、判断の根拠と基準を取得するには、次のようにします。
要求仕様、製品説明、設計図書などに従って、実際の結果が計画と矛盾しているかどうかを確認し、欠陥を確認するための直接の根拠を提供します。
文書による根拠がない場合は、類似ソフトウェアの一般的な特性に基づいて欠陥があるかどうかを確認し、矛盾があるかどうかを説明できます。
ユーザーの一般的な使用習慣に従って、それが欠陥であるかどうかを確認するため。
設計者、開発者、顧客担当者などの関係者と協議し、欠陥であるかどうかを確認します。
合理的な議論を行い、判断の理由を試験監督に説明し、客観性と厳密さに注意を払い、個人的な感情を混ぜないでください。
テスト管理者が最終決定を下すのを待ちますが、それでも議論がある場合は、会社のポリシーで定められたルートを通じて上司に報告することができ、上司が決定を下します。
003. 質問: Web サイトがある場合、どのようにテストしますか?
まず、要件の説明や Web サイトのデザインなどの関連ドキュメントを見つけて、テスト要件を分析します。
テスト計画を作成し、テスト範囲とテスト戦略を決定します。これには通常、機能テスト、インターフェイス テスト、パフォーマンス テスト、データベース テスト、セキュリティ テスト、互換性テストが含まれます。
テスト ケースを設計します。
機能テストには次の側面が含まれますが、これらに限定されません。
リンクテスト。リンクが正しくジャンプするか、空のページや無効なページはないか、誤ったエラー メッセージが返されるかどうか。
関数のテストを送信します。
マルチメディア要素を正しくロードして表示できるかどうか。
多言語対応により、選択した言語が正しく表示されるかどうかなど。
インターフェイスのテストには次の側面が含まれますが、これらに限定されません。
ページのスタイルが統一されていて美しいかどうか
ページレイアウトは合理的か、キーコンテンツやホットコンテンツは目立つか
制御が正常に動作するかどうか
インストールする必要があるがインストールされていないコントロールについて、自動ダウンロードおよびインストールの機能を提供するかどうか
単語チェック
パフォーマンス テストでは通常、次の 2 つの側面が考慮されます。
応力試験; 荷重試験; 強度試験
データベースのテストは、実行する必要があるかどうかを具体的に判断する必要があります。データベースでは通常、接続、データ アクセス操作、データ コンテンツの検証を考慮する必要があります。
セキュリティテスト:
基本的なログイン機能をチェックします
システムクラッシュや権限リークを引き起こすオーバーフローエラーが発生したかどうか
SQL インジェクションなど、関連する開発言語の一般的なセキュリティ問題チェック。
高度なセキュリティ テストが必要な場合は、専門のセキュリティ会社の支援を受けるか、テストを外注するか、サポートを受けるようにしてください。
互換性テストでは、要件の説明の内容に従って、サポートされるプラットフォームの組み合わせが決定されます。
ブラウザの互換性。
オペレーティング システムの互換性。
ソフトウェアプラットフォームの互換性。
データベースの互換性
テストが実行され、欠陥が記録されます。テストスケジュールを合理的に調整および調整し、テストに必要なリソースを事前に取得し、管理システム (要件の変更、リスク、構成、テスト文書、欠陥レポート、人的リソースなど) を確立します。
定期的にテストを見直し、評価、要約し、テストの内容を調整します。
004. 検索エンジンに中国語の文字を入力すると、対応するドメイン名に解決される テストに LoadRunner を使用する方法。
テスト計画を策定し、テスト基準とテスト範囲を決定する
一般的なビジネス プロセスや珍しいビジネス プロセスなどをカバーする、典型的なシナリオのテスト ケースを設計します。
テスト ケースに従って、自動テスト スクリプトとシナリオを開発します。
テスト スクリプトの記録: 新しいスクリプト (Web/HTML プロトコル) を作成します。記録ボタンをクリックし、ポップアップ ダイアログ ボックスの URL に「about:blank」と入力します。開いているブラウザでの通常の操作プロセスの後、記録を終了します。 ; スクリプトをデバッグして保存すると、文字セットの関連付けに注意を払う必要がある場合があります。
テスト シナリオの設定: 主にシステムの平均トランザクション応答時間が通常の状況で標準を満たしているかどうか、システムがクラッシュするかどうか、テストの実行、テスト結果の取得、テスト結果の分析を判断するために、パフォーマンスのテスト シナリオを設定します。
005. 質問: 300 個のクライアントを持つクライアントと、サーバーに圧力をかける 300 個のクライアントを持つ 300 個のクライアントの違いは何ですか?
1 つのクライアント上に 300 人のユーザーがいると、クライアントのリソースがより多く占有され、テスト結果に影響します。スレッド間の干渉が発生し、一部の例外が発生する可能性があります。
1 つのクライアント上に 300 人のユーザーがいる場合は、より多くの帯域幅が必要になります。
IP アドレスの問題の場合は、IP スプーフを使用して、単一の IP アドレスへの最大接続数に対するサーバーの制限を回避する必要がある場合があります。
すべてのユーザーは 1 つのクライアント上に存在するため、分散管理の問題を考慮する必要はありません。ユーザーが異なるクライアントに分散している間は、コントローラーを使用してユーザーを異なるクライアント全体に展開することを検討する必要があります。同時に、対応する権限構成とファイアウォール設定も与える必要があります。
006. ソフトウェアの概念と特徴、ソフトウェアの再利用の意味、どのようなコンポーネントが含まれているのかを説明します。
ソフトウェアは、ハードウェア、コンピュータ プログラム、手順、ルール、およびコンピュータ システムの動作に関連する可能性のあるファイル、文書、データと相互依存するコンピュータ システムの別の部分です。
ソフトウェアの再利用（ソフトウェア再利用）とは、ソフトウェアの開発と保守のコストを削減するために、既存のソフトウェアに関するあらゆる種類の関連知識を利用して新しいソフトウェアを作成することです。ソフトウェアの再利用は、ソフトウェアの生産性と品質を向上させるための重要なテクノロジーです。初期のソフトウェアの再利用は主にコードレベルの再利用であり、再利用される知識はプログラムを指しますが、後にはドメイン知識、開発経験、設計上の決定、アーキテクチャ、要件、設計、コード、ドキュメントなどの関連するすべての側面を含むように拡張されました。
再利用可能なソフトウェアコンポーネントを一般に再利用コンポーネントと呼びます。
007. ソフトウェアのライフサイクルとそのモデルは何ですか?
ソフトウェアライフサイクル（ソフトウェアライフサイクル）は、ソフトウェアライフサイクル、生存期間とも呼ばれます。ソフトウェア開発の構想が形成され、開発されたソフトウェアが利用価値を失い消滅するまでの全過程を指します。一般に、ライフサイクル全体は計画（定義）、開発、運用（保守）の3つの期間で構成され、各期間はいくつかの段階に分かれています。各ステージには明確なタスクがあります。
周期モデル (典型的なタイプ):
ウォーターフォールモデル
ラピッド プロトタイピング モデル: ラピッド プロトタイピング モデルでは、要件分析段階でのソフトウェア要件の予備的ではあるが完全ではない分析と定義、およびソフトウェア システムのプロトタイプの迅速な設計と開発が可能になり、ユーザーに機能とパフォーマンスのすべてまたは一部を示すことができます。開発するソフトウェアのテストと評価、ユーザーはプロトタイプのテストと評価を行い、ソフトウェア要件を充実させ改良するための具体的な改善提案を行います。開発者はそれに応じてソフトウェアを変更および改善し、ユーザーが開発するまでソフトウェアの実装、テスト、およびメンテナンスを完了します。満足し承認されています。
反復モデル: 反復には、製品リリース (安定した実行可能な製品バージョン) をもたらすすべての開発アクティビティと、そのリリースを使用するために必要なその他すべての周辺要素が含まれます。ある意味、開発イテレーションは、要件分析、設計、実装、テストのワークフローなど、すべてのワークフローを一度に実行するプロセスです。本質的には、小さなウォーターフォール プロジェクトのようなものです。RUP は、すべての段階を反復に細分化できると考えています。各反復では、最終製品のサブセットであるリリース可能な製品が生成されます。
ライフサイクルのフェーズ:
ソフトウェアの計画と実現可能性の分析
需要分析
ソフトウェア設計
コーディング
ソフトウェアテスト
運用・保守
008. ソフトウェアテストとは? ソフトウェアテストの目的と原則
指定された条件下でプログラムを動作させて、プログラムのエラーを発見し、ソフトウェアの品質を測定し、設計要件を満たしているかどうかを評価するプロセス。
ソフトウェアテストの目的:
テストとは、プログラムを実行してバグを見つけることです
成功したテストケースは、これまで発見されていないバグを発見することにあります。
成功したテストとは、これまで発見されていないバグを発見したものです
製品が約束や宣伝どおりの機能を果たし、ユーザーがアクセスできる機能が明確に文書化されていることを確認してください。
製品がパフォーマンスと効率の要件を満たしていることを確認する
製品が堅牢でユーザー環境に適応できることを確認する
ソフトウェアテストの原則:
テスト ケースの必須部分は、予想される出力または
プログラマーは自分が書いたプログラムのテストを避けるべきです
ソフトウェアを作成する組織は、作成したソフトウェアをテストしてはなりません
各テストの実行結果を徹底的に確認する必要がある
テスト ケースは、有効で予期される入力だけでなく、無効で予期しない入力に対しても作成する必要があります。
プログラムが「本来の動作をしていない」ことをチェックするのはテストの半分にすぎず、テストの残りの半分はプログラムが「本来の動作を行っていない」ことを確認することです。
ソフトウェア自体が使い捨てのソフトウェアでない限り、使い捨てのテスト ケースは避けるべきです
テスト作業を計画するとき、バグは見つからないと暗黙のうちに想定すべきではありません。
プログラムの一部にさらに多くのバグがある確率。その部分ですでに見つかっているバグの数に比例します。
ソフトウェアテストは非常に創造的で知的にやりがいのある仕事です
009. ソフトウェア構成管理の役割は何ですか? ソフトウェア構成には何が含まれますか?
ソフトウェア構成管理 (SCM) は、変更を特定、整理、および制御するための技術です。ソフトウェア構成管理は、ソフトウェア エンジニアリング プロセス全体に適用されます。ソフトウェアを構築する際には変更は避けられず、変更はプロジェクト上のソフトウェア開発者の混乱を悪化させます。SCM 活動の目標は、変更を特定し、変更を管理し、変更が正しく実装されていることを確認し、他の関係者に変更を報告することです。ある意味、SCM は、エラーを最小限に抑えて生産性を最大化するために、変更を特定、整理、および制御するための手法です。
ソフトウェア構成には、構成項目の識別、ワークスペース管理、バージョン管理、変更管理、ステータスレポート、構成監査が含まれます。
010. ソフトウェアの品質とは何ですか?
一言で言えば、ソフトウェア品質とは「ソフトウェアが明示的および暗黙的に定義された要件にどの程度準拠しているか」です。具体的には、ソフトウェアの品質とは、ソフトウェアが明示的に記載された機能およびパフォーマンス要件、ドキュメントに明示的に記載された開発標準、および専門的に開発されたすべてのソフトウェアが持つべき暗黙の特性にソフトウェアがどの程度準拠しているかを指します。ソフトウェアの品質に影響を与える主な要因は、管理の観点からソフトウェアの品質を測定することです。ソフトウェア製品を使用する際のユーザーの 3 つの視点をそれぞれ反映する 3 つのグループに分類できます。正確性、堅牢性、効率性、完全性、使いやすさ、リスク（製品の運用）、理解性、保守性、柔軟性、テスト容易性（製品の変更）、移植性、再利用性、相互運用性（製品の移行）。
011. 現在の主なテストケース設計手法は何ですか?
ホワイトボックステスト: ロジックカバレッジ、ループカバレッジ、基本パスカバレッジ
ブラックボックステスト: 境界値分析、同値クラス分割、エラー推測、因果関係図、状態図、テスト概要、ランダムテスト、シナリオ
012. ソフトウェアのセキュリティはどのような側面からテストする必要がありますか?
ソフトウェア セキュリティ テストには、プログラムとデータベースのセキュリティ テストが含まれます。システムセキュリティ指標の違いに応じて、テスト戦略も異なります。
ユーザー認証のセキュリティテストで考慮すべき問題: システム内の異なるユーザー権限を明確に区別するか、システム内でユーザーの競合が発生するかどうか、ユーザー権限の変更によりシステムが混乱を引き起こすかどうか、ユーザーのログインパスワードが表示され、再現可能かどうか絶対的な方法 (ユーザーがログインした後にリンクをコピーしてシステムに直接入る) でシステムにログインすることが可能かどうか、ユーザーがシステムからログアウトした後にすべての認証マークが削除されるかどうか、可能かどうか戻るボタンを使用してパスワードを入力せずにシステムに入ることができ、システムのネットワークセキュリティのテストを考慮する必要があります。 質問、講じられた保護対策が正しく組み立てられているかどうか、関連するシステムパッチがインストールされているかどうかをテストし、不正な攻撃をシミュレートして、保護システムが強力で、成熟したネットワーク脆弱性検査ツールを使用してシステム関連の脆弱性をチェックします（つまり、最も専門的なハッカー攻撃ツールを使用して攻撃を試みます。現在最も一般的に使用されているのはNBSIシリーズとIPhacker IPです）、さまざまなトロイの木馬を使用しますシステムのトロイの木馬の状況をチェックするための検査ツール、システム内のプログラムの各グループのプラグインの脆弱性をチェックするためのさまざまなプラグイン対策ツールを使用する
データベースのセキュリティに関する考慮事項: システム データが機密であるかどうか (たとえば、銀行システムの場合、これは特に重要であり、一般的な Web サイトにはそれほど高い要件はありません)、システム データの整合性 (企業の実名を完了したばかりです)検証サービスシステム（データの不完全性により本システムの機能実現に支障がある）、システムデータの管理性、システムデータの独立性、システムデータのバックアップおよびリストアの可否（データのバックアップが完了しているか、バックアップできるか）復元できるかどうか、復元が完了できるかどうか）
013. テストケース、テストスクリプトとは何ですか? 両者の関係は何ですか?
テストの実施のためにテスト対象システムに提供される、特定の入力データ、操作またはさまざまな環境設定、および期待される結果のセット。
テスト スクリプトは、自動テスト用に作成されたスクリプトです。
テスト スクリプトの記述は、対応するテスト ケースに対応する必要があります。
014. 静的テスト、動的テスト、ブラック ボックス テスト、ホワイト ボックス テスト、アルファ テスト、ベータ テストとは何かを簡単に説明します。
静的テストは、プログラム自体を実行せずに、プログラム コード内の潜在的なバグを見つけたり、プログラム コードを評価したりするプロセスです。
動的テストとは、テスト対象のプログラムを実際に実行し、対応するテストインスタンスを入力し、実行結果と期待される結果との差異を確認し、実行結果が要件を満たしているかどうかを判断することにより、プログラムの正確性、信頼性、有効性を検証することです。プログラムを解析し、システムの動作効率や堅牢性などの性能を分析します。
ブラックボックステストは、ソフトウェア機能の正確性や操作性を確認するために一般的に使用され、入出力間の関係やプログラム機能の場合は、ソフトウェアの仕様に基づいてテストケースを決定し、テスト結果の正確性を推測します。
ホワイトボックステストは、ソフトウェアの論理構造の分析に基づいて実行され、コードベースのテストであり、テスターはプログラムコードを読み取るか、開発ツールのシングルステップデバッグを使用してソフトウェアの品質を判断します。一般的にブラックボックステストはプロジェクトマネージャーが行い、それを達成するためにプログラマーが開発を行います。
アルファテストは、ユーザーが開発環境で実施するテスト、または社内のユーザーが実際の運用環境を模擬して実施する管理テストであり、プログラマーやテスターが行うことはできません。
ベータテストとは、ソフトウェアの複数のユーザーが、1人または複数のユーザーの実際の使用環境下で実行するテストです。通常、開発者はテスト サイトには存在せず、プログラマーやテスターがベータ テストを行うことはできません。
015. ソフトウェア品質保証制度とは何ですか? 品質保証管理に関する国家規格とは何ですか? シリアル番号や正式名称は何ですか?
SQA は、(ソフトウェアの) 品質を保証するための一連のソフトウェア エンジニアリング プロセスと方法で構成されます。SQA はソフトウェア開発プロセス全体を通じて実行されます。それには、要件文書レビュー、コード管理、コードレビュー、変更管理、構成管理、バージョン管理、およびソフトウェアテストが含まれます。
ソフトウェア品質保証 (SQA-ソフトウェア品質保証) は、提案された標準、手順、実践および方法がすべてのプロジェクトに正しく採用されることを管理者が保証するための、計画的かつ体系的な方法を確立することです。ソフトウェア品質保証の目的は、ソフトウェア プロセスを管理者が見えるようにすることです。ソフトウェア製品と活動のレビューと監査を実施することにより、ソフトウェアが標準に準拠していることを検証します。ソフトウェア品質保証グループは、プロジェクトの開始時に計画、標準、プロセスの確立に関与します。これらにより、ソフトウェア プロジェクトが政府機関のポリシーの要件を満たすことが可能になります。
016. ソフトウェア製品の品質特性は何ですか?
機能: 適応性、正確性、相互運用性、コンプライアンス、セキュリティ。
信頼性: 成熟度、耐障害性、容易な回復。
ユーザビリティ: 理解しやすく、学びやすく、操作しやすい。
効率: 時間特性、リソース特性。
保守性: 分析の容易さ、変更の容易さ、安定性、テストの容易さ。
移植性: 適応性、設置の容易さ、コンプライアンス、交換の容易さ
017. ソフトウェアテストの戦略とは何ですか?
ソフトウェア テスト戦略: 特定のソフトウェア テスト標準およびテスト仕様の指導の下、テスト プロジェクトの特定の環境制約に従って規定されたソフトウェア テストの原則、方法、方法の集合。
018. いくつかの段階に分かれたソフトウェアテストのテスト戦略と要件は何ですか?
開発プロセスに対応して、テスト プロセスは、単体テスト、統合テスト、システム テスト、受け入れテストの 4 つの主要な段階を経ます。
単体テスト: 単体テストは、ソフトウェア設計の最小単位、つまり正確性をチェックするためのプログラム モジュールまたはコード セグメントのテスト作業であり、通常は開発者によって実行されます。
統合テスト: 統合テストは、テストの設計要件に従ってモジュールを組み立てることであり、主な目的はインターフェイスに関連する問題を見つけることです。製品をテスト部門に提出する前に製品開発チームは共同デバッグを実施する必要があるため、ほとんどの企業では統合テストは開発者によって行われます。
システム テスト: システム テストは、統合テストに合格した後に実行されます。目的は、システムを完全に実行し、各サブシステムが正常に動作し、設計要件を満たしているかどうかを確認することです。主にテスト部門で実施され、テスト部門の中で最も大規模かつ最も重要なテストであり、製品の品質に大きな影響を与えます。
受け入れテスト: 受け入れテストは、要求フェーズの「要求仕様書」を受け入れ基準とし、実際のユーザーの動作環境をシミュレートする必要があります。実際のプロジェクトの場合は顧客と一緒に実施できますし、製品の場合は最後のシステムテストになります。テスト内容は機能モジュールの総合テスト、特にドキュメントテストです。
単体テストのテスト戦略:
トップダウンの単体テスト戦略: 単独の単体テストよりもはるかにコストがかかるため、単体テストには適していません。
ボトムアップの単体テスト戦略: より合理的な単体テスト戦略ですが、テスト サイクルが長くなります。
単体テストの戦略: 最適な単体テスト戦略。
統合テストのテスト戦略:
Big Bang Integration: メンテナンス プロジェクトまたはテスト対象のシステムが小規模な場合に適しています
トップダウンの統合: 明確で安定した製品管理構造に適応します。上位レベルのインターフェイスはほとんど変更されません。下位レベルのインターフェイスは未定義であるか、頻繁に変更される可能性があります。生産および港湾管理コンポーネントには大きな技術的リスクがあり、これらを改善する必要があります。できるだけ早く検証されました; できるだけ早く検証されることを希望します 製品のシステム機能の動作を確認できます。
ボトムアップ統合: 最下位のインターフェイスは比較的安定していますが、高レベルのインターフェイスは頻繁に変更され、最下位のコンポーネントはより早く完成します。
進捗ベースの統合
利点: 高度な並列性があり、プロジェクトの開発進行を効果的に短縮できます。
短所: 杭とドライバーの作業負荷が大きい、一部のインターフェイス テストが不十分、一部のテストが繰り返し行われ無駄が多い。
システムテストのテスト戦略:
データおよびデータベースの整合性テスト、機能テスト、ユーザー インターフェイス テスト、パフォーマンス テスト、負荷テスト、強度テスト、容量テスト、セキュリティおよびアクセス制御テスト、フェイルオーバーおよび回復テスト、構成テスト、インストール テスト、暗号化テスト、可用性テスト、バージョン検証テスト;文書化テスト
019. ソフトウェアテストの各段階では通常どのような作業が行われますか?各段階の結果ファイルは何ですか?何が含まれますか?
単体テスト段階: 独立した各単体モジュールをシステムの他の部分から分離してテストし、各プログラム モジュールの正当性をチェックして、各プログラム モジュールが指定された機能を正しく実装しているかどうかを確認します。単体テストレポートを生成し、欠陥レポートを提出します。
統合テスト段階: 統合テストは単体テストに基づいており、すべてのソフトウェアユニットが対応する技術指標と必要なアクティビティを満たしているか、または実現しているかどうかをテストします。このフェーズでは、統合テスト レポートが生成され、欠陥レポートが送信されます。
システムテストフェーズ: 検証テストに合格したソフトウェアは、特定のコンピュータシステム全体の要素として使用され、コンピュータハードウェア、周辺機器、一部のサポートソフトウェア、データ、人員などの他のシステム要素と組み合わせて、実際の動作でテストされます。環境: コンピュータ システムの包括的な機能範囲。この段階では、テストの概要と欠陥レポートを提出する必要があります。
020. ソフトウェア開発プロセスにおけるテスターの仕事は何ですか?
1. システム内のバグをできるだけ早く発見します。
2. ソフトウェア開発プロセスにおける欠陥を回避します。
3. ソフトウェアの品質を測定し、システムの品質を保証します。
4. ユーザーのニーズに注意を払い、システムがユーザーのニーズを満たしていることを確認します。
全体的な目標は、ソフトウェアの品質を保証することです。
021. 以前の仕事では、ソフトウェア欠陥 (またはバグ) 記録には何が含まれていましたか? 高品質のソフトウェア欠陥 (バグ) 記録を提出するにはどうすればよいですか?
バグ記録には基本的に次の内容を含める必要があります。
バグ番号、バグの重大度レベル、優先度、バグが生成されたモジュール、まず、バグの一般的な内容を説明するバグの概要、バグに対応するバージョン、バグの詳細な説明が必要です。いくつかのスクリーンショット、ビデオなど、バグが発生したときのテスト環境、生成された条件は対応する操作手順、高品質のバグ記録:
- 一般的な UI は統一され、正確である必要があります。また、欠陥レポートの UI は、簡単に見つけて見つけられるように、テストされたソフトウェア UI と一致している必要があります。
- 正確な表現と専門性を確保するために、業界で一般的に使用されている用語と手法を使用するようにしてください。
- 各欠陥レポートには欠陥が 1 つだけ含まれます。各欠陥レポートには欠陥が 1 つだけ含まれるため、欠陥修正者は欠陥を迅速に特定し、一度に 1 つの欠陥のみを修正することに集中できます。検証者は、一度に欠陥が正しく修正されたかどうかのみを検証します。
- 再現不可能な欠陥も報告する必要がある まず、欠陥レポートは欠陥を再現できることを証明する必要があります。再現できない欠陥は可能な限り再現する必要があり、あらゆる努力をしても再現できない場合でも、その欠陥を報告する必要がありますが、その報告には、再現できない欠陥の発生頻度を示す必要があります。
- 欠陥の種類を明示 欠陥の現象に応じて、欠陥の種類を総合的に判断します。たとえば、機能上の欠陥、インターフェイスの欠陥、データの欠陥、合理化は、これが最も一般的な欠陥または欠陥のタイプであることを示唆しており、他の形式の欠陥または欠陥もいずれかの形式に従属していることを示しています。
- 欠陥の重大度と優先度を明確に示す 重大度と優先度の違いを常に明確にしてください。重大度の高い問題は修正する価値がない可能性があり、外観上の小さな問題は優先度が高いと考えられる場合があります
- 簡潔、正確、完全な説明は、欠陥の本質を明らかにし、欠陥または欠陥が発生する場所を記録します。説明は欠陥の本質を正確に反映し、短く明確でなければなりません。ソフトウェア欠陥管理データベース内の定式化されたテスト欠陥の検索を容易にするために、欠陥が発生したときにユーザー インターフェイス (UI) を含めることを習慣にしてください。たとえば、レコード ダイアログ ボックスのタイトル、メニュー、ボタンなどのコントロールの名前
- 短い行の間に自動デジタル シリアル番号を使用し、同じフォント、フォント サイズ、行間隔を使用します。 短い行の間に自動デジタル シリアル番号を使用し、同じフォント、フォント サイズ、行間隔を使用して、各レコードの形式が一貫していることを確認します。標準化と専門性を実現します。
- 操作ステップの簡潔さ、順序性、および簡単な繰り返しを確保するために、各ステップで操作を 1 つだけ記録するようにしてください。
- 不良を迅速かつ正確に繰り返すための確認手順は、「完了」は漏れがないこと、「正確」は手順が正しいこと、「短い」は冗長な手順がないことを意味します。 。
- 欠陥に応じて、画像キャプチャを行うかどうかを選択できます 欠陥や欠陥現象を目視で観察するには、通常、欠陥または欠陥が現れる界面を添付し、「添付」部分に添付する必要があります記録を画像の形式で添付します。スペースを節約し、欠陥または欠陥の本質を正確に反映するために、欠陥または欠陥が発生したときに全画面、アクティブウィンドウ、およびローカルエリアをキャプチャできます。欠陥や欠陥位置を迅速に特定して修正するには、通常、中国の管理マップを添付する必要があります。 必要な特別な文書と個人的な提案やコメントを添付する 特定の文書を開いたときに欠陥または欠陥が発生した場合、その欠陥または欠陥を迅速に再現できるように、その文書を添付する必要があります。場合によっては、欠陥または欠陥修正者に欠陥または欠陥のパフォーマンスをさらに明確にするために、個人的な修正提案やコメントを添付することができます。
- スペルと文法の欠陥を確認する 各欠陥を提出する前に、スペルと文法をチェックして、内容が正しく、欠陥が正しく説明されていることを確認してください。
- 複雑な文型を避け、できるだけフレーズや短い文章を使用する ソフトウェア欠陥管理データベースの目的は、欠陥の特定を容易にすることであるため、語彙や複雑な文型を変更することなく、操作手順を客観的に記述する必要があります可読性を高めるため。上記は、テストの欠陥を報告するための標準的な要件を要約したものですが、さまざまなソフトウェア テスト要件があり、テスターは長期間のテストの後、徐々に専門的な良い習慣を身につけ、対応するテスト経験を蓄積し、常に新しい仕様作成要件を追加します。さらに、他のテストエンジニアのテスト欠陥レポートを読んで研究したり、自分の過去のテスト欠陥レポートと比較して考えることで、常にスキルを向上させることができます。
- 欠陥の説明の内容 欠陥の説明の内容には、欠陥の操作手順、実際の結果、および期待される結果が含まれます。この操作手順により、開発者は欠陥を再現して修正することが容易になります。開発者の中には、欠陥を再現する能力が低い人もいます。指摘されている欠陥は理解していますが、再現することができません。特に、システムに慣れていない新規開発者にとっては、導入手順により、それらの再現が容易になります。実際の結果によって開発者は何が間違っていたのかを知ることができ、期待された結果によって開発者は正しい結果がどうあるべきかを知ることができます。
022. ソフトウェアテストの基本的な手法としてブラックボックステストとホワイトボックステストがありますが、それぞれのメリットとデメリットを教えてください！
ブラックボックス テストの利点は、比較的単純で、プログラムの内部コードや実装を理解する必要がないこと、ソフトウェアの内部実装とは何の関係もないこと、ユーザーの観点からは、それを知るのが簡単であることです。ユーザーがどの機能を使用するか、どのような問題が発生するか、ソフトウェア開発ドキュメントに基づいて、ドキュメント内のどの機能がソフトウェアによって実装されているかを知ることもでき、ソフトウェア自動テストを行うときに便利です。
ブラックボックス テストの欠点は、すべてのコードをカバーすることは不可能であり、カバー率が低く、コード量全体の 30% に達するだけであること、自動テストの再利用性が低いことです。
ホワイト ボックス テストの利点は、ソフトウェア テスターがコード カバレッジを増やし、コードの品質を向上させ、コード内の隠れた問題を発見できるようにすることです。
ホワイト ボックス テストの欠点は、プログラムを実行するにはさまざまなパスがあり、すべての実行パスをテストすることは不可能であること、テストはコードに基づいており、開発者が実行しているかどうかしかテストできないことです。正しいのですが、設計が正しいかどうかが分からず、一部の機能要件を見逃す可能性があり、システムが巨大な場合、テストのオーバーヘッドが非常に大きくなります。
023. 紙コップのテスト方法は？
機能: 水カップに水を入れて、漏れているかどうかを確認し、水が飲めるかどうかを確認します。
安全性: カップの中に毒物や細菌はありませんか?
信頼性: さまざまな高さから落としたカップの損傷の程度
携帯性: カップがさまざまな場所、温度、その他の環境でも正常に使用できるかどうか
互換性: カップにジュース、白湯、アルコール、ガソリンなどを入れることができるかどうか。
使いやすさ：カップは熱いか、滑り止めはあるか、飲みやすいか
ユーザーマニュアル: ユーザーマニュアルには、カップの使用法、制限事項、および使用条件が詳細に記載されていますか?
疲労試験：カップに水を入れ（ケース1）24時間放置し漏れ時間と状況を確認、ガソリンを入れて（ケース2）24時間放置し漏れ時間と漏れ状況等を確認します。
圧力テスト: 針を使用し、針に重りを加え続けて、どの程度の圧力が浸透するかを確認します。
024. テスト計画作業の目的は何ですか?テスト計画書の内容には何を含めるべきですか?その中で最も重要なのはどれですか?
ソフトウェア テスト計画は、テスト プロセスをガイドするプログラム的な文書です。
リーダーはテスト計画に従ってマクロ管理を実施し、それに応じたリソース割り当てなどを実行できます。
テスターは、プロジェクトのテスト全体の状況や、プロジェクトのテストのさまざまな段階で実行すべき作業などを理解できます。
他の担当者がテスターの作業内容を理解し、関連する協力作業を実行するのに便利です
製品概要、テスト戦略、テスト方法、テスト領域、テスト構成、テストサイクル、テストリソース、テストコミュニケーション、リスク分析などが含まれます。ソフトウェア テスト計画の助けを借りて、テストに関与するプロジェクト メンバー、特にテスト マネージャーは、テスト タスクとテスト方法を明確にし、テスト実装プロセスでの円滑なコミュニケーションを維持し、テストの進行状況を追跡および管理し、次のような問題に対処することができます。テストプロセスにおけるさまざまな変更。
テスト計画の作成 6 つの要素 (5W1H):
Why - これらのテストが実行される理由。
何を - どのような側面をテストするか、さまざまな段階での作業内容。
いつ - さまざまなステージの開始時間と終了時間をテストします。
どこ - 対応する文書、欠陥の保管場所、テスト環境など。
誰 - プロジェクトの関連要員の構成、どのテスターがテストのために手配されるか。
どのようにするか、どのように行うか、テストに使用するテスト ツールとテスト方法
テスト計画とテスト仕様およびテスト ケースの間には戦略的および戦術的な関係があり、テスト計画は主にマクロの観点からテスト アクティビティの範囲、方法、リソースの割り当てを計画しますが、テスト仕様とテスト ケースは具体的なものです。テストタスクを完了するための戦術。したがって、最も重要なことは、テスト戦略とテスト方法をテストすることです (最初に復習できることが最善です)。
025. ブラックボックス テストのテスト ケースの一般的な設計方法は何ですか? テスト ケース設計におけるこれらの方法の適用を説明するために、具体的な例を使用してください。
1) 等価クラス分割: 等価クラスとは、入力フィールドのサブセットを指します。このサブセットでは、各入力データはプログラムのエラーを明らかにすることに相当します。ある等価性をテストするには次のように仮定するのが合理的です。クラスはこのクラスの他の値のテストと等しいため、すべての入力データは合理的にいくつかの同値クラスに分割でき、各同値クラスの 1 つのデータがテストの入力条件として取られ、小さな代表的なテスト データの量 良好なテスト結果の取得 同値クラスの分割には、有効な同値クラスと無効な同値クラスの 2 つの異なる状況が考えられます。
2) 境界値解析法：同値クラス分割法を補足するものです。テスト業務の経験から、入出力範囲内ではなく、入出力範囲の境界で多くのエラーが発生することがわかっているため、さまざまな境界条件に合わせてテスト ケースを設計することで、より多くのエラーを検出できるようになります。
境界値分析手法を使用してテスト ケースを設計するには、最初に境界条件を決定する必要があります。通常、入力と出力の同値クラスの境界は、テストに重点を置く必要がある境界条件です。値が完全に等しい、同値クラス内の典型的な値や任意の値をテスト データとして選択するのではなく、境界よりわずかに大きいか小さい値をテスト データとして選択する必要があります。
3) エラー推測方法: 経験と直観に基づいて、プログラム内で考えられるすべてのエラーを推測し、的を絞った方法でテスト ケースを設計します。
エラー推測手法の基本的な考え方: プログラム内で考えられるすべてのエラーとエラーが発生しやすい特殊なケースをリストし、それらに基づいてテスト ケースを選択します。たとえば、単体テスト中にモジュール内の多くの一般的なエラーがリストされています。従来品 テストで見つかったエラー等、経験をまとめたものです また、入力データ、出力データが0である、入力フォームが空白、または入力フォームが1行しかない などの状況です。これらの状況を選択できます 次の例はテスト ケースとして使用されます。
4) 特性要因図法：上記で紹介した同値クラス分割法と境界値分析法は、いずれも入力条件を考慮することに重点を置いており、入力条件間の関係や相互の組み合わせなどは考慮していません。入力条件の組み合わせにより、新たな状況が生成される場合もありますが、入力条件の組み合わせを確認することは容易ではありません。すべての入力条件を同値類に分けたとしても、それらの組み合わせは非常に多く存在します。さまざまな条件の組み合わせを記述し、それに応じて複数のアクションを生成してテストケースの設計を検討するために、因果関係図（ロジックモデル）を使用する必要があります。因果関係図法の最終結果は、判定テーブルですので、様々な組み合わせのプログラム入力条件を確認するのに適しています。
5) 直交テーブル分析手法: 多数のパラメータの組み合わせによりテストケースの数が急増する可能性がありますが、これらのテストケースには明らかな優先順位の差がなく、テスターがこのようなテストを完了することはできません。多数のテストがあるため、直交表を使用していくつかのユースケースを削減し、できる限り少ないユースケースでできるだけ広い範囲をカバーできるようにすることができます。
6) シナリオ分析手法: ユーザーのシナリオに従ってユーザーの操作ステップをシミュレートすることを指し、特性特性図に似ていますが、実行の深さと実現可能性がより優れている可能性があります。
7) 状態図法: 入力条件とシステム要件の記述を通じてテスト対象システムのすべての状態を取得し、入力条件と状態を通じて出力条件を取得し、入力条件、出力条件および状態を通じてテスト対象システムのテスト ケースを取得します。
8) アウトライン法: アウトライン法は要件に着目した方法であり、さまざまなテスト条件を列挙するために、要件をアウトラインに変換します。アウトラインは、ルートと各リーフ ノードの間に一意のパスを持つツリー構造として表されます。アウトライン内の各パスは、テスト ケースの定義に使用される特定の入力条件のセットを定義します。ツリー内のリーフまたはアウトライン内のパスの数から、すべての機能をテストするのに必要なテスト ケースのおおよその数がわかります。
026. テストアクティビティの完全なプロセスを詳細に説明します。(参考までに、この回答は主にウォーターフォールモデルの実践です)
プロジェクトマネージャーは顧客とコミュニケーションをとりながら要件書を完成させ、開発者とテスターは共同で要件書のレビューを完了します レビュー内容には、要件の記述が不明瞭な箇所や、明らかな矛盾や実現不可能な箇所が含まれます機能。プロジェクトマネージャーは、開発者、テスター、顧客の意見を統合してプロジェクト計画を完成させます。その後、SQA がプロジェクトに入り、統計と追跡を開始します。
開発者は要求書に従って要件分析書を完成させ、テスターは両者の認識漏れや認識の相違がないかを主なレビュー内容とします。テスターはテスト計画文書を完成させます。テスト計画に含まれる内容は上記で説明されています。
テスターは修正された要件分析書に従ってテストケースの作成を開始し、開発者は概要設計書と詳細設計書を完成させます。これら 2 つのドキュメントは、テスターがテスト ケースを作成するための補助資料になります。
テスト ケースが完了したら、テストと開発をレビューする必要があります。
テスターが環境を構築する
開発者は最初のバージョンを提出しますが、説明が必要な未完成の機能がある可能性があります。テスターはテストを実施し、バグを発見した後、BugZilla に送信します。
開発者はバグ修正や機能追加を含む第2版を提出し、テスターがテストを実施します。
上記の作業を繰り返すと、通常 3 ～ 4 バージョン後に BUG の数が減り、出荷要件が満たされます。
顧客から問題が報告された場合、テスターは再現と再テストを支援する必要があります。
027. BUG管理ツールの追跡プロセス（例としてZen Taoを使用）
テスターは BUG を見つけて Bugzilla に送信します。ステータスは新規です。BUG の受信者は開発インターフェイス担当者です。
開発インターフェースは、該当モジュールの開発者にバグを割り当て、ステータスを割り当て済みに変更します。開発者とテストはバグを確認します。バグが自分のものの場合は受信するように設定され、他の開発者の問題の場合は、この動作を実行するかどうかは次の開発者次第です。問題がない場合は、議論して確認し、このバグを拒否し、その後テスターがこの問題をクローズする必要があります。
開発者がバグを受け入れて変更した場合は、バグのステータスを修正済みに変更し、テストをテストできるバージョンを通知します。
テスターは新しいバージョンでテストを行い、問題がまだ存在することが判明した場合は検証が拒否され、問題が修正された場合はバグがクローズされます。
028. テスターと開発者のコミュニケーションのプロセスにおいて、コミュニケーションの効率と効果を高めるにはどうすればよいと思いますか? テスターと開発チームの他のメンバーとの間で良好な人間関係を維持するための鍵は何だと思いますか?
対面でのコミュニケーション、次に電話での直接コミュニケーションを心掛け、メールなどタイムリーでないコミュニケーションツールでしかコミュニケーションが取れない場合には、その特性を深く理解し、明確に表現できる必要性を強調しましょう。
また、TestDirector などのテスト管理ツールを使用して管理するとより効果的ですが、TestDirector には BUG に関する正確な記述があることに注意してください。
チーム内のテスターと開発者の間で良好なコミュニケーションを確立するには、次の点に注意してください。
1 つは誠実さ、2 つ目はチームスピリット、3 つ目は職業上の共通言語を持つこと、4 つ目は人ではなく物事について正しく、仕事を第一に行うことです。
もちろん、バグ追跡システムに入る代わりに、小さな問題を直接指摘することで、相手の好感度を高めることもできます。
029. テストに関して最も興味があるのはどこですか?その理由は何ですか?
この面接の質問に対する明確で統一された答えはありませんが、多くの企業で尋ねられる可能性があります。検討のために次の回答を提供してください。
最大の関心、これはやりがいのある仕事だと感じていること。
テストは経験産業であり、長く働けば働くほど、テストで良い仕事をすることの難しさと楽しさは増します。
自分の仕事を通じて、ソフトウェア製品をどんどん完成させ、その楽しさを体験することができます。
これらの質問に答えるときは、次の点に注意してください。
可能な限り採用企業の技術ルートに合わせて興味を表明し、例えばデータベースアプリケーション会社であればデータベースのテストに興味があり、テストを通じてデータベースの習熟度を向上させたいと考えています。
テストの目的は、あなたの能力を向上させ、より良いテストを行うことであることを示し、雇用主がそのような取り決めをしていない限り、能力の向上は将来の能力開発やその他の目的のためではありません。
求人企業の範囲を超えて興味を表明しすぎないでください。たとえば、人材紹介会社は金融関連のソフトウェアを扱っているが、あなたはゲーム ソフトウェアに興味を示している、または人材紹介会社は JAVA 開発を行っており、あなたは C 言語プログラムの開発に興味を示しているなどです。
030. テストのメリットは何だと思いますか？
この面接に決まった答えはありませんが、以下の点を参考に自分の特徴を組み合わせてみてください。
回復力があり、忍耐強く、組織的で、課題に直面するのが好きで、何事もうまくやる自信があり、コミュニケーション能力が高く、前マネージャーからの良いコメントが私が順調に進んでいることを示しています
031. これまでの仕事で行ったことやよく知っていることを簡単に説明します。参考回答は以下の通りです。
これまでの私の主な仕事は、システムテストと自動化テストでした。システムテストでは、主にBOSSシステムのビジネスロジック機能とソフトスイッチシステムのクラス5特性をテストします。パフォーマンステストでは主にストレステストを実施し、さまざまなリクエスト数におけるシステムの応答時間やシステムリソース消費量を取得します。自動テストは主に、自作のスクリプトといくつかのサードパーティ ツールを組み合わせてソフトスイッチの特性をテストすることです。
テストでは、ユーザーのニーズを正確に理解することが非常に重要だと感じています。さらに、BUG の管理は要件に基づいて行う必要があり、すべての BUG を変更する必要はありません。
新しいバージョンでは、最初に発見されたバグのほとんどは修正されていますが、本来の正しい機能が正しくなくなる可能性があるため、テスト作業には忍耐と細心の注意が必要です。したがって、反復テストと回帰テストに注意してください。
032. C/C++ における static の用途は何ですか? (少なくとも 2 つ説明してください)
関数の本体で、static として宣言された変数は、関数の呼び出し全体でその値を維持します。
モジュール内 (ただし関数の外) では、static として宣言された変数には、モジュール内で使用される関数からアクセスできますが、モジュール外の他の関数からはアクセスできません。ローカルグローバル変数です。
モジュール内で、静的に宣言された関数は、そのモジュール内の他の関数からのみ呼び出すことができます。つまり、この関数は、それが宣言されているモジュールのローカル スコープに制限されます。
033 参照とポインタの違いは何ですか?
参照は初期化する必要がありますが、ポインタは初期化する必要はありません。
初期化後に参照を変更することはできませんが、ポインターはそれが指すオブジェクトを変更することができます。
null 値への参照はありませんが、null 値へのポインタは存在します。
034. インターネットではどのネットワーク プロトコルが使用されていますか? プロトコルの主な階層構造は何ですか? インターネットの物理アドレスと IP アドレスの変換にはどのようなプロトコルが使用されていますか?
TCP/IP プロトコルの主な階層構造は、アプリケーション層/トランスポート層/ネットワーク層/データリンク層です。
ARP (アドレス解決プロトコル) (アドレス解決プロトコル)
035. 統合テストにおけるトップダウン統合とボトムアップ統合という 2 つの戦略についての理解を話し、それぞれの長所と短所、およびどのタイプのテストが主に適しているかについて話します。
トップダウンの統合
利点: 主要な制御点と判断点をより早く検証できる; 深さ優先に従って、完全なソフトウェア機能を最初に実現および検証できる; 機能がより早く確認されるため、自信が得られる; 必要なドライバーは 1 つだけであり、ドライバー開発コストを削減する; 障害分離をサポートします。
短所: ピラーの大量の開発、低レベルの検証が遅れる、低レベルのコンポーネントが十分にテストされていない。
製品制御構造への適応は比較的明確で安定しています。上位レベルのインターフェイスはほとんど変更されません。下位インターフェイスは未定義であるか、頻繁に変更される可能性があります。生産および港湾制御コンポーネントには高い技術的リスクがあり、できるだけ早く検証する必要があります。 ; 製品のシステムの機能的な動作をできるだけ早く確認したいと考えています。
2. ボトムアップの統合
利点: 基礎となるコンポーネントの動作を早期に検証できること、作業を最初に並行して統合できるため、トップダウンより効率的であること、スタブの作業負荷が軽減されること、障害の分離がサポートされていること。
短所: ドライバーの開発負荷が高く、高レベルの検証が遅れ、設計ミスの発見が間に合わない。
低レベル インターフェイスへの適応は比較的安定していますが、高レベル インターフェイスは頻繁に変更され、低レベル コンポーネントはより早く完了します。
036. ソフトウェア受け入れテストには、正式受け入れテスト、アルファ テスト、ベータ テストが含まれます。
037. システムテストには、パフォーマンステスト、負荷テスト、強度テスト、ユーザビリティテスト、セキュリティテスト、構成テスト、インストールテスト、ドキュメントテスト、障害回復テスト、ユーザーインターフェイステスト、回復テスト、配布テスト、ユーザビリティテストなど、多くの戦略があります。テスト中。
038. システムテスト計画を設計する際に参照する必要があるプロジェクト文書には、ソフトウェアテスト計画、ソフトウェア要件成果物、および反復計画が含まれます。
039. 特性特性図を描いてテストケースを書く手順は、__、__、__、__、特性特性図から状態図への変換の5つのステップがあります。特性要因図を使用してテスト ケースを生成する基本的な手順は次のとおりです。
§ 原因 (つまり、入力条件または入力条件の同等のクラス) であり、結果 (つまり、出力条件) であるソフトウェア仕様の記述を分析し、それぞれの原因と結果に識別子を割り当てます。
§ ソフトウェア仕様の記述の意味を分析し、原因と結果、原因と原因の対応関係を調べ、それらの関係に従って、因果関係図を描きます。
§ 文法的または環境的な制約により、原因と原因の組み合わせ、および原因と結果の間の組み合わせの中には不可能なものもあります。これらの特殊なケースを示すために、因果図上に制約または制限が記号でマークされます。§ 因果関係図を意思決定表に変換します。
§ 判定表の各列を基にしてテストケースを設計します。
040. これらのテストを完了するのに最適な人物は誰ですか、またテストは何ですか?
コードおよび関数レベルのテストは通常、ホワイトボックス テスターによって行われ、各コードまたは関数の正確性をチェックして、指定された関数が正しく実装されているかどうかを確認します。
モジュールおよびコンポーネント レベルのテストの主な基礎は、プログラム構造設計とテスト モジュール間の統合と呼び出し関係であり、これは通常、テスターによって完了されます。
システムテストはモジュールテストと単体テストに基づいて行われます。システムの機能と性能を理解し、テストケースに基づいて総合的なテストを実施します。
041. テスト ケースを設計するときにどのような側面を考慮する必要がありますか。つまり、どの側面がさまざまなテスト ケースでテストされますか?
テストケースを設計する際には、全体のプロセスや機能だけでなく、強度テスト、性能テスト、ストレステスト、境界値テスト、安定性テスト、セキュリティテストなどの側面にも注意を払う必要があります。(テスト ケースで考慮する必要がある 4 つの基本要素は、入力、出力、操作、およびテスト環境です。さらに、テスト ケースではテストの種類 (機能、パフォーマンス、セキュリティ...) を考慮する必要があります。この部分は答えることができます。 TPを参照してください。また、ユースケースの重要性と優先順位も考慮する必要があります)
042. Windowsでテキストファイルを保存する際、保存ダイアログが表示されますが、そのファイル名でテストケースを作成する場合、同値クラスはどのように分ければよいでしょうか？
A などの半角文字、全角文字、AA、I I、特殊文字 /'。';、=- など、com などの予約語、ファイル形式が 8.3 形式である、ファイル名形式が 8.3 形式ではない、/,, * などの 9 個の特殊文字。
043. 10 文字の郵便番号の入力を必要とするテキスト ボックスがあると仮定すると、テキスト ボックスを同等のクラスにどのように分割する必要がありますか?
特殊文字（10 * や ¥ など）、英字（ABCDefghik など）、10 文字未満（123 など）、10 文字を超える文字（11111111111 など）、数字とその他の混合文字（123AAAAAAAA など）、空文字、予約文字
044. ソフトウェアテストプロジェクトはいつ始まりましたか?なぜですか?
テストの対象はプログラムのコーディングだけではなく、ソフトウェア開発プロセスで生成されるすべての製品をテストする必要があり、ソフトウェアの欠陥は拡大する傾向があるため、ソフトウェアテストは要件分析の段階で行う必要があります。修理にかかる費用が多ければ多いほど、費用も高くなります。
045.回帰テストとは何ですか?
回帰テスト: (回帰テスト): 回帰テストには、ユースケース回帰とエラー回帰の 2 種類があります。ユースケース回帰は、一定期間後に以前に使用したユースケースに戻って再テストし、問題が見つかるかどうかを確認することです。また。バグリグレッションとは、以前のバージョンで発生・修正された不具合を新バージョンで再検証し、その不具合を核として該当する修正部分をテストする手法です。
046. 単体テスト、結合テスト、システムテストの焦点は何ですか?
単体テストは、ソフトウェア設計の最小単位であるプログラムモジュール（プロセス指向では関数や手続き、オブジェクト指向ではクラス）を対象とし、各プログラムモジュール内に存在する可能性のあるエラーを発見する正当性チェックのテスト作業です。一般に、手動静的検査と動的実行追跡の 2 つのステップがあります。
結合テストは、単体テストを通過した各モジュールに統合されたコンポーネントをテストすることを目的としており、主な内容は各単位モジュール間のインターフェースと統合後の各モジュールが実現する機能です。
システムテストは、コンピュータシステム全体の要素として、コンピュータハードウェア、周辺機器、一部のサポートソフトウェア、データ、人員などの他のシステム要素と組み合わされた統合ソフトウェアシステムを対象としており、実際の動作環境で一連のテストを実行します。コンピュータシステム上の統合テストと検証テスト。
047. テストエンジニアが持つべき資質とは何ですか？
1. 責任感 2. コミュニケーション能力 3. チームワークの精神 4. 忍耐力、慎重さ、自信 5. 常に疑いの姿勢を持ち、不具合防止の意識を持つ 6. 一定のプログラミング経験がある
048: ソフトウェアのテストにはどのようなものがありますか? 簡単に紹介します。
テスト戦略によって分類されます。 1. 静的テストと動的テスト 2. ブラック ボックス テストとホワイト ボックス テスト 3. 手動テストと自動テスト 4. スモーク テスト 5. 回帰テスト。
テストフェーズによって分類: 単体テスト、統合テスト、システムテスト。
その他の一般的なテスト方法: 1. 機能テスト 2. パフォーマンス テスト 3. ストレス テスト 4. 負荷テスト 5. ユーザビリティ テスト 6. インストール テスト 7. インターフェイス テスト 8. 構成テスト 9. ドキュメント テスト 10. 互換性テスト 11. セキュリティ テスト 12 、回復テスト
049: テスト計画をうまく進めるための鍵は何だと思いますか?
テストの目的を明確にし、テスト計画の実行可能性を高める
ソフトウェア テスト計画を作成する重要な目的は、テスト プロセスでより多くのソフトウェア欠陥を検出できるようにすることです。そのため、ソフトウェア テスト計画の価値は、テスト プロジェクトの管理と潜在的なソフトウェア欠陥の発見に役立つ能力に依存します。したがって、ソフトウェア テスト計画のテスト範囲は機能要件を高度にカバーし、テスト方法は実用的で、テスト ツールは非常に実用的で使いやすく、生成されるテスト結果は直感的で正確でなければなりません。
「5W」ルールを遵守し、内容とプロセスを明確にする
「5W」ルールとは、「What（何をするか）」、「Why（なぜ行うのか）」、「When（いつ行うか）」、「Where（どこで）」、「How（どう行うか）」のことを指します。 」。「5W」ルールを使用してソフトウェア テスト計画を作成すると、テスト チームがテストの目的 (Why) を理解し、テストの範囲と内容 (What) を明確にし、テストの開始日と終了日 (When) を決定するのに役立ちます。 )、テストの方法とツール (How) を示し、テスト文書とソフトウェアの保管場所 (Where) を示します。
レビューと更新のメカニズムを採用して、テスト計画が実際のニーズを満たしていることを確認します
テスト計画書作成後、レビューされていない場合は、テストチームに直接送信され、テスト計画書の内容が不正確であったり、テスト内容が省略されていたり、変更によりテスト範囲が増減したりする可能性があります。ソフトウェア要件に記載されていないため、テスト計画の内容が時間内に更新されておらず、誤解を招く可能性があります。
テスト計画を作成し、詳細仕様書、テストケースをそれぞれテストします。
詳細なテスト技術指標は独自に作成したテスト詳細仕様書に含める必要があり、テストチームがテストプロセスを実行するようにガイドするために使用されるテストケースは、独自に作成したテストケース文書またはテストケース管理データベースに配置する必要があります。テスト計画とテスト仕様およびテスト ケースの間には戦略的および戦術的な関係があり、テスト計画は主にマクロの観点からテスト アクティビティの範囲、方法、リソースの割り当てを計画しますが、テスト仕様とテスト ケースは具体的なものです。テストタスクを完了するための戦術。
050: テストケース設計で良い仕事をするための鍵は何だと思いますか?
ホワイトボックス テスト ケース設計の鍵は、より少ないテスト ケースでできるだけ多くの内部プログラム ロジックの結果をカバーすることです。
ブラックボックス ユース ケース設計の鍵は、より少ないユース ケースでモジュールの出力インターフェイスと入力インターフェイスをカバーすることでもあります。最小限のユースケースで妥当な時間内に最大限の問題を見つける完全なテストは不可能
051: テストのキャリア開発の目標は何ですか?
テスト経験が豊富であればあるほど、テスト能力は高くなります。したがって、私のキャリア開発には、上級テストエンジニアに向けて一歩ずつ積み重ねる時間が必要です。また、最初の 3 年間でテストの経験を積み、常に自分自身を更新および修正し、テスト タスクで良い仕事をするという予備的なキャリア プランもあります。
052: テスト終了の基準は何ですか?
ミクロな観点から見ると、テスト計画で定義されています。たとえば、システムが一定のパフォーマンスの下で 72 時間スムーズに動作することです。現在、バグ追跡システムでは、このバージョンには一般的な重大なバグはありません。この数値は、一般的なバグの数が 3 未満、バグ修正率が 90% 以上のパラメータを設定し、開発マネージャー、テスト マネージャー、プロジェクト マネージャーが署名してバージョン リリースに同意します。
マクロについて言えば、ソフトウェアが完全に消滅した時点でテストは終了します。
053. 完全なテストセットはどの段階で構成されるべきですか?
実現可能性分析、要件分析、全体設計、詳細設計、コーディング、単体テスト、結合テスト、システムテスト、受け入れテスト
054. 以前働いていた会社のソフトウェア開発プロセスを知っていますか? もし知っている場合、完全な開発プロセスでどのようなタスクを完了する必要があるか説明してください? これらのタスクを完了するためのさまざまな役割は何ですか? 以前のテスト作業では、あなたは具体的にどのような仕事に従事してきましたか?その仕事のどの部分が最も得意ですか?
開発プロセス - 要件調査（要求者）、要件分析（要求者）、概要設計（設計者）、詳細設計（設計者）、コーディング（開発者）
テストプロセス - 要件レビュー、システムテスト設計、概要設計レビュー、統合テスト設計、詳細設計レビュー、単体テスト設計、テスト実行
テスト作業の全プロセスを行っており、テスト設計が得意
品質を決めるのはプロセスであり、ソフトウェアのプロセス改善はあくまでもソフトウェアの品質を向上させ、過去のさまざまな経験や教訓を蓄積することです。
055. テストケース設計の原則とは 現在、主なテストケース設計手法にはどのようなものがありますか?
代表性: 合理的と不合理、合法と違法、境界と境界を越える、および制限を含む、あらゆる種類の入力データ、操作および環境設定を表現し、カバーできること。
決定可能性: つまり、テスト実行結果の正確性は決定可能であり、各テスト ケースには対応する期待される結果が存在する必要があります。
再現性: つまり、同じテスト ケースに対して、システムの実行結果は同じである必要があります。
メソッドには、等価クラス、境界値、因果関係図、状態図、直交メソッド、アウトラインメソッドが含まれます。
056. オブジェクト指向のテストケース設計の手法は何通りあるのか?どうやって実現するのか?
クラス内の各コンストラクターのテスト ケースのセットを設計する
複合クラスのクラス変数、インスタンス変数
複合クラスのさまざまなメソッド
事前条件と事後条件に基づいてテスト ケースを設計する
コードに基づいてテスト ケースを設計する
057. LoadRunner は 3 つのモジュールに分かれていますか? 各モジュールの主な機能を簡単に説明してください。
仮想ユーザー ジェネレーター: 足音の記録用
Mercury LoadRunner コントローラ: シナリオの作成、実行、監視に使用されます。
Mercury LoadRunner Analysis: テスト結果の分析用
058. テストに最も興味があるのはどこですか?その理由は何ですか?
最大の関心事は、テストが難しくて挑戦的であるということです!テストを長く続けるほど、うまくテストすることが難しくなります。以前、良いテスト エンジニアになる方法について、心配のないテスト ネットワークに関する記事を見たことがあります。合計 11 と 12 のポイントがリストされていますが、その中には人間の性格に関係するものもあれば、後天的な努力が必要なものもあります。しかし、性格に関する 1 と 2 の点を除けば、私には自信がありません。他の点ではうまくいくと確信しています。
私が初めてテスト業界に入ったとき、私のテストに対する理解は、Wuyou Test の Web サイトから学んだ情報に基づいていました。当時は、テストをうまく行うには多くのスキルが必要であるという事実を目指していました。テストは簡単ではありますが、難しいですが、当時私は開発を本当にやりたかったのですが (専攻が好きだったので、基本的に学校の専門課程を欠席しませんでした)、しかしテストのほうが難しく、開発よりも大変だったので、テストでうまくやりたいという気持ちが強くなりました。
テストのプロセス全体で非常に難しく感じるポイントが 2 つあると思います (私にとって、難しいことに非常に興味があります)。1 つ目はテスト ケースの設計です。テストの本質はテスト ケースにあるからです。テスト ケース。設計の観点から言えば、バージョンが公開されるかなり前にユース ケースを作成する必要があります。どのようなテスト メソッドを使用して作成する必要がありますか? (つまり、テスト計画またはテスト戦略)。新しいタスクをテストするだけであれば、次のようになります。ビジネス要件を理解するために一定の時間を費やします。また、技術的基盤であるビジネス ニーズはよく理解されています (プロダクト マネージャーや開発者とより多くのコミュニケーションをとることで目標を達成できます)。しかし、技術的基盤はそれほど単純ではないため、意識的な学習能力が必要です。 , ウェブサイトなど、最も基本的な技術的な知識としては、ウェブサイトが内部的にどのように動作するか、バックグラウンドがユーザーのリクエストにどのように応答するか、テスト環境を構築する方法などを知る必要があり、これらは早い段階で学ぶ必要があります。テストを始める前に最低限の準備はできている、何が難しいか、要件の詳細が決まっていない、といった問題はユースケースを設計するときに見つかります。
2 番目はバグを見つける時間です。これはテスターにとって最も基本的なタスクです。一般に、ほとんどのバグは、テスト ケースに従ってテストを開始することで見つけることができます。中には、まだ理解する必要があるバグがいくつかあります。テスト プロセス。詳細情報を取得し、テスト ケースを追加し、バグをテストします。そして、バグを見つけるにはどうすればよいでしょうか? テスト ケースが有効な場合にバグを見つけるには、注意力と忍耐力が必要です。すべてのユース ケースでバグが見つかる可能性があり、あらゆる場所で間違いが発生する可能性があるため、テスト プロセス中に考え方を明確にする必要があります (データ フローとテスト プロセスの結果を注意深く読む必要があり、そこにバグが見つかります)。バグの記述方法も非常に特殊で、どのような状況でバグが発生するのか、少し条件が変わればバグは存在しない、バグを再現するための最低限の手順は何か、バグの法則とは何か、もしあなたは十分に優秀なので、開発者が最初に問題を特定するのを助けることができます。
59. どのタイプのソフトウェア テストに精通していますか? これらのさまざまなテスト タイプ (機能テスト、パフォーマンス テストなど) の違いと関連性を比較してみてください。
テストの種類には、機能テスト、パフォーマンス テスト、インターフェイス テストがあります。
機能テストはテスト作業の中で最も大きな割合を占めており、機能テストはブラック ボックス テストとも呼ばれます。テストオブジェクトをブラックボックスとして扱うことです。ブラックボックステスト手法を動的テストに使用する場合、ソフトウェア製品の内部構造や処理プロセスをテストすることなく、ソフトウェア製品の機能をテストする必要があります。ブラックボックス技術を使用してテストケースを設計する方法には、同値クラス分割、境界値分析、エラー推定、因果関係図、および包括的戦略が含まれます。
パフォーマンス テストは、自動テスト ツールを使用して、さまざまな正常、ピーク、および異常な負荷状態をシミュレートすることにより、システムのさまざまなパフォーマンス指標をテストします。負荷テストとストレス テストはどちらもパフォーマンス テストであり、組み合わせることができます。負荷テストを通じて、さまざまなワークロード下でのシステムのパフォーマンスを確認します。目標は、負荷が徐々に増加したときのシステムのさまざまなパフォーマンス指標の変化をテストすることです。ストレス テストは、システムのボトルネックまたは許容できないパフォーマンス ポイントを特定することにより、システムが提供できる最大のサービス レベルを取得するテストです。
インターフェイス テスト。インターフェイスはソフトウェアとユーザー間の対話の最も直接的な層であり、インターフェイスの品質によってソフトウェアに対するユーザーの第一印象が決まります。さらに、適切に設計されたインターフェイスは、ユーザーが対応する操作を自分で完了できるようにガイドし、ガイドの役割を果たすことができます。同時に、インターフェイスは人間の顔のようなものであるため、ユーザーを引き付けるという直接的な利点があります。適切にデザインされたインターフェイスは、ユーザーに安心感、喜び、成功感をもたらしますが、逆に、インターフェイスの設計が失敗すると、ユーザーはイライラすることになります。ユーザーの恐怖と放棄。
違いは、機能テストでは製品のすべての機能に焦点が当てられ、すべての詳細な機能とあらゆる考えられる機能上の問題が考慮されることです。パフォーマンス テストは主に、全体としてマルチユーザーの同時実行下での製品の安定性と堅牢性に焦点を当てています。インターフェイスのテストでは、使いやすさ、分かりやすさ、標準化（ショートカットキーなど）、美しさ（ユーザーの注意を引くことができるか）、使用時の安全性（可能な限り）などのユーザーエクスペリエンスに重点を置きます。フロントデスクは、ユーザーが誤って無効なデータを入力することを防ぎます。もちろん、エクスペリエンスを考慮して、警告をポップアップ表示するのは失礼ではありません)? あるパフォーマンス テストを行う場合、まず、機能ポイントでは、まず機能に問題がないことを確認してから、この機能ポイントのパフォーマンス テストを検討します。
060. ブラックボックステスト、ホワイトボックステスト、単体テスト、結合テスト、システムテスト、受け入れテストの違いやつながりを比較してみてください。
ブラックボックステスト: 製品の機能設計仕様がわかれば、実装された各機能が要件を満たしているかどうかを証明するためにテストを実行できます。
ホワイトボックステスト: 製品の内部作業プロセスがわかれば、各内部動作が設計仕様を満たしているかどうか、およびすべての内部コンポーネントがチェックされているかどうかを証明するためにテストできます。
ソフトウェアのブラックボックス テストとは、ソフトウェアのインターフェイスでテストが実行されることを意味します。この方法では、テスト対象をブラックボックスとみなして、テスターはプログラムの論理構造や内部特性を全く考慮せず、プログラムの機能が要件仕様書の機能記述に適合しているかどうかだけをチェックします。プログラム。したがって、ブラック ボックス テストは、機能テストまたはデータ駆動テストとも呼ばれます。ブラック ボックス テストは、主に次の種類のエラーを検出することを目的としています。
1. 誤った機能や不足している機能はないか 2. インターフェース上で入力が正しく受け付けられるか? 正しい結果が出力されるか 3. データ構造の誤りや外部情報(データファイルなど)へのアクセスエラーはないか4、性能は要件を満たしていますか? 5、初期化エラーや終了エラーはありませんか?
ソフトウェアのホワイトボックステストは、ソフトウェアの手順の詳細を詳細に検査することです。この方法では、テスト オブジェクトをオープン ボックスとみなします。これにより、テスターはプログラムの内部論理構造と関連情報を使用して、テスト ケースを設計または選択し、プログラムのすべての論理パスをテストできます。さまざまな時点でプログラムの状態を調べることにより、実際の状態が期待される状態と一致しているかどうかを判断します。したがって、ホワイト ボックス テストは、構造テストまたはロジック駆動テストとも呼ばれます。ホワイトボックステストでは主に次のようなプログラムモジュールをチェックします。
1. プログラム モジュールのすべての独立した実行パスを少なくとも 1 回テストします。
2. すべての論理的判断について、「真」を取る場合と「偽」を取る場合の 2 つの状況を少なくとも 1 回テストできます。
3. ループの境界内および実行の境界内でループ本体を実行します。
4. 内部データ構造等の妥当性をテストする。
単体テスト (モジュール テスト) は、テスト対象のコードの非常に特殊な小さな機能が正しいことを検証するために開発者によって作成された小さなコードです。一般に、単体テストは、特定の条件 (またはシナリオ) の下で特定の機能の動作を判断するために使用されます。
単体テストはプログラマ自身によって行われ、最終的に恩恵を受けるのはプログラマです。プログラマは関数コードを書く責任があると同時に、自分のコードの単体テストを書く責任もある、と言えます。単体テストは、このコードの動作が期待と一致していることを証明するために実行されます。
統合テスト (アセンブリ テスト、ジョイント テストとも呼ばれます) は、単体テストの論理的な拡張です。最も単純な形式では、テストされる 2 つのユニットが 1 つのコンポーネントに結合され、それらの間のインターフェイスがテストされます。この意味で、コンポーネントとは、複数のユニットが統合された集合体を指します。実際のプログラムでは、多くのユニットがコンポーネントに結合され、これらのコンポーネントはプログラムのより大きな部分に集約されます。このアプローチは、フラグメントの組み合わせをテストし、最終的にプロセスを拡張して、モジュールを他のモジュール グループでテストすることです。最後に、プロセスを構成するすべてのモジュールが一緒にテストされます。
システムテストは、テスト対象のサブシステムをテスト用の完全なシステムに組み立てることです。システム方式仕様書で規定された機能をシステムが本当に提供できるかを検証する有効な方法です。（共通共同デバッグテスト）
システム テストの目的は、最終ソフトウェア システムに対して包括的なテストを実施し、最終ソフトウェア システムが製品要件を満たし、システム設計に従っていることを確認することです。
受け入れテストは、ソフトウェアを展開する前の最後のテスト操作です。受け入れテストの目的は、ソフトウェアの準備が整い、エンド ユーザーがソフトウェアの意図した機能やタスクを実行するために使用できることを確認することです。
受け入れテストは、システムが意図したとおりに動作することを将来のユーザーに実証します。統合テストの後、すべてのモジュールが設計に従って完全なソフトウェア システムに組み立てられ、インターフェースのエラーが基本的に排除されたら、ソフトウェアの有効性をさらに検証する必要があります。これが受け入れテストのタスクです。ユーザーが当然期待するとおり、ソフトウェアの機能パフォーマンスです。
061. 開発者がバグではないと言ったらどう対処しますか?
開発者はこれはバグではないと言いましたが、2 つの状況があり、1 つは要件が決まっていないのでこれを行うことができるという状況と、この時点でプロダクト マネージャーを見つけて変更が必要かどうかを確認することができるという状況です。2つ目は、このような事態は起こり得ないので修正する必要はありませんが、その際、まず何が原因でバグが発生しているのかを可能な限り把握することができます。間違っている場合、どのような悪い結果が生じるでしょうか? プログラマはさまざまな理由を提示するかもしれませんが、あなたはその説明に反論することができます。それでもダメならこの問題を上げて開発担当者とテスト担当者に確認して、修正するなら変更する、修正したくないなら変更しないでください。実際にはバグではなく、私が推奨する方法で TD に書き込むだけなので、開発者が修正しなければ大きな問題は発生しません。バグであると判断された場合は、自分の立場を貫き、問題が最終的に確認されるようにしなければなりません。
062. ソフトウェアのテスト作業はなぜチームで実行する必要があるのですか?
テストが行われていないソフトウェアは、リリース前にソフトウェアの品質を知ることが難しいため、ISOの品質認証と同様に、テストにも品質保証が必要となるため、ソフトウェアテストをチームで実施する必要があります。テストの過程でソフトウェアの問題が発見され、開発者に通知されて修正され、リリース間近のテストレポートからソフトウェアの品質を知ることができます。
063. テスト計画には何を含めるべきですか?
背景、プロジェクト概要、目的、テスト範囲、テスト戦略、分業、リソース要件、スケジュール、参考資料、共通用語、提出書類、リスク分析。
064. ソフトウェア業界の背景を踏まえて、ソフトウェアのビジネスをどのように理解していますか?
ソフトウェアの機能と操作プロセスを理解するためにユーザーマニュアルを読んでください。ビジネス知識を補うためにビジネスに関する専門書を読んでください。実際のユーザーデータがある場合は、実際のデータを参照として使用できます。以前の使用例やバグレポートを参照してください。ソフトウェアを使用する過程で、もっと考え、プロダクト マネージャーとより多くのコミュニケーションを図ります。
065. テストケースの役割を見つけるにはどうすればよいですか?
構成: 執筆、構成、機能範囲、再現性、追跡、テスト検証
066. 互換性テストとは何ですか? 互換性テストリストをテストに使用する例を教えてください。
主に、ソフトウェア製品のバージョン間の互換性を検証します。下位互換性と相互互換性を含みます。下位互換性とは、新しいバージョンのテスト ソフトウェアが以前のバージョンの機能を保持している場合を指します。また、相互互換性とは、共存する、関連するが同一ではない 2 つの製品間の互換性を検証することです。
067. あるソフトウェアをテストしたところ、WIN98では動作が非常に遅いことが分かりました。ソフトウェアに問題があるのか、ソフトウェアやハードウェアの動作環境に問題があるのかを見分けるにはどうすればよいですか？
ソフトウェアの動作環境をご確認ください。要件を満たしている場合はプログラムに問題があり、要件を満たしていない場合はハードウェア システムに問題があります。
068. 要件テストの注意点は何ですか？
自社のテンプレートを使用しているかどうか、文書の内容が仕様書に準拠しているかどうか、すべての要件が適切に分類および分析されているかどうか、すべての要件に一貫性があるかどうか、要件が実現可能であるかどうか（つまり、要件の組み合わせに要件があるかどうか）ソリューション）、要件を実装するために制約を使用できるかどうか、要件が適切であるかどうか（つまり、目的の製品を生産する合理的な確率で正式な開発組織に送信できるかどうか）、他のすべての要件が正しく相互参照されているかどうか、およびユーザーの説明が明確であるかどうか、要件が顧客の言語で説明されているかどうか、各要件の説明が明確かつ明確であり、実装のために独立したグループに引き渡されたときに理解できるかどうか、すべての要件が検証可能かどうか、各要件に独立性があるかどうか、たとえ変更があったとしても、他の要件に影響を与えないこと、パフォーマンス指標が明確であるかどうか、非機能要件が完全に表現されているかどうか、適用される標準またはプロトコルが完全にリストされているかどうか、および標準とプロトコルの間に矛盾があるかどうか
069. 主キーと外部キーの役割、インデックスのメリット・デメリットは？
回答: 主キー: テーブル内で一意の識別キーです。役割: エンティティの整合性を確保するため、データベースの操作を高速化するため、新しいテーブル レコードを追加すると、データベースは新しいレコードの主キー値を自動的に取得し、その値を同じ値で繰り返すことはできません。他のテーブルに記録された主キー; データベースは主キーを押す レコードは値の順、または主キーが指定されていない場合は入力された順に表示されます。
外部キー: 主キーに従属し、2 つのテーブル間の接続を表します。役割: 外部キーを使用すると、冗長性を回避できます。
インデックスの利点: 1. 一意のインデックスを作成することで、テーブル内のデータの一意性が保証されます; 2. データの検索が高速化します; 3. テーブル間の接続が高速化します; 4.グループ化と並べ替えのデータ取得を使用すると、グループ化と並べ替えの時間を大幅に取得できます; 5. クエリ プロセスで最適化非表示機能を使用して、システムのパフォーマンスを向上させます。
デメリット: 1. インデックスの作成に時間がかかり、データ量の増加に伴ってインデックスの作成量も増加します、2. インデックスが物理的なスペースを占有する必要があります。
3. テーブル内のデータを変更する場合、インデックスも動的に保守する必要があるため、データ保守の速度が低下します。
070. パフォーマンステストのプロセスは何ですか?
1. テスト要件の分析 2. テスト計画の策定とレビュー 3. テスト ケースの設計と開発 4. テストの実行と監視 5. テスト結果の分析 6. パフォーマンス テスト レポートの作成 7. テスト経験の概要
071. バグのライフサイクルを簡単に説明しますか?
1. BUG を効果的に記録する 2. BUG テンプレートを使用する 3. BUG の優先度と重大度を評価する 4. BUG の存続期間 5. BUG データベースを維持する
072. 欠陥記録には何を含めるべきですか?
欠陥の識別、欠陥の種類、欠陥の重大度、欠陥発生の可能性、欠陥の優先順位、欠陥のステータス、欠陥の発生源、欠陥の原因、欠陥の原因。
073. どのようなタイプのソフトウェア テストに精通していますか? これらのさまざまなテスト タイプ (機能テスト、パフォーマンス テストなど) の違いと関連性を比較してみてください。
ユーザビリティテスト インターフェースの使いやすさ、操作のしやすさなど
機能テスト - システムの機能要件の実現
セキュリティテスト - システムにセキュリティリスクや脆弱性があるかどうか
パフォーマンス テスト - 大規模な同時実行下でのシステムの応答速度と堅牢性
074. テスト計画をうまく進めるための鍵は何だと思いますか?
プロジェクトまたはシステムのビジネス要件を理解する
プロジェクトマネージャーと調整して、プロジェクトのスケジュールと手配を理解します。
075. テストケース設計で良い仕事をするための鍵は何だと思いますか?
ビジネス要件とソフトウェア要件について非常に明確であり、さまざまな要件に応じてさまざまなテストケース設計を選択できます
076. これまでの仕事でテストケースレビューを実施したことがありますか? はいの場合、テストケースレビューのプロセスと内容について説明してください。
計画のレビュー -> 事前レビュー -> レビュー。
レビューの内容は主に、ソフトウェア要件に対するテストケースが網羅されているか、関連する境界が考慮されているか、複雑なプロセスに対して複数のテストデータが用意されているか、非機能要件に特化したテストがあるかどうかなどです。
077. パフォーマンス テストの目的は何だと思いますか? パフォーマンス テストで良い仕事をするための鍵は何ですか?
重要なのは、テスト スクリプトを記録し、テスト中にテスト環境をクリーンな状態に保つことです。
078. 過去のソフトウェア テスト作業で、ソフトウェアの欠陥 (バグ) を管理するためにツールを使用しましたか? 「はい」の場合、ツールと組み合わせてソフトウェアの欠陥 (バグ) を追跡および管理するプロセスについて説明してください。
CQ、BugFree などの無料ツールを使用することもできます。
079. ソフトウェアプロセスの改善についてどう思いますか? これまで働いてきた企業で改善すべき点はありますか? 理想的なテスターにはどのような作業環境を期待しますか?
高度な経験やアイデアをプロセスに定着させ、プロセス改善と能力向上を通じてソフトウェアの品質を向上させます。
TCP/IP 5 層プロトコル: アプリケーション層、トランスポート層、ネットワーク層、データリンク層、ハードウェア層
この記事が役に立った場合は、大金を稼ぐために手を差し伸べて、「いいね！」をしてください。サポートに感謝します。あなたの「いいね！」が私の継続的な更新のモチベーションです。
要約:
最後に、私の記事を注意深く読んでくださった皆さんに感謝します。互恵性は常に必要です。それはそれほど価値のあるものではありませんが、必要な場合はそれを取り上げることができます。
これらの資料は、[ソフトウェア テスト] の友人にとって、最も包括的かつ完全な準備倉庫となるはずです。この倉庫は、最も困難な旅を乗り越える何万人ものテスト エンジニアにも同行してきました。お役に立てれば幸いです。パートナーは下の小さなカードをクリックしてください。受け取る