準備工作：
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
a.遇到bug先截圖在本地
b.集中提交時，使用同步助手-時實螢幕分享，挨個截圖
c.在pc端輸入bug描述資訊
d.如果有需要，把你想要開發將bug改成什麼樣子(預期結果)，也寫上，示例：
修改原因：
無網狀態仍能開啟發布頁面可能會出現的問題：
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.對待常出低階錯誤的開發，態度可以強硬一點，給對方施加壓力去自測，可以減輕測試的負擔，節約測試時間
移動app傳統測試流程優化
本文出自天外歸雲的 在傳統的軟體測試流程中，每一期需求從開發到上線都要經歷從需求分析與評審 測試用例評審 開發 測試 發布的流程。其中測試包含了後台測試 前端web測試 客戶端測試。後台測試又包括後台 邏輯測試 介面測試 介面壓力測試等，web端測試包含了前端頁面的ui介面測試 pc與移動端瀏覽器相...
name return value優化測試
text1.cpp 定義控制台應用程式的入口點。include stdafx.h include include include using namespace std class test test test const test t private double array 100 inline...
Schedule（優化測試）
簡單地說下題目 有n個test case，我們已經知道這n個test case的執行時間t 0 t 1 t n 1 以及每個test case成功pass的概率p 0 p 1 p n 1 現在要求設定test case的順序，使得按該順序執行這些test case的期望時間最小，輸入 line 1 ...