軟件產品檢驗檢測質量狀況分析

王 蕊，張碧肖，黃 婧

（國家軟件產品質量監督檢驗中心（江蘇），江蘇 南京 210012）

1 總體狀況

1.1 質量發展現狀

我國的軟件智能化行業正處于快速發展期，尤其是東南一帶經濟發達省份的軟件行業收入已占全國軟件行業收入的絕大部分。隨著客戶質量意識的不斷提升和政府部門信息化工程建設力度不斷加大，對于軟件智能化產品質量第三方檢測服務的需求也越來越大，對軟件智能化產品質量的要求也越來越高。

1.2 檢驗檢測基本情況

第三方檢測機構所承擔的檢測任務主要來源于政府和企業的委托檢驗。以2018年三季度為例，我中心共檢測軟件產品246批次，檢測企業數129家，全部為委托檢驗類型，主要提供實測數據。弱電智能化產品5批次，檢測企業數4家，批次合格率80%。

1.3 檢測情況分析

軟件產品檢測項目主要包括功能性、性能效率、兼容性、易用性、可靠性、信息安全性、維護性、可移植性等質量特性，在委托檢驗中，檢測重點通常集中在軟件功能性、性能效率和信息安全性三個方面。由于軟件產品屬于非傳統行業，客戶定制化特點非常明顯，在通常用于驗收測試的委托檢驗中，通常會進行2-3輪檢測，在首輪檢測中發現的問題，在與開發方和委托方溝通后，經過進一步修改，更新版本，在后續檢測中將問題修正。軟件產品的委托檢驗，通常只提供實測結果，不提供判定結論。弱電智能化產品主要檢測項目有綜合布線、智能樓宇、機房檢測、信息網絡等。

軟件產品委托檢驗首輪測試中，共在50個軟件樣品中發現8940個問題。按照嚴重等級劃分，其中S2級問題1444個，占比16.2%；S3級問題7377個，占比82.5%，S4級和S5級問題119個，占比1.3%。缺陷等級定義見圖1：

圖1 缺陷等級定義

依據GB/T 25000.10-2016國家標準，軟件產品質量模型見圖2：

圖2 軟件產品質量模型

按發現問題所屬質量特性統計，功能性問題372個，占比4.2%；性能效率問題19個，占比0.2%；信息安全性問題8547個，占比95.5%；其他質量特性委托檢測較少，共發現問題2個，占比忽略不計。

首輪測試后，測試人員將結果通知到開發方，經過修改后再進行二輪甚至三輪測試，復測后問題數量呈現明顯收斂趨勢。

2 軟件產品質量問題產生的原因分析

造成軟件缺陷的主要原因，主要有軟件本身、團隊工作和技術問題等，也與軟件產品的特點和開發過程有密切關系：

2.1 軟件本身

⊙ 需求不明確，設計方案偏離客戶需求，導致產品功能不符合客戶預期；

⊙ 系統結構復雜，系統維護困難；

⊙ 對程序邏輯路徑或數據范圍的邊界考慮欠缺，漏掉邊界條件，造成容量或邊界錯誤；

⊙ 實時應用要進行精心設計和技術處理以保證精確的時間同步，否則容易引起時間不協調問題；

⊙ 沒有考慮系統崩潰后的自我恢復或數據異地備份、災難恢復等問題，導致系統存在安全隱患；

⊙ 系統運行環境復雜，計算機環境千變萬化，用戶的各種操作方式或各種不同的輸入數據，容易引起一些特定用戶環境下的問題；

⊙ 系統應用中突發數據量引起的性能負載問題；

⊙ 通信端口多、存取和加密手段的矛盾性等，會造成系統的安全性或適用性等問題；

⊙ 新技術的采用或涉及系統兼容性問題，事先沒有考慮到。

2.2 團隊工作

（1）用戶溝通方面，需求分析時對客戶的需求理解出現偏差

要改進這個問題可以從以下四個方面展開：一是使用項目管理信息系統進行輔助溝通，例如：PMIS。二是建立溝通基礎結構：①工具：電話、傳真、電郵、PMIS；視頻會議系統、文件管理系統、字處理程序。②技術：指導方針、文檔模板、會議基本原則和程序；決策過程、解決問題方法、沖突解決和協商技術。③原則：提供開放式對話環境；使用“率直交流”和遵守公認工作道德規范。三是使用項目溝通模板。四是制定項目溝通基本原則。

（2）不同階段的開發人員相互理解不一致。

（3）設計或編程上的一些假定依賴關系，相關人員沒有充分溝通。

（4）項目成員技術水平差異導致代碼質量參差不齊。

2.3 技術問題

（1）算法錯誤：在給定條件下沒能給出正確或準確的結果。

（2）語法錯誤：對于編譯性語言程序，編譯器可以發現這類問題；但對于解釋性語言程序，只能在測試運行時發現。

（3）計算和精度問題：計算的結果沒有滿足所需要的精度。

（4）系統結構不合理、算法選擇不科學，造成系統性能低下。

（5）接口參數傳遞不匹配，導致模塊集成出現問題。

2.4 項目管理問題

（1）質量意識不足，沒有盡早介入測試，或測試不充分。

（2）開發周期短，需求分析、設計、編程、測試等各項工作不能完全按照流程進行，同時給開發人員造成太大壓力，引起一些人為錯誤。

（3）開發流程不完善，存在太多隨機性，缺乏嚴謹的內審或評審機制，容易產生問題。

（4）文檔不完善，風險估計不足等。

3 措施與建議

（1）制訂周詳的軟件開發計劃。要進行調查研究，理解工作任務、工作范圍和所付的代價，提交可行性研究報告，編制詳盡的軟件開發計劃。

（2）軟件需求分析，對用戶需求進行具體分析和細化，并用軟件需求規格說明書表達出來，作為用戶和軟件人員之間的共同約定。在進行需求調研時，不但要更多的獲取功能或者業務需求，對于客戶在軟件系統性能上的需求，也應進行詳盡的獲取。這些需求在實現過程中應具體體現在開發和測試等文檔中。針對此類性能需求的深入分析，往往能較好的規避軟件系統瓶頸，解決此問題，需要對需求進行全面有效的管理，可以按照以下辦法進行管理：

①成立需求分析小組，任務是得到各方簽字認可的需求說明書。

②準備文檔和幫助客戶了解相關技術和項目管理知識。

③訪談客戶：了解劃分客戶所有用戶類型及潛在類型；選擇每類用戶代表，對其訪談和調研；需求分析人員對收集的需求進行分析和整理；需求分析人員將需求以適當方式呈交用戶和開發方。

④需求分析：圖形表示方式描述整理結構，包括邊界和接口；通過原型、頁面流等方式向用戶提供可視化界面，用戶提出評價；系統可行性分析，需求實現的技術可行性、環境、費用、時間分析；模型描述系統功能項、數據實體、外部實體、實體相互關系、實體狀態轉換。

⑤需求說明書編寫。

⑥需求驗證和評審：確保說明書準確、完整變大必要的質量特點；用戶參與，可外部專家評審；一般評審：用戶評審、同行評審。

⑦需求定稿建立基線。

⑧管理和控制需求變更：手段：變更控制委員會、需求變更流程；委員會與項目風險承擔著協商。

尤其是針對變更的需求，在面對變更需求時，應該堅持以下原則：謹慎對待變更請求，盡量控制變更；高度重視需求變更；簽署變更控制的協議；在基線的基礎上，做好變更實施；應有變更控制工具的支持；把項目變化融入項目計劃；及時發布變更信息。

（3）軟件架構設計決定系統的模塊結構，應清晰給出模塊的相互調用關系、模塊間傳遞的數據以及每個模塊的功能說明，定義數據結構，軟件體系架構是為軟件系統提供結構、行為和屬性的高級抽象。在結構建模時應遵從最直觀的結構、以特殊問題為目的建立框架、對機構和框架進行補充，演化“大顆?！毙袨?、研究步驟和過程、一組功能構建，下層向上層提供服務。（4）軟件編碼應符合規范要求。

（5）軟件測試應盡早并全面介入，及時發現并修改缺陷，降低開發成本和周期。

（6）軟件維護，經過測試并應用的軟件仍可能有錯，用戶需求和系統環境也會隨時發生變化，開發時應考慮軟件可維護性。

（7）非功能性的需求很多時候需要考慮硬件以及網絡方面的成本。針對這些問題需要與客戶進行良好溝通，設定合理的非功能性目標，做好成本與質量的平衡。

（8）制訂完善的測試方案并貫徹落實，它直接影響軟件的質量。