定義
在規定的條件下對程序進行操作，以發現程序錯誤，衡量軟件質量，並對其是否能滿足設計要求進行評估的過程。
測試就是發現錯誤而執行程序的過程。
原則
-
保證測試的覆蓋度，但是窮舉測試是不可能的。
-
所有的測試都應該追溯到用戶。
-
越早測越好，測試過程與開發過程應該是互相結合的。
-
測試的規模 從小到大，從單元測試到系統測試。
-
不能爲了便於測試而擅自修改程序。
-
既應該測試軟件能做什麼，也應該測試軟件不能做什麼。
度量
-
測試覆蓋率
-
缺陷發現率
-
測試成功率（或者說用例通過率）
測試做到什麼程度並沒有一個固定答案。只要滿足兩個顯式條件和一個隱含條件就要一直進行。
顯式條件：
-
項目風險
-
項目經費
隱含條件：
-
老闆們從當前的測試結果已經獲得了足夠的信心,或者徹底摧毀了信心。只要他們還在猶豫咱就得繼續幹活。
測試的原則
測試只是展示缺陷
測試只能表明缺陷存在,卻不能證明沒有缺陷。測試能降低未發現缺陷留存的概率,卻 不能證明軟件是絕對正確的。 正如某些數學命題,你可以窮舉 1-n,證明其正確,卻依然無法證明對於 n+1 仍然正確。
窮盡測試是不可能的
測試所有的輸入和條件組合是不可能的,除非是極其簡單的情況。可以取而代之的是基 於風險和優先級的測試。 當不懂裝懂的老闆要求你徹底測試一個軟件的時候,這是你反駁的最好支持,當然要說 的委婉一點。
早期測試
要較早發現缺陷,就要在軟件週期儘可能早的時候開始測試,而且要專注於已定義的測 試目標。 儘早開始測試!這句話估計早就把大家的耳朵磨起繭了。爲什麼要早?因爲越早發現問 題,解決的代價就越小。
缺陷簇生
要對缺陷發現率高的模塊投入更多的測試。少量的模塊往往隱藏了大部分的缺陷。 這不僅僅是所謂的物以類聚。缺陷發現率高的模塊往往於需求不清,設計不當,編碼復 雜度高等內在原因關聯,所以從風險的角度來看必然較高,多花些時間絕對值得。
殺蟲劑悖論
相同的測試再重複多次後就無法再找到缺陷了。要克服“殺蟲劑悖論”,測試用例要不斷評審修改,不斷添加新的和不同的測試,就有可能找到更多缺陷。 隨着對系統的加深理解,必然會有更多的測試用例產生。另外缺陷本身也是新用例的很 好來源。
測試是上下文相關的
測試在不同上下文環境中的執行是不同的。比方說 安全關鍵系統 (safety critical system)和電子商務網站的測試方法就有很大不同。 這個原理相對難理解。這裏其實強調的是不能用相同的態度和手段來測試不同類型的系 統。安全關鍵系統的概念要到高級大綱中才出現,指的是對系統安全要求苛刻的系統, 較之一般的電子商務系統的測試要求更爲嚴苛。
無錯謬論
假如建立的系統不穩定或不能滿足用戶需要和期望,那麼發現和修復缺陷就毫無幫助了。 缺陷數量往往用來評估某軟件的質量,但要是系統本身背離了用戶要求,那就算缺陷再 少也沒用,因爲沒有人會去用它。所以測試時要注意驗證(verification)和確認(validation)的區別。需求規格說明和其他文檔只是需求的不完全載體。文字說明必然有遺漏和偏差, 而各人的理解更有可能出錯。要不斷通過各種途徑保證所生產的的確就是用戶需要的。 常用的方式就是邀請領域專家或用戶儘可能多地參與到開發活動來,特別是需求評審和 演示(Demo)。
測試的標準
-
測試的標準是用戶的需求。
所有的軟件測試都應該追溯用戶的需求，測試人員要始終站在用戶的角度去看問題、去判斷的軟件缺陷的影響，系統最嚴重的錯誤是那些導致程序無法滿足用戶需求的缺陷。
測試主要步驟
-
計劃與控制
-
分析與設計
-
實施與執行
-
評估出口準則和報告
-
測試結束活動
測試流程
熟悉產品／項目
需求評審
測試需求
測試計劃
測試用例
預測試
第一輪測試
第二輪迴歸測試
第三輪測試
測試報告
測試總結
爲什麼要避免測試自己的程序？
由於心理因素，人們潛意識都不希望找到自己的錯誤。基於這種思維定勢，人們難於發現自己的錯誤。
軟件測試的要素
質量：
軟件質量是軟件測試的目標，也是軟件測試工作的中心，一切從質量出發，也就是一切從客戶需求出發。任何違背質量的東西都是問題，測試就是要找出這些問題。
人員：
人是決定的因素，測試人員的態度、素質、能力決定着測試的效果，對測試產品的質量也有很大的影響。測試人員因素包括測試組織結構、角色和責任的定義。
技術：
軟件測試技術，包括方法、工具。
資源：
主要是指測試環境中所需要的硬件設備、網絡環境，甚至包括測試數據。另外一個重要因素就是測試時間，時間也是測試的資源，但測試人員不能看做資源，每個人的能力千差萬別，不同的測試人員擔任不同的角色，不能相互代替。這也是軟件圖書的經典之作——《人件》的作者反對將人作爲資源對待的原因。
流程：
從測試計劃和測試用例的創建、評審到測試的執行、報告，設定每個階段的進出標準。
軟件質量
軟件產品質量評價國際標準ISO 14598 把軟件質量定義爲：軟件特性的總和，軟件滿足規定或潛在用戶需求的能力。上述定義反應如下3個方面的問題：
軟件需求是度量軟件質量的標準；
軟件人員必須遵循軟件過程過程的規範；
如果軟件只是滿足規定的需求，而不能滿足可能存在的隱含需求，軟件質量也不能保證。
軟件團隊的責任
-
發現軟件程序、系統或產品中“所有”的問題
-
儘早地發現問題
-
督促和協助開發人員儘快地解決程序中的缺陷
-
幫助項目管理人員制定合理的開發計劃
-
對缺陷進行跟蹤、分析和分類總結，以便讓項目的管理人員和相關的負責人員能夠及時、清楚地瞭解產品當前的質量狀態
-
幫助改善開發流程、調高產品開發效率
-
促進程序編寫的規範性、易讀性、可維護性等
缺陷發現率
缺陷發現率DDP是另一個衡量測試工作效率的軟件質量成本的指標。

缺陷發現率DDP＝Bugs（tester）/ （Bugs（tester）+ Bugs（customer））
缺陷發現率越高，也就是測試者發現的錯誤多，發佈後客戶發現的錯誤就越少，降低了外部故障不一致成本，達到節約總成本的目的，可獲得較高的測試投資回報率。
測試分類
黑盒測試
-
又稱功能測試或數據驅動測試，是針對軟件的功能需求/實現進行測試，通過測試來檢測每個功能是否符合需求，不考慮程序內部的邏輯結構。
-
方法：
-
功能劃分
-
等價類劃分
-
邊界值劃分
-
因果圖（魚骨圖）
-
錯誤推測
白盒測試
-
白盒測試也稱結構測試或邏輯驅動測試，必須知道軟件內部工作過程，通過測試來檢測軟件內部是否按照需求、設計正常運行。
-
方法：
對應於程序的一些主要結構：語句、分支、邏輯路徑、變量；
-
語句覆蓋方法
-
分支覆蓋方法
-
邏輯覆蓋方法
單元測試
-
定義： 又稱模塊測試，是針對軟件設計的最小單位程序模塊進行正確性檢查的測試工作；可以從程序的內部結構出發設計測試用例，多個模塊測試可以平行地獨立進行測試；
-
目的：發現模塊內部可能存在的差錯；
-
內容：模塊接口測試（數據流入流出）、局部數據結構測試、路徑測試、錯誤處理測試、邊界測試。
-
步驟：利用設計文檔設計測試用例；創建被測模塊的樁模塊或驅動模塊；利用被測試模塊、驅動模塊和樁模塊來建立測試環境，進行測試。
集成測試
-
定義：又稱組裝測試或聯合測試，在單元測試的基礎上，將所有模塊按概要設計和詳細設計進行組裝。
-
目的：發現模塊連接中的接口可能存在的各種差錯
-
內容：
-
穿越模塊之間的數據是否會丟失；
-
-
一個模塊組裝後是否會對另一模塊或其他模塊存在影響
-
各個子功能組裝在一起是否會達到預期的父功能
-
全局數據結構是否有問題；
-
單個模塊的錯誤累積起來是否會放在。
-
組裝方法：包括一次性組裝方式、增殖式組裝方式兩種組裝方法
-
完成標誌：成功地執行了測試計劃中規定的所有測試用例；修正了所發現的錯誤；測試結果通過專門小組的評審
系統測試
-
目的：驗證和確認系統是否達到其原始目標，而對集成的硬件和軟件系統進行的測試
-
測試內容：在真實或模擬系統運行環境下，檢查完整的程序系統能否和系統（硬件設備、網絡、系統軟件）正確配置、連接，滿足用戶需求
驗收測試
-
測試目的：在用戶環境中進行測試，以確定系統和產品是否能夠滿足合同或用戶所規定的需求
-
測試內容：根據任務書或合同、供需雙方約定的驗收依據文檔進行對整個系統的測試與評審，確認是否接收或拒絕系統
Alpha測試
-
屬於驗證測試。模擬運行。由開發人員與測試的測試人員。
Beta測試
-
屬於驗收測試。由軟件的最終用戶在一個或多個用戶場所來進行的，開發者通常不在現場，用戶記錄測試中遇到的問題並報告給開發者。
靜態測試
-
靜態測試又稱爲靜態分析技術，不執行被測試軟件，對需求分析說明書、軟件設計說明書、源程序做結構檢測、流圖分析、符號執行等找出軟件的錯誤。
動態測試
-
通過輸入一組預先按照一定的測試準則構造的實例數據動態運行程序，而達到發現程序錯誤的過程。
如何進行單元測試
-
完成最小的軟件設計單元——模塊驗證工作。
-
確保模塊的正確編碼
-
使用過程設計描述作爲指南，對重要的控制路徑進行測試以發現模塊內錯誤。
-
通常情況下面向白盒的
-
對代碼風格和規則、程序設計結構、業務邏輯等進行靜態測試，及早地發現和解決不易顯現的錯誤。
-
單元測試的內容
-
接口測試
-
內部數據結構
-
全局數據結構
-
邊界
-
語句覆蓋，錯誤路徑
自動化測試
自動化測試是把以人爲驅動的測試行爲轉化爲機器執行的一種過程。
-
在設計了測試用例並通過評審之後，由測試人員根據測試用例中描述的規程一步步執行測試，得到實際結果與期望結果的比較。在此過程中，爲了節省人力、時間或硬件資源，提高測試效率，便引入了自動化測試的概念。
手工和自動化
手工測試缺點在於測試工作量大，重複多，迴歸測試難以實現
自動測試利用軟件測試工具自動實現全部或部分測試工作：管理、設計、執行和報告；節省大量的測試開銷，並能夠完成一些手工測試無法實現的測試
-
手工完成測試的全部過程無法保證測試的科學性與嚴密性:
-
修改缺陷越多，迴歸測試約困難
-
沒有人能向決策層提供精確的數據以度量當前的工作進度及工作效率
-
反覆測試帶來的倦怠情緒及其他人爲因素使得測試標準前後不一
-
測試花費的時間越長，測試的嚴格性也就越低
-
自動測試將測試人員從反覆、煩雜的測試執行中解放出來，用更多的時間進行測試設計和結果分析
-
軟件測試不可能全部自動化
-
不能完成所有手工測試任務
-
無創造性，且靈活性差，不能改進測試的有效率
-
過程中可能會遇到很多想不到的問題，尤其是在軟件不穩定的情況下
-
測試腳本的維護高
測試用例設計原則
-
單個用例最小化原則
-
這條原則是所有這四條原則中的“老大“，也是在工程中最容易被忘記和忽略的，它或多或少的都影響到其它幾條原則。
-
-
測試用例的覆蓋邊界定義更清晰，則測試結果對產品問題的指向性更強。
-
測試用例間的耦合度最低，則彼此之間的干擾也就越低。
-
上述這些優點所能帶來直接好處是，測試用例的調試、分析和維護成本最低。每個測試用例應該儘可能的簡單，只驗證你所要驗證的內容。
-
測試用例替代產品文檔功能原則
-
通常我們會在開發的初期（Scrum每個Sprint的頭兩天）用Word文檔或者OneNote的記錄產品的需求、功能描述、以及當前所能確定的任何細節等信息，勾勒將要實現功能的樣貌，便於團隊進行交流和細化，並在團隊內達成對產品功能共識。但隨着產品開發深入，團隊會對產品的功能有更新的認識，產品功能也會被更具體細化，在一個迭代或者Sprint結束的時候最終實現的功能很可能是A+。如此往復，在不斷傾聽和吸收用戶的反饋，多個迭代過後，原本被描述爲A的功能很可能最終變爲了Z。這是時候再去看看曾經的Word文檔和OneNote頁面，它們仍然記錄的是A。之所以會這樣 ，是因爲很少有人會去以及能夠去不斷地去更新那些文檔，以準確地反映出功能當前準確的狀態。
-
單次投入成本和多次投入成本原則
-
成本永遠是任何項目進行決策時所要考慮的首要因素，項目中的測試也是如此，對成本的考慮也應該客觀和全面的體現在測試的設計、執行和維護的整個階段中。
-
測試中的成本按其時間跨度可以分爲：單次投入成本和多次投入成本。例如：編寫測試用例可以看作是單次投入成本，因爲編寫測試用例一般是在測試的計劃階段進行（Scrum每個Sprint的開始階段）的，雖然後期會有小的改動，但絕大多數是在一開始的設計階段就基本上成型了；
-
使測試結果分析和調試最簡單化原則
-
這條原則實際上是單次投入成本和多次投入成本原則 – 針對自動化測試用例的擴展和延續。在編寫自動化測試代碼時，要重點考慮如何使得測試結果分析和測試調試更爲簡單，包括：用例日誌、調試輔助信息輸出等。
測試用例方法
-
等價類劃分
-
等價類劃分
-
錯誤推測
-
因果圖
-
判定表驅動分析
-
正交實驗設計
-
場景設計法
-
狀態轉換圖
測試用例內容
測試用例主要包括用例編號、用例描述、前提條件、輸入數據、測試步驟和期望結果6項關鍵內容：
-
用例編號
用例的組織要方便測試人員執行測試用例，應設計一套良好的用例編號體系。
-
用例描述
用例描述應使用最精簡的文字，描述出用例的全貌。讓測試人員不用看測試步驟，只看這個描述就可以知道這個用例是描述哪個場景、哪個功能點。
-
前提條件
一個測試用例一般是針對一個特點的場景，而需要測試的場景發生時通常會有一些鋪墊場景，即測試用例的前提，如軟硬件環境配置、權限設置，數據準備。
-
輸入數據
一個測試用例可以有一個或多個輸入數據，也可以無輸入數據。
-
測試步驟
測試步驟是測試用例的主體，一個測試用例由一個或多個步驟組成，每個步驟之間有一定的前後關係。每個步驟必須表述詳細，描述清晰，用於規範、嚴謹而又客觀，最基本的要求是能夠使其他人理解，並能正確的執行編寫者希望的操作。
-
期望結果
期望結果是測試執行對執行結果進行對比的標尺，是測試是否通過的判斷依據。測試結果必須保證其正確性。
測試計劃
根據項目相關文檔，需要定義測試範圍、測試策略、人員分配、軟硬件配置、進度表以及測試過程每個階段需要達到的目標。
查詢遺漏問題的方法
-
說明書是基礎和標準
測試的執行，通常按測試用例來進行，但測試用例的設計編寫是依據產品規格說明書、需求規格說明書、界面設計規範等。寫測試用例時難免有考慮不到的地方，因此反覆閱讀說明文檔，也許會有一些新的思路和啓發。在項目後期，迴歸測試階段，容易思維定勢、疲憊，這是可以把這些文檔拿出來，再看一下功能點是否覆蓋，覆蓋到的是不是和需求一致，沒有偏差。
-
相關變動郵件，討論記錄
變動是一個項目過程中不可少的部分，而這些變動，通常是通過討論的方式定下來的，因此會有一些文檔記錄和郵件。反覆閱讀這些郵件和文檔記錄，可以更深入的理解項目。
-
不定期閱讀別人的缺陷
每個人的思路、考慮的角度和操作習慣各不相同，因此發現的問題就會不一樣。多閱讀別人的缺陷可以拓寬思路，看多了，也會不自覺把多種思路集中到一起，慢慢得應用到測試實踐中了。
-
多和開發人員溝通
功能測試對測試人員來說大多是黑盒測試，只有開發人員最清楚哪個函數調用哪個函數、哪塊單元測試不夠充分、哪個邏輯結構比較複雜，多和他們溝通，可以知道哪裏還需要多關注一下。
-
有選擇的重新驗證以前的缺陷
特別在迴歸測試、驗收測試階段，除了驗證前面發現的缺陷，還要重視那些與缺陷相關的模塊。一個底層參數的變動，可能會引起很多相關功能的問題，繼而造成缺陷的遺漏。
-
關注變化
一段代碼的改動，需要開發人員和測試人員去識別。開發人員知道改動的地方會被哪些模塊調用或者會引起哪些模塊的變化，但由於時間緊、任務重、很難做好單元測試，因此開發人員要通知測試人員需要關注的測試點。
-
簡單思維方式，一主線爲主，減少大遺漏
一個項目的成功不是把缺陷全報出來，而是在有限的代價下達到預期的質量。按計劃進行的項目，主要功能的質量在一定程度上決定了產品的好壞。在項目工期緊張時，全部走完所有測試用例是很難的，可以基本功能爲主線，做好相關測試用例的執行，保證不會發生大的質量事故。
在測試後期，測試人員可能對質量已經很有信心，受思維和經驗的侷限性，可能僅限於此。若此時，在產品發佈之前，調動其他組的員工參與限時測試並給予獎勵，必然能有效減少軟件缺陷帶來的風險，提高產品質量。
軟件缺陷（bug）
軟件缺陷是指系統或系統部件中那些導致系統或部件不能實現其應有功能的缺陷。一般定義缺陷有以下5條原則：
-
軟件未實現產品說明書要求的功能。
-
軟件出現產品說明書指明不應該出現的錯誤。
-
軟件實現了產品說明書未說明的功能。
-
軟件未實現產品說明書雖未明確提及但應該實現的目標。
-
軟件難以理解，不易使用，運行速度慢，或者軟件測試員認爲最終用戶會認爲不好。
提交缺陷（bug）的要求
Bug描述的基本要求是分類準確、敘述簡潔、步驟清楚、實際結果描述準確、複雜問題有據可查（截圖或其他形式的附件）。基本要求如下：
-
問題描述一般格式：模塊或功能點=>測試步驟=>期望結果=>實際結果=>其他信息
-
單一：儘量一個bug只針對一個軟件缺陷
-
簡潔：每個步驟儘量簡單明瞭
-
再現：問題必須能在自己機器上重現方可上報（個別嚴重問題重現不了也可上報，但必須標明）
-
複雜問題：附截圖補充說明或直接通知指定的修改人，截圖文件格式建議用JPG或GIF
-
報告中不允許使用抽象的詞語：“有錯誤”，“有時候”之類的不確定語句
-The Ene-
QQ羣:330374464
分享該篇文章,獲取更多資源
