根據Pinch媒體數據2009年進行的研究，一個移動應用程序的平均生命周期只有30天。此后移動應用程序的數量激增，生命周期變得更短了。這些變化趨勢要求軟件質量保證團隊重新改進他們的軟件測試方法，并將之與移動應用程序開發團隊和客戶群緊密相連。客戶需要更多的應用程序和功能，因此保證移動應用程序的質量對維護現有客戶群并獲取新客戶都是必不可少的。鑒于軟件開發和質量保證（測試）的時間很短，即使有替代策略存在，軟件測試自動化從一定程度上在公司的生命周期中是必要的。
　　一家app開發公司會因為各種原因（內部和外部的都有）而決定將其測試工作自動化。不論深層原因，一旦一家公司決定將其測試工作自動化，就需要一個系統的方法來定下自動化流程的工具。測試自動化的成功很大程度上取決于所使用的工具。如今市場上有各種自動化工具，選擇正確的工具滿足公司特定的測試需求算得上是一個蠻有壓力的任務。
　　一個剛開發的產品，相對來說還是不太穩定。在那些階段，手動測試是一個快速驗證產品是否如期運行的好方法。為了驗證和確認（V&V），軟件測試員應該利用這個階段熟悉產品規格并編寫測試用例。產品規格一完成，測試員應該開始思考他們該如何將測試用例自動化了。軟件開發公司經常要在為特定短期客戶項目挑選工具并投資挑選工具和為長期項目/產品挑選工具間做出調解，以避免重新加工或后期浪費大筆費用。移動應用程序短暫的生命周期里在形成一個連貫的工具策略時提出了一個管理難題。這種情況下，基于場景的方法可以幫助管理者對連貫的需求投資負責，為他們公司的移動測試自動化做準備，并為戰術和戰略項目投資正確的工具。

 1.支持移動平臺
       無論要求規范是什么，你都需要挑選正確的工具，不僅要支持目標操作系統如iOS，Android，Windows以及它們的不同版本，還要支持底層硬件配置。質量保證團隊安排其測試工作時需要考慮許多移動應用程序特有的難題。最根本的問題之一是搞明白一個應用程序（代碼庫）如何在不同的操作系統，界面上運行。盡管移動平臺市場的玩家主要是Google和Apple，但開發者仍需要將Symbian和Windows Phone用戶考慮在內。即使是在單個平臺內，也有一堆軟件版本等因素要考慮。因此，檢查最老和最新的平臺支持版本極其重要。
       2.支持應用程序類型
一旦初始自動化工具入選，你就需要檢查可以用這些工具所管理的應用程序的類型。多數工具都是特定的不能同時支持本地，混合和web應用程序。多數移動測試進程并不是萬全之策。因此，很有可能需要在自動化流程鏈中挑選一些工具。根據被測應用程序的類型，至少80%的測試活動可以被自動化（按照帕累托定律算）。然而考慮到一堆平臺上的應用程序的功能，就需要一些特別的手動測試。使用正確的工具就可以幫助提高效率，減少成本，同時可以在部署應用程序或服務時，提供一個客觀環境來評估應用程序的質量并預測實際環境中的用戶體驗。
       3.源代碼要求
      為了獲得最佳測試質量，本地移動應用程序應該在安裝程序內隨附一些工具特定框架，這樣軟件測試員就可以向設備/仿真器發送一些指令直接用本地應用程序執行任務。多數常規瀏覽器都有它們自己的網絡驅動程序，所以測試員可以在這些特定瀏覽器網絡驅動程序的幫助下測試應用程序。在多數情況下，移動應用程序不會帶著它們的源代碼或框架被交付給測試團隊，也就是說，它們可以在不同移動平臺上模擬同樣的功能。在一些情況下，有用于iOS的App Package一類的方法，盡管該模塊并不以和擁有源訪問的流程一樣的方式提供測試覆蓋率，但它卻為測試提供比精易應用程序安裝本身更多的容量。于是源代碼和平臺框架是需要考慮在內的重要指南，因為不是總能夠獲得測試用的源代碼，尤其是當測試工作被外包給第三方時。
       4.應用程序重構要求
       移動測試自動化的另一個障礙是修改應用程序的要求，即重構使之可以被自動化工具測試。重構的技巧是能夠驗證功能被保留了。測試專業需要確保所有變化在重構前后都被驗證了。盡管將這個流程自動化沒必要，但這在隨后的回歸中或許有幫助。重構復雜的應用程序或代碼模塊是一門藝術，將這些元素自動化應該盡最大的努力。挑選的工具應該滿足在不同粒度水平交付預期結果所需的可擴展性要求；或許有必要將第三方庫包含在測試項目中，建立你的產品的測試版本或改善現有交付測試的app版本。
       5.測試腳本生成
       對于需要大量測試覆蓋的移動應用程序，創建實時測試腳本或許會提出一個極大的挑戰。盡管測試自動化大大地提高了執行效率，但這些效率提高都伴隨著巨大的成本，尤其是開發測試腳本庫以確保測試覆蓋需求的時候。自動化測試用例腳本生成工具也許能通過幫助創建關于運行需求的腳本測試場景進一步提高效率并擴大測試范圍。關于可擴展性，所挑選用來自動化生成測試腳本的工具應該要支持腳本參數。然而該方法通常受限于工具能力且無法交付和編程方法一樣的覆蓋度，它使用power coding和基本編程語言。編程選項沒有自動化測試腳本方法那么快，但是其結果更有效更靈活。因此，有必要評估可用資源以便在工具評估過程中挑選一個方法。

 6.編程語言規范
       廣泛地講，用于開發應用程序的編程語言在質量保證過程中起著重要作用。測試員經常選擇過程語言，例如Perl，Python，Ruby等來為自動化測試用例創建腳本，因為這些編程語言通常更容易學，不需要匯編（這就節省了不少時間），擁有大量用戶群和庫可供選擇以解決各種自動化難題。使用一個面向對象的編程語言開發了測試腳本時，自動化經常選用面向對象的語言，如Java，C++，.NET等，這對于解決方案的體系結構十分重要。除了選擇正確的工具和編程語言，測試員工分配也很重要。重復利用現有內部知識，經驗和技巧比采用新技巧更有效。
       7.運行時對象識別
       功能和負載測試工具有個根本區別。功能測試工具在用戶界面層進行，而負載測試工具是在協議層進行的。功能測試工具的運行時對象識別幾乎從未達到過100%。如果對象識別成功率低于50%，那么測試自動化團隊將執行這么多解決方案以擊敗測試自動化的對象。在負載測試中，這個問題并不重要。應用程序變化和它們對測試腳本中對象識別的影響對于測試自動化團隊往往是個難題。獨特的對象識別大大降低了變化的影響并簡化了測試腳本維護。你必須了解并評估怎樣在運行中使用特定工具進行對象識別，如果有可能的話，獲取特定對象以便在收集對象庫中的識別性能上輕松進行檢查。
      8.數據驅動輸入
       如今大多數app都是交互式的，需要用戶在某些時候鍵入一些東西。知道應用程序如何回應各組輸入對于將穩定有質量的產品推向市場很有必要。數據驅動測試幫助我們理解應用程序如何應對各種輸入。不是讓測試員手動將無窮的數據組合或硬-特定代碼輸入測試腳本，而是測試基礎設施框架工作自動從數據源取值，將取出的數據輸入應用程序，驗證應用程序在用另一組值重復測試前反應正確。自動化數據驅動測試極大地擴大了測試覆蓋面，同時減少了創建更多有不同變量的測試的需求。重視對數據驅動測試的使用可以確保應用程序是用來測試限制條件和無效輸入的。數據驅動測試常常是基于模型的測試的一部分，具有覆蓋廣泛輸入數據的隨機性。為了確保擁有不同數據組合的測試執行，應該要恰當管理數據源。所選測試自動化工具應該包含驅動程序并支持多種數據格式，比如平面文件，電子表格和數據庫存儲。
       9.結果和錯誤日志
       在測試用例開發和執行期間，常常有必要記錄展示更多開發人員特定信息的內容。可是對于測試經理來說，知道一個特定測試是通過還是失敗就足夠了。根據要求，或許有必要自動抓取失敗測試過程的截圖和錄像，讓開發員可以更輕易地再現問題并找出其根本原因。自動化工具也應該要有必要的過濾器來根據類型，文本，優先級，時間及其他重要屬性挖掘日志信息。允許從時間軸上的一個自動化測試運行到另一個查看日志總結并用于配置報告格式的工具也是挑選測試自動化工具時需要考慮的功能。
       10.連續測試
       連續測試方法背后的中心思想是，經常推進代碼變化并快速得到關于這些變化對現有系統的影響的反饋。一個強大的測試自動化框架應該能夠支持團隊合作和自動化測試基礎設施組件（比如：集成開發環境即IDE，測試框架，版本控制，測試配置管理，問題追蹤，報告生成等等）的集成。連續測試以及使用現有質量保證工具和技術的集成對QA流程效率非常重要。不進行連續測試就會讓缺陷有機可乘。發現了缺陷，就要在上面放更多代碼，使得對后面所發現缺陷的修復更難更貴。即刻測試變化大大減少了找出缺陷的成本，因此自動化工具應該用每個提交觸發生成并自動執行相關測試或一天中隔一段時間執行一次。此外，將測試集分解得更小，平行運行測試集，自動給正在弄已發現缺陷的代碼的開發員分配缺陷是獲得高質量結果的最便宜最快速的方法。該方法也給開發員提供了嘗試的空間，同時從回歸保護主代碼庫。如此，測試每段代碼分支都和測試主代碼一樣嚴格。這樣一個從連續集成到新分支的應用程序一旦建立就可以幫助發現兼容問題并緩解最后的集成。
       11.定價模式
       測試自動化經常被視作成本很高的一個主要原因是：自動化工作是單獨完成的，與主開發工作完全分開。有效躲開阻礙測試的設計決策的后果，開發員繼續創建幾乎無法自動化的軟件。有效的敏捷團隊（團隊中每個參與自動化測試的開發員）打破了這些限制，自動化測試進入一個開發者可以在里面檢查他們的代碼的常用庫。這樣就大大減少了測試自動化的成本。有一些免費的開源和專門的測試工具可以用來評估。選好了開源工具，就有機會檢查工具評估有多穩定以及那些工具有多快能否支持技術的最新變化。對于專門的解決方案，工具的價格是證明投資和ROI計算時需要考慮的關鍵因素之一。檢查許可模式也很重要，比如按使用次數、節點、站點許可證、有效期等支付。另一個需要重點考慮的是加載項、支持和更新的可用性以及這些功能是否需要額外花費。最后也是最重要的一點，所選工具的易用性。工具的復雜度應該和測試團隊接受新工具的能力，公司的編程能力相匹配。

本文轉自 作者：Mithun Sridharan

>>>>>查看更多測試分析相關資訊、產品

【年終促銷第二波火熱進行中，全場六折起，豪禮升級，挑戰全年最低價】

活動時間：11月1日-11月30日