軟件測試流程概述

1、軟件測試流程概述一、新產(chǎn)品或工程管理流程1、需求調(diào)研在軟件需求分析階段，測試人員從軟件生命周期的需求階段就開始介入在需求 階段的測試人員參與軟件需求調(diào)研，以測試角度分析需求的可測性，可構(gòu)思將來對其 測試的方法、原則等；同時全面了解系統(tǒng)需求，從客戶角度考慮軟件測試需要達(dá)到的 驗證狀態(tài)，即何些功能點需重點測試、何些無需，以便將來制定測試計劃。2、制定測試計劃進(jìn)行每一種測試之前，測試負(fù)責(zé)人要根據(jù)“產(chǎn)品定義書”及“總體設(shè)計說明” 和“詳細(xì)設(shè)訃文檔”制定“測試計劃”，制定總體的測試il劃，詳細(xì)闡明本次測試LI 的、對象、方法、范圍、過程、環(huán)境要求、接受標(biāo)準(zhǔn)以及測試人員和測試時間等內(nèi) 容，“測試計劃”經(jīng)過

2、審查通過，才能實施。3、需求 Review開發(fā)在完成軟件需求分析之后，會提交需求分析文檔，測試人員根據(jù)需求調(diào)研 所了解的需求以及產(chǎn)品需求說明文檔等資料,對需求分析文檔進(jìn)行Review,檢查文 檔是否滿足了需求，是否與需求一致等等。4、設(shè)計 Review在軟件分析設(shè)計階段，測試人員參與設(shè)計討論，了解系統(tǒng)的實現(xiàn)方式和原理，并 對概要設(shè)計和詳細(xì)設(shè)訃提出自己的見解。設(shè)訃結(jié)束之后，開發(fā)提交概要設(shè)計文檔和 詳細(xì)設(shè)計文檔，測試人員對設(shè)訃進(jìn)行Review,檢査設(shè)計規(guī)劃和實現(xiàn)方案是否合理，如 果不合理,存在的問題是什么、如何改進(jìn)等等。5、測試設(shè)計在設(shè)計測試方案時，首先分解測試內(nèi)容，對于一個復(fù)雜系統(tǒng)，通?？梢苑纸?/p>

3、成兒 個互相獨立的子系統(tǒng)，正確地劃分這些子系統(tǒng)及其邏輯組成部分和相互間的關(guān)系，可 以降低測試的復(fù)雜性，減少重復(fù)和遺漏，也便于設(shè)計和開發(fā)測試用例,有效的組織測 試，將系統(tǒng)分析人員的開發(fā)分析文檔加工成以測試為角度的功能點分析文檔,重要的 是描述對系統(tǒng)分解后每個功能點逐一的校驗描述，包括何種方法測試、何種數(shù)據(jù)測 試、期望測試結(jié)果等。然后以功能點分析文檔作為依據(jù)進(jìn)行測試用例的設(shè)計，設(shè)訃 測試用例是關(guān)系到測試效果以至軟件質(zhì)量的關(guān)鍵性一步，也是一項非常細(xì)致的工作, 根據(jù)對具體的北側(cè)系統(tǒng)的分析和測試要求，逐步細(xì)化測試的范圍和內(nèi)容，設(shè)計具體的 測試過程和數(shù)據(jù)，同時將結(jié)果寫成可以按步執(zhí)行的測試文檔。每個測試用例

4、必須包 括以下兒個部分：(1) 標(biāo)題和編號測試的H標(biāo)和的(3) 輸入和使用的數(shù)據(jù)和操作過程(4) 期望的輸出結(jié)果(5) 其他特殊的環(huán)境要求、次序要求、時間要求等6、開發(fā)測試工具和準(zhǔn)備測試數(shù)據(jù)在軟件測試中，為了提高測試工作的效益和質(zhì)量，只要條件許可,應(yīng)盡可能采用 計算機(jī)自動或半自動測試的方法,利用軟件工具本身的優(yōu)勢來提高工作效率7、測試執(zhí)行當(dāng)所有必需的測試準(zhǔn)備工作都已完成,并且產(chǎn)品已經(jīng)開發(fā)完畢并提交測試，則 可以按照預(yù)定的測試訃劃和測試方案逐項進(jìn)行測試。在測試過程中發(fā)現(xiàn)的任何與預(yù) 期LI標(biāo)不符的現(xiàn)象和問題都必須詳細(xì)記錄下來，填寫測試記錄。為了能準(zhǔn)確的找出 問題產(chǎn)生的原因，及時的解決問題，保證測試

5、工作的順利進(jìn)行，一般來說所發(fā)現(xiàn)的問 題必須是能夠重視的。8、回歸測試在測試中發(fā)現(xiàn)的任何問題和錯誤都必須有一個明確的解決方法。一般來說，經(jīng) 過修改的軟件可能仍然包含著錯誤，其至引入了新的錯誤，因此對于修改以后的程 序和文檔，按照修改的方法和影響的范圍，必須重新進(jìn)行有關(guān)的測試。另一方面，對 于版本更新后的軟件也必須進(jìn)行同樣的測試過程。9、測試分析報告測試結(jié)束后要及時地進(jìn)行總結(jié),對測試結(jié)果進(jìn)行分析，山測試負(fù)責(zé)人提交“測 試分析報告”。10、產(chǎn)品發(fā)布測試完畢，整理產(chǎn)品發(fā)布包和相關(guān)文檔并發(fā)布。對于新產(chǎn)品來說，必要的文檔 必須包括：(1) 安裝操作手冊(2) 產(chǎn)品白皮書(3) 管理維護(hù)手冊(4) 用戶操作

6、手冊測試報告11、版本控制新版本軟件發(fā)布之后，馬上對代碼進(jìn)行質(zhì)量控制。(1) Bu訂d Master給新版本的源代碼打一個cvs tag,方便代碼回滾check out。比如，發(fā)布版本為p2p3. 3. 2,則給該軟件源代碼也打一個與發(fā)布版本相同名字 的tagp2p3. 3. 2。這樣做的一個好處是，在U前的軟件的基礎(chǔ)上做了修改并發(fā)布新的 版本后，如果需要check out某個版本的源代碼，則可以通過這個版本的tag來 check out,代碼的修改可以在該版本上進(jìn)行。(2) Build Master對新發(fā)布的軟件源代碼進(jìn)行cvs lock,不允許開發(fā)人員在軟 件發(fā)布之后commit源代碼，直

7、到有新版本需求修改再給開發(fā)人員開放commit權(quán) 限。這樣做的好處是避免開發(fā)人員隨意修改和commit源代碼，確保源代碼服務(wù)器上 的源版本版本與當(dāng)前最新的發(fā)布版本一致。二、工程維護(hù)管理流程1、收集新需求:新功能和不緊急的故障，其代碼的修改操作不必馬上進(jìn)行，取 而代之的是做好新需求與故障統(tǒng)計;對已經(jīng)確認(rèn)的故障也可以先在bug管理系統(tǒng)報 bug,但只是記錄，不需求馬上修改。當(dāng)然了，對于緊急的工程故障，需要馬上修改和 測試。2、確認(rèn)新需求:與工程人員或客戶或產(chǎn)品經(jīng)理確認(rèn)新需求，確保需求被理解正 確。3、需求討論：當(dāng)需求與故障積累到一定數(shù)量或者工程有新版本需求，進(jìn)行一次 發(fā)布測試，在新版本開始修改之詢把近期積累的需求與故障整理，與相關(guān)開發(fā)人員、測試人員、項LI經(jīng)理和測試經(jīng)理討論，確認(rèn)哪些新功能可以實現(xiàn)、新功能的實現(xiàn)方 法與業(yè)務(wù)流程、新功能開發(fā)修改時間、測試版本、測試時間與發(fā)布時間。4、在bug跟蹤管理系統(tǒng)報bug:確認(rèn)所有需要修改的新功能和需求錄入bug 跟蹤管理系統(tǒng)，并在bug跟蹤管理系統(tǒng)中詳細(xì)描述新功能需求和解決方法，同時整理 相關(guān)bug列表，交付開發(fā)修改。5、制定測試計劃：A、根據(jù)用戶需求，定義并完善測試需求，作為測試的標(biāo)準(zhǔn)B、確定重點測試事項，哪些功能需要重點測試C、測試時間汁劃，并詳細(xì)汁劃具體測試任務(wù)與時間D、風(fēng)險說明E、測試準(zhǔn)備，提前對測試環(huán)境和測試資源進(jìn)行準(zhǔn)備