自動化測試用例的法寶
軟件測試
1已閱讀
2023-03-31 17:19:05
導讀
今天，我們上海博為峰的小編來給大家講講自動化測試。因自動化測試的種類比較繁多，故相關的自動化測試用例的設計方法、呈現(xiàn)方式、執(zhí)行過程也是五花八門。那我們就在其中挑幾種比較主流的來進行討論，其中也可能不免會有一些不同之處，大家可以按需斟酌閱讀。
自動化的意義
那么開正式開始介紹之前，我們需要搞明白自動化測試的必要性和存在意義。
其中最淺顯的一點就是可以提高我們的測試效率，因為是機器來幫我們執(zhí)行測試活動，這個觀點當然沒錯，但也還是有很多的企業(yè)仍然停留在這個認知層面中，就如我之前闡述過，很多企業(yè)或團隊仍然會以KPI或晉升目標作為動機來開展自動化測試和與之相關的建設活動，這個也就是我們圈內說的，“為了自動化而自動化”。
在這樣的大基調下，自動化能帶給我們的益處與提升是什么，也就不得而知了，更多的則是人力與時間成本的大幅消耗與極為不成正比的投入產出比。
博主自己所理解的自動化測試的存在意義就四個層面來說分為：企業(yè)、產品、團隊、個人。
01 企業(yè)
首先就企業(yè)而言，投入自動化測試的本質其實是要降本增效，這里大概會有人提出疑問，怎么會是降本呢？無論是招聘專業(yè)人員還是投入對應硬件，怎么看都是增本呀。
其實這里有一個誤區(qū)，就我們個人而言，看到的現(xiàn)象的確如此，但對于企業(yè)來說，只要是有明確的戰(zhàn)略目標、長足的遠見規(guī)劃以及一定的投入，從長遠來看這其實是一筆穩(wěn)賺不虧的決定。
02 產品
這里就要結合我們的第二個層面的“產品”來說一說了。眾所周知，在互聯(lián)網(wǎng)行業(yè)中，無論是同行業(yè)亦或是跨行業(yè)，軟件的激烈競爭從來就未停歇過，一款產品的及時面世與穩(wěn)定迭代更新，更是搶占有效市場的先決條件。
試想一下，一家僅靠純手工測試的產品，能做到上述的要求嗎？畢竟人為的還是具有一定的不確定性的，這個和執(zhí)行者的情緒、環(huán)境、主觀想法、惰性有著密不可分的關系，任何一個因素都有可能影響整個產品的質量表現(xiàn)。
所以企業(yè)的前期投入是顯性投入，但后期的自動化測試亦或是更近一層的CI/CD帶來的收益則都是隱性的，可能最后大家真正能見到的將會是產品銷量、收益的增長。
當然，不是投入了自動化測試就一定會讓產品的質量與銷量取得成功，其中的很多因素都必須明確并選擇正確。諸如投入后解決什么樣的問題或矛盾、技術棧的選擇、框架的設計、日常維護、專人專崗、硬件支撐、投入產出比的審查、后期優(yōu)化等等等等。
03 團隊
對于團隊來說，擁有自動化測試能力無疑會讓團隊的外界評價更上一個層次，現(xiàn)在業(yè)界內對于測試人員的要求越來越高，大家都有目共睹。
一個只有手工測試人員的團隊與可長期穩(wěn)定支撐開發(fā)人員且能自主執(zhí)行自動化測試活動的團隊，不用我說也就高下立見了。
也正因如此，專業(yè)的團隊可以在企業(yè)內拿到更多更好的資源也就無可厚非，有了這些實質性的支撐，相信團隊的規(guī)模亦或是實力也將會是越來越強。
04 個人
那么在個人層面上，掌握了自動化測試能力，無疑是增加了自己的一份核心競爭力，增強競爭力的根本出發(fā)點，無非就是讓我們可以在測試的道路上走的更穩(wěn)更遠，升職加薪自不必多說。再則加上如今AI、大數(shù)據(jù)依然成為了主流趨勢，一個沒有編程能力并且沒有設計理念的測試，必然會被社會與時代淘汰。
寫好自動化用例的因素
01 萬物皆對象
學過java或python的同學應該都知道這句話吧，沒錯，在我們設計自動化測試用例的時候也需要這個理念。
畢竟和黑盒測試用例不同，自動化測試用例不是給人類執(zhí)行的，我們需要使用對應的開發(fā)語言來進行用例的編寫。在編寫測試用例腳本的時候，時時刻刻需要把這個理念貫徹其中。
當然，編寫用例的過程與其他開發(fā)人員的編碼沒有什么本質上的區(qū)別，也別指望用例腳本可以一次性的編寫到位，腳本大多數(shù)都是需要一次又一次的優(yōu)化，起初寫的效率低一點也沒關系，我們先確?？梢耘芡ǎ瑥陀眯院徒研钥梢陨晕⒉铧c。
但是跑通之后，我們就應該著眼于性能方面，如果你用的python，跑幾條用例是完全沒有問題的，因為python是動態(tài)語言，變量指向對象的時候編譯器無法做任何預測，另外加上他本身是解釋執(zhí)行，所以是在跑大量測試用例的情況下，一定會出現(xiàn)運行周期時間長與意外報錯的情況出現(xiàn)，此時提高代碼的性能就成為了重中之重，算法時間復雜度的優(yōu)化、內置方法的合理使用、避免全局變量、減少循環(huán)等等都可以為我們的代碼提供相應的性能提升。
02 業(yè)務強關聯(lián)
與黑盒測試用例不同，自動化測試用例內的業(yè)務關聯(lián)性會很強。其實我們從其本質形態(tài)來考慮的話也就能探究一二，它需要解決的本來就是一些功能穩(wěn)定、業(yè)務路徑明確的正向測試場景，測試用例腳本不可能只操作某個業(yè)務界面中的某一個功能，這樣就太浪費了。
一般來說測試腳本都需要覆蓋某一個正常業(yè)務的整條流程，這樣我們才可以在其運行的過程中，加入自己所需的各類斷言，來驗證多條用例中的測試預期結果。另外由于和黑盒測試用例的本質不同，也就更好的印證了自動化測試用例可以快速進行業(yè)務驗證與歸回、冒煙。
03 正向場景
對于自動化測試來說，最恐怖的情形就是將所有的正向、逆向測試場景一股腦的塞進自動化測試框架。有些人會本能的認為既然是自動化執(zhí)行，為什么不可以執(zhí)行逆向測試用例呢？只要設計好合適的參數(shù)、編寫進測試用例真的就萬無一失了嗎？
其實逆向測試場景與測試用例被適合放入自動化測試的原因就在于它本身的不確定性，這種不確定性會影響自動化測試的最終運行結果。
做過自動化測試的同學都知道，對于執(zhí)行自動化測試來說真正可怕的不是逆向測試用例，而是那種不知道什么時候就會報錯的測試場景和用例，而這種測試用例的所在場景，絕大多數(shù)會出現(xiàn)在逆向測試場景中。
我們要知道自動化測試不是幫測試人員把什么事情都干了。所以針對功能穩(wěn)定、需求變動不多的正向測試場景，我們可以放心的將自動化測試投入其中，但逆向的測試場景就不建議如此操作了。
如果真的要放，也只建議放入比較不重要的功能模塊，一些業(yè)務復雜和重要的功能模塊的逆向場景還是需要經驗豐富的測試人員去進行手工確認來的更為的穩(wěn)妥。
一般來說自動化測試主要覆蓋產品的主體happy path即可，無需設計過多的逆向場景在其中，影響自動化測試活動的穩(wěn)定性。不要忘記了，自動化測試的主要作用還是讓我們的測試人員從繁雜重復的測試中脫離出來，把精力投入更重要、更復雜的模塊和業(yè)務測試中去。
04 多場景構建
這里的多場景構建理念是希望可以充分的利用自動化測試的優(yōu)勢，以更少的運行次數(shù)來盡可能的覆蓋更多的測試場景。
舉個例子，一個自動化測試腳本中存在多條測試用例，那么我們在設計用例的過程中需要充分的利用腳本中的業(yè)務界面，來進行多個場景的組合構建。
諸如CRM，我們都會在客戶信息界面中驗證客戶的各類信息、增刪改查操作，而這些操作如果可能盡量放在頁面的一次性操作中，除非和后面的業(yè)務有強關聯(lián)（后續(xù)操作的必要數(shù)據(jù)），否則基本都是按照這個原則。
這也就是上面說的盡量在一遍中將可以驗證的業(yè)務場景組合在一起，而非跑多輪同樣的業(yè)務線卻只是驗證的測試點不同。
05 強針對性
一般來說，我們設計自動化測試用例，來源的基礎都是我們之前設計的黑盒測試用例，普遍的做法是將P0與P1級別的正向測試用例加入到自動化測試用例中。
這樣做是完全沒有問題的，不過我們還需要注意的是，針對不同的測試類型，我們的自動化測試用例不是一成不變的。例如自動化測試中最常配到的冒煙和回歸測試，這兩類的自動化測試用例就不應該相同。
冒煙測試的測試用例應該更傾向于快速的將主流程進行驗證，確保當前版本的提測質量值得開展接下去的測試活動，也更注重于老用例的套用。
回歸測試則是針對部分功能修復后對于整體功能與延展部分模塊的正常運行是否會有影響，這塊需要在已修復的功能模塊和測試認為有必要開展的相關模塊間開展自動化測試，所以自動化測試用例會有和冒煙部分重疊的情況出現(xiàn)，同時也會新增用于確認相關延展部分的功能正常運行的用例。
06 獨立測試功能點
這個也很好理解，和黑盒測試用例沒有區(qū)別，雖然腳本里會設計某個頁面當前整體的線性業(yè)務操作，但是我們仍舊要確保好每條自動化測試用例中只驗證一個功能點，切不可圖方便把一條用例中放入多個功能點進行確認。
這時一定有人會問，我多放幾個斷言不就可以進行多功能確認了嗎？其實這個觀點是違背了測試用例設計的初衷的，多個斷言自然可以判斷多個功能點，但大家試想一下，一條測試用例中有多個驗證點是否會讓用例本身的步驟變多，且無法拆解，這個和寫黑盒測試用例不一樣的地方就在于你的代碼是無法獨立拆解出來的。
那么接下來的問題就是同樣是測試用例，是一堆組合后的測試用例復用度高？還是獨立測試功能點的用例復用度高？大家都不用細想，答案就已經很明顯了。就好比是樂高積木，如果需要你設計一座城堡，是一整塊不規(guī)則形狀的大積木好還是一小塊一小塊規(guī)整的小積木好？
07 完整設計
我們除了設計基本的測試用例之外，同樣也可以利用自動化的優(yōu)勢來進行一些額外的用例擴展設計。
在日常中，我們的自動化測試也不是只要設計相關的功能測試點即可的，這里還括了相關的一些測試數(shù)據(jù)操作。那么測試數(shù)據(jù)的前后置操作也就理所當然的變成了設計測試用例中必須的步驟之一了。
在黑盒測試中，我們的測試數(shù)據(jù)都會在我們執(zhí)行前定義或創(chuàng)建好，在執(zhí)行的過程中就會比較的順暢。而自動化測試中，這個操作我們就無需再手動提前進行操作了，一般來說我們會把需要生成的測試數(shù)據(jù)提前的放入某個獨立的測試用例內進行預先創(chuàng)建，這個稱為前置操作，其實也就是我們所說的前提條件。
而同樣的，我們在執(zhí)行完某些操作或業(yè)務流之后，也可以將這些測試數(shù)據(jù)進行回收、刪除，這被稱為后置操作。這樣我們就可以時刻我們的測試環(huán)境可以重復的進行同樣的測試用例而不會擔心環(huán)境或數(shù)據(jù)等因素發(fā)生改變。
另外，因為我們的測試過程是“過不留痕”，所以在重要的用例與斷言處可以使用截圖函數(shù)、打印日志等方式留下測試證據(jù)，以便在出現(xiàn)Bug時方便排查與定位。
好了，以上就是關于自動化測試用例的一些設計因素與心得，希望可以幫助到大家更好的總結出各自的心得體驗。
2023/04/01
2023/04/01
2023/04/01
2023/04/01
