ことわざにあるように、素人は興奮を見守り、専門家は道を見守ります。
この記事は、テストを受けたばかりの新しい学生や、豊富なテスト経験を持つ古い学生が共有するのに役立つ、非常に価値があると思う私の経験のいくつかを要約することを願って書いています.
私たちの素敵な新しいクラスメート、テスト分野で働くことになるパートナーが、私の記事を通じてテストの根底にあるロジックを理解してくれることを願っています。ユース ケースを作成し、バグを報告し、自動化を開発し、プラットフォームを構築する毎日。
混乱している
テスターは PRD ポーターであってはならず、シニア テスト エンジニアは単にテスト ツールの開発者であってはなりません。
テスターはテストの最も基本的な基礎理論を習得しなければならず、もちろんR&Dコーディング技術も不可欠であり、この2つが欠けると優れたテスターにはなれない、以前はコードを書くのが苦手なテスターが多く、それからテスト; しかし、将来または現在、コードを理解していないテスターが優れたテスターになることは困難ですが、コードのみを理解し、テストの理論的基礎を理解していない人 (テスト分析を理解していない、ユース ケースの設計、テスト戦略など) の人、または何かを知っていても実際の作業で使用しない人) は、資格のあるテスターであってはなりません。
テストの根底にあるロジックとテストの方法のいくつかを理解してもらいましょう。
テスターホーム「2021年テスト業界アンケート調査報告書」による【優秀なテスターが持つべき技術・能力】分析
1. 「プログラミング/スクリプティング/自動化、通信表現、テスト基礎理論」は優秀なテスターの3つのコアコンピタンスと考えられており、他の項目をリードし続けています。
2. データベース、パフォーマンス テスト、セキュリティ テスト、およびビッグ データ アルゴリズムの技術的要件は、2020 年から大幅に増加します。
3 つのコア コンピテンシーは、基本的には誰もが認識しており、安定していますが、近年、新しい技術要件に対する需要が大きく、分析データから、テスターに対する市場の要件は、今後ますます増加することがわかります。ただし、3 つのコア コンピテンシーはテスターの必修コースであり、変化はそれほど大きくなく、常にコアの位置を占めます。
10 年以上前に QTP が始まって以来、自動化されたテストはテスト担当者が追求する目標でした。今日まで、さまざまな自動化テクノロジとフレームワークが目を見張るものでした。市場はテスターに対してますます高度な要件を持っており、テスターはできることだけではありません。自動化のユース ケースを記述するだけでなく、自動化フレームワーク プラットフォームを開発および維持する能力も必要です。純粋なブラック ボックスのテスターは、機能のアップグレードを完了しているか、アップグレードの途中です。完全に依存する人はますます少なくなっています。仕事を完成させるためのブラックボックステスト ユースケースやプログラミング言語を理解していない場合、職務経歴書の合格は難しいと予想されます。
しかし、テスターのコード能力はどんどん強くなっているのに、テストの基本的な能力は無視され、テストの分野での専門的な能力は徐々に弱まっているという、流れに逆らうように、前進しなければ後退する。3 つのコア機能は連携する必要がある。
私は長年にわたり、この部門で多くの採用面接に参加してきました.多くのテスターは長年働いていますが、テストケースの設計方法と戦略を十分に理解していない.少なくとも60%のテスターはそうではないと感じています.ユースケース設計で何を使うべきかを知っている. ユースケース設計法は, テスト分析や設計をどのように行うかを考えない. 彼らのほとんどは機能テストの実行者にすぎない. 彼らはテスト設計についてほとんど考えず, テスト計画を書く人はほとんどいない.テスト ケースは PRD の分割にすぎません。要するに、テスターは注意しないと PRD ポーターになってしまいます。
古いテスターとして、私はまだテスト業界が健全に発展することを願っています. 新しいスキルの向上により, テストのプロ意識も時代に追いつくことができます. 結局, 品質保証はテスターの基盤です.
ブラックボックステストとは？
プログラムをブラックボックスと見なし、プログラムの機能が PRD 規定に従って正常に使用されているか、プログラムが入力データを正しく受け取り、プログラムの内部構造を考慮せずに正しい出力を生成できるかをチェックします。
これは、実際にはブラックボックス テストの定義であり、ブラック ボックス テストの根底にあるロジックです。ほとんどの人は定義に注意を払いませんが、定義はしばしば真実を教えてくれます。
職場の多くの人は、あるタイプのシステム テストに慣れていて、その後新しいタイプのビジネスに切り替えると、突然、どのように開始すればよいかわからなくなります。おそらく、常に新しいものに適応する時期があります。実際、すべてのブラックボックステストの根底にあるロジックをマスターすることで、適応や調整をせずにすぐに始めることができる限り、同じです。
ほとんどがブラックボックステストなので、どのようなシステムであっても、「プログラムがPRDに従って正常に動作するか、プログラムが入力データを正しく受け取り、正しい出力を生成できるかをチェックする」というのがテストプランです。 .
私たちのテストは PRD に基づいています.まず第一に、PRD をよく理解し、次にその入力と出力を分析する必要があります.これらはすべてカバーされており、基本的に 80 点を達成することができます.つまり、このプロジェクトに勝ちました.問題ない。
最後に、もう一度強調したいのは、私が言ったことをまだ誰もが理解していないのではないかと心配しているためです. 初日のテストを理解すれば、ブラックボックステスト入力と出力とは何ですか; しかし、多くの場合、真実は普通の中に隠されています, 彼の定義を思い出してください! ! !
プロジェクトに遭遇し、テストを開始する方法がわからない場合は、定義を取り出して 3 回注意深く読んでください。答えが必ず見つかります。! !
強調: 実際には、純粋なブラック ボックスは多くありません. 入力と出力を理解することに加えて、中間処理ロジックも明確にする必要があります, これはテストに役立ちます. さらに重要なことは: PRD に精通しており、PRD に精通している必要があります. コンテンツ分析は完全であり、テキストまたは単語の段落が欠落していません. 実際、PRD と設計ドキュメントには、掘り下げるのを待っている多くの抜け穴があります。
【入出力テストモデル】
【入力】: ここでの入力は、インターフェイス上の単純な入力ボックスではなく、システムの実行をトリガーできるすべての入力が入力です。
コード構造の階層化に従って、入力は次のように分類することもできます。
1. インターフェイス操作の入力:
フォワード操作:
1) 単一操作:
・通常操作：入力ボックス、ボタン、ラジオチェックボックス、ボタン、ドロップダウンボックスなどの特定の操作 異常操作：入力ボックスの異常値、長入力など、ボタンの複数回クリック、素早い連続クリック(非常に速い) データの繰り返し送信、システムの応答の遅さなど、さまざまな問題を見つけやすく、これが原因でシステムがクラッシュする可能性があります)
2) 複雑な操作:
・複合運用：システム全体の機能はさまざまな運用の組み合わせであり、もうひとつはビジネスシナリオに関連するもので、さまざまなビジネスシナリオを組み合わせて同時に運用する。
• 並列操作: 複数の人が同じファンクション ポイントで同時に操作するか、2 人が同時に単価を変更または削除するなど、複数の人が同じデータを操作します。
逆の操作:
3) 逆操作:
• ロールバック操作: ブラウザまたは APP を介したロールバック操作 キャンセル操作: 通常の操作が突然キャンセルされた場合、たとえば、ユーザーが大量のフォームに入力し、突然キャンセルした場合. 保存またはプロンプトが必要ですか? 削除操作: システムが提供する機能を使用してデータを削除します。
次の入力は無視するのが最も簡単です。
2. サービス層の入力:
• インターフェイス サービス: 外部に提供されるインターフェイスも、システムにとって非常に一般的な入力であり、この入力も最も問題が発生しやすいものです。
・ファイルのアップロード：一部のシステム機能は、ftpサーバー上のExcelやxmlなどのファイルを取得してシステムを起動するため、このときの入力はファイルになります。
•MQ メッセージ: JD の最も一般的な入力形式でもあります.MQ にはファイル アドレスなども含まれる場合があり、この入力がより柔軟になります。
強調：
• インターフェイスの入力上流では、形式に関係なく、上流データの各フィールドを分析して、さまざまな上流入力の可能性を理解する必要があります。
• 一部のフィールドについては、このフィールドの意味、可能な列挙値、可能な結果などをビジネスから理解する必要があります [ソース]。
• さらに、歴史的な理由により、ソース データには想像を絶するさまざまなデータが含まれている可能性があります。
•入力の分析には非常に重要です。この時点で、[同等のクラス] メソッドを分析に使用できます。
3. データ層の入力:
• データの変更: 新しいデータの挿入や削除などがあるかどうかを監視する多くのバックグラウンド処理タスクがあります。データベースへの変更。そのうちのいくつかは、キャッシュされたデータ変更の時間の変更です。時間指定されたタスクは、データの入力だけでなく、時間でもあります。
【出力】：出力は可視出力と不可視出力に分けられる
目に見える出力: これは、私たちの共通のシステム操作のフィードバック、ユーザーが直接見ることができる変更です; 箇条書きボックス、プロンプト、ジャンプ、データの追加、変更、および削除後の変更、操作の変更後の写真、ビデオなど。
目に見えない出力: 目に見えない出力は無視するのが最も簡単で、最も問題があります; [見えない出力] には、データベースの変更、キャッシュの変更、システム ファイルの変更、ダウンストリーム インターフェイスに送信されたデータなどが含まれます。
[目に見える出力] 機能の 90% 以上を検証するのに役立ちますが、インターフェイスを介して表示されるデータは、新しい追加が成功したか正しい変更であるかにかかわらず、追加または変更したデータを検証することもできます。その一部が表示されます; 表示されない多くのフィールドがあり、一部は下流または他のシステムでのみ使用される可能性があり、一部は将来の使用のために予約されている可能性があります. これらの目に見えない部分はしばしばシステム例外を引き起こします. それは隠された最大の穴でもあります.システムで;
したがって、テストはユーザーの視点からシステムをテストするだけでなく、設計者の視点からもテストする必要があり、製品全体の視点からも検討する必要があります。
テストの分析と設計に関しては、これがテスターの核となる能力だと思います。
上記のブラックボックステストや入出力モデルはあくまで機能テストの手法であり、機能テストは一般的なシステムテストの80%～90%程度を占めていますが、全てではありません。そして、それはテストの 1 つの段階と 1 つのタイプにすぎません. 良いテストを行うためには、テストの分析と設計が不可欠です.
質問について考えることができます: プロジェクトを取得したときにどのようにテストしますか? 品質を確保するには？
インタビュー中に多くの人が私に与えた答えは、要件を分析し、ユースケースを書き、テストを実行し、レポートを送信することでした.テストと分析を行うことは、システムの品質を保証するものではありません.
プロジェクトをどのようにテストしますか?
5W2H方式で解析できますが、実はテストアーキテクトとしては5Wも3Wも必要なく、2W+1Hで十分！
この 2W+1H が最も重要であり、経験に置き換えられて無視されるのが最も簡単でもあるため、製品の形状とシステムの構造により、日常のテスト作業は基本的に固定されているため、ー 様へとととのえますプロジェクトのことを考える必要がなくなり、基本的には経験をもとに、違うシステムや新しいビジネスに出くわすとすぐに動き出します、どうやって始めればいいのかわからない現時点では、2W1H分析方法がこの問題を解決するのに役立ちます。
テスト アーキテクトは、次の 3 つの質問 (2W+1H) について考えるだけで済みます。
1.なぜ？なぜこのプロジェクトを行うのですか？プロジェクトの背景は？——理由がわかってこそ、ユーザーが何を求めているかがわかります。
2. 何？このプロジェクトでは何をテストする必要がありますか? テストの範囲は？——スコープが明確な場合にのみ、テストを逃すことはありません。
3. どのように? このプロジェクトをどのように測定しますか? どのようなテスト戦略、テスト方法を使用する必要がありますか? ——これは、テストには戦略と方法が必要であることを示しています
テスト リーダー (および場合によってはテスト アーキテクト) が判断するために、さらに 2 つの質問があります。
4. いつ? プロジェクトの完了予定時刻は?
5. 誰が? どのリソースを呼び出すことができますか?
プロジェクト マネージャーが考慮する必要があるその他の 2 つの質問: (テスト リーダーも考慮する必要がある 2 つの質問)
6. どこ？一元化して閉鎖する必要がありますか? また、研究開発とテストのために一緒に座る必要がありますか?
テスターは、テストする必要がある環境についても考えることができますか? テスト環境？発売前の環境？オンライン環境？ウィンドウズ環境？リナックス環境？ios環境？アンドロイド？何のブラウザ？どのバージョンなど
7.いくら？このプロジェクトの費用はいくらですか? 工数は何日必要ですか？どのくらいのサーバー リソースが必要ですか?
テストの分析と設計の根底にあるロジックは、2W1H の 3 つの質問にどのように答えるかです。
テスト分析を実施し、プロジェクトの [背景] を理解し、テストの [スコープ] を確認するために、なぜ、そして何が私たちを導くことができるか。
どのように私たちをテスト設計に導き、プロジェクトの背景とテスト範囲に従ってテストの[戦略]を決定することができますか.
ただ、現在はまだ方法論の話で具体的な操作手順はまだ話されていませんが、この部分は内容が多いので記事で詳しく説明できますし、自分で学ぶこともできます。は HTSM ヒューリスティック テスト戦略モデルで、このモデルは 2W+1H にちょうど対応します。
テスターとして、「コミュニケーションや表現などのソフトスキル」は、優秀なテスターの3つのコアコンピタンスの1つと考えられています。
上記の統計によると、90％以上の人々が承認されています。以前の結論のいくつかを共有させてください。
1.積極的なコミュニケーション
ECの分野は変化が速いという特徴があり、ニーズやプロジェクトによっては立ち上げを急がなければならないことも多く、PRDでは時間が短いため、ロジックに抜け穴があったり、まったく考えられていなかったりすることがあります。 、どのようにテストする必要がありますか？現時点では、コミュニケーションが必要です. いつでも製品と要件を伝達し、いつでも開発と設計を伝達し、いつでも共同デバッグのために他のシステムと伝達できます. コミュニケーションがなければ、プロジェクトの落とし穴は簡単に見逃されます. 製品探し、研究開発、テストなど、コミュニケーションも積極的に行う必要があり、自分が上司であり、プロジェクトの品質は基本的に保証されています.ボススタッフ。
2. 自分の基準を持つ
システム テストの最も基本的な基礎は要件仕様です。テスト担当者として、私たちは最後の保証です。テストには独自の分析が必要であり、R&D のアイデアに簡単に従うことはできません。なぜなら、彼があなたに言ったことはすでに彼らによって処理されているからです。すでに元の要件から逸脱している可能性がありますが、ここにテストの価値があります。彼らの言うことが99%正しかったとしても、それは分析の材料としてしか使えないので、要求を通じて自分たちで分析しなければなりません。
3. 何事にも懐疑的
要件はテストの根拠ですが、その根拠が間違っていることもあるため、PRD に対しても懐疑的な態度を取らなければなりません。テストとは、すべてを疑うことであり、すべてのプロセスの詳細をすべて疑うことであり、要件を見たとき、基本的に彼が正しいと最初に仮定します.全体をある程度理解した後、プロセスが完全であるかどうかを疑い始めます.・抜け穴はないか・モジュールの機能はユーザーの要求を満たしているか・異常動作の問題はないか・ユーザーは使い方を知っているか この機能は実際に顧客の問題を解決しますか? これらの質問は、当社の品質基準、テスト戦略、およびテスト経験のいくつかを通して疑われ、考えられる可能性があります。要するに、すべての機能をテストするときは「よく考えて」ください。
4. 会社とユーザーの視点で考える
会社が大きくなればなるほど部署が増えてシステムが複雑化する、相互依存性が高いほど問題が発生する可能性が高くなる、境界が増えるためコミュニケーションのコストが高くなる、などの点が多くなります。コミュニケーションが整っていない場合、または考慮されていない場合、または相手に責任があると全員が考えている場合、落とし穴が発生します; もちろん、そのような落とし穴のほとんどは共同デバッグテスト段階で発見されますが、テストの進行に大きな影響を与え、逆作業、遅延、その他のリスクを引き起こすことがよくあります。
これらの落とし穴がテスト フェーズで見つかる場合は、メイン テストが必要ですが、メイン テストは人ではなく、すべてのテスターが「メイン テスト」であるべきだと思います。
ソフトウェア品質の最終ゲートキーパーであるテスターとして、自分の担当部分だけに集中するのではなく、自分の部門やチームに限定するのではなく、システム全体に疑問がある限り、全員が責任を負うべきです。それらを提起し、それらを解決するために誰かを見つけます。
テストは部品だけでなく、全体の状況を見て、会社とユーザーの視点で考えてテストする必要があります。
要約する
上記は主に私の経験の一部とテストのいくつかのポイントを要約したものであり、不足がある場合や十分に包括的でない場合は、さらに追加していただければ幸いです。
今後も、私が非常に重要だと考える HTSM モデルと、非常に重要だと考える等価クラス分割、シナリオ テスト、遺伝子テスト、探索的テストのいくつかの優れた方法などを引き続き共有していきます。
要するに、共有するための私の貴重な経験のいくつかを共有したいと思います.
最後に: 以下の完全なソフトウェア テスト ビデオ学習チュートリアルが整理されてアップロードされました。友人は必要に応じて無料で入手できます。【保证100%免费】
これらの資料は、[ソフトウェア テスト] の友人のための最も包括的で完全な準備倉庫である必要があります. この倉庫はまた、最も困難な旅を通して何万人ものテスト エンジニアに同行しています. それがあなたにも役立つことを願っています!
软件测试技术交流群社：786229024（里面还有工作内推机会，毕竟我们是关系社会。）ソフトウェア テスト インタビュー ドキュメント
私たちは高給の仕事を見つけるために勉強しなければなりません. 次のインタビューの質問は、アリ、テンセント、バイトなどの一流のインターネット企業からの最新のインタビュー資料であり、一部のバイトのボスは信頼できる回答を提供しています. このセットを終了する インタビュー資料誰もが満足のいく仕事を見つけることができると信じています。
面接書類の入手方法：
