准備工作：
1.明確需求：3個思考方向
a.UI頁面上增加了哪些數據
b.每個頁面都包含哪些功能
c.梳理功能，1個功能出現在哪幾個頁面（便於設計可復用的測試用例）
2.設計用例，2個思考方向：
a.1條用例連貫盡可能多的頁面
b.執行的順序：先驗證異常，再驗證正常功能操作
3.設計測試數據
a.邊界值數據展示，可集中在1條用例中，以頁面為單位進行測試。通過fiddler等工具，抓取單一頁面接口信息，把數據修改成測試數據並保存為文件。
(一邊操作，一邊創建測試數據是很浪費時間和精力的)
4.不做開發的人工代碼調試員
a.對測試版本提要求，達不到測試標准，堅決打給開發自測
（如果測試想后期輕松，最好給開發提供易於理解和操作的測試用例，並要求開發按用例自測）
測試期間：
1.測試bug
a.測試出bug先記錄，集中在某一個時間點，一次性提交（上午1次，下午1次）
2.提交bug
如果是測試APP，按以下步驟提交bug
a.遇到bug先截圖在本地
b.集中提交時，使用同步助手-時實屏幕分享，挨個截圖
c.在PC端輸入bug描述信息
d.如果有需要，把你想要開發將bug改成什么樣子(預期結果)，也寫上，示例：
bug描述：無網狀態，點擊發布 toast提示：無法連接到網絡，請稍后再試（不要打開 發布頁）
修改原因：
無網狀態仍能打開發布頁面可能會出現的問題：
1.發布失敗UI錯誤
2.重新連接網絡，數據異常隱患。
備注：有需要指遇到以下2種問題：
a.非需求bug，但影響用戶體驗的問題
b.非bug，但是冗余的功能，這些功能可能會產生bug
預期結果多多參照大廠的競品，盡量不要是自己想出來的
3.bug溝通
集中和開發溝通bug的時間。首輪測試未完成，但開發開始改bug的階段，開發會因以下問題找測試溝通。
（這會打斷測試思路和測試執行的操作，並且次數多了會影響測試的情緒）
a.開發自己無法重現
b.懷疑是機型適配問題，找測試要測試機
c.不理解 測試寫的操作步驟
這時候與開發約法三章
開發遇到上面3種情況，暫且把問題記下。在測試完成第1輪測試后，集中找測試溝通。
或者更好的辦法（更高效）是，化被動為主動，提bug過程中，把你認為操作步驟略復雜，開發可能會不清楚的問題，一 一記錄，集中主動去演示給開發。
4.UI測試
UI部分由UI設計師來確認結果，時間寶貴，時間應該花在探究有價值的問題上
心得：越是正式執行測試前的准備工作，越不能偷懶，正式測試時如果測試自己對邏輯都梳理不清楚，不但會被 開發和產品鄙視，還會拖長測試周期，原本1天就能完事，要用2天。生命不應該被這樣浪費。
5.對待常出低級錯誤的開發，態度可以強硬一點，給對方施加壓力去自測，可以減輕測試的負擔，節約測試時間
以上是我總結的在測試過程中，如何通過調整測試流程，提升測試效率。如果你有更好的想法，歡迎討論。
原創所有，轉載請注明出處。