Linux上でWindowsソフトを動作させるDavidの独占販売契約をターボがとったみたい

世界初！ターボリナックス、リナックス上でWindowsソフトを動作させる
「David」の独占販売契約を締結
らしい。元ネタは、ここ

　で、しくみについてなんですけど

Davidは、動作させるWindowsアプリケーション共通モジュール(Davidエンジン)と、アプリケーションごとに異なるプラグイン型モジュール(Davidイネーブラー)で構成され、Turbolinux上でWindowsアプリケーションを動作させることができます。


　つーことは、たぶん、共通モジュールで、システムコールの呼び出しをおこない、プラグインモジュールのほうで、EXEファイルから、システムコール変換をするのかなあ？？

　問題は、このてのやつって、ちゃんと動くかどうか、どこまでテストしてくれるかどうかだよね。。
　文書作成系は、すぐに、おちてもらっちゃ、困るわけだし。。。

　ただ。。。

Linux上でWindowsアプリケーションを違和感無く共存させる同機能の実現により、ユーザーのリナックス利用が格段に容易になり、今後ビジネスとコンシューマの両市場においてリナックスの採用が加速されると期待しています。


　あのー、Linuxべんちゃーのお偉いさんと話すと、そう思ってる人、多い印象受けるんだけど、WindowsのソフトがLinuxで動いても、Linuxを使わないのよ。。

　なぜならね。。。

　Windowsソフトは、パソコン買うとついてくる
　Linuxは、フリーとか言いながら、お金出さないとかえない。

　わざわざ、お金だして、Linuxかって、今と同じWindowsアプリケーション動かして何が楽しいのよ？
　Linuxじゃないと、できないことがないと、わざわざ、お金出して買わないだけど。。。

　でも、Linuxのお偉いさんたちは、ユーザー層を広げるために（そうすると、多くさばけて儲かると思っている）、Winodows層の人たち、とくに初心者を取り込んで。。そのためにインストールはやさしく、Windowsソフトはうごいて。。って、かんがえるのよねー。

　その考え方は、売り上げはあがっても、利益は上がんないと思うんだけどね。

　利用者を増やすと、サポート要員も増やさないといけない。パッケージの売れる量より、サポート要員の費用のほうが、普通高い（すべてノンサポートにしても、ある程度売れ出すと、会社に電話がかかってくるのが実情のはず。なので、サポート版とノンサポートを分けたほうがＧｏｏｄ）

　そこで、ＯＳより、サーバーサイドのアプリのものをとりいれ、一件当たりの単価をあげたほうがＧｏｏｄ。

　そういう意味では、前、Turboを持っていて、ライブドアに売った、ＳＲＡの戦略は正しいと思う。
　ＳＲＡは、PostgreSQLのほうにすすんだけど、たしかにPostgreSQLのほうが、ＤＢコンサルなど、利益率の高いビジネスが組めるから。。。

　って、話ぜんぜんそれてきたので、このへんで。

テスト項目設定率で品質をはかる危険性

　テストの品質の指標のひとつとして、テスト項目設定率として、１０００ステップ（１Ｋｓ）あたり何件のテスト項目を設定したかどうかで確認する方法があります。
　何年前かのたしか、情報処理試験、プロジェクトマネージャーの午後１にも、それを基にした、問題があったと思います（この設定項目数を満たしていなかった場合、どうするか、その場合の費用負担はどうなるかなど）。
　なので、これと、バグ出現件数（これも１Ｋｓあたりの件数で表す）をあわせて指標にすることがあると思います。

　でも、この指標、危険だったりします。

---

　ループや、場合わけの場合に問題が起こります。
　たとえば、１００個の場合があって、それらが、１０個あるメソッドのいずれか１個を呼び出している場合、こんなプログラムになります
switch(sts)
{
　　　　case　1:
　　　　case　3:
　　　　case　16:
　　　　　　　　return M01(args);

　　　　case　2:
　　　　case　4:
　　　　case　19:
　　　　　　　　return M02(args);

　　　　　　　　:
　　　　　　（省略）
　　　　case　35:
　　　　　　　　return M10(args);　　//　１０個目のモジュール
　　　　}

このように書いた場合、１００通りしらべる方法と、１００個の値のうち、同じモジュールを呼び出すものは同値と考え、１０個分調べる考え方があります。
　でも、ここで、一番間違えやすいのは、case文の文字です。
　今回はいいけど、case '19':とcase 19 （数字と文字）の間違い(''が抜けている）とかとか。。こぴぺしたとき、最後の行が抜けたとか（最後の行に改行を打たず、一番下まで言ったと思ってこぴぺしたら、最後の行だけつかめてなくて、コピーできていないとか）。
　つーことを考えると、１００とおり、やるべきです。

　でも、１００とおりやらなくても、上記の場合だと、１０通りしらべるだけで、テスト項目設定率は結構高くなり、品質上、問題なくなります。逆に、ここで１００通りやると、やりすぎみたいな数字が出ます。
　この手で、特に困るのは、ループしている場合です。順番で、Ａメソッド、Ｂメソッド、Ｃメソッドとやるのと、Ｂメソッド、Ａメソッド、Ｃメソッドとやるケースがあるとき、１つだけチェックしただけで、テスト項目設定率的には、十分ってことがあります。

---

　実際には、仮にテスト項目設定率的には、十分なので、単体テストでやらなくても、結合や、総合テストで、たいてい、全ケーステストされるので、大丈夫なことは多いんですけど、結合、総合で、テストを縮退してしまった場合や、仕様書を書く人が、そういうことに気づかなかった場合、テストされずじまいになってしまい、お客さんのところで、急に問題が起こり、どういうテストしてるんじゃいということになったりするかもしれません（え、そういう話があるのかもしれません、ないかもしれません。ご想像にお任せします）。

---

　逆に、帳票出力の場合、こまります。値を設定するのに、いろいろプログラムを書くのですが、結局１本道で、分岐もなく、帳票を出せばわかるというときがあります。
　だからといって、テスト項目設定率でいくと、このテストを１個しかしないと、２００ステップにテスト１個なんていうケースが出てきてしまい、とうてい許されない話になってきてしまったりします。
　なので、この場合は、ログをいれて（いれなくて、帳票の目視でもＯＫだと思うけど）、各項目の値を確認するので、１項目にしたりします。

---

　基本的に、テスト項目設定率は、上記のように、ループの問題を解決できないという点で、C0（命令網羅）の指標に近いのですが、じゃーＣ０かというと、命令網羅としては、帳票なんか、一本道だから、１つのテストでいいはずなのに、いくつもテストしなきゃならなかったりします。

　ということで、この指標は絶対ではないんですけど、情報処理試験にもでるように、かなり使われています。

---

　で、この問題を、どうしているかというと、自主的テストというのがあって、ＰＭの判断で、テスト項目設定率がすでに規定を満たしているのにもかかわらず、テストをしてもいい（する）場合があります（情報処理試験のさっきの問題は、設定率が規定に満たさないとき、理由を書くものだったが、その逆のパターン）。

　で、ふつうは、どこかのテストで、全数をテストする形になっていると思います。
　じゃないと、客先で問題出るかもしれないので。。。

全数をテストする形になっていると思います。

全数をテストする形になっていると思います。

そうですよね。はい。やっぱ、全数テストしないといけないですよね。

たった、５００通りくらいですもんね（＾＾；）

さ、ばかいってないでやろうっと。