チームのすべての SOAtest ユーザーが接続できるリポジトリにアセットを永続化したら、チーム メンバーの役割に基づいてワークフローを定義することを推奨します。

開発者

JUnit や NUnit といった単体テストのフレームワークに加えて、開発者は機能テストのフレームワークを必要とします。そうすることで、システムの機能を基本的なテストのセットに対して展開できるためです。実際のところは、このような手法はアジャイルの開発モデルや TDD (テスト駆動開発) 手法で必要とされます。

開発者のテスト作業は、開発グループの外でも使用されるべきです。テスト対象のシステムの技術的知識には開発者が最も精通しているため、機能テストのための初期構成単位を提供することによって、テスト プロセスを速やかに開始することができます。たとえば、構成単位の定義には次のようなものがあります。

  • WSDL、WADL、OpenAPI/Swagger または RAML 定義からの Web サービスの初期テスト - サービスが適切に操作されることを想定した基本パラメーター値を使用。
  • Web サイト全体の主な使用事例のフロー。
  • SOAtest DB Tool で使用するためのデータベース接続設定の初期構成とサンプル クエリー。
  • JMS/JNDI の設定。

そのような初期テストの成果物は、"静的な" 記述 (サンプル XML メッセージの Word 文書や、使用説明の wiki など) の置換や向上によって、開発者が QA にシステムのテスト方法のライブかつ実行可能な記述を提供することを可能にします。

そのため Parasoft は、開発者が QA と同じテスト プロジェクトにアクセスし、QA がベースにできるテスト生成物を提供することを推奨します。 そうすることによって QA は、接続設定、URL、サンプル メッセージのような技術的知識よりも、エンド ユーザーの経験といったシステムのビジネス要件に焦点を当てることが可能となります。一般的には、開発者が提供するテストは基本中の基本となり、主なユース ケースをカバーします。開発者は、システムが少なくとも基本レベルで稼働することを示す構成要素を設定する傾向にあります。

品質保証

推奨するワークフローでは、QA チームのメンバーは開発者が作成したサンプル テストでワークプレースを更新し、その基盤を使用して、システム周辺のさまざまなユース ケース シナリオを設計し、何が動作しないかを見出します。次に例を示します。

  • テストのカバー範囲を広げるために、データ ソースでテスト ケースを拡張する。
  • エラー条件のテスト ケースなど、ネガティブ シナリオを設計する。
  • システムがすべてのエンド ユーザー要件に従うか検証するために、ユース ケース シナリオ テストを作成する。
  • 複数のアプリケーションに及ぶエンド ツー エンド ビジネス プロセス テストを設計する
  • テスト成功基準と検証アサーションを定義する。

QA が作成したテストは共有リポジトリにコミットして開発者も実行できるようにするべきです。そうすることによって、開発者は QA が次にテストを再実行するのを待つことなく、テスト ケースを使用してシステムの問題の再現、問題のデバッグ、コードの変更の検証をすることができます。

セキュリティ テスト

セキュリティは検査演習としてライフサイクルの後半まで放置される傾向にあります。しかし Parasoft をはじめセキュリティ専門家の大多数は、セキュリティ開発ライフサイクルのインライン プロセスとしてセキュリティに取り組むことを推奨しています。Parasoft ソリューション フレームワークはこの理念に従います。 

Parasoft SOAtest は、静的解析や侵入テストなどのセキュリティ関連の検証を用いて既存の機能テスト ケースを拡大するのに使用されます。セキュリティ検証の責任を担うエンジニア (開発者、QA または別のグループなど) は機能テストのトップにセキュリティ侵入テストを構成できます。これが、テスト成果物への共有アクセスが必要とされ、共有ワークスペース上での共同作業が非常に実践的であるもうひとつの理由です。

詳細については、「セキュリティ テスト」を参照してください。

負荷テストと性能テスト

一部の組織には、現実的な負荷テストを実行するのに適したハードウェアやステージング環境に接続できる、集中型の負荷/パフォーマンス テスト グループが存在します。 一方、この作業をプロジェクト チームが担当する組織もあります。または、スケール、ライフサイクルのステージ、そしてテスト頻度の差で、両方が混在するケースもあるかもしれません。 すべてのテスト ケースにおいて (誰が負荷テストを設計したかや誰がどこまで実行したかに関係なく)、機能テスト プロジェクトへのアクセスは非常に有益です。 なぜならパフォーマンス テストは既存の機能テストに負荷をかけて実行するように設計されているからです。パフォーマンス テスト エンジニアのタスクは次のとおりです。

  • 開発者や試験者がリポジトリへ追加したプロジェクト (.tst) ファイルを呼び出す。
  • 既存の単体テストや機能テストを使用して負荷テストのシナリオを定義する。
  • SLA に対してサービスを検証し、モニターを使用してボトルネックを確認するために、QoS (予期されるサービス品質) メトリクスを定義する 。
  • 共有リポジトリに負荷テストのシナリオをコミットする。

詳細については、『負荷テスト (Load Test)』を参照してください。

  • No labels

Need assistance? Visit our support page