1、由於開發人員技術水平的不同（編碼技術和編碼規範），會導致程式碼的優劣程度不同，應用不同模組由不同人員開發導致缺陷出現率也不同。開發人員的水平也決定了軟體程式的質量，和二次開發維護的難易程度。

2、當流程出現問題時，測試發現bug越多，開發修改後出現更多bug，如何才能趨於穩定？

3、專案是要質量還是市場，如何把握產品的定位？在二次開發立項時，應該考慮功能模組和資料的問題，是否可以沿用，老版本部分功能模組與新版本的耦合性是否很大，如果很大則開發時間應比實際開發時間預算多1.5到3倍，視專案規模而定。程式碼整合，開發計劃是否在開發時計劃後期迭代過程中應把老程式碼（亂、差）進行替換優化。

4、任務分配：
    專案經理給所有人不均分配任務，每個人的能力不同，完成任務的效率和質量不同。如果A完成了，就讓未完成任務的B給A分配任務。B的任務未完成就是B的責任，不能找A的原因。B分配任務的原則要根據任務多少、任務難易程度；不能把90%的任務都分給A了，自己卻做很少，然後任務未完成就推給A責任；或是把難的任務都給A，自己做簡單的；任務的分配要與A進行溝通，如果遇到兩個人都完成困難，不能在規定時間內按時完成的應該及時上報。

5、表單重複提交：比如提現、支付，客戶端會發送多次資訊給伺服器，伺服器就響應多次，造成多次支付或提現的現象。支付寶和微信都出現過但錢未丟失，易造成使用者誤解，弱網環境造成傷害較大。

6、客戶端頁面重新整理或跳轉不成功，導致上個操作已經實現，但是無法進入到下一個操作頁面或步驟，導致的問題。比如提交付款操作後，頁面沒有跳轉而是繼續停留在當前頁面，導致使用者誤認為沒有操作成功，重複進行操作。這種問題後臺需要對同一編號訂單的狀態進行判斷，使其付款後不能二次付款操作或其他操作等。弱網環境造成的傷害，會讓使用者造成誤解。

7、總結手機測試可以用到的方法，工具，流程，分解部分業務流程形成總結。報告+文件+配置文件。（這個是啥？）

8、新老版本更新，如果業務流程也有改動，應該分析老版本業務流程對新版本的影響，比如老版本業務沒有錢包餘額功能，不支援記賬，而新版本的可以則多了這個功能後，使用者在老版本執行訂單過程中切換到新版本使用後會帶來什麼影響：1、新版本多了餘額，使用者先在老版本進行服務操作，最後在新版本進行結算操作，那麼結算後是按照老版本的流程走還是新版本的流程走？（在新版本上線後，對老版本進行釋出任務、確認完成任務的遮蔽），2、新版本多了記賬功能，那麼老版本的資料，是否要顯示到新版本的記賬當中，還是說記賬只記錄新版生成的訂單記錄。（關於更新是個有針對性的問題，就像登入一樣，看似簡單，一旦想成規模考慮的就多了，比如各種第三方登入、各個平臺登入、各個角色登入、賬號的一致性、安全性等等，更新要考慮相容性、安全性、穩定性、各個平臺等等）。市場人員只要發現一個問題，就好像這個產品快要死掉了一樣。。。。。。

9、涉及金錢交易：
    1、對賬：出賬入賬的閉環、當入賬出現問題時，出賬需要封死（出賬可能有多種情況：提現、支付、積分兌換等不然無法追溯金額流水）
    2、查賬：簡易對賬、詳細對賬
    3、策略的經常變換會導致對賬不準確或複雜話，如費率的改變需要提前做好準備（建立嘗試建立時間尺度，會提前進行版本更新）
    4、在查賬過程中，進行成功支付，查賬結束後判斷金額丟失，再次支付時進行查賬，就會查出壞賬。查賬前後應做限制，避免查賬過程中出現數據變動，導致查賬失敗

（這裡是亂寫的）

10、如何明確測試計劃，計劃中應該體現不同版本的測試重點。實際情況是每個版本的專案時間，沒有正確計算測試時間，對測試過程中的單元、整合、冒泡、系統、驗收測試進行精確定位。測試可能不是一次性完成的工作，也不是每次都對全部模組都進行測試。應該劃分模組，將模組的測試結果做封閉，程式碼做封閉，和開發進行溝通降低模組程式碼之間的耦合度。而不是在原來程式碼基礎的情況下進行修改，造成專案的冗餘度，從程式碼的架構清晰度來根除缺陷的產生。還應該尋求其他方法來輔助缺陷的產生。（事實證明很難做到）

11、用例編寫技巧：
先分類編寫有效用例，滿足需求基本功能和流程的用例
再根據基本用例延生編寫異常用例：如延遲、輸入長度限制、輸入型別限制、UI效果限制
再根據上面的用例編寫場景用例：弱網環境、伺服器部署、斷電環境、通話環境，環境的用例不用每條用例都重複，可以根據實際情況進行用例細分，比如弱網環境的退出功能就不用測試，但是支付功能或網頁互動功能等就需要測試
在寫用例時，需要根據劃分重複測試點、互動測試點、優先測試點、重要測試點等，

12、測試工作的意義：協助提高軟體質量、找bug、分析測試結果、總結專案經驗，為下個專案做經驗累積、分析測試需求，提高專案需求