對于android軟件測試人員來說，想要在面試中有出色的表現，那么提前了解面試題目很重要。以下是小編幫你們整理的android軟件測試面試題，一起來學習啦。

　　android軟件測試面試題篇一

　　1、什么是手機軟件測試

　　手機作為專用的消費類電子產品需要進行以下測試：可靠性測試(對于硬件則是RQT;對于軟件則是field trial);標準符合性測試(FTA);互操作性測試(IOT);安全性測試(安規測試);強度測試等。

　　2、性能測試

　　性能測試強調長時間、重復或者高強度的進行某些操作，來驗證產品在各種極限條件下的表現。性能測試隸屬于軟件測試中的系統測試，它對軟件在集成系統中運行的性能行為進行測試，旨在及早確定和消除軟件中與構架有關的性能瓶頸。

　　3、手機中的性能測試分類

　　(1)時間相關的性能測試可分為長時間保持測試和限定時間反應測試

　　(2)次數相關的性能測試是測試終端重復穩定地進行某項功能的能力

　　(3)并發測試主要是測試終端同時進行多項業務時表現出的處理能力，例如同時進行CS域語音業務和PS域下載業務，或者在MP3播放的同時進行上網業務，以測試協議棧、操作系統和處理器對并發業務的支持能力

　　(4)負載測試主要是驗證系統的負載工作能力。例如同時進行多個ftp下載，使下行傳輸率接近極限值，觀察終端是否可以正常工作

　　4、手機性能測試的方法

　　手機性能測試的方法按照自動化程度不同可分為手工測試和自動測試。

　　手工測試主要是通過測試人員手動操作，并借助某些監測儀器和工具，來驗證手機性能

　　5、白盒測試、黑盒測試

　　白盒測試(White-box Testing，又稱邏輯驅動測試,結構測試)是把測試對象看作一個打開的盒子。利用白盒測試法進行動態測試時，需要測試軟件產品的內部結構和處理過程，不需測試軟件產品的功能。白盒測試又稱為結構測試和邏輯驅動測試。

　　任何工程產品(注意是任何工程產品)都可以使用以下兩種方法之一進行測試。

　　黑盒測試：已知產品的功能設計規格，可以進行測試證明每個實現了的功能是否符合要求。

　　白盒測試：已知產品的內部工作過程，可以通過測試證明每種內部操作是否符合設計規格要求，所有內部成分是否以經過檢查。

　　軟件的黑盒測試意味著測試要在軟件的接口處進行。這種方法是把測試對象看做一個黑盒子，測試人員完全不考慮程序內部的邏輯結構和內部特性，只依據程序的需求規格說明書，檢查程序的功能是否符合它的功能說明。因此黑盒測試又叫功能測試或數據驅動測試。黑盒測試主要是為了發現以下幾類錯誤：

　　1、是否有不正確或遺漏的功能?

　　2、在接口上，輸入是否能正確的接受?能否輸出正確的結果?

　　3、是否有數據結構錯誤或外部信息(例如數據文件)訪問錯誤?

　　4、性能上是否能夠滿足要求?

　　5、是否有初始化或終止性錯誤?

　　軟件的白盒測試是對軟件的過程性細節做細致的檢查。這種方法是把測試對象看做一個打開的盒子，它允許測試人員利用程序內部的邏輯結構及有關信息，設計或選擇測試用例，對程序所有邏輯路徑進行測試。通過在不同點檢查程序狀態，確定實際狀態是否與預期的狀態一致。因此白盒測試又稱為結構測試或邏輯驅動測試。白盒測試主要是想對程序模塊進行如下檢查：

　　1、對程序模塊的所有獨立的執行路徑至少測試一遍。

　　2、對所有的邏輯判定，取“真”與取“假”的兩種情況都能至少測一遍。

　　3、在循環的邊界和運行的界限內執行循環體。

　　4、測試內部數據結構的有效性，等等。

　　android軟件測試面試題篇二

　　問題一：為什么要在一個團隊中開展軟件測試工作?

　　任何軟件在開發過程中都會留下缺陷，帶有缺陷的軟件產品如果提交出去，可能會給公司帶來不可估量的損失，我們必須在客戶之前發現盡可能多的問題，從而保障客戶滿意。而發現問題的這個過程稱之為測試。

　　問題二：簡述你在以前的工作中做過哪些事情，比較熟悉什么。

　　此問題每個人都不一樣。我自己的答案如下。

　　我主要的工作是系統測試和自動化測試，也曾少量涉及性能測試。在系統測試中，主要是對BOSS系統的業務邏輯功能，以及軟交換系統的Class 5特性進行測試。性能測試中，主要是進行的壓力測試，在各個不同數量請求的情況下，獲取系統響應時間以及系統資源消耗情況。自動化測試主要是通過自己寫腳本以及一些第三方工具的結合來測試軟交換的特性測試。

　　問題三：你所了解的的軟件測試類型都有哪些，簡單介紹一下。

　　1. 基本功能驗證。主要是對發布的版本進行一些最主要功能的測試。英文常見叫法是Smoking Test, Basic Verification Test或者Sanity Check。

　　2. 功能測試。主要是依據需求或者需求分析文檔，對所發布的版本進行測試，看看是否滿足需求，是否出現了不必要的功能。

　　3. 單元測試。是開發人員進行的測試之一，一般是開發人員對很小的模塊，比如函數進行測試，一般來說，開發人員還需要開發相應的測試樁來進行此類測試。

　　4. 集成測試。在大型的開發過程中，軟件是模塊化進行開發的，將不同的模塊揉合在一起的話，需要進行的測試就是集成測試。

　　5. 系統測試。當軟件提交給測試組后，是對整個系統的所有功能進行測試，一般來說，功能測試是系統測試的一個部分。

　　6. 壓力測試。主要是在很大性能的情況下，這個性能已經接近了系統的極限，看看系統運轉的情況。

　　7. 負載測試。主要是用各種不同的性能去檢測系統，采集各個數據在這些性能情況下的數據。

　　8. 黑盒測試。指系統對你來說是完全不透明的，只給你留下了輸入和最終輸出，這個是功能測試的方法之一。

　　9. 灰盒測試。指在了解部分系統內部工作機制的情況下，對于系統進行的覆蓋性測試。

　　10. 白盒測試。主要是在單元測試和集成測試的情況下，開發人員已知代碼，對這一段的代碼進行全路徑的覆蓋測試。

　　11. 界面測試。主要是看用戶界面的友好性和易用性，是否有文字或者排版錯誤，是否有輸入限制等等。

　　12. 回歸測試。一般是系統發現BUG，開發人員修改后，和BUG直接相關以及可能相關的功能進行的測試。

　　13. 安裝和卸載的測試。

　　14. 恢復測試。主要是一個系統在發生了災難的情況下，從錯誤中是否容易恢復。

　　15. 兼容性測試。一個系統在不同的語言，操作系統下的系統測試。

　　16. 安全測試。系統在遇到攻擊或者類似情況下的表現。

　　17. Alpha測試。系統在給最終用戶前，測試人員在實驗室中模擬最終用戶的測試。

　　18. Beta測試。由部分最終用戶通過使用來進行的測試。

　　19. 比較測試。和其他具有相同或者類似功能的系統進行對比的測試。

　　20. 驗收測試。一般是最終用戶在接受產品前，依據自己所提出的要求進行的測試，很多情況下，驗收測試可能委托第三方機構完成。

　　問題四：測試計劃工作的目的是什么?測試計劃文檔的內容應該包括什么?其中哪些是最重要的?

　　軟件測試計劃是指導測試過程的綱領性文件。

　　包含了產品概述、測試策略、測試方法、測試區域、測試配置、測試周期、測試資源、測試交流、風險分析等內容。借助軟件測試計劃，參與測試的項目成員，尤其是測試管理人員，可以明確測試任務和測試方法，保持測試實施過程的順暢溝通，跟蹤和控制測試進度，應對測試過程中的各種變更。

　　測試計劃和測試詳細規格、測試用例之間是戰略和戰術的關系，測試計劃主要從宏觀上規劃測試活動的范圍、方法和資源配置，而測試詳細規格、測試用例是完成測試任務的具體戰術。所以其中最重要的是測試測試策略和測試方法(最好是能先評審)。

　　android軟件測試面試題篇三

　　一：你認為做好測試計劃工作的關鍵是什么?

　　1. 明確測試的目標，增強測試計劃的實用性

　　編寫軟件測試計劃得重要目的就是使測試過程能夠發現更多的軟件缺陷，因此軟件測試計劃的價值取決于它對幫助管理測試項目，并且找出軟件潛在的缺陷。因此，軟件測試計劃中的測試范圍必須高度覆蓋功能需求，測試方法必須切實可行，測試工具并且具有較高的實用性，便于使用，生成的測試結果直觀、準確

　　2. 堅持“5W”規則，明確內容與過程

　　“5W”規則指的是“What(做什么)”、“Why(為什么做)”、“When(何時做)”、“Where(在哪里)”、“How(如何做)”。利用“5W”規則創建軟件測試計劃，可以幫助測試團隊理解測試的目的(Why)，明確測試的范圍和內容(What)，確定測試的開始和結束日期(When)，指出測試的方法和工具(How)，給出測試文檔和軟件的存放位置(Where)。

　　3. 采用評審和更新機制，保證測試計劃滿足實際需求

　　測試計劃寫作完成后，如果沒有經過評審，直接發送給測試團隊，測試計劃內容的可能不準確或遺漏測試內容，或者軟件需求變更引起測試范圍的增減，而測試計劃的內容沒有及時更新，誤導測試執行人員。

　　4. 分別創建測試計劃與測試詳細規格、測試用例

　　應把詳細的測試技術指標包含到獨立創建的測試詳細規格文檔，把用于指導測試小組執行測試過程的測試用例放到獨立創建的測試用例文檔或測試用例管理數據庫中。測試計劃和測試詳細規格、測試用例之間是戰略和戰術的關系，測試計劃主要從宏觀上規劃測試活動的范圍、方法和資源配置，而測試詳細規格、測試用例是完成測試任務的具體戰術

　　二：常見的測試用例設計方法都有哪些?請分別以具體的例子來說明這些方法在測試用例設計工作中的應用。

　　1. 等價類劃分

　　劃分等價類: 等價類是指某個輸入域的子集合.在該子集合中,各個輸入數據對于揭露程序中的錯誤都是等效的.并合理地假定:測試某等價類的代表值就等于對這一類其它值的測試.因此,可以把全部輸入數據合理劃分為若干等價類,在每一個等價類中取一個數據作為測試的輸入條件,就可以用少量代表性的測試數據.取得較好的測試結果.等價類劃分可有兩種不同的情況:有效等價類和無效等價類.

　　2. 邊界值分析法

　　邊界值分析方法是對等價類劃分方法的補充。測試工作經驗告訴我,大量的錯誤是發生在輸入或輸出范圍的邊界上,而不是發生在輸入輸出范圍的內部.因此針對各種邊界情況設計測試用例,可以查出更多的錯誤.

　　使用邊界值分析方法設計測試用例,首先應確定邊界情況.通常輸入和輸出等價類的邊界,就是應著重測試的邊界情況.應當選取正好等于,剛剛大于或剛剛小于邊界的值作為測試數據,而不是選取等價類中的典型值或任意值作為測試數據.

　　3. 錯誤推測法

　　基于經驗和直覺推測程序中所有可能存在的各種錯誤, 從而有針對性的設計測試用例的方法.

　　錯誤推測方法的基本思想: 列舉出程序中所有可能有的錯誤和容易發生錯誤的特殊情況,根據他們選擇測試用例. 例如, 在單元測試時曾列出的許多在模塊中常見的錯誤. 以前產品測試中曾經發現的錯誤等, 這些就是經驗的總結. 還有, 輸入數據和輸出數據為0的情況. 輸入表格為空格或輸入表格只有一行. 這些都是容易發生錯誤的情況. 可選擇這些情況下的例子作為測試用例.

　　4. 因果圖方法

　　前面介紹的等價類劃分方法和邊界值分析方法,都是著重考慮輸入條件,但未考慮輸入條件之間的聯系, 相互組合等. 考慮輸入條件之間的相互組合,可能會產生一些新的情況. 但要檢查輸入條件的組合不是一件容易的事情, 即使把所有輸入條件劃分成等價類,他們之間的組合情況也相當多. 因此必須考慮采用一種適合于描述對于多種條件的組合,相應產生多個動作的形式來考慮設計測試用例. 這就需要利用因果圖(邏輯模型). 因果圖方法最終生成的就是判定表. 它適合于檢查程序輸入條件的各種組合情況.

　　5. 正交表分析法

　　有時候，可能因為大量的參數的組合而引起測試用例數量上的激增，同時，這些測試用例并沒有明顯的優先級上的差距，而測試人員又無法完成這么多數量的測試，就可以通過正交表來進行縮減一些用例，從而達到盡量少的用例覆蓋盡量大的范圍的可能性。

　　6. 場景分析方法

　　指根據用戶場景來模擬用戶的操作步驟，這個比較類似因果圖，但是可能執行的深度和可行性更好。

　　
看了“android軟件測試面試題”的人還看過：

1.

2.

3.

4.

5.

6.