在前乙個測試子專案中的表現不錯，而後我又被調入乙個產品發布版本的回歸測試子專案中去。相比之前的測試子專案（軟體模組的功能測試），回歸測試就很不一樣了。回歸測試所執行的，都是比較基礎的測試用例，也是不管版本如何變遷也都不必要進行太多改動的測試用例。也正因為需要比較頻繁地（每乙個新的產品發布版本）執行這些測試用例，所以這些用例幾乎都有相應的測試指令碼，可以縮短測試執行時間，指令碼就是利用之前我提到過的內部工具寫成的。指令碼語言本身可以抽取一些library出來，具有一定的模組化構造，可以減少一些重複的指令碼**，但是後來我從測試自動化（ta，testautomation）的角度來看，依然是非常低級別（基礎，非編譯）的自動化實踐。
相比之前跟著導師幹活，這一次的工作回歸測試的另乙個挑戰在於，它涉及到的系統架構範圍往往不止乙個模組。之前在導師的帶領下工作，只需要按照用例中所給出的資訊，執行相應的命令即可。就算你不太明白命令中一些部分的引數該如何設計，在人機介面上執行這些命令時，它自己也能發現不合規的命令格式並且給出提示，要求你輸入正確的值。只是執行、觀察、發現錯誤、修改命令或引數、重新執行、記錄結果，還是很輕鬆的。但如今由於要測試更多的模組、更廣的範圍，需要了解的命令也逐漸地多起來，在測試中發現一些異常現象後要檢視日誌、系統狀態也需要執行一些命令，而這些命令並不在我負責測試的技術領域中，所以還得去找相關領域的測試同事、專家請教學習，或者不願意求人的話就得自己找相關文件。在此，溝通以及查閱資料或者摸索的能力就非常重要了。
只是執行測試是相對簡單而且有點枯燥的活，因為這些功能多數都是穩定的，不大會出錯。於是我就把一些時間花在思考、理解這些測試用例和指令碼上，正好回歸測試的用例中總有一些是執行時間比較長的，我就利用這些時間去查閱資料、文件，理解測試用例的設計理念，以及研究多個測試用例之間的關係，看看是不是有漏測的功能。
在當時，我們的回歸測試用例都是從現有的功能測試用例中直接篩選出來的，挑選的是其中比較基礎的、通用的測試用例，是否容易實現指令碼化也是考量的因素之一。因此，如果只是去看測試計畫中的測試用例集，難以看到全貌，不知道為何要選擇這些用例，也不知道這些用例之間有什麼特別的聯絡，它們結合在一起是否有足夠完整地覆蓋了要測試的範圍。因而，想要理解這些測試用例以及其關係，找到是否有漏測的功能，需要額外花一些功夫順藤摸瓜地檢視相關技術領域、模組的測試用例和以往的測試計畫。看一看某個測試用例在它的模組裡，是否還有其他的測試用例也在驗證相似的功能，有什麼區別，為何不選擇其他的測試用例做回歸測試，以及是否有一些應該測而沒有測的功能（這需要研究功能需求規格說明書文件才行）。研究這些問題其實是蠻有意思的事，它能夠幫助你更深刻地理解自己手中正在執行的測試用例，更能夠分辨出在執行中你對哪些輸出資訊應該保持關注，而對其他一些資訊則可以睜乙隻眼閉乙隻眼（因為有其他的測試用例會專門檢查這一塊的情況）。做到測試用例或者測試執行有重點、有針對性有著莫大的好處，專注能幫你過濾掉一些不必要關注的資訊，延緩測試過程中的緊張感，也能夠提高你對重點資訊的關注度和敏感度，更容易發現問題。
***********************************=分割線******************************==
軟體測試自動化
只有當系統的介面元素不會頻繁的變化 系統功能基本穩定，已經通過一至兩輪的手工測試，確定系統不會存在重大缺陷時，才可以考慮自動化的實施。使用自動化測試工具代替手工完成一些測試任務，現在國內主流的測試工具是loadrunner 和qtp。lr 效能測試工具 和qtp 自動化測試工具 的區別 1 lr 基...
我的自動化測試框架
參考 自動化測試框架基於page object模式，unittest框架設計，目錄結構如下 test project config 存放配置檔案 data 存放頁面元素 drivers 存放瀏覽器驅動目錄 log 存放日誌目錄 report 存放執行報告目錄，使用htmltestrunner tes...
我的自動化測試之路
因為我一直在分享自動化測試技術，所以，時常被問到 功能測試想 動化，請問應該怎麼入手？或者有哪些書推薦？那麼，接下來我就結合我的經歷聊一聊我是如何在工作中做自動化測試的。我的軟體測試職業開始和大多數最普通的測試人員一樣，一開始在一家幼兒教育平台的公司做軟體測試，公司最開始只我人一位軟體測試人員，沒有...