Ubuntu チームはどのようにしてバグが再び発生しないことを保証するのでしょうか?
何度か見たことがあります。パッケージをインストールしたら使えなくなる。
はい、バグが非常に早く修正されることもあります。
しかし、バグが再び発生しないように自動テストを改善する努力は見られません。
ここ 2 週間で私に影響を与えた 2 つの例を挙げます。
他にも例はありますが、それらを列挙することは質問の一部ではありません。
バグページからのコメントvsftp:
この新しいパッケージをテストしてご協力ください。https://wiki.ubuntu.com/Testing/EnableProposed-proposed を有効にして使用する方法についてのドキュメント。あなたのフィードバックは、このアップデートを他の Ubuntu ユーザーに提供するために役立ちます。
わかりましたが、上記の引用文の「テスト」はマニュアルテスト。
品質を確保するため自動化されたテストが必要です。
私にとって、手動テストは時間の無駄です。一方、自動テストを構築することで品質は保証されます。
ここで再び質問です:
Ubuntu チームはどのようにしてバグが再び発生しないことを保証するのでしょうか?
この質問の履歴
当初のタイトルは「Ubuntu チームはどのようにしてバグが再発しないようにしているのですか?」でした。現在は「Ubuntu チームはどのようにして自動テストを行っているのですか?」となっています。これは、手動テストは解決策ではないと私が信じているためです。手動テストの実施方法のみを説明する回答には、低評価を付けないでください。
答え1
Ubuntu には自動テストがあります。たとえば、自動テストは、最初のバグ例が再発しないようにするために使用されます。私が最初に言及した vsftpd のバグを修正したのですが、その際に、同じことが再発しないように自動テストも追加しました。これは、バグ自体に投稿された変更ログ エントリで確認できます。
vsftpd (3.0.2-1ubuntu2.14.04.1) trusty; urgency=medium
* d/p/ubuntu-seccomp-gettimeofday.patch: permit gettimeofday() for logging
calls (LP: #1219857).
* Add dep8 smoke test.
-- Robie Basak <[email protected]> Tue, 29 Apr 2014 15:33:07 +0000
このバグを自動テストの欠如の例とみなす理由がわかりません。バグの中でこのことについて何度も言及しているからです。たとえば、要約の中で「将来これを検出するために dep8 テストを追加しました」や「含まれている dep8 テストは、このバグの修正を自動的に検証します」と述べました。
Ubuntu はディストリビューションであることを忘れないでください。これは、私たちがアップストリームと呼ぶ多くの外部プロジェクトを統合した集合体です。Ubuntu は、より広範なフリー ソフトウェア エコシステムの他の人々の作業なしには実現できません。同様に、私たちは、ソフトウェアの専門家であるアップストリームの作者にテストの提供を依頼することがよくあります。
さらに、当社はさまざまなプロジェクトの集合体であるため、単一の自動テスト インフラストラクチャでは意味がありません。領域が異なればニーズも異なります。そのため、当社のテスト戦略はこれらのニーズに合わせて非常に広範囲に及び、さまざまなインフラストラクチャを通じて手動テストと自動テストの両方をカバーしています。
上流プロジェクトが自動テストを提供している場合、パッケージビルドの一部としてそれを実行します。テストに合格しないとパッケージビルドは失敗します。利用可能な自動テストがこのように有効になっていることを確認することは、私たちの主な包含要件:パッケージにテスト スイートが同梱されており、ビルド中に動作しない明らかな理由がない場合 (例: ルート権限やネットワーク アクセスが必要)、パッケージのビルド中にテスト スイートを実行し、失敗したテスト スイートによってビルドが失敗するようにします。
さらに、私たちは「自動インストールパッケージテスト」と呼ばれる仕様に基づいて実行します。8 をこれは、パッケージ間の統合が正しく機能するかどうかをテストするために設計されています。dep8 テストを後退させるパッケージ更新は、修正されるまで開発リリースには適用されません。
私はデスクトップ チームと電話チームが行う自動テストについてはあまり詳しくありませんが、長年にわたってそれらに関する言及を見てきたため、より多くのメカニズムが存在することは知っています。これには、非常に印象的だと思う自動 GUI テストも含まれます。デスクトップと電話の自動テストをカバーする別の回答を歓迎します。
答え2
方法はいくつかあります。
たくさんの目。
Ubuntuはオープンソースなので、誰でもコードを見て問題が何であるかを知ることができます。コードを見ることに興味がある人は、コードの中にバグを見つけたり、使用したりすることがよくあります。ランチパッドで報告するそして一般の人が修正することもできる。
テストして修正を提案したら、メインの Ubuntu パッケージとのマージをリクエストします。他の開発者がこの変更を確認し、承認された場合はそれを追加します。
誰でも修正できるため、すぐに発見され、レビューされ、しばらく放置される可能性は低くなります。これは次のポイントにつながります。
これらの目にはコンピューターの目も含まれます。
アップストリーム QA プロセスは文書化/実証され、SRU トラッキング バグからリンクされる必要があります。このようなアップストリーム自動テストが利用できないその他のケースでは...
これは、通常は自動テストが実施されていることを示しています。
ベータ版リリース
Ubuntuが一般にリリースされる前にはベータ版があります。現在は15.10ベータ版で、2015年10月22日リリースリリース前には、多くの人がこれを使用し、レビューし、バグを修正しているはずです（5ヶ月22日この場合）。
つまり、バグはすぐに削除され（Many Eyes のため）、公式リリース前に修正されるため、一般ユーザーは影響を受けません。
熟練したコードライター
高品質のコードを書くのが得意な人は、そのコードを書いている人です。Ubuntu を次のように書いている人は 1 人だけではありません。
世界中から人々が集まり、Ubuntu の開発元である Canonical に雇用されている人々もいます。こうした人々は皆、少しずつ新しいコードに貢献しています。私が 2,000 行のコードを書いたら、バグはたくさん発生します。200 人が 10 行だけ書いたら、バグはずっと少なくなります。
安定した基盤
私の知る限り、Ubuntu は新しいリリースが出るたびに根本から書き直されるわけではありません。その代わりに、次のバージョンは現在のバージョン (つまり、2015/04/30 時点では 15.10 と 15.04 はどちらも同じ) として始まり、そこから新しい機能が追加されます。
作業の基盤がしっかりしていれば、書くコードが少なくなり、既存のものを信頼できるようになります。既存のものに頼ることができれば、バグが入り込むことも少なくなります。
バージョン管理および記録ソフトウェア
同じバグが複数回発生した場合 (異なるバージョンで、または修正が機能しなかった、または別のパッチによってバグが再発した場合)、バグがどのように修正されたかを説明するドキュメントがあり、再度修正することができます。
私の知る限り、自動テストは存在しません。しかし、自動テストとは何でしょうか? コンパイルできれば、それが自動テストでしょうか? それが何であるかを説明せずに「自動テスト」と言うことはできません。
答え3
バグのあるコードを書かないでください。笑。これに対する詳細な回答を書く気力は失せました。ここにまともな記事があります: https://www.iiitd.edu.in/~jalote/papers/CommonBugs.pdf
そしてここに、作り方に関する良い本がありますC++ の間違い
最善の答えは、ソフトウェア開発タスクをいくつか実行し、問題がどこから来ているのかを自分で確認することかもしれません。私の経験では、予期しない入力/結果の処理は非常に大きな問題です。次に、下流のバグがあります。たとえば、誰かが iostream.h に脆弱性を見つけた場合、そのライブラリを呼び出すすべてのソフトウェアにも同じバグがある可能性があり、少なくともレビューする必要があります。
自動テストについては、確かに存在しますが、限界もあります。すべての言語で機能する単一のソリューションは知りません。本当に興味があるなら、AI を搭載した遺伝的コード デバッガーを書いてください。私の知る限り、すべてはまだ初期段階です。以下は博士課程の学生による研究です。 出典: : www.cs.cmu.edu