軟體需求分析是軟體測試流程中的基礎一環，用來明確軟體測試物件以及測試範圍，並作為測試覆蓋的基礎。其目的是確保所有風險承擔者盡早地對專案功能達成共識並對將來的產品有個相同而清晰的認識。
測試需求分析階段
責任主要負責人
pm（專案經理/產品經理）
測試人員
參與需求評審，提供評審意見，明確產品需求
輸入文件
需求說明文件
輸出文件
《需求規格說明書》
軟體測試計畫是指導測試過程的綱領性檔案，包含了產品概述、測試策略、測試方法、測試範圍、測試配置、測試進度、測試資源、風險分析等內容。借助軟體測試計畫，參與測試的專案成員，尤其是軟體測試管理人員，可以明確測試任務和測試方法，保持測試實施過程的順暢溝通，跟蹤和控制軟體測試進度，應對軟體測試過程中的各種變更。
測試計畫制定階段
責任主要負責人
測試經理（制定總體測試計畫）
測試人員
制定部分測試計畫內容匯報給測試經理
輸入文件
《需求規格說明書》《專案開發計畫》
輸出文件
《軟體測試計畫》
軟體測試用例是指導軟體測試工作的一種文件，它是通過使用在軟體測試計畫中確定的測試技術，對於已確定的軟體測試需求進行逐步推敲而設計出來的。
軟體測試用例設計完成，要進行綜合評審，通過評審可以彌補軟體需求中遺漏的一些因果關係和異常案例，可以改善測試分析和設計的過程。類似地，軟體測試工作的其它產出文件，如軟體測試計畫、軟體風險分析應該進行評審。
測試用例設計階段
責任主要負責人
測試人員全體
測試人員
使用用例設計方法來設計測試用例並進行評審
輸入文件
《需求規格說明書》《軟體測試計畫》《軟體設計文件》
輸出文件
《軟體測試用例》
要順利執行測試，首先要確定正確地搭建了軟體測試環境。軟體測試環境是指為了完成軟體測試工作所必須的計算機硬體、軟體、網路裝置、歷史資料的總稱。測試環境的搭建是一項非常重要的工作，同時也可能是一項很耗時的工作。有些軟體的測試環境要求比較複雜，需要在測試執行之前做好充分的準備。
在大資料系統的測試過程中，測試環境和資料的準備是測試過程中的重點。
大資料系統由於其自身的特點（資料規模大、資料多樣、計算複雜度高、分布式結構等）使得對它的測試與傳統軟體測試有所不同，包括需要使用大資料測試工具、測試環境和資料的準備等，對測試人員提出了更高的專業要求。
大資料系統通常是分布式架構，測試環境複雜。接下來我們重點講述大資料測試環境搭建時需要考慮的問題。搭建大資料測試，需要我們考慮以下幾點：
環境是否具有分布式節點和分布式資料儲存的集群；
環境是否有足夠的空間來儲存和處理大規模資料；
另外如果是做大資料系統的效能測試的話，還要考慮影響大資料系統效能的一些因素----網路環境、應用、虛擬化、資料質量等，所以還應考慮部署合適的監控系統，監控整個集群機器、服務、計算、儲存、任務等層面的指標。
而根據對大資料所測場景不同，所需要的測試環境也有所不同，但測試環境的軟硬體配置、軟體模組的版本應與生產環境一致。
如果是在大資料新業務上線前對系統功能做驗證測試，通常需要構造單獨的類生產的迷你測試環境；
如果是測試實時資料處理業務或是做系統元件的公升級測試，則可以按照系統生產環境進行等比例縮放；
如果是測試重要業務功能或是做系統的效能測試，則需要直接在生產環境上進行測試。
目前很多網際網路軟體應用，後台都會有資料庫做支撐，那就需要在測試的時候準備相應的測試資料，準備測試資料是軟體測試工作的一項必備工作。如何快速地建立測試資料，也是測試工程師的重要能力之一。
建立測試資料的過程，往往需要很長的時間，傳統的建立測試資料的方法分為手動建立和自動化建立兩種方法。
手動建立測試資料一般有如下幾種方法：
使用自建指令碼也可以生成測試資料，比如指令碼語言ruby或python，fit或fitnesse等工具以及shell指令碼等。
獲取自有資料當然更好，因為資料準確、實時、高效。根據使用場景的不同，測試資料可以直接使用真實資料，也可以按照某種演算法構造。
真實資料引流
生產環境資料複製。
構造資料
拿到資料之後，我們要對資料進行預處理。資料預處理是一種資料探勘技術，本質就是為了把原始資料轉換為可以理解的格式或者符合我們挖掘的格式。為什麼要進行預處理呢？因為直接獲取的資料通常質量比較低，主要表現為這些現象：
資料可能是不完整的，缺少某些屬性值；
高維度，所謂的高維度是指資料的屬性或欄位太多；
資料可能存在重複；
資料可能會由於包含**或者名稱的差異導致跟實際需要的資料不一致
可能含雜訊，所謂的含雜訊就是指資料中存在著錯誤或異常資料。
資料預處理就是解決上面所提到的資料問題的可靠方法。首先要進行資料清洗，資料清洗完成之後接著進行或者同時進行資料整合、轉換、歸一化等一系列處理，這個過程就是資料預處理。一方面是提高資料的質量，另一方面可以讓資料更好的適應特定的專案環境。初學者可以了解以下幾種資料預處理的方法：
缺失值的處理。總的原則是：使用最可能的值代替缺失值，使缺失值與其他數值之間的關係保持最大。
異常值的處理。異常值是資料集中偏離大部分資料的資料。
資料的標準化處理。資料的標準化是將資料按比例縮放，使之落入乙個小的特定區間。
資料連續屬性離散化。一些資料探勘演算法，特別是分類演算法，要求資料是分類屬性形式。常常需要將連續屬性變換成分類屬性，即連續屬性離散化。
提交了測試物件並且測試物件滿足了測試執行的進入準則後（測試的進入準則會在第3章軟體測試計畫中詳細講述，就是滿足了一定的條件，才能開始執行測試），可以開始測試執行。
測試的執行只能有2種結果：pass或者fail。測試不通過的話，測試人員就應該把發現的問題及時記錄下來，報告給開發人員做出相應的修改。缺陷記錄是測試人員工作的具體表現形式，是測試人員與開發人員溝通的基礎。因此，如何錄入乙個高質量的缺陷報告，是每個測試人員都要重視的問題。
測試執行階段
責任主要負責人
測試經理（跟蹤實際測試情況，處理疑難問題）
測試人員
執行實際測試用例，提交缺陷，回歸缺陷
輸入文件
《需求規格說明書》《軟體測試計畫》《軟體設計文件》《測試用例文件》《測試資料》
輸出文件
《軟體缺陷報告文件》
軟體測試進行到一定程度就要進行測試評估了。測試評估可以在軟體測試過程中階段性進行，也可以是測試整體結束後進行。通過測試評估生成的測試總結報告（又叫測試評估報告）來確定測試是否達到了出口準則。
測試總結階段
責任主要負責人
測試經理（編寫測試總結報告）
測試人員
提供自己負責部分的測試情況總結
輸入文件
《需求規格說明書》《軟體測試計畫》《軟體設計文件》《測試用例文件》《測試資料》《軟體缺陷報告文件》
輸出文件
《軟體測試總結報告》
軟體測試到此是否就結束了呢？還有最後乙個環節，那就是測試檔案的歸檔。測試檔案歸檔是在測試驗收結束，宣布測試有效及結束測試後，對整個過程中涉及到的各種標準文件進行歸檔、存檔。可以使用文件管理工具來完成此項工作。如ftp、svn、git、vss、wiki等。
軟體測試的過程，其實是乙個完整的pdca迴圈。測試不應該在執行完軟體測試後就戛然而止，應該使用這次測試總結出來的經驗和教訓指導下一次測試的設計和執行。軟體測試中到處都體現著pdca迴圈的精神。
大的測試流程中，制定好測試計畫、執行測試、通過測試結果來檢查測試計畫制定的合理性，然後分析計畫偏離的原因，再把總結出來的經驗用於指導下一次測試的計畫，這樣就形成了乙個pdca迴圈過程。
提交乙個缺陷也可以應用pdca迴圈，先寫下來，再檢查，然後提交審核，對提出的意見進行分析，總結寫的不好的地方，把總結的經驗用於指導下一次報告的編寫，這樣的過程同樣是乙個pdca。
編寫測試用例也是乙個pdca，選擇好測試用例的編寫方法，開始設計測試用例，然後通過評審來發現更多問題，或者通過執行測試用例來發現bug，再根據執行的情況和bug的情況來分析測試用例的有效性，把這些總結出來的經驗用於指導下一次的測試用例設計。這也是乙個pdca迴圈。
所有的測試最終都應該以使用者需求為依據
應盡早開展軟體測試工作
軟體測試中的pareto法則
程式設計師應該盡量避免測試自己編寫的程式
窮盡測試是不可能的
軟體測試是有風險的
good-enough原則
程式中存在軟體缺陷的可能性與該部分已經發現的缺陷成正比
軟體測試經常會有免疫現象發生
無法通過軟體測試發現所有的軟體缺陷
並非所有的軟體缺陷都會修復
前進兩步，後退一步(這是指修復軟體缺陷，總會以20%~50%的機率引入新的缺陷，所以整個過程是前進兩步，後退一步的。通過合理的回歸測試可以有效的解決部分這種問題.)
軟體測試學習筆記三 黑盒測試
1 黑盒測試的基本觀點 任何程式都可看做式從輸入定義與對映到輸出值域的函式過程，被測程式被認為是乙個打不開的黑盒子，黑盒子中有什麼不需要知道，只要知道這個盒子有什麼功能。發現以下幾類錯誤 1 功能是否正確和完備 2 輸入是否被接受，輸出是否正確 3 效能是否滿足要求 1 等價類劃分法 1 定義 將不...
軟體測試 介面測試 三
有軟體的地方就有介面，就會有介面測試。介面測試是軟體測試中，最多，最繁瑣，最簡單的測試。尤其在本地化測試 多國語言測試 中，有很多的介面測試。介面測試,也叫ui測試 user inte ce testing 本文介紹一些常見的介面測試，以及描述介面bug時所用的術語。檢查使用者介面的風格是否滿足客戶...
軟體測試基礎三
軟體測試需求分析 1 什麼是軟體需求 測試需求主要解決 測什麼 的問題,一般 來自需求規格說明書中原始需求 測試需求應全部覆蓋已定義的業務流程,以及功能和非功能方面的需求 2 軟體需求的必要性 簡而言之 只有明確了測試需求,才知道怎麼去測試?什麼時候開始測試,要多少人測試,在什麼環境上測試?3 如何...