採用シーズンのソフトウェアテストポジションにインタビューする方法は？超包括的なテスト共有

プロジェクトのテストプロセス

1. 要件ドキュメントを入手したら、テストケースを作成します

2. テストケースを確認する

3. 開発パッケージを待っています

4. 展開テスト環境

5. スモークテスト（Webページのアーキテクチャ図）

6. ページ初期化テスト（データベース内のデータコンテンツとページに表示されるコンテンツに一貫性があるかどうか、およびそれらが特定の順序で配置されているかどうかを確認します）

7.特定の実行テストケース（ほとんどすべての機能テスト、プロセスメソッド、シナリオメソッド）

8. 欠陥を見つけた場合は、欠陥フォームに記入する必要があります

9. 非機能テスト（SQL、jsインジェクション、ページ効率、js検証のバイパス、データベースへのデータの直接追加）

10. 最終テストレポートを書く

テストケースの設計方法

同値類、境界値、直交実験法、状態遷移法、因果関係図、シナリオテスト法、異常解析法、因果関係図、誤差推測法、判定表

テストケースの要素

IDサブジェクトテスト名作成日デザイナーの説明ステップ名ステップの説明期待される結果の実行ステータス

テストの優先順位

1. 最初に変更されたパーツをテストし、次に変更されていないパーツをテストします

2. 最初にプログラムのコア機能をテストし、次に一般的な機能をテストします

3. 最初に論理関数をテストし、次にビジネス関数をテストします

4. 最初に一般的な状況をテストし、次に異常な状況をテストします

5. 最初に機能をテストしてから、パフォーマンスをテストします

テストレポートに含まれるもの

1.テストの背景を書く

2.テストの目的

3.テスト範囲

4.テスト環境

5.テストデータ

6.テスト基準（強調）

7.テストの進捗状況

8.テスト結果

9.テストの結論

一部の企業は非標準のテストレポートを使用します

おおよそ、テストに費やした時間、テストでテスターに​​よって発見されたバグの数、修正されたバグの数、残りのバグの数、残りのバグの理由、テスト結果などが含まれます。

バグのライフサイクル

送信-開発検証-承認-拒否-開発ソリューション-テスター検証-クローズ-失敗オープン

バグステータス

1. NEW：開発ドッキングステータスに送信されたすべての問題はNEWです。つまり、処理されません。

2. OPEN：開発ドッキング担当者は、最初は転送する問題と判断され、テスターと開発者が指定され、ステータスはOPENです。

3. REFUSE：開発Dockerは、問題を次のリンクに転送する必要はないと判断し、ステータスはREFUSEであり、理由が入力されています。

4. 修正済み：開発者は修復を完了し、テストする必要があり、ステータスは修正済みです

5. REOPEN：テスト部門は、開発者に対するテスターの修復結果に合格し、ステータスはREOPENです。

6. 閉じる：テスターは、問題が要求またはその他の問題であると判断し、理由を入力する必要があります。

欠陥のある要素

欠陥タイトル欠陥ステータス提出者担当者優先度重大度欠陥説明時間スクリーンショット

欠陥レベル

致命的な問題：コア機能が使用できないか、システムがクラッシュします

重大な問題メインビジネスプロセスが使用できず、メインビジネスプロセスの機能に欠陥があり、メインプロセスの使用を継続できません。

一般的な問題メインプロセスの機能上の欠陥ではなく、一般的な問題

マイナーな問題インターフェイスUIの問題プロンプトは標準化されていません。

提案された質問は、あなた自身の経験に基づいていくつかの示唆的な質問をします

WEBテストとAPPテストの違い

1. アーキテクチャが異なります。

Web側はb / sアーキテクチャに基づいており、b / sアーキテクチャはブラウザアドレスに基づいてアクセスされます

アプリ側はc / sアーキテクチャであり、c / sアーキテクチャにはキャリアとしてのクライアントが必要です

2. バージョンリリースの方法とプロセスが異なります。

Web版がリリースされ、新しいコードが開発され、対応するサーバーアドレスにデプロイされ、Web側の更新を均一に実現できます。

アプリのバージョン、開発はパッケージ化する必要があります（apkパッケージとipaパッケージ）、パッケージ化した後、対応するチャネルに公開する必要があります

3. 互換性

Web、さまざまなブラウザ（つまり、chrome、firefox、360、QQ）の互換性をテストします

アプリ、さまざまな解像度、画面サイズ、携帯電話のブランド、システムバージョンをテストします

4. パフォーマンスの側面

Web、テスト応答時間

アプリ、テスト応答時間、トラフィック、消費電力、CPU、GPU、メモリ

5. 安全性

Web、SQLインジェクション。xss攻撃など

アプリ、https暗号化、署名、強化、パスワード暗号化など。

6.アプリのテスト機能

適合性試験

ネットワークテスト

オンラインアップグレードテスト

割り込みテスト

消費電力テスト

弱いネットワークテスト

インストールとアンインストールのテスト

フローテスト

アプリテストの主な内容

1. 機能テスト

ビジネスロジックの正当性のテスト

2. 互換性テスト

システムバージョン

解決

開発者がバグをバグではないと判断した場合の対処方法

一般的なLinuxコマンド

どのような状況で要素を見つけることができないか

GETリクエストとPOSTリクエストの違い

ネットワークの状況

3. 異常テスト

ホットスタート

ネットワークスイッチ

電話情報端末復旧

4. アップグレード、インストール、アンインストール

5. 堅牢性テスト

携帯電話のリソース消費

データ消費

バッテリーテスト

クラッシュリカバリ

開発者がバグをバグではないと判断した場合の対処方法

1. 問題を欠陥管理データベースに送信して記録します。

2. 判断の根拠と基準を得る

要件仕様、製品説明、設計文書などに従って、実際の結果が計画と矛盾していないかどうかを確認し、欠陥を確認するための直接的な基礎を提供します。

文書の根拠がない場合は、同様のソフトウェアの一般的な特性に基づいて不整合があるかどうかを説明し、それが欠陥であるかどうかを確認できます。

ユーザーの一般的な使用習慣に従って、それが欠陥であるかどうかを確認します。

設計者、開発者、顧客担当者などの関係者と話し合い、それが欠陥であるかどうかを確認します。

3. 合理的な議論を行い、あなたの判断の理由をテストマネージャーに説明し、客観的で厳密であり、個人的な感情と混ざらないようにします。

4. テストマネージャーが最終決定を下すのを待ちます。それでも紛争が発生する場合は、会社の方針で提供されているチャネルを通じて上司に報告し、上司が決定を下すことができます。

一般的なLinuxコマンド

1. ifconfigビューのIPアドレス

2. catは、指定されたファイルの内容全体を表示するために使用されます

3. moreは、指定されたファイルの内容をページネーションの形式で表示します

4. mkdir作成ディレクトリ

5. タッチして新しいファイルを作成します

6. grepは、ファイル内で修飾された文字列を検索します

7. 検索指定されたファイルを検索します

8. tail -fは、表示ファイルの後のN行のデータの内容を自動的に更新するために使用されます。

9. -9強制終了を殺す

10. netstat -anp | grepポート番号ビューポート

11. chmod -R777は777パーミッションを与えます

どのような状況で要素を見つけることができないか

1. 不正なコード

2. 要素が表示されない（要素を待つ必要がある）

3. iframeの要素

4. マルチウィンドウ

5. ポップアップウィンドウが表示されます（システムポップアップウィンドウ、JSポップアップウィンドウ）

6. 要素の属性値は動的に読み込まれます

7. 要素を一意に決定することはできません

8. 読み取り専用属性（要素は操作できません）

GETリクエストとPOSTリクエストの違い

1. GETはURLまたはCookieを使用してパラメーターを渡し、POSTはデータをBODYに配置します

2. GET URLには長さの制限があり、POSTデータは非常に大きくなる可能性があります

3. POSTはアドレスバーに表示されないため、GETよりも安全です。

4. 通常、GETはデータの取得に使用され、POSTはデータの送信に使用されます

なぜインターフェーステストを行うのですか

1. バグが少ないほど、修理コストは低くなります。

2. フロントエンドが変更された場合、バックエンドインターフェイスを変更する必要はありません

3. システムのセキュリティと安定性を確認してください。パラメータのフロントエンド送信は信頼できません。

インターフェイステストはどのように行われますか

–プロジェクトのフロントエンドとバックエンドの呼び出しは主にhttpプロトコルインターフェイスに基づいているため、インターフェイスのテストは主にツールまたはコードを介したhttpリクエストの送受信をシミュレートすることです。postman、jmeter、soupUIなどの多くのツールがあります。

-コードで実現されるインターフェースの自動化でも実現できます。フレームワークはUIオートメーションに似ています。リクエストの送信はアサーションによって判断されます。

インターフェイステストの要点

1. インターフェイスから返されるデータが期待される結果と一致しているかどうかを確認します

2. インターフェイスのフォールトトレランスを確認し、渡されたタイプが間違っている場合に処理できるかどうかを確認します

3. インターフェーステストの境界値

4. インターフェイスのパフォーマンス

5. インターフェイスのセキュリティ

httpステータスコード

1. 1xx：要求は正常ですが、応答がありません。実験状態でのみ使用できます。

2. 2xx：2の先頭は、送信が成功したことを示します

3. 3xx：3はリダイレクトを表し、一般的な302

4. 4xx：400はクライアントから送信された文法が正しくないことを意味し、401はアクセスされたページが許可されていないことを意味し、403はページにアクセスする権限がないことを意味し、404はそのようなページがないことを意味し、415はフォーマットエラーです。

5. 5xx：5で始まるものはサーバー例外を表し、500はサーバー内部例外を表し、504はサーバータイムアウトを表します

クッキーとセッションの違い

1. Cookieデータはクライアントのブラウザに保存され、セッションデータはサーバーに保存されます

2. Cookieはあまり安全ではありません。他のユーザーは、ローカルに保存されているCookieを分析し、Cookieのなりすましを実行できます。セキュリティを考慮して、セッションを使用する必要があります。

3. セッションは一定期間サーバーに保存されます。訪問数が増えると、セッションはより占有されます。サーバーのパフォーマンスを考慮すると、サーバーのパフォーマンスを下げるためにCookieを使用する必要があります。

一般的に使用されるadbコマンド

1. adb start-server start adb service

2. adb kill-server close adb service

3. adbデバイスはデバイス番号を表示します

4. adbプッシュコンピュータ電話

5. adbプルモバイルコンピューター

6. adb logcat | grep包名（unix）

7. adb logcat | findstrサインアップ（win）

8. adbshel​​lシェルコマンドラインに入る

9. adbinstall電話にアプリをインストールします

10. adbuninstallアンインストールアプリを電話に

11. adblogcat>ファイル名出力ログをファイルに

12. adb shell top testappリソース消費コマンド

製品のビジネスプロセス

構文解析

履歴書に書かれたプロジェクトの全体的なビジネスプロセスを尋ねる

たとえば、eコマースプロジェクトの登録機能、登録の開始から登録の成功までのプロセス全体

オンライン基準を満たすバージョンは何ですか

合否基準

（1）ソフトウェア要求分析仕様で定義されているすべての機能が完全に実現されており、すべてのパフォーマンス指標が要件に達している。

（2）検収試験で見つかったエラーが修正され、すべてのレベルでの欠陥修復率が標準に達しました。

（3）すべてのテスト項目には、緊急または重大なレベルのエラーが残っていません。

（4）要件分析文書、設計文書、およびコーディングは一貫しています。

（5）完全な受け入れテスト成果物（テスト計画、テストケース、テストログ、テスト通知、テスト分析レポート、受け入れられるソフトウェアインストールプロセス）

シーケンス。）。

欠陥修理率基準

（1）緊急および重大レベルのエラー修復率は100％に達する必要があります。

（2）通常レベルのエラー修復率は95％以上である必要があります。

（3）最適化レベルのエラー修復率は60％以上に達する必要があります。

注：プロジェクトが緊急の場合、通常レベルのエラー修復率は60％以上に達し、最適化されたレベルのエラー修復率は20％に達します。

サーバーの動作ステータス応答インジケーター

（1）同時実行中のcpu％の最大使用率は70〜80％を超えてはなりません。ランデブー同時実行がある場合、短時間で100＆に近づくか到達することが許可される場合がありますが、ほとんどはそうではありません。

95％をチェックする必要があります。

（2）メモリテスト中に、メモリが十分であり、使用可能なメモリが20％以上であることを確認します。

（3）ディスクは、ハードディスクの読み取りと書き込みが40％以下であるかどうかを監視します。

（4）CPU負荷平均は、CPUコア数* 2を超えてはならず、CPUコア数を超えてはなりません。

テストケースレビュープロセスと関連する参加者

1：レビュープロセス

A：開始する前に次の準備をしてください

1.レビューの理由を特定します

2.レビューの時間を決定します

3.レビューの参加者を特定します

4.レビューの内容を明確にする

5.レビュー基準の終了を決定します

6.少なくとも1日前に、レビューが必要なコンテンツがレビュー会議の関係者に電子メールで送信されます。また、詳細なレビューの時間と場所、および補償に関与した担当者を示してください。

7.電子メールで、レビュー会議の関係者に、レビューの内容を少なくとも1回読んでもらい、関連する質問を記録して、レビュー会議で提起できるようにします。

8.会議の主催者（通常はユースケースの作成者）は、会議の前に関連する質問を整理して、会議で提起できるようにする必要があります。

B：レビューを開始する

1.レビューミーティングを開催します。参加者は、デザイナーの説明の後にコメントや提案をすると同時に、詳細なレビュー記録を行いました。

2.一般郵便で関係者と連絡する

3.一般的なIMツールは関連する担当者と直接通信します

4.レビューの内容に応じてレビューする

2：コンテンツの判断

1.ユースケース設計の構造的配置が明確かつ合理的であるかどうか、および要件を効率的にカバーするのに役立つかどうか。

2.優先順位の取り決めが合理的かどうか。

3.テスト要件のすべてのファンクションポイントをカバーするかどうか。

4.ユースケースが適切に実行可能かどうか。たとえば、ユースケースの前提条件、実行手順、入力データ、および期待される結果が明確で正しいかどうか、期待される結果の明確な検証方法があるかどうかなどです。

5.冗長なユースケースは削除されましたか？

6.十分なネガティブテストケースが含まれていますか？完全に定義すると、ここで2＆8ルールを使用すると、ポジティブユースケースの数の4倍になります。結局のところ、堅牢なソフトウェアでは、コードの80％が関数実装の20％を「保護」しています。

7.ユーザーの使用シナリオと使用プロセスのテストケースをユーザーレベルから設計するかどうか。

8.簡潔で再利用可能かどうか。たとえば、反復性の高いステップまたはプロセスを抽出して、再利用可能な標準ステップとして定義できます。

3：参加しているレビュー担当者（ここではレビューのために複数のレベルに分けられます）

1.部門レビュー、テスト部門のすべてのメンバーが関与するレビュー。

2.プロジェクトマネージャー、要件アナリスト、アーキテクチャデザイナー、開発者、テスターを含む会社のレビュー。

3.顧客の開発者とテスターを含む顧客レビュー。この状況は、アウトソーシング企業でより一般的です