1. B/SアーキテクチャとC/Sアーキテクチャの違い
B/SはOSとブラウザさえあればクロスプラットフォーム、クライアント側のメンテナンス不要、メンテナンスコストの低さは実現できますが、パーソナライゼーション能力が低く応答速度が遅いのに対し、C/Sは応答速度が速く、強力なセキュリティのため、一般的なアプリケーションに適しています
。 ローカルエリアネットワークでは、異なるオペレーティングシステムに合わせて開発する必要があり、保守コストが高いためです。
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: (見つからない) サーバーはクライアントによって要求されたリソースを見つけることができません; Not Found
500: (サーバーの内部エラー) 要求を完了できません。
3. POSTとGETの違い
Get リクエストは通常、データを取得することです (実際には送信することもできますが、一般的な方法はデータを取得することです)。post リクエストは通常、データを送信することです。
Get は、送信プロセス中にデータがリクエストの URL に配置され、Post のすべての操作がユーザーには表示されず、リクエスト データが本文 (最も一般的なシナリオ、ユーザーのログイン パスワード) に配置されるため、安全ではありません。送信、ポストでリクエストする必要があります)
Get で送信されるデータの量は、主に URL の長さの制限により少量ですが、Post で送信されるデータの量は比較的多く、通常はデフォルトで無制限です。
Get リクエストはキャッシュできますが、Post リクエストはキャッシュされません
同時に、ソフトウェア テストに関するビデオ チュートリアルも用意しました。必要な場合は、すぐ下で視聴するか、記事の最後にある小さなカードをクリックして情報ドキュメントを無料で入手してください。
ビデオチュートリアルを視聴できる場所:
https://www.bilibili.com/video/BV1SY4y1p7k6/?spm_id_from=333.999.0.0&vd_source=74d0257ec7066cc4f9013524f0bb70134. 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. ユーザーのトレーニング
管理者として、1 人は特定の工場または地域でトレーニングを受けている必要があります。
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. テストの目的を明確に理解する
2. 製品の機能テストポイントを理解している
3. 「相互影響」の問題を回避するためのモジュールの原理に精通している
4. ユーザーシナリオの問題とインターネットアクセスの問題に焦点を当てる
5. 雑にならない主要なテストケース設計
テスト ケースを作成する場合:
1. テストケースフレームワークを構築する
2. テスト手順の設計 (1 つは、手順が大まかすぎるとテストを見逃しやすいということです。もう 1 つは、詳細に記述しすぎるため、時間と労力がかかる可能性があり、経営者の思考を制限します。）
テストケースの設計方法と考え方
1. 製品テストの主な目的を念頭に置く
2. 正確な表現に注意する
23. 一般的なテストケースの設計方法
同値クラス分割、境界値解析、誤差推論法、決定表、直交実験法
24. シーンメソッドを使用する場合
シナリオ手法は、業務プロセスが明確で複雑な業務を伴うシステムや機能の解決に適しており、ソフトウェアビジネスをベースにしたテスト手法です。
シナリオ手法を使用する目的は、ビジネス フローを使用して孤立した機能ポイントをつなぎ合わせ、テスターに全体的なビジネス感覚を確立し、機能の詳細でビジネス プロセスの重要なポイントを無視する誤った傾向を回避することです。 。例: 音声通話の一般的なビジネス プロセスは、音声通話、同時振動、音声メッセージ、通話保留、通話転送の機能を組み合わせたものです。
基本的にどのソフトウェアもシナリオ方式を採用していますが、これはどのソフトウェアもその背後にビジネスサポートがあるためです。
シナリオ手法は主にソフトウェアのビジネスロジックやビジネスプロセスをテストするために使用されます。私たちはテスト課題をもらったとき、あるコントロール（同等のクラス＋境界値＋判定テーブルなど）の詳細なテストにまず注目するのではなく、主要な業務プロセスや主要な機能が適切であるかどうかにまず注目します。正しく実装されているため、シナリオ メソッドを使用する必要があります。ビジネスプロセスや主要な機能に問題がなければ、制御の詳細を同値クラス、境界値、デシジョンテーブルの観点からテストします（最初に全体、次に詳細）。
注: シナリオ方式のテストケース設計のポイントは、ビジネスプロセスが正しいかどうかをテストすることですが、テストの際には、ビジネスプロセステストで問題がないことが機能を保証するわけではないことに注意してください。また、テストの適切性を確保するために、単一の機能について詳細なテストを実行する必要があります。
25. 偶発的なトラブルへの対応
必ずバグを報告してください
1. このような欠陥があることを覚えておいてください。そうすれば、将来その欠陥に遭遇したときに、その原因がわかるかもしれません。
2. 特殊な操作や動作環境など、エラーの原因を特定してください。
3. テスターよりもプログラマーの方がプログラムに精通しているので、たとえ再現できなくても提出すれば、プログラマーは問題を理解してくれるでしょう。
4. 再現不可能な問題が再発した後は、プログラマに直接電話して問題を調査してもらうことができます。
5. バグを記録するときは、問題が発生したときのテスト手順、テスト環境、テストデータを明確に記述するようにしてください。
バグを再現してみる
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. テストレポートの主な内容
テストレポートに含まれるもの: テストモジュール (各モジュールは、テストの開始時刻と終了時刻、設計されたユースケースの数、合格した数、失敗した数、バグの数、残ったバグの数を記録する必要があります) 、解決されたバグの数、およびこのモジュールのフォローアップ 要約すると、
時間軸に従ってバグの数をカウントするバグ統計、たとえば: XXXX X 月 X 日、見つかったバグの数、解決されたバグの数、残っているバグの数、高レベルのバグの数、中レベルのバグの数、低レベルのバグの数 プロジェクトの終了までにリストされたバグと提案の数 プロジェクトの概要、
レポートテストの一般的な結果。
残りとリスク、ソフトウェアに残っている問題は何か、リスクは何か、すべてを1つずつ説明し、最終的にソフトウェアがオンライン
基準、日付、署名、押印などを満たしているかどうかを判断する必要があります。
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. 機能のビジネス上の問題をテストできるように、機能が正しく実装されているかどうかを知る 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 攻撃を防止できるかどうか誤ログインの回数は制限されています
(総当たりクラッキングを防ぐため) 1 人のユーザーが異なる端末にログインすること、およびユーザーが異なる場所からログインすることをサポートします
ユーザーエクスペリエンステスト
ページレイアウトは適切か、入力ボックスとボタンの位置は合っているか
入力ボックスの大きさ、ボタンの長さ、高さは適切か
キーボードで操作できるか、ショートカットキーはあるか
ユーザー名とパスワードを入力して 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.
商品の
合計金額は正しいですか?注文情報が正しいことを確認していますか?精度が不正確です (例: 正しい合計価格は 18.99 ですが、結果は実際に 18.999999999999 であることを示しています)
18. トップに戻る機能はありますか? 19.
製品属性を編集することはできますか? .全商品を選択できますか? 23.全商品の選択をキャンセルできますか? 24.ショッピングカート内の商品の仕様を変更できますか?
25. 在庫数を超える買い物の追加には制限があるかどうか
26. ショッピングカートを空にすることはできるかどうか
27. 商品数量の増減により決済金額は変化するかどうか
28. 多すぎる場合現象
29. 携帯電話から電話がかかってくると、タオバオのページはまだ実行されます
30. 携帯電話のメモリが十分でない場合、タオバオの実行中にタオバオがフリーズしますか?
以前にリリースされた一連のソフトウェア テスト リソースを整理しました [無料で入手するには、記事の最後にある小さなカードをクリックしてください]。入手するためのルーチンは必要ありません。
基本的にソフトウェアテストの中核となる技術点をすべて網羅しています: テスト理論、Linux 基礎、MySQL 基礎、Web テスト、インターフェイス テスト、アプリ テスト、管理ツール、Selenium 関連、パフォーマンス テスト、コンピュータ ネットワーク、構成原理、データ構造とアルゴリズム、ロジック質問、人事、技術的な脳マップなど...クオリティが非常に高いです！！！技術面接には十分すぎるほどです！
文書全体は合計 200 ページを超えており、すべてをお見せするのは決して非現実的です。読者の読書体験に影響を与えないように、内容の一部のみを示しています。ご理解いただけると幸いです。面接前に復習して良い仕事を見つけるのに役立ち、学習するためにインターネットで情報を検索する時間を節約できます。皆さんも何か得るものがあれば幸いです！
