【連載】ラズパイとPythonでテスト自動化やってみた #3～AUTOmeal:判定編～

組込み機器のテストの際、地味に面倒なのが結果判定です。

ひたすら積み上げられたテスト項目と手順を眺めつつ、
「ボタンを押して風量が変わった、OK」
「距離値に応じてLEDが点灯した、OK」
という風に、
ひとつひとつOK/NGを確認していくのは気が遠くなる作業ですね。

ぼーっとどこかへ行ってしまいそうになる意識を、必死に現実に引き留めて行う結果判定。

「ヨシ！」
と思っても、やはり人間が実施するものなので、ヒューマンエラーは付きものです。

で、あとになってから確認したはずの部分で不具合が発覚して
「ねえ。これ。ちゃんと確認してOK出したんだよね？ (圧」
なんてこともあったりなかったり…。

そんなときもやっぱりAUTOmeal！！！
ヒューマンエラーに泣く人を減らすために、自動化を取り入れていきましょう。

「パート1：制御」「パート2：計測」に続き、第3回目は満を持して「判定」を行います！

今回も自動テスト初心者の私がトライアルやってみました！
(もうこれで自動テスト経験者にステップアップしてもいいでしょうか…)

はじめに。前回の振り返り

AUTOmealは、組込み機器のテストにおける「制御」「計測」「判定」を、人に代わって自動で実行してくれる、
夢のようなソリューションです。

連載第1回、第2回ではそれぞれ「制御」と「計測」をやってみました。

第1回：制御編の振り返り

制御編では、Pythonスクリプトを使ってデモボードを自動制御してみました！ ボタンをポチポチしたり、距離センサの前で手を近づけたり離したりするところを AUTOmealが代わりにやってくれたわけです。
💡 「【連載】ラズパイとPythonでテスト自動化やってみた #1～AUTOmeal:制御編～」

第2回：計測編の振り返り

計測編では、使用するI/Fボードの設定を追加して、計測をできるようにしました！ ロジックやアナログ、PWMの波形をリアルタイムで計測してAUTOmealアプリ上に表示させるところをご覧いただきました。 波形の表示だけでなく、スクリプトを使って取得した値をログに出力させることもできました。
💡 「【連載】ラズパイとPythonでテスト自動化やってみた #2～AUTOmeal:計測編～」

計測の準備

前回、前々回は「制御」「計測」をそれぞれ実施しましたが、
今回は「判定」と「結果の確認」をメインに行っていきます。

具体的な工程を一連の流れとして実施する今回の構成をご参考にしていただけると
テスト自動化のイメージがより具体的になるのではないでしょうか！

使用するI/Fボードの追加

今回はラズパイの上に載っている全ての拡張I/Fボードを使うため、下図のようにボードを設定しました。
3回目となると、設定も手慣れたものです(かんたんなので元から楽々ですが)。

(余談)手動テスト時代

実際に結果判定の自動化のお話しに入る前に、
すこしだけ手動テストのことについてお話ししたいと思います。

冒頭でも少し触れましたが、
今までのテストはテスト仕様書などに書かれた以下のような項目を参考に、
人が手で操作を実施し、操作した結果が想定通りのものになっているかを判定していました。

• テスト項目
• 確認手順
• 期待する動作 …等

上記のような内容を、↓のようにExcelなどを使って管理されている方もまだまだ多いのではないでしょうか？

テスト系の課だったので、テストガッツリやっとくかということで、
とりあえずひと通り思いつく項目を挙げて実施しました。

単体も統合も妥当性確認も、ぜんぶがぜんぶ結構な項目数になりました。

• ボタンでターゲットのON/OFFがちゃんと切り替わるか
• ブザーの音の高さが変わるか
• 距離センサの前で手を動かして、それに合わせてLEDの色が変わるか

などを一つ一つ確認していましたが、シンプルに疲れました。

テストにNGが出ようものならもう最悪。
不具合修正！
NG項目再テスト！
確認OK！よし、やっとテストから解放！

…かと思いきや。

先輩「じゃあ、影響範囲も再度実施してデグレチェックしてね。結合からでいいから。」

え、NGやり直すだけじゃないの？
”からでいい”って何？
と思わず顔に出てしまった思い出…。

実際の開発の際も妥当性確認の作業に入ったときには上のようなテスト仕様書を渡され、
それに沿ってテストを実施しました。
ひよっこゆえ、妥当性確認中分からないところがある度に先輩に聞きに行っていました。

手動テストだと、このようにテスト実施者の負担が大きくなったり(手戻りがあるとさらに大変)、
経験値の差が出てしまうことがありました。

そんな課題を解決するためにもAUTOmealは生まれたんですね。
(個人的に「あの時AUTOmeal的なものがあれば」と思わずにはいられない。)

結果判定の自動化

さて、それでは自動テストの方に入っていきましょう！
まずはテストシナリオについてです。

テストシナリオ

第1回、第2回目の記事では、それぞれ制御と計測だけをスクリプトの命令として書いていました。
ターゲットの動作を計測するだけでなく、その結果が想定したものかを判定するように書きます。

といっても、トライアルセットでの接続は限られているため結果判定をするスクリプトだけ今回はご紹介します。

今回は計測の対象としてLEDとフィンの状態を見てみます。

• 距離値に応じたLEDの点灯 (Logic)
• MT状態のフィンの動作(PWM)

以下のような内容を判定していきます。

• LED：一定の距離より遠いときにLEDは消灯しているか
• フィン：MTのときフィンの動作は停止しているか

それに対し、Python上では以下のような値が取得できます。

• Logic：計測ラインの”Hi = 1 / Lo = 0”をint値で取得
• PWM：計測ラインの”周波数、デューティー比”を取得

これらを踏まえて、実際の判定スクリプトを作成していきます。
次に続きます。

LEDの状態判定

トライアルセットのLEDは距離値に応じて点灯個数が変わり、
距離値の元の電圧が高くなるほど(距離が近くなるほど)、点灯個数が増えていきます。

今回は距離値の元の電圧が2300mV以下(およそ10cmよりも遠い)のときに
赤いLEDが消えたままかどうかを確認します。

距離値(アナログ入力)とLEDの点灯・消灯(ロジック入力)が計測できるため、
それらを組み合わせ if 文と assert 文を使用して作ってみました。

assert 文とは、条件式がTrueではない時に例外を投げるものです。
(== False と指定することで、Falseではない時に例外を投げるようにもできます。)
コードが予期せぬ動作をした際に、例外を投げて処理が止まります。
自動テストは人が付きっ切りでない状態で実行することが多いと思います。
そんなときに予期せぬ動作をしたまま処理が動き続けてしまうと、
気付いたら大変なことになっているかもしれません。

そこで、 assert 文を使っておくと、勝手に例外を投げて処理を止めてくれるため安心です。
(例外処理のケアがしきれていないときに使えますね)

以下のようなスクリプトになります。
距離センサで取得した電圧が2300mV以下の場合は消灯しているはずのため、
Lo(False)になっている場合は、例外を投げます。
※このLEDはHi(True)が消灯、Lo(False)が点灯の状態です。

スクリプトは以下のようになります。

import automeal as am
import time

# 待ちを行います。
time.sleep(1)

# GP10制御ch1～ch3 初期化します。
# 制御ch1～3 をHiにします。
print(“ch1~3の初期化としてHiにします。”)

am.write_logic_rpigp10(“Board1”, 1, True)

# 待ちを行います。
time.sleep(0.5)

am.write_logic_rpigp10(“Board1”, 2, True)

# 待ちを行います。
time.sleep(0.5)

am.write_logic_rpigp10(“Board1”, 3, True)

# 待ちを行います。
time.sleep(1)

# 距離センサから取得した電圧値を計測します。
print(“Board3 (アナログ入力ボード)の入力ch1 の計測を行います。”)
result_analog = am.read_analog_cpiai1208li(“Board3”, 1)
print(“電圧値：%dmV”%(result_analog))

# 待ちを行います。
time.sleep(1)

# Hi/Loを表示します。
print(am.read_logic_rpigp10(“Board1”,1))

# 待ちを行います。
time.sleep(1)

# 電圧値にLEDの消灯が対応していない場合例外を投げます。
# HiがTrueで消灯, LoがFalseで点灯
if result_analog < 2300:
    assert am.read_logic_rpigp10(“Board1”,1) == True
else
    assert am.read_logic_rpigp10(“Board1”,1) == False

# 待ちを行います。
time.sleep(1)

フィンの状態判定

トライアルセットのフィンは、ターゲットデモボードがATのときは
デューティー比がおよそ “9.0%” と “4.5%” を行き来しながら、パタパタと動きます。
ターゲットデモボードがMTのときは、デューティー比およそ “6.5%” の状態で停止しています。

なので今回はMTモードのときに、デューティー比がおよそ “6.5%” であるかを確認します。
デューティー比が想定される範囲内に収まっているかどうかを if else 文で判定しました。

Pythonは習得の難易度が比較的低い言語でありながら、できることもいっぱいです！
今回はかんたんなスクリプトしか作成していませんが、
ライブラリなども活用すると、もっといろんな判定や結果表示が実現できます。

スクリプトは以下のようになります。

import automeal as am
import time

# 待ちを行います。
time.sleep(1)

# GP10制御ch1～ch3 初期化します。
# 制御ch1～3 をHiにします。
print(“ch1~3の初期化としてHiにします。”)
am.write_logic_rpigp10(“Board1”, 1, True)

# 待ちを行います。
time.sleep(0.5)

am.write_logic_rpigp10(“Board1”, 2, True)

# 待ちを行います。
time.sleep(0.5)

am.write_logic_rpigp10(“Board1”, 3, True)

# 待ちを行います。
time.sleep(1)

# フィンからの入力を計測します。
print(“Board4 (PWM入出力ボード)の入力ch1 の計測を行います。”)
result_freq,result_duty = am.read_pwm_ampio(“Board4”,1)

# 待ちを行います。
time.sleep(1)

print(“実行時の計測値は以下でした。”)
print(“周波数：%dHz”%(result_freq))
print(“デューティー比：{:.1%}”.format(result_duty/100))

# 待ちを行います。
time.sleep(1)

# 計測結果を判定します。
if result_duty >= 6 and result_duty < 7:
    print(‘OK：想定される範囲内です。’)
else :
    print(‘NG：フィンの状態を確認してください。’)

# 待ちを行います。
time.sleep(1)

「あれ？計測しかしてなくないか？制御はどこいった？」と思われた方もいるかもしれません。
・・・そうです、トライアルセットでは制御した結果、計測する部分に反映されるような動作はありません。

ですので、トライアルの際は是非実際のターゲットに繋いでお試しいただけると
より具体的に制御、計測、結果判定の流れを理解することができるかと思います。

実機への接続時にお困りのことがあれば、サポートもしますので
自分が自動化したいテストを実際に実機でやってみることをおすすめします！

スクリプトの実行と結果の確認

話が逸れましたが・・・
今回はコマンドラインから上記のスクリプトたち + αを実行してみました！

AUTOmealはアプリ上から実行したいスクリプトを選択してデバッグ的に実行することもできますが、
実際自動でテストを流すときはコマンドラインから実行することが多いですよね。
CIツールを使うことで、毎週金曜のこの時間からスクリプトを自動で流すなんてこともできます。
そのあたりは、またの機会にCIツールでの自動実行について記事にできたらなと思っています！

CLIでの実行ではプロジェクトフォルダの下の “Scripts” というフォルダに入れているスクリプトが実行されます。

コマンドラインからスクリプトを実行すると、コマンドライン上では下記のように処理が流れていきます。
処理がどこまで行ったのかや、どんな値が入ったのかを確認したい場合は print 文を使って、
後から確認できるようにしておくと、予期せぬ何かがあったときなどに対応しやすいです！

テスト実行後は、プロジェクトフォルダの下の “Reports” フォルダに実行結果が作成されます。
全体の実行結果と各スクリプト(.pyファイル)ごとの結果が確認できます。

全体の実行結果を記録する “Result.csv” を見ると、そのスクリプトが問題なく終了したかどうかが分かります。
スクリプトの中でのOK/NGではなく、スクリプトの実行が正常に完了したか(Pass)、
問題があり完了できなかったか(Failed)などが分かります。

CLIからの実行の際のオプションや、”Result” 部分の説明などはチュートリアルに詳しく記載しています。
トライアルの際に是非見ていただけると嬉しいです。

各スクリプト(.pyファイル)ごとの結果の中身は下図のようになっています。
OutputLog.logを開くと、コマンドラインに表示されていた内容も確認することができます。

また、Zip化されているレポートをアプリから開くと、そのときの波形の確認もできてしまいます！
ログファイルだけでは分かりづらい実際の内部の動きもかんたんに確認できるのはありがたいですね。

自動で結果判定してみた感想

ひとことで言うと、かんたんにいろいろできそう。

ベースがPython言語なので、今回のように割とシンプルな判定もできますし、
複雑な判定処理を書いて厳密な判定を実現することもできそうです。
設定もかんたんだし、スクリプトも一度書いてしまえば実行させるだけで
回帰テストもスクリプトを回すだけになるので、精神的にくる地獄の再テストからも解放されそう。
(実際はスクリプトの正当性を評価したり、もう少し作業が必要だと思いますが)
何より今まで都度手動で行っていた作業の手間が省け効率化が図れますし、楽。

判断や判定って、個人的に人間が頭で考えてやるイメージがあります。
ですが、人間よりも機械の方が(たいてい)正確で頭がいいんだから機械にやってもらった方がいいかなと思います。
また、人がやるとどうしてもふわっとした部分が出てくるのではないかなと思います。
そうすると、実施者によって結果判定のばらつきが出てしまったりもしますよね。
そういうところを避けるためにも機械にはっきりとOK/NGを判定してもらうのがいいですね。

結果判定部分に限った話ではないし、以前にも書いたかもしれませんが、
やっぱりツールの学習コスト的にもコスパがいい気がします。
使い方が難しくてノウハウを持ったそのツールのエキスパートしか
なかなか使いこなせてないツールもたまにあったりするかと思います。
その点、AUTOmealは設定も操作もかんたんで誰でもすぐに使いこなせそうだなと感じました。

スクリプトはPython言語なので、使った経験がある人も多いと思いますし、
初めて書く人も言語自体の難易度が低いのですぐにできるようになると思います。
ツールを使うにあたって習得したPythonの書き方も個人の経験、資産として残り、
その後のエンジニアライフにも役立つものになるのではないでしょうか。なんだかお得！！

最後に

いかがでしたか？

これまで3回にわたってAUTOmealでの「制御」「計測」「判定」について連載してきました。
なんとなくイメージが湧いたという方がいらっしゃれば幸いです。

テスト自動化やってみた！的な記事を書いてきましたが、
正直、振り返っていただくとお分かりになるかも、なのですが…

私、ほとんど何もしてません。
だいたいAUTOmeal任せでした。
(自動化なのでそりゃそうですね)

楽することは悪いことではありません。
開発も楽しく、楽にやっていきたいですよね(*’▽’)
気の遠くなるようなテスト作業はAUTOmealに任せて、そこで温存した労力や時間を他のことに充てていきましょう！

そして、結果判定まで終わったからといって、今回でAUTOmealについての連載記事が終了するわけではありません！
3回の連載ではお伝えしきれていない情報がたくさんあります。
今後もまだまだ続くのでご期待ください(*^-^*)

さっそくですが次回はシリアル通信の自動化についてお話ししたいと思います。
今後ともよろしくお願いいたします！

最後までお読みいただき、ありがとうございました！