<output id="qn6qe"></output>

    1. <output id="qn6qe"><tt id="qn6qe"></tt></output>
    2. <strike id="qn6qe"></strike>

      亚洲 日本 欧洲 欧美 视频,日韩中文字幕有码av,一本一道av中文字幕无码,国产线播放免费人成视频播放,人妻少妇偷人无码视频,日夜啪啪一区二区三区,国产尤物精品自在拍视频首页,久热这里只有精品12

      軟件自動化測試初學者忠告

      題外話

      測試入門

      很多受過高等教育的大學生經常問要不要去報測試培訓班來入門測試。

      答案是否。

      高等教育的合格畢業生要具備自學能力,如果你不具備自學能力,要好好地反省一下,為什么自己受了高等教育迷戀于各種入門級別的培訓?是沒有毅力還是不知道學習方法?

      沒有毅力的話,要自己多看些勵志的書,多想想社會的殘酷,親人的失望等來勉勵自己,畢竟企業多半也不會喜歡懶散的人的。

      不知道學習方法的話,讀《軟件評測師教程》(國內軟件評測師教材),《Software Testing Foundations 4th》(強烈推薦 國外測試認證ISTQB教材),《谷歌測試之道》是通常比培訓機構更好地入門測試。

      以上書籍及測試標準等后續將陸續上傳:https://github.com/china-testing/python-testing-examples

      image

      我身邊碰到比較有水平的軟件測試,沒有一個是什么石、testing、林、鳥、*內等入門測試的。而且這些機構經常打著包就業的名義騙人去培訓,培訓的老師通常口才很好,善于包裝,但是關鍵的一點,這些老師多數自己都不是合格的測試。培訓完之后有些學生重學幾次又無法就業,甚至出現學生和培訓機構對簿公堂的情況(這種情況通常是培訓機構敗訴,如果你身邊有這樣的被騙朋友可以建議他們先交涉不行再找律師保護自己)。

      實體培訓業尤其成為打著就業的幌子進行行騙的重災區,導致現在主流企業一看到有某些機構經歷的簡歷直接連面試機會都沒有了。

      當然不是一棍子打死所有的測試培訓,比如斯特沃克的培訓,google的gtac等分享是做得相當不錯,建議自己先對測試有一定的了解,了解測試培訓授課老師的水平之后再選擇培訓,盡量自學為主,在身邊找有經驗的實際測試人員稍微帶下。

      測試的方向整體是功能測試的工作崗位逐漸減小。facebook就沒有測試人員,google也沒有專職的功能測試,功能測試由開發、產品、用戶等分擔會降低溝通等成本。未來的測試人員更加需要開發技能。

      對于太極,推拿之類的,視頻是很好的學習方法。但是對于軟件自動化測試,最好的學習方法不是聽課,也不是看視頻,而是在有經驗的專業人士指導下進行項目實戰、發現問題、解決問題。實戰實戰再實戰!

      本人曾在公司項目中曾手把手教剛畢業的毫無編程基礎的技校生接口、性能、自動化等測試,結果3個月之后他們都跳槽,薪水從4k漲到10k以上(2015年)。

      自動化測試進階

      IT主要技術體現大多先用英文描述,要想提升到比較高的水平,必須要有流利的英文閱讀能力。

      搜索引擎方面要珍惜生命,遠離競價排名,做個有良知不受騙的人,從不用死不悔改的*度開始,優選google,其他的還有 必應 雅虎 oscobo, 很多QQ群還有免費fanqiang工具。google的搜索通常能直中目標,stackoverlow的回答通常是首選方案。

      選擇有水平的業內人士幫助是掌握linux、python和測試基礎之后一個迅速提升的方法。

      自動化測試的層次

      image

      從圖看出自動化盡量以單元、接口為主,如果你有志在自動化測試深入,還在死磕QTP,selenium等的話,建議看下pytest、pexpect、API測試、單元測試等。

      腳本

      1-1 不要在實際項目中使用錄制和回放

      大多數自動化工具(特別是商業工具)具有記錄和播放功能,這個功能的表面簡單,實際有陷阱。錄制和回放在廣告視頻和演示文稿中看起來非常棒。但錄制的腳本不使用變量,循環和條件。自動創建的程序和函數的名稱通常不直觀,通常所有操作都錄在一個函數中(可能很大),執行不穩定,維護成本也高。

      • 錄制和回放適用點
        • 在學習自動化工具
        • 不重用的工作
        • 很難識別和處理的控件

      1-2 不要使用暫停

      暫停,比如python中的:

      
      import time
      
      time.sleep(5)
      
      

      定義全局變量可以避免大量代碼修改,如下

      
      WAIT_TIME = 5
      ...
      time.sleep(WAIT_TIME)
      
      

      上述等待不利于快速執行,較快出現的控件同樣需要常見等待。等待對象或對象屬性是更好的選擇,比如selenium中的顯式等待:

      
      from selenium import webdriver
      from selenium.webdriver.common.by import By
      from selenium.webdriver.support.ui import WebDriverWait
      from selenium.webdriver.support import expected_conditions as EC
      
      driver = webdriver.Firefox()
      driver.get("http://somedomain/url_that_delays_loading")
      try:
          element = WebDriverWait(driver, 10).until(
              EC.presence_of_element_located((By.ID, "myDynamicElement"))
          )
      finally:
          driver.quit()
      
      

      又如selenium中的隱式等待:

      
      from selenium import webdriver
      
      driver = webdriver.Firefox()
      driver.implicitly_wait(10) # seconds
      driver.get("http://somedomain/url_that_delays_loading")
      myDynamicElement = driver.find_element_by_id("myDynamicElement")
      
      

      以WebDriverWait一定的時間間隔檢查對象的存在(例如每秒一次),如果象出現,則返回true。如果對象在timeout參數指定的時間內沒有出現,則返回false。因此,如果控件一秒鐘內出現,那么等待時間將會是 1秒。

      當然短時間的等待,有時也是必要的,比如降低CPU使用率,短時間等待狀態改變等。

      1-3 在循環中超時退出

      以常量的形式定義超時。例如定義兩種類型的短超時(3秒)和長超時(3分鐘)。

      1-4 不要將自動化測試完全等同于開發

      雖然自動化需要編程技巧,但它通常不是完整的開發項目。自動化常由初級程序員開發,因為工作簡單得多,并一般為內部需求。在99%的情況下不需要大多數設計模式。在使用數據庫時不會使用事務。測試數據量一般不會很大。

      代碼要力求簡單,快速開發。即使使用了行為驅動開發(BDD:behavior-driven development)或關鍵字驅動的測試(KDT:keyword-driven testing)等方法也要盡量保證代碼簡單。

      1-5 不要寫復雜的代碼

      在使用條件和條件時,盡量遵循“不超過三個嵌套級別”的規則。

      代碼嵌套超過三層非常難以調試。寧肯代碼多重復也不要嵌套超過三層。

      1-6 驗證邏輯條件的所有選項

      
      if A and B or C:
      # if (A and B) or (C and D)
      
      

      定要檢查這些代碼的每個條件(在這個例子中的A,B,C)和所有可能的True和False。添加括號能增加可讀性。

      1-7 使用編程規范

      初學者通常不太關注變量和函數的名稱使用任何規則。盡管如此,幾乎所有的語言都有所謂的編碼標準。比如python的PEP8, google的編程規范。

      在大項目中這些標準成為強制性規則,方便互相理解代碼。

      1-8 使用靜態代碼分析器

      對于流行的編程語言,有特殊的代碼分析器。例如Python的pylint,JavaScript語言的jslint等。

      特別指出對python這樣的動態類型的語言更加重要。

      pylint通常有很多誤報,但是mypy的檢查則比較實用。參考:python代碼分析和lint

      1-9 隨機

      比如打開菜單有快捷鍵、下拉菜單、圖標等多種方式,盡量寫方法隨機調用各種方式。以求覆蓋各種場景,不過要記得添加日志以便跟蹤錯誤。

      1-10 不要使用坐標

      非標準控件盡量不要使用坐標,可以用圖像識別的方法:

      
      Window.Toolbar.Click(135, 15)
      
      

      替換為:

      
      toolbar_click_button_by_image(Window.Toolbar, "Button Caption")
      
      

      1-11 學習和使用庫

      比如:

      
      full_name = '{0}\\{1}'.format(file_path, file_name)
      
      

      在linux上就比較尷尬,可以替換為:

      
      full_name = os.path.join(file_path, file_name)
      
      

      附: python自動化測試開發庫

      1-12 避免復制和粘貼

      復制的代碼維護成本很高,盡量提取為公共庫。

      公共測試庫示例

      1-13 異常捕捉到具體的類

      異常通常是程序考慮不周到才會發生:

      
      try:
          x = input('Enter the first number: ')
          y = input('Enter the second number: ')
          print x/y
      except Exception as e:
          pass
      
      

      上述捕捉所有異常并忽略異常的代碼通常只在臨時代碼中使用。通常也要把異常異常信息顯示出來。比如

      
      import sys
      try:
      	x = input('Enter the first number: ')
      	y = input('Enter the second number: ')
      	print x/y
      except Exception as e:
      	print e
      	for  item in sys.exc_info():
      		print item
      
      

      又如:

      
      import traceback
      
      import cv2
      import numpy as np
      
      def raw2jpg(filename, height=480, width=640):
          try:
              img = np.fromfile(filename, dtype=np.uint16)
              img = img.reshape( (height, width) )
              img.astype(np.float)
              img = np.sqrt(img)
              img = img * (255 / img.max())
              #img.astype(np.uint8)
              cv2.imwrite(filename+'.jpg', img)
          except Exception as info:
              print('Error: {}'.format(filename))
              print(info)
              traceback.print_exc()
              return False
      
          return True 
      
      

      更佳的方式是捕捉到具體異常:

      
      try:
          x = input('Enter the first number: ')
          y = input('Enter the second number: ')
          print x/y
      except ZeroDivisionError as e1:
          print("ZeroDivisionError")
      except TypeError as e2:
          print("TypeError")
      
      

      另外一種異常處理方式:

      
      far = 0 if not no_number else far_number/float(no_number)
      
      

      1-14 代碼與數據分離

      對于小數據集可以使用數組或列表。大數據可以使用數據驅動測試(DDT:data-driven testing)。數據源可能為數據庫,Excel或CSV文件等。

      注意點:

      • 以讀模式打開數據文件。
      • 每列只存儲一種類型的數據。在數據庫的情況下,
      • 用完關閉與數據源
      • 數據文件中不要用空行

      1-15 調試

      簡單的可以多使用print或者logging打印一些信息。更高級的內容有

      ?斷點 ?單步執行 ?查看本地和全局變量的值 ?觀察變量和表達式

      1-16 不要為未來編寫代碼

      項目的變化是很頻繁,可以做一些自動化測試的技術預研,但一般不要書寫有些只供未來使用的代碼。

      1-17 讓代碼更好

      在不影響性能的情況下提高可讀性。

      1-18 測試選擇適當的語言

      語言上手的難易程序和流行度及庫支持。一般而言python因為其容易上手、是膠水語言(與其他語言調用方便)、語法簡潔、維護成本低、方便調試,是目前自動化測試占有率最高的首選語言。但是c#在windows平臺、java、c++等也有一定的市場。雖然python的占有率最高,但是一定要考慮到有些自動化測試開發可能已經有c++,go,java之類的現成的工具。

      盡量不要使用新的編程語言。 咨詢開發,可以和開發采用同一種語言,尤其是單元測試,一般為采用和開發一樣的語言。

      值得注意的是TCL(Tool Command Language)早起因為expect的命令自動化擁有一定的名聲,且testcenter、smartbits等儀表一度不支持python等主流語言。但是TCL的語法晦澀,功能弱小,是能不用就不要去用的語言。

      參考資料: 編程流行度 tiobe

      1-19 使用變量前要初始化

      這個在python中可以用mypy檢查。

      測試最佳實踐

      2-1 不要實現被測應用的功能

      因為:

      ?計算和邏輯可能很復雜,且開發已經實現了 ?計算和邏輯可能會更改 ?使用浮點數的精度可能和語言有關。

      白盒和灰盒測試中一般是知道輸入和預期結果就好,不要知道具體內部實現過程。

      例外:大數據、搜索引擎中間算法等不明確預期結果的測試,經常用python快速實現一遍,與開發用c++等語言實現得結果進行比對。

      2-2 測試的獨立性

      2-3 哪些不應該自動化

      主要是基于成本考慮

      ?難以維護的自動化。 ?盡量多做單元測試和接口測試的自動化,少做UI層的自動化 ?重復使用次數不多的自動化

      有些手工不能做的必要測試,即便自動化的成本很高,也是需要自動化。

      2-4 向開發人員尋求幫助

      開發在具體的開發方面可以值得學習,但是在自動化測試很方案方面自己定奪比較好。比如結果驗證,開發大多喜歡直接從數據庫中讀數據,但是實際上展示數據庫數據的應用也是可能出問題的。

      2-5 云測試

      云測試

      ?要測試桌面應用程序,必須打開會話,操作系統是否支持 ?硬件相關的測試云測試支持并不方便。 ?移動設備的云服務通常比較貴 ?Web應用程序的自動化比較適合在云中執行。 ?手機兼容性的測試可以考慮云,功能自動化測試則不用云比較好。

      2-6 充分利用邊界值和等價類

      2-7 錯誤與警告

      注意區分自動化測試平臺或工具的錯誤和被測應用的bug。

      2-8 使用合適的技術

      在測試自動化中使用了許多特定的方法:ODT,DDT,KDT,BDD,頁面對象,基于模型的測試等等。比如那么對KDT一般需要一部分寫測試平臺,一部分寫測試庫,一部分寫測試用例。

      2-9 特殊錯誤的驗證

      可以書寫一個臨時的測試來處理某些特定的bug。

      2-10 在寫真實測試之前做POC

      環境

      軟件測試自動化中有兩種主要的環境類型。一個創建和調試測試,另一個用于運行測試。

      3-1 為您的需要選擇一套適當的工具

      以接口自動化測試為例,一些團隊,執著的認為java是最好的語言,要用java去發HTTP請求,更有甚者,用jmeter去做接口自動化測試。不排除個別場景,這可能是合適的方式,但是通常的HTTP接口測試,用requests,代碼行數通常比java少一個數量級,還不用編譯。

      python是主流語言中的膠水語言,和其他語言配合都比較完美,通常情況下是自動化測試的首選語言,但是python未必適用所有地方,還需要其他工具和語言進行補充,不過不要太多,學習很多語言也是一件痛苦的事情。

      現在還有很多培訓機構在鼓吹UI自動化就是自動化測試的全部,一說自動化就是QTP,一問Selenium,Testcomplete之類的都不知為何物,更不用說什么junit,pytest之類的了。

      3-2 慎用自動提交bug

      配置錯誤,測試代碼錯誤經常導致測試失敗。

      測試代碼有時難以描述清楚測試步驟

      注意不要提交重復的bug。

      在沒有十足的把握的情況下可以用半自動的方式,發送郵件給測試人員,然后又測試人員提交bug。

      3-3 不要使用欺騙的結果

      避免注釋測試代碼的問題部分或改變預期的結果,以便測試不會出現失敗。

      如果實在用禁用,要知道禁用用例的比例,后面定期檢查修改。

      3-4 熟練使用工具

      比如wingide中Ctrl + \為注釋代碼的快捷鍵

      3-5 使用版本控制系統

      避免文件丟失,方便協作,盡快使用hg、git之類的。

      3-6 避免自定義表單

      本來自動化就是為了把頁面的東西盡可能走后臺,你為了取悅領導(附:大陸目前多數測試領導是不太合格的)還是什么原因,搞成形式主義了。當然數據報表是另外一回事。

      參數可以用配置文件等方式。

      3-7 自動化所有能自動化的東東

      比如:測試,代碼,測試環境,虛擬機,SQL查詢,測試數據,報告等等

      運行,日志記錄,驗證

      4-1 盡可能經常運行腳本

      4-2 測試失敗時重新執行

      當出現錯誤時應用程序運行很長一段時間,或特定情況下要盡量定位問題。

      一般而言失敗的測試先記錄下來,所有測試執行完之后在重新執行一次。

      4-3 豐富的日志內容

      錯誤日志盡量包含:預期值,實際值,地點和操作。

      參數盡量用引號等括起來,以免把包含空格的參數當成多個參數。

      4-4 截圖

      UI測試必要的時候可以截圖,同時處理好滾動。

      4-5 盡量避免比較圖像

      審查

      審查是保持碼清晰易懂的好方法,要做代碼的互相評審。

      5-1 讓非自動化者也可以看懂代碼

      
      def test_login(url, user, password, text):
          open_page(url)
          login_as(login=user, password=password)
          verify_page_opened(text)
      
      

      5-2 避免不必要的優化

      在開始執行任何優化之前如需要慎重考慮。

      通常不需要的優化工作看起來像這樣:

      1.應用程序啟動3秒鐘,然后進行5秒鐘的測試腳本填充搜索字段,還有5秒鐘搜索過程,之后腳本用1秒鐘讀取找到的數據并進行驗證。 2.測試人員開始優化讀取和驗證 3.測試人員花費一天時間進行優化并達到目標:閱讀和閱讀每次運行時間為半秒

      事實上,測試工程師的代碼生產力已經翻了一番,但是結果是他整體方案取得了約5%的收益。花一天時間是不值得的。一般需要綜合考慮,涉及腳本、被測應用、環境、執行頻率等。

      建議你在兩種情況下優化測試:

      ?如果測試運行時間過長,并且測試的應用程序是在測試執行期間空閑。 ?如果您在代碼中看到明顯的問題,請更正其中的問題。

      pandas大數據分析性能優化實例-read_csv引擎和分組等,這里是一個必要的優化實例。

      5-3 定期審查別人的代碼

      定期審查別人的新代碼。可以結對編程,甚至是同時一個人寫,一個人看。

      5-4 參與論壇和討論

      如果您是自動化領域的初學者,并且在自動化團隊中工作,那么會從你的同事那里學到很多東西。如果你是唯一的自動化工程師在公司或你的部門沒有人能幫助你?

      stackoverflow等社區常常可以找到自己問題滿意的答案。同時試圖幫助別人也可以擴展自己的眼見。

      5-5 執行重構

      重構是對現有代碼的簡化,功能和應用程序不會改變。盡管測試自動化中的代碼通常很多實際應用更簡單,有時候你仍然需要重構。

      ?您可能會發現您所支持的代碼太復雜。 ?可能有編寫新測試的請求,需要修改代碼 ?可能需要重構來改進已編寫的代碼

      重構后可以執行所有測試來驗證,也可以在公共庫等地方添加必要的單元測試。

      5-6 刪除低收益的測試

      ?測試執行了多少次; ?測試發現了多少實際問題; ?測試需要多久進行一次維護。

      參考資料

      image

      posted @ 2023-04-24 19:58  磁石空杯  閱讀(347)  評論(0)    收藏  舉報
      主站蜘蛛池模板: 起碰免费公开97在线视频 | 久久99精品国产99久久6尤物| 鄂托克前旗| 亚洲精品一区二区18禁| 亚洲综合精品香蕉久久网| 亚洲熟女综合色一区二区三区 | 日韩国产亚洲欧美成人图片| 高雄县| 视频一区视频二区在线视频| 激情综合色综合久久综合| 欧美亚洲另类 丝袜综合网| 免费看成人aa片无码视频吃奶 | 亚洲国产欧美在线看片一国产 | 人妻少妇偷人一区二区| 亚洲中文字幕无码爆乳| 人妻日韩人妻中文字幕| 国产情侣激情在线对白| 亚洲av无码精品色午夜蛋壳| 国内精品久久人妻互换| 亚洲av无码精品蜜桃| 国产亚洲综合另类色专区| 久久99精品国产麻豆婷婷| 欧美成人午夜精品免费福利| 国产日韩精品一区在线不卡| 日本大片免A费观看视频三区| 女人被狂躁c到高潮喷水一区二区| 日韩亚洲精品国产第二页| 精品乱人码一区二区二区| 久久精品伊人狠狠大香网| 一本色道久久东京热| 日韩av高清在线看片| 四虎在线成人免费观看| 无码人妻精品一区二区三| 蜜桃臀av在线一区二区| 十八禁国产一区二区三区| 激情综合网五月婷婷| 国产精品v欧美精品∨日韩 | 97精品人妻系列无码人妻| 国产午夜精品理论大片| 亚成区成线在人线免费99| 鲁丝片一区二区三区免费|