成功的9大步驟：從手動測試轉爲自動化測試

時間 2020-09-21

原文原文鏈接

您或您的團隊目前是否手動測試並嘗試採用自動化測試？在本文中，咱們將概述小型QA團隊如何從手工測試到無代碼測試再到徹底自動化的測試。這個過渡不會一蹴而就，但成功實現要比預期的容易得多。web

對單調重複的手動測試說不

願意對單調乏味的重複性手動測試說不，就是邁向自動化測試的第一步。做爲測試團隊，須要認可手工測試常常受到重複性的困擾，而且容易出錯。任何團隊最終都會由於一次又一次地作一樣的事情而陷入困境，從而影響團隊的效率和積極性。一些團隊將經過自動化一些小塊的重複性工做來克服這個挑戰。例如，將測試數據導入數據庫的腳本，生成隨機測試數據的實用程序。數據庫

瞭解切換障礙

一旦確認了團隊須要轉移到自動化測試，下一步就是要知道是什麼阻礙着團隊作出這一轉變。在大多數狀況下，這個阻礙是對自動化所涉及的複雜性的恐懼，好比學習編程，腦海中容易浮現出「咱們能學習一種新的編程語言並實施一個成功的測試自動化項目嗎？」諸如此類的問題。團隊應該從小處着手，選擇適合他們測試需求的正確工具。編程

例如，若是團隊的應用程序大量使用iFrames，那麼在選擇一個不能很好地與iFrames配合使用的工具以前就須要斟酌；或者，若是測試團隊沒有任何自動化經驗，那麼在開始自動化測試前先構建自動化測試框架。瀏覽器

從小處作起，但務必要成功

好的開始是成功的一半。當您的團隊剛接觸自動化測試時，選擇簡單而小型的測試用例是很是重要的。選擇您常常手動測試但容易測試的測試用例。簡單和小型的測試用例易於自動化、調試、維護和重用。不要先從那些耗時或複雜的開始，不然會讓開局就變得更困難，下降成功的可能性。例如從登陸、建立用戶等簡單的測試用例開始。框架

選擇合適的工具和框架

簡化流程是成功的關鍵，選擇工具和框架的組合會更容易作到這一點。是的，你沒聽錯，必須是工具的組合，依靠單一的工具很難得到自動化測試的成功。Selenium執行可能會成爲基礎，由於它是用於不一樣編程語言的最流行和最方便的工具。從構建在Selenium之上的無代碼測試工具開始。無代碼測試工具能夠覆蓋大多數簡單到中等複雜的手工測試。編程語言

國產項目管理軟件禪道自研的ZTF自動化測試工具，可很好地驅動8種單元測試框架、3種自動化測試框架來執行測試，並把最終結果回傳給禪道，進行統一的報告展現。禪道ZTF打通了項目管理和持續集成工具之間的溝壑，貫穿持續集成、持續測試、持續部署等DevOps生命週期的不一樣階段。工具

學習並實踐編程

選擇團隊最熟悉的編程語言。無代碼測試可能可以覆蓋大部分手動測試，可是對於複雜的步驟或測試，您將須要編寫腳本。僅僅學習是不夠的，你應該把你的學習付諸實踐來理解和編寫好的代碼。請記住，做爲一個團隊，你的目標是經過自動化重複的手工測試來確保軟件的質量。單元測試

明確自動化內容

團隊必須優先考慮哪些測試須要自動化。自動化測試的新知識並不能應用於全部的事情——事實上，自動化全部測試是不可能的，還有許多測試更適合手動完成。試圖自動化複雜且不經常使用的測試是失敗的公式，不值得團隊付出努力。每當新特性發布時，仍然須要使用手動和探索性測試技能。運行風險分析來肯定應用程序中應該自動化的部分。此外，還須要注意一些細節，好比若是應用程序是基於web的，那麼將須要建立一個對特定測試套件相當重要的瀏覽器和設備列表。學習

對不可靠的自動化測試零容忍

就像你做爲手動測試人員同樣，要拒絕對失敗的測試感到滿意，不該該容忍有時經過而有時失敗的自動化測試。不可靠的測試將導致團隊失去信心，是失敗的墊腳石。例如，若是在一個冗長的測試用例的初始步驟中就出現失敗，就沒法肯定該步驟以外是否沒有錯誤。這樣的不肯定性將不利於鼓舞團隊士氣，也沒法使整個自動化過程輕鬆有效。測試

不要忽視團隊協做

任何項目的成功成果都是由一個協做團隊保證的。自動化測試也不例外。團隊的全部自動化測試都必須位於一個可隨時隨地訪問的存儲庫中。對於可追溯性和可問責性，一個指示誰對哪一個測試用例進行更改的變動記錄應該始終存在。您所選擇的工具應該容許協做，而且還應該使您能夠更容易地對您將在一段時間內建立的100多個測試進行分類、標記、排序和篩選。