ソフトウェアテスト

Windowsアプリケーションを自動操作するAutoIt

Windowsアプリケーションのテストでは、GUIを操作することが多い。

その操作を自動化できれば、手間を大幅に減らすことができるし、最初に正しい手順を決めてしまえば、間違いが起こらない。

とりわけ毎回同じことをするスモークテストで、自動化の効果は顕著だ。

テストの自動化は、WindowsのUIオートメーション機能を使って自分で実装してもよいが、世の中には既に優れたツールがある。

例えば、AutoItがそれだ。

このツールはとても良くできていて、Windows操作を記憶して、その記憶を、AutoIt独自の言語で書いたスクリプトに変換する。

そのスクリプトを実行すれば、何度でも同じ操作を再現できるので、いつも同じことをするようなテストでは大幅に手間を減らせて、ヒューマンエラーも防げるというわけだ。

【注意!】
ところで、このツールを使う時、一つ注意することがある。
それは、インストールしただけでは、Pathが通っていないことだ。

インストール後、忘れずに、

"C:\Program Files (x86)\AutoIt3\Extras\Au3Record"

をPathに追加しておかないと、操作を記録しようとすると、"DLL Load failure"というエラーが出る。

忘れやすいので、注意が必要だ。

| | コメント (0) | トラックバック (0)

gcovでカバレッジテストをしてみる

「知識ゼロから学ぶソフトウェアテスト」の21ページから24ページにかけて書かれている、ステートメントカバレッジ(C0)とブランチカバレッジ(C1)の例が、gcovではどのように解析されるのかを確認してみた。

下の関数をテストする。

func(int con1, int con2)
{
int x = 1;

if (con1 == 0) {
x = x + 1;
}

if (con2 > 1) {
x = x * 2;
}

printf ("x = %d\n", x);
}

ステートメントカバレッジでは命令文(ステートメント)の実行状況を確認する。
開発者なら、

x = x +1
や、
x = x * 2

のコードが正しく実装できているかが気になり、例えば下のようなコードを使って、con1=0かつcon2=2の条件で、関数funcを実行してみるのではないだろうか。

main()
{
func(0, 2);
}

mainとfuncをtmp1.cというファイルに保存してgcovで解析する。

>gcc -fprofile-arcs -ftest-coverage -o tmp1 tmp1.c
>./tmp1
x = 4
>gcov -b tmp1.c
File 'tmp1.c'
Lines executed:100.00% of 11
Branches executed:100.00% of 4
Taken at least once:50.00% of 4
Calls executed:100.00% of 2
tmp1.c:creating 'tmp1.c.gcov'

命令文は100%実行されているが、ブランチ(分岐)で分かれるバスの50%が抜けていることがわかる。
このため、開発者がcon2>1と書くべきところをcon2>0と書いてしまったバグはこのテストでは見つけられない。

そこで、すべてのブランチの条件判定結果がTRUE、FALSEを少なくとも一回づつになるようにテストケースを書く。今の場合は、con1=0かつcon2=2のテストケースと、con1=1かつcon2=1のテストケースを書けば良いので、例えば下のようなコードを書く。

main()
{
func(0, 2);
func(1, 1);
}

このmainとfuncをtmp2.cというファイルに保存してgcovで解析する。

>gcc -fprofile-arcs -ftest-coverage -o tmp2 tmp2.c
>./tmp2
x = 4
x = 1
>gcov -b tmp2.c
File 'tmp2.c'
Lines executed:100.00% of 12
Branches executed:100.00% of 4
Taken at least once:100.00% of 4
Calls executed:100.00% of 3
tmp2.c:creating 'tmp2.c.gcov'

今度はブランチから分かれるすべてのパスを通っており、開発者がcon2>1と書くべきところをcon2>0と書いてしまったバグも見つけることができる。

このように、ステートメントカバレッジはテストとしては弱いものであるので、単体テストではブランチテストも合わせて行い、できるだけ高いカバレッジ率になるようにテスト計画を立てるのが良い。


知識ゼロから学ぶ ソフトウェアテストBook知識ゼロから学ぶ ソフトウェアテスト


著者:高橋 寿一

販売元:翔泳社
Amazon.co.jpで詳細を確認する


| | コメント (0) | トラックバック (0)

単体テストを意識してソースコードを書く

ソフトウェアの単体テストは、コードを書く時から意識していないと、きちんと行うことは難しい。

オブジェクト指向プログラミング言語でコードを書いている場合は、クラスとクラスの依存関係が多かったり、OSやミドルウェアとの依存関係が多かったりすると、後から単体テスト用のモッククラスを作るのに、かなりの労力を必要とする。

もともとモッククラスを作るのには、手間がかかるので、あとからクラスの依存関係を分析しながらモッククラスを作るのは、経験豊富なプログラマにとっても気が重くなる仕事であることだろう。

そこで、モッククラスを作る時間がない場合などはデバッグ手法をつかって、単体テストの代わりをすることになるのだが、この方法は後々のことを考えると賢明は方法とは思えない。

確かにその時は、単体テスト相当のことができるだろうが、テストコードが後に残らないので、後になって他の人が同じコードをテストしなくてはならなくなった場合や、最初にコードをテストした本人が数ヶ月後にまたテストをしなくてはならなくなった場合に、同じテストができる可能性がかなり小さい。

単体テストがしやすいように、最初からテストを意識したソースコードを書くことを心がけたい。

★WOZ★

知識ゼロから学ぶ ソフトウェアテスト Book 知識ゼロから学ぶ ソフトウェアテスト

著者:高橋 寿一
販売元:翔泳社
Amazon.co.jpで詳細を確認する

| | コメント (0) | トラックバック (0)

スモークテストの由来

ソフトウェア開発で、ビルドの後、そのビルドが成功していることを確認するために、広く浅く行うテストのことをスモークテストという。

実は「スモークテスト」という言葉は、ソフトウェア工学が始めて使ったものではなく、昔からある言葉だ。

例えば、配管を組み立てたり修理した後、パイプに漏れがないことを確かめたり、電子回路を組み立てた後、始めて動かしたときに回路が焼けて煙がでないことを確かめたりすることを「スモークテスト」と呼ぶ。電子回路の場合はまさに煙が出るので、スモークテストのイメージがよくわかる。

これ以外でも、木管楽器を組み立てたり修理した後で、キーから空気が漏れていないことを確認することも「スモークテスト」というそうだ。

ビルド後に行う開発やテストは、そのビルドが成功していることを前提としている。それを保証するために、スモークテストは必ず行う必要がある。

★WOZ★

知識ゼロから学ぶ ソフトウェアテスト Book 知識ゼロから学ぶ ソフトウェアテスト

著者:高橋 寿一
販売元:翔泳社
Amazon.co.jpで詳細を確認する

| | コメント (0) | トラックバック (0)

スモークテストは自動化に向いているテストだ

ソースコードを更新した後、ビルドが成功していることを確認するスモークテストは、自動化に向いているテストの一つだ。

例えばWindows上の開発なら、UIオートメーションを使うと、GUIのテストまで自動化できるので、テスト工数を大幅に削減できる。

またLinux上の開発では、Dogtailを使うとGUIテストを自動化できる。

スモークテストはビルドの度に繰り返されるので、この工数削減は非常に効果的だと言える。以前見積もった一例をあげると、自動化コードの作成コストは、2回のスモークテストで元がとれるケースがあった。

もちろん、いつまでたっても自動化コードを継続的に追加したり修正したりする必要があれば、それだけ自動化によるコスト削減効果は薄れることになる。どこまでを自動化し、どこからを手作業でテストするのかの判断が重要だ。

★WOZ★

知識ゼロから学ぶ ソフトウェアテスト Book 知識ゼロから学ぶ ソフトウェアテスト

著者:高橋 寿一
販売元:翔泳社
Amazon.co.jpで詳細を確認する

| | コメント (0) | トラックバック (0)

大切なのはツールを使いこなすことだ~静的解析ツールの誤検知

ソースコードの静的解析は、ソフトウェアを動かすことなく字面から、バグの可能性を見つけるために行う。静的解析ツールとしては、QAC、QAC++が有名だが、最近はPreventもよく使われるようになっている。

しかし、いずれのツールを使うにせよ、バグの誤検知や過剰検知が起こりうる。静的解析ツールを使う上で気をつけなくてはいけないのは、それら誤検知や過剰検知を精査することを忘れてはならないということだ。

実際に、ある開発チームでは、QAC++の検知結果をすべて真に受けて、本来修正しなくても良いところまで修正することに決めたため、その修正作業に多くの時間を使ってしまった。そして、その無駄を残業や休日出勤で補うことになった。さらに悪いことに、本来触らなくてもよい部分まで修正した際に、新たなバグを埋め込む危険まであったのだ。

実はそのチームには、QAC++の検知結果を精査する目利きがいなかったために、そのようなことになったのだが、この話から得られる教訓は、どんなツールを使うにせよ、ツールに使われるのではなくツールを使いこなすことが重要だということだ。

★WOZ★

知識ゼロから学ぶ ソフトウェアテスト Book 知識ゼロから学ぶ ソフトウェアテスト

著者:高橋 寿一
販売元:翔泳社
Amazon.co.jpで詳細を確認する

| | コメント (0) | トラックバック (0)

スモークテストは必ず実施しよう

ソフトウェアのソースコードを追加、削除、修正してビルドしたときに、これまで動いていたソフトウェアが動かなくなってしまうことがある。しかも、ソフトウェアの規模が大きくなればなるほど、そういうことは起こりがちだ。

ビルドして動かなくなってしまったら、その後に続く実装、テスト、バグ調査が実質的にできなくなってしまう。

そんな事態に陥るのを避けるために、ビルド後すぐにソフトウェアが動くことを確認するテストを行う。このテストをスモークテストという。

スモークテストではビルドが成功していることを確認できれば良いので、広く浅いテストでよいが、ビルドしたときには毎回、全テストをする必要がある。

スモークテストにより、ビルドの失敗を早期に発見できれば、開発者が、正しく動いていないソフトウェアを使って、実装、テスト、バグ調査をする無駄を排除することができる。

★WOZ★

知識ゼロから学ぶ ソフトウェアテスト Book 知識ゼロから学ぶ ソフトウェアテスト

著者:高橋 寿一
販売元:翔泳社
Amazon.co.jpで詳細を確認する

| | コメント (0) | トラックバック (0)

Linuxでのカバレッジテスト

LinuxでC/C++を使ってソフトウェアを作る場合、カバレッジテストにはgcovを使うと良い。カバレッジテスト用の製品としてはIBMのPureCoverageが有名だが、一本20万円以上するので、気軽に使ってみるというわけにもいかないだろう。

その点、gcovならLinuxに標準で入っているし、使い方も簡単なので導入も用意だ。

例えば、test.cというファイルに書かれたCのプログラムについて、カバレッジテストを行う場合、次のようにしてC0とC1のカバレッジを算出することができる。

$ gcc --coverage test.c

$ ./a.out

$ gcov -b test.c

テスト結果は、test.c.gcovという名前のファイルに出力されるので、次のようにして確認できる。

$ less test.c.gcov

★WOZ★

| | コメント (0) | トラックバック (0)

テスト駆動開発

実際に導入してみて成功した開発手法に「テスト駆動開発」がある。

テスト駆動開発は、次の1〜4を繰り返すことでソフトウェアを作っていく開発手法だ。

  1. 最初に、ユニット(関数やメソッド)が正しく実装されていることを検証するテストコードを先に書く(テストファースト)
  2. 次に、そのテストを失敗させるようにユニットを実装する(実際は有効なコードは何も書かない。例えば、return (false)等を書く)
  3. その後、仕様を満たすようにユニットを実装してテストを成功させる
  4. 最後にそのユニットのコードを整理して完成させる(リファクタリング)

この手法はソフトウェアが満足すべき仕様をテストという形で定義できるので、設計の検証を早く行えるというメリットがある。

また、3の段階でとりあえず動くソフトウェアが手に入るので、結合テストを早く始められるというメリットがある。

さらに、1で書いたテストコードはスモークテストにも使えるので、ユニットの修正による新たなバグの埋め込みを早期に見つけることができる。

このテスト駆動開発を支援するツールは、プログラミング言語ごとに用意されている。

  • C++にはCppUnit
  • C#にはNUnit
  • PythonにはPyUnit
  • JavaにはJUnit

という具合だ。

★WOZ★

| | コメント (0) | トラックバック (0)

UIオートメーションによるWindowsアプリケーションの自動テスト

WindowsのGUIアプリケーションのテストは、UIオートメーションにより自動化できる。

UIオートメーションは、Windows Presentation Foundation (WPF) をサポートするすべてのオペレーティングシステムで利用可能な、Microsoft Windows の新しいアクセシビリティフレームワークだ。

自動テストを実行する側のプログラムは、UIオートメーションの動作原理がわかってしまえば簡単に作ることができる。まずは、UIオートメーションの概要を簡潔に説明していて、サンプルプログラムがわかりやすい@itの記事を読むのが良いだろう。またUIオートメーションの詳細はMSDNに記載されている。

実際の開発に適用したところ、手作業でテストにするのに比べて大幅にテスト時間とコストを削減することができた。

注意すべきことは、マイクロソフトにより、テスト可能なGUI部品が順次追加されているものの、自動テストに対応していない部品があるということだ。

もし、ある部品が自動テストに対応していないなら、対応している部品で置き換えられれば一番良い。しかし、顧客の要求その他の理由で、そうできない場合もあるだろう。自動化できない部品が関係するテストは手作業ですることになるが、その場合でも自動化の恩恵は得られるだろう。

しかし、最初から自動テストに対応している部品を把握しておき、それらの部品だけを使ってGUIを構成することを目標にして、顧客との間で要求仕様をまとめていくのが最善だと思う。

★WOZ★

| | コメント (0) | トラックバック (0)