如何評估軟件的可靠性？

Question

我們目前正在制定我們將要進行的貿易研究的評估標準。

我們選擇的一個標準是可靠性（和/或魯棒性 - 它們是否相同？）。

您如何評估該軟件是否可靠而又無法承受太多時間評估？

編輯：沿着KenG給出的迴應的路線，縮小問題的焦點： 您可以選擇50個現有的軟件解決方案。您需要評估它們的可靠程度，但不能測試它們（至少在初始階段）。什麼有形指標或其他可用於評估所述可靠性？

Answer 1

可靠性和魯棒性是一個系統正的兩種不同的屬性：

Reliability

的IEEE其定義爲」系統或組件以 的 能力下執行其所需的功能。 規定的條件爲指定的 一段時間。「

Robustness

是強大的，如果它繼續，儘管輸入，計算異常操作，因爲它被設計爲內等

所以一個可靠系統執行其功能限制; A 強大的如果出現意外/未預料的情況，系統將繼續運行。

如果您有機會獲得你正在評估該軟件的任何歷史，可靠性一些想法可以從報告的缺陷推斷，「補丁」的發行數量隨着時間的推移，即使在代碼庫翻騰。

產品是否有自動化測試過程？測試覆蓋率可以是另一個信心指標。

一些使用敏捷方法可能不符合這些標準以及項目 - 頻繁的發佈和大量的重構預計

檢查與現實世界的信息的軟件/產品的現有用戶。

Answer 2

好了，關鍵字「可靠」可能會導致不同的答案......當可靠性思考，我覺得兩個方面： 1〜總是做出正確的答案（或最佳答案） 2〜總是給人相同的答案

無論哪種方式，我認爲它歸結爲一些可重複的測試。如果有問題的應用程序沒有使用字符串的單元和驗收測試進行構建，您仍然可以想出一套手動或自動測試來重複執行。

事實上，測試總是返回相同的結果將顯示方面＃2照顧。對於方面1而言，它確實取決於測試編寫者：提出可以暴露錯誤或缺陷的良好測試。

如果不知道應用程序是關於什麼的，對不起，我不能更具體。例如，如果消息總是被傳遞，永不丟失，從不包含錯誤等等，那麼消息傳遞系統將是可靠的......計算器對可靠性的定義會有很大的不同。

Answer 3

與已使用它的人交談。你可以測試自己的可靠性，但這很難，很昂貴，而且根據你測試的內容可能會非常不可靠，特別是如果你時間不夠緊的話。大多數公司會願意讓您與當前的客戶聯繫，如果它能幫助您銷售他們的軟件，他們將能夠給您一個關於軟件如何處理的真實世界的想法。

Answer 4

這取決於您正在評估哪種類型的軟件。一個網站的主要（也可能只是）可靠性標準可能是它的正常運行時間。 NASA將具有完全不同的軟件可靠性定義。你的定義可能會介於兩者之間。

如果您沒有足夠的時間來評估可靠性，那麼絕對是關鍵，您可以自動執行您的測量過程。您可以使用continuous integration工具來確保您只需要手動查找一次錯誤。

我建議你或你公司的某人閱讀Continuous Integration: Improving Software Quality and Reducing Risk。我認爲這將有助於您引導您對軟件可靠性的定義。

Answer 5

如果可靠性是一個關鍵標準，並且您沒有（或不願意承諾），那麼您就必須理解並完全接受您將做出妥協，否則可能會產生負面影響。根據這些資源進行適當的評估。儘管如此 - 確定了使軟件可靠性至關重要的關鍵要求，然後根據這些要求設計測試進行評估。

魯棒性，並在其相互之間的關係可靠性交叉，但不一定是相同的。

如果不能處理超過10個連接，你指望100000個連接的數據服務器 - 這是不穩健。如果它在> 10個連接處死亡，它將不可靠。如果同一臺服務器可以處理所需的連接數量，但間歇性地死亡，則可以說它仍然不健壯並且不可靠。

我的建議是，你有經驗的QA人員是誰在爲你的研究將開展該領域的知識諮詢。該人員將能夠幫助您設計關鍵區域的測試 - 在您的資源限制範圍內。我建議一箇中立的第三方（而不是軟件作者或供應商）來幫助你決定你需要測試的關鍵功能，以便做出決定。

Answer 6

正如任何事情，如果你沒有自己的東西評估的時候，那麼你必須依靠他人的判斷。

Answer 7

可靠性是出頭的有效性..另外兩個是維修性和可用性三個方面一個...

一個有趣的紙... http://www.barringer1.com/pdf/ARMandC.pdf討論得更詳細些，但通常

可靠性是基於系統可能中斷的概率，即它越容易中斷，它的可靠性就越低......在其他系統（軟件除外）中，它通常以平均無故障時間（MTBF）來衡量這是硬盤等常見度量標準...（10000小時MTBF）在軟件中，我想你可以用平均值關鍵系統故障之間或應用程序崩潰之間的時間，或不可恢復的錯誤之間的時間，或任何阻礙或負面影響正常系統生產力的錯誤之間的時間...

可維護性是衡量多久/工時和/或其他資源），當它發生中斷時，需要進行修復。在軟件中，您可以添加到這個概念多久或多麼昂貴，以增強或擴展軟件（如果這是一個持續的需求）

可用性是前兩個的組合，並向計劃者表明，如果在確定失敗後，每個失敗的單元在固定，修復等情況下無法使用多長時間後，我有100個這樣的東西運行了10年，平均而言，100箇中有多少個可以運行一次？ 20％，還是98％？

Answer 8

如果你不能測試它，你將不得不依賴開發人員的聲譽，以及他們如何跟隨他們的其他測試應用程序在這個應用程序上的相同做法。例如：微軟在他們的應用程序的第一版上做得不是很好，但通常很不錯（Windows ME的版本是0.0001）。

Answer 9

根據您正在評估的服務類型，您可能會獲得可靠性指標或SLI - 服務級別指標 - 衡量服務/產品效果如何的指標。例如 - 在1秒內處理99％的請求。

基於SLI，您可能會設置服務級別協議 - 您和軟件提供商之間關於SLO（服務級別目標）的合同，您希望它們不會產生這些後果。