自己紹介
- 村上です
- オズビジョン6年。
- 過去にはゲーム会社にいたり、受託開発したり。
- 猫好き
- 本は古典が好き
- 仕事はほとんどPHP。
- テストコードはPHPUnit、Seleniumをちょろちょろ触る。
テスト関連で読んだ本
- はじめて学ぶソフトウェアのテスト技法
- ソフトウェアテスト293の鉄則
- テストから見えてくる グーグルのソフトウェア開発
- マインドマップから始めるソフトウェアテスト
ソフトウェア・テストの技法 第２版
- 著者:グレンフォード・J・マイヤーズ
- 1979年初版
- 1980年日本語訳
- 2004年2版
- 古典だけど25年ぶりにWebプログラミングとかエクストリームプログラミングの内容を追加して出版された。
- 2版も10年以上前だけど。
１章〜３章まで読んだ
- １章：自己診断テスト
- 3つの数字を入力してどんな３角形になるかを出力するシステムのテストを考える。
- ２章：プログラム・テストの心理学と経済学
- テストはサディスティックだ！
- 全部テストするのは無理だ！
- ３章：プログラムの検査、ウォークスルー、検討
- 要はレビュー。
１章：自己診断テスト
このプログラムのテストケースとテストデータを考えてみろ。
- 入力ダイアログから３つの整数を読む。
- ３つの値は、三角形の3辺の長さを表す。
- 出力は、三角形が「不等辺三角形」「二等辺三角形」「正三角形」のどれかを示すメッセージ。
やってみたところ
- パラメタの値が3つじゃないとかやな！
- 入力が数字じゃないとかやな！
- 0とかマイナス値とかやな！
- あとは正常系のパターンやな！
足りなかった事
- 少数を考えてなかった！
- 数字３つなら全部三角形が成り立つと思ってた！
- １、２、３だと線になってしまう。
- １、２、５だと線がつながらない。
- 各パターンの順番を変えたパターンがなかった。
- １、２、３の他に２、１、３とか。
１章まとめ
もし、あなたが良い点を取ったならおめでとう。
さもなければ、私が助けよう
だそうです。助けてもらおうと思います。
２章：プログラム・テストの心理学と経済学
全てのパターンをテストする事は無理ですよという前提から始まるこの章。
テストとは！
↓違う
・エラーが無い事を示す過程
・意図された通りに動く事を示すこと
・思い通り動く確信を作る
↓正解
・エラーを見つけるつもりでプログラムを実行すること。
心理的な話
言葉遊びのようでもあるが
-
「エラーが無いようにする」
- エラーが出ないようなテストデータを考える心理になる。
-
「エラーの存在を証明する」
- エラーを見つける確率の高いデータを考える心理になる。
つまり
- テストとはサディスティックな行為だ！
- 破壊的だ！
- エラーの発見は「失敗したテスト」ではなく「成功したテスト」だ！
例えるなら
体調が悪くて医者に行って「異常はありません」と言われたらどう思うか？
プログラムを体調の悪い患者だと思え！
全てのテストが無理な話
- ブラックボックステスト
- ホワイトボックステスト
- 他いろいろ原則
ブラックボックステスト
- 入力と出力を気にしてテストする。
- 入力可能な全ての値を試す。
↓ - 無理
↓ - 制限されたパターンで発見できるエラーを最大化する。という事になる。
ホワイボトックステスト
- プログラムの全ての経路を通るようなテストをすれば完全なテストになるか。
↓ - 繰り返し処理があるから無理
- プログラムが仕様通りじゃないかもしれないから無理
↓
略
その他原則
- 結果もしっかり定義しておく。
- もっともらしい結果を都合よく解釈するのが人間というもの。
- 他人にテストしてもらう
- エラーが見つかった所には更にエラーがある
など、１０個ぐらい書いてあります。
３章：プログラムの検査、ウォークスルー、検討
要するにレビューの事だった。
昔読んだ本と同じような事が書いてあった。
「ピアレビュー」
https://www.amazon.co.jp/ピアレビュー-Karl-Wiegers/dp/489100388X
エラーの早期発見
- 発見が早いと修正のコストが安い
- レビューでエラーを見つけると修正箇所も同時に見つかる
- エラーがまとめて見つかる
経済的！
レビューのやりかた
- 書いた人以外が読む。
- エラーを見つける事に集中する。
- 修正方法については後で話す。
- 人ではなくプログラムに質問する。
- レビュー結果を人事評価などに使わ無い。
- エラーのチェックリストを使う。
など
感想
Web上でのレビューが流行ってるからこういう事するのが少なくなりました。
そんなことないですか。
仲間内の評価
お互いのコードを評価して品質を高めていこうという取り組みについて書いてあった。
テストとは直接関係ない。
- メンバーから自分にとって最高なコードと最低なコードと思うものを集める。
- 集まったメンバーに無作為にコードを配ってチェックしてもらう。
評価のしかた
YES、NOをつけてもらう。
- 理解しやすかったか
- 設計が明確で適切か
- 変更しやすいか
- 自分が書いたとしたら誇りに思えるか
プログラマの自己評価に使ってみよう。
次回
- ４章はテストケースの設計の話とか。