アカウント名:
パスワード:
境界値ならテストして当然出だし、境界値でない所でバグなんてよほど変な作りでないと起き得ないし。問題が起きても複数モジュール全部巻き込んで落ちるとか、航空機用のソフト開発でそんな事態が起きるって一体全体どうなっている……
もしボールを空中に放り投げたなら、その軌跡を確信を持って予測できる。というのも、我々は普通の状況において、ある物理法則がそこに適用されることを知っているからである。もしそのボールをもうちょっと強く放り投げただけで、ボールが飛んでいく途中で急に静止し、それからまっすぐに空高く飛んでいったりしたら、とても驚くだろう。ボールの動きをシミュレートする完全にデバッグしきれてないソフトウェアにおいては、ちょうどこの種の振舞いがいとも容易に起きてしまうのである。
大規模なアプリケーションにおいては、数百、いや、数千の変数とともに複数の制御スレッドが存在するかもしれない。システム内部のこれら変数とその現在値と各プロセスの現在アドレスとその呼び出しスタックの完全な集合が、アプリケーションの現在の状態を決定する。ソフトウェアはデジタル・コンピュータ上で実行されるため、システムは拡散的な複数の状態を持つ。これに対して、放り投げられたボールの動きのようなアナログ・システムは連続的なシステムである。拡散的なシステムはその性質上、取り得ることが可能な有限の複数状態を持っている。大規模システムにおいては、組み合わせの爆発によって、この数がとても大きくなってしまう。
我々はシステムをモジュール化して設計しようとする。これによってシステムのある部分の振舞いに対してできるだけ影響を与えないようにするためである。しかしながら、ここには拡散的な状態間の相転移は連続的な機能でモデル化できないという問題が残っている。外部からソフトウェア・システムに与えられるイベントはそのシステムを新しい状態に遷移させる可能性を持っているし、さらに悪いことには、状態から状態のマッピングは必ずしも決定的ではないのである。最悪の状況においては、設計者がイベント間のある相互関係を考慮し忘れていたことで、ある1つの外部イベントがシステムの状態を混乱させてしまうかもしれない。
例えば飛行翼とその客室の環境が1つのコンピュータで管理されている旅客機を想像してみなさい。もしシート38Jの乗客が頭上のライトを点灯した途端、飛行機が急降下したら、非常に具合の悪いことになるであろう。連続的システムにおいては、この種の振舞いは起こりにくい。しなしながら、拡散的システムにおいては、全ての外部イベントはシステムの内部状態のどの部分にも影響を与える可能性が存在するのである。
もっとも、システムを厳密にテストするのは、このようなことが起こらないようにするためなのだが、最も厳密なシステムを除けば、どのシステムに対しても徹底的なテストなど不可能である。我々は、大規模な拡散的システムの振舞いを完全にモデル化するツールも知的な能力も持ち合わせていないのだから、我々はシステムの正しさに関してある程度の信頼度を得ることで満足しなくてはならない。
翻訳ミスと思われる × 拡散的 〇 離散的
磁方位270度とか有限な滑走路情報全部ぶち込んでみるのはそこまで複雑なテストかな。
実機テストをせずに手を抜いたみたいだね。世界の全ての空港でテスト飛行しておけば、バグを潰せたと思われる。
技適を与えた当局もメンツが潰れるし、申請したらテストの許可も出るでしょ。同社は、去年墜落事故起こした機種もあったし相当人手が足りないのか、今後も不安は残る。
JRの改札機システム作ってる会社は、開発者が駅を回ってすべてのパターンのテストしてる、みたいなことは無いよ
条件が揃わないものはテストと呼ばないだけの話では
山のような乗降パターンのテストはしてた筈だがな。
CJK結合文字に同じ書体が入っている文字が選ばれた時のリスクは事前にほぼ誰も指摘してなかったぞ俺は見たこと無い
鏡をどうぞ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
「毎々お世話になっております。仕様書を頂きたく。」「拝承」 -- ある会社の日常
にわかには信じがたい (スコア:0)
境界値ならテストして当然出だし、
境界値でない所でバグなんてよほど変な作りでないと起き得ないし。
問題が起きても複数モジュール全部巻き込んで落ちるとか、
航空機用のソフト開発でそんな事態が起きるって一体全体どうなっている……
IBM ラショナル部門 某技術者による、素人さん向け ソフトウェアの複雑度の説明 (スコア:3, 興味深い)
もしボールを空中に放り投げたなら、その軌跡を確信を持って予測できる。というのも、我々は普通の状況において、ある物理法則がそこに適用されることを知っているからである。もしそのボールをもうちょっと強く放り投げただけで、ボールが飛んでいく途中で急に静止し、それからまっすぐに空高く飛んでいったりしたら、とても驚くだろう。ボールの動きをシミュレートする完全にデバッグしきれてないソフトウェアにおいては、ちょうどこの種の振舞いがいとも容易に起きてしまうのである。
大規模なアプリケーションにおいては、数百、いや、数千の変数とともに複数の制御スレッドが存在するかもしれない。システム内部のこれら変数とその現在値と各プロセスの現在アドレスとその呼び出しスタックの完全な集合が、アプリケーションの現在の状態を決定する。ソフトウェアはデジタル・コンピュータ上で実行されるため、システムは拡散的な複数の状態を持つ。これに対して、放り投げられたボールの動きのようなアナログ・システムは連続的なシステムである。拡散的なシステムはその性質上、取り得ることが可能な有限の複数状態を持っている。大規模システムにおいては、組み合わせの爆発によって、この数がとても大きくなってしまう。
我々はシステムをモジュール化して設計しようとする。これによってシステムのある部分の振舞いに対してできるだけ影響を与えないようにするためである。しかしながら、ここには拡散的な状態間の相転移は連続的な機能でモデル化できないという問題が残っている。外部からソフトウェア・システムに与えられるイベントはそのシステムを新しい状態に遷移させる可能性を持っているし、さらに悪いことには、状態から状態のマッピングは必ずしも決定的ではないのである。最悪の状況においては、設計者がイベント間のある相互関係を考慮し忘れていたことで、ある1つの外部イベントがシステムの状態を混乱させてしまうかもしれない。
例えば飛行翼とその客室の環境が1つのコンピュータで管理されている旅客機を想像してみなさい。もしシート38Jの乗客が頭上のライトを点灯した途端、飛行機が急降下したら、非常に具合の悪いことになるであろう。連続的システムにおいては、この種の振舞いは起こりにくい。しなしながら、拡散的システムにおいては、全ての外部イベントはシステムの内部状態のどの部分にも影響を与える可能性が存在するのである。
もっとも、システムを厳密にテストするのは、このようなことが起こらないようにするためなのだが、最も厳密なシステムを除けば、どのシステムに対しても徹底的なテストなど不可能である。我々は、大規模な拡散的システムの振舞いを完全にモデル化するツールも知的な能力も持ち合わせていないのだから、我々はシステムの正しさに関してある程度の信頼度を得ることで満足しなくてはならない。
Re:IBM ラショナル部門 某技術者による、素人さん向け ソフトウェアの複雑度の説明 (スコア:1)
翻訳ミスと思われる
× 拡散的
〇 離散的
Re: (スコア:0)
磁方位270度とか有限な滑走路情報全部ぶち込んでみるのはそこまで複雑なテストかな。
Re:IBM ラショナル部門 某技術者による、素人さん向け ソフトウェアの複雑度の説明 (スコア:1)
実機テストをせずに手を抜いたみたいだね。
世界の全ての空港でテスト飛行しておけば、バグを潰せたと思われる。
技適を与えた当局もメンツが潰れるし、申請したらテストの許可も出るでしょ。
同社は、去年墜落事故起こした機種もあったし相当人手が足りないのか、今後も不安は残る。
Re: (スコア:0)
JRの改札機システム作ってる会社は、開発者が駅を回ってすべてのパターンのテストしてる、みたいなことは無いよ
Re: (スコア:0)
Re: (スコア:0)
条件が揃わないものはテストと呼ばないだけの話では
Re: (スコア:0)
山のような乗降パターンのテストはしてた筈だがな。
Re: (スコア:0)
って吹いてたでしょ
たかだか常用漢字2文字の有限の組み合わせにすぎないのに
Re: (スコア:0)
CJK結合文字に同じ書体が入っている文字が選ばれた時のリスクは事前にほぼ誰も指摘してなかったぞ
俺は見たこと無い
Re: (スコア:0)
鏡をどうぞ。