一、測試流程與生命周期
1.軟件的生命周期
生命周期包括：軟件定義及規划，需求分析，軟件設計，軟件編碼，軟件測試（單元測試，集成測試，系統測試，驗收測試），運行維護
2.軟件測試的基本流程
開發流程：需求分析--功能組成+具體邏輯--編寫代碼--單元測試--打包提交測試--測試提交bug--修復bug--回歸測試--...N輪--版本上線--面向用戶使用
測試流程：需求分析+原型圖--編寫測試用例--評審測試用例--開發出接口，進行接口自動化--開發出功能，進行功能測試--測試提交bug-修復bug--回歸測試--...N輪--版本上線--面向用戶
3.各階段介紹
軟件定義及規划：此階段是軟件開發方與需求方共同討論，主要確定軟件的開發目標及其可行性
需求分析：在確定軟件開發可行的情況下，對軟件需要實現的各個功能進行詳細分析
軟件設計：此階段主要根據需求分析的結果，對整個軟件系統進行設計，如系統框架設計，數據庫設計等等
程序編碼：此階段是將軟件設計的結果轉換成計算機可運行的程序代碼。在程序編碼中必須要制定統一，符合標准的編寫規范。以保證程序的可讀性，易維護性，提高程序的運行效率
軟件測試：在軟件設計完成后要經過嚴密的測試，以發現軟件在整個設計過程中存在的問題並加以糾正。在測試過程中需要建立詳細的測試計划並嚴格按照測試計划進行測試，以減少測試的隨意性
運行維護：軟件維護是軟件生命周期中持續時間最長的階段。在軟件開發完成並投入使用后，由於多方面的原因，軟件不能繼續適應用戶的要求。要延續軟件的使用壽命，就必須對軟件進行維護。軟件的維護包括糾錯性維護和改進性維護兩個方面
二、測試的分類方法
1.黑盒測試
概念：在完全不考慮程序內部結構和內部特性的情況下，針對可見的功能進行測試
優點：容易實施，不需要關注內部的實現；更貼近用戶的使用角度
缺點：測試覆蓋率較低，一般只能覆蓋到代碼量的不到40%；針對黑盒的自動化測試，復用率較低，維護成本較高（程序功能變化快）
黑盒測試主要關注什么？
是否有不正確或遺漏的功能？在接口上，輸入是否能正確的接受？能否輸出正確的結果？是否有數據結構的錯誤或外部信息（例如數據文件）訪問錯誤？性能上是否能滿足要求？（長時間測試，並發測試，響應測試）
黑盒測試的主要設計方法？
等價類划分法：針對很多輸入條件，等價的歸為一類，會形成典型的代表性的輸入，根據典型的輸入編寫用例
邊界值分析法：關注各種各樣邊界條件
錯誤推測法：基於經驗或直覺判斷程序中可能出現錯誤的地方，針對性的設計用例
因果圖法：需求規格說明書，根據規格語義說明編寫用例
正交試驗分析法：通過正交性從一組數據中篩選典型代表性數據的設計方法
狀態遷移圖法：通過梳理軟件功能點中的軟件狀態變遷關系設計用例
流程分析法：梳理程序邏輯執行路徑
2.白盒測試
概念：又稱結構化測試和透明盒測試，針對程序的邏輯結構設計用例
優點：迫使測試人員去仔細思考軟件的實現，理解原理；可以檢測代碼中每條分支和路徑；揭示隱藏在代碼中的錯誤；對代碼的測試比較徹底
缺點：昂貴（較高的覆蓋率）；無法檢測代碼中遺漏的路徑和數據敏感性錯誤（數據處理的有問題）；不能直接驗證需求的正確性（從代碼層面進行驗證）
白盒測試的主要設計方法：代碼檢測法、靜態結構分析法、靜態質量度量法、邏輯覆蓋法、基本路徑測試法
3.靜態測試：是指無須執行被測程序，而是通過評審軟件文檔或代碼，質量程序靜態復雜度，檢查軟件是否符合編碼標准，借以發現編寫的程序的不足之處，減少錯誤出現的概率，方式有互審、走查、會議
4.動態測試：是指通過運行被測程序，檢查運行結果與預期結果的差異，並分析運行效率、正確性和健壯性等
5.手工測試：由專門的測試人員從用戶視角來驗證軟件是否滿足設計要求的行為。更適用針對深度的測試和強調主觀判斷的測試
6.自動化測試：使用單獨的測試工具軟件控制測試的自動化執行以及對預期和結果進行自動檢查
7.UI測試：用戶界面測試是指測試用戶界面的風格是否滿足客戶要求，文字是否正確，頁面是否美觀，操作是否對用戶友好，人性化，易操作性測試等
8.冒煙測試：冒煙測試的對象是新編譯的每一個需要正式測試的軟件版本，目的是確認軟件基本功能正常，可以進行后續的正式測試工作
9.隨機測試：隨機測試沒有書面測試用例、記錄期望結果、檢查列表、腳本或指令的測試。主要是根據測試者的經驗對軟件進行功能和性能抽查。隨機測試是根據測試說明書執行用例測試的重要補充手段，是保證測試覆蓋完整性的有效方式和過程
10.本地化測試：本地化就是將軟件版本語言進行更改，比如將英文的windows改成中文的windows就是本地化
11.安裝測試：安裝測試是確保軟件在正常情況和異常情況下，例如，進行首次安裝、升級、完整的或自定義的安裝都能進行安裝的測試。異常情況包括磁盤空間不足、缺少目錄創建權限等場景
三、測試用例設計
等價類划分法：顧名思義就是將測試的范圍划分成幾個互不相交的子集，他們的並集是全集，從每個子集選出若干個有代表性的值作為測試用例。
邊界值分析法：長期的測試工作經驗告訴我們，大量的錯誤是發生在輸入或輸出范圍的邊界上，而不是發生在輸入輸出范圍的內部。因此為了查出更多的錯誤，設計的測試用例應選取正好等於、剛剛大於、剛剛小於邊界的值。
錯誤推測法：在測試程序時，人們可以根據經驗或直覺推測程序中可能存在的各種錯誤，從而有針對性地編寫檢查這些錯誤的測試用例的方法。這種方法沒有固定的形式，依靠的是經驗和直覺，很多時候，我們都會不知不覺的使用到。
判定表法：又稱為策略表，基於策略表的測試，是功能測試中最嚴密的測試方法。該方法適合於邏輯判斷復雜的場景，通過窮舉條件獲得結果，對結果再進行優化合並，會得到一個判斷清晰的策略表。
正交實驗法：用語言描述正交實驗法會很抽象難懂，簡單說，就是在各因素互相獨立的情況下，設計出一種特殊的表格，找出能以少數替代全面的測試用例。其中，上面所說的特殊表格就是正交表，是按照一定規則生成的表。
四、Bug提交
1.Bug有效性
交付過程中測試者需按照設定好的模塊，對Bug進行歸類提交；
Bug的類型確認為UI問題、功能問題、崩潰問題，提交Bug時不能弄錯；
需求是否明確、前提條件是否滿足、輸入數據是否正確、操作步驟是否清楚、Bug是否唯一性；
避免提交設計如此、操作錯誤、重復的、已知的Bug；
盡量少花時間在邊界值、頁面顯示問題上，多提業務邏輯功能、交互測試方面的問題。
2.Bug標題
Bug標題要求簡明扼要的闡述問題本質，使查看人員能快速了解Bug內容。需要寫明在哪個頁面執行什么操作出現什么現象。
3.測試設備
提交Bug要表明測試使用的設備、設備操作系統版本、測試環境、網絡類型等等。
4.前提條件
明確指出所提交的Bug是在怎么樣的情況下出現的，當所發現Bug前提條件為空時，需要填無。
5.測試步驟
要簡明清晰分步驟描述如何復現Bug問題，步驟用序號編排。
要按照自己的操作的實際步驟寫清楚每一步是怎么操作的，最后操作到哪個頁面或者點擊哪個按鍵。
如在特定情況下發生的問題，還需明確提供以下信息：
准確寫出連續點擊次數，點擊時長與上下滑動屏幕時長。
對於特定數據產生的問題，提供具體數據。
精准描述bug產生的路徑后，再描述現象。
6.期望結果
按照測試步驟應當得到的正確結果，按照產品需求的期望清晰准確的填寫預期結果。而且結果必須是肯定無疑義，可判定性的結果。
7.截圖和附件
UI類型：Bug需要上傳截圖，並且增加相應的紅框標識；
功能類型：問題必須上傳視頻文件，上傳格式MP4為主；
崩潰類型：bug則需要上傳視頻和log並且log不得超過10分鍾。
五、測試報告編寫
1.什么是測試報告
測試報告是產品部與技術部進行溝通的主要手段；是一個測試活動的總結，項目是否結項的重要參考和依據；軟測試報告是對測試過程和測試結果進行分析和評估，確認測試計划是否得到完整履行、測試覆蓋率是否達到預定要求以及對產品質量是否有足夠信心，並最終在報告中給出測試和產品質量的評估結論。
2.測試報告的內容
測試項目的版本，測試項目內容的概述
測試的時間、地點、人員
測試環境：測試環境的描述，包括客戶端和網絡環境
測試資源：測試過程中的測試資源使用
缺陷統計：包括bug數，解決數，遺留數，bug模塊分布
測試用例的執行情況：測試的覆蓋率
測試評估：基於軟件缺陷的質量評估，寫明在這一版本中，哪些功能被實現了，哪些還沒有實現，這里只需寫明和上一版本不同之處即可
規避措施
急待解決的問題：寫明當前項目組中面臨的最優先的問題，可以重復提出
附件
3.測試報告的注意事項
兩個核心內容：一、評估測試覆蓋率；二、基於軟件缺陷的質量評估。
內容簡潔：說話抓住重點，不說廢話，簡單易懂，精益求精，簡單明了，能用圖形、表格的盡量用圖形、表格展示，這樣更加直觀。
分析結論一定要給出，並且明顯的位置。讓項目經理清楚你的測試結論是什么，當時間比較緊的時候他看到結論心里就有數了。
測試報告寫完后，把其他的詳細數據付成附件，可供想得到詳細數據學習的人去學習理解。
在測試報告中的問題，要有優先級