<dd id="dbjz6"><noscript id="dbjz6"></noscript></dd>
    <th id="dbjz6"></th>
      1. <dd id="dbjz6"></dd>
        1. 一名測試實習生的心路歷程

          初識測試

          不知不覺,我在測試部的實習已經快三個月了,入職第一天的場景仿佛還在昨天。在實習之前,我對測試的認識僅僅停留在一些軟件測試和測試方法的理論知識上,在學生階段項目中的測試,最多也是對自己的代碼進行一些單元測試。

          我之前所理解的測試是與開發分開,測試人員只需要“鼠標點點點”,根據需求尋找bug,不需要寫代碼、看代碼。然而,通過項目實踐,我對測試工作有了真正的認識和見解,認識到測試前置的重要性,依據W測試模型,在需求和設計階段就介入測試,盡早發現缺陷,如需求文檔、設計可行性,也需要提前編寫接口用例,例如在測試交易鏈路時,提前設計用例以覆蓋鏈路的每個分支。除此之外,還需要深入代碼的設計邏輯才能更好地測試。

          項目實踐與成長

          實習第一周,安裝測試常用軟件和平臺,做好測試前的預備工作

          1. Xmind:思維導圖軟件,用于編寫測試用例。
          2. SwitchHosts:hosts管理利器,用于管理、快速切換Hosts小工具。
          3. Fidder:抓包工具,將手機的網絡設置手動代理,連接電腦端的IP與端口,可以抓取手機訪問的URL以及一些參數。注意,要抓取https請求時需要安裝Fiddler證書,下載方式“http://電腦IP:端口”。Fidder與SwitchHosts一般配合使用。
          4. Git、SourceTree:在gitlab上下載分支,使用SourceTree切換分支。
          5. IDEA、Maven:使用IDEA配置Maven,導入gitlab上的項目。
          6. Xshell:訪問遠端的服務器,主要進行一些日志的查看,學會日志查看的相關命令,如tail、grep等。
          7. TestNG:用于單元測試,學會常用注解。例如,@Test、@BeforeTest、@AfterTest、@DataProvider。
          8. TAPD平臺:敏捷項目管理平臺,用于創建需求、項目跟進、提交bug等。
          9. 環境管理平臺:用于申請環境、管理機器、管理服務調用關系。
          10. Beetle平臺:轉轉測試部主導研發的CI/CD分支管理平臺,集成了code review、code diff、增量代碼覆蓋率等功能。

          實踐項目:我主要參與了清結算業務線配置、pop售后維修、退款等項目的測試工作。項目的流程主要分為這幾個階段:

          一名測試實習生的心路歷程

          1、熟悉需求:根據PM所出的需求文檔提前了解本期項目的背景、需求點。
          2、需求評審:主要是PM講述需求,作為測試人員,要積極參與其中,對一些模糊點或疑問點及時提出并解決,如果開發后再解決成本高。
          3、設計評審:主要是技術評審,RD會對自己的庫表、開發思路講解,測試人員需要從中評估是否符合項目的功能性與非功能需求,并評估需求的可測性,提前思考和規劃后續的測試方案。
          4、用例設計:從需求中提煉出測試點,使用xmind編寫用例,設計的用例要注意幾點:
          ①頁面:是否與原型相符、非法數據前端是否校驗、文案內容。
          ②流程:業務流轉是否正常。
          ③數據:非法數據是否校驗、傳參是否正確,數據展示處理,數據庫中記錄、值是否正確。
          做好測試前置工作——編寫接口測試用例,接口測試在接口開發完成后就可介入,不需要關注接口的內部實現邏輯,只需構造入參、校驗出參。首先需要引入pom依賴查看接口,測試過程要做到幾點:
          ④構造數據:初始化測試數據,例如我們要測試申請售后的接口

          一名測試實習生的心路歷程

          首先需要構造交易完成的訂單數據,其次需要構造申請售后需要的參數,如該接口需要一個Map,把數據通過封裝到map中即可,注意key值與RD開發時使用的key對應,避免解析后的不一致,value即為構造的數據。
          ⑤調接口:輸入接口參數,調用接口,測試接口能否成功調通。使用原子層Atomic調用接口,傳入構造的map參數。
          ⑥斷言:獲取接口返回的結果,判斷response數據是否符合預期,注意異常數據的測試。

          在做白盒測試時,要深入代碼邏輯,使測試用例做到語句覆蓋、判定覆蓋、條件覆蓋,提高測試的覆蓋率,例如,對于多分支代碼,用例需要考慮每個分支的情況,將所有if…else分支覆蓋到,對于判定條件中有“||”或者“&&”的代碼,設計的用例要覆蓋每個條件。

          一名測試實習生的心路歷程

          除此之外,在設計用例時還需要使用等價類劃分法、邊界值法等方法,比如對于錢款相關的測試,邊界值是必不可少的。
          5、用例評審:“一千個人就有一千個哈姆雷特”,每個人對同一個需求的理解不同,關注點不同,總會存在一些遺漏點,因此需要其他人員評審用例是否存在遺漏,以保證測試用例的覆蓋率,并對用例設計過程中存在的疑問點再次與PM確認。
          6、開發自測&冒煙:根據測試人員提供的冒煙用例進行自測,自測完成后項目提測,并發送提測郵件,測試人員正式介入測試。
          7、 測試階段:測試環境分為動態測試機和穩定機兩類,動態環境用來部署本次有改動的服務,穩定環境保持一套與線上一致全量服務并定時同步。測試工作主要是在動態環境上進行,需要在動態測試環境驗證和沙箱環境驗證。
          1)測試環境:環境平臺上的一套多人共享、按需求隔離的環境,連接線下數據庫,用于部署web/rpc服務。在測試環境中,首先驗證冒煙用例是否通過,然后驗證其他用例。在驗證過程中,使用TAPD平臺提交bug,對bug的復現描述要清晰,提交bug注意以下幾點要素:

          1. bug標題:言簡意賅,說明是什么bug。
          2. bug內容:bug出現的環境、重現步驟、預期結果、實際結果、截圖標明bug位置、錯誤日志截圖、logId。
          3. bug嚴重程度:致命、嚴重、一般、提示。
          4. bug 優先級:高、中、低。
          5. bug處理人:定位bug的修復人。

          在測試過程中要注意在Beetle上查看代碼的覆蓋率,以防用例未完全覆蓋修改的部分,用例全部測試完并通過后,才能進入沙箱環境驗證。
          2)沙箱環境:一套預上線環境,連接線上數據庫。沙箱驗證時要謹慎,不能對線上用戶造成影響。沙箱驗證完成后,即可進入上線階段。
          8、上線階段:在上線前要求RD梳理一下上線流程以及回滾方法。上線完成后,進行線上測試。
          9、項目復盤:回顧項目的各個階段,對過程中存在的問題進行總結、分析,吸取經驗教訓,避免出現重復錯誤。

          實踐中的成長:

          首個測試任務“清結算業務線配置”中,我主要是對web頁面進行測試,本次測試中,我熟悉了清結算業務,學會使用Fiddler抓包,以定位錯誤問題是前端還是后端,能夠使用Xshell查看一些錯誤日志,然而,在測試過程中,我忽略了一些前端校驗和樣式問題,明白了對于頁面來說,肉眼可見的不適均可能為bug。

          在“pop售后維修”的測試任務中,我熟悉了售后維修的流程,學會在IDEA編寫接口用例、查看離線任務。然而,在測試過程中,我忽略了客服仲裁后操作的鏈路是否正常,理所當然的認為只要出現過的操作都是對的,歸根結底,我認為是缺少對RD設計邏輯的研究,不了解其狀態機配置的鏈路,測試過程中沒有將每個訂單流程走到終態。針對這一問題,首先需要提前了解RD的設計邏輯,明確狀態機的鏈路、鏈路的分支,在測試各鏈路的分支時,一定要從起始狀態走到終止狀態,從而保證整個流程的正確性

          上一頁12下一頁
          ?

          留言

          chinesemature老熟妇oldman