1. 從「用戶登錄」開始談測試

1.1.將「用戶登錄」測試用例分分類

等價類劃分和邊界值分析方法是最常用、最典型、也是最中要的黑盒測試方法（2.3.中會詳細說明）

• 等價類劃分：是將所有可能的輸入數(shù)據(jù)劃分成若干個子集，在每個子集中任意一個輸入數(shù)據(jù)對于揭露程序中潛在錯誤都具有同等效果，那么這樣的子集就構(gòu)成一個等價類。
• 邊界值分析方法：是選取輸入、輸出的邊界值進行測試。

用戶登錄測試用例.png

優(yōu)秀的測試工程師必須具有寬廣的知識面，才能設(shè)計出有針對性、便于發(fā)現(xiàn)問題的測試用例。

1.2.窮盡測試

所謂的“窮盡測試”是指包含了軟件輸入值和前提條件所有可能組合的測試方法，完成窮盡測試的系統(tǒng)里應(yīng)該不殘留任何未知的軟件缺陷，你可以通過做更多的測試來找到它們，也就是說你的測試還沒有窮盡。
軟件測試的用例設(shè)計是不可窮盡的，工程實踐中難免受制于時間成本和經(jīng)濟成本，所以優(yōu)秀的測試工程師需要兼顧缺陷風(fēng)險和研發(fā)成本之間的平衡。

原文鏈接為極客時間版權(quán)所有: https://time.geekbang.org/column/article/10030

2. 如何設(shè)計一個“好的”測試用例？

2.1. 什么是“好的”測試用例？

“好的”測試用例一定是一個完備的集合，他能夠覆蓋所有等價類以及各種邊界值，而跟否發(fā)現(xiàn)缺陷無關(guān)。

2.2. “好的”測試用例具備那些特征

1. 整體完備性：“好的”測試用例一定是完備的整體，是有效的測試用例組成的集合，能夠完全覆蓋測試需求。
2. 等價類劃分的準(zhǔn)確性：值的是對于沒個等價類都能保證只要其中一個輸入測試通過，其他數(shù)據(jù)也一定測試通過。
3. 等價類集合的完備性：需要保證所有可以的邊界值和邊界條件都已經(jīng)正確識別。

2.3. 三種常用的測試用例設(shè)計方法

測試用例的設(shè)計方法：比如等價類劃分法、邊界值分析法、錯誤推測方法、因果圖方法、判定表驅(qū)動分析法、正交實驗設(shè)計方法、功能圖分析方法、場景設(shè)計方方法、形式化方法、擴展有限狀態(tài)機方法等等。

我們以身份證中的7～14位日期是否有效設(shè)計測試用例

1. 等價類劃分方法：
   • 有效等價類：年按人類最高年齡120歲推算，有效年份應(yīng)為2019～1899年中間；月應(yīng)為1～12月；日應(yīng)為1～31日；
   • 無效等價類：年小于1899年或大于2019年；月等于00或大于12；日等于00或大于31日；
2. 邊界值分析方法：選取閏年非閏年20040229以及20050228；大小月日期20000630以及2000731；
3. 錯誤推測方法：身份證號不可重復(fù)；數(shù)據(jù)庫鏈接失??；

有了上述的三種方法后，如果要對身份證號碼有效性設(shè)計全面的設(shè)計用例，將所有位的有效性都考慮到的話，首先要去具體了解了身份證編碼規(guī)則后去做對應(yīng)的有效驗證。

具體到測試用例本身的設(shè)計，有兩個關(guān)鍵點需要你注意。

1. 從軟件功能需求出發(fā)，全面地、無遺漏地識別出測試需求是至關(guān)重要的，這將直接關(guān)系到用例的測試覆蓋率。
2. 對于識別出的每個測試需求點，需要綜合運用等價類劃分、邊界值分析和錯誤推測方法來全面地設(shè)計測試用例。

最后，如果想設(shè)計一個“好的”測試用例，你必須要深入理解被測軟件的架構(gòu)設(shè)計，深入軟件內(nèi)部的處理邏輯，需求覆蓋率和代碼覆蓋率這兩個指標(biāo)可以幫你衡量測試執(zhí)行的完備性。

原文鏈接為極客時間版權(quán)所有: https://time.geekbang.org/column/article/10150

3. 單元測試（Junit）

3.1. 為什么要做單元測試？

很多公司都不會做單元測試，包括我，現(xiàn)階段也不做單元測試。主要原因是現(xiàn)在的開發(fā)要求速度的要快，迭代要快，不做單元測試可以節(jié)約很大的時間成本以及人力資源。
但放在長遠的時間線上來看，不做單元測試會存在出現(xiàn)Bug不知道那塊代碼出了問題（因為不停的在迭代會讓原先成立的接口出現(xiàn)一些因為原先需求開始忽略，而導(dǎo)致不知道是那里出了問題）
這時候單元測試的作用就體現(xiàn)了，每次迭代的功能代碼與測試代碼對應(yīng)，跑一遍測試代碼就知道哪里出了問題，可及時修改。

3.2. Java中使用的測試框架Junit5

由于我也是初學(xué)者，就不展開說了，下面是Junit5的學(xué)習(xí)鏈接：JUnit 5 Jupiter API
以及Junit官方文檔：官方文檔

學(xué)習(xí)中多理解注釋（Annotations）與斷言（Assertions）的內(nèi)容。后續(xù)對Junit的學(xué)習(xí)內(nèi)容單獨寫文章說明。

總之，測試用的框架與工具是其次，重要的是先弄清楚要測什么！

原文鏈接為極客時間版權(quán)所有: https://time.geekbang.org/column/article/10275

4. 自動化測試

4.1. 為什么要自動化測試？

自動化測試的本質(zhì)是用一段代碼去測試另一段代碼的過程。由此可見，自動化測試的代碼編寫是費時費力的（這里依然推薦用Junit）。
自動化測試使用比較多的場景如下：

1. 回歸測試（再次測試原先已完成的功能代碼）
2. 持續(xù)運行測試系統(tǒng)穩(wěn)定行及高并發(fā)場景的壓力測試。
3. 保證每次執(zhí)行測試的操作以及驗證的一致性。
   此類較機械化操作的測試場景，需要用到自動化測試

4.2. 什么樣的項目適合自動化測試？

1. 需求穩(wěn)定，不會頻繁變更
2. 研發(fā)和維護周期長，需要頻繁執(zhí)行回歸測試
   • 軟件產(chǎn)品比軟件項目更適合做自動化測試。
   • 對于軟件項目的自動化測試，就要看項目的具體情況了。最終目標(biāo)是用20%的精力去覆蓋80%的回歸測試。
3. 需要在多種平臺上重復(fù)運行相同的場景
4. 某些測試項目通過手工測試無法實現(xiàn)，或者手工成哥太高
5. 被測軟件的開發(fā)較規(guī)范，能夠保證系統(tǒng)的可測試性
6. 測試人員已經(jīng)具備一定的編程能力

總之，測試用例的設(shè)計是至關(guān)重要的，在這之前，不要花太多的精力在自動化測試上。如果維護自動化測試的代價高過了節(jié)省的測試成本，那么在這樣的項目中推進自動化測試就會得不償失。

原文鏈接為極客時間版權(quán)所有: https://time.geekbang.org/column/article/10483

5. 軟件開發(fā)各階段的自動化測試

這一講的專業(yè)詞匯較多，不懂的詞匯多搜索了解下！

下面圖中展示的是軟件開發(fā)的各個階段以及對應(yīng)會使用到的技術(shù)、工具：

測試技術(shù)、工具.png

原文鏈接為極客時間版權(quán)所有: https://time.geekbang.org/column/article/10572

6. 什么是測試覆蓋率？

測試覆蓋率.png

需求覆蓋率：需求覆蓋率是指測試對需求的覆蓋程度，通常的做法是將每一條分解后的軟件需求和對應(yīng)的測試建立一對多的映射關(guān)系，最終目標(biāo)是保證測試可以覆蓋每個需求，以保證軟件產(chǎn)品的質(zhì)量。

代碼覆蓋率：代碼覆蓋率是指，至少被執(zhí)行了一次的條目數(shù)占整個條目數(shù)的百分比。

這篇還是看原本較好，明白代碼覆蓋率是什么？該怎么做？

原文鏈接為極客時間版權(quán)所有: https://time.geekbang.org/column/article/10759

7. 如何高效填寫軟件缺陷報告？

7.1. 什么是缺陷報告？

缺陷報告是測試工程師與開發(fā)工程師交流溝通的重要橋梁，也是測試工程師日常工作的重要輸出。

7.2. 缺陷報告的組成部分

缺陷報告.png

原文鏈接為極客時間版權(quán)所有:https://time.geekbang.org/column/article/10936

8. 測試計劃

8.1. 沒有測試計劃會怎么樣？

1. 很難確切地知道具體的測試范圍，以及應(yīng)該采取的具體測試策略；
2. 很難預(yù)估具體的工作量和所需要的測試工程師數(shù)量，同時還會造成各個測試工程師的分工不明確，引發(fā)某些測試工作被重復(fù)執(zhí)行而有些測試則被遺漏的問題；
3. 測試的整體進度完全不可控，甚至很難確切知道目前測試的完成情況，對于測試完成時間就更難預(yù)估準(zhǔn)確的時間節(jié)點了；
4. 整個項目對潛在風(fēng)險的抵抗能力很弱，很難應(yīng)對需求的變更以及其他突發(fā)事件。

8.2. 做測試計劃中要解決那些問題？

測試計劃.png

原文鏈接為極客時間版權(quán)所有: https://time.geekbang.org/column/article/11063

9. 軟件工程師的核心競爭力

9 .1. 測試工程師的基礎(chǔ)知識

測試基礎(chǔ)知識.png

9.2. 傳統(tǒng)測試工程是的核心競爭力

傳統(tǒng)測試工程師的核心競爭力.png

9.3. 測試開發(fā)工程師

首先既然是測試開發(fā)工程師，那么代碼開發(fā)能力是最基本的要求。

1. 測試系統(tǒng)需求分析能力
2. 更寬廣的知識體系

原文鏈接為極客時間版權(quán)所有: https://time.geekbang.org/column/article/11325

10. 測試工程師需要掌握的非測試知識

與開發(fā)工程師相比，你需要了解的技術(shù)種類要多得多，視野也要寬廣很多，只是在每類技術(shù)的深度方面不如開發(fā)工程師。

你可以參照下面這個比喻，來理解開發(fā)工程師和測試工程師的對知識的要求：開發(fā)工程師通常是“深度遍歷”，關(guān)注的是“點”；而測試工程師通常是“廣度遍歷”，關(guān)注的是“面”。

非測試知識.png

原文鏈接為極客時間版權(quán)所有: https://time.geekbang.org/column/article/11453

11. 互聯(lián)網(wǎng)產(chǎn)品測試策略

11.1. 傳統(tǒng)軟件測試策略設(shè)計

重單元測試

傳統(tǒng)測試策略.png

11.2. 互聯(lián)網(wǎng)產(chǎn)品測試策略

重API測試

互聯(lián)網(wǎng)測試策略.png

原文鏈接為極客時間版權(quán)所有: https://time.geekbang.org/column/article/11462