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