作者|藺文文
從學習到工作的轉換與思考
從自己決定實習，到作為一名測試實習生入職公司，前后只有五天時間。來到北京，一個我完全陌生的城市。初來對寒冷大風天氣的不適應，第一次上班體驗到的地鐵早高峰，入職后坐在工位看着大家在認真工作的新鮮感…這些我第一次經歷的事情，到現在都已經過去兩個月了。
從學習到工作，聽起來好像是跨越了兩個維度的事情。在我看來，工作本身也是一個不斷學習的過程，不斷遇到問題不斷解決問題，提高能力，積累經驗。在學校學習的時候，測試基本都停留在紙上談兵階段，動手操作的經驗並不多。通過兩個月的實習，對測試有了更深一步的認知，實際參與了完整項目和需求后，知道其實測試一開始就會介入，貫穿整個項目，從需求到開發到上線，越早介入越早發現不合理的地方，了解開發和產品的思路，了解整個需求，測試可以做得更好。對於一些復雜的部分，涉及到很多的數據和流轉，需要寫測試方案，准備和構造測試數據。學習的時候所有事情都是自己，是較為獨立的存在，工作之后好像事情都變得有規章了，流程清晰起來，每個方向都有負責人。如果說大學是從學校向社會過渡的重要節點，那么實習就是正式進入職場前的測試階段，有充足的時間熟悉業務，熟悉工作流程和工作內容。
實習期間學到了什么
常用軟件:
1、IDEA：開發工具
2、MIT Kerberos Ticket Manager：服務器權限管理工具
使用Kerberos登錄堡壘機首先需要申請Kerberos賬號，修改密碼后進行登錄；
3、Xshell：服務器日志查看工具
建立會話成功后連接至服務器，進入相應目錄查看日志。出現bug時，查看日志。
常用日志分類：
debug：調試時系統運行的狀態信息。
info：輸出的信息，打印程序正常的狀態信息，便於追蹤定位系統當前狀態。
warn：警告信息，系統發出警告，但是不影響運行。
Error：錯誤信息，最常用的日志信息，表示系統出現錯誤，無法運行得到正確的結果，Error屬於異常信息的一種，測試過程中要多關注異常信息，有些異常並不直接影響業務流程，但也要關注原因提出必要的改進意見。
4、Charles/Fiddler/Whistle：抓包工具
Charles，Fiddler一般需要安裝Switchhost配置hosts 。Whistle是網頁版工具，推薦安裝proxyOmega插件一起使用，whistle具體安裝使用可以閱讀開發者的文檔http://wproxy.org/whistle/ ；
5、Switchhost：代理切換工具，用於配置hosts，切換路徑；
6、Xmind：導圖工具
使用Xmind編寫用例，用例是后續測試階段的重要依據；
7、SourceTree：git的GUI工具
使用SourceTree拉取、上傳、克隆gitlab上的項目，新建，切換分支；
8、Navicat for MySQL：數據庫連接管理工具
查看數據庫數據、字段。
常用平台：
1、Beetle：代碼分支流程管理平台，git組權限申請；
2、GitLab：git平台;
3、 TAPD：項目管理平台;
4、dashen：搭建的知識共享平台;
5、環境平台系統：申請環境、部署服務;
6、 運維工單系統：Kerberos賬號申請、服務器訪問權限、VPN權限申請等等。
測試環境IOS使用whistle抓包：
前提手機和電腦在同一wifi環境下
1、申請測試環境
2、 部署服務
3、配置whistle
4、手機設置代理：測試完記得關閉代理，否則不能正常上網：
圖1. 設置手機代理
5、對於https請求需要下載安裝證書
ios10.3以后，手機下載完成后需要手動信任證書：打開手機設置-通用-關於本機-證書信任設置-信任證書，就可以正常抓包了。
6、要測試轉轉app的話，需要下載測試包。
項目流程：
圖2. 項目流程
QA參與的重要節點：
1、 需求評審
PM對需求進行講解，QA也需要參與，可以針對可行性、完整性、用戶體驗等等提出自己的疑問，后續需求和原型發生變化或更新時，PM應及時同步至TAPD；
2、 設計用例
測試用例：為了某個特殊目標編制的一組測試輸入、執行條件以及預期結果，以便測試某個程序路徑或核實是否滿足某個特定需求。
（1）如何進行用例設計
根據原型和開發文檔，針對功能、數據校驗、數據傳輸展示、頁面美觀、請求參數和響應數據等等設計測試用例，對輸入數據、處理過程以及輸出進行用例設計，具體的方法包括等價類、邊界值、場景法、錯誤推測法等。
（2）拆解用例方式
先要熟悉需求，將需求划分為多個測試點，針對測試點拆分，可根據篩選條件，結果列表等進行划分。根據輸入、處理、結果三大步驟將具體的操作步驟轉化為一條條測試用例。
（3）用例的要素
一條測試用例主要包括輸入數據、前提條件、測試步驟、預期結果。用例需要做到清晰易讀，執行力高，考慮全面避免遺漏。
3、 用例評審
一般測試工作量較大的需求需要組織會議進行用例評審。用例評審主要由QA對自己的用例進行講述，避免有疏漏的地方或者理解偏差的地方，保證項目質量，針對主流程選出冒煙用例；
4、測試
開發執行冒煙用例，通過后進行提測，正式進入測試階段。依據測試用例進行測試，執行用例過程中要及時標記用例，方便查看測試進度和復查。發現bug時提交至tapd，bug要做到簡單清晰，直擊重點。測試時可以在beetle上check代碼覆蓋率，檢查是否有遺漏的場景。
圖3. 一個bug應該包含的內容
圖3. Bug的一生
上述都是在測試服務器上，連接的線下數據庫進行測試，主要是對系統和項目進行測試，開發者修改bug。在測試環境完成測試后，進入沙箱環境進行測試，預上線，主要是主流程的走查，數據的流轉以及校驗，連接的是線上數據庫，所以要謹慎操作，防止影響線上帶來事故。
5、 上線
沙箱測試完成后進行上線。
主要參與項目和需求：
1、 搜索測試工具完善：測試組提供的工具
搜索在服務優化時，需要保證搜索結果的差異在可控范圍內，所以提供測試工具驗證差異范圍。一是主搜接口的新老策略下，召回結果的差異比；二是新舊ES索引下驗證商品數據是否一致。通過完善該測試工具，熟悉搜索推薦測試工具編寫流程，熟悉了項目各層之間的調用關系和配置文件的配置過程；
2、 基礎服務接口：zzLabel一部分接口測試
先修改host，然后初始化服務，實例化對象，最后編寫測試用例。通過該需求，熟悉編寫簡單接口測試用例，構造入參，使用斷言判斷出參是否正確；
3、 賬單3.0：資金與對賬管理系統
主要負責了商品對賬、售后對賬、提現對賬三部分的用例編寫和測試。根據測試用例，構造測試需要的數據進行測試。通過這個項目，熟悉了大項目的項目流程和測試流程，熟悉web系統功能測試用例編寫，學會定位問題。每日進行的站會要對各個方向進度進行匯總，同步進度，測試階段有阻礙的點及時拋出，優先解決。
實習的一些改進想法
在測試賬單3.0時，因為對需求不夠熟悉，加上第一次編寫較多的測試用例，很多場景沒有考慮到，用例覆蓋的不夠全面。因為前期並沒有做好這一點，由於對需求和數據不夠熟悉，導致后面測試進度較緩慢，沒有明確的測試流程。測試需求時，第一步要熟悉需求，熟悉需求關聯的業務，熟悉流程和數據，編寫覆蓋率高、簡潔清晰並且執行力高的用例，測試時按照用例順序進行測試，避免出現bug重復提交的錯誤，及時標記，明確測試進度。
發現bug時，最基本的是要定位前端還是后端，后續應該做到結合日志定位到具體代碼模塊，定位具體錯誤原因，了解RD和FE的開發規范和思路。
在測試時，也應該提高自己的溝通技巧，盡量簡單清晰的描述問題。
end