テスト観点とは

　テスト設計で「テスト観点」という言葉がよく使われるのですが、意味が広く、議論の発散の要因になりがちと感じています。そこで、今回は「テスト観点」の用語について、前提の「観点」の用語とともに簡単に解説したいと思います（いろいろな定義付けがされている言葉なので、あくまで筆者の見解になります）。

観点とは

　まず「観点」という用語ですが、これは「着目したい特質・側面の方向性」という意味付けの言葉です。
　例えば椅子について考える場合ですと、「上から見たらどう観えるか」「前から見たらどう観えるか」といったものが観点になります。また空間座標的なものに限らず、次のようなものも観点に該当します。

  • 重さはどうか、材質はどうか、耐用年数はどうか
  • ●●の規格に適合しているか
  • ●●のレビューサイトでの評価はどうか

　このように観点には多種多様なものがあります。

　なお観点を愚直に表現すると長くなるので、しばしば観点は単語に省略表記されます。例えば「重さはどうか」「材質はどうか」「耐用年数はどうか」といった観点は、観点のモデリングなどでは「重さ」「材質」「耐用年数」と省略表記される場合がよくあります。

観点の用途

　観点の用途として、主に以下の2つがあります。

  1. 対象の側面・特質を観察・分析するために使われる
    • 例えば、ソフトウェアを作ろうとする際に、作りたいソフトウェアを表現するために、複数の観点を用います。
  2. 側面・特質の観方を明示するために使われる
    • 例えば、テストエンジニアのテスト設計のノウハウを明示化する際に、対象者の特質を明示するため、対象者の観点を抽出します。

観点の導き方

　観点は、目的と制約に沿って導かれ、使用されます。

目的に基づいた観点の選択

　まず観点は目的に沿って選ばれます。
　例えば「大きな椅子を部屋に運び込めるか明らかにする」という目的があるとします。
　この目的を詳細化すると例えば「椅子がドアの枠内に入るか明らかにする」という目的が出てきます。するとその目的達成手段の検討のために、「椅子の高さはどれぐらいか」「椅子の横幅はどれぐらいか」という観点が導かれます。
　また詳細化で「椅子を手で運べるか明らかにする」という目的が出てきます。するとその目的達成手段の検討のために、「椅子の重さはどれぐらいか」という観点が導かれます。

　このように目的達成の手段の検討を支えるため、観点が導出されます。

制約に基づいた観点の選択

　一方、観点は制約に見合うように選択・整理されます。

　ここでいう制約の代表的なものとして、時間・人・コストなどのリソース制約があります。観点は無数にありますが、リソースは有限です。リソースに見合うように、観点を整理・絞り込む必要があります。
　また観察者の限界もあります。観点が増えすぎると、人間が認知できる限界を超え、観察や分析が困難になります。すなわち観察者が扱えるまで、観点を整理・絞り込む必要があります。
　「整理・絞り込み」には、次のアプローチが使われます。

  • 必要性の低い観点を捨てる
  • 抽象化する
  • 関心ごとの分離を行って、分けて考えられるようにする
  • 構造化などの整理を行って扱いやすくする

観点を組み合わせる

　一定以上の複雑さを持つ目的に対応する場合、多数の観点の組み合わせが求められます。
　例えば「立体の椅子の形状を把握する」ことを目的とする場合、正面から見る観点だけでは目的を果たせません。前、上、下、右、左、後の6面と、複数の観点を組み合わせる必要があります。
　より複雑な目的に対応しようとすると、必要な観点は更に増えます。例えば「椅子を製造する」という目的ならば、立体形状だけでなく、重さ、材質、加工方法、コスト、材料の納入見込み、耐用年数、製品の品質のばらつきといった観点の検討も必要になります。
　こうした観点の爆発に対しては、観点の抽出過程の段階でも、最終的な観点の成果物表現の段階でも、前述の削減・抽象化・分割・整理が求められてきます。

観点を導くためのインプット

　観点は様々なインプットを使って導き出されます。

　まず観る対象の特質を抽出し、そこから観点をピックアップするアプローチがあります。例えば後述するテスト観点については、テスト対象を記載したテストベースから情報を分析し、テスト設計の観点に反映する場合があります。

　また外部から観点を持ってくるアプローチもあります。
　よくあるのが観る者の知見に基づいた観点です。「過去の失敗経験に基づいて失敗リスクの高い特質に着眼する」「長年学んできた膨大な知見に基づいて、有効な観点を総合的にピックアップする」「作業している中で感じた気がかりを観点にする」といったアプローチは普遍的に採用されます。
　また、外部の形式知を使うアプローチも一般的です。形式知とは、グッドプラクティス、パターン、標準といったものです。ソフトウェア開発ですと、仕様から設計構造を見出すためのGRASPパターンや、ISO25010の品質特性といったものが該当します。なお外部の形式知から観点を導入する際は、対象に合わせた取捨選択やテーラリングが求められるのが一般的です。

テスト観点とは

　次に本題のテスト観点についてです。
　テスト観点は、テストの活動で使われる観点です。

　様々なテストの活動に対応して、様々なバリエーションがあります。例えば次のようなものがあります。

  • テストの計画や戦略を検討するための観点（観点の対象：テストの計画や戦略）
  • テストのニーズ・シーズからテストの要求を分析するための観点（観点の対象：定義されたテスト要求）
  • テストベースから必要なテストを見つけ出すための観点（観点の対象：テストケース）

　例えば「テストベースから必要なテストを導くための観点」ですと、具体例としては以下のようなものが該当します。

  • ログイン機能のふるまいと仕様書の記載の合致性のテストは必要ないか？
  • 通信過負荷時の動作の確認は必要ないか？
  • APIの処理速度のテストは必要か？

　どれも「テスト観点」と省略されて語られる場合があります。会話の混乱のもとになりがちなので、具体的な意味付けを行いたい場合は、「テスト観点」が具体的にどの観点について語っているか明確化した方が無難です。

一般的なテスト観点の用例

　なお一般的にテスト観点というと、「テストのインプット（テストベースなど）から、テストケースを導くために用いる、テストすべき特質や側面」を指す場合が多いです。この観点は、以下の２つに分類されます。

  • 目的(What)から目的達成手段（HowTo）への転換の切り口（例えば、要求を実装へ転換するための取っ掛かり）
  • 抽象的・曖昧なテストケースから具体的なテストケースへ設計する手段

　前者は、テスト分析の切り口です。Ostrandの4つのビュー、企業が公開しているテスト観点表など、形式知化されている観点が代表例になります。後者も包含します。
　後者は、いわばテストの意図です。ここではテスト観点とテストケースが全射の関係を持ちます。十分にブレークダウンされたテスト観点はテスト条件として扱えます。

2軸4象限でフロントローディングの方針立てを整理する

　テストクラスタでフロントローディングがよく話題になるようになっています。これに関して、作業や課題を2軸4象限で整理すると検討を整理できる場合があります。チームで課題を話し合うときの議論の整理といった、簡易的・アドホックな使い方限定のプチフレームワークですが、今回その整理方法について触れたいと思います。

2軸4象限

　整理に用いる2軸は次の通りです。

  1. 早期にやるべきかの必要性（あるいは重要性）：
    • 早期にやるべきか、早期にやらなくてよいか(後回ししてもよいか)
  2. 早期にできるかの実現性：
    • 早期にできるか、早期にできないか

　これを図にして、次のような4象限マトリクスにします。それぞれA、B、C、Dの象限を割り当てます。

f:id:goyoki:20190922013034p:plain

※一般的な必要性（or重要性）と実現性のマトリクス分析を、フロントローディングに適用したものになります。

　おおよそですが、それぞれの象限ごとに、フロントローディングを進めるにあたっての対応方針が異なってきます。

4象限ごとのフロントローディングの対応方針

A、B、C、Dに対し、フロントローディングを進めるにあたっては次のような方針立てを行います。

「D：後回しにしてよい&早期からできる」の対応方針

  • Dの作業の例
    • 後のプログラミングで検討しても支障のない、詳細なIF仕様の設計など
  • Dに対する方針
    • 該当作業は、重要度と余裕に応じて実施します。後回しにするなら、いつ実施するか方針立てします。
    • このDに属する作業については、早めに処理する方針を立てれば、後の余裕を確保できます。ただやり直しや陳腐化のリスクの点で、B象限とA象限対応を優先する方が無難な場合があります。

「C：後回しにしてよい&早期からできない」の対応方針

  • Cの作業の例
    • 顧客リリース物のチェックなど
  • Cに対する方針
    • 後回しで実施します。Cに属する作業については、後々実施すべきタイミングで確実に実施できるように、中期的な方針立てを実施します。

「B：早期にやるべき&早期からできる」の対応方針

  • Bの作業の例
    • プロジェクト成否へのインパクトの大きいリソース確保の調達計画など
  • Bに対する方針
    • 重要度に応じて、実施します。Bに属する作業については、該当する作業をきちんと識別して確実に実施する方針を立てるのが重要です。

「A：早期にやるべき&早期からできない」の対応方針

  • Aの作業の例
  • Aに対する方針
    • フロントローディングにあたって、知恵を絞って方針を工夫する対象です。3つの方針で対応していきます。
      1. 早期にできるようにして、B象限に移動させる
        • e.g. 未知未経験で早期に実施できない → 反復開発やプロトタイプで早期に実践経験を積んで、未知未経験を早期に解消する
      2. 後回しできるようにして、C象限に移動させる
        • e.g. 要求が未確定なために早期に実施できない場合 → 想定される要求を数パターン設定し、それらに対応できるように、外部インターフェースに可変点を設ける
      3. ステークホルダと調整してスコープ外にする

　全体の対応方針ですが、フロントローディングの推進ではA象限、B象限への注力が重要になります。逆にC、D象限の前倒しで時間を浪費して、本質的なA、B象限がおざなりになることも多いです。

アーキテクチャ設計での例

　フレームワークの使い方は主に次の2パターンです。

  1. 識別した作業の方針立て
    • 課題や作業を識別した後、それらがこの4象限のどこに分類されるのか考えることで、方針を考えます。
  2. 課題や作業を分析するための観点
    • 4象限を観点にして、課題や作業を分析します。

　アーキテクチャ設計を例にとると、チームメンバーで、アーキテクチャドライバを観点にして課題を出し、課題を重要度と4象限で分類して、フロントローディングの対応方針を立てるといった使い方をします。

Jenkinsfileを構造的に整理する

　Jenkins PipelineのJenkinsfileでテスト並列実行を最適化する - 千里霧中 つながりの話です。Jenkinsfileでは、groovyの構文を活用してJenkins Pipelineの実装を整理できます。

処理をメソッドとして抜き出す

　まずJenkinsfileではメソッドやクラスを任意に定義可能です。これにより重複する記述をメソッドにまとめるといったことが可能になります。
　例えば以下のJenkinsfileを例とします。

pipeline { 
  agent any 
  stages {
    stage('Test') { 
      steps {
        parallel 'run_test':{
          node('node1') {
            println 'run test code'
          }
          node('node2') {
            println 'run test code'
          }
        }
      }
    }
  }
}

　仮に「println 'run test code'」が長大な重複コードとすると、Jenkinsfileでは次のようにメソッドrun_test_code()としてまとめられます。

def run_test_code() {
  println 'run test code'
}

pipeline { 
  agent any 
  stages {
    stage('Test') { 
      steps {
        parallel 'run_test':{
          node('node1') {
            run_test_code()
          }
          node('node2') {
            run_test_code()
          }
        }
      }
    }
  }
}

Pipeline定義を動的に生成する

　Pipelineの定義はマップとして動的に生成することも可能です。ループ処理で定義の繰り返しを生成したり、条件分岐で定義を切り替えたりすることで、複雑なPipeline定義をシンプルなコードで実装できる場合があります。

　例えば以下のような重複の多いJenkinsfileを例に取ります。

//node1、node2でテスト並列実行
parallel 'node1' :{
  node('node1') {
    println 'run test code'
  }
, 'node2' :{
  node('node2') :{
    println 'run test code'
  }
}

これはfor文で以下のように重複部分をまとめられます。実行時の処理は前と同じです。

//node1、node2で並列実行
List node_list = ['node1', 'node2']
Map branches = [:]

for (int i = 0; i < node_list.size(); i++) {
  String node_name = node_list[i]
  branches[node_name] = {
    node(node_name) {
      println 'run test code'
    }
  }
}
parallel(branches)

ファイルを分ける

　Jenkinsfileは他ファイルのGroovyコードを呼び出せます。これにより、複数のJenkisfileの共通部分を外部モジュールとして切り出す、長大なJenkinsfileをファイル分割する、外部のライブラリを利用する、といったことが可能になります。

　例えば標準のJSONライブラリを使う場合は、次のような通常のimport構文で実装できます。

import groovy.json.JsonOutput
pipeline {
  agent any 
  stages {
    stage('Test') { 
      steps {
        parallel 'run test':{
          node('node1') {
            def hoge = JsonOutput.toJson([text : "dummy"])
            ...
          }
        }
      }
    }
  }
}

Jenkins PipelineのJenkinsfileでテスト並列実行を最適化する

　Jenkinsのpipelineを使うと、Jenkinsfileとしてジョブの定義・連携をGroovyで柔軟に記述できるようになります。そこでは例えば「変数を用いてノードやステージを横断する連携を実装する」「いろいろな外部スクリプトを実行して最適な実行条件を分析する」といった処理を容易に実装できます。

　今回はその具体例として、pytestのテスト実行時間の最適化を行うJenkinsfileを題材にします。

pytestのテスト並列実行の時間を最適化する

　対象は、pytestの2並列実行のジョブです。具体的には、Jenkins Pipelineで指定されたgitリポジトリから必要なファイルをチェックアウトし、その中のpytestのテストケースをノードサーバで実行して、結果をプッシュ＆ Jenkins Test Report出力する処理とします。実現にあたっては、（仮にテストケースが長大であるとして）ノードサーバを2つ用意し、テストを2分割してそれぞれのノードで並列実行させることで、テスト実行時間の短縮を狙います。

　このテストの2分割ですが、旧来の静的なジョブ定義では、テストケース数などで事前に静的分割せざるを得ない場合が多いです。一方でJenkins Pipelineを用いると、テスト実行時間が均等に分割されるように、テストケースを動的に2分割する処理を容易に実装できます。

Jenkinsfileの実装

　そのJenkinsfileの具体例を示します。ここでは以下を実装しています。

  • Prepareステージで、create_test_selection_file.py(実装例は後述)をシェル実行し、その標準出力をtest_selectionに格納します。
    • create_test_selection_file.pyは、テストケースファイルを、テスト実行時間が均等に2分割になるように2つにグルーピングし、結果をpytestの引数形式で標準出力するスクリプトです。過去のJUnit XML形式レポートからファイル名と実行時間のデータを抽出・集計することで実現します。
  • Testステージで、2つのノード：node1、node2にて、pytestのテストケースを並行実行します。pytestには、前ステージで得たtest_selectionを引数として指定します。
  • Reportステージで、pytestが生成したテストレポートファイルのプッシュと、Jenkins Test Reportへの出力を行います。

まとめると外に用意した集計スクリプトを呼び出して、ノードで実行するテストケースを動的に選択しています。

Jenkinsfileの実装例：

pipeline { 
    environment {
        test_selection = ""
    }
    agent any 
    stages {
        stage('Prepare') {
            steps {
                script {
                    def output = sh (
                        script: 'python create_test_selection_file.py',
                        returnStdout: true
                    ).trim()
                    test_selection = output.split(',')
                }
            }
        }
        stage('Test') { 
            steps {
                parallel 'automation test':{
                    node('node1') {
                        checkout scm
                        sh "pytest ${test_selection[0]} --junitxml=testresult/result1.xml"
                        sh "python push_test_report.py testresult"
                    }
                    node('node2') {
                        checkout scm
                        sh "pytest ${test_selection[1]} --junitxml=testresult/result2.xml"
                        sh "python push_test_report.py testresult"
                    }
                }
            }
        }
        stage('Report'){
            steps {
                git branch: 'main', url: 'git://hoge/integration-test.git'
            }
            post {
                always {
                    junit 'intagration_test/testresult/*.xml'
                }
            }
        }
    }
}
create_test_selection_file.pyの実装

　（主題ではないため簡易的なサンプルですが）例えば以下のようなものになります。

import glob
import xml.etree.ElementTree as ET
import numpy as np

NUMBER_OF_TESTNODE = 2

def select_test_by_time(test_files, resultfiles):
    test_result = {}
    all_time = 0.0
    for file in resultfiles:
        root = ET.parse(file).getroot()
        all_time += float(root.attrib['time'])
        for testcase in root.iter('testcase'):
            test_result[testcase.attrib['file']] = test_result.get(testcase.attrib['file'], 0) + float(testcase.attrib['time'])

    testsuite_time = 0.0
    node_no = 0
    output = ""
    for key, value in test_result.items():
        testsuite_time += value
        output += key + ' '
        if testsuite_time > all_time / NUMBER_OF_TESTNODE and node_no < NUMBER_OF_TESTNODE - 1:
            testsuite_time = 0
            output += ","
            node_no += 1
    output = output.replace('\\','/')
    print(output)

def select_test_by_number(test_files):
    test_group = list(np.array_split(test_files, NUMBER_OF_TESTNODE))
    output = ''
    for tests in test_group:
        output += ' '.join(tests) + ','
    output = output.replace('\\','/')
    print(output)

def create_test_selection_file():
    test_file = 'test/test*.py'
    input_file = 'testresult/*.xml'

    test_files = glob.glob(test_file)
    resultfiles = glob.glob(input_file)

    if resultfiles:
        select_test_by_time(test_files, resultfiles)
    else:
        select_test_by_number(glob.glob(test_file))

if __name__ == '__main__':
    create_test_selection_file()

atestcovでオールペア法での冗長なテストケースを見つける

ソフトウェアテスト #2 Advent Calendar 2018 - Qiitaの12/15の記事になります。

ATestCovの使い方の一例紹介です。

組み合わせテストツールATestCovを公開 - 千里霧中

atestcovを使って、テストケース削除時のnワイズカバレッジの変化を確認することで、nワイズテストにおける冗長なテストケースを検出できます。

pythonでのこの実装例を示します。
例は2ワイズカバレッジ（オールペア法）が対象です。テストケースを１つ削除した入力ファイルを全パターン生成し、atestcovで2ワイズカバレッジの変化を確認しています。
これにより、削除しても2ワイズカバレッジを下げないテストケースをピックアップします。

# check_2wise_testcase.py
'''指定されたテストケースのうち、削除しても2ワイズカバレッジを低下させないテストケースを検出する'''
import subprocess
import sys
import os
import re

def get_2wisecov(testcase_file, parameter_file):
    '''atestcovを実行し、2ワイズカバレッジ結果部分を抜き出す'''
    result = subprocess.check_output(f'atestcov.exe -t {testcase_file} -p {parameter_file}')
    return re.search('2wise coverage: ([0-9.]+)', result.decode('utf-8')).group(1)

def check_test(testcase_file, parameter_file):
    '''削除しても2ワイズカバレッジが変化しないテストケースをピックアップする'''
    origin_cov = get_2wisecov(testcase_file, parameter_file)
    print(f'2wiseカバレッジ:{origin_cov}%')

    with open(testcase_file) as f:
        lines = f.readlines()

    filename = 'temp.txt'
    for i in range(1, len(lines)):
        with open(filename, mode='w') as f:
            for index, line in enumerate(lines):
                if index == i:
                    remove_testcase = line.replace('\n', '')
                    continue
                f.write(lines[index])
        if get_2wisecov(filename, parameter_file) == origin_cov:
            print(f'-冗長なテストケース：{remove_testcase}({i+1}行目)')

        os.remove(filename)

if __name__ == '__main__':
    if len(sys.argv) != 3:
        print("実行引数：python check_2wise_testcase.py テストケースファイルパス パラメータファイルパス")
        sys.exit(1)
    check_test(sys.argv[1], sys.argv[2])

実行例として、次の入力ファイルを用意します。

テストケース定義ファイル：SampleTestCase.txt

麺,スープ
細麺,豚骨
太麺,豚骨
細麺,醤油
太麺,醤油
太麺,豚骨

パラメータ定義ファイル：SampleParameter.txt

麺:細麺,太麺
スープ:豚骨,醤油

実行コマンドは次の通りです。

python check_2wise_testcase.py SampleTestCase.txt SampleParameter.txt

すると次のような結果が得られます。

2wiseカバレッジ:100.00%
-冗長なテストケース：太麺,豚骨(3行目)
-冗長なテストケース：太麺,豚骨(6行目)

これにより、2wiseカバレッジを基準とした場合、テストケース定義ファイルの3行目あるいは6行目のテストケースが冗長なのが分かります。

ATestCovを使って、テストケースで網羅できていないパラメータ組み合わせを見つける

先日公開したATestCovの使い方の一例紹介です。

組み合わせテストツールATestCovを公開 - 千里霧中

ATestCovでは、実行時引数「--info」(-i)の付与で、テストケースで網羅できていないパラメータ組み合わせを検出できます。
実行例として、以下のファイルを入力して実行します。

SampleParameter.txt(パラメータ入力ファイル)
#パラメータと値の一覧
麺:細麺,太麺
スープ:豚骨,醤油,味噌
SampleTestCase.txt(テストケース入力ファイル)
#テストケース一覧
麺,スープ
細麺,豚骨
太麺,醤油
細麺,醤油

今回、この入力ファイルを用いて、テストケースで網羅できていない、2つのパラメータの組み合わせを調べます。
調べ方は、2ワイズカバレッジ（2因子間網羅率）計測コマンドに、「--info」を付与します。実行コマンドは次のようになります。

./atestcov --testcase SampleTestCase.txt --param SampleParameter.txt --upper 2 --lower 2 --info

すると、2ワイズカバレッジに加えて、次のように「[info]」ログが出力されます。

atestcov(ver.0.04) ***
[info]measurering:2wise coverage
 [info]uncover:麺:細麺  スープ:味噌  
 [info]uncover:麺:太麺  スープ:豚骨  
 [info]uncover:麺:太麺  スープ:味噌  

[coverage report]
number of test case: 3
number of parameter: 2
2wise coverage: 50.00%(3/6)

このうち「[info]uncover:」の行で表示された組み合わせが、テストケースで網羅できていない組み合わせです。例えば「細麺の味噌スープ」を、テストケースが網羅できていないと読み取れます。

特定の組み合わせを調査対象から外す

網羅できていない組み合わせをピックアップする際、特定の組み合わせはピックアップから除外したい場合があります（例えば禁則の組み合わせなど）。その際は排他制約の文をパラメータに追加します。

例えば「太麺の豚骨スープ」は網羅しなくてよいならば、次のように@mutexで明記します。

SampleParameter.txt(パラメータ入力ファイル)
#パラメータと値の一覧
麺:細麺,太麺
スープ:豚骨,醤油,味噌
#禁則
@mutex 麺:太麺, スープ:豚骨


すると、出力で「[info]uncover:麺:太麺 スープ:豚骨 」が表示されなくなります。

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

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

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 麺:硬め, あぶら:多め

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

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