APP的發展在軟體行業非常的迅速，但是APP給使用者帶來的體驗以及軟體質量的本身還是存在很多的不足。

APP測試也隨之發展起來，但是在具體的質量要求上還是沒有一定的規範要求。

借鑑前輩們的測試經驗彙總一下，日後供自己學習使用。

一個APP專案從開發到上線需要做的工作還是比較多的，大致的流程：

一、評估測試周期
二、整理測試資源
三、測試要點

            1）預測試，在正式的開始測試之前，需要對開發提測的功能進行簡單的測試，主要是為了保證測試流程可以進行下去，提高測試的效率

            2）功能測試，預測試通過之後，就要按照測試用例進行功能的測試，在確定完全提測之後，測試過程中遇到的所有問題都要進行記錄，提交到bug管理工具

            3）UI測試，UI測試這一部分相對於功能來說優先順序低一點，這部分主要涉及到UI部門的驗收，在測試的時候一切按照事先確定的UI效果圖進行。

           4）相容測試/效能測試，這部分目前還只是一個比較不受重視的部分，公司的裝置也只是一部分，效果不是太好，效能測試這一部分到目前為止我還沒有做過，該怎麼做也不是很清楚。

          5）迴歸測試，迴歸測試在整個測試的過程中可能會重複多次，因為每次的修改提交的版本都不能夠保證其它功能不能出現問題，這個是一個比較難解決的問題，一般的解決方法都是使用UI自動化測試將這個迴歸跑一次，但是並不能百分之百的保證測試的整個流程中不出現問題。從此看來自動化測試還是非常有必要出現的，要花大力氣開展工作。
        
四、測試日報
五、產品上線報告

以上是一個APP專案上線的大致流程，具體的細節問題還是需要根據實際的情況安排具體的計劃。

以下是對測試工作的內容的總結，這些都是前輩們總結的，借鑑一下參考

一、測試周期
APP的測試周期一般是兩週，可以根據專案的實際情況以及版本質量對測試周期進行適當的調整。在正式的測試開始之前應該向主管或產品經理確認專案的排期。

二、測試資源
在開始測試之前對測試的各項資源進行檢查。產品功能需求文件、產品原型圖、產品效果圖、行為統計分析文件、測試裝置等。對於一些特殊的需求要有專門的測試安排，具有秒殺專題的專案，需要規劃秒殺時間表；優惠券相關的專案需要申請新增優惠券資料；具有支付功能的專案需要提前申請支付賬戶等。

三、UI測試
1）確保原型圖和效果圖是最新的版本
2）確保產品UI設計符合領導的要求
3）所有的介面問題都以效果圖為準，如果存在體驗方面的問題需要向相關的人員詢問，最後以郵件的形式確定
4）在測試的時候測試環境中的資料是模擬資料，測試的時候要考慮正式環境下的資料可能顯示的情況

四、功能測試
1）確保功能需求文件是最新的
2）確認所有提測的軟體功能都以按照需求完成並且邏輯完全正確
3）所有的功能問題都要以需求文件為準，如果存在使用者體驗方面的問題，需要向相關的人員詢問以郵件的形式確認最終的決定。
4）對於需求中一些難以在短時間或不能實現的功能，需要向產品確認，開發的解釋不能作為功能裁定的結果，以郵件的形式確認。
5）在專案中由外部原因導致的問題，要督促客戶端與服務端進行協調儘快的解決，這些在以後的測試報告中都要寫清楚
6）所有的“延期處理、設計問題”等，這些都需要和產品確認之後才能夠決定，也要在報告中告知
7）在上線之後的測試過程中，需要釋出的一些資訊等，最好都要寫上測試二字，以標記是測試人員在進行測試以免造成影響

五、相容測試/效能測試
1）確保版本在所有的機型上都可以使用，對於使用者的使用量低於5%的機型可以不用考慮
2）對於低端效能相容機上獨有的問題，如果存在很大的技術問題，如果在排期內無法按時解決，在測試報告中需要告知，並向產品確認最終的決定，以郵件的形式
3）效能測試必須滿足硬體壓力條件下的測試需要，使用者常用的APP要在後臺執行環境中測試
4）網路響應對使用者體驗方面的效能測試，需要保證在WiFi、3G、2G網路下的切換效果。比如WiFi切換到2G環境，網路響應的速度以及切換介面

六、迴歸測試
1）軟體在最終上線之前，需要對產品做迴歸測試，測試的內容包括之前所有的測試專案
2）迴歸測試不再對細節進行測試，類似於對產品進行驗收，以客戶正常使用的角度進行測試。
3）通過迴歸測試之後，才能夠將軟體提交給產品，然後上線。

七、測試日報的內容

測試人員每天需要對當天的測試專案寫日報。
測試日報包含的內容：
1）對當前測試版本質量進行分級
2）對比較嚴重的問題進行標記，提示開發人員及時修改
3）對版本的整體情況進行評估

八、產品在上線之前測試人員給產品傳送上線報告