アカウント名:
パスワード:
境界値ならテストして当然出だし、境界値でない所でバグなんてよほど変な作りでないと起き得ないし。問題が起きても複数モジュール全部巻き込んで落ちるとか、航空機用のソフト開発でそんな事態が起きるって一体全体どうなっている……
もしボールを空中に放り投げたなら、その軌跡を確信を持って予測できる。というのも、我々は普通の状況において、ある物理法則がそこに適用されることを知っているからである。もしそのボールをもうちょっと強く放り投げただけで、ボールが飛んでいく途中で急に静止し、それからまっすぐに空高く飛んでいったりしたら、とても驚くだろう。ボールの動きをシミュレートする完全にデバッグしきれてないソフトウェアにおいては、ちょうどこの種の振舞いがいとも容易に起きてしまうのである。
大規模なアプリケーションにおいては、数百、いや、数千の変数とともに複数の制御スレッドが存在するかもしれない。システム内部のこれら変数とその現在値と各プロセスの現在アドレスとその呼び出しスタックの完全な集合が、アプリケーションの現在の状態を決定する。ソフトウェアはデジタル・コンピュータ上で実行されるため、システムは拡散的な複数の状態を持つ。これに対して、放り投げられたボールの動きのようなアナログ・システムは連続的なシステムである。拡散的なシステムはその性質上、取り得ることが可能な有限の複数状態を持っている。大規模システムにおいては、組み合わせの爆発によって、この数がとても大きくなってしまう。
我々はシステムをモジュール化して設計しようとする。これによってシステムのある部分の振舞いに対してできるだけ影響を与えないようにするためである。しかしながら、ここには拡散的な状態間の相転移は連続的な機能でモデル化できないという問題が残っている。外部からソフトウェア・システムに与えられるイベントはそのシステムを新しい状態に遷移させる可能性を持っているし、さらに悪いことには、状態から状態のマッピングは必ずしも決定的ではないのである。最悪の状況においては、設計者がイベント間のある相互関係を考慮し忘れていたことで、ある1つの外部イベントがシステムの状態を混乱させてしまうかもしれない。
例えば飛行翼とその客室の環境が1つのコンピュータで管理されている旅客機を想像してみなさい。もしシート38Jの乗客が頭上のライトを点灯した途端、飛行機が急降下したら、非常に具合の悪いことになるであろう。連続的システムにおいては、この種の振舞いは起こりにくい。しなしながら、拡散的システムにおいては、全ての外部イベントはシステムの内部状態のどの部分にも影響を与える可能性が存在するのである。
もっとも、システムを厳密にテストするのは、このようなことが起こらないようにするためなのだが、最も厳密なシステムを除けば、どのシステムに対しても徹底的なテストなど不可能である。我々は、大規模な拡散的システムの振舞いを完全にモデル化するツールも知的な能力も持ち合わせていないのだから、我々はシステムの正しさに関してある程度の信頼度を得ることで満足しなくてはならない。
翻訳ミスと思われる × 拡散的 〇 離散的
磁方位270度とか有限な滑走路情報全部ぶち込んでみるのはそこまで複雑なテストかな。
実機テストをせずに手を抜いたみたいだね。世界の全ての空港でテスト飛行しておけば、バグを潰せたと思われる。
技適を与えた当局もメンツが潰れるし、申請したらテストの許可も出るでしょ。同社は、去年墜落事故起こした機種もあったし相当人手が足りないのか、今後も不安は残る。
JRの改札機システム作ってる会社は、開発者が駅を回ってすべてのパターンのテストしてる、みたいなことは無いよ
条件が揃わないものはテストと呼ばないだけの話では
山のような乗降パターンのテストはしてた筈だがな。
CJK結合文字に同じ書体が入っている文字が選ばれた時のリスクは事前にほぼ誰も指摘してなかったぞ俺は見たこと無い
鏡をどうぞ。
>境界値ならテストして当然出だし、>境界値でない所でバグなんてよほど変な作りでないと起き得ないし。ここ数十年にわたるソフトウェアやハードウェアの不具合によるシステム異常は「当然だし」「起きえないし」という観点てテストしている結果によるものです。
何をいっているんだ?とか、言っている意味が分からない人はバグという観点を学びなおした方がいいかもしれまsねn
タイピングがバグってますよ
それはまさにそうなんだが、あまりに自明で初歩的な境界値 [srad.jp]で起きてる現象っぽいので、よりにもよって航空機の開発でそんなところすらテストできない状況が発生するってのが驚きなんだよ。
> タイピングがバグってますよ「当然出だし」に便乗したネタ感
The Registerの記事読んでみたら、248日以内に再起動しないと整数オーバーフロー発生するバグとか、エアバスだとそれが149時間のやつがあったとか書いてあるぞ。
自動化への道は険しいのう…
そもそも一度電源が投入されたら24時間以内に必ず何らかの方法(墜落含む)でシャットダウンされるので、そこまでの能力は必要ないのです…。
毎回”シャットダウン”してんの?
旅客機は着陸後毎回電源が落とされています。(ただし、コネクタを物理的に外したりやブレーカーを遮断しない限りバッテリー等には常に通電しているので787で起きたような248日問題が起きうることもあります。)
プログラミング経験少なそうなご意見.「境界値」という値があると思っているのか。バグは境界値でしか起きないと思っているのか。
しかもこんなのは、まだまだ序の口だからね。
> プログラミング経験少なそうなご意見. たぶんテストについて「完全に理解」してる段階。
境界以外のバグも当然あるが、このケースに関して言えば不具合が発生する値と発生しない値があるんだからその境界は存在するだろ・・・単純な条件分岐の境界だけに限らず、複数モジュールの関係性から生まれる数式上の境界や式精度が限界を超える境界など、境界と一口に言っても色々ある。どの程度掘り下げた境界が不具合の境界だったのかは知らないが、磁方位270度とか思いの外わかりやすい境界で起きてるらしいし、「ちゃんとテスト組んだけどカバーするのが無理なくらい複雑な条件だった」みたいな話ではない。
そもそも、全部の滑走路のデータ突っ込めば出てきた筈の不具合だし。
やたら「境界値」にこだわってるみたいだけど、方位270度は境界値じゃないし、実装上のゼロ除算バグでしょコレ。っていうツッコミだと思うの。
270度は、cosで0になるので、ゼロ除算バグを誘発する境界値と言えると思う。
入力の境界値ではなかろう制御理論で言うところの極ってやつ?
条件分岐やそういう特異な値の境界での動作見るのが境界値チェックでは?
磁方位は0-360の整数なので270は特異でも境界でも真ん中でもないラジアンでは3/2Pi≒4.71239でやはり特異でも境界でも真ん中でもないtan(3/2Pi)は特異だが入力が磁方位ならtan(3/2Pi)は計算式であって入力値ではない
どうやっても「(境界値だから)テストして当然」という発言の後付け正当化は無理
そもそもテストして当然という発言は実装時に検討して当然という言葉になって跳ね返ってくるので使わないほうがいいかなーって。// そして客は「不具合はないのが当然。俺の要求に穴があるのも当然。要求の穴は受注した開発者が塞ぐのが当然。」などとおっしゃる。
ラジアンは知ってるのに三角関数が返す値は見たことないんだね……可哀相に。
核ミサイルを北極上空飛ばして打ち込んでも大丈夫かとか、核ミサイルを赤道や緯度0°や180°超えて打ち込んでも大丈夫かとか、境界値テストされないまま運用されてる気がするんだが
ちゃんと計算されてる。角度とか。
ジンバルロックがない四元数というのがあるよ。
Unity弄ってる高校生でも四元数なのになんでボーイングが弧度法使ってんだって話ですわ境界チェック(笑)すれば弧度法と三角関数でいいと思ってる奴って頭どうなってんだろうな
滑走路の方位角や磁方位やUI全般がarc degreeだから最初から四元数で処理するのは不可能。そんなんプログラミングに触れる程度の理解力があれば小学生でも理解できるだろう。
境界チェック如きで発見可能なパターンであることに反論出来なくなって悔しいのはわかるけど、四元数まで持ち出して言い訳するのは見苦しいよ。そもそも扱う次元数が無茶苦茶。
「信じがたい」「当然」「起き得ない」
ソフトウェアバグを語る素養を持ち合わせているように見えないな
信頼性が求められる環境における体制の話として信じがたいのと、ソフトウェア開発でどんなバグが起きうるかの話をごっちゃにする方がどうかと………
ソフトウェア開発で起こりうるバグは信頼性が求められる環境であっても起こりうるどんなに厳重に体制を構築しても確率をある程度減らすことしかできない
90度の倍数の確認すら漏れてて厳重な体制と言えるんだ……
そりゃインシデントがあって初めて分かった原因だから当たり前
「求められるべき水準」と「実際」の落差を言ってる所に、実際の水準は低かったんだから実際との落差はないってアホかな。
エンジニアのくせに自分が言ったこと書いたもの異常動作をすると勝手に怒りだすバカって意外と多いよ特に口頭だと「そんなのは非常識だから起こる状況が間違いなので考えなくていい」とかな
勝手にでなく、ちゃんとした鬼女のある話でしょ。・それなりに権限を持った人が、その裁量で対象外にOKを出した。・それで、テスト工数が100分の1とかになった。・その人は、一番良い成果と評価された。・でも違ったら、その人の脳に直接響くダメージとなる。で、脳がバグるのは正常では?
原因が分かっていることなら異常ではない問題ではないのだったら素人がフグを調理して死ぬのも異常ではない問題ではないと言える
ふぐを素人が調理して食って死ぬのは仕様でありまた99.99999999999999999999999%再現するのでいちいちテストしません。
つまり機序が分かっていることは問題では無いと言いたいんだろ書かれたソース通りの異常動作だから発注仕様書に違反していてもこれが俺の仕様だとまさに元コメで言ってるバカじゃん
発注者:神実装者:自然素人が調理したふぐを食べ他人が死ぬのは仕様どおりの実装であり動作として問題はない。当然発注者の要求に沿った仕様でもある。むしろ正常系の処理が仕様通りに実装されているという観点から確認すべき。ぶっちゃけ雑な喩え話に噛み付いているだけでもとこめのバカはどうでもいい。
鬼女
全数検査はしないのが一般的ですまあ境界値テストの対象から漏れちゃったんでしょう
アップデートで新たに出て来た可能性も。
より多くのコメントがこの議論にあるかもしれませんが、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)
鏡をどうぞ。
Re:にわかには信じがたい (スコア:1)
>境界値ならテストして当然出だし、
>境界値でない所でバグなんてよほど変な作りでないと起き得ないし。
ここ数十年にわたるソフトウェアやハードウェアの不具合による
システム異常は「当然だし」「起きえないし」という観点て
テストしている結果によるものです。
何をいっているんだ?とか、言っている意味が分からない人は
バグという観点を学びなおした方がいいかもしれまsねn
Re: (スコア:0)
タイピングがバグってますよ
Re: (スコア:0)
それはまさにそうなんだが、あまりに自明で初歩的な境界値 [srad.jp]で起きてる現象っぽいので、
よりにもよって航空機の開発でそんなところすらテストできない状況が発生するってのが驚きなんだよ。
> タイピングがバグってますよ
「当然出だし」に便乗したネタ感
Re:にわかには信じがたい (スコア:1)
The Registerの記事読んでみたら、248日以内に再起動しないと整数オーバーフロー発生するバグとか、エアバスだとそれが149時間のやつがあったとか書いてあるぞ。
自動化への道は険しいのう…
Re: (スコア:0)
そもそも一度電源が投入されたら24時間以内に必ず何らかの方法(墜落含む)でシャットダウンされるので、そこまでの能力は必要ないのです…。
Re: (スコア:0)
毎回”シャットダウン”してんの?
Re:にわかには信じがたい (スコア:2, 参考になる)
旅客機は着陸後毎回電源が落とされています。
(ただし、コネクタを物理的に外したりやブレーカーを遮断しない限りバッテリー等には常に通電しているので787で起きたような248日問題が起きうることもあります。)
Re: (スコア:0)
プログラミング経験少なそうなご意見.
「境界値」という値があると思っているのか。
バグは境界値でしか起きないと思っているのか。
しかもこんなのは、まだまだ序の口だからね。
Re: (スコア:0)
> プログラミング経験少なそうなご意見.
たぶんテストについて「完全に理解」してる段階。
Re: (スコア:0)
境界以外のバグも当然あるが、このケースに関して言えば
不具合が発生する値と発生しない値があるんだからその境界は存在するだろ・・・
単純な条件分岐の境界だけに限らず、複数モジュールの関係性から生まれる
数式上の境界や式精度が限界を超える境界など、境界と一口に言っても色々ある。
どの程度掘り下げた境界が不具合の境界だったのかは知らないが、
磁方位270度とか思いの外わかりやすい境界で起きてるらしいし、
「ちゃんとテスト組んだけどカバーするのが無理なくらい複雑な条件だった」
みたいな話ではない。
そもそも、全部の滑走路のデータ突っ込めば出てきた筈の不具合だし。
Re:にわかには信じがたい (スコア:1)
やたら「境界値」にこだわってるみたいだけど、方位270度は境界値じゃないし、実装上のゼロ除算バグでしょコレ。っていうツッコミだと思うの。
Re:にわかには信じがたい (スコア:3)
270度は、cosで0になるので、ゼロ除算バグを誘発する境界値と言えると思う。
Re: (スコア:0)
入力の境界値ではなかろう
制御理論で言うところの極ってやつ?
Re: (スコア:0)
条件分岐やそういう特異な値の境界での動作見るのが境界値チェックでは?
Re: (スコア:0)
磁方位は0-360の整数なので270は特異でも境界でも真ん中でもない
ラジアンでは3/2Pi≒4.71239でやはり特異でも境界でも真ん中でもない
tan(3/2Pi)は特異だが入力が磁方位ならtan(3/2Pi)は計算式であって入力値ではない
どうやっても「(境界値だから)テストして当然」という発言の後付け正当化は無理
Re: (スコア:0)
そもそもテストして当然という発言は実装時に検討して当然という言葉になって跳ね返ってくるので使わないほうがいいかなーって。
// そして客は「不具合はないのが当然。俺の要求に穴があるのも当然。要求の穴は受注した開発者が塞ぐのが当然。」などとおっしゃる。
Re: (スコア:0)
ラジアンは知ってるのに三角関数が返す値は見たことないんだね……可哀相に。
Re: (スコア:0)
核ミサイルを北極上空飛ばして打ち込んでも大丈夫かとか、
核ミサイルを赤道や緯度0°や180°超えて打ち込んでも大丈夫かとか、
境界値テストされないまま運用されてる気がするんだが
Re: (スコア:0)
ちゃんと計算されてる。角度とか。
Re: (スコア:0)
ジンバルロックがない四元数というのがあるよ。
Re:にわかには信じがたい (スコア:1)
Unity弄ってる高校生でも四元数なのになんでボーイングが弧度法使ってんだって話ですわ
境界チェック(笑)すれば弧度法と三角関数でいいと思ってる奴って頭どうなってんだろうな
Re: (スコア:0)
滑走路の方位角や磁方位やUI全般がarc degreeだから最初から四元数で処理するのは不可能。
そんなんプログラミングに触れる程度の理解力があれば小学生でも理解できるだろう。
境界チェック如きで発見可能なパターンであることに反論出来なくなって悔しいのはわかるけど、
四元数まで持ち出して言い訳するのは見苦しいよ。
そもそも扱う次元数が無茶苦茶。
Re: (スコア:0)
「信じがたい」「当然」「起き得ない」
ソフトウェアバグを語る素養を持ち合わせているように見えないな
Re: (スコア:0)
信頼性が求められる環境における体制の話として信じがたいのと、
ソフトウェア開発でどんなバグが起きうるかの話をごっちゃにする方がどうかと………
Re: (スコア:0)
ソフトウェア開発で起こりうるバグは信頼性が求められる環境であっても起こりうる
どんなに厳重に体制を構築しても確率をある程度減らすことしかできない
Re: (スコア:0)
90度の倍数の確認すら漏れてて厳重な体制と言えるんだ……
Re: (スコア:0)
そりゃインシデントがあって初めて分かった原因だから当たり前
Re: (スコア:0)
「求められるべき水準」と「実際」の落差を言ってる所に、
実際の水準は低かったんだから実際との落差はないってアホかな。
Re: (スコア:0)
エンジニアのくせに自分が言ったこと書いたもの異常動作をすると勝手に怒りだすバカって意外と多いよ
特に口頭だと「そんなのは非常識だから起こる状況が間違いなので考えなくていい」とかな
Re: (スコア:0)
勝手にでなく、ちゃんとした鬼女のある話でしょ。
・それなりに権限を持った人が、その裁量で対象外にOKを出した。
・それで、テスト工数が100分の1とかになった。
・その人は、一番良い成果と評価された。
・でも違ったら、その人の脳に直接響くダメージとなる。
で、脳がバグるのは正常では?
Re: (スコア:0)
原因が分かっていることなら異常ではない問題ではないのだったら
素人がフグを調理して死ぬのも異常ではない問題ではないと言える
Re: (スコア:0)
ふぐを素人が調理して食って死ぬのは仕様でありまた99.99999999999999999999999%再現するのでいちいちテストしません。
Re: (スコア:0)
つまり機序が分かっていることは問題では無いと言いたいんだろ
書かれたソース通りの異常動作だから発注仕様書に違反していてもこれが俺の仕様だと
まさに元コメで言ってるバカじゃん
Re: (スコア:0)
発注者:神
実装者:自然
素人が調理したふぐを食べ他人が死ぬのは仕様どおりの実装であり動作として問題はない。
当然発注者の要求に沿った仕様でもある。
むしろ正常系の処理が仕様通りに実装されているという観点から確認すべき。
ぶっちゃけ雑な喩え話に噛み付いているだけでもとこめのバカはどうでもいい。
Re: (スコア:0)
鬼女
Re: (スコア:0)
全数検査はしないのが一般的です
まあ境界値テストの対象から漏れちゃったんでしょう
Re: (スコア:0)
アップデートで新たに出て来た可能性も。