個人測試總結

總結個人測試知識體系：

自動化測試準備工作：

1、移動平台android端產品功能和介面測試

2、測試計畫：不同產品的計畫表，計畫要點的闡述、作用闡述、計畫項

測試用例：不同產品的測試用例，用例管理工具，用例的內容，用例的注意事項

測試過程：與開發人員的溝通注意，用例的覆蓋情況，通過與失敗標準，回歸

測試情況，測試結束標準，測試過程中用到的測試工具和方法

以功能測試為主，介面測試為輔助

功能測試主要以滿足需求為主

介面測試主要發現的問題點

測試報告：不同產品的測試報告

移動產品的自動化測試框架搭建與執行

推動並監控測試流程

優勢：2、具有一年以上手機移動端應用測試經驗者

3、自動化測試工具的開發、熟悉白盒測試、**測試優先

要做自動化，首先考考慮產品是否適合做自動化測試。這方法比較普遍的共識是從三個方面進行權衡。

軟體需求變動不頻繁

測試指令碼的穩定性決定了自動化測試的維護成本。如果軟體需求變動過於頻繁，測試人員需要根據變動的需求來更新測試用例以及相關的測試指令碼，而指令碼的維護本身就是乙個**開發的過程，需要修改、除錯，必要的時候還要修改自動化測試的框架，如果所花費的成本不低於利用其節省的測試成本，那麼自動化測試便是失敗的。

專案中的某些模組相對穩定，而某些模組需求變動性很大。我們便可對相對穩定的模組進行自動化測試，而變動較大的仍是用手工測試。

專案週期較長

由於自動化測試需求的確定、自動化測試框架的設計、測試指令碼的編寫與除錯均需要相當長的時間來完成。這樣的過程本身就是乙個測試軟體的開發過程，需要較長的時間來完成。如果專案的週期比較短，沒有足夠的時間去支援這樣乙個過程，那麼自動化測試便成為笑談。

自動化測試指令碼可重複使用

自動化測試指令碼的重複使用要從三個方面來考量，一方面所測試的專案之間是否很大的差異性（如c/s系統和b/s系統的差異）；所選擇的測試工具是否適應這種差異；最後，測試人員是否有能力開發出適應這種差異的自動化測試框架。