アドオン/試験
システムにつきものの試験工程（xxテスト）というプロセスについて、つらつらと。
はじめに †
或る人曰く、プロジェクトの半分の期間はテストに充てるべきだと。
いい加減な試験をすると、その場では原因も対策も即座に対応できても、工程が後ろに行けば行くほど、その時とシステムのあるべき振る舞いが違っていたり、単に担当者が交代したことで、原因の究明も応急処置も恒久処置も難しくなる。
不具合のないシステム・プログラムはこの世に存在しないが、それに胡坐をかかず、少しでも上質なモノを仕上げられるように進めていきたい。
試験の技法 †
いかに実施するか、まずはここから入りたい。 試験の技法は、大きく2種類に分けることができる。 ホワイトボックステストとブラックボックステストである。
ホワイトボックステスト †
端的に言えば、プログラムの構造を主眼とする = ロジックから追う手法である。 単体テストに用いられることが多い。
文網羅 †
ソースコードの各文がテストで実行されたかどうかで判断する。
分岐網羅 †
制御構造上の分岐でそれぞれの分岐方向がテストされたかどうかで判断する。
経路網羅 †
対象コードの考えられる全ての経路についてテストで実行されたかどうかで判断する。
入口/出口網羅 †
存在する全ての関数呼び出しがテストで実行されたかどうかで判断する。
これらの観点にて、それぞれどれだけテストされたかを網羅率という尺度で評価する。
私見だが、SAPというシステム自体が巨大すぎることに起因するブラックボックスであり、そのブラックボックスが生み出したマスタやコンフィグおよび伝票をInputとするため、局地的にホワイトボックス化することの意味合いは薄いと考える。
もちろん、すべてブラックボックスであって良い・・・ということでは全くない。
ブラックボックステスト †
入力の内容、出力の結果を主眼とした手法である。 その試験に用いる道具というか、テクニックについて。
同値分割 †
Inputについては、有効なデータの範囲と無効なデータの範囲に分け、それぞれの代表的な値を用いてテストを行う。
境界値（限界値）分析 †
Inputについては、有効なデータの範囲と無効なデータの範囲に分け、更にその境界となる値を用いてテストを行う。 バグや要件が明確な仕様に落ちていない振る舞いは、分岐の境界で発生する場合も多いため、同値分割よりも多くの欠陥を発見することができる。
ディシジョンテーブル †
複数の条件およびその組み合わせがInputと成り得る場合に、 入力と出力の関係を表形式で表したもの。 縦が評価軸、横をテストケースとするのが一般的か。
試験の種類 †
まず最初に、ビッグバンテストという方法があることに触れたい。これはシステムの構成要素全てが完成してからテストを行うことを意味する。 SAPというシステムでは、余程の小規模であっても、行い得ない。 なぜなら、テストで見つけた問題が、どの機能に起因するかをまず「探す」必要があり、そこに費やす時間は浪費でしかないためだ。 また、不具合が不具合を呼んだり、それらが作用しあったりして、原因の特定がさらに困難になる場合もある。
そこで、一般的には工程ごとに、また徐々に規模を大きくして試験を行っていく。
ベンダが実施するテスト †
単体テスト †
Unit Testingの頭をとってUTとも呼ぶ、試験の中では最も基本的な試験。機能の最小単位で試験を行う。 割と重きを置かれない傾向はあるが、ここで実施するテストとその結果が、システムとしての品質を大きく左右する。 実際に実装した開発者が実施することが多いが、モノ作りのレベルやリテラシーがモロに出るため、設計者はテスト項目のレビューくらいはしたいところ。 Cording TestやProgram Testと呼ばれることもあるが、田舎っぺが作った和製英語のため、恥ずかしいのでやめたほうがいい。
受入テスト †
設計者が、実装が仕様通りであるかを試験する。 基本的にはコンサルタントが行うが、コンサルタント自身が実装した場合は設計者 = 実装者であるため、実施する意味はない。 顧客が行う検収テストについて、この呼び名を用いることもある。
結合テスト †
SAPにおいては、コンフィグ＋アドオンについて、モジュール単位やコンポーネント単位、大括りな業務ごとでまとめたイベントを結合テストと呼ぶ。 期間の短いプロジェクトでは、ここをまとめて統合テストに含めることも多い。 アプローチによって、トップダウンテスト（top down test）とボトムアップテスト（bottom up test）に分けることができる。
- トップダウンテスト 上位モジュールから順に結合させてテストを行なう。この手法の利点は、仕様的な振る舞いを決定する上位モジュールを早期に検証することによって、 機能漏れ、仕様の認識違いなどの致命的な不具合を、開発の早い段階で発見できることにある。 一方で、数の多い下位モジュールの検証が先送りされるため、開発と平行してテストを進めにくいという欠点もある。
- ボトムアップテスト トップダウンテストとは逆に、単体テストが完了した下位モジュールから順に結合させてテストを行なう。 この手法の利点は、数が多く独立性の高い下位モジュールから順に検証することで、開発とテストを平行して実施できることにある。 一方で、システムの根幹となる上位モジュールで不具合が発見された場合、テストが完了したはずの下位モジュールも影響を受けるという欠点も持っている。
- SAPのプロジェクトでは？ 単に、業務フローに従い、マスタデータを登録し、業務プロセスを実施できるかを試験し、課題を炙り出すことを指すことが多い。
統合テスト †
Integration Testingの略でITとも呼び、インタフェースしている他のハードウェアやシステム、その通信インフラなども含めた組み合わせで実施するテスト。 検証機で実施することもあるが、本番機に専用のクライアントを用意して実施するのが一般的か。 SAPでよく使われる呼び名である運用テスト（Operation Test）は、ここに属する。
ストレステスト †
システムに対して高い負荷を与え、データの破壊など致命的な問題が発生しないかをテストすること。 これにより、高い負荷が加わっている状況でしか発生しない不具合や、発生確率の低い欠陥を発見することができる。
パフォーマンステスト †
ソフトウェアシステムの性能を測り、既定の性能が出ることを確かめること。 通常、プログラム単体では問題が発生しなくても、通信、データベース、I/O、高負荷、長時間使用などの条件下では性能が低下することがあるため、これを確認するために実施する。 OSやミドルウェアなどでは性能を測定するための共通の計測モデルが決まっていることもある。
回帰テスト（リグレッションテスト） †
システムの機能を追加・変更した場合に、修正前の他の機能が動作することを確認するために行うテストのこと。 実施する回数も多いことから、過去のテスト資産を有効に使うべきだが、「正常系だけ、単体レベルで、ざっくり流す」という雑なテストがされがち。
べき論で言えば、厳密にはあるプログラムに対して仕様変更をした場合、実施したすべてのテストをやり直さねばならないことになるが、現実には難しいし中には「今となっては全く不要」という項目もある。
しかしながら、繁忙期や担当者が変更となった場合なんかは、思わぬことが起こり得るので、できる限りの回帰テストはできるかぎりの範囲で実施するべきかと思う。
ユーザが実施するテスト †
承認テスト †
保守・運用時のシステム障害による変更や改善要望などについてシステムの実際の利用者が行うテストで、機能や性能が要求通りのであるか確認する。単に受入テストとも呼ぶ。
ベータテスト †
完成前のソフトウェアを一般のユーザに利用してもらい、欠陥を発見してもらうテストのこと。 ベータテストで配布されるソフトウェア（ベータ版）は、基本的には製品版と同等の機能を備えるが、予期せぬ不具合が存在する可能性があるため、利用に際しては細心の注意を払わなければならない。
アルファテスト †
アルファテストは、ベータテストよりも完成度の低い段階（アルファ版）で行うテストである。オンラインゲームにおいては、ベータテストを広く一般に公開し、宣伝の目的も兼ねて実施される場合が多い。
コメントはありません。 Comments/アドオン/試験
