BossとLagouで数十枚の履歴書を提出しましたが、70%が未読、30%が既読、既読返信の半分は履歴書添付の送付を求められ、今週は7～8社が面接を受けましたので、現在の環境は本当に難しい
この半月の間、毎日3～4件の面接が設定されており、平均すると各企業2回以上の面接が行われており、口頭で合意した。個人的には外資系企業が気に入っていますが、やはり人気がありません。国内のインターネット企業は本当に怖いです。対面での技術面接の経験が皆さんのお役に立てれば幸いです、さあ！急ぐ！
技術面接の質問
1. プロジェクトおよびビジネス関連
1.現在のプロジェクトのテストプロセスについて説明してください。
要件プレゼンテーション→要件レビュー→技術レビュー→テストケースレビュー→研究開発スモーク→研究開発テスト→テストテスト事前チェック→テストレーンテスト→シャトルバスリリース>テスト統合テスト (製品受け入れ) -> リリース前環境リリース -> 実稼働環境リリース (製品テスト受け入れ) -> オンライン データ監視 (1 ～ 2 日) -> ビジネス ドキュメントの作成 (これは当社のケースです)会社、実情に合わせて誰でも説明できる）
2. テスト プロセスで改善できる点はありますか? これらの問題についてフィードバックがあり、結果は得られていますか?
1) 火曜から木曜の期間中、隔週で APP カテゴリを反復して公開プロセスを標準化し、研究開発のオンライン公開権限を回復します。
2) テスト提出プロセスを標準化し、テスト提出の許可条件、テスト提出と返却プロセス、煙を通過しなかった場合のペナルティの仕組みを増やす。
3）製品レビューを標準化し、新しい需要の提示、90％以上の製品完成がレビューに入り、需要の完成は拒否されます。
4) オンライン CS の仕組み、PO、P1 旧病院リプレイ、P3、P4 CS 降下、ピットを踏んだ経験の記録、逆プロセス最適化または基本機能構築を導入します。
3. 需要が明確ではありません。どうすれば解決できますか?
1) 根本的な問題はプロセスのメカニズムです。チームワークは個人の信頼性ではなくプロセスの仕組みが必要であり、その仕組みを運用するには担当者と連携の仕方が不可欠な要素となります。プロセスメカニズムの確立は、アジャイルで無駄のない考え方を指すこともあります。
2) コミュニケーションでブレークスルーを起こす プロジェクトを高品質かつタイムリーに提供することが業界と研究の共通の目標であり、共通の目標に基づいてコミュニケーションを図り、協力における問題を解決します。
4. テストタスクが多すぎて時間が足りないのですが、どうすればよいですか?
個々のプロジェクトの質問:
テスト範囲の評価が不完全で、時間見積もりが楽観的すぎて、時間見積もり、研究開発、テストの工数比が 3:1（+時間）になっていないか
テストの進行を妨げる問題（バグ、テスト環境 など）があるか、テスト時間がかかり、プロジェクトが逆戻りしているか、機能が多く、テスト時間が不十分であるかどうか（需要の削減、バッチでのオンライン化） 2 ) プロジェクトの問題のほとんどは
テスト効率に問題はないか 、冗長なテストケースが多すぎないか
頻繁に並列テストが行われ、テストのパフォーマンスが期待を満たさなくなるかどうか (リソース割り当て)
・ 長期的な人員負荷が80％を超えているか、業務配置が合理的か、人員がボトルネックに達していないか（人員追加）
5. Cookie、セッション、トークンの違いを紹介します
1) セッションはサーバーに保存され、ステータス リストとして理解でき、一意の識別記号 sessionId (通常は cookie に保存されます) が付けられます。サーバーは cookie を受信した後、sessionId を解析して検索します。セッション リストで、対応するセッションを見つけます。
2) Cookie は、クライアントに保存される sessionId を持つトークンのようなもので、通常はブラウザによって自動的に追加されます。
3) Cookie のセキュリティはセッションよりも劣ります。
4) トークンもトークンに似ており、ステートレスで、ユーザー情報はトークンに暗号化されており、サーバーはトークンを受信した後に復号化すると、それがどのユーザーであるかを知ることができます。
6. Get リクエストと Post リクエストの違い
1) get はサーバーからデータを取得すること、post はサーバーにデータを送信することです。
2) get のパラメータは URL で確認できますが、post のパラメータはユーザーからは確認できません。
3) get によって送信されるデータの量は少量であり、2KB を超えることはできません。郵便で送信されるデータの量は比較的多く、通常はデフォルトで無制限になっています。
4) get の安全性は比較的低く、post の安全性は比較的高い。
7. 一般的なステータス コードは何ですか?
2は成功を表します。
200: リクエストは正常に処理されました。3 はリダイレクトを意味します。
301: 永続的なリダイレクト。リソースには新しい URI が割り当てられています。
302: 一時的なリダイレクト。リソースは一時的に割り当てられています。新しい URI4 はクライアント エラーを表します。
400: リクエスト メッセージの構文エラー、またはパラメータ エラー。 401: HTTP 認証に合格する必要がある、または認証に失敗しました。 403: リクエスト リソースが拒否されました。
404: 要求されたリソースが見つからず、サーバーは理由もなく拒否されました。5 はサーバー エラーを表します。
500内部サーバーエラー;
501: リクエストは完了しませんでした。サーバーは要求された機能をサポートしていません 503: サーバーが過負荷になっているか、メンテナンスのため停止しています。
8. HTTP と HTTPS の違いは何ですか?
1) http はハイパーテキスト転送プロトコルであり、情報はプレーン テキストで送信され、https は安全な ssl 暗号化転送プロトコルです。
2) http と https はまったく異なる接続方法と異なるポートを使用します。前者は 80 です。
9. フロントエンドの問題、バックエンドの問題、またはデータの問題をトラブルシューティングするにはどうすればよいですか?
1) フロントエンドがパケットをキャプチャしてインターフェイスを呼び出しているかどうかを確認し、インターフェイスが呼び出されない場合は、フロントエンドに問題があります。
2) インターフェースが正常に結果を返しても、その結果が期待した結果と異なる場合は、フロントエンドのパラメータが正しいかどうかを確認してください。パラメータが間違っている場合は、フロントエンドの問題です。パラメータは正しいが、結果がエラーを返す場合、それはバックエンドの問題です。
3) バックエンド インターフェイスから返されたデータは正しいが、ページが正しく表示およびレンダリングされない場合、これもフロントエンドの問題です。
10. WebテストとAPPテストの違い
1) 携帯電話はコミュニケーションツールとして使用され、電話の着信、発信、テキストメッセージの受信などの操作は、アプリアプリケーションプログラムに影響を与えるため、アプリテストで考慮すべき最初の属性特性は次のとおりです。中断テスト、着信中断: 電話が切れる、電話が切れる 切断、電話が切れる、電話が切れて通話が中断される メッセージ: テキスト メッセージの受信、テキスト メッセージの表示。
その他の中断: Bluetooth、目覚まし時計、データ ケーブルの抜き差し、電話のロック、電話の停電、電話の問題。(システムクラッシュ、再起動)
2) 携帯電話ユーザーによるアプリ製品のインストールとアンインストール: 前バージョン/前々バージョンから最新バージョンに直接アップグレードします。
·新しいバージョンを新規インストールします
新しいバージョンは古いバージョンを上書きし、古いバージョンをインストールしてアンインストールし、新しいバージョンをインストールし、新しいバージョンをアンインストールし、新しいバージョンをインストールします
· 機能インターフェイスのテストという点では、Web テストとアプリ テストに違いはありません。主な違いは次の点です。
1. システム構成
Web 側は B/S アーキテクチャに基づいており、サーバー側が変更されると、クライアント側も同期して更新されます。
アプリは C/S アーキテクチャであるため、サーバーが変更された場合は、クライアントを更新し、クライアントのコア バージョンを再テストする必要があります。
2. 業績指標
Web 側: 応答時間、CPU、メモリ、スループット。
アプリ: 応答時間、CPU、メモリ、スループット、モバイル トラフィック、モバイル電力。
3. 互換性テスト
ウェブ側: ブラウザ互換
C 側のオペレーティング システム。(Windows、Mac、Linux)
アプリ: 携帯電話のオペレーティング システム (Android、iOS、Windows)、電話のモデル、解像度。(モバイル画面サイズ)
4. Web と比較して、アプリには、干渉テスト(着信、メッセージ、その他のアプリケーション)、弱いネットワーク テスト、ネットワーク スイッチング テスト、インストール、アップデート、アンインストールなどの特別なテストがいくつかあります。
5. テストツール app:appium web:selenium
6. インターフェース操作
Web 側: 画面の左上隅と右下隅。
アプリ: ジェスチャー、携帯電話の水平および垂直画面、タッチ、表裏切り替え、コーナーテスト。
11. パフォーマンス テストではどの指標に焦点を当てる必要がありますか?
1) 応答時間 (RT): 応答時間とは、システムが要求に応答するのにかかる時間を指します。
2) スループット (Throughput): スループットとは、単位時間あたりにシステムによって処理されるリクエストの数を指します。
3) 同時接続数: 同時接続ユーザー数とは、通常、システムが搭載できるシステム機能を同時に使用できるユーザーの数を指します。
4) OPSueries Per Second とは、「1 秒あたりのクエリ レート」を意味します。これは、サーバーが 1 秒あたりに応答できるクエリの数であり、特定のクエリ サーバーが指定された時間内に処理するトラフィックの量の尺度です。
5) TPS: TransactionsPerSecond の略で、サーバーが 1 秒間に処理できるトランザクション数です。ソフトウェアのテスト結果の測定単位です。トランザクションは、クライアントがサーバーにリクエストを送信し、サーバーが応答するプロセスです。クライアントは、リクエストを送信すると計時を開始し、サーバーの応答を受信すると計時を終了し、使用時間と完了したトランザクションの数を計算します。
12. あなたの会社ではインターフェースのテストをどのように行っていますか?
インターフェイス テストと一般テストの実際の違いは、テスト ケースの設計部分です。
1) インターフェース仕様を取得します。
2) インターフェーステスト機能のユースケースを設計します（主にインターフェースがビジネス要件を満たせるかどうかをユーザーの観点から見て、ユースケース設計はブラックボックスのユースケースのセットです）。
３）様々な入力パラメータの検証（正常な状態、異常な状態には、誤った数の入力パラメータ、誤ったタイプ、オプション／必須、相互に排他的または関連するパラメータの考慮が含まれる）。
4) インターフェースの戻り値の各種検証。(インターフェースのドキュメント要件を満たします)
5) インターフェイスの実装ロジックを理解し、ロジック カバレッジを実現します。(ステートメント/条件/分岐/判断/...)
6) インターフェイスは同時に実行できますか?安全ですか?パフォーマンスは要件を満たしていますか?
7) ツールまたは自作コードを使用して検証します。
8) 見つかった問題は機能テストと同じであるため、バグを報告し、追跡ステータスの追跡ステータスを追跡する必要があります。
13. インターフェースのテストケースを設計するにはどうすればよいですか?
一般に、インターフェイスのテスト ケースを設計するときは、次の側面を考慮する必要があります。
① 前提条件を満たしているかどうか。
一部のインターフェイスでは、データを正常に取得するために前提条件を満たす必要があります。トークンへのログインが必要な一般的なリバース ユース ケース: 前提条件が満たされるかどうかについて 0 ～ n 個のユース ケースを設計します (n 個の条件と仮定します)。
②デフォルト値パラメータを運ぶかどうか。
前方のユースケース: デフォルト値を持つパラメータはいずれも入力されず、パラメータは渡されず、すべての必須パラメータには正しい既存の「通常」値が入力され、その他は入力されず、1 つのユースケースが設計されています。 。
③ビジネスルールと機能要件。
ここで、時間の状況に応じて、インターフェースパラメータの記述と組み合わせて、N 個のポジティブなユースケースと詳細な思考ケースを設計する必要がある場合があります。
最後に、私の記事を注意深く読んでくださった皆さんに感謝します。互恵性は常に必要です。それほど価値のあるものではありませんが、必要な場合はそれを取り上げることができます。
これらの資料は、[ソフトウェア テスト] の友人にとって最も包括的で完全な準備倉庫となるはずです。この倉庫は、最も困難な旅を乗り越える何万人ものテスト エンジニアにも同行してきました。お役に立てれば幸いです。パートナーは下の小さなカードをクリックしてください受け取る