A公司某財(cái)稅軟件開發(fā)項(xiàng)目質(zhì)量管理改進(jìn)方案設(shè)計(jì)案例目錄TOC\o"1-3"\h\u15590A公司某財(cái)稅軟件開發(fā)項(xiàng)目質(zhì)量管理改進(jìn)方案設(shè)計(jì)案例 1139051.1質(zhì)量改進(jìn)對(duì)策 175321.2A公司某財(cái)稅軟件需求階段改進(jìn) 2140111.2.1完善需求及UI的評(píng)審機(jī)制 2258201.2.2制定統(tǒng)一的UI設(shè)計(jì)規(guī)范 5313581.2.3增加需求的變更控制 6284061.2.4針對(duì)產(chǎn)品經(jīng)理定期內(nèi)部培訓(xùn) 7289701.3A公司某財(cái)稅軟件開發(fā)階段改進(jìn) 732431.3.1代碼規(guī)范管理 8207341.3.2代碼審核管理 820331.3.3規(guī)范自測(cè)制度 8158811.3.4針對(duì)開發(fā)人員定期內(nèi)部培訓(xùn) 958491.4A公司某財(cái)稅軟件測(cè)試階段改進(jìn) 9141581.4.1組建專業(yè)測(cè)試團(tuán)隊(duì) 9165631.4.2加強(qiáng)測(cè)試用例的評(píng)審機(jī)制 11250631.4.3加強(qiáng)測(cè)試文檔的管理 12質(zhì)量改進(jìn)對(duì)策根據(jù)第三及第四章節(jié)，本文通過對(duì)A公司某財(cái)稅軟件開發(fā)項(xiàng)目的現(xiàn)狀考察發(fā)現(xiàn)了其存在較多質(zhì)量管理問題，并對(duì)問題進(jìn)行了深入分析，本章將以全面質(zhì)量管理理念及PDCA方法論為指導(dǎo)，針對(duì)存在的問題及原因分析，提出一套適合于A公司某財(cái)稅軟件開發(fā)項(xiàng)目的質(zhì)量管理改進(jìn)方案。具體如下:（1）需求階段改進(jìn)在完成需求分析后，要做好需求確認(rèn)評(píng)審工作，以便避免即將交付的需求產(chǎn)生邏輯漏洞；一旦需求變更，要做好相應(yīng)的變更控制。確定質(zhì)量方針、目標(biāo)、明確責(zé)任人、評(píng)審計(jì)劃等，再根據(jù)PDCA，對(duì)需求變更方面進(jìn)行控制，確保需求質(zhì)量；針對(duì)對(duì)技術(shù)不熟悉以及專業(yè)水平較弱的產(chǎn)品經(jīng)理，定期組織內(nèi)部培訓(xùn)，從“源頭”進(jìn)行改進(jìn)。（2）開發(fā)階段改進(jìn)為了保證開發(fā)質(zhì)量，避免由于開發(fā)工程師個(gè)人的背景及經(jīng)歷原因?qū)е碌拇a個(gè)性化較重，從而造成的維護(hù)成本高的問題，公司內(nèi)部需要制定代碼規(guī)范管理制度，統(tǒng)一代碼管理；同時(shí)為了確保每位開發(fā)工程師的代碼質(zhì)量，需要制定代碼審核規(guī)范；為了避免不必要的后期缺陷及返工成本，加強(qiáng)開發(fā)工程師的自測(cè)管理；針對(duì)能力較弱的開發(fā)工程師，定期組織內(nèi)部培訓(xùn)，盡快提升人員素質(zhì)，確保開發(fā)質(zhì)量。（3）測(cè)試階段改進(jìn)從A公司的組織架構(gòu)可以看出，A公司缺乏專業(yè)的測(cè)試團(tuán)隊(duì)。而從第三章及第四章的內(nèi)容也可以發(fā)現(xiàn)，A公司某財(cái)稅軟件開發(fā)項(xiàng)目的測(cè)試階段由于缺乏專業(yè)的團(tuán)隊(duì)導(dǎo)致了測(cè)試不全面的問題。為了保證測(cè)試質(zhì)量，需要組建專業(yè)的測(cè)試團(tuán)隊(duì)。同時(shí)測(cè)試用例作為整體測(cè)試階段的重要依據(jù)，需要加強(qiáng)其在測(cè)試及驗(yàn)收階段的評(píng)審機(jī)制，保證測(cè)試用例的全面性、可靠性。在測(cè)試文檔方面，要加強(qiáng)文檔的管理，保證變更及時(shí)性。A公司某財(cái)稅軟件需求階段改進(jìn)需求分析是該項(xiàng)目的根本，能否滿足用戶的實(shí)際需求，能否長(zhǎng)遠(yuǎn)發(fā)展，直接關(guān)系到項(xiàng)目的成功與否。所以，通常情況下，需求部分是整個(gè)項(xiàng)目管理過程中的主要部分。如何保證需求分析的精準(zhǔn)及全面是A公司某財(cái)稅軟件開發(fā)項(xiàng)目的關(guān)鍵問題。需求階段的改進(jìn)主要體現(xiàn)在三個(gè)方面：需求的評(píng)審及跟進(jìn)、需求的變更流程以及人員的培訓(xùn)。完善需求及UI的評(píng)審機(jī)制根據(jù)第4章對(duì)A公司某財(cái)稅軟件開發(fā)項(xiàng)目分析可知，A公司某財(cái)稅軟件開發(fā)項(xiàng)目在需求分析的過程中，存在多種的問題，如需求分析不清、邏輯漏洞、變更頻繁、設(shè)計(jì)圖與原型圖不符等，這些問題會(huì)導(dǎo)致項(xiàng)目缺乏計(jì)劃性，導(dǎo)致成本增加、質(zhì)量降低?；诖?，要對(duì)輸出到開發(fā)階段的需求進(jìn)行嚴(yán)謹(jǐn)?shù)卦u(píng)審及跟進(jìn)，并從源頭上加強(qiáng)溝通，來杜絕掉需求變更頻繁、邏輯漏洞、原型圖不符等的情況。以此為依據(jù)，通過參考戰(zhàn)略合作公司項(xiàng)目開發(fā)過程中的需求評(píng)審及跟進(jìn)流程以及項(xiàng)目干系人之間的頭腦風(fēng)暴，對(duì)項(xiàng)目原需求分析與設(shè)計(jì)階段的流程圖進(jìn)行改進(jìn)，得到改進(jìn)后的需求分析與設(shè)計(jì)階段的流程圖，如圖5.1及圖5.2所示。圖5.1需求分析與設(shè)計(jì)階段原流程圖圖5.2需求分析與設(shè)計(jì)階段改進(jìn)流程圖在以上需求分析及設(shè)計(jì)流程中，主要針對(duì)需求收集方式及評(píng)審流程進(jìn)行了改進(jìn)。原需求收集階段主要是由產(chǎn)品經(jīng)理通過與客戶溝通或與實(shí)施組長(zhǎng)溝通，獲得需求后自行整理，并轉(zhuǎn)化為原型和文檔。改進(jìn)的需求收集是要遵循“三次握手”原則的，所謂“三次握手”原則，即是需求進(jìn)行反復(fù)確認(rèn)的過程，最終達(dá)到各方對(duì)需求全面精準(zhǔn)掌握的目的。在此次收集需求的過程中，主要是由產(chǎn)品經(jīng)理與客戶進(jìn)行面對(duì)面溝通，項(xiàng)目經(jīng)理旁聽，必要時(shí)需要有實(shí)施團(tuán)隊(duì)的組長(zhǎng)的參與。這樣就減少了對(duì)需求理解不到位或產(chǎn)生誤解的可能性，通過這種方式來盡量減少需求的變更頻率。而需求的評(píng)審也由原來的一次評(píng)審增加到三次。在原流程之中，需求與文檔同時(shí)準(zhǔn)備完成后進(jìn)行評(píng)審，之后直接交付設(shè)計(jì)團(tuán)隊(duì)進(jìn)行設(shè)計(jì)，產(chǎn)品經(jīng)理自行驗(yàn)收后交付開發(fā)團(tuán)隊(duì)；在評(píng)審過程中如果出現(xiàn)問題，再次修改后也無需二次確認(rèn)，可以直接交付設(shè)計(jì)團(tuán)隊(duì)。這樣會(huì)造成需求可能不全面、邏輯不夠完善及UI圖可能由于驗(yàn)收不仔細(xì)造成的與原型產(chǎn)生偏差的情況。改進(jìn)后的評(píng)審流程分為三輪，第一輪為原型初步完成時(shí)的評(píng)審，主要評(píng)審需求是否完善，由產(chǎn)品團(tuán)隊(duì)內(nèi)部召開，以此來評(píng)判整體的邏輯是否順暢。當(dāng)?shù)谝惠喸u(píng)審結(jié)束后，產(chǎn)品經(jīng)理開始撰寫對(duì)應(yīng)的需求文檔，同時(shí)可將原型文件交付設(shè)計(jì)團(tuán)隊(duì)進(jìn)行UI初版設(shè)計(jì)。需求文檔完成后進(jìn)行第二輪評(píng)審，此次評(píng)審的目的主要是對(duì)整體需求的細(xì)節(jié)是否到位、需求是否全面、邏輯是否暢通進(jìn)行評(píng)審。根據(jù)原型圖及需求文檔的內(nèi)容得到的最終版UI圖會(huì)在產(chǎn)品組內(nèi)部進(jìn)行第三次評(píng)審，以確保UI圖的風(fēng)格統(tǒng)一性及與原型的一致性。制定統(tǒng)一的UI設(shè)計(jì)規(guī)范A公司某財(cái)稅軟件由于其用戶需要長(zhǎng)時(shí)間在軟件上進(jìn)行工作的處理，諸如錄入憑證、沖銷存貨等，容易產(chǎn)生疲勞。因此軟件的界面需要簡(jiǎn)潔，同時(shí)色彩度不能像其他官方網(wǎng)站一樣采用明艷的色調(diào)，對(duì)舒適度要求較高。因此除了在5.2.1章節(jié)改進(jìn)的需求評(píng)審的流程中保障設(shè)計(jì)圖與原型圖的一致性以外，還需要制定一套統(tǒng)一的UI設(shè)計(jì)規(guī)范來提高質(zhì)量管理的效率。通過與設(shè)計(jì)部的主管進(jìn)行溝通，結(jié)合公司內(nèi)部其他項(xiàng)目的設(shè)計(jì)效果，制定統(tǒng)一規(guī)范方向：視覺與全局規(guī)則。視覺方向主要分為色彩、字體和圖標(biāo)，通過對(duì)主色、功能色、中性色的定義，規(guī)范整體項(xiàng)目的色彩范圍；通過對(duì)字體的字號(hào)、行高以及不同場(chǎng)景下的字體顏色、粗細(xì)的定義，以及設(shè)定圖標(biāo)的角半徑、比重、負(fù)空格，保證視覺的一致性。全局規(guī)則主要包括布局、按鈕、邊角、導(dǎo)航的設(shè)計(jì)規(guī)范，由于財(cái)稅軟件的表格內(nèi)容較多，因此對(duì)其進(jìn)行重點(diǎn)規(guī)范，保證界面的簡(jiǎn)潔。增加需求的變更控制雖然通過需求收集階段的控制手段可以盡量減少需求后期變更的發(fā)生，但針對(duì)敏捷型項(xiàng)目來說，需求變更不可避免。而且，因?yàn)槠髽I(yè)內(nèi)部文化原因，一旦領(lǐng)導(dǎo)提出建議，項(xiàng)目組可回旋的余地極小。根據(jù)以往項(xiàng)目經(jīng)驗(yàn)，一旦領(lǐng)導(dǎo)提出需求，最后基本都會(huì)增加到需求里，最終會(huì)造成需求的變更，進(jìn)而造成項(xiàng)目可能的延期，為了避免延期的發(fā)生，進(jìn)而收緊工期趕工，從而造成質(zhì)量問題。所以對(duì)于本次項(xiàng)目建設(shè)，制定了需求變更流程對(duì)需求變更進(jìn)行嚴(yán)格管控，如圖5.3所示。圖5.3需求變更控制流程圖需求變更可以由項(xiàng)目經(jīng)理、產(chǎn)品經(jīng)理、需求開發(fā)人員、設(shè)計(jì)人員或者用戶提出，發(fā)起方填寫變更申請(qǐng)單，給出需求描述與變更理由。需求變更提出后，交予項(xiàng)目經(jīng)理確認(rèn)，由項(xiàng)目經(jīng)理初步確定變更級(jí)別；對(duì)不可行的需求變更，由項(xiàng)目經(jīng)理、技術(shù)部、業(yè)務(wù)部門、專家組與提出變更者協(xié)商，取消變更請(qǐng)求。如果變更可行，項(xiàng)目經(jīng)理在《需求變更申請(qǐng)單》詳細(xì)描述變更理由及變更的影響范圍，并交由用戶進(jìn)行簽字確認(rèn)，確定最終變更需求，以防需求變更結(jié)果客戶否認(rèn)。需求一旦變更就意味著成本增加，所以必須通過高層確認(rèn)，項(xiàng)目管理辦公室(主要由公司高層組成)分析變更必要性和技術(shù)可行性并給出結(jié)論，批準(zhǔn)變更提交或拒絕。變更批復(fù)后，需要將變更部分納入需求文檔、同步更新項(xiàng)目相關(guān)文檔(包括設(shè)計(jì)文檔、測(cè)試文檔等)。如果變更可能導(dǎo)致項(xiàng)目進(jìn)度延期，將同步調(diào)整項(xiàng)目計(jì)劃。質(zhì)量管理員監(jiān)督變更實(shí)施過程并協(xié)助配置管理員對(duì)變更后的交付件進(jìn)行版本控制。針對(duì)產(chǎn)品經(jīng)理定期內(nèi)部培訓(xùn)主要針對(duì)產(chǎn)品經(jīng)理進(jìn)行一些簡(jiǎn)單的技術(shù)知識(shí)培訓(xùn)以及專業(yè)技能和業(yè)務(wù)知識(shí)分享。本項(xiàng)目的產(chǎn)品基本上對(duì)于技術(shù)知識(shí)沒有深入了解，甚至有些對(duì)于技術(shù)的一些基礎(chǔ)理論也沒有接觸過，這種情況會(huì)導(dǎo)致沒有技術(shù)經(jīng)驗(yàn)的產(chǎn)品經(jīng)理在進(jìn)行需求分析設(shè)計(jì)的時(shí)候，和開發(fā)溝通會(huì)產(chǎn)生一定的難度。一旦在需求溝通過程中出現(xiàn)了需求的溝通偏差，會(huì)造成返工或影響到最終產(chǎn)品的質(zhì)量。因此，對(duì)于一些完全沒有技術(shù)背景的產(chǎn)品經(jīng)理，要定期組織一些簡(jiǎn)單的培訓(xùn)課程或分享課程，同時(shí)推薦一些簡(jiǎn)單實(shí)用的技術(shù)類書籍，比如《寫給產(chǎn)品經(jīng)理的技術(shù)書》等。由于產(chǎn)品經(jīng)理的能力參差不齊，為了保障需求輸出的質(zhì)量，可以定期開展產(chǎn)品經(jīng)理的技能分享會(huì)，每周一次，進(jìn)行分享。從而達(dá)到互相督促，互相進(jìn)步，學(xué)以致用的目的。針對(duì)財(cái)稅軟件的業(yè)務(wù)特殊性，定期由財(cái)稅專家對(duì)產(chǎn)品經(jīng)理進(jìn)行培訓(xùn)及分享，以此保證產(chǎn)品經(jīng)理對(duì)于業(yè)務(wù)的熟知度，更好地理解客戶需求，進(jìn)行需求的設(shè)計(jì)。A公司某財(cái)稅軟件開發(fā)階段改進(jìn)軟件開發(fā)的過程是質(zhì)量保證的重點(diǎn)之一，加強(qiáng)研發(fā)過程中代碼的規(guī)范性和可讀性，加強(qiáng)代碼編程的質(zhì)量，提高開發(fā)效率。為實(shí)現(xiàn)此目標(biāo)，A公司某財(cái)稅軟件開發(fā)項(xiàng)目的軟件設(shè)計(jì)過程中，改進(jìn)內(nèi)容包括四項(xiàng)：明確和統(tǒng)一代碼編寫規(guī)范，提高代碼的規(guī)范性和可維護(hù)性；進(jìn)行代碼的審核管理；規(guī)范自測(cè)制度；針對(duì)開發(fā)人員進(jìn)行培訓(xùn)。代碼規(guī)范管理由于A公司某財(cái)稅軟件在開發(fā)過程中涉及的編程語(yǔ)言主要為PHP，因此在項(xiàng)目的開發(fā)團(tuán)隊(duì)內(nèi)部采用《PHP編碼規(guī)范》，為了滲透編碼標(biāo)準(zhǔn)，組織整體培訓(xùn)，確保開發(fā)人員對(duì)編碼規(guī)范的掌握。定期對(duì)開發(fā)人員培訓(xùn)和宣導(dǎo)代碼編寫規(guī)范和注釋規(guī)范，以確保開發(fā)團(tuán)隊(duì)統(tǒng)一的編碼規(guī)范，加強(qiáng)代碼規(guī)范性。在此過程中，要形成相應(yīng)的管理辦法對(duì)開發(fā)環(huán)節(jié)進(jìn)行質(zhì)量控制，對(duì)源碼進(jìn)行考核，建立健全的開發(fā)機(jī)制，降低開發(fā)人員個(gè)人素質(zhì)對(duì)項(xiàng)目的影響。精細(xì)化設(shè)計(jì)中的功能，討論和確定如何提高產(chǎn)品的質(zhì)量，除了強(qiáng)調(diào)功能、性能的高要求外，還要從安全性、可靠性、穩(wěn)定性、效率性、可維護(hù)性和易擴(kuò)展性等方面提出對(duì)軟件設(shè)計(jì)的質(zhì)量要求，結(jié)合A公司某財(cái)稅軟件開發(fā)項(xiàng)目的特性，由于涉及到的客戶票據(jù)量很大，隱私性較強(qiáng)，系統(tǒng)安全性和穩(wěn)定性尤其重要，分別從接口安全性、資源分配、算法邏輯等方面提出設(shè)計(jì)要求。代碼審核管理通過《PHP編碼規(guī)范》只能解決代碼規(guī)范一致性、提高代碼可讀性問題，為了提高軟件服務(wù)性能和軟件編碼水平，需要成立專門的代碼審核小組，負(fù)責(zé)對(duì)軟件開發(fā)工程師提交的代碼進(jìn)行審核，剔除不合理或者不恰當(dāng)?shù)拇a設(shè)計(jì)，提高代碼的健壯性，只有審核通過的代碼才會(huì)合并到測(cè)試分支進(jìn)行提測(cè)；為了更好的實(shí)現(xiàn)代碼審核小組的代碼審核工作，將代碼提交系統(tǒng)同OA進(jìn)行關(guān)聯(lián)，當(dāng)代碼進(jìn)行提交后，可以實(shí)時(shí)通知代碼審核小組的審核人員，讓代碼審核人員了解代碼的實(shí)時(shí)變化，并可以直接對(duì)代碼進(jìn)行審核評(píng)論，從而進(jìn)一步有效地控制代碼質(zhì)量。規(guī)范自測(cè)制度公司一直在倡導(dǎo)在軟件開發(fā)過程中即對(duì)軟件產(chǎn)品進(jìn)行檢查，盡早發(fā)現(xiàn)問題。對(duì)于軟件開發(fā)工程師而言，自測(cè)是一種必要的流程。通過交付測(cè)試團(tuán)隊(duì)前的自測(cè)，有一些隱藏的缺陷將會(huì)被軟件開發(fā)工程師發(fā)現(xiàn)。若是沒有經(jīng)過自測(cè)或者重視度不足，軟件開發(fā)工程師將這些項(xiàng)目提交測(cè)試階段后，會(huì)被負(fù)責(zé)該項(xiàng)目測(cè)試的軟件測(cè)試工程師發(fā)現(xiàn)并將其打回。通過在自測(cè)的過程中增加PDCA小循環(huán)，增加對(duì)軟件項(xiàng)目的自測(cè)執(zhí)行情況的確認(rèn)環(huán)節(jié)，則避免了軟件項(xiàng)目被反復(fù)打回提交的尷尬現(xiàn)象。對(duì)問題的跟蹤要不斷重復(fù)循環(huán)，注重測(cè)試的反饋和跟蹤，提高測(cè)試的執(zhí)行，從而達(dá)到持續(xù)提升和改進(jìn)產(chǎn)品質(zhì)量的過程。嚴(yán)格要求軟件開發(fā)工程師在完成對(duì)應(yīng)的項(xiàng)目模塊的開發(fā)工作后，需要對(duì)其所開發(fā)的項(xiàng)目模塊進(jìn)行完整的自測(cè)，從功能模塊級(jí)別上確保項(xiàng)目的功能正確性，并且可以通過自測(cè)引導(dǎo)實(shí)現(xiàn)更簡(jiǎn)潔、高效的軟件設(shè)計(jì)。只有經(jīng)過檢驗(yàn)的產(chǎn)品，才具有一定的質(zhì)量保證，通過軟件工程師的自測(cè)實(shí)現(xiàn)對(duì)項(xiàng)目質(zhì)量的保證。針對(duì)開發(fā)人員定期內(nèi)部培訓(xùn)通過第四章的問題分析已經(jīng)可以發(fā)現(xiàn)，本項(xiàng)目的開發(fā)團(tuán)隊(duì)中存在能力較弱的團(tuán)隊(duì)成員，由于自身能力的原因會(huì)出現(xiàn)所負(fù)責(zé)的模塊缺陷率較高的情況；同時(shí)也存在對(duì)于業(yè)務(wù)的熟知度較低的成員，為了幫助這兩種類型的團(tuán)隊(duì)成員快速成長(zhǎng)起來，避免后續(xù)的項(xiàng)目中重復(fù)出現(xiàn)由于人員問題導(dǎo)致的質(zhì)量問題，可以在內(nèi)部技術(shù)小組中組織定期“老員工”對(duì)“新員工”的專業(yè)技能培訓(xùn)?！袄蠁T工”溫故知新的同時(shí)帶動(dòng)“新員工”一起成長(zhǎng)，保證后續(xù)項(xiàng)目的產(chǎn)品質(zhì)量。同時(shí)定期組織業(yè)務(wù)培訓(xùn)會(huì)，保障每位相關(guān)的開發(fā)成員對(duì)于業(yè)務(wù)的熟知度，進(jìn)而保障產(chǎn)品質(zhì)量。A公司某財(cái)稅軟件測(cè)試階段改進(jìn)組建專業(yè)測(cè)試團(tuán)隊(duì)軟件測(cè)試是軟件產(chǎn)品校驗(yàn)及軟件質(zhì)量管理中極為重要的過程之一，其作用是識(shí)別并及時(shí)糾正產(chǎn)品中的問題和缺陷，最終交付質(zhì)量高、客戶認(rèn)可的軟件產(chǎn)品。在A公司某財(cái)稅軟件開發(fā)項(xiàng)目的軟件測(cè)試工作中，實(shí)施人員和產(chǎn)品人員“兼職”部分重要功能模塊的測(cè)試，但由于專業(yè)度不足以支撐，因此并不能得到最終質(zhì)量的保證。因此對(duì)于A公司某財(cái)稅軟件開發(fā)項(xiàng)目來說，首要任務(wù)是組建專業(yè)的測(cè)試團(tuán)隊(duì)，有專屬的測(cè)試人員對(duì)產(chǎn)品進(jìn)行測(cè)試和校驗(yàn)。測(cè)試團(tuán)隊(duì)包括客戶測(cè)試團(tuán)隊(duì)和項(xiàng)目測(cè)試團(tuán)隊(duì)，除了項(xiàng)目中開發(fā)人員的自測(cè)，項(xiàng)目測(cè)試團(tuán)隊(duì)的INT測(cè)試，客戶測(cè)試團(tuán)隊(duì)的UAT測(cè)試，同時(shí)項(xiàng)目中的產(chǎn)品經(jīng)理、開發(fā)人員也要參與并配合測(cè)試工作的進(jìn)行，以確保測(cè)試工作的高效性和全面性，測(cè)試工作角色及職責(zé)，詳見表5.1。表5.1工作角色職責(zé)表組織結(jié)構(gòu)角色職責(zé)項(xiàng)目測(cè)試組項(xiàng)目經(jīng)理跟進(jìn)測(cè)試進(jìn)度，協(xié)調(diào)測(cè)試人員與其他相關(guān)人員的工作，確保測(cè)試順利進(jìn)行客戶測(cè)試經(jīng)理監(jiān)控項(xiàng)目的測(cè)試進(jìn)度和測(cè)試管理工作，確保測(cè)試順利進(jìn)行軟件測(cè)試組項(xiàng)目組測(cè)試人員負(fù)責(zé)系統(tǒng)的整體測(cè)試工作；負(fù)責(zé)項(xiàng)目缺陷的匯總分析，并跟進(jìn)修復(fù)情況；編寫測(cè)試用例及最終測(cè)試報(bào)告客戶測(cè)試人員負(fù)責(zé)系統(tǒng)的UAT測(cè)試；對(duì)系統(tǒng)已實(shí)現(xiàn)的內(nèi)容與需求相比較，確保無偏差技術(shù)支持產(chǎn)品經(jīng)理在測(cè)試人員測(cè)試前及測(cè)試中提供需求確認(rèn)支持開發(fā)工程師在測(cè)試工作中提供技術(shù)方面的支持測(cè)試團(tuán)隊(duì)組建后，要針對(duì)不同階段采取不同的測(cè)試策略。（1）集成測(cè)試在完成單元測(cè)試后，便進(jìn)入集成測(cè)試階段。在公司的其他項(xiàng)目中，都是采用非增量式集成的方式，也就是把測(cè)試對(duì)象一次性打包，進(jìn)行整體測(cè)試。采用這種方式的優(yōu)點(diǎn)在于時(shí)間短，并且能有效發(fā)現(xiàn)測(cè)試中的問題，導(dǎo)致測(cè)試過程中問題的數(shù)量會(huì)逐漸增多。不過，由于測(cè)試范圍大，所以發(fā)現(xiàn)bug的幾率也大。所以，在這個(gè)階段經(jīng)常會(huì)多種多樣的問題，而且，存在定位bug不準(zhǔn)的問題。定位bug不準(zhǔn)也就不好修復(fù)bug，所以該方法導(dǎo)致集成測(cè)試質(zhì)量較低，測(cè)試成本較大。本次項(xiàng)目采用螺旋式模型，迭代開發(fā)頻繁，所以采用了增量式集成測(cè)試，逐步將已集成和未集成的模塊進(jìn)行打包測(cè)試，測(cè)試集成問題。QA組通過PDCA進(jìn)行管理，通過以下兩方面對(duì)集成測(cè)試過程進(jìn)行改進(jìn):1）非增量式集成測(cè)試逐步擴(kuò)大測(cè)試范圍，可以準(zhǔn)確定位bug、回歸測(cè)試，提高測(cè)試質(zhì)量;2）最大程度利用測(cè)試管理工具redmine，將其功能開發(fā)到極致，提升測(cè)試效率。（2）系統(tǒng)測(cè)試集成測(cè)試后，便進(jìn)入系統(tǒng)測(cè)試階段。系統(tǒng)測(cè)試相對(duì)而言就比較深入了，需要對(duì)需求有一定了解，所以，在項(xiàng)目建設(shè)的初期——需求分析與設(shè)計(jì)階段，就需要核心測(cè)試人員介入到項(xiàng)目中，同時(shí)由于A公司某財(cái)稅軟件開發(fā)項(xiàng)目的財(cái)稅專業(yè)性，需要對(duì)財(cái)稅相關(guān)知識(shí)有所了解，后續(xù)如果需要，需要適當(dāng)對(duì)測(cè)試人員進(jìn)行專業(yè)性培訓(xùn)。等待測(cè)試人員對(duì)項(xiàng)目的功能需求、性能要求等掌握后，再由該測(cè)試人員組織系統(tǒng)測(cè)試工作，檢驗(yàn)產(chǎn)品是否滿