2018-07-18

組み合わせテストツールATestCovを公開

組み合わせテスト設計の補助用に、nワイズカバレッジを計測する簡易的なツールATestCovをリリースしました。

ツールの想定用途は、既存のテストケースの網羅度チェックや、組み合わせのばらつきの評価です。

計測対象のnワイズカバレッジは、テストケース中に、n個のパラメータ組み合わせがどれぐらい出現するかを、網羅率で示したものです。
具体的な公知のテスト技法との関係として、同値分割テストの網羅率では、1ワイズカバレッジを評価に用います。オールペア法（ペアワイズ法）や直交表技法の網羅率では、2ワイズカバレッジの網羅に重点を起きます。

使い方

使い方ですが、テストケース記述ファイルと、パラメータ記述ファイルを実行引数に指定して実行します。

パラメータ記述ファイルは、以下のようなテスト条件のパラメータと値を列記したファイルです（PICTの入力ファイルと同じです）。

#パラメータ記述ファイル.txt
麺:硬め,普通,柔らかめ
スープ:塩,醤油
あぶら:多め,普通,少なめ
飯:あり,なし

テストケース記述ファイルは、以下のようなテストケースを羅列したファイルです（PICTの出力結果と同じです）。

#テストケース記述ファイル.txt
麺	スープ	あぶら	飯
硬め	塩	あり	あり
普通	醤油	なし	なし
硬め	醤油	なし	なし

これを以下のように実行します。

atestcov.exe --param パラメータ記述ファイル.txt --testcase テストケース記述ファイル.txt

すると、以下のように、nワイズカバレッジを一覧表示します。

[coverage report]
number of test case: 3
number of parameter: 4
1wise coverage: 90.00%(9/10)
2wise coverage: 45.95%(17/37)
3wise coverage: 20.00%(12/60)
4wise coverage: 8.33%(3/36)

その他の使い方

排他制約にも対応しています。排他制約は以下のように「@mutex」を付与して記述します。

#パラメータ記述ファイル.txt
麺:硬め,普通,柔らかめ
スープ:塩,醤油
あぶら:多め,普通,少なめ
飯:あり,なし

@mutex 麺:硬め, あぶら:多め

排他制約で指定された組み合わせは、カバレッジ計測から除外されます。

その他、追加の実行時引数で、網羅できていない組み合わせの表示や、組み合わせテストのメトリクスの表示を追加できるようにしています。

2018-04-03

ISO/IEC/IEEE 42010での「観点」関連の用語の定義・用例

テストでは観点という言葉が時々使われています。ただ結構曖昧な用語なので、議論すると話が発散しがちな印象を持っています。
そこでは体系だった標準を土台にすると発散を軽減できる場合があるのですが、テストの観点を語る上で使えそうな標準として、ISO/IEC/IEEE 42010があります。

ISO 42010は、アーキテクチャ設計を対象にConcern（関心事）、Viewpoint（観点）、View（側面）の定義や関係性を規定するものです。
この規格は書いてある通りに従えば良いというものではないものの、Viewpoint、Viewなどの言葉の定義の共有手段として使えます。
またアーキテクチャ設計についての文献では、ISO 42010に則った解説や、ISO42010との関係性を明記した解説が結構あります。そのためアーキテクチャ設計の観点を学ぶ際の前提知識としても有用です。
テスト観点についての議論の助けになると思いますので、今回「観点」の用語に絞ってISO 42010について触れたいと思います。

用語

まずISO 42010で扱う用語を簡単に説明します。
留意点として、用語の対象はほとんどアーキテクチャについてです。本来「Architecture Viewpoint」「Architecture View」などと前後にArchitectureを明記しますが、自明であるとして規格では「Architecture」を省略しています。ここでもその省略表記に従います。

Concern(関心事)
- システムに対するステークホルダ（システムに関わる個人や組織）の関心事。
- 要求、制約、シーズ、製品リスクなどが該当する。

Viewpoint(観点)
- Conernにうまく対応するために用いる、アーキテクチャについての観点。
- アーキテクチャの品質特性、モデルの種類、Concernを形式化したものなどで表現される。

View
- Viewpointから見えるアーキテクチャの側面を表現したもの。
- アーキテクチャの構造モデルなどが該当する。

Architecture Description
- アーキテクチャの表現物。
- 最終的なアーキテクチャ設計成果物そのもの。Viewはこの一部。

Model Kind
- モデルの種類。
- クラス図、ユースケース図など。ViewpointはModel Kindと紐付けられることが多い。

Model
- Model Kindに従って表現したモデル成果物。
- クラス図で構造を表現した成果物など。Viewの一種。

Perspective
- 明示的に定義を行っているわけではないが、構造を横断する横断的Viewpointのような意味で使われている用語。
- なお規格が引用している文献「ソフトウェアシステムアーキテクチャ構築の原理」では、ViewpointとPerspectiveを別の概念として区別している（前者は構造的に分けて考えられる観点、後者は構造を横断する横断的関心事、のように分けている）。

各用語の関係性

ISO 42010では前述の用語の関係性を「Conceptual model of an architecture description」という図でまとめています。そのうち、今回の解説に関係するものを抜粋すると、以下のようになります。

f:id:goyoki:20180403005221p:plain

関係性を大まかに説明すると次のようになります：

ステークホルダのConcernに対応するために、アーキテクチャを分析・設計します。
アーキテクチャの分析・設計を整理だてて行うために、整理・体系化されたViewpointを利用します。そこではViewpointごとにViewを分析し、得られたViewをArchitecture Descriptionとします。
ViewpointはModel Kindに関連付けられています。Viewの分析は、その関連付けされたModel Kindのモデルをモデリングする活動となります。

各用語の具体例

例えば給湯ポットの場合、具体例は次のような感じになります。

Concernの例

ポットの使用者のConcern
- どれぐらい早く沸騰させられるか
- 子供が誤って給湯できないようにするロック機能はあるか
開発者のConcern
- 開発をどのように分業できるか

Viewpointの例

効率性についてのViewpoint
- ハードウェアの資源効率性、加熱の時間効率性、・・・
内部構造についてのViewpoint
- ハードウェアとソフトウェアの責務分掌、ソフトウェアの構造、ソフトウェアの状態、・・・

Viewの例

Viewpoint「ソフトウェアの構造」に対するView
- ハードェア制御部・基本フレームワーク部・アプリケーション部の3層構造をモデリングしたパッケージ図
Viewpoint 「ハードウェアの資源効率性」に対するView
- 「ROMサイズは128MByte以下である」
- 「シングルコアである」

活用

ViewpointやViewをうまく体系化すると、次のような活用が可能になります。

分析や設計の進め方についてのコミュニケーション（共有、レビュー、教授など）を容易にします。
View ModelとしてViewpointを整理しておくと、分析漏れに気づいたり、分析結果を整理したりするのに有用な事があります。
Viewpointを分けることで、複雑で大規模な分析を、分けて進められるようにします。

こうした活用を行っているものとしては、例えば開発プロセスのRUPやUPが有名です。

2018-02-04

FreeMindからテストケースを自動生成するテストツールFMPictをリリース

最近、FMPictというテスト設計自動化ツールを作りました。

https://github.com/hiro-iseri/fmpict

FMPictは、FreeMindのモデルからテストケースを生成するテスト設計自動化ツールです（PICTを制御して実現しています）。nワイズカバレッジ(n:1～3)を100%網羅するテストケースを生成できます。オールペア法ツール、クラシフィケーションツリー法ツールとして利用可能です。

ツールは以下のメリットを持ちます。

マインドマップでテスト条件をモデリングできます。それにより、テスト条件の抽象構造やグルーピング構造をわかりやすく表現できます。
ツリーモデルの記法的制約（*）の回避手段として、リンク記法とタグ記法という機能を加えています。これによりツリーの重複をなくしたり、複数のツリーを一つのツリーにまとめて描いたりすることが可能です。
PICTをマインドマップで操作できます。

環境設定とインストール

環境設定とインストールの手順は以下に記載しています。

https://github.com/hiro-iseri/fmpict/blob/master/doc/howto_setup.md

PICT、Freemind、Python(2.7 or 3。pip必要)が必要です。Win、Macで動作確認しています。
FMPictのインストールは「pip install fmpict」を実行ください。

機能の概要

記法ルールは以下にまとめています。

https://github.com/hiro-iseri/fmpict/blob/master/doc/manual.md

大まかに、プレフィックスかフォルダアイコンでノードの種類を表現します。テスト条件（因子orクラシフィケーション）にはフォルダアイコンか先頭文字「@」を付与します。値（水準orクラス）は何も付けません。

例えば次のようなモデルをFreeMindで描きます。

f:id:goyoki:20180204230440p:plain

そして以下のコマンドを実行します。

fmpict FreeMindファイルのファイルパス

すると2ワイズカバレッジ100%網羅のテストケースが出力されます。

ライス  味      ほうれんそう    スープ  味玉    麺      チャーシュー
なし    普通    あり    こってり        なし    ふつう  なし
中      普通    なし    ふつう  あり    硬め    あり
小      こいめ  あり    ふつう  なし    硬め    なし
小      薄め    なし    こってり        あり    ふつう  あり
なし    薄め    なし    ふつう  あり    硬め    なし
なし    こいめ  あり    ふつう  あり    ふつう  あり
小      普通    なし    こってり        なし    硬め    あり
中      薄め    あり    こってり        なし    ふつう  なし
中      こいめ  なし    こってり        あり    ふつう  あり

テストケースの生成では、色々な網羅基準を選択可能です。詳しい手順を以下に記載しました。

https://github.com/hiro-iseri/fmpict/blob/master/doc/howto_select_coverage_criteria.md

2017-12-06

FreeMindを使ってテスト設計技法クラシフィケーションツリー法のツールを作る

ソフトウェアテストの小ネタ Advent Calendar 2017 - Qiitaの7日目の記事です。

テスト業務でFreeMindを使っている現場をちらほら見ます。このFreeMindについてですが、中身はテキストベースのXMLフォーマットなので、容易に読み出しや変更を行えます。XMLパーサでスクリプトを組めば、自動で他の成果物と連携させたり、ツリーの整合性を維持したりできるようになります。
今回は実践例として、このFreeMindを使ってテスト設計技法であるクラシフィケーションツリー法の簡易的なツールを作ります（クラシフィケーションツリー法の詳細は「クラシフィケーション・ツリー法入門」を参照ください。題材の完成形は「https://github.com/hiro-iseri/fm_ctm」）。

1. FreeMindでクラシフィケーションツリーを表現する。

まずFreeMindでクラシフィケーションツリーを描きます。
クラシフィケーションツリーの表現では、最低限クラスとクラシフィケーションの区別が必要です。その区別は一般的には枠線の形で行いますが、今回は区別に操作容易なアイコンを用います。具体的には、テストの入力に指定する末端のクラシフィケーションに、フォルダアイコンを付与する表記ルールを取ります。
例題として、ラーメン二郎のツリーを描いてみました。

2. Freemindのツリーを読み込む

次にFreeMindから、テスト条件となるクラシフィケーションとクラスの抽出を行います。
今回はPythonのXMLパーサを用います。処理としては、マインドマップのノードを再帰的に巡回し、フォルダーアイコンが付与されたノード（属性BUILTINに「"folder"」格納）と、その子ノードのテキストを抽出していきます。
コードは例えば以下のようになります。ファイルパスinput_fileのファイルを解析し、クラシフィケーション名をキー、クラス名のリストを値とするディクショナリを_clsf_dictに格納しています。

import xml.etree.ElementTree as ET

_clsf_dict = {}

def _get_testcon_from_node(parent):
    """FreeMindのノードを再帰的に巡回。クラシフィケーションとクラスの組を_clsf_dictへ格納"""

    if [x for x in parent if x.attrib == {'BUILTIN': 'folder'}]:
        class_list = []
        for node in list(parent):
            if 'TEXT' in node.attrib:
                class_list.append(node.attrib['TEXT'].encode(sys.stdout.encoding))
        cf_text = parent.attrib['TEXT'].encode(sys.stdout.encoding)
        _clsf_dict[cf_text] = class_list
    else:
        for node in list(parent):
            _get_testcon_from_node(node)
    return _clsf_dict

...
cls_tree = ET.parse(input_file)
_get_testcon_from_node(cls_tree.getroot())
# _clsf_dictに結果格納
...

3. ツリー結果をPICTに入力し、テスト条件リストを生成する。

最後にテスト条件一覧を出力します。
今回はFreeMindから抽出したクラシフィケーションとクラスの組を、組み合わせテストツールPICTに入力して、2ワイズカバレッジ100%のテスト条件組み合わせを出力させます。
コードは例えば以下のようになります。
前述の「2.」のディクショナリclsf_dictを入力にして、結果を標準出力に出力しています。

def _print_testcondition(clsf_dict):
    """クラシフィケーションとクラスの組をインプットにpictを実行。その結果を標準出力に出力"""
    # クラスとクラシフィケーションの組をpict形式ファイルtemp.csvとして保存
    with open("temp.csv", "w") as pict_input_file:
        for key, classlist in clsf_dict.iteritems():
            line = key + ':' + ",".join(classlist) + '\n'
            pict_input_file.write(line)
    subprocess.Popen("pict temp.csv", shell=True)

表示例は以下の通りです。

豚        アブラ  野菜    ニンニク        辛め    麺      サイズ
豚W     なし    増し    増し    なし    普通    小
普通    増し    あり    なし    あり    硬め    大
豚入り  あり    増し    あり    増し    硬め    大
豚入り  あり    なし    なし    あり    普通    小
普通    なし    なし    増し    増し    普通    大
豚W     なし    あり    なし    増し    硬め    小
豚W     あり    なし    あり    なし    硬め    大
豚入り  あり    あり    増し    あり    硬め    小
豚入り  増し    あり    あり    なし    普通    小
豚W     増し    増し    あり    あり    普通    大
普通    なし    増し    あり    あり    硬め    小
豚入り  なし    増し    なし    なし    硬め    小
豚W     増し    なし    増し    増し    硬め    小
普通    あり    なし    あり    なし    普通    大

コード完成形

題材を実行可能にしたコードを以下に置いています。

https://github.com/hiro-iseri/fm_ctm

「python fmctm.py マインドマップファイル」で実行します。

2017-09-20

テスト設計コンテスト出場募集中&宣伝

　去年からU30テスト設計コンテストというコンテストイベントで、審査委員長をやらせて頂いています。今コンテストへの出場応募中ということで、今回その宣伝をしたいと思います。

テスト設計コンテストとは

　テスト設計コンテストは、ASTERが開催しているテスト設計のコンテストです。2011年から毎年開催していて、毎回相当数のエントリーがあります。
　テスト設計コンテストでは、指定された製品仕様書に対するテスト設計の優劣で優勝を競います。テスト設計はどこでもやっているようなブラックボックスのシステムテストが多いです。
　審査は半年程度をかけた二段階制で、書類審査等で予選をして、通過チームで決勝を行います。
　なお自分の担当するU30は、若手の方やコンテスト初心者の方が挑戦しやすくすることを目的に、30歳以下に限定しています。

　申込みはこちらから。申し込み期限は9/29です。

テスト設計コンテストで得られるメリット

　有料ですし作業量も大きいですが、テスト設計コンテストへの参加にはそれに見合う色々なメリットがあると感じています。かつて応募者側で何度か参戦した時に感じたものをベースに、メリットを列挙したいと思います。

●自分達のテスト設計に対して、様々な改善アドバイスをもらえる。

　テスト設計コンテストでは、テスト設計をより良くするアドバイスをもらえます。
　まず審査物に対して、採点結果と審査コメントがフィードバックされます（予選を勝ち抜けば、予選・決勝と二回フィードバック機会があります）。この審査コメントは、審査員が個々人で出した評価コメントで構成されます。審査者は、テストのコンサルタント、マネージャ、専業のテストエンジニア、開発者、テスト設計コンテスト優勝者など、様々な人が集まっています。その各々の視点で、長い時間を投じて、改善を促すために成果物の良いところ・悪いところを評しています。多種多様なプロのフィードバックのため、有益なアドバイスにいくつも巡り合う可能性があると感じます。
　評価コメントは、例えば以下のような感じです（出場チーム以外は非公開なので、実例の一部を抜き取って、デフォルメして書いています。また審査員による個人差も大きいので、全く別物のコメントもあります）。

リスク分析から、仕様の抜け漏れを抽出している点、振る舞いモデルで仕様の矛盾を指摘している点は評価できます。リスク分析で用いているHAZOPを参考にしたガイドワード手法は、不十分な仕様に対して有効かつオリジナリティがあります。
テスト分析では、テストの厚み・テストの網羅基準の分析が不足しています。テストアーキテクチャレベルで分析されていないため、以降のテスト設計技法の選択の根拠が読み取れなくなっています。まず要求やリスクにもとづいてテストアーキテクチャレベルでテストの網羅基準や優先付けの方針をたて、各テスト設計に展開するステップを取ってみると良いでしょう。
テスト設計は概ね問題ありません。一点だけ、状態遷移モデルが誤っています。テスト技法を適用しやすくするために、本来複数に分けるべき状態を、一つに無理やりまとめてモデリングしてしまっていると感じます。構造モデリングをしっかりして、本質的な状態が何か分析すべきです。
ドキュメントはPFDで全体像が説明されている他、体系的に整理され理解しやすかったです。ただ形式が長大なExcel方眼紙であり保守性に劣ると感じます。自分達が現場で使いたいかという視点で改善すると良いかもしれません。

　こういったものが10人弱程度分、各チームにフィードバックされます。

●テスト戦略やテスト設計の型と実例を学べる

　テスト設計コンテストでは、テスト設計のやり方、実例、見本を学べる機会が豊富です。
　例えば参加者向けのチュートリアルでは、仕様書を分析して戦略を立てテストケースを設計する一連の流れを、具体的に学べます。
　また参加チームには、見本として過去の優勝チームのテスト設計成果物が共有されます。真似するだけでも知識の整理になります。
　そして審査会場では、他チームの成果物の解説を聞いたり、参加者・審査員と交流したりする機会が複数あります。そこでは同じ題材を対象とした、様々なテスト設計のアプローチを学べます。参加者も、優勝を狙って本気を出しているテスト専業会社のチームや、独自のテスト手法を作っている方が力試しで個人参加しているチーム、学生の研究室チーム等などが混在しています。それらが個性を出し合って工夫しているので、触れられるテスト設計もバリエーション豊かです。こうして様々なアプローチを学ぶことは、知識を広げたり、新たな知見を得たりするのに有益だと思います。

●優勝すると、テストのコミュニティで名声が得られる場合がある

　主観ですが、テスト設計コンテストの優勝チームは、その後表立って活躍する方が多いと感じています。例えばこれまでの優勝者も、コンテストネタで記事を連載したり、JaSSTなどのカンファレンスへ講演者として招待されたり、各地で請われてコンテスト成果物について解説する勉強会を開催したりと、色々引っ張りだこになっていました。
　また、運営団体はテスト設計コンテストを結構重視しているため、国際標準規格を策定している研究者、国内トップのテストコンサルタント、大小様々なカンファレンス・シンポジウム等の運営者・技術委員、著名な技術書著者など、テスト業界で実績を持っている人達が多数審査に動員されています。守秘義務で表になることはありませんが、審査を通してそうした審査員に技術的高評価を持たれることは、テスト業界で活動する上で良い影響になるのではと感じています。なお、自分を含め審査員は、テスト設計コンテストで優勝することの凄さ・技術レベルの高さを、審査の中でいつも強く実感させられています。

●テスト設計の楽しみを感じられる

　テスト設計コンテストでは、良いテスト設計を作る楽しさややりがいを感じることが多いと思います。
　現場では、テスト設計は評価されにくい傾向があります。コンテストでは細かな観点で良し悪しが明示化されるため、作りがいが出てきます。審査が必要なコンテストという形式上、審査の枠・観点に合わせる窮屈さはあります。それでも世の中の沢山の技術を活用したり、独自の技術を生み出したり、技術要素を組み合わせて体系を構築したりする余地は多分に残っています。
　またテスト設計コンテストでは、テスト設計が好きな人達が沢山参加していて、コンテストを通じて勉強会仲間になる機会もあります。テスト設計の同好の士ができるのも、楽しさを見つける下地になると思います。

募集について

　以上宣伝でした。冒頭でも触れましたが、コンテストの応募は公式サイト（ASTER-テスト設計コンテスト）で9/29まで行っています。
　誠意を尽くして審査しますので、興味の有る方は気軽にご応募頂ければと思います。

2017-08-28

「テスト戦略」を解説している書籍まとめ

　最近自分の周りで「テスト戦略とは何か」という議論をちらほら見ます。それを見ていて、世の中のテスト本ではどのような定義で「テスト戦略」の言葉を使っているか気になりました。
　そこで今回、テスト戦略について解説のある書籍を、概要とともにリストアップしてみました。

リストアップの対象

　数が多いので、テストの解説本で、紙面化されいて、日本語で書かれている書籍に対象を絞っています(よく引用されるJSTQBだけ例外)。
　なお、一般的に市販されている日本語のソフトウェアテスト専門書はほとんど読んでいると思いますが、忘れたり、手元になかったり、破棄したりした本もあるので、抜け漏れもあるかと思います。

前置き：推薦図書

　リストを書く前に、先に推薦文献や全体の傾向に触れます。
　推薦文献ですが、テスト戦略を学ぶ取っ掛かりとしては、「http://www.jasst.jp/archives/jasst10s/pdf/S1.pdf」「JSTQB Advanced Level シラバス日本語版テストマネージャ」の２つがお勧めです。両方とも手軽に読めて無料です。
　次のステップは、学びたいテスト戦略の目的やスコープによって変わると思います。たとえばマネジメントを含むテストプロジェクトの戦略を学ぶ場合、以降のリストで「詳細度★★★」にしている書籍は推薦できると思います。テスト設計の戦略ならばとっかかりとして「ソフトウェアテスト　293の鉄則」が、具体例としてリストの後半にあるバイザー本や、HAYST法の本等が良いと思います。

前置き：リストアップした書籍の全体の傾向

　次にリストアップした書籍の全体の概要です。
　多くの書籍は、一般的な「戦略」の定義に則った上で、書籍のテーマの戦略を「テスト戦略」と呼んでいるようです。例えばテスト設計の解説書なら、テスト設計の戦略をテスト戦略と呼称することが多いです。マネジメントの解説書なら、テストマネジメントの戦略をテスト戦略と呼称することが多いです。

　また「テスト戦略」の定義は多少のブレがあります。リストアップした書籍をグループ分けすると、概ね以下の流派がありそうです。

特定プロジェクトに依存せず横断的に適用できる、組織で蓄積したソフトウェアテストの工夫全般（JSTQB）
良いテスト設計を行うための、テスト設計の段取りや技術の戦略（293の鉄則、ISO29119など）
テストプロジェクトを成功させるための戦略全般（RexBlackの書籍など）
テストプロジェクトを成功させるための戦略のうち、リソース配分と段取りに関するもの（TPI NEXTなど）
テスト設計技法（バイザー本などの古典）

前置き：凡例

　整理のため、書籍解説では以下の凡例に基づいて項目分けしています。

【解説の詳細度】として、テスト戦略の直接的な解説の詳しさに応じて★を大まかに付けています。★が多いほど解説が多いです。
【解説目的】として、本でテスト戦略を解説している目的を、以下から複数選択で記載します。
- 定義解説：テスト戦略の用語定義の解説を目的とする
- グッドプラクティス解説：良いテスト戦略についての、普遍的な原則やパターン、プラクティスの解説を目的とする
- 事例解説：特定のプロジェクトや組織で実践したテスト戦略の解説を目的とする
【遂行手段】として、テスト戦略を遂行するために工夫・実践する活動を、以下から複数選択で記載します。
- スケジュール・リソース：マネジメントに含まれる、スケジュール・人員・環境確保・組織体制の戦略を策定する
- テストプロセス：テストプロジェクト全体のプロセスの戦略を策定する
- テスト設計：テスト設計や、テスト設計に限定したプロセスの戦略を策定する
- テスト実装：テスト実装の戦略を策定する

テスト戦略を解説した書籍（タイトルが詳細へのリンクになっています）

「実践ソフトウェアエンジニアリング」

【解説の詳細度】★★★
【解説目的】定義解説、グッドプラクティス解説
【遂行手段】スケジュール・リソース、テストプロセス、テスト設計、テスト実装
【特徴や留意点など】
「ソフトウェアテストの戦略とは、品質の高いソフトウェアが開発できるように、テスト設計手法を手順や計画としてまとめあげることである」と記述。
良いテスト設計をするためのテストプロジェクトの戦略を、テスト戦略と呼称している。テスト設計の進め方がメインだが、テスト設計を円滑にするための組織構成やプロジェクトの段取りもテスト戦略に含まれる。

「ソフトウェアテスト12の必勝プロセス」

【解説の詳細度】★★★
【解説目的】定義解説、グッドプラクティス解説、事例解説
【遂行手段】スケジュール・リソース、テストプロセス、テスト設計、テスト実装
【特徴や留意点など】
「テストプロジェクトとテストチームの目標または任務に沿って採用した手法及び意思決定の総体」をテスト戦略と記述。「テストを実行する時の具体的な方針、技法、プロセス、方式」はテスト戦術として、テスト戦略と区別している。
プロジェクトを成功させるためのテストプロジェクトの戦略を、テスト戦略と呼称している。環境確保、予算の工夫など広い範囲のマネジメントの工夫もテスト戦略に含む。

JSTQB,ISTQB,「Advanced Level シラバス日本語版テストマネージャ」

【解説の詳細度】★★★
【解説目的】定義解説、グッドプラクティス解説
【遂行手段】スケジュール・リソース、テストプロセス、テスト設計、テスト実装
【特徴や留意点など】
「テスト戦略は、組織の一般的なテスト方法を記述している。プロダクトおよびプロジェクトのリスクマネジメント、テストレベルへの分割、およびテストに関する上位の活動を含む」と呼称。
テスト戦略は、複数のプロジェクトに横断的に適用できる、普遍的・一般的なテスト活動の工夫と定義している。特定プロジェクトに限定されない、組織横断的な知見であることが判断基準で、テスト戦略が扱う活動に縛りは設けていない。テスト技法の選択、自動化ツールの導入、コンサルの活用など様々なものをテスト戦略として紹介している。
本書はテスト戦略の参考文献として、引用されていることが多い。

「ソフトウェアPRESS vol.5」

【解説の詳細度】★★★
【解説目的】定義解説、グッドプラクティス解説
【遂行手段】スケジュール・リソース、テストプロセス、テスト設計
【特徴や留意点など】
「テスト戦略とは、テストがうまくいくようにテスト設計の方法（アプローチ）や考え方をまとめ上げることです」と記述。
テストレベルの分け方の工夫、リソース配分、テスト設計技法の選択など、リソースの割り当て、テストの段取り、テスト設計が主な内容。そのほか、レビューや設計のコーディネートなど、他の関連活動の戦略もテスト戦略で扱っている。

ソフトウェアテスト実践ワークブック

【解説の詳細度】★★★
【解説目的】定義解説、グッドプラクティス解説
【遂行手段】テスト設計
【特徴や留意点など】
「テストによりプロジェクトにどんな利益がもたらされるか」というテスト目標をインプットとして策定した、「テストの指針となる原則とアイデア」がテスト戦略と記述している。
テスト設計をうまくするための、テストの十分性基準の設定と、テスト設計の段取り・技法選択が主な内容である。

「TPI NEXT ビジネス主導のテストプロセス改善」

【解説の詳細度】★★
【解説目的】グッドプラクティス解説
【遂行手段】スケジュール・リソース、テストプロセス、テスト設計
【特徴や留意点など】
「テスト戦略とは、工数やリソースをテストプロセスへ最適に割り振るための指針である。テスト戦略には、テストにかける工数の分配と、テストする箇所のカバレッジやテスト対象の側面について定義する」と記述。
定義は独自のもの。TPI NEXTはテストの活動をキーエリアという要素に分割している。本書のテスト戦略はそのキーエリアの一つであるが、他書のテスト戦略に含まれるテスト設計や組織、計画などの戦略は、他のキーエリアに分離されている。

「ソフトウェアテスト　293の鉄則」

【解説の詳細度】★★
【解説目的】定義解説、グッドプラクティス解説
【遂行手段】テスト設計
【特徴や留意点など】
「テスト戦略とは、テスト設計の指針をまとめたものを指している」と記述。「テスト戦略」に、プロジェクトのリソースやスケジュールの工夫といったマネジメントの計画は含まれない。
良いテストを作るためのテスト設計のやテスト設計プロセスの戦略を、テスト戦略と呼称している。
本書はテスト戦略の参考書籍として、引用されていることが多い。

「ソフトウェア品質保証の考え方と実際」、「ソフトウェア品質保証入門」

【解説の詳細度】★★
【解説目的】事例解説、グッドプラクティス解説
【遂行手段】テストプロセス、テスト設計
【特徴や留意点など】
内容が重複しているので二冊をまとめる。前者が詳細本、後者が入門本と位置づけられているが、テスト戦略に限っては、後者のほうが解説が多い。
良いテストを作るためのテスト設計の戦略を、テスト戦略と呼称している。
テスト設計と、テスト設計を主観点にしたプロセスの戦略が中心。本書ではレビューをテストの一部（机上テストと呼称）としているため、テスト戦略にレビューの戦略も含まれる。

「事例とツールで学ぶHAYST法」

【解説の詳細度】★★
【解説目的】定義解説、グッドプラクティス解説、事例解説
【遂行手段】テストプロセス、テスト設計、テスト実装
【特徴や留意点など】
政略と戦略の２つの用語を区別して使い分けている。戦略は英語のStrategyと対応付ける事が多いと思うが、本書は、政略にPrinciple・Policyを、戦略にPersonnel・Planを対応付けている。
良いテスト作るためのテストプロジェクトの戦略を、テスト戦略と呼称している。
テスト戦略はテスト設計と、テスト設計プロセスの戦略が主だけれど、他部署との連携などマネジメントの戦略も含んでいる。

「ソフトウェアテスト見積りガイドブック」

【解説の詳細度】★★
【解説目的】グッドプラクティス解説
【遂行手段】スケジュール・リソース、テストプロセス、テスト設計、テスト実装
【特徴や留意点など】
「ソフトウェアの重要な部分を特定したうえで、品質をどこまで確保し、そのためにテストにどれだけの資源を投入するか、また投入する資源をどう使うかといった方針」をテスト戦略と呼称。
戦略に対応する英語にはApproachを挙げている。
テストの解説というより見積もりの解説の書籍である。ただ見積もりの分析材料としてテスト戦略を重視しているため、全体に渡って戦略への言及がある。

「自動ソフトウェアテスト」

【解説の詳細度】★★
【解説目的】グッドプラクティス解説
【遂行手段】スケジュール・リソース、テストプロセス、テスト設計
【特徴や留意点など】
テスト戦略を、欠陥予防戦略と、欠陥検出戦略の2つで構成している。両方共プロジェクト全体の活動を含む。欠陥予防戦略は、早期のテスト関与、標準ガイドラインの活用、レビューなどを扱う。欠陥検出戦略はレビュー、テスタビリティの作り込み、テスト自動化、リスクアセスメントなどを扱う。
テスト戦略に、テスタビリティの作り込みと言った設計・実装の工夫が含まれるのが特徴。

「ソフトウェアのテスト技法（計算機科学/ソフトウェア技術講座）」

【解説の詳細度】★★
【解説目的】グッドプラクティス解説
【遂行手段】テストプロセス、テスト設計
【特徴や留意点など】
「単体テスト、結合テストなどテストの作業段階の設定を含め、どのような順序でプログラムの構成要素をテストしていくかを定める」ことをテストの戦略と記述している。
テストレベル・テストフェーズの策定、結合テストのアプローチ、テストの実施準備など、テスト実施の段取りの話が中心。

ソフトウェアテストを改善する50の実践手法

【解説の詳細度】★★
【解説目的】グッドプラクティス解説
【遂行手段】スケジュール・リソース、テストプロセス、テスト設計、テスト実装
【特徴や留意点など】
「テスト戦略は○○である」という定義の説明はない。ただ「テスト目標を最も有効な方法で達成する助け」「所定の目標を達成するために、テスト・チームが遂行すべき非常に具体的なアクティビティが含まれる」なものがテスト戦略と説明される。
テスト戦略は、テストプロジェクトを成功させるための戦略全般を指す。テストプロジェクトのリスクマネジメントが中心である。

バイザー本「実践的プログラムテスト入門」 , 「ソフトウェアテスト技法」

【解説の詳細度】★
【解説目的】グッドプラクティス解説
【遂行手段】テスト設計
【特徴や留意点など】
著者が同じで言葉遣いが似ているため２冊をまとめる。
「テストスイートに含めるテストケースを選択/生成するためのシステマティックな方法」をテスト戦略と記述。
良いテストを作るためのテスト設計の技法やアプローチを「テスト戦略」と呼称している。テスト戦略とテスト設計技法を同等のものとして扱っているのが特徴的。
なお「ソフトウェアテスト技法」ではテストのための開発の戦略も解説しているが、テスト戦略とは区別されている。

「ソフトウェアテストと品質保証の実際」

【解説の詳細度】★
【解説目的】事例解説
【遂行手段】テストプロセス、テスト設計
【特徴や留意点など】
色々な会社のテストや品質保証の事例をまとめた書籍。
「戦略」は開発を含めて包括的に解説されていたり、他の用語（アプローチ等）に置き換わっていたりするので、本書では「テスト戦略」という言葉はあまり出てこない。ただテスト戦略に該当する活動の解説は複数ある。
日立の事例でのテスト戦略として、前述の「ソフトウェア品質保証の考え方と実際」とほぼ同じ解説が行われている。
アクセンチュアの事例で、「各テストステージ（JSTQBでいうテストレベル）の範囲、テストプロセス、役割と責任、必要となるMetricsを明確に定義する」のがテスト戦略と解説されている。

「ソフトウェアテストの技法第２版」

【解説の詳細度】★
【解説目的】グッドプラクティス解説
【遂行手段】テスト設計
【特徴や留意点など】
良いテストを作るためのテスト設計の戦略を、「テストの戦略」と呼称している。
テストの戦略として、ホワイトボックステストとブラックボックステストを挙げている。内容はテスト設計のみ。バイザー本と同じく、テスト設計技法とテスト戦略を区別していないように見える。ただ、テスト設計技法の書籍なのでたまたまそうなっているだけかもしれない。

「基本から学ぶテストプロセス管理」

【解説の詳細度】★
【解説目的】グッドプラクティス解説
【遂行手段】スケジュール・リソース、テストプロセス、テスト設計、テスト実装
【特徴や留意点など】
「テストの戦略とは、できるだけ多くのバグを突き止めて識別するための全体的な計画」と記述。テスト戦略の範囲は広く、要員確保などリソースマネジメントの戦略も包含。
プロジェクトを成功させるための、テストプロジェクトの戦略をテスト戦略と呼称している。
「テスト戦略」の言葉の解説は少ない。ただ書籍全体がテスト戦略のグッドプラクティスの解説を行っているような内容で、今回のテーマにとっては重要度が高い本だと思う。

「体系的ソフトウェアテスト入門」

【解説の詳細度】★
【解説目的】グッドプラクティス解説
【遂行手段】スケジュール・リソース、テストプロセス、テスト設計、テスト実装
【特徴や留意点など】
プロジェクトを成功させるためのテストプロジェクトの戦略を「テストの戦略」と呼称している。
テスト戦略には、誰がテストするか、トレーニングをどうするかといった、マネジメントの要素を含む。直接的な説明は少ないが、テスト戦略に該当する活動の解説は結構ある。

「基本から学ぶソフトウェアテスト」

【解説の詳細度】★
【解説目的】グッドプラクティス解説
【遂行手段】スケジュール・リソース、テストプロセス、テスト設計、テスト実装
【特徴や留意点など】
まとまった解説はなく、散発的にテストの戦略という言葉を使っている。プロジェクトを成功させるための、テストプロジェクトの戦略全般をテスト戦略と呼称しているようだ。

「ソフトウェアテストHAYST法入門」

【解説の詳細度】★
【解説目的】グッドプラクティス解説、事例解説
【遂行手段】テストプロセス、テスト設計、テスト実装
【特徴や留意点など】
良いテストを作るための、テスト設計と、テスト設計プロセスの工夫を「テストの戦略」と呼称している。ただ戦略がテスト設計の話ばかりなのは、テスト設計手法の解説本なのでたまたまそうなっている可能性もある。
同じ著者の方の別のHAYST法の本で、テスト戦略の解説が行われている。

「現場の仕事がバリバリ進むソフトウェアテスト手法」

【解説の詳細度】★
【解説目的】用語解説、グッドプラクティス解説
【遂行手段】テストプロセス、テスト設計、テスト実装
【特徴や留意点など】
「テスト全体の活動のバランスを考えるのがテスト戦略です」「テスト戦略とは、品質目標達成のために、どうテストを進めれば市場に出てはいけない重大なバグを『できるだけ早く、できるだけ低コストで発見する』ことができるかを決めることです」と記述。
プロジェクトを成功させるためのテストプロジェクトの戦略を、テスト戦略と呼称している。テスト戦略には、ミーティング方針などの開発チームとの連携の戦略や、見積もりの戦略も含まれる。
なおプレゼン資料なので今回含めていないが、著者の方がテスト戦略についての講演資料を公開している（http://www.jasst.jp/archives/jasst10s/pdf/S1.pdf）。こちらは「テスト戦略とは何か」をダイレクトに解説している資料で、今回のテーマを学ぶなら必読だと思う。

「ステップアップのためのソフトウェアテスト実践ガイド」

【解説の詳細度】★
【解説目的】用語解説、グッドプラクティス解説
【遂行手段】テストプロセス、テスト設計
【特徴や留意点など】
大辞泉の戦略の解説を引用し、それに準拠している。その定義にもとづいて、テストプロジェクトの戦略をテスト戦略と呼称。
戦術と戦略の区別を重視している。「ツールによる自動化」「リソース不足解消のための人員追加」「テスト設計技法の選択」といったものはテスト戦術であり、テスト戦略に含めるべきでないと記述している。

「ソフトウェア品質知識体系ガイドV2」

【解説の詳細度】★
【解説目的】グッドプラクティス解説
【遂行手段】テストプロセス、テスト設計
【特徴や留意点など】
解説はISO/IEC29119を紹介するのみ。一応の引用としてISO/IEC 29119はOrganizational Test StrategyとTest Strategyの2つを提示している。後者は「part of the Test Plan that describes the approach to testing for a specific test project or test sub-process or sub-processes」と記述している。ここにはテスト設計だけでなく、ツールや環境の戦略も含まれる。
（このBOKは日本でのテストの話題を結構網羅しているので）意外だったが、テスト戦略の定義や解説はほぼなかった。

実践アジャイルテスト

【解説の詳細度】★
【解説目的】グッドプラクティス解説、事例解説
【遂行手段】テストプロセス、テスト設計
【特徴や留意点など】
「戦略は長期の行動計画」と記述している。複数のプロジェクトで共通なテストのプロセス・戦略をテスト戦略と呼称している。JSTQBと類似している。
テスト戦略には、テストレベル、テストパラダイム、ツール、環境など、テストのエンジニアリングプロセス全般が含まれる。
テスト戦略についての直接的な解説は少ないが、アジャイルテストにおける、テスト戦略に該当する活動についての解説を全体に渡って行っている。

継続的デリバリー

【解説の詳細度】★★
【解説目的】グッドプラクティス解説、事例解説
【遂行手段】テストプロセス、テスト設計
【特徴や留意点など】
テスト解説本ではないが、テスト戦略の具体例の解説が充実しているためおまけとして掲載。
「テスト戦略の設計は、プロジェクトのリスクを識別して優先順尾をつけ、それを緩和するためにどんなアクションを取ればよいかを決定するプロセス」と記述。
良いテストを行うための、テストプロジェクトの戦略をテスト戦略と呼称。

2017-08-05

優先度上限プロトコルによる優先度逆転の回避・リソース共有効率化

　並行処理での優先度逆転の回避や効率性改善の実現手段として、優先度上限プロトコルがあります。優先度上限プロトコルは、リソースをロックしたプロセスの優先度を上限値に引き上げる仕組みです。
　今回はTOPPERS/ASP3での実装を例に、簡単な解説を書きたいと思います。

優先度上限プロトコルを使用しない実装

　優先度上限プロトコルは、シングルタスクのRTOSですと動きが明快です。そのためシミュレータが提供されていてPCで簡単に動かせるRTOS、TOPPERS/ASP3で動作確認します。

　今回は、基本的に前エントリ「TOPPERS/ASP3をシミュレータで動かす & タスクを実装する - 千里霧中」に追加変更を加えたコードを用います。環境構築やコンフィギュレータの操作はそのエントリを参照ください。
　まずは比較対象として、優先度上限プロトコルを用いない版を説明します。

実装

　前述エントリと同じく、TASK_HOGE、TASK_HIGH_HOGEの２つのタスクを用意します。タスク優先度は、TASK_HIGH_HOGE > TASK_HOGE です。
　そのタスクのコンフィギュレーション設定は、例えば以下のように記述します。

CRE_TSK(TASK_HOGE, { TA_NULL, 10, task_hoge, 5, STACK_SIZE, NULL });
CRE_TSK(TASK_HIGH_HOGE, { TA_NULL, 11, task_highlevel_hoge, 4, STACK_SIZE, NULL });

　次にタスクの実装です。今回は、メインタスクがTASK_HOGEをウェイクアップし、そのTASK_HOGEは途中でTASK_HIGH_HOGEをウェイクアップする動作を実装します。
　まずメインタスクに以下のウェイクアップ処理を追記します。

act_tsk(TASK_HOGE);
act_tsk(TASK_HIGH_HOGE);
for (i = 0; i < task_loop; i++);
wup_tsk(TASK_HOGE);

　TASK_HOGEの実装は以下の通りです。

void task_hoge(intptr_t exinf)
{
  while (true) {
    slp_tsk();
    syslog(LOG_INFO, "hoge");
    wup_tsk(TASK_HIGH_HOGE);    
    syslog(LOG_INFO, "hoge end");
  }
}

　TASK_HIGH_HOGEの実装は以下の通りです。

void task_highlevel_hoge(intptr_t exinf)
{
  while (true) {
    slp_tsk();
    syslog(LOG_INFO, "high hoge");
    syslog(LOG_INFO, "high hoge end");
  }
}

動作

　上記のサンプルを動かすと、以下のログ出力が得られます。

hoge
high hoge
high hoge end
hoge end

　コンフィギュレーションで指定したタスク優先度の通り、TASK_HIGH_HOGEをウェイクアップしたタイミングで、実行タスクがTASK_HOGEからTASK_HIGH_HOGEにスイッチしているのがわかります。

優先度上限プロトコルを使用する実装

　次に優先度上限プロトコルを使用した例です。今回は、TASK_HOGEがTASK_HIGH_HOGEをウェイクアップする際、優先度上限プロトコルを設定したミューテックスMTX_RESOUCEをロックするように実装します。
　まずコンフィギュレーションの記述です。ミューテックスMTX_RESOUCEの設定を追加します。MTX_RESOUCEの優先度上限は全タスク中最高の値を指定します。

CRE_TSK(TASK_HOGE, { TA_NULL, 10, task_hoge, 5, STACK_SIZE, NULL });
CRE_TSK(TASK_HIGH_HOGE, { TA_NULL, 11, task_highlevel_hoge, 4, STACK_SIZE, NULL });
CRE_MTX(MTX_RESOUCE, { TA_CEILING, 1 });

　そしてタスク実装です。最初の実装例のうち、TASK_HOGEを以下のように変更します。MTX_RESOUCEのロック制御処理を、TASK_HIGH_HOGEウェイクアップ前後に追記しています。

void task_hoge(intptr_t exinf)
{
  while (true) {
    slp_tsk();
    syslog(LOG_INFO, "hoge");
    loc_mtx(MTX_RESOUCE);
    wup_tsk(TASK_HIGH_HOGE);    
    syslog(LOG_INFO, "hoge end");
    unl_mtx(MTX_RESOUCE);
  }
}

動作

　上記のサンプルを動かすと、以下のログ出力が得られます。

hoge
hoge end
high hoge
high hoge end

　MTX_RESOUCEのロックを開放するまで、TASK_HIGH_HOGEのタスク実行が行われないことがわかります。ロック中、TASK_HOGEの優先度がTASK_HIGH_HOGEを上回っているということです。

優先度上限プロトコルの用途

　マルチタスクでの優先度設定は、一般的にタスクごとの優先度設定で行います。優先度上限プロトコルは、それに加えて、リソースごとの優先度設定を可能にする仕組みとも解釈できます。
　優先度上限プロトコルの主用途は、優先度逆転の防止です。これによりデッドロックの回避等を行います。
　また、リソース占有時間の最適化にも用いられます。例えばノンプリエンプティブならば、特定のリソース専有中での無用なコンテキストスイッチやタスク中断を抑止します。一般的ではないですが、プリエンプティブで、特定のリソース専有処理を早く処理させるために活用しているところも見たことがあります。
　優先度上限プロトコルはPOSIXスレッドのサポートが有名です。特にPOSIX準拠のRTOSでは活用の余地があります。

　なお「リソースごとの優先度設定を可能にする」というと聞こえは良いのですが、マルチプロセスで常用されているわけではありません。以下のような制約を持つためです。

タスクの優先度を動的に変えてしまうので、マルチタスクの設計をかえって複雑化させる場合があります。まず優先度上限プロトコルを使用しなくても良いようにタスク設計を工夫したほうが良いことがあります（タスクが使用するリソースを限定的に、リソースが紐づくタスクを限定的に）。
ラウンドロビンなどのプリエンプティブなスケジューリング（よくある典型がPOSIXを使う組み込みLinux）では、メリットをどこまで得られるかが不透明です。例えばロック時間の短縮を意図しても、具体的にどこまで時間短縮できるかが見積もりが難しいです。そのためラウンドロビンでの活用は少ないです。デッドラインの遵守などには、タスク単位の割り込み制御、CPUアフィニティの設定、FPGA・他プロセッサへの切り出し等など、別対策に頼らざるを得ない場合が多いです。

　もちろん上記の制約は状況によります。例えば重要なクリティカルセクション１、２個程度に限定して優先度上限プロトコルを適用することで、マルチタスク設計を簡略化できる場合もあります。また優先度逆転を事前のコンフィギュレーションで防止できるのが便利な状況もあります。

使い方

その他の使い方

用語

各用語の関係性

各用語の具体例

Concernの例

Viewpointの例

Viewの例

活用

環境設定とインストール

機能の概要

1. FreeMindでクラシフィケーションツリーを表現する。

2. Freemindのツリーを読み込む

3. ツリー結果をPICTに入力し、テスト条件リストを生成する。

コード完成形

テスト設計コンテストとは

テスト設計コンテストで得られるメリット

●自分達のテスト設計に対して、様々な改善アドバイスをもらえる。

●テスト戦略やテスト設計の型と実例を学べる

●優勝すると、テストのコミュニティで名声が得られる場合がある

●テスト設計の楽しみを感じられる

募集について

リストアップの対象

前置き：推薦図書

前置き：リストアップした書籍の全体の傾向

前置き：凡例

テスト戦略を解説した書籍（タイトルが詳細へのリンクになっています）

「ソフトウェア品質保証の考え方と実際」 、 「ソフトウェア品質保証入門」

バイザー本 「実践的プログラムテスト入門」 , 「ソフトウェアテスト技法」

優先度上限プロトコルを使用しない実装

実装

動作

優先度上限プロトコルを使用する実装

動作

優先度上限プロトコルの用途

「ソフトウェア品質保証の考え方と実際」、「ソフトウェア品質保証入門」

バイザー本「実践的プログラムテスト入門」 , 「ソフトウェアテスト技法」