Webアプリケーションテスト手法
Webアプリケーションを開発する側にたち、テスト手法を「テストの自動化（駆動開発）」「非機能テスト（性能、セキュリティ）」を中心について解説。対応言語（Perl、ActionScript、PHP、Ruby、JavaScript）の専門家が執筆しているところも特徴的。この本で学んだものをより効率的・効果的にテストへ活かすには、テスト戦略・設計にかかわる本もあわせて読むと相乗的に品質を上げることが可能かも。
| 固定リンク | コメント (0) | トラックバック (0)
トラブルをきっかけに、”メンテ”イップスに。なりたくないねえ。
==
仕事の中であまりperlは扱わないのですが、
特集 Happy Testing Perl by 技術評論社
この特集では，TAPをはじめとしたPerlプログラミングにおけるテスト手法を解説します。ここで紹介するモジュールはどれも実践的なものばかりです。ぜひ皆さまのプログラミングの際に活用してください。Happy testing!!
テスト系の連載が増えてきた気がします。
| 固定リンク | コメント (0) | トラックバック (0)
JacaScriptが初心者向けなのかどうかは別として、手ごろだったので原因結果グラフからデシジョンテーブルを作成するツールをJavaScriptでためしに作り中。エクセルVBAとかのが使えるんだろうな。
原因結果グラフ→デシジョンテーブル（v0.2）
# Opera9.26で確認中。まだブラウザによっては動作しないかも。。。
以下、TODOとして。
| 固定リンク | コメント (0) | トラックバック (0)
朝の投稿。
==
「超高速、完全自動、しかもフリー」 WebテストツールのGITAK公開
TIBCO Developer Network
※Codezineの画像を引用
見た目はSeleniumに似ているようだが、少し使ってみようかな。
==
#2007/04/06追記。
General Interface Test Automation Kit: User Guide（PDF）
TIBCO General Interface Test Automation Kit is developed using the Selenium test tool. Selenium, an open-source tool by Thoughtworks developers, is an embedded browser script framework that works in Internet Explorer, Mozilla, Firefox, and Safari.
なんだー、コアはSeleniumなのか。
| 固定リンク | コメント (0) | トラックバック (0)
JaSST'07終了。第2日目も午後から参加。午前中のミニパネルも聴きたかったなあ。
==
第1日目のセッションでJameleonについての発表があった。その中でJameleonのデメリットとして「判定ポイント見極めが難しい」というのがあった。これはけっこう落とし穴であって、発表者である加藤さんも注意を促していた。(他の発表の場でもよく指摘してたな)
GUIテストツールを使わずに手動＆目視で確認するときの人間の視覚認識はけっこうすごい。サビタイジングと呼ばれる能力らしく、見た瞬間に状態を把握することができるらしい。例えばお札を数える場合、素人でも一度に2枚あるいは3枚を束にして数えられるし、プロであれば5枚を束にして数えられる。これは一種のサビタイジングに似た能力なのかな、と個人的に思ってます。(間違ってたらご指摘ください)
おそらく、手動＆目視でGUIテストを実施した場合も同じで、画面全体の印象などと一緒に瞬時にテスト実施結果の検証が行われるのだと思います。見逃しや勘違いなどヒューマンエラーについては決してツールにはかなわないけど、そういった包括的な判断はツールでは難しい。そのため、Jameleonなどのツールを利用する場合は複数の判定条件を指定することが重要となってくる。
加藤さんも指摘されていたが、例えば「表示メッセージの大きさ/色/場所」「本来あるべきでないもの」なんかをきちんとツールの判定条件に含めるのだ。
ちなみに、これはGUIテストツールだけじゃなくて僕は単体テストの判定条件にも活用している。関数/メソッドの復帰値だけじゃなく、それ以外の判定条件をなるべく記述する、といった具合に。
# テストツールのセッションを聴いていて、思い出したので記事にしてみました。
| 固定リンク | コメント (0) | トラックバック (0)
いまいち、All-pair法のメリットが自分の頭に入ってこない。ナゼダロウ
==
テストを自動化、効率化するためのテストツールは、当然テストを実施するコストを軽減してくれる。でも、それは単なる作業の効率化であって、品質向上にはさほど影響しない場合がある。(もちろん、浮いた時間で重要箇所のテストを厚くするなどやり方はあるが)
自分がソフトウェアテストに興味を持つきっかけになったのは、まさに「自動化」という手段を求めたことである。当然、手動でテストを実施する時間を短縮することができたが、目に見える品質向上というのはなかなか出てこなかった。なぜ？なぜ？と考えて、僕は「テスト設計」が重要じゃないか、というふうに考えた。どんなにいいツールを持っていても、使い方によっては宝の持ち腐れになる。テストケースに漏れがあれば、そのテストをどんなに厚く行ったって、欠陥は見つからないのだ。
テスト設計が重要なことは、いろんな本に載っているし、誰に聞いたって、そのとおり、自明なこと。だけど、テストツールという手段をまず求めたことで、そういう大事なところに気づけた、ということもいえるのではないだろうか。
教えられることよりも、自分で答えにたどり着くことのほうが、ずっとありがたみがわかる。と思います。
| 固定リンク | コメント (4) | トラックバック (0)
今日は社外の勉強会にはいけませんでした。残念！
==
自動テスト生成によって、既存コードの質を上げる--アジター社CEO語る by ITPro
これまでも、開発者はユニット単位で動作を検証するのが普通だった。しかしそれは、コードが「何をすべきか」ということについての検証しかしないことが多い。つまり、想定外のコードや例外となるケースのテストを記述するのは難しい。（中略）
その通りだ。旧版に搭載していた「アジテーション」という、おかしな振る舞いをするケースを見つける機能を応用して、いろいろな入力データに対する出力結果のフローを見て、どのように振る舞うかを解析する。その結果からテスト・ケースとすべき状態を抜き出して、テスト・コードを自動生成する。
自動的にバグのありそうな条件を見つけ出すって、どうやってるんだろう？truss/strace/ltraceをして出現したシステムコールについて自動分析して怪しい条件を作成してるのかな？
--ほかのプログラミング言語へ対応することは考えているのか。いや。全く考えていない。CやC++、Visual Basicはミッション・クリティカルな言語ではない。C＃は可能性があるが、製品で対応しなければならないほどの市場ではない。
C言語も作ってください～～メールサーバとかけっこうミッション・クリティカルなものもありますよん。
| 固定リンク | コメント (0) | トラックバック (0)
前回よりも直交表の割り付け方を工夫したので、サイズも小さいし、多因子間網羅率も高いはず。。。
次の課題は、2因子間網羅率の計算と、3因子間網羅率の計算、かな。とりあえず今日はここまで。
| 固定リンク | コメント (2) | トラックバック (0)
ひとまず、サンプル2号を作成。でも、やってみると直交が崩れてる。。。ショック。。。
今日はもうおしまい。
==
自分で試してみた。因子数は14個、いくつかは多水準化が必要な場合でやってみたらサイズが128に膨れてしまった。この大きさは妥当なのだろうか。それに、テストケースは出来上がってるけど、本当に網羅してるのかってのが一目じゃわかりにくいな。何か検算機能をつけてみるかな。
| 固定リンク | コメント (2) | トラックバック (0)
組み合わせテストケース作成ツール（サンプル）でアップしたサンプルページ、Firefoxで試したら全然動かなかったみたい。。。なので、少し修正してみました。
あぁぁぁ、恥ずかしい・・・
| 固定リンク | コメント (0) | トラックバック (0)
HAYST法 | JSTQB | pairwise・All-pair法 | TestLink | おすすめサイト | ウェブログ・ココログ関連 | グレーボックステスト | コーディング規約 | セミナー | ソフトウェアテスト | ソフトウェア品質 | タグチメソッド | チームビルド | テスト設計 | テスト関連ツール | テスト駆動型開発 | デシジョンテーブル | データフローテスト | ニュース | マインドマップ | レビュー・インスペクション | 例題 | 分析 | 勉強会 | 単体テスト | 原因結果グラフ | 品質工学 | 学問・資格 | 書籍・雑誌 | 状態遷移テスト | 直交表 | 結合テスト | 趣味 | 雑記
最近のコメント