2015年，高級軟件工程師Benjamin Willenbring對Autodesk公司進(jìn)行自動化軟件測試感到興奮。但這種興奮卻沒有持續(xù)多久，這是因為自動化團(tuán)隊與其他部門溝通不多，而當(dāng)測試進(jìn)入生產(chǎn)階段時，并沒有帶來大家所希望的結(jié)果。

Willenbring說：“我們談?wù)摰氖欠菦Q定性的失敗測試，但對其測試并沒有太大的信心。開始運(yùn)行測試非常困難，由于沒有參考的案例，需要經(jīng)常溝通，并且產(chǎn)生大量文件，我當(dāng)時真的不知道如何處理。”

[[316367]]

自動化軟件可以簡化Willenbring的工作。在接下來的幾年里，這些問題占據(jù)了他的大部分精力。

Willenbring的經(jīng)歷并不罕見。隨著自動化通過IT技術(shù)的應(yīng)用而迅速普及，并提供了一些寶貴的經(jīng)驗和教訓(xùn)。

從DevOps的自動化工作流到機(jī)器人流程自動化(RPA)，自動化流程旨在減少繁瑣的工作，并使熟練的員工解脫出來從事更高級別的任務(wù)。但是，具有缺陷的辦公場所或部署不完善的項目可能會使自動化的夢想變成一場噩夢。一些IT專家對他們所聽說或遭遇的自動化失敗案例進(jìn)行了闡述，并分享了六個技巧，以幫助企業(yè)的自動化計劃避免失敗的命運(yùn)。

1. 自動化是每個人工作的一部分

Willenbring的自動測試面臨一個關(guān)鍵問題：唯一了解自動測試的人員就是構(gòu)建自動測試軟件的人員，但通常他們并不一定在企業(yè)總部工作。

Willenbring說：“測試框架的困難之一是，當(dāng)出現(xiàn)故障時，它無法真正提供良好的反饋。如果失敗，需要做的第一件事就是通過協(xié)作應(yīng)用程序Slack聯(lián)系測試負(fù)責(zé)人，并問為什么會失敗?然后，通過人工重新運(yùn)行測試，對于框架的某些特殊版本，需要對可看到結(jié)果或?qū)⒁獙l(fā)生的情況進(jìn)行溝通。”

DXC科技公司全球DevOps產(chǎn)品經(jīng)理Robert Haas表示，其測試框架違反了兩項基本規(guī)則，每個自動化制度都應(yīng)遵守這兩條規(guī)則。首先是必須記錄自動化代碼。Haas說：“無論企業(yè)使用像編制文檔之類的現(xiàn)代方法，還是對Visio圖表進(jìn)行注釋，如果有一些文檔描述了最初所做的事情，那么解決問題將變得更加容易。”

如果沒有文檔，自動測試對Willenbring的團(tuán)隊是難以理解的。他們將無法理解測試結(jié)果，并且對測試和創(chuàng)建它們的團(tuán)隊失去信心。Willenbring說：“有時候開發(fā)人員可能并不在乎，認(rèn)為這不可能是真正的失敗。有時候，測試框架確實存在真正的失敗。但是，關(guān)鍵問題是對測試和結(jié)果缺乏信任。”

Haas的另一個建議是：“根據(jù)需要交付的業(yè)務(wù)價值，對需要實現(xiàn)自動化的活動進(jìn)行優(yōu)先排序。”但是由于Autodesk的測試團(tuán)隊與開發(fā)團(tuán)隊如此分離，Willenbring發(fā)現(xiàn)他選擇的代碼庫中的許多領(lǐng)域都違背了常識。他說，“需要讓主題專家或了解重要內(nèi)容的人員選擇要測試的東西。如果只是在瀏覽一大堆錯誤記錄，那么不能保證測試的數(shù)量能夠準(zhǔn)確地反映出任何有意義的東西。”

新上任的工程總監(jiān)使Willenbring及其團(tuán)隊擺脫了這一惡性循環(huán)。工程總監(jiān)要求質(zhì)量測試成為每個人的工作，其中包括測試自動化，并取消集中式測試，讓各個部門負(fù)責(zé)為其工作編寫測試代碼。Willenbring和他的團(tuán)隊現(xiàn)在可以根據(jù)自己的需求量身定制測試，并將該過程整合到他們的日常生活中。最后他說：“必須對‘那不是我的工作’的態(tài)度制定零容忍政策。”

Willenbring為此受到啟發(fā)，并對其自動化之旅進(jìn)行了詳細(xì)的描述，其中包括人們可能感興趣的深入材料，以及他處理的Selenium和Cypress測試框架的詳細(xì)信息。

2. 為復(fù)雜性做好準(zhǔn)備

安全和合規(guī)自動化供應(yīng)商Tripwire公司最近注意到該公司的一個大型金融客戶的自動化解決方案運(yùn)行有些奇怪。

Tripwire的加拿大地區(qū)經(jīng)理Irfahn Khimji說：“這家公司部署了自動解決方案，但卻花費(fèi)了很長時間，我們一直在想為什么看不到其許可證使用率顯著上升?因為他們部署的速度應(yīng)該很快。”

事實證明，大部分自動化的持續(xù)集成(CI)/持續(xù)部署(CD)管道的理想正在金融組織的各個業(yè)務(wù)部門工作中實現(xiàn)，每個業(yè)務(wù)部門都依賴于自己定制的軟件組件集。

Khimji說：“他們正在嘗試使用30多種應(yīng)用程序，這些應(yīng)用程序的商品化(在各種庫中需要的模塊以及類似的東西)都面臨一些挑戰(zhàn)。調(diào)整管道以處理所有這些不同的變化確實減緩了自動化過程，因為它不僅是簡單的部署，還需要確保所有這些不同的技術(shù)都相互協(xié)作。”

沒有什么靈丹妙藥可以解決這個問題，但是需要知道，隨著自動化流程中組件數(shù)量的增長，連接這些組件所需的管道數(shù)量會以指數(shù)級增長，并變得更加復(fù)雜。當(dāng)過渡到自動化流程時，這種復(fù)雜性將需要更多的時間和資源。

增加這種復(fù)雜性的另一個因素不僅是要連接的組件數(shù)量，還包括它們的來源。大多數(shù)管道或機(jī)器人流程自動化(RPA)驅(qū)動的環(huán)境都包含內(nèi)部組件和第三方組件的異構(gòu)組合，如果出現(xiàn)問題將難以解決。

DXC科技公司的Haas說：“確保持續(xù)集成(CI)/持續(xù)部署(CD)管道或自動化過程的所有組件都與軟件提供商簽訂維護(hù)合同。如果有開源組件，請進(jìn)行風(fēng)險評估，以確定是否應(yīng)考慮使用產(chǎn)品的托管版本，而不是依靠開源社區(qū)的基于Web的支持。”

3. 當(dāng)心“黑盒”

金融機(jī)構(gòu)一直是希望部署機(jī)器人流程自動化(RPA)和聊天機(jī)器人的機(jī)構(gòu)之一，Aisera公司的首席執(zhí)行官兼聯(lián)合創(chuàng)始人Muddu Sudhakar警告說，他在這些環(huán)境中經(jīng)?？吹竭@樣一種情況：流程被視為一個單一的整體功能單元，成為了一個“黑盒”，其內(nèi)部操作很難被排除在故障之外。

他說：“在整體結(jié)構(gòu)中，客戶將檢查其帳戶的狀態(tài)，如果要提取并轉(zhuǎn)移這筆費(fèi)用，這一切都將一步到位。如果出了問題，并且沒有經(jīng)過審計的步驟監(jiān)控，那么在災(zāi)難性失敗中取回資金的唯一方法是致電客戶服務(wù)部門，也許需要親自去銀行取款。”

對于Sudhakar來說，這種設(shè)計通常是企業(yè)早期采用自動化的標(biāo)志。只要一切都按計劃進(jìn)行，這樣的項目就可以產(chǎn)生良好的結(jié)果。但是如果不是這樣，企業(yè)通常必須回來拆分這些黑盒。最好從一開始就避免使用它們。

他說：“將每個過程分解為多個構(gòu)建塊，其中每個構(gòu)建塊都是可審核和可監(jiān)控的。”

4. 建立制衡機(jī)制

Ari Meisel是Less Doing公司創(chuàng)始人，也是一位對自動化工作特別感興趣的生產(chǎn)力教練。他經(jīng)常為生活方便開發(fā)一些自動化軟件。但當(dāng)他試圖避免停車罰單時，采用自動化軟件卻遭遇了一個沉痛的教訓(xùn)。

Meisel擁有一輛皮卡車，從技術(shù)上講是一輛商用車，而在他居住的紐約市，這種汽車的擁有者很容易對罰單提出異議：“可以向當(dāng)?shù)刎攧?wù)部門發(fā)送信函辯解說，‘我正在送貨。'”

他承認(rèn)，他的這種做法并不完全合法的：他創(chuàng)建了一種自動化軟件系統(tǒng)，可以隨機(jī)生成發(fā)票，并將發(fā)票和信函發(fā)給當(dāng)?shù)刎斦块T，以對取消罰單進(jìn)行辯解。他表示這種方法開始奏效，但卻出現(xiàn)了問題，因為該系統(tǒng)發(fā)送了100多次完全一樣的信函和發(fā)票，財務(wù)部門威脅要把我送進(jìn)監(jiān)獄，為此我找到律師進(jìn)行辯護(hù)，最終結(jié)果我為此花費(fèi)了3.6萬美元。”

他意識到，他的自動化處理軟件需要的是一個防錯措施。這個術(shù)語的意思是“防錯”，在豐田公司的汽車生產(chǎn)體系中，采用過程的步驟，這個步驟被分成了兩個步驟，第二個步驟的運(yùn)行依賴于第一個步驟。雖然增加步驟但反而提高了效率，這好像有些自相矛盾，但如果沒有排除錯誤將會影響生產(chǎn)線運(yùn)行。Meisel說，在他的逃避罰單的計劃中，如果自動運(yùn)行程序?qū)⒚恳粡埌l(fā)票與之前發(fā)送的發(fā)票進(jìn)行比較，查看內(nèi)容是否相同。這是一件很容易做到的事。”

這擴(kuò)展了Aisera的Sudhakar的建議：每個自動化步驟不僅應(yīng)該是可以審核的，而且還應(yīng)由其他自動化步驟不斷進(jìn)行審核。在AIOps領(lǐng)域中，自動化平臺承擔(dān)了工程師的IT管理負(fù)擔(dān)。Sudhakar說：“我稱之為美國航天局(NASA)方法。NASA必須假設(shè)將要發(fā)生的故障，必須采用具有制衡功能的AIOps解決方案。”

但是，除非親身經(jīng)歷了自動化的失敗，否則很難看到它的價值，Meisel說：“人們在90%的時間內(nèi)都會出問題。他們表示，不會采用這種永遠(yuǎn)不會真正受益的自動化技術(shù)，然后卻發(fā)現(xiàn)他們確實需要它。”

5. 不要忽視安全

自動化的持續(xù)集成(CI)/持續(xù)部署(CD)管道有一個秘密：許多用于解決安全性要求的管道最初是作為影子IT推出的。Tripwire的Khimji說：“開發(fā)者想繼續(xù)下一次迭代(開發(fā)代碼)。因此，當(dāng)嚴(yán)格的IT和安全流程陷入困境時，他們認(rèn)為，‘我可以在云平臺中生成這些映像，并且我可以規(guī)避它們。”

這并不意味著這些管道天生就不安全，但是應(yīng)該調(diào)查哪些安全實踐是為了提高自動化效率而放棄的。此外，需要記住，任何自動化進(jìn)程都代表了攻擊的另一個向量。自主操作的進(jìn)程可能具有提升的權(quán)限，使它們成為誘人的目標(biāo)。Aisera公司的Sudhakar說，他了解一些稱之為“黑天鵝”的例子：例如一個競爭對手在一家公司內(nèi)部使用DevOps管道將惡意軟件注入代碼庫，使其傳播到生產(chǎn)環(huán)境中，使其系統(tǒng)無法運(yùn)行。

6.不要廉價地自動化

Tesults公司首席開發(fā)人員和創(chuàng)始人Ajeet Dhaliwal發(fā)現(xiàn)，不當(dāng)?shù)某醋鲿碚`解。許多企業(yè)都有一個“自動化測試”的愿景，但它與最佳實踐大相徑庭。在沒有技術(shù)背景的小型組織中尤其如此。由于他們了解人工測試，因此從邏輯上講，自動測試應(yīng)該只是無需人工干預(yù)即可進(jìn)行的人工測試的一種版本。

因此，Dhaliwal說，“他們鼓勵那些沒有軟件開發(fā)背景的傳統(tǒng)質(zhì)量保證(QA)測試人員執(zhí)行人工測試，使測試實現(xiàn)自動化。有時這意味著使用工具，只記錄人工用戶界面(UI)測試，以便以后重復(fù)進(jìn)行。這些方法的健壯性和靈活性與開發(fā)人員在自動化方面能夠?qū)崿F(xiàn)的目標(biāo)不匹配。”

Dhaliwal補(bǔ)充說：“自動化測試開發(fā)人員還需要成為軟件工程師。有一些初級開發(fā)人員參與是可以的，但是這些公司需要一些經(jīng)驗豐富的開發(fā)人員來領(lǐng)導(dǎo)這項工作，而他們沒有這樣的人員。”

而且，正如Autodesk的Willenbring所說，軟件工程師還需要了解如何構(gòu)建自動化流程。他說：“這只是開發(fā)人員將擁有的技能之一。當(dāng)企業(yè)可以使用這些技能時，希望這些技巧將有助于企業(yè)的自動化項目獲得成功。”