41、どのようなユニットテスト、統合テスト、システムテストの焦点はありますか？
- ユニットテストのための：ソフトウェア設計の最小単位 -プログラムモジュール（プロセスのためのプロセスの関数であり、オブジェクト指向である）は、試験の正確性をテストするために、各エラーは、プログラムモジュールは、内部に存在することが見出されています。二つの一般的なステップがあります：人工静的チェック\動的な実行トレース
- 統合テスト針：によって右個々のモジュールの構成要素は、ユニットテストを調べる統合、およびその主な内容は、それぞれの単位モジュール間のインターフェイス、モジュールと統合することによって実現される各種機能
- システムテストは：を目的とする統合されたソフトウェア・システムの優れたコンピュータ・ハードウェア・システムの他の要素と組み合わせて全体のコンピュータ・システムの要素として、\周辺\特定の支援ソフトウェア\データと担当者は、実際の動作環境であることが、コンピュータシステムの統合テストと検証テストのシリーズ
42、テストエンジニアは、これらの資質を持っている必要がありますか？
1、2責任、コミュニケーションスキル3、4チームワーク、忍耐、ケア、自信5、常に懐疑的な態度、そして意識的に6欠陥予防、およびいくつかのプログラミング経験を持っています
43は、あなたがソフトウェアテスト、簡単な紹介の種類が何であるかを知っています。
カテゴリ別テスト戦略：
- 1、静的および動的試験
- 2、ブラックボックスとホワイトボックス
- 3、手動および自動テスト
- 4、スモークテスト
- 5、回帰テスト。
押してテストフェーズカテゴリ：
- ユニットテスト、
- 統合テスト、
- システムテスト。
他の一般的な試験方法：
- 図1に示すように、機能テスト
- 2、パフォーマンステスト
- 3、ストレステスト
- 図4に示すように、負荷試験
- 5、ユーザビリティテスト
- 6、インストールおよびテスト
- 7、インターフェース試験
- 図8に示すように、コンフィギュレーション・テスト
- 9、文書テスト
- 10、互換性テスト
- 11、セキュリティテスト
- 12、復旧テスト
44、あなたは鍵がテスト計画作業を行うことは何だと思いますか？
ターゲットのテスト、強化ユーザビリティテスト計画
- ライティングソフトウェアのテスト計画は、重要な目的は、テストプロセスをよりソフトウェアの欠陥を見つけることができるようにすることです持っているので、ソフトウェアのテスト計画の値が助けにそれに依存するテスト項目を管理し、潜在的なソフトウェアの欠陥を見つけます。したがって、ソフトウェアのテスト計画のテストの範囲は正確な、直感的なテスト結果を生成する、使いやすい、機能要件の高さをカバーし、試験方法は実用的でなければならない、テストツールと高い実用的なを持っている必要があります
「5W」のルール、クリアなコンテンツとプロセスを遵守
「5W」ルールは「なぜ（なぜ）」、「ときは（それを実行するとき）」、「どこで（場所）」、「どのように（行う方法）。」、「何（やる）」を指し、、ソフトウェアのテスト計画を作成するための「5W」ルールの使用は、（とき）テストの開始日と終了日を決定するテスト（なぜ）、スコープや特定のテスト（何）のコンテンツの目的を理解するためのテストチームを助けることができ、手法やツールをテストすることを指摘しました（ 、テストのマニュアルとソフトウェア（）の保管場所を与える方法）。
- レビューと更新のメカニズムは、テスト計画は、実際の需要を満たすためにことを保証するために採用しました
- 評価しないように、被験者がテストチームに直接送信した場合、テスト計画が完了した書き込みをした後、試験の試験計画の内容が不正確または不足しているコンテンツであってもよいし、ソフトウェア要件は、テスト範囲の変更による変化、およびテストプログラムの内容が更新されない、誤解を招きますテストエグゼクティブ
- それぞれ、詳細な仕様、テストケースをテスト計画を作成し、テストします
- 独立して詳述されている仕様書作成したテストに詳細なテスト仕様が含まれている必要があり、テストチームが作成したテストケースやテストケース管理データベース別の文書にテストケースの実装のプロセスをガイドします。詳細なテスト計画、テスト仕様書、テストケースは、戦略と戦術の関係で、テスト計画の主な活動は、計画されたマクロ試験方法及びリソースの割り当て、および詳細なテスト仕様書の範囲、テストケース、テスト作業の具体的な戦術を完成させることです。
45.あなたは鍵がテストケースの設計作業を行うことですどう思いますか？
- キーの実施形態に白いボックスがプログラム結果の内部ロジックの限り少ないケースカバーを使用するように設計されています
- また、設計されたブラックボックスを使用して、実施例鍵方式より少ないケースを使用するためには、モジュール出力及び入力インタフェースをカバー。最小限のユースケースは、合理的な期間内にそのほとんどの問題を発見したと完全にテストすることはできません。
46.あなたのキャリアの目標は何ですかをテストすることですか？
- 私は個人的に私の最初のキャリアが蓄積要約に時間がかかるので、長いテスト作業が、より多くの、テスト機能をテストが累積経験する必要はありませんので、自分の欠点に自分自身を見つけるし、改善していることを感じ、私の第二の目標は、テスト開発にあります。知識と学習の開発中のスケジュールのテストを見て、常に自己修正自体を改善し、テストの作業を行い、今年テストし、自動化されたパフォーマンス分析は、パフォーマンス最適化の方向のためのプログラムを学んでいる暇な時間を決定するために
47、テスト基準の終わりは何ですか？
- 、マイクロから定義されるように、システムが一定の性能で72時間円滑に実行して、テスト計画で、現在のバグ追跡システムであり、現在のバージョンは、一般的に深刻なバグ、3以下の通常のバグの数、90％のバグ修理率はありません上記パラメータ等、次いでCO署名認識バージョンリリース開発マネージャ、テストマネージャ、プロジェクトマネージャによって。
- マクロた場合、テストが終わった後に、ソフトウェアが完全に消滅するとき、それはあります。
48、テストの完全なセットは、どの段階で構成する必要がありますか？
- 実現可能性の分析は、分析、概要設計、詳細設計、コーディング、単体テスト、統合テスト、システムテスト、受け入れテストを必要とします
49あなたは過去、エンタープライズソフトウェア開発プロセスの仕事を理解していますか？何をすべきかのあなたが知っている場合は、Shishuしてください完全な開発プロセス？これらのタスクを完了するために異なる役割は何ですか？あなたは以前のすべてのテスト作業に特異的にどのような仕事のしてきましたか？せいぜい仕事のどの部分？
- ---開発プロセスの研究ニーズ（需要スタッフ）、（開発者）をコード、分析（需要スタッフ）、アウトラインデザイン（デザイナー）、詳細設計（設計者）が必要
- ---評価テスト、システムテストの設計、予備設計レビュー、統合テスト、設計、詳細設計レビュー、ユニットテスト設計、テスト実行を必要とします
- テストの全体のプロセスは、設計、テストで良い行われました
- プロセスは、正確にソフトウェアの品質、蓄積された過去の様々な教訓を向上させるために、ソフトウェアプロセス改善の品質を決定します。
50、テストケースの設計原理は何ですか？現時点では、メインのテストケースの設計方法があるのですか？
- 表現：表現し、すべての、合理的かつ不合理な、法的および違法な国境と国境を越えた、だけでなく、入力データ、動作および環境設定の制限などをカバーします。
- 決定可能性：即ち、試験の結果の正しさは、対応する所望の結果を有していなければならない各テストケースについて決定されます。
- 再現性：同じ試験の結果は、実行、システムが同じでなければなりません。
- メソッドは、クラス、境界値、因果ダイアグラム、状態図、直交法、誤差推定処理を同値
51は、オブジェクト指向の設計をテストするには、いくつかの方法がありますか？どのように達成するために？
- テストケースのセットを設計するために、各クラスのコンストラクタ
- クラスのクラス変数、インスタンス変数の組み合わせ
- クラスメソッドの様々な組み合わせ
- 事前条件と事後条件のテストケース
- コード設計のテストケースによると、
あなたが最大の関心をテスト52、？なぜ？
最大の関心は挑戦し、困難なテストしています！テストは、より良いテストを行うにはどのようにハード感じることができなるようにしてください。私は安心してオンラインテスト中の記事は、テストエンジニアを行う方法についてです見ていました。11ポイントの合計を一覧表示し、そしていくつかは人格に関連している、いくつかの努力を取得する必要があります。しかし、私はよく分からない文字に関する1,2のポイントに加えて、他の点は、私はそれを行うことは非常に確信しています。
ただ、テスト業界を入力し始め、テストの知識がインターネット安心テストからの情報の一部を理解することです、テストを行うように指示されたエントリが容易であるが、うまくやってスキルがかかるが、より多くの開発よりも行うことは困難ですその時私は、より多くの困難なテストは、より発展よりも挑戦見て（私の職業のように、私はので、私は基本的にお見逃しなく学校のコース）の開発をやってみたかったが、難しい、テストは一層強化したいと思うでしょう。
私は、全体のテストプロセスは、私は2つの非常に難しい（私にとっては、難しいこと、私は非常に興味があった）があると思わせることを感じます
- 最初は、テストケースの設計、テスト、それの本質は、および以前のバージョンで出てくるので、ユースケースは、テストケースの設計に書かれた、書き込み何のテスト方法ですか？あなただけの新しいタスクをテストした場合（つまり、テスト計画やテスト戦略である）、あなたがビジネス要件や技術インフラを消化するためにいくつかの時間を費やす必要が、ビジネスニーズを十分に理解されている（マルチプロダクトマネージャーや開発者は、通信を実現することができるようになります目的）、および技術基盤にすることはできませんので、単純な、そしてあなたは、このようなことのサイト、あなたはそれがサイト内でどのように動作するかを知っておく必要がある基本的な技術知識として自己を意識する、学ぶ必要があり、背景がどのようにユーザーの要求に応答することを、この能力は？テスト環境をセットアップする方法？これらの必要性は、最初に学びます。テストを開始する前に、少なくとも基本的な準備を行うことができます、あなたは何の問題が発生する可能性がありますか？需要の詳細を決定は良いではないですか？これらの問題は、ユースケースのデザインで見つけることができます。
- 第二は、バグを見つけるための時間です、これはバグのほとんどの場合で見つけることができ、テスト・プロセスを開始するための一般的な試験によれば、テスターの最も基本的なタスクである必要があり、まだ測定されたバージョンのより良い理解をテストするためのいくつかのバグがありますバグアウト詳しくは、補のテストケース、テストのために。そして、どのようにバグを見つけるには？これはバグを見つけるために、慎重かつ忍耐を通して、テストケースに有効必要とし、各ユースケースは、すべての場所は、テストプロセスを明確に思考するように、（テストプロセスとデータが流れ、間違って行くことができるバグを発見する可能性があります結果は）慎重に、バグが発見された内部を見ていました。どのような条件が少し変更した場合、このバグを持っていない、また状況が生じるであろうものを下に非常に特定のバグ、バグを記述するために、少なくとも、このバグを再現することができどのような手順になります、バグは、法律が何であるかを生成しますか？あなたは十分に強力であれば、それは、開発者が最初の問題を見つけることができます。
53、あなたは何をしているテストソフトウェアの種類に精通していますか？私たちは、これらの異なるテストの種類とそれらの接続を比較してみてください（このような機能テストなどを、パフォーマンステスト......）
試験タイプ：機能テスト、パフォーマンステスト、インタフェーステスト。
- 機能テストはまた、ブラックボックステストとして知られている試験で最大の割合、機能テスト、を占めています。これは、ブラックボックスのようにオブジェクトをテストすることです。ブラックボックス動的試験を用いた方法をテストする場合、ソフトウェア製品とプロセスの内部構造を検査することなく、ソフトウェア製品の機能をテストする必要があります。技術設計方法を使用してブラックボックステストケースは以下のとおりです。同値分割、境界値分析、エラー推測、原因と結果の図や包括的な戦略。
- パフォーマンステストは、自動テストツールを通じて、正常、異常なピーク負荷条件のシステム性能のアナログ多様性をテストすることです。性能試験属し負荷やストレステストは、2を組み合わせることができます。ワークロードの様々なシステムの性能を決定するために試験荷重によって、目標が徐々に増加する場合、負荷試験、システムのパフォーマンス指標の変化。圧力試験を提供することができる最大サービス・レベル・テスト・システムを得るために、ボトルネックを識別またはパフォーマンスポイントを受け取ることができないことにより、システムです。
- インターフェイスのテストは、界面層のソフトウェアは、最も直接的で、ユーザインタラクション、ユーザーインターフェースの良いか悪いか判断ソフトウェアの第一印象です。さらにうまく設計されたユーザインターフェースは、それぞれの操作を完了するために導くことができ、関数ウィザード。直接の利点を持つ男の顔としてインターフェイスは、顧客を引き付けるためにしながら。その後、ユーザーが不満を持ってできるようにするインターフェースデザインの失敗に反し原因で、ユーザーがリラックス感と成功感を与えるために適切に設計されたインターフェース、恐怖で、ユーザの無駄で実用的な強力な月とあきらめます。
- 違いは細部機能、アカウントに可能性のある問題のそれぞれを取って、機能テストを懸念し、製品のすべての機能に、ということです。性能試験は、マルチユーザーの同時実行性の下で、全体として製品の安定性と堅牢性に焦点を当てました。それは（これまでと同様に安全であればインターフェイスは、より多くのユーザー体験に焦点を当ててテストし、かどうかを使用する製品を使用するユーザーは、どうか理解しやすい、仕様（のようなショートカット）場合、（ユーザの注意を引き付ける能力）美しいです受信避ける意図的でないユーザー入力の無効なデータは、当然のことながら、）、考慮に経験を取るあまりにも失礼なポップアップ警告することはできませんか？最初の我々が最初にその機能は問題ありませんことを確認しなければならないファンクションポイントかもしれ際に性能試験を行い、その後、特徴点の性能試験を考えます
- ユーザビリティテスト - フレンドリーなインターフェースなので、上の操作の容易さと。
- 機能テスト - 機能要件を満たすためのシステム
- セキュリティテスト - システムは、セキュリティ上のリスクと脆弱性をあるかどうか
- パフォーマンステスト - 大規模な同時実行中のシステムの応答性と堅牢性
54は、ブラックボックステスト、ホワイトボックステスト、単体テスト、統合テスト、システムテスト、受け入れテストの相違点との関係を比較してみてください。
- ブラックボックステスト：製品は機能のそれぞれの実装をテストすることができる公知の機能設計仕様は、要件を満たしています。
- ホワイトボックステスト：プロセス知られている製品の内部の仕組みは、検査に合格するために、すべての内部コンポーネントかどうかを、内部動作大会の各設計仕様かどうかを試験することができます。
ブラックボックステストは、ソフトウェアのインターフェイスで実行されることをソフトウェア手段をテストします。この方法は、ブラックボックステストオブジェクトとして見られるべきであり、テスタは、プログラムがその機能の説明であるか否かをプログラム内の論理構造及び内部機能、要求仕様に応じてのみ、プログラム命令、機能チェックを考慮していません。だから、機能テストやデータ駆動型テストをテストするブラックボックスと呼ばれます。
ブラックボックステストは、エラーの種類を発見するために、主に次のとおりです。
- 1、間違っていたり欠けている機能がある場合は？
- 2、インターフェイス上で、入力が適切に受け入れていますか？出力することができる、正しい結果？
- 3、エラーまたはアクセスエラー（例えば、データファイルなど）のデータ構造の外部情報がありますか？
- 4、パフォーマンス上の要件を満たすことができるのですか？5.初期化または終了エラーはありますか？
ホワイトボックステストソフトウェアは、ソフトウェアの手続きについての詳細な検査を行うことです。この方法は、テスタの手順をすべての論理パスをテストするためのテストケースを設計又は選択された番組情報の内部論理構造を使用することを可能にするボックスを開くために、検査対象と見なされます。状態の異なる時点で手順をチェックすることにより、期待した状態線の実際の状態かどうかを決定します。従ってホワイトボックステストはまた、構造的または論理ドライブのテストとして知られています。
ホワイトボックステストプログラムモジュールは、主に次のことを確認したいです：
1、少なくとも一度テストしたプログラムモジュールのすべての独立した実行パス。
2、すべてのロジックの決定は、「真」取られ、少なくとも一度測定した場合、両方の「偽」を取ります。
図3は、ループがmetes及び動作サイクルの範囲内で行われます。
4、などの内部データ構造の有効性を試験します。
- ユニットテスト（モジュールテスト）は、試験下の小テストコードの書き込みにコード開発者の小片であり、それはクリア機能が正常です。典型的には、特定の条件（またはシーン）を判定するためのテストユニットは、特定の機能に作用します。
- ユニットテストは、プログラマ自身によって行われ、究極の受益者もプログラマです。プログラマが、それは彼らのコードのためのユニットテストを書くために責任を有している機能のコードを記述する責任があると言うことができます。ユニットテストは、ちょうど証明するために、この行動規範および当社の予想と一致。
- 統合テスト（また、組立試験、ジョイントテストと呼ばれる）は、論理拡張ユニットテストです。これは最も単純な形である2つを1つの組立部、およびテストインターフェースその間に結合テストしました。ある意味で、それは重合単位の複数の統合されたアセンブリを指します。現実のシナリオでは、コンポーネントに多くのユニットは、これらの成分は、重合プロセスのより大きな部分に変わります。試験方法は、フラグメントの組み合わせであり、そして最終的にはモジュールの他のグループとあなたのモジュールをテストするためのプロセスを展開します。最後に、すべてのテストモジュールは、一緒にプロセスを構成します。
- システムテストは、テストに完全なシステムに組み立てサブシステムをテストしています。これは、システムが実際の機能を指定した効率的な方法の仕様システムソリューションを提供することができるかどうかをテストします。（共通FBIテスト）
- 目的は、徹底的にシステムをテストし、最終的なソフトウェアシステムをテストし、最終製品は従って、システムソフトウェアやシステム設計のニーズを満たすことを確実にするためです。
- 受け入れテストは、ソフトウェアの導入の操作前の最終テストです。目的は、ソフトウェアの受け入れテストの準備ができていることを確認することです、そしてエンドユーザーが意図した機能やタスクの実行ソフトウェアのために使用することができます。
- 受け入れテストは、システムが、スケジュール要件として働くことができることを将来のユーザーです。統合テストでは、完全なソフトウェアシステムに組み立てられたすべてのモジュールによると、インターフェイスエラーが基本的に、彼らはさらに、ソフトウェアの機能、性能を受け入れテストの課題であるソフトウェアの正当性、すなわちを確認する必要があり、除外しているように設計されていますユーザーとして合理的に予想されます。
開発者はバグではないと言うとき55、どのように対処するのですか？
開発者は、2例があり、それはバグではないと言います
- まず、需要が私はそれを行うことができますので、この時間は、プロダクトマネージャーを確認することができました、または変更する必要があり、その後、3ウェイ議論がかどうかを変更するには良いの外観を決定するために、決定されていません。
- 第二には、これが起こることはほとんどありませんので、バグが何に基づいてされる前に、私は可能な限り言うことができ、この時間を変更する必要はありませんか？それは、ユーザや問題を発見された場合、有害転帰何？プログラマはあなたに多くの理由を与える可能性があり、あなたは彼の解釈に異議を唱えることができます。それが仕事をしない場合、私は、この質問に開発マネージャおよびテストマネージャーと確認を行うことができますあなたは変化に変更する場合は、その後、変更されていない場合は変更されません。実際には、いくつかの本当にないバグ、開発者がいない大きな問題を修正していない場合、私はちょうど、TD書かれた方法をお勧めします。バグが、自分の位置に固執するようにしてくださいと判断された場合、問題が最終確認を取得してみましょう。
56、なぜチームでソフトウェアのテスト作業を行う必要がありますか？
- 何がテストされているのでソフトウェアは、同じISOの品質認証のように、またテストする品質保証、ソフトウェアテストのチームで作業する必要がある上、この時間を必要とし、以前のリリースへのソフトウェアの品質を知ることは困難ではありません。
- ソフトウェアテストの過程で適時に問題を発見し、その開発者は、今後のリリースでは、高品質のソフトウェアの場合、テストレポートからの結果を、問題を修正することができます。
含めるべきである57、テスト計画？
- 背景、プロジェクトプロファイル、テスト範囲、テスト戦略、人事部門、リソース要件、スケジュール、参照文書、一般的に使用されている用語、書類を提出する、リスク分析の目的。
58、ソフトウェア業界の背景のために、あなたはどのようにソフトウェアビジネスを理解できますか？
- ソフトウェアの機能と業務プロセスの取扱説明書を読んで、見て、プロの本付加サービスの知識の事業の一部であり、実際のデータユーザが存在する場合、あなたは実際のデータの参照を取得することができ、前の基準ユースケースとバグレポートを、ソフトウェア製品の使用より多くの交流やプロダクトマネージャー、思考より。
59、どのようにテストケースの役割を配置するには？
- 組織：準備、組織、機能カバレッジ、再現性、追跡、テスト確認
60、互換性テストは何ですか？テストのための互換性テストのリストを使用する方法の例を与えます。
- 異なるバージョン間の主な検証ソフトウェア製品との互換性。含むが、下位互換性と互換性の互い違い、ソフトウェアのテストケースの新しいバージョンとの下位互換性は、以前のバージョンのその機能を保持することである、2つの共存関連ではなく、同一の製品間の互換性を検証するために互換性が互い違いです。
*******転載するなど、オリジナルを尊重してください、ソースを明記してください：からの転載：https://www.cnblogs.com/shouhu/、ありがとうございました！！*******