カテゴリ:テスト( 5 )
Testlink1.9.9とredmineを連携させる。
目的:
Testlink1.9.9とredmineを連携させる。

手順:
1.TestlinkのSystem>Issue Tracker Managementを選択する。
b0232065_19224199.png
2.Issue Tracker Managementを選択すると以下の画面が表示される
b0232065_19224175.png
Typeを選択すると連携するバグトラッキングシステムを選択できる。
この場合は「redmine」を選択する。
その後に、Show configuration exampleを選択すると、該当のバグトラッキングシステムの設定のサンプルが表示されるのでそれをもとにConfigurationを記述する。
変更すべきは以下の通り
<apikey> Redmineで作成したAPIキー
 e4a413a3b7a3c238102b7393c035bbc5f5eb6409
uribase RedmineのURL
 http://192.168.67.128/redmine/
uriview RedmineのissuesへのURL
 http://192.168.67.128/redmine/issues/
projectidentifier Redmineのプロジェクト名
 test

3.testlinkのプロジェクトで先ほど追加したIssue Trackerを選択する
b0232065_19224223.png
5.テスト実行結果でチケットへの作成リンクが行える
b0232065_19224178.png
リンクは既存のチケットを選択してそれにリンクをはる。
作成は以下のように、新しいチケットを追加する。
b0232065_19224113.png
チケットのタイトルにはテスト仕様のテストスイート名とテストケース名から作成される。
テストリンクで記述した内容がチケットにも記述される。
b0232065_19224157.png

[PR]
by mima_ita | 2014-04-27 19:51 | テスト
TestLink1.9.9を使ってみた
Window7のXAMPP1.8.3にTestLink1.9.9を入れてみた・・・

うごかねぇ


Login画面を表示しようとしているところで、Smartyがエラーを吐いているようなので、下記を最新に置き換える。
testlink\third_party\smarty3

下記のページよりダウンロード
http://www.smarty.net/download
Smarty 3.1.18 [Smarty-stable.tar.gz] [Smarty-stable.zip]

無事動くようになる。

ちなみにdebian6+PHP5.4の場合は素直にインストールできたので環境依存だと思われる。


1.7系からの変更点
ステップと期待値が記述できるようになっている(昔からだっけ?)

プラットフォームを追加できる。
これにより同じテストをWin7用、WinXP用といった別プラットフォームで行えるようになる。これはいい変更

外部APIが使えるようになっているようだ。

TracやRedmineとの連携は Issue Tracker Managementで行うようになっている。

CSVのインポートはなくなったようだ

Excelのテストケースのインポートの仕方。
昔はCSVから変換ツールがあったがなくなった。
なんか、外国産のコンバーターツールもあるが、例によって日本語が化ける(まぁ作成したXMLをUTF8に変換すればいい)

よろしい。なければつくろう。
http://needtec.sakura.ne.jp/release/testlink.xlsm

Excelで入力した項目でTestLink用のXMLに変換するぞ。
ステップと期待値はALT+ENTERでセル内で改行すると、それを1ステップとしてかぞえる。
中項目、小項目は省略できるぞ。その場合は大項目の下にテストケースが作成される。

昔、似たようなツールを新入社員の研修課題にしたが、MSXMLのDOM操作が結構めんどくさい。
(´・ω・`) ナンカスマンカッタ。



[PR]
by mima_ita | 2014-04-20 20:35 | テスト
JsTestDriverを使ったJavaScriptのテスト
JsTestDriverを使用するとJavaScriptの自動テストができます。
http://code.google.com/p/js-test-driver/

テストの手順は次のような感じです。
1.JsTestDriverのサーバーを起動します。
java -jar JsTestDriver.jar --port 4224

2.テストを実行したいブラウザで上記のサーバーに接続します。
FireFox、IE,Safariなど一度に複数のクライアントが接続できます。

3.テストを記述します。また、同時にフォルダの構成などを記述する設定ファイルを書きます。
このあたりの書き方は以下を参照
http://blog.asial.co.jp/1051

4.テストを記述したフォルダで以下のようなコマンドを実行します。
java -jar JsTestDriver.jar --tests all

これにより、現在、port4224に接続していた全クライアントのブラウザで同じテストがじっこうされます。


さて、問題はテストのログに日本語を使うと文字化けすることです。
http://qiita.com/opengl-8080/items/009eb0a2b89f3751ecd1

じつは、この問題は、パッチで回避できます。
http://confluence.jetbrains.com/display/WI/Patched+JsTestDriver-1.3.5
上記のページからJARファイルを直接ダウンロードもできますし、
1.3.5のバージョンに差分をあてる方法があります。
以下のソースをもとに
http://js-test-driver.googlecode.com/archive/v1.3.5.zip

下記の内容を適用してビルドすればよいでしょう。
http://git.jetbrains.org/?p=idea/contrib.git;a=blob_plain;f=JsTestDriver/lib/jstestdriver-core/jstd-1.3.5-issue-85-fix.patch;hb=HEAD

gitで開発中のバージョンをみると上記のパッチは次回のリリースに適用されそうな感じです。

テストケースのメソッド名は"test xxxx"とつけないと認識しないようだ。
TestCase("ObservableNotifyObserversTest", {
  "エラーが発生してもNotifyが実行される : function() {
    // これは認識しない
  },
  "test エラーが発生してもNotifyが実行される" :function() {
    // これは認識する
  }
});


[PR]
by mima_ita | 2013-12-29 21:23 | テスト
レガシーなテスト環境の作成方法
レガシーな環境でテストを行うにはどうするか?
最前は実機を用意することだ。 なければ、VirtualPCを使用すればよい。 (当然、シビアなタイミングなバグとかは再現しない場合もある)

今回の例ではWindows7 HomeEditionをホストとして XP + IE6.0の仮想マシンの環境を作成する。


手順:

1.下記のページよりWindows Virtual PCを取得する
http://www.microsoft.com/ja-JP/download/details.aspx?id=3702

2.Microsoftのページより任意の仮想マシンをダウンロードする。
http://www.modern.ie/ja/virtualization-tools#downloads

このページにはWinXP-IE6の古い奴からWin7のIE10の環境までそろっている。また、Macの環境も用意してある。 ここから、好きなイメージを取得すること。

3.ダウンロードしたイメージを回答すると下記のファイルがあるので実行する。
IE6 - WinXP.vmc

4.デフォルトで用意されているユーザーにIEUserが存在する。
しかし、初期設定としてパスワードが設定されていない。
XPにログインするには「ツール→統合環境を無効にする」を選択しなければならない。

統合環境を無効にした場合、ホストのクリップボード内容を仮想マシンにコピーしたりできなくなる。
なので、仮想マシンにログインしたら、ただちにIEUserにパスワードを作成して統合環境を有効にしなければならない。

WindowVista 以降の仮想マシンの場合のIEUserのパスワードは次に記述してある。
https://modernievirt.blob.core.windows.net/vhd/virtualmachine_instructions_2013-07-22.pdf


5.HTTP経由でホストに接続するにはネットワークの設定が必要である。
ホスト側のWin7にMicrosoft Loopback Adapterを導入する。
http://blogs.wankuma.com/hatsune/archive/2010/05/13/189032.aspx


次にVirtualPCのネットワークの設定をする。
b0232065_1125307.png


この時点で、Win7と仮想PCのXpでipconfigを行うとそれぞれに新しいネットワークアダプタとIPが割り当てられている。 そのIPを使って互いに通信できる。 なお、ファイアウォールを適切に設定しないとVista以降はPINGが通らないので焦らないこと。


問題:
・1月でアクティベートしないと使えなくなる。
期限がきたら、仮想マシンの環境を一旦削除して、初期化しなおせばよい。


・英語しかしようできない。
日本語フォントを仮想マシンに入れればよい。
http://ipafont.ipa.go.jp/ipafont/download.html

各アプリケーションはそのフォントを選択する。
IEなどは日本語ページを開くと自動で選択してくれる。

・キーボードは英語配列なので、文字の入力はホストからクリップボード経由で転送したほうが楽
ドライバーの更新を以下のページを参考に行なえば、キーボード配列は日本語にできる
http://doratech.jugem.jp/?eid=40
[PR]
by mima_ita | 2013-11-12 11:29 | テスト
実際にやったDBの自動テスト方法
■目的
ここでは実際にやった、Databaseの自動テストにまわりについて記述する。
OracleとSQLServerが対象になる。

■環境について
ベストは開発者毎のインスタンスを用意する。
インスタンスが1つしか用意できない場合はスキーマーを区切る。

最悪は全ての開発者が1つの環境を使うことである。
なぜ最悪かというと、ある開発者がおこなったテストが別の開発者に影響をあたえる可能性があるからだ。
これは非常にリスクが高い。

また、開発者毎のPCにデータベースをおくかどうかは議論が出るところである。
少人数で制御がきくなら個人の端末に環境を用意したほうが望ましい。
しかし、その制御が利かない場合、必ず古い環境で開発を続行し続けるという人間がでる。
・・・であれば、DB管理者が全ての開発者のDBを管理するというのが望ましいかもしれない。

このあたりは開発者の力量しだいだろう。開発者を信頼できない場合は、絶対にローカルにDBを作らせない。
ローカルにDBをつくるメリットをはるかに超える余計な問題を生む。

■環境の同期
開発者毎に環境を用意した場合、問題になるのはDBの同期である。
ストアドプロシージャーはスクリプトで管理する。
これを自動で適用する。

なお、ほぼ全てのDBはストアドプロシージャーはシステム用のテーブルに格納されているので、そこから取得できる。
つまり、全てのファンクションを抜き出してMD5で表現してしまえば、自分の環境が最新かどうかチェックするのは容易だ。

問題はテーブル構成などが変わった場合。
これは自動で行うのは危険だ。慎重に行うべきだ。

なお、勘違いしている人もいるが、列の追加とか削除も大抵スクリプトでできる。


■テストの方法
自動テストは3段階にわかれる。

1.テストデータの準備
2.テストの実行
3.結果の検証。

1は確実に行える。
やりかたとしては2通りあり、テーブルを空にしたあと、INSERTのスクリプトを投げてテストデータを作る方法。
次にフルバックアップをリストアする方法だ。
フルバックアップは管理者権限がないと厳しいのでスクリプトをなげる方法のほうがいい。
あと、生データだとどんなデータか確認できるが、バイナリだと厳しい。

2テストの実行は任意のストアドなり、プログラムを動かせばよい。
ADO経由すればWSH経由でストアドだろうがなんだろうが実行できる。


3結果の検証が一番困難だ。
テストの実行の内容によってここは2種類ある。
1つは参照系のテスト実行だ。
これは、期待値を外部ファイルなりに保持しておき、それと参照した内容をつき合わせて確認する。
この時、注意すべきはどのデータを取得するべきかだ。
可変の列は比較から除いたほうがいい。たとえば、更新日やユーザー名は変わる可能性があるので、比較に使用しない方が望ましい。
ちなみにORDERBYを聞かせたほうがテストはらくだ。テスト対象のファンクションが行の順番不動の場合、結果の検証はめんどくさい。

つぎに更新系のテストだ。
これは更新をおこなったあと、テーブルを参照して期待どおりに更新されているか確認する必要がある。
理想を言えばのテーブルの内容を抜き出して関係ないテーブルに影響がないことを確認すべきだろう。
しかし、これは時間がかかるのでやめておいたほうがいい。
更新ロックがかかっているかどうかの試験もやろうと思えばできる。
これは、スクリプトで指定のテーブルに更新ロックを掛けて待機する。
その間にテスト対象の処理を実行して例外がかえってくることを確認する。
テストがおわったらスクリプトを終了してやって、再度、実行して今度は正常に動作することを確認すればよい。
これは、更新ロックのチェックがNOWAITの場合のみできる。

これらは、WindowsであればWSHでADOを使用すればスクリプト言語で全て記述できるし、おおくのDBの場合、コマンドプロンプトから実行できるようなツールが提供されている。

なお、どの環境でも、動くテストを記述することが重要だ。
ユーザー名とかはテスト用のユーザを共通でつかったほうが楽だろう。

■DBの自動テストの問題
DBのテストの最大の問題は時間がかかることだ。
テストデータの準備、テストの実行などは通常の単体テストよりコストのかかる処理だ。
自動テストを入れている場合、このDBのテストを行うかどうかはオプションで指定できるようにしたほうがのぞましい。


あと自動化のつねとして、本番環境を飛ばさないような工夫が必要だ。
本番環境とテスト環境のログインユーザーなどが同じなどは本番データを吹き飛ばす可能性があって危険だ。
とくにテストデータをスクリプトで管理していると、それをまちがって本番に流しかねないリスクがある。
可能なら、テストデータのスクリプトの先頭に想定以外のDBではテストを中断するなどのロジックが必要かもしれない。


以上
[PR]
by mima_ita | 2012-10-03 00:40 | テスト



実験ですお
検索
カテゴリ
最新の記事
.NET4.5におけるasy..
at 2014-07-02 00:46
.NETでTwitterを検..
at 2014-06-29 00:49
Redmineのプラグインで..
at 2014-06-28 03:29
IO.popenのwrite..
at 2014-06-28 03:25
RedmineのWikiでU..
at 2014-06-28 03:16
以前の記事
最新のトラックバック
その他のジャンル
ブログパーツ