軟件測(cè)試基本流程與規(guī)范

軟件測(cè)試基本流程與規(guī)范目標(biāo)制定完整且具體的測(cè)試路線和流程，為快速、高效和高質(zhì)量的軟件測(cè)試提供基礎(chǔ)流程框架。最終目標(biāo)是實(shí)現(xiàn)軟件測(cè)試規(guī)范化，標(biāo)準(zhǔn)化。測(cè)試流程說(shuō)明測(cè)試需求分析測(cè)試需求是整個(gè)測(cè)試過(guò)程的基礎(chǔ)；確定測(cè)試對(duì)象以及測(cè)試工作的范圍和作用。用來(lái)確定整個(gè)測(cè)試工作（如安排時(shí)間表、測(cè)試設(shè)計(jì)等）并作為測(cè)試覆蓋的基礎(chǔ)。而且被確定的測(cè)試需求項(xiàng)必須是可核實(shí)的。即，它們必須有一個(gè)可觀察、可評(píng)測(cè)的結(jié)果。無(wú)法核實(shí)的需求不是測(cè)試需求。所以我現(xiàn)在的理解是測(cè)試需求是一個(gè)比較大的概念，它是在整個(gè)測(cè)試計(jì)劃文檔中體現(xiàn)出來(lái)的，不是類似的一個(gè)用例或者其他.·測(cè)試需求是制訂測(cè)試計(jì)劃的基本依據(jù)，確定了測(cè)試需求能夠?yàn)闇y(cè)試計(jì)劃提供客觀依據(jù)；·測(cè)試需求是設(shè)計(jì)測(cè)試用例的指導(dǎo)，確定了要測(cè)什么、測(cè)哪些方面后才能有針對(duì)性的設(shè)計(jì)測(cè)試用例；·測(cè)試需求是計(jì)算測(cè)試覆蓋的分母，沒有測(cè)試需求就無(wú)法有效地進(jìn)行測(cè)試覆蓋；測(cè)試方法與規(guī)范測(cè)試方法隨著軟件技術(shù)發(fā)展，項(xiàng)目類型越來(lái)越多樣化。根據(jù)項(xiàng)目類型應(yīng)選用針對(duì)性強(qiáng)的測(cè)試方法，合適的測(cè)試方法可以讓我們事半功倍。以下是針對(duì)目前項(xiàng)目工程可以參考的測(cè)試方法：β測(cè)試（beta測(cè)試）--非程序員、測(cè)試人員β測(cè)試，英文是Betatesting。又稱Beta測(cè)試，用戶驗(yàn)收測(cè)試（UAT）。β測(cè)試是軟件的多個(gè)用戶在一個(gè)或多個(gè)用戶的實(shí)際使用環(huán)境下進(jìn)行的測(cè)試。開發(fā)者通常不在測(cè)試現(xiàn)場(chǎng)，Beta測(cè)試不能由程序員或測(cè)試員完成。當(dāng)開發(fā)和測(cè)試根本完成時(shí)所做的測(cè)試，而最終的錯(cuò)誤和問題需要在最終發(fā)行前找到。這種測(cè)試一般由最終用戶或其他人員完成，不能由程序員或測(cè)試員完成。α測(cè)試（Alpha測(cè)試）--非程序員、測(cè)試人員α測(cè)試，英文是Alphatesting。又稱Alpha測(cè)試.Alpha測(cè)試是由一個(gè)用戶在開發(fā)環(huán)境下進(jìn)行的測(cè)試，也可以是公司內(nèi)部的用戶在模擬實(shí)際操作環(huán)境下進(jìn)行的受控測(cè)試，Alpha測(cè)試不能由該系統(tǒng)的程序員或測(cè)試員完成。在系統(tǒng)開發(fā)接近完成時(shí)對(duì)應(yīng)用系統(tǒng)的測(cè)試;測(cè)試后，仍然會(huì)有少量的設(shè)計(jì)變更。這種測(cè)試一般由最終用戶或其他人員來(lái)完成，不能由程序員或測(cè)試員完成。兼容性測(cè)試--測(cè)試人員兼容性測(cè)試是指測(cè)試軟件是否可以成功移植到指定的硬件或者軟件環(huán)境中，例如在B/S項(xiàng)目中各個(gè)不同瀏覽器之間的測(cè)試。用戶界面測(cè)試-UI測(cè)試--測(cè)試人員用戶界面測(cè)試，英文是Userinterfacetesting。又稱UI測(cè)試。用戶界面，英文是Userinterface。是指軟件中的可見外觀及其底層與用戶交互的部分（菜單、對(duì)話框、窗口和其它控件）。方法？工作一旦做到執(zhí)行階段，我們可以更好的根據(jù)這些功能表一點(diǎn)一點(diǎn)的覆蓋。也能讓我們?cè)谟美u(píng)審時(shí)，充分的證實(shí)我們的工作是有效的能夠保證產(chǎn)品的質(zhì)量。）一般在此之前，一些業(yè)務(wù)培訓(xùn)和需求評(píng)審是有必要是聽一下的。這樣能夠更早更熟練的理解需求，也能保證產(chǎn)品設(shè)計(jì)中出現(xiàn)的一些誤區(qū)。對(duì)于一個(gè)個(gè)測(cè)試該如何進(jìn)行測(cè)試？如下：功能測(cè)試功能范圍（劃分出各自負(fù)責(zé)的功能模塊）使用測(cè)試方法（等價(jià)類、邊界值等測(cè)試方法方法）測(cè)試標(biāo)準(zhǔn)（符合設(shè)計(jì)、需求和規(guī)范文檔對(duì)該功能的描述）界面測(cè)試兼容性測(cè)試測(cè)試計(jì)劃要充分考慮測(cè)試計(jì)劃的實(shí)用性，即測(cè)試計(jì)劃與實(shí)際之間的接近程度和可操作性。編寫測(cè)試計(jì)劃的目的在于充分考慮執(zhí)行測(cè)試時(shí)的各種資源，包括測(cè)試內(nèi)容、測(cè)試標(biāo)準(zhǔn)、時(shí)間資源、人力資源等等，準(zhǔn)確地說(shuō)是要分析執(zhí)行時(shí)所能夠調(diào)用的一切資源以及受各種條件限制，可能受到的各種影響。測(cè)試內(nèi)容：對(duì)一個(gè)軟件來(lái)說(shuō)測(cè)試計(jì)劃中會(huì)明確本次測(cè)試做哪些測(cè)試？如：系統(tǒng)測(cè)試：在整個(gè)系統(tǒng)測(cè)試中會(huì)有（界面測(cè)試、功能測(cè)試、性能測(cè)試、兼容性測(cè)試、安裝卸載測(cè)試、可靠性測(cè)試等測(cè)試）。測(cè)試目的：一般多為保證產(chǎn)品質(zhì)量是否達(dá)到預(yù)期的指標(biāo)。這個(gè)指標(biāo)也就是在測(cè)試中定義的結(jié)束標(biāo)準(zhǔn)。測(cè)試標(biāo)準(zhǔn)：需要考慮本次測(cè)試需要輸入那些文檔，該項(xiàng)目結(jié)束標(biāo)準(zhǔn)定義、測(cè)試結(jié)束標(biāo)準(zhǔn)的定義？bug級(jí)別定義、優(yōu)先級(jí)定義、bug管理流程定義。這個(gè)都需要在執(zhí)行測(cè)試事明確。計(jì)劃中應(yīng)該包含這些內(nèi)容。資源分配：這里分為人力資源、軟硬件資源等劃分。一般會(huì)把人力資源的利用寫入一個(gè)測(cè)試人員任務(wù)分配表里，按照不同的階段，每個(gè)階段提交相應(yīng)的成果（難度很大）。軟硬件資源中主要是在做計(jì)劃時(shí)考慮到需要多少電腦或別的工具，列出清單。測(cè)試風(fēng)險(xiǎn)：大多考慮到的就是項(xiàng)目開發(fā)延期、測(cè)試人員不足用例無(wú)法全面覆蓋測(cè)試點(diǎn)、時(shí)間不足用例無(wú)法全部執(zhí)行、bug無(wú)法及時(shí)修改導(dǎo)致無(wú)法驗(yàn)證、測(cè)試人員技能不足導(dǎo)致測(cè)試進(jìn)度拉長(zhǎng)。軟件測(cè)試策略一般都是分開來(lái)做相關(guān)測(cè)試方案。。測(cè)試附件用例模板、缺陷報(bào)告模板測(cè)試環(huán)境的搭建缺陷管理流程和缺陷級(jí)別定義缺陷狀態(tài)一般分為：新建、打開、已分配、已修復(fù)、關(guān)閉、重新打開中間會(huì)有：延期、重復(fù)、拒絕等狀態(tài)缺陷管理流程：測(cè)試人員或開發(fā)人員發(fā)現(xiàn)bug后，判斷輸入哪個(gè)模塊的問題，填寫bug報(bào)告后，系統(tǒng)會(huì)自動(dòng)通過(guò)Email通知開發(fā)組長(zhǎng)和該模塊開發(fā)者。開發(fā)組長(zhǎng)根據(jù)具體情況，重新reassigned分配給bug所屬的開發(fā)者。開發(fā)者收到email信息后，判斷是否為自己的修改范圍。若不是，重新reassigned分配給開發(fā)組長(zhǎng)或應(yīng)該分配的開發(fā)者。若是，進(jìn)行處理，resolved并給出解決方法。（可創(chuàng)建補(bǔ)丁附件及補(bǔ)充說(shuō)明）測(cè)試人員查詢開發(fā)者已修改的bug，進(jìn)行回歸測(cè)試。經(jīng)驗(yàn)證無(wú)誤后，修改狀態(tài)為verified。待整個(gè)產(chǎn)品發(fā)布后，修改為closed。還有問題，reopened，狀態(tài)重新變?yōu)椤皀ew”，并發(fā)送郵件通知。如果這個(gè)bug一周內(nèi)一致沒被處理過(guò)。Bugzilla就會(huì)一直用email騷擾它的屬主，直接采取行動(dòng)。管理員可以設(shè)定最遲采取行動(dòng)的期限，比如3天，系統(tǒng)默認(rèn)7天。缺陷等級(jí)劃分：分級(jí)Bug等級(jí)Bug等級(jí)說(shuō)明分類說(shuō)明致命問題Blocker導(dǎo)致整個(gè)產(chǎn)品無(wú)法進(jìn)行測(cè)試。修改優(yōu)先級(jí)為最高，該級(jí)別需要程序員立即修改○模塊無(wú)法啟動(dòng)或異常退出○其它導(dǎo)致無(wú)法測(cè)試的錯(cuò)誤Critical死機(jī)，數(shù)據(jù)丟失，主要功能完全喪失，系統(tǒng)懸掛等錯(cuò)誤。修改優(yōu)先級(jí)為最高，該級(jí)別需要程序員立即修改○運(yùn)行過(guò)程中系統(tǒng)崩潰/死機(jī)/重啟○功能設(shè)計(jì)與需求嚴(yán)重不符○嚴(yán)重花屏○內(nèi)存泄漏○影響手機(jī)語(yǔ)音或數(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ò)誤等）○長(zhǎng)時(shí)間操作無(wú)進(jìn)度提示○系統(tǒng)未優(yōu)化（性能問題）Minor微小的問題，對(duì)功能幾乎沒有影響，產(chǎn)品及屬性仍可使用。修改優(yōu)先級(jí)為低，該級(jí)別需要程序員修改或不修改○界面格式等不規(guī)范○操作時(shí)未給用戶提示○文字排列不整齊等一些小問題○光標(biāo)跳轉(zhuǎn)設(shè)置不好，鼠標(biāo)（光標(biāo)）定位錯(cuò)誤輕微問題Trivial提示信息格式不符合要求,違背正常習(xí)俗習(xí)慣的，界面不美觀，控件排列、格式不統(tǒng)一○輔助說(shuō)明描述不清楚○個(gè)別不影響產(chǎn)品理解的錯(cuò)別字○可輸入?yún)^(qū)域和只讀區(qū)域沒有明顯的區(qū)分標(biāo)志Enhancement功能性建議，功能使用性、方便性、易用性不夠○建議測(cè)試實(shí)施執(zhí)行開發(fā)就會(huì)轉(zhuǎn)版本給我們測(cè)試部門進(jìn)行系統(tǒng)測(cè)試了。拿到版本我們首先搭建測(cè)試環(huán)境做一個(gè)預(yù)測(cè)試，目的是來(lái)評(píng)斷這個(gè)版本是不是可測(cè)試的。如果預(yù)測(cè)試不通過(guò)，打回開發(fā)部返工，如果通過(guò)了，就開始我們第一輪的系統(tǒng)測(cè)試。第一輪系統(tǒng)測(cè)試我們會(huì)執(zhí)行我們所編寫的所有測(cè)試用例，做好測(cè)試結(jié)果的記錄，發(fā)現(xiàn)缺陷了提交缺陷報(bào)告。當(dāng)?shù)谝惠啘y(cè)試結(jié)束后，我們把所有的bug單提交給開發(fā)人員，由他們進(jìn)行修改。在他們修復(fù)bug期間，我們會(huì)對(duì)第一輪系統(tǒng)測(cè)試做一個(gè)測(cè)試評(píng)估，出一個(gè)測(cè)試報(bào)告。還要根據(jù)實(shí)際情況，對(duì)我們寫的測(cè)試用例進(jìn)行修改和增加。開發(fā)改bug結(jié)束，提交一個(gè)新的版本給我們，我們重新搭建測(cè)試環(huán)境開始第二輪系統(tǒng)測(cè)試。首先是回歸我們提交的缺陷報(bào)告，然后會(huì)在用例中挑選一些優(yōu)先級(jí)別比較高的用例來(lái)進(jìn)行測(cè)試，發(fā)現(xiàn)問題了繼續(xù)提交缺陷報(bào)告，只到缺陷率低于用戶要求了，我們就進(jìn)行最后一輪的回歸測(cè)試，結(jié)束系統(tǒng)測(cè)試。具體測(cè)試輪次是根據(jù)版本質(zhì)量和項(xiàng)目復(fù)雜度而決定的。測(cè)試評(píng)估執(zhí)行階段結(jié)束了進(jìn)入測(cè)試評(píng)估階段，我們會(huì)出一個(gè)總的測(cè)試報(bào)告對(duì)我們測(cè)試的這個(gè)過(guò)程和版本的質(zhì)量做一個(gè)詳細(xì)的評(píng)估需求需要評(píng)審那些？用例需要評(píng)審那些？計(jì)劃應(yīng)該評(píng)審那些？缺陷評(píng)審那些？bug評(píng)估？測(cè)試總結(jié)報(bào)告文檔的輸出：1、可以讓具體的任務(wù)負(fù)責(zé)人對(duì)該本次測(cè)試中個(gè)人負(fù)責(zé)的模快進(jìn)行評(píng)價(jià)，提出相關(guān)建議。給出總體的評(píng)估2、整體上的bug按照不同等級(jí)統(tǒng)計(jì)出來(lái)、用例數(shù)量、用例執(zhí)行數(shù)量3、對(duì)項(xiàng)目中測(cè)試人力資源的統(tǒng)計(jì)。（單位：人/天）4、項(xiàng)目中軟硬件