文／ThoughtWorks 楊瑞
我嘗試從幾個(gè)角度來分析，在正式分析開始前藐握，我們先把范圍劃定在軟件開發(fā)這個(gè)圈子里頭靴拱，并且對(duì)這些問題進(jìn)行解釋。關(guān)于這方面的討論猾普，一般會(huì)存在以下幾個(gè)誤區(qū)：
- 將開發(fā)階段袜炕、測試階段完全剝離。
- 對(duì)測試的理解有些偏差初家，誤認(rèn)為測試只是在產(chǎn)品做出來之后偎窘，使用它，然后挑毛病笤成，找bug评架。
- 誤認(rèn)為測試只有功能性的校驗(yàn)。
下頭對(duì)這3點(diǎn)逐一解釋：
將開發(fā)階段炕泳、測試階段完全剝離纵诞。
** 經(jīng)常有人會(huì)問，“為什么互聯(lián)網(wǎng)公司不開除測試培遵，轉(zhuǎn)而讓大眾來測浙芙，找到一個(gè)bug給100元？”**
這個(gè)問題有個(gè)假設(shè)籽腕，就是開發(fā)階段嗡呼、測試階段完全剝離開了。開發(fā)階段單純地就是開發(fā)人員敲代碼皇耗，然后出來的東西交給測試人員去做測試南窗。
我不否認(rèn)，現(xiàn)在依然存在這樣的實(shí)踐方式。但是万伤，這不是一個(gè)好的方式窒悔。因?yàn)檫@種流程，把發(fā)現(xiàn)bug的時(shí)間點(diǎn)推遲了敌买。而發(fā)現(xiàn)bug的時(shí)間點(diǎn)越靠后简珠，修復(fù)它所要付出的代價(jià)就越大。
這點(diǎn)應(yīng)該很容易理解虹钮，比如你敲釘子聋庵，如果一口氣敲完了才發(fā)現(xiàn)，敲歪了芙粱，那就得拔出來重新來祭玉，可是東西上已經(jīng)有一個(gè)很深的洞了。所以宅倒，好的方式是敲一敲攘宙，檢查一下，隨時(shí)糾正方向拐迁，確保前進(jìn)的大方向是正確的蹭劈。
軟件更是如此，某個(gè)bug可能是在最底層的地方發(fā)生的线召，如果早期發(fā)現(xiàn)铺韧，定位也容易，修復(fù)起來被牽扯到的地方也少缓淹，付出的代價(jià)可以接受哈打。因?yàn)閎ug的產(chǎn)生可能是多個(gè)原因，有可能是功能性的讯壶，也有可能是對(duì)業(yè)務(wù)理解的偏差導(dǎo)致開始就做錯(cuò)了料仗。
如果在產(chǎn)品做出來，發(fā)布給最終用戶之后才發(fā)現(xiàn)伏蚊。那個(gè)時(shí)候再排查到底哪里出了問題立轧，就不是一時(shí)半會(huì)能做到的了，代價(jià)很大躏吊。
所以比較好的實(shí)踐方式氛改，是由專業(yè)的業(yè)務(wù)人員把要做的東西切割成足夠小的、彼此獨(dú)立的比伏、可單獨(dú)交付的模塊胜卤，開發(fā)、測試以及業(yè)務(wù)人員及時(shí)溝通赁项、及時(shí)反饋葛躏，一個(gè)一個(gè)小模塊完成澈段，隨時(shí)做隨時(shí)測。把發(fā)現(xiàn)bug的時(shí)間點(diǎn)盡量往前推舰攒，這樣就可以把修復(fù)它的代價(jià)降得盡可能小均蜜。
當(dāng)然，小模塊都通過測試芒率，并不意味著所有小模塊拼裝起來組成的系統(tǒng)一定正確，還需要進(jìn)行層次高一點(diǎn)的集成測試篙顺。這就引出了第2點(diǎn)偶芍。
測試就是找bug的？
對(duì)測試的理解有些偏差德玫，誤認(rèn)為測試只是在產(chǎn)品做出來之后匪蟀，使用它，然后挑毛病宰僧，找bug材彪。
有這樣的偏差并不奇怪，因?yàn)閳?zhí)這樣想法的人太多了琴儿，甚至包括一些軟件行業(yè)的從業(yè)人員段化。比如有這樣的說法：
開發(fā)就是敲代碼的，測試就是找bug的
如果是業(yè)外人士造成，我覺得有這樣的誤解沒什么显熏。畢竟，隔行如隔山晒屎，但業(yè)內(nèi)人士這樣理解的話喘蟆，真的不知道該說什么好了。開發(fā)是不是只管敲代碼鼓鲁，這里不談蕴轨。這里我們要談的，是骇吭，測試不是單純的找bug橙弱。
現(xiàn)在我們承接第1點(diǎn)，來說說為什么測試不是在產(chǎn)品做出來之后绵跷，單純的找bug膘螟。
先科普的一個(gè)東西，就是測試金字塔碾局。
這是Martin Fowler的一篇博客中提到的《TestPyramid》荆残。
看不懂這個(gè)圖沒關(guān)系，我來慢慢解釋净当。
測試是分層的内斯，它真的不是只有在產(chǎn)品做出來后才開始的蕴潦，并且也不能那個(gè)時(shí)候才開始。原因在第1點(diǎn)里已經(jīng)解釋過了俘闯。一個(gè)工程級(jí)別的軟件產(chǎn)品潭苞，它的測試大致覆蓋了代碼級(jí)別的單元測試，模塊級(jí)別的API測試真朗，還有端到端的集成測試此疹。這并不全面，還有很多其他類型遮婶，這里我們只是大概分成這3種蝗碎，便于解釋、理解旗扑。
底部那層蹦骑，就是代碼級(jí)別的單元測試。它是發(fā)現(xiàn)bug的最前沿陣地臀防，能在這個(gè)層級(jí)抓住的bug眠菇，修復(fù)起來的代價(jià)，會(huì)小很多袱衷。而且這部分測試數(shù)量很大捎废，驗(yàn)證的東西也不是最終用戶所能理解的，通常都是自動(dòng)化運(yùn)行祟昭，有很多種框架可供選擇缕坎。只有這層的測試全部通過，才會(huì)運(yùn)行后面更上層的測試篡悟。
中間那層谜叹，是service級(jí)別的測試，大概可以理解成模塊間的API測試搬葬。到這一層荷腊，基本每個(gè)模塊的功能都得到了保障，但是他們彼此的協(xié)作不一定正常急凰，所以這層集中要測的就是不同模塊間的協(xié)作女仰、通信了。這部分測試數(shù)量第二多抡锈，也是自動(dòng)化運(yùn)行疾忍。通過之后，就可以開始最上面那層的測試了床三。
頂部那層一罩，這部分測試的數(shù)量最少，是UI級(jí)別的測試撇簿。測試的過程大致可以認(rèn)為是聂渊，模擬使用產(chǎn)品的過程差购，最終用戶也能理解了。比如從注冊(cè)用戶開始汉嗽，到注冊(cè)成功欲逃，登錄成功，頁面正確加載饼暑。這種校驗(yàn)最基本功能的測試稳析，叫冒煙測試，確保產(chǎn)品可以正確運(yùn)行弓叛，沒有無法啟動(dòng)之類的重大缺陷迈着。除此之外，還有部分不便自動(dòng)化的測試邪码，需要手動(dòng)測試，同時(shí)還會(huì)校驗(yàn)一些邊角的情形咬清。
即便上面說的測試全部通過闭专，也不能確保產(chǎn)品萬無一失沒有bug，這是不可能的旧烧。只能說影钉，通過了那么多層的測試，產(chǎn)品處在一個(gè)穩(wěn)定狀態(tài)了掘剪，最終用戶的使用體驗(yàn)良好平委，絕大部分需求都可以滿足。
誤認(rèn)為測試只有功能性的校驗(yàn)夺谁。
之所以有人會(huì)這樣認(rèn)為廉赔，可能是覺得測試只是在使用產(chǎn)品的過程中，發(fā)現(xiàn)了功能上匾鸥、界面上不合理的地方蜡塌，報(bào)告給開發(fā)，他們修復(fù)勿负，就結(jié)束了馏艾。
其實(shí)不然，測試除了功能性的校驗(yàn)奴愉，還有安全方面的測試琅摩、性能方面的測試、兼容性的測試锭硼，等等等等房资。一個(gè)負(fù)責(zé)任的企業(yè)，不可能把包含安全漏洞账忘、性能奇差志膀、對(duì)運(yùn)行系統(tǒng)有各種吹毛求疵嚴(yán)酷要求的產(chǎn)品發(fā)布給普通用戶熙宇，就算他們敢發(fā)布，用戶也會(huì)選擇唾棄他們溉浙。所以在發(fā)布產(chǎn)品之前烫止，肯定有這方面的測試，而這方面的測試戳稽，不是普通用戶所能勝任的馆蠕。
喏，現(xiàn)在看到了吧惊奇。其實(shí)測試也是一個(gè)復(fù)雜的工程互躬，并非單純的使用最終產(chǎn)品，找到其中的缺陷和問題颂郎，再提交這么簡單的事情吼渡。
說到這里，我猜想乓序，所謂的“讓大眾去測試寺酪，去找bug”，很大程度應(yīng)該是指測試金字塔中替劈，位于頂層的那部分寄雀。讓用戶通過自己的使用，遇到bug直接報(bào)陨献。
也有人說盒犹，單元測試那些是開發(fā)做的。對(duì)于那些測試金字塔中層級(jí)較低的測試眨业，可以由開發(fā)人員或者其他相應(yīng)的技術(shù)人員在產(chǎn)品發(fā)布前解決急膀。對(duì)于那些層級(jí)高的，比如UI級(jí)別的測試龄捡，可以分發(fā)出去脖阵，讓最終用戶來測試，并且獎(jiǎng)錢墅茉！
OK命黔，沒問題。那就依照這個(gè)說法就斤，我再來解釋為什么UI級(jí)別的測試也不能不管不顧的直接扔給最終用戶悍募。前面有人也提到了相關(guān)的東西，我在這里依舊分幾點(diǎn)來說洋机，先來個(gè)summary坠宴，主要是這幾個(gè)點(diǎn)：
測試是一項(xiàng)工程，需要計(jì)劃绷旗、策略喜鼓。不能無腦亂來副砍。
對(duì)于bug的描述和修復(fù)，是有相應(yīng)要求的庄岖。普通用戶做不來豁翎。
詳細(xì)解釋如下：
1、測試是一項(xiàng)工程隅忿，需要計(jì)劃心剥、策略。不能無腦亂來
即便對(duì)于大家認(rèn)為沒有技術(shù)含量的手動(dòng)測試背桐，也要制定相應(yīng)的測試策略优烧、測試計(jì)劃。確定使用什么方法去測試產(chǎn)品链峭，如何測試畦娄，開展測試時(shí)如何組織測試用例，人員如何分配弊仪，團(tuán)隊(duì)如何分工合作纷责。如果沒有這些綱領(lǐng)性、指導(dǎo)性的東西撼短，面對(duì)產(chǎn)品那么多的功能，全憑腦子想挺勿，用到哪里測到哪里曲横？這個(gè)真有點(diǎn)天方夜譚了。蘇杰的回答中已經(jīng)提到不少不瓶。
要構(gòu)建這么多測試禾嫉，是需要團(tuán)隊(duì)內(nèi)的人員一起努力、合作的蚊丐。要考慮哪些東西需要提前注意熙参，哪些情況需要單獨(dú)拿出來測試，哪些東西不重要可以不測麦备。在開發(fā)的過程中就盡量避免出現(xiàn)問題孽椰，而不是等它出現(xiàn)再修。
2凛篙、對(duì)于bug的描述和修復(fù)黍匾，是有相應(yīng)要求的
還是那句話，測試是一項(xiàng)工程呛梆。發(fā)現(xiàn)了bug锐涯，需要把它用合理的形式記錄下來，反饋給開發(fā)方填物，再經(jīng)過多方人員的溝通纹腌，修復(fù)霎终，回歸測試，才能確認(rèn)修復(fù)好了升薯，再次發(fā)布產(chǎn)品莱褒。
對(duì)于記錄bug也有一些要求，比如要闡明在運(yùn)行什么系統(tǒng)下覆劈、系統(tǒng)的版本保礼、產(chǎn)品的版本、如果是瀏覽器中打開還要標(biāo)明瀏覽器版本责语、重現(xiàn)步驟炮障、提供截圖、提供測試賬號(hào)坤候。
開發(fā)人員拿到bug后胁赢，可以根據(jù)那些信息嘗試快速地復(fù)現(xiàn)bug，再定位白筹，再修復(fù)智末。如果中間出現(xiàn)問題，需要跟報(bào)bug的人員溝通徒河、確認(rèn)系馆，是產(chǎn)品本身就如此設(shè)計(jì)的？是偶然發(fā)生無法復(fù)現(xiàn)的顽照？是優(yōu)先級(jí)很低暫且不用管的由蘑？
這些事情，如果是在團(tuán)隊(duì)內(nèi)代兵，很好實(shí)施尼酿。如果需要跟用戶做這樣的溝通，那真是……費(fèi)死牛勁了植影。所以裳擎，即便大家都認(rèn)為沒有技術(shù)含量的UI測試，也不能直接扔給用戶去做思币。
最后鹿响，最重要的一點(diǎn)在這里：
- 用戶使用產(chǎn)品，享受的是體驗(yàn)谷饿。
- 目的是高效舒服地解決自己的問題抢野。
如果沒有任何測試，直接把產(chǎn)品扔出去各墨，讓用戶負(fù)責(zé)測試指孤。前面提到的安全、性能、兼容性還有功能上的各種問題恃轩，任何一個(gè)都會(huì)導(dǎo)致用戶崩潰结洼。
所以，無論如何都不能把質(zhì)量沒有保障的產(chǎn)品叉跛，直接扔給最終用戶去做測試松忍。
最后感慨一下，大家普遍對(duì)測試有一定程度的誤解筷厘，覺得測試就是在界面點(diǎn)點(diǎn)點(diǎn)鸣峭，找?guī)讉€(gè)茬，就算完事了酥艳。
其實(shí)摊溶，測試需要專業(yè)的人士，需要對(duì)產(chǎn)品的透徹理解充石，需要對(duì)用戶的同理心莫换，需要對(duì)市場的把握，需要足夠好的大局觀骤铃，需要足夠的耐心拉岁，需要一定的技術(shù)功底，需要寬泛的知識(shí)面惰爬，需要良好的溝通能力喊暖，需要能夠協(xié)調(diào)團(tuán)隊(duì)中不同角色。
說的好像很高級(jí)撕瞧，好多事情是產(chǎn)品經(jīng)理或者項(xiàng)目經(jīng)理干的活陵叽，但是，說實(shí)話风范，想做一個(gè)好的測試人員，這些東西真的都需要沪么。當(dāng)然硼婿，如果愿意踏踏實(shí)實(shí)做一個(gè)點(diǎn)界面的人，那就不需要這些禽车。
再響應(yīng)一下現(xiàn)在很熱的口號(hào)寇漫，“工匠精神”，作為一個(gè)有工匠精神和責(zé)任心的企業(yè)殉摔，怎么能容許自己的產(chǎn)品質(zhì)量沒有保障就直接交付給用戶呢州胳？
Google出過一本書，叫《Google軟件測試之道》逸月，里面提到過一些觀點(diǎn)栓撞，原話記不清了。我說說我的理解：
- 盡量把測試往前推，盡早發(fā)現(xiàn)瓤湘，降低修復(fù)成本瓢颅；
- 測試的目的不是發(fā)現(xiàn)bug，而是預(yù)防bug的發(fā)生弛说；
當(dāng)各種測試做的足夠好的時(shí)候挽懦，即發(fā)布的產(chǎn)品質(zhì)量有足夠保障時(shí)，一些不重要木人、影響小的問題可以不考慮信柿，直接發(fā)布產(chǎn)品，用戶發(fā)現(xiàn)提出反饋后醒第，酌情修復(fù)渔嚷；
通過各種技術(shù)手段和流程改進(jìn)，逐步的解放公司內(nèi)部測試人員淘讥，讓他們把精力放在對(duì)產(chǎn)品的把握上圃伶。
