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