Jason English為Parasoft撰寫的Intellyx BrainBlog

您是否曾經有一位朋友因為牙齒的潔白而被強迫癥所困擾？他們去找美容牙醫(yī)進行激光美白，然后抱怨說不夠美白？最終，它們達到了漸近點，牙齒的表面無法反射99.9％的光線，因此，要獲得能夠提供99.999％潔白牙齒的治療，成本太高，而且是不可能的。

測試工程師、性能測試人員和SRE著迷于在軟件交付的最后一步達到99.999%（有時甚至更高）的可靠性，這對客戶的影響最大。

如果您也擁有有關應用程序可靠性的OCD，那么您已經計算出了數(shù)學知識，并意識到5 9相當于每年總計約5.26分鐘的停機時間。您還意識到測試工程的成本和努力超過99.9％以確保99.999％的正常運行時間是不菲的。

在大多數(shù)情況下，將生產從3 9提升到5 9會比3 9吞噬更多的IT預算！

似乎世界上所有的生產前性能測試都不可能消除所有可能導致0.001％的停機時間的未知狀況。不管我們花多少錢。

但是，讓我們不必擔心您無法改進的一件事，一直到軟件交付的右側。不，不，不......無論如何，當應用程序完全烘焙后，在這里解決問題要花費很多。不能迷戀它。

只是一個小小的閃光點。沒有人是完美的。學會放松。

與早期的DevTest團隊取得新的見解

為什么不將生產暫時擱置一會，而在軟件生命周期開始時與DevTest團隊閑逛呢？

在軟件交付左側的此處，他們正在繪制地圖、編寫代碼并挑選組件。不在乎世界，不用擔心部署中可能發(fā)生什么未知的未知因素。

他們正在運行測試優(yōu)先的敏捷開發(fā)，并且每個構建都在運行大量結構代碼檢查，并運行自動化的單元和回歸測試套件。他們在那種測試上向左移動。

他們也不必擔心自己所做決策的影響。當將各種服務、軟件和基礎結構組件集成到一個正在運行的應用程序后面時，它們在負載下進行交互時會產生各種非功能性問題。

早期的設計和開發(fā)選擇可能會在以后提供壞消息，但是傳統(tǒng)上，非功能測試（NFT）和性能測試會在生產階段進行。

等等，如果您可以將NFT引入設計和開發(fā)呢？能否提供足夠的預警以防止最嚴重的錯誤？

將NFT和PerfTest向左移動

非功能性問題很難在軟件的早期發(fā)現(xiàn)，因為在現(xiàn)實中很難在實驗室中再現(xiàn)真實情況。

您可以在應用程序界面或用戶授權過程上運行Selenium功能測試套件，或者運行一組API服務測試調用和數(shù)據(jù)集以驗證響應，或者對代碼運行一堆JUnit或NUnit測試。但是所有這些方法只能測試您期望在早期階段發(fā)現(xiàn)的問題。

為了更貼近現(xiàn)實世界，團隊可以選擇三種選擇。

1.插入功能測試以進行基準測試。如果在CI/CD軟件管道中插入Selenium功能測試，并使用諸如之類的配套工具自動化它們，以監(jiān)視每次構建的執(zhí)行時間，則可以為任何應用程序、組件或服務捕獲一個相當不錯的基準。

如果響應時間有某種偏差（無論出于何種原因），則構建可以通知構建平臺或開發(fā)人員某些異常（可能無法正常運行）導致特定組件的運行速度降低。

2.重用測試并在負載下重復。為什么要等到最后才使用需要近乎完成的UI調用的LoadRunner之類的工具，專門的測試技能以及較高的單座成本？

相反，如果您從Parasoft SOAtest之類的工具中進行了Selenium測試以及一些安全性檢查以及服務和集成測試，然后開始循環(huán)并重新運行它們，也許在數(shù)據(jù)或時序方面存在較高的頻率？您將獲得早期性能測試，向左移動。

在這里，您可以將Web樣式、UI調用、對API或事件隊列的非UI調用的不同組合結合起來，以進行混合性能測試，從而可以測試應用程序目標生態(tài)系統(tǒng)的多個層面，而無需等待完成的應用程序。

3.隔離環(huán)境依賴性。向左移NFT的最后障礙是應用程序實際存在的環(huán)境。現(xiàn)代應用程序在充滿數(shù)據(jù)和服務依賴關系的世界中發(fā)揮作用。

在這里，可以使用服務虛擬化解決方案進行基于環(huán)境的測試，以便對實時應用程序周圍的所有上游和下游依賴性進行檢測。這樣，您就可以模擬諸如銀行合作伙伴的系統(tǒng)、國家天氣或空中交通系統(tǒng)之類的東西，這些東西永遠都不會受到您的控制，也無法導入您自己的DevTest實驗室。

可以將依賴項作為虛擬服務進行偵聽并捕獲為虛擬服務，就軟件測試而言，這些組件可以響應“比真實情況要好”。

一家加拿大銀行使用了這三種技術的組合。他們自動執(zhí)行功能測試以獲取貸款應用程序組件的基準，然后與其他一些測試一起重新運行該測試，以進行數(shù)據(jù)查詢和對第三方信貸服務的虛擬服務“模擬”的API調用。

他們很擔心。如果虛擬API服務響應太慢——被測組件會發(fā)生什么？它做出了預期的響應，但是隨后測試團隊加快了該第三方響應的虛擬服務，使其在最短的時間內完成。當出現(xiàn)響應速度太快時，出現(xiàn)了一個“競爭條件”，導致組件事務失敗！

The Intellyx Take

在軟件中，只有一個完美的定義，但是失敗是無限的。

無論我們刷多少遍，我們都永遠不會有100％潔白的牙齒。無論我們進行多少測試，我們都永遠不會100％清除生產中的缺陷，在這些缺陷中，錯誤很難隔離且修復成本很高。

但是，通過適當?shù)臏y試左移，包括非功能測試和性能測試，我們可以得到一個預警系統(tǒng)，該系統(tǒng)可以消除許多這些新生問題，使它們沒有機會出現(xiàn)在性能實驗室中或失敗在客戶面前。