天天看點

移動應用測試計劃

确定功能和屬性

User story: A high-level user or business requirement commonly used in Agile software development, typically consisting of one or more sentences in the everyday or business language capturing what functionality a user needs,

any non-functional criteria, and also includes acceptance criteria.

使用者故事:靈活軟體開發中常用的進階使用者或業務需求,通常由日常或業務語言中的一個或多個句子組成,用于捕獲使用者需要的功能,任何非功能性标準,還包括驗收标準。

Use case: A sequence of transactions in a dialogue between an actor and a component or system with a tangible result, where an actor can be a user or anything that can exchange information with the system.

使用案例:參與者與具有有形結果的元件或系統之間的對話中的一系列事務,其中參與者可以是使用者或可以與系統交換資訊的任何事物。

現在,從這些定義中并不明顯,但用例通常比使用者故事更大,更詳細。一個用例是個人(通常被稱為演員)如何通過一系列步驟與系統完成某項任務或實作某些目标。這些步驟包括正常工作流程中的步驟以及作為異常工作流程一部分的步驟。異常工作流包括由不允許的輸入或操作導緻的錯誤處理,但也包括非典型但允許的輸入或操作。用例的重點不僅僅是目标或任務,而且還有系統和演員之間的流程。

現在靈活流程,文檔經常不全或者在演進中,需要特别注意非功能需求。

風險分析

首先,您與項目團隊成員合作,确定系統可能出現的問題。這些是品質風險,或者使用另一個通用名稱,産品風險。對于提供步行或行車路線的地圖應用,示例包括無法正确确定位置,無法以預設機關顯示距離(例如,公制與英制),以及使用太小的字型來制作街道名稱和地标名稱難以閱讀。在基于風險的測試中,這些品質風險是潛在的測試條件。要确定哪些風險是測試條件,您和您的同僚評估每種風險的水準。将測試重要風險。與每種風險相關的測試工作取決于其風險等級。風險測試的順序也取決于其風險等級。

評估風險等級的最簡單方法是使用兩個因素:可能性和影響。包含品質風險、項目風險

品質風險示例:

  • 在登入期間,應用軟鍵盤輸入在字段中顯得非常緩慢;
  • 當使用網絡(而不是GPS)擷取位置資訊時,app無法找到位置;
  • 如果在建立帳戶期間Wi-Fi或蜂窩資料連接配接丢失,則應用程式崩潰

項目風險的一些示例:

  • 關鍵項目參與者在項目結束前退出;
  • 測試所需的裝置未及時傳遞;
  • 項目贊助商在項目期間取消項目資金。

品質風險類别

描述
競争 比不上競争對手
資料品質 處理,存儲或檢索資料時出現故障。
日期和時間處理 基于日期或基于時間的輸入/輸出、計算和事件處理。
災難處理和恢複 面對災難性事件和/或無法從此類事件中正确恢複時,不能優雅地降級。
文檔 使用者或系統管理者的操作說明失敗。
錯誤處理和恢複 由于可預見的錯誤(例如使用者輸入錯誤)而導緻失敗。
功能 特定功能無法工作,無論是給出錯誤答案還是不工作。
安裝,設定,更新,和遷移 阻止或阻礙部署系統,将資料遷移到新版本的故障,包括不必要的副作用(例如,安裝其他不受歡迎的非預期軟體,如間諜軟體,惡意軟體等)。
互操作性 主要元件,子系統或相關系統互相作用發生故障。
負載,容量 将系統擴充到預期的峰值并發使用級别時出現故障。
本地化 在特定地區失敗,包括語言,資訊,稅收和财務,營運問題,和時區。
聯網和分布式 無法處理網絡/分布式操作,包括延遲,延遲,丢失資料包/連接配接,和不可用的資源。
操作和維護 危及持續運作的故障,包括備份/恢複過程。
包裝/履行 與包裝和/或傳遞系統或産品相關的故障。
性能 無法執行(即響應時間,吞吐量,和/或資源使用率)在預期負載下的要求。
可移植性,配置和相容性 特定于不同支援平台的故障,支援的配置,配置問題,和/或與其他軟體/系統共存。
可靠性,可用性和穩定性 無法滿足合理的可用性預期,平均故障間隔時間以及從可預見的不良事件中恢複。
安全/隐私 無法保護系統和安全資料免受欺詐或惡意濫用,可用性問題,違反相關安全或隐私法規以及類似問題。
符合标準 未遵守強制性标準,公司标準和/或适用的自願标準。
狀态和事務 未能正确響應事件序列或特定事務。
使用者界面和可用性 人為因素失敗,尤其是在使用者界面。

參考資料

确定覆寫率目标

比如代碼、網絡等覆寫。

确定測試政策

測試環境、人員及能力先前版本,競争對手的應用程式,行業标準以及與性能,可靠性和可用性相關的常見使用者期望。進入退出标準等。

測試條件和範圍

如果測試人員能力足夠,能基于測試條件來确定如何進行測試。則文檔不需要過細。

回歸測試

盡量采用自動化的方式。

繼續閱讀