【一】為什麼要測試？
【1】軟體的非正常執行（有些軟體在電量低的情況下不能執行）或其自身的缺陷Bug會引發很多問題。
【2】軟體是由開發人員編寫程式碼和文件組成的，是人都有可能犯錯，測試的工作是需要對開發出來的軟體進行測試。
【3】環境也會影響軟體，以致出現軟體失效的現象。
【4】測試只是保證關鍵質量的活動之一，並不完全取決於測試，由開發，產品，運維一起決定的。
【二】什麼是測試？
【1】製造行業（簡稱QC）的定義：以檢驗產品是否滿足需求為目的
【2】軟體行業的定義：找Bug, 找缺陷
（開發人員透過程式語言把功能實現出來，測試的工作就是不斷發現軟體中的缺陷，然後讓開發人員進行修復）
【3】測試用例：在理解的條件基礎上對軟體進行測試的步驟。==》只要能發現錯誤就是一個成功的測試用例
【三】軟體生命週期
【1】概念：軟體生命週期又稱軟體生存週期或軟體開發生命週期，指的是軟體從生產到報廢的過程，是一種時間的概念
eg.一部手機的壽命
【2】包括哪些階段：
（1）客戶問題引入或定義：比如電商平臺我們團隊會派產品經理和客戶進行交接，我們能不能接這個專案，這個專案到底賺不賺錢。
（2）可行性分析：涉及經濟，商業論證，政治，法律，技術等
（3）專案招投標：透過公開招募或競爭性選擇來選擇最優的供應商提供相關產品或服務。招一個專案組過來做一個產品需要多長時間。
（4）專案立項：使用者的專案需要在半年之後需要交付哪些功能，一年之後完成哪些功能。
（5）需求分析：根據顧客需求輸出需求文件。
（6）開發階段（設計，編碼，測試）
（7）維護：一般在專案立項的時候客戶不會把錢全部打給團隊，可能會打個30%的定金，等專案全部開發完畢後可能會另外支付60%，最後10%客戶的要求是團隊必須維護這個應用軟體一年或者三年。
【3】模型：
（1）瀑布模型（waterfall)：用的非常少，每個程式必須按部就班進行，浪費時間且影響效率。
系統需求》軟體需求》分析》程式設計》編碼》測試》執行
（2）V模型：專案的階段（是軟體生命週期的5需求分析和6專案的開發階段）
1.使用者需求分析階段：公司接到一個專案之後分配專案組，專案組的各個成員都對使用者的需求進行分析，首先由產品經理根據使用者需求提煉成為專案需求然後輸出需求文件，與此同時專案組的其他成員比如測試人員和開發人員也根據使用者的需求進行初步的分析。》大家各自分析完成後，產品經理召開需求評審會議，專案組成員根據各自的分析對需求文件中有問題的地方或者模稜兩可的地方提出意見，然後產品經理根據大家提出的不同意見對需求文件進行修改》最後經過大家一致意見透過修改好的需求文件稱之為需求規格說明書（SRS：需求的基線化文件→當前的狀態非常的穩定且已經終結，不可以被隨意的更改，隨時可以進入到下一個狀態）。
2.概要設計階段：開發人員根據需求規格說明書（SRS），編寫概要設計說明書（HLD）,設計出應用程式的大體框架結構。
3.詳細設計階段：開發人員根據概要設計說明書（HLD），編寫詳細設計設計說明書（LLD），設計出具體要開發的哪些功能。
4.編碼實現階段：又稱coding編碼階段，開發人員根據詳細設計設計說明書（LLD）編寫程式碼，寫完程式碼以後對程式碼進行打包，打包成一個專案程式碼包。
5.單元測試階段（UT）：白盒測試
黑盒測試：又稱功能測試，是一種從使用者角度出發的測試。把被測程式當作一個黑盒子，測試人員完全不用考慮盒子裡面的邏輯結構和具體運作，只依據程式的需求規格說明書，檢查程式的功能是否符合它的功能說明。主要的測試方法有等價劃分類，錯誤推測法等。
白盒測試：也稱為結構測試。多用於單元測試階段。它根據程式的控制結構設計測試用例，開發人員針對於自己編寫好的程式碼包進行自測，用程式碼測試程式碼，是需要知道軟體的內部邏輯，從而對邏輯進行測試，然後輸出單元測試報告。
灰盒測試：又稱介面測試，多用於整合測試階段，是介於白盒測試與黑盒測試之間的一種測試，需要知道軟體內部的部分邏輯，不僅關注輸出、輸入的正確性，同時也關注程式內部的情況。灰盒測試不像白盒那樣詳細、完整，但又比黑盒測試更關注程式的內部邏輯。
三者的區別：
從測試目標和依據來說：黑盒面對的是產品設計，白盒針對的是程式功能的實現，灰盒針對兼而有之，既要考慮產品設計要求，又考慮到功能實現的效果
從實現者而言：黑盒在意的是客戶的角度，白盒測試針對的研發人員。
從測試模組顆粒度而言：白盒在意的是程式碼實現層面，而灰盒更加側重模組之間，而黑盒更在於使用者層面
6.整合測試階段IT（灰盒測試也叫介面測試）：測試人員對開發程式碼包實現的功能和頁面進行測試，輸出系統整合測試報告。
模組A，模組B，模組C，模組D，模組E，==》灰盒測試：對不同的模組之間進行介面測試
7.系統測試階段ST：除了保證應用程式本身執行和功能正常，還要與第三方應用程式進行銜接。
整合測試階段IT和系統測試階段ST合併成為SIT，即系統整合測試。
8.驗收測試階段UAT：由產品經理或者產品專案組對軟體的程式碼包進行驗收測試，輸出驗收測試報告。
α（阿爾法）驗收測試：由專案組中的產品成員或者業務人員進行驗收，測試人員模擬使用者的行為去進行測試，如果在驗收過程中發現了問題可以直接讓開發人員現場對bug進行解決修復。
β（貝塔）驗收測試：產品已經交付到了客戶手中，客戶自己去操作產品驗收，如果發現了問題則由客戶把出現的問題進行統一收集，然後以郵件的形式傳送給專案組成員，然後再由開發人員去跟進並進行解決。
V模型如下
使用者需求 ==》 驗收測試（是根據使用者的需求來進行驗收）
需求分析 ==》 系統測試（是根據需求進行系統測試）
概要設計 ==》 整合測試（是根據概要設計進行整合測試）
詳細設計 ==》單元測試（是根據詳細設計進行單元測試）
編碼和實現
面試題：您之前公司的專案階段有哪些？並且每個階段的輸入（准入）和輸出（準出）是什麼？
准入 準出
客戶需求分析階段 ===》對需求進行分析，生成需求文件 ===》需求規格說明書（SRS）
概要設計階段 ===》需求規格說明書（SRS） ===》概要設計說明書（HLD）
詳細設計階段 ===》概要設計說明書（HLD） ===》詳細設計說明書（LLD）
編碼實現階段 ===》根據詳細設計說明書（LLD）編寫程式碼 ===》整個專案程式碼包（.war .jar格式包）
單元測試階段 ===》開發人員根據程式碼包進行自測 ===》單元測試報告
系統整合測試階段 ===》測試人員編寫和執行測試用例，對程式碼包進行測試 ===》系統整合測試報告
驗收測試階段 ===》產品專案組或客戶對程式碼包進行驗收 ===》驗收測試報告
（3）W模型：是V模型的補充，它貫穿整個軟體產品週期。但是還是認為是序列的開發模式。
優點：1.將測試貫穿到整個軟體的生命週期中，且除了程式碼要測試。需求，設計等文件都要測試。2.更早的介入到軟體開發中，能儘早的發現缺陷並進行修復。3.測試與開發獨立起來，並於開發並行。
缺點：1.對有些專案，開發過程中根本沒有文件產生，故W模型無法使用。2.對於需求和設計的測試技術要求很高，實踐起來很困難。
（4）H模型（整套課程都是圍繞H模型）：專案的流程（在公司裡面測試和開發崗位是怎麼樣去協調工作的，從這個專案的立項到拿到需求以及中間經歷了什麼樣的內容，到產品輸出上線）
1.分為兩條線，一條開發線，一條測試線。開發人員和需求人員拿到需求規格說明書（SRS）之後進行澄清，為什麼要澄清？因為產品經理根據使用者的需求提煉為專案需求的過程中可能會有模稜兩可的地方，總共24W，有6W的時間對需求文件進行澄清看需求，產品經理在第3W的時候會主持召開需求澄清會議進行需求評審，此時開發和測試人員對需求文件瞭解的差不多了，開發和測試人員對需要改進的地方提出意見，透過不斷地意見交換和修改，最終會形成需求規格說明書（需求規格說明書本質上還是需求文件，只不過得到了大家的一致認可後才叫需求規格說明書）
假設6個月（=180天=24周W）1個版本》先有專案還是先有版本/產品？》先有專案，立項之後透過專案的開發，專案的實施才有產品的上線
& 專案和版本/產品的關係？》微信成立8年 , V1.0, V2.0，》版本會不斷迭代開發。
2.需求規格說明書之後，開發人員說我可以開發，測試人員說我可以測試。2W的時間開發人員編寫概要設計說明書（HLD）以及詳細設計說明書（LLD）。與此同時測試人員繼續深入瞭解SRS,然後評審HLD，LLD，測試經理輸出測試計劃和測試方案，測試工程師輸出testcase（測試用例或者測試案例TC）並進行多次用例評審，最終形成用例基線文件。==》開發人員在寫程式碼的同時測試人員在寫測試用例。
3.多次用例評審有三種方式：
交叉評審：在測試組內測試人員相互進行先評審（人員一般就是測試組裡面的）
組內評審（又稱正式評審)：在專案組內進行評審（專案經理，測試經理，開發經理，開發人員等等與專案組相關的人員）
會議評審：有客戶方參與。
需求評審或者說需求澄清會議是由產品經理召開和產品經理主講
案例評審會議是由測試經理召開，是由測試人員主講（誰寫的用例誰講）
基線文件：當前的狀態非常的穩定且已經終結，不可以被隨意的更改，隨時可以進入到下一個狀態。
測試經理將用例基線文件輸出到testlink用例管理工具（又稱測試管理工具》禪道：專案管理工具和用例和BUG管理工具），並將TC（test case）測試用例初稿分配給TE（誰寫誰測的原則）
開發人員將寫好的程式碼打包然後給到測試經理進行部署專案》測試經理或測試骨幹或測試環境運維人員搭建測試環境》基於Linux系統部署專案包
4.常用的環境有哪些：
測試環境（測試伺服器）：測試人員在這個環境上進行系統整合測試。
開發環境（開發伺服器）：開發人員在這個環境上進行程式碼的開發，除錯。
預釋出環境：產品在預釋出環境上進行驗收測試，如果驗收沒問題，則將程式碼包發給運維人員，運維人員將程式碼包部署到線上環境。
生產環境（正式伺服器）：又叫做真實線上環境，例如騰訊課堂可以購買網路課程，給到所有使用者使用的環境。
5.部署完專案之後的操作：
測試人員進行冒煙測試》來源於硬體行業》電路板：最主要的功能已經失效》冒煙測試：測試主體功能》測試QQ的登入主體功能，QQ登入成功》支付功能的主體功能》找回密碼功能的主體功能》找回密碼成功
冒煙測試不透過重新把版本打回》開發人員重新去修改程式碼
冒煙測試用例是從sit1測試
冒煙測試透過則執行sit1測試
sit1叫做第一輪系統整合測試，又叫做全量測試，例如當前版本寫了1000條用例，要把所有寫的用例執行一遍（1000條用例能發現大約300-400個bug）。冒煙測試用例是從所有寫的1000條測試用例中選取20-30條進行測試
sit2叫做第二輪系統整合測試，又叫做迴歸測試(從第二輪測試開始到最後一輪都可以稱之為迴歸測試)，又叫做增量測試（在原有的用例上面增加新的用例增加了50條）》迴歸測試測什麼？會選取450條》測試上一輪出現BUG的用例。測試主體功能（冒煙測試）。測試與上一輪出現BUG相關模組的用例。測試新增加的用例。
sit3簡稱叫做迴歸測試，選取200條用例
sit4簡稱叫做迴歸測試，選取60條用例
發現的bug呈快速收斂狀態是哪個階段？》從系統整合測試到進入迴歸測試
sit4為什麼會存在0個bug或者1個bug?》這個1個bug可能是建議性（應用型）的bug，不對功能使用造成影響，功能性bug必須全部測試完成，直到全部修復》建議性的bug可以和測試經理申請可以放到下個版本進行修復
測試完成之後達到上線的硬性條件是什麼？最終實現的 0 bug
6個月一個版本，假設有20個子需求點》開始，語音通話，聊天 現在：紅包，小程式，公眾號，影片號》先挑最主要的功能進行實現
H模型可以理解為也是一個迭代開發模型，在H模型中，軟體測試過程活動完全獨立，貫穿於整個產品的週期，與其他流程併發的進行，某個測試點準備就緒時，就可以從測試準備階段進行到測試執行階段，軟體測試可以儘早的進行，軟體測試可以根據被測物的不同而分層次進行。
（5）敏捷開發模型：這是一種新的模型，前面的幾種都是屬於傳統型，它能適應快速需求變化，交付週期短，輕量級的開發模式。
（6）迭代開發模型：專案被分為大量迭代過程，一次迭代就是一個完整的開發迴圈，是一個可以釋出的可執行的產品，屬於軟體開發週期中最終產品的一個子集。
（7）增量開發模型：專案被劃分為一系列的增量，每一個增量都交付整個專案需求中的一部分功能。需求按優先順序進行劃分增量的支付。
【四】測試的基本原則
【1】測試的標準是使用者需求
【2】測試不僅僅是單純的軟體本身的測試
【3】軟體外在沒有失效不代表軟體系統是可用的
【4】軟體的完美度沒有完全正確的，測試只能幫助軟體更加完美，更加正確
【5】窮盡測試是不可能的（有些條件組合非常多，窮盡測試是不可能的）
==》窮盡測試是指包含了軟體輸入值和前提條件所有可能組合的測試方法，完成窮盡測試的系統裡應該不殘留任何未知的軟體缺陷，你可以透過做更多的測試來找到他們，也就是說你的測試還沒有窮盡。
【6】測試應該儘早介入（早期引入的問題佔到整個問題數目的50%以上）
【7】二八原則：80%的缺陷或錯誤會集中出現在單元測試階段20%的區域中
【8】殺蟲劑效應：也就是說要不斷更新用例，因為反覆的執行相同的測試用例將會發現新缺陷的能力幾乎為零。
【9】測試活動依賴測試物件，測試的關注點不一樣，有的更多關注安全和效能的測試
【10】儘量選擇第三方測試，避免自己測試自己開發的程式。
【五】測試活動的生命週期（指的是測試流程）
測試計劃（測試准入）與控制》測試分析與設計》測試實現與執行》測試報告（測試準出）》測試過程資產歸檔（測試總結）