1.?行為準(zhǔn)則

文章來源地址http://www.zghlxwxcb.cn/news/detail-750146.html

2.?編寫、運(yùn)行和修復(fù)測試用例會讓人感覺很忙碌

2.1.?測試本身才更容易成為繁忙的工作

2.2.?糟糕的測試會增加開發(fā)人員的開銷而不提供價值，并且還會增加測試套件的不穩(wěn)定性

3.?測試用途

3.1.?測試可以檢查代碼是否正常工作

3.1.1.?測試本身就可以驗證軟件的行為是否符合預(yù)期

3.1.2.?預(yù)料之外的軟件行為會給用戶、開發(fā)人員和運(yùn)維人員帶來很多困擾

3.1.3.?測試這道工序可以證明代碼已經(jīng)按規(guī)定生效了

3.2.?保護(hù)代碼不會被將來那些無意中的修改所影響

3.2.1.?測試可以保護(hù)現(xiàn)有的行為不受新變化的影響

3.3.?鼓勵清爽的代碼

3.4.?強(qiáng)迫開發(fā)者試用他們自己的API

3.4.1.?編寫測試也迫使開發(fā)人員思考他們程序的接口和實現(xiàn)過程

3.4.2.?編寫測試也可以迫使開發(fā)人員分別通過改進(jìn)關(guān)注點分離和降低緊耦合的方式來確保他們的代碼擁有良好的構(gòu)造

3.5.?記錄組件之間如何交互

3.5.1.?測試其實是另一種形式的文檔，它說明了代碼是如何被交互的

3.6.?作為一個實驗的“游樂場”

3.7.?測試驅(qū)動的開發(fā)

3.7.1.?test driven development，TDD

3.7.2.?TDD是指在寫代碼之前先編寫測試的實踐，如果測試寫好之后運(yùn)行測試失敗了，那么就去編寫代碼使其通過

4.?測試類型

4.1.?成功的項目會在現(xiàn)實世界中做出務(wù)實的測試決定

4.2.?單元測試

4.2.1.?驗證代碼的“單元”

4.2.2.?通常指某個單一的方法或行為

4.2.3.?單元測試應(yīng)該快速、簡短且集中

4.2.3.1.?消除外部依賴性可以使單元測試快速而集中

4.2.4.?模擬遠(yuǎn)程系統(tǒng)允許測試?yán)@過網(wǎng)絡(luò)調(diào)用，可簡化設(shè)置，并且避免緩慢的運(yùn)行過程

4.2.5.?模擬方法和對象允許開發(fā)人員編寫集中的單元測試，這些單元測試可以只完成一個特定的行為動作

4.3.?集成測試

4.3.1.?驗證多個組件集成在一起之后是否還能正常工作

4.3.2.?如果你發(fā)現(xiàn)自己在測試中實例化了多個相互作用的對象，那么你正在寫的可能就是集成測試

4.3.3.?開發(fā)人員運(yùn)行集成測試的頻率較低，所以反饋的周期更長

4.3.4.?可以找出那些通過各自獨(dú)立的單元測試難以發(fā)現(xiàn)的問題

4.4.?系統(tǒng)測試

4.4.1.?驗證整個系統(tǒng)的整體運(yùn)行情況

4.4.2.?端到端(end-to-end，e2e)的工作流程是為了模擬在預(yù)生產(chǎn)環(huán)境中系統(tǒng)與真實用戶的互動

4.5.?性能測試

4.5.1.?監(jiān)控不同配置下的系統(tǒng)性能

4.5.2.?負(fù)載測試可以監(jiān)控不同負(fù)載水平下的性能

4.5.3.?壓力測試將系統(tǒng)負(fù)載推高到崩潰的程度

4.5.3.1.?壓力測試可暴露系統(tǒng)的負(fù)載能力究竟有多大，以及在過度負(fù)載下會發(fā)生什么狀況

4.5.4.?對于容量規(guī)劃和服務(wù)等級目標(biāo)定義非常有用

4.6.?驗收測試

4.6.1.?指由客戶或其代理人進(jìn)行的，以驗證交付的軟件是否符合驗收標(biāo)準(zhǔn)的測試

4.6.2.?正式的驗收測試及驗收標(biāo)準(zhǔn)是作為昂貴的合同中的一部分來規(guī)定的

4.6.3.?國際標(biāo)準(zhǔn)化組織(International Standards Organization，ISO)要求驗收測試可以驗證明確的業(yè)務(wù)需求，作為其安全標(biāo)準(zhǔn)的一部分

4.6.3.1.?ISO認(rèn)證審核委員會要求提供需求和相應(yīng)的測試文件證據(jù)

5.?測試工具

5.1.?測試用例的編寫工具

5.1.1.?如模擬庫，可以幫助你編寫干凈和高效的測試

5.1.2.?模擬庫通常用于單元測試，特別是在面向?qū)ο蟮拇a中

5.1.3.?模擬庫還可以防止應(yīng)用程序的代碼中充斥著測試專用的方法、參數(shù)或變量

5.1.4.?模擬庫可以幫助開發(fā)人員訪問受保護(hù)的方法和變量，而無須修改常規(guī)代碼

5.1.5.?對模擬庫的過度依賴是一種代碼異味，它表明代碼緊緊地耦合在了一起

5.2.?測試框架

5.2.1.?通過模擬測試的生命周期，從setup到teardown，幫助測試的運(yùn)行

5.2.1.1.?管理測試的setup和teardown

5.2.1.2.?管理測試執(zhí)行和編排

5.2.1.2.1.?可以通過編排測試流程來幫助控制測試的速度和隔離度

5.2.1.2.2.?串行測試是一個接一個地執(zhí)行，一次執(zhí)行一個測試會更安全，因為測試之間相互影響的機(jī)會比較少

5.2.1.2.3.?并行執(zhí)行更快捷，但由于共享的狀態(tài)、資源或其他污染，因而更容易出錯

5.2.1.3.?生成測試結(jié)果報告

5.2.1.3.1.?幫助開發(fā)人員調(diào)試那些失敗的構(gòu)建任務(wù)

5.2.1.4.?提供工具，如擴(kuò)展的斷言方法

5.2.1.5.?與代碼覆蓋率工具集成

5.2.2.?還可以保存測試結(jié)果，與構(gòu)建系統(tǒng)集成，并提供其他的輔助功能

5.3.?代碼質(zhì)量工具

5.3.1.?強(qiáng)制執(zhí)行代碼質(zhì)量規(guī)則的工具被稱為linter，linter可以運(yùn)行靜態(tài)分析并執(zhí)行代碼風(fēng)格檢查

5.3.2.?對那些未能通過質(zhì)量檢查的代碼庫要有務(wù)實精神

5.3.3.?不要讓代碼變得更糟，但也要避免以破壞性地停止一切的方式來清理工程

5.3.4.?用來分析代碼覆蓋率和代碼復(fù)雜性

5.3.4.1.?代碼復(fù)雜度工具可以通過計算圈復(fù)雜度

5.3.4.1.1.?大致上通過代碼的路徑數(shù)量來防范過于復(fù)雜的邏輯

5.3.4.1.2.?你的代碼復(fù)雜度越高，就越難測試，也越有可能包含更多的bug

5.3.4.1.3.?圈復(fù)雜度通常隨著代碼庫的大小而增加，所以總體得分高并不一定是壞事

5.3.4.2.?代碼覆蓋率工具衡量的是有多少行代碼被測試套件執(zhí)行過

5.3.4.2.1.?如果你修改的代碼降低了代碼覆蓋率，你應(yīng)該編寫更多的測試用例

5.3.4.2.2.?確保測試用例可以對你所做的任何新的修改進(jìn)行驗證，以合理的覆蓋率為目標(biāo)

5.3.4.2.2.1.?經(jīng)驗值是65%到85%

5.3.4.2.3.?僅僅依靠覆蓋率并不能夠衡量測試質(zhì)量的優(yōu)劣

5.3.4.2.3.1.?它可能會有很大的誤導(dǎo)性，無論是在高覆蓋率還是低覆蓋率的時候

5.3.4.2.3.2.?為了達(dá)到100%的覆蓋率而癡迷于創(chuàng)建單元測試并不能保證你的代碼能夠安全地集成

5.3.5.?通過靜態(tài)分析來尋找bug

5.3.6.?檢查代碼風(fēng)格錯誤

5.3.6.1.?代碼風(fēng)格檢查工具可以確保所有源代碼的格式相同

5.3.6.2.?每行最大字符數(shù)、駝峰命名法與蛇形命名法、適當(dāng)?shù)目s進(jìn)

5.3.6.3.?一致的風(fēng)格有助于多名程序員在一個共享代碼庫上進(jìn)行協(xié)作

5.3.6.4.?強(qiáng)烈建議你設(shè)置你的IDE，以便可以自動應(yīng)用所有的風(fēng)格規(guī)則

5.3.7.?通常被設(shè)置為構(gòu)建或編譯步驟的一部分來運(yùn)行

到了這里，關(guān)于讀程序員的README筆記06_測試（上）的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！