第187回： 「ソフトウェアテストしようぜ」4 シーリングファン
◀前の記事へ 次の記事へ▶
≡ はじめに
前回は、「シーリングライト」のソフトウェアテストの話を書きました。
内容としては、「GIHOZで状態遷移テスト」という話を書きました。
テスト技法の話はあまりしたくなかったので、「なぜ1スイッチテスト」をするかの話は書きませんでした。そうしたら、
これはお好みの明るさにしたあと消灯してお好みの明るさボタンを押すと前回の明るさに戻っているんですよね。テストに漏れがないかをどう確認するかが難しそう。 https://t.co/fC8WyEsFsT
— Iwasaki Teruyuki (@twk) July 24, 2022
というRTをいただきました。
そこで、反省して、前回のnoteに
1スイッチテストを実施することで、調光した明るさを記憶していることを確認できます。
と書き足しました。
「調光→消灯→調光」や「調光→ブルーライト→調光」などが網羅的に現れるのが1スイッチテストですから。
ということで、今後は「なぜその技法を使おうとしたのか」について、もう少し詳しく書こうかなと思います。
2スイッチテスト、3スイッチテストもGIHOZで同じように作成できますが、「ある状態を決めるときに使う変数が１つしかないのであれば、普通は１スイッチテストで十分」です。
例えば、ビデオの「一時停止状態」のときに[一時停止ボタン]を押して一時停止状態を解除したとします。このときに、「前の状態」を格納している変数の値をみて、「前の状態が通常再生だったから通常再生に遷移する」、「前の状態が早送り中に一時停止したから早送り状態に遷移する」という実装であれば１つの変数しか参照しないので１スイッチテストで十分です。
そうではなく、「動作モード（再生、速い、コマ送り）」と「時間（順方向、逆方向）」の２つの変数を見て、「コマ送りで、逆方向」からの一時停止だったからその状態に戻るという作り方だと２スイッチテストの方が良いです。
2スイッチテストは、「2つ前の状態の影響を受ける場合に使用する」というのはその通りですが、それだと考えにくいです。
なお、普通のソフトウェアは「ステートレス」（現在の状態を表すデータなどを保持せず、入力の内容によってのみ出力が決定される方式）で作るくらいなので、2つ前の状態の影響を受けることは滅多にありません。
さて、今回のお題は、我が家のリビングの天井についている「シーリングファン」です。
≡ お題（シーリングファン）の説明
前回の再掲になりますが、お題の説明です。
リビングの天井についているシーリングファン（ライト付き）です。右下に写っているダウンライトとは直接の関係はありません。
ウチでは部屋の調光にはダウンライトの方を使っていて、シーリングファンの方は全体の明るさのために使っています。（ダウンライトを使う頻度は少ないです）
シーリングファンの調光機能を使うためには、シーリングファンの電球を白熱球にしなくてはなりません。最初はそうしていたのですが、電球が5個あるのでわりと頻繁に電球交換が発生し、面倒だからLED球に替えて、それ以降、シーリングファンの調光機能は使わなくなりました。
※ 今調べたら調光対応のLEDランプもあるのですね。今度ためしてみようかな。
ところで、ダウンライトも白熱球ですが、消費電力の関係か寿命が長い気がしています。（点ける頻度が少ないだけかもしれません）
それから、まったく個人的な好みですが、照明機器はODELICが好きです。前回の自室の照明はナショナルだったけど。（笑）
シーリングファンとは、多くは吹き抜けの上に設置して、羽を回転することによって、空気を攪拌する機器のことです。
羽の回転方向を変えることで、「夏は下向き 冬は上向き」に風の流れを作ります。
どちらの風向も空気を攪拌する機能としては大差ないのですが、リビングの天井に設置したときは、人との距離が近いので、風向きを下向きにすると微風が体に当たって扇風機のように涼しい気がします。
リモコンの写真は以下の通りです。
それぞれのボタンの意味は下記の通りです。（右上側面のチャンネル切り替えスイッチの説明は省きます）
こちらの説明はマニュアルを書き写したものです。
【ファン】ファン停止・運転ボタン： ボタンを押すごとに「運転⇔停止」と切り替わります
【照明】照明切/入ボタン： 照明の点灯・消灯をおこないます
【▲▼】ファン風向切替・照明調光ボタン： ファンの風向切替 照明の調光をおこないます
【弱中強】ファン風量切替ボタン： ファン運転時、ファンの風量：弱・中・強をダイレクトに選択できます
上記に加えて、「メモリー機能」として「最後に設定した状態を自動的に記憶する機能です。運転停止後、再びボタンを押すとファン（風向/風量）、照明（調光）それぞれ停止前の状態で運転（点灯）します。停電などで通電が停止したのちの電源通電時は、通電停止前の状態で運転・点灯します」と書いてあります。
≡ テスト対象を理解する
テストを作る前に、テスト対象を理解することが何より大切です。
前回の公開後、こんなツイートをいただきました。
それと、ファンがうるさいかどうかも気になりポイントです。
— リナ？ (@____rina____) July 23, 2022
うちのファンうるさくって、何なら、上の部屋にも響くんですよね…おかげでほとんどつかってません。今も別に扇風機使ってるw
このように使用者目線でテスト対象を理解しようとするのはとても大切なことと思っています（そして、私に不足している能力です）。
レビューのリーディング技法でいえば、「使用者目線のパースペクティブレビュー」ということになります。
≡ テストを作成する（ステップ1）
それでは、今回も2ステップに分けて、テストを作っていきます。まずは、“私はこういうテストを考えた”ってことを書きます。
私の場合は、2段階に分けてテストを作成しています。
ステップ1では、直感で「これはするだろう」というテストを書き出します。そして、ステップ1で思いついたテストは、「論理的に考えると不要そうに見えても実施する」ことにしています。
（案外、テストでは「直感があたる」から）
今回は、
強回転中の停電復旧
をテストしたいと思いました。
ファンが強回転（高速回転）している状態で停電が起こって、その後、電気が復旧したら、仕様（マニュアル）どおりに【強回転で回りだす】に違いありません。このテストでバグが見つかるとは思っていません。
それでも、私は「強回転中の停電復旧」のテストをしたいです。
エアコンは、停電復旧後、【停止状態になる】という仕様をご存じでしょうか？
熱帯魚や犬・猫などのペットを飼育していると、ペットのために夏場はエアコンを点けっぱなしにして外出します。
ところが、上記の仕様により、外出中に停電があると停電が復旧してもエアコンは停止したままです。
室温はあがり、犬や猫は涼しい場所に避難するとしても、熱帯魚は水槽の上の照明と、ろ過装置などの関係で水温が上昇し死んでしまうことが多々あります。（私も経験しました）
エアコンの場合は秘密の呪文で【停電が解消されて通電が始まったタイミングで停電前の状態で運転を再開する】ことができます。（できない機種もあるかもしれませんし、マニュアルには書いていないと思います）
気になった方は「エアコン 停電 自動復帰」あたりでググると色々と出てきます。
この仕様は、メーカーがいじわるでしているわけではなく、高電流が流れる起動時に人がいなくて自動的にエアコン内部に通電してよいのか？ ということです。IoTの普及でリモートからエアコン起動することができるようになりつつありますが、その場合でも人が起動を指示しています。
ですから、シーリングファンでは【停電前の状態で運転を再開する】で本当に大丈夫なの？ と、そこをテストして、「ほんの少しでも安全性に問題があったら」（例えば、地震で停電して、運悪く物理的に羽が回らない状況になっていると火災につながるリスクが高くなるなどがあったら）、再検討を促したいからです。
≡ テストを作成する（ステップ2）
次にステップ2です。
■ 表のテスト
まずは、前回の復習を兼ねて状態遷移モデルを作ります。
今回も前回に続き、GIHOZを使いました。ベリサーブさん、ありがとうございます。
まずは、仕様を確認し、そこから状態遷移図をGIHOZで描きます。「停電時のメモリー機能」のような特別なものは、それ専用のテストを作るので、状態遷移テストからは除外します。
【ファン】ファン停止・運転ボタン： ボタンを押すごとに【運転⇔停止】と切り替わります
【照明】照明切/入ボタン： 照明の点灯・消灯をおこないます
【▲▼】ファン風向切替・照明調光ボタン： ファンの風向切替 照明の調光をおこないます
【弱中強】ファン風量切替ボタン： ファン運転時、ファンの風量：弱・中・強をダイレクトに選択できます
取り敢えず、ファンと照明に分けて考えます。
ファンの状態は、風向（上、下）と、風量（弱、中、強）の組合せですから、「上・弱」、「上・中」、「上・強」、「下・弱」、「下・中」、「下・強」の6つです。GIHOZにアクセスして状態を入力します。
このあたりの手順は深く考えずにツールに入力してしまうのが良いと思います。6つ入力して、「あ、ファンが回っていない状態を見逃してた」って気がついたら「停止」を追加すればよいだけです。←今、起こったこと。www
風量が「弱・中・強」でなく「1，2，3，4，5，6，7，8，9，10」と多く、このままでは、
風向（2通り）×風量（10通り）＋停止状態（1通り）＝21状態
になってしまうと思ったら、風量は境界値分析して「1，10」だけにして、
風向（2通り）×風量（2通り）＋停止状態（1通り）＝5状態
5つの状態でテストします。
「1回で最高の状態遷移図を描こう」なんて考えずに、「試行錯誤していいものに近づけよう」というアプローチが良いと思います。
境界値分析をするときには、プログラムのソースコードをチラ見して、境界値の条件で分岐していることを調べるか、開発者に聞いてみるといいです。
それでは、状態から状態へ線が引いてみます。
あれあれ？ 「【停止】状態から線が引けないぞ」となりました。
上の状態遷移図は、「【停止】状態から線が引けない問題」を解決した図です。赤い線が主に追加したところです。
Ⓗは、履歴状態(History State)とかヒストリー状態と呼ぶもので、動作中という大きな状態から抜け出すときにその時にいた入れ子の状態（履歴）を覚えておいて、それをⒽという記号であらわしたものです。Ⓗから【上・弱】への矢印は、状態の履歴がないときに、遷移するデフォルトの状態を示しています。
ただ、現時点（2022/7）では、GIHOZは入れ子の状態遷移図には対応していないようなので、【停止】状態を除いた状態遷移テストをします。
【停止】状態からの遷移、特に前回の状態を記憶しているかどうは別途テストします。
照明については、【消灯】、【点灯】、【調光】の状態があります。こちらは前回と比べて【ブルーライト】状態がないのでシンプルです。
GIHOZが生成した以下のテストケースをテストします。
以上で、ファンと照明それぞれの状態遷移テスト用のテストケースが得られました。
ここで気になるのは、「ファンと照明って本当に独立しているんだっけ？」という疑問です。自分なら独立して作るけど、このリモコンを見ると「▲▼」ボタンをファンと照明で共用しているし、怪しいなぁ、、、と違和感を覚えます。
このときに、ファンと照明を合わせた状態遷移テストをしてもよいのですが、ファンと照明を合わせると、状態数は結構多いです。ファンの状態遷移図だけでも状態は7個ありました。照明の状態遷移図でも2つありましたので、二つを合わせると7×2＝14個の状態があります。明るさの中間状態（調光中）も入れると、7×3＝21個もの状態になってしまい、状態遷移図はぐっちゃぐちゃで見通しが悪いものになりそうです。
そこで、ファンと照明の組合せの確認は全体の状態遷移テストではなく、組合せテストで手を抜くことにします。マニュアルを読み直しても「ファンが回転中は調光できない」といった特別な関係の記載はありませんから独立していると見なしてよいでしょう。
このように、特別な関係がないことを「無則」と呼びます。
「関係ないはずが、同時に使ったらバグった」という問題は「無則と思っていたら無則じゃなかった」ということです。そして無則のテストには組合せテスト技法を使います。
組合せテスト技法の詳細は省きます。気になる方は以前のnoteをご参照ください。
組合せテストですが、GIHOZでは、「ペアワイズテスト」を使用します。
組合せテストでは、1番初めに、組み合わせるものを明らかにする必要があります。「組み合わせるもの」のことを「因子・水準」と呼んだり「パラメータ・値」と呼んだりします。「因子＝パラメータ、水準＝値」です。
私は、因子と水準を見つけるためにラルフチャートを作っています。ラルフチャートについては、「詳説ラルフチャート」に詳しく書きました。今回ですと、こんな図になります。
ここから、因子・水準を抜き出してGIHOZのペアワイズテストに入力します。（直交表に入力しても良いです）
GIHOZに入力するときには、上から「状態変数」、「入力」の順番で入力します。
ラルフチャートのノイズの位置にある「電球種別」については、できあがったテストマトリクスを電球種別ごとにテストします。
生成条件は以下としました。
今回は、水準間に同時に組合せが取れないものは無いので制約はオフにしています。組合せパラメータ数をデフォルトの2から3に増やしたのは、今回、状態変数が3つなので、全ての状態を網羅したいと思ったからです。
このあたりは、テスト工数との相談となります。テスト工数がなければ、組合せパラメータ数はデフォルトの2のままでテストすることでしょう。
出来上がった表の一部を載せます。全部で38件となりました。
私は組合せテスト件数を64件前後に収めることが多いです。
この表のテストの仕方は、初めの3列を順番に入力してその状態を作ったら、4列目の「ファン」か5列目の「照明」のどちらかを入力し、6列目と7列目を入力します。4と5について値が［操作しない］のところは相手側もしたことにしてよしです。
ここで、風向きに停止中、明るさに消灯中が無いことが気になる人がいるかもしれません。なぜなくて良いのか？の答えは考えてみてください。
ここで、お知らせなのですが、今回、このテストをいくつか試していたら「照明が点いているとファンの風向きを変更できない」という現象が見つかりました。照明が消えていれば風向きを変えることができますし、照明が点いていても風量は変えることができます。
「▲▼」ボタンをファンと照明で共用していることが原因かなあと思っていますが、「仕様」かもしれません。
この照明を10年以上使っていて初めて気が付きました。風向きを変えることなんて滅多にしませんし、仮に気が付いたとしても、色々しているうちに変わったらそれ以上追求したいと思いません。したがってこのバグの重要度は「軽微」と思います。
■ 裏のテスト
裏のテストでは、意地悪な条件を考えます。今回であれば、停電が連続して発生するケースや、LED球に切り替えたときに本体にある「電球種別スイッチ」の切り替えをし忘れたケース等です。
他にも、風向き切り替えは羽根の回転を逆回しにする事で実現しているので、時間がかかりますので、この回転を切り替えている長時間のあいだに何か処理が入らないかなと考えます。こういう事を考えているときが楽しいですよね。
≡ 次回のお題
次回のお題はこちらです。
今回、割と重いお題となってしまったので次回は軽く扇風機です。
マニュアルはこちらです。
全部のテストは大変なので、おもしろそうな「タイマー」をお題とします。該当部分のマニュアルをコピペしておきます。
設定した時間は扇風機の柱部分にあるスタンドインジケータのランプで知らせます。そこもマニュアルをコピペしておきますね。
≡ おわりに
今回は、「シーリングファン」のテストがテーマでした。
そもそも、仕様がわかりにくいですよね。リモコンも直感的ではないですし。
次回の扇風機は簡単すぎるかもしれません！？
（首振り機能や、リズム運転機能などの付加的な機能との組合せはテスト対象外とします。
「タイマー」機能以外のステキ機能（おやすみ運転機能なども）は無いことにしてください）