テストの技法

2023/4/29 - 読み終える時間: 4 分

Testing Techniques の翻訳版です。

テストの技法

2023年4月26日

Nandish Kumar / Testing Engineer

前回のブログでは、テスターが持つべき基本的なテストの特長について述べました。今日は、技術そのものに焦点を当てます。もし見逃したら、前のブログへのリンクはこちらです： 「テスト」と「チェック」の違い

私たちテスティングセンターオブエクセレンス（TCoE）は、このプロセスを Five-fold Testing System (五重のテストシステム) と呼んでいます。あなたが行うあらゆるテストは、5つの次元で説明できます。

• テスター - テストを行う「人」について説明します。
• カバレッジ - 「何を」テストするかを説明する（例：ファンクションテストでは、すべてのファンクションをテストする）。
• 潜在的な問題 - テストを行う「理由」（すなわち、どのようなリスクに対してテストを行うか）を説明します。
• アクティビティ - 「どのように」テストを行うかを記述する（例：探索的テスト）
• 評価 - テストの合格・不合格を見分ける方法を説明する

ほとんどのテストは、5つの次元すべてに関与しています。ある次元に焦点を当てたテクニックと、他の次元に焦点を当てたテクニックを組み合わせることで、望む結果を得ることができるのです。

実際にどのような効果があるのか、見てみましょう。

ある人が「ファンクションテスト（すべての機能を徹底的にテストすること）をしてください」と言うかもしれません。これは、何をテストすべきかを示しています。しかし、誰がテストを行うのか、どのようなバグを探すのか、各機能をどのようにテストするのか、そしてプログラムの合否をどのように判断するのかを決めなければなりません。

誰かが、 extreme-value テスト（変数に極値を入力したときのエラー処理をテストする）をするように言うかもしれません。これは、どのような種類の問題を探すべきかを教えてくれます。しかし、誰がテストを行うのか、どの変数をどのようにテストするのか、そして結果をどのように評価するのかを決めなければなりません。

最後に、誰かがあなたにベータテスト（市場の外部代表者にソフトウェアをテストしてもらうこと）を依頼するかもしれません。これで、誰がテストするのかがわかります。あなたはまだ、彼らに何を伝えるか（そしてどのくらい伝えるか）、製品のどの部分を見るか、どんな問題を探すか（そしてどんな問題を無視するか）を決めなければなりません。また、ベータテストでは、ある種の問題の見分け方を具体的に伝えたり、特定のテストを特定の方法で実施するよう求めたりすることもあります。

Test Automation Center of Excellence で利用されているさまざまなテクニック

人ベースのテクニックは、「誰が」テストを行うかに焦点を当てます。

ユーザーテスト。製品を使用する一般的な人々を対象としたテストです。ユーザーテストは、開発中のいつでも、お客様のサイトでもお客様のサイトでも、慎重に指示された練習でも、ユーザーの自由裁量でも行われることがあります。タスク分析など、ユーザーテストの中には、一人で行うテストというよりも、（少なくとも一人のユーザーとあなたの会社のテストチームの少なくとも一人のメンバーが参加する）共同探求のようなものもあります。

アルファテスト - テストチーム（と、場合によっては興味を持つ、友好的な内部関係者）が行う社内テスト。

ベータテスト - ユーザーテストの一種で、組織外のテスターを使用する。テスト対象の製品は、通常、完成に非常に近い状態です。多くのテストセンターでは、ベータテストとして「プレリリースコード」を顧客に公開する。

バグバッシュ - プログラマーや技術顧問など、手の空いている人を使って行う社内テスト。一般的なバグバッシュは半日程度で終了し、ソフトウェアのリリースが間近に迫っているときに行われる。

専門家によるテスト - ソフトウェアが扱ういくつかの問題についての専門家に製品を渡し、フィードバック（バグ、批判、褒め言葉など）を求める。

ペアテスト - 2人のテスターが協力してバグを見つけます。通常、2人は1台のコンピューターを共有し、テスト中にそのコンピューターの制御を交換します。

カバレッジベースの手法は、「何を」テストするかに重点を置いています。

機能テスト

すべての機能を1つずつテストします。その機能が動作すると確信できる程度に、徹底的にテストする。ホワイトボックスの機能テストは、通常ユニットテストと呼ばれ、コードの中で見たままの機能に集中する。

等価クラス分析。等価クラスとは、ある変数に対して、同等と考えられる値の集合のことです。テストケースは、次のような場合に等価となります：

(a) すべてが同じものをテストしている

(b) 一人がバグをとれば、他の人もバグをとるだろう。

(c)一人がバグをとらえなければ、他の人もおそらくとらえられない。

等価クラスを見つけたら、そのメンバーのうち1つか2つだけをテストする。

境界のテスト

等価クラスは、値の集合です。それらを数直線上にマッピングすることができれば、境界値はクラスの最小と最大のメンバーです。境界テストでは、この境界値をテストします。また、テストするクラスの最小のメンバーよりちょうど小さく、テストするクラスの最大のメンバーよりちょうど大きい、近くのクラスの境界値もテストします。

例えば、10～50の整数を受け付ける入力フィールドを考えてみましょう。注目すべき境界値は、10（最小）、9（小さすぎる最大の整数）、50（最大）、51（大きすぎる最小の整数）です。

ロジックテスト

変数には、プログラムの中での関係があります。たとえば、「PERSON-AGEが50より大きく、SMOKERがYESなら、OFFER-INSURANCEはNOでなければならない」という決定ルールがプログラムにあるとします。決定ルールは、論理的な関係を表現している。論理テストは、プログラム内のすべての論理関係をチェックしようとするものです。

仕様に基づくテスト

仕様書に記載されている製品に関する事実上の主張をすべて検証することに焦点を当てたテスト。これには、マニュアル、マーケティング文書や広告、顧客に送付する技術サポート文書に記載されているすべての主張が含まれることが多い。

組み合わせのテスト

2つ以上の変数を互いに組み合わせてテストすること プログラムによって提供されるほとんどの恩恵は、多くの変数の相互作用に基づいています。テストでそれらを共同で変化させなければ、個々の値ではなく、難しい組み合わせによって引き起こされるエラーを見逃すことになります。

アクティビティベースのテクニック

「どのように」テストするかに重点を置いています。

リグレッションテスト

リグレッションテストでは、同じテストを再利用することで、変更があった後に（これを用いて）再テストを行えます。リグレッションテストには2種類あります：

• バグを報告し、それが修正されたと後で聞いた後に、bug fix regression を行います。目標は、その修正が良いものであることを証明することです。古いバグのリグレッションの目的は、ソフトウェアの変更によって古いバグの修正が未修正になったことを証明することである。
• Side-effect regression は、stability regression とも呼ばれ、製品の相当部分を再テストする。

その目的は、変更によって、以前は動作していたものが壊れてしまったことを証明することです。

スモークテスト

このタイプの副作用リグレッションテストは、新しいビルドがテストする価値があることを証明することを目的として行われます。これはビルド検証テスト（BVT）とも呼ばれます。スモークテストは、しばしば自動化され、あるビルドから次のビルドへと標準化されます。動作すると思われるものをテストし、動作しない場合は、プログラムが間違ったファイルでビルドされたか、基本的な何かが壊れているのではないかと疑うことになります。

探索的テスト。テスターには、プロジェクトを通して、製品、市場、リスク、以前のテストに失敗した方法などについて学ぶことを期待します。新しいテストは常に作成され、使用されます。新しいテストは、テスターの継続的な知識に基づいているため、古いテストよりも強力です。

シナリオ・テスト。シナリオ・テストには通常、以下の属性が含まれます。

• テストは現実的でなければならない。顧客が行うであろうことを反映したものでなければならない。
• テストは、プログラムにとって挑戦的であるべき方法で、いくつかの機能を含む複雑なものでなければなりません。
• プログラムがテストに合格したか不合格になったか、簡単かつ迅速に判断できること。
• ステークホルダーは、このテストに失敗したらプログラムを修正すべきだと激しく主張する可能性がある。

ユースケースから派生したテストは、シナリオテストやユースケースフローテストとも呼ばれます。以上のような属性を持つテストは説得力があり、プログラムに失敗してもバグフィックスをもたらす可能性が高い。

インストールテスト

ソフトウェアをインストールできる様々な方法、様々な種類のシステムにインストールする。ディスク上のどのファイルが追加、変更されたかを確認する。インストールしたソフトは動作するか？アンインストールするとどうなるか？

負荷テスト

テスト対象のプログラムやシステムは、リソースに対する多くの要求に直面しているシステム上で実行されることにより、攻撃されます。十分な負荷がかかると、システムはおそらく故障しますが、故障に至る事象のパターンから、テスト対象のソフトウェアやシステムの脆弱性が指摘され、テスト対象のソフトウェアをより通常通りに使用した場合に悪用される可能性があります。

ロングシーケンステスト

テストは一晩、あるいは数日、数週間にわたって行われる。その目的は、短いシーケンステストでは見逃されるようなエラーを発見することです。この方法で発見されることが多いエラーの例としては、メモリリーク、スタックオーバーフロー、2つ以上の機能の間の悪い相互作用などが挙げられます。これは、期間テスト、信頼性テスト、耐久性テストと呼ばれることもあります。

パフォーマンステスト

このテストは通常、プログラムの実行速度を測定し、最適化が必要かどうかを判断するために実行されます。しかし、このテストによって、他の多くのバグが発見されることがあります。以前のリリースからパフォーマンスが大きく変化した場合、コーディングエラーの影響を示すことがあります。

例えば、簡単な関数テストの実行にかかる時間を今日テストし、明日同じマシンで同じテストを実行した場合、テストの実行速度が3倍以上速くなったり遅くなったりしたら、プログラマーに確認するかバグレポートを書くことになるでしょう。どちらの場合も、プログラムの基本的な部分が変更されていることが疑われるからです。

評価ベースの技術は、テストが成功したか失敗したかをどのように見分けるかに焦点を当てます。

データの自己検証

テストに使用するデータファイルには、出力データが壊れているかどうかを判断するための情報が含まれています。

保存した結果との比較

今日出た結果と先週の結果を比較して「合格か不合格か」を判断する回帰テスト。先週は正しい結果が出たのに、今は違うということは、その違いが新たな不具合を反映している可能性があります。

仕様書などの権威ある文書との比較

仕様書との不一致は（おそらく）エラーである。

一貫性

一貫性は、プログラムを評価するための重要な基準です。矛盾はバグを報告する理由になるかもしれませんし、意図的な設計の変化を反映しているかもしれません。

• 歴史との整合性。現在の機能の動作は、過去の動作と一致している。
• ユーザーの期待との整合性。機能の動作は、ユーザーが望んでいると思われるものと一致している。

上記の手法に加えて、テスティングセンターオブエクセレンス（TCoE）は、現在、組織全体に対して「アクセシビリティ・アズ・ア・サービス」を提供しています。これは、HCLSoftwareのデジタル製品が、障害を持つ人を含むすべての人にとってアクセシブルであることを保証するために、HCLSoftwareが支援できることを意味します。HCLSoftwareのアクセシビリティ・テスト・サービスの活用にご興味をお持ちの方は、ぜひお問い合わせください。