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