境界値でない所でバグなんてよほど変な作りでないと起き得ないし。(#3743918)もしボールを空中に放り投げたなら、その軌跡を確信を持って予測できる。いうのも、我々は普通の状況において、ある物理法則がそこに適用されることを知っているからである。そのボールをもうちょっと強く放り投げただけで、ボールが飛んでいく途中で急に静止し、それからまっすぐに空高く飛んでいったりしたら、とても驚くだろう。ボールの動きをシミュレートする完全にデバッグしきれてないソフトウェアにおいては、ちょうどこの種の振舞いがいとも容易に起きてしまうのである。大規模なアプリケーションにおいては、数百、いや、数千の変数とともに複数の制御スレッドが存在するかもしれない。システム内部のこれら変数とその現在値と各プロセスの現在アドレスとその呼び出しスタックの完全な集合が、アプリケーションの現在の状態を決定する。ソフトウェアはデジタル・コンピュータ上で実行されるため、システムは拡散的な複数の状態を持つ。これに対して、放り投げられたボールの動きのようなアナログ・システムは連続的なシステムである。拡散的なシステムはその性質上、取り得ることが可能な有限の複数状態を持っている。大規模システムにおいては、組み合わせの爆発によって、この数がとても大きくなってしまう。我々はシステムをモジュール化して設計しようとする。これによってシステムのある部分の振舞いに対してできるだけ影響を与えないようにするためである。ここには拡散的な状態間の相転移は連続的な機能でモデル化できないという問題が残っている。外部からソフトウェア・システムに与えられるイベントはそのシステムを新しい状態に遷移させる可能性を持っているし、さらに悪いことには、状態から状態のマッピングは必ずしも決定的ではないのである。最悪の状況においては、設計者がイベント間のある相互関係を考慮し忘れていたことで、ある1つの外部イベントがシステムの状態を混乱させてしまうかもしれない。飛行翼とその客室の環境が1つのコンピュータで管理されている旅客機を想像してみなさい。シート38Jの乗客が頭上のライトを点灯した途端、飛行機が急降下したら、非常に具合の悪いことになるであろう。連続的システムにおいては、この種の振舞いは起こりにくい。しなしながら、拡散的システムにおいては、全ての外部イベントはシステムの内部状態のどの部分にも影響を与える可能性が存在するのである。システムを厳密にテストするのは、このようなことが起こらないようにするためなのだが、最も厳密なシステムを除けば、どのシステムに対しても徹底的なテストなど不可能である。我々は、大規模な拡散的システムの振舞いを完全にモデル化するツールも知的な能力も持ち合わせていないのだから、我々はシステムの正しさに関してある程度の信頼度を得ることで満足しなくてはならない。Coward磁方位270度とか有限な滑走路情報全部ぶち込んでみるのはそこまで複雑なテストかな。(#3744033)実機テストをせずに手を抜いたみたいだね。世界の全ての空港でテスト飛行しておけば、バグを潰せたと思われる。技適を与えた当局もメンツが潰れるし、申請したらテストの許可も出るでしょ。同社は、去年墜落事故起こした機種もあったし相当人手が足りないのか、今後も不安は残る。Cowardリスクの受容というものかもね。それで電車の衝突は無いからね。Coward山のような乗降パターンのテストはしてた筈だがな。Coward鏡をどうぞ。現在のしきい値以下です。(#3743887)>境界値ならテストして当然出だし、>境界値でない所でバグなんてよほど変な作りでないと起き得ないし。ここ数十年にわたるソフトウェアやハードウェアの不具合によるシステム異常は「当然だし」「起きえないし」という観点てテストしている結果によるものです。[srad.jp]で起きてる現象っぽいので、よりにもよって航空機の開発でそんなところすらテストできない状況が発生するってのが驚きなんだよ。Registerの記事読んでみたら、248日以内に再起動しないと整数オーバーフロー発生するバグとか、エアバスだとそれが149時間のやつがあったとか書いてあるぞ。Cowardそもそも一度電源が投入されたら24時間以内に必ず何らかの方法(墜落含む)でシャットダウンされるので、そこまでの能力は必要ないのです...。(#3744200)旅客機は着陸後毎回電源が落とされています。(ただし、コネクタを物理的に外したりやブレーカーを遮断しない限りバッテリー等には常に通電しているので787で起きたような248日問題が起きうることもあります。Cowardプログラミング経験少なそうなご意見.「境界値」という値があると思っているのか。バグは境界値でしか起きないと思っているのか。こんなのは、まだまだ序の口だからね。プログラミング経験少なそうなご意見.たぶんテストについて「完全に理解」してる段階。単純な条件分岐の境界だけに限らず、複数モジュールの関係性から生まれる数式上の境界や式精度が限界を超える境界など、境界と一口に言っても色々ある。「ちゃんとテスト組んだけどカバーするのが無理なくらい複雑な条件だった」みたいな話ではない。そもそも、全部の滑走路のデータ突っ込めば出てきた筈の不具合だし。(#3743970)やたら「境界値」にこだわってるみたいだけど、方位270度は境界値じゃないし、実装上のゼロ除算バグでしょコレ。いうツッコミだと思うの。(#3744093)270度は、cosで0になるので、ゼロ除算バグを誘発する境界値と言えると思う。Cowardそもそもテストして当然という発言は実装時に検討して当然という言葉になって跳ね返ってくるので使わないほうがいいかなーって。客は「不具合はないのが当然。俺の要求に穴があるのも当然。要求の穴は受注した開発者が塞ぐのが当然。Cowardラジアンは知ってるのに三角関数が返す値は見たことないんだね......可哀相に。Cowardちゃんと計算されてる。Cowardジンバルロックがない四元数というのがあるよ。degreeだから最初から四元数で処理するのは不可能。そんなんプログラミングに触れる程度の理解力があれば小学生でも理解できるだろう。四元数まで持ち出して言い訳するのは見苦しいよ。そもそも扱う次元数が無茶苦茶。実際の水準は低かったんだから実際との落差はないってアホかな。Coward勝手にでなく、ちゃんとした鬼女のある話でしょ。・それなりに権限を持った人が、その裁量で対象外にOKを出した。・それで、テスト工数が100分の1とかになった。・その人は、一番良い成果と評価された。・でも違ったら、その人の脳に直接響くダメージとなる。Cowardふぐを素人が調理して食って死ぬのは仕様でありまた99.99999999999999999999999%再現するのでいちいちテストしません。素人が調理したふぐを食べ他人が死ぬのは仕様どおりの実装であり動作として問題はない。発注者の要求に沿った仕様でもある。正常系の処理が仕様通りに実装されているという観点から確認すべき。ぶっちゃけ雑な喩え話に噛み付いているだけでもとこめのバカはどうでもいい。Cowardアップデートで新たに出て来た可能性も。多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。service.閉じるスラド処理中...。