如何看待程序員眼中的測(cè)試
碼農(nóng)的產(chǎn)品和服務(wù)大都是以軟件形式存在的，我們存在的價(jià)值之一就是快速提供高質(zhì)量的軟件產(chǎn)品或服務(wù)。如何保障軟件的高質(zhì)量呢？這與軟件測(cè)試分不開(kāi)的，測(cè)試是保證軟件質(zhì)量的關(guān)鍵環(huán)節(jié)之一。
什么是軟件測(cè)試？
軟件測(cè)試是以評(píng)價(jià)一個(gè)程序或者系統(tǒng)屬性為目標(biāo)的任何一種活動(dòng)。測(cè)試是對(duì)軟件質(zhì)量的度量。——《軟件測(cè)試完全指南》
遠(yuǎn)在1983年，IEEE對(duì)軟件測(cè)試是：使用人工或自動(dòng)的手段來(lái)運(yùn)行或測(cè)定某個(gè)軟件系統(tǒng)的過(guò)程，其目的在于檢驗(yàn)它是否滿足規(guī)定的需求或弄清預(yù)期結(jié)果與實(shí)際結(jié)果之間的差別。也就是說(shuō)，軟件測(cè)試的最初目的是為了檢驗(yàn)軟件系統(tǒng)是否滿足需求。
雖然測(cè)試是為了發(fā)現(xiàn)程序中的錯(cuò)誤而執(zhí)行程序的過(guò)程，但并不僅僅是為了找出錯(cuò)誤。通過(guò)分析錯(cuò)誤產(chǎn)生的原因和發(fā)生趨勢(shì)，還可以幫助我們發(fā)現(xiàn)當(dāng)前軟件開(kāi)發(fā)過(guò)程中的缺陷，以便及時(shí)改進(jìn)。當(dāng)然，沒(méi)有發(fā)現(xiàn)錯(cuò)誤的測(cè)試也是有價(jià)值的，完整的測(cè)試是評(píng)定軟件質(zhì)量的一種方法。
簡(jiǎn)單地說(shuō)，軟件測(cè)試就是證明軟件不存在錯(cuò)誤的過(guò)程。
測(cè)試與QA的區(qū)別
QA是quality assurance的縮寫(xiě)，也就是質(zhì)量保證。軟件測(cè)試只是QA的一部分，是QA 的子集。QA的內(nèi)容比測(cè)試大多了，能對(duì)產(chǎn)品、工作流程、組織方式等跟公司經(jīng)營(yíng)有關(guān)的事情進(jìn)行反饋，很多外企的高層都是QA出身，尤其在制造業(yè)。 簡(jiǎn)單的來(lái)說(shuō)，測(cè)試從技術(shù)上保證軟件質(zhì)量，QA從過(guò)程上保證軟件質(zhì)量。
QA關(guān)注的重點(diǎn)不僅僅是軟件的質(zhì)量，而是整個(gè)軟件過(guò)程，尤其是過(guò)程和體系，例如ISO 9000系列的質(zhì)量體系等。一句話，所有和質(zhì)量相關(guān)的事都是QA的事。
測(cè)試的領(lǐng)域
剛?cè)胄械臅r(shí)候，從硬件工程師轉(zhuǎn)作測(cè)試。嚴(yán)格遵循貝爾北方實(shí)驗(yàn)室的軟件工程流程，將測(cè)試領(lǐng)域分為13個(gè)，由于年代的久遠(yuǎn)，現(xiàn)在只能記得11個(gè)了。
功能性測(cè)試 functionaliy
軟件的功能性是第一要?jiǎng)?wù)，完成一半功能的成品也要強(qiáng)于完成了全部功能的半成品。 軟件實(shí)現(xiàn)了哪些功能？是否真正完成了這些功能呢？
健壯性測(cè)試 Robustness
健壯性是指軟件的容錯(cuò)能力，違約的輸入能否導(dǎo)致故障的引入呢？長(zhǎng)時(shí)間的壓測(cè)是否會(huì)導(dǎo)致程序異常呢？
性能測(cè)試 performance
用戶體驗(yàn)至上的背后是性能至上，良好的運(yùn)行性能才能滿足用戶的預(yù)期。性能測(cè)試是和時(shí)間賽跑，測(cè)試軟件的運(yùn)行速度， 以及資源的使用率。
互操作性測(cè)試 interoperability
很多軟件不是孤立存在的，不能因?yàn)橛脩羰褂昧宋覀兊能浖瑢?dǎo)致用戶所使用的其他軟件不能正常使用，同時(shí)還要保證用戶正在使用的軟件不會(huì)對(duì)我們的軟件產(chǎn)出不良影響。尤其注意的是，軟件間存在相互調(diào)用的情況。
輔助性測(cè)試 Accessibility test
可用性主要針對(duì)不同用戶和不同場(chǎng)景。例如，前些天“餓了么”聽(tīng)障騎手的故事就說(shuō)明了這個(gè)問(wèn)題， 可用性測(cè)試沒(méi)有過(guò)關(guān)，好在后來(lái)雪峰說(shuō)新版本可以讓聽(tīng)障騎手方便使用了。
易用性測(cè)試 usability
方便用戶的使用又是一個(gè)比較泛的領(lǐng)域。用戶的使用習(xí)慣，單雙手操作，按鈕的位置，實(shí)現(xiàn)目標(biāo)功能的路徑深度等等，都是易用性的考量指標(biāo)，有時(shí)也會(huì)把審美考慮進(jìn)去。
安全性測(cè)試 security
和健康一樣，只有失去它的時(shí)候才知道它的可貴。數(shù)據(jù)源的安全，傳輸信道的安全，數(shù)據(jù)存儲(chǔ)的安全等等，盡管安全的重要性眾所周知，但真正為安全投入的公司并不是很多。
恢復(fù)性測(cè)試 recovery
恢復(fù)性測(cè)試一般指系統(tǒng)在正?；虍惓Ｍ顺龊螅欠衲軌蚧謴?fù)到之前的運(yùn)行狀態(tài)。例如，很多手機(jī)都有recovery模式， 拔電源等破壞性測(cè)試有時(shí)也作為測(cè)試手段。
兼容性測(cè)試 compatibility
兼容性涉及的領(lǐng)域也較多。常見(jiàn)的如多瀏覽器測(cè)試，app的多機(jī)型測(cè)試等等，好在現(xiàn)在有一些云測(cè)試平臺(tái)可以幫我們解決環(huán)境的兼容性問(wèn)題。 我們更多的關(guān)注軟件自身的不同版本間的兼容性，包括前向兼容和后向兼容。
發(fā)布測(cè)試 deliverable
發(fā)布測(cè)試更多是在軟件的下載，安裝，卸載等。一般地，把升級(jí)和熱更新等也放到發(fā)布測(cè)試中，包括灰度升級(jí)。
文檔完整性測(cè)試 documentation
文檔是一個(gè)老話題，程序員經(jīng)常抱怨文檔不足，又往往討厭寫(xiě)文檔，陷入自相矛盾中。測(cè)試文檔的完整性會(huì)被認(rèn)為不那么重要，好的方式可能是從產(chǎn)品側(cè)解決，讓產(chǎn)品自身具有自解釋性，代碼也是如此。
測(cè)試的過(guò)程
測(cè)試的領(lǐng)域是從空間的維度對(duì)測(cè)試進(jìn)行的分類，從時(shí)間的維度來(lái)看，又可以大概分為4個(gè)過(guò)程。
單元測(cè)試
單元測(cè)試：是在軟件開(kāi)發(fā)過(guò)程中要進(jìn)行的最低級(jí)別的測(cè)試活動(dòng)，在單元測(cè)試活動(dòng)中，軟件的獨(dú)立單元將在與程序的其他部分相隔離的情況下進(jìn)行測(cè)試。通常情況下，單元測(cè)試（模塊測(cè)試）是RD編寫(xiě)的一小段代碼，用于檢驗(yàn)被測(cè)代碼的一個(gè)很小的、很明確的功能是否正確。通常而言，一個(gè)單元測(cè)試是用于判斷某個(gè)特定條件（或者場(chǎng)景）下某個(gè)特定函數(shù)的行為。
集成測(cè)試
集成測(cè)試也叫組裝測(cè)試或聯(lián)合測(cè)試。在單元測(cè)試的基礎(chǔ)上，將所有函數(shù)或程序模塊按照設(shè)計(jì)要求（如根據(jù)結(jié)構(gòu)圖）組裝成為子系統(tǒng)或系統(tǒng)，進(jìn)行集成測(cè)試。通常情況下，集成測(cè)試是RD進(jìn)行的一種檢驗(yàn)程序內(nèi)部各函數(shù)或各模塊聯(lián)合起來(lái)是否存在問(wèn)題的一種方式。
端到端測(cè)試
端到端測(cè)試（E2E），其實(shí)就是對(duì)多個(gè)系統(tǒng)進(jìn)行系統(tǒng)測(cè)試。在端到端測(cè)試中，業(yè)務(wù)流程是最重要的，端到端測(cè)試是范圍最廣的測(cè)試。集成測(cè)試主要關(guān)注系統(tǒng)之間的接口。系統(tǒng)之間需要交換信息，所以集成測(cè)試是端到端測(cè)試的先決條件。E2E的測(cè)試并不局限于功能性。在端到端的測(cè)試環(huán)境中，需要對(duì)服務(wù)的許多非功能性屬性進(jìn)行評(píng)估，如性能和安全性。
用戶場(chǎng)景測(cè)試
用戶場(chǎng)景測(cè)試是指部分真實(shí)用戶對(duì)產(chǎn)品或服務(wù)的真實(shí)使用測(cè)試，在過(guò)去的電信類產(chǎn)品中是現(xiàn)場(chǎng)測(cè)試（field trial），或者beta測(cè)試。 對(duì)互聯(lián)網(wǎng)產(chǎn)品往往是友好用戶測(cè)試（公測(cè)），或者灰度升級(jí)測(cè)試。
基于階段目標(biāo)的測(cè)試
至于大家常說(shuō)的黑白灰盒測(cè)試，是從產(chǎn)品細(xì)節(jié)的透明度來(lái)看的，程序員可以不必仔細(xì)區(qū)分。但是，對(duì)一些特定階段的測(cè)試還需給予關(guān)注。
冒煙測(cè)試 smoke test
冒煙測(cè)試是在將代碼更改簽入到產(chǎn)品的發(fā)布版之前對(duì)這些更改進(jìn)行驗(yàn)證的過(guò)程。在檢查了代碼后，冒煙測(cè)試是確定和修復(fù)軟件缺陷的最經(jīng)濟(jì)有效的方法。冒煙測(cè)試用于確認(rèn)代碼中的更改會(huì)按預(yù)期運(yùn)行，且不會(huì)破壞整個(gè)版本的穩(wěn)定性。簡(jiǎn)單地說(shuō)，冒煙測(cè)試是對(duì)軟件基本的功能進(jìn)行測(cè)試，以確認(rèn)基本功能正常，保證系統(tǒng)能跑起來(lái),正是進(jìn)入測(cè)試階段的版本必須首先通過(guò)冒煙測(cè)試的考驗(yàn)。
回歸測(cè)試 regression test
回歸測(cè)試是指修改了舊代碼后，重新進(jìn)行測(cè)試以確認(rèn)修改沒(méi)有引入新的錯(cuò)誤或?qū)е缕渌a產(chǎn)生錯(cuò)誤。回歸測(cè)試在整個(gè)軟件測(cè)試過(guò)程中占有很大的工作量比重，開(kāi)發(fā)的各個(gè)階段都會(huì)進(jìn)行多次回歸測(cè)試。在漸進(jìn)和快速迭代開(kāi)發(fā)中，新版本的連續(xù)發(fā)布使回歸測(cè)試進(jìn)行的更加頻繁，而在極限編程等敏捷流程中，更是要求每天都進(jìn)行若干次回歸測(cè)試。因此，選擇正確的回歸測(cè)試策略來(lái)改進(jìn)回歸測(cè)試的效率和有效性是非常有意義的。
壓力測(cè)試 stress test
壓力測(cè)試往往被安排在測(cè)試流程中相對(duì)靠后的階段，是性能測(cè)試和健壯性測(cè)試的一部分。壓測(cè)通過(guò)確定一個(gè)系統(tǒng)的瓶頸或者不能接受的性能點(diǎn)，來(lái)確定產(chǎn)品或服務(wù)可以正常服務(wù)的最高性能。通過(guò)測(cè)試系統(tǒng)在資源超負(fù)荷情況下的表現(xiàn)，或者在系統(tǒng)資源特別低的情況下軟件系統(tǒng)運(yùn)行情況，找到系統(tǒng)在哪里失效以及如何失效的地方。
其他針對(duì)專項(xiàng)的測(cè)試還有很多，例如面向配置的容量測(cè)試，面向安全的滲透性測(cè)試等等。
自動(dòng)化測(cè)試
軟件研發(fā)敏捷性的一個(gè)重要表征就是產(chǎn)品的自動(dòng)化測(cè)試程度。自動(dòng)化測(cè)試一般是使用自動(dòng)化測(cè)試工具來(lái)進(jìn)行的測(cè)試，不需要人為的干預(yù)。然而，自動(dòng)化測(cè)試不是把手工測(cè)試從測(cè)試過(guò)程中拋棄，也不是要用自動(dòng)化測(cè)試替代掉所有的手工測(cè)試。
自動(dòng)化測(cè)試的前提是有充分的測(cè)試設(shè)計(jì)和數(shù)據(jù)準(zhǔn)備，其中測(cè)試覆蓋度完全是由測(cè)試設(shè)計(jì)來(lái)決定的，這就是測(cè)試架構(gòu)師非常難得的原因之一。個(gè)人認(rèn)為，自動(dòng)測(cè)試更適合于相對(duì)穩(wěn)定的功能測(cè)試，壓力測(cè)試，尤其是各種回歸測(cè)試。
客戶端自動(dòng)化測(cè)試工具一瞥
很多客戶端平臺(tái)自帶了一些測(cè)試工具，例如Android 上的Monkey等，可以編寫(xiě)腳步利用這些工具
Web 測(cè)試： Selenium
Selenium 是一組跨平臺(tái)的web應(yīng)用自動(dòng)化測(cè)試工具。通過(guò)使用Selenium，開(kāi)發(fā)人員在不需要學(xué)習(xí)任何測(cè)試腳本語(yǔ)言的情況下，可以很容易地使用記錄/回放測(cè)試工具來(lái)編寫(xiě)測(cè)試，讓我想起了久遠(yuǎn)的MS-Test。
Selenium 提供對(duì)眾多編程語(yǔ)言的支持，包括c#、Java、Groovy、Perl、PHP、Python、Ruby和各種流行的測(cè)試框架。
APP 測(cè)試：Appium
Appium是一個(gè)開(kāi)源、跨平臺(tái)的測(cè)試框架，可以用來(lái)測(cè)試原生及混合的移動(dòng)端應(yīng)用。Appium支持IOS、Android及FirefoxOS平臺(tái)，使用WebDriver的json wire協(xié)議，來(lái)驅(qū)動(dòng)iOS系統(tǒng)的UIAutomation庫(kù)和Android系統(tǒng)的UIAutomator框架。
Appium支持Selenium WebDriver支持的所有語(yǔ)言，如java、Object-C、JavaScript、Php、Python、Ruby、C#、Clojure等，也可以使用Selenium WebDriver的Api。Appium支持任何一種測(cè)試框架，支持真正的跨平臺(tái)自動(dòng)化測(cè)試。
Appium采用C/S架構(gòu)，客戶端對(duì)webdriver做了封裝，讀取各種語(yǔ)言編寫(xiě)的測(cè)試腳本并轉(zhuǎn)換為測(cè)試命令發(fā)送給服務(wù)端。服務(wù)端的兩個(gè)功能，一是接收從Appium Client發(fā)送過(guò)來(lái)的命令（也就是測(cè)試用例），另一個(gè)是作為bootstrap客戶端，接收client的命令后，通過(guò)socket方式，發(fā)給目標(biāo)android機(jī)器的bootstrap，驅(qū)動(dòng)Uiautomator執(zhí)行自動(dòng)化操作。
類似的還有rebotium 等。
服務(wù)端的自動(dòng)化測(cè)試工具一瞥
服務(wù)端測(cè)試包括兩部分：一種是針對(duì)web或app的服務(wù)端進(jìn)行測(cè)試；另一種是針對(duì)后端的數(shù)據(jù)庫(kù)，緩存系統(tǒng)，中間件或文件系統(tǒng)等進(jìn)行的測(cè)試， 自動(dòng)化工具不勝枚舉。
請(qǐng)求模擬：postman
postman是Chrome的一個(gè)插件，從字面意思理解就是能夠發(fā)送POST請(qǐng)求的工具，是一個(gè)非常卓越的WebAPI接口測(cè)試的工具，能夠非常方便的構(gòu)造Web請(qǐng)求并且驗(yàn)證返回的結(jié)果信息。如果用瀏覽器直接請(qǐng)求查看接口返回結(jié)果的話，修改參數(shù)以及發(fā)送post請(qǐng)求時(shí)很不方便，postman就提供了這些便利。
Postman請(qǐng)求支持多種格式解析如JSON/XML/文本，支持管理請(qǐng)求包括分組、重命名等，支持導(dǎo)出數(shù)據(jù)包存為文件或者云存儲(chǔ)，而且是跨平臺(tái)的，通過(guò)api 編程接口可以實(shí)現(xiàn)基于postman 的自動(dòng)化測(cè)試。
抓包分析：charles
Charles 常用的網(wǎng)絡(luò)抓包工具，通過(guò)將自己設(shè)置成系統(tǒng)的網(wǎng)絡(luò)訪問(wèn)代理服務(wù)器，使得所有的網(wǎng)絡(luò)訪問(wèn)請(qǐng)求都通過(guò)它來(lái)完成，從而實(shí)現(xiàn)了網(wǎng)絡(luò)包的截取和分析，配合 SSL 功能，還可以分析Https協(xié)議。Charles 支持重發(fā)網(wǎng)絡(luò)請(qǐng)求，修改網(wǎng)絡(luò)請(qǐng)求參數(shù)，支持網(wǎng)絡(luò)請(qǐng)求的截獲并動(dòng)態(tài)修改，更重要的是支持模擬慢速網(wǎng)絡(luò)。
當(dāng)然，也可以使用其他sniffer 工具配合wireshark 完成傳輸鏈路的自動(dòng)化測(cè)試。
壓力測(cè)試：AB
壓測(cè)的工具很多，ab、http_load、webbench、siege等等。ab是apache自帶的壓力測(cè)試工具，是apachebench命令的簡(jiǎn)稱。它非常實(shí)用，它不僅可對(duì)apache服務(wù)器進(jìn)行訪問(wèn)壓測(cè)，也可以對(duì)其它類型的服務(wù)器進(jìn)行壓測(cè)，比如nginx、tomcat等。
ab命令會(huì)創(chuàng)建多個(gè)并發(fā)訪問(wèn)線程，模擬多個(gè)訪問(wèn)者同時(shí)對(duì)某一URL地址進(jìn)行訪問(wèn)。ab命令對(duì)發(fā)出負(fù)載的計(jì)算機(jī)要求很低，它既不會(huì)占用很高CPU，也不會(huì)占用很多內(nèi)存，卻會(huì)給目標(biāo)服務(wù)器造成巨大的負(fù)載，其原理類似CC攻擊。使用時(shí)需要注意的是，在剛開(kāi)始?jí)簻y(cè)的時(shí)候，負(fù)載不要太大，否則可能造成目標(biāo)服務(wù)器資源耗完，嚴(yán)重時(shí)甚至導(dǎo)致死機(jī)。
對(duì)應(yīng)更加完備的壓測(cè)，可以使用LoadRunner 等其他商業(yè)工具軟件。
面向測(cè)試的開(kāi)發(fā)
對(duì)于程序員來(lái)講，測(cè)試是保證高質(zhì)量軟件的關(guān)鍵手段之一。將質(zhì)量思維融入開(kāi)發(fā)流程，可以采用測(cè)試驅(qū)動(dòng)開(kāi)發(fā)（TDD）的極限編程方法，從業(yè)務(wù)入手，以測(cè)試先行的方法來(lái)反向推動(dòng)代碼的實(shí)現(xiàn)。
簡(jiǎn)單的說(shuō)，就是每當(dāng)需要添加一個(gè)新功能，或修改現(xiàn)有功能時(shí)，首先思考這部分代碼期望達(dá)到的輸入與輸出，先把驗(yàn)證該業(yè)務(wù)的單元測(cè)試用例寫(xiě)出來(lái)，再去寫(xiě)最簡(jiǎn)單的實(shí)現(xiàn)代碼來(lái)通過(guò)該測(cè)試；不斷重復(fù)此過(guò)程直到完成整個(gè)功能。
典型的TDD開(kāi)發(fā)步驟如下：
- 分析并確定一個(gè)目標(biāo)場(chǎng)景
- 用一個(gè)單元測(cè)試來(lái)驗(yàn)證該場(chǎng)景的輸入輸出
- 運(yùn)行該測(cè)試，得到失敗的測(cè)試結(jié)果
- 以最簡(jiǎn)單的功能代碼來(lái)通過(guò)該測(cè)試
- 再次運(yùn)行該測(cè)試，測(cè)試通過(guò)
- 進(jìn)行代碼重構(gòu)，包括功能代碼和單元測(cè)試代碼
- 重復(fù)以上步驟，直至開(kāi)發(fā)完成
在TDD中遵循一切從簡(jiǎn)的原則，以業(yè)務(wù)為導(dǎo)向，隔離目標(biāo)場(chǎng)景，通過(guò)重構(gòu)改進(jìn)代碼的可讀性，可維護(hù)性，減少冗余代碼等。同時(shí)維護(hù)一個(gè)測(cè)試列表 － 在開(kāi)始開(kāi)發(fā)之前，先列出所有需要的測(cè)試，并在開(kāi)發(fā)中不斷維護(hù)該列表，避免遺忘一些必要的測(cè)試。提高效率，不需要另外單獨(dú)的文檔，而是在測(cè)試類中對(duì)每個(gè)測(cè)試方法對(duì)應(yīng)的業(yè)務(wù)場(chǎng)景，輸入和期望的輸出進(jìn)行詳細(xì)的描述。
由于測(cè)試先行，并達(dá)到足夠的覆蓋率，確保代碼都經(jīng)過(guò)了測(cè)試，有利提高代碼質(zhì)量。 TDD產(chǎn)生的測(cè)試就是對(duì)系統(tǒng)的一套完整的說(shuō)明文檔， 還能夠產(chǎn)生一組完備的測(cè)試套件，這讓團(tuán)隊(duì)可以更加自信得去進(jìn)行代碼重構(gòu)。同時(shí)大大提高回歸測(cè)試的頻率，同時(shí)減少所花費(fèi)的時(shí)間，避免產(chǎn)生冗余的，沒(méi)有用的代碼，減少對(duì)代碼 Debugging 的時(shí)間。 將一個(gè)功能分解為一個(gè)個(gè)可以測(cè)試的更小單元，能夠產(chǎn)生更小的，更清晰的，更加責(zé)任明確的類，更加松耦合的組件和清晰的接口。
ATDD是TDD的變種，TDD是基于單元測(cè)試的，而ATDD面向用戶驗(yàn)收測(cè)試的。 在準(zhǔn)備實(shí)施一個(gè)功能前，首先定義出期望的質(zhì)量標(biāo)準(zhǔn)和驗(yàn)收細(xì)則，以及明確且達(dá)成共識(shí)的驗(yàn)收測(cè)試計(jì)劃，以此來(lái)驅(qū)動(dòng)開(kāi)發(fā)人員的TDD實(shí)踐和測(cè)試人員的測(cè)試腳本開(kāi)發(fā)。對(duì)開(kāi)發(fā)團(tuán)隊(duì)來(lái)說(shuō)，ATDD 是由外向內(nèi)，多方介入的，基于拉動(dòng)策略的，并行開(kāi)發(fā)測(cè)試方法；確保所有交付的產(chǎn)品都經(jīng)過(guò)了充分的測(cè)試。
另外，BDD是TDD的補(bǔ)充，更適合高級(jí)別的業(yè)務(wù)需求和驗(yàn)收標(biāo)準(zhǔn)。通過(guò)用戶故事定義需求，BDD定義的用戶故事可以作為開(kāi)發(fā)過(guò)程中的統(tǒng)一標(biāo)準(zhǔn)，促進(jìn)開(kāi)發(fā)人員、測(cè)試人員及用戶共同協(xié)作。Cucumber是一個(gè)BDD自動(dòng)化測(cè)試框架，提供了對(duì)自然語(yǔ)言定義行為及步驟的支持。在執(zhí)行用例時(shí)，會(huì)通過(guò)行為和步驟定義自動(dòng)調(diào)用步驟定義內(nèi)的代碼運(yùn)行。同時(shí)，提供了良好的斷言機(jī)制，當(dāng)執(zhí)行失敗時(shí)，可以清晰的看到測(cè)試用例的執(zhí)行步驟，明確失敗原因。
事情都有兩面性，沒(méi)有銀彈。TDD產(chǎn)生的代碼質(zhì)量取決于測(cè)試的質(zhì)量，不正確的測(cè)試會(huì)產(chǎn)生錯(cuò)誤的代碼，業(yè)務(wù)場(chǎng)景覆蓋不充分的測(cè)試液會(huì)產(chǎn)生功能不完整的代碼。更重要的是，TDD只適用于輸入輸出明確的開(kāi)發(fā)項(xiàng)目，不適用于某些探索性的，輸出不確定的開(kāi)發(fā)，比如人工智能，安全等領(lǐng)域的研發(fā)。 另外在某些環(huán)境，TDD實(shí)施會(huì)有一些困難，例如異步通信等，需要一些額外的輔助工具，增加了復(fù)雜性。
也就是說(shuō)，TDD不是萬(wàn)能的，不可能完全依賴TDD來(lái)提高質(zhì)量。它既無(wú)法替代集成測(cè)試、性能測(cè)試等，也不能讓程序沒(méi)有bug。關(guān)鍵一點(diǎn)，TDD不適合所有項(xiàng)目，要求需求必須足夠清晰，對(duì)模型和依賴特別復(fù)雜的項(xiàng)目也不太行。
小結(jié)
No test， No quality！質(zhì)量很多時(shí)候是產(chǎn)品存亡的關(guān)鍵因素，沒(méi)有質(zhì)量的產(chǎn)品很難說(shuō)什么用戶體驗(yàn)。作為一個(gè)程序員，要把質(zhì)量思維融入到開(kāi)發(fā)過(guò)程中，對(duì)測(cè)試做到胸中有數(shù)。
【本文來(lái)自51CTO專欄作者“老曹”的原創(chuàng)文章，作者微信公眾號(hào)：喔家ArchiSelf,id:wrieless-com】
