1. B/SアーキテクチャとC/Sアーキテクチャの違い
- B/S に必要なのはオペレーティング システムとブラウザだけであり、クロスプラットフォーム、メンテナンス不要のクライアント、低いメンテナンス コストを実現できますが、パーソナライゼーション機能が低く、応答速度が遅いです。
- C/Sは応答速度が速く、セキュリティが強いため、OSに合わせて開発する必要があり、保守コストが高いため、ローカルエリアネットワークでよく使われています。
2.HTTPプロトコル
http プロトコルはハイパーテキスト転送プロトコルとも呼ばれ、ネットワークリクエストを行う場合は基本的に http プロトコルを使用します。
http プロトコルにはリクエストとレスポンスが含まれます。
リクエストには次のものが含まれます。リクエスト アドレス、リクエスト メソッド、リクエスト メソッドには get リクエストと post リクエストが含まれます。get と post の違いは、get リクエストの後にアドレス バーの後ろにリクエスト パラメータが続くことですが、リクエスト パラメータのサイズは制限されており、異なるものです。ブラウザが異なります。通常は4KBです。post リクエストは主にリクエスト パラメータをサーバーに送信するために使用されます。post リクエストのパラメータはリクエスト エンティティのコンテンツに配置されるため、get リクエストよりも安全です。さらに、リクエストには、サポートされているデータ型、リクエストのソースの場所、Cookie ヘッダーなどの関連ヘッダー情報など、さまざまなリクエスト ヘッダー情報が含まれます。
応答。主に、200、304、307、404、500 などの応答のステータス コードが含まれます。
キャッシュされた応答ヘッダーの設定、Content-Type コンテンツ タイプ、Cookie ヘッダー情報の設定など、さまざまな応答ヘッダー情報もあります。
- 200: (成功) サーバーはリクエストを正常に処理しました。
- 304: (未変更) クライアントは条件付きリクエストを送信しますが、サーバー上のリソースは変更されていないため、この応答ステータスに応答します。
- 307: (リダイレクト) 内部ブラウザのリダイレクト
- 404: (見つかりません) サーバーはクライアントによって要求されたリソースを見つけることができません; 見つかりません
- 500: (内部サーバー エラー) リクエストを完了できませんでした。
PDF インタビューの質問の完全版は、次のグループに参加できます。
3. POSTとGETの違い
- Get リクエストは通常、データを取得することです (実際には送信することもできますが、一般的な方法はデータを取得することです)。post リクエストは通常、データを送信することです。
- Get は、送信プロセス中にデータがリクエストの URL に配置され、Post のすべての操作がユーザーには表示されず、リクエスト データが本文 (最も一般的なシナリオ、ユーザーのログイン パスワード) に配置されるため、安全ではありません。送信します。ポストリクエストを使用する必要があります)
- Get によって送信されるデータの量は主に URL の長さの制限により少量ですが、Post によって送信されるデータの量は比較的多く、通常はデフォルトで無制限です。
- Get リクエストはキャッシュできますが、Post リクエストはキャッシュされません
4. Cookieとセッションの違いと関係
- Cookie と Session は両方ともセッション テクノロジであり、Cookie はクライアント側で実行され、Session はサーバー側で実行されます。
- Cookie にはサイズ制限があり、ブラウザによって保存される Cookie の数も制限されていますが、セッションにはサイズ制限がなく、サーバーのメモリ サイズに関連します。
- Cookie には潜在的なセキュリティ リスクがあり、傍受またはローカル ファイルを通じて Cookie が見つかると攻撃が実行される可能性があります。
- セッションはサーバーに保存され、消えるまで一定期間存在します。セッションが多すぎると、サーバーへの負荷が増大します。
5. 試験の目的
簡単に言うとユーザー向けのテストであり、最終的にユーザーに渡される製品の機能がユーザーのニーズを満たしているかどうかを確認し、できるだけ多くの修正を加えていくことがテストの最終的な目的です。製品がユーザーに引き渡される前に、可能な限り問題を解決します。
6. ソフトウェアテストの段階は何ですか?
単体テスト、結合テスト、システムテスト、受け入れテスト。
単体テスト
ソフトウェア開発中に実行されるテスト アクティビティの最低レベルです。単体テスト アクティビティでは、ソフトウェアの独立したユニットがプログラムの残りの部分から分離されてテストされます。テストの焦点は、サブルーチンを含むシステムのモジュールにあります。検証など
統合テスト
組立試験、結合試験とも呼ばれます。単体テストに基づいて、設計要件に従ってすべてのモジュールがサブシステムまたはシステムに組み立てられ、統合テストが実行されます。実践の結果、一部のモジュールは独立して動作することはできますが、接続されたときに正常に動作することは保証されません。プログラム内でローカルに反映できない問題はグローバルに顕在化し、機能の実現に影響を与える可能性があります。テストの焦点は、モジュール間の接続とパラメータの転送です。
システムテスト
テスト対象のサブシステムをテスト用の完全なシステムに組み立てることです。システム方式仕様書で規定された機能をシステムが本当に提供できるかを検証する有効な方法です。テストは、システム全体の動作と他のソフトウェアとの互換性に焦点を当てています。
システムテストの範囲
機能テスト、UIテスト、パフォーマンステスト、フォールトトレランステスト、ユーザビリティテスト、異常問題テスト、安定性テスト、システム安定性テスト、
互換性テスト、インターフェーステスト、セキュリティテスト、ログイン権限テスト
受け入れテスト
ソフトウェア製品検査の最後のリンクです。プロジェクトのミッションステートメントまたは契約書、およびサプライヤーとバイヤーが合意した承認基準文書に従ってシステム全体をテストおよびレビューし、システムを承認するか拒否するかを決定します。
その他はいくつかの段階に分かれています
回归测试：ソフトウェアの新しいバージョンをテストする場合、以前の重要なバージョンのすべてのテスト ケースが繰り返されます。目的:
1. 以前のバージョンのすべての欠陥が修正されていることを確認します。
2. これらの欠陥を修正しても新たな欠陥が発生しないことを確認する
冒烟测试：新しいバージョンに対する計画的な大規模テストを行う前に、ソフトウェアの基本的な機能が実現されているか、テスト可能であるかを検証することを指します。テスタビリティテストとも呼ばれます。
7. テストとβテストの違い
а测试 ユーザーが開発環境で行うテストや、社内のユーザーが実運用環境を模擬して行うテストです。ß测试 受け入れテストです。ベータ テストは、1 人以上のユーザーの施設で実行されるテストです。
8. 受け入れテストはどのように行うのですか?
1. インターフェーステスト; ソフトウェア製品の全ページを閲覧したときに、機能ボタンやインターフェースが正常に表示できるかどうかを指します。
2. 機能テスト；製品の機能が正常に実現できるかどうか。
3. パフォーマンス テスト: CPU、メモリ、ネットワーク環境、バージョンなどの複数のテストを含む、パフォーマンスのボトルネックを発見するプロセス。
4. セキュリティテスト: 製品情報の機密性、パスワード保護、その他の機能テスト。
9. ホワイトボックス、ブラックボックス、グレーボックステストの違い
ブラック ボックスとグレー ボックスの違い:
ソフトウェアに複数のモジュールが含まれている場合、ブラック ボックス テストを使用するときは、ソフトウェア システム全体の境界だけを気にする必要があり、さまざまなモジュールがどのように機能するかを気にする必要はありません。ソフトウェアシステムが連携します。また、グレー ボックス テストを使用する場合は、モジュール間の相互作用に注意する必要があります。
白いボックスと灰色のボックスの違い:
グレー ボックス テストでは、モジュールの内部実装の詳細を気にする必要はありませんが、ソフトウェア システムの内部モジュールについては、グレー ボックス テストでもブラック ボックスとして扱われます。ホワイトボックス テストでは、実装の詳細と内部モジュールの分岐についての深い理解も必要です。
10. 発煙試験の目的
正式なテストの前に、製品またはシステムの主な要件または前提条件にバグがないかどうかを確認します。
11. 回帰テストはどのように行うのですか?
- 1. テスト戦略策定段階で、回帰テスト戦略を策定する
- 2.回帰テストが必要なバージョンを決定する
- 3.回帰テストバージョンがリリースされ、回帰テスト戦略に従って回帰テストが実行されます。
- 4. 回帰テストに合格し、欠陥追跡リスト (問題リスト) を閉じます。
- 5. 回帰テストが失敗した場合、欠陥追跡シートは開発者に返却され、開発者は問題を再編集して、回帰テストを再度テスターに提出します。
12. ニーズ分析の目的
まず、ユーザー要求を機能要求に変換します。 1) テスト範囲の進捗を測定する 2) 処理分岐を測定する 3) 必要な業務の現場を測定する 4) その機能に対応する入力、処理、出力を明確にする 5) 機能要件を定義するhidden 形式的な要件が明確になります。
次に、テスト活動の 5 つの要素を明確にします。テスト要件は何か、テスト方法の決定、テスト時間の指定、テスターの決定、テスト環境の決定です。テストに必要なスキル、ツール、対応する背景知識、テストに必要な知識、テスト環境の決定です。テストプロセスでのリスクなど テスト漏れや誤解を避けるために、テスト要件は可能な限り詳細かつ明確にする必要があります。
13. テスト計画の目的
1. テスト作業の内容（範囲）、テスト作業の方法、テスト作業に必要な各種リソースをできるだけ早く明確にする。
2. 試験作業に携わるすべての担当者は、考慮すべき課題と次の試験作業の準備条件をできるだけ早く実行するものとします。
3. テスト計画作業の焦点は、現在の作業タスクの準備と計画、および情報交換です。
14. テスト計画の作成をいつ開始するか
テスト計画は、要件を整理した上で開発計画と併せて策定する計画であり、プロジェクト計画のいずれかの計画に属します。
15. 誰がテスト計画を書きますか
プロジェクト マネージャー (プロジェクトの観点から検討)
テスト マネージャー (テスト チームの観点から検討)
テスター (具体的なテスト計画を作成)
16. テスト計画の内容
1. テストの目的: テストの目的を簡単に説明します。
2. テストの概要: テスト対象のソフトウェアの簡単な説明、用語の説明、参照した関連文書。
3. テスト範囲: テスト計画に含まれるテスト ソフトウェアの範囲と優先順位、どのソフトウェアをテストする必要があるか、どのソフトウェアをテストする必要がないのか、またはテストまたは延期できないのか。
4. 重要事項: テスト対象ソフトウェアの主な機能とテストのキーポイントをすべて列挙し、テストケースの設計と対応し、確認できる部分である必要があります。
5. 品質目標: ソフトウェアをテストするための製品品質目標とソフトウェア テスト目標を策定します。
6. リソース要件: ソフトウェアおよびハードウェア、テスト ツール、テストに必要な技術リソース、トレーニング、ドキュメントなど。
7. 人員組織: テストを実施するには何人が必要か、それぞれの役割と責任、関連する学習とトレーニングが必要かどうか、いつ開始する必要があるか、およびテストはどれくらいの期間続くか。
8. テスト戦略: 全体的なテスト戦略、使用されるテスト技術および方法を策定します。
9. リリースの提出: テスト計画に従ってテストがリリースされた後に納品する必要があるソフトウェア製品、テスト ケース、テスト データおよび関連ドキュメント。
10. テストの進行状況とタスクの人員配置: テスト計画を複数のテスターに合理的に割り当て、順序に注意する 開発されたリリースが不確実な場合は、テスト期間を指定することができる 長期にわたる大規模テストの場合計画に基づいて、マイルストーンを使用して進行中の変更を表すことができます。
11. テストの開始/完了/遅延/継続の基準: テストの開始と完了の基準を策定します。場合によっては、何らかの理由 (障害となるバグが多すぎる) でテスト計画が遅延し、問題が解決された後にテストを続行します。
12. リスク分析: テスト計画において考えられるリスクと解決策を考慮する必要があります。
17. 終了条件（プロジェクト開始条件）
1. ソフトウェアは完全にテストされています
開発者テスト→クロステスト→テスターテスト→ユーザーのビジネス専門家テスト→一定数のユーザービジネス専門家による集中テスト→オンライン化前の試行→オンライン化。
2. ユーザートレーニング
管理者には、特定の工場または地域で訓練を受けた人が必要です。
3. 基本データのインポートが完了しました
ユーザー、組織、ビジネス データなどの基本データをインポートする必要があります。
4. 認証が完了している必要があります
5. 新旧システムの切り替えは事前にリハーサルを行い、各種旧データのインポートが完了していること。
6. 緊急時の計画を立てておく必要があります。
18. 一般的なテストのリスク
1. 要件のリスク、2. テストケースのリスク、3. 欠陥のリスク、4. コード品質のリスク、5. テスト環境のリスク、6. テスト技術のリスク、7. 回帰テストのリスク、8. 通信および調整のリスク、9. 研究開発プロセスリスク、10. その他の予測不可能なリスク
19. テストケースの要素
1. ユースケース番号、2. テストモジュール、3. ユースケースのタイトル、4. テストレベル、5. テストの目的と条件、6. テストの入力、7. 操作手順、8. 期待される結果
20. テストケースレベルの分割
テスト ケースの優先順位付けの目的: テスト ケースの優先順位付けを使用すると、テスト戦略に基づいてケースを簡単にフィルターできます。例えば、ある機能に小さな変更がある場合、高さ測定や中・高優先度のユースケースのみが使用されます。たとえば、スモーク テストでは、実行の優先順位が最も高いユース ケースをフィルタリングするだけで済みます。
テスト ケースの優先順位の目的に応じて、より高い優先順位のテスト ケースでカバーされるテスト ポイント (登録機能など、ユーザーが最も関心を持つ必要がある) は、正常に登録できるユース ケースの優先順位が最も高くなります ( (すべての登録が成功するわけではありません) ケースの優先度が最も高く、1 つだけ選択する必要があります)、その他の異常チェックは 2 番目の優先度であり、シーンに含まれる一部のテスト ポイントは表示されにくい、または問題があっても表示されません大、優先度は低くてもよい
21. ユーザーのニーズを確実に満たすにはどうすればよいですか?
1. 要件の確認、2. 要件の整理、テスト範囲の確認、3. テスト計画の作成、4. テスト計画に従ってテストケースを作成、5. テストステップの実行
22. 良いテストケースを書くための鍵/良いユースケースを書くときに注目すべきディメンション
1. テストの前に:
1. テストの目的を明確に理解する、2. 製品の機能テストのポイントを理解する、3. 「相互影響」問題を回避するためのモジュールの原理を理解する、4.ユーザーシナリオの問題とインターネットアクセスの問題に注意してください。
5. 雑にならない主要なテストケース設計、
2. テスト ケースを作成する場合:
1. テストケースフレームワークの構築、2. テスト手順の設計（手順が大まかすぎるとテストを見逃しやすい、もう 1 つは詳細に書きすぎて時間がかかり、時間がかかる可能性がある）労働集約的であり、経営陣の思考を制限することになります。)
3. テストケースの設計方法と考え方
1. 製品テストの主な目的を念頭に置く、2. 言葉の正確な使用に注意する
23. 一般的なテストケースの設計方法
同値クラス分割、境界値解析、誤差推論法、決定表、直交実験法
24. シーンメソッドを使用する場合
シナリオ手法は、業務プロセスが明確で複雑な業務を伴うシステムや機能の解決に適しており、ソフトウェアビジネスをベースにしたテスト手法です。
シナリオ手法を使用する目的は、ビジネス フローを使用して孤立した機能ポイントをつなぎ合わせ、テスターに全体的なビジネス感覚を確立し、機能の詳細でビジネス プロセスの重要なポイントを無視する誤った傾向を回避することです。 。例: 音声通話の一般的なビジネス プロセスは、音声通話、同時振動、音声メッセージ、通話保留、通話転送の機能を組み合わせたものです。
基本的にどのソフトウェアもシナリオ方式を採用していますが、これはどのソフトウェアもその背後にビジネスサポートがあるためです。
シナリオ手法は主にソフトウェアのビジネスロジックやビジネスプロセスをテストするために使用されます。私たちはテスト課題をもらったとき、ある制御（同値クラス＋境界値＋判定表など）の詳細なテストにまず注目するのではなく、主要な業務プロセスや主要な機能が適切であるかどうかにまず注目します。正しく実装されているため、シナリオ メソッドを使用する必要があります。ビジネスプロセスや主要な機能に問題がなければ、制御の詳細を同値クラス、境界値、デシジョンテーブルの観点からテストします（最初に全体、次に詳細）。
注: シナリオ方式のテストケース設計のポイントは、ビジネスプロセスが正しいかどうかをテストすることですが、テストの際には、ビジネスプロセステストで問題がないことが機能を保証するわけではないことに注意してください。テストの適切性を確認するには、単一の機能に対して詳細なテストを実行する必要があります。
25. 偶発的なトラブルへの対応
1. バグは必ず送信してください。
- 1. このような欠陥があることを覚えておいてください。そうすれば、将来その欠陥に遭遇したときに、その原因がわかるかもしれません。
- 2. 特殊な操作や動作環境など、エラーの原因を特定してください。
- 3. テスターよりもプログラマーの方がプログラムに精通しているので、たとえ再現できなくても提出すれば、プログラマーは問題を理解してくれるでしょう。
- 4. 再現不可能な問題が再発した後は、プログラマに直接電話して問題を調査してもらうことができます。
- 5. バグを記録するときは、問題が発生したときのテスト手順、テスト環境、テストデータを明確に記述するようにしてください。
2. バグを再現してみます。
26. ある場所がバグだと思っていても、開発側はバグではないと考えている場合、どう対処すればよいですか?
1. 開発バグと判断した根拠を伝えるとともに、開発がバグではないと判断した理由を明らかにする。
2. 1. 要件定義書の参照、2. プロダクトマネージャーとの連絡、確認をもとに、開発理由を検証します。
3. 検証結果はバグではありません。バグを閉じます。バグの場合は、製品の品質を確保するために開発に送信して処理します。
27. 製品の発売後にユーザーがバグを見つけた場合、テスターは何をすべきですか?
1. テスターが問題を再現した後、追跡のために問題チケットを送信します。
2. 問題の重大度、問題が修正された場合の影響範囲、回帰テストのためにどの機能をテストする必要があるかを評価します。
3. 問題が修正されたら、まずテスト環境に戻り、合格後に本番環境にパッチを適用し、回帰テストを実行します。
4. 経験を要約し、問題の原因を分析し、次回同じ問題が起こらないようにします。
28. 二十八の定理
欠陥は積み重なる傾向があります。モジュールには他のモジュールよりも多くの欠陥が見つかりました。これは通常、モジュールが欠陥を明らかにしたことを意味するわけではありませんが、このモジュールにはまだ発見されていない欠陥が同じくらいあることを意味します。これは有名な 28 の定理です。欠陥の 80% は 20% のモジュールに発生します。
29. 欠陥を追跡する方法
不具合が見つかった場合は、Zentao 上の開発部門に問題リストを提出し、定期的に（1 時間でも 2 時間でも大丈夫です）不具合が解決したかどうかを確認する必要があります。解決が間に合わない場合は、開発を促す 開発者に時間内に問題を修正してもらう 問題が修正された後、時間内に回帰テストを実行する必要がある
30. 不具合状況
1. 初期化: 欠陥の初期状態。
2. 割り当て予定: 欠陥は、処理のために関連する開発者に割り当てられるのを待っています。
3. 修正予定: 欠陥は開発者が修正するのを待っています。
4. 検証対象: 開発者は修正を完了し、テスターによる検証を待っています。
5. レビュー対象: 開発者が欠陥の修正を拒否したため、レビュー委員会によるレビューが必要です。
6. 解決済み: 欠陥は処理されました。
31. 欠陥の分類
軽微な欠陥、一般的な欠陥、重大な欠陥、致命的な欠陥
32. 欠陥チケットには次の要素が含まれている必要があります
欠陥のタイトル、欠陥の種類、再現手順、期待される結果、実際の結果、欠陥の優先順位、添付ファイルの備考
33. 試験報告書の主な内容
テストレポートに含まれるもの: テストモジュール (各モジュールは、テストの開始時刻と終了時刻、設計されたユースケースの数、合格した数、失敗した数、バグの数、残ったバグの数を記録する必要があります) 、解決されたバグの数、および結論としてこのモジュールのフォローアップ）
BUG統計は、時間軸に従ってBUGの数を数えます。例: XXXX X月X日、見つかったバグの数、クローズされたバグの数、残っているバグの数、高レベルのバグの数、中レベルのバグ、低レベル、推奨されるバグの数 プロジェクトの終了までにリストされるバグの数
プロジェクトの概要、テストの一般的な結果を報告します。
ソフトウェアの残存事項とリスク、残存する問題とリスクを一つ一つ説明する必要がある
最後に、ソフトウェアがオンライン標準、日付、署名、スタンプなどを満たしているかどうかを判断します。
34. バグを見つける方法:
1. バグを見つけるには、まずバグの詳細情報を確認し、説明に従ってどのモジュールのどのコードに問題があるのかを最初に分析します。
2. バグの原因となったテスト環境、テストコードセグメント、テストデータを確認し、テスターの誤操作によるプログラム例外を排除します。
3. テストコード、テスト環境、データが正しいことを確認した後、バグの根本原因をさらに分析します。ここでは、関連ツールを使用して分析できる特定のテスト ビジネスに注目する必要があります。
4. 製品またはビジネスに関連するログ記録がある場合、ログを分析することでバグを確認できます。
5. 一連の分析後、テスターは基本的にバグの原因を確認し、開発者に直接バグの指摘を依頼できます（コミュニケーションスキルに注意）
6. すべての側面を分析してもバグの原因が確認できない場合は、開発者を見つけて一緒に原因を突き止めることができます（バグシーンは保存されるか、バグシーンが再現されることに注意してください）
7. バグを確認した後、バグ追跡のために船荷証券が開発者に送信されます。
次の情報を問題シートに明確に記載する必要があります。
具体的なテスト時間、テスト環境、テストシナリオ、テストの具体的な業務と機能、使用したテストコードとテストデータ、テスト実行手順、テスト結果、バグ現象（できればスクリーンショット）、ログ記録、期待される結果、バグ確認関係者等
8. 開発者がバグを修正した後、バグを追跡し、回帰テストを実行します。(バグが完全に修正されているか、他の機能に影響がないか、新たな問題が発生していないかに注意してください)
35. 開発には修正する時間がありません。バグ修正を促進する方法:
1. パスが深いバグについては、開発促進やバグ修正を目的としたテストを行う際には、以下の点に注意する必要があります。
a) ユーザーの観点から問題の深刻さを分析し、ユーザーがこの問題に遭遇する確率を分析し、開発が問題の深刻さを認識できるようにユーザーの観点から考えるように開発を誘導します。
b) 開発の参考にするために、開発者との以前の同様の問題をリストアップできます。
c) ソフトウェアの責任者は製品にあり、テストや開発の意見がまとまらない場合でも、開発や修正を進めることができないからといって諦めず、製品を見つけて確認し、最終的な判断は自分に委ねられます。製品担当者へ。
2. 発売時期が迫っており、開発が遅すぎて修正できない場合、この時点でテストで問題の深刻さを分析し、修正が必要かどうか製品担当者と話し合う必要があります。
3. バグ修正 変更が大きく、影響範囲が広く、最適解がないため、プロジェクトがオンライン化しようとしているノードでこのようなことが起こることはタブーです。このような状況に直面した場合、開発者は調査作業を行ったり、他の同僚に相談したり、臨時の会議を開催して全員の力を結集して適切な変更計画を検討することをお勧めします。
4. サードパーティ アプリケーションの問題は、開発側では変更できません。原因を確認した後、製品などの関連スタッフを見つけ、サードパーティのスタッフに連絡し、問題についてフィードバックを提供し、問題を解決するためにアプリケーションを推進する必要があります。
まとめ
つまり、バグが修復されるかどうかにかかわらず、テストには独自の原則があり、同時にメリットとデメリットを比較検討する必要があります。開発を進めることができないからといって諦めたり、バグをオンラインに公開したり、オンラインに移行するまでの時間に影響する小さなバグをそのままにしておくわけにもいきません。
36. ソフトウェアテストプロセス
ユーザーニーズの把握 – 「要件仕様書の参照 –」テスト計画（人的・物的リソースの手配とタイムスケジュール） – 「テストケースの作成 –」「ユースケースのレビュー –」環境構築 – 「テストパッケージの配置予測（スモークテスト）」 – 正式テスト – バグ – テスト後のレポート – 「リリースされたバージョン」 – ユーザー指向
37. ボールペンをテストするには、どのような側面をテストする必要がありますか? 三角形のテストケース設計
性能テスト
正常に書けますか? ペン油漏れはありませんか? ペンキャップは正常に押して飛び出すことができますか?
機能テスト
ペンはどのくらいの期間使用できますか、書いた文字は消えますか?
ユーザビリティテスト
ペンの長さや太さは使いやすいか、リフィルの交換はしやすいか？
インターフェーステスト
見た目が美しく、ファッショナブルで、面白いかどうか
セキュリティテスト
ペンの油には有害な物質が含まれていますか? ペン先は人を傷つけやすくありませんか? ペンの油やインクの使用期限はどのくらいですか? 有害な物質は生成されますか?
互換性テスト
温度、気圧、重力が異なる環境でも正常に使用できますか? 異なる紙質や強度で筆記した結果はどうなりますか?
三角形のテスト ケース設計:
1. 3 辺が三角形を形成できない場合はエラーが表示され、三角形を形成できる場合はその三角形の周囲長が計算されます。
2. 二等辺三角形の場合は「二等辺三角形」と出力し、2 つの二等辺三角形の二乗和が 3 番目の辺の二乗和と等しい場合は「直角二等辺三角形」と出力します。
3. 正三角形の場合は、「正三角形」と出力します。
4. プログラムのフローチャートを作成し、テストケースを設計します。
因果関係図、等価クラス分け（推奨検査方法）
38. プロジェクトで見つかった古典的なバグは何ですか? 何が原因でしょうか？
エンコードの問題
ブラッシング防止のためインターフェースを制限している場合、カウンタにより電流が制限され、一定の閾値を超えるとcodeMsgオブジェクトをフロントエンドに返して表示する際に表示されるStringが文字化けする問題が発生します。戻り値は常に json 形式であり、データにカプセル化されています。
今回は、Spring コントローラーがデータを返すのではなく (SpringBoot のデフォルトは utf-8)、バイト配列を直接返すために出力ストリームを通じて直接応答に書き込まれ、エンコードされた文字化けの問題が発生します。 utf-8を使用すると解決します。
解決が難しいバグは 2 種類しかなく、1 つはプログラムのロジックに問題があり、正しい結果が得られないこと、もう 1 つはミドルウェアや開発環境の問題です。
(1) ロジックに問題がある場合、プロジェクトが比較的大きい場合は、シングルステップ デバッグのみを使用するか、System.out.println() を使用して目的のデータを出力し、どのステップに問題があるかを確認することができます。 。
(2) 開発環境やミドルウェアに問題がある場合は、インターネット上の情報を参照するしか解決できません。英語の読解力に問題がない場合は、Stack Overflow を使用して情報を確認することをお勧めします。
39. 要件文書があまり詳細ではない場合、テストを実行するにはどうすればよいですか?
1. 製品や開発者、あるいはこの機能を依頼した人に、この機能の背景や意図、どのような問題を解決したいのかを率先して理解してもらう。テスト時にアイデアを出し、関数が正しく実装されているかどうかを知る
2. 機能のいくつかのビジネス上の問題をテストできるように、このビジネスに精通している人にテストしてもらうようにしてください。
3. 要求仕様がないため、テスト側は機能が完成してテストに移行して初めてその機能が分かるため、この時点でテストケースを書いても遅いのでこの方法を採用しますテスト中のテストポイントを記録し、グループ内でこれらのテストポイントを確認し、漏れがないか確認します。
40. ソフトウェアのバグをできるだけ早く見つけるにはどうすればよいですか?
再現可能なバグを優先します。いくつかの手がかりのないバグについては、経験豊富な同僚、バグの増幅、バイナリ位置決め方法、シミュレートされたシーンなどについて話し合うことができます。
41. ATM のカード飲み込み現象はバグですか?
いいえ、術後にキャッシュカードを抜き忘れて不正請求されることを防ぐために特別に設けられたセキュリティ対策であり、カウントダウンタイマーが特別に設置されています。制限時間内にカードを取り出さないとカードが飲み込まれてしまいます
42. 問題のないシートの提出を減らすにはどうすればよいですか?
1. 欠陥の概要説明は、関連する開発担当者が一目で問題を理解できるように、明確かつ正確である必要があります。
2. 完全な欠陥レポートには、概要説明、欠陥発見者、テスト環境、ブラウザ、欠陥再現手順、重大度レベル、譲受人、機能モジュールなどの必要な要素情報が含まれている必要があります。必要な要素情報は完全かつ明確でなければなりません。説明された。
3. 関係する開発責任者が提出された欠陥を再現手順に従って正確に再現し、欠陥の原因を特定できるように、欠陥再現手順を明確に記述しなければなりません。
4. 割り当ては明確である必要があり、欠陥が特定の開発者に属することがわかっている場合は、中間割り当てプロセスの時間を短縮するために、対応する担当者に直接割り当てるべきです。
5. テストデータ テストデータは欠陥を再現するための重要な要素情報であり、テストに使用される情報は明確かつ正確に記述されなければなりません。開発者は、テストによって提供されたテスト データに基づいて欠陥を正確に再現できます。
6. 添付ファイルのスクリーンショット情報、添付ファイルまたはスクリーンショットの情報により、開発者は一目で問題を理解できるため、必要に応じて添付ファイルまたはスクリーンショットの情報を提供することも非常に重要です。
7. 欠陥内容の説明の口調 欠陥リストを作成するときは、（テストの専門性を反映して）専門用語を使用するようにしてください。次に、欠陥レポートを作成するときに個人的かつ客観的な口調を使用しないように注意してください。開発者とテスターの関係に影響を与えないように。
43. Windows 上で動作が非常に遅いプログラムがありますが、プログラムに問題があるのか、ソフトウェアやハードウェア システムに問題があるのかを判断するにはどうすればよいですか?
1. システムに中程度の特性があるかどうかを確認します。たとえば、ブラウザ ウィンドウが継続的に開かれる、システム内のファイル アイコンが均一のアイコンに変更される、CPU 使用率が 90% 以上に維持されるなどです。
2. ソフトウェア/ハードウェア構成がソフトウェアの推奨規格を満たしているか確認します。
3. 現在のシステムが独立しているかどうか、つまり、次のような CPU リソースを消費する外部サービスを提供していないことを確認します。
4. C/S 構造または B/S 構造のソフトウェアの場合、サーバーへの接続の問題が原因であるか、アクセスの問題が原因であるかを確認する必要があります。
5. システムに負荷がかかっていないときに、パフォーマンス モニターをチェックして、アプリケーションの CPU/メモリへのアクセスを確認します。
44. 検索機能のテスト方法
功能方面的测试：
単一の単語、フレーズ、文を検索し、取得したコンテンツが正確かどうか、およびリンクが正確かどうか
長さ: たとえば、入力ボックスが 100 文字をサポートしている場合、最大長が 100 文字と 101 文字で正常であるかどうかをテストする必要があります。
サポートされている文字の種類は何ですか: 数字、文字、漢字、文字! ＠！#、特殊文字; (要求に応じて)
文字列の前後にスペースがあるかどうか、前後のスペースをフィルタリングするかどうか、および途中のスペースを保持するかどうか (要件に応じて)
全角および半角の文字と数字（必要に応じて）
性能方面的测试
検索ボタンをクリックしてから検索結果が表示されるまでどのくらい時間がかかりますか
検索ページに到達するまでにどれくらい時間がかかりますか
セキュリティテスト
SQL インジェクション攻撃を防止できるか、XSS 攻撃を防止するかどうか
ユーザーエクスペリエンスのテスト:
ページレイアウトは適切か、入力ボックスとボタンの位置は合っているか
入力ボックスのサイズとボタンの長さ、高さが適切かどうか
ショートカットキー：全選択、一部選択、コピー、切り取り、貼り付けの可否、最大長を超えて貼り付けた文字列の表示方法
互換性テスト
BS アーキテクチャ: IE、Firefox、Google、360 などのさまざまなブラウザ テスト。
APP: Huawei、vivo、oppo など、さまざまなタイプ、さまざまな解像度、さまざまなオペレーティング システムの主流の携帯電話でテスト済み。
45. ログイン機能のテスト方法
功能方面的测试：
正しいユーザー名とパスワードを入力し、送信ボタンをクリックしてログインに成功すると、正しいページに移動します。
正しいユーザー名と間違ったパスワードを入力すると、ログインが失敗し、対応するエラー メッセージが表示されます。
間違ったユーザー名と正しいパスワードを入力すると、ログインが失敗し、対応するエラー メッセージが表示されます。
ユーザー名が空の場合、検証ログインは失敗し、対応するエラー メッセージが表示されます。
パスワードが空の場合、検証ログインは失敗し、対応するエラー メッセージが表示されます。
ユーザー名とパスワードは空です。ログインをクリックしてください
ユーザー名とパスワードの前後にスペースがあるかどうか、間のスペースを処理するかどうか（要件に応じて）
性能方面的测试
ログインページを開くのにどれくらい時間がかかりますか
正しいユーザー名とパスワードを入力した後、正常にログインして新しいページに移動するまでにどれくらい時間がかかりますか?
安全性方面的测试
パスワードがフロントエンドで暗号化されるかどうか、およびネットワーク送信中に暗号化されるかどうか
ユーザー名とパスワードの入力ボックスは SQL インジェクション攻撃を防ぐことができますか?
ユーザー名とパスワードの入力ボックスが XSS 攻撃を防止できるかどうか
間違ったログインの数を制限する (総当たりクラッキングを防ぐため)
複数のユーザーによる同じマシンへのログインをサポートするかどうか
ユーザーが別の端末でログインする
ユーザーのリモートログイン
用户体验测试：
ページレイアウトは適切か、入力ボックスとボタンの位置は合っているか
入力ボックスのサイズとボタンの長さ、高さが適切かどうか
全ての操作をキーボードで行うことは可能ですか、ショートカットキーはありますか？
ユーザー名、パスワードを入力してEnterを押し、ログインできるかどうかを確認します
認証コードが含まれる場合は、文字が歪んで認識しにくいかどうか、色（色覚異常ユーザー）を考慮するか、更新ボタンや変更ボタンが使いやすいかどうかなども考慮する必要があります。
兼容性测试
BS アーキテクチャ: IE、Firefox、Google、360 などのさまざまなブラウザ テスト。
APP: Huawei、vivo、oppo、Apple など、さまざまなモデル、さまざまな解像度、さまざまなオペレーティング システムを備えた主流の携帯電話でテスト済み。
46. タオバオのショッピング カートをテストする必要がある場合、テスト ケースをどのように設計しますか、またどのような側面を考慮する必要がありますか。
1. タオバオページを開いた後、ページのレイアウトは完了していますか?
2. ページ上の機能ボタンが正常に表示できるか
3. 買い物かごに追加する商品ページに表示されるかどうか
4. 選択した商品をショッピングカートに追加できるかどうか
5. ショッピングカートに入れた後、商品のすべての情報が表示されるかどうか
6. ショッピングカートに追加した商品を削除できるかどうか
7. ネットワークが貧弱であるか、ネットワークがショッピング カートに正常に追加できない場合
8. ショッピングカートを追加した後、プラス記号をクリックすると数量は増加しますか?
9. 買い物かごに入れた後、マイナス記号をクリックすると数量は減りますか?
10. マイナス記号をクリックして特定のレベルまで下げると、これ以上下げることはできないというメッセージが表示されますか?
11. タオバオ ユーザーがログインしていない場合、ショッピング カートに追加するときに最初にログインするよう求めるメッセージが表示されますか?
12. 製品が選択されていない場合は、「チェックアウト」をクリックすると、「チェックアウトする項目を追加してください」というメッセージが表示されますか?
13. 商品確認後、選択した商品の合計金額を表示するかどうか
14. 合計金額を表示する項目にチェックを入れた後の合計金額の計算は正しいですか？
15. 商品を選択して購入手続きボタンをクリックすると、注文内容の確認ページに入りますか？
16. 注文確認情報ページの合計金額は正しいですか?
17. 合計価格は不正確になりますか。たとえば、正しい合計価格は 18.99 ですが、結果は実際に 18.999999999999 であることを示しています。
18. トップに戻る機能はありますか?
19. 製品の属性を編集することはできますか?
20. コレクションに移動できますか
21. 店舗名の表示の有無
22. すべての商品を選択することはできますか?
23. すべての製品の選択を解除することはできますか?
24. ショッピングカート内の商品の仕様変更は可能ですか？
25. 追加ショッピングの数量が在庫数量を超えるかどうかは制限されています
26. ショッピングカートを空にすることはできますか?
27. 商品の数量が増減すると決済金額は変わりますか?
28. リフレッシュ回数が多すぎるとフラッシュバック現象が発生しますか?
29. 携帯電話がかかってくると、淘宝網のページは引き続き実行されます
30. 携帯電話のメモリが十分でない場合、淘宝網は実行中にフリーズしますか?
47. テストケースの一般規則
最後に、私の記事を注意深く読んでくださった皆様に感謝いたします。ここに来られた者として、迂回路を避けていただきたいと思います。ここでは、自動テストのための学習リソースをいくつか共有します。お使いいただければ、 、あなたはそれを持ち帰ることができます。あなたに与えられることを願っています。途中で助けてください。( Python プログラミング、WEB 自動テスト、アプリ自動テスト、インターフェイス自動テスト、テスト フレームワーク、継続的インテグレーション、自動テスト開発、パフォーマンス テスト、セキュリティ テスト、大規模な工場面接の質問、履歴書テンプレートなど、そしてもちろんいくつかのテストの基本が含まれます) 、ツール、アプリのテスト、インターフェイスのテスト、Linux、mysql データベース、その他の基本的な知識）を学ぶことで、より良い進歩が得られると信じています。
情報取得方法：
