テストインタビューの質問

2018年8月12日-----テスト問題

1. Q:互換性テストとは何ですか?どのような互換性テスト焦点を当てましたか?

 

:メインは、多くの場合、ソフトウェアの移植性と言われて、通常は異なるハードウェアプラットフォーム上で実行できる互換性テストソフトウェア、ソフトウェアプラットフォームを、確認することです。

互換性のある型、壊れている場合、そこプラットフォームの互換性、ネットワークの互換性、データベースの互換性、および互換性のあるデータフォーマット。

互換性テストは、互換性のある環境の分析に焦点を当てています。一般的に、ソフトウェア環境を実行している場合には、それは互換性行われる必要がある、非常に特定ではありません。ソフトウェアを実行するのに必要な、または要件文書によると、フォームにこれらの環境を整理するために、どのような状況でソフトウェアを使用するユーザーを描画することが一般的に可能な、あなたは互換性テスト互換環境をやって来ます

互換性と構成テストの違いは、テストが通常で構成されていないということであるクリーンOS のテストケースを実行すると、互換性テストはで主にあるクリーンOS 環境次の操作を行います

 

彼は加えた:特定のステップの互換性テストを実行します。スモークテストを行うには良いハードウェアおよびソフトウェア環境の列リスト、またはテストのすべてのステップで。測定は、通信とどのようにこれらの顔を開発するために何をすべきかとの互換性はありませんの発展と互換性がありません。修理費用が非常に高く、製品マネージャー場合はどのように通信することができます。誰が確認フォーム

2. Q:私はで見つかったプログラム、持っているWindowsの差別がプログラムやシステムのハードウェアおよびソフトウェアの問題では、問題がどのように非常にゆっくりと実行して、

 

A: 1 、システムは毒性の特性を持っているかどうかを確認します

2 、チェックソフトウェア/ ハードウェアの構成は、推奨される標準のソフトウェアを満たしています

3は、現在のシステムが独立していることを確認し、つまり、外部には、任意の消費提供しないCPUのリソースサービスを

4は、場合C / S またはB / Sをチェックする必要の問題のサーバ、またはアクセスの問題に接続されていないため、ソフトウェアアーキテクチャによって引き起こさ

5 いずれかの負荷のないシステムでは、アプリケーションことを確認するために、パフォーマンスモニタを表示するCPU / 利用可能なメモリを

 

追加:各ステップがどのように達成するか、どのような技術を使用する必要があります

3. Q:テスト戦略は何ですか

 

:ブラックボックス / ホワイトボックス/ 灰色のボックス、静的/ 動的、手動/ 自動、スモークテスト、回帰テスト、ベータ(ベータテストポリシー)

 

追加:何ベータ市他のテスト戦略はありますか?テスト戦略とテスト方法とテストタイプの違いは何ですか?

4. Q:直交テスト設計方法の特徴は何ですか?

 

:少なくとも隠蔽動作は、テストケースの設計小さい、高効率、非常に複雑での実験。

しかし、より深い欠陥、より複雑な欠陥、または無力;基本認証、および調べるために、一般的にできるように起因する統合された2次欠陥のために。

特定の状況下では、一般的に行うことは非常に困難直交します。ほとんどのだけこの方法を使用する場合、システムのテスト

 

追加:、どのようなテストの各フェーズは、このような各段階の技術で必要とされるものをユニット、統合、システム、ベータ、などのシステムのテスト、ある場合には、要件は何ですか

5. Q:テストケースの設計の完全なプロセスを説明して

 

A:ニーズ分析 + 保守作業の要件を変更します

需要に基づいて導出テスト要件

テスト計画、設計、テスト・評価プログラム

プログラム、デザインのテストケース、テストケースによって審査した後、再び見直されます

 

追加:テストケースの設計プロセスについて追加するものはありますか?

6. Q:どのようなユニットテストの戦略?

 

A:サイクルをカバーする論理カバレッジ、ピア・レビュー、検査テーブル、コードレビュー、コードレビュー、データフロー解析景泰

 

注:ユニットテストの内容が、それでもおそらく見て

7. Q:あなたはどのようなものですテストソフトウェアの種類に精通していますか?これらの異なるテストの種類とそれらの接続を試してみてください(このような機能テスト、性能テストなど...)を比較しましたか?

 

互換性テストとしても知られている(互換性テスト)、「コンフィギュレーションテストの他の要素との間の互換性は、(コンフィギュレーションテスト)相互作用」、そのようにテストソフトウェアシステム、か:ように、ブラウザ、オペレーティングシステム、ハードウェアおよび。異なるソフトウェアおよびハードウェア構成のテストオブジェクトの動作を確認します。

機能テスト(機能テストとも呼ばれる、行動試験(行動試験)は、製品、ユーザーと操作の特徴は、実施形態を説明した試験製品の特性及び設計要件を満たすために彼らの行動を決定するように動作可能です。ローカライズされたソフトウェアの機能テストは、ユーザーが正常に動作対象とするアプリケーションやウェブサイトを確認します。ターゲットユーザの経験が十分になることを保証するために適切なプラットフォーム、ブラウザやテストスクリプトを使用して、アプリケーションと同じでは特にこの市場向けに開発されました。

試験パフォーマンス(性能試験)は、製品またはコンポーネントの評価は、試験の性能要件を満たしています。これは、負荷テスト、強度試験、試験データベース容量、およびベンチマークの他のタイプを含みます。

 

追加しました:テストの種類は何に分けることができますか?場所を補完することが必要かどうか

8. Q:ソフトウェアのバグ(またはと呼ばれるバグ)に何を記録?どのように高品質なソフトウェアの欠陥(提出するバグ)レコードを?

 

A:(c)標準

 

追加:何ですか 5Cの基準は?答えは、私たちが追加する必要があり、不完全でした

9. Q :ベータテストおよびアルファテストの違いは何ですか?

 

A:ベータテスト(ベータ]テストは)、テストは、ユーザーの実際の環境の一つ以上のユーザソフトウェアの複数をテストするために行われています。通常、開発者ではないテストサイト

アルファ(試験[アルファ]試験)、シミュレートされた実際の動作環境下で行う試験をユーザの開発環境で実行され、ユーザが制御することができる内部テスト

 

追加しました:それは知られているが、どのような面接をシミュレーション夜とルームメイトで、言うことはありません。また、知識のサプリメントを追加しました

10. Q:評価ソフトウェアは、一般的に誰が参加していますか?その目的は何ですか?

 

:公式の結果は、レビューと承認のためのソフトウェア製品の部門のユーザー、顧客やスタッフに(などのドキュメント、コード、生産​​のさまざまな段階を含む)会議ソフトウェアプロジェクトに提出されます。目的は、ソフトウェア製品、開発、保守、環境の適用の設計上の欠陥の品質に影響を与える可能性がある領域を特定するため、および是正措置をとることだけでなく、パフォーマンス、セキュリティ、経済面での可能な改善を特定することです。

スタッフ:ユーザー、顧客や部門の開発者、テスト担当者、アナリストは、要求できるが、査定段階でそれを参照するには

 

追加:混沌の回答、また改善するために調整する必要があります。特定の必要性を理解することを学びます

 

2018年8月13日

1. Q:テスト活動、見つかった不完全または不正確な文書化要件場合、どのように対処するには?

 

テスト要件分析 要件が不完全または不正確な文書化し、それをコーディネートし、関係者の即時交換をしなければならないことがわかりました。

 

追加:会社、要件文書を担当している一般的な、通常の状況下では、誰が報告しなければならないように

2. Q:評価の段階とプロジェクト評価の違いは何ですか?

 

ステージレビュー プロジェクト評価の様々な段階の:ステージ上の成果と仕事

プロジェクト評価 、プロジェクト全体の見直しの:仕事と製品

 

追加:レビューとプロジェクトの評価段階通常、何を見直し

3. Q:定義の作業バージョンを記述する?

 

いいえ建設: BUILDありません

 

追加:聞いた、あなたが知っている必要があります

4. Q:スタブとは何ですか?何がモジュールを駆動していますか?

 

スタブ:テストモジュールの下にモジュールを呼び出します

ドライバモジュールは、 テスト対象のモジュールを呼び出し

 

追加:あなたがたは理解していなかった、と補充するために必要な

5. Q:ファンは何ですか?ファンアウトとは何ですか?

 

ファン:被呼番号、ファンアウト:さらにモジュールの数を調整します

 

追加:理解し、補充する必要はなかったです

6. Q:あなたはキーがテスト計画作業を行うことは何だと思いますか?

 

ソフトウェアのテストは、ソフトウェアテストの効果的な実施を確保するために、スコープや予算をテストし、ソフトウェアのテストをクリアテストオブジェクトの正式な実装、および資源の総合的な分析と計画、時間、リスクの前に計画されています。

仕事をするために重要なテスト計画 :目的、管理、標準化

 

ターゲットのテスト、強化されたユーザビリティテスト計画

ソフトウェアのテスト計画が重要な目的を持って書くことはテストプロセスがより多くのソフトウェアの欠陥を見つけることができるようにすることですので、ソフトウェアのテスト計画の値は、試験項目の管理に役立つ、および潜在的なソフトウェアの欠陥を見つけるために、それに依存します。したがって、テストソフトウェアのテスト計画の範囲は、機能要件の高さをカバーしなければならない、試験方法は実用的でなければならない、テストツールと、実用的な高使いやすい、テスト結果を生成し、直感的な、正確を持っています

2 「に準拠5W 」のルール、クリアなコンテンツとプロセス

5W 」ルール「とは何か」、(やる)「なぜ(なぜ)」、「ときは(それを実行するとき)」、「どこで(場所)」、「どのように(行う方法)。」「の使用5W テスト(の目的を理解するためのテストチームを助けることができるソフトウェアのテスト計画を作成するための」ルール、なぜ)、特定のテスト(の範囲と内容何を)、(テストの開始日と終了日を決定する)、(手法やツールがテストされていることを指摘しましたどのように、テストのマニュアルおよびソフトウェアの格納場所を(与え)どこで)。

3 テスト計画は、実際の需要を満たすためにことを保証するために採用したレビューと更新のメカニズム

テストチームに直接送信査定の対象とならない場合は、テスト計画が完了した書き込みをした後、試験の試験計画の内容が不正確または不足しているコンテンツであってもよいし、ソフトウェア要件は、テスト範囲の変更による変化、およびテストプログラムの内容が更新されない、誤解を招きますテストエグゼクティブ。

それぞれ、テスト計画を作成し、詳細な仕様、テストケースをテストします

それは独立して作成された詳細な仕様書、作成したテストケースやテストケース管理データベース別の文書にテストケースの実装のプロセスをガイドするためにテストチームをテストするために、詳細なテスト仕様が含まれている必要があります。詳細なテスト計画、テスト仕様書、テストケースの戦略と戦術の関係で、マクロ試験方法およびリソースの割り当て、および詳細なテスト仕様書、テストケースからテスト計画の主要な活動計画範囲は、テストタスクに特定の戦術を完成させることです。

追加:反射、これらは十分ではありません

7. Q:あなたはどう思いますかは、良いテストケースの仕事への鍵ですか?

 

要件や設計書、システムに精通度を理解します

 

追加:反射、これらは十分ではありません

 

8. Q:簡単に欠陥のライフサイクルを記述?

 

提出 commit-> 確認confirm-> 配分- > 修正- > 確認してください- > 閉じます

 

追加:これは最も完全なものではありません

9. Q:セキュリティソフトウェアをテストするためのいくつかの領域でなければなりませんか?

 

回答:

(1)ユーザの認証メカニズムを:そのようなデジタル証明書、スマートカード、二要素認証、安全な電子トランザクションプロトコルとして

(2)暗号化機構

(3)セキュリティ戦略:セキュリティログ場合、侵入検知、絶縁保護、脆弱性スキャン

(4)データのバックアップとリカバリツール:ストレージデバイス、ストレージ最適化、ストレージ保護、ストレージ管理を

(5)アンチウイルスシステム

 

追加:安全性試験は理解していない、我々は開いた本を探す必要があり

10. Q:ソフトウェア構成管理と仕事の理解が行わ?

 

ソフトウェアの開発を通して、ソフトウェア構成管理は、常に活動のあらゆる側面をテストし、開発をカバーし、活動をテストし、その重要な役割の一つは、構成アイテムの状態を監視し、各設定項目の包括的な管理を保存することで、プロジェクトマネージャーおよび関連スタッフは、ソフトウェアプロセスの制御を達成するために、報告します。

含むソフトウェア構成管理、テスト、 4つの最も基本的な活動:

設定項目の識別

構成項目制御

設定項目ステータスレポート

構成監査

通常支援するソフトウェア構成管理ツール、主によって、 MSのSourceSafe 合理的ClearCaseの、など

おすすめ

転載: www.cnblogs.com/520502-thy/p/11770818.html