項目軟件測試流程與規(guī)范

1、XXXX測試組XXX項目軟件流程與測試規(guī)范目錄一、項目軟件流程與測試人員工作范圍51、項目軟件流程階段52、測試人員工作范圍53、相關(guān)名詞解釋6二、業(yè)務(wù)需求階段61、考核指標62、本階段工作流程63、本階段具體做法74、參考經(jīng)驗7三、業(yè)務(wù)需求與驗收測試設(shè)計71、考核指標72、本階段工作流程83、本階段具體做法84、參考經(jīng)驗8四、業(yè)務(wù)需求分析與系統(tǒng)設(shè)計81、考核指標82、本階段工作流程83、本階段具體做法94、參考經(jīng)驗9五、需求理解、系統(tǒng)設(shè)計與確認、系統(tǒng)測試設(shè)計91、考核指標92、本階段工作流程93、本階段具體做法104、參考經(jīng)驗10六、概要設(shè)計101、考核指標102、本階段工作流程103、本階

2、段具體做法114、參考經(jīng)驗11七、概要設(shè)計與集成測試設(shè)計111、考核指標112、本階段工作流程123、本階段具體做法124、參考經(jīng)驗12八、詳細設(shè)計階段141、考核指標142、本階段工作流程143、本階段具體做法144、參考經(jīng)驗14九、詳細設(shè)計與單元測試設(shè)計151、考核指標152、本階段工作流程153、本階段具體做法154、參考經(jīng)驗15十、單元測試151、考核指標152、本階段工作流程153、本階段具體做法154、參考經(jīng)驗16十一、集成161、考核指標162、本階段工作流程163、本階段具體做法164、參考經(jīng)驗16十二、集成測試171、考核指標172、本階段工作流程173、本階段具體做法184

3、、參考經(jīng)驗18十三、實施階段211、考核指標212、本階段工作流程213、本階段具體做法214、參考經(jīng)驗21十四、確認測試與系統(tǒng)測試221、考核指標222、本階段工作流程223、本階段具體做法224、參考經(jīng)驗22十五、交付231、考核指標232、本階段工作流程233、本階段具體做法234、參考經(jīng)驗23十六、驗收測試階段241、考核指標242、本階段工作流程243、本階段具體做法244、參考經(jīng)驗24一、項目軟件流程與測試人員工作范圍1、項目軟件流程階段XXX項目，目前采用的項目流程，主要有以下階段一、理解業(yè)務(wù)需求階段(立項)；二、業(yè)務(wù)需求與驗收測試設(shè)計階段；三、需求分析與系統(tǒng)設(shè)計；四、需求分析、

4、系統(tǒng)設(shè)計與確認、系統(tǒng)測試設(shè)計；五、概要設(shè)計；六、概要設(shè)計與基礎(chǔ)測試設(shè)計；七、詳細設(shè)計八、詳細設(shè)計與單元測試設(shè)計；九、編碼；十、單元測試；十一、集成；十二、集成測試；十三、實施；十四、確認測試與系統(tǒng)測試；十五、交付；十六、驗收測試；2、測試人員工作范圍一、理解業(yè)務(wù)需求；二、編寫相關(guān)業(yè)務(wù)文檔；三、編寫相關(guān)測試文檔；四、參與項目會議并整理會議記錄；五、參與項目設(shè)計；六、制定測試計劃與測試方案；七、編寫測試用例；八、執(zhí)行測試；九、驗證項目問題十、提交測試報告十一、版本推廣；十二、版本后續(xù)維護3、相關(guān)名詞解釋業(yè)務(wù)需求說明書：依據(jù)項目需求為藍本，將項目需求整理成冊，為項目其他文檔母本，為編碼工作的業(yè)務(wù)指導(dǎo)

5、文檔系統(tǒng)規(guī)格書：依據(jù)業(yè)務(wù)需求說明書，規(guī)定需求實現(xiàn)的邏輯與流程，以及涉及的表結(jié)構(gòu)、字段類型，囊括模塊流程圖、模塊之間的關(guān)系、業(yè)務(wù)流程說明、實現(xiàn)過程、數(shù)據(jù)表等關(guān)鍵要素。軟件需求說明書：以簡練、準確、無歧義描述語言，描述軟件需求，是軟件測試的關(guān)鍵文檔，也是編寫測試列表、測試案例的基礎(chǔ)文檔。模測問題：模擬生產(chǎn)環(huán)境測試過程中所發(fā)現(xiàn)的項目軟件缺陷或者功能沒有實現(xiàn)等問題。生產(chǎn)問題：生產(chǎn)環(huán)境中業(yè)務(wù)人員發(fā)現(xiàn)的項目軟件缺陷或者功能沒有實現(xiàn)等問題靜態(tài)問題：項目文檔中，錯誤或者不規(guī)范的流程圖、不合理、錯誤或者的描述等體現(xiàn)在文檔中的問題。有效問題：測試問題提出后，經(jīng)過編碼人員修改，最終被修改驗證通過的問題。二、業(yè)務(wù)需求

6、階段1、考核指標業(yè)務(wù)需求理解處于項目立項階段，需求理解的程度將直接影響后續(xù)階段。本階段考核指標將體現(xiàn)在后續(xù)階段中：編寫項目相關(guān)文檔的質(zhì)量、測試的執(zhí)行力、程序派錯率、遺漏的問題數(shù)等。2、本階段工作流程1業(yè)務(wù)部門在生產(chǎn)過程中面向XX客戶提出的使用需求，整理成書面文檔，匯總后將需求提交至XXX，同時提出軟件功能需求。2XXX從全國各業(yè)務(wù)部門(含海外地區(qū))上報的需求，下發(fā)XXX所屬的各研發(fā)部。3各研發(fā)部從XXX領(lǐng)取項目任務(wù)4框架構(gòu)建人員與編碼人員理解業(yè)務(wù)需求，可通過調(diào)研、會議、郵件、涵的方式。3、本階段具體做法參與需求研討會，理解業(yè)務(wù)需求4、參考經(jīng)驗業(yè)務(wù)部門提出的需求共有兩種：對現(xiàn)有系統(tǒng)功能的改造；提

7、出新的業(yè)務(wù)功能要求。對于現(xiàn)有功能的改造需求理解：在熟悉現(xiàn)有業(yè)務(wù)功能的基礎(chǔ)上，針對改造的內(nèi)容，預(yù)估涉及改造的功能模塊；系統(tǒng)現(xiàn)有框架或?qū)崿F(xiàn)方式不會做大的改動，從會議討論中可以發(fā)現(xiàn)本次改造的重點與難點；區(qū)分出重點與難點之后，其他功能完全可以自我理解。對于現(xiàn)有功能改造的需求理解，建立在對現(xiàn)有系統(tǒng)的理解的基礎(chǔ)上。新進人員對系統(tǒng)的熟悉程度可以向項目組其他成員請教。對于新的業(yè)務(wù)需求：需求理解研討會上仔細做筆記，搞清每一個功能模塊的輸入與輸出，以達到對業(yè)務(wù)流程以及實現(xiàn)過程的精確把握；對于不理解或無把握之處提出自己的有效問題或者建議，恰恰體現(xiàn)出認真思考的工作態(tài)度。整理需求研討會議紀要，可以試著自己設(shè)計業(yè)務(wù)功能的

8、框架與實現(xiàn)過程，比較架構(gòu)辦的預(yù)案，縮小差距，提高自身需求理解的程度。三、業(yè)務(wù)需求與驗收測試設(shè)計1、考核指標系統(tǒng)軟件的質(zhì)量：體現(xiàn)業(yè)務(wù)需求理解的程度，也體現(xiàn)在驗收測試設(shè)計中。驗收結(jié)果達不到預(yù)期值將從根本上決定考核指標。風險程度：項目參與人員的技術(shù)成熟度、穩(wěn)定性、溝通能力、工時額度、人員或部門的配合度。驗收測試對業(yè)務(wù)需求的覆蓋率。2、本階段工作流程參與需求研討會，間接參與驗收測試設(shè)計，預(yù)估項目風險3、本階段具體做法1參與需求研討會：對于業(yè)務(wù)部門提出的需求，逐字逐句理解并把握，否定無效需求。2間接參與驗收測試設(shè)計3預(yù)估項目風險4、參考經(jīng)驗1參與需求研討會：同上。2間接參與驗收測試設(shè)計。集成測試與系統(tǒng)測

9、試階段不體現(xiàn)項目軟件驗收工作，但是集成測試與系統(tǒng)測試范圍必須涵蓋業(yè)務(wù)需求范圍，包含直接劃定的業(yè)務(wù)范圍與相關(guān)聯(lián)的業(yè)務(wù)范圍。本階段可以參考集成測試階段。3預(yù)估項目風險：積極參與項目的組織結(jié)構(gòu)、平時注意業(yè)務(wù)經(jīng)驗與技能的積累，并保持長期性與穩(wěn)定性；對項目進度的不合理安排提出自己的建議。四、業(yè)務(wù)需求分析與系統(tǒng)設(shè)計1、考核指標1業(yè)務(wù)需求理解程度：同上。2系統(tǒng)設(shè)計合理性、可行性：合理性、可行性程度將直接影響項目后續(xù)階段。3靜態(tài)問題：體現(xiàn)在系統(tǒng)規(guī)格書文檔中靜態(tài)測試問題個數(shù)。2、本階段工作流程1參與項目需求的理解。2參與業(yè)務(wù)需求的理解。3參與項目系統(tǒng)規(guī)格書的編寫與修改。3、本階段具體做法1參與項目需求的理解：同

10、上。2參與業(yè)務(wù)需求的理解：依據(jù)項目需求，整理并歸納業(yè)務(wù)需求。3項目系統(tǒng)規(guī)格書：以業(yè)務(wù)需求為依據(jù)，按照一定的格式編寫或者修改系統(tǒng)規(guī)格數(shù)。4、參考經(jīng)驗2參與業(yè)務(wù)需求理解：根據(jù)歷次會議討論結(jié)果和會議紀要，拆分或整合項目需求，整理完畢的業(yè)務(wù)需求說明書必須包含項目需求的所有內(nèi)容和隱含內(nèi)容，為系統(tǒng)規(guī)格數(shù)編寫或者修改的依據(jù)。3系統(tǒng)規(guī)格書編寫與修改：熟練使用相關(guān)的流程圖工具，如VISO等，在理解業(yè)務(wù)流程、業(yè)務(wù)邏輯、涉及的表結(jié)構(gòu)、字段等基礎(chǔ)上進行規(guī)格書的編寫與修改。系統(tǒng)規(guī)格書有固定的格式，有模板共參考。理解業(yè)務(wù)流程與業(yè)務(wù)邏輯可以向框架人員或者編碼人員進行溝通，也可以根據(jù)自己的理解或者會議討論結(jié)果、紀要進行；涉及

11、的表結(jié)構(gòu)、字段可向項目編碼人員所取，對于新建表、更新表等操作，要要根據(jù)業(yè)務(wù)功能注意表之間的關(guān)聯(lián)。五、需求理解、系統(tǒng)設(shè)計與確認、系統(tǒng)測試設(shè)計1、考核指標系統(tǒng)設(shè)計：系統(tǒng)設(shè)計對業(yè)務(wù)需求功能覆蓋率、合理程度、界面友好、操作便利性等。2、本階段工作流程集成測試人員偶爾參與系統(tǒng)設(shè)計3、本階段具體做法1對于修改現(xiàn)有功能的業(yè)務(wù)需求類，可以向編碼人員展示現(xiàn)有功能的實現(xiàn)過程、邏輯復(fù)雜性、參數(shù)設(shè)計合理性、GUI資源等。2對于全新的業(yè)務(wù)需求類，可以向編碼人員建議類似的業(yè)務(wù)實現(xiàn)過程。4、參考經(jīng)驗1修改現(xiàn)有功能的業(yè)務(wù)需求類：在頁面展示上類似于增加字段，后臺數(shù)據(jù)表增加對應(yīng)字段類型等改造。業(yè)務(wù)流程基本不會發(fā)生質(zhì)的改變。測試人

12、員可以先熟悉現(xiàn)有功能模塊的菜單位置、圖形界面，以數(shù)據(jù)驅(qū)動、業(yè)務(wù)驅(qū)動或者后臺數(shù)據(jù)查看的方式掌握現(xiàn)有的業(yè)務(wù)功能。2全新的業(yè)務(wù)需求類：XX現(xiàn)有的業(yè)務(wù)實現(xiàn)過程基本為申請簽批臺帳，這是業(yè)務(wù)的主要流程，針對不同的業(yè)務(wù)類型只是表現(xiàn)為菜單位置不同，實現(xiàn)過程大同小異，測試人員可以從大體流程上把握新需求的實現(xiàn)過程，不至于茫然而無從下手。六、概要設(shè)計1、考核指標1靜態(tài)測試問題：體現(xiàn)在軟件需求說明書中的文檔問題。2、項目需求與產(chǎn)品雙向追溯：產(chǎn)品功能點與項目軟需契合程度。2、本階段工作流程1業(yè)務(wù)需求的討論。2非業(yè)務(wù)需求的討論。3編寫或修改軟件需求說明書。4評審需求要點并參與設(shè)置需求實現(xiàn)優(yōu)先級。5制定項目需求與產(chǎn)品雙向追

13、溯表。3、本階段具體做法2非業(yè)務(wù)需求討論：與本次項目需求相關(guān)但無須本次項目中實現(xiàn)的需求、本次項目關(guān)聯(lián)的其他業(yè)務(wù)需求，對相關(guān)的業(yè)務(wù)類型進行列舉，并討論有效解決方案。3編寫或修改軟件需求說明書：依據(jù)系統(tǒng)規(guī)格書進行。4依據(jù)模塊重要性、關(guān)鍵路徑對其他模塊影響程度設(shè)置需求實現(xiàn)優(yōu)先級。5項目需求與產(chǎn)品雙向追溯表：實現(xiàn)項目需求與產(chǎn)品功能的對照關(guān)系。4、參考經(jīng)驗2非業(yè)務(wù)需求的討論：可以列舉本次業(yè)務(wù)實現(xiàn)過程中對其他業(yè)務(wù)類型所產(chǎn)生的影響，比如下游系統(tǒng)的數(shù)據(jù)需求、數(shù)據(jù)移行、接口參數(shù)等；其他相關(guān)聯(lián)的業(yè)務(wù)實現(xiàn)；此項需要較豐富的業(yè)務(wù)知識?？傊稽c：和本次項目相關(guān)的，都可以納入到討論的范圍。3軟件需求說明書。嚴格按照系統(tǒng)規(guī)

14、格書進行編寫。與系統(tǒng)規(guī)格書格式不一致，提供模板?；疽貫椋耗K編號、模塊名稱、功能概括、角色、運行條件、輸入字段、輸出字段、約束關(guān)系、頁面截圖、業(yè)務(wù)功能詳述等，并注意文檔排版與美觀。其中業(yè)務(wù)功能為重點，詳細闡述本功能模塊實現(xiàn)的功能點，描述無別字、錯字，表述要清晰、準確、無冗余，否則屬于靜態(tài)測試問題。軟件需求說明書與系統(tǒng)規(guī)格書在表述內(nèi)容上要嚴格保持一致。軟件需求說明書修改要根據(jù)相關(guān)會議討論結(jié)果，并確認有修改必要后再行修改。4設(shè)置需求實現(xiàn)優(yōu)先級：測試人員參與此項工作有助于了解模塊的關(guān)鍵程度，實施測試時可以先測試高優(yōu)先級模塊。有利于提高測試效率，同時也能有效把握測試進度。5項目需求與產(chǎn)品雙向追溯表

15、：檢測產(chǎn)品功能列表是否全部體現(xiàn)出項目需求，可以有效控制項目需求的遺漏和冗余，高于項目需求或者低于項目需求都有可能存在缺陷。七、概要設(shè)計與集成測試設(shè)計1、考核指標1項目測試列表：測試列表中所涉及的功能模塊的覆蓋率直接影響測試案例的覆蓋率，進而影響軟件測試質(zhì)量。2項目測試計劃：體現(xiàn)測試工作量、測試時間與測試進度控制，進而影響測試質(zhì)量。3項目測試方案：體現(xiàn)測試工具、測試順序與測試倫次，進而影響測試效率。4項目測試案例：測試執(zhí)行的依據(jù)，直接體現(xiàn)了功能模塊的測試覆蓋率。2、本階段工作流程1編寫項目測試列表。2編寫項目測試計劃。3編寫項目測試方案。4編寫項目測試案例。3、本階段具體做法1編寫項目測試列表。

16、包含要素：模塊名稱、變更類型、接口、測試案例分支、模塊重要性、計劃編寫案例數(shù)、實際編寫案例數(shù)、測試人員、測試結(jié)論等。2編寫項目測試計劃。包含要素：項目簡介、測試目標、測試環(huán)境、工作量、人力資源要素、測試時間與進度、風險等。3編寫項目測試方案。包含要素：環(huán)境、參數(shù)、數(shù)據(jù)準備、測試工具、測試列表、測試順序與倫次等。4編寫項目測試案例。包含要素：模塊名稱、模塊功能描述、測試案例分支、測試用例、預(yù)期結(jié)果、測試人員、用例預(yù)期執(zhí)行時間、用例測試通過時間、問題數(shù)、問題號等。4、參考經(jīng)驗1編寫項目測試列表。以軟件需求說明書為藍本，此文檔作用基本為列出本次項目所實現(xiàn)的功能點，編寫此文檔時，可以拷貝軟件需求說明書

17、中的業(yè)務(wù)功能詳述部分，進行修改，加入模塊或者是字段之間的約束關(guān)系，整合在一起，即：編寫項目測試列表即要體現(xiàn)所有的功能點，也要體現(xiàn)模塊與模塊、字段與字段之間的約束關(guān)系?？梢蕴峁┠０骞﹨⒖几袷?，并注意整個文檔的排版與可讀性。，2編寫項目測試計劃。對項目進行簡單介紹、說明測試工作應(yīng)該達到的預(yù)期目標(問題或缺陷閉環(huán)率100%)，體現(xiàn)測試工作所處的軟硬件環(huán)境、預(yù)期的工作量、測試參與人員與QA、一定時間段內(nèi)的應(yīng)達的測試進度、測試風險。其中：測試進度依據(jù)測試時間來制定并嚴格執(zhí)行，否則，規(guī)定的時間內(nèi)完不成測試任務(wù)；測試風險考慮參與測試的人員的技術(shù)成熟度、穩(wěn)定性、積極性、編碼人員修改問題的實效性、配合力度，或者

18、其他相關(guān)部門、個人對提供直接數(shù)據(jù)的依賴程度。風險一般是客觀存在的風險。3編寫項目測試方案。體現(xiàn)測試工執(zhí)行中的測試工作、測試順序和倫次等測試策略。測試環(huán)境體現(xiàn)了軟件版本安裝路徑、訪問地址、測試列表、所需的軟硬件要求等；參數(shù)部分體現(xiàn)了軟硬件參數(shù)、環(huán)境參數(shù)、數(shù)據(jù)交互接口、DSR配置以及參數(shù)失效的錯誤碼等；測試工具，目前主要采用黑盒手工測試，自動化測試工具很少使用，輔助測試工具主要有：Rational缺陷管理工具、數(shù)據(jù)庫管理工具、抓圖工具、歸并沖突管理工具等；測試列表同上；順序與倫次，按照業(yè)務(wù)流程與關(guān)鍵路徑對功能模塊進行排序，確定測試順序，一般的做法是抓住主要的業(yè)務(wù)流程，其他模塊可以放在后面進行細測，

19、比如參數(shù)設(shè)置的模塊。測試倫次原則上是至少兩輪，第一論對項目中的所有模塊進行細致的測試，第二論主要是對第一論測試中缺陷較多的模塊進行測試，同時應(yīng)注意的是，確認對于修改后的問題不會引起其他的問題，或者修改后的問題在新版本中確認修改測試通過。4編寫項目測試案例。功能模塊名稱：體現(xiàn)在軟件需求說明書中；變更類型：是指當前測試的模塊是改造后的模塊還是新做的模塊；接口：模塊與模塊之間數(shù)據(jù)交互需要相關(guān)接口，或者是系統(tǒng)與其他系統(tǒng)中數(shù)據(jù)交互也需要接口，接口的名稱與具體參數(shù)在系統(tǒng)規(guī)格書中有詳細的描述；壓力：是否需要進行壓力測試，如終端多用戶同時登陸等，目前在XX手工黑盒手工測試過程中較少使用；模塊的重要性：關(guān)鍵路徑

20、模塊應(yīng)擺放重點測試的地位應(yīng)體現(xiàn)該模塊在整個業(yè)務(wù)流程中的重要性，模塊的重要性依據(jù)業(yè)務(wù)流程與業(yè)務(wù)功能而定；案例分支紀要：在測試列表中體現(xiàn)；測試用例：依據(jù)分支紀要逐條設(shè)計測試案例(測試用例)，可依據(jù)因果關(guān)系分析法、等價類劃分、邊界值等測試理論進行設(shè)計測試案例，測試案例力求詳細，應(yīng)該覆蓋所有程序分支，這里體現(xiàn)了軟件需求說明書與歷次會議紀要等注意點的積累。描述語言力求準確，不建議案例重復(fù)。有意思的是，錯誤的數(shù)據(jù)輸入也是測試的常用方法；期望結(jié)果：與軟件需求說明書、系統(tǒng)規(guī)格書、項目軟需保持一致或是與邏輯保持一致。測試用例的設(shè)計基本單位是，一個用例驗證一個功能點，比如驗證短期流動資金貸款合同申請完畢后保存成功

21、所展示的提示資源，可以這樣設(shè)計用例：做一筆短期流程資金業(yè)務(wù)，必輸項輸入完畢后點擊“保存”按鈕，查看提示信息。該用例的預(yù)期結(jié)果是：頁面提示該筆業(yè)務(wù)合同保存成功。從上面的用例我們能看到的要素為：是短期流動資金業(yè)務(wù)，做的是申請操作，必輸項體現(xiàn)基本輸入數(shù)據(jù)，數(shù)據(jù)輸入完畢后的操作，最后才是測試目的，目的體現(xiàn)了測試的功能點。至于如何輸入數(shù)據(jù)、數(shù)據(jù)之間的約束關(guān)系、如何驗證數(shù)據(jù)保存后后臺數(shù)據(jù)表與前臺頁面輸入的是否一致、保存不成功的異常處理方式，則體現(xiàn)在上條或者下條測試用例中；預(yù)期測試結(jié)果：依據(jù)軟件需求說明書或者系統(tǒng)規(guī)格書業(yè)務(wù)模塊功能描述中模塊所實現(xiàn)的作用，最為最終測試結(jié)果。若測試結(jié)果與以往的經(jīng)驗不相符和，以軟

22、需和規(guī)格書為準。因為業(yè)務(wù)需求是變化的，特別是改造的模塊，先前的業(yè)務(wù)所實現(xiàn)功能有可能在本次項目中實行另外一套標準；測試人員：測試過程中執(zhí)行測試用例的人員，測試用例設(shè)計者與執(zhí)行者可能不是同一個人，這樣就要求在設(shè)計測試用例時注意用例的可行性、可讀性、易操作、規(guī)范。用例預(yù)期執(zhí)行時間：根據(jù)測試的整體時間、項目的功能點數(shù)、業(yè)務(wù)流程的復(fù)雜性、模塊之間的關(guān)系、關(guān)鍵路徑等制定用例的執(zhí)行時間。用例預(yù)期執(zhí)行時間體現(xiàn)對整個測試進度的控制，測試人員應(yīng)該合理安排整體進度，并盡量在預(yù)期時間之前執(zhí)行本用例，避免其他突發(fā)因素影響案例的執(zhí)行，從而導(dǎo)致進度滯后，比如本模塊的數(shù)據(jù)之源出現(xiàn)問題；用例通過時間：本條測試用例測試通過的時間

23、，但是不是最終測試通過時間，只是體現(xiàn)了當前時間段內(nèi)測試通過，應(yīng)該注意其他模塊修改后對本模塊是否存在影響。最終通過時間一般為測試結(jié)束時間，這時所有問題閉環(huán)；問題數(shù)：執(zhí)行該條用例時所發(fā)現(xiàn)的問題或者缺陷的數(shù)量；問題號：取自Rational中對應(yīng)問題的ID。在項目測試結(jié)束時，案例全部測試通過。5從上面的闡述中，我們能發(fā)現(xiàn)下面的對應(yīng)關(guān)系：軟件需求說明書細化了系統(tǒng)規(guī)格書的內(nèi)容；測試案例細化了測試列表；測試方案與測試計劃體現(xiàn)了測試過程的整體控制。八、詳細設(shè)計階段1、考核指標靜態(tài)測試問題：在項目軟件詳細設(shè)計過程中發(fā)現(xiàn)的系統(tǒng)規(guī)格書或者軟件需求說明書錯誤之處。2、本階段工作流程1修改系統(tǒng)規(guī)格書。2修改軟件需求說明

24、書。3、本階段具體做法1修改系統(tǒng)規(guī)格書：根據(jù)編碼人員或者框架人員所發(fā)現(xiàn)的問題修改系統(tǒng)規(guī)格書。2修改軟件需求說明書：同上。4、參考經(jīng)驗1修改系統(tǒng)規(guī)格書：可以通過項目例會、咨詢編碼人員、咨詢框架人員，弄清問題所在，修改系統(tǒng)規(guī)格書的對應(yīng)之處。同時應(yīng)考慮修改的地方對其他模塊的影響程度，即：符合前一個模塊的輸出與下一個模塊的輸入。2修改軟件需求說明書。同上。九、詳細設(shè)計與單元測試設(shè)計1、考核指標2、本階段工作流程1編寫程序規(guī)格書。2制定代碼設(shè)計曲線。3制定代碼檢查計劃。3、本階段具體做法目前測試人員較少參與該階段工作。4、參考經(jīng)驗十、單元測試1、考核指標2、本階段工作流程1編碼人員自測3、本階段具體做法

25、1偶爾協(xié)助編碼人員準備自測數(shù)據(jù)。4、參考經(jīng)驗1協(xié)助編碼人員準備自測數(shù)據(jù)：可以利用數(shù)據(jù)庫現(xiàn)有數(shù)據(jù)、可以直接操作后臺數(shù)據(jù)表，比如修改字段值等等。十一、集成1、考核指標2、本階段工作流程1評審測試計劃。2評審測試方案。3評審測試案例。4測試準備。3、本階段具體做法1評審測試計劃：項目例會方式評審。2評審測試方案：項目例會方式評審。3評審測試案例：項目例會方式評審。4數(shù)據(jù)準備：測試數(shù)據(jù)。5環(huán)境準備：軟硬件環(huán)境。6相關(guān)文檔：學(xué)習文檔、技術(shù)文檔、日志等。4、參考經(jīng)驗1評審測試計劃：由計劃制定人主持例會，闡述計劃制定的依據(jù)，項目組其他人員評審計劃是否可行，存在異議之處以會議紀要的方式確認下來，并由計劃制定人

26、更新到測試計劃中，備案。2評審測試方案：同評審測試計劃。3評審測試案例：同評審測試計劃。4數(shù)據(jù)準備。常用的支行、柜員、客戶，相關(guān)參數(shù)，這些數(shù)據(jù)可以在平時工作中注意積累。這里提到的數(shù)據(jù)，要素比較全面、可用性比較高，這樣在測試執(zhí)行過程中可以起到事半功倍的效果。5環(huán)境準備。包括軟硬件環(huán)境。硬件方面：處理器、內(nèi)存、顯卡顯存、硬盤轉(zhuǎn)速是否達到測試所需；軟件方面：測試工具是否正常使用、數(shù)據(jù)庫工具是否可用、IE版本是否符合要求、系統(tǒng)補丁是否齊全、IE設(shè)置是否正確、操作系統(tǒng)語言版本、防火墻是否阻斷通訊、最新程序數(shù)否更新到測試環(huán)境等等。6相關(guān)文檔。各個項目文檔是否最新版本、各個項目文檔是否評審?fù)ㄟ^。十二、集成測

27、試1、考核指標1集成測試有效問題數(shù)：在集成測試過程中發(fā)現(xiàn)的有效問題數(shù)，目前XX制定的4%，即：百功能點要發(fā)現(xiàn)至少四個有效問題。比如，XX2008年7月份版本所有項目的總功能點為10000，則在缺陷管理工具中至少體現(xiàn)400個以上有效問題并全部解決，才符合版本出口條件。4為季度版本中所有項目的均值。2靜態(tài)問題數(shù)：相關(guān)項目文檔所體現(xiàn)的靜態(tài)問題。3問題驗證的實效性。XX制定的規(guī)范：當前狀態(tài)為自己手中的問題要在兩個工作日之內(nèi)驗證完畢。2、本階段工作流程1集成測試執(zhí)行。2提交集成測試問題。3驗證集成測試問題。4更新測試案例。5分析缺陷分布。6統(tǒng)計集成測試問題數(shù)量。3、本階段具體做法1集成測試：嚴格依據(jù)軟件

28、需求說明書進行集成測試。2提交集成測試問題：按照一定的程序、規(guī)定的方式在指定的缺陷管理工具中提交問題。3驗證集成測試問題：該問題狀態(tài)為“修改完成，待確認”狀態(tài)時進行問題驗證。4更新測試案例：提交測試問題后，根據(jù)問題內(nèi)容對應(yīng)到具體的案例中5分析缺陷分布：根據(jù)問題所在功能模塊，概算問題分布，以確認回裝驗證重點。6統(tǒng)計集成測試問題數(shù)量：貫穿在測試過程中，可以及時更改測試方法或者測試深度。4、參考經(jīng)驗1集成測試：1）深入了解軟件需求說明書并嚴格按照軟件需求說明書的業(yè)務(wù)流程進行集成測試工作。軟需是測試人員進行測試的最直接的項目文檔，軟需當中體現(xiàn)了基本的業(yè)務(wù)流程與業(yè)務(wù)邏輯。執(zhí)行測試的過程中依據(jù)軟需當中的每

29、一段文字、每一個判定、每一種業(yè)務(wù)條件組織測試用例，功能模塊最終的驗證結(jié)果與軟需描述完全保持一致才能說明該模塊測試通過。軟需的編寫一般是按照業(yè)務(wù)流程或者是業(yè)務(wù)邏輯進行編寫的，所以一般也間接決定了執(zhí)行測試的功能模塊順序。XX現(xiàn)場一般采用的測試方法是按照軟需的描述一步步進行驗證。但是，即使在規(guī)范的條件約束下，軟需的描述語言在不同編碼人員的編寫下，有一定的不一致，這種情況下，我們需要從自身理解的業(yè)務(wù)需求來判斷軟需的功能描述是否正確，若存在不一致之處，及時與相關(guān)人員進行溝通，經(jīng)過確認之后在對該模塊進行測試。值得注意的是，模塊與模塊之間的關(guān)聯(lián)性非常重要，如果是一個人執(zhí)行整個業(yè)務(wù)的測試，會注意模塊之間的相互

30、影響；如果復(fù)雜的業(yè)務(wù)流程由多人負責不同的模塊進行測試，此時需要加強測試合作。簡單的做法是告訴其他人我需要什么樣的數(shù)據(jù)，或者請?zhí)峁┓蠝y試要求的數(shù)據(jù)，以便于更有利的發(fā)現(xiàn)問題并定位問題。測試的同時我們需要保持清醒的頭腦，多想想當前的模塊數(shù)據(jù)來源的多樣性與數(shù)據(jù)輸出的多樣性，此時宜采用發(fā)散思維。并注意一筆數(shù)據(jù)的復(fù)用，提高測試效率。同時，在測試過程中也思考，根據(jù)業(yè)務(wù)流程或者數(shù)據(jù)驅(qū)動的方式所發(fā)現(xiàn)的許多業(yè)務(wù)細節(jié)在軟需中是否已經(jīng)包含，往往這些細節(jié)在測試過程中是必須要執(zhí)行的。2）相關(guān)業(yè)務(wù)的表結(jié)構(gòu)請參考軟件需求說明書。測試過程中不可避免的要與后臺數(shù)據(jù)表進行接觸，熟練使用數(shù)據(jù)庫管理工具與精通各類表結(jié)構(gòu)在測試過程中會

31、給予很大的幫助，甚至為了測試業(yè)務(wù)的中間模塊，在業(yè)務(wù)流程存在瓶頸的情款下，我們可以直接操作后臺數(shù)據(jù)表。了解表結(jié)構(gòu)我們基本可以有如下好處：a查看前臺頁面展示與后臺數(shù)據(jù)表數(shù)據(jù)是否一致。b頁面保存或者修改數(shù)據(jù)后，后臺數(shù)據(jù)表是否更新并且更新結(jié)果與預(yù)期保持一致。c查看相關(guān)存儲過程，分解程序執(zhí)行的每一步，有利于白盒測試經(jīng)驗的積累。d直接修改相關(guān)表中字段，快速得到所需數(shù)據(jù)，特別在生產(chǎn)問題驗證等時間緊、任務(wù)重的測試工作中，免去了前臺頁面的許多環(huán)節(jié)。舉一個印象很深例子：在一個不上主機的國內(nèi)地區(qū)，做一筆國內(nèi)銀行保函修改申請的業(yè)務(wù)，這種測試需求在前臺頁面是根本沒有辦法實現(xiàn)的，而我們只需要修改一個表中一個字段值，就輕松

32、解決了。新進測試人員也不必感到恐慌，只要平時多加注意并養(yǎng)成經(jīng)驗積累的好習慣與保持良好的記憶，上述的操作是不難做到的。3）測試業(yè)務(wù)流程請參考系統(tǒng)規(guī)格書。系統(tǒng)規(guī)格書中對每一個模塊都會有一張易懂的流程圖，測試人員可以據(jù)圖了解業(yè)務(wù)的每一個分支，避免了分支的遺漏。我的理解是，系統(tǒng)規(guī)格書是對功能模塊的業(yè)務(wù)概述，可以有助于理解軟件需求說明書中難懂的語言邏輯，特別是在軟需不斷更新的情況下。同時，系統(tǒng)規(guī)格書中有業(yè)務(wù)所涉及的所有表名稱，這是軟需中所沒有的，而我們積累表名稱的來源也是系統(tǒng)規(guī)格書。建議的做法：將表名整理成冊并匹配簡單說明，你將成為數(shù)據(jù)高手，在他人需要幫助的情況下，輕松解決問題，是團隊合作的催化劑。4）

33、查看相關(guān)會議紀要。先期投入巨大時間與人力的項目例會，最終體現(xiàn)在集成測試階段。會議紀要點睛式的要點描述，更有助于提高測試覆蓋率，在測試的過程中注意紀要的要點，將會使測試更加完美。曾經(jīng)有這樣的經(jīng)歷：項目集成測試完畢后，我們在想，軟需與規(guī)格書上的所有要點我們都測試到了，會議紀要也測試到了，我們提出的問題相當有水平，我們會覺得測試是一個追求完美的工作，下一次會更加完美，就讓系統(tǒng)測試人員因發(fā)現(xiàn)不了高質(zhì)量的問題痛苦去吧。5）整個測試過程要高度關(guān)注測試時間。時間的寬裕是保證測試質(zhì)量的關(guān)鍵要素之一，關(guān)注時間要素可以有效調(diào)整測試進度，避免因時間分配不科學(xué)，導(dǎo)致有的模塊測試不充分。我們也常常遇到測試的有效時間被嚴

34、重擠壓的情況。這時我們需要先測試已經(jīng)開發(fā)完畢的模塊。先保證可以測試的模塊質(zhì)量，至于剩下的模塊開發(fā)進度，我們要和編碼人員保持不間斷的溝通，明確交付測試的時間。對于按期交付測試的模塊我們也可以通過把握時間，合理的安排測試進度，從而保證了測試質(zhì)量。6）測試過程中注意測試順序與測試倫次。測試的順序依據(jù)項目的不同存在差異，總之做到合理安排就可以，倫次一般采用不低于二倫的方式，第一論對所有的模塊進行功能測試，第二論對發(fā)現(xiàn)問題較多的模塊進行測試，或者是確認問題二次修改產(chǎn)生的影響。7）測試過程中養(yǎng)成良好的日志習慣。日志的格式不作統(tǒng)一，依據(jù)個人的習慣而進行。日志主要記錄了測試過程中使用的基礎(chǔ)數(shù)據(jù)，這對于我們驗證

35、問題時可以提供幫助，我們可以使用現(xiàn)有的數(shù)據(jù)來驗證問題，有時候不要重新做數(shù)據(jù)，一方面可以節(jié)省時間，另一方面避免了垃圾數(shù)據(jù)的產(chǎn)生，同時，我覺得記日志不光是只在測試過程中，對于其他的工作過程或者是生活中，隨時記錄有用的信息，重要性不言而喻。8）按照測試案例組織測試用例。測試用例在編寫過程中，記載了許多重要的或者容易被遺忘的用例。測試過程中時時回顧可以有效的避免用例的遺漏，這在緊張的測試過程中很重要的。9）測試過程中要保持積極性。積極性在測試過程中表現(xiàn)為熱情主動、高昂的工作狀態(tài)，同時，遇到困難也總是以積極的心態(tài)取客服，其高昂的工作情緒也能感染其他人。工作積極的工作者能給客戶信任感，相信沒有哪一個客戶愿

36、意把工作交給工作消極的人。10）與客戶有效溝通。溝通是使問題快速解決的方法之一。溝通的過程也是自我思想展示的表現(xiàn)。在溝通的過程中，我們需要把問題問的詳細一點、表達要準確一點，在繁忙的工作中，客戶不會花費很多的時間去了解你的問題，把握住要點很重要，以得到確認的答案為最終目標。溝通的方式多種多樣，我們需要掌握技巧，對客戶適當?shù)馁澝琅c表揚，可以拉近彼此的心理距離。態(tài)度要好一點，因為多數(shù)情況下我們在向客戶請教；耐心要大一點，不光是我們在向客戶詢問，客戶同時也會請教我們；對于耐性不好的客戶，我們的心態(tài)要堅強一點，不要因為暫時的受阻而放棄了下次問題的咨詢，從測試質(zhì)量來講，這是得不償失的。此時我們需要寬容的

37、心態(tài)，放棄前嫌，當作什么事情都沒有發(fā)生，這樣做不僅僅對客戶，對組內(nèi)的其他成員也試用，所謂的面子，不是別人給的，而是自己給自己的，也許這就是所謂的“得意淡然、失意夷然”吧。11）項目例會上，發(fā)言要積極。項目例會制度就是為了解決問題而設(shè)立的，有問題不在例會上解決，我們找不到更有效的解決途徑。同時，也沒有人因為你的問題淺顯而取笑，相反，會上更關(guān)注的是你積極參與的態(tài)度，說明了你認真思考。12）項目組舉辦的活動或者相關(guān)培訓(xùn)要積極參加?；顒优c培訓(xùn)是促進團隊合作的有效途徑，借助別人的經(jīng)驗進行原始的資本積累，更增進了人與人之間的合作的默契，這種默契應(yīng)用到工作中是寶貴的資源，測試工作需要這樣的默契與資本積累，可

38、以有效的環(huán)節(jié)工作的壓力并提供技能，進而提高測試工作的效率。在生活中也是一生受用。存在這樣的一種現(xiàn)象：很少或者從不參加活動或者培訓(xùn)的人，在工作和生活中往往是自閉的。2提交集成測試問題：在XX現(xiàn)場，問題不光是項目測試過程中發(fā)現(xiàn)的功能或者頁面資源的缺陷，也包含影響測試進度的問題，比如環(huán)境問題、或者項目版本問題。對于影響測試進度的問題，我們也可以提交到缺陷管理系統(tǒng)中，因為不解決它們會影響測試進度，這也是流程規(guī)定的。對于項目流程中的功能問題，一經(jīng)確認后，需要馬上提交到缺陷管理系統(tǒng) (Rational)中，簡單的缺陷直接判定，對于沒有把握的問題可以通過溝通確認。提交問題：一般采用簡要、準確、直觀的操作步驟

39、來定位問題所在，使編碼人員第一時間可以定位問題的原因。目前測試組在提交問題基本采用的要素有：所屬項目、功能模塊、問題相關(guān)人員、問題概述、緊急程度、嚴重程度、問題的詳細描述、操作步驟、問題的展示形式、復(fù)現(xiàn)率、期望的結(jié)果、測試數(shù)據(jù)，最后可以采用截圖或者文本進行進一步的描述。3驗證集成測試問題：目前XX對問題解決的實效性控制的比較嚴格，問題在自己手中不能超過兩天。問題的狀態(tài)有更新時，會通過郵件的形式自動通知去驗證問題。驗證之前要確認程序是否已經(jīng)更新到測試環(huán)境中。當問題的錯誤結(jié)果不再復(fù)現(xiàn)，則表示問題驗證通過，但是值得注意的是，不要影響了正常的功能模塊，同時置問題狀態(tài)為“修改確認通過”。對于驗證不通過的

40、問題，確認后堅決打回去，“修改確認不通過”，除非是在項目封版或者其他原因才可以置通過，這要和XX測試經(jīng)理確認。4更新測試案例：養(yǎng)成每天更新案例的良好習慣，通過案例的更新，可以把握時間，同時這也是XX測試經(jīng)理了解你工作進度的書面資料。5分析缺陷分布：缺陷分析操作，不僅僅在項目測試結(jié)束后，也體現(xiàn)在測試進程中，是質(zhì)量控制的一種方式。我們可以通過問題所屬的模塊，來統(tǒng)計缺陷的分布，把握測試重點；也可以通過問題的類型，來預(yù)估測試的質(zhì)量，取得測試在深度和廣度上是否達標的基本數(shù)據(jù)，有利于及時變換測試的方式：比如頁面資源類的問題較多，我們需要加深測試的力度與深度；如果業(yè)務(wù)邏輯或者流程中隱藏較深的問題較多，我們可以適當安排進行頁面資源的測試；同時，也可以更測分析出來的數(shù)據(jù)，進行人員的再分配。6統(tǒng)計集成測試問題數(shù)量：目前測試人員比較關(guān)注有效問題數(shù)，因為這直接關(guān)系著XX的考核，即：考核指標為4。對于已經(jīng)達到基準的項目，集成測試人員可以注重其他細節(jié)方面的測試；低于基準的項目，請加深測試力度，同時也請克服壓力，只要你努力了，會有好的結(jié)果，不妨改變測試的思路，或者繼續(xù)加深對業(yè)務(wù)的理解，或者改變測試方法，或者改變測試重點等等。十三、實施階段1、考核指標2、本階段工作流程集成測試人員較少參與本階段工作3、本階段具體做法4、參考經(jīng)驗十四、