Weitere ähnliche Inhalte
Mehr von Kouichi Akiyama (13)
業務状態遷移テストを語る夕べ
- 1. © 2018 Fuji Xerox Co., Ltd. All rights reserved.
業務状態遷移テストを語る夕べ
ユーザー受け入れテストで行う業務シナリオテストの一手法
秋山の考え方を語るだけですので、「そういうふうに考える人
もいるのねー」という軽い姿勢で聞いていただけると幸いです。
2018年8月24日
富士ゼロックス/秋山浩一
@西新宿三井ビル15階
- 2. © 2018 Fuji Xerox Co., Ltd. All rights reserved. 2
「HAYST法で作った表にはテストしたいことが、ひとつも出てこない」、、、と、たまに言われる
• (パターン1)きわどい業務フローをテストしたい
Ð (例)保険の満期が近づいていることの通知を出した後に、満期前に特約条件を変えたときをテストしたい
• 「そういう良いテストが思いついたら、どんどんしてください。私も必要と思いますよ」と言うと……
Ð 2機能間の組合せを網羅したら97%のバグは見つかるって言ったじゃないと怒られる
• (パターン2)こんな組合せは現実には、あり得ないのでテストしても意味がない
Ð (例)生命保険申込書のテストで: 「加入者年齢:18歳 × 既往症:認知症」の組合せをテストしたってねえ……
• 「ではなぜその組合せの入力を許しているのですか?」と聞いてみると……
Ð 禁則の実装をするのは面倒だから
• 「『18歳の加入者の既往症が認知症』は、 絶対にはありえないことですか?」と聞いてみると……
Ð あったとしても頻度が低いからバグっていてもリスクが低いんです
(このコンサル、リスクの概念を知らないんじゃないかな∼)
Ð 「『はい。はい。』やれというなら、やりますよ。100件くらいテストが増えても、どうってことない」(投げやり)
業務状態遷移テストを語る動機 = 網羅型の業務テスト
HAYST法(組合せテスト)って、入力の数が非常に多い画面のテストでしか使えないんじゃない?
『きわどい条件で、バグがでそうなところ』をテストしたい!(多くのテストエンジニアの声)
≪2種類のテスト≫
網羅型のテスト: テストすべき観点(カバレッジアイテム)について網羅的に評価し品質を保証する
検出型のテスト: 障害が多いと推測される箇所や重要度の高い箇所に狙いを絞って評価することで
少ない手間で素早く多くの危険な障害を検出する
【現実的な工数で高い品質を達成するためには両者のバランスをとるべし】 SQuBOK V2 p276より
- 3. © 2018 Fuji Xerox Co., Ltd. All rights reserved.
・状態遷移
・業務状態遷移
①業務状態遷移のイメージ
3
- 4. © 2018 Fuji Xerox Co., Ltd. All rights reserved. 4
状態が遷移しないソフトウェア
• 数値計算
Ð (例)合計値(和)を求めるソフトウェア『sum(a, b)』は『a+b』の結果を返すものとする
• sum(3, 4)の実行結果は『7』
Ð 『7』以外はありえない
Ð 一般に科学的な数値計算部分(摂氏と華氏の変換など30℃→86°F)で状態遷移テストは行わない
状態が遷移するソフトウェア
• たいていのソフトウェア
Ð (例)ATM
• 『10万円引き出す』の実行結果は?
Ð 『10万円が引き出される』 ← 通常ケース(ハッピー・パス)
Ð 残高が3万円だったら? ← 引き出せない?
Ð 定期預金に1千万円あったら? ← 自動ローン??
Ð 状況(残高と定期預金の組合せ)によって結果が変わる
• sum(3, 4)について再考
Ð 合計値を2進数で表示する仕様なら『111』かも??
Ð どこかに、「k進数で表示する」という情報があるはず ← ここでは状態変数と呼んでみる
Ð 状態とは「状態変数の組合せ」である ← 状態の定義の一つ
(他にも「データやイベントのガード条件が同じ」を状態と定義する → 開発は楽になる)
状態遷移
- 5. © 2018 Fuji Xerox Co., Ltd. All rights reserved. 5
機能(どちらかといえばシステムテスト)
• 個々のプログラムが実装した因果関係(プロット)
Ð 因果関係
• 原因(事前状態、入力)
Ð 2進数表示の状態で、3と4を入力する
• 結果(期待出力、事後状態)
Ð 『111』が出力する、状態は2進数表示状態のまま
順序(受け入れテストでの中心)
• 人間は、やりたいように機能を使う(ストーリー)
Ð やりたいように?
• 入力するものが届く順序
Ð Eコマースで「送付先」と「購入商品・個数」はどちらを先に入力しても良い
• 訂正
Ð あとから発生する訂正作業(数量の変更、入力ミスの訂正)
事態(見つかったらラッキー的な)
• 本番環境
Ð 開発環境と本番環境の違い(CPU数などのインフラのグレード、データ量・データバリエーション)
• 異常事態
Ð ノイズ(CPU負荷=時間、資源負荷=リソース)
業務状態遷移
(ユーザー受け入れテストで行う業務フロー・業務シナリオ)
HAYST法の受け入れテストでは、導
入して良い業務を確定する。バグが
あっても人間系で回避できるかどうか
が大切。したがって、順序について
「業務状態遷移のモデル」で網羅する
- 6. © 2018 Fuji Xerox Co., Ltd. All rights reserved.
・車線逸脱アラート
②組み込み系で見つけたい
状態遷移問題
6
- 7. © 2018 Fuji Xerox Co., Ltd. All rights reserved. 7
車線逸脱アラートとは
• 目的
Ð 運転中に車が車線をはみだしたら警告音などの(アラート)で運転手に注意を促す安全機能
• はみ出す → うっかりと(ボーっとして)
Ð 通常の車線変更でアラートが鳴ってはいけない
Ð そのために
「方向指示器が点灯中に車線逸脱してもアラートは鳴動しない」
という仕様が追加された
状態遷移が起因するバグ
• ハザードランプ点灯中の車線逸脱
Ð アラートが鳴らない
• 実車テストで前方渋滞時にハザードを点灯してからブレーキを踏んだ
Ð 車線の逸脱があった
Ð アラートが鳴ると思ったが鳴らなかった
• 原因
Ð 方向指示器とハザードで同じ変数を使っていた
Ð 車線逸脱アラートは方向指示器がついている状態と認識
Ð 仕様どおり鳴動しない
車線逸脱アラート(事例ではなく、架空の話)
- 8. © 2018 Fuji Xerox Co., Ltd. All rights reserved.
・ラルフチャート分析
③変更ラルフチャートと波
及ラルフチャート
8
- 9. © 2018 Fuji Xerox Co., Ltd. All rights reserved. 9
どういうテストをしたら見つかるか?
• 状態遷移テスト?
Ð 【ハザードが点灯している状態】で【車線を逸脱】するイベントを発生させればよい
• ハザードランプの状態遷移テストで【車線を逸脱】イベントに気がつくか
Ð 気がつかない、その1(ランプと関係するイベントに着目してしまうから)
• トンネルに入る
• 電圧を変化させる
Ð 気がつかない、その2(車線逸脱アラートは追加機能)
• 既存機能の(特にこれまでバグゼロだった)ハザードのテストは手を抜く
• 車線逸脱イベントから逆探索しても影響を与える状態が見つからない
• 業務状態遷移テスト?
Ð 高速道路走行業務について網羅的にテストする
• 渋滞という業務には、ハザード状態がある
• そこに【車線を逸脱】するイベントを発生させればよい?
Ð そんなに上手くいくのか???
Ð このバグがなぜ起こったのかの深掘りが必要ではないのか?
• 内部情報を使うしかない
Ð 変更ラルフチャート
Ð 波及ラルフチャート
車線逸脱アラート
- 10. © 2018 Fuji Xerox Co., Ltd. All rights reserved. 10
2つの不具合発生パターン
一つの目的機能内で閉じた不具合
• 単機能(有則)と組合せ(無則)のテスト
Ð 仕様書に書いてある機能を有則のテストをする
(CEGTESTでデシジョンテーブルを作る)
← SQiPシンポジウム 併設チュートリアル
Ð 仕様書に書いていない機能間の無則のテストをする
(HAYST法で直交表を作る)
← JaSST 2018 東北
複数の目的機能を組み合わせたときに発生する不具合
• 不具合の発生パターン(4つ)
Ð 変数の共有(状態→状態) ← 車線逸脱問題
変更RC(a)と、波及RC(b)を連結
状態変数を介してバグが伝播
Ð 順序(入力→出力が、出力→入力)
(a)(b)(d)を連結
順番を変えたテストを行う
Ð 初期設定もれ(入力→状態)
(a)(c)を連結
初期設定RCをスキップする
Ð ノイズ発生(出力→ノイズ)
(c)(d)を連結
負荷を意識的にかける