オンライン銀行振込のテスト方法、テスト ケースの設計。
回答のアイデア:
マクロ的には、品質モデル（普遍的な公式）から考えることができ、転送の機能、性能、セキュリティをテストすることがポイントです。テストケースの設計は、シナリオメソッドをメインメソッドとして使用でき、最初に転送の基本フローと代替フローをリストします。それからシーンをデザインし、最後にシーンに合わせてデータをデザインします。実際の面接では、具体的な例が必要です。
最初にインターフェイスを確認してください。
再テスト機能:
ピア転送と銀行間転送を確認します。
転送制限を確認します。
違法な口座からの送金を確認します (報告された紛失、凍結、ロックされた口座)。
次に、パフォーマンスをテストします。
テスト作業のプロセスは? 欠陥の状態は? テスト ケースを設計する方法はいくつある?
テスト エンジニアの実際のワークフロー (例として、P2P の中規模バージョン、月に 1 つのバージョン):
プロダクト マネージャーまたは SR は、要件書を開発およびテストに送信します。
最初にテストを見て、需要分析を行います。テストチームリーダーがテスト計画を作成し、テスターにテストタスクを割り当てます（2日間）（このとき、開発は需要分析も実施しています）
2 日後、プロダクト マネージャーは再びテストと開発をまとめて要件を説明 (または要件を確認) しました. 質問がある場合は、直接質問することができます. 要件に問題がある場合は、問題を提起することもできます.戻ったときに SR がそれらを修正します。(所要説明時間0.5日)
要件について話し合った後、テスト担当者はテスト シナリオを整理し、ケース (xmind と Excel を使用) を作成する必要があり、合計 5 営業日かかります。(開発は現時点でコードを書いています)
その後、ケース レビューが行われます. レビュー中には、SR、テストの同僚、開発の同僚がいます. レビューの間、通常、SR、テスト チームのリーダー、および対応するモジュールの開発の同僚がいくつかのコメントを与えます. レビュー後、戻ってケースを修正および補足します。(ケースレビューに0.5日)
変更後、2 つの処理状況があります。
大規模なプロジェクトでは、2 回目のケース レビューが必要になる場合があります。
小規模なプロジェクトの場合、時間が限られている場合は通常、2 回目の試行は行われませんが、改訂または追加されたケースは、リーダーが確認できるように電子メールで送信し、コピーを他の同僚に送信する必要があります。(ケースレビューに 0.5 日、ケース修正に 0.5 日、ケース 2 回目のトライアルに 0.5 日)
ケースレビューの後、テストが開始されます. 一般的に、テスト環境は開発され、セットアップされています.
中規模バージョンのテストは通常、2 ラウンドに分けられます: 1 ラウンド: 5 日; 2 ラウンド: 3 日; 回帰テスト 2 日; (合計 10 営業日)。
リグレッション テストが完了し、オンライン基準が満たされた後、予定どおり、通常は同日の夜の 12 時にオンラインになります。
欠陥ステータス: 欠陥管理のフローチャート
プロジェクトで見つかった古典的なバグは何ですか?
互換性の問題です。IE ブラウザでは注文の送信ボタンをクリックできますが、Google では Firefox ではクリックできません。
注文ページをクエリすると、条件に従ってフィルタリングされた結果が目的の結果ではなく、一部のフィールドの値が表示されない、または正しく表示されない。(開発時にライブラリテーブルから取得した値が間違っているため)
支払いが成功した後、注文ステータスはトランザクションの成功に引き渡されていません。（コードがライブラリテーブルの決済成功記録のステータスコードを正しく取得していないため）
支払いパスワードを変更します。新しいパスワードは元のパスワードと一致しており、それが過ぎています。システムは古いパスワードと新しいパスワードを確認していません。
決済時の携帯電話認証コードは常時使用可能で、有効期限管理がうまくいかない。
モバイル アプリがネットワークから切断された後、もう一度クリックします。ネットワークが切断されたことを示す分かりやすいエラー ページは表示されず、未定義のみが返されます。
満期時の定期預金の自動振替をどのように測定しますか?
回答のアイデア: 有効期限が切れると必ず境界が存在するため、境界値方式を設計で考慮することができます。自動ダンピング (まず、自動ダンピングとは何かを理解する必要があります。)
お金の節約をテストする方法、使用するテスト方法は?
準備のアイデア: 貯蓄は、現在の需要、預金ゼロ、一時金の引き出しなど (特定のルールについては Baidu の下) に分類し、各カテゴリのビジネス ルールに従って適切なユース ケースの設計方法を選択する必要があります。たとえば、1回の最低入金額はいくらですか? 一度に入金できる上限額など
バグを見つけた後はどうすればよいですか?
まず開発がバグかどうかを相談し、彼に予備的な判断をしてもらいます。
バグでなければ、開発側からの理由で比較的十分であり、私がミスをしたのは事実なので忘れてください。
開発者もそれがバグであると考えている場合は、直接言及してください。
開発側の回答に疑問がある場合はバグだと思いますし、開発側はバグではないと主張していますので、弊社チームリーダーまたは開発チームリーダーに相談して判断してもらいます。
BUGが見つかった場合、それは開発自体には関係なく、コンセプトや要件に関係しているのですが、どうすれば解決できますか?
問題をテスト チーム リーダーと開発チーム リーダーに公開し、彼らの意見を聞きます. チーム リーダーは、開発グループ マネージャーとプロジェクト マネージャーに通知し、全員が問題を解決するためにプロダクト マネージャーと話し合います.変更する必要があります。変更されます。
テストの非常に緊急のプロセスで、ブロッキングの問題が発生した場合、対応する開発はそれを解決する時間がありません.どのように問題の解決を促進しますか?
まず問題の深刻度を判断し、該当する開発者から問題の原因を学びます。
次に、自分のテスト チーム リーダーと開発チーム リーダーに報告し、チーム リーダーに知らせ、彼らの意見を調べてから、問題を開発チーム マネージャーに報告して、彼らが調整して対処できるようにします。問題を解決するためにこの開発を支援する他の経験豊富な上級開発者を手配し、残業して問題解決とテストを完了します。
機能テストのバグ レベルをどのように分割しますか?
バグの重大度: L4 と L3 は一般的に言及されており、L2 はプロセスに影響しない限りほとんど言及されていません。L1 は非常に致命的なバグであり、基本的に言及されていません。
他人のユースケースを実行します。ユースケースが間違っているとわかった場合はどうすればよいですか?
最初にケースの作成者に相談するか、テスト チームのリーダーに確認を依頼し、実際に間違っている場合はユース ケースを修正します。
スモークサイドをやったことがありますか？スモークテスト（理論）とは？
スモークテストはプレテストとも呼ばれ、正式なテストの前に、主要なプロセスが通過できることを確認するためのテストです。
スモークテストはありません、つまり、テスト前に開発セルフテストが一般的に必要ですが、開発セルフテスト後（セルフテストには約1日かかります）、スモークテストがないことを確認してください。重大な問題がある場合、テストを開始するようにテストに通知します。
プロジェクトにどれくらいの期間取り組んでいますか? また、ユースケースをいくつ書いていますか? プロジェクトには何人いますか？
プロジェクトはどのくらいの期間行われましたか: (2 つの回答。最初の回答を選択することをお勧めします)
プロジェクトは私が入ったときにすでにオンラインになっていて、それは常に存在し、その後バージョンのマイナー アップデートがあり、マイナー リビジョンの場合はバージョンを作成するのに約半月、ミディアム リビジョンの場合は約 1 か月かかります。バージョンを作成します。バージョンアップのたびに、新機能点や修正点など約60件（月1バージョンの例）を書き込んでいます。
私が入社した当初は、このプロジェクトに最初から（つまり需要分析が始まって）参加しており、約半年で0から1になり、プロジェクトチーム全体では半年で900件程度の案件を書いたと思います。1人で約200本（チームリーダー含めて合計5本）書きました。
PS: ゼロから参加までのプロジェクトであると言う場合、6 か月の期間は需要分析から始まります。要件書が作成される前に、プロダクト マネージャーは多くの準備作業を行う必要があり、これには約 3 か月かかる場合があります。
次に、6 か月の実際の作業時間をテストします。
最初の 2 か月: 最初は、要件書に抜け穴が多く、要件のレビューが多く、基本的には週 1 回でした。開発はコード設計、テストは要件分析、リファレンスドキュメントの閲覧、xmindによるテストシナリオの整理、テストポイントの抽出など、開発とテストの両方が関与することになり、開発ではプロダクトマネージャーと要件について話し合い、テスト多くの場合、開発および製品マネージャーにそれについて尋ねます. ニーズに関する質問. より完璧なロジックを考え出すために、誰もが一歩一歩衝突してきました。
途中2ヶ月：開発・設計後、コーディングを行い、事前に整理したテストシナリオをもとにテスト・ケース作成を行い、さらなる最適化を行います。この期間中、需要台帳は基本的に安定しており、変更されることはありません。変更とは、要件を絞り込み、一般的な場所をより詳細に記述し、理解しやすくすることであり、機能ポイントの大まかな方向性は変更されません。開発およびテスト期間中にご不明な点がございましたら、メールまたは電話でプロダクト マネージャーにお問い合わせください。テストでは、ファンクション ポイントに関する開発上の論理的な質問もよくあります。
次の 2 か月: ケースワークの実装が開始されます。通常、最初のテストは 1 か月、2 番目のラウンドは 1 か月、回帰テストは半か月の 2 回に分けられます。Uat テスト グループは、st テストの第 2 ラウンド中に並行して開始されました。UATテストチームは専任の担当者がいます.通常、stテストチームはそれをサポートするために約1人を派遣する必要があります.uatテストにも1回目（半月）と2回目（半月）があります. .
プロジェクトに関与する人数: 多くの場合、会社には多くのプロジェクトがあり、私はプロジェクト チームの 1 つにすぎません. 私の P2P プロジェクト チームには、開発に 15 人、テストに 5 人、約 20 人がいます. （誰もがアウトソーサーと自負し、A社で働く、オンサイトワークともいう）
6 か月間の P2P ローン商品のテストを依頼された場合、どのようにケースを設計し、テスト ポイントに名前を付ける必要がありますか?
(答えのアイデア: 1. ユーザーの視点からテストします。ユーザーがどのように使用するかをテストできます。2. 1 人が複数の役割を果たし、テストします。3. より異常なシナリオを考え出します。)
ローン商品の入札が終了する T+7 での完全な入札と不十分な入札の条件。
入札終了日T+7前の商品貸出、商品全額前倒し
プロダクトが確立された後、毎月の返済日の前に、システムが電子メール、テキスト メッセージ、およびサイト内の手紙を送信して、借り手にプラットフォーム アカウントにリチャージするように通知するかどうかを確認します。
毎月の返済日に、借り手が返済のためにリチャージする場合、リチャージ資金が十分にある場合、リチャージ資金が不足している場合、またはリチャージがない場合のシステムの処理方法を確認します。リチャージ資金が不足している場合、またはリチャージがない場合、システムは違約金を発生させる必要があります。
借り手が残金を前払いするシナリオでは、一部の商品は早期返済に対応していないか、一部の商品は一定期間後にのみ前払いが可能です (早期返済には一定の手数料がかかります)。これらは、焦点を当てるべきテストポイントです。(借り手ユーザーとして操作して残高を前払いし、バックグラウンド管理者としてレビューしてから、投資家ユーザーとして仮想口座で受け取った資金を確認する必要があります)
借り手が最後の期間の資金を返済するとき、バックグラウンド ページに移動してローン商品のステータスを確認すると、正常に終了するはずでした。トップページに行って再度検索すると、そのようなローン商品はありません。（または追加するには：データベースにアクセスして、このローン商品のステータスを確認してください）
P2P はまだオンラインですか? 確認できますか？プロジェクトにかかった時間と、完了する予定の期間はどれくらいですか?
回答: 2 つのオプション:
まだオンラインになっていないので確認できません.これは新しいプロジェクトであり、半年で完了する予定です.ただし、いくつかの問題が途中で解決されていないため、期間内に完了していません.予定時刻。
あなたが書いたプロジェクトの名前は確かにインターネット上で見つけることができるので、オンラインで見つけることができると言われています。（面接官が実際に確認していない場合があります）
実名認証をどのように測定しましたか? データはどのプラットフォームから取得されますか?
実名認証インターフェース:
銀行カードの実名認証（銀行インターフェースを呼び出し、カード番号、名前、ID番号、携帯電話番号を確認します。携帯電話で受信した確認コードを使用する必要があります）
本人確認・名義認証（国民IDカード番号照会サービスセンター、または直接公安窓口）
登録には実名認証が必要ですか?
登録は実名認証不要：お買い物の際は実名認証が必要です。
P2P のバックグラウンド管理もテストしていますか? 個人のセサミクレジットはどこで取得できますか?
バックグラウンド管理のテスト:
背景もテストしていますが、主にフロントをテストしています。
バックグラウンドは、主にローン管理や資金管理を含むフロントデスクを管理します。
ローン管理：投資家の投資状況を確認したり、借り手のローン商品を確認したり、ローン商品を管理したりできます。承認、各期間の返済督促、早期警告など。
資金管理: ユーザーのリチャージを管理および確認し、ユーザーの出金プロセスを承認します。
セサミ クレジット ポイント: Alipay のインターフェイスに電話をかける、セサミ クレジット: Alipay のインターフェイスに電話をかける (アリペイはこのようなセサミ クレジット サービスを提供し、小切手ごとに約 0.1 元を請求します)
バックグラウンドでユーザーの削除をテストしたい場合、ユーザー名の後ろにある削除ボタンの場合、どのようなテストケースを書くことができますか
ユーザーを削除するシナリオ: 削除ボタンをクリックすると、ページが自動的に更新され、このページでユーザーを照会できなくなります。次に、別のブラウザーを開き、削除されたユーザーをフォアグラウンドでログインすると、ユーザーが存在しないことを示すプロンプトがページに表示されます。
複数のユーザーを同時に削除するシナリオ: チェック ボックスを使用して、複数の選択をテストし、選択を逆にして、すべてのユーザーを削除します。削除後、このページで削除されたユーザーを照会することはできません。また、フロント デスクに移動して削除されたユーザーにログインすると、ユーザーが存在しないことを示すページが表示されます。
JD にショッピング ページがあるとしたら、どのようにテストしますか? どの主要機能がテストされていますか?
まず要件分析を行い、xmind を使用してテスト ポイントを整理し、ケースを書き、ケースをレビューして他の人の意見を求めます。次に、ケースを改善し、他の人が確認できるように送信します。
テストポイントは、まずUIの側面である美学、そして操作のしやすさや分かりやすさが試されます。
次に、彼の機能ポイントを検討し、登録してログインし、ショッピング カートを追加し、注文し、支払い、発送し、受領を確認し、評価します。支払い時の拘束力のある銀行カード、実名認証もあります
パフォーマンスに関しては、ウェブページを開く、注文を確認する、支払いの応答時間などです。
互換性: 360、Firefox、Google など、さまざまな主流のブラウザーをサポートします。
ショッピングカートの追加のテストポイントについて、「ショッピングカートの追加」をテストする方法を教えてください
（追加・削除・修正・確認の角度）
ショッピングカートに追加できるかどうか、同じ商品を再度ショッピングカートに追加できるかどうか。
ショッピングカートの商品数の上限（タオバオ限定100個）
ショッピング カートでアイテムを正常に削除できるかどうか、削除後にアイテムを再び追加できるかどうか。
追加された各商品の数量が正常に増減できるかどうか、および数量が 0 より大きいかどうか
ショッピングカートを終了し、再度ショッピングカートを確認すると、商品は正常です。
ショッピングカート内のアイテムは、選択、選択解除、または二重選択することができ、選択したアイテムと数量を通常どおりに配置できます。
製品がショッピング カートに追加された後、棚から削除されました。ショッピング カートに、この赤ちゃんの有効期限が切れたことが表示されます。
製品がショッピング カートに追加されると、価格が引き下げられ、ショッピング カートに価格引き下げのリマインダーが表示されます。
商品をショッピングカートに追加した後、在庫が少なくなっています。
通常、P2P 機能のテストは何回行いますか?
答え：
中規模バージョン (メジャー リビジョン、オンラインで月 1 回): テストは通常 2 ラウンドに分けられます: 1 回目: 5 日、2 回目: 3 日、回帰テスト 2 日 (合計 10 営業日) ）。(月に 22 営業日、要件の分析とレビュー、テスト ケースの作成などに、通常、バージョン全体の半分、または数日少ない時間がかかります)
小規模バージョン (軽微な変更、2 週間に 1 回): 一連のテストに 3 日間、回帰テストに 2 日間。
話し合う会議が開かれるたびに、10 人以上の開発者が会議に出席しますか?
ケース レビュー ミーティング: 一般的な開発とテスト、およびプロダクト マネージャーが出席します。（開発グループマネージャーも参加可能） 要件検討会：プロジェクトマネージャー、開発グループマネージャー、プロダクトマネージャー、テスト、開発が主に来ます。
それが私たちのテストグループミーティングである場合、私たちは通常出席しなければならず、すべてのテスト同僚が自分の経験を報告し、進捗状況と問題を報告します。
データベース ルックアップ 2 つのテーブル
回答のアイデア:
複数テーブル クエリ、後で学習します: テーブル 1、テーブル 2 から列 1、列 2 を選択します。ここで、テーブル 1. 列 = テーブル 2. 列 この形式はそれを言うことができなければなりません。
データベースに精通していますか？普段データベースをよく利用しますか。
データベースに精通していますか: DML ステートメントの追加、削除、変更、クエリなど、比較的詳しい: (順番に発言してください)
1 テーブル名の値に挿入 (値 1、値 2、値 3、...)
2 テーブル名 where 条件から削除
3 update table name set column name = new value
4 テーブル名から*を選択
最長のクエリ ステートメントは select * from table name です。ここで、条件は列名でグループ化され、条件は列名でグループ化されます。
通常、データベースをよく使用しますか (テスト プロセスの約 1/4 はデータベースのチェックに費やされます): 大丈夫です.通常、問題が発生した場合、バグに遭遇した場合は、データベースにクエリを実行する必要があります。がまず問題と判断されます。開発により、データベース テーブル設計用の Excel (データ ディクショナリ) が提供されます。これには、テーブル名とテーブル内のフィールドが記述されています。データをクエリする条件として、トランザクション プロセスのいくつかの一意の識別子を使用します。予備分析の後、問題は開発にさらされます。(たとえば、タオバオが支払いを行うとき、支払いパスワードを入力した後、支払いが成功したというプロンプト メッセージが返され、インターフェースの注文クエリはまだ支払いを保留中です。このとき、 order テーブルを作成し、作成したトランザクションの一部を見つけます。order、エラーを分析し、それを開発に公開します)
Linux がファイルを表示するために使用するコマンドと、プロセスを表示するために使用するコマンド
答え：
ファイルの内容を表示するコマンドは more less head tail cat tac です
プロセスの表示: ps -ef | grep プロセス番号
ログファイルを表示するためによく使用されます: less、view
ログを表示するためによく使用されるコマンドと、表示される主な内容
ログを表示するには、less コマンドまたは view コマンドを使用します。
主にプログラムの実行記録を確認してください.たとえば、支払いが失敗した場合は、バックグラウンドで.logログファイルにエラーメッセージが出力され、ログ情報を分析することで問題を事前に判断できます. （補足：データベースへのクエリ、注文データの分析、支払い状況の確認なども）
PS: ログは、.txt のようなテキスト ファイルに属する .log のテキスト ファイルです。vi または vim エディターはメモ帳ソフトウェアであり、通常、ログの表示には使用されません。
.log ログ ファイルのエラー文字列を見つける方法
最初の方法: (最初の方法を言うことをお勧めします)
猫 a.log | grep エラー;
2 番目の方法:
1 つ少ない a.log;
2 /エラー;
使い慣れた Linux コマンド
Linux：猫、もっと、少ない、頭-n、尾-n、見つける、| grep,ps -ef,tar,gzip,mv,cp,touch,mkdir，vi,top
また、環境を構築するプロセスで使用されるコマンドについて話すこともできます。
テスト用のテスト環境を提供したのは誰ですか? Linux はどのようにテスト環境を構築しますか?
一般的な開発と構築ですが、以前に自分で小さなプロジェクトを構築したこともあります (Songqin の学生は、試験システムの構築プロセスを参照してください)。
プロセスはおそらく次のとおりです。
最初のビルド:
winscp を使用して、Tomcat、MySQL インストール パッケージ、JDK (Java 開発環境キット) を Linux にアップロードします。
tar -zxvf 解凍パッケージ コマンドを使用して、jdk、tomcat、および mysql を解凍してインストールし、jdk 環境変数を構成します。
war パッケージ (Web プログラム) を tomcate の指定したディレクトリ webapps の下に置き、サーバーを起動します。(startup.sh のパスを入力し、Enter キーを押して実行します)
初めてビルドされていない:
tomcate の指定ディレクトリ webapps 配下に war パッケージ (web プログラム) を置き (web サーバーとデータベースサーバーが存在する前提で)、サーバーを起動します。(startup.sh のパスを入力し、Enter キーを押して実行します)
パケット キャプチャ ツールは以下を使用します。
つまり、フィドラー ツールを開いた後、ブラウザーに移動して Web ページを開くと、フィドラーは自動的にパケットをキャプチャし、要求応答データをキャプチャします。ローカル プロキシとして自動的に設定され、https プロトコルのパッケージをキャプチャするように設定することもできます。
携帯電話をつかんでインターネット データ パケットにアクセスする場合は、携帯電話のネットワーク設定でプロキシ サーバーを設定する必要があります。fiddler をプロキシ サーバーとして使用することであり (fiddler 自体がリモート接続をサポートするように設定する必要があります)、携帯電話は fiddler ツールに接続されているため、携帯電話のプロキシ サーバーの設定ページでは、使用するコンピューターの IP アドレスを入力する必要があります。フィドラーツールとフィドラーのポート番号8888を開き、携帯電話がフィドラーに接続し、フィドラーを介してインターネットにアクセスできるようにします。
PS: すべてのブラウザには独自のパケット キャプチャ ツールがあります. F12 ショートカット キーでこのツールを呼び出すことができます. 開発者はこのツールを使用してページ データを分析し、ページ データを分析してプログラムの問題を特定します.
金融業界についてどれだけ知っていますか
次の教師によってまとめられた理解を覚えておいてください。
リーダーが過負荷のタスクを割り当て、リーダーがあなたの能力を過大評価した場合、どうすればよいですか?
回答のアイデア:
まず第一に、あなたの態度を表明し、態度を完成させるために残業することをいとわない. また、テストの同僚にサポートを依頼し、チームリーダーに調整させることもできます.
過大評価された能力、能力は職場での自分の努力によってリーダーシップの要件を満たすことができます
全体として、基本的な考え方は正しい姿勢を持つことです。
タスクを直接拒否することはできません。でも同時に、上手く出来ないならリーダーに寛容になってほしいとも言いました。
あなたがチーム リーダーで、チーム内の 1 人の従業員が提供されたタスクを時間どおりに完了できない場合、どのように対処しますか。
回答のアイデア:
まず、タスクの配置が従業員の能力を超えていないかどうかを確認します。
そうでない場合は、まず自分の体や状態について懸念を表明し、タスクが間に合わなかった理由を理解し、その理由が客観的なものである場合は、スタッフと一緒に残業してタスクを完了します。
態度が原因の場合は、問題を指摘し、残業を命じます。
自分のミスが原因で職場で何か問題が発生した場合、あなたはどうしますか?
回答のアイデア:
まず第一に、私の仕事に対する姿勢は今でも非常に正しいので、私の過去の仕事で同じようなことは一度も起きていないことを表明しなければなりません。
自分のミスで仕事上の問題が発生した場合は、まずリーダーに問題を報告し、問題の影響を最小限に抑えるように努めてください。
モジュールテストが与えられた場合、どうすればそれをわずか 1 週間で効率的に完了することができますか?
回答: 限られた時間の中で、要件が明確になったら、作業計画を策定し、日常業務を細分化し、重要な機能を最初に確保し、修復状況をフォローアップし、バグを検証します。進捗状況を報告する作業日報を発行し、危険があれば適時にリーダーに報告する。
要件のないアプリ テスト プロジェクトが与えられた場合、どのようにテストする必要がありますか?
教師の提案: APP の 11 の主要なテスト ポイントによると:
許可テスト
テストのインストール、実行、アンインストール
UI テスト
機能テスト
性能試験
割り込みテスト
互換性テスト
安全性試験
回帰試験
アップグレード更新テスト
ユーザー エクスペリエンス テスト
補足：自分の経験に基づいてテスト計画を立て、毎日進捗を報告し、毎日のテストレポートを発行してください。
テスト プロセスで問題が発生した場合は、適時に報告し、適時にバグを追跡し、開発者とさらにコミュニケーションを取り、要件を明確にします。
あなたと開発者の間の意見の相違にどのように対処しますか?
回答のアイデア:
大原則は、人ではなく物を扱うことです。
また、まずは開発の観点から相手の意見や提案を受け入れると同時に、自分の感情をコントロールし、相手の感情がコントロールできるようになったら意見を言います。
チーム リーダーのユース ケースが間違っていても、彼は正しいと考えている場合、どのように対処しますか?
答え：
通常、リーダーは私たちよりも包括的な視点から問題を見るので、リーダーのユースケースでは考慮できないことが実際にあることを最初に確認する必要があります。
自分が正しいと主張するつもりはありません。
あなたは機能とパフォーマンスの両方に責任があります。
機能をテストして機能の完成を確認してから、パフォーマンスを行います.バグを提出した後、開発が改善されていない場合は、パフォーマンステストの準備をすることができます.作業時間が厳しい場合は、残業への取り組み
当社の自動テストで使用している言語はJavaですが、Javaがわからない場合はどうすればよいですか？
回答のアイデア:
できないことについての標準的な考え方: 関連するコンテンツを少し知っていると言うか、学習能力が高く、学習意欲と態度が優れていると表現します。
Java を学んだ後、オブジェクト指向のカプセル化、継承、ポリモーフィズム、マルチスレッドを作成する 2 つの方法 (カスタム サブクラスが Thread クラスを継承するか、カスタム サブクラスが Runable インターフェイスを実装するか) を理解し、例外についても理解しています。例外形式です。最後にキャッチしてみてください。ノウリスト、セット、マップ集。Java で自動化を行う方法をすぐに学ぶことができます。
以前のプロジェクトはどのように管理されていましたか?
回答のアイデア:
以前のプロジェクトでは、ZENTAO はテスト要件管理、ユース ケース管理、および欠陥管理に使用されていました。また、バージョン管理ツールはSVNを使用しています。
以前のプロジェクトで 1 日に実行する必要があるユース ケースの数
回答のアイデア:
平常時は1日20件程度のユースケースを実施しているが、テスト開始当初はバグが多く、開発側とのやり取りにかなりの時間を要した
ケースの実行は遅くなります。後ろに行くほど速くなります。
回帰テストを行うとき、それらすべてを行いますか?
時間を見て、時間さえあれば全部戻ってくるし、戻ってくる時は俺の方が操作が上手いので基本的にバグは無い。そのため、ケースの実行速度が速くなります。
時間がない場合は、回帰テストのために重要なモジュールが選択されます。
PS: 自分で言語を整理してください。
ユースケースのカバレッジをどのように保証しますか? 繰り返さないようにしますか？
決定表法の考え方を用いて、まず網羅的に列挙し、次に代表者を選出します。
その後、ケースレビューでは、製品マネージャー、開発チームリーダー、テストチームリーダー、および該当モジュールの開発担当者もチェックして意見を聞き、ケースが完全に網羅されていること、および問題がないことを確認します。冗長なケース。
ソフトウェア テストに興味があり、テストの知識についてさらに学び、テストの問題を解決し、テストで発生した混乱を解決するのに役立つガイダンスを開始したい場合は、ここに技術専門家がいます。就職活動中や学校を卒業したばかりの方、すでに働いているが難しいと感じている方、テストの点数が足りないと感じて勉強を続けたい方、転職したいと思っている方、仕事がうまくいかないことを恐れている方学べない方は、810119819 からグループに参加できます。 大手ソフトウェアテスト会社の最新インタビュー資料や、Python の自動化、インターフェース、フレームワーク構築に関する学習資料を受け取ることができます！
あなたのケースはどのように評価されますか？
レビュー中はプロダクトマネージャー（SR）、テスト担当者、開発担当者がおり、レビュー中はジェネラルプロダクトマネージャー（SR）、テストチームのリーダー、対応するモジュールの開発担当者がコメントします。戻ってケースを修正および補足します。
変更後、2 つの処理状況があります。
大規模なプロジェクトでは、2 回目のケース レビューが必要になる場合があります。
小規模なプロジェクトの場合、時間が限られている場合は通常、2 回目の試行は行われませんが、改訂または追加されたケースは、リーダーが確認できるように電子メールで送信し、コピーを他の同僚に送信する必要があります。(ケース レビューに 0.5 日、ケース修正に 0.5 日、ケース 2 回目のトライアルに 0.5 日)。
ビューとは何ですか?
ビューは SQL ステートメントを記録し、クエリが作成されたときにのみデータが返されます。テーブルは具体的なテーブルです。ビューはデータのクエリのみを実行でき、テーブルは追加、削除、変更、およびクエリを実行できます。
一生懸命働いたのに、上司から割り当てられたタスクをまだ完了していません。どうすればよいですか?
回答のアイデア:
実際、リーダーのお気に入りの従業員は、強力な能力と優れた態度です。リーダーの募集の目的は、彼が問題を解決するのを助けることです。
せっかく頑張ったのに、上司の仕事をやり遂げていないあなたは、その理由を分析する必要があります.もしそれが自分の能力不足のせいなら、意欲を示し、能力を向上させ続けてください.リーダーに期待します.理解することができます。
可能性のあるリーダーがあまりにも多くのタスクを割り当てたことが原因である場合は、自分の能力が限られていること、および自分の能力がプロジェクトの進行に影響を与えたくないことを巧みに表現する必要があります。効率アップの提案。
あなたのキャリアプランは？
まず、ビジネスと環境にすばやく慣れ、率先して調査し、チームリーダー、マネージャーに異動します（自分の努力と安定性を強調してください）。
(機能テストの面接では、自動化してパフォーマンスを向上させたいとは言わないでください。彼は、あなたが不安定になることを恐れており、将来、彼の会社の機能テストを嫌うからです。会社が自動化またはパフォーマンスの使用を検討しない限り、将来の試験技術）
週末に仕事がないときは何をしますか。
時間があれば、自動化、パフォーマンス、python と selenium の自習など、技術的な知識を統合することを学びます。
前の会社から何を学びましたか？
みんなで力を合わせて取り組んだ真面目で整然としたプロジェクトプロセスから、大変な作業でしたが、得たものはたくさんありました。テストの経験、ビジネスへの精通、スキルの向上、チームワークと忍耐の精神を獲得しました。
前の給料で仕事を辞めた理由
インタビュアーはこう言うかもしれません: 真実を教えてください。
（日常的に話すことを選びましょう） まず、仕事の経験を向上させる機会を与えてくれた前の会社に感謝したいと思います. 私が仕事を辞めたい理由は、さまざまな経験を積み、学びたいからです.さらに自分を磨くために。御社は私の要件に非常に適していると思います。
どこに住んでいますか
多くの人が仕事を辞めるとき、遠方に住んでいるという理由で退職を申し込むことが多いため、面接官はあなたが将来不安定になるのを防ぐためにどこに住んでいるかを尋ねるかもしれません.
答え：
遠くに住んでいる学生はどこに住んでいて、仕事は近くにあると言うでしょう。（勤務地から1時間以内の居住地を推奨）
退去時のお給料はいくらですか？
現在の予想給与より500元少ないと言った。
テスト開発とインターフェイスの自動化に注力し、クローラーが取得した希少な高品質のリソースを共有します. WeChat をフォローして、それらを取得してください.
最後に：[役立つチュートリアル]
これらの資料は、[ソフトウェア テスト] を行う友人にとって比較的完成度の高いものである必要があります. この種の学習資料は、最も困難な旅にも同行しました. あなたにも役立つことを願っています! 特にテクノロジー業界では、すべてをできるだけ早く行う必要があり、技術スキルを向上させる必要があります。
上記のソフトウェア テスト データ収集パートナーは、下の小さなカードをクリックできます