Tricentis的創始人兼CPO Wolfgang Platz最近在DevOps Chat Podcast上加入了Mitchell Ashley，談論所有關於持續測試的事情——包括Wolfgang新發布的書，“企業連續測試。”
討論探討了用更高級別的集成、係統和端到端用戶體驗測試擴展開發測試的必要性，這些測試通常由共享測試和運營團隊執行得很好。
以下是討論中的一些節選。的完整的文本可以在DevOps.com上找到。
測試自動化vs持續測試
希禮:我知道持續測試、CI/ cd——所有這些東西當然是DevOps的核心和中心，一切都是從那裏開始的。當然，自動化測試是其中的關鍵部分。所以，當然，這個主題是有需要的。你為什麼決定寫一本書呢?
坐:因此，在與客戶交談並提出這個產品時，我必須承認的是，軟件測試在許多組織中被視為繼子。我的意思是，每個人都意識到開發的相關性，不要誤會我，每個人都意識到IT可以帶來的好處。
但是軟件測試是一種生活在陰影中，這是一種體驗。當我和客戶交談時，我發現他們的要求和他們的直覺需求總是差不多的。他們看到軟件測試就在這裏，他們在某種程度上接受了軟件測試的需要，但突然之間，他們說，“嗯，我的意思是，這需要很多努力，所以我們想把這個自動化。”
希禮:嗯哼。
坐:以更專業的方式處理軟件測試的第一反應是，“讓我們把那件事自動化吧。”自動化是改進軟件測試的一個超級元素方麵，不要誤解我的意思。然而，讓大型企業客戶跟上軟件測試的速度，實際上更像是一個轉型之旅。這是一個你需要經曆的變更議程。
因為這不僅僅是自動化。我的一個朋友說，自動化就是少做點髒活，對吧?
希禮:嗯哼。
坐:但是當你更全麵地看待軟件測試，當你清楚地理解你想要用測試覆蓋的每一個功能的商業價值是什麼時，優化軟件測試就有如此多的潛力。為了解決可能存在於某些功能中的業務風險，測試用例的具體需求是什麼，然後執行這些測試的正確策略是什麼?你打算通過用戶界麵來運行它們嗎?你會通過api來運行它們嗎?你會使用解耦來運行它們嗎，這是一種服務虛擬化使你能夠做到的?
隻有當你有了全麵的視角，你才能讓持續測試真正起作用。否則，它將隻是一些小事情，小改進，當然有幫助，但不開發一個更好的軟件測試世界的全部力量，這就是為什麼我一直在寫這本書。我認為現在應該讓人們意識到——“等一下，這不僅僅是跳上自動化火車。這還不是事情的全部。”如果你隻是那樣想的話，你會把很多東西拋在腦後。這說得通嗎，米奇?
希禮:它完全是這樣的，我想如果我從你描述的東西中提取一些東西，一個是自動化是它的一部分，但連續也是改變你如何思考測試的整個範式的另一個方麵。因為我記得就在不久之前，你們還有一個QA團隊和一個開發團隊。
坐:正確的。
質量角色如何演變
希禮:當然，這自然會造成緊張，因為QA團隊試圖在發布前找出每個問題和需要解決的問題，並召開變更控製會議等等。這是高度手動的，即使一些測試是腳本化的。但現在，在這個持續集成的世界裏，持續的自動化測試你知道，這不是團隊和人之間的爭論和摩擦，更多的是關於我們如何確保我們自動化了正確的事情?我們如何確保當問題需要修複時，當構建中斷和測試失敗時，我們會升級，並確保我們測試的是正確類型的功能?
所以，它讓開發人員參與進來——告訴我你是否同意這一點——它真的讓開發人員更多地參與到創建和擁抱測試中來，而不是成為別人做的一個單獨的功能。真的嗎?
坐:是的,當然。我是說，你已經指出來了，米奇。以前，這就像開發、測試和運維為軟件開發生命周期提供不同的團隊。然而，發生的事情是，這些大型的，我們稱之為卓越測試中心，在那裏你會有大量的手工測試人員，通常集中一些管理能力，甚至可能有一點自動化。
這一塊，這些大型的tcoe，這些優秀的測試中心，他們要麼消失了要麼——或者每個人都在問自己，他們是否應該繼續這種模式。完全正確。因為我們現在看到的對開發速度的需求是，開發和測試之間的合作需要更加緊密，需要更加流暢。
所以，我們看到的是，這些優秀的考試中心被撕裂了。我們在這裏提出的建議是，如果你有一個非常精簡的團隊，一個最佳實踐團隊，或者我們稱之為數字TCOE，一方麵在開發和測試之間有這種緊密的聯係，但另一方麵，提供一些關於如何以最好的方式進行測試的指導。
希禮:嗯哼。
坐:我們看到很多公司轉向了Dev Testers，在敏捷團隊中直接建立了開發人員和測試人員的混合形式。
希禮:嗯哼。
坐:我認為這當然是正確的做法。然而，另一方麵，我們希望非常清楚地認識到，複雜的係統環境需要更高級別的集成測試和一些端到端用戶驗收測試，當人們進入敏捷和DevOps實踐時，這一點現在往往被遺忘了。
轉變過度左傾——並以個人喜好開拓對吧
坐:所以，我認為，是的，我們看到了tcoe的侵蝕。他們加入了開發測試人員，這是很有道理的，但請各位注意，對更高級別測試的需求並沒有在一夜之間消失，需要有人來照顧這一點。我們看到的是，這些需求傾向於更多地向運營團隊轉移，向一種共享服務團隊轉移，現在在大型企業中，但我要說的是，這是一種與流媒體相反的轉變，就像把測試人員推向開發。我們現在也看到了一種向右轉移的運動，這確保了一些更高級別的測試仍然包含在這些共享服務組織中。
希禮:是的，你那樣指出這一點很有趣，因為你知道，你確實聽到了一點關於右移的東西，你想一下我們正在運行的世界，它要複雜得多，因為我們在雲環境中運行，可能做的是雲原生，也可能不是，但我們可能在多雲、私有數據中心、私有雲等環境中工作。
所有這些環境的組合——你知道，有些應用程序可能在一個地方，有些可能在多個地方。這個環境有很多變化，運營團隊會說，“我怎麼知道這個東西能工作?當它壞了，我怎麼知道你能迅速修複它?”診斷它，測試它，並快速應用修複。
坐:絕對的。
進展測試vs.回歸測試
希禮:而且這種自動化也是單元和功能測試的自動化，而且還能夠進行一些性能測試回歸測試這可能是特定於那個環境的，甚至可能是特定於一個迭代版本的，或者是備份和重新應用更改或撤銷更改的。
所以，在這種複雜的環境下，依靠手工流程似乎幾乎是不可能完成的任務。你必須要有自動化，你必須要有做測試的哲學。我討厭在這裏打蠟。也許我在唱你們的歌，[笑聲]但這似乎就是我們生活的環境，我們必須找出最好的方法來做到這一點。我說對了嗎?
坐:不,拒絕很酷。我很高興你提到了回歸，因為我們必須承認的是，敏捷開發的整個思維模式，根據定義，是進步而不是倒退。這很好，因為敏捷開發就是要推出新的版本，推出新的功能、新特性、新功能，比以往更快。
但這種思維方式的含義是，所有敏捷開發團隊和敏捷團隊中的開發測試人員，他們也有這種進步的思維方式。這意味著，是的，如果你和他們一起工作，他們會接受單元測試的需要，他們中的一些人會創建偉大的單元測試。我們已經在我們的客戶群體中看到了這一點。但在某個時間點上，當這轉向回歸時，你可能會發現設置一次單元測試是一回事，但保持單元測試運行是另一回事。我們看到的是，一旦你從遞進轉向回歸，你需要有一個不同的思維方式的人，真正接受回歸作為他們軟件測試行為的關鍵方麵。如果你不這樣做，隨著時間的推移，你就會在複雜的係統環境中遇到問題。
我們看到，實際上，我稱之為單元測試隨時間的蒸發，我們和一些瑞士銀行做了一個很好的調查，我們發現設置單元測試是一件很容易做到的事情。但隨著時間的推移，隨著更多的發布，你會看到它們的覆蓋範圍、潛力和威力正在被侵蝕。然後，人們會更多地參考更高層次的集成，來捕捉這些向前發展的錯誤，這是很有意義的。
但我隻是想讓你意識到——不要把敏捷開發和開發測試人員視為軟件測試的唯一實例。如果你這樣做，你就會在一個複雜的、多係統的環境中遇到問題，這個環境有高度的回歸，有一個沉重的主幹，有一個真正的企業係統環境。
希禮:沃爾夫岡，你是說-你知道，我們過去常說你必須有獨立的QA團隊，所以那些沒有開發軟件的人可以更全麵地測試它，你知道，測試你自己的軟件是很難的，因為你會假設一些事情。
你是說，即使在這個自動化的世界，持續測試的世界，我們仍然需要那些有那種係統性徹徹不透的QA類測試方法的人，即使我們在自動化它，也不嚴格依賴開發人員來創建一個自我創建的單元和係統測試?你是這個意思嗎?
坐:完全正確。這就是我想說的。
關於沃爾夫岡的書《企業持續測試》
希禮:好。跟我們說說你的書吧。你知道，要想讀一本關於一個技術主題的技術書籍，有很多方法。這是一個規範性的“如何做”嗎?這是一種戰略指南，闡述如何在敏捷和DevOps中整合一個完整的持續企業測試計劃嗎?跟我們說說你寫這本書的方法吧。
坐:本書的目的是提供一個全麵的概述，當你去進行持續測試時，你需要考慮什麼。正如我在我們對話的一開始就指出的那樣，僅僅實現軟件測試的自動化並不是解決方案。你需要對這個主題有一個更全麵的看法。
所以，這本書真正要做的是，它要引入一種價值/的視角基於風險的測試敬你，這才是基礎。在我們想要做一個軟件測試之前，我們要確保做這個測試是值得的，對吧?如果這隻是一個功能，與業務的相關性非常非常小，你可能隻需要一個測試用例就可以了，你知道我的意思嗎?
希禮:嗯哼。
坐:然而，如果它是您軟件的一個絕對任務關鍵的功能，那麼您就需要確保這個特定用例中所有不同風格的用例和所有不同的過程都被真正覆蓋了，否則，從風險的角度來看，它是不可承受的。
因此，對業務風險(斜杠)有一個清晰的理解——與您的軟件提供的每個功能相關的業務價值是基礎。如果你清楚地理解了這一點，你就能展示一張地圖，你想把錢投到哪裏的地圖。你猜怎麼著?這張地圖不僅僅是用於您的預算分配，它還將與您的報告相關，因為您的報告應該麵向覆蓋的業務風險，而不僅僅是計算測試用例。
你猜怎麼著?你的管理層會喜歡的。突然之間，他們看到有人對軟件測試領域的預算如何分配有一個計劃。所以，這真的是很酷的東西。
一旦你知道了這一點，你就會想要確保手頭有正確的測試用例。我們將給你一個關於如何創建最有意義的測試用例的不同技術的概述——有意義的是我可以用具體的測試用例覆蓋的附加業務風險的程度是多少，對嗎?當我們完成了這些，我們將讓你意識到有不同的方法來實現自動化。你可以通過用戶界麵，你可以通過API。當你經曆這些的時候，一定要把係統解耦，這樣你總是能確切地知道失敗的原因是什麼。
希禮:嗯哼。
坐:當你想到這個的時候，你想要確保你的測試數據是穩定的，這意味著係統手上總是有一個可靠的基本數據集，這樣你就不會對測試失敗感到驚訝，這隻是測試數據不一致或不正確的問題。
所以，所有這些東西都會在書中介紹。當然，不會深入到非常非常細節的層麵，但我認為至少在某種程度上，你知道它是關於什麼的，你有一個很好的基礎，從那裏你可以開始深入挖掘東西。但理想的情況是，你拿著這本書走回家，然後說:“嗯哼。現在我明白這是怎麼回事了。”而且我不會直接走出去，跳到下一個測試自動化的開源框架上，然後說，“這將是我整個旅程的聖杯”，你知道嗎?這取決於你想要達到的目標。
希禮:它是關於為如何做這類工作創建一個係統的、規範性的框架，因為測試是，這聽起來像是一個很容易理解的詞，但它也太超負荷了，因為，正如你所說，有很多測試的方式，無論是通過API、接口，有安全測試，有黑箱測試，你提出了測試數據的整個話題。它一開始就很難獲得，你必須把它作為主要內容，你知道，隨著功能和應用程序的發展而發展——
坐:哦,是的。
希禮:——部分回歸，也。這真的是一個非常複雜的話題，你會進入性能測試，負載測試，有點混亂猴子式的彈性測試，各種各樣的事情都可能發生。然後在幕後，現在我們自動化了這麼多，我們有了這些超級有價值的數據，我們可以和業務溝通。我們在這裏插入代碼，它就進入了生產，下麵是我們如何知道它經過了徹底的測試，並確保當我們把它投入生產時，它是可靠的。
坐:是的，而這實際上是我們的旅程的前進方向。我們將看到發生的是越來越多的跟蹤信息，來自生產的日誌信息將反饋到測試循環中，對嗎?
希禮:嗯哼。
坐:我已經指出了商業風險的投保範圍。我的意思是，你如何對商業風險有一個清晰的認識呢?你要通過了解係統使用的頻率和潛在的損害是什麼來解決這個問題。現在，如果你有適當的日誌記錄，這些信息都可以從生產日誌中獲得。這些生產日誌可以反饋到循環中，現在影響您對特定功能的測試意識，從最開始，從開發的角度，到更高級別的測試。
所以，我們將要看到的是，數據，數據的使用，即使有一些人工智能的參與，也將成為驅動測試周期進一步效率的巨大來源。因此，我們將看到，實際上，基於價值的測試的想法，與手頭有正確的測試用例相結合，通過這個我們將進入未來的數據循環，會更加優化和加速。
