組み合わせテストを教えてもらった(3)
全3回の、第3回。
テストの組み上げ方
組み上げ方はテスト戦略として、どんなバグを見つけたいか、何をする期間か、どんな人がテストをするか、対象についての知識がどれくらいあるかなどによって、使い分ける。
増加/非増加
増加
低いレベルから作り始めて、レベルを上げながらどんどん増やしていく。
非増加
高いレベルから作り始める。シナリオテストを行うことが多い。
アジャイルの場合
組み合わせをあとから付け足す方法論。
Sprint毎に、ユーザーストーリーに対して最短のパスを開発する(テストも含まれる)。
- 事前設計は当然する。実施がインクリメンタルなだけ。
- テストケースが減る訳じゃない。
バグを予測できないものはテストではない
テストはエラーを発見したら、成功。そうでなければ失敗。
各テストフェーズの完了基準(参考：マイヤーズ)
0. 実施期間の終了によってテストを完了とする
1.ある網羅基準について満たしたテストをすべて実施して完了とする
○○技法の△△基準で網羅したテストを、すべて実施した。
2.設定したエラー件数の発見によって完了とする
そのフェーズでどんなエラーが何件あるか見積もり、その件数分エラーを発見したら完了とする。
- フェーズ毎にエラーの件数は違う
テストレベルが上がるにつれて減るべきエラーや、テストレベルが高くないと出ないエラーがあるはず。
例：仕様書を読み違えた、論理が反対になっていた、エラー処理がなかった、マルチスレッド考慮漏れ、etc..
| フェーズ | エラーA | エラーB | エラーC |
|---|---|---|---|
| 単体 | 100 | 0 | 0 |
| 統合 | 10 | 20 | 50 |
| システム | 0 | 10 | 0 |
- 件数での見積もりができないとだめ
「見積もりエラー数 / テストケース数が高いところは、優先度が高い」と言える。
→件数でないと困る。
3.エラー件数の発生具合によって完了とする
プロダクト、プロジェクトによって適したグラフがちがうから、戦略時に決めておく。
- 要望に応えるには
検出するバグの総量は面積。
- 【余談】TDD
まとめとかいろいろ
現実的なのは2
3にも挑戦はできるし、意味のある値をとることはできるが、完了はできない。
→傾向を測ることしかできない。
(2・3で)エラー件数に届かない
- テスト戦略が間違っている(品質が良い場合もここに含まれる)
- テスト設計が間違っている
- テスト実施者が設計通りに実施していない
品質の大きさのようなもの
- エラーは不具合モードで分けるより品質で分ける方が有用っぽい(byきょんさん)
- 機能性が大きくて使用性が小さいみたいな表現ができそう
組み合わせテストを教えてもらった(2)
全3回予定の、第2回。
基本的なツールとしてPictMasterの使い方を教えていただきました。
PictMaster
http://sourceforge.jp/projects/pictmaster/
※PICTが入っていないPCの場合、まずPICTをインストールする必要があります。
とりあえず使ってみる
- パラメータ：因子
- 値の並び：水準をカンマ区切りで書く
実行するとこんなファイルができる。
制約表を使ってみる
とりあえず使ってみるのファイルに、制約表を追加。
メモ：レスザンの値は値の並びに書いてある値しか指定できなかった。
(< 120 は書けなかった)
結果表を使ってみる
制約表を使ってみるのファイルに結果表を追加。
実行ー。
原型シートを使ってみる
結果表を使ってみるで生成された表をメインシートの右隣のシートに貼る。
※結果内容があるとエラーになるので消しておく必要有り。
商品価格の水準に130を追加して、実行ー。
以前やったテストは確実にやって、さらに何か追加するときに使う。
a.xls
毎回同名のファイルを作るので、一度閉じるか別名で保存しないと次の実行はできない。
組み合わせテストを教えてもらった(1)
全3回予定の、第1回。
http://goyoki.hatenablog.com/entry/2012/07/11/004240
こちらの資料の47ページからを見ながら教えていただきました。
組み合わせテストの種類
有則
因子・水準の組み合わせの規則が決まっている
【ラックの温度と在庫数と投入金額】 適温のラック + 在庫有 + 価格分(以上)の金額投入 → 販売ボタンが点く 適温のラック + 在庫無 → 売り切れランプが点く
- 全網羅が基本(数が爆発した場合はレイヤーを分けて範囲を調整)
- デシジョンテーブル・原因結果グラフ・ドメイン分析などを使う
無則
因子・水準の組み合わせの規則が決まっていない
【硬貨の種類と残高】 受け入れ可能な硬貨を投入 → 金額表示機が表示する残高に硬貨の金額分加算される 【在庫の数と投入金額】 ラック内の在庫の数(1以上) + 投入金額(該当商品の価格以上) →ある範囲の中であれば水準は問わない
- 全網羅は無理(リスクの高い組み合わせを優先させる)
- 直行表・ペアワイズなどを使う
禁則
組み合わせられない(処理が行われない・起こり得ない・その状態は作れないなど)
- (だいたい)有則の組み合わせを探していると出てくる
リフレクションを教えてもらった
リフレクションとは
- 動的(実行時)に、型の情報/メソッドの情報などを取得する。
- 取得した情報を元に、インスタンスの生成/メソッドの呼び出し行う。
動的に型の生成・書き換え/メソッドの生成・書き換え(もするらしい)。
どういう時に使うのでしょう
文字列からオブジェクトを生成し、メソッドを呼び出す。
設定ファイルにクラス名(例:Hoge)が文字列で書いてある。
プログラムが設定ファイルのクラス名を読み込み、リフレクションを使ってHoge型のオブジェクトを生成する。
ToString
フィールドの中身を文字列で表示するToString()を用意するとこんな感じになる。
→ int y みたいなフィールドが増えると、ToString()を書き換えないといけない。
class Hoge { int x; string str; public override string ToString() { return "Hoge(x = " + x + ", str = " + str + ")"; } }
そこで、リフレクションを使ってこんな感じに書いておく。
→フィールドが増えてもToString()を書き換えなくていい。
public class Class2 { int x; int y; string str = "Test"; public override string ToString() { var t = typeof(Class2); return "Hoge(" + string .Join(", ", t.GetFields(BindingFlags.NonPublic | BindingFlags.Instance) .Select(f => f.Name + "=" + f.GetValue(this))) + ")"; } static void Main() { var c = new Class2(); Console.WriteLine(c.ToString()); } }
遅いけどな
実行時に処理するので遅いので、使い方注意。
特にf.GetValue(this)が10～100倍くらい遅い。
時間計測した。
ユースケースを教えてもらった(2)
ISO2501nを教えてもらった
わかったこと
品質モデルとは(確認)
プロダクトをいろいろな視座から考えてみるヒントみたいなものだと思っています。
→だいたいそんな感じです。
ISO25000系は現在進行形で作られている品質モデル
SQuaREシリーズとも呼ばれる。
(ISO9126も含めた)既存の品質モデルを汲んでいる。
- ISO/IEC 2500n：品質管理部門 【邦訳有】
- ISO/IEC 2501n：品質モデル部門【邦訳有】
- ISO/IEC 2502n：品質測定部門【一部(？)邦訳有】
- ISO/IEC 2503n：品質要求部門【邦訳まだ】
- ISO/IEC 2504n：品質評価部門【審議中】
ISO2501n
以下のための品質モデルと実際的な利用のための手引きを提供する。
- 製品品質(内部ソフトウェア品質/外部ソフトウェア品質)
- 利用時のソフトウェア品質
品質モデルを使用する人
- 開発者
- 取得者
- 品質保証要員及び品質制御要員
- 独立した評価者(特にソフトウェア製品の品質の仕様化及び評価に責任のある人々)
品質モデルの使用から便益を得る製品開発時の活動
- ソフトウェア要求事項及びシステム要求事項の識別
- 要求事項定義の包括性の妥当性確認
- ソフトウェア設計の目的及びシステム設計の目的の識別
- ソフトウェア試験の目的及びシステム試験の目的の識別
- 品質保証の部分として品質制御基準の識別
- ソフトウェア製品及び／又はソフトウェア集約的コンピュータシステムに対する受入れ基準の識別
- これらの活動の支援における品質特性の測定量の確立
利用時の品質モデル
対象コンピュータシステム及び対象ソフトウェア製品を含む人間－コンピュータシステム全体に焦点。
人間とコンピュータとの対話の成果に関係する。
- 有効性(有効性)
- 効率性(効率性)
- 満足性(実用性/信用性/快感性/快適性)
- リスク回避性(経済リスク緩和性/健康・安全リスク緩和性/環境リスク緩和性)
- 利用状況網羅(利用状況完全性/柔軟性)
製品品質モデル
対象ソフトウェア製品を含む対象コンピュータシステムに焦点。
外部品質と内部品質に適用できる。
【】は影響を与える他の品質。
機能適合性【一次利用者の利用時の品質】
- 機能完全性
- 機能正確性
- 機能適切性
性能効率性【一次利用者の利用時の品質／他の利害関係者に関係する情報システム品質】
- 時間効率性
- 資源効率性
- 容量満足性
互換性【保守作業の利用時の品質】
- 共存性
- 相互運用性
使用性【一次利用者の利用時の品質】
- 適切度認識性
- 習得性
- 運用操作性
- ユーザエラー防止性
- ユーザインタフェース快美性
- アクセシビリティ
信頼性【一次利用者の利用時の品質／他の利害関係者に関係する情報システム品質】
- 成熟性
- 可用性
- 障害許容性(耐故障性)
- 回復性
セキュリティ【一次利用者の利用時の品質／他の利害関係者に関係する情報システム品質】
- 機密性
- インテグリティ
- 否認防止性
- 責任追跡性
- 真正性
保守性【保守作業の利用時の品質】
- モジュール性
- 再利用性
- 解析性
- 修正性
- 試験性
移植性【保守作業の利用時の品質】
- 適応性
- 設置性
- 置換性
利害関係者
利害関係者のニーズを収集するための枠組みも提供する。
一次利用者
主目標を達成するためにシステムと対話をする人
自動販売機でジュースを買う人
二次利用者
- コンテンツプロバイダ，システム管理者及び／又はシステム上級管理者，並びにセキュリティ管理者
自動販売機に巡回してくるコカ○ーラの人
- 保守者，分析者，移植者，設置者
自動販売機を設置しているフランチャイズオーナー
間接利用者
システムと直接対話をしないが，出力を受け取る人。
コ○コーラの売り上げとかを調査したりする人
大事なこと
品質要求事項は利害関係者の観点から定義することが望ましい。
→アジャイルっぽい。と思った。(感想)
難しいと思ったこと
具体的なプロダクトに適用すること
考えたことがなかったような特性は特に、練習が必要そうだと思いました。
ユースケースを教えてもらった
ユーザーストーリー同様、テスト設計コンテストの課題(http://aster.or.jp/business/contest/testbase.html)を使って教えてもらいました。
わかったこと
「ユースケース」と言われるのは、UML(図)の場合とシナリオ(文)の場合がある。
文重要。文には大きく3流派がある。
- RUP(ラショナル統一プロセス)
- Alistair Cockburn
- ICONIX ← きょんさんはこれが書きやすい
パスの書き方いろいろ
実装に依らない言葉で書く
1STEPには以下2つを必ず含める
ユーザーがすること ユーザーがしたことに対してシステムがどう動くか
ユーザーとシステムをつなぐインターフェース(バウンダリ)はきちんと書く
× ユーザーが硬貨を入れると ○ ユーザーが硬貨投入口に硬貨を入れると
基本パスと代替パスに分けて書く
基本パスと代替パスの名前はいろいろ。
ex)晴れの日パスと雨の日パス
パスが大量になり過ぎたらケースを分割する
要求分析～外部設計、および及びそれにかかわるテストを考えるときに使える
ユーザーストーリーは要求分析までが範囲
難しいと思ったこと
どれくらいのパスを書いたら満足かわからない
ICONIXとRUPは目安があるので勉強するといいとのこと。
きょんさん的には実装できる気がするまで。
