隨著軟件和互聯(lián)網(wǎng)行業(yè)的發(fā)展辜荠，軟件測試正受到方方面面的機遇和挑戰(zhàn)。從技能層面上講：領(lǐng)域知識政冻、測試工具枚抵、測試思維、自動化測試框架明场、編碼技能.....等等方方面面都有待提升汽摹，又都無法一蹴而就；從職業(yè)發(fā)展跑道的角度上來講：管理通道苦锨、技術(shù)通道逼泣、甚至擴崗位轉(zhuǎn)型都是可以考慮的，但也無一坦途舟舒。測試人員大腦被各種的思潮不停拍打著.....測試會不會死掉拉庶？我們到底應(yīng)該怎么走？從當(dāng)前從網(wǎng)上的各種分享渠道來看秃励，理性的觀點應(yīng)該是：測試崗位可能會死掉氏仗，但是測試的職能不會死掉。大牛們建議給測試人員的發(fā)展提升方向主要是：測試工具與技術(shù)夺鲜、測試思維皆尔、測試策略。在我看來這三個都是測試人員的關(guān)鍵提升方向币励，三者并不是誰替代誰的關(guān)系慷蠕，而是應(yīng)該選擇合適的學(xué)習(xí)路徑全面提升。但無論選擇何種學(xué)習(xí)路徑終極的修煉一定是思維榄审。
一.軟件開發(fā)和測試中的一些現(xiàn)象：
我們先來看看測試和開發(fā)工作中的一些現(xiàn)象：
做測試設(shè)計的時候砌们，很多人會沉迷于輸出大量的測試用例杆麸。比如搁进，在測試網(wǎng)絡(luò)設(shè)備端口工作模式的時候浪感，本端端口、對端端口所支持的工作模式饼问、介質(zhì)類型兩兩組合影兽，輸出茫茫多的用例，樂此不疲的Copy莱革、Paste峻堰，測試執(zhí)行和工作匯報的時候似乎也很滿足與自己的工作量。而后呢盅视？當(dāng)新的測試測試任務(wù)增了不同的硬件單板捐名，增加了更多的接口類型和工作模式之后呢.....？類似這樣的例子還很多闹击，我們都很辛苦,加班很多镶蹋，但這樣自己的成長在哪里？那這里究竟缺少一個什么能力呢赏半？
還有些測試人員（包括曾經(jīng)的我）贺归，認(rèn)為測試用例的編寫應(yīng)該事無巨細(xì)，盡可能的詳細(xì)断箫，在用例步驟中應(yīng)該盡可能的清晰的描述清楚每一個細(xì)節(jié)拂酣，讓任何新手一看就能夠明白該怎么測試。在以往非敏捷研發(fā)模型的大背景下仲义，一個版本交付周期20幾天甚至1個月的情況下婶熬，其實時是OK的，即使你拿出3-5天做測試設(shè)計測試時間還是足夠的埃撵。但學(xué)習(xí)了邰曉梅MFQ 的TestCondition后尸诽，我發(fā)現(xiàn)一個用例其實并不需要展現(xiàn)每一個細(xì)節(jié)，只需要將其重要的覆蓋場景盯另、覆蓋數(shù)據(jù)或其他條件參數(shù)清楚就可以了性含。在敏捷大背景下應(yīng)盡可能減少測試設(shè)計過程中文本化編寫的時間，把時間歸還給測試人員鸳惯，讓他們有更充足測試執(zhí)行和思考的時間商蕴，價值更大。那么從事無巨細(xì)的的腳本化用例到TestCondition的轉(zhuǎn)變過程需要的是一種什么能力呢芝发？
在開發(fā)過程中绪商，讓我看到了更多軟件設(shè)計與實現(xiàn)方面現(xiàn)象：大量的配置約束腳本，在增一個單板類型的時候所有腳本都要進(jìn)行維護(hù)辅鲸，缺少的是什么格郁？還是新增單板，只是變更了底層BSP，但依然波及著上層協(xié)議棧例书，這里面缺少的是什么锣尉？一個原本清晰的代碼邏輯，在做了若干年的需求之后决采，代碼架構(gòu)已經(jīng)喪失了層次感自沧、變得理不清脈絡(luò)故障難以定位了，缺少的是什么树瞭？
對拇厢，缺少的是抽象！
測試人員的測試設(shè)計需要抽象出什么是測試邏輯晒喷？什么是測試數(shù)據(jù)孝偎？什么是測試條件？使得測試用例具備可復(fù)用性凉敲。作為軟件開發(fā)人員抽象能力更是必不可少邪媳。"設(shè)計模式"里面就提到了要基于“抽象編程”，這樣才能減少耦合荡陷，使得程序的可維護(hù)性和可擴展性更好雨效。
可見，當(dāng)測試人員還在糾結(jié)自己到底應(yīng)該繼續(xù)走測試的道路還是應(yīng)該轉(zhuǎn)型做開發(fā)是不是更有出路的時候其實你更應(yīng)該修煉的是抽象能力废赞。抽象能力是你在不同行業(yè)和崗位可無縫平移的重要技能之一徽龟。
下面我從：架構(gòu)、設(shè)計和執(zhí)行三個維度來橫向?qū)Ρ纫幌麻_發(fā)人員和測試人員都應(yīng)該具備的抽象能力：
二.架構(gòu)層面的抽象：
無論是軟件開發(fā)活動還是軟件測試活動唉地，在架構(gòu)從層面上都應(yīng)該是有抽象的据悔。我們最常見的一種抽象就是進(jìn)行分層。第一次聽到分層的概念是在學(xué)習(xí)TCP/IP的5層和OSI的7層網(wǎng)絡(luò)模型如下圖所示：
這兩個都是經(jīng)典的網(wǎng)絡(luò)模型耘沼，從提出到現(xiàn)在40年以上了我們依然可以看到當(dāng)前從大到一個復(fù)雜的網(wǎng)絡(luò)极颓，小到一個網(wǎng)絡(luò)設(shè)備的設(shè)計實現(xiàn)，都在從抽象層面上遵循著這樣的分層的規(guī)律群嗤。它的核心思想是：
從下層到上層菠隆，每一層為上層提供提供服務(wù)，上層依賴下層所提供的接口狂秘，各司其職專注其應(yīng)該做的事情骇径。
其實這樣的分層理念在任何行業(yè)都是適用的，具有普適意義：
2.1 軟件開發(fā)領(lǐng)域的分層：
DDD（領(lǐng)域驅(qū)動設(shè)計）是當(dāng)前炙手可熱的的軟件開發(fā)范式者春。在DDD里面就提到了4層分層模型破衔，如下圖所示：
DDD四層模型將整個軟件分為了:用戶界面層(User Interface Layer)、應(yīng)用層(Application)钱烟、領(lǐng)域?qū)樱―omain Layer）晰筛、基礎(chǔ)設(shè)施層(Infrastructure Layer)嫡丙。
其中：基礎(chǔ)設(shè)施層提供通用的技術(shù)能力。如：網(wǎng)絡(luò)通訊接口读第、數(shù)據(jù)庫接口等曙博；領(lǐng)域?qū)邮钦驹谟脩艉蛻?yīng)用的角度抽象出來的軟件的核心概念，它是眾多領(lǐng)域?qū)ο筘苑健⒕酆系募涎虼瘢I(lǐng)域?qū)拥脑O(shè)計力爭做到軟件真實應(yīng)用的領(lǐng)域模型和設(shè)計模型的一致泰佳；應(yīng)用層要定義軟件要完成的事務(wù)盼砍，事務(wù)的實現(xiàn)依賴領(lǐng)域?qū)拥闹С郑挥脩艚涌趯右簿褪翘峁┸浖o用戶的界面呈現(xiàn)逝她。
DDD四層模型的核心是領(lǐng)域?qū)咏阶覀兛吹搅怂蚑CP/IP層次模型同樣理念。DDD對整個軟件每個層次職責(zé)定義和聚焦點是定義十分清晰和明確的黔宛，保證每個層次做好它該做的事情近刘，并為上層提供著支持。
2.2 測試領(lǐng)域的分層和分級：
復(fù)雜的軟件設(shè)計臀晃，會將軟件從函數(shù)/類單元觉渴、模塊、組件徽惋、子系統(tǒng)案淋、系統(tǒng)這樣從微觀的層級進(jìn)行劃分。我們測試隨之也會有單元測試险绘、集成測試踢京、系統(tǒng)測試、甚至是系統(tǒng)集成測試宦棺，這就是我們的測試分層瓣距。而按照邰曉梅的MFQ理論每一個分層我們又可以進(jìn)行分級：單功能（M）、功能交互(F)代咸、整體上的質(zhì)量屬性(Q)蹈丸。單功能驗證更偏向LLT(Low Level Testing),而Q更偏向于HLT(HIGH Level Testing),如下圖所示：
不同測試分層體現(xiàn)的是不同的測試視角的融合；在大公司里不同層次的測試工作可能還是由不同團(tuán)隊來完成呐芥，它體現(xiàn)的是不同團(tuán)隊的協(xié)作白华；分工之后各個團(tuán)隊也可以更聚焦自己做的測試工作。
總結(jié)：
無論測試人員還是開發(fā)人員贩耐，在面對復(fù)雜問題時一定要具備層次化思考的習(xí)慣弧腥，要學(xué)會切蛋糕，并將蛋糕進(jìn)行有效的分配和協(xié)作潮太。
三.設(shè)計層面的抽象：
設(shè)計層面的抽象管搪，我們通常見到的是將自己具體工作對象進(jìn)行模型化的梳理虾攻。模型的使用可以參考，但不存在最佳實踐更鲁。
3.1軟件開發(fā)領(lǐng)域的模型(模式)：
軟件開發(fā)領(lǐng)域中提到模型霎箍，我第一反應(yīng)想到的是“設(shè)計模式”中提到的23種常用設(shè)計模式。它們都是為解決具體設(shè)計問題提供的一種參考澡为，比如：
工廠模式：
給所有"產(chǎn)品"抽象出一個公共的接口漂坏，工廠類根據(jù)需要實例化不同的"產(chǎn)品"。它抽象出產(chǎn)品創(chuàng)建接口媒至。業(yè)務(wù)代碼可以依賴工廠接口進(jìn)行編碼顶别。解決了 當(dāng)“產(chǎn)品”種類擴展時對于其他業(yè)務(wù)代碼的修改和波及問題。
中介者模式（Mediator）：
用一個中介對象來封裝一系列的對象交互拒啰，中介者使得各對象不需要顯示的相互引用驯绎，從而使其松耦合，而且可以獨立地改變他們之間的交互谋旦。它解決的是對象間的復(fù)雜引用和交互問題剩失。
我們可以看到“設(shè)計模式”，它是軟件開發(fā)中對具體事務(wù)進(jìn)行分析后進(jìn)行抽象的一種選擇册着。軟件設(shè)計有了合適的模型可以使軟件更合理的構(gòu)建拴孤，軟件才能做到：可維護(hù)、可復(fù)用甲捏、可擴展演熟。清晰的模型也更加便于不同開發(fā)人員之間的交流。
3.2軟件測試領(lǐng)域的模型：
在MFQ理論中摊鸡，我們有著一套對被測對象的建模的方法：P:Parameter ;P:Proccess? D:Data? C: Combination S:State绽媒。
比如：在通訊協(xié)議行業(yè)的軟件測試中，對于有狀態(tài)的協(xié)議測試采用S:State的模型進(jìn)行建模比較合適免猾。例如下面的 ARP協(xié)議的基于狀態(tài)的建模：
在對被測對象進(jìn)行建模的時候著重分析和考慮它所體現(xiàn)出來的外在特征選取合適的建模方式是辕，這個建模的過程即是對被測對象抽象理解的過程。但并不代碼它只能用一種建模方式猎提，任何一種建模方式也很難涵蓋它的方方面获三。同樣好的測試模型也便于團(tuán)隊內(nèi)部的交流和評估。
總結(jié)：
無論是開發(fā)還是測試锨苏，對被測對象都需要對所工作的對象進(jìn)行分析和學(xué)習(xí)疙教，而分析和學(xué)習(xí)的產(chǎn)物之一就是模型。前人為我們留下了許多經(jīng)典的模型伞租、模式我們可以根據(jù)工作對象的特征進(jìn)行選取贞谓，但并不代表這種選擇是唯一的，只要能更好的解決問題我們也完全可以提出自己的模式或模型葵诈，而真正的高手更是能達(dá)到“無招勝有招”的境界裸弦。
四.執(zhí)行層面的抽象：
執(zhí)行祟同，在漢語詞典中的解釋是：貫徹施行;實際履行。
從字面上就仿佛告訴我們理疙，執(zhí)行工作存在著一張有形或無形的Paper晕城，讓你完全遵從它一步一步去履行，它像由機器去執(zhí)行一段固定的腳本那么的機械窖贤。然而無論是測試還是開發(fā)領(lǐng)域砖顷，目前都有著這么一些實踐不那么遵循Paper卻做的似乎也非常成功。
執(zhí)行層面的抽象赃梧，我想講的是跳出腳本化去追尋事物的本質(zhì)滤蝠。
4.1開發(fā)編碼過程中的抽象：
傳統(tǒng)的研發(fā)流程開發(fā)人員可能習(xí)慣于等待，等待完善的架構(gòu)和方案槽奕，然后再按照Paper進(jìn)行編碼几睛。然而房轿，好的架構(gòu)不是設(shè)計出來的粤攒。需求是不斷變化甚至一開始都是無法明確的，開發(fā)人員又如何能期待拿到一張靠譜的Paper包治百病囱持，永遠(yuǎn)Match住不斷變化的需求呢夯接？
所以最新的研發(fā)思維是TDD，認(rèn)為好的架構(gòu)是“重構(gòu)”出來的纷妆】福基于滿足實例化的需求光督、用戶故事的測試用例永遠(yuǎn)寫出剛剛夠用的代碼进萄。最求完美的架構(gòu)和方案并不是實物的本質(zhì)，快速響應(yīng)變化驰唬，抓住用戶的應(yīng)用場景為用戶提供價值是我們做編碼的本質(zhì)际邻。在重構(gòu)中我們不斷的滿足變化的需求芯丧，也不斷的提煉出我們的架構(gòu)。
當(dāng)然在最求為用戶提供價值的同時世曾，也同樣要考慮團(tuán)隊內(nèi)部的成本和價值缨恒。有的人會說，不是盡快的給用戶提供價值就行了嗎轮听？還要什么重構(gòu)骗露？還要什么抽象？有新需求代碼Copy,Paste一把血巍；加個功能宏塞代碼萧锉；運行狀態(tài)梳理不清楚了加個標(biāo)志位（全局變量）；那么長此以往...........我想說的是那么多程序員加班不是為了理想而只是為填坑述寡。長期處于填坑狀態(tài)的程序員柿隙，必定會處于一種“稀缺”狀態(tài)玫恳，會導(dǎo)致認(rèn)知帶寬急劇下降（稀缺，認(rèn)知帶寬的概念优俘，請參考《稀缺》這本書）京办，埋下更多的坑。這樣填坑式的加班對于客戶和項目都沒有任何的價值帆焕。
4.2測試執(zhí)行過程中的抽象：
從測試的本質(zhì)上來說：測試是為了發(fā)現(xiàn)缺陷而不是為了證明軟件沒有缺陷惭婿。《軟件測試的藝術(shù)》也在測試心理學(xué)的章節(jié)中提到了“測試是為了發(fā)現(xiàn)錯誤而執(zhí)行程序的過程”叶雹。
簡單說就是發(fā)現(xiàn)聚焦風(fēng)險的缺陷才是硬道理财饥。
測試用例精美與否，文檔漂亮與否都不是關(guān)鍵問題折晦。我們說到了需求是變化的用戶場景也是變化的如果能夠要求一份一成不變的Paper就能滿足所有測試的需求钥星？基于上面提到的兩個方面ET探索性測試被越來越多的提起。ET更注重測試人員的測試思路满着；信息的及時反饋谦炒；策略的及時調(diào)整；而不是讓文本化的工作占據(jù)大量的精力风喇，更不是用例機械化的執(zhí)行限制了自己的思路宁改。
當(dāng)測試人員在每個測試周期一遍一遍的重復(fù)執(zhí)行測試用例而逐漸開始發(fā)現(xiàn)沒有任何斬獲的時候，是否還是還應(yīng)該還是為了測試執(zhí)行率魂莫，覆蓋率進(jìn)行機械的執(zhí)行呢还蹲？答案是否定的，執(zhí)行用例并不是測試的本質(zhì)耙考。本質(zhì)是發(fā)現(xiàn)更多的缺陷谜喊。比如，在項目生命周期的中期倦始，按照《軟件測試經(jīng)驗與教訓(xùn)》那本書中提到的缺陷率“倒浴盆曲線”那樣,你應(yīng)該嘗試的是新的測試策略來保持持續(xù)的缺陷發(fā)現(xiàn)率斗遏，采用新的工具、手段楣号，收集新的測試Idea進(jìn)行探索最易。
總結(jié)：
正如《簡單思考》一書中的觀點：“排除表面價值”，實現(xiàn)真正的簡單思考就是要“抓住本質(zhì)炫狱，精簡一切"藻懒。作為開發(fā)人員，本質(zhì)就是持續(xù)交付內(nèi)/外部價值视译，降低成本嬉荆。而測試人員的價值就是盡可能早、多的發(fā)現(xiàn)產(chǎn)品缺陷酷含。這樣你才能從繁雜的事務(wù)中正確的應(yīng)用你有限的精力鄙早。這樣的簡單思考的抽象思維汪茧，無論是測試人員還是開發(fā)人員都是需要的。
最后限番，我想說的是與其焦慮測試人員的未來舱污，不如先力爭從測試技術(shù)、測試策略弥虐、測試思維這三個維度努力讓自己成為業(yè)界的專家再說扩灯，修煉到高階之后重點在思維；任何一個行業(yè)無論處在什么階段霜瘪，你要能站在金字塔的頂尖總不會混得太差珠插。多學(xué)習(xí)一些除了測試之外的“軟技能”。不僅僅是大家熟悉的溝通力颖对、表達(dá)力....捻撑。在互聯(lián)網(wǎng)P to P時代的個人分享能力；個人營銷能力缤底；如何技術(shù)換資源顾患？資源建平臺？....這些都是要成功的重要技能训堆。
