面試問題：
1.什麼是軟件測試？
軟件功能是否滿足客戶的需求。
目的：找BUG，驗證是正確的
注意事項：
1.不要背答案
2.結合目前學習,寫代碼的一些體會
3.結合生活的一些案例
對本人來說：軟件測試就是在完成了自己的項目後，進行多方面測試，比如臨界值，不同環境下，跳轉上然後找到BUG，將項目完成的更好，還有與自己預期結果的做一個對比，驗證是不是滿足自己的需求。代碼實現相當於只是完成了框架，就像蓋房子一樣一個毛坯房，而軟件測試就是裝修，最後入住的一定是裝修過沒有問題的新家。
同時在這裏我們可以對軟件測試的流程進行了解：
1.需求分析，需求評審
需求分析和評審是對客戶的需求進行分析看是否可行，需要怎麼進行測試。
2.編寫測試計劃：
編寫測試計劃通俗的講就是什麼人在什麼時間做什麼事，最後產出什麼東西。
也就是測試人員要測試那些模塊，在什麼期限提交什麼文檔。
3.編寫測試用例，用例評審
測試用例就是想好被測試物品，用什麼方法測試驗證它的功能一系列。
評審：主要審覈測試用例不能想當然的測試，作爲測試工程師需要有“破壞性”想法測試軟件。
4.執行測試，提交BUG，迴歸測試：
bug是缺陷，發現後需要提交給開發人員修改，然後進行迴歸測試，驗證bug是否被修復。
5.編寫測試總結報告
bug都改好了後，要編寫測試總結報告，這款軟件的質量如何。
千萬需要注意不要與軟件生命週期混淆
軟件的生命週期：
- 需求分析
- 軟件設計
- 程序編碼
- 軟件測試
- 運行維護
2.爲什麼要做軟件測試？
本人回答：本人認爲軟件測試是必不可少的一項，尤其在我們實現了一些功能，後會進行驗證，不斷的修復bug可以將項目進行優化，給用戶提供更好的產品。也是個人性格方面，遇到問題不是很害怕，喜歡追根溯源找到產生問題的源頭。
3.作爲一個合格的軟件測試人員應該具有哪些素質？
本人回答：掌握一門技術語言，熟悉網絡數據庫，瞭解Linux的一些基本指令這些
一定要具有很良好的溝通能力，遇到代碼bug上的一些問題的時候我們是需要與研發工作人員對接，相比較告訴研發工作人員的有bug，不如直接告訴我們找到bug導致了什麼樣的問題總結起來，也可以減少研發相對應的工作。同時也需要對自己有收穫的東西進行總結歸類，一方面是沉澱提升個人能力，也會鍛鍊解決問題的思維。
3.研發與測試(測開)的區別？
測開區別與測試：
1.掌握自動化
2.具有代碼能力
研發與測試的區別：
1.目的：研發完成開發任務（完成），測試驗證（研發完成的正確性）。
2.階段：研發主要參與編碼，測試是貫傳整個軟件的生命週期。
3.開發工具不同
4.方法（研發 if else for等）（測試黑盒白盒包括一些測試用例編寫的方法）
5.發展方向（研發：技術：架構師 其他：CEO）
6.工作內容：研發：根據需求通過代碼來實現。測試：藉助工具驗證開發人員的代碼。
三大概念：
需求：
符合正式文檔規定的條件和權能，分爲用戶需求和軟件需求
用戶需求：比較粗，只是大概的功能描述。
軟件需求：可以指導項目組成員進行下一步工作。研發人員可以設計，編碼。測試可以編寫測試用例。
BUG：
與需求規格說明書（前提需求正確）或用戶期望（合理期望）不匹配的
測試用例：
向被測試的程序輸入的一組集合：
要素：測試環境，測試數據，測試步驟，預期結果，備註，測試版本，前提條件等…
軟件的生命週期：需求-計劃-設計-編碼-測試-運行維護。
研發模型：瀑布模型：
特點：串型
適合的項目：需求相對穩定的項目，已有類似的項目。
缺點：
1.發現缺陷的時機比較晚，修改缺陷的成本高
2.過程中積累的經驗不能及時的分享給其他項目。
3.測試是最後環節，讓人覺得測試不重要。
螺旋模型：
特點：漸進式（每環進行風險分析）
強調：風險
適合的項目：複雜度高，風險大，規模龐大。
優點：項目的風險低。
缺點：風險分析需求時間，增加時間成本，項目進度緩慢。
增量，迭代：
目的：減少項目的風險。
適用：大型項目
增量：第一次發佈10個功能，第二次發佈10個功能且對第一次發佈的功能不會造成影響。不需要修改
迭代：第一次發佈，第二次發佈，第二次發佈會對第一次的有影響：必須修改第一次發佈中的一些功能。
敏捷：
宣言：
1.輕文檔
2.客戶參與
3.擁抱變化
4.人與人的溝通
scrum敏捷模式:
核心角色：
PO （產品負責人）
SM（敏捷教練）
TEAM
特點：人員要求5-10人
站會：時間不超多15分鐘
迭代週期：1-4周
敏捷開發的流程：PO整理user story—發佈計劃會議（項目進行幾次迭代）–迭代會議（分配任務，確認時間）–研發中–研發完成–測試中–測試完成（完成一個給待發布里面放一個）–待發布–發佈上線
傳統的開發模型：只關注結果。敏捷開發：不僅關注結果，更關注過程。
傳統的開發模型與敏捷開發模型的區別：
傳統的開發模型有什麼？
他們的特點是什麼？
敏捷的開發模型和特點？
主要區別於傳統開發模型：敏捷開發模型輕文檔，客戶參與，更新迭代快，注重溝通
敏捷測試：
1.不依賴文檔–重在溝通，自己的文檔–思維導圖
2.迭代頻繁–調整自己，盡力適應。
軟件測試的常用類型：
1、單元測試
這是在開發人員級別使用的最基本的測試，測試人員專注於單元代碼的單個部分，而它已經從任何外部交互或依賴於任何模塊之前被隔離。這個測試要求開發人員檢查他們編寫的最小代碼單元，並證明單元可以獨立工作
2.集成測試：
在開發人員級別上，在單元測試之後，還應該仔細檢查這些最小代碼的組合(或集成)。集成測試提供了訪問網絡、數據庫和文件系統的測試模塊。
它們將指示數據庫和網絡在合併到整個系統時是否運行良好。最重要的是，在前一階段測試的小代碼單元之間的連接將在這個階段被證明。
3.功能測試：
毫無疑問，功能測試是更高級別的測試類型，應該在集成測試之後使用。
功能測試檢查輸出與規範中定義的輸入的準確性。對中間值不太重視，但對所創建的最終輸出給予了更多的關注。
4.冒煙測試：
冒煙測試的類比來自於電子產品，其中一個問題意味着電路板散發出煙霧。
在功能測試完成之後，在新安裝和更新的輸入值之後，將在起始點執行一個簡單的測試.
5.迴歸測試
當系統中出現複雜的bug時，通常會影響系統的核心區域，所以使用迴歸測試來重新測試系統的所有模塊
6.UI測試：
除了上面的核心測試類型， UI測試現在也是一個衆所周知的，在軟件工程行業非常流行。該圖形用戶界面測試確保了對所有用戶友好的特定應用程序或產品。UI測試主要評估設計組件，如佈局、顏色、字體、大小等等。另外， UI測試可以手動和自動執行。
當然這不是完整的測試分類列表，因爲目前已經有超過150種的測試類型，並且仍在增加中。另外請注意，並非所有測試類型都適用於所有項目，這仍然取決於項目的性質以及測試範圍。
測試模型：
V模型：
是串行所以結合瀑布模型一樣具有：發現bug時間晚，修復起來成本大，不能及時分享項目經驗，測試爲最後環節。
W模型：
強調測試伴隨着整個軟件開發週期，而且測試的對象不僅僅是程序，需求、設計等同樣要測試，也就是說，測試與開發是同步進行的。
W模型的優點：
有利於儘早全面地發現問題。從需求分析開始測試工程師就參與到項目的測試中，當需求分析完成後，測試工程師就需要參與到需求的驗證和確認活動中，並需要提供可測試性需求分析說明書，這樣可以儘早地發現需求階段的缺陷。同時，對需求的測試也有利於及時瞭解項目難度和測試風險，及早制定應對措施，這將顯著減少總體測試時間，加快項目進度。
缺點：
存在侷限性，需求、設計、編碼等活動被視爲是串行的，同時，測試和開發活動也保持着一種線性的前後關係，上一階段完全結束，纔可正式開始下一階段工作，這樣就無法支持迭代的開發模型。對於當前軟件開發複雜多變的情況，W模型並不能解除測試管理面臨的困惑。
W模型的特徵：
(1)測試階段劃分得更全面，不僅僅是單元測試、集成測試和系統測試;
(2)測試與開發是並行的，從需求測試就應該開始介入;
(3)提出儘早測試的概念，這樣可以降低缺陷修復成本;
(4)測試對象不僅僅是程序，還包括需求或其他的相關文檔。
軟件測試能夠適應敏捷開發模式：車輪模型
“車輪”模型是一種以用戶需求和用戶反饋爲驅動，以測試爲核心、用於迭代開發模式的測試模型。由於用戶需求和用戶反饋是增量式的遞交，所以產品開發過程是不斷重複循環的。測試滲透在產品開發的全過程中，跟蹤每一個環節的輸入和輸出。在“車輪”模型中，測試直接對需求負責，保證產品在各個階段都是符合需求的，測試對象是產品生命週期全過程。
“車輪”模型中的測試是一個獨立的流程，其中包括：測試管理和測試執行。測試管理是指，對測試計劃、測試說明、測試資源、源程序、測試用例、測試環境、測試腳本、測試報告、缺陷單等進行管理，同時對測試人員進行合理分工。測試執行是指，測試人員在分配到任務後，對測試對象進行相應的測試，包括：接口測試、功能測試、集成測試、系統測試、迴歸測試等。
由於測試在“車輪”模型中處於核心位置，跟蹤產品生命週期的全過程，所以對測試人員的要求也較高。測試人員除了能熟練執行接口測試、功能測試、集成測試、系統測試、迴歸測試等基礎測試，還需要具備需求分析、文案編輯能力，同時還需要有一定的編碼能力，能理解程序的實現算法。
模型詳述:
（１）需求分析階段：①測試需求文檔，提出需求缺陷，跟蹤缺陷修改情況；②參加需求評審，協助制定驗收標準；③根據最終確定的需求文檔編寫測試計劃；④根據需求文檔、業務流程，設計測試流程。
（２）產品設計階段：①對原型進行測試，提出原型缺陷，跟蹤缺陷修改情況；②根據需求文檔、業務流程和原型，設計功能測試用例。
（３）詳細設計階段：①測試詳細設計文檔，提出設計缺陷，跟蹤缺陷修改情況；②根據詳細設計文檔編寫接口測試計劃，設計接口測試用例和測試腳本；③根據詳細設計文檔、數據字典搭建測試環境，準備測試數據。
（４）編碼實現階段：①對已完成編碼的接口進行接口測試；②集成通過接口測試的接口進行模塊測試；③根據需要選擇進行壓力測試、性能測試、穩定性測試、兼容性測試、安全性測試、自動化測試；④跟蹤缺陷，不斷進行迴歸測試。
（５）系統集成階段：①集成全部模塊進行系統測試；②完成測試報告；③編寫用戶手冊；④收集β測試中的用戶反饋，對用戶反饋進行覈查篩選確定系統缺陷，跟蹤缺陷修改情況；⑤協助實施人員完成系統部署和產品上線。
模型優勢:
和常用測試模型相比，“車輪”模型有如下優點：
（１）強調測試對象不是代碼而是整個產品生命週期，每一個可交付的中間件都需要通過適當的方式進行測試，真正實現了“全過程”測試，提高了軟件測試質量［１２］。
（２）由於測試在項目啓動初期就參與其中，保證了測試和開發過程的密切銜接，確保能在第一時間發現錯誤。
（３）現實中的開發不是一種串行的活動，在大多數情況下是交叉進行的，那麼相應的測試也不存在嚴格的先後關係。“車輪”模型適應了這一現實狀況，讓各階段的測試（如：接口測試、集成測試、系統測試、迴歸測試等）跟隨開發進度反覆觸發、循環迭代。
（４）將測試活動完全獨立出來，同時採取敏捷方法，及時響應並全程跟蹤，完全實現了測試和開發的同步。
（５）體現了客戶、產品經理、開發人員以及測試人員之間的交互，當需求發生變更時能夠及時調整方案。並且測試結果實時反饋，也保證了測試質量。
模型應用實施
將“車輪”模型應用到一個社會治理網格化微信公衆號的開發項目中，該項目包括公衆號前臺開發和後臺管理平臺開發。其中的志願者模塊完全依照“車輪”模型進行全程測試。首先，產品經理與客戶溝通需求並完成需求文檔後，將需求文檔交付給測試人員和開發人員進行評估。在此階段測試人員會對需求的可行性、合理性及完整性進行測試，並將需求缺陷提交給產品經理。之後產品經理會根據測試提交的缺陷以及開發反饋的意見重新補充並修改需求文檔。需求文檔定稿後，產品經理、開發人員和測試人員共同參與需求評審會議，制定產品驗收標準。
接下來，產品經理根據需求文檔完成產品原型的設計後，將原型交付給開發人員和測試人員。在此階段對原型進行測試，主要包括：界面是否美觀；配色是否合理；交互是否友好；操作步驟是否簡單；功能是否齊全；使用場景是否全覆蓋；邏輯是否合理；操作流程是否順暢等。測試人員將原型缺陷提交給產品經理後，產品經理會根據測試缺陷以及開發意見對原型進行修改，最終確定原型。
開發人員根據原型進行詳細設計階段，測試人員同時設計編寫測試用例。對於需要進行接口測試的部分，測試人員依據開發人員提供的接口說明書設計編寫接口測試腳本。在此階段測試人員還要搭建測試環境，準備測試數據。
由於志願者模塊內還細分了多個小模塊，開發人員會將逐個完成的小模塊提測給測試人員。測試人員對提測的模塊會先進行冒煙測試，確保提測內容的主要功能已通，可以進行後續的全面測試。如在冒煙測試過程中發現阻塞缺陷立即打回給開發人員重新編碼。於是整個開發實現過程是一種邊開發邊測試的狀態。當所有小模塊全部完成後，開發人員會集中修復測試人員提交的缺陷，而測試人員會不斷迴歸測試已修復的缺陷。
最後測試人員還要再整體進行系統測試、兼容性測試以及併發測試。當已知缺陷全部修復完成後，產品達到驗收條件即可上線並交付給客戶使用。
配置管理，評審，變更：
配置管理：
工具：Git，SVN
管理什麼：軟件，文檔版本，代碼，工具，數據—配置項
評審：
核心文檔，測試用例，設計文檔，需求，計劃類
代碼（代碼走查，代碼審查，CODERIVWER）
變更：
提交申請–評估風險–變更–驗證–發佈
一旦變更，配置管理也要變更。
缺陷
缺陷描述：
要素：測試環境，測試數據，測試步驟，預期結果，實際結果，附件，級別，優先級…
缺陷級別：
崩潰，嚴重，一般，次要，建議
A-B-C-D-E與級別相對應。
缺陷狀態及轉換：
狀態：NEW,OPEN,FIXED,DELAY,REJECTED,CLOSE,REOPEN
如何開展第一次測試：
1.學習項目相關的文檔
2.參加項目會議
3.獲取項目相關的管理，使用地址，用戶名密碼等
4.學習相關的規範（編寫測試用例，提交缺陷，使用工具）
5.積極主動（與項目成員接觸）
如何發現更多的BUG
1.兩個28原則：（模塊，人員）
80%的缺陷是由20%的模塊引起，或者出自20%的研發人員。
2.不要依賴測試用例和需求
3.逆向思維，發散性，擴展性
4.測試要儘早介入（如果需求時就存在bug，可以降低後期的成本）
面試題：提交一個缺陷研發人員不認可怎麼辦？
- 先自查，確認缺陷。
- 不能站在自己角度是認爲“缺陷”，需要站在用戶的角度上考慮。
- 缺陷級別定位準確。
- 提高自身的業務能力與技術水平。
- 第三方進行評審。
測試用例
測試用例是爲了實施測試向被測試系統提供的一組集合，這組集合包含：測試環境，操作步驟，測試數據，預期結果等…
測試用例的設計方法：（都是黑盒測試方法使用在系統測試中）
- 基於需求的設計方法
- 等價類
- 邊界值
- 因果圖
- 正交排列
- 場景設計法
- 錯誤猜測法
基於需求
根據需求來寫測試用例：
難點在於：需要讀出除需求以外的測試點。
例：（買一款3000元以下的華爲智能手機）
我們已知信息：3000以下，智能，品牌 但是我們購買過程中是需要做一些基本的測試確保手機可以使用等一些測試。
等價類
思想：解決輸入無窮的問題
目的：減少測試用例
使用場景：只針對於輸入
概念：無窮的輸入進行N個歸類，從每一類中提取一個數據進行測試，如果這個數據測試通過就表示，這一個類測試通過。
有效等價類：符合要求，滿足客戶需求。
無效等價類：有效等價類以外。
邊界值
使用場景：輸入和輸出
概念：輸入和輸出的“邊界值”
等價類的一種補充方法，和等價類成對出現。
取值：
【1，50】 （0,1,50,51）
（1,50】（1,2,50,51）
因果圖（根據因果圖可以清楚知道輸入輸出的關係，從而根據依賴編寫測試用例）
使用場景：強調的是輸入（原因）和輸出（結果）的關係。
概念：強調的輸入（原因）和輸出（結果）關係，適用於有多個輸入，並且輸出依賴於輸入。
恆等 與 或 非
步驟：
1.梳理出所有的輸入。
2.梳理出所有的輸出。
3.梳理出輸入和輸出的關係。
4.畫因果圖
5.畫判定表--------列數（通過計算得出）
輸出：冪數 ------------輸入：底數
恆等：
與：
或
案例：
假設業務單據的處理規則爲：“淘寶618活動，提單已提交，訂單合計金額大於300元或有紅包，則進優惠”。
- 對於這條業務規則，首先通過分析所有可能的輸入和可能的輸出，可以得到如下結果：
● 輸入：訂單已提交、金額大於300、有紅包。
● 輸出：優惠、不優惠。 - 然後，進行第二步，找出輸入與輸出之間的對應關係。通過分析，可以看出有以下的對應關係。
(1)訂單已提交，訂單金額大於300元，則優惠。
(2)訂單已提交，訂單金額小於等於300元，無紅包，不優惠
(3)訂單已提交，有紅包，則優惠。
(4)訂單已提交，訂單金額大於300元，有紅包，則優惠。
(5)訂單未提交，不優惠。 - 爲了方便畫出因果圖和判定表，需要對所有輸入和輸出編號，現在編號如下。
1：訂單已提交。
2：訂單金額大於300元。
3：有紅包
21：優惠
22：不優惠 - 畫因果圖
判定表：我們輸入的條件是3個，結果是兩個所以：222=8個
正交排列法（採用抽樣，減少測試用例區別於等價類不解決輸入無窮問題）
思想：正交表------正交實驗（抽樣）
兩條性質：（畫圖重點遵守這個性質來畫圖）
1.任何列中出現的數字的個數一樣。
2.任何兩列中有序對數出現的次數一樣。
目的：減少測試用例
看起來與等價類的目的一樣。但是這裏是有區別的正交排列是需要滿足性質通過抽樣來滿足減少測試用例的，等價類主要是解決輸入無窮的問題的。
公式：L=N（TC）
L 正交表
N 實驗次數------ 通過水平和因素計算：公式是 N=(T-1)*C+1
T 水平== 變量的取值
C 因素== 變量
.
步驟：
1.理出所有的因素
2.理出所有的水平
3.選一個合適正交表
4.畫出正交表，水平帶進去。
5.第一行就是一條測試用例
6.最後將（特殊的）需要測試的數據加進去，補充測試用例
例：
1、因素：姓名、郵箱、密碼、確認密碼、驗證碼
2、水平：填寫、不填寫
我們算出N=6
水平是偶數個，所以們的測試用例可以是8,10 都行但是最少不低於6
這裏我們可以添加特殊的一些測試用例：
場景法：(不同事件流，可能會有不同的結果，根據不同場景編寫測試用例)
理解爲業務流程：把各個孤立的功能點串起來，但是一個業務流程不一定是一個場景（一條分支代表一個場景）
.
事件，事件流。
什麼是事件，什麼又是事件流呢？
我們舉例說明：
一個登陸界面，點擊登陸按鈕做爲案例。
事件：
1,判斷用戶名是否存在
2.判斷用戶名和密碼是否正確
3.判斷用戶狀態是否正確
4.判斷用戶是否激活
5.click或者submit
以上每一個單獨的都是一個事件
事件流：
我們點擊登錄按鈕後：事件是如何在後臺如何執行，是以一個什麼樣的邏輯？
1-2-3-4-5 ？
4-3-1-2-5 ？
這樣的將事件串起來的執行，稱爲事件流。
在場景發中有兩個單位：1，功能 ----------2，事件
還是以登錄的一個按鈕來說：
如果在業務角度上以功能爲單位的話：這不是一個場景。
如果在事件流的角度上以事件爲單位的話：這就是一個場景。
是否是場景，需要根據現在是以什麼爲單位來判斷。
錯誤推測法：（基於經驗和直覺，找出程序中你認爲可能出現的錯誤，有針對性地設計測試用例）
推測來源：
1.經驗可能來自於在對某項業務的測試較多
2.來自於售後用戶的反饋意見
3.從故障管理庫中整理bug。梳理出產品以往哪些地方容易出現問題，問題越多的地方，潛在的bug也就越多。
.
輸入框的類型：等價類中的無效等價類，錯誤推測法
某個模塊業務邏輯複雜：錯誤推測法
測試分類
