試析軟件工程系統項目開(kāi)發(fā)的質(zhì)量控制
為達到質(zhì)量要求所采取的作業(yè)技術(shù)和活動(dòng)稱(chēng)為質(zhì)量控制。這就是說(shuō)，質(zhì)量控制是為了通過(guò)監視質(zhì)量形成過(guò)程，消除質(zhì)量環(huán)上所有階段引起不合格或不滿(mǎn)意效果的因素。以達到質(zhì)量要求，獲取經(jīng)濟效益，而采用的各種質(zhì)量作業(yè)技術(shù)和活動(dòng)。那么，軟件工程系統項目開(kāi)發(fā)的質(zhì)量控制有哪些方法呢?請看本文介紹。
論文摘要：依據GB/T16260<信息技術(shù)軟件產(chǎn)品評價(jià)質(zhì)量特性及其使用指南》，結合某軟件工程的項目開(kāi)發(fā)，通過(guò)過(guò)程質(zhì)量控制，認識質(zhì)量特性，選擇適當開(kāi)發(fā)控制模型，對工作內容在質(zhì)量控制方法、控制措施和控制流程的一點(diǎn)認識。
論文關(guān)鍵詞：質(zhì)量控制 內容 方法 措施
1 項目概況
整個(gè)工程項目要完成兩個(gè)系統的建設：
1.1 行政辦公自動(dòng)化系統
行政辦公自動(dòng)化系統基于WEB，采用B/S多層結構設計。以JAVA、JSP、XML、.NET等為核心編程技術(shù)。整個(gè)系統能夠充分保證數據的安全，可根據需要提供數字簽名、電子印章、加密驗證，保證系統安全。具有靈活的權限設置功能。系統能滿(mǎn)足長(cháng)時(shí)間穩定運行的要求，具有高度容錯性，能夠為辦公提供科學(xué)高效的工作計劃管理和監督檢查功能及方便的數據收集查詢(xún)服務(wù)。同時(shí)提供高度的系統自適應性。
1.2 行政網(wǎng)站系統
本網(wǎng)站定位在電子政務(wù)門(mén)戶(hù)網(wǎng)站，其基本功能有：信息發(fā)布、對外宣傳、信息查詢(xún)、便民服務(wù)、網(wǎng)上辦事等。整個(gè)網(wǎng)站著(zhù)重于先進(jìn)性、實(shí)用性、安全性、可擴充性、兼容性、經(jīng)濟性和科學(xué)性等原則。
2 軟件產(chǎn)品質(zhì)量特性
軟件產(chǎn)品質(zhì)量特性一般分6類(lèi)：功能性、可靠性、易使用性、效率、可維護性和可移植性。
2.1 功能性
與一組功能及其指定的性質(zhì)有關(guān)的一組屬性。這里的功能是指滿(mǎn)足明確或隱含的需求的那些功能。
2.2 可靠性
與在規定的一段時(shí)間和條件下，軟件維持其性能水平的能力有關(guān)的一組屬性。
2.3 易使用性
與一組規定或潛在的用戶(hù)為使用軟件所需作的努力和對這樣的使用所作的評價(jià)有關(guān)的一組屬性。
2.4 效率
與在規定的條件下，軟件的性能水平與所使用資源量之間關(guān)系有關(guān)的一組屬性。
2.5 可維護性
與進(jìn)行指定的修改所需的努力有關(guān)的一組屬性。
2.6 可移植性
與軟件可從某一環(huán)境轉移到另一環(huán)境的能力有關(guān)的一組屬性。
3 軟件產(chǎn)品開(kāi)發(fā)模型
軟件產(chǎn)品常用的開(kāi)發(fā)模型有：瀑布模型(V模型、噴泉模型)、螺旋模型、原型模型(鋸齒模型、快速原型)、構件組裝模型(增量模型)、統一軟件過(guò)程RUP模型等。在實(shí)際開(kāi)發(fā)不是使用單一模型，本項目中就使用了多模型的集合控制的方法。
4 質(zhì)量控制工作內容、方法和措施
1.質(zhì)量控制是項目開(kāi)發(fā)過(guò)程的重點(diǎn)，開(kāi)發(fā)過(guò)程中的質(zhì)量控制是把好質(zhì)量關(guān)的重要一環(huán)。質(zhì)量工程師必須熟悉設計方案，熟悉施工規范、軟件規范和質(zhì)量驗收規范。
2.在本項目開(kāi)發(fā)中，質(zhì)量人員應采用軟件工程的思想，對所開(kāi)發(fā)的軟件、系統、網(wǎng)站進(jìn)行一系列的軟件測試。
3.軟件測試是在一定控制的條件下，圍繞一個(gè)系統或應用的操作并且評價(jià)其結果(一個(gè)最簡(jiǎn)單的例子：如果用戶(hù)使用硬件A，在應用接口B上做了操作C，那么結果D應當出現)，控制的條件應當包括正常和異常的條件。測試企圖使事情變得很糟糕，從而來(lái)檢測出一些應當發(fā)生而沒(méi)有發(fā)生，或者不應當發(fā)生而發(fā)生的事情。
4.關(guān)于如何安排QA和測試的任務(wù)時(shí)，不同的承包方變化是很大的。有時(shí)它們可以有一個(gè)組或一個(gè)人來(lái)負責，共同的是一個(gè)項目組混合了測試人員和開(kāi)發(fā)人員，并且他們一起緊密的工作，而QA過(guò)程有項目經(jīng)理來(lái)監督。所有這些是同承包方的大小和商業(yè)結構有關(guān)的。在本項目中，質(zhì)量人員會(huì )與承包方南京擎天科技有限公司進(jìn)行充分的溝通，確認他們在軟件開(kāi)發(fā)中慣用的測試組織和測試手段，并力圖將質(zhì)量人員的質(zhì)量行動(dòng)和軟件質(zhì)量意圖滲透到整個(gè)項目的開(kāi)發(fā)過(guò)程中去。
5.本項目中可能出現問(wèn)題或者缺陷的來(lái)源：
(1)缺乏或者沒(méi)有進(jìn)行溝通，如對于一些我們在開(kāi)發(fā)過(guò)程中應當或者不應當實(shí)現的細節問(wèn)題。
(2)軟件復雜度—— 在當今的軟件開(kāi)發(fā)中，對于一些沒(méi)有經(jīng)驗的人來(lái)說(shuō)，軟件復雜性可能是難以理解的。圖形化界面，客戶(hù)/服務(wù)器和分布式的應用，數據通信，大規模的關(guān)系數據庫，應用程序的規模等指數般的增加了軟件的復雜度。面向對象技術(shù)也有可能增加軟件復雜度，除非能夠被很好的工程化。
(3)編程錯誤——任何一個(gè)編程人員都可能產(chǎn)生錯誤。
(4)不斷變更的需求——用戶(hù)可能不知道變更的影響，或者知道影響卻還是需要進(jìn)行變更，這些會(huì )引起重新設計與重新安排，并對其它項目產(chǎn)生影響，使已完成的工作可能不得不重做或推翻，硬件需求可能也會(huì )受到影響。如果存在許多小的變更或者任何大的改動(dòng)，由于項目中不同部分間可知和不可知的依賴(lài)關(guān)系，這樣就會(huì )產(chǎn)生問(wèn)題，跟蹤變更的復雜性也可能引入錯誤。項目開(kāi)發(fā)人員的積極性也會(huì )受到打擊。在這種情況下，質(zhì)量人員必須了解結果的風(fēng)險，必須適應和計劃進(jìn)行大規模的測試來(lái)防止不可避免的BUG出現無(wú)法控制的局面。
(5)時(shí)間的壓力——軟件項目的時(shí)間安排是最難的，通常是需要很多猜測的工作。當最后期限來(lái)臨的時(shí)候，錯誤也就伴隨發(fā)生了。
(6)缺乏文檔的代碼——維護和修改很差的代碼或缺乏文檔的代碼是很困難的。最終結果將導致BUG的出現。
(7)軟件開(kāi)發(fā)工具——視圖工具，類(lèi)庫，編譯器，腳本工具等等通常會(huì )把它們自身的BUG 引入到本項目中。
6.質(zhì)量人員視情況應該實(shí)施的測試類(lèi)型：
(1)黑盒測試— —不是基于內部代碼和設計的知識，而是基于需求和功能。
(2)白盒測試——基于應用程序的內部邏輯的知識，通過(guò)語(yǔ)句，分支，路徑和條件的覆蓋率。
(3)單元測試——測試中的最小單位，測試特殊的功能或代碼模塊。由于需要對內部代碼和設計的詳細知識，該測試一般由開(kāi)發(fā)者完成而不是由質(zhì)量人員完成。該測試的容易程度同代碼設計的好壞直接相關(guān)。
(4)增量型的集成測試——隨著(zhù)新功能的增加，不斷的對應用程序進(jìn)行測試。在程序的所有部分完成之前，需要一個(gè)應用程序的各個(gè)部分之間能夠相對獨立的進(jìn)行工作。這類(lèi)型測試可以由開(kāi)發(fā)者或質(zhì)量人員完成。
(5)集成測試—一測試應用程序結合的部分來(lái)確定它們的功能結合到一起是正確的。在這里‘部分’的概念可能是代碼模塊，獨立的應用程序，在網(wǎng)絡(luò )上的客戶(hù)端和服務(wù)器斷程序等等。這類(lèi)型測試典型的是于客戶(hù)/服務(wù)器和分布式系統相關(guān)。這類(lèi)測試通常應該由開(kāi)發(fā)者在質(zhì)量人員的指導和監督下完成。
(6)功能測試—— 是一種黑盒測試，同應用程序的功能需求緊密相關(guān)。這類(lèi)型測試應當由質(zhì)量人員來(lái)完成。這并不意味著(zhù)開(kāi)發(fā)人員在發(fā)布版本之前就不需要檢查他們的代碼。
(7)端到端測試— — 同系統測試類(lèi)似，包括模擬現實(shí)世界對一個(gè)完整的應用環(huán)境進(jìn)行測試。例如同數據庫進(jìn)行交互、使用網(wǎng)絡(luò )通信，或者其他的軟件、硬件和系統進(jìn)行交互。這類(lèi)測試通常應該由開(kāi)發(fā)者在質(zhì)量人員的指導和監督下完成。在某些情況下，可以和某些測試合并進(jìn)行。
(8)理智測試——這是一種典型的原始測試，其目的是要確定一個(gè)新的軟件版本在一些主要的測試努力下表現的足夠好并且可以接受。例如：如果一個(gè)OA軟件每五分鐘當機一次，使系統執行速度極其緩慢，或者破壞系統數據，那么該軟件就處于不夠‘理智’狀態(tài)，必須保證在當前狀態(tài)下進(jìn)行進(jìn)一步測試。
(9)可接受性測試—～基于最終用戶(hù)的規格進(jìn)行的最后測試�；蛘呋谧罱K用戶(hù)在一定的時(shí)間范圍內的測試。
(10)壓力測試——該術(shù)語(yǔ)通常同負荷測試和性能測試是可交換的。也可用于描述這樣一些測試，如：在不正常的負荷狀態(tài)下，過(guò)分的重復某些動(dòng)作或輸人情況下進(jìn)行的系統功能測試。
(11)安裝和反安裝測試——測試完全、部分或升級的安裝/反安裝過(guò)程。
(12)安全性測試——測試系統對于內部和外部非法人侵、故意損壞時(shí)的表現情況�？赡苄枰獜碗s的測試技術(shù)。
(13)兼容性測試——測試系統在不同的平臺/硬件/操作系統/網(wǎng)絡(luò )上的表現情況。
7.質(zhì)量人員或者承包方軟件測試人員執行軟件測試需要執行的步驟：
(1)獲取需求、功能設計、詳細設計規格和其他必須文檔;
(2)獲取預算和時(shí)間安排需求;
(3)確定項目相關(guān)人員和他們的責任，匯報需求，必須的標準和過(guò)程(如版本過(guò)程、變更過(guò)程等);
(4)確認應用高風(fēng)險的部分，設定優(yōu)先級，確定測試的范圍和限制;
(5)確定測試的方法——單元測試、集成測試、功能測試、負荷測試、可用性測試等;
(6)確定環(huán)境需求(軟件/硬件/通信等);
(7)確定測試用具環(huán)境(記錄/回放工具、覆蓋率分析器、測試跟蹤、問(wèn)題跟蹤等等);
(8)確定測試輸入需求;
(9)確定任務(wù)，任務(wù)責任和相應的工作量;
(10)設定時(shí)間安排估計、時(shí)間表、里程碑等;
(11)確定輸入的等價(jià)類(lèi)、邊界值分析、錯誤類(lèi);
(12)準備測試計劃文檔和需要的評審;
(13)寫(xiě)測試用例;
(14)對測試用例進(jìn)行必須的評審;
(15)準備測試環(huán)境和測試用具，獲取需要的用戶(hù)手冊/參考文檔/配置指導/安裝指導，建立跟蹤過(guò)程，日志和存檔過(guò)程，獲取測試數據;
(16)獲取和安裝軟件版本;
(17)執行測試;
(18)評價(jià)和匯報測試結果;
(19)跟蹤問(wèn)題和修改;
(20)如果需要進(jìn)行再測試;
(21)在整個(gè)生命周期內維護和修改測試計劃、測試用例、測試環(huán)境和測試用具。
8.本項目因為采用了WEB開(kāi)發(fā)技術(shù)，因此還需要進(jìn)行特定于WEB開(kāi)發(fā)的軟件測試。其控制方法及措施：
(1)功能測試
a)鏈接測試.b)表單測試;c)Cookies測試;d)設計語(yǔ)言測試;e)數據庫測試
(2)性能測試
a)連接速度測試.b)負載測試;c)壓力測試
(3)可用性測試
a)導航測試Ib)圖形測試;c)內容測試;d)整體界面測試
(4)客戶(hù)端兼容性測試
a)平臺測試.b)瀏覽器測試
(5)安全性測試以上質(zhì)量控制過(guò)程中所描述的任何測試和流程，并不意味應該完全由質(zhì)量人員完成。在大多數情況下，質(zhì)量人員只需要審核承包方的開(kāi)發(fā)人員或者測試人員的測試計劃和測試結果報告。承包方的開(kāi)發(fā)人員和測試人員應該自行完成上述測試和流程，并向質(zhì)量人員提交詳細的計劃和報告，等待質(zhì)量人員復核和簽認。
5 結語(yǔ)
質(zhì)量管理可以說(shuō)是一個(gè)企業(yè)、一個(gè)項目的關(guān)鍵命脈，質(zhì)量控制隨著(zhù)數字化、信息化的技術(shù)革命其模式已發(fā)生結構性變化，本文觀(guān)點(diǎn)是對近幾年的在軟件開(kāi)發(fā)項目質(zhì)量工作總結的淺見(jiàn)。
參考文獻(略)
【試析軟件工程系統項目開(kāi)發(fā)的質(zhì)量控制】相關(guān)文章：
淺探軟件工程系統項目開(kāi)發(fā)的質(zhì)量控制11-21
試析建筑工程機電安裝質(zhì)量控制12-07
房地產(chǎn)開(kāi)發(fā)項目成本控制11-21
試析企業(yè)外包風(fēng)險控制11-15
試析家庭系統的“價(jià)值倫理”03-07
試析基于軟件歷史信息的軟件工程12-06
試析應收賬款內部控制的探討12-04
工程項目合同管理系統的分析與開(kāi)發(fā)論文03-03
- 相關(guān)推薦