本來這篇博文我是想這樣開頭的：
也許有人看見這篇文章的標題會覺得 —— 這跟開發(fā)人員無關(guān)。
不脸爱，你錯了窟却，這跟開發(fā)人員有關(guān)昼丑，并且有部分工作是需要開發(fā)人員去做的。
但夸赫，最近遇到了一些事情菩帝，我想換一個開頭方式：
人在工作和生活中，風平浪靜時茬腿，就像在實現(xiàn) stories呼奢。而那些突如其來的、打斷風平浪靜的局面的事情切平，就像一個個 bugs握础。作為一個 Tech，我已經(jīng)習(xí)慣了去解決這些 ”bugs“悴品，但又不免內(nèi)心會吐槽禀综，這些突如其來的問題，作為產(chǎn)品和服務(wù)提供商苔严，就不能重視一下質(zhì)量建設(shè)定枷？
說到質(zhì)量建設(shè)，就不得不來看一下敏捷測試四象限届氢。（這個轉(zhuǎn)接是不是還蠻絲滑順暢的）
四象限左邊部分欠窒，用以”支持團隊“ —— 幫助團隊開發(fā)產(chǎn)品。
與左邊相異的右邊部分退子，用以”評價產(chǎn)品“ —— 對交付的產(chǎn)品增量進行評測岖妄。
四象限下邊部分型将，用以”面向技術(shù)“ —— 面向技術(shù)領(lǐng)域。
與下邊相異的上邊邊部分荐虐，用以”面向業(yè)務(wù)“ —— 面向業(yè)務(wù)領(lǐng)域茶敏。
先聲明，敏捷測試四象限可以認為是一個模型缚俏，或者工具，大家參照它來劃分和搭建項目中的測試“架構(gòu)”贮乳。因此忧换，對于具體的項目而言，并不是每一個部分都必須采用和執(zhí)行向拆，但至少不要漏掉真正需要的維度和實踐亚茬。
第一象限，開發(fā)們最熟悉的部分
四象限中左下方的象限代表了測試驅(qū)動開發(fā)浓恳。
估計有人會說刹缝，明明象限圖上面寫的只是”單元測試“、”組件測試“颈将，怎么扯到測試驅(qū)動開發(fā)上去了梢夯？
測試驅(qū)動開發(fā)，可以分狹義（TDD）和廣義晴圾，狹義是指開發(fā)時小步開發(fā)颂砸、先寫測試、再寫實現(xiàn)的開發(fā)方式死姚；廣義是指人乓，加上業(yè)務(wù)、測試參與都毒，以終為始色罚，團隊明確最終交付驗收測試項，使用測試前置策略账劲，以此出發(fā)進行功能設(shè)計戳护、開發(fā)和構(gòu)建的整個過程。當然瀑焦，如果認可了狹義和廣義兩種方式之后姑尺，會覺得并無區(qū)別，就是”測試驅(qū)動開發(fā)“蝠猬。當然較真一點的切蟋，會覺得廣義中其實還包含了ATDD、BDD等榆芦。
老實說柄粹，早期的時候喘鸟，我也認為先寫測試，還是后寫測試（我不是指開發(fā)完了之后補測試）驻右，沒有明顯的區(qū)別什黑。
但經(jīng)歷了更多項目之后，深刻地感受到 —— 要使一個團隊（對堪夭，我說的并不是特指的某個人愕把，我指的是團隊），能寫出有效森爽、高質(zhì)量的測試恨豁，那還是一起來用TDD吧。
首先爬迟，以測試先行的方式開發(fā)的代碼橘蜜，自然會被要求設(shè)計為可測試的。
并且付呕，伴隨著開發(fā)過程中編寫的測試计福，在幫助設(shè)計開發(fā)、保證質(zhì)量的同時徽职，在開發(fā)完成以后這些測試也承擔著頻繁回歸和重構(gòu)安全網(wǎng)的作用象颖。
最后，當然附加作用就是這些測試是一份產(chǎn)品代碼的使用指南姆钉。
至于開發(fā)完了之后補測試這種 —— 首先它頂多是只能算是一種回歸測試力麸，補上的測試一般會分支覆蓋不全；就算最好的情況育韩，分支都覆蓋全了克蚂，它頂多也只能算另一種白盒測試，對“支持團隊進行產(chǎn)品開發(fā)”中的設(shè)計和開發(fā)并無反饋和指導(dǎo)作用筋讨。更別說埃叭，大部分開發(fā)會”產(chǎn)品代碼都寫完了，趕緊補完測試后悉罕，趕去下一個story”的敷衍感赤屋。或者壁袄，只要沒有強制要求类早，“以后加測試” —— 只是一句自己騙自己的謊言。
因此種種嗜逻，敏捷測試第一象限中涩僻，測試驅(qū)動開發(fā)構(gòu)建出的單元測試、組件測試，用以確保產(chǎn)品代碼的內(nèi)部質(zhì)量逆日。
內(nèi)部質(zhì)量嵌巷，不是通過客戶判斷的，是由開發(fā)們定義的室抽。當內(nèi)部質(zhì)量下降時搪哪，直觀的可見損失比如：開發(fā)速率越來越慢，越來越多的bugs需要修復(fù)坪圾，不斷被推遲的緊急重構(gòu)等等晓折。當然，如果除了第一象限外的其他象限測試也都同時翻車兽泄，這些產(chǎn)品質(zhì)量缺陷將會被用戶感知漓概。
舉個現(xiàn)實生活中有趣的例子：本人最近使用了支某寶辦理ETC，ETC設(shè)備被郵寄過來收到之后已日，需要車主安裝、激活栅屏。
我打開產(chǎn)品說明書飘千，使用支某寶激活引導(dǎo)小程序進行安裝和激活。
當?shù)竭_激活這個步驟的時候栈雳，提示“OBU設(shè)備故障护奈，請聯(lián)系客服處理”。
找到客服哥纫，客服直接告知：寄回更換設(shè)備霉旗。
依樣寄回，過了兩三天后蛀骇，手機突然收到一條提示 —— ETC已成功激活厌秒？這是在做線上debug？
聯(lián)系客服擅憔，客服說是技術(shù)人員在檢修設(shè)備鸵闪。“檢修”設(shè)備暑诸。
過了兩天蚌讼，快遞收到之前那臺設(shè)備，已被激活个榕。
總結(jié)一句：設(shè)備出廠有缺陷篡石，新品寄回僅檢修，線上debug激活西采，用戶收到設(shè)備仍然一臉蒙圈 —— “賬號”不僅被線上debug進行了寫操作凰萨，到底修好沒有還需用戶自己開去一個ETC入口檢驗。
看，作為一個用戶沟蔑，我雖然看不到內(nèi)部質(zhì)量湿诊，但同時我也沒有看到任何質(zhì)量構(gòu)建發(fā)揮作用。
支持團隊開發(fā)過程的面向技術(shù)測試瘦材，是所有將要進行的測試的重要基礎(chǔ)厅须。如果團隊沒有對這個象限中的測試做足夠多的工作，其他類型的測試將會更加困難食棕。因為團隊的代碼缺少內(nèi)部質(zhì)量朗和，每項任務(wù)將需要更長的時間。
ps：第一象限的內(nèi)容并非只有單元測試簿晓、組件測試眶拉，只要是“支持團隊開發(fā)過程的面向技術(shù)測試”都可以放在其內(nèi)，比如：契約測試憔儿。
第一象限的測試是自動化的忆植，支持快速反饋的。
第二象限谒臼，更高層次的支持團隊開發(fā)
第二象限也可以叫面向用戶的測試朝刊，它們確定外部質(zhì)量和用戶需要的功能，包括驗證用戶故事蜈缤、功能拾氓、界面、交互等等底哥。
但既然是敏捷測試咙鞍，這里強調(diào)的就又是 —— 測試驅(qū)動開發(fā)，只不過是從一個更高的層次上趾徽，包含了ATDD续滋、BDD。
第二象限需要測試人員參與孵奶，開發(fā)人員提供技術(shù)支持吃粒，產(chǎn)品人員提供業(yè)務(wù)和用戶故事。
測試人員需要對產(chǎn)品系統(tǒng)有全面的了解拒课、關(guān)注全局徐勃、故事的業(yè)務(wù)和技術(shù)方面，而且始終考慮最終用戶體驗早像，以激發(fā)和揭示需求中的邊界和隱藏假定僻肖，最終同業(yè)務(wù)和開發(fā)們明確驗收測試項，以此來幫助團隊開發(fā)正確的需求卢鹦。
在必要情況下臀脏，測試人員使用業(yè)務(wù)領(lǐng)域語言DSL將驗收測試轉(zhuǎn)化為能夠執(zhí)行的測試代碼劝堪，實現(xiàn)BDD，以驅(qū)動開發(fā)揉稚。一些較常見的工具比如cucumber秒啦。
當然，如果有人說搀玖，團隊測試人員忙的沒時間余境，只能在開發(fā)整體完成了之后才能以“測評”、“查bugs”的形式進行用戶故事測試灌诅、功能測試芳来。
那我只能送兩老話：
“你無法把質(zhì)量測試進產(chǎn)品中”、“一次性把事情做好猜拾，可以杜絕浪費”即舌。
簡單點說，就是測試人員發(fā)現(xiàn)了bugs挎袜，還是需要返工給開發(fā)人員修復(fù)顽聂，開發(fā)修復(fù)后，測試人員再重測盯仪，更何況bugs發(fā)現(xiàn)的越晚紊搪，修復(fù)的成本越高。這些種種磨总，其實造成一些時間和效能的浪費嗦明，無法實現(xiàn)及時的支持團隊開發(fā)笼沥。
再舉一個最近生活中碰到的有趣的例子：本人最近申請了某訊王卡升級5G的業(yè)務(wù)蚪燕。
10月31日出的某訊王卡5G宣傳，本人滿足上面所有前置條件奔浅，看著廣告上11月30日之前辦理可以半年月租享受7折的優(yōu)惠馆纳，同時想支持一把5G事業(yè)，
于是果斷買了5G手機汹桦，接著點擊了王卡助手的申請升級5G鲁驶。
結(jié)果，第一次短信反饋舞骆，申請失敗 —— 因為有一個王卡福利0元1G流量包钥弯。
手動上聯(lián)通app注銷了該業(yè)務(wù)，顯示流量包將在11月30日失效督禽。
再次點擊申請升級脆霎，第二次短信反饋，申請失敗 —— 因為這個流量包失效時間在11月30日狈惫，因此只能在12月才能辦理睛蛛。
一看，哪有這樣的說法，這要是開通不了忆肾，不等于廣告虛假宣傳么荸频，于是馬上聯(lián)系了王卡客服和聯(lián)通客服。
歷經(jīng)3天的溝通和協(xié)作客冈，最后王卡客服 + 我 + 聯(lián)通電話客服旭从，才成功完成這次5G套餐的升級。
主要原因 —— 王卡客服的賬號權(quán)限根本完成不了這些流量包的立即取消失效郊酒，也就無法在廣告優(yōu)惠期內(nèi)完成辦理5G套餐遇绞。
最后是依靠聯(lián)系聯(lián)通電話客服這條workaround才完成辦理5G套餐。
看看燎窘，整個功能測都沒有測試摹闽，就上線了。雖然對于5G剛商用褐健，必然有些手忙腳亂表示理解付鹿，但另一角度也說明“面向業(yè)務(wù)”的測試有多重要。
當然能做到測試驅(qū)動開發(fā)蚜迅，就更敏捷了舵匾。
第二象限的測試一般是自動 + 手動，BDD的測試可以實現(xiàn)自動谁不，另外基于界面的End to End坐梯、或者是只基于API的重復(fù)性回歸測試都盡量自動化，將手動測試放在分析 或者 其他自動測試彌補不了的工作上刹帕。并且手動測試時的前置條件吵血、測試數(shù)據(jù)準備等等，其實也可以借助自動化完成以提高效率偷溺。
最后
這篇文章里面的兩個生活中有趣的例子蹋辅，放在第一象限、第二象限有人也許會覺得有些硬靠的感覺挫掏。
我想說 —— 沒錯??侦另。這兩個例子硬寫進來，就是想吐下槽他們?yōu)樯恫缓煤米鰷y試尉共？
我這還有第三個例子：
在安和某康做體檢預(yù)約褒傅，小程序填入工號后，接收手機驗證碼進行登錄袄友。
第一次登錄成功殿托，完成預(yù)約，之后幾天token失效了杠河。再進行登錄碌尔，手機就再也接收不到驗證碼了浇辜。
反饋給安和某康客服，客服聯(lián)系了技術(shù)部唾戚，最后就扔給我一個系統(tǒng)內(nèi)部日志柳洋，告知我已經(jīng)發(fā)送成功。叹坦。
由于想解決問題熊镣，本人愿意協(xié)助他們線上debug，并聯(lián)系聯(lián)通客服排除了手機和聯(lián)通設(shè)置的一切問題募书，第二次安和某康技術(shù)部還是扔給我一個系統(tǒng)內(nèi)部日志绪囱。。
我是一個用戶莹捡，與其之間隔了電信供應(yīng)商鬼吵、短信渠道商、之后可能才到安和后臺篮赢，給我看后臺內(nèi)部日志齿椅。。
最后還是客服人員上場启泣，詢問我是否完成了預(yù)約涣脚，沒有完成可以人工幫我的喲~ 收不到短信驗證碼，也可以后臺人工查的喲~
基于安和某康貌似只是個體檢資源協(xié)調(diào)服務(wù)公司寥茫，可能科技不是他們的核心領(lǐng)域遣蚀，直到最后我依然無法再登錄，那也只能這樣了纱耻。
