軟件測試的基本流程與測試規(guī)范;

1、軟件測試流程和規(guī)范軟件測試的基本流程與測試規(guī)范目錄前言1一、軟件測試的流程21.測試基本流程圖22.測試各階段工作流程32.1需求分析階段32.2計劃與設(shè)計階段42.3測試實施階段42.4測試結(jié)束52.5測試驗收和歸檔7二、軟件測試規(guī)范81.測試階段所基于的文檔（包括但不限于）81.1軟件需求規(guī)格說明書81.2軟件設(shè)計說明（概要設(shè)計或詳細(xì)設(shè)計）81.3軟件設(shè)計原型（demo）91.4接口文檔92.測試的種類（按階段劃分）92.1單元測試92.2集成測試112.3冒煙測試（非必須）122.4系統(tǒng)測試122.5隨機(jī)測試（非必須）132.6驗收測試（非必須）133.測試的類型（按測試內(nèi)容劃分）143

2、.1功能測試143.2界面測試（ui測試）193.3接口測試203.4性能測試203.5兼容性測試223.6安全測試223.7安裝測試244.缺陷管理254.1缺陷提交規(guī)范254.2缺陷生命周期274.3缺陷等級劃分28ii前言此文檔就項目中測試部分的工作流程進(jìn)行了一個梳理，參考了不同的資料，提煉整理的內(nèi)容為業(yè)內(nèi)已經(jīng)成型、被大多數(shù)項目采用和認(rèn)可的。因此，該流程并不針對某一個具體的企業(yè)或者項目，運(yùn)用到某一個項目中時，可進(jìn)行必要的增減和修改。另外，文章中測試規(guī)范部分，也是查閱了網(wǎng)上很多的資料、參考了其他項目文檔，并結(jié)合本人經(jīng)驗整理而成，可以覆蓋到項目開發(fā)過程中會遇到的絕大部分的測試面，針對不同的測

3、試內(nèi)容，該規(guī)范也能夠起到一定的指導(dǎo)和參考作用。但是在實際的工作中，放到具體的項目里，也需要根據(jù)具體情況和要求進(jìn)行適當(dāng)?shù)恼{(diào)整。一、軟件測試的流程1.測試基本流程圖2.測試各階段工作流程2.1需求分析階段測試需求是整個測試過程的基礎(chǔ)；確定測試對象以及測試工作的范圍和作用。用來確定整個測試工作（如安排時間表、測試設(shè)計等）并作為測試覆蓋的基礎(chǔ)，測試需求是計算測試覆蓋的分母，沒有測試需求就無法有效地進(jìn)行測試覆蓋。開始分析和提取測試需求的時候，整個項目一定至少已經(jīng)進(jìn)入設(shè)計階段，一定要有需求文檔、設(shè)計說明文檔或者原型作為依據(jù)。而且被確定的測試需求項必須是可核實的、可測的，不能有模棱兩可的概念，比如：大概、約

4、、或者；也不能為無法量化、主觀性的概念，比如：處理速度快、設(shè)計頁面好看。它們必須有一個可觀察、可評測的結(jié)果。無法核實的需求不是測試需求。測試需求是制訂測試計劃的基本依據(jù)，確定了測試需求能夠為測試計劃提供客觀依據(jù)； 測試需求是設(shè)計測試用例的指導(dǎo)，確定了要測什么、測哪些方面后才能有針對性的確定測試方案，設(shè)計測試用例。過程要點詳細(xì)說明輸入條件項目進(jìn)入軟件設(shè)計階段，至少需要有需求文檔、軟件設(shè)計說明書或者軟件原型（demo）工作內(nèi)容測試人員根據(jù)相關(guān)文檔梳理、提取測試需求，確定測試內(nèi)容（功能、性能、兼容性等）、使用的測試方法（手工測試、自動化測試），已保證此次需要測試的內(nèi)容覆蓋完整。退出標(biāo)準(zhǔn)提取完整的測試

5、需求點輸出內(nèi)容明確測試策略，列出具體的功能列表（非必須項）2.2計劃與設(shè)計階段2.2.1測試計劃階段當(dāng)項目進(jìn)入到實現(xiàn)階段，測試經(jīng)理就應(yīng)該和整個項目的開發(fā)人員、需求設(shè)計人員研究討論，并對本次測試的交接時間、投入的人力、擬定測試的輪次、各輪次持續(xù)的時間、測試的內(nèi)容和深度進(jìn)行規(guī)模預(yù)估，并制定出測試計劃。過程要點詳細(xì)說明輸入條件項目進(jìn)入到實現(xiàn)階段（編碼），需求規(guī)格說明書、軟件設(shè)計說明書（概要設(shè)計或詳細(xì)設(shè)計）、原型（demo）已輸出。工作內(nèi)容和整個項目組討論并確認(rèn)此次項目測試階段的人力、時間投入，測試輪次預(yù)估，測試的交接和驗收時間退出標(biāo)準(zhǔn)明確測試內(nèi)容、時間、人力安排輸出內(nèi)容測試人員提交評審后的測試計劃2

6、.2.2測試設(shè)計階段在項目進(jìn)入實現(xiàn)階段的同時，測試人員還需要根據(jù)基線版的軟件需求規(guī)格說明書和產(chǎn)品設(shè)計說明書編寫測試用例。根據(jù)每一個測試需求點和功能點，運(yùn)用不同的用例設(shè)計方法編寫用例，針對不同的測試內(nèi)容，可能會涉及到的用例包括：功能測試用例、性能測試用例、接口測試用例和自動化測試用例。過程要點詳細(xì)說明輸入條件測試需求明確，測試計劃明確，已有基線需求和測試計劃工作內(nèi)容根據(jù)每一步測試計劃編寫全部的測試用例退出標(biāo)準(zhǔn)測試用例需要覆蓋所有的測試需求輸出內(nèi)容測試人員提交評審后的測試用例，測試腳本（性能、自動化）2.3測試實施階段測試實施階段是測試人員在整個項目中需要投入最多工作量的階段，也是最主要，最重要的

7、一個階段。在這個階段中，測試人員需要根據(jù)前期的測試計劃、測試策略來執(zhí)行測試用例，根據(jù)設(shè)計的測試用例來執(zhí)行測試，并使用測試管理工具記錄、提交、跟蹤測試中發(fā)現(xiàn)的缺陷，并配合、督促開發(fā)人員復(fù)現(xiàn)、定位、修復(fù)缺陷，然后驗證和關(guān)閉缺陷。過程要點詳細(xì)說明輸入條件測試用例工作內(nèi)容根據(jù)測試計劃中分配給自己的測試任務(wù)，在測試計劃的時間段內(nèi)，執(zhí)行相應(yīng)的全部測試用例，并將測試結(jié)果記錄到測試管理工具中。如有需求和設(shè)計上的變更，需要不斷完善測試用例。退出標(biāo)準(zhǔn)執(zhí)行完畢所有測試用例，結(jié)果被記錄輸出內(nèi)容測試結(jié)果（輸出到測試管理工具中）2.4測試結(jié)束約定的測試周期完成后，測試人員需要總結(jié)此次測試的結(jié)果，并編寫報告。2.4.1缺陷

8、報告提交測試結(jié)束后，根據(jù)項目組的要求和具體情況，可能會要求提交缺陷報告（非必須），統(tǒng)計此次測試過程中出現(xiàn)的缺陷數(shù)量、分布情況、各功能模塊發(fā)現(xiàn)的缺陷占比、嚴(yán)重等級和修復(fù)情況等。缺陷報告的內(nèi)容側(cè)重對于缺陷的統(tǒng)計和分析。2.4.2測試報告提交測試報告是在一個測試階段結(jié)束后，或者項目的全部測試工作結(jié)束后需要提交的，所以報告又分為階段性測試報告，和總結(jié)性測試報告。報告需要對此次或此階段測試的情況進(jìn)行統(tǒng)計，匯總，分析，以供整個項目組了解軟件開發(fā)的質(zhì)量、開發(fā)的進(jìn)度及軟件修復(fù)的情況，對項目經(jīng)理決定上線與否，上線時間，項目是否會延期等相關(guān)決策提供一個重要的參考依據(jù)。過程要點詳細(xì)說明輸入條件測試人員完成了預(yù)定周期

9、的測試任務(wù)（一個階段或整個項目）工作內(nèi)容（階段性報告）測試人員根據(jù)此輪測試的結(jié)果，編寫階段性測試報告，主要應(yīng)包含以下內(nèi)容：l 測試報告的版本l 測試的人員和時間l 測試所覆蓋的缺陷測試組在這輪測試中所有處理的缺陷情況l 上一版本活動缺陷的數(shù)量（未關(guān)閉的缺陷）l 經(jīng)過此輪測試，所有活動缺陷的數(shù)量及其狀態(tài)分類l 測試評估寫明在這一版本中，哪些功能被實現(xiàn)了，哪些還沒有實現(xiàn)，這里只需寫明和上一版本不同之處即可。l 急待解決的問題寫明當(dāng)前項目組中面臨的優(yōu)先級最高的問題（非必須項）工作內(nèi)容（總結(jié)性報告）當(dāng)整個項目的測試工作全部結(jié)束后，測試人員應(yīng)就該項目的測試情況編寫總結(jié)性測試報告，測試報告必須包含以下內(nèi)容

10、：l 測試資源概述多少人、多長時間l 測試結(jié)果摘要分別描述各個測試需求的測試結(jié)果，產(chǎn)品實現(xiàn)了哪些功能點，哪些沒有實現(xiàn)，以及沒有實現(xiàn)的原因。l 缺陷分析按照缺陷的屬性分類分析，比如：缺陷總數(shù)、各模塊的缺陷分布、不同嚴(yán)重等級的缺陷、缺陷的修復(fù)情況、未修復(fù)的缺陷及未修復(fù)的原因、對項目整體的影響等等（也可單獨寫一份缺陷報告）l 測試評估從總體對項目質(zhì)量進(jìn)行評估l 測試組建議從測試組的角度為項目組提出工作建議退出標(biāo)準(zhǔn)本次測試中所有的相關(guān)測試數(shù)據(jù)統(tǒng)計完畢，完成統(tǒng)計分析輸出內(nèi)容缺陷報告（非必須）、測試報告（根據(jù)實際的項目規(guī)模可細(xì)分為階段性的和總結(jié)性的）2.5測試驗收和歸檔2.5.1測試驗收當(dāng)上述所有工作完成

11、后，測試人員應(yīng)對測試的過程、效果進(jìn)行驗收，宣布測試的所有工作完成（根據(jù)實際項目的規(guī)模來定，非必須）過程要點詳細(xì)說明輸入條件測試實施工作結(jié)束，所有測試文檔已編寫完畢工作內(nèi)容測試驗收工作由測試經(jīng)理進(jìn)行，驗收內(nèi)容報告：l 測試效果驗收測試是否達(dá)到預(yù)期目標(biāo)l 測試文檔驗收測試過程中文檔是否齊全，是否符合標(biāo)準(zhǔn)l 測試評估從總體對測試的質(zhì)量進(jìn)行評估l 測試建議對本次測試工作指出不足，并對以后的工作提出改進(jìn)、優(yōu)化建議l 宣布測試結(jié)束測試組成員簽字宣布本次測試結(jié)束退出標(biāo)準(zhǔn)簽發(fā)測試驗收報告輸出內(nèi)容所有測試人員測試驗收報告2.5.2測試歸檔測試歸檔是在測試驗收結(jié)束宣布測試有效，結(jié)束測試后，對測試過程中涉及到各種標(biāo)

12、準(zhǔn)文檔進(jìn)行歸檔。過程要點詳細(xì)說明輸入條件測試驗收通過工作內(nèi)容歸檔測試過程中所有文檔，主要包括以下文檔（必須）l 測試計劃l 測試用例l 測試報告退出標(biāo)準(zhǔn)全部文檔歸檔完畢輸出內(nèi)容歸檔清單二、軟件測試規(guī)范測試代碼和項目開發(fā)代碼應(yīng)該利用配置管理工具（如svn）分開管理。測試代碼編寫完成后，存放在配置庫中。開發(fā)過程中，可根據(jù)需要對自己編寫代碼進(jìn)行測試。并且測試環(huán)境和開發(fā)環(huán)境應(yīng)分隔開來，以免相互影響，便于缺陷的復(fù)現(xiàn)和定位，在條件允許的情況下，性能測試環(huán)境應(yīng)和功能測試環(huán)境分開，以免在性能測試過程中對功能測試造成影響。1.測試階段所基于的文檔（包括但不限于）測試規(guī)范形成的前提是需要有有章可循的依據(jù)，這些依據(jù)

13、需要基于標(biāo)準(zhǔn)的項目文檔，常見的文檔包括下面幾種：1.1軟件需求規(guī)格說明書軟件需求說明書是為了使用戶和軟件開發(fā)者雙方對該軟件的初始規(guī)定有一個共同的理解， 使之成為整個項目組開展工作的基礎(chǔ)。包含硬件、功能、性能、輸入輸出、接口需求、警示信息、保密安全、數(shù)據(jù)與數(shù)據(jù)庫、文檔和法規(guī)的要求等等。軟件需求說明書的作用在于便于用戶、開發(fā)人員進(jìn)行理解和交流，反映出用戶問題的結(jié)構(gòu)，可以作為軟件開發(fā)工作的基礎(chǔ)和依據(jù)，并作為確認(rèn)測試和驗收的依據(jù)。1.2軟件設(shè)計說明（概要設(shè)計或詳細(xì)設(shè)計）軟件設(shè)計又劃分為概要設(shè)計和詳細(xì)設(shè)計。概要設(shè)計是在用戶提出的需求和軟件的設(shè)計實現(xiàn)之間架起橋梁，是將用戶提出的目標(biāo)和需求轉(zhuǎn)換成具體界面設(shè)計

14、解決方案的重要階段。概設(shè)的主要任務(wù)是把需求分析得到的系統(tǒng)擴(kuò)展用例圖轉(zhuǎn)換為軟件結(jié)構(gòu)和數(shù)據(jù)結(jié)構(gòu)。設(shè)計軟件結(jié)構(gòu)的具體任務(wù)是：將一個復(fù)雜系統(tǒng)按功能進(jìn)行模塊劃分、建立模塊的層次結(jié)構(gòu)及調(diào)用關(guān)系、確定模塊間的接口及人機(jī)交互的界面等。從而設(shè)計建立一個目標(biāo)系統(tǒng)的邏輯模型。而詳細(xì)設(shè)計是軟件工程中軟件開發(fā)的一個步驟，就是對概要設(shè)計的一個細(xì)化，就是詳細(xì)設(shè)計每個模塊實現(xiàn)算法，所需的局部結(jié)構(gòu)。在詳細(xì)設(shè)計階段，主要是通過需求分析的結(jié)果，設(shè)計出滿足用戶需求的軟件系統(tǒng)產(chǎn)品。軟件設(shè)計說明對測試工作開展有很大影響，沒有軟件設(shè)計說明很多問題將無法溯源，測試準(zhǔn)備的前期工作也是根據(jù)軟件設(shè)計說明來制定的。1.3軟件設(shè)計原型（demo）頁面

15、原型是項目人員快速熟悉項目的最佳路徑，讓開發(fā)人員和測試人員更直觀的了解客戶的需求和產(chǎn)品的實現(xiàn)方式、業(yè)務(wù)邏輯，幫助項目人員更快的理解用戶需求、業(yè)務(wù)邏輯，用更直觀，具體的界面化方式來說明用戶想要如何來實現(xiàn)他們需要的功能?；蛘咴谛枨蟛粔蛎鞔_，設(shè)計說明書不夠全面的情況下，頁面原型也是后期測試用例編寫思想的重要根據(jù)。1.4接口文檔當(dāng)項目中各個子系統(tǒng)間、各個功能模塊間有交互，需要開發(fā)接口時，接口文檔會定義出參數(shù)傳遞、參數(shù)返回的規(guī)則，比如：參數(shù)的名稱、參數(shù)的類型、長度、是否必填、各個返回碼所代表的含義，當(dāng)項目中有接口測試需求的時候，此文檔是很重要的測試依據(jù)。2.測試的種類（按階段劃分）測試的階段也根據(jù)項目開

16、發(fā)的進(jìn)度來進(jìn)行，從先到后劃分為下面幾種測試階段：（根據(jù)項目的實際要求進(jìn)行相應(yīng)測試）2.1單元測試單元測試是指對軟件中的最小可測試單元進(jìn)行檢查和驗證。準(zhǔn)入條件1、 源碼已實現(xiàn)完成或50%；2、 源碼編譯能通過；3、 項目需求文檔、概要設(shè)計文檔、詳細(xì)設(shè)計文檔均通過評審并歸檔；4、 單元測試用例通過評審并歸檔；主要測試點和方法l 代碼靜態(tài)檢查無需運(yùn)行被測代碼，僅通過分析或檢查源程序的語法、結(jié)構(gòu)、過程、接口等來檢查程序的正確性，找出代碼隱藏的錯誤和缺陷，如參數(shù)不匹配，有歧義的嵌套語句，錯誤的遞歸，非法計算，可能出現(xiàn)的空指針引用等等。l 獨立路徑和錯誤檢查獨立路徑測試：在模塊中應(yīng)對每一條獨立執(zhí)行路徑進(jìn)行

17、測試，每條語句至少執(zhí)行一次。測試目的主要是為了發(fā)現(xiàn)因錯誤計算、不正確的比較和不適當(dāng)?shù)目刂屏髟斐傻腻e誤。錯誤檢查：首先檢查程序是否有錯誤處理；其次對于程序中的防錯處理的完整性和正確性進(jìn)行檢查。錯誤處理包括：不同數(shù)據(jù)類型的對象之間進(jìn)行比較；錯誤地使用邏輯運(yùn)算符或優(yōu)先級；因計算機(jī)表示的局限性，期望理論上相等而實際上不相等的兩個量相等；比較運(yùn)算或變量出錯；循環(huán)終止條件或不可能出現(xiàn)；迭代發(fā)散時不能退出；錯誤地修改了循環(huán)變量。單元測試人員一般是開發(fā)自測。參與組織需要參與的人員的職責(zé)如下表：編號角色職責(zé)說明1需求經(jīng)理對測試中需求不明確地方，進(jìn)行明確；2產(chǎn)品經(jīng)理對測試中產(chǎn)品功能實現(xiàn)歧義地方，進(jìn)行明確；3開發(fā)人

18、員負(fù)責(zé)功能開發(fā)、缺陷修復(fù)、單元測試；4開發(fā)責(zé)任人負(fù)責(zé)軟件開發(fā)進(jìn)度、版本提交和相關(guān)協(xié)調(diào)；5配置管理員負(fù)責(zé)每輪測試前：代碼獲取、編譯、發(fā)布；6測試經(jīng)理負(fù)責(zé)項目測試整體計劃、協(xié)調(diào)和質(zhì)量；2.2集成測試集成測試，也叫組裝測試或聯(lián)合測試。在單元測試的基礎(chǔ)上，將所有模塊按照設(shè)計要求（如根據(jù)結(jié)構(gòu)圖）組裝成為子系統(tǒng)或系統(tǒng)，進(jìn)行集成測試。它最簡單的形式是：把兩個已經(jīng)測試過的單元組合成一個組件，測試它們之間的接口。準(zhǔn)入條件1、 單元測試用例編寫完成；2、 核心功能開發(fā)完成；3、 項目需求文檔、概要設(shè)計文檔、詳細(xì)設(shè)計文檔均通過評審并歸檔；4、 子系統(tǒng)間接口說明文檔通過評審并歸檔；5、 項目集成測試用例文檔通過評審并

19、歸檔；主要測試點和方法（詳見3.3接口測試章節(jié)）參與組織需要參與的人員的職責(zé)如下表：編號角色職責(zé)說明1需求經(jīng)理對測試中需求不明確地方，進(jìn)行明確；2產(chǎn)品經(jīng)理對測試中產(chǎn)品功能實現(xiàn)歧義地方，進(jìn)行明確；3開發(fā)人員負(fù)責(zé)功能開發(fā)、缺陷修復(fù)、單元測試；4開發(fā)責(zé)任人負(fù)責(zé)軟件開發(fā)進(jìn)度、版本提交和相關(guān)協(xié)調(diào)；5配置管理員負(fù)責(zé)每輪測試前：代碼獲取、編譯、發(fā)布；6測試經(jīng)理負(fù)責(zé)項目測試整體計劃、協(xié)調(diào)和質(zhì)量；2.3冒煙測試（非必須）冒煙測試是開發(fā)完成后，正式移交測試前做的一個中間測試工作，即在剛剛編譯出來后，開發(fā)人員需要進(jìn)行基本確認(rèn)測試，例如是否可以正確安裝/卸載，主要功能是否實現(xiàn)，是否存在嚴(yán)重死機(jī)或數(shù)據(jù)嚴(yán)重丟失等bug。

20、如果通過了該測試，則可以移交測試，開始正式測試。否則，就需要重新編譯版本，再次執(zhí)行版本可接收確認(rèn)測試，直到成功。該工作可由開發(fā)人員先行自測，保證移交測試版本的質(zhì)量，防止出現(xiàn)阻礙測試的情況出現(xiàn)，也可由測試人員來進(jìn)行，只有冒煙測試通過后，才進(jìn)入正式的測試流程，否則會把版本打回，重新編譯。2.4系統(tǒng)測試系統(tǒng)測試是針對整個產(chǎn)品系統(tǒng)進(jìn)行的測試，目的是驗證系統(tǒng)是否滿足了需求規(guī)格的定義，找出與需求規(guī)格不符或與之矛盾的地方，從而提出更加完善的方案。也是整個測試工作最重要，最關(guān)鍵的測試部分。準(zhǔn)入條件1、 單元、集成測試完成；2、 前階段中缺陷修復(fù)率100%；3、 功能用例編寫完成，覆蓋率達(dá)100%；4、 項目需

21、求文檔、設(shè)計文檔均通過評審并歸檔；5、 測試用例通過評審并歸檔；主要測試點和方法（詳見3.1功能測試章節(jié)）參與組織需要參與的人員的職責(zé)如下表：編號角色職責(zé)說明1需求經(jīng)理對測試中需求不明確地方，進(jìn)行明確；2產(chǎn)品經(jīng)理對測試中產(chǎn)品功能實現(xiàn)歧義地方，進(jìn)行明確；3開發(fā)人員負(fù)責(zé)功能開發(fā)、缺陷修復(fù)、單元測試；4開發(fā)責(zé)任人負(fù)責(zé)軟件開發(fā)進(jìn)度、版本提交和相關(guān)協(xié)調(diào)；5配置管理員負(fù)責(zé)每輪測試前：代碼獲取、編譯、發(fā)布；6測試經(jīng)理負(fù)責(zé)項目測試整體計劃、協(xié)調(diào)和質(zhì)量；7測試人員負(fù)責(zé)測試方案編寫、測試用例編寫、測試執(zhí)行、質(zhì)量分析；2.5隨機(jī)測試（非必須）隨機(jī)測試沒有書面測試用例、記錄期望結(jié)果、檢查列表、腳本或指令的測試。主要是

22、根據(jù)測試者的經(jīng)驗對軟件進(jìn)行功能和性能抽查。隨機(jī)測試是根據(jù)測試說明書執(zhí)行用例測試的重要補(bǔ)充手段，是保證測試覆蓋完整性的有效方式和過程。 隨機(jī)測試主要是對被測軟件的一些重要功能進(jìn)行復(fù)測，也包括測試那些當(dāng)前的測試用例沒有覆蓋到的部分。另外，對于軟件更新和新增加的功能要重點測試。重點對一些特殊點情況點、特殊的使用環(huán)境、并發(fā)性、進(jìn)行檢查。尤其對以前測試發(fā)現(xiàn)的重大bug，進(jìn)行再次測試，可以結(jié)合回歸測試2.6驗收測試（非必須）2.6.1 測試 （beta測試）測試是軟件的多個用戶在一個或多個用戶的實際使用環(huán)境下進(jìn)行的測試。開發(fā)者通常不在測試現(xiàn)場，beta測試不能由程序員或測試員完成。 當(dāng)開發(fā)和測試根本完成時

23、所做的測試，而最終的錯誤和問題需要在最終發(fā)行前找到。這種測試一般由最終用戶或其他人員完成，不能由程序員或測試員完成。2.6.2 測試（alpha測試）alpha測試是由一個用戶在開發(fā)環(huán)境下進(jìn)行的測試，也可以是公司內(nèi)部的用戶在模擬實際操作環(huán)境下進(jìn)行的受控測試，alpha測試不能由該系統(tǒng)的程序員或測試員完成。 在系統(tǒng)開發(fā)接近完成時對應(yīng)用系統(tǒng)的測試;測試后，仍然會有少量的設(shè)計變更。這種測試一般由最終用戶或其他人員來完成，不能由程序員或測試員完成。測試和測試的不同之處在于測試的環(huán)境，前者是在開發(fā)環(huán)境，后者是在實際使用環(huán)境（生產(chǎn)環(huán)境），故后者模擬真實使用場景程度更高，發(fā)現(xiàn)的問題也更有意義，一般運(yùn)用在項目

24、的試運(yùn)行階段。3.測試的類型（按測試內(nèi)容劃分）3.1功能測試功能測試也叫黑盒測試，是在不看代碼的前提下，通過運(yùn)行軟件來進(jìn)行測試，重點是關(guān)注系統(tǒng)的功能實現(xiàn)是否正常、設(shè)計是否合理、用戶的需求是否全部覆蓋，這也是測試工作最主要、最重要的內(nèi)容。在版本穩(wěn)定以后，或者進(jìn)行回歸測試的時候，可根據(jù)項目的具體情況，對主要功能通過編寫自動化測試腳本，進(jìn)行自動化測試。根據(jù)被測功能點的特性列丼出相應(yīng)類型的測試用例對其進(jìn)行覆蓋，如；涉及輸入的地方需要考慮等價、邊界、負(fù)面、異?；蚍欠?、場景回滾、關(guān)聯(lián)測試等測試類型對其進(jìn)行覆蓋。 在測試實現(xiàn)的各個階段跟蹤測試實現(xiàn)與需求輸入的覆蓋情況，及時修正業(yè)務(wù)或需求理解錯誤。測試內(nèi)容序列

25、分類說明1基本功能1.正常增、刪、改、查；2.正常業(yè)務(wù)流程；3.正常權(quán)限功能；4.正常數(shù)據(jù)調(diào)用（包括數(shù)據(jù)）。2邊界類1.驗證邊界值，對16-bit 的整數(shù)而言 32767 和 -32768 是邊界；2.屏幕上光標(biāo)在最左上、最右下位置；3.報表的第一行和最后一行；4.數(shù)組元素的第一個和最后一個；5.最小值-1/最大值+1/空值；6.分析規(guī)格說明，找出其它可能的邊界值條件。3等價類1.有效等價類，指符合系統(tǒng)設(shè)計有意義的輸入輸出合集；2.無效等價類，指不符合系統(tǒng)設(shè)計錯誤的輸入輸入合集；4錯誤推測基于經(jīng)驗和直覺推測程序中所有可能存在的各種錯誤；5因果圖設(shè)計因果圖，將因果圖轉(zhuǎn)化為判定表，判定表的每一列作

26、為一條測試用例。6用戶場景設(shè)計根據(jù)不同用戶運(yùn)行該系統(tǒng)時所做的操作，來設(shè)計用例。8app特有功能1.應(yīng)用的前后臺切換；2.數(shù)據(jù)更新；3.離線瀏覽；4.定位、照相機(jī)服務(wù)，掃描二維碼功能；5.時間測試；6.push測試；7.運(yùn)行測試。app的功能測試具體為：l 運(yùn)行1）app安裝完成后的試運(yùn)行，可正常打開軟件。2）app打開測試，是否有加載狀態(tài)進(jìn)度提示。3）app打開速度測試，速度是否可觀。4）app頁面間的切換是否流暢，邏輯是否正確5）注冊-同表單編輯頁面-用戶名密碼長度-注冊后的提示頁面-前臺注冊頁面和后臺的管理頁面數(shù)據(jù)是否一致-注冊后，在后臺管理中頁面提示6）登錄-使用合法的用戶登錄系統(tǒng)。-系

27、統(tǒng)是否允許多次非法的登陸，是否有次數(shù)限制。-使用已經(jīng)登陸的賬號登陸系統(tǒng)是否正確處理。-使用禁用的賬號登陸系統(tǒng)是否正確處理。-用戶名、口令（密碼）錯誤或漏填時能否登陸。-刪除或修改后的用戶，原用戶登陸。-不輸入用戶口令和用戶、重復(fù)點（確定或取消按鈕）是否允許登陸。-登陸后，頁面中登陸信息。-頁面中有注銷按鈕。-登陸超時的處理。7）注銷-注銷原模塊，新的模塊系統(tǒng)能否正確處理。-終止注銷能否返回原模塊，原用戶。-注銷原用戶，新用戶系統(tǒng)能否正確處理。-使用錯誤的賬號、口令、無權(quán)限的被禁用的賬號進(jìn)行注銷l 應(yīng)用的前后臺切換1) app切換到后臺，再回到app，檢查是否停留在上一次操作界面。2) app切

28、換到后臺，再回到app，檢查功能及應(yīng)用狀態(tài)是否正常，ios 4和ios 5的版本的處理機(jī)制有的不一樣。 3) app切換到后臺，再回到前臺時，注意程序是否崩潰，功能狀態(tài)是否正常，尤其是對于從后臺切換回前臺數(shù)據(jù)有自動更新的時候。 4) 手機(jī)鎖屏解屏后進(jìn)入app注意是否會崩潰，功能狀態(tài)是否正常，尤其是對于從后臺切換回前臺數(shù)據(jù)有自動更新的時候。 5) 當(dāng)app使用過程中有電話進(jìn)來中斷后再切換到app，功能狀態(tài)是否正常 6) 當(dāng)殺掉app進(jìn)程后，再開啟app，app能否正常啟動。 7) 出現(xiàn)必須處理的提示框后，切換到后臺，再切換回來，檢查提示框是否還存在，有時候會出現(xiàn)應(yīng)用自動跳過提示框的缺陷。 8)

29、對于有數(shù)據(jù)交換的頁面，每個頁面都必需要進(jìn)行前后臺切換、鎖屏的測試，這種頁面最容易出現(xiàn)崩潰。l 免登錄很多應(yīng)用提供免登錄功能，當(dāng)應(yīng)用開啟時自動以上一次登錄的用戶身份來使用app. 1) app有免登錄功能時，需要考慮ios版本差異。 2) 考慮無網(wǎng)絡(luò)情況時能否正常進(jìn)入免登錄狀態(tài)。 3) 切換用戶登錄后，要校驗用戶登錄信息及數(shù)據(jù)內(nèi)容是否相應(yīng)更新，確保原用戶退出。 4) 根據(jù)mtop的現(xiàn)有規(guī)則，一個帳戶只允許登錄一臺機(jī)器。所以，需要檢查一個帳戶登錄多臺手機(jī)的情況。原手機(jī)里的用戶需要被踢出，給出友好提示。 5) app切換到后臺，再切回前臺的校驗 6) 切換到后臺，再切換回前臺的測試 7) 密碼更換后

30、，檢查有數(shù)據(jù)交換時是否進(jìn)行了有效身份的校驗 8) 支持自動登錄的應(yīng)用在進(jìn)行數(shù)據(jù)交換時，檢查系統(tǒng)是否能自動登錄成功并且數(shù)據(jù)操作無誤。 9) 檢查用戶主動退出登錄后，下次啟動app，應(yīng)停留在登錄界面l 數(shù)據(jù)更新根據(jù)應(yīng)用的業(yè)務(wù)規(guī)則，以及數(shù)據(jù)更新量的情況，來確定最優(yōu)的數(shù)據(jù)更新方案。 1) 需要確定哪些地方需要提供手動刷新，哪些地方需要自動刷新，哪些地方需要手動+自動刷新。 2) 確定哪些地方從后臺切換回前臺時需要進(jìn)行數(shù)據(jù)更新。 3) 根據(jù)業(yè)務(wù)、速度及流量的合理分配，確定哪些內(nèi)容需要實時更新，哪些需要定時更新。 4) 確定數(shù)據(jù)展示部分的處理邏輯，是每次從服務(wù)端請求，還是有緩存到本地，這樣才能有針對性的進(jìn)

31、行相應(yīng)測試。 5) 檢查有數(shù)據(jù)交換的地方，均有相應(yīng)的異常處理。 l 離線瀏覽很多應(yīng)用會支持離線瀏覽，即在本地客戶端會緩存一部分?jǐn)?shù)據(jù)供用戶查看。 1) 在無網(wǎng)絡(luò)情況可以瀏覽本地數(shù)據(jù) 2) 退出app再開啟app時能正常瀏覽 3) 切換到后臺再切回前臺可以正常瀏覽 4) 鎖屏后再解屏回到應(yīng)用前臺可以正常瀏覽 5) 在對服務(wù)端的數(shù)據(jù)有更新時會給予離線的相應(yīng)提示l app更新當(dāng)客戶端有新版本時，有更新提示。 2) 當(dāng)版本為非強(qiáng)制升級版時，用戶可以取消更新，老版本能正常使用。用戶在下次啟動app時，仍能出現(xiàn)更新提示。 3) 當(dāng)版本為強(qiáng)制升級版時，當(dāng)給出強(qiáng)制更新后用戶沒有做更新時，退出客戶端。下次啟動ap

32、p時，仍出現(xiàn)強(qiáng)制升級提示。 4) 當(dāng)客戶端有新版本時，在本地不刪除客戶端的情況下，直接更新檢查是否能正常更新。5) 當(dāng)客戶端有新版本時，在本地不刪除客戶端的情況下，檢查更新后的客戶端功能是否是新版本。 6) 當(dāng)客戶端有新版本時，在本地不刪除客戶端的情況下，檢查資源同名文件如圖片是否能正常更新成最新版本。如果以上無法更新成功的，也都屬于缺陷。l 定位、照相機(jī)服務(wù)1) app有用到相機(jī)，定位服務(wù)時，需要注意系統(tǒng)版本差異 2) 有用到定位服務(wù)、照相機(jī)服務(wù)的地方，需要進(jìn)行前后臺的切換測試，檢查應(yīng)用是否正常。 3) 當(dāng)定位服務(wù)沒有開啟時，使用定位服務(wù)，會友好性彈出是否允許設(shè)置定位提示。當(dāng)確定允許開啟定位

33、時，能自動跳轉(zhuǎn)到定位設(shè)置中開啟定位服務(wù)。 4) 測試定位、照相機(jī)服務(wù)時，需要采用真機(jī)進(jìn)行測試。l 時間測試客戶端可以自行設(shè)置手機(jī)的時區(qū)、時間，因此需要校驗該設(shè)置對app的影響。 -中國為東8區(qū)，所以當(dāng)手機(jī)設(shè)置的時間非東8區(qū)時，查看需要顯示時間的地方，時間是否展示正確，應(yīng)用功能是否正常。時間一般需要根據(jù)服務(wù)器時間再轉(zhuǎn)換成客戶端對應(yīng)的時區(qū)來展示，這樣的用戶體驗比較好。比如發(fā)表一篇微博在服務(wù)端記錄的是10：00，此時，華盛頓時間為22：00，客戶端去瀏覽時，如果設(shè)置的是華盛頓時間,則顯示的發(fā)表時間即為22:00,當(dāng)時間設(shè)回東8區(qū)時間時，再查看則顯示為10：00。l push測試1) 檢查push消息

34、是否按照指定的業(yè)務(wù)規(guī)則發(fā)送 2) 檢查不接受推送消息時，檢查用戶不會再接收到push. 3) 如果用戶設(shè)置了免打擾的時間段，檢查在免打擾時間段內(nèi)，用戶接收不到push。在非免打擾時間段，用戶能正常收到push。4) 當(dāng)push消息是針對登錄用戶的時候，需要檢查收到的push與用戶身份是否相符，沒有錯誤地將其它人的消息推送過來。一般情況下，只對手機(jī)上最后一個登錄用戶進(jìn)行消息推送。 5) 測試push時，需要采用真機(jī)進(jìn)行測試。 3.2界面測試（ui測試）界面測試（簡稱ui測試)，測試用戶界面的功能模塊的布局是否合理、整體風(fēng)格是否一致、各個控件的放置位置是否符合客戶使用習(xí)慣。測試內(nèi)容1、 導(dǎo)航、鏈接

35、、cookie、頁面結(jié)構(gòu)包括菜單、背景、顏色、字 體、按鈕名稱、title、提示信息的一致性等；2、 界面內(nèi)容完整性檢查，通過瀏覽器測試，確認(rèn)對象可以正確的反應(yīng)業(yè)務(wù)的功能和需求，包括窗口與窗口之間的跳轉(zhuǎn)，字段與字段之間的瀏覽，各種快捷鍵的使用。3、 窗口的對象和特征（例如：菜單、大小、位置、狀態(tài)和中心）都符合標(biāo)準(zhǔn)。3.3接口測試當(dāng)模塊之間、子系統(tǒng)之間有接口交互時，需要根據(jù)接口文檔進(jìn)行測試，接口測試也叫集成測試或灰盒測試，主要用于檢測外部系統(tǒng)與系統(tǒng)之間以及內(nèi)部各個子系統(tǒng)之間的交互點。測試的重點是要檢查數(shù)據(jù)的交換，傳遞和控制管理過程，以及系統(tǒng)間的相互邏輯依賴關(guān)系等。測試內(nèi)容1、 輸入的實際參數(shù)與形

36、式參數(shù)的個數(shù)是否相同；2、 輸入的實際參數(shù)與形式參數(shù)的屬性是否匹配；3、 輸入的實際參數(shù)與形式參數(shù)的量綱是否一致；4、 調(diào)用其他模塊時所給實際參數(shù)的個數(shù)是否與被調(diào)模塊的形參個數(shù)相同；5、 調(diào)用其他模塊時所給實際參數(shù)的屬性是否與被調(diào)模塊的形參屬性匹配；6、 調(diào)用其他模塊時所給實際參數(shù)的量綱是否與被調(diào)模塊的形參量綱一致；7、 調(diào)用預(yù)定義函數(shù)時所用參數(shù)的個數(shù)、屬性和次序是否正確；8、 是否存在與當(dāng)前入口點無關(guān)的參數(shù)引用；9、 是否修改了只讀型參數(shù)；10、 對全局變量的定義各模塊是否一致；11、 是否把某些約束作為參數(shù)傳遞。12、 如果模塊功能包括外部輸入輸出，還應(yīng)該考慮下列因素：-文件屬性是否正確；

37、-open/close語句是否正確；13、 格式說明與輸入輸出語句是否匹配；14、 緩沖區(qū)大小與記錄長度是否匹配；15、 文件使用前是否已經(jīng)打開；16、 是否處理了文件尾；17、 是否處理了輸入/輸出錯誤；18、 輸出信息中是否有文字性錯誤。3.4性能測試性能測試是通過性能測試工具模擬多種正常、峰值以及異常負(fù)載條件來對系統(tǒng)的各項性能指標(biāo)進(jìn)行測試。性能測試包括的測試內(nèi)容主要概括為三個方面：應(yīng)用在客戶端性能的測試、應(yīng)用在網(wǎng)絡(luò)上性能的測試和應(yīng)用在服務(wù)器端性能的測試。通常情況下，三方面有效、合理的結(jié)合，可以達(dá)到對系統(tǒng)性能全面的分析和瓶頸的預(yù)測。性能測試的目的是通過確定一個系統(tǒng)的瓶頸或者不能接受的性能點

38、，來獲得系統(tǒng)能提供的最大服務(wù)級別的測試。一個系統(tǒng)需要達(dá)到的性能指標(biāo)也是來源于需求，和用戶對該軟件的性能要求。常見的性能指標(biāo)如下：l 響應(yīng)時間（按照不同的處理細(xì)分）1）事務(wù)處理類 快速響應(yīng)類普通響應(yīng)類2）查詢類3）統(tǒng)計類l 吞吐量與關(guān)鍵量l 事務(wù)成功率l 服務(wù)器資源cpu使用率內(nèi)存使用率i/o吞吐量測試內(nèi)容性能測試類型包括負(fù)載測試，強(qiáng)度測試，容量測試等。l 負(fù)載測試：是一種主要為了測試軟件系統(tǒng)是否達(dá)到需求文檔設(shè)計的目標(biāo)，譬如軟件在一定時期內(nèi)，最大支持多少并發(fā)用戶數(shù)，軟件請求出錯率等，測試的主要是軟件系統(tǒng)的性能。l 壓力測試：強(qiáng)度測試也就是壓力測試，壓力測試主要是為了測試硬件系統(tǒng)是否達(dá)到需求文檔設(shè)

39、計的性能目標(biāo)，譬如在一定時期內(nèi)，系統(tǒng)的cpu利用率，內(nèi)存使用率，磁盤i/o吞吐率，網(wǎng)絡(luò)吞吐量等，壓力測試和負(fù)載測試最大的差別在于測試目的不同。l 容量測試：確定系統(tǒng)最大承受量，譬如系統(tǒng)最大用戶數(shù)，最大存儲量，最多處理的數(shù)據(jù)流量等。另外，并發(fā)測試是應(yīng)用在客戶端，以客戶端做為入口進(jìn)行的一項重要性能測試，它是一個負(fù)載測試和壓力測試的過程，即逐漸增加負(fù)載，直到系統(tǒng)的瓶頸或者不能接收的性能點，通過綜合分析交易執(zhí)行指標(biāo)和資源監(jiān)控指標(biāo)來確定系統(tǒng)并發(fā)性能的過程。3.5兼容性測試web兼容性測試范圍主要從操作系統(tǒng)、瀏覽器、分辨率這三方面考慮， 而系統(tǒng)（如不同的windows版本）和瀏覽器（如ie9、谷歌、火狐）

40、是重點考慮方向，系統(tǒng)應(yīng)該支持什么系統(tǒng)和瀏覽器，也是應(yīng)以需求為依據(jù)。app兼容性主要考慮內(nèi)部和外部兼容性1）與本地及主流app是否兼容；2）基于開發(fā)環(huán)境和生產(chǎn)環(huán)境的不同，檢驗在各種網(wǎng)絡(luò)連接下(wifi、gsm、gprs、edge、wcdma、cdma1x、cdma2000、hspda等)，app的數(shù)據(jù)和運(yùn)用是否正確；3）與各種設(shè)備是否兼容，若有跨系統(tǒng)支持則需要檢驗是否在各系統(tǒng)下，各種行為是否一致： -不同操作系統(tǒng)的兼容性，是否適配-不同手機(jī)屏幕分辨率的兼容性-不同手機(jī)品牌的兼容性 3.6安全測試安全測試是在it軟件產(chǎn)品的生命周期中，特別是產(chǎn)品開發(fā)基本完成到發(fā)布階段，對產(chǎn)品進(jìn)行檢驗以驗證產(chǎn)品符合安

41、全需求定義和產(chǎn)品質(zhì)量標(biāo)準(zhǔn)的過程 。如需求上對軟件產(chǎn)品有具體的安全等級要求，那么我們需要從下面幾個方面進(jìn)行安全測試：可測試性和通用性上劃分為：權(quán)限管理測試、認(rèn)證測試、會話管理測試、服務(wù)器測試、數(shù)據(jù)注入測試，其余方面（如環(huán)境安全、媒體安全）可在部署和運(yùn)維中保證。測試內(nèi)容l 權(quán)限管理測試驗證用戶是否可以進(jìn)行橫向越權(quán)和縱向越權(quán)操作 頁面是否進(jìn)行權(quán)限判斷 頁面資源標(biāo)志是否和用戶信息匹配 用戶登錄后，應(yīng)以會話中的用戶session的用戶身份信息為準(zhǔn)。 每個url必須堅定權(quán)限，不能通過菜單屏蔽或按鈕disable作為限制條件。l 認(rèn)證測試認(rèn)證測試是為了避免用戶賬號和密碼遭到暴力破解而進(jìn)行的測試 系統(tǒng)存在驗證

42、碼機(jī)制。 不允許簡單面的存在。如純英文、純數(shù)字等。 認(rèn)證失敗的錯誤提示不應(yīng)該提示詳細(xì)信息，避免攻擊者根據(jù)提示信息改良破解方式。 系統(tǒng)存在鎖定策略。 系統(tǒng)不存在認(rèn)證繞過的漏洞。 找回密碼和修改密碼不存在漏洞。 使用安全的數(shù)據(jù)傳輸。 強(qiáng)口令策略。l 會話管理測試會話管理用于保持用戶的整個會話活動與計算機(jī)系統(tǒng)跟蹤過程，根據(jù)項目需求，關(guān)注web服務(wù)器的會話管理。 用戶登錄后，身份信息由服務(wù)器端會話的session中的用戶信息為準(zhǔn)。 cookie中不會帶有session id信息。 用戶操作停止后會話保持時間不會超過10分鐘，超過10分鐘會跳轉(zhuǎn)回登錄界面。 用戶登錄后，每次請求服務(wù)器數(shù)據(jù)后session

43、 id都會改變。 注銷后用戶信息被清除。l 服務(wù)器測試 服務(wù)器運(yùn)行賬號不應(yīng)該是特權(quán)賬號或高級別權(quán)限賬號，如“root”“administrator”等。 未使用的端口應(yīng)為關(guān)閉狀態(tài)。 不能通過任何方式獲得服務(wù)器的詳細(xì)版本信息。l 數(shù)據(jù)注入測試當(dāng)系統(tǒng)接受數(shù)據(jù)注入時，可能會造成數(shù)據(jù)泄露、數(shù)據(jù)被修改等嚴(yán)重影響，導(dǎo)致業(yè)務(wù)中斷。 不存在注入點。 頁面中不包含類似系統(tǒng)命令的返回信息。3.7安裝測試安裝測試只針對c/s架構(gòu)的系統(tǒng)（即app），需要驗證app是否能正確安裝、運(yùn)行、卸載以及操作過程和操作前后對系統(tǒng)資源的使用情況。測試內(nèi)容l 安裝1）軟件在不同操作系統(tǒng)（android、ios）下安裝是否正常（手機(jī)端

44、）。2）軟件安裝后的是否能夠正常運(yùn)行，安裝后的文件夾及文件是否寫到了指定的目錄里。 3）軟件安裝各個選項的組合是否符合概要設(shè)計說明 4)）軟件安裝向?qū)У膗i測試 5）軟件安裝過程是否可以取消，點擊取消后，寫入的文件是否如概要設(shè)計說明處理 6）軟件安裝過程中意外情況的處理是否符合需求（如死機(jī)，重啟，斷電） 7）安裝空間不足時是否有相應(yīng)提示8）安裝后沒有生成多余的目錄結(jié)構(gòu)和文件9）對于需要通過網(wǎng)絡(luò)驗證之類的安裝，在斷網(wǎng)情況下嘗試一下10）還需要對安裝手冊進(jìn)行測試，依照安裝手冊是否能順利安裝l 卸載1）直接刪除安裝文件夾卸載是否有提示信息。 2）測試系統(tǒng)直接卸載程序是否有提示信息。 3）測試卸載后文

45、件是否全部刪除所有的安裝文件夾。4）卸載過程中出現(xiàn)的意外情況的測試（如死機(jī)、斷電、重啟）。 5）卸載是否支持取消功能，單擊取消后軟件卸載的情況 。6）系統(tǒng)直接卸載ui測試，是否有卸載狀態(tài)進(jìn)度條提示 。4.缺陷管理4.1缺陷提交規(guī)范4.1.1缺陷應(yīng)有的基本要素（*號為必須要素）*缺陷id（由系統(tǒng)自動生成，唯一的）*缺陷的標(biāo)題測試的軟件和硬件環(huán)境（特殊環(huán)境下可注明）*測試的軟件版本（缺陷發(fā)現(xiàn)版本和修復(fù)版本，發(fā)現(xiàn)版本是指當(dāng)前版本，修復(fù)版本一般由項目經(jīng)理確認(rèn)）*缺陷的類型（功能的、性能的、使用方面、安全的等等）*缺陷的嚴(yán)重程度（由測試人員確定） 缺陷的處理優(yōu)先級（一般由項目經(jīng)理確定）*復(fù)現(xiàn)缺陷的操作步

46、驟（操作步驟） 復(fù)現(xiàn)缺陷的測試數(shù)據(jù) （特定數(shù)據(jù)需要注明，比如特定的賬號）*缺陷的實際結(jié)果描述（錯誤描述）*期望的正確結(jié)果描述（期望結(jié)果）缺陷產(chǎn)生的原因分析 （如果測試人員能判定原因就給出，不能判定就無需給出，以免誤導(dǎo)開發(fā)人員）注釋文字和截取的缺陷圖像4.1.2缺陷的書寫規(guī)范l 缺陷標(biāo)題 1.標(biāo)題應(yīng)該保持簡短、準(zhǔn)確，提供缺陷的本質(zhì)信息，并便于讀者搜索查尋。2.良好的缺陷標(biāo)題應(yīng)該按照下列方式書寫： 盡量按缺陷發(fā)生的原因與結(jié)果的方式書寫（“執(zhí)行完a后，發(fā)生b，”或者“發(fā)生b， 當(dāng)a執(zhí)行完后”）3.避免使用模糊不清的詞語，例如“功能中斷，功能不正確，行為不起作用，”等。應(yīng)該使用具體文字說明功能如何中斷，如何不正確，或如何不起作用4.為了方便搜索和查詢，請使用關(guān)鍵字5.為了便于他人理解，避免使術(shù)語、