atestcovでオールペア法での冗長なテストケースを見つける - 千里霧中
ソフトウェアテスト #2 Advent Calendar 2018 - Qiitaの12/15の記事になります。 ATestCovの使い方の一例紹介です。 組み合わせテストツールATestCovを公開 - 千里霧中 atestcovを使って、テストケース削除時のnワイズカバレッジの変化を確認することで、nワイズテストにおける冗長なテストケースを検出できます。 pythonでのこの実装例を示します。 例は2ワイズカバレッジ（オールペア法）が対象です。テストケースを１つ削除した入力ファイルを全パターン生成し、atestcovで2ワイズカバレッジの変化を確認しています。 これにより、削除しても2ワイズカバレッジを下げないテストケースをピックアップします。 # check_2wise_testcase.py '''指定されたテストケースのうち、削除しても2ワイズカバレッジを低下させないテストケース
ATestCovを使って、テストケースで網羅できていないパラメータ組み合わせを見つける - 千里霧中
先日公開したATestCovの使い方の一例紹介です。 組み合わせテストツールATestCovを公開 - 千里霧中 ATestCovでは、実行時引数「--info」(-i)の付与で、テストケースで網羅できていないパラメータ組み合わせを検出できます。 実行例として、以下のファイルを入力して実行します。 SampleParameter.txt(パラメータ入力ファイル) #パラメータと値の一覧 麺:細麺,太麺 スープ:豚骨,醤油,味噌 SampleTestCase.txt(テストケース入力ファイル) #テストケース一覧 麺,スープ 細麺,豚骨 太麺,醤油 細麺,醤油今回、この入力ファイルを用いて、テストケースで網羅できていない、2つのパラメータの組み合わせを調べます。 調べ方は、2ワイズカバレッジ（2因子間網羅率）計測コマンドに、「--info」を付与します。実行コマンドは次のようになります。 .
組み合わせテストツールATestCovを公開 - 千里霧中
組み合わせテスト設計の補助用に、nワイズカバレッジを計測する簡易的なツールATestCovをリリースしました。 ATestCovユーザマニュアル リリースページ ツールの想定用途は、既存のテストケースの網羅度チェックや、組み合わせのばらつきの評価です。 計測対象のnワイズカバレッジは、テストケース中に、n個のパラメータ組み合わせがどれぐらい出現するかを、網羅率で示したものです。 具体的な公知のテスト技法との関係として、同値分割テストの網羅率では、1ワイズカバレッジを評価に用います。オールペア法（ペアワイズ法）や直交表技法の網羅率では、2ワイズカバレッジの網羅に重点を起きます。 使い方 使い方ですが、テストケース記述ファイルと、パラメータ記述ファイルを実行引数に指定して実行します。 パラメータ記述ファイルは、以下のようなテスト条件のパラメータと値を列記したファイルです（PICTの入力ファイル
ISO/IEC/IEEE 42010での「観点」関連の用語の定義・用例 - 千里霧中
テストでは観点という言葉が時々使われています。ただ結構曖昧な用語なので、議論すると話が発散しがちな印象を持っています。 そこでは体系だった標準を土台にすると発散を軽減できる場合があるのですが、テストの観点を語る上で使えそうな標準として、ISO/IEC/IEEE 42010があります。 ISO 42010は、アーキテクチャ設計を対象にConcern（関心事）、Viewpoint（観点）、View（側面）の定義や関係性を規定するものです。 この規格は書いてある通りに従えば良いというものではないものの、Viewpoint、Viewなどの言葉の定義の共有手段として使えます。 またアーキテクチャ設計についての文献では、ISO 42010に則った解説や、ISO42010との関係性を明記した解説が結構あります。そのためアーキテクチャ設計の観点を学ぶ際の前提知識としても有用です。 テスト観点についての議論
FreeMindからテストケースを自動生成するテストツールFMPictをリリース - 千里霧中
最近、FMPictというテスト設計自動化ツールを作りました。 https://github.com/hiro-iseri/fmpict FMPictは、FreeMindのモデルからテストケースを生成するテスト設計自動化ツールです（PICTを制御して実現しています）。nワイズカバレッジ(n:1～3)を100%網羅するテストケースを生成できます。オールペア法ツール、クラシフィケーションツリー法ツールとして利用可能です。 ツールは以下のメリットを持ちます。 マインドマップでテスト条件をモデリングできます。それにより、テスト条件の抽象構造やグルーピング構造をわかりやすく表現できます。 ツリーモデルの記法的制約（*）の回避手段として、リンク記法とタグ記法という機能を加えています。これによりツリーの重複をなくしたり、複数のツリーを一つのツリーにまとめて描いたりすることが可能です。 PICTをマインドマ
ツリーで分析するときはクラスベースでも考えよう - 千里霧中
以下でツリーモデルで物事を分析する難しさが少し触れられていたので、ツリーモデルの記法上の制約について書きたい(一応の前置きとして、今回書くのは主に記法上の制約のみで、ツリーによる分析の進め方にはあまり言及しない)。 http://togetter.com/li/1047939 クラシフィケーションツリー法等を使っていて、ツリーモデルで分析を行う際は、クラスベースモデルでも考えたほうが良い場合が多い。お互いメリット・デメリット両方あり、うまく補完しあえるためだ。 具体的には、複雑なis-aの関係性を持つもの、has-a/is-aの関係性が混在するものは、ツリーでは表現しにくいが、クラス図ではすっきり表現できることが多い。例えば具体例としては以下。 フィーチャモデルの描き方 from H Iseri 他にも、前述の例と似てるけれど、概念モデルでも設計モデルでもよく出てくるBridgeパターン
憂鬱なExcel作業をPythonで紛らわす - 千里霧中
自分の組み込み業界ではやたらExcelが多くて、Excelドキュメントのレビューの機会が度々ある。その中には、ファイル間のトレーサビリティ目視チェックといった、時に刺身タンポポと揶揄されるような気の滅入る作業も少なくない。 こういった作業は、周知の通りだと思うけれど、マイクロソフト系の言語や、Python、Rubyなど様々なプログラミング言語がExcel操作のライブラリを提供しているおかげで、自動化できることが多い。 そのため基本姿勢として自動化に手を付けてみるのは良いと思う。生産性が上がることが多いのもある。また何より、例えば「Excelの目視レビューでなく、Pythonのコーディングをしている」と思えば気を紛らわせられる、ような気がする。ソフトウェア開発者として精神衛生的に良い。 今回はその自動化の実現手段の一つとして、Pythonのopenpyxlを使ったExcelドキュメントのチェ
PyAutoGUIでGUIの自動操作 - 千里霧中
PyAutoGUIがシンプルでかなり使いやすかったのでメモ。 PyAutoGUIは、GUIの自動操作をサポートするPython用ライブラリ。マウス操作、キーボード操作、スクリーンキャプチャ、指定した画像のマッチングと座標取得などの機能を提供する。シンプルだけれど、自動操作に必要な機能がひと通り揃っている。 使用例として、GUI縛りのツールを自動操作させ、結果が得られたらその画面キャプチャを保存するスクリプトを載せる。 #-*- coding: utf-8 -*- #run_and_capture.py import pyautogui, time from datetime import datetime # 処理開始ボタンを探してクリックする position = pyautogui.locateCenterOnScreen('startbutton.png') #startbutton
キーワード駆動テストの導入 - 千里霧中
最近キーワード駆動テストがややバズワード化している傾向を感じている。というのも、キーワード駆動テストの導入で無用な手間を増やしている場面を見るようになっているためだ。 キーワード駆動テストはフレームワークによっては手間を増やすことがあるので、その導入にあたっては、導入内容が目的に見合っているか多少の注意を向ける必要があると感じる。基本的な事柄であえて言及する必要もない内容かも知れないが、今回はそれについて簡単に触れたい。 キーワード駆動テストの目的 言及するまでもないかもしれないけれども、何かしらの改善を行う際は、その手段が目的に見合っているか留意する必要がある。ではキーワード駆動テストの目的は何かというと、大雑把にまとめて以下の３つがある。なおこれは排他ではなく、一緒に目指しても良い。 目的(1)テストの保守性改善 まず目的の一つに、テスト設計やテスト実装物の保守性改善のための構造化手段
C/C++でのユニットテストによるメモリリーク検出 - 千里霧中
CやC++の開発ではメモリリークに悩まされることが多い。メモリ管理はスマートポインタに限定するなど自分たちが注意しても、外部で開発されたコードやレガシーコードによって結局逃れられないことがしばしばある。 さらに組み込み開発といったコードの実行環境に制約が多い場合は、検出や再現がやりにくいことから、メモリリークのデバッグやテストが結構なストレスになることがある。 こうした、面倒な問題になりがちなメモリリーク対応では、全てに対応できるというわけではないけれど、ユニットテストでの検証が有効なことが多い。ユニットテストならば、再現性の確保、異常な入力の実現、コードの切り分けといったものが容易なためだ。デバッグ等で便利なので、今回いくつかの方法をまとめたいと思う。 対象のコード 今回はメモリリークを発生させる題材として、以下のコードを解析する。 class Base { }; class Hoge
Cadence SMVによるアルゴリズムの検査 - 千里霧中
先日、Cadence SMVによるモデル検査を扱う機会があった。アルゴリズムの検証で有用だと感じたので 復習がてら簡単に使ってみたい。 検査 今回は、並行コンピューティング技法で紹介されているスピンロックのバグの実装例をモデル検査で検証する。 その検査対象の擬似コードは以下の通り。2つのスレッドがスピンロックでそれぞれのCriticalRegionの保護しながら動作する。当然ながらこのロックには欠陥がある。 int thread0inside = 0; int thread1inside = 0; void threadZero() { while (true) { while (thread1inside) {} ...OtherTask... thread0inside = 1; ...CriticalRegionOfThreadZero... thread0inside = 0; .
テストの品質モデルについて発表 - 千里霧中
先日、JaSST13'東海のポスターセッションにて、「テストの品質モデル構築の取り組み」と題した発表をさせて頂きました。 テストの品質モデル構築の取り組み from H Iseri 内容は、まず前提として、テスト環境・テストスクリプト・テストデータといった、テスト実装・テスト環境構築の成果物の総称を指す言葉として「テストシステム」という用語を定義しています。そしてそのテストシステムの品質モデルを、ISO/IEC25010ベースで作成したものが主なコンテンツとなっています。 背景ですが、現在では同じテスト環境が、プログラミング中・テスト工程・リリース作業等々、開発ライフサイクルを横断して活用されるのが（特にテスト自動化で顕著ですが）ありふれた姿となっています。 また特に自動テストについては、プロジェクトを超え、資産としてブランチや派生プロジェクトにも引き継がれるようになっています。そこでは例
データの品質モデル（ISO/IEC 25012）について - 千里霧中
ソフトウェア品質モデルの国際的な標準規格としては、長らくISO/IEC 9126が一般的でした。ただ規格が置換されたこともあり、最近はISO/IEC 25000シリーズ（通称SQuaRE）が使われるようになっています。 ISO/IEC 25000シリーズでは、ISO/IEC 9126と比べていろいろ変更や拡張が行われています。特になかでも目を引くのがISO/IEC 25012でデータの品質モデルを新たに追加している点です。データの品質モデルはこれまでなかったものではないものの、システムの品質モデルと並ぶ位置づけで定義しているのが印象強いです。 このデータの品質モデルについてですが、上位のレベルのテスト設計・実装で活用できそうなものとなっています。 というのも、データ駆動テストやキーワード駆動テストを行うと、データ（キーワード含む）と、それ以外のスクリプトやフレームワーク部分で利用者・利用状
WACATE2013冬にてリスクベースドテストについて講演 - 千里霧中
先週末、WACATE2013冬というソフトウェアテストの合宿勉強会にて「リスクベースドテストを活用しよう」というセッションを担当させていただきました。 リスクベースドテストを活用しよう/Risk Based Testing In Action - Speaker Deck 内容はリスクベースドテストの概要や一連の進め方の解説となっています。 今回はリスクベースドテストの運用上の問題がよく見られる現状もあり、特に「4. リスクベースドテストの限界・注意点」の解説を行えればという思いで機会を頂きました。 内容を詰め込みすぎてしまい駆け足気味のセッションとなってしまいましたが、適切なリスクベースドテストの活用の一助になればと考えています。
黒背景のプレゼン資料では色盲の方に配慮する - 千里霧中
開発系の勉強会では黒背景のプレゼン資料を作成する方が少なくありません。自分も、暗い部屋で見やすい・発色をより鮮やかに感じるといった理由で、2年ぐらい前から黒背景でプレゼン資料を作ることが増えてきました。またプレゼンの印象を良くするアドバイスとして白黒反転が推奨されているのもちらほら見かけます（例えばhttp://blogs.itmedia.co.jp/kenjiro/2009/03/post-09e7.html）。 ただ過去の講演の事前レビューで @t-wada さんからアドバイスされたことなのですが、黒背景では、一定数いる色盲の方が見にくい配色が一部あるそうです。 例えば一番多い例として赤緑色盲がそうです。赤緑色盲は日本人男性の5%、白人男性の8%の割合で存在しており、程度にばらつきがあるものの以下のような特性を持っています。 赤成分・緑成分の判別がしにくい 赤成分や緑成分が暗く見える
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
AAAにてテスト自動化の品質特性について講演 - 千里霧中