背景

首先自動(dòng)化的引入能夠解決什么問題焰情？只有清晰正確的認(rèn)識(shí)到自動(dòng)化測(cè)試能給我們帶來的預(yù)期收益、目標(biāo)剥懒。再結(jié)合團(tuán)隊(duì)的具體情況内舟，避免對(duì)自動(dòng)化工具產(chǎn)生過高的預(yù)期，避開一些常見的誤區(qū)初橘，有效的持續(xù)構(gòu)建自動(dòng)化測(cè)試验游，才有可能真正體現(xiàn)出自動(dòng)化測(cè)試本身的價(jià)值。這是一個(gè)長(zhǎng)期投入的過程保檐。“其路漫漫遠(yuǎn)兮, 吾將上下而求索”

目標(biāo)是什么耕蝉？

首先自動(dòng)化測(cè)試的意義是能夠幫助節(jié)省人力、時(shí)間或資源夜只，提高測(cè)試效率垒在。那么從個(gè)人和團(tuán)隊(duì)不同的視角去分析自動(dòng)化目標(biāo)：

• 個(gè)人角度：
  • 通過自動(dòng)化測(cè)試工具，節(jié)省時(shí)間扔亥、提升效率场躯、保障質(zhì)量。 // 真的么砸王？
  • 體現(xiàn)代碼能力推盛，提升自己的價(jià)值和議價(jià)能力。 // 目前看來好像是這樣谦铃？
  • 把重復(fù)執(zhí)行工作解放耘成，發(fā)揮主觀能動(dòng)性的其他相關(guān)測(cè)試，發(fā)現(xiàn)更深層的問題。（如：探索性測(cè)試） // 覺得可行嗎瘪菌？
• 團(tuán)隊(duì)視角：

  • 突破現(xiàn)有資源瓶頸撒会，提升測(cè)試效能，降低人力成本师妙。
    // 不能把降低人力成本放在核心位置诵肛，否則容易適得其反。

  • 降低人為錯(cuò)誤率默穴，規(guī)避因?yàn)槿说钠谡荨T性思維偏差、投機(jī)取巧導(dǎo)致的錯(cuò)誤蓄诽。

  • 提升執(zhí)行效率薛训，以及應(yīng)對(duì)高重復(fù)度任務(wù)，比如系統(tǒng)穩(wěn)定性(回歸)測(cè)試和高并發(fā)場(chǎng)景的壓力測(cè)試仑氛。

  • 增加軟件的信任程度乙埃。

    解釋下這點(diǎn): 通常當(dāng)執(zhí)行有效的自動(dòng)化腳本并成功后，那么就可以說當(dāng)前的交付物是基本可靠的锯岖，通常測(cè)試很難去決定或左右質(zhì)量的上限介袜，但是可以保障質(zhì)量的下限。換個(gè)角度來講出吹，回歸測(cè)試自動(dòng)化的穩(wěn)定執(zhí)行遇伞，可以讓團(tuán)隊(duì)有信心相信當(dāng)前的交付物是可靠的。畢竟測(cè)試本身就是一種提升信心的活動(dòng)趋箩。

指標(biāo)如何度量赃额？

自動(dòng)化測(cè)試常見度量指標(biāo)：用例數(shù)（新增及維護(hù)）加派、覆蓋率(代碼行叫确、接口、功能)芍锦、ROI竹勉、通過率、執(zhí)行率等等娄琉。不同的團(tuán)隊(duì)面臨的問題不同次乓，所采用的指標(biāo)也不相同。即使是是這樣孽水，但是大致遇到的問題卻是相識(shí)的票腰。// 具體指標(biāo)也可以通過團(tuán)隊(duì)實(shí)際的痛點(diǎn)或面臨的現(xiàn)狀，用結(jié)果來倒逼反推指標(biāo)女气。
比如：

往往結(jié)果數(shù)據(jù)統(tǒng)計(jì)并不難杏慰。但是到最后會(huì)發(fā)現(xiàn)一個(gè)問題，就是實(shí)際度量數(shù)據(jù)反映的情況和預(yù)期存在很大的差異性，無論是從質(zhì)量或效率來看缘滥。在特定的時(shí)間內(nèi)很難達(dá)到預(yù)期的目標(biāo)轰胁。

就比如發(fā)現(xiàn)度量數(shù)據(jù)呈現(xiàn)出的效率好像提升了，用例數(shù)大幅度增長(zhǎng)朝扼，但實(shí)際業(yè)務(wù)測(cè)試的周期好像似乎沒有變化赃阀？又或者下個(gè)月的度量指標(biāo)數(shù)據(jù)下降了。但是測(cè)試周期反而又大幅度減少了擎颖？這樣一來榛斯，測(cè)試效能度量、質(zhì)量保障似乎是靠天吃飯的搂捧，咋一聽起來有點(diǎn)搞笑或者不可思議肖抱。但是現(xiàn)實(shí)情況就是這樣的0.0，那么問題到底在哪里异旧？
?：這里可能或許存在人員在執(zhí)行力方面的一些問題? 還是其他因素意述？思考一下？

問題會(huì)在哪里吮蛹？

也許出在 "目標(biāo)" 本身荤崇，目標(biāo)即導(dǎo)向。那么效率提升的本質(zhì)是不是就一定是 "用例數(shù)量多"潮针、"覆蓋率多"术荤、"ROI就高" ？

好像也不全是每篷，其實(shí)目標(biāo)本質(zhì)是簡(jiǎn)單直接: 在定時(shí)任務(wù)的背景下【快-> 時(shí)間縮短】瓣戚，在定量任務(wù)的背景下【快-> 人力減少】

在具體指標(biāo)設(shè)定時(shí)，除了"定性"焦读、不可避免的還要"定量"子库，一方面視為了度量其絕對(duì)值，另一方面是與其"定性"相互佐證矗晃。

【定性】：時(shí)間縮短-> 例如: 項(xiàng)目平均測(cè)試交付周期縮短 X%

【定量】：累計(jì)節(jié)省人力投入（或累計(jì)節(jié)省額外人力投入）-> 例如: 累計(jì)節(jié)省回歸測(cè)試 X 小時(shí)

近期有看到一個(gè)有意思的話題討論：" 關(guān)于敏捷測(cè)試底能不能度量或者需不需要度量的思考?"

因?yàn)閺拿艚轀y(cè)試宣言來看仑嗅，度量本身就是不敏捷的。但不可否認(rèn)度量指標(biāo)可能是一個(gè)好的測(cè)試實(shí)踐张症。但是仓技，如果過度關(guān)注度量的指標(biāo)數(shù)據(jù)，甚至用來考核指標(biāo)俗他，那么可能就會(huì)流于形式化脖捻，導(dǎo)致就會(huì)為了數(shù)據(jù)而數(shù)據(jù)。偏離了度量本身的初衷兆衅。

自動(dòng)化測(cè)試存在的誤區(qū)地沮？

在最開始的時(shí)候颜价，聊了引入自動(dòng)化測(cè)試的目標(biāo)和期待。在引入自動(dòng)化工具之前如果未考慮引入的目的及具體能夠解決什么問題及帶來的價(jià)值诉濒。但如果團(tuán)隊(duì)對(duì)于自動(dòng)化測(cè)試有過高的期待周伦，覺得引入自動(dòng)化測(cè)試就可以解決所有問題。

• 關(guān)于這些誤區(qū)可以從以下幾點(diǎn)來討論：

  • 為了做自動(dòng)化而自動(dòng)化未荒？
    事先沒有做好規(guī)劃专挪，管理好引入自動(dòng)化測(cè)試的目標(biāo)和合理的預(yù)期，只是盲目的引入片排，認(rèn)為自動(dòng)化測(cè)試能夠提效寨腔、降低成本、保障質(zhì)量率寡。

    關(guān)于自動(dòng)化是否能夠提效和保障質(zhì)量有待商榷迫卢，尤其是質(zhì)量一直是爭(zhēng)議的點(diǎn)。其次是降低人力成本冶共，這里也是有誤區(qū)的乾蛤，首先引入自動(dòng)化的目的應(yīng)該是替換重復(fù)的工作，解放測(cè)試人員的時(shí)間和精力捅僵，發(fā)揮人的主觀能動(dòng)性家卖，間接地發(fā)現(xiàn)更多、更深層次的問題庙楚。這里應(yīng)該要清晰的認(rèn)識(shí)到自動(dòng)化測(cè)試存在的局限性上荡。

  • 為什么發(fā)現(xiàn)不了更多的缺陷？

    發(fā)現(xiàn)更多的缺陷應(yīng)該是手工測(cè)試的主要目的馒闷，不能奢望自動(dòng)化發(fā)現(xiàn)更多新的問題酪捡。事實(shí)上，自動(dòng)化測(cè)試主要驗(yàn)證原有的功能（回歸測(cè)試）

    如果沒有建立一個(gè)正確的軟件測(cè)試自動(dòng)化的觀念認(rèn)知纳账，認(rèn)為測(cè)試自動(dòng)化可以完全代替手工測(cè)試逛薇，或者認(rèn)為測(cè)試自動(dòng)化可以發(fā)現(xiàn)大量缺陷，或者不愿在初期進(jìn)行比較大投入的話塞祈，很容易導(dǎo)致半途而廢金刁。那么失敗也將是必然的帅涂。

  • 一定能提升效率和質(zhì)量议薪？

  這里的也是最常見的誤區(qū)，大部分人都以為只要在項(xiàng)目流程中引入自動(dòng)化工具媳友，那么就一定能提升效率并且線上的缺陷會(huì)大幅度下降斯议，很顯然這么想的大部分人都失望了，甚至?xí)l(fā)出一些疑問醇锚？"為什么我們自動(dòng)化都做了這么久哼御，投入這么多人力坯临、時(shí)間、成本恋昼，但是沒能得到預(yù)期的結(jié)果呢看靠？"

  其實(shí)能合理的有效的持續(xù)構(gòu)建自動(dòng)化測(cè)試，是有可能提升效率并且保障回歸階段特定功能的可靠產(chǎn)品交付液肌。但是由于引入的前期沒有做技術(shù)選型挟炬、框架調(diào)研、以及項(xiàng)目成熟度等諸多因素的考慮嗦哆，都會(huì)導(dǎo)致自動(dòng)化測(cè)試落地的失敗谤祖。

  • 錄制回放的自動(dòng)化工具“真的好”？

    在早期的自動(dòng)化測(cè)試工具(Selenium老速、LoadRunner)中粥喜，都會(huì)有錄制回放的功能。這個(gè)功能有多雞肋橘券，只要用過的都應(yīng)該清楚额湘，說多了都是淚。

    現(xiàn)在又火起來了旁舰，為什么呢缩挑？因?yàn)楝F(xiàn)在的錄制回放和以前的已經(jīng)不是一回事了。早期的錄制回放指提是錄制某個(gè)用戶的行為動(dòng)作鬓梅，然后通過協(xié)議回放出來供置。而現(xiàn)在的錄制回放，更多的是基于流量的錄制回放绽快，錄制的是大量用戶在現(xiàn)網(wǎng)的實(shí)際請(qǐng)求芥丧，然后在測(cè)試環(huán)境中回放。

  注意哈：這兩個(gè)完全不是一個(gè)級(jí)別的事坊罢。后者需要依賴大量的基礎(chǔ)能力续担，諸如基于中間件的流量錄制、數(shù)據(jù)清洗改造等大量工作活孩，一般公司不具備這種能力物遇。即使具備這種能力，在投入較大的成本之后憾儒，會(huì)發(fā)現(xiàn)并沒有多大實(shí)際的效果询兴。ROI 較低，典型的吃力不討好起趾。

  • 自動(dòng)化測(cè)試平臺(tái)是"高大上"诗舰？

    從自動(dòng)化工具→框架→自動(dòng)化平臺(tái)是逐漸過度的過程，也是必然的趨勢(shì)训裆，但是不包括所有的團(tuán)隊(duì)都適合這種情況眶根。因?yàn)槠脚_(tái)就意味著局限性蜀铲，規(guī)范性。而大多數(shù)團(tuán)隊(duì)往往就做不到規(guī)范化属百。盲目的平臺(tái)化只能引起水土不服记劝。尤其是敏捷測(cè)試多變的模式下，大部分平臺(tái)功能支撐會(huì)很難適應(yīng)族扰。

    當(dāng)然并不是說平臺(tái)化一無是處隆夯。恰恰相反，如果平臺(tái)足夠規(guī)范化别伏、貼合實(shí)際業(yè)務(wù)蹄衷、優(yōu)先考慮使用者感受等多個(gè)方面的來持續(xù)建設(shè)自動(dòng)化測(cè)試平臺(tái)，“高大上”指日可待厘肮。

引入自動(dòng)化需要考慮那些方面的問題愧口？

開展自動(dòng)化測(cè)試，投入的基本上就是時(shí)間成本类茂。當(dāng)然還需要綜合考量一些其他影響因數(shù)耍属。主要有以下三個(gè)方面：

• 項(xiàng)目周期

  • 項(xiàng)目的持續(xù)時(shí)間短

    當(dāng)有一些傳統(tǒng)公司項(xiàng)目緊急程度非常高，從立項(xiàng)到結(jié)束只有一個(gè)月的時(shí)間巩检，而這一個(gè)月的時(shí)間可能大部分時(shí)間都是在做前期需求溝通厚骗，產(chǎn)品需求頻繁變更、開發(fā)實(shí)現(xiàn)變更兢哭、測(cè)試用例設(shè)計(jì)等领舰，而測(cè)試又未能提前介入，導(dǎo)致提測(cè)之后迟螺，留給測(cè)試的時(shí)間是不多的冲秽。所以這個(gè)時(shí)候如果強(qiáng)行要做自動(dòng)化測(cè)試，時(shí)間成本將會(huì)明顯提升矩父，ROI也低锉桑。甚至基本質(zhì)量都無法得到保障。

  • 項(xiàng)目的持續(xù)時(shí)間短

    在單周窍株、雙周民轴、甚至去迭代的團(tuán)隊(duì)，本身交付壓力已經(jīng)足夠大的情況下球订，需要考慮自動(dòng)化編寫和維護(hù)的成本后裸，不可能去犧牲和壓榨原本手動(dòng)測(cè)試的時(shí)間，這里質(zhì)量的風(fēng)險(xiǎn)會(huì)大大提高辙售。當(dāng)然更不可能奢望成員利用業(yè)余或者周末在家的時(shí)間去實(shí)現(xiàn)自動(dòng)化轻抱。這。旦部。祈搜。很難有什么成效吧。 // 這里可以考慮從工具下手士八，降低編寫和維護(hù)成本容燕。

• 成本問題

  • 人員能力

  引入自動(dòng)化測(cè)試，首先測(cè)試人員的能力要求也會(huì)相對(duì)高一些婚度，例如要懂協(xié)議相關(guān)蘸秘，編程語言、業(yè)務(wù)程度等蝗茁，這類人員本身成本也會(huì)相對(duì)較高人的問題是最核心也是最重要的醋虏，因?yàn)閳F(tuán)隊(duì)成員的能力都是不同的，比如測(cè)試技能哮翘、興趣颈嚼、責(zé)任、執(zhí)行力等饭寺。都是決定最終自動(dòng)化能否成功的關(guān)鍵阻课。

  • 協(xié)作規(guī)范

  想要自動(dòng)化能夠順利高效的落地，前提得是有標(biāo)準(zhǔn)化的流程艰匙。比如接口自動(dòng)化測(cè)試限煞，
  需要有規(guī)范的接口文檔。目前大部分團(tuán)隊(duì)的文檔管理方式不一员凝，其維護(hù)程度較差署驻。或者文檔萬年都沒有維護(hù)健霹。如果是僅僅依賴測(cè)試人員通過抓包來分析接口再進(jìn)行代碼編寫測(cè)試腳本硕舆，浪費(fèi)時(shí)間，效率低骤公，后期維護(hù)成本極高抚官。

  • 時(shí)間成本

  不管是開發(fā)腳本還是維護(hù)腳本，都是需要時(shí)間投入阶捆。雖然從長(zhǎng)遠(yuǎn)上來看凌节，自動(dòng)化的效率是能夠體現(xiàn)出來的。但是針對(duì)某個(gè)迭代來說洒试，是需要從原來的功能測(cè)試時(shí)間中抽出一部分時(shí)間來編寫腳本和維護(hù)腳本的倍奢。那如何保證有限的時(shí)間既保證了功能測(cè)試的覆蓋，又能實(shí)現(xiàn)自動(dòng)化測(cè)試的覆蓋垒棋？

  顯然這里是矛盾的卒煞，可能有些團(tuán)隊(duì)成員會(huì)說利用加班或者業(yè)余時(shí)間來投入的。 ~有了解過這種類似的情況純粹是靠愛發(fā)電叼架，這種情況很難維持畔裕，并且用例的有效性有待考量衣撬。~

• 效率問題

  在引入自動(dòng)化測(cè)試之前有沒有考慮過，工具本身是否解決效率的問題扮饶。那些地方做可以提升效率具练，那些反而會(huì)拖后腿。而且同時(shí)如果還盲目的追求自動(dòng)化覆蓋率的話甜无，也將走向誤區(qū)扛点。那么基于效率來分析，可以從以下兩個(gè)方面來做嘗試：

  • 基于風(fēng)險(xiǎn)

    應(yīng)該優(yōu)先考慮測(cè)試核心岂丘、業(yè)務(wù)高頻場(chǎng)景或者功能模塊陵究。例如：會(huì)影響核心流程的、在測(cè)試環(huán)節(jié)中BUG相對(duì)集中的功能點(diǎn)奥帘、影響服務(wù)級(jí)別協(xié)議 SLA铜邮、資損、用戶高頻使用的功能等翩概。

  • 基于ROI

    基于BUG的修復(fù)成本牲距，越早發(fā)現(xiàn)成本也就也低。越底層的自動(dòng)化測(cè)試越能產(chǎn)生更高的價(jià)值钥庇。所以分層自動(dòng)化測(cè)試的必要性不言而喻牍鞠。 // 分層自動(dòng)化測(cè)試內(nèi)部有做分享

    從測(cè)試金字塔模型來分析，以及團(tuán)隊(duì)實(shí)際情況來考量评姨，一般采用會(huì)建議優(yōu)先引入接口/集成自動(dòng)化測(cè)試(依賴后端接口規(guī)范)难述。當(dāng)然核心流程的 UI 自動(dòng)化也很有必要(依賴前端的代碼規(guī)范)。如果開發(fā)的單元測(cè)試能夠引入效果會(huì)更佳吐句。 // 目前來看完全取決于開發(fā)的自覺性

當(dāng)能夠很好地平衡這些成本關(guān)系后胁后，引入自動(dòng)化測(cè)試才有可能產(chǎn)生真正的價(jià)值，并且需要長(zhǎng)期持續(xù)構(gòu)建有效的構(gòu)建自動(dòng)化嗦枢。否則很容易變成面子工程攀芯，半路夭折，淪為測(cè)試人員的負(fù)擔(dān)文虏。

落地失敗導(dǎo)致的原因有哪些侣诺？

在上述的問題⊙趺兀可以說在一定程度上問題基本都解決掉了年鸳。但是自動(dòng)化測(cè)試仍然沒能達(dá)到預(yù)期的效果。隨之丸相，新的問題又來了搔确？你可能會(huì)開始吐槽：“自動(dòng)化這么難搞,為什么我們還要趨之若鶩?”

雖然目前大多現(xiàn)狀即便如此，還是得分析可能導(dǎo)致的原因在哪里：

• 人員問題

  • 缺乏編程技術(shù)能力

    國(guó)內(nèi)軟件測(cè)試起步比較晚，早期的測(cè)試工程師清一色地做著功能（手工）測(cè)試膳算，不需要有編碼能力座硕，甚至覺得不用會(huì)編碼是理所應(yīng)當(dāng)?shù)摹＝┠觊_始隨著敏捷測(cè)試的盛行畦幢，自動(dòng)化測(cè)試逐漸成為行業(yè)趨勢(shì)坎吻，才驅(qū)使一些測(cè)試人員去學(xué)習(xí)編程語言缆蝉，但都僅僅局限于自動(dòng)化工具層面宇葱，很少有能夠深入學(xué)習(xí)的。

    大部分可能接觸的一些框架工具比如：RF刊头、LR黍瞧、selenium、appium原杂、requests印颤、unittest 等等。掌握這些常見的技能穿肄，這里會(huì)有一種情況就是你可能上手寫一些自動(dòng)化腳本年局，但是至于寫的是否有效、合理咸产、不得而知矢否。// 這里腳本的合理有效性起到?jīng)Q定性因素

  • 測(cè)試用例設(shè)計(jì)覆蓋目的性弱

    隨機(jī)性、低覆蓋脑溢、無法真正的縮短執(zhí)行效率僵朗。沒有合理的規(guī)劃用例的設(shè)計(jì)。比如：在手動(dòng)執(zhí)行測(cè)試用例時(shí)屑彻，為了縮短執(zhí)行時(shí)間验庙，避免某些操作的重復(fù)執(zhí)行，通常會(huì)先設(shè)計(jì)執(zhí)行場(chǎng)景社牲，一個(gè)場(chǎng)景下粪薛，盡可能根據(jù)執(zhí)行順序，覆蓋更多的測(cè)試用例搏恤。 // 而在編寫自動(dòng)化腳本的時(shí)候常常會(huì)忽略這一點(diǎn)

  • 缺乏用例的有效驗(yàn)證

    通過平時(shí)發(fā)現(xiàn)大部分的自動(dòng)化測(cè)試用例驗(yàn)證只是斷言狀態(tài)或者簡(jiǎn)單響應(yīng)的內(nèi)容违寿。然而一條嚴(yán)謹(jǐn)有效的測(cè)試用例。通常要對(duì)響應(yīng)的結(jié)果做全面覆蓋挑社≡山纾考慮響應(yīng)內(nèi)容可能存在一些非冪等性的屬性。

    比如當(dāng)前時(shí)間痛阻，目前提供的關(guān)鍵字中菌瘪，靈活的支持過濾掉那些屬性不校驗(yàn)的功能。需要避免在提升效率、穩(wěn)定性的過程中俏扩，忽略質(zhì)量的基本要求糜工，如果是這樣的話，那么就會(huì)顯的有些本末倒置了录淡。// 有效驗(yàn)證是關(guān)鍵

  • 用例穩(wěn)定性

    這又是一個(gè)讓測(cè)試工程師很尷尬的事情捌木，因?yàn)榇a基礎(chǔ)功底問題，在編寫過程中自身的問題存在比較多嫉戚，debug調(diào)試成本高刨裆，運(yùn)行不穩(wěn)定、斷言不合理等問題導(dǎo)致測(cè)試結(jié)果可信度不高彬檀。 // 用例設(shè)計(jì)很重要

    對(duì)于這種情況帆啃，只能不斷去強(qiáng)化你的代碼能力，而且心態(tài)上有改變：不要覺得寫代碼的測(cè)試太難窍帝。自動(dòng)化測(cè)試的本質(zhì)其實(shí)還是在做功能測(cè)試努潘。 // 僅僅是通過代碼代替你的手動(dòng)操作而已，很多人往往忽略了這一點(diǎn)坤学。

    還有另外一點(diǎn)疯坤，就是當(dāng)你在寫代碼的時(shí)候，應(yīng)該像 RD 一樣要求自己寫的代碼是易讀深浮、可維護(hù)的压怠。在學(xué)習(xí)測(cè)試框架（多閱讀源碼去理解作者設(shè)計(jì)的意圖）的同時(shí)，還要關(guān)注數(shù)據(jù)結(jié)構(gòu)略号、設(shè)計(jì)模式刑峡、數(shù)據(jù)庫、中間件等玄柠。

    • 另外突梦，在編寫測(cè)試用例時(shí)，盡可能遵循FIRST原則：
      • F——Fast：快速
      • I——Isolated：隔離
      • R——Repeatable：可重復(fù)
      • S——Self-verifying：自我驗(yàn)證
      • T——Timely：及時(shí)

  • 用例的維護(hù)性

    在以上的問題都不太需要考慮的時(shí)候羽利，并且大量的測(cè)試用例集成到CI/CD流程宫患，不要以為這個(gè)時(shí)候就成功了，就能輕松的享受自動(dòng)化來的收益了这弧。

    往往這才是第一步娃闲。因?yàn)殡S著產(chǎn)品模塊、功能隨著快速迭代的過程也隨之發(fā)生頻繁的變更匾浪，及時(shí)皇帮、有效的維護(hù)這些用例將會(huì)成為你的首要事項(xiàng)。

    如果你最初的用例不規(guī)范蛋辈、設(shè)計(jì)不合理属拾、按照個(gè)人習(xí)慣編寫将谊，那么無效用例就會(huì)發(fā)生雪球效應(yīng)，最后讓你負(fù)擔(dān)不起渐白，大部分自動(dòng)化測(cè)試無疾而終就是因?yàn)檫@個(gè)原因尊浓。所以有效及時(shí)的維護(hù)是首要任務(wù)。 // 用例設(shè)計(jì)是基礎(chǔ)再次強(qiáng)調(diào)

• 工具問題

  • 工具的使用體驗(yàn)

    在多人協(xié)作的自動(dòng)化項(xiàng)目過程中纯衍，因每個(gè)人的能力栋齿、習(xí)慣、經(jīng)驗(yàn)或標(biāo)準(zhǔn)不規(guī)范襟诸，就可也可以引入能導(dǎo)致前期編寫成本高瓦堵、可讀性差、后期維護(hù)成本高励堡。針對(duì)這類似問題可以對(duì)自動(dòng)化規(guī)范作出標(biāo)準(zhǔn)輸出谷丸，定期分享和培訓(xùn)組員的基礎(chǔ)能力堡掏。

    也可以在技術(shù)引進(jìn)的時(shí)候考慮是否有替代人工編寫腳本的方案应结，節(jié)省人力的同時(shí)需要考慮維護(hù)成本。

  • 自動(dòng)化孤島泉唁，缺乏持續(xù)性

    初期引入到CI/CD持續(xù)集成中鹅龄，出發(fā)點(diǎn)是好的，但是會(huì)發(fā)現(xiàn)過程中存在一些問題亭畜。比如流程節(jié)點(diǎn)或卡點(diǎn)增多扮休，導(dǎo)致流程繁瑣，又或者自動(dòng)化測(cè)試用例執(zhí)行失敗率高拴鸵、有效性差玷坠、環(huán)境因素等其他干擾因素。人員的工作量增加劲藐“吮ぃ可能引起排斥效果。

  • 技術(shù)選型局限性

    假設(shè)團(tuán)隊(duì)成員都已經(jīng)具備初步的編碼能力后聘芜，會(huì)面臨下一個(gè)問題：怎么做自動(dòng)化兄渺？或者說用那種自動(dòng)化工具？

    困惑于不知道選什么樣的測(cè)試框架汰现、工具挂谍，困惑于不知道從接口、Web瞎饲、移動(dòng)端哪一層入手口叙。切入點(diǎn)無從下手。

    • 框架選型

      由于大部分測(cè)試人員學(xué)習(xí)編碼是以自動(dòng)化為出發(fā)點(diǎn)嗅战，比如selenium妄田、appium等等。他們所具備的編碼能力只局限于這些框架API。而編程的基本往往被忽視形庭，基礎(chǔ)不行铅辞。所以這樣一來，可能就只有從熟悉的框架著手萨醒，而不能全盤考慮各類框架優(yōu)劣勢(shì)斟珊。

      這樣的話，就會(huì)存在很難根據(jù)自身實(shí)際業(yè)務(wù)來考量選擇合適的工具框架富纸，因?yàn)闆]得選囤踩。更別說根據(jù)開源工具來進(jìn)行二次開發(fā)了。

    • 分層策略

      然后是測(cè)試分層晓褪，其實(shí)測(cè)試分層是個(gè)比較大的話題堵漱，單元、集成涣仿、接口勤庐、UI都可以介入入。至于測(cè)試分層自動(dòng)化好港，上次分享專門分享過有興趣的去翻下 PPT愉镰。大家可能都知道，問題越早發(fā)現(xiàn)钧汹，解決的成本也就越低丈探。自動(dòng)化能夠下沉到越底層，那么ROI的收益會(huì)更高拔莱。

// 這里也存在可能技術(shù)選型的負(fù)責(zé)人沒從團(tuán)隊(duì)整體情況去考慮也會(huì)導(dǎo)致工具選型的失敗

• 過于"工具平臺(tái)化”

  這里在說一個(gè)常見的現(xiàn)象：平時(shí)可以發(fā)現(xiàn)大多測(cè)試社區(qū)碗降、博客、群聊等等塘秦，討論的測(cè)試框架稿饰、平臺(tái)的功能實(shí)現(xiàn)被啼。某某工具有支持某些強(qiáng)大的功能等等。

  但是很少有人會(huì)聊自動(dòng)化測(cè)試用例如何設(shè)計(jì)這才是最核心的東西。工具平臺(tái)的功能支持再多烂叔，再強(qiáng)大毛雇。沒有測(cè)試用例支撐至扰，那都是工具開發(fā)人員的自嗨而已桦他。

  目前大部分測(cè)試開發(fā)的心態(tài)可能就是：他開發(fā)的工具框架厲害。功能多霹期，代碼能力強(qiáng)叶组。測(cè)試框架、平臺(tái)信手拈來历造，至于用例怎么寫跟我沒關(guān)系甩十。殊不知船庇，不管是手工測(cè)試還是自動(dòng)化測(cè)試，其核心資產(chǎn)絕對(duì)是測(cè)試用例侣监，而不是那些爛代碼堆砌出來的框架平臺(tái)鸭轮。
  // 工具平臺(tái)建設(shè)最重要還是要考慮結(jié)合實(shí)際業(yè)務(wù)、團(tuán)隊(duì)成員的能力出發(fā)橄霉，不能為了工具而工具窃爷。為了追求平臺(tái)而平臺(tái)。

• 團(tuán)隊(duì)問題

  • 過于關(guān)注覆蓋率

    一味追求需求覆蓋率姓蜂、接口覆蓋率按厘、代碼行覆蓋率，而實(shí)際問題是覆蓋率只能保證你執(zhí)行到了钱慢，但是它并不意味著它能發(fā)現(xiàn)有效的問題逮京。過于關(guān)注覆蓋率往往只會(huì)適得其反。在分層自動(dòng)化分享的時(shí)候有專門的做過分析束莫，覆蓋率最合適有效的比例是在15%-25%之間懒棉。覆蓋率的考量應(yīng)該也是要取舍的。

  • 優(yōu)先級(jí) VS 成本

    質(zhì)量范疇的各類工作如果用四象限法則來劃分的話麦箍，自動(dòng)化體系建設(shè)大概率會(huì)落到『重要不緊急』第四象限漓藕。自動(dòng)化能帶來那些價(jià)值都是不確定的，尤其是大部分公司手動(dòng)測(cè)試占比依舊是主力挟裂，自動(dòng)化的引入不一定能夠解決質(zhì)量、效率問題揍诽。

    • 而且诀蓉，如果你真的要全面推行自動(dòng)化體系落地，短期成本還會(huì)明顯增加：
      • 人力成本：需要有編程能力的暑脆。
      • 學(xué)習(xí)成本：手工測(cè)試到自動(dòng)化測(cè)試的培訓(xùn)
      • 流失成本：普通測(cè)試工程師學(xué)會(huì)了自動(dòng)化測(cè)試能力渠啤，有了更高的薪酬期望，可能會(huì)跑路添吗。
      • 時(shí)間成本：測(cè)試分層的測(cè)試范圍越大（多層累加）沥曹，不一定會(huì)縮短測(cè)試周期。短期來看是投入大于產(chǎn)出碟联。

  • 內(nèi)部斷層

    能在部門或者公司層面推送自動(dòng)化體系建設(shè)的本來就不多妓美。一般都是在內(nèi)部搞搞。而在網(wǎng)上能找到這種成功分享的經(jīng)驗(yàn)卻很少鲤孵，即使去參加各種測(cè)試峰會(huì)的分享壶栋，所見識(shí)到的所謂成功經(jīng)驗(yàn)，不一定能直接拿來用或者借鑒普监。大部分都是自研且根據(jù)自身業(yè)務(wù)的實(shí)際情況二次開發(fā)定制的贵试。作業(yè)不好抄啊琉兜。

    而自動(dòng)化體系建設(shè)的測(cè)試開發(fā)人員，大多只關(guān)注框架和平臺(tái)的實(shí)現(xiàn)毙玻，不關(guān)心后續(xù)的推動(dòng)和落地豌蟋。甚至是開發(fā)出來的工具平臺(tái)是否能夠滿足業(yè)務(wù)線的期望他們是不關(guān)心的。

    而執(zhí)行層只關(guān)注簡(jiǎn)不簡(jiǎn)單桑滩，是否好上手夺饲。是否影響之前的習(xí)慣（因?yàn)闆]有人喜歡被改變）。這里就會(huì)存在意識(shí)斷層施符。畢竟不在一個(gè)維度往声。各自都缺乏全局視角看待問題。

  • 長(zhǎng)期干擾因素多

    自動(dòng)化體系建設(shè)是一個(gè)長(zhǎng)期沉淀的過程戳吝，貫穿整個(gè)產(chǎn)品研發(fā)的生命周期浩销，是敏捷測(cè)試實(shí)踐中不可或缺的一部分。

    在自動(dòng)化實(shí)踐的過程中會(huì)遇到諸多的干擾因素听哭，測(cè)試資源不足慢洋，項(xiàng)目周期壓縮、提測(cè)質(zhì)量陆盘、需求頻繁變動(dòng)普筹、領(lǐng)導(dǎo)對(duì)自動(dòng)化結(jié)果的質(zhì)疑等等一系列問題，都會(huì)導(dǎo)致自動(dòng)化測(cè)試會(huì)不得不愛隘马。面對(duì)這些問題大多數(shù)情況只能接受并妥協(xié)太防，手動(dòng)測(cè)試加速需求交付似乎就成了唯一。

  • 對(duì)自動(dòng)化測(cè)試的堅(jiān)持

    不同的組織架構(gòu)酸员，對(duì)待自動(dòng)化的態(tài)度不一樣蜒车。如果測(cè)試有獨(dú)立的質(zhì)量部門，有絕對(duì)的話語權(quán)幔嗦，那么推行自動(dòng)化體系建設(shè)才有底氣酿愧。// 這里感謝當(dāng)初 @智哥 對(duì)自動(dòng)化的堅(jiān)持

    而如果是業(yè)務(wù)線形式開發(fā)測(cè)試融合到一起，通常業(yè)務(wù)負(fù)責(zé)人是產(chǎn)品或者開發(fā)邀泉，那么在這種組織架構(gòu)下嬉挡，Leader是不太關(guān)心過程是否用的是什么技術(shù)。他們更關(guān)注的是結(jié)果汇恤，是否能夠高效率庞钢、高質(zhì)量的完成需求交付即可。

    甚至部分開發(fā)人員或測(cè)試人員本身都對(duì)自動(dòng)化測(cè)試結(jié)果存在質(zhì)疑的話屁置，自動(dòng)化體系的落地將更難實(shí)現(xiàn)焊夸。但是即使是這樣或那樣的諸多問題，也不要輕言放棄蓝角。

自動(dòng)化測(cè)試演進(jìn)

只有當(dāng)我們正確認(rèn)認(rèn)識(shí)到自動(dòng)化測(cè)試能給我們帶來的預(yù)期收益阱穗、目標(biāo)和規(guī)避了大部分誤區(qū)之后饭冬，結(jié)合團(tuán)隊(duì)的具體情況，逐步的引入自動(dòng)化測(cè)試揪阶，給予一定的時(shí)間昌抠，慢慢沉淀和發(fā)展，才有可能真正實(shí)現(xiàn)自動(dòng)化測(cè)試的價(jià)值鲁僚。

在不同的階段炊苫，自動(dòng)化的形態(tài)和預(yù)期也不一樣。主要分以下幾個(gè)階段：

• 工具使用

  在團(tuán)隊(duì)前期冰沙，基于 PostMan/jmeter 之類工具的簡(jiǎn)單接口調(diào)用侨艾，應(yīng)當(dāng)致力于一些基礎(chǔ)規(guī)范的制定，比如讓開發(fā)提交時(shí)效性高的接口文檔拓挥，或者通過類似Swagger的插件來自動(dòng)生成文檔唠梨。開發(fā)討厭兩件事：一、討厭別人讓自己寫文檔 二侥啤、討厭別人不寫文檔当叭。

• 引入測(cè)試框架

  當(dāng)下流行的測(cè)試框架也很多，如HttpRunner盖灸，Pytest蚁鳖，Junit5、AirTest等等赁炎。如果團(tuán)隊(duì)成員的代碼能力更強(qiáng)些醉箕，開發(fā)的配合度更高些，也可以嘗試一些左移的框架甘邀，如基于SpringBootTest 的注解進(jìn)行dubbo服務(wù)接口測(cè)試或基于SOA的單元測(cè)試等或其他一些TDD/BDD相關(guān)的測(cè)試框架實(shí)踐琅攘。

  另外有了一定的基礎(chǔ)之后，還可以通過優(yōu)化框架來提供一些提升效率的功能松邪，比如自動(dòng)生成最基礎(chǔ)的測(cè)試用例、數(shù)據(jù)等哨查，或者能夠解析接口文檔逗抑，然后基于這些接口或者用例來補(bǔ)充和完善測(cè)試場(chǎng)景。

• 平臺(tái)化

  當(dāng)團(tuán)隊(duì)實(shí)踐自動(dòng)化測(cè)試有一定的規(guī)模之后寒亥，再考慮做成平臺(tái)化邮府，推廣到更多的團(tuán)隊(duì)當(dāng)中去。大型的公司中都會(huì)有相關(guān)的工具溉奕。比如開源平臺(tái)：meterSphere褂傀、HttpRunnerManagement等其他相關(guān)的。當(dāng)然根據(jù)實(shí)際業(yè)務(wù)進(jìn)行二次開發(fā)是很有必要的加勤。

• 敏捷測(cè)試 DevOps

  可以適當(dāng)開始引入敏捷相關(guān)工具仙辟，CI/CD 流程管理同波， DevOps 平臺(tái)也很多，都會(huì)帶有一定的自動(dòng)化測(cè)試工具叠国，產(chǎn)品良莠不齊需要甄別未檩。嘗試摸索找到符合自身團(tuán)隊(duì)最佳的測(cè)試實(shí)踐。

• AI 智能測(cè)試

  這類自動(dòng)化測(cè)試在最前沿TOP一線互聯(lián)網(wǎng)公司正在逐步的落地(有幸參加了一些技術(shù)峰會(huì))粟焊，看似大勢(shì)所趨冤狡，未來前景無限。但是個(gè)人覺得看看就好项棠。
  // 感謝 @毒蜂 大佬帶我出去漲了見識(shí)

最后

自動(dòng)化的概念的初衷是解決回歸測(cè)試場(chǎng)景的應(yīng)用悲雳。具有可重復(fù)性、穩(wěn)定性等場(chǎng)景香追。主要是考慮功能的穩(wěn)定性和投入成本合瓢，很顯然前期項(xiàng)目功能變化頻繁，需求變更的風(fēng)險(xiǎn)較高翅阵，同時(shí)交付周期較短歪玲。想做到高覆蓋就需要大量的開發(fā)、維護(hù)成本掷匠。其中最主要的矛盾來自于“成本問題”滥崩，反過來想，如果實(shí)現(xiàn)自動(dòng)化覆蓋率的成本在不斷降低讹语，矛盾弱化钙皮，那么這個(gè)局限性可能將會(huì)不復(fù)存在。

只有當(dāng)團(tuán)隊(duì)正確的認(rèn)識(shí)到自動(dòng)化測(cè)試能給我們帶來的預(yù)期收益和目標(biāo)后顽决，結(jié)合團(tuán)隊(duì)的具體情況短条，避免對(duì)自動(dòng)化測(cè)試有過高的預(yù)期，避開一些常見的誤區(qū)才菠，持續(xù)逐步的引入自動(dòng)化測(cè)試茸时，給予一定的時(shí)間，慢慢沉淀和發(fā)展赋访，才有可能真正實(shí)現(xiàn)自動(dòng)化測(cè)試的價(jià)值可都。

?? 綜上，真正要落地自動(dòng)化測(cè)試體系建設(shè)蚓耽，要綜合考慮到人員能力渠牲、成本、項(xiàng)目步悠、組織架構(gòu)等因素签杈，這是件昂貴的事情。也正因?yàn)榘嘿F鼎兽，更應(yīng)該踏踏實(shí)實(shí)邁好每一步答姥，不要把事情浮于表面铣除。

以上這么多廢話都是這些年在自動(dòng)化道路上中學(xué)習(xí)的無感所悟。中間有無奈踢涌、有茫然通孽、當(dāng)然更多的則是收獲。歡迎對(duì)自動(dòng)化測(cè)試感興趣的同學(xué) _{點(diǎn)贊+關(guān)注+回復(fù)} 一起討論睁壁。