測試基本知識(shí)

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

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

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

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

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

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

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

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

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

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

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

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

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

區(qū)別：

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

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

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

應(yīng)用場景：

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

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

4、請(qǐng)說一說黑盒與白盒的測試方法

黑盒測試：

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

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

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

白盒測試：

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

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

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

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

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

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

常用白盒測試方法：

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

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

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

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

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

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

（4）判定/條件覆蓋同時(shí)滿足判定覆蓋條件覆蓋。

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

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

5、請(qǐng)說一下手動(dòng)測試與自動(dòng)化測試的優(yōu)缺點(diǎn)

手工測試缺點(diǎn)：

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

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

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

（1）測試人員具有經(jīng)驗(yàn)和對(duì)錯(cuò)誤的猜測能力。

（2）測試人員具有審美能力和心理體驗(yàn)。

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

自動(dòng)化測試的優(yōu)點(diǎn)：

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

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

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

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

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

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

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

自動(dòng)化測試的缺點(diǎn)：

（1）不能取代手工測試

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

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

（4）測試自動(dòng)化不能提高有效性

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

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

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

自動(dòng)化測試的意義在于

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

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

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

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

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

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

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

8、請(qǐng)你說一下如何寫測試用例

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

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

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

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

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

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

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

9、請(qǐng)問你覺得測試項(xiàng)目具體工作是什么？

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

10、請(qǐng)你說一說測試用例的邊界

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

常見的邊界值：

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

（2）屏幕上光標(biāo)在最左上、最右下位置

（3）報(bào)表的第一行和最后一行

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

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

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

按照軟件質(zhì)量國家標(biāo)準(zhǔn)GB-T8566--2001G，軟件質(zhì)量可以用下列特征來評(píng)價(jià)：

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

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

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

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

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

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

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

黑盒測試：

（1）等價(jià)類劃分

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

（2）邊界值分析法

邊界值分析法是對(duì)等價(jià)類劃分的一種補(bǔ)充，因?yàn)榇蠖鄶?shù)錯(cuò)誤都在輸入輸出的邊界上。邊界值分析就是假定大多數(shù)錯(cuò)誤出現(xiàn)在輸入條件的邊界上，如果邊界附件取值不會(huì)導(dǎo)致程序出錯(cuò)，那么其他取值出錯(cuò)的可能性也就很小。

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

（3）正交試驗(yàn)法

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

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

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

（5）流程分析法

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

（6）輸入域測試法

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

（7）輸出域分析法

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

（8）判定表分析法

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

（9）因果圖法

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

（10）錯(cuò)誤猜測法

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

（11）異常分析法

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

白盒測試：

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

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

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

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

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

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

常用白盒測試方法：

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

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

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

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

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

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

（4）判定/條件覆蓋同時(shí)滿足判定覆蓋條件覆蓋。

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

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

13、請(qǐng)你說一下app性能測試的指標(biāo)

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

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

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

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ò)流量測試是針對(duì)大部分應(yīng)用而言的，可能還有部分應(yīng)用會(huì)關(guān)注網(wǎng)速、弱網(wǎng)之類的測試。

流量測試包括以下測試項(xiàng)：

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

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

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

（4）電量：

l? 測試手機(jī)安裝目標(biāo)APK前后待機(jī)功耗無明顯差異；

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

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

（5）啟動(dòng)速度：

l? 第一類：首次啟動(dòng)--應(yīng)用首次啟動(dòng)所花費(fèi)的時(shí)間；

l? 第二類：非首次啟動(dòng)--應(yīng)用非首次啟動(dòng)所花費(fèi)的時(shí)間；

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

（6）滑動(dòng)速度、界面切換速度

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

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

（1）New:（新的）

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

（2）Assigned（已指派的）

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

（3）Open（打開的）

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

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

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

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

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

（6）Reset(再測試)

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

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

如果測試人員經(jīng)過再次測試之后確認(rèn)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ā)人員認(rèn)為是正常行為而不是bug時(shí)，這種情況下開發(fā)人員可以拒絕，并將bug的狀態(tài)設(shè)置為“Pending?Reject”

（10）Rejected(被拒絕的)

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

（11）Postponed（延期）

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

不同類別的bug：

l? Bug類型

l? 代碼錯(cuò)誤

l? 界面優(yōu)化

l? 設(shè)計(jì)缺陷

l? 配置相關(guān)

l? 安裝部署

l? 安全相關(guān)

l? 性能問題

l? 標(biāo)準(zhǔn)規(guī)范

l? 測試腳本

l? 其他

15、請(qǐng)你說一說web測試和app測試的不同點(diǎn)

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

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

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

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

（2）性能方面:

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

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

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

（3）兼容方面：

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

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

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

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

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

16、請(qǐng)問你了解什么測試方法

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

17、請(qǐng)問黑盒測試和白盒測試有哪些方法

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

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

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

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

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

l? 測試方法用過等價(jià)劃分法、邊值分析法、錯(cuò)誤推測法、因果圖法。

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

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

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

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

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

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

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

（1）功能測試

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

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

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

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

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

l? 記住用戶名的功能

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

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

l? 密碼是否非明文顯示顯示，使用星號(hào)圓點(diǎn)等符號(hào)代替。

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

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

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

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

（2）界面測試

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

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

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

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

（3）性能測試

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

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

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

（4）安全性測試

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

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

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

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

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

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

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

l? 同一用戶能否在多臺(tái)機(jī)器上登錄。