測試流程及測試?yán)碚摲椒y試流程1.軟件開發(fā)流程：需求分析—>概要設(shè)計(jì)—>詳細(xì)設(shè)計(jì)—>編碼開發(fā)—>測試—>維護(hù)2.測試流程為：單元測試/集成測試—>系統(tǒng)測試/自動(dòng)化測試—>性能測試—>驗(yàn)收測試 3.目標(biāo)：3.1制定完整且具體的測試路線和流程，為快速、高效和高質(zhì)量的軟件測試提供基礎(chǔ)流程框架。 3.2最終目標(biāo)是實(shí)現(xiàn)軟件測試規(guī)范化、標(biāo)準(zhǔn)化、自動(dòng)化。 4.測試流程說明：5.測試需求分析 測試需求是整個(gè)測試過程的基礎(chǔ)；確定測試對象以及測試工作的范圍和作用。用來確定整個(gè)測試工作（如安排時(shí)間表、測試設(shè)計(jì)等）并作為測試覆蓋的基礎(chǔ)。而且被確定的測試需求項(xiàng)必須是可核實(shí)的。即，它們必須有一個(gè)可觀察、可評(píng)測的結(jié)果。無法核實(shí)的需求不是測試需求。所以我現(xiàn)在的理解是測試需求是一個(gè)比較大的概念，它是在整個(gè)測試計(jì)劃文檔中體現(xiàn)出來的，不是類似的一個(gè)用例或者其他.·測試需求是制訂測試計(jì)劃的基本依據(jù)，確定了測試需求能夠?yàn)闇y試計(jì)劃提供客觀依據(jù)；·測試需求是設(shè)計(jì)測試用例的指導(dǎo)，確定了要測什么、測哪些方面后才能有針對性的設(shè)計(jì)測試用例；·測試需求是計(jì)算測試覆蓋的分母，沒有測試需求就無法有效地進(jìn)行測試覆蓋。白盒測試白盒也稱結(jié)構(gòu)測試，這是將軟件看成一個(gè)透明的白盒子，按照程序的內(nèi)部結(jié)構(gòu)和處理邏輯來選定測試用例，對軟件的邏輯路徑及過程進(jìn)行測試，檢查它與設(shè)計(jì)是否相符。性能測試性能測試，英文是PerformanceTesting。性能測試是在交替進(jìn)行負(fù)荷和強(qiáng)迫測試時(shí)常用的術(shù)語。理想的“性能測試”(和其他類型的測試)應(yīng)在需求文檔或質(zhì)量保證、測試計(jì)劃中定義。性能測試一般包括負(fù)載測試和壓力測試。通常驗(yàn)證軟件的性能在正常環(huán)境和系統(tǒng)條件下重復(fù)使用是否還能滿足性能指標(biāo)?；蛘邎?zhí)行同樣任務(wù)時(shí)新版本不比舊版本慢。一般還檢查系統(tǒng)記憶容量在運(yùn)行程序時(shí)會(huì)不會(huì)流失(memoryleak)。比如，驗(yàn)證程序保存一個(gè)巨大的文件新版本不比舊版本慢。5.1.2測試規(guī)范 測試規(guī)范是根據(jù)開發(fā)規(guī)范而制定的測試標(biāo)準(zhǔn)，測試規(guī)范也是后期測試用例編寫的重要依據(jù)。因?yàn)殚_發(fā)規(guī)范因公司而異，因產(chǎn)品而異，所以測試規(guī)范的標(biāo)準(zhǔn)程度每個(gè)公司都不一樣。從理論到方法到各類流程到各類報(bào)告模版，都屬于測試規(guī)范的范疇，當(dāng)一整套規(guī)范形成之后，可使得測試工作進(jìn)行更加穩(wěn)健，所有問題有據(jù)可查。5.2軟件需求規(guī)格說明書軟件需求規(guī)格說明書是軟件達(dá)到的各項(xiàng)功能的目標(biāo)。是測試人員各項(xiàng)工作的依據(jù)，沒有需求就無法判斷測試結(jié)果是正確的。5.3軟件設(shè)計(jì)說明（概要與詳細(xì)設(shè)計(jì)） 設(shè)計(jì)說明書包含軟件的一些框架、字段、數(shù)據(jù)庫設(shè)計(jì)等。軟件設(shè)計(jì)說明對測試工作開展有很大影響，沒有軟件設(shè)計(jì)說明很多問題將無法溯源，測試準(zhǔn)備的前期工作也是根據(jù)軟件設(shè)計(jì)說明來制定的。5.4頁面原型（demo）頁面原型是項(xiàng)目人員快速熟悉項(xiàng)目的最佳路徑。在需求不夠明確，設(shè)計(jì)說明書不夠全面的情況下，頁面原型也是后期測試用例編寫思想的重要根據(jù)。6.測試過程設(shè)計(jì) 明確測試目的，最終達(dá)成目的并驗(yàn)證結(jié)果是測試要做的事情。包括：測試范圍：描述本次測試中的測試范圍，如：測試軟件功能范圍、測試種類等。簡單的描述如何搭建測試平臺(tái)以及測試的潛在的風(fēng)險(xiǎn)。項(xiàng)目信息：說明要測試的項(xiàng)目的相關(guān)資料，如：輸入輸出文檔，產(chǎn)品描述，軟件主要功能。人力資源的分配。測試需求：籠統(tǒng)說，就是測試中的所有設(shè)計(jì)和需求文檔。作為本次測試的依據(jù)6.1測試策略制定這一階段在于需求、詳細(xì)設(shè)計(jì)、測試計(jì)劃完成之后，主要是本次測試的策略階段。很多公司缺少這個(gè)階段，需要有計(jì)劃性的分出產(chǎn)品的功能扣出測試的功能點(diǎn)，現(xiàn)階段大多公司都是直接拿著文檔就開始做用例設(shè)計(jì)。對需求進(jìn)行分析，列出具體的功能列表。（一般根據(jù)功能交互文檔就能明確出此功能的大體功能，一層層的分下去，一直到每個(gè)功能表單。然后考慮到使用哪些測試方法？工作一旦做到執(zhí)行階段，我們可以更好的根據(jù)這些功能表一點(diǎn)一點(diǎn)的覆蓋。也能讓我們在用例評(píng)審時(shí)，充分的證實(shí)我們的工作是有效的能夠保證產(chǎn)品的質(zhì)量。）一般在此之前，一些業(yè)務(wù)培訓(xùn)和需求評(píng)審是有必要是聽一下的。這樣能夠更早更熟練的理解需求，也能保證產(chǎn)品設(shè)計(jì)中出現(xiàn)的一些誤區(qū)。對于一個(gè)個(gè)測試該如何進(jìn)行測試？如下：功能測試功能范圍（劃分出各自負(fù)責(zé)的功能模塊）使用測試方法（等價(jià)類、邊界值等測試方法）測試標(biāo)準(zhǔn)（符合設(shè)計(jì)、需求和規(guī)范文檔對該功能的描述）界面測試兼容性測試性能測試6.2測試計(jì)劃要充分考慮測試計(jì)劃的實(shí)用性，即測試計(jì)劃與實(shí)際之間的接近程度和可操作性。編寫測試計(jì)劃的目的在于充分考慮執(zhí)行測試時(shí)的各種資源，包括測試內(nèi)容、測試標(biāo)準(zhǔn)、時(shí)間資源、人力資源等等，準(zhǔn)確地說是要分析執(zhí)行時(shí)所能夠調(diào)用的一切資源以及受各種條件限制，可能受到的各種影響。測試內(nèi)容：對一個(gè)軟件來說測試計(jì)劃中會(huì)明確本次測試做哪些測試？如：系統(tǒng)測試：在整個(gè)系統(tǒng)測試中會(huì)有（界面測試、功能測試、性能測試、兼容性測試、安裝卸載測試、可靠性測試等測試）。測試目的：一般多為保證產(chǎn)品質(zhì)量是否達(dá)到預(yù)期的指標(biāo)。這個(gè)指標(biāo)也就是在測試中定義的結(jié)束標(biāo)準(zhǔn)。測試標(biāo)準(zhǔn)：需要考慮本次測試需要輸入那些文檔，該項(xiàng)目結(jié)束標(biāo)準(zhǔn)定義、測試結(jié)束標(biāo)準(zhǔn)的定義？bug級(jí)別定義、優(yōu)先級(jí)定義、bug管理流程定義。這個(gè)都需要在執(zhí)行測試時(shí)明確。計(jì)劃中應(yīng)該包含這些內(nèi)容。資源分配：這里分為人力資源、軟硬件資源等劃分。一般會(huì)把人力資源的利用寫入一個(gè)測試人員任務(wù)分配表里，按照不同的階段，每個(gè)階段提交相應(yīng)的成果（難度很大）。軟硬件資源中主要是在做計(jì)劃時(shí)考慮到需要多少電腦或別的工具，列出清單。測試風(fēng)險(xiǎn)：大多考慮到的就是項(xiàng)目開發(fā)延期、測試人員不足用例無法全面覆蓋測試點(diǎn)、時(shí)間不足用例無法全部執(zhí)行、bug無法及時(shí)修改導(dǎo)致無法驗(yàn)證、測試人員技能不足導(dǎo)致測試進(jìn)度拉長。軟件測試策略一般都是分開來做相關(guān)測試方案。6.3測試附件用例模板、缺陷報(bào)告模板測試環(huán)境的搭建缺陷管理流程和缺陷級(jí)別定義缺陷狀態(tài)一般分為：新建、打開、已分配、已修復(fù)、關(guān)閉、重新打開中間會(huì)有：延期、重復(fù)、拒絕等狀態(tài) 缺陷管理流程： 測試人員或開發(fā)人員發(fā)現(xiàn)bug后，判斷輸入哪個(gè)模塊的問題，填寫bug報(bào)告后，系統(tǒng)會(huì)自動(dòng)通過Email通知開發(fā)組長和該模塊開發(fā)者。開發(fā)組長根據(jù)具體情況，重新reassigned分配給bug所屬的開發(fā)者。開發(fā)者收到email信息后，判斷是否為自己的修改范圍。若不是，重新reassigned分配給開發(fā)組長或應(yīng)該分配的開發(fā)者。若是，進(jìn)行處理，resolved并給出解決方法。（可創(chuàng)建補(bǔ)丁附件及補(bǔ)充說明）測試人員查詢開發(fā)者已修改的bug，進(jìn)行回歸測試。經(jīng)驗(yàn)證無誤后，修改狀態(tài)為verified。待整個(gè)產(chǎn)品發(fā)布后，修改為closed。還有問題，reopened，狀態(tài)重新變?yōu)椤皀ew”，并發(fā)送郵件通知。如果這個(gè)bug一周內(nèi)一直沒被處理過。Bugzilla就會(huì)一直用email騷擾它的屬主，直接采取行動(dòng)。管理員可以設(shè)定最遲采取行動(dòng)的期限，比如3天，系統(tǒng)默認(rèn)7天。缺陷等級(jí)劃分：分級(jí)Bug等級(jí)Bug等級(jí)說明分類說明致命問題Blocker導(dǎo)致整個(gè)產(chǎn)品無法進(jìn)行測試。修改優(yōu)先級(jí)為最高，該級(jí)別需要程序員立即修改○模塊無法啟動(dòng)或異常退出○其它導(dǎo)致無法測試的錯(cuò)誤Critical死機(jī)，數(shù)據(jù)丟失，主要功能完全喪失，系統(tǒng)懸掛等錯(cuò)誤。修改優(yōu)先級(jí)為最高，該級(jí)別需要程序員立即修改○運(yùn)行過程中系統(tǒng)崩潰/死機(jī)/重啟○功能設(shè)計(jì)與需求嚴(yán)重不符○嚴(yán)重花屏○內(nèi)存泄漏○影響手機(jī)語音或數(shù)據(jù)通訊等○嚴(yán)重的數(shù)值計(jì)算錯(cuò)誤嚴(yán)重問題Major主要功能喪失，導(dǎo)致嚴(yán)重的問題，或致命的錯(cuò)誤聲明。修改優(yōu)先級(jí)為高，該級(jí)別需要程序員盡快修改○功能未實(shí)現(xiàn)或者存在錯(cuò)誤○輕微的數(shù)值計(jì)算錯(cuò)誤○系統(tǒng)所提供的功能或服務(wù)受明顯的影響○用戶數(shù)據(jù)丟失或破壞一般問題Normal次要功能喪失，不太嚴(yán)重，如提示信息不太準(zhǔn)確。修改優(yōu)先級(jí)為中，該級(jí)別需要程序員修改○操作界面錯(cuò)誤（包括數(shù)據(jù)窗口內(nèi)列名定義、含義是否一致）○邊界條件下錯(cuò)誤○功能存在錯(cuò)誤，但出現(xiàn)概率很低○提示信息錯(cuò)誤（包括未給出信息、信息提示錯(cuò)誤等）○長時(shí)間操作無進(jìn)度提示○系統(tǒng)未優(yōu)化（性能問題）Minor微小的問題，對功能幾乎沒有影響，產(chǎn)品及屬性仍可使用。修改優(yōu)先級(jí)為低，該級(jí)別需要程序員修改或不修改○界面格式等不規(guī)范○操作時(shí)未給用戶提示○文字排列不整齊等一些小問題○光標(biāo)跳轉(zhuǎn)設(shè)置不好，鼠標(biāo)（光標(biāo)）定位錯(cuò)誤輕微問題Trivial提示信息格式不符合要求,違背正常習(xí)俗習(xí)慣的，界面不美觀，控件排列、格式不統(tǒng)一○輔助說明描述不清楚○個(gè)別不影響產(chǎn)品理解的錯(cuò)別字○可輸入?yún)^(qū)域和只讀區(qū)域沒有明顯的區(qū)分標(biāo)志Enhancement功能性建議，功能使用性、方便性、易用性不夠○建議7.測試實(shí)施7.1執(zhí)行開發(fā)就會(huì)轉(zhuǎn)版本給我們測試部門進(jìn)行系統(tǒng)測試了。拿到版本我們首先搭建測試環(huán)境做一個(gè)預(yù)測試，目的是來評(píng)斷這個(gè)版本是不是可測試的。如果預(yù)測試不通過，打回開發(fā)部返工，如果通過了，就開始我們第一輪的系統(tǒng)測試。第一輪系統(tǒng)測試我們會(huì)執(zhí)行我們所編寫的所有測試用例，做好測試結(jié)果的記錄，發(fā)現(xiàn)缺陷了提交缺陷報(bào)告。當(dāng)?shù)谝惠啘y試結(jié)束后，我們把所有的bug單提交給開發(fā)人員，由他們進(jìn)行修改。在他們修復(fù)bug期間，我們會(huì)對第一輪系統(tǒng)測試做一個(gè)測試評(píng)估，出一個(gè)測試報(bào)告。還要根據(jù)實(shí)際情況，對我們寫的測試用例進(jìn)行修改和增加。開發(fā)改bug結(jié)束，提交一個(gè)新的版本給我們，我們重新搭建測試環(huán)境開始第二輪系統(tǒng)測試。首先是回歸我們提交的缺陷報(bào)告，然后會(huì)在用例中挑選一些優(yōu)先級(jí)別比較高的用例來進(jìn)行測試，發(fā)現(xiàn)問題了繼續(xù)提交缺陷報(bào)告，直到缺陷率低于用戶要求了，我們就進(jìn)行最后一輪的回歸測試，結(jié)束系統(tǒng)測試。具體測試輪次是根據(jù)版本質(zhì)量和項(xiàng)目復(fù)雜度而決定的。8.測試評(píng)估執(zhí)行階段結(jié)束了進(jìn)入測試評(píng)估階段，我們會(huì)出一個(gè)總的測試報(bào)告對我們測試的這個(gè)過程和版本的質(zhì)量做一個(gè)詳細(xì)的評(píng)估需求需要評(píng)審那些？用例需要評(píng)審那些？計(jì)劃應(yīng)該評(píng)審那些？缺陷評(píng)審那些？bug評(píng)估？測試總結(jié)報(bào)告文檔的輸出：1、可以讓具體的任務(wù)負(fù)責(zé)人對本次測試中個(gè)人負(fù)責(zé)的?？爝M(jìn)行評(píng)價(jià)，提出相關(guān)建議。給出總體的評(píng)估2、整體上的bug按照不同等級(jí)統(tǒng)計(jì)出來、用例數(shù)量、用例執(zhí)行數(shù)量3、對項(xiàng)目中測試