こんばんは、うっちゃんＸです。
今、自分はソフトウェアテストの仕事をしてるのですが、結構この仕事の経験ってあとあと役に立つのだろうなー。
なんて実感してます。
特に、プログラマやったときに役に立つのかなと・・・。
実際プライベートで作ってる、自分用の領収書管理ソフト（VB.NET2005 Express Edition）で、バグを見つけたり、仕様のおかしいところや問題点を見つけるのがうまくなりました。
ええ、その分自分が作ってるものに関しては、モチベーション下がりました・・・。
我ながら、仕様バグ多すぎ・・・。
自分で作ってて、作ってる途中で弱点がわかったり。
たとえば、「このボタン押したら落ちるよねー」とかですね。
（分かってるんだったら直せよ！）
いや、時間ないし。明日仕事だし。Ｃの勉強もしなきゃいけないし。
ところで、自分がテストする場合。異常系のテスト項目がすっごく好きなんです。
で、仕事でもすごく重い異常系の項目があって、自分で項目考えたんですけど。
ローカルから画像を読み込むときに、その画像ファイルが壊れていたら、というシチュエーションで、空のＥｘｃｅｌファイルを作り、名前を「test.jpg」に変更して読み込ませるのですが。
自分が作ってるソフトで試したら同じ症状が出て落ちた。
で、これをですね。
try～catch文で例外処理をやってみると、
これで、落ちずに復帰します。
画像はもちろん読み込めなかったので、表示されませんが・・・。
表示されなくても他の処理も正常動作してるので、一件落着？
こんな風に自分が作るソフトの品質も上げることができます。
ちゃんとした画像ファイルを読み込ませると、ちゃんと表示されます。
で、これ書いてる途中に仕様バグ見つかったりね？
一応、ファイルを開くダイアログには、ＪＰＥＧファイルだけを表示するようにしてるんですけど、今回のようなシチュエーションもあるので、読めないファイルを登録できて、表示するときにエラーを出すのはいかがなものかと・・・。
領収書を登録するときに、先に領収書画像が読めるかどうか確かめて、読めなかったら登録させない。そんな感じにしないといけなかったですね。
ね？ こんな風にプログラマとしての自分も少しずつスキルアップしていけるし、仕様を考える立場になった場合にも。役に立ちます。
品質管理についても、意識が高まると思います。
なんていうか・・・。視野が広がったとかですね。
いま、よい経験をしていると思います。
いま興味本位で「Ｃ＃ 例外処理」で検索して見つけたのが「blog C#」でした。
Ｃ＃にも例外処理があるんだなー（ほとんどあるだろうＪＡＶＡとかもあるし）なんて思ってたら、悪い例が載ってて。
「Exception でまとめて catch すること」はダメだそうで。
慌てて自分のプロジェクトを見てみると・・・。
「Catch ex As Exception」・・・（汗）。
あああー！！ やっちゃってるよー！！ バカー！！
そのブログでは理由として
ExecutionEngineException
StackOverflowException
OutOfMemoryException
の三つは「メモリの中がズタズタにされている」かもしれないから、素直にアプリを終了させる。ことが鉄則らしい。
じゃ、不正なファイルを読み込ませて「メモリが足りない」ってのは「OutOfMemoryException」かなぁ？
もしそうだったら、
「表示されなくても他の処理も正常動作してるので、一件落着？」
って書いたあれ、間違いじゃん・・・。
祝日にこの３つの例外でキャッチできるか試してみて、キャッチ出来たら素直にアプリケーションを落とそう・・・。
で、Ｔｒｙ～Ｃａｔｃｈ文が点在するのもダメらしい。
ひとつにまとめろと書いてあった。
「Application.ThreadException イベントでハンドリングして例外に対する処理を書く」らしいのですが。
やっべ！ 自分例外が出そうなところだけ「Ｔｒｙ～Ｃａｔｃｈ」置きまくってたから、やり方わかんないよー。
うーん。火曜日の祝日に試してみるかな？
っていうか、やり方わかってもかなりの修正が入りそう。
まだまだ、スキルアップが必要な私でした。
っていうか、ソース眺めててまたバグを見つけたかもしれない・・・・。
ね？テストチームを経験すると、かなり勉強になりますよ。
もう、今日はお風呂入って寝るよ。
今、自分はソフトウェアテストの仕事をしてるのですが、結構この仕事の経験ってあとあと役に立つのだろうなー。
なんて実感してます。
特に、プログラマやったときに役に立つのかなと・・・。
実際プライベートで作ってる、自分用の領収書管理ソフト（VB.NET2005 Express Edition）で、バグを見つけたり、仕様のおかしいところや問題点を見つけるのがうまくなりました。
ええ、その分自分が作ってるものに関しては、モチベーション下がりました・・・。
我ながら、仕様バグ多すぎ・・・。
自分で作ってて、作ってる途中で弱点がわかったり。
たとえば、「このボタン押したら落ちるよねー」とかですね。
（分かってるんだったら直せよ！）
いや、時間ないし。明日仕事だし。Ｃの勉強もしなきゃいけないし。
ところで、自分がテストする場合。異常系のテスト項目がすっごく好きなんです。
で、仕事でもすごく重い異常系の項目があって、自分で項目考えたんですけど。
ローカルから画像を読み込むときに、その画像ファイルが壊れていたら、というシチュエーションで、空のＥｘｃｅｌファイルを作り、名前を「test.jpg」に変更して読み込ませるのですが。
自分が作ってるソフトで試したら同じ症状が出て落ちた。
で、これをですね。
try～catch文で例外処理をやってみると、
これで、落ちずに復帰します。
画像はもちろん読み込めなかったので、表示されませんが・・・。
表示されなくても他の処理も正常動作してるので、一件落着？
こんな風に自分が作るソフトの品質も上げることができます。
ちゃんとした画像ファイルを読み込ませると、ちゃんと表示されます。
で、これ書いてる途中に仕様バグ見つかったりね？
一応、ファイルを開くダイアログには、ＪＰＥＧファイルだけを表示するようにしてるんですけど、今回のようなシチュエーションもあるので、読めないファイルを登録できて、表示するときにエラーを出すのはいかがなものかと・・・。
領収書を登録するときに、先に領収書画像が読めるかどうか確かめて、読めなかったら登録させない。そんな感じにしないといけなかったですね。
ね？ こんな風にプログラマとしての自分も少しずつスキルアップしていけるし、仕様を考える立場になった場合にも。役に立ちます。
品質管理についても、意識が高まると思います。
なんていうか・・・。視野が広がったとかですね。
いま、よい経験をしていると思います。
いま興味本位で「Ｃ＃ 例外処理」で検索して見つけたのが「blog C#」でした。
Ｃ＃にも例外処理があるんだなー（ほとんどあるだろうＪＡＶＡとかもあるし）なんて思ってたら、悪い例が載ってて。
「Exception でまとめて catch すること」はダメだそうで。
慌てて自分のプロジェクトを見てみると・・・。
「Catch ex As Exception」・・・（汗）。
あああー！！ やっちゃってるよー！！ バカー！！
そのブログでは理由として
ExecutionEngineException
StackOverflowException
OutOfMemoryException
の三つは「メモリの中がズタズタにされている」かもしれないから、素直にアプリを終了させる。ことが鉄則らしい。
じゃ、不正なファイルを読み込ませて「メモリが足りない」ってのは「OutOfMemoryException」かなぁ？
もしそうだったら、
「表示されなくても他の処理も正常動作してるので、一件落着？」
って書いたあれ、間違いじゃん・・・。
祝日にこの３つの例外でキャッチできるか試してみて、キャッチ出来たら素直にアプリケーションを落とそう・・・。
で、Ｔｒｙ～Ｃａｔｃｈ文が点在するのもダメらしい。
ひとつにまとめろと書いてあった。
「Application.ThreadException イベントでハンドリングして例外に対する処理を書く」らしいのですが。
やっべ！ 自分例外が出そうなところだけ「Ｔｒｙ～Ｃａｔｃｈ」置きまくってたから、やり方わかんないよー。
うーん。火曜日の祝日に試してみるかな？
っていうか、やり方わかってもかなりの修正が入りそう。
まだまだ、スキルアップが必要な私でした。
っていうか、ソース眺めててまたバグを見つけたかもしれない・・・・。
ね？テストチームを経験すると、かなり勉強になりますよ。
もう、今日はお風呂入って寝るよ。
