原創(chuàng)作者：jerry
來自Sawin軟件研發(fā)之窗
最后修改時間：2007-8-31
冒煙測試是指開發(fā)團(tuán)隊提交給測試團(tuán)隊進(jìn)行測試的前期，測試團(tuán)隊檢查產(chǎn)品的主要功能是否實現(xiàn)，是否有影響產(chǎn)品正常運(yùn)行的錯誤。如果存在這些問題，測試團(tuán)隊有權(quán)退回測試任務(wù)給開發(fā)組，開發(fā)組重新組織單元和集成測試。
又叫衰竭測試，測試人員對已經(jīng)測試過的內(nèi)容進(jìn)行重新測試的活動。因為經(jīng)過一輪測試以后測試組發(fā)現(xiàn)一些缺陷，開發(fā)人員在修改這些缺陷的同時勢必會引起其他缺陷的發(fā)生，回歸測試主要就是測試這些新缺陷的活動。
基于一個應(yīng)用代碼的內(nèi)部邏輯知識，測試是基于覆蓋全部代碼、分支、路徑、條件
不基于內(nèi)部設(shè)計和代碼的任何知識，而是基于需求和功能性。
最微小規(guī)模的測試;以測試某個功能或代碼塊。典型地由程序員而非測試員來做，因為它需要知道內(nèi)部程序設(shè)計和編碼的細(xì)節(jié)知識。這個工作不容易作好，除非應(yīng)用系統(tǒng)有一個設(shè)計很好的體系結(jié)構(gòu); 還可能需要開發(fā)測試驅(qū)動器模塊或測試樁。
一個應(yīng)用系統(tǒng)的各個部件的聯(lián)合測試，以決定他們能否在一起共同工作。部件可以是代碼塊、獨立的應(yīng)用、網(wǎng)絡(luò)上的客戶端或服務(wù)器端程序。這種類型的測試尤其與客戶服務(wù)器和分布式系統(tǒng)有關(guān)。集成方法由自上而下，自下而上，混合三種方式。
用于測試應(yīng)用系統(tǒng)的功能需求的黑盒測試方法。這類測試應(yīng)由測試員做，這并不意味著程序員在發(fā)布前不必檢查他們的代碼能否工作(自然他能用于測試的各個階段)。
基于系統(tǒng)整體需求說明書的黑盒類測試;應(yīng)覆蓋系統(tǒng)所有聯(lián)合的部件
測試不運(yùn)行的部分————只是檢查和審閱。
通常意義上的測試————運(yùn)行和使用軟件。
指正規(guī)測試完畢后由公司內(nèi)部人員充當(dāng)客戶進(jìn)行測試；
指產(chǎn)品在推出之前，給一些友好客戶使用，讓他們來進(jìn)行測試。
圖一 缺陷管理流程
1. 測試人員發(fā)現(xiàn)一個缺陷，設(shè)置狀態(tài)為New；
2. 提交給缺陷控制人員；
3. 缺陷控制人員判斷這個缺陷是否為缺陷；
4. 如果不是設(shè)置狀態(tài)為Invalid；
5. 否則判斷這個缺陷在本輪測試中是否可以修改；
6. 如果暫時不能不能修改，保持狀態(tài)New；
7. 否則設(shè)置狀態(tài)為Assigned；
8. 將Assigned的缺陷交給開發(fā)人員修改；
9. 修改完畢，設(shè)置狀態(tài)為Fixed；
10. 測試人員復(fù)測標(biāo)記為Fixed的缺陷；
11. 復(fù)測是否成功；
12. 復(fù)測成功，設(shè)置狀態(tài)為Closed；
13. 否則設(shè)置狀態(tài)為ReOpen；
14. 返回步驟8
（SEI TSP國際標(biāo)準(zhǔn)）
1. 每次測試開始，開發(fā)部門提出測試重點，開發(fā)機(jī)版本同步到測試機(jī)器上；
2. 測試人員進(jìn)行冒煙測試，如果冒煙測試沒有通過退回給開發(fā)部門，等待開發(fā)部門重新提交測試任務(wù)，返回第1步；
3. 否則測試人員執(zhí)行測試活動；
4. 開發(fā)人員修改被確認(rèn)的缺陷（狀態(tài)為Assigned）；
5. 當(dāng)測試人員認(rèn)為測試結(jié)束，大部分缺陷都發(fā)現(xiàn)完畢，開發(fā)機(jī)上版本第二次同步到測試機(jī)器上；
6. 測試人員對缺陷進(jìn)行復(fù)測，標(biāo)記為ReOpen或Closed；
7. 開發(fā)人員對于ReOpen的缺陷進(jìn)行修改；
8. 復(fù)測期間每天晚上將開發(fā)機(jī)器上的版本同步到測試機(jī)器上；
9. 如果所有Open，ReOpen的缺陷都Closed掉，本輪測試結(jié)束，回到第1步進(jìn)行新的一輪回歸測試；
10. 當(dāng)一輪測試中發(fā)現(xiàn)的缺陷不存在Blocker，Critical，Major，Normal的缺陷，或者M(jìn)inor，Trivial，Enhancement的缺陷少于10個，測試機(jī)器上的版本同步到發(fā)布機(jī)器上，測試任務(wù)完成。
Ø Blocker：（阻礙的）
阻礙開發(fā)和/或測試工作，冒煙測試沒有通過，不能夠進(jìn)行正常的測試工作
Ø Critical：（緊急的）
系統(tǒng)無法測試，或者系統(tǒng)無法繼續(xù)操作，應(yīng)用系統(tǒng)異常中止
對操作系統(tǒng)造成嚴(yán)重影響，系統(tǒng)死機(jī)，被測程序掛起，不響應(yīng)等
造成重大安全隱患情況（如機(jī)密性數(shù)據(jù)的泄密）
功能沒有實現(xiàn)，無法進(jìn)行某一個功能操作，影響系統(tǒng)使用
Ø Major：（重大的）
功能基本實現(xiàn)，但在特定情況下導(dǎo)致功能失敗
導(dǎo)致輸出的數(shù)據(jù)錯誤（數(shù)據(jù)內(nèi)容出錯、格式錯誤、無法打開等）
導(dǎo)致其它功能模塊無法正常執(zhí)行
功能不完整或者功能實現(xiàn)不正確
導(dǎo)致數(shù)據(jù)最終操作結(jié)果錯誤
Ø Normal：(普通的)
功能部分失敗，對整體功能的實現(xiàn)基本不造成影響。
Ø Minor：（較小的）
鏈接錯誤、系統(tǒng)出錯提示不正確或沒有捕獲系統(tǒng)出錯信息、數(shù)據(jù)的重要操作（添加、刪除、修改）沒有提示、出現(xiàn)頻率極低，會對功能實現(xiàn)造成非致命影響。
Ø Trivial：（外觀的）
產(chǎn)品外觀上的問題或一些不影響使用的小毛病，如菜單或?qū)υ捒蛑械奈淖制磳懟蜃煮w問題等等
Ø Enhancement(改進(jìn)的)
對于系統(tǒng)產(chǎn)品建議或意見
Ø P5：嚴(yán)重級別比較高的，影響測試進(jìn)行或者系統(tǒng)無法繼續(xù)操作
Ø P4：對系統(tǒng)操作有影響，但是不需要馬上修改
Ø P3：頁面缺陷（不屬于定義的缺陷范圍）或者建議
Ø P2：準(zhǔn)備在下一輪測試前修改完畢
Ø P1：準(zhǔn)備在下一版本中修改
在內(nèi)容中分別按下面格式進(jìn)行書寫
Bug所處的模塊
出現(xiàn)bug的詳細(xì)描述
bug現(xiàn)象
bug總結(jié)
|
編號
|
Chinafi_***_XXX
|
|
前置條件
|
|
|
說明
|
|
|
項號
|
測試步驟
|
顯示結(jié)果
|
是否通過
|
概要說明
|
|
1
|
1,
|
|
|
|
|
|
2，
|
|
|
|
|
|
3，
|
|
|
|
|
|
4，
|
|
|
|
|
|
5，
|
|
|
|
|
2
|
1，
|
|
|
|
|
|
2，
|
|
|
|
|
|
3，
|
|
|
|
|
|
4，
|
|
|
|
|
|
5，
|
|
|
|
|
|
6，
|
|
|
|
|
|
7，
|
|
|
|
|
|
8,
|
|
|
|
|
|
9，
|
|
|
|
編號格式：”Chinafi_”+ModuleName+”_”+XXX:
1. Chinafi 為固定的開始字符；
2. ModuleName:為模塊名，首字母大寫，字母之間以_隔開；
3. XXX：為3位0-9的字母；
前置條件：完成此項測試，哪些模塊的功能必須正確，那些資源必須到位等前提條件；
說明：測試項目的描述；
項號：一個測試中包括可幾個項目，每個項目的編號；
測試步驟：完成測試的具體步驟描述；
顯示結(jié)果：對于一些重要步驟的頁面顯示結(jié)果，每一項最后一步的顯示結(jié)果必須書寫；
是否通過：Y測試通過，N測試未通過；
概要說明：對于測試過程中的一些說明注解。
|
編號
|
Chinafi_Storeroom_Overview_002
|
|
前置條件
|
我?guī)旃芾韀test]功能正常
|
|
說明
|
大庫概況功能調(diào)整(具體人才信息，實時改為每天凌晨自動執(zhí)行)
|
|
項號
|
測試步驟
|
顯示結(jié)果
|
是否通過
|
概要說明
|
|
1
|
1,進(jìn)入系統(tǒng)
|
|
|
|
|
|
2，進(jìn)入人才/我?guī)旃芾?/div>
|
|
|
|
|
|
3，按[test]
|
|
|
|
|
|
4，進(jìn)入人才/大庫概況
|
|
|
|
|
|
5，點沒入自動庫人數(shù)小計中的數(shù)據(jù)
|
頁面顯示速度很快，并且沒有功能錯誤
|
Y
|
正式機(jī)器上調(diào)用為二十幾秒，140機(jī)器上為5，6秒
|
|
2
|
1，進(jìn)入系統(tǒng)
|
|
|
|
|
|
2，進(jìn)入人才/大庫概況
|
|
|
|
|
|
3，統(tǒng)計沒有進(jìn)入自動庫人數(shù)統(tǒng)計
|
結(jié)果為N
|
|
|
|
|
4，到案管/我的人才庫中尋找一條只有進(jìn)入一個人才庫的人才
|
|
|
|
|
|
5，點訪這個人才
|
|
|
|
|
|
6，將這個人才剔除
|
|
|
|
|
|
7，執(zhí)行人才/我?guī)旃芾碇械腫test]
|
|
|
|
|
|
8, 進(jìn)入人才/大庫概況
|
|
|
|
|
|
9，統(tǒng)計沒有進(jìn)入自動庫人數(shù)統(tǒng)計
|
結(jié)果為N+1
|
Y
|
|
在項目名稱中，數(shù)據(jù)庫和數(shù)據(jù)庫進(jìn)程應(yīng)作為一個子系統(tǒng)來進(jìn)行測試。在測試這些子系統(tǒng)時，不應(yīng)將測試對象的用戶界面用作數(shù)據(jù)的接口。對于數(shù)據(jù)庫管理系統(tǒng) (DBMS)，還需要進(jìn)行深入的研究，以確定可以支持以下測試的工具和技術(shù)。
對測試對象的功能測試應(yīng)側(cè)重于所有可直接追蹤到用例或業(yè)務(wù)功能和業(yè)務(wù)規(guī)則的測試需求。這種測試的目標(biāo)是核實數(shù)據(jù)的接受、處理和檢索是否正確，以
及業(yè)務(wù)規(guī)則的實施是否恰當(dāng)。此類測試基于黑盒技術(shù)，該技術(shù)通過圖形用戶界面 (GUI)
與應(yīng)用程序進(jìn)行交互，并對交互的輸出或結(jié)果進(jìn)行分析，以此來核實應(yīng)用程序及其內(nèi)部進(jìn)程。以下為各種應(yīng)用程序列出了推薦使用的測試概要：
用戶界面 (UI) 測試用于核實用戶與軟件之間的交互。UI 測試的目標(biāo)是確保用戶界面會通過測試對象的功能來為用戶提供相應(yīng)的訪問或瀏覽功能。另外，UI 測試還可確保 UI 中的對象按照預(yù)期的方式運(yùn)行，并符合公司或行業(yè)的標(biāo)準(zhǔn)。包括用戶友好性，人性化測試。
負(fù)載測試是一種性能測試。在這種測試中，將使測試對象承擔(dān)不同的工作量，以評測和評估測試對象在不同工作量條件下的性能行為，以及持續(xù)正常運(yùn)行
的能力。負(fù)載測試的目標(biāo)是確定并確保系統(tǒng)在超出最大預(yù)期工作量的情況下仍能正常運(yùn)行。此外，負(fù)載測試還要評估性能特征，例如，響應(yīng)時間、事務(wù)處理速率和其
他與時間相關(guān)的方面。
是一種性能測試，實施和執(zhí)行此類測試的目的是找出因資源不足或資源爭用而導(dǎo)致的錯誤。如果內(nèi)存或磁盤空間不足，測試對象就可能會表現(xiàn)出一些在正
常條件下并不明顯的缺陷。而其他缺陷則可能由于爭用共享資源（如數(shù)據(jù)庫鎖或網(wǎng)絡(luò)帶寬）而造成的。強(qiáng)度測試還可用于確定測試對象能夠處理的最大工作量。
容量測試使測試對象處理大量的數(shù)據(jù)，以確定是否達(dá)到了將使軟件發(fā)生故障的極限。容量測試還將確定測試對象在給定時間內(nèi)能夠持續(xù)處理的最大負(fù)載或
工作量。例如，如果測試對象正在為生成一份報表而處理一組數(shù)據(jù)庫記錄，那么容量測試就會使用一個大型的測試數(shù)據(jù)庫，檢驗該軟件是否正常運(yùn)行并生成了正確的
報表。
與競爭伙伴的產(chǎn)品的比較測試，如軟件的弱點、優(yōu)點或?qū)嵙Α?/div>
對“用戶友好性”的測試。顯然這是主觀的，且將取決于目標(biāo)最終用戶或客戶。用戶面談、調(diào)查、用戶對話的錄象和其他一些技術(shù)都可使用。程序員和測試員通常都不宜作可用性測試員。
對軟件的全部、部分或升級安裝/卸載處理過程的測試。
可確保測試對象能成功完成故障轉(zhuǎn)移，并能從導(dǎo)致意外數(shù)據(jù)損失或數(shù)據(jù)完整性破壞的各種硬件、軟件或網(wǎng)絡(luò)故障中恢復(fù)。
故障轉(zhuǎn)移測試可確保：對于必須持續(xù)運(yùn)行的系統(tǒng)，一旦發(fā)生故障，備用系統(tǒng)就將不失時機(jī)地“頂替”發(fā)生故障的系統(tǒng)，以避免丟失任何數(shù)據(jù)或事務(wù)。
恢復(fù)測試是一種對抗性的測試過程。在這種測試中，將把應(yīng)用程序或系統(tǒng)置于極端的條件下（或者是模擬的極端條件下），以產(chǎn)生故障（例如設(shè)備輸入/
輸出 (I/O) 故障或無效的數(shù)據(jù)庫指針和關(guān)健字）。然后調(diào)用恢復(fù)進(jìn)程并監(jiān)測和檢查應(yīng)用程序和系統(tǒng)，核實應(yīng)用程序或系統(tǒng)和數(shù)據(jù)已得到了正確的恢復(fù)。
安全性和訪問控制測試側(cè)重于安全性的兩個關(guān)鍵方面：
應(yīng)用程序級別的安全性，包括對數(shù)據(jù)或業(yè)務(wù)功能的訪問
系統(tǒng)級別的安全性，包括對系統(tǒng)的登錄或遠(yuǎn)程訪問。
應(yīng)用程序級別的安全性可確保：在預(yù)期的安全性情況下，主角只能訪問特定的功能或用例，或者只能訪問有限的數(shù)據(jù)。例如，可能會允許所有人輸入數(shù)
據(jù)，創(chuàng)建新賬戶，但只有管理員才能刪除這些數(shù)據(jù)或賬戶。如果具有數(shù)據(jù)級別的安全性，測試就可確保“用戶類型一”能夠看到所有客戶消息（包括財務(wù)數(shù)據(jù)），而
“用戶二”只能看見同一客戶的統(tǒng)計數(shù)據(jù)。
系統(tǒng)級別的安全性可確保只有具備系統(tǒng)訪問權(quán)限的用戶才能訪問應(yīng)用程序，而且只能通過相應(yīng)的網(wǎng)關(guān)來訪問。
配置測試又叫兼容性測試，核實測試對象在不同的軟件和硬件配置中的運(yùn)行情況。在大多數(shù)生產(chǎn)環(huán)境中，客戶機(jī)工作站、網(wǎng)絡(luò)連接和數(shù)據(jù)庫服務(wù)器的具體
硬件規(guī)格會有所不同。客戶機(jī)工作站可能會安裝不同的軟件例如，應(yīng)用程序、驅(qū)動程序等而且在任何時候，都可能運(yùn)行許多不同的軟件組合，從而占用不同的資源。
（如瀏覽器版本。OS版本等）
是指為各個地方開發(fā)產(chǎn)品的測試，如英文版，中文版等等，包括程序是否能夠正常運(yùn)行，界面是否符合當(dāng)?shù)亓?xí)俗，快捷鍵是否正常起作用等等，特別測試在A語言環(huán)境下運(yùn)行B語言軟件（比如在英文win98下試圖運(yùn)行中文版的程序），出現(xiàn)現(xiàn)象是否正常。
測試在不同分辨率下，界面的美觀程度,分為800*600，1024*768，1152*864，1280*768，1280*1024，1200*1600大小字體下測試
由于測試人員的思路不盡相同，每個人測試的側(cè)重點不同，由于都按照測試用例進(jìn)行測試，但是測試用例一般僅描述系統(tǒng)的
一些基本測試項，不會將所有的測試用例方方面面都寫到，有時還需要測試人員的經(jīng)驗和素質(zhì)。所以A測試某個產(chǎn)品用了七個工作日，第一天到第四天報出許多
bug,但從第五天開始幾乎報不出啥bug了。七天后換了B,B一下子又測試出一堆bug,不能說A的水平差，只能說，該產(chǎn)品已經(jīng)對A產(chǎn)生了抗藥性，這就
是測試學(xué)中的殺蟲劑現(xiàn)象。
所以在測試中每次輪流測試最好安排不同的測試人員進(jìn)行不同模塊測試工作，以避免殺蟲劑現(xiàn)象產(chǎn)生。