一、測試活動的生命周期
測試計劃(測試準入) -> 需求分析與設計 -> 測試實現與執行 -> 測試報告(測試準出) -> 測試總結
1、測試計劃
任務的安排與制定測試的方法
2、測試的分析
到底如何測試
用什么方法測試
3、測試的執行
行動
4、測試報告
測試執行結果的總結
5、測試總結
項目上線后
測試人員本次的測試總結
測試方法的不足地方，為下次做準備
二、軟件測試的過程
按照測試階段劃分為: 單元測試、集成測試、系統測試、驗收測試。
單元測試UT
單元測試是針對軟件基本組成單元(軟件設計的最小單元)來進行正確性檢驗的測試工作，單元測試的目的是檢測軟件模塊《詳細設計說明》(LLD)的符合程度。集合測試IT
集合測試是在單元測試的基礎上，將所有模塊按照概要設計要求組裝成子系統或系統，驗證組裝后功能以及模塊間接口是否正確的測試工作。集成測試的目的是檢測軟件模塊對《概要設計說明》(HLD)的符合程度。
問題: 如何理解軟件間的接口？
軟件不同部分之間的交互接口，通常就是所謂的API --- 應用程序編程接口，其表現的形式是源代碼。
系統測試ST
系統測試是將已經集成好的軟件系統，作為整個系統與計算機硬件、外設、數據和人員等其他元素結合在一起，在實際運行環境下，對系統進行一系列的測試工作。
目的: 與《需求規格說明書》(SRS)進行比較，發現軟件與系統需求定義不符合或與之矛盾的地方。-
單元測試UT、集合測試IT、 系統測試ST的區別
UT/IT/ST的區別 系統整合測試SIT
系統整合測試就是評估產品在其規格范圍內的環境下工作，能否完成產品設計規格所需的功能以及與周邊設備、應用軟件的兼容性。大致可以分為硬、軟件兼容性測試，認證測試。冒煙測試
冒煙測試的名稱可以理解為該種測試耗時短，僅用一袋煙功夫就足夠了。也有人認為是形象地類比新電路基本功能檢查。任何新電路板焊接后，先通電檢查，如果存在缺陷，電路板可能會短路，板子冒煙。
冒煙測試的對象是每一個新編譯的需要正式測試的軟件版本，目的是確認軟件基本功能正常，可以進行后續的正式測試工作。冒煙測試的執行者是版本編譯人員。
有的公司運作模式為"轉測試"，測試需要的基本用例，全部通過后，才是進入系統測試的準則。可以由開發人員或是測試人員進行測試，某一特性或模塊測試不通過，即轉測試不通過，不可進行系統測試。
冒煙測試，在系統測試之前，對主要的功能進行測試；
回歸測試
回歸測試是指修改了舊代碼后，重新進行測試以確定修改沒有引入新的錯誤或導致其他代碼產生錯誤。自動回歸測試將大幅度降低系統測試、維護升級等階段的成本。回歸測試作為軟件生命周期的一個組成部分，在整個軟件測試過程占有很大的工作量比重，軟件開發的各個階段都會進行多次回歸測試。在漸進和快速迭代開發中，新版本的連續發布使回歸測試進行的更頻繁，而在極端編程方法中，更是要求每天都進行若干次回歸測試。因此，通過選擇正確的回歸測試策略來改進回歸測試的效率和有效性是很有意義的。回歸測試策略
選擇回歸測試策略應該兼顧效率和有效性兩個方面。常用的選擇回歸測試的方式包括:
a、再測試全部用例，選擇基線測試用例庫中的全部測試用例組成回歸測試包，這是一種比較安全的方法，再測試全部用例具有最低的遺漏回歸錯誤的風險，但測試成本最高。全部再測試幾乎可以應用到任何情況下，基本上不需要進行分析和重新開發，但是，隨著開發工作的進展，測試用例不斷增多，重復原先所有的測試將帶來很大的工作量，往往超出了我們的預算和進度。
b、基于風險選擇測試，可以基于一定的風險標準來從基線測試用例中選擇回歸測試包。首先運行最重要的、關鍵的和可疑的測試，而跳過那些非關鍵的、優先級低的或高穩定的測試用例，這些用例即便可能測試到缺陷，這些缺陷的嚴重性也僅有三級或四級，一般而言，測試從主要特征到次要特征。
c、基于操作剖面選擇測試，如果基線測試用例庫的測試用例是基于軟件操作剖面開發的，測試用例的分布情況反映了系統的實際使用情況。回歸測試所使用的測試用例個數可以由測試預算確定，回歸測試可以優先選擇那些針對最重要或最頻繁使用功能的測試用例，釋放和緩解最高級別的風險，有助于盡早發現那些可靠性有最大影響的故障。這個方法可以在一個給定的預算下最有效的提供系統可靠性，但實施起來有一定的難度。
d、再測試修改部分當測試者對修改的局部化有足夠的信心時，可以通過相依性分析識別軟件的修改情況并分析修改的影響，將回歸測試局限于被改變的模塊和它的接口上。通常，一個回歸錯誤一定涉及一個新的、修改的或刪除的代碼段。在允許的條件下，回歸測試盡可能覆蓋受影響的部分。
總結: 再測試全部用例的策略是最安全的策略，但已經運行過許多次的回歸測試不太可能揭示新的錯誤，而且很多時候，由于時間、人員、設備和經費的原因，不允許選擇再測試全部用例的回歸測試策略，此時可以選擇適當的策略進行縮減的回歸測試。
- 驗收測試
在軟件產品完成了單元測試、集成測試和系統測試之后，產品發布之前所進行的軟件測試活動。它是技術測試的最后一個階段，也成為交付測試。驗收測試的目的是確保軟件準備就緒，并且可以讓最終用戶將其用于執行軟件的既定功能和任務。
實施驗收測試的常用策略有三種，分別是:
- 正式驗收
- 非正式驗收或Alpha測試
- Beta測試
- 正式驗收
正式驗收測試是一項管理嚴格的過程，它通常是系統測試的延續。計劃和設計這些測試的周密和詳情成都不亞于系統測試，選擇的測試用例應該是系統測試中所執行測試用例的子集。
優點:
- 要測試的功能和特性都是已知的；
- 測試的細節是已知的并且可以對其進行評測；
- 這種測試可以自動執行，支持回歸測試；
- 可以對測試過程進行評測和檢測；
- 可接受性標準是已知的；
缺點:
- 要求大量的資源和計劃；
- 這些測試可能是系統測試的再次實施；
- 可能無法發現軟件中由于主觀原因造成的缺陷，這是因為你只查找預期要發現的缺陷；
- 非正式驗收或α測試
在非正式驗收測試中，執行測試過程的限定不像正式驗收測試中那樣嚴格。在此測試中，確定并記錄要研究的功能和業務任務，但沒有可以遵循的特定測試用例，測試內容由各種測試員決定。這種驗收測試方法不像正式驗收測試那樣組織有序，而且更為主觀。
大多數情況下，非正式驗收測試時最終用戶組織執行的。
優點:
- 要測試的功能和特性是已知的；
- 可以對測試過程進行評測和檢測；
- 可以接受性標準是已知；
- 與正式驗收測試相比，可以發現更多由于主觀原因造成的缺陷；
缺點:
- 需求資源、計劃和管理資源；
- 無法控制所使用的測試用例；
- 最終用戶可能沿用系統工作的方式，并可能無法發現缺陷；
- 最終用戶可能專注于比較新系統與遺留系統，而不是專注于查找缺陷；
- 用于驗收測試的資源部受項目的控制，并可能受到壓縮；
- β測試(UAT測試)
β測試是由軟件的多個用戶在一個或多個用戶的實際使用環境下進行的測試。這些用戶與公司簽訂了支持產品預發發行合同的外部用戶，他們要求使用該產品，并愿意返回所有錯誤信息給開發者
與α測試不同的是，β測試測試時開發者通常不在測試現場。因此，β測試是開發者無法控制的環境下進行的軟件現場測試；
β測試中，由用戶記錄下遇到的所有問題，包括真的和主觀認定的，定期向開發者報告，開發者在中和用戶的報告后，做出修改，在將軟件產品交付給全體用戶使用；
三、軟件測試的方法
- 測試方法劃分
1. 按代碼是否可見劃分
- 白盒測試
- 灰盒測試
- 黑盒測試
2. 按狀態劃分
- 靜態測試
- 動態測試
3.按人機劃分
- 手工測試
- 自動化測試
白盒測試
白盒測試，指的是把盒子蓋子打開，去研究里面的源代碼和程序結果。
它是按照程序內部的結構測試程序，通過測試來檢測產品內部動作是否按照設計規格說明書的規定正常進行，檢驗程序找那個的每條通路是否都能按預定要求正確工作。黑盒測試
黑盒測試，指的是把被測的軟件看做是黑盒子，我們不去關注盒子里面的結構是什么樣子的，只關心軟件的輸入數據和輸出結果。
它只檢查程序功能是否按照要求規格說明書的規定正常使用，程序是否能適當地接受輸入數據而產生正確的輸出信息。黑盒測試著眼于程序外部結構，不考慮內部邏輯結構，主要針對軟件界面和軟件功能進行測試。灰盒測試
灰盒測試介于黑盒測試與白盒測試之間。
可以理解為，灰測試關注輸出對于輸入的正確性，同時也關注內部表現，但這種關注不像白盒測試那樣詳細、完整，只是通過一些表性的現象、事件、標志來判斷內部的運行狀態，有時候輸入時正確的，但內部其實是錯誤的，這種情況非常多，如果每次都通過白盒測試來操作，效率會很低，因此需要采取這樣的一種灰盒測試。靜態測試
靜態測試，指不實際運行被測軟件，而只是靜態檢查程序代碼、界面或文檔可能存在錯誤的過程。
靜態測試包括:
- 對于代碼測試，主要是測試代碼是否符合相應的標準和規范；
- 對于界面測試，主要測試軟件的實際界面與需求中的說明是否相符；
- 對于文檔測試，主要測試用戶手冊和需求說明是否真正符合用戶的實際需求；
動態測試
動態測試，指實際運行被測程序，輸入相應的測試數據，檢查輸出結果和預期結果是否符合的過程。手工測試
手工測試，即由人去一個個的去執行測試用例，通過鍵盤鼠標等輸入一些參數，查看發揮結果是否符合預期結果。自動化測試
自動化測試，把以人為驅動的測試行為轉化為機器執行的一種過程。
通常，在設計了測試用例并通過評審之后，由測試人員根據測試用例中描述的規程一步步執行測試，得到實際結果與預期結果的比較。在此過程中，為了節省人力、時間或硬件資源，提高測試效率，便引入了自動化測試的概念。
四、總結
- 單元測試、集成測試、系統測試、系統整合測試、驗收測試
- 回歸測試、冒煙測試
- 黑盒測試、白盒測試、灰盒測試
- 靜態測試、動態測試
- 手工測試、自動化測試
