app穩定性測試怎麼測（安卓app測試）

2023-08-08 17:45:36

一個app性能測試+ᓉ+主要測試哪些方面

如果你說的是古文，就是指被審判！一般用於犯罪嫌疑人！通常會被嚴刑逼供，很摻

如何製作移動app測試方案及詳細流程?

1.首先是測試 資源確認及準備
（1）產品需求文檔，產品原型圖 ，接口說明文檔及設計文檔應該齊全
（2）測試設備及測試工具 的準備：IOS和Android的不同年版本的真機，以及測試相關工具的準備
2.測試用例的設計及評審
（1）根據產品需求文檔，產品原型圖等文檔，設計客戶端的一般功能測試用例
（2）測試用例評審，修改與完善，評審過後著手進入正式測試階段
3. UI測試
（1）確保手頭的原型圖與效果圖為當前最新版本，符合產品經理及用戶需求
（2）測試過程一切以效果圖為準，若用戶體驗方面有建議，先以郵件的形式 與產品經理確認，確認通過後，可以正式的發出用戶體驗方面的問題
4.功能測試
（1）APP功能測試主要依據編寫的功能 測試用例進行軟體功能的遍歷
（2）涉及的測試主要包括基本功能測試，安裝，卸載，運行測試 ，異常處理（包括網絡 突然中斷或者網速 過慢，機器內存不足等異常情況的處理 ）
5.中斷測試
（1）軟體運行 過程中接電話，收簡訊，鎖屏，鬧鈴，充電，收到通知提醒後在 使用軟體，軟體任可以 正常運行
（2）運行軟體時由前臺切換到後臺，再切換回前臺 仍能繼續運行
6.兼容性及適配器測試
（1）硬體的適配 ：不同手機 廠商，硬體 性能，不同屏幕大小的適配
（2）OS版本的兼容
（3）不同屏幕解析度的適配：移動端設備的屏幕解析度多種多樣 ，如果 app沒有做合適的處理可能會顯示不好，甚至影響功能的操作
（4）兼容性測試必須放在 一定數量的真機上運行 ，由於真機類型較多，兼容性測試 的時候可以選取典型的幾種運用較多的真機進行兼容性測試
7.性能測試
（1）客戶端性能測試注重安裝卸載時間，啟動時間，頁面加載時間，主要功能佔用的床鋪，內存，流量，耗電量 等，以及與同類產品相比較是否具有優勢
（2）至於伺服器端的性能，主要利用接口對伺服器進行加壓，重點關注相應時間，吞吐量，並發數，事務通過率等
8.穩定性測試
（1）安卓app的穩定性常常使用 monkey進行測試，通過隨機事件流模擬個人操作，對檢查程序的內存溢出，空指針有很大的作用
9.檢測分析及測試報告輸出
以上各種形式的APP測試結束後，應該形成完整的分析及報告文檔，輸出給相關人員
TestBird

手機app測試有哪些工具盒方法

1、安卓黑盒測試工具
1)包括本身自帶的monkey,Monkey是Android中的一個命令行工具，可以運行在模擬器裡或實際設備中
2) robotium與appium，這些工具用於黑盒的自動化測試。可以在有源碼或者只有APK 的情況下對目標應用進行測試。提供了模仿用戶操作行為的API，比如在某個控制項上點擊，輸入Text
等等。（推舉你可以研究一下這個工具，開源的，我有資料）
2、白盒測試，Android在SDK中集成了JUnit框架。所以，你可以基於JUNIT框架進行安卓的白盒測試代碼開發
3、安卓的測試方法其實與web測試方法大多類似，只是多了一些特殊的測試場景，例如-遍歷測試、故事驅動、適配測試、電量測試、弱網測試、流量測試等
4、兼容性測試的話，一是可以利用虛擬機保證系統間的兼容性，但更多的還需要依靠真機測試，因為每個真機的上層API使用和渲染是不太一樣的
如果你想要什麼資料的話或者想一起學習研究的話，可以給我發郵件：[email protected]

如何軟體測試穩定性

運行在手機裡的軟體由於平臺和手機設備資源的限制，所以一般容易出bug的操作是功能交互或者是資源不足的情況下。在手機測試中最容易出error的測試方法是邊界值測試，交互測試，錯誤值測試，中斷測試（用另一個程序中斷當前運行的程序）和返回測試（在運行程序的過程中有多級目錄那種，不斷地返回）。
這些方法是相對容易出error的測試方法，當然所測的手機情況不同，還需要你自己多總結總結。

如何連接手機測試android應用

當當網--餘易--建築與風水,先從這書學起.我感覺比沈氏和中洲編排的較好.

如何設計Android APP測試用例

在當今競爭激烈的市場上一個APP的成功離不開一個可靠的用戶界面（UI）。因此，對功能和用戶體驗有一些特殊關注和照顧的UI的全面測試是必不可少的。當涉及到安卓平臺及其提出的獨特問題的數量（安卓就UI提出顯著挑戰）時，挑戰變得更加複雜。關鍵字「碎片化」象徵著移動應用全面測試的最大障礙，還表明了發布到市場上的所有形態、大小、配置類型的安卓設備所引起的困難。本文將介紹安卓模擬器如何能通過使用一些技巧和簡單的實踐提供覆蓋大量設備類型的廣泛測試。
簡介—分散裝置裡的測試

一般安卓開發者在其日常工作中面臨的最大挑戰之一是：終端設備和[url=]作業系統[/url]版本的範圍太廣。OpenSignal進行的一項研究表明，2013年7月市場上有超過11，828的不同安卓終端設備，所有設備在類型/大小/屏幕解析度以及特定配置方面有所不同。考慮到前一年的調查僅記錄有3，997款不同設備，這實在是一個越來越大的挑戰障礙。
圖1. 11，828 款安卓設備類型（ OpenSignal研究， 2013年7月[ 1 ] ）分布
從一個移動APP開發角度出發，定義終端設備有四個基本特徵：
1．作業系統：由「API指標」（ 1 ～18 ）專業定義的安卓作業系統版本（ 1.1～ 4.3 ），。
2．顯示器：屏幕主要是由屏幕解析度（以像素為單位），屏幕像素密度（ 以DPI為單位），和/或屏幕尺寸（以英寸為單位）定義的。
3．CPU：該「應用程式二進位接口」 （ABI ）定義CPU的指令集。這裡的主要區別是ARM和基於Intel的CPU。
4．內存：一個設備包括內存儲器（ RAM）和Dalvik 虛擬存儲器（ VM堆）的預定義的堆內存。
這是前兩個特點，作業系統和顯示器，都需要特別注意，因為他們是直接由最終用戶明顯感受，且應該不斷嚴格地被測試覆蓋。至於安卓的版本， 2013年7月市場上有八個同時運行導致不可避免的碎片的不同版本。七月，近90％這些設備中的34.1 ％正在運行Gingerbread版本（ 2.3.3-2.3.7 ），32.3 ％正在運行Jelly Bean（ 4.1.x版），23.3 ％正在運行Ice Cream Sandwich（ 4.0.3 - 4.0.4 ）。
圖2. 16款安卓版本分布（OpenSignal研究，2013年7月[1]）
考慮設備顯示器，一項TechCrunch從2013年4月進行的研究顯示，絕大多數（79.9％）有效設備正在使用尺寸為3和4.5英寸的「正常」屏幕。這些設備的屏幕密度在「MDPI」（～160 DPI），「hdpi」（～240 DPI）和「xhdpi」（～320 DPI）之間變化。也有例外， 一種只佔9.5％的設備屏幕密度低「hdpi」（～120 DPI）且屏幕小。
圖3. 常見的屏幕尺寸和密度的分布（谷歌研究，2013年4月）[2]
如果這種多樣性在質量保證過程中被忽略了，那麼絕對可以預見：bugs會潛入應用程式，然後是bug報告的風暴，最後Google Play Store中出現負面用戶評論。因此，目前的問題是：你怎麼使用合理水平的測試工作切實解決這一挑戰？定義測試用例及一個伴隨測試過程是一個應付這一挑戰的有效武器。
用例—「在哪測試」、「測試什麼」、「怎麼測試」、「何時測試」？
「在哪測試」
為了節省你測試工作上所花的昂貴時間，我們建議首先要減少之前所提到的32個安卓版本組合及代表市場上在用的領先設備屏的5-10個版本的顯示屏。選擇參考設備時，你應該確保覆蓋了足夠廣範圍的版本和屏幕類型。作為參考，您可以使用OpenSignal的調查或使用手機檢測的信息圖[3]，來幫助選擇使用最廣的設備。
為了滿足好奇心，可以從安卓文件[5]將屏幕的尺寸和解析度映射到上面數據的密度（「ldpi」，「mdpi」等）及解析度（「小的」，「標準的」，等等）上。
圖5. 多樣性及分布很高的安卓終端設備的六個例子（手機檢測研究，2013年2月）[3]
有了2013手機檢測研究的幫助，很容易就找到了代表性的一系列設備。有一件有趣的瑣事：30％印度安卓用戶的設備解析度很低只有240×320像素，如上面列表中看到的，三星Galaxy Y S5360也在其中。另外，480×800解析度像素現在最常用（上表中三星Galaxy S II中可見）。
「測試什麼」
移動APP必須提供最佳用戶體驗，以及在不同尺寸和解析度（關鍵字「響應式設計」）的各種智慧型手機和平板電腦上被正確顯示（UI測試）。與此同時，apps必須是功能性的和兼容的（兼容性測試），有儘可能多的設備規格（內存，CPU，傳感器等）。加上先前獲得的「直接」碎片化問題（關於安卓的版本和屏幕的特性）， 「環境相關的」碎片化有著舉足輕重的作用。這種作用涉及到多種不同的情況或環境，其中用戶正在自己的環境中使用的終端設備。作為一個例子，如果網絡連接不穩定，來電中斷，屏幕鎖定等情況出現，你應該慎重考慮壓力測試[4]和探索性測試以確保完美無錯。
圖6. 測試安卓設備的各個方面
有必要提前準備覆蓋app最常用功能的所有可能的測試場景。早期bug檢測和原始碼中的簡單修改，只能通過不斷的測試才能實現。
「怎麼測試」
將這種廣泛的多樣性考慮在內的一種務實方法是， 安卓模擬器 - 提供了一個可調節的工具，該工具幾乎可以模仿標準PC上安卓的終端用戶設備。簡而言之，安卓模擬器是QA流程中用各種設備配置（兼容性測試）進行連續回歸測試（用戶界面，單元和集成測試）的理想工具。探索性測試中，模擬器可以被配置到一個範圍廣泛的不同場景中。例如，模擬器可以用一種能模擬連接速度或質量中變化的方式來設定。然而，真實設備上的QA是不可缺少的。實踐中，用作參考的虛擬設備依然可以在一些小的（但對於某些應用程式來說非常重要）方面有所不同，比如安卓作業系統中沒有提供程序特定的調整或不支持耳機和藍牙。真實硬體上的性能在評價過程中發揮了自身的顯著作用，它還應該在考慮了觸摸硬體支持和設備物理形式等方面的所有可能終端設備上進行測試（可用性測試）。
「何時測試」
既然我們已經定義了在哪裡（參考設備）測試 ，測試什麼（測試場景），以及如何（ 安卓模擬器和真實設備）測試，簡述一個過程並確定何時執行哪一個測試場景就至關重要了。因此，我們建議下面的兩級流程：
1 ．用虛擬設備進行的回歸測試。
這包括虛擬參考設備上用來在早期識別出基本錯誤的連續自動化回歸測試。這裡的理念是快速地、成本高效地識別bugs。
2 ．用真實設備進行的驗收測試。
這涉及到：「策劃推廣」期間將之發布到Google Play Store前在真實設備上的密集測試（主要是手動測試），（例如，Google Play[ 5 ]中的 alpha和beta測試組） 。
在第一階段，測試自動化極大地有助於以經濟實惠的方式實現這一策略。在這一階段，只有能輕易被自動化（即可以每日執行）的測試用例才能包含在內。
在一個app的持續開發過程中，這種自動化測試為開發人員和測試人員提供了一個安全網。日常測試運行確保了核心功能正常工作，app的整體穩定性和質量由測試數據透明地反映出來，認證回歸可以輕易地與最近的變化關聯。這種測試可以很輕易地被設計並使用SaaS解決方案（如雲中的TestObject的UI移動app測試）從測試人員電腦上被記錄下來。
若且唯若這個階段已被成功執行了，這個過程才會在第二階段繼續勞動密集測試。這裡的想法是：如果核心功能通過自動測試就只投入測試資源，使測試人員能夠專注於先進場景。這個階段可能包括測試用例，例如性能測試，可用性測試，或兼容性測試。這兩種方法相結合產生了一個強大的移動apps質量保證策略[ 7 ] 。
結論 - 做對測試
用正確的方式使用，測試可以在對抗零散的安卓的鬥爭中成為一個有力的工具。一個有效的測試策略的關鍵之處在於定義手頭app的定製測試用例，並定義一個簡化測試的工作流程或過程。測試一個移動app是一個重大的挑戰，但它可以用一個結構化的方法和正確的工具集合以及專業知識被有效解決掉。