試析軟件工程系統項目開發的質量控制

時間：2024-10-05 15:13:53 碩士論文我要投稿

試析軟件工程系統項目開發的質量控制

　　為達到質量要求所采取的作業技術和活動稱為質量控制。這就是說，質量控制是為了通過監視質量形成過程，消除質量環上所有階段引起不合格或不滿意效果的因素。以達到質量要求，獲取經濟效益，而采用的各種質量作業技術和活動。那么，軟件工程系統項目開發的質量控制有哪些方法呢?請看本文介紹。

　　論文摘要：依據GB/T16260<信息技術軟件產品評價質量特性及其使用指南》，結合某軟件工程的項目開發，通過過程質量控制，認識質量特性，選擇適當開發控制模型，對工作內容在質量控制方法、控制措施和控制流程的一點認識。

　　論文關鍵詞：質量控制內容方法措施

　　1 項目概況

　　整個工程項目要完成兩個系統的建設：

　　1.1 行政辦公自動化系統

　　行政辦公自動化系統基于WEB，采用B/S多層結構設計。以JAVA、JSP、XML、.NET等為核心編程技術。整個系統能夠充分保證數據的安全，可根據需要提供數字簽名、電子印章、加密驗證，保證系統安全。具有靈活的權限設置功能。系統能滿足長時間穩定運行的要求，具有高度容錯性，能夠為辦公提供科學高效的工作計劃管理和監督檢查功能及方便的數據收集查詢服務。同時提供高度的系統自適應性。

　　1.2 行政網站系統

　　本網站定位在電子政務門戶網站，其基本功能有：信息發布、對外宣傳、信息查詢、便民服務、網上辦事等。整個網站著重于先進性、實用性、安全性、可擴充性、兼容性、經濟性和科學性等原則。

　　2 軟件產品質量特性

　　軟件產品質量特性一般分6類：功能性、可靠性、易使用性、效率、可維護性和可移植性。

　　2.1 功能性

　　與一組功能及其指定的性質有關的一組屬性。這里的功能是指滿足明確或隱含的需求的那些功能。

　　2.2 可靠性

　　與在規定的一段時間和條件下，軟件維持其性能水平的能力有關的一組屬性。

　　2.3 易使用性

　　與一組規定或潛在的用戶為使用軟件所需作的努力和對這樣的使用所作的評價有關的一組屬性。

　　2.4 效率

　　與在規定的條件下，軟件的性能水平與所使用資源量之間關系有關的一組屬性。

　　2.5 可維護性

　　與進行指定的修改所需的努力有關的一組屬性。

　　2.6 可移植性

　　與軟件可從某一環境轉移到另一環境的能力有關的一組屬性。

　　3 軟件產品開發模型

　　軟件產品常用的開發模型有：瀑布模型(V模型、噴泉模型)、螺旋模型、原型模型(鋸齒模型、快速原型)、構件組裝模型(增量模型)、統一軟件過程RUP模型等。在實際開發不是使用單一模型，本項目中就使用了多模型的集合控制的方法。

　　4 質量控制工作內容、方法和措施

　　1.質量控制是項目開發過程的重點，開發過程中的質量控制是把好質量關的重要一環。質量工程師必須熟悉設計方案，熟悉施工規范、軟件規范和質量驗收規范。

　　2.在本項目開發中，質量人員應采用軟件工程的思想，對所開發的軟件、系統、網站進行一系列的軟件測試。

　　3.軟件測試是在一定控制的條件下，圍繞一個系統或應用的操作并且評價其結果(一個最簡單的例子：如果用戶使用硬件A，在應用接口B上做了操作C，那么結果D應當出現)，控制的條件應當包括正常和異常的條件。測試企圖使事情變得很糟糕，從而來檢測出一些應當發生而沒有發生，或者不應當發生而發生的事情。

　　4.關于如何安排QA和測試的任務時，不同的承包方變化是很大的。有時它們可以有一個組或一個人來負責，共同的是一個項目組混合了測試人員和開發人員，并且他們一起緊密的工作，而QA過程有項目經理來監督。所有這些是同承包方的大小和商業結構有關的。在本項目中，質量人員會與承包方南京擎天科技有限公司進行充分的溝通，確認他們在軟件開發中慣用的測試組織和測試手段，并力圖將質量人員的質量行動和軟件質量意圖滲透到整個項目的開發過程中去。

　　5.本項目中可能出現問題或者缺陷的來源：

　　(1)缺乏或者沒有進行溝通，如對于一些我們在開發過程中應當或者不應當實現的細節問題。

　　(2)軟件復雜度—— 在當今的軟件開發中，對于一些沒有經驗的人來說，軟件復雜性可能是難以理解的。圖形化界面，客戶/服務器和分布式的應用，數據通信，大規模的關系數據庫，應用程序的規模等指數般的增加了軟件的復雜度。面向對象技術也有可能增加軟件復雜度，除非能夠被很好的工程化。

　　(3)編程錯誤——任何一個編程人員都可能產生錯誤。

　　(4)不斷變更的需求——用戶可能不知道變更的影響，或者知道影響卻還是需要進行變更，這些會引起重新設計與重新安排，并對其它項目產生影響，使已完成的工作可能不得不重做或推翻，硬件需求可能也會受到影響。如果存在許多小的變更或者任何大的改動，由于項目中不同部分間可知和不可知的依賴關系，這樣就會產生問題，跟蹤變更的復雜性也可能引入錯誤。項目開發人員的積極性也會受到打擊。在這種情況下，質量人員必須了解結果的風險，必須適應和計劃進行大規模的測試來防止不可避免的BUG出現無法控制的局面。

　　(5)時間的壓力——軟件項目的時間安排是最難的，通常是需要很多猜測的工作。當最后期限來臨的時候，錯誤也就伴隨發生了。

　　(6)缺乏文檔的代碼——維護和修改很差的代碼或缺乏文檔的代碼是很困難的。最終結果將導致BUG的出現。

　　(7)軟件開發工具——視圖工具，類庫，編譯器，腳本工具等等通常會把它們自身的BUG 引入到本項目中。

　　6.質量人員視情況應該實施的測試類型：

　　(1)黑盒測試— —不是基于內部代碼和設計的知識，而是基于需求和功能。

　　(2)白盒測試——基于應用程序的內部邏輯的知識，通過語句，分支，路徑和條件的覆蓋率。

　　(3)單元測試——測試中的最小單位，測試特殊的功能或代碼模塊。由于需要對內部代碼和設計的詳細知識，該測試一般由開發者完成而不是由質量人員完成。該測試的容易程度同代碼設計的好壞直接相關。

　　(4)增量型的集成測試——隨著新功能的增加，不斷的對應用程序進行測試。在程序的所有部分完成之前，需要一個應用程序的各個部分之間能夠相對獨立的進行工作。這類型測試可以由開發者或質量人員完成。

　　(5)集成測試—一測試應用程序結合的部分來確定它們的功能結合到一起是正確的。在這里‘部分’的概念可能是代碼模塊，獨立的應用程序，在網絡上的客戶端和服務器斷程序等等。這類型測試典型的是于客戶/服務器和分布式系統相關。這類測試通常應該由開發者在質量人員的指導和監督下完成。

　　(6)功能測試—— 是一種黑盒測試，同應用程序的功能需求緊密相關。這類型測試應當由質量人員來完成。這并不意味著開發人員在發布版本之前就不需要檢查他們的代碼。

　　(7)端到端測試— — 同系統測試類似，包括模擬現實世界對一個完整的應用環境進行測試。例如同數據庫進行交互、使用網絡通信，或者其他的軟件、硬件和系統進行交互。這類測試通常應該由開發者在質量人員的指導和監督下完成。在某些情況下，可以和某些測試合并進行。

　　(8)理智測試——這是一種典型的原始測試，其目的是要確定一個新的軟件版本在一些主要的測試努力下表現的足夠好并且可以接受。例如：如果一個OA軟件每五分鐘當機一次，使系統執行速度極其緩慢，或者破壞系統數據，那么該軟件就處于不夠‘理智’狀態，必須保證在當前狀態下進行進一步測試。

　　(9)可接受性測試—～基于最終用戶的規格進行的最后測試。或者基于最終用戶在一定的時間范圍內的測試。

　　(10)壓力測試——該術語通常同負荷測試和性能測試是可交換的。也可用于描述這樣一些測試，如：在不正常的負荷狀態下，過分的重復某些動作或輸人情況下進行的系統功能測試。

　　(11)安裝和反安裝測試——測試完全、部分或升級的安裝/反安裝過程。

　　(12)安全性測試——測試系統對于內部和外部非法人侵、故意損壞時的表現情況。可能需要復雜的測試技術。

　　(13)兼容性測試——測試系統在不同的平臺/硬件/操作系統/網絡上的表現情況。

　　7.質量人員或者承包方軟件測試人員執行軟件測試需要執行的步驟：

　　(1)獲取需求、功能設計、詳細設計規格和其他必須文檔;

　　(2)獲取預算和時間安排需求;

　　(3)確定項目相關人員和他們的責任，匯報需求，必須的標準和過程(如版本過程、變更過程等);

　　(4)確認應用高風險的部分，設定優先級，確定測試的范圍和限制;

　　(5)確定測試的方法——單元測試、集成測試、功能測試、負荷測試、可用性測試等;

　　(6)確定環境需求(軟件/硬件/通信等);

　　(7)確定測試用具環境(記錄/回放工具、覆蓋率分析器、測試跟蹤、問題跟蹤等等);

　　(8)確定測試輸入需求;

　　(9)確定任務，任務責任和相應的工作量;

　　(10)設定時間安排估計、時間表、里程碑等;

　　(11)確定輸入的等價類、邊界值分析、錯誤類;

　　(12)準備測試計劃文檔和需要的評審;

　　(13)寫測試用例;

　　(14)對測試用例進行必須的評審;

　　(15)準備測試環境和測試用具，獲取需要的用戶手冊/參考文檔/配置指導/安裝指導，建立跟蹤過程，日志和存檔過程，獲取測試數據;

　　(16)獲取和安裝軟件版本;

　　(17)執行測試;

　　(18)評價和匯報測試結果;

　　(19)跟蹤問題和修改;

　　(20)如果需要進行再測試;

　　(21)在整個生命周期內維護和修改測試計劃、測試用例、測試環境和測試用具。

　　8.本項目因為采用了WEB開發技術，因此還需要進行特定于WEB開發的軟件測試。其控制方法及措施：

　　(1)功能測試

　　a)鏈接測試.b)表單測試;c)Cookies測試;d)設計語言測試;e)數據庫測試

　　(2)性能測試

　　a)連接速度測試.b)負載測試;c)壓力測試

　　(3)可用性測試

　　a)導航測試Ib)圖形測試;c)內容測試;d)整體界面測試

　　(4)客戶端兼容性測試

　　a)平臺測試.b)瀏覽器測試

　　(5)安全性測試以上質量控制過程中所描述的任何測試和流程，并不意味應該完全由質量人員完成。在大多數情況下，質量人員只需要審核承包方的開發人員或者測試人員的測試計劃和測試結果報告。承包方的開發人員和測試人員應該自行完成上述測試和流程，并向質量人員提交詳細的計劃和報告，等待質量人員復核和簽認。

　　5 結語

　　質量管理可以說是一個企業、一個項目的關鍵命脈，質量控制隨著數字化、信息化的技術革命其模式已發生結構性變化，本文觀點是對近幾年的在軟件開發項目質量工作總結的淺見。

　　參考文獻(略)

【試析軟件工程系統項目開發的質量控制】相關文章：

淺探軟件工程系統項目開發的質量控制11-21

工程項目合同管理系統的分析與開發論文03-03

相關推薦