測試基本知識

1、請你分別介紹一下單元測試、集成測試、系統(tǒng)測試、驗收測試、回歸測試：

（1）單元測試：完成最小的軟件設(shè)計單元（模塊）的驗證工作，目標是確保模塊被正確的編碼，使用過程設(shè)計描述作為指南，對重要的控制路徑進行測試以發(fā)現(xiàn)模塊內(nèi)的錯誤，通常情況下是白盒的，對代碼風格和規(guī)則、程序設(shè)計和結(jié)構(gòu)、業(yè)務(wù)邏輯等進行靜態(tài)測試，及早的發(fā)現(xiàn)和解決不易顯現(xiàn)的錯誤。

（2）集成測試：通過測試發(fā)現(xiàn)與模塊接口有關(guān)的問題。目標是把通過了單元測試的模塊拿來，構(gòu)造一個在設(shè)計中所描述的程序結(jié)構(gòu)，應(yīng)當避免一次性的集成（除非軟件規(guī)模很小），而采用增量集成。

自頂向下集成：模塊集成的順序是首先集成主模塊，然后按照控制層次結(jié)構(gòu)向下進行集成，隸屬于主模塊的模塊按照深度優(yōu)先或廣度優(yōu)先的方式集成到整個結(jié)構(gòu)中去。

自底向上集成：從原子模塊開始來進行構(gòu)造和測試，因為模塊是自底向上集成的，進行時要求所有隸屬于某個給頂層次的模塊總是存在的，也不再有使用穩(wěn)定測試樁的必要。

（3）系統(tǒng)測試：是基于系統(tǒng)整體需求說明書的黑盒類測試，應(yīng)覆蓋系統(tǒng)所有聯(lián)合的部件。系統(tǒng)測試是針對整個產(chǎn)品系統(tǒng)進行的測試，目的是驗證系統(tǒng)是否滿足了需求規(guī)格的定義，找出與需求規(guī)格不相符合或與之矛盾的地方。系統(tǒng)測試的對象不僅僅包括需要測試的產(chǎn)品系統(tǒng)的軟件，還要包含軟件所依賴的硬件、外設(shè)甚至包括某些數(shù)據(jù)、某些支持軟件及其接口等。因此，必須將系統(tǒng)中的軟件與各種依賴的資源結(jié)合起來，在系統(tǒng)實際運行環(huán)境下來進行測試。

（4）回歸測試：回歸測試是指在發(fā)生修改之后重新測試先前的測試用例以保證修改的正確性。理論上，軟件產(chǎn)生新版本，都需要進行回歸測試，驗證以前發(fā)現(xiàn)和修復(fù)的錯誤是否在新軟件版本上再次出現(xiàn)。根據(jù)修復(fù)好了的缺陷再重新進行測試?；貧w測試的目的在于驗證以前出現(xiàn)過但已經(jīng)修復(fù)好的缺陷不再重新出現(xiàn)。一般指對某已知修正的缺陷再次圍繞它原來出現(xiàn)時的步驟重新測試。

（5）驗收測試：驗收測試是指系統(tǒng)開發(fā)生命周期方法論的一個階段，這時相關(guān)的用戶或獨立測試人員根據(jù)測試計劃和結(jié)果對系統(tǒng)進行測試和接收。它讓系統(tǒng)用戶決定是否接收系統(tǒng)。它是一項確定產(chǎn)品是否能夠滿足合同或用戶所規(guī)定需求的測試。驗收測試包括測試和測試。

?測試：是由用戶在開發(fā)者的場所來進行的，在一個受控的環(huán)境中進行。

?測試：由軟件的最終用戶在一個或多個用戶場所來進行的，開發(fā)者通常不在現(xiàn)場，用戶記錄測試中遇到的問題并報告給開發(fā)者，開發(fā)者對系統(tǒng)進行最后的修改，并開始準備發(fā)布最終的軟件。

2、請你回答一下單元測試、集成測試、系統(tǒng)測試、驗收測試、回歸測試這幾步中最重要的是哪一步

這些測試步驟分別在軟件開發(fā)的不同階段對軟件進行測試，我認為對軟件完整功能進行測試的系統(tǒng)測試很重要，因為此時單元測試和集成測試已完成，能夠?qū)浖泄δ苓M行功能測試，能夠覆蓋系統(tǒng)所有聯(lián)合的部件，是針對整個產(chǎn)品系統(tǒng)進行的測試，能夠驗證系統(tǒng)是否滿足了需求規(guī)格的定義，因此我認為系統(tǒng)測試很重要。

3、請回答集成測試和系統(tǒng)測試的區(qū)別，以及它們的應(yīng)用場景主要是什么？

區(qū)別：

（1）計劃和用例編制的先后順序：從V模型來講，在需求階段就要制定系統(tǒng)測試計劃和用例，HLD的時候做集成測試計劃和用例，有些公司的具體實踐不一樣，但是順序肯定是先做系統(tǒng)測試計劃用例，再做集成。

（2）用例的粒度：系統(tǒng)測試用例相對很接近用戶接受測試用例，集成測試用例比系統(tǒng)測試用例更詳細，而且對于接口部分要重點寫，畢竟要集成各個模塊或者子系統(tǒng)。

（3）執(zhí)行測試的順序：先執(zhí)行集成測試，待集成測試出的問題修復(fù)之后，再做系統(tǒng)測試。

應(yīng)用場景：

（1）集成測試：完成單元測試后，各模塊聯(lián)調(diào)測試；集中在各模塊的接口是否一致、各模塊間的數(shù)據(jù)流和控制流是否按照設(shè)計實現(xiàn)其功能、以及結(jié)果的正確性驗證等等；可以是整個產(chǎn)品的集成測試，也可以是大模塊的集成測試；集成測試主要是針對程序內(nèi)部結(jié)構(gòu)進行測試，特別是對程序之間的接口進行測試。集成測試對測試人員的編寫腳本能力要求比較高。測試方法一般選用黑盒測試和白盒測試相結(jié)合。

（2）系統(tǒng)測試：針對整個產(chǎn)品的全面測試，既包含各模塊的驗證性測試（驗證前兩個階段測試的正確性）和功能性（產(chǎn)品提交個用戶的功能）測試，又包括對整個產(chǎn)品的健壯性、安全性、可維護性及各種性能參數(shù)的測試。系統(tǒng)測試測試軟件《需求規(guī)格說明書》中提到的功能是否有遺漏，是否正確的實現(xiàn)。做系統(tǒng)測試要嚴格按照《需求規(guī)格說明書》，以它為標準。測試方法一般都使用黑盒測試法。

4、請說一說黑盒與白盒的測試方法

黑盒測試：

黑盒測試也稱功能測試或數(shù)據(jù)驅(qū)動測試，它是在已知產(chǎn)品所應(yīng)具有的功能，通過測試來檢測每個功能是否都能正常使用，在測試時，把程序看作一個不能打開的黑盆子，在完全不考慮程序內(nèi)部結(jié)構(gòu)和內(nèi)部特性的情況下，測試者在程序接口進行測試，它只檢查程序功能是否按照需求規(guī)格說明書的規(guī)定正常使用，程序是否能適當?shù)亟邮蛰斎霐?shù)鋸而產(chǎn)生正確的輸出信息，并且保持外部信息（如數(shù)據(jù)庫或文件）的完整性。

“黑盒”法著眼于程序外部結(jié)構(gòu)、不考慮內(nèi)部邏輯結(jié)構(gòu)、針對軟件界面和軟件功能進行測試。“黑盒”法是窮舉輸入測試，只有把所有可能的輸入都作為測試情況使用，才能以這種方法查出程序中所有的錯誤。實際上測試情況有無窮多個，因此不僅要測試所有合法的輸入，而且還要對那些不合法但是可能的輸入進行測試。

常用的黑盒測試方法有：等價類劃分法；邊界值分析法；因果圖法；場景法；正交實驗設(shè)計法；判定表驅(qū)動分析法；錯誤推測法；功能圖分析法。

白盒測試：

白盒測試也稱為結(jié)構(gòu)測試或邏輯驅(qū)動測試，是針對被測單元內(nèi)部是如何進行工作的測試。它根據(jù)程序的控制結(jié)構(gòu)設(shè)計測試用例，主要用于軟件或程序驗證。白盒測試法檢查程序內(nèi)部邏輯結(jié)構(gòu)，對所有的邏輯路徑進行測試，是一種窮舉路徑的測試方法，但即使每條路徑都測試過了，但仍然有可能存在錯誤。因為：窮舉路徑測試無法檢查出程序本身是否違反了設(shè)計規(guī)范，即程序是否是一個錯誤的程序；窮舉路徑測試不可能檢查出程序因為遺漏路徑而出錯；窮舉路徑測試發(fā)現(xiàn)不了一些與數(shù)據(jù)相關(guān)的錯誤。

白盒測試需要遵循的原則有：

（1）保證一個模塊中的所有獨立路徑至少被測試一次；

（2）所有邏輯值均需要測試真（true）和假（false）；兩種情況；

（3）檢查程序的內(nèi)部數(shù)據(jù)結(jié)構(gòu)，保證其結(jié)構(gòu)的有效性；

（4）在上下邊界及可操作范圍內(nèi)運行所有循環(huán)。

常用白盒測試方法：

靜態(tài)測試：不用運行程序的測試，包括代碼檢查、靜態(tài)結(jié)構(gòu)分析、代碼質(zhì)量度量、文檔測試等等，它可以由人工進行，充分發(fā)揮人的邏輯思維優(yōu)勢，也可以借助軟件工具（Fxcop）自動進行。

動態(tài)測試：需要執(zhí)行代碼，通過運行程序找到問題，包括功能確認與接口測試、覆蓋率分析、性能分析、內(nèi)存分析等。

白盒測試中的邏輯覆蓋包括語句覆蓋、判定覆蓋、條件覆蓋、判定/條件覆蓋、條件組合覆蓋和路徑覆蓋。六種覆蓋標準發(fā)現(xiàn)錯誤的能力呈由弱到強的變化：

（1）語句覆蓋每條語句至少執(zhí)行一次。

（2）判定覆蓋每個判定的每個分支至少執(zhí)行一次。

（3）條件覆蓋每個判定的每個條件應(yīng)取到各種可能的值。

（4）判定/條件覆蓋同時滿足判定覆蓋條件覆蓋。

（5）條件組合覆蓋每個判定中各條件的每一種組合至少出現(xiàn)一次。

（6）路徑覆蓋使程序中每一條可能的路徑至少執(zhí)行一次。

5、請說一下手動測試與自動化測試的優(yōu)缺點

手工測試缺點：

（1）重復(fù)的手工回歸測試，代價昂貴、容易出錯。

（2）依賴于軟件測試人員的能力。

手工測試優(yōu)點：

（1）測試人員具有經(jīng)驗和對錯誤的猜測能力。

（2）測試人員具有審美能力和心理體驗。

（3）測試人員具有是非判斷和邏輯推理能力。

自動化測試的優(yōu)點：

（1）對程序的回歸測試更方便。這可能是自動化測試最主要的任務(wù)，特別是在程序修改比較頻繁時，效果是非常明顯的。由于回歸測試的動作和用例是完全設(shè)計好的，測試期望的結(jié)果也是完全可以預(yù)料的，將回歸測試自動運行，可以極大提高測試效率，縮短回歸測試時間。

（2）可以運行更多更繁瑣的測試。自動化的一個明顯的好處是可以在較少的時間內(nèi)運行更多的測試。

（3）可以執(zhí)行一些手工測試困難或不可能進行的測試。比如，對于大量用戶的測試，不可能同時讓足夠多的測試人員同時進行測試，但是卻可以通過自動化測試模擬同時有許多用戶，從而達到測試的目的。

（4）更好地利用資源。將繁瑣的任務(wù)自動化，可以提高準確性和測試人員的積極性，將測試技術(shù)人員解脫出來投入更多精力設(shè)計更好的測試用例。有些測試不適合于自動測試，僅適合于手工測試，將可自動測試的測試自動化后，可以讓測試人員專注于手工測試部分，提高手工測試的效率。

（5）測試具有一致性和可重復(fù)性。由于測試是自動執(zhí)行的，每次測試的結(jié)果和執(zhí)行的內(nèi)容的一致性是可以得到保障的，從而達到測試的可重復(fù)的效果。

（6）測試的復(fù)用性。由于自動測試通常采用腳本技術(shù)，這樣就有可能只需要做少量的甚至不做修改，實現(xiàn)在不同的測試過程中使用相同的用例。

（7）增加軟件信任度。由于測試是自動執(zhí)行的，所以不存在執(zhí)行過程中的疏忽和錯誤，完全取決于測試的設(shè)計質(zhì)量。一旦軟件通過了強有力的自動測試后，軟件的信任度自然會增加。

自動化測試的缺點：

（1）不能取代手工測試

（2）手工測試比自動測試發(fā)現(xiàn)的缺陷更多

（3）對測試質(zhì)量的依賴性極大

（4）測試自動化不能提高有效性

（5）測試自動化可能會制約軟件開發(fā)。由于自動測試比手動測試更脆弱，所以維護會受到限制，從而制約軟件的開發(fā)。

（6）工具本身并無想像力

6、你覺得自動化測試有什么意義，都需要做些什么

自動化測試的意義在于

（1）可以對程序的新版本自動執(zhí)行回歸測試

（2）可以執(zhí)行手工測試困難或者不可能實現(xiàn)的測試，如壓力測試，并發(fā)測試，

（3）能夠更好的利用資源，節(jié)省時間和人力

執(zhí)行自動化測試之前首先判斷這個項目是不是和推廣自動化測試，然后對項目做需求分析，指定測試計劃，搭建自動化測試框架，設(shè)計測試用例，執(zhí)行測試，評估

7、請你回答一下測試的相關(guān)流程是什么？

測試最規(guī)范的過程如下

需求測試->概要設(shè)計測試->詳細設(shè)計測試->單元測試->集成測試->系統(tǒng)測試->驗收測試

8、請你說一下如何寫測試用例

（1）測試人員盡早介入，徹底理解清楚需求，這個是寫好測試用例的基礎(chǔ)

（2）如果以前有類似的需求，可以參考類似需求的測試用例，然后還需要看類似需求的bug情況

（3）清楚輸入、輸出的各種可能性，以及各種輸入的之間的關(guān)聯(lián)關(guān)系，理解清楚需求的執(zhí)行邏輯，通過等價類、邊界值、判定表等方法找出大部分用例

（4）找到需求相關(guān)的一些特性，補充測試用例

（5）根據(jù)自己的經(jīng)驗分析遺漏的測試場景

（6）多總結(jié)類似功能點的測試點，才能夠?qū)懗鲑|(zhì)量越來越高的測試用例

（7）書寫格式一定要清晰

9、請問你覺得測試項目具體工作是什么？

搭建測試環(huán)境——撰寫測試用例——執(zhí)行測試用例——寫測試計劃，測試報告——測試，并提交BUG表單——跟蹤bug修改情況——執(zhí)行自動化測試，編寫腳本，執(zhí)行，分析，報告——進行性能測試，壓力測試等其他測試，執(zhí)行，分析，調(diào)優(yōu)，報告

10、請你說一說測試用例的邊界

邊界值分析法就是對輸入或輸出的邊界值進行測試的一種黑盒測試方法。通常邊界值分析法是作為對等價類劃分法的補充，這種情況下，其測試用例來自等價類的邊界。

常見的邊界值：

（1）對16-bit 的整數(shù)而言 32767 和 -32768 是邊界

（2）屏幕上光標在最左上、最右下位置

（3）報表的第一行和最后一行

（4）數(shù)組元素的第一個和最后一個

（5）循環(huán)的第 0 次、第 1 次和倒數(shù)第 2 次、最后一次

11、請你說一下軟件質(zhì)量的六個特征

按照軟件質(zhì)量國家標準GB-T8566--2001G，軟件質(zhì)量可以用下列特征來評價：

（1）功能特征：與一組功能及其指定性質(zhì)有關(guān)的一組屬性，這里的功能是滿足明確或隱含的需求的那些功能。

（2）可靠特征：在規(guī)定的一段時間和條件下，與軟件維持其性能水平的能力有關(guān)的一組屬性。

（3）易用特征：由一組規(guī)定或潛在的用戶為使用軟件所需作的努力和所作的評價有關(guān)的一組屬性。

（4）效率特征：與在規(guī)定條件下軟件的性能水平與所使用資源量之間關(guān)系有關(guān)的一組屬性。

（5）可維護特征：與進行指定的修改所需的努力有關(guān)的一組屬性。

（6）可移植特征：與軟件從一個環(huán)境轉(zhuǎn)移到另一個環(huán)境的能力有關(guān)的一組屬性。

12、請你說一下設(shè)計測試用例的方法

黑盒測試：

（1）等價類劃分

等價類劃分是將系統(tǒng)的輸入域劃分為若干部分，然后從每個部分選取少量代表性數(shù)據(jù)進行測試。等價類可以劃分為有效等價類和無效等價類，設(shè)計測試用例的時候要考慮這兩種等價類。

（2）邊界值分析法

邊界值分析法是對等價類劃分的一種補充，因為大多數(shù)錯誤都在輸入輸出的邊界上。邊界值分析就是假定大多數(shù)錯誤出現(xiàn)在輸入條件的邊界上，如果邊界附件取值不會導致程序出錯，那么其他取值出錯的可能性也就很小。

邊界值分析法是通過優(yōu)先選擇不同等價類間的邊界值覆蓋有效等價類和無效等價類來更有效的進行測試，因此該方法要和等價類劃分法結(jié)合使用。

（3）正交試驗法

正交是從大量的試驗點中挑選出適量的、有代表性的點。正交試驗設(shè)計是研究多因素多水平的一種設(shè)計方法，他是一種基于正交表的高效率、快速、經(jīng)濟的試驗設(shè)計方法。

（4）狀態(tài)遷移法

狀態(tài)遷移法是對一個狀態(tài)在給定的條件內(nèi)能夠產(chǎn)生需要的狀態(tài)變化，有沒有出現(xiàn)不可達的狀態(tài)和非法的狀態(tài)，狀態(tài)遷移法是設(shè)計足夠的用例達到對系統(tǒng)狀態(tài)的覆蓋、狀態(tài)、條件組合、狀態(tài)遷移路徑的覆蓋。

（5）流程分析法

流程分析法主要針對測試場景類型屬于流程測試場景的測試項下的測試子項進行設(shè)計，這是從白盒測試中路徑覆蓋分析法借鑒過來的一種很重要的方法。

（6）輸入域測試法

輸入域測試法是針對輸入會有各種各樣的輸入值的一個測試，他主要考慮?極端測試、中間范圍測試，特殊值測試 。

（7）輸出域分析法

輸出域分析法是對輸出域進行等價類和邊界值分析，確定是要覆蓋的輸出域樣點，反推得到應(yīng)該輸入的輸入值，從而構(gòu)造出測試用例，他的目的是為了達到輸出域的等價類和邊界值覆蓋。

（8）判定表分析法

判定表是分析和表達多種輸入條件下系統(tǒng)執(zhí)行不同動作的工具，他可以把復(fù)雜的邏輯關(guān)系和多種條件組合的情況表達的即具體又明確；

（9）因果圖法

因果圖是用于描述系統(tǒng)輸入輸出之間的因果關(guān)系、約束關(guān)系。因果圖的繪制過程是對被測系統(tǒng)的外部特征的建模過程，根據(jù)輸入輸出間的因果圖可以得到判定表，從而規(guī)劃出測試用例。

（10）錯誤猜測法

錯誤猜測法主要是針對系統(tǒng)對于錯誤操作時對于操作的處理法的猜測法，從而設(shè)計測試用例

（11）異常分析法

異常分析法是針對系統(tǒng)有可能存在的異常操作，軟硬件缺陷引起的故障進行分析，分析發(fā)生錯誤時系統(tǒng)對于錯誤的處理能力和恢復(fù)能力依此設(shè)計測試用例。

白盒測試：

白盒測試也稱為結(jié)構(gòu)測試或邏輯驅(qū)動測試，是針對被測單元內(nèi)部是如何進行工作的測試。它根據(jù)程序的控制結(jié)構(gòu)設(shè)計測試用例，主要用于軟件或程序驗證。白盒測試法檢查程序內(nèi)部邏輯結(jié)構(gòu)，對所有的邏輯路徑進行測試，是一種窮舉路徑的測試方法，但即使每條路徑都測試過了，但仍然有可能存在錯誤。因為：窮舉路徑測試無法檢查出程序本身是否違反了設(shè)計規(guī)范，即程序是否是一個錯誤的程序；窮舉路徑測試不可能檢查出程序因為遺漏路徑而出錯；窮舉路徑測試發(fā)現(xiàn)不了一些與數(shù)據(jù)相關(guān)的錯誤。

白盒測試需要遵循的原則有：

（1）保證一個模塊中的所有獨立路徑至少被測試一次；

（2）所有邏輯值均需要測試真（true）和假（false）；兩種情況；

（3）檢查程序的內(nèi)部數(shù)據(jù)結(jié)構(gòu)，保證其結(jié)構(gòu)的有效性；

（4）在上下邊界及可操作范圍內(nèi)運行所有循環(huán)。

常用白盒測試方法：

靜態(tài)測試：不用運行程序的測試，包括代碼檢查、靜態(tài)結(jié)構(gòu)分析、代碼質(zhì)量度量、文檔測試等等，它可以由人工進行，充分發(fā)揮人的邏輯思維優(yōu)勢，也可以借助軟件工具（Fxcop）自動進行。

動態(tài)測試：需要執(zhí)行代碼，通過運行程序找到問題，包括功能確認與接口測試、覆蓋率分析、性能分析、內(nèi)存分析等。

白盒測試中的邏輯覆蓋包括語句覆蓋、判定覆蓋、條件覆蓋、判定/條件覆蓋、條件組合覆蓋和路徑覆蓋。六種覆蓋標準發(fā)現(xiàn)錯誤的能力呈由弱到強的變化：

（1）語句覆蓋每條語句至少執(zhí)行一次。

（2）判定覆蓋每個判定的每個分支至少執(zhí)行一次。

（3）條件覆蓋每個判定的每個條件應(yīng)取到各種可能的值。

（4）判定/條件覆蓋同時滿足判定覆蓋條件覆蓋。

（5）條件組合覆蓋每個判定中各條件的每一種組合至少出現(xiàn)一次。

（6）路徑覆蓋使程序中每一條可能的路徑至少執(zhí)行一次。

13、請你說一下app性能測試的指標

（1）內(nèi)存：內(nèi)存消耗測試節(jié)點的設(shè)計目標是為了讓應(yīng)用不占用過多的系統(tǒng)資源，且及時釋放內(nèi)存，保障整個系統(tǒng)的穩(wěn)定性。當然關(guān)于內(nèi)存測試，在這里我們需要引入幾個概念：空閑狀態(tài)、中等規(guī)格、滿規(guī)格。

空閑狀態(tài)指打開應(yīng)用后，點擊home鍵讓應(yīng)用后臺運行，此時應(yīng)用處于的狀態(tài)叫做空閑；中等規(guī)格和滿規(guī)格指的是對應(yīng)用的操作時間的間隔長短不一，中等規(guī)格時間較長，滿規(guī)格時間較短。

內(nèi)存測試中存在很多測試子項，清單如下：

l? 空閑狀態(tài)下的應(yīng)用內(nèi)存消耗；

l? 中等規(guī)格狀態(tài)下的應(yīng)用內(nèi)存消耗；

l? 滿規(guī)格狀態(tài)下的應(yīng)用內(nèi)存消耗；

l? 應(yīng)用內(nèi)存峰值；

l? 應(yīng)用內(nèi)存泄露；

l? 應(yīng)用是否常駐內(nèi)存；

l? 壓力測試后的內(nèi)存使用。

（2）CPU：

使用Android提供的view plaincopy在CODE上查看代碼片派生到我的代碼片

adbshell dumpsys CPUinfo |grep packagename >/address/CPU.txt來獲??；

使用top命令view plaincopy在CODE上查看代碼片派生到我的代碼片

adbshell top |grep packagename>/address/CPU.txt來獲取。

（3）流量：

網(wǎng)絡(luò)流量測試是針對大部分應(yīng)用而言的，可能還有部分應(yīng)用會關(guān)注網(wǎng)速、弱網(wǎng)之類的測試。

流量測試包括以下測試項：

l? 應(yīng)用首次啟動流量提示；

l? 應(yīng)用后臺連續(xù)運行2小時的流量值；

l? 應(yīng)用高負荷運行的流量峰值。

（4）電量：

l? 測試手機安裝目標APK前后待機功耗無明顯差異；

l? 常見使用場景中能夠正常進入待機，待機電流在正常范圍內(nèi)；

l? 長時間連續(xù)使用應(yīng)用無異常耗電現(xiàn)象。

（5）啟動速度：

l? 第一類：首次啟動--應(yīng)用首次啟動所花費的時間；

l? 第二類：非首次啟動--應(yīng)用非首次啟動所花費的時間；

l? 第三類：應(yīng)用界面切換--應(yīng)用界面內(nèi)切換所花費的時間。

（6）滑動速度、界面切換速度

（7）與服務(wù)器交互的網(wǎng)絡(luò)速度

14、請你說一說bug的周期，以及描述一下不同類別的bug

（1）New:（新的）

當某個“bug”被第一次發(fā)現(xiàn)的時候，測試人員需要與項目負責人溝通以確認發(fā)現(xiàn)的的確是一個bug，如果被確認是一個bug，就將其記錄下來，并將bug的狀態(tài)設(shè)為New。

（2）Assigned（已指派的）

當一個bug被指認為New之后，將其反饋給開發(fā)人員，開發(fā)人員將確認這是否是一個bug，如果是，開發(fā)組的負責人就將這個bug指定給某位開發(fā)人員處理，并將bug的狀態(tài)設(shè)定為“Assigned”。

（3）Open（打開的）

一旦開發(fā)人員開始處理bug的時候，他（她）就將這個bug的狀態(tài)設(shè)置為“Open”，這表示開發(fā)人員正在處理這個“bug”。

（4）Fixed（已修復(fù)的）

當開發(fā)人員進行處理（并認為已經(jīng)解決）之后，他就可以將這個bug的狀態(tài)設(shè)置為“Fixed”并將其提交給開發(fā)組的負責人，然后開發(fā)組的負責人將這個bug返還給測試組。

（5）Pending?Reset（待在測試的）

當bug被返還到測試組后，我們將bug的狀態(tài)設(shè)置為Pending Reset。

（6）Reset(再測試)

測試組的負責人將bug指定給某位測試人員進行再測試，并將bug的狀態(tài)設(shè)置為“Reset”。

（7）Closed（已關(guān)閉的）

如果測試人員經(jīng)過再次測試之后確認bug?已經(jīng)被解決之后，就將bug的狀態(tài)設(shè)置為“Closed”。

（8）Reopen（再次打開的）

如果經(jīng)過再次測試發(fā)現(xiàn)bug（指bug本身而不是包括因修復(fù)而引發(fā)的新bug）仍然存在的話，測試人員將bug再次傳遞給開發(fā)組，并將bug的狀態(tài)設(shè)置為“Reopen”

（9）Pending?Reject（拒絕中）

如果測試人員傳遞到開發(fā)組的bug被開發(fā)人員認為是正常行為而不是bug時，這種情況下開發(fā)人員可以拒絕，并將bug的狀態(tài)設(shè)置為“Pending?Reject”

（10）Rejected(被拒絕的)

測試組的負責人接到上述bug的時候，如果他（她）發(fā)現(xiàn)這是產(chǎn)品說明書中定義的正常行為或者經(jīng)過與開發(fā)人員的討論之后認為這并不能算作bug的時候，開發(fā)組負責人就將這個bug的狀態(tài)設(shè)置為“Rejected”。

（11）Postponed（延期）

有些時候，對于一些特殊的bug的測試需要擱置一段時間，事實上有很多原因可能導致這種情況的發(fā)生，比如無效的測試數(shù)據(jù)，一些特殊的無效的功能等等，在這種情況下，bug的狀態(tài)就被設(shè)置為“Postponed”。

不同類別的bug：

l? Bug類型

l? 代碼錯誤

l? 界面優(yōu)化

l? 設(shè)計缺陷

l? 配置相關(guān)

l? 安裝部署

l? 安全相關(guān)

l? 性能問題

l? 標準規(guī)范

l? 測試腳本

l? 其他

15、請你說一說web測試和app測試的不同點

（1）系統(tǒng)架構(gòu)方面：

l? web項目，一般都是b/s架構(gòu)，基于瀏覽器的

l? app項目，則是c/s的，必須要有客戶端，用戶需要安裝客戶端。

web測試只要更新了服務(wù)器端，客戶端就會同步會更新。App項目則需要客戶端和服務(wù)器都更新。

（2）性能方面:

l? web頁面主要會關(guān)注響應(yīng)時間

l? 而app則還需要關(guān)心流量、電量、CPU、GPU、Memory這些。

l? 它們服務(wù)端的性能沒區(qū)別，都是一臺服務(wù)器。

（3）兼容方面：

l? web是基于瀏覽器的，所以更傾向于瀏覽器和電腦硬件，電腦系統(tǒng)的方向的兼容

l? app測試則要看分辨率，屏幕尺寸，還要看設(shè)備系統(tǒng)。

l? web測試是基于瀏覽器的所以不必考慮安裝卸載。

l? 而app是客戶端的，則必須測試安裝、更新、卸載。除了常規(guī)的安裝、更新、卸載還要考慮到異常場景。包括安裝時的中斷、弱網(wǎng)、安裝后刪除安裝文件 。

l? 此外APP還有一些專項測試：如網(wǎng)絡(luò)、適配性。

16、請問你了解什么測試方法

等價類劃分，邊界值分析，錯誤推測，因果圖法，邏輯覆蓋法，程序插樁技術(shù)，基本路徑法，符號測試，錯誤驅(qū)動測試

17、請問黑盒測試和白盒測試有哪些方法

l? 黑盒測試方法有等價類劃分，邊界值分析，錯誤推測，因果圖法

l? 白盒測試方法有邏輯覆蓋法，程序插樁技術(shù)，基本路徑法，符號測試，錯誤驅(qū)動測試

18、請問你怎么看待測試，知道哪些測試的類型，有用過哪些測試方法？

l? 測試是軟件開發(fā)中不可或缺的一環(huán)，測試通過經(jīng)濟，高效的方法，捕捉軟件中的錯誤，從而達到保重軟件內(nèi)在質(zhì)量的目的。

l? 測試分為功能測試和非功能測試，非功能測試又可以分為性能測試、壓力測試、容量測試、健壯性測試、安全性測試、可靠性測試、恢復(fù)性測試、備份測試、協(xié)議測試、兼容性測試、可用性測試、配置測試、GUI測試。

l? 測試方法用過等價劃分法、邊值分析法、錯誤推測法、因果圖法。

19、請問你怎么測試網(wǎng)絡(luò)協(xié)議

協(xié)議測試包括四種類型的測試

（1）一致性測試：檢測協(xié)議實現(xiàn)本身與協(xié)議規(guī)范的符合程度

（2）、互操作性測試：基于某一協(xié)議檢測不同協(xié)議實現(xiàn)間互操作互通信的能力

（3）性能測試：檢測協(xié)議實現(xiàn)的性能指標，比如數(shù)據(jù)傳輸速度，連接時間，執(zhí)行速度，吞吐量，并發(fā)度，

（4）健壯性測試：檢測協(xié)議是現(xiàn)在各種惡劣環(huán)境下運行的能力，比如注入干擾報文，通信故障，信道被切斷

20、請你說一說簡單用戶界面登陸過程都需要做哪些分析

（1）功能測試

l? 輸入正確的用戶名和密碼，點擊提交按鈕，驗證是否能正確登錄。

l? 輸入錯誤的用戶名或者密碼,驗證登錄會失敗，并且提示相應(yīng)的錯誤信息。

l? 登錄成功后能否能否跳轉(zhuǎn)到正確的頁面

l? 用戶名和密碼，如果太短或者太長，應(yīng)該怎么處理

l? 用戶名和密碼，中有特殊字符（比如空格），和其他非英文的情況

l? 記住用戶名的功能

l? 登陸失敗后，不能記錄密碼的功能

l? 用戶名和密碼前后有空格的處理

l? 密碼是否非明文顯示顯示，使用星號圓點等符號代替。

l? 牽扯到驗證碼的，還要考慮文字是否扭曲過度導致辨認難度大，考慮顏色（色盲使 用者），刷新或換一個按鈕是否好用

l? 登錄頁面中的注冊、忘記密碼，登出用另一帳號登陸等鏈接是否正確

l? 輸入密碼的時候，大寫鍵盤開啟的時候要有提示信息。

l? 什么都不輸入，點擊提交按鈕，檢查提示信息。

（2）界面測試

l? 布局是否合理，testbox和按鈕是否整齊。

l? testbox和按鈕的長度，高度是否復(fù)合要求。

l? 界面的設(shè)計風格是否與UI的設(shè)計風格統(tǒng)一。

l? 界面中的文字簡潔易懂，沒有錯別字。

（3）性能測試

l? 打開登錄頁面，需要的時間是否在需求要求的時間內(nèi)。

l? 輸入正確的用戶名和密碼后，檢查登錄成功跳轉(zhuǎn)到新頁面的時間是否在需求要求的時間內(nèi)。

l? 模擬大量用戶同時登陸，檢查一定壓力下能否正常登陸跳轉(zhuǎn)。

（4）安全性測試

l? 登錄成功后生成的Cookie，是否是httponly (否則容易被腳本盜取)。

l? 用戶名和密碼是否通過加密的方式，發(fā)送給Web服務(wù)器。

l? 用戶名和密碼的驗證，應(yīng)該是用服務(wù)器端驗證， 而不能單單是在客戶端用javascript 驗證。

l? 用戶名和密碼的輸入框，應(yīng)該屏蔽SQL注入攻擊。

l? 用戶名和密碼的的輸入框，應(yīng)該禁止輸入腳本 （防止XSS攻擊）。

l? 防止暴力破解，檢測是否有錯誤登陸的次數(shù)限制。

l? 是否支持多用戶在同一機器上登錄。

l? 同一用戶能否在多臺機器上登錄。