正式に別のポストに異動したので、自由な時間を利用して、面接前に確認した知識を整理し、困っている人を助け、自分で要約を作成することができました。
面接や転勤の準備をする前に、主に次のような最も基本的な理論的知識に誰もが精通している必要があります。
###软件さ试基
####ソフトウェアテストの定義
手動または自動の手段を使用してソフトウェアシステムを実行または測定し、ソフトウェアシステムが指定された要件を満たしているかどうかを確認し、期待される結果の違いを見つけるプロセス。
####テストはステージごとに分類されます
- 単体テスト
- 統合テスト
- 確認テスト
- システムテスト
- 受け入れテスト
####テスト対象のソフトウェアを実行する必要があるかどうかに応じて：
**静的テスト：**は、プログラム自体を実行せずに、プログラムコードで発生する可能性のあるエラーを探すプロセス、またはプログラムコードを評価するプロセスを指します。さらに、静的分析とも呼ばれ、実際にテスト対象のソフトウェアを実行するのではなく、ソフトウェアの形式と構造を直接分析して欠陥を見つけます。これには主に、ソースコード、プログラムインターフェイス、さまざまなドキュメント、および中間製品（製品仕様、技術設計ドキュメントなど）のテストが含まれます。
**動的テスト：**動的分析とも呼ばれます。これは、テスト対象のソフトウェアを実際に実行する必要があることを意味します。プログラムの実行中に効果的なテストケースに合格するなど、実行中のプログラムの状態と動作を観察することで、ソフトウェアの欠陥を発見します。 （対応する入力と出力の関係）テスト中のプログラムの実行ステータスを分析するか、追跡と比較を実行し、プログラムの動作と設計仕様または顧客のニーズとの間の不一致を見つけます。
####コード分類を表示する必要があるかどうかに応じて：
- ブラックボックステスト
- ホワイトボックステスト
**ブラックボックステスト：**は、プログラムの内部ロジック構造や処理プロセスを考慮せずに、システムの入力と出力のみを考慮して、テスト対象のソフトウェアをブラックボックスとして扱うことです。ブラックボックステストの基本は、各ステージの要件仕様です（たとえば、要件分析ステージは製品要件仕様であり、ユニットテストステージは機能の詳細設計仕様です）。
**ホワイトボックステスト：**は、ブラックボックスを開いて、プログラムのソースコードと内部論理構造を調査します。ホワイトボックステストの基本はプログラムコードです。
ホワイトボックステストのカバレッジインジケータを使用して設計されたテストケースと、ブラックボックスメソッドによって取得されたテストケースは、重複することがよくあります。したがって、ホワイトボックステストは通常、ブラックボックステストの補足として機能します。
####テストの実行中に手動による介入が必要かどうかに応じて：
- 手動テスト
- 自動テスト
**手動テスト：**テスト計画の作成、テストケースの設計と実行、テスト結果の検査と分析など、テスト作業は完全に手動で行われます。従来のテスト作業は手動で行われます。
**自動テスト：**さまざまなテストアクティビティの管理と実装です。自動テストツールまたは自動テストスクリプトを使用して、テストスクリプトの開発と実行などのテストを実行し、特定の自動テストツールでテスト要件を検証します。 。このタイプのテストは通常、実行中に手動で介入する必要はありません。通常、機能テスト、回帰テスト、パフォーマンステストで広く使用されています。
その他のテストタイプ:(知っている、1つか2つだけ）
**スモークテスト：**オブジェクトは、正式にテストする必要がある新しくコンパイルされたソフトウェアバージョンであり、ソフトウェアの基本機能が正常であることを確認することを目的としています。テスト。
**ランダムテスト：**テスターの経験に基づいてソフトウェアの機能とパフォーマンスをチェックすることは、テストカバレッジの整合性を確保するための効果的な方法とプロセスです。
**パフォーマンステスト：**ソフトウェアが通常の環境およびシステム条件下でパフォーマンスインジケーターを満たしているかどうかを確認します。
①ストレステスト
②負荷テスト
実際の作業では、ソフトウェアテストプロセスはそれほど複雑ではありません。多くの場合、コストを節約するために、次のようにします
。1。要件に従ってテストプランを作成します
2.テストプランと製品要件に従ってテストケースを作成します
3.テストケースを実行します
4.回帰テスト
5.受け入れテスト
####ソフトウェアテストの仕様：この概念は非常に抽象的であり、会社の特定の条件に従って決定する必要があります。
会社の時間と人件費が十分である場合、テスト仕様では、テストドキュメントの作成、テストケースの数、テストデータの効率、手動テストと自動テストの配布、テストタスクの配布など、より高い要件を定義できます。などがより完璧になります。
ただし、会社の時間と人件費が限られている場合は、この仕様を適切に削減し、主要なテストドキュメントを作成する必要があります。テストデータには、少量で効率的なものが必要です。テストケースは迅速に実行し、フィードバックを迅速に行う必要があります。
面接前には、日々の心理的準備や定期的な自己紹介に加え、会社の立場に応じてレジュメを改善する必要があります。以下は、成熟したインターネット企業が行ったインタビューの要約です。企業に入るとき、担当者は最初に1時間テストペーパーに記入することです。私の意見では、これはインタビュアーのレベルと態度をテストすることです。そのため、インタビューでは、主にテストの質問とインタビューを組み合わせて、必要と思われる次の知識ポイントを要約します。
####インタビュー中の質疑応答（インタビュー/筆記試験）
1。ソフトウェアの品質とは何ですか？
ソフトウェアの品質：ソフトウェア製品の特性は、ユーザーの機能とパフォーマンスの要件を満たすことができます。
2.ソフトウェア製品の品質の6つの特性：
機能性、信頼性、使いやすさ、効率性、保守性、および移植性
3.ソフトウェアテスト仕様書には
** 1）テスト仕様が含まれます：**は開発仕様に従って策定されたテスト標準であり、テスト仕様は後のテストケースを作成するための重要な基礎でもあります。開発仕様は会社ごと、製品ごとに異なるため、テスト仕様の標準レベルは会社ごとに異なります。
理論から方法、さまざまなレポートテンプレートに至るまで、すべてが仕様の範囲に属します。一連の仕様が形成されると、テスト作業の進行がより安定し、すべての問題が十分に文書化されます。
** 2）テスト計画には次の内容が含まれます。** a。概要b。テストの目的c。テストの目的とリリース基準d。テストする領域が計画されています; e。テスト方法の説明f。テストスケジュールg。テストリソースh。構成スコープとテストツール
** 3）テストケース：**これは自己理解と記述仕様に依存します。後で時間があるときに整理します。
** 4）バグレポート（欠陥レコード）：**番号、バグが属するモジュール、バグの説明、バグレベル、発見日、発見者、変更日、変更者、変更方法、回帰結果など。
4.テストのライフサイクル
①
テスター向けのビジネストレーニングを実施する②テスト要件の分析
③テストプランを作成する
④テストケースを作成する
⑤テストの実行（バグ追跡を含む）
⑥テストレポートを作成する
注：各ステップが終了する前に、レビューに注意を払う必要があります。
5.バグのライフサイクル
New-Open-fixed-close（Testdirector）
欠陥ステータスは、一般に、新規、オープン、割り当て済み、修復済み、クローズ済み、および再開済みに分けられます。延期、繰り返し、拒否などの状態があります。
①欠陥が見つかりました（欠陥レポートを記録してプログラマーに提出してください）
②開く（プログラマーが変更します）
③解決します（テスターが確認し、欠陥が修復されました/レポートを閉じます）
④閉じる
6.ソフトウェアテストワークフロー
製品プロジェクトの確立-計画の準備-テストの準備-テストの実行-テストの評価-データの収集-完了の基準- -概略報告
7.補足テスト方法
Alphaαテスト（
内部
テスト）制御テストは、シミュレートされた実際の動作環境で内部ユーザーによって実行されます。Beitaβテスト（ユーザー受け入れテスト）
ユーザーは実際の使用環境でテストを実行し、開発者は通常テストサイトにいません。
Αβテストはによってテストすることはできません
システムテストタイプ
①互換性テスト：B / Sプロジェクト内の異なるブラウザ間のテストなど、ソフトウェアを指定されたハードウェアまたはソフトウェア環境に正常に移植できるかどうかをテストします。
②ユーザーインターフェーステスト（UIテスト）：
ユーザーインターフェーススタイルが顧客のニーズを満たしているかどうか、テキストが正しいかどうか、ページが美しいかどうか、ソフトウェアの外観と下部でユーザーと対話するパーツ（メニュー、ダイアログボックス、ウィンドウ、その他のコントロール）を指します。テキストと写真の組み合わせが完璧かどうか、そして操作がフレンドリーかどうか。
ユーザーインターフェイスがユーザーの期待やニーズを満たしているかどうか、および使いやすさ、人間味、操作のテストのしやすさなど、企業/業界の基準を満たしているかどうかを確認します。
③性能試験（疲労試験・ストレス試験・応答時間・インターフェース間
試験）④回復試験
⑤整合性・安全性
試験
⑥構造試験
△容量試験⑧機能試験（耐障害性［ロバスト性］試験）
8.ソフトウェアの欠陥レベルはどのように分割する必要がありますか？
ソフトウェアの欠陥レベルは、重大度と優先度で表すことができます。
重大度：顧客満足度に対する欠陥の影響の満足度を
1に分割して測定し、このモジュールを引き起こす可能性のある致命的なエラーとその他の関連するモジュールの異常、クラッシュなど;
2.重大なエラー、問題はこのモジュールに限定されているため、モジュールが誤動作したり、異常終了したりします;
3.一般的なエラー、モジュールの機能部分が失敗します;
4。モジュールを提案します。問題のある人がテストを提案しますモジュール改善の提案;
優先度：修復中の欠陥の緊急性;
1.即時解決（P1レベル）：欠陥により、システム機能がほとんど使用できなくなるか、テストを続行できず、すぐに修復する必要があります;
2.高優先度（P2レベル）：欠陥は深刻であり、テストに影響を与えるため、優先順位を付ける必要があります。3。
通常のキューイング（レベルP3）：通常は修復のために欠陥をキューに入れる必要があります
。4。優先度が低い（レベルP4）：時間があるときに欠陥を修正できます。
9.ソフトウェアテストの「5W」ルール、明確な内容とプロセスを教えてください。
「5W」ルールは、「何を」、「なぜ」、「いつ」、「どこで」、「どのように」を指します。「5W」ルールを使用してソフトウェアテストプランを作成すると、テストチームがテストの目的を理解し（理由）、テストの範囲と内容を明確にし（何を）、テストの開始日と終了日を決定し（いつ）、テストの方法とツールを指摘するのに役立ちます（方法）、テストドキュメントとソフトウェアの保存場所（場所）を指定します。
10.優れたテストケース設計の鍵は何だと思いますか？
ホワイトボックステストケース設計の鍵は、より少ないユースケースで可能な限り多くの内部プログラムロジック結果をカバーすることです。
ブラックボックステストケース設計の鍵は、より少ないユースケースでモジュールの出力および入力インターフェイスをカバーすることでもあります。完全なテストを達成し、最小限の使用例で妥当な時間内に最大の問題を見つけることは不可能です。
11. 2進数から10進数（この基本的な計算方法を理解するため）
11111000111 497
12.テストライフサイクル：
計画、設計、実装、実行、要約、評価
13.テストプロセス：
1）要件に従ってテスト計画を作成します
2）テスト設計
3）テストケースを作成します
4）テストケースを実行します
5）回帰テスト
6）受け入れテスト
14.テストフェーズに従って、テストは次のように分割されます。
- 単体テスト
- 統合テスト
- 確認テスト
- システムテスト
- 受け入れテスト
15.ユニットテスト、統合テスト、およびシステムテストの焦点は何ですか？
回答：ユニットテストは、ソフトウェア開発プロセスで実行される最低レベルのテストアクティビティです。ユニットテストアクティビティでは、ソフトウェアの独立したユニットは次のようになります。テストは、他のパーツを分離して実行されます。テストは、サブルーチンの正確性の検証を含む、システムのモジュールに焦点を当てています。
統合テストは、アセンブリテストまたは共同テストとも呼ばれます。ユニットテストに基づいて、すべてのモジュールは、統合テストの設計要件に従ってサブシステムまたはシステムに組み立てられます。一部のモジュールは個別に機能しますが、接続時に正しく機能することは保証されません。プログラムの一部に反映できない問題は、全体的な状況にさらされ、機能の実現に影響を与える可能性があります。テストの焦点は、モジュール間の接続とパラメーターの転送です。
システムテストは、テストされたサブシステムをテスト用の完全なシステムにアセンブルすることです。システムがシステム計画仕様で指定された機能を実際に提供できるかどうかを確認するのに効果的な方法です。このテストは、システム全体の動作と他のソフトウェアとの互換性に焦点を当てています。
16.開発ライフサイクル
①計画
②需要分析
③設計
④コーディング
⑤テスト
⑥運用・保守
17.テスト終了の基準
- すべてのユースケースをテストする
- カバレッジは標準に達します
- 標準までの不良率
- 他の指標は基準を満たしています
18.欠陥に対してどのような管理措置が取られていますか？
回答：1。欠陥をより適切に管理するには、商用またはオープンソースの欠陥管理ツールを導入する必要があります。
2.欠陥のライフサイクルに従って、欠陥提出管理、欠陥ステータス管理、および欠陥分析管理を検討します。
3.検出されたすべての欠陥（テストまたはコード読み取りによって検出されたかどうかに関係なく）は、欠陥管理ツールに迅速かつ正確に送信する必要があります。これは、欠陥送信の管理です。
4.欠陥を提出した後、すぐに対応する開発者に割り当てる必要があります。欠陥を提出する人は、欠陥の状態に細心の注意を払い、欠陥をできるだけ早く解決できるように支援する必要があります。欠陥が解決されたら、欠陥の修復をすぐに確認する必要があります。そのような目的は2つあります。1つは欠陥をできるだけ早く解決すること、もう1つは欠陥状態の管理である後続の欠陥の分析を容易にすること（年齢などの欠陥関連情報の正確性を確保すること）です。
5.開発プロセスとテストプロセスをより良く改善するために、欠陥を分析し、欠陥のタイプや欠陥の年齢分布などの情報を要約する必要があります。これが欠陥分析の管理です。
19.ソフトウェアテストはいくつのステージに分割する必要がありますか？各ステージでテストする必要があるポイントを簡単に説明しますか？各ステージの意味ですか？
回答：一般的に、ユニットテスト、統合テスト、システムテスト、および受け入れテストに
分割できます。各ステージはに分割されます。テスト計画、テスト設計、ユースケース設計、実行結果、テストレポートの5つのステップで
は、最初のテストは各モジュールに焦点を当ててソースコードの正確性を確認します。この段階は、主にホワイトボックステスト方法を使用したユニットテストになります。次は、モジュールの統合と完全なソフトウェアパッケージを形成するための統合です。統合テストは、検証とプログラム構成の問題に焦点を当てています。ブラックボックステスト法が主に使用され、ホワイトボックステスト法が補足されます。
ソフトウェア統合後、確認とシステムテストを完了する必要があります。確認テストは、ソフトウェアがすべての機能要件とパフォーマンス要件を満たしていることを最終的に保証します。確認テストは、ブラックボックステスト方法のみを適用します。
20.設計文書テストとは何ですか？
回答：テスト設計はすべての要件を満たしていますか、また設計が妥当かどうか。
21.要件文書テストとは：
回答：メインのテスト要件に論理的な矛盾があるかどうか、および要件を技術的に実現できるかどうか。
#####大手インターネット企業への最初のインタビュー（筆記試験+インタビュー）の質問には、通常、次の内容が含まれています。後で拡張に集中できます。
1.上位5つのデータベーススクリーニング結果
2.ランディングページとテストの考慮事項のサイズ
インターフェイス|パフォーマンス|機能
3.ホワイトボックステスト、ブラックボックステスト
4.欠陥管理ツール
5.セレン自動テスト理解レベル
6.テストケース、境界値テストケース
7.ゴミ箱を渡してください。どのようにテストすればよいですか？
#####その他：
1。ユースケースを設計するための方法と基礎は何ですか？
回答：ホワイトボックステストケースの設計には、次の方法があります：基本パステスト\境界値分析\カバレッジテスト\ループテスト\データフローテスト\プログラムインストルメンテーションテスト\ミューテーションテスト。現時点では、詳細な設計仕様とそのコード構造が基本です。
ブラックボックステストケースの設計方法：ユーザーのニーズに基づくテスト\機能図分析方法\等価クラス分割方法\境界値分析方法\エラー推論方法\因果関係ダイアグラム法\判断テーブル駆動分析法\直交実験設計法。基本はユーザー要件仕様、詳細設計仕様です。
2.スタブモジュールとは何ですか？
回答：たとえば、関数Aでユニットテストを実行すると、テストされた関数ユニットには関数Bも含まれます。エラーと位置決めエラーを改善するには、シミュレートする関数Bのスタブを作成する必要があります。機能Bの機能は正しいことが保証されています。
3.ドライブモジュールとは何ですか？
回答：ドライバモジュールは、ほとんどの場合「メインプログラム」と呼ばれ、テストデータを受信してテスト済みモジュールに転送します。機能ユニットをユニットテストする場合、テスト済みユニット自体を独立して実行することはできず、送信する必要があります。ドライブ
モジュールを書き込むためのデータは、主に次のことを完了します：
1）テスト入力を受け入れる、
2）入力を判断する、
3）テスト対象ユニットに入力を渡し、テスト対象ユニットを駆動して実行する、
4）テスト対象ユニットの実行結果を受け入れる、そして
結果を判断します; 5）ユースケース実行の結果としてテストレポートを出力します。
4.バグジラ欠陥管理ツールを使用したソフトウェア欠陥（BUG）追跡の管理プロセスを説明します。
回答：1）テスターまたは開発者がバグを見つけたら、問題が属するモジュールを特定します。バグレポートに入力すると、システムから自動的に電子メールで通知されます。プロジェクトリーダーまたは開発者に直接通知します。
2）検証が正しければ、ステータスは
VERIFIEDに変更されます。製品全体がリリースされた後、ステータスはCLOSEDに変更されます。3）まだ問題があり、REOPENED、ステータスが再び「New」に変更され、電子メール通知が送信されます。
4）プロジェクトチームリーダーは、特定の状況に応じて、バグが属する開発者に再割り当てされます。
5）はいの場合、それに対処し、解決し、解決策を示します。（パッチの添付ファイルと補足説明を作成できます）
6）電子メール情報を受信した後、開発者はそれが自分の変更の範囲内であるかどうかを判断します。
7）そうでない場合は、割り当てられるべきプロジェクトリーダーまたは開発者に再割り当てされます。
8）テスターは、開発者が変更したバグを照会して再テストします。
5.完全なブラックボックステストを実行できる場合でも、ホワイトボックステストを実行する必要がありますか？（ホワイトボックスとブラックボックスの違い）
A：エンジニアリング製品（エンジニアリング製品であることに注意）は、次の2つの方法のいずれかで実行できます。テスト。
ブラックボックステスト：製品の機能設計仕様を知っているので、実装された各機能が要件を満たしているかどうかを証明するためにテストを実行できます。ホワイトボックステスト：製品の内部作業プロセスを知っているテストを使用して、各内部操作が設計仕様を満たしているかどうか、およびすべての内部コンポーネントがチェックされているかどうかを証明できます。
ソフトウェアのブラックボックステストは、ソフトウェアのインターフェイスでテストを実行する必要があることを意味します。このメソッドは、テストオブジェクトをブラックボックスと見なし、テスターはプログラムの論理構造と内部特性をまったく考慮せず、プログラムの機能がプログラムの要件仕様に基づいてその機能の説明を満たしているかどうかを確認するだけです。したがって、ブラックボックステストは機能テストまたはデータ駆動型テストとも呼ばれます。ブラックボックステストは、主に次のタイプのエラーを見つけることです
。1。正しくない、または欠落している機能がありますか？
2。インターフェイスで、入力を正しく受け入れることができますか？正しい結果を出力できますか？
3。データ構造エラーがありますか？または、外部情報（データファイルなど）のアクセスエラー？
4。パフォーマンスは要件を満たすことができますか？
5。初期化または終了エラーはありますか？
ソフトウェアのホワイトボックステストは、ソフトウェアの手順の詳細の詳細な検査です。このメソッドは、テストオブジェクトをオープンボックスと見なします。これにより、テスターはプログラム内のロジック構造と関連情報を使用して、プログラムのすべてのロジックパスをテストするテストケースを設計または選択できます。さまざまな時点でプログラムの状態を確認することにより、実際の状態が期待される状態と一致しているかどうかを判断します。したがって、ホワイトボックステストは、構造テストまたはロジック駆動テストとも呼ばれます。ホワイトボックステストは、主に次の相対的なプログラムモジュールをチェックすることです
。1。プログラムモジュールのすべての独立した実行パスを少なくとも1回テストします。
2.すべての論理的判断について、「真」と「偽」の2つのケースを少なくとも1回テストできます。
3.ループの境界と操作の境界内でループ本体を実行します。
4.内部データ構造などの妥当性をテストします。
上記の事実は、ソフトウェアテストに致命的な欠陥、つまり、不完全なテストと不完全なテストがあることを示しています。どのプログラムも（膨大な数の徹底的な）限られたテストしか実行できないため、エラーが見つからない場合、プログラムにエラーがないとは言えません。
最後に言いたいのは、実際、個々の面接の仕事の要件とあなた自身の給与の期待に応じて、企業のキャリアに必要な技術的および理論的知識は、あなたの経験とニーズを満たすかどうかを定義する技術的能力に基づいているということです。私はプロジェクトの経験がない転職者なので、理論的な知識を強化し、言語の学習、Javaの選択、データベースの学習、基本的なSQLの追加、削除、変更などのボーナスポイントを拡大し続けることができます。チェック;セレンの記録を自動化することも学びます、これらは私ができるすべてです。その後、面接前に上記の知識ポイントを見直し、面接中の回答はスムーズで論理的で、基本的に問題はありませんでした。
私たち自身の手で主導権を握ることによってのみ、私たちは選択する権利を持つことができます。