この質問にはすでに回答があります：
回答
バグのないアプリケーションに最も近いのはより高価になります。これは、100％のコードカバレッジをターゲットにするようなものです。0％から95％、95％から99％、99％から99.9％に同じ時間とお金を費やします。
コードカバレッジまたは品質のこの追加の0.1％が必要ですか？原子炉の冷却システムを制御するソフトウェア製品に取り組んでいる場合は、おそらくそうです。ビジネスアプリケーションで作業している場合はおそらくそうではありません。
また、高品質のソフトウェアを作成するにはが必要です。まったく異なるアプローチ。ビジネスアプリの作成に一生を費やした開発者のチームに、ほぼバグのないアプリケーションを作成するよう依頼することはできません。 高品質のソフトウェアには、正式な証明 、コストが非常に高いため、ビジネスアプリでは絶対に使用したくないものです。
で説明したように私の記事：
-
ビジネスアプリは、「ライフクリティカルなソフトウェアに必要な品質をターゲットにするべきではありません。ビジネスアプリが時々失敗した場合、それは失敗するだけだからです」。重要です。おそらくすべての大企業のWebサイトでバグやダウンタイムが発生していますが、Amazonが唯一の例外です。このダウンタイムとこれらのバグは煩わしく、月に数千ドルの費用がかかる可能性がありますが、修正にははるかに費用がかかります。
-
コストを主な焦点にする必要があります。実践的に研究する必要があります。 5 000人の顧客に影響を及ぼし、それらの顧客が永遠に去るほど重要なバグを想像してみましょう。これは重要ですか？はい？もっと考えてみてください。これらの顧客のそれぞれが年間10ドルを支払っているとしたら、どうなるでしょうか。バグを修正するのに約$ 100 000の費用がかかりますか？バグ修正は今ではそれほど面白くありません。
次に、具体的に質問に答えます：
多くのテストを行った後でもバグが報告されるのはなぜですか？それは要件の問題ですか？クライアントは私たちが提供するものに満足していないようです？何か間違ったことをしていますか？
多くのことがうまくいかない可能性があります。テストとは、実際の自動テストを意味しますか？そうでなければ、これはそれ自体が大きな問題です。テスターは要件を理解していますか？定期的に顧客と連絡を取りますか？少なくとも反復ごとに1回、せいぜい顧客担当者はチームのメンバーがオンサイトですぐに連絡できます？あなたの反復は十分に短いですか？開発者は独自のコードをテストしていますか？
上記のリンクの適切なものを書く記事と同様に、バグレポートを取得して調査しますこのバグが最初に発生した理由と、各テスターが見逃した理由。これにより、チームのプロセスのギャップについていくつかのアイデアが得られる可能性があります。
考慮すべき重要なポイント：顧客はバグ修正にお金を払っていますか？そうでない場合は、次のことを検討するように促される可能性があります。バグになります。バグに費やした時間の支払いを彼に行わせると、バグレポートの数が大幅に減ります。
誰かが開発したアプリケーションを開発したことがありますか。完全にバグがない？プロセスは何ですか？マイナーなバグでアプリケーションをデプロイできないのはなぜですか？私たちは完璧主義者になるはずですか？
私。私は先週末に自分用のアプリを作成しましたが、これまでのところバグは見つかりませんでした。
バグは、報告されたときのバグにすぎません。したがって、理論的には、バグのないアプリケーションを持つことは完全に可能です。誰も使用しなければ、バグを報告する人は誰もいません。
今、完全に一致する大規模なアプリケーションを作成します。仕様であり、正しいことが証明されている（上記の正式な証明を参照）のは別の話です。これがライフクリティカルなプロジェクトである場合、これは目標である必要があります（これは、アプリケーションを意味するものではありません >バグはありません。
現在のシナリオは、開発とテストの正しいプロセスですか？そうでない場合、開発者、テスター、クライアントが一緒に最大の利益を得る効率的な方法は何ですか？
-
お互いを理解するために、彼らは通信する必要があります。これは、私が見たほとんどの企業で起こっていることではありません。ほとんどの企業では、プロジェクトマネージャーだけが顧客（場合によっては担当者）と話します。次に、彼は要件の理解を開発者、インタラクションデザイナー、アーキテクト、DBA、テスターと（時には部分的に）共有します。
これが、顧客（または顧客の代表者）にとって不可欠である理由です。チームの誰もが到達可能である（アジャイルアプローチ）、またはチーム内の他の数人とのみ通信することを許可し、情報をチーム全体で共有できる方法でそれを行うことを許可する正式な通信手段を持つこと。全員が同じ情報を持っていることを確認します。
-
開発とテストを行うプロセスはたくさんあります。会社とチームを正確に知らなければ、どちらをすべきかを判断する方法はありません。あなたのケースに適用されます。コンサルタントを雇うか、十分に熟練したプロジェクトマネージャーを雇うことを検討してください。
コメント
回答
すべてのバグが同じように作成されるわけではないため、もみ殻から小麦を選別する必要があります。
期待
ソフトウェアの機能とエンドユーザーの期待が不足しているために、多くのバグが発生します。この期待は、他のソフトウェアの使用、誤ったドキュメント、熱心な営業スタッフ、ソフトウェアの使用方法など、多くの分野から来ています。
スコープクリープ
言うまでもなく、配信する量が多いほど、バグが発生する可能性が高くなります。多くのバグは、単に新機能の裏で発生します。 X & Yを配信しますが、顧客は、これの裏側でZも実行する必要があると言っています。
問題のドメインを理解する
問題のドメインが十分に理解されていないという単純な理由で、多くのバグが発生します。すべてのクライアントには、独自のビジネスルール、専門用語、および物事のやり方があります。これの多くはどこにも文書化されません-それはただ人々の頭の中にあるでしょう。世界最高の意志で、これらすべてを1回のパスでキャプチャすることはできません。
だから…どうしたらよいか。
自動化された単体テスト
コード変更などの予期しない副作用として、多くのバグが発生します。自動化された単体テストがあるので、これらの問題の多くを回避し、最初からより良いコードを生成できます。
テストは提供されたデータと同じくらい良いので、問題のドメインを完全に理解していることを確認してください。
コードカバレッジ
これは、自動化された単体テストと密接に関連しています。実用的な限り多くのコードがテストされていることを確認してください。
レッスンを学ぶ
狂気は同じことを何度も何度も繰り返し、異なる結果を期待しています
最後の失敗の原因を理解していますか？あなたは？本当に？あなたはやめたかもしれません問題 発生していますが、本当のルートソースは何でしたか？悪いデータ？ユーザーエラー？ディスクの破損？ネットワークの停止？
何らかの解決策に向けて前進することなく、同じ問題に何度も遭遇することほどクライアントを悩ませることはありません。
回答
ソフトウェア開発の当初から欠陥がありました。質問から、欠陥が使いやすさや機能にどの程度、どの程度の影響を与えるかを判断するのは困難です。
欠陥のないプログラムは存在しますが、重要なシステムには欠陥があります。
ある種の優先順位を決定する必要があり、欠陥の原因（どこで発生したか）を調査する必要があります。簡単なQ &投稿。
品質に問題がある組織の原因分析と修正プロセスについて、すべての本が書かれています。
だから私の推薦：（順不同）
- 欠陥追跡システムをまだ見つけていない場合は実装する
- 欠陥の重大度を分類する方法を決定する
- 顧客の期待に応えていない理由（開発者、QA、顧客など）を把握する
- 「5つのなぜ」などの演習について学び、同様の調査を行います。あなたの欠陥の原因のいくつかへの分析。
回答
アプリケーションの名前によって異なります。
つまり、特定の状況下でリアルタイムの動作が正確にそのようなものであることを確認する必要があるインタラクティブプログラムの場合、バグがないことを証明することは基本的に不可能です。初期化。 停止問題を解決できれば可能だと思いますが、解決できません。
ただし、 「そのような入力は最終的にそのような最終状態を生成します」というステートメントの場合、不変条件を使用できるため、「バグのない証明」の可能性が高くなります。。それだけで、正しさの証明をサブ問題に分解できます。各問題は、すべての状況下で正しく機能することが比較的簡単に証明できます。残りのプログラムの（ただし、一般的に、&メモリにかかる時間についてはあまり正確ではありません）。
このような手法は基本的にどのプログラムでも可能です。プログラミング言語（ Malbolge のようないくつかの難解な言語はそれを非難しようとしますが！）、しかしすべての命令型言語では、それは非常にすぐに乱雑になります、あなたは細心の注意を払って多くのことを追跡しなければならないので暗黙のプログラム状態。関数型言語 1 では、証明ははるかに見栄えがする傾向があります（純粋言語、または言語の純粋関数型サブセット）。それでも、特に動的タイプの場合、許可される入力について多くの要件を書き出す必要があります。それはもちろん、強力な静的型システムの主な利点の1つです。要件はコード内にあります！
理想的には、つまり、実際には、O “CamlまたはHaskellプログラムでさえ非合計関数、つまり、正しいタイプ 2 にもかかわらず、特定の入力に対してクラッシュ/ハング/スローする関数。これらの言語には非常に柔軟な型システムがありますが、それを使用して何かを完全に制限することができない場合があります。
依存型言語を入力してください！これらは必要に応じて型を正確に「計算」できるため、定義するすべてのものに、必要なものすべてを証明する型シグネチャを正確に含めることができます。実際、依存型言語はほとんどの場合、証明環境。残念ながら、それらのどれも実際には本番ソフトウェアを作成することではないと思います。実際のアプリケーションの場合、完全にバグプルーフに最も近いのは、Haskellで完全に完全な機能を使用して作成することだと思います。可能です。これにより、機能の説明に関してのみですが、バグプルーフ –にかなり近づきます。Haskell 「モナドを使用してIOを処理する独自の方法も、いくつかの非常に便利な証拠を提供しますが、通常、何かにかかる時間については何もわかりません」仕上げ。おそらく、特定の状況では、ユーザーのPOVから–に指数関数的な時間がかかる可能性があり、プログラムが完全にハングするのと同じくらい深刻なバグになる可能性があります。
1 またはより一般的には、記述的言語。論理言語の経験はあまりありませんが、証明においても同様に優れていると思います。よろしくお願いします。
2 正しいタイプでない場合、コンパイラはそれらの言語でそれを許可しません 。これにより、すでに多くのバグが排除されています（そして、Hindley-Milnerタイプの推論のおかげで、実際にはプログラムもより簡潔になります！）
コメント