序文
以前にいくつかのインタビューの質問を見て、役に立つだろうといつも感じていましたが、何度も読んでも覚えられないので、あらゆる分野の偉人がすべて共有しているすべてのインタビューの質問を統合しました。スワイプすれば、あちこちで質問を探す必要はなく、今日私が整理した面接の質問を共有できます。同時に、すべての人向けにソフトウェア テストのビデオ チュートリアルも用意しました。必要に応じて直接視聴することも、記事の最後にある小さなカードを直接クリックして情報ドキュメントを入手することもできます。無料で
以下で無料のビデオチュートリアルをご覧ください。
https://www.bilibili.com/video/BV1SY4y1p7k6/?spm_id_from=333.999.0.0&vd_source=74d0257ec7066cc4f9013524f0bb70131. JD ソフトウェアテスト面接後の 30 の質問 (乾物)
1. ブラック ボックス テストのテスト ケースの一般的な設計方法は何ですか? テスト ケースの設計におけるこれらのメソッドの適用を説明するには、具体的な例を使用してください。
1) 等価クラスの分割: 等価クラスとは、入力フィールドのサブセットを指します。このサブセットでは、各入力データはプログラムのエラーを明らかにすることに相当します。次のように仮定するのが合理的です: 特定の等価性をテストする フィールドの代表値クラスはこのクラスの他の値のテストと等しいため、すべての入力データは合理的に複数の同値クラスに分割でき、各同値クラスの 1 つのデータがテストの入力条件として取られ、少量の代表的なテスト データの取得 良好なテスト結果の取得 同値クラスの分割には、有効な同値クラスと無効な同値クラスの 2 つの異なる状況が考えられます。
2) 境界値分析: 同値クラス分割法を補足するものです。テスト業務の経験から、入出力範囲内ではなく、入出力範囲の境界で多くのエラーが発生することがわかっているため、さまざまな境界条件に合わせてテスト ケースを設計することで、より多くのエラーを検出できるようになります。
境界値分析手法を使用してテスト ケースを設計するには、最初に境界条件を決定する必要があります。通常、入力と出力の同値クラスの境界は、テストに重点を置く必要がある境界条件です。値が完全に等しい、同値クラス内の典型的な値や任意の値をテスト データとして選択するのではなく、境界よりわずかに大きいか小さい値をテスト データとして選択する必要があります。
3) エラー推測方法: 経験と直観に基づいて、プログラム内のすべての考えられるエラーを推測し、的を絞った方法でテスト ケースを設計します。
エラー推測手法の基本的な考え方: プログラム内で考えられるすべてのエラーとエラーが発生しやすい特殊なケースをリストし、それらに基づいてテスト ケースを選択します。たとえば、モジュール内の多くの一般的なエラーは単体テスト中にリストされています。従来品 テストで見つかったエラー等、経験をまとめたものです また、入力データ、出力データが0である、入力フォームが空白、または入力フォームが1行しかない などの状況です。これらの状況を選択できます 次の例はテスト ケースとして使用されます。
4) 特性要因図法：上記で紹介した同値クラス分割法と境界値分析法は、いずれも入力条件を考慮することに重点を置いており、入力条件間の関係や相互の組み合わせなどは考慮していません。入力条件の組み合わせにより、新たな状況が生成される場合もありますが、入力条件の組み合わせを確認することは容易ではありません。すべての入力条件を同値類に分けたとしても、それらの組み合わせは非常に多く存在します。さまざまな条件の組み合わせを記述し、それに応じて複数のアクションを生成してテストケースの設計を検討するために、因果関係図（ロジックモデル）を使用する必要があります。因果関係図法の最終結果は、判定テーブルですので、様々な組み合わせのプログラム入力条件を確認するのに適しています。
5) 直交テーブル分析手法: 多数のパラメータの組み合わせによりテストケースの数が急増する可能性がありますが、これらのテストケースには明らかな優先順位の差がなく、テスターがこのようなテストを完了することはできません。多数のテストがあるため、直交表を使用していくつかのユースケースを削減し、できる限り少ないユースケースでできるだけ広い範囲をカバーできるようにすることができます。
6) シナリオ分析手法: ユーザーのシナリオに従ってユーザーの操作ステップをシミュレートすることを指し、特性特性図に似ていますが、実行の深さと実現可能性がより優れている可能性があります。
7) 状態図法: 入力条件とシステム要件の記述を通じてテスト対象システムのすべての状態を取得し、入力条件と状態を通じて出力条件を取得し、入力条件、出力条件および状態を通じてテスト対象システムのテスト ケースを取得します。
8) アウトライン法: アウトライン法は要件に着目した方法であり、さまざまなテスト条件を列挙するために、要件をアウトラインに変換します。アウトラインは、ルートと各リーフ ノードの間に一意のパスを持つツリー構造として表されます。アウトライン内の各パスは、テスト ケースの定義に使用される特定の入力条件のセットを定義します。ツリー内のリーフまたはアウトライン内のパスの数から、すべての機能をテストするのに必要なテスト ケースのおおよその数がわかります。
2. テスト アクティビティの完全なプロセスを詳細に説明します。(参考までに、この回答は主にウォーターフォールモデルの実践です)
プロジェクトマネージャーは顧客とコミュニケーションをとりながら要件書を完成させ、開発者とテスターは共同で要件書のレビューを完了します レビュー内容には、要件の記述が不明瞭な箇所や、明らかな矛盾や実現不可能な箇所が含まれます機能。プロジェクトマネージャーは、開発者、テスター、顧客の意見を統合してプロジェクト計画を完成させます。その後、SQA がプロジェクトに入り、統計と追跡を開始します。
開発者は要求書に従って要件分析書を完成させ、テスターは両者の認識漏れや認識の相違がないかを主なレビュー内容とします。テスターはテスト計画文書を完成させます。テスト計画に含まれる内容は上記で説明されています。
テスターは修正された要件分析書に従ってテストケースの作成を開始し、開発者は概要設計書と詳細設計書を完成させます。これら 2 つのドキュメントは、テスターがテスト ケースを作成するための補助資料になります。
テスト ケースが完了したら、テストと開発をレビューする必要があります。
テスターが環境を構築する
開発者は最初のバージョンを提出しますが、説明が必要な未完成の機能がある可能性があります。テスターはテストを実施し、バグを発見した後、BugZilla に送信します。
開発者はバグ修正や機能追加を含む第2版を提出し、テスターがテストを実施します。
上記の作業を繰り返すと、通常 3 ～ 4 バージョン後に BUG の数が減り、出荷要件が満たされます。
顧客から問題が報告された場合、テスターは再現と再テストを支援する必要があります。
3. BUG管理ツールの追跡プロセス（例としてBugZillaを使用）
テスターは BUG を見つけて Bugzilla に送信します。ステータスは新規です。BUG の受信者は開発インターフェイス担当者です。
開発インターフェースは該当モジュールの開発者にバグを割り当て、ステータスが割り当て済みに変更されます。開発者とテストはバグを確認します。自分のバグの場合は受信するように設定され、別のバグの場合は受信するように設定されます。開発者の問題がある場合、転送されます。この動作を実行するかどうかは次の開発者次第です。問題がない場合は、議論して確認し、このバグを拒否する必要があります。その後、テスターがこの問題をクローズします。
開発者がバグを受け入れて変更した場合は、バグのステータスを修正済みに変更し、テストをテストできるバージョンを通知します。
テスターは新しいバージョンでテストを行い、問題がまだ存在することが判明した場合は検証を拒否し、問題が修正された場合はバグを閉じます。
4. テスターと開発者間のコミュニケーションのプロセスにおいて、コミュニケーションの効率と効果を向上させるにはどうすればよいと思いますか? テスターと開発チームの他のメンバーの間で良好な人間関係を維持するための鍵は何ですか?
対面でのコミュニケーション、次に電話での直接コミュニケーションを心掛け、メールなどタイムリーでないコミュニケーションツールでしかコミュニケーションが取れない場合には、その特性を深く理解し、明確に表現できる必要性を強調しましょう。
また、TestDirector などのテスト管理ツールを使用して管理するとより効果的ですが、TestDirector には BUG に関する正確な記述があることに注意してください。
チーム内のテスターと開発者の間で良好なコミュニケーションを確立するには、次の点に注意してください。
1 つは誠実さ、2 つ目はチームスピリット、3 つ目は職業上の共通言語を持つこと、4 つ目は人ではなく物事について正しく、仕事を第一に行うことです。
もちろん、バグ追跡システムに入る代わりに、小さな問題を直接指摘することで、相手の好感度を高めることもできます。
5. テストに関して最も興味があるのはどこですか? なぜ？
この面接の質問に対する明確で統一された答えはありませんが、多くの企業で尋ねられる可能性があります。検討のために次の回答を提供してください。
最大の関心、これはやりがいのある仕事だと感じていること。
テストは経験産業であり、長く働けば働くほど、テストで良い仕事をすることの難しさと楽しさは増します。
自分の仕事を通じて、ソフトウェア製品をどんどん完成させ、その楽しさを体験することができます。
これらの質問に答えるときは、次の点に注意してください。
可能な限り採用企業の技術ルートに合わせて興味を表明し、例えばデータベースアプリケーション会社であればデータベースのテストに興味があり、テストを通じてデータベースの習熟度を向上させたいと考えています。
テストの目的は、あなたの能力を向上させ、より良いテストを行うことであることを示し、雇用主がそのような取り決めをしていない限り、能力の向上は将来の能力開発やその他の目的のためではありません。
求人企業の範囲を超えて興味を表明しすぎないでください。たとえば、人材紹介会社は金融関連のソフトウェアを扱っているが、あなたはゲーム ソフトウェアに興味を示している、または人材紹介会社は JAVA 開発を行っているが、あなたは C 言語プログラムの開発に興味を示している、などです。
6. テストの利点は何だと思いますか?
この面接に決まった答えはありませんが、以下の点を参考に自分の特徴を組み合わせてみてください。
回復力があり、忍耐強く、組織的で、課題に直面するのが好きで、何事もうまくやる自信があり、コミュニケーション能力が高く、前マネージャーからの良いコメントが私が順調に進んでいることを示しています
7. これまでの仕事で行ったこと、およびよく知っていることを簡単に説明します。参考回答は以下の通りです。
これまでの私の主な仕事は、システムテストと自動化テストでした。システムテストでは、主にBOSSシステムのビジネスロジック機能とソフトスイッチシステムのクラス5特性をテストします。パフォーマンステストでは主にストレステストを実施し、さまざまなリクエスト数におけるシステムの応答時間やシステムリソース消費量を取得します。自動テストは主に、自作のスクリプトといくつかのサードパーティ ツールを組み合わせてソフトスイッチの特性をテストすることです。
テストでは、ユーザーのニーズを正確に理解することが非常に重要だと感じています。さらに、BUG の管理は要件に基づいて行う必要があり、すべての BUG を変更する必要はありません。
新しいバージョンでは、最初に発見されたバグのほとんどは修正されていますが、本来の正しい機能が正しくなくなる可能性があるため、テスト作業には忍耐と細心の注意が必要です。したがって、反復テストと回帰テストに注意してください。
8. C/C++ での static の用途は何ですか? (少なくとも2つ以上指定してください)
1) 関数本体で、static として宣言された変数は、関数の呼び出し中にその値を維持します。
2) モジュール内 (ただし関数本体の外) では、static として宣言された変数は、モジュール内で使用される関数からアクセスできますが、モジュール外の他の関数からはアクセスできません。ローカルグローバル変数です。
3) モジュール内で、static として宣言された関数は、このモジュール内の他の関数からのみ呼び出すことができます。つまり、関数は、それが宣言されているモジュールのローカル スコープに制限されます。
9. 参照とポインタの違いは何ですか?
1) 参照は初期化する必要がありますが、ポインタは初期化しません。
2) 参照は初期化された後は変更できませんが、ポインタは指すオブジェクトを変更できます。
3) null への参照はありませんが、null へのポインタは存在します。
10. インターネットではどのネットワーク プロトコルが使用されますか? プロトコルの主な階層? インターネットの物理アドレスと IP アドレスの変換にはどのようなプロトコルが使用されますか?
TCP/IP プロトコルの主な階層構造は、アプリケーション層/トランスポート層/ネットワーク層/データリンク層です。
ARP (アドレス解決プロトコル) (アドレス解決プロトコル)
11. 統合テストにおけるトップダウン統合とボトムアップ統合という 2 つの戦略についての理解を教えてください。それぞれの長所と短所、および主にどのタイプのテストに適しているかについて話してください。
トップダウンの統合
利点: 主要な制御および判断ポイントがより早期に検証される; 完全なソフトウェア機能を最初に深さに応じて実現および検証できる; 機能がより早期に検証されるため、信頼性がもたらされる; 必要なドライバは 1 つだけであり、ドライバ開発コストが削減される; 障害分離をサポートします。
短所: カラムの開発量が多い、基礎となる検証が遅れる、基礎となるコンポーネントが十分にテストされていない。
製品管理構造は比較的明確で安定しています。高レベルのインターフェースはほとんど変更されません。低レベルのインターフェースは未定義であるか、頻繁に変更される可能性があります。生産および港湾制御コンポーネントには高い技術的リスクがあり、できるだけ早く検証する必要があります。 ; 製品のシステムの機能的な動作をできるだけ早く確認したいと考えています。
ボトムアップの統合
利点: 基礎となるコンポーネントの動作を早期に検証できます。最初に作業を並行して統合できるため、トップダウンよりも効率的です。スタブの作業負荷が軽減され、障害の分離がサポートされます。
短所: ドライバーの開発負荷が大きい、高レベルの検証が遅れ、設計ミスの発見が間に合わない。
基礎となるインターフェイスは比較的安定しており、上位レベルのインターフェイスは頻繁に変更され、基礎となるコンポーネントはより早く完成します。
12. ソフトウェア受け入れテストには、正式な受け入れテスト、アルファ テスト、ベータ テストが含まれます。
13. システム テストには、パフォーマンス テスト、負荷テスト、強度テスト、ユーザビリティ テスト、セキュリティ テスト、構成テスト、インストール テスト、ドキュメント テスト、障害回復テスト、ユーザー インターフェイス テスト、回復テスト、配布テストなど、さまざまな戦略があります。テスト、ユーザビリティテスト。
14. システムテスト計画を設計する際に参照する必要があるプロジェクト文書には、ソフトウェアテスト計画、ソフトウェア要件成果物、および反復計画が含まれます
。特性特性図を描いてテスト ケースを作成する手順は、__、__、__、__、特性特性図を状態図に変換するという 5 つのステップがあります。特性要因図を使用してテスト ケースを生成する基本的な手順は次のとおりです。
§ 原因 (つまり、入力条件または入力条件の同等のクラス) であり、結果 (つまり、出力条件) であるソフトウェア仕様の記述を分析し、それぞれの原因と結果に識別子を割り当てます。
§ ソフトウェア仕様記述の意味を分析し、原因と結果、原因と原因の対応関係を調べ、それらの関係に従って、因果関係図を描きます。
§ 文法的または環境的な制約により、原因と原因の組み合わせ、および原因と結果の間の組み合わせの中には不可能なものもあります。これらの特殊なケースを示すために、因果図上に制約または制限が記号でマークされます。§ 因果関係図を意思決定表に変換します。
§ 判定表の各列を基にしてテストケースを設計します。
16. これらのテストを最もよく行うのは誰ですか、また何をテストするのか教えてください。
コードおよび関数レベルのテストは通常、ホワイトボックス テスターによって行われ、各コードまたは関数の正確性をチェックして、指定された関数が正しく実装されているかどうかを確認します。
モジュールおよびコンポーネント レベルのテストの主な基礎は、プログラム構造設計とテスト モジュール間の統合と呼び出し関係であり、これは通常、テスターによって完了されます。
システムテストはモジュールテストと単体テストに基づいて行われます。システムの機能と性能を理解し、テストケースに基づいて総合的なテストを実施します。
17. テスト ケースを設計するときはどのような側面を考慮する必要がありますか?つまり、どの側面がさまざまなテスト ケースでテストされますか?
テストケースを設計する際には、全体のプロセスや機能だけでなく、強度テスト、性能テスト、ストレステスト、境界値テスト、安定性テスト、セキュリティテストなどの側面にも注意を払う必要があります。(テスト ケースで考慮する必要がある 4 つの基本要素は、入力、出力、操作、およびテスト環境です。さらに、テスト ケースでは、テストの種類 (機能、パフォーマンス、セキュリティなど) を考慮する必要があります。この部分は、 TP を参照することで回答できます。また、ユースケースの重要性と優先順位も考慮する必要があります)
18. Windowsでテキストファイルを保存する際、保存ダイアログが表示されるのですが、そのファイル名でテストケースを作成する場合、同値クラスはどのように分ければよいのでしょうか？
A などの半角文字、全角文字、AA、I I、特殊文字 /'。';、=- など、com などの予約語、ファイル形式が 8.3 形式である、ファイル名形式が 8.3 形式ではない、/,, * などの 9 個の特殊文字。
19. 10 文字の郵便番号の入力を必要とするテキスト ボックスがあると仮定すると、そのテキスト ボックスを同等のクラスにどのように分割する必要がありますか?
10 * や ¥ などの特殊文字、ABCDefghik などの英字、123 などの 10 文字未満、11111111111 などの 10 文字を超える文字、123AAAAAAAA などの数字とその他の混合、空文字、予約文字
20. ソフトウェアテストプロジェクトはいつ始まりましたか? なぜ？
テストの対象はプログラムのコーディングだけではなく、ソフトウェア開発プロセスで生成されるすべての製品をテストする必要があり、ソフトウェアの欠陥は拡大する傾向があるため、ソフトウェアテストは要件分析の段階で行う必要があります。修理にかかる費用が多ければ多いほど、費用も高くなります。
21. 回帰テストとは何ですか?
回帰テスト: (回帰テスト): 回帰テストには、ユースケース回帰とエラー回帰の 2 種類があります。ユースケース回帰は、一定期間後に以前に使用したユースケースに戻って再テストし、問題が見つかるかどうかを確認することです。また。バグリグレッションとは、以前のバージョンで発生し修正された不具合を新バージョンで再検証し、その不具合を核として該当する修正部分をテストする手法です。
22. 単体テスト、統合テスト、システムテストの焦点は何ですか?
単体テストは、ソフトウェア設計の最小単位であるプログラムモジュール（プロセス指向では関数や手続き、オブジェクト指向ではクラス）を対象とし、各プログラムモジュール内に存在する可能性のあるエラーを発見する正当性チェックのテスト作業です。手動静的検査 / 動的実行追跡
統合テストは、単体テストに合格した各モジュールに統合されたコンポーネントの検査を目的としており、その主な内容は各単体モジュールと実現された機能間のインターフェイスです
。システムテストは、統合されたソフトウェアシステムを対象としており、コンピュータシステム全体の要素として、コンピュータハードウェア/周辺機器/一部のサポートソフトウェア/データや人員などの他のシステム要素と組み合わされており、一連の統合テストと確認テストが行われます。オペレーティング環境のコンピュータ システム上で実行されます。
23. テストエンジニアはどのような資質を備えている必要がありますか?
1. 責任感 2. コミュニケーション能力 3. チームワークの精神 4. 忍耐力、慎重さ、自信 5. 常に疑いの姿勢を持ち、不具合防止の意識を持つ 6. 一定のプログラミング経験がある
24. どのような種類のソフトウェア テストを知っていますか?簡単に紹介します。
テスト戦略によって分類されます。 1. 静的テストと動的テスト 2. ブラック ボックス テストとホワイト ボックス テスト 3. 手動テストと自動テスト 4. スモーク テスト 5. 回帰テスト。
テストフェーズによって分類: 単体テスト、統合テスト、システムテスト。
その他の一般的なテスト方法: 1. 機能テスト 2. パフォーマンス テスト 3. ストレス テスト 4. 負荷テスト 5. ユーザビリティ テスト 6. インストール テスト 7. インターフェイス テスト 8. 構成テスト 9. ドキュメント テスト 10. 互換性テスト 11. セキュリティ テスト 12 、回復テスト
25. テスト計画をうまく進めるための鍵は何だと思いますか?
テストの目的を明確にし、テスト計画の実行可能性を高める
ソフトウェア テスト計画を作成する重要な目的は、テスト プロセスでより多くのソフトウェア欠陥を発見できるようにすることです。そのため、ソフトウェア テスト計画の価値は、テスト プロジェクトの管理と潜在的なソフトウェア欠陥の発見に役立つ能力に依存します。したがって、ソフトウェア テスト計画のテスト範囲は機能要件を高度にカバーし、テスト方法は実用的で、テスト ツールは非常に実用的で使いやすく、生成されるテスト結果は直感的で正確でなければなりません。
「5W」ルールを遵守し、内容とプロセスを明確にする
「5W」ルールとは、「What（何をするか）」、「Why（なぜ行うのか）」、「When（いつ行うか）」、「Where（どこで）」、「How（どう行うか）」のことを指します。 」。「5W」ルールを使用してソフトウェア テスト計画を作成すると、テスト チームがテストの目的 (Why) を理解し、テストの範囲と内容 (What) を明確にし、テストの開始日と終了日 (When) を決定するのに役立ちます。 )、テストの方法とツール (How) を示し、テスト文書とソフトウェアの保管場所 (Where) を示します。
レビューと更新のメカニズムを採用して、テスト計画が実際のニーズを満たしていることを確認します
テスト計画書作成後、レビューされていない場合は、テストチームに直接送信され、テスト計画書の内容が不正確であったり、テスト内容が省略されていたり、変更によりテスト範囲が増減したりする可能性があります。ソフトウェア要件に記載されていないため、テスト計画の内容が時間内に更新されておらず、誤解を招く可能性があります。
テスト計画を作成し、詳細仕様書、テストケースをそれぞれテストします。
詳細なテスト技術指標は独自に作成したテスト詳細仕様書に含める必要があり、テストチームがテストプロセスを実行するようにガイドするために使用されるテストケースは、独自に作成したテストケース文書またはテストケース管理データベースに配置する必要があります。テスト計画とテスト仕様およびテスト ケースの間には戦略的および戦術的な関係があり、テスト計画は主にマクロの観点からテスト アクティビティの範囲、方法、リソースの割り当てを計画しますが、テスト仕様とテスト ケースは具体的なものです。テストタスクを完了するための戦術。
26. テストケース設計で良い仕事をするための鍵は何だと思いますか?
ホワイトボックス テスト ケース設計の鍵は、より少ないテスト ケースでできるだけ多くの内部プログラム ロジックの結果をカバーすることです。
ブラックボックス ユース ケース設計の鍵は、より少ないユース ケースでモジュールの出力インターフェイスと入力インターフェイスをカバーすることでもあります。最小限のユースケースで妥当な時間内に最大限の問題を見つける完全なテストは不可能
27. テストのキャリア開発の目標は何ですか?
テスト経験が豊富であればあるほど、テスト能力は高くなります。したがって、私のキャリア開発には、上級テストエンジニアに向けて一歩ずつ積み重ねる時間が必要です。また、最初の 3 年間でテストの経験を積み、常に自分自身を更新および修正し、テスト タスクで良い仕事をするという予備的なキャリア プランもあります。
28. テスト終了の基準は何ですか?
ミクロな観点から見ると、テスト計画で定義されています。たとえば、システムが一定のパフォーマンスの下で 72 時間スムーズに動作することです。現在、バグ追跡システムでは、このバージョンには一般的な重大なバグはありません。この数値は、一般的なバグの数が 3 未満、バグ修正率が 90% 以上のパラメータを設定し、開発マネージャー、テスト マネージャー、プロジェクト マネージャーが署名してバージョン リリースに同意します。
マクロについて言えば、ソフトウェアが完全に消滅した時点でテストは終了します。
29. 完全なテストセットはどの段階で構成されますか?
実現可能性分析、要件分析、全体設計、詳細設計、コーディング、単体テスト、結合テスト、システムテスト、受け入れテスト
30. あなたが過去に働いていた会社のソフトウェア開発プロセスを知っていますか? もしそうなら、開発プロセス全体でどのような作業を行う必要があるか説明してください。これらのタスクを達成するためのさまざまな役割は何ですか? 以前のテストの仕事では、具体的にどのようなタスクに取り組んできましたか? 仕事のどの部分が一番得意ですか?
開発プロセス - 要件調査（要件担当者）、要件分析（要件担当者）、概要設計（設計者）、詳細設計（設計者）、コーディング（開発者）
テストプロセス - 要件レビュー、システムテスト設計、概要設計レビュー、統合テスト設計、詳細設計レビュー、単体テスト設計、テスト実行
テスト作業の全プロセスを行っており、テスト設計が得意
品質を決めるのはプロセスであり、ソフトウェアのプロセス改善はあくまでもソフトウェアの品質を向上させ、過去のさまざまな経験や教訓を蓄積することです。
2. ソフトウェアテストの古典的な面接の質問はすべてここにあり、最初の 5 つの質問は必ず聞かれます
質問 1: ソフトウェア テストの業界を選んだ理由は何ですか?
回答: ソフトウェア テストが大好きなので、キャリアとしてソフトウェア テストを選びました。ソフトウェアテストは、ソフトウェアプログラミングよりも挑戦的で創造的な職業だと思います。(開発を続けることができないからソフトウェア テストを行うことにしたとは言わないでください。また、コードを入力するのは好きではないとも言わないでください)
質問 2: ソフトウェア テストについてのあなたの理解について教えてください。
回答: ソフトウェア テストは、ソフトウェアの機能を検証し、欠陥、バグ、誤動作のない良好な標準のソフトウェア製品を作成するプロセスです。
質問 3: テスト ログとは何ですか?
回答: テスト ログには、ソフトウェア テスト中に実行された操作の完全なリストが含まれており、テスト ログからテストが成功したか失敗したかを知ることができます。
質問 4: 手動テストと自動テストの違いは何ですか?
回答: 手動テストはユーザーが手動で実行し、自動テストは事前スクリプトを使用して自動的に実行されます。自動テストはより速く、より安全で、費用対効果が高くなりますが、手動テストは時間がかかり、安全性も低くなります。
質問 5: ホワイト ボックス テストとブラック ボックス テストの違いは何ですか?
回答: ホワイト ボックス テストは、ユーザーが内部構造の実現を知る必要があるソフトウェア テスト方法ですが、ブラック ボックス テストでは、ユーザーはユーザーの内部動作モジュールを知る必要はありません。ホワイト ボックス テストでは、ユーザーはプログラミング スキルを持っている必要がありますが、ブラック ボックス テストでは、ユーザーはプログラミング スキルを必要としません。
質問 6: ブラック ボックス テストの利点は何ですか?
回答: ブラック ボックス テストは、プログラミングの知識がほとんどないユーザーでも実行でき、ホワイト ボックス テストのプロセスよりもはるかに高速です。ソフトウェアのすべてのコンポーネントとモジュールはテストされていないため、ソフトウェア製品にほとんどエラーが発生する可能性があります。
質問 7: ホワイト ボックス テストの利点は何ですか?
回答: ホワイト ボックス テストでは、各コンポーネントがプログラマーによってテストされるため、ソフトウェア製品の高品質が保証されます。これは時間のかかるプロセスであり、ブラック ボックス テストよりも時間がかかります。
質問 8: 回帰テストとは何ですか?
A: ソフトウェアを変更または修正した場合は、ソフトウェアの機能が適切に動作していることを確認し、ソフトウェアに意図しないバグがないことを確認するために再テストします。このテストプロセスは回帰テストと呼ばれます。
質問 9: 機能テストとは何ですか?
A: 機能テストは、顧客の仕様に対するテストおよび検証プロセスであり、顧客のすべての要件を満たします。
質問 10: テスト ケースとテスト スクリプトの関係は何ですか?
3、ソフトウェアテストの面接でよくある質問
1. テストの段階は何ですか?
一般的に単体テスト、結合テスト、確認テスト、システムテスト、受け入れテストの5段階に分かれます。
2. ソフトウェアのテスト方法は何ですか?
ブラックボックス、ホワイトボックス、グレーボックス。
3. データベースにおける sum と count の違いと使い方
一般的なインタビューでは、合計とグループごとの並べ替えを一緒に使用します
。 count: クエリするデータ レコードの数を数えます: select count(*) from students table;
sum: sum: select sum(chengji) from Student table where name='张three';
4. モジュールのテストケースを設計する
面接者の経験、ユースケース設計能力、考え方、習得したテスト手法が総合的に評価されているかを調査し、
機能テスト、インターフェーステスト、例外テスト、パフォーマンステスト、セキュリティテストの側面から分析する
5. pytest はテスト ケースをどのように管理しますか?
test で始める、Test にちなんだクラス名など、ケースのルールをマスターします。
単一の py ケース ファイルの実行方法、複数のフォルダーの管理方法
6. ソフトウェアテスト業界を選んだ理由は何ですか?
ソフトウェアテスト業界については以前から知っていたので、彼の発展の見込みは非常に高いと思います。
(開発ができないときにテストに切り替えるなんて言わないでください。)
7. ソフトウェアテストにはどのような種類がありますか?
テストの種類には、機能テスト、パフォーマンス テスト、インターフェイス テストが含まれます。
8. テスト ケース、テスト スクリプトとは何ですか? 両者の関係は何ですか?
テストの実施のためにテスト対象システムに提供される、特定の入力データ、操作またはさまざまな環境設定、および期待される結果のセット。
テスト スクリプトは、自動テスト用に作成されたスクリプトです。
テスト スクリプトの記述は、対応するテスト ケースに対応する必要があります。
9. テスト計画とテストケースはどのように作成すればよいですか?
簡単に言えば、テスト計画には、詳細なテスト戦略とテスト方法、合理的かつ詳細なリソースの配置などが含まれている必要があります。テストケースに関しては、要件（機能要件と非機能要件を含む）が機能点まで絞り込まれているかどうかによって異なります。テストできるかどうかは待ってください。
10. ソフトウェアテストの戦略は何ですか?
ソフトウェア テスト戦略: 特定のソフトウェア テスト標準およびテスト仕様の指導の下、テスト プロジェクトの特定の環境制約に従って規定されたソフトウェア テストの原則、方法、方法の集合。
ソフトウェアテストの一般的な筆記試験の質問:
真または偽 (Y=はい、N=偽)
1. ソフトウェア テストの目的は、ソフトウェアの欠陥をできるだけ多く見つけることです。(Y)
2. ベータテストは受け入れテストの一種です。(Y)
3. 受け入れテストはエンドユーザーによって実行されます。(ん)
4. テスターは、プロジェクトが承認される前に成果物を提出する必要はありません。(Y)
5. 単体テストでは、ソフトウェアの欠陥の約 80% を見つけることができます。(Y)
6. コードレビューとは、ソースコードがモジュール設計の要件を満たしているかどうかを確認することです。(ん)
7. ボトムアップ統合では、テスターがドライバーを作成する必要があります。(Y)
8. 負荷テストは、テスト対象のシステムの最高レベルの機能を検証することです。(ん)
9. テスターは原則を遵守する必要があり、欠陥が修復されない場合は合格しません。(ん)
10. コードレビュー担当者は通常、テスターが担当します。(ん)
11. ソフトウェア構成の問題を人為的になくすことができます。(ん)
12. 統合テスト計画は、要件分析フェーズの最後に提出されます。(ん)
複数の選択肢
1. 以下のロジックカバレッジテスト方法のうち、最もカバレッジ能力が高いのは(D)です。
A．ステートメントの対象範囲 b. 判決内容 C. 条件の範囲 ｄ．条件の組み合わせの適用範囲
2. ブラックボックステストとホワイトボックステストの違いについて、次の記述のうち正しいものはどれですか(A)
A．ホワイトボックス テストはプログラム構造に焦点を当てますが、ブラックボックス テストは機能
Bに焦点を当てます。ホワイトボックステストでは自動テストツールが使用できますが、ブラックボックステストではツールが使用できません テスト問題集中講義100回
C．ホワイトボックス テストには開発者の参加が必要ですが、ブラックボックス テストにはその必要はありません
。ブラックボックステストはホワイトボックステストよりも広く使用されています
3. HTTPプロトコルにおけるステータスコードの表現について、次の記述のうち誤っているものはどれか(D)
A．1**: クライアントエラーを示します
B．2*: リクエストが正常に受信されたことを示します *
C. 3**: リクエストが完了し、顧客がリクエストをさらに調整する必要があることを示します
D. 4**: サーバーエラーを示します
4. Linux の場合: bugzilla.tar.gz を解凍し、tar コマンドによって処理されたファイル名の詳細をレポートするには、コマンド (A) を使用する必要があります。
A．tar –xvzf bugzilla.tar.gz B．tar –cvzf bugzilla.tar.gz
C．tar –cvzf bugzilla.tar.gz D．tar –cxvf bugzilla.tar.gz
5. Redhat Linux 9 でソフトウェア パッケージ perl.i386.rpm をインストールし、インストール中に # を使用してインストールの進行状況を表示するには、使用するコマンドは (A) です。
A．rpm –ih perl.i386.rpm B．rpm –i perl.i386.rpm
C．rpm –e perl.i386.rpm D．rpm –V perl.i386.rpm
6. Linux の vi エディターで、変更を保存せずに vi を終了したいとします。コマンドを使用する必要があるのは(C)です
A．:qa B．:qw C．:q! D．:!q
7. データベースには、教師テーブル (教師番号、教師名) とカリキュラム テーブル (コース番号、コース名、教師番号) の 2 つのデータ テーブルが格納されており、特定の教師が担当するコースをすばやく見つけるには、次のインデックスを使用します。確立された正しい方法は(C)です
A．
教師 ID Bによって教師テーブルにインデックスを作成します。
コース番号Cごとにカリキュラムのインデックスを作成します。
教師番号Dごとにカリキュラムのインデックスを作成します。教師名による教師テーブルのインデックス
8. book テーブル内の書籍名 (bookname) に「コンピュータ」を含むすべての書籍の状況を問い合わせるには、ステートメント (B) を使用できます。
A. SELECT * FROM book WHERE bookname LIKE 'computer'
B. SELECT * FROM book WHERE book_name LIKE '%computer%'
C. SELECT * FROM book WHERE book_name='computer'
9. アルファ テストに関する次の記述のうち、正しいものはどれですか: (AD)
A.α テストにはユーザー代表の参加が必要です
B.α テストにはユーザー代表の参加は必要ありません
C.α テストはシステム テストの一種です
D.α テストは受け入れテストの一種です
10. ソフトウェア テスト計画のレビューには誰が参加しますか? (ABCD)
A. プロジェクト マネージャー
B. SQA リーダー
C. 構成リーダー
D. テスト グループ
4. ネットワーク全体で最も完全なソフトウェア テストのインタビューの質問と回答 (パフォーマンス テスト + 機能テスト + インターフェイス テスト + 自動テスト)
性能試験
パフォーマンス テストのプロセスを簡単に説明してください。
1. パフォーマンス要件を分析します。
2. パフォーマンス テスト計画を作成します。
3. テスト ケースの作成
4. テスト環境の構築とテスト データの準備
5. パフォーマンス テスト スクリプトの作成
6. パフォーマンス テスト スクリプトのチューニング。
7. テストシナリオを設計します。
8. テスト結果を分析します。
9. 回帰パフォーマンステスト。
10. テストレポートを作成します。
パフォーマンステストはいつ、どのような環境で実行されますか?
テストは独立した性能テスト環境を構築し、時間的には
ベンチマークテスト：機能テスト後、システムが比較的安定したときに実施します。
負荷テスト: 誰もシステムを使用していない真夜中に
think_time の役割は何ですか?
実際の運用ユーザーの操作をシミュレートして、サーバーへの影響を調べます。
性能テストの結果が信頼できることを確認した後、次の問題が見つかった場合は、以下の考え方に従って問題を特定します。
検証コード機能を使って、どのように性能テストを行うのですか？
1. 検証コードを一時的にブロックし、性能テスト完了後に復元する
2. 汎用検証コードを使用する
パフォーマンステストの指標とは何ですか?
応答時間
スループット
CPU
メモリ
IO
ディスク
機能テスト
ソフトウェア テスト業界についてどう思いますか?なぜソフトウェア テストを選択する必要があるのですか?
ソフトウェアテストは有望なキャリアです。この業界での経験は豊富です。私はこのポジションに非常に適していると思いますので、しっかりと進んでいきたいと思っています。
テスト中にバグが見つかったが、開発者がそれはバグではないと考えた場合はどうすればよいでしょうか?
まず、提出および登録のために問題を欠陥管理プラットフォームに送信します。次に、判断の根拠と基準を取得するには、次のようにします。
要求仕様、製品説明、設計図書などに従って、実際の結果が計画と矛盾しているかどうかを確認し、欠陥を確認するための直接の根拠を提供します。
文書による根拠がない場合は、類似ソフトウェアの一般的な特性に基づいて欠陥があるかどうかを確認し、矛盾があるかどうかを説明できます。
ユーザーの一般的な使用習慣に従って、それが欠陥であるかどうかを確認するため。
設計者、開発者、プロダクトマネージャーなどの関係者と協議し、不具合かどうかを確認してください。
合理的な議論を行い、判断の理由を試験監督に説明し、客観性と厳密さに注意を払い、個人的な感情を混ぜないでください。プロダクト マネージャーが最終決定を下すのを待ちます。まだ議論がある場合は、テスト マネージャーに確認してください。オンライン レポートを送信するときは、このバグのリスクを早期警告として残し、プロジェクトの全員にこのことを知らせてください。状況。
テストケースを設計する方法にはどのようなものがありますか?
等価クラス、境界値、デシジョンテーブル、因果関係図。
ソフトウェアテストの戦略は何ですか?
ソフトウェア テスト戦略: 特定のソフトウェア テスト標準およびテスト仕様の指導の下、テスト プロジェクトの特定の環境制約に従って規定されたソフトウェア テストの原則、方法、方法の集合。
ソフトウェア開発プロセスにおけるテスターの仕事は何ですか?
(1) システムのバグをできるだけ早く発見する。
(2) ソフトウェア開発プロセスにおける欠陥を回避します。
(3) ソフトウェアの品質を測定し、システムの品質を保証する。
(4) 利用者のニーズに配慮し、システムが利用者のニーズを満たすよう努めます。全体的な目標は、ソフトウェアの品質を保証することです。
インターフェース自動テスト
取得と投稿の違いは何ですか?
Get リクエスト。ブラウザは http ヘッダーとデータを一緒に送信します。サーバーは 200 応答コードを返します
。Psot リクエスト。ブラウザは最初にヘッダーを送信し、サーバーは 100 (続行) に応答し、次にデータを送信します。サーバーは 200 応答を返します。コード
ポストはハイになるより安全です
インターフェイスの自動化での関連付けにどう対処するか?
前のリクエストで返された結果を次のリクエストのパラメータに渡し、リクエストの結果をクラス属性に反映し(setattr()関数を使用)、次のリクエストでクラス属性を呼び出します。
自動テストの結果を確認するにはどうすればよいですか?
アサーション。期待される結果が実際の結果と比較されます。
テストシナリオに従ってデータベース検証を行い、リクエスト前にデータベース内のデータをクエリし、データを比較します。
パラメータ化とデータドリブンについての理解について教えてください。
この質問には、自動テストにおける 2 つの非常に重要な概念、パラメーター化とデータ駆動型が関係します。実際、テスト スクリプトとデータの分離は同じことのように思えます。例: ログイン スクリプトは元々、ユーザー名、パスワードといったテスト データの固定セットを書き込んでいました。データが変更されるたびにスクリプトも変更する必要があります。データをスクリプトから分離したい場合は、ユーザー名とパスワードを外部 (できれば外部ファイル) に抽出します。これはパラメーター化と呼ばれます。
パフォーマンス テストでは、実際のビジネス シナリオに近い、各仮想ユーザーが異なるユーザー名とパスワードを使用してログインするようにしたいと考えています。自動テストでは、さまざまな種類のユーザー名やパスワードなど、さまざまなデータの組み合わせをテストしたいと考えています。どのようなシナリオであっても、データは複数存在する必要がありますが、ログイン操作のプロセスは固定されています。これをデータドリブンと呼びます。
一般的な開発言語の単体テストフレームワークには、PythonのddtモジュールやTestNGのDataProviderアノテーションなどのデータ駆動型の機能があります。
インターフェイスによって生成されたガベージ データをクリーンアップするにはどうすればよいですか?
上記と同様、データ作成とデータクリーニングはPythonを使用してデータベースに接続し、追加、削除、変更、クエリ操作を行う必要があります
テストケースの前操作、データ準備のためのsetUp
後操作、データのTearDownクリーニング
WebUI 自動テストの側面
セレンに元素が存在するかどうかを確認するにはどうすればよいですか?
要素の存在を判定するネイティブメソッドは存在せず、要素の位置検索＋例外キャプチャで判定するのが一般的です。
Hidden または Display = none 要素を Selenium に配置できますか?
いいえ、クリックしたい場合は、js を使用して display=none のプロパティを削除できます。
Selenium スクリプトの実行速度を上げるにはどうすればよいですか?
1. テストケースを最適化します。
2. 無駄な操作手順を削減します。
3. ページの読み込みを中断します。
4. Selenium グリッドを使用します。
継続的インテグレーションとは何ですか?
頻繁にコードを幹に組み込み、プロジェクトの構築を継続的に実行することで、エラーを迅速に発見し、枝が幹から大きく逸脱することを防ぎます
層別テストとは何ですか?
1. データ層
2. インターフェース層
3. UI層
アプリのテスト
IOS携帯電話とAndroid携帯電話の違い、システムについて説明してください。
2 つの動作メカニズムは異なります。IOS はサンドボックス動作メカニズムを使用し、Android は仮想マシン動作メカニズムを使用します。
この 2 つのバックグラウンド システムは異なります。IOS のサードパーティ プログラムはバックグラウンドで実行できませんが、Android のプログラムはすべてバックグラウンドで実行でき、メモリがなくなるまで終了しません。
アプリのパフォーマンステスト、つまり特別なテストでは何に重点を置く必要があると思いますか?
メモリ、CPU 使用率、消費電力、トラフィックなど。
Android システムの 4 層アーキテクチャについて簡単に説明してください。
上から順に、アプリケーション プログラム層、アプリケーション プログラム フレームワーク層、システム ランタイム層、Linux コア層です。
テスト中にアプリでクラッシュや ANR が発生した場合はどうしますか?
まずログをフィルタリングできます: adb logcat | findstr xxxxx (ログ情報のフィルタリング)、次にその中のキーワード (例外、クラッシュなど) を検索して、問題が送信された原因となったメソッドまたは例外を確認します。問題の原因を特定し、開発者に引き渡して根本的な原因を見つけて修正することができます。
実用的な Android UI 自動テスト ツールを簡単に紹介してください。
appium: ネイティブ アプリケーション、モバイル Web アプリケーション、ハイブリッド アプリケーションのテストに使用できる、クロスプラットフォームのモバイル オートメーション フレームワークです。
robotium: 海外の Android 自動テスト フレームワークで、主に Android プラットフォーム アプリケーションのブラックボックス自動テストを目的としており、さまざまなジェスチャ操作 (クリック、長押し、スライドなど) をシミュレートするための API や、検索やアサーションのメカニズムを提供し、各種コントロールを操作します。
フルスタック自動化テストの面接の質問
1. Web オートメーション テストの面接での質問
1. Selenium の hidden または display = none 要素を見つけることはできますか?
いいえ、JavaScript を記述して、最初にラベルの hidden を 0 に変更してから、要素を配置することができます。
2. Selenium で要素の操作の成功率を確保するにはどうすればよいですか? 言い換えれば、クリックした要素がクリック可能であることを確認するにはどうすればよいでしょうか?
インテリジェントな待機時間要素を追加します driver.implicitly_wait(30)
必須の待機時間を追加します (Python で sleep を記述するなど)
さまざまな方法で ID、名前、クラス、X パス、CSS セレクターを見つけてみます。最初の方法が失敗した場合は、自動的に2本目を試してみる 2種類
3. Selenium スクリプトの実行速度を上げるにはどうすればよいですか?
コードの最適化、マルチタスク、分散デプロイメントにより、スクリプトの実行速度が向上します。
4. ユースケースは、実行プロセス中に不安定になることがよくあります。つまり、今回は通過できますが、次回は通過しません。ユースケースの安定性を向上させるにはどうすればよいですか?
time.sleep( )
driver.implicitly_wait(30)
例外をキャプチャして処理するために使用します。
5. 自動化のユースケースの実行戦略は何ですか?
自動テストは本質的にソフトウェア開発と同じであり、自動テスト ツールを使用してテスト要件を分析し、自動テスト ケースを設計して自動テスト フレームワークを構築し、自動スクリプトを設計して作成し、テスト スクリプトの正確性を検証して、最終的に自動化を完了します。スクリプト (つまり、テストを主な機能とするアプリケーション ソフトウェア) を作成し、テスト結果を出力します。
6. 自動テスト中にデータ検証のためにデータベースに接続する必要がありますか?
データベースレベルでのデータ検証は、システムのデータ処理が正しいかどうかをより容易に検証できますが、データ処理ロジックが正常である場合には、UIレベルでの検証も必要になります。
7. id、name、class、xpath、css セレクターの属性のうち、どれが好みですか?またその理由は何ですか?
css と xpath のほとんどすべての要素を見つけることができますが、ページ上で要素を変更すると位置が簡単に変更されるという欠点があるため、最初に ID または名前が使用されます。
8. ページ上で動的に読み込まれる要素を見つけるにはどうすればよいですか?
動的要素が配置用に表示されるまで、動的にロードされた要素のイベントをトリガーします。
9. 属性が動的に変化する要素を見つけるにはどうすればよいですか?
xpath または css は兄弟、親、子を通じて検索します
10. リンクをクリックした後、Selenium はページが読み込まれるまで自動的に待機しますか?
します
11. ページオブジェクトのデザインパターンとは何ですか?
簡単に言うと、ページをオブジェクトとして使用し、使用中のページ オブジェクトを渡し、ページ オブジェクト内の対応するメンバーまたはメソッドを使用することです。これにより、オブジェクト指向とオブジェクト指向のカプセル化機能をよりよく反映できます。言語 (Java や Python など)。
12. (デバッグ目的で) 要素を配置した後に要素を強調表示するにはどうすればよいですか?
JavaScript などのスクリプトを使用して要素の属性をリセットし、配置された要素に背景や境界線を追加します。
13. アサーションとは何ですか?
アサーションは、プログラムがすでに持っている必要がある状態、またはプログラム実行中のある時点で一連のプログラム変数が満たさなければならない条件を指定する論理式です。
14. 自動テストの最大の欠陥は何だと思いますか?
信頼性が不安定コストと利益
の維持が困難
2.APPUI自動化テストの面接の質問
1. Android APP のメモリが不足している場合、システムはどのようにプロセスを終了してメモリを確保しますか?
システムは一時停止（サスペンド）したプロセスの終了を優先し、メモリを解放します。
2. APP テストでよくある深刻な問題は何ですか? それぞれの原因は何でしょうか？
一般的なものはクラッシュと ANR (アプリケーションの応答なし、スタック) で、通常はデバイスの断片化、ネットワークの大規模な変動、メモリ リーク、コード書き込みエラーが原因で発生します。
3. 使用したことのある APP 自動テスト ツールを簡単に紹介してください。
主観的な意見を含む自由回答形式の質問
他の使い慣れた自動化ツールの長所と短所を比較してください。
自動化の簡単な計画 (簡潔に、重要な内容について具体的に説明してください)。(ヒント: アプニウムなど)
4. Android テストと Web テストの違いは何ですか?
同じ点:
テストケースの設計は等価クラスや境界値などの手法に基づいており、テスト原則は同じです;
ほとんどのテストケースはビジネス機能を検証するためにブラックボックステスト手法を使用しています;
インターフェイスのレイアウト、スタイルが適切であるかどうかを確認する必要があります、ボタンは美しく統一されています (UI テスト)
、ページの読み込みとページめくりの速度、ログイン時間のオーバーフローなどの問題 (パフォーマンス テスト) は
アプリケーション システムの安定性をテストします。
違い：
携帯電話はコミュニケーションツールとして使用されており、通信等の動作によってはAPP（割り込みテスト）が発生することがあります。
携帯電話ユーザーによるアプリ製品のインストールとアンインストール: 前バージョン/前々バージョンから最新バージョンに直接アップグレードします。
Web の自動テストで最も一般的に使用されるツールは Selenium ですが、Android 携帯電話の自動テストでより一般的に使用される自動ツールは、Monkey、Monkeyrunner、Appium です (テスト ツールは異なります)。
5. アプリのテストにはどのような環境がありますか?
ローカル環境: アプリがインストールされている携帯電話環境およびコンピューター上に構築された自動テスト環境 (Android SDK など
)。
サーバー環境: war パッケージによってデプロイされたサーバー。サーバーはブラウザーまたはアプリを通じてアクセスできます
。(アクセスはWebプログラムのインターフェースです)
6. Android SDK のインストール手順を簡単に紹介します。
jdk と Android SDK
をダウンロードして jdk をインストールし、環境変数 (java_home、classpath、path) を設定します。
7. モバイル アプリケーションとそのサーバーのテスト ポイントを簡単に紹介してください。
モバイル アプリケーションには主に、権限、インストール、操作とアンインストール、UI、機能、パフォーマンス、中断、互換性、セキュリティ、
回帰、アップグレードと更新、ユーザー エクスペリエンスが含まれます。（アプリの11の主要なテストポイント）
サーバーにはインターフェイステスト、パフォーマンステスト、セキュリティテストがあります。
8. アプリのバグがクライアントの問題かバックグラウンドの問題かを判断する方法
これはビジネスによって異なります。一般的なデータの問題のほかに、フロントエンドの問題もあります。一般的なアプローチは、フロントエンド開発者に問題を提起することです。フロントエンド開発者は、それが自分の問題なのか、バックグラウンドから返されたデータなのかを知っています
。
9. Android でログ情報を取得するにはどうすればよいですか?
Android システムのログ情報をリアルタイムでローカルにインポートします: adb logcat -v time > d:\mylog.log
アプリを実行して使用し、アプリのログ情報をリアルタイムで取得します (cmd で情報を返します)。
adb シェル モンキー -p com. android.calendar -v 1000 > d:\mylog2.log
10. 一般的な adb コマンド:
現在接続されているデバイスの表示: adb devices
ソフトウェアのインストール: adb install path\xx.apk
ソフトウェアのアンインストール: adb uninstall <パッケージ名>
コンピューターからデバイスにファイルを送信: adb Push <ローカル パス> <リモート パス>
adb Push C:\ test1。 txt /sdcard/
デバイスからコンピューターにファイルをダウンロードします: adb pull <リモート パス> <ローカル パス>
adb pull /sdcard/test1.txt D:
リアルタイムでログを取得します: adb logcat -v time > D:\mylog。 log
端末デバイスのシェルにログインします: adb shell
パッケージ名/アクティビティ名を検索します: adb logcat | findstr START
(スクリプトでは、cmp= の後の値がパッケージ名/アクティビティ名です)
Start APP Start
adb Shell am start -n パッケージ名/アクティビティ
アプリを閉じる
構文 : adb Shell am 強制停止 パッケージ名
モニター アプリの起動時間
adb Shell am start -W パッケージ名/アクティビティ
モンキーコマンド:
adb Shell Monkey -v -p mypackage 50
11. APP の非常に多くの主流モデルをテストするにはどうすればよいですか?
当社が購入しました。Meizu、Huawei、Xiaomi、iphone7、iphone8、iphone8plus、iphone
x との互換性をテストします。一部のモデルは利用できません。最初に同僚の携帯電話を借りてテストし、会社に同時に購入を申し込みます。 、または
クラウド実機を使用します。
12. アプリがクラッシュします (フラッシュバック)。原因は何でしょうか?
キャッシュのゴミが多すぎる：Androidのシステムの特性上、ジャンクファイルを長期間クリーンアップしないとどんどんスタックしてしまい、フラッシュバックも発生します
。メモリ不足
アプリケーションのバージョン互換性の問題: アプリケーションのバージョンが低すぎると、互換性がなくなりクラッシュします。さらに、いくつかの新しいバージョンがデバッグ中ですが、これもアプリケーションのクラッシュの原因となります。解決策: バージョンが古すぎる場合は、新しいバージョンに更新してください。新しいバージョンがクラッシュした場合は、アプリケーションが修正およびデバッグされている可能性があり、アンインストール後に古いバージョンをインストールできます。
APPがネットワークのどこにアクセスしているか、コンポーネント内のImageViewが正常にダウンロードされ、アプリページに表示できるか確認してください。
アプリの SDK が携帯電話のシステムと互換性があるかどうかを確認します。
Android 5.0 を Android 6.0 にアップグレードすると、ビデオの再生などの特定の状況でフラッシュバックが発生し、
一部のシステム API は古いバージョンでは利用可能ですが、新しいバージョンでは利用できなくなります。
13. Appiumの起動方法は何ですか
1. クライアントの起動
2. コマンドラインの起動
14. これまでに使用した Android UI 自動テスト ツールを簡単に紹介してください。
appium: ネイティブ アプリケーション、モバイル Web アプリケーション、ハイブリッド アプリケーションのテストに使用できる、
クロスプラットフォームのモバイル オートメーション フレームワークです。robotium: 海外の Android 自動テスト フレームワークで、主に
Android プラットフォーム アプリケーションのブラックボックス自動テストを目的としており、さまざまなジェスチャ操作 (クリック、長押し、
スライド各種コントロールを操作します。
15. Android携帯電話とIOS携帯電話の違いとシステムについて説明してください。
2 つの動作メカニズムは異なります。IOS はサンドボックス動作メカニズムを使用し、Android は仮想マシン動作メカニズムを使用します。
2 つのバックグラウンド システムは異なります。IOS のサードパーティ プログラムはバックグラウンドで実行できませんが、Android のプログラムはすべてバックグラウンドで実行でき、メモリがなくなるまで終了しません。
IOS は UI 命令に対して最高の権限を持ち、Android はデータ処理命令に対して最高の権限を持ちます。
3. インターフェース自動化テストの面接での質問
1. Webdriver はインターフェイスのテストに使用できますか?
インターフェイス テスト用の既製のモジュールがあり、WebDriver は WebUI の自動テストに使用されます。インターフェースのテストを実装したい場合は、Requests モジュールを使用して実現できます。
2. あなたの理解によると、ソフトウェア インターフェイスとは何ですか?
これは、異なるモジュール間でのデータの送受信とその処理を特に担当するプログラム内のクラスまたは関数を指します。
3. HTTP プロトコルと HTTPS プロトコルの違いは何ですか?
httpsプロトコルはCA（Certificate Authority、認証局）に証明書を申請する必要があり、一般に無料の証明書は少ないため一定の料金が必要ですが、httpはハイパーテキスト転送プロトコルであり、情報は平文で送信されます
。暗号化通信や本人認証を行うネットワークプロトコルは
httpプロトコルよりも安全で、
httpとhttpsでは接続方法もポートも異なり、前者は80、後者は443です。
4. HTTPS はどの層にありますか?
HTTPS はアプリケーション層にあります。
5. get と post の違いは何ですか?
POST と GET はどちらもサーバーにデータを送信し、サーバーからデータを取得します。
違い：
送信方法: get はアドレスバーを通じて送信され、post はメッセージを通じて送信されます 送信
長: get パラメータには長さの制限があります (URL の長さによって制限されます)、post は無制限です
GET は TCP パケットを生成します (GET の場合)リクエスト、ブラウザは http ヘッダーとデータを一緒に送信し、サーバーは
200 で応答してデータを返します）、POST は 2 つの TCP パケットを生成します（POST の場合、ブラウザーは最初にヘッダーを送信し、サーバーは 100 で続行して応答し、ブラウザー
はデータを再度送信すると、サーバーは 200 ok でデータを返します)
取得リクエストのパラメーターは閲覧履歴に完全に保存されますが、投稿内のパラメーターは保存されません。
データ クエリを実行するときは、GET を使用することをお勧めします。データの追加、変更、削除を行う場合は、post メソッドを使用することをお勧めします。
6. 一般的な POST データ送信方法
主なメソッドは 4 つあります: application/x-www-form-urlencoded、multipart/form-data、
application/json、text/xml など。
7. HTTP プロトコルのステートレス プロトコルとは何ですか? HTTP プロトコルのステートレス プロトコルを解決する方法
ステートレスとは、プロトコルにトランザクション処理用のメモリ機能がなく、サーバーがクライアントがどのような状態にあるのかを認識しないことを意味します。つまり、
HTTP リクエストをサーバーに送信すると、サーバーはリクエストに従ってデータを送信しますが、
送信後に情報は記録されません。HTTP はステートレス プロトコルです。つまり、各リクエストは独立しており、Keep-Alive は
この結果を変更できません。状態が欠落しているということは、その後の処理で以前の情報が必要な場合に再送信する必要があることを意味し、
接続ごとに転送されるデータ量の増加につながる可能性があります。一方、サーバーが以前の情報を必要としない場合、サーバーの応答は速くなります。HTTP
プロトコルの特徴には、サーバーが解放され、リクエストごとに無駄な接続占有が発生しないというメリットと、
リクエストごとに大量のコンテンツ情報が繰り返し送信されるというデメリットがあります。クライアントとサーバー間で動的に対話するWeb アプリケーションの出現後
、HTTP のステートレスな性質がこれらのアプリケーションの実現を大きく妨げています。結局のところ、
対話は過去と未来の間のリンクである必要があります。シンプルなショッピング カートプログラムは、ユーザーが以前に何を選択したかを知る必要もあります。そこで、
HTTP 接続状態を維持するための 2 つの技術が登場しました。1 つは Cookie で、もう 1 つはセッションです。
8. Cookieとセッションの違い
Cookie データは顧客のブラウザに保存され、セッション データはサーバー上ではあまり安全ではありません。
ローカルに保存された Cookie を他人が解析して Cookie を不正操作する可能性があります。セキュリティを考慮すると、セッション データを
使用する必要があります
。セッションはサーバーに保存されます。一定期間サーバーを停止しております。アクセス数が増加すると、サーバーのパフォーマンスを占有します。サーバーのパフォーマンスの
低下を考慮して、Cookie を使用する必要があります。1
つの Cookie で保存されるデータは 4K を超えることはできません。多くのブラウザでは、サイトの保存データは最大 20 に制限されています
ログイン情報などの重要な情報を保存できるCookieセッションの場合、保存する必要があるその他の情報を Cookie に配置できます
9. リクエストインターフェイスの一般的なリターンステータスコード
1xx – 情報 (暫定的な応答を示します。クライアントは、通常の応答を受信する前に、1 つ以上の 1xx 応答を受信する準備ができています) 2xx – 成功 (サーバーが
クライアントの要求を正常に受け入れたことを示します)
3xx – リダイレクト (クライアントが参照する必要があります)リクエストを満たすためにさらにアクションが必要です。たとえば、ブラウザはサーバー上の別のページをリクエストするか、プロキシ サーバー経由でリクエストを繰り返す必要がある場合があります)
4xx – クライアント エラー (送信エラー。クライアントに問題があります。たとえば、 、クライアント クライアントは存在しないページを要求し、クライアントは有効な ID 検証情報を提供しません)
5xx – サーバー エラー (サーバーはエラーのため要求を完了できません)
一般的なリターン コードは次のとおりです。
200 OK - [GET]: サーバーはユーザーが要求したデータを正常に返しました。
201 CREATED - [POST/PUT/PATCH]: ユーザーはデータの作成または変更に成功しました。
202 Accepted - [*]: リクエストがバックグラウンドに入ったことを示します。キュー (非同期タスク)
204 NO CONTENT - [DELETE]: ユーザーはデータを正常に削除しました
400 INVALID REQUEST - [POST/PUT/PATCH]: ユーザーが送信したリクエストが間違っており、サーバーは次の操作を実行しませんでした401 Unauthorized
-[*]: ユーザーに権限がないことを示します (トークン、ユーザー名、パスワードのエラー)
403 Forbidden -[*]: ユーザーが許可されていることを示します (401 エラーではなく)。アクセスは禁止されています
404 NOT FOUND -[*]: ユーザーが発行したリクエストはレコードに対して存在しません、サーバーは動作しませんでした、操作は冪等です 406 Not Acceptable - [GET]: ユーザーが要求した形式ではありませ
ん利用可能 (たとえば、ユーザーは JSON 形式を要求しましたが、XML 形式のみ)
500 INTERNAL SERVER ERROR - [*]: サーバーでエラーが発生しました。ユーザーは、行われた要求が成功したかどうかを判断できません。
10.DNSとは何ですか?
DNS はドメイン ネーム システム (Domain Name System) です。DNS はドメイン名の解決に使用されます。
インターネット上で URL を入力し、他のサーバーにアクセスすると、IP に変換されます。これがなければ、覚えておく必要があります。 Baidu Baidu の IP にアクセスしたい場合は、
DNS 処理を使用すれば、対応する Web サイトのドメイン名、つまり URL を覚えておくだけで済みます。
11. あなたの会社ではインターフェースのテストをどのように行っていますか?
インターフェイス テストと一般テストの実際の違いは、テスト ケースの設計部分です。
インターフェース仕様を取得します。
インターフェイス テスト機能のユース ケースを設計します (主に、インターフェイスがビジネス要件を満たせるかどうかをユーザーの観点から確認するため、ユース ケースの設計はブラック ボックスのユース ケースのセットです)。
さまざまな入力パラメーターの検証 (正常な場合、異常な場合には、入力パラメーターの数が正しくない、タイプが間違っている、オプション/必須、相互排他的または関連するパラメーターの考慮が含まれます)。
インターフェースの戻り値の各種検証（インターフェース文書の要件に準拠）
インターフェースの実装ロジックを理解し、ロジックカバレッジ（文/条件/分岐/判断/…）を実現
インターフェースは同時に実行できるか、安全か、パフォーマンスは要件を満たしていますか?
ツールまたは自己記述コードを使用して検証します。
見つかった問題は機能テストと同じであり、バグを報告し、追跡ステータスの追跡ステータスを追跡する必要があります。
12. インターフェースのテストケースを設計するにはどうすればよいですか?
一般に、インターフェイス テスト ケースの設計では、次の側面を考慮する必要があります。
前提条件が満たされているかどうか
一部のインターフェースでは、データを正常に取得する前に前提条件を満たす必要があります。
トークンへのログインが必要な一般的なリバース ユース ケース: 前提条件が満たされるかどうかの 0 ～ n 個のユース ケースを設計します (条件を n とする)
デフォルト値のパラメータを保持するかどうかポジティブなユースケース: パラメータにデフォルト値を入力しない、パラメータを渡さない、必須パラメータに正しい既存の「通常の」値を入力する、その他を
入力しない、デザイン 1 のユースケース
ビジネスルールと機能要件
ここで、時間の状況に応じて、インターフェイスパラメータの記述と組み合わせて、N 個の順方向ユースケースと逆方向ユースケースを設計する必要がある場合があります
パラメータは必須ですか?
逆の使用例: 必須パラメータごとに、パラメータ値が空である逆の使用例を設計します。
パラメータ間に相関関係があるかどうか
一部のパラメータは相互に制約的な関係にあります
パラメーターのデータ型の制限
逆の使用例: パラメーター値の型と一致しないパラメーターごとに逆の使用例を設計します。
パラメータのデータ型自体のデータ範囲値制限
前方ユースケース: すべてのパラメータについて、各パラメータのパラメータ値がデータ範囲内の最大値となる前方ユースケースを設計します。
13. インターフェイスのテストを行っていますが、何をテストしているのですか?
ユーザビリティテスト
合意されたプロトコル、方法、形式の内容に従って、データをインターフェースに転送し、処理後に期待される結果を返します。
インターフェイス関数が正しく実装されているかどうか、
戻り値のテスト - 内容に加えて戻り値も正しい必要があり、呼び出し元が正しく解析できることを保証するために型も正しい必要があります、パラメーター値の
境界値、等価クラスのテスト、
エラーおよび例外処理テスト
異常な値 (null 値、特殊文字、合意された長さの超過など) を入力すると、インターフェイスは正しく処理でき、期待どおりに応答します。間違った
パラメータを入力すると、インターフェイスは正しく処理でき、期待どおりに応答します。
さらに入力すると、入力パラメータが少ない場合、インターフェイスは期待どおりに正しい処理と応答を行うことができます;
間違った送信データ形式 (フォーム形式で記述された JSON 形式など) テスト;
セキュリティ テストは、主に送信データのセキュリティを指します。
機密データ (パスワード、秘密キーなど) が送信用に暗号化されているかどう
か、返されたデータにユーザー パスワード、完全なユーザー銀行口座情報などの機密データが含まれているかどうか、
インターフェースが受信データに対してセキュリティ検証を実行しているかどうか。 ID とトークン 同様の検証、
インターフェイスが悪意のあるリクエスト (サーバーのクラッシュを引き起こす多数の偽造リクエスト インターフェイスなど) を防止しているかどうか、
インターフェイスの応答時間、同時処理能力、ストレス テスト処理などのパフォーマンス テスト。
同じインターフェイスへの同時リクエスト (特に POST リクエスト)、インターフェイスの処理 (同じレコードの挿入によりデータ エラーが発生し、システム障害が発生するなど)、インターフェイスの応答時間はユーザーが許容できる範囲内
です
。最大のボトルネックが現在のビジネス ニーズを満たしているかどうかを判断するための圧力テスト。
14. インターフェイスのテストには通常どのようなツールが使用されますか?
一般的に使用される http プロトコル インターフェイス テスト ツール (postman、fiddler、jmeter など)。WebService インターフェイスは SoapUI、
jmeter などを使用します。
15. インターフェイスのドキュメントがありません。インターフェイスのテストはどのように行うのですか?
この質問は主に EQ をテストします。平たく言えば、面接官を騙す能力です。まず、面接官を騙しましょう。試験に入るときはブラインドテストでもあります。いつでも責められる準備をしてください。もちろんです。 、面接官の驚きに答えてはなりません (心理的な mmp、
笑顔の顔)、次のステップは、
パケット キャプチャ ツールを使用してインターフェイスをキャプチャして処理し、ターゲットを絞ったテストを実施することです。インターフェイスのフィールド情報が不明瞭な場合は、
開発ソリューションに集中する時間です。(一般的なパケット キャプチャ ツール Fiddler、Charles など)
16. 手動インターフェイス テストまたは自動インターフェイス テストのプロセスで、上流インターフェイスと下流インターフェイスのデータ依存性にどのように対処しますか?
グローバル変数を使用して、ログイン後にトークンを返すなどの依存データを処理し、他のインターフェイスでこのトークンが必要な場合は、
グローバル変数を使用してトークン パラメーターを渡します。
17. サードパーティのデータに依存するインターフェイスをテストするにはどうすればよいですか?
模擬試験の後、面接官が「模擬サービスかどうか」と尋ねたら、引き続き穴を掘り続けて模擬サービスを構築します。
18. インターフェーステストで、ログイン状態に依存するインターフェースをテストするにはどうすればよいですか?
ログイン ステータスに依存するインターフェイスの本質は、リクエストが送信されるたびに、リクエストを正常に送信するにはセッションまたは Cookie を含める必要があり、
必要なセッションまたは Cookie は POST リクエストの作成時に追加されることです。
19. テストのために弱いネットワークをシミュレートするにはどうすればよいですか?
Fiddler と charles はどちらも弱いネットワーク テストをシミュレートできます。通常、シミュレートされたパケット損失と呼ばれるものも、シミュレートされた弱いネットワーク テストです。詳細については
、「弱いネットワークのシミュレーション方法がいくつかあり、最適なものが必ずあります」を参照してください。
20. 通常のインターフェースのテスト中にどのようなバグを発見しましたか?
面接官がこの質問をするのは、主にあなたが本当にインターフェイステストを行ったかどうかを知りたいからです。結局のところ、多くの小規模パートナーの履歴書はパッケージ化されています（パッケージ化なしでは面接の機会さえありません。順番に方法はありません）。生き残るためには理解できます） 一般的なエラー、
インターフェースが実装されていない、規約に従って結果が返されない、境界値処理エラーなど。
異常な値 (null 値、特殊文字、合意された長さの超過など) を入力すると、インターフェイスはエラーをスローし、カプセル化は実行されません。間違ったパラメータを入力したり、入力パラメータを増やしたり、入力パラメータを減らしたり、インターフェイスでエラーが発生する可能性があります
。
平文送信などのセキュリティ問題、返された結果には機密情報が含まれている、ユーザー ID 情報の検証がない、悪意のあるリクエストの傍受がないなど、パフォーマンスの問題 (インターフェイス上での複数の同一操作の同時挿入、長い応答時間など
)界面圧力試験などのボトルネック。
21. インターフェースに例外がある場合、その例外をどのように分析しますか?
まずパケットをキャプチャし、fiddler (charles) ツールを使用してパケットをキャプチャするか、ブラウザ上の F12 デバッグ ツールを使用します。APP 上にある場合は、Fiddler をプロキシとして使用し、携帯電話を介してプロキシを設定して表示します
。リクエストとリターン メッセージ、
バックエンド ログ (Linux システムは xhell 経由でサーバーに接続し、インターフェイス ログを確認し、エラー メッセージがあるかどうかを確認するなど) を確認します (コマンド: tail -f ログ ファイル)。
22. バグがフロントエンドかバックエンドかを分析するにはどうすればよいですか?
通常、バグが話題になると、フロントエンド開発とバックエンド開発は常に口論になり、それが相手のバグであることを認めません。この状況は簡単に判断できます。まずパケットをキャプチャしてリクエスト メッセージを確認し、次にインターフェイス ドキュメントを確認してリクエスト メッセージに問題があるかどうかを確認します。
問題がある場合は、
フロント エンドによって送信されたデータが表示されます。は間違っています;
、返されたデータが正しくありません、これはバックエンド開発の問題です。
23. インターフェーステストの自動化を行っていますか?
現在、多くのアプリケーションでは、メンテナンスコストが低く、利益が大きいインターフェイステストを自動化することが一般的に推奨されています。
Jmeter、Robot Framework、pytest など、一般的に使用されるツールが多数あります。
24. JMeter リスナーはいくつリストされますか?
JMeter リスナーの一部は次のとおりです。
コレクション レポート
概要レポート
結果の表示 結果のツリー
ビュー 結果のテーブル グラフ
結果
BeanShell リスナーの
概要レポート など。
25. Python でのデータ駆動型テスト
Unittest には組み込みのデータ ドライバーはありません。これを実現するには ddt を使用する必要があります。まず、
Python オペレーティング環境に ddt をインストールする必要があります。次のコマンドを使用して
pip install ddt
別のテスト フレームワーク pytest をインストールします。これはデータ駆動型の実装に付属しており、
@pytest.mark.parametrize(argnames,argvalues) によってパラメーター化されます。
独自のニーズに応じて、Python を使用してデータを読み取り、駆動することもできます。
26. インターフェース自動化における関連付けをどのように扱うか?
前のリクエストで返された結果を次のリクエストのパラメータに渡し、リクエストの結果をクラス属性に反映し(setattr
()関数を使用)、次のリクエストでクラス属性を呼び出します。
27. 自動テストの結果を確認するにはどうすればよいですか?
アサーション、期待される結果と実際の結果を比較します
。 データベース検証、テスト シナリオに従ってデータベース内のデータをクエリし、リクエスト前のデータと比較します。
28. 具体的には、このプロジェクトの実際の状況に自動化がどのように適用されているか、および自動化結果の分析について教えてください。
すべての自動テスト フレームワークの設計と実装が完了したら、インターフェイス テストを実施し、Jenkins への統合、
タイミング実行の設定、HTML レポートの生成、テストの合格率の確認、インターフェイスの機能の確認を行います。バージョンがリリースされるたびに
、開発とテストの前に回帰テストと新機能を実行します。
技術支援
最後に、これはソフトウェア テストのための独習チュートリアルのコレクションです。テスト業界で開発を行っている友人にとっては非常に役立つはずです。必要な友人のために、[記事の最後にある小さなカードをクリックして無料で入手できます]。基本的な入門レベルのリソースに加えて、ブロガーは多くの高度な自動化リソースも収集しており、理論から実際の戦闘まで、知識と行動を統合することで真に習得できます。コンテンツのフルセットはネットワーク ディスクにパッケージ化されており、コンテンツの総量は300 G 近くになります。
☑ 215 のエピソード - ゼロ基礎から熟練度までのビデオコースのフルセット
☑ [コースウェア + ソースコード] - 完全なサポートチュートリアル
☑ 18 セット - 実際のプロジェクトのソースコードをテスト
☑ 37 セット - テストツールパッケージ
☑ 268 の質問 - 実際の面接の質問
☑ 200 個のテンプレート - 面接履歴書テンプレート、テスト計画テンプレート、ソフトウェア テスト レポート テンプレート、テスト分析テンプレート、テスト計画テンプレート、パフォーマンス テスト レポート、パフォーマンス テスト レポート、パフォーマンス テスト スクリプト ユースケース テンプレート (完全な情報)
これらの資料は、[ソフトウェア テスト] を行う友人にとって、最も包括的で完全な準備倉庫となるはずです。この倉庫は、私が最も困難な旅を乗り越えるのにも同行してくれました。そして、あなたにも役立つことを願っています。何事もできるだけ早く行うべきであり、特に技術産業においては、技術スキルを向上させなければなりません。
