虚数空間とか懐かしいです。
多元宇宙論ブームのせいで、実は虚数空間も実在しているんじゃないかと妄想しているごみためまんです。
# 実在してたら虚じゃないじゃん(笑
1つの記事へのセルフツッコミをネタにするテクニック。
言い訳をコメントにかいたらツイッキーですが、別記事にしたらネタがニバーイニバーイ(by高見山)
故・田口玄一博士を偲んで:モンキーにも言い分はある ごみため(ー日ー膳!)
ソフトウェアテストを効率化する際の根本問題は、
状態空間が広すぎる
ことだと思います。しかも疎です。
メモリだけを考えても、使うかどうか分からないメモリ空間が何GBもあります。そしてそのうちたった1バイトが0か1かの違いだけでシステムがクラッシュするのです。
そのアドレスすらわからないメモリの状態をテストや設計に含めないなら、ロバストなシステムは名ばかりになりますよね。
よくあるのは、上記の状態空間が設計可能という幻想です。
その次が、アクセスするメモリの範囲やアドレスは静的・動的解析であらかじめ知ることができるという思い込みです。
バグゼロの”純粋プログラム”なら、それは可能かもしれませんが、実際のプログラムにはかならず潜在バグを含んでいるので、すべてを事前に知ることができないのです。
逆にいえば、
そのプログラムがアクセスするすべてのメモリの範囲をあらかじめしることができたら、バグゼロも不可能ではない
ということになるのかもしれません。
たとえばちょっとしたインデクス計算のバグがあるだけで、アクセスするメモリのアドレスは狂います。
狂ったアドレスにアクセスした結果、別のインデクス計算に影響を及ぼしたら、それはもう設計可能性云々を超えた話です。
インデクスが狂うということは、状態空間の虚像のようなものです。
プログラムで定義したつもりの状態空間ではなく、実際のプログラムは別の状態空間で動作を続けます。その際、元の状態空間に基づいたテストはほとんど意味をなしませんね。
手続き型言語のプログラムの場合は、インデクスが狂う前と後で状態空間が変化すると考えても差し支えないかもしれません。しかし両者を写像で表現できたとして、また疎な変換行列が沸いてくるだけで、問題がどんどん厄介になるだけでしょう。
ただ、そんな親亀こけたら小亀もこける式の実装になっていなければ、多少は設計可能性が見えてきそうです。それがたぶん、先日書いた以下の一部といえるでしょう。
まずはバグを設計しましょう。アナログ回路のノイズのように。
・・・
バグも同じです。仕様を満たさなくなるバグは出ないように。仕様に関係のないバグは潜在してもかまわないのです。
# 何を当たり前のことをえらそうに書いているのでしょうか(笑
ここまで考えれば、
じゃぁ、掌握可能な小さい状態空間でおさまる
小さい部品単位のプログラムをバグゼロで作成して、
それらを組み合わせて大きなプログラムを作れば、
みんなハッピーじゃね?
と言い出す馬鹿が多数沸いてくるでしょう。それはそれこれはこれです。
単体テストをしっかりやれば
結合テストは手抜きでよい
システム全体のテストなんて、最終リハーサルだけ
なとという世迷言を吐く管理ボケマネージャは無視しないと!
仮にバグゼロの小さいプログラム(関数だったりクラスだったりするでしょう)があったとして、それらを組み合わせた大きいプログラムがバグゼロにならないことは、みなさんご同意されますね?
まさかとは思いますが、
バグゼロつまりユニットテストが完璧な
クラスライブラリを使えば、
それは品質の高い部品を使うということだから、
組み合わせ試験でも、相対的にバグは出にくいはず
などという頭のおかしい考えをお持ちなら、たぶん職探しをしたほうが良いと思います。
そこに線形性はないわけです。
そういやシステムの信頼性の定義かなにかでそんな話があったな、と思い出したところで今日は終了です。
|
そういや大鷲トリコはどうなった?