ソフトウェアテストエンジニアのスキルツリーについて語る

ソフトウェアテストエンジニアは歴史の長いポジションであり、ソフトウェア開発業界からソフトウェアテストエンジニアの役割が始まったと言えます。時代の発展に伴い、ソフトウェアテストエンジニアの役割と責任も、初期のウォーターフォール開発プロセスにおけるテスト段階の実行者としての役割から、アジャイル開発における QA (品質保証) の役割へと静かに変化しています。プロセス、チーム全体と製品の品質に責任を持ち、テスト エンジニアの責任と境界は拡大し続けています。近年、インターネット業界の多くのテストエンジニアはテスト開発エンジニア、つまり自動テストやテストツールを開発する能力を持つテストエンジニアと呼ばれており、テストエンジニアに対する要求は新たな高みに達していると言えます。

テスト作業を経験した学生は理解が深まると思います.ウォーターフォールモードであろうとアジャイルモードであろうと,テスト担当者の仕事は製品リリースの最終段階で常に圧迫されます.チーム全体のプレッシャーは.テスト エンジニア. 開発プロセスの遅延を無視する人は誰もいません, それは過ぎ去ったものであり、遡及会議中に議論される可能性があるためです. しかし、現時点で最も重要な問題は、製品のリリースを完了することです. したがって、テスト エンジニアが必要とするスキルを探す前に、テスト エンジニアの中心的な問題は何かを把握する必要があります。

テスト エンジニアが直面する主要な質問

最小の投資で製品の品質を最大化する方法

誰もがこの疑問を抱いたことがあると思いますが、商業社会が追求するのは効率、さらには究極の効率です。テストエンジニア、QA、または高レベルのテスト開発エンジニアと呼ばれるかどうかにかかわらず、テストエンジニアも例外ではありません。最大限に。現実的に言えば、あなたの給与レベルは、この核となる問題を解決する能力に依存します。私たちは目標を明確にしており、必要な機能もこの目標に沿って設定されています。

概要

 

著者の経験と理解によると、ソフトウェア テスト エンジニアには次のスキルが必要です。

• テスト設計機能
• コード能力
• 自動試験技術
• 品質プロセス管理
• 業界の技術知識
• データベース
• ビジネス知識

テスト設計

テスト エンジニアとして最も基本的な能力は、製品に基づいてテスト ケースを設計する能力です。最も基本的な能力は、多くの場合、習得するのが最も困難です。優れたテスト ケースを設計するには、製品の特性とビジネスを熟知し、ユーザーの使用シナリオを体系的に考える必要があります。さらに、経験や制約のないアイデアに基づいてユース ケースを設計するだけでなく、標準化されたユース ケースを設計するのに役立つ科学的なテスト ケース設計手法がいくつかあります。業界には、テスト エンジニアが習得する必要のある古典的なテスト ケース設計手法がいくつかあります。

• 境界値解析
• 同等クラス区分
• 因果図
• 判定表
• 直交実験計画

上記の方法はドグマではなく、テスト ケース設計の考え方を明確にし、効率を向上させるためのツールです。

コード能力

従来の考え方では、テスターのコード能力に対する要件はそれほど高くないように思われます。これは業界でも実際に当てはまります。多くのテスト エンジニアは、基本的にコーディングする能力がなく、より多くのテスト実行者です。しかし、今日の時代、従来の機能テスターの限界を突破するには、コーディング能力が必須です。コード能力を持つテスト エンジニアには、次の 2 つの利点があります。

開発コードを読む

開発コードを読む能力があれば、テスターの効率を向上させるのに非常に役立ちます。

• コードの開発と変更による影響の範囲、つまりテストの範囲を見積もる
• テクニカル レビューに参加し、テストのリスク、難しさ、およびキー ポイントを評価します。
• コード ロジックを介してテスト ケースを設計し、テスト ケースのカバレッジを強化します。
• 欠陥の予備的な位置決め

実際、できることはまだたくさんあり、それらはテスト プロセスの多くの詳細に反映されています。

自動テストの開発

自動テストは、テスト開発の方向性であり、効率を改善する効果的な方法です。コーディングできるため、さまざまな一般的な自動テスト フレームワークやユース ケース開発を簡単に制御できます。

自動テスト

自動テストに関する上記の説明をフォローアップしてください。現在の人気企業の採用において、自動化能力はすでに必要な能力であり、誰もが注目する領域でもあります。現在、自動テストは次のカテゴリに大別できます。

UIの自動化

UI 自動化の目標は、製品の UI インターフェイスで人間の操作をシミュレートして、結果を観察してテストの実行を完了することです。UIの自動化は、クライアントの形からPC側とモバイル側の自動テストに分けることもできます. マスターする必要があるいくつかの有名な自動化ツールがあります:

セレン

Selenium は、Web サイド製品の古典的な UI 自動化ツールであり、さまざまな開発言語を適切にサポートしています。その原則は、スクリプトによって生成された操作命令を WebDriver を介してブラウザに渡し、必要な操作を実行して対応するフィードバックを取得し、スクリプトで検証を完了することです。

アピウス

名前から、このツールと Selenium の類似性がわかります。実際、Appium はモバイル側の Selenium として理解できます。また、モバイル端末で人間の操作をシミュレートしてテストケースを実行する目的もあります。モバイルインターネット時代の到来により、より多くのサービスがPCのWEB側からモバイル側に移され、モバイル側の自動テストはますます重要になっています。

実際、UI オートメーションの原則は非常に似ており、基本的なロジックは次のとおりです。

1. 位置決め要素
2. 操作要素
3. 反応を得ます

最後に、テスト ケースは、python の unittest、JAVA の TestNG、Ruby の respec など、ある種のテスト ケース フレームワークを通じて管理されます。したがって、特定の UI 自動化フレームワークとツールを理解していれば、新しいフレームワークとツールを類推して簡単に学習できます。

インターフェースの自動化

SaaSが主流となった現在、API、つまりインターフェースはビジネスを支える中核的な部分になっています。フロントエンド ページやアプリ内の業務データは、さまざまな API を介してサーバーと通信し、業務機能を実現します。現在、ほとんどのインターフェースは HTTP プロトコルに基づいており、その中で Restful インターフェースが大部分を占めています。また、Python や Ruby などの多くの言語には、HTTP プロトコル リクエストをサポートする優れたライブラリがあり、インターフェイスの自動化を設計するための優れた基盤を提供します。中心的な質問である入出力比の測定に戻ります。UI の自動化は、実装コストと保守コストの両方の点で膨大であるため、業界はインターフェイス レイヤーの自動化にますます注目しています。インターフェースの自動化には、次の利点があります。

• 高い作業効率
• 低開発コスト
• 低メンテナンスコスト
• 開発コードと同時に開発可能

インターフェースの自動化の実装のアイデアもシンプルで明確です。つまり、ブラウザーをシミュレートし、HTTP 要求を送信してインターフェースへの呼び出しを実現し、戻り値を期待値と比較して、検証の目的を達成します。結果。もちろん、真に効率的なインターフェイス自動化フレームワークを設計するのは簡単ではありません。これには、ユースケースの開発効率を改善し、開発および保守コストを削減する方法などの重要な問題が含まれます。同時に、インターフェイス テストとパフォーマンス テストを組み合わせて、インターフェイス自動化テストの内容を充実させることができます。

品質管理プロセス

アジャイル開発プロセスにおいて、テスト エンジニアには、品質保証エンジニアという新しい定義があります。テストの実行は責任の一部にすぎず、さらに重要なことに、チーム全体の製品品質に対する責任があります。スプリント サイクル全体の観点から、QA エンジニアは一貫して品質保証の意識を実装する必要があり、開発との関係は、早期のバグ発見から、開発チームが製品の品質を一緒に改善するのを支援する方法に変わりました。同時に、製品チームと緊密に連携し、要件分析段階に介入して、製品リリース前のテスト実行段階に介入するのではなく、品質保証業務がどのように計画および設計されているかを分析することも必要です。これには、チームとの連携方法、コミュニケーション方法など、多くのソフトスキル要件も含まれており、これもアジャイル開発モデルの鍵の 1 つです。

業界の技術知識

コンテンツのこの部分は、実際には非常に豊富なコンテンツをカバーしています。インターネット業界を例に取りましょう。インターネット製品の場合、テストエンジニアは、フロントエンドページの技術スタック、API設計、バックエンドサーバー設計、後述するデータベース、サービスアーキテクチャ全体など、多くの知識を知っているか、習得する必要があります。テストエンジニアは理解する必要があります。この問題に対応して、関連する知識を整理するのに役立つ非常に優れた質問があります。

ブラウザーの入力ボックスに URL を入力してから Web ページのコンテンツを表示するまで、このプロセスでは何が行われたのでしょうか。

この質問への回答の深さと幅は、基本的に、テスト エンジニアのインターネット製品テクノロジの把握を反映している可能性があります。ここでは、製品をテストするのに非常に役立つ、関連するテクノロジと概念の一部を簡単にリストします。

• DNS
• TCP/IP
• HTTP
• SSL
• 安らかな
• HTML
• ドム
• CSS
• 与える
• Xpath
• サーバ
• nginx
• SQL
• クッキー&セッション
• ここでは、XSS、CSRF は一部のコンテンツにのみ関与しており、特定のコンテンツは、作業で遭遇するシナリオに従って詳細に調査および理解できます。

データベース

データベースが個別にリストされている理由は、データベースの知識が今日の多くの製品にとって非常に重要であるためです。手動テストでも自動テストでも、データベースにアクセスしてデータを検証する必要がある場合があります。現在使用されているデータベースは、次の 2 つのカテゴリに分類できます。

• リレーショナル データベース
• 非リレーショナル データベース

リレーショナル データベース

リレーショナル データベースは、最も一般的なタイプのデータベースで、SQL Server、MySQL などの RDBMS データベース プログラムによって管理および使用されます。リレーショナル データベースでは、トランザクション (Transaction) の概念が強調されます。いわゆるトランザクションとは、ユーザーが定義する一連のデータベース操作であり、これらの操作はすべて実行されるか、まったく実行されないかのいずれかであり、切り離すことのできない作業単位です。たとえば、リレーショナル データベースでは、トランザクションは SQL ステートメント、一連の SQL ステートメント、またはプログラム全体である可能性があります。トランザクションには、原子性、一貫性、分離、耐久性の 4 つの属性が必要です。これら 4 つのプロパティは、ACID プロパティと呼ばれることがよくあります。

• 原子性: トランザクションは全体として実行され、トランザクションに含まれるデータベースに対する操作はすべて実行されるか、いずれも実行されません。
• 一貫性: トランザクションは、データベースの状態が一貫性のある状態から別の状態に変化することを保証する必要があります。一貫した状態の意味は、データベース内のデータが整合性の制約を満たす必要があるということです。
• 分離: 複数のトランザクションが同時に実行される場合、1 つのトランザクションの実行が他のトランザクションの実行に影響を与えるべきではありません。
• 耐久性: トランザクションがコミットされると、データベースへの変更はデータベースに永続的に保存される必要があります。

実際のアプリケーションでは、SQL 言語をマスターする必要があります。SQL ステートメントを使用してデータベース内の必要なデータを検索できることは、テスト エンジニアにとって必要なスキルです。SQL ステートメントの構文は一般的に似ており、RDBMS が異なると細部が若干異なります。自動化の実装では、自動化されたテストで期待値を取得するためにデータベースにアクセスすることも一般的なシナリオです。さまざまな言語にデータベースにアクセスするためのライブラリがあり、全体としてアプリケーションは非常にシンプルです。

非リレーショナル データベース

ソーシャルネットワークやその他のアプリケーションなど、インターネットで大量の非構造化データが生成されるに伴い、ユーザーの個人情報、ソーシャルネットワーク、地理的位置、ユーザー生成データ、およびユーザー操作ログは等比数列で増加しています。同時に、従来のリレーショナル データベースでは対応できない大量のデータ マイニング作業にも直面しています。そのため、NoSQL は徐々に開発されました。NoSQL の最も顕著な特徴は、非構造化データであり、一般的に、データは列と行の形式で保存されなくなりました。NoSQL でデータを格納するには、値ペア ストレージ、列ストレージ、ドキュメント ストレージなど、さまざまな方法があります。たとえば、より一般的な MongoDB はデータをドキュメントとして格納し、データ構造はキーと値 (key=>value) のペアで構成されます。MongoDB ドキュメントは JSON オブジェクトに似ています。フィールド値には、他のドキュメント、配列、およびドキュメントの配列を含めることができます。

RDBMS と NoSQL

RDBMS

• 高度に組織化された構造化データ
• 構造化照会言語 (SQL) (SQL)
• データと関係の両方が別々のテーブルに格納されます。
• データ操作言語、データ定義言語
• 厳密な一貫性
• 基本事務

NoSQL

• SQL 以外のものを表す
• 宣言型クエリ言語なし
• 定義済みスキーマなし: キー値ストア、列ストア、ドキュメント ストア、グラフ データベース
• ACID プロパティではなく、結果整合性
• 構造化されていない予測不可能なデータ
• CAP定理
• ハイパフォーマンス、ハイアベイラビリティ、スケーラビリティ

ビジネス知識

テストエンジニアにとって、テスト対象の製品に関するビジネス知識も非常に重要です。テスト エンジニアは既に上記のすべてのスキルを持っているかもしれませんが、これらのスキルをどのように使用して、最初に述べたソフトウェア テストの中心的な問題を解決できるのでしょうか? ここでの鍵、または中心点は、テストしている製品のビジネスです。テスト、企画、実装にはさまざまな方法がありますが、その中からどれを選ぶかは、製品のビジネスを深く理解することにかかっています。ここでのプロダクト ビジネスとは、プロダクトの特性だけでなく、プロダクトのユーザー特性、ユーザーの使用習慣、およびそれによるプロダクトへのトラフィックの傾向も含みます。テスターは、製品開発者の視点ではなく、ユーザーの視点から製品を分析する必要があるとも言えます。テスターはまた、製品のコア機能とコア ビジネスを見つけ、そのような分析を使用してテストの優先順位を分割し、欠陥を分類する必要があります。同時に、自動テストの計画とアーキテクチャにも重要な影響を与えます。たとえば、自動テストでは、コア ビジネスと機能を最初にカバーする必要があります。同時に、ビジネスの特性に応じて、自動化された方法を使用してユーザーの使用シナリオをシミュレートし、限られた自動化リソースを最も重要な部分に投資する必要があります。 . このスキルは、特定の知識ポイントがないかのように、架空のように聞こえるかもしれませんが、継続的な作業と要約では、優れたテスト エンジニアは、特定の種類の製品を満たす一連のテスト方法を要約することができ、より一般的なものを作成することさえできます。ベスト プラクティスを作成し、さまざまな製品で使用します。