現場數據

產品實際使用中得到的數據為現場數據。軟件現場數據不同於測試數據，對其的分析就變得更為重要。現場收集的數據通常都沒有進行有效控制，分析的過程是基於得到的以往的數據，而現場數據分析系統一般不能停止操作運行來等待數據的分析。另外，由於競爭壓力，各組織往往不願意公開現場數據。 ^[1] 

要收集某項數據及分析數據，測試人員和分析人員如果缺乏明確認識，可能會造成投人了大量資源進行現場失效數據收集卻回報甚微的情況。軟件可靠性研究必須有明確的對象、目標和分析方法，這樣可以有效地利用現有數據，並將收集需要的補充數據的費用降至最低。使用階段收集和分析的現場可靠性數據，對產品的設計和製造的評價最權威，因為它反映的使用環境條件最真實，參與評估的產品數量較多，其評估結果反映了產品趨向成熟期或到達成熟期時的可靠性水平，是該產品可靠性工作的最終檢驗，也是今後開展新產品的可靠性設計和改進原產品設計的有益的參考。 ^[1] 

建立一個完全可靠的數據收集過程需要數據採集者和使用者不斷地合作。有兩種現場數據的收集方法：在線自動記錄和人工報告。在線自動記錄是由操作系統對錯誤進行自動地在線記錄，而人工報告是由用户、問題分析員和軟件開發人員三類數據收集者記錄產生，由用户記錄系統運行時所出現的問題，並把這些問題交由分析員進行診斷，最後由開發人員在確定分析結果後進行修復。在這兩種數據收集方法中，數據應用人員根據需要提供定義和格式來收集軟件錯誤和失效數據，這樣數據就能夠按照給定的定義和格式自動地由操作系統或人工收集得到。兩種收集方法對於準確的可靠性分析工作來説都是必需的，並且在理想情況下，兩種數據是可以進行交叉引用的。可靠數據收集過程是一個漫長的過程，數據收集的定義和格式會隨着數據收集過程、軟件及硬件環境的變化而進行調整。 ^[1] 

多數大型計算機系統都在操作系統中提供記錄錯誤的軟件。該軟件記錄在各個子系統，如內存、磁盤和網絡子系統出現的錯誤信息，系統事件信息如重新啓動和突然斷電等也包括在操作系統中。記錄通常包括錯誤發生的位置、時間和類型，出錯時系統的狀態和錯誤修復情況（如再運轉）。這些記錄被定期地存儲在一個永久性的系統文件中。

對於系統進程在運行時出現的問題，或由系統處理進程檢測出的非優先應用中出現的問題和不正常硬件出現的情況，操作人員可以在必要時介入並收集額外的數據，如有關處理進程狀態的信息塊和處理器內存信息塊。這些信息塊由於量很大，因而通常不存在於事件記錄中。這些信息在一個高級環境中可以被當做一部分在線自動記錄，因為在這些高級環境中，許多通常由操作人員完成的任務都被編入操作系統的數據收集模塊中了。

主要優點：能夠記錄大量瞬時錯誤和在線錯誤恢復處理進程等信息，它還提供了近乎100%的記錄和準確的時間信息，而這對於人工報告來説是非常困難的。

缺點：在線記錄也面臨着一些問題，如在線錯誤記錄提供的信息沒有潛在錯誤信息和脱機診斷，所以很有必要在自動記錄中補充進一些人工報告中的信息。 ^[1] 

人工報告即現場問題報告。當某一個問題影響到用户應用程序或者系統的運行時，用户便把它寫入錯誤報告文件以尋求問題的解決。問題有可能很簡單，比如説對軟件性能缺乏瞭解，或是表面性的小問題。也有可能比較嚴重，比如系統崩潰或是丟失數據之類。首先，報告應包含下列信息：錯誤出現時間、嚴重程度、系統識別和用户提供的問題描述。在系統崩潰和數據丟失的情況下，還應提供附加的信息（如處理器內存信息塊）。當報告的問題由系統分析員和開發人員診斷和修復時，所有的診斷分析過程、潛在故障信息、失效的表現和修復過程全都應附在報告中。由於這些信息用固定格式很難描述，因此人工報告主要是用段落文字來描述，只有報告頭與所有其他報告一樣有固定的格式。另外還有一種報告叫操作員記錄，是由系統操作員來完成的。操作員記錄的內容包含系統崩潰、失效診斷和軟硬件更新等信息。

軟件錯誤報告詳細地列出了潛在故障、症狀和修復情況的信息。因此利用這種報告便可用來分析許多軟件可靠性問題。然而利用人工報告進行評價分析時，仍存在兩個缺點。首先，報告不詳細的問題比較突出，據估計近80%的處理器的失效是由於沒有進行記錄。因此説理想情況應該是在線記錄、人工報告和操作員記錄都存在並同時進行參考。其次，因為人工報告是人為寫出的文字報告，不易由自動化的工具進行分析處理，不能像原始數據被組織成結構化的數據，這樣就不利於數據分類，並對每一分類的實例進行計數。這就意味着即便某失效已發生很長時間，但仍需要了解該失效的詳細情況，而此時可能有關該失效的重要信息都已丟失，這樣就可能導致人們把大量的評估精力都用在這種數據的重新組織上，而不是問題的分析上。為了有效解決這個問題，可以在收集數據以前產生目錄。 ^[1] 

可靠性數據的收集應有周密的計劃。現場數據不可能做到非常完善，產品一經投入使用，所到之處都是數據的發生地，在不可能做到面面俱到的情況下，應根據需求分析選擇重點產品和地區作為數據收集點。 ^[1] 

在進行數據收集以前必須進行需求分析，明確數據收集的內容及目的，對可靠性數據的需求是根據產品生命週期內不同階段對可靠性分析的需要決定的。有目的、有針對性地收集這些數據，對產品可靠性增長及達到其設計要求的目標值將起到重要作用。然而不同的生命階段對數據的需求是不同的，所收集的對象和內容應隨之確定。 ^[1] 

在不同的生命階段有不同的數據收集點，對於現場數據，主要是使用部門的質控室或維修部門等。在選擇重點地區或部門時，以有一定的代表性為好，如使用的產品羣體較大，管理較好，使用中代表了典型的環境與使用條件等。對於新投入使用的產品，應儘可能從頭開始跟蹤記錄，以反映其使用的全過程。 ^[1] 

這是數據收集系統的重要任務。根據需求制定所需收集內容的統一、規範化的表格，這將便於計算機處理，也便於在同行業或同部門內流通；有利於減少重複工作，提高效率，也有利於明確認識，統一觀點。 ^[1] 

在建立了完善的數據收集系統以後，可依數據傳送的途徑，按正常流通渠道進行數據收集。當數據收集系統運行尚不完善時，可用以下兩種方式進行收集：一是在使用現場聘請信息員，讓其按所要求收集的內容，逐項填表，定期反饋；另一方式是派專人到現場收集，按預先制訂好的計劃進行。兩種方式收集的效果是相同的。

最後，為保證上述工作有條不紊地順利開展，嚴格的科學管理手段是不可缺少的。否則，軟件故障的收集工作就不可能圓滿完成。負責收集軟件故障數據的人員，必須具有細心、嚴謹、堅韌不拔的工作作風，當然，在收集軟件故障數據時，如果成本、進度方面的矛盾變得十分尖鋭，就應該採取靈活的折中方案。 ^[1] 

從實際系統中獲取現場可靠性數據並對其進行分析處理可以按照以下5個步驟進行：

從現場數據中提取必要的信息。要進行該步驟就必須詳盡地瞭解實際系統所涉及的操作系統、目標軟件和系統操作等相關內容，實際的處理過程可根據數據類型而定。 ^[1] 

對所獲取數據進行分析。通過該步驟可達到兩個目的，一是得到運行軟件在實際環境中的可靠性特徵，二是分析出影響軟件系統可靠性的因素以便於提高系統性能。 ^[1] 

根據數據分析的結果確定合適的可靠性模型（如Markov模型），並估計參數的實際變化範圍。所確認的可靠性模型要能夠對實際環境中的軟件可靠性行為進行一種抽象描述，這些軟件可靠性模型包括可執行性模型、錯誤和可恢復模型、現場捕捉到的有效故障的軟件可靠性模型以及依靠工作負荷的軟件可靠性模型。 ^[1] 

在未得到所開發模型的求解技術的情況下進行的。一旦掌握了求解技術，那麼利用真實數據就可以使該模型發揮作用。這裏的模型求解還含有求得可靠性標準的含義（這些標準包括可靠性、可用性和運行性能等）。 ^[1] 

對模型中由於各種因素變化而對軟件可靠性產生的影響進行評估。通過該步驟可以確定系統的可靠性瓶頸，並且可以預測設計中的變動對軟件可靠性所產生的影響。 ^[1] 

軟件可靠性的試驗評估工作可以在軟件生命週期的不同階段進行。在開發階段，可靠性數據需要通過代碼檢查和軟件測試產生，很多研究都已經對開發階段所收集的可靠性數據進行了評估。然而開發階段的軟件可靠性並不能代表運行階段的軟件可靠性，因為運行中軟件的可靠性可能會與其開發階段的可靠性有很大差別。在軟件運行階段，軟件的更新速度相對低一些。由於各種故障軟件的可視性和系統對它的容錯特性都是不一樣的，另外由於工作負荷的影響，軟硬件平台的交互作用和環境因素對軟件的影響也不盡相同，因此每一個軟件的故障都對軟件可靠性有着不同的影響，這樣在運行階段軟件可靠性的估計就不能使用在開發階段所收集的數據。在該階段，最好的辦法就是通過直接收集到的可靠性數據來分析運行軟件的可靠性。 ^[1]