**
ui測試：核對rp/效果圖
功能測試：核對需求文件、相容性測試、效能壓力測試， 盡快申請到正式環境下測試，後台訂單統計測試、使用者行為統計測試、傳送上線報告、回歸測試
測試資源
產品功能需求文件；
產品原型圖；
產品效果圖；
行為統計分析定義文件；
測試裝置（ios8.0-ios11；android4.0-android8.1；winphone7.1及以上；symbian 等其他。
安裝與解除安裝安全性
應用程式應能正確安裝到裝置驅動程式上
能夠在安裝裝置驅動程式上找到應用程式的相應圖示
是否包含數字簽名資訊
jad檔案和jar包中包含的所有託管屬性及其值必需是正確的
jad檔案顯示的資料內容與應用程式顯示的資料內容應一致
安裝路徑應能指定
沒有使用者的允許, 應用程式不能預先設定自動啟動
解除安裝是否安全, 其安裝進去的檔案是否全部解除安裝
解除安裝使用者使用過程中產生的檔案是否有提示
其修改的配置資訊是否復原
解除安裝是否影響其他軟體的功能
解除安裝應該移除所有的檔案
資料安全性
當將密碼或其他的敏感資料輸人到應用程式時, 其不會被儲存在裝置中, 同時密碼也不會
輸人的密碼將不以明文形式進行顯示
密碼, 信用卡明細, 或其他的敏感資料將不被儲存在它們預輸人的位置上
不同的應用程式的個人身份證或密碼長度必需至少在4一8 個數字長度之間
當應用程式處理信用卡明細, 或其他的敏感資料時, 不以明文形式將資料寫到其它單獨的
防止應用程式異常終止而又沒有側除它的臨時檔案, 檔案可能, 然後讀取這些資料資訊。
當將敏感資料輸人到應用程式時, 其不會被儲存在裝置中
備份應該加密, 恢復資料應考慮恢復過程的異常 通訊中斷等, 資料恢復後再使用前應該
應用程式應考慮系統或者虛擬機器產生的使用者提示資訊或安全替告
應用程式不能忽略系統或者虛擬機器產生的使用者提示資訊或安全警告, 更不能在安全警，利用顯示誤導資訊欺騙使用者，應用程式不應該模擬進行安全警告誤導使用者
在資料刪除之前，應用程式應當通知使用者或者應用程式提供乙個「取消」命令的操作
）「 取消」 命令操作能夠按照設計要求實現其功能
應用程式應當能夠處理當不允許應用軟體連線到個人資訊管理的情況
當進行讀或寫使用者資訊操作時, 應用程式將會向使用者傳送乙個操作錯誤的提示資訊
在沒有使用者明確許可的前提下不損壞側除個人資訊管理應用程式中的任何內容μ
應用程式讀和寫資料正確。
應用程式應當有異常保護。
如果資料庫中重要的資料正要被重寫, 應及時告知使用者
能合理地處理出現的錯誤
意外情況下應提示使用者
人機介面安全性
返回選單總保持可用
命令有優先權順序
聲音的設定不影響應用程式的功能
應用程式必需利用目標裝置適用的全屏尺寸來顯示上述內容
應用程式必需能夠處理不可預知的使用者操作, 例如錯誤的操作和同時按下多個鍵
解除安裝 直接刪除安裝資料夾解除安裝是否有提示資訊。
測試系統直接解除安裝程式是否有提示資訊。
測試解除安裝後檔案是否全部刪除所有的安裝資料夾。
解除安裝過程**現的意外情況的測試（如宕機、斷電、重啟）。
解除安裝是否支援取消功能，單擊取消後軟體解除安裝的情況 。
系統直接解除安裝ui測試，是否有解除安裝狀態進度條提示 。
ui測試
(如選單、對話方塊、視窗和其它可規控制項)布局、風格是否滿足客戶要求、文字測試的目標是確保使用者介面會通過測試物件的功能來為使用者提供相應的訪問或瀏覓功能。
導航測試
按鈕、對話方塊、列表和視窗等；或在不同的連線頁面之間需要導航
是否易於導航，導航是否直觀
是否需要搜尋引擎
導航幫助是否準確直觀
導航與頁面結構、選單、連線頁面的風格是否一致
圖形測試
橫向比較。各控制項操作方式統一
自適應介面設計，內容根據視窗大小自適應
頁面標籤風格是否統一
頁面是否美觀
頁面的應有其實際意義而要求整體有序美觀
質量要高且尺寸在設計符合要求的情況下應盡量小
介面整體使用的顏色不宜過多
資料更新
需要確定哪些地方需要提供手動重新整理，哪些地方需要自動重新整理，哪些地方需要手動+自動
確定哪些地方從後台切換回前台時需要進行資料更新。
根據業務、速度及流量的合理分配，確定哪些內容需要實時更新，哪些需要定時更新。
確定資料展示部分的處理邏輯，是每次從服務端請求，還是有快取到本地，這樣才能有
檢查有資料交換的地方，均有相應的異常處理。
定位、照相機服務
有用到相機，定位服務時，需要注意系統版本差異
有用到定位服務、照相機服務的地方，需要進行前後臺的切換測試，檢查應用是否正常。
當定位服務沒有開啟時，使用定位服務，會友好性彈出是否允許設定定位提示。當確定
測試定位、照相機服務時，需要採用真機進行測試。
測試 檢查push訊息是否按照指定的業務規則傳送
檢查不接受推送訊息時，檢查使用者不會再接收到push.
如果使用者設定了免打擾的時間段，檢查在免打擾時間段內，使用者接收不到push。
push。
當push訊息是針對登入使用者的時候，需要檢查收到的push與使用者身份是否相符，沒有
一般情況下，只對手機上最後乙個登入使用者進行訊息推送。
測試push時，需要採用真機進行測試。
測試公升級後的功能是否與需求說明一樣
測試與公升級模組相關的模組的功能是否與需求一致
公升級安裝意外情況的測試（如宕機、斷電、重啟
公升級介面的ui測試
不同作業系統間的公升級測試
使用者體驗測試
通過獨立空間和非經驗的統計復用方式去有效評價產品的體驗特性
是否有空資料介面設計，引導使用者去執行操作。
是否濫用使用者引導。
是否有不可點選的效果，如：你的按鈕此時處於不可用狀態，那麼一定要灰掉，或者拿
選單層次是否太深
互動流程分支是否太多
相關的選項是否離得很遠
一次是否載入太多的資料
介面中按鈕可點選範圍是否適中
標籤頁是否跟內容沒有從屬關係，當切換標籤的時候，內容跟著切換
操作應該有主次從屬關係
是否定義back的邏輯。涉及軟硬體互動時，back鍵應具體定義
是否有橫屏模式的設計，應用一般需要支援橫屏模式，即自適應設計
伺服器宕機或出現404、502等情況下的測試
dns、空間服務商的情況下會影響其穩定性，如：當出現網域名稱解析故障時，
api的請求很可能就會出現404錯誤，丟擲異常。這時需要對異常進行正確的處
介面測試
json格式的資料給客戶端，所以我們在服務端需要進行介面測試，確保
json內容正確，對分支、異常流有相應的返回值。此塊測試可
itest框架進行測試。最方便的是採用httpclient進行介面測試。
webdriver協議解析出要執行的操作，最後呼叫ios或者android平台上的原生測試框架完成測試
App測試流程及測試點
測試流程 ui測試 核對rp 效果圖 功能測試 核對需求文件 相容性測試 效能壓力測試，盡快申請到正式環境下測試，後台訂單統計測試 使用者行為統計測試 傳送上線報告 回歸測試 測試資源 產品功能需求文件 產品原型圖 產品效果圖 行為統計分析定義文件 測試裝置 ios8.0 ios11 android...
APP測試流程與測試點
對需求進行分析，包括業務層面和資料層面的分析 制定相應的測試計畫，確定測試策略和範圍，分配人員任務 根據人員安排，完成不同模組的測試用例的編寫 用例評審 看業務邏輯是否完整通順，用例數量是否達標，用例標題是否清晰，資料流動影響的模組 根據開發給的文件部署相關測試環境 第一輪全面執行測試用例，期間不接...
APP測試常用測試點
功能測試和業務邏輯測試，ui測試和互動測試外，1.相容性測試 android版本的相容性 4.4 4.3,4.2,4.1 5.0，5.1 6.07.0，7.1 8.0 手機品牌的相容性 相容主流手機品牌 華為，小公尺，魅族，oppo，vivo，360，錘子，一加 裝置螢幕解析度的相容性 16 9 非...