?目錄

“中年危機(jī)”，更可怕的是自身危機(jī)

為什么會(huì)有危機(jī)感？

學(xué)習(xí)資源推薦

軟件測試所有方向的學(xué)習(xí)路線

?一、測試與軟件模型

二、測試用例設(shè)計(jì)

三、軟件測試類型

四、自動(dòng)化測試

五、測試文檔編寫與缺陷管理

六、常用的測試工具

七、軟件測試面試題總結(jié)

---

前幾天還有朋友說，從騰訊跳槽去了字節(jié)，一開始我還不理解，以為他是在走職場下坡路。但現(xiàn)在看來，字節(jié)的薪資是真的香。 按照脈脈和知乎上字節(jié)員工的說法，即便是應(yīng)屆畢業(yè)生都可以拿到比阿里高 20%-30% 的薪資，而有工作經(jīng)驗(yàn)的員工，普遍薪資水平高出業(yè)內(nèi) 30% 以上。 再看看數(shù)據(jù)，字節(jié)測試工程師的平均月薪就有 2W，根據(jù)拉勾網(wǎng)的招聘需求也能看出，大廠測試更需要代碼能力，也都是具有自動(dòng)化實(shí)施經(jīng)驗(yàn)的測試工程師。

不過，我身邊有很多朋友，普通二本畢業(yè)，沒有多漂亮的簡歷，甚至沒有一份像樣的工作經(jīng)歷，也都進(jìn)了大廠工作。
但有一個(gè)非常重要的前提，就是他們技術(shù)能力都很強(qiáng)。
大廠并不要求每個(gè)人都有超高的學(xué)歷、不一般的背景，但一定一定會(huì)要求你，具備過硬的技術(shù)實(shí)力、有足夠扎實(shí)的代碼能力。
然而，能具備這兩點(diǎn)的只是少數(shù)人，更多人的情況是，忙著上班，也沒人帶，自己也不太會(huì)規(guī)劃。
我建議大家多去投簡歷面試，能遇到合適的機(jī)會(huì)最好，如果真沒啥好機(jī)會(huì)，建議抽時(shí)間來好好規(guī)劃一下，把自己沒掌握的技術(shù)點(diǎn)攻克，從原理到落地實(shí)踐。這樣無論是對于我們現(xiàn)在工作而言還是以后的跳槽打算都是一項(xiàng)重要的支撐點(diǎn)。

“中年危機(jī)”，更可怕的是自身危機(jī)

許多程序員往往想著中年危機(jī)，也就是人到了35歲以后，公司是否還愿意高薪聘請軟件測試工程師，還是直接找應(yīng)屆生解決問題。
其實(shí)，除了“中年危機(jī)”，
如今互聯(lián)網(wǎng)企業(yè)內(nèi)卷也比較嚴(yán)重，甚至很多企業(yè)程序員變成了產(chǎn)品經(jīng)理和運(yùn)營，一個(gè)人當(dāng)一群人用。
“我是革命一塊磚，哪里需要哪里搬。”尤其在中小企業(yè)，這樣的人才比比皆是，他們不知道自己想要什么。
關(guān)鍵是，即便是如此，當(dāng)一個(gè)行業(yè)處于發(fā)展階段，急需要大批量的人才時(shí)，也無所謂。
IT這個(gè)行業(yè)沒有我們想象中那么光鮮，一個(gè)蘿卜一個(gè)坑，最后留下的基本都做到了管理層，普通人，一般35歲還處于基層的話，大多會(huì)被優(yōu)化點(diǎn)。
不算身處哪個(gè)行業(yè)，都要未雨綢繆，提前做好規(guī)劃。

為什么會(huì)有危機(jī)感？

從知識(shí)層面說：當(dāng)你知之甚少，觀看龐大的信息流，超出你的認(rèn)知上限，你會(huì)產(chǎn)生知識(shí)焦慮和危機(jī)感。解決的辦法就是學(xué)習(xí)，看系統(tǒng)的書籍，努力提升自我，根據(jù)自己的能力設(shè)定合理的計(jì)劃并去實(shí)踐。

實(shí)踐很重要，你會(huì)在這個(gè)過程中有所提升，提升的程度取決于你的專注程度和堅(jiān)持不懈的結(jié)果，在學(xué)習(xí)和實(shí)踐的過程中會(huì)轉(zhuǎn)移你的危機(jī)意識(shí)（強(qiáng)烈的危機(jī)意識(shí)是一種溢出的精神能量，并且會(huì)造成焦慮以及不安）。

學(xué)習(xí)資源推薦

學(xué)習(xí)資源是學(xué)習(xí)質(zhì)量和速度的保證，因此找到高質(zhì)量的學(xué)習(xí)資源對我們來說也是非常重要的。以下列出的學(xué)習(xí)資源不分排名，都是好資源：

軟件測試所有方向的學(xué)習(xí)路線

?一、測試與軟件模型

軟件開發(fā)生命周期模型指的是軟件開發(fā)全過程、活動(dòng)和任務(wù)的結(jié)構(gòu)性框架。軟件項(xiàng)目的開發(fā)包括：需求、設(shè)計(jì)、編碼、測試、穩(wěn)定、部署、維護(hù)等階段。

常見的軟件開發(fā)模型有瀑布模型、迭代開發(fā)、螺旋開發(fā)和敏捷開發(fā)。

1 瀑布模型

瀑布模型式是最典型的預(yù)見性的方法，嚴(yán)格遵循預(yù)先計(jì)劃的需求分析、設(shè)計(jì)、編碼、集成、測試、維護(hù)的步驟順序進(jìn)行。步驟成果作為衡量進(jìn)度的方法，例如需求規(guī)格，設(shè)計(jì)文檔，測試計(jì)劃和代碼審閱等等。瀑布式的主要有以下問題：

各個(gè)階段的劃分完全固定，階段之間產(chǎn)生大量的文檔，極大地增加了工作量；

由于開發(fā)模型是線性的，用戶只有等到整個(gè)過程的末期才能見到開發(fā)成果，從而增加了開發(fā)的風(fēng)險(xiǎn)；

早期的錯(cuò)誤可能要等到開發(fā)后期的測試階段才能發(fā)現(xiàn)，進(jìn)而帶來嚴(yán)重的后果。

因此，瀑布式方法在需求不明并且在項(xiàng)目進(jìn)行過程中可能變化的情況下基本是不可行的。

2 迭代開發(fā)模型

迭代式開發(fā)是一種與傳統(tǒng)的瀑布式開發(fā)相反的軟件開發(fā)過程，具有更高的成功率和生產(chǎn)率。在迭代開發(fā)中，整個(gè)開發(fā)工作被組織為一系列的短小的、固定長度（如3周）的小項(xiàng)目，逐步逐步的完成，故為迭代。每一次迭代都包括需求分析、設(shè)計(jì)、實(shí)現(xiàn)與測試。采用這種方法，開發(fā)工作可以在需求被完整地確定之前啟動(dòng)，并在一次迭代中完成系統(tǒng)的一部分功能或業(yè)務(wù)邏輯的開發(fā)工作。再通過客戶的反饋來細(xì)化需求，并開始新一輪的迭代。迭代開發(fā)具有以下優(yōu)點(diǎn)：

降低風(fēng)險(xiǎn)。如果開發(fā)人員重復(fù)某個(gè)迭代，那么損失只是這一個(gè)開發(fā)有誤的迭代的花費(fèi)。

適應(yīng)需求變更。由于用戶的需求并不能在一開始就作出完全的界定，它們通常是在后續(xù)階段中不斷細(xì)化的。

持續(xù)的測試與集成，降低后期的工作量與風(fēng)險(xiǎn)。

3 螺旋開發(fā)模型

螺旋開發(fā)，將瀑布模型和快速原型模型結(jié)合起來，強(qiáng)調(diào)了其他模型所忽視的風(fēng)險(xiǎn)分析，特別適合于大型復(fù)雜的系統(tǒng)。“螺旋模型”剛開始規(guī)模很小，當(dāng)項(xiàng)目被定義得更好、更穩(wěn)定時(shí)，逐漸展開。 “螺旋模型”的核心就在于不需要在剛開始的時(shí)候就把所有事情都定義的清清楚楚。您輕松上陣，定義最重要的功能，實(shí)現(xiàn)它，然后聽取客戶的意見，之后再進(jìn)入到下一個(gè)階段。如此不斷輪回重復(fù)，直到得到您滿意的最終產(chǎn)品。 螺旋開發(fā)分為以下四個(gè)階段：

制定計(jì)劃：確定軟件目標(biāo)，選定實(shí)施方案，弄清項(xiàng)目開發(fā)的限制條件；

風(fēng)險(xiǎn)分析：分析評估所選方案，考慮如何識(shí)別和消除風(fēng)險(xiǎn)；

實(shí)施工程：實(shí)施軟件開發(fā)和驗(yàn)證；

客戶評估：評價(jià)開發(fā)工作，提出修正建議，制定下一步計(jì)劃。

一個(gè)階段首先是確定該階段的目標(biāo)，完成這些目標(biāo)的選擇方案及其約束條件，然后從風(fēng)險(xiǎn)角度分析方案的開發(fā)策略，努力排除各種潛在的風(fēng)險(xiǎn)，有時(shí)需要通過建 造原型來完成。如果某些風(fēng)險(xiǎn)不能排除，該方案立即終止，否則啟動(dòng)下一個(gè)開發(fā)步驟。最后，評價(jià)該階段的結(jié)果，并設(shè)計(jì)下一個(gè)階段。

4 敏捷開發(fā)模型

敏捷開發(fā)，是一種從1990年代開始逐漸引起廣泛關(guān)注的一些新型軟件開發(fā)方法，是一種應(yīng)對快速變化的需求的一種軟件開發(fā)能力。相對于“非敏捷”，更強(qiáng)調(diào)程序員團(tuán)隊(duì)與業(yè)務(wù)專家之間的緊密協(xié)作、面對面的溝通（認(rèn)為比書面的文檔更有效）、頻繁交付新的軟件版本、緊湊而自我組織型的團(tuán)隊(duì)、能夠很好地適應(yīng)需求變化的代碼編寫和團(tuán)隊(duì)組織方法，也更注重軟件開發(fā)中人的作用。

個(gè)體和互動(dòng)重于流程和工具。

可工作的軟件重于求全而完備的文檔。

客戶協(xié)作重于合同談判。

應(yīng)對變化重于遵循計(jì)劃。

其中位于右邊的內(nèi)容雖然也有其價(jià)值，但是左邊的內(nèi)容最為重要。人員彼此信任，人少但是精干，可以面對面的溝通。

敏捷開發(fā)小組主要的工作方式可以歸納為：作為一個(gè)整體工作；按短迭代周期工作；每次迭代交付一些成果；關(guān)注業(yè)務(wù)優(yōu)先；檢查與調(diào)整。

最重要的因素恐怕是項(xiàng)目的規(guī)模。規(guī)模增長，面對面的溝通就愈加困難，因此敏捷方法更適用于較小的隊(duì)伍，40、30、20、10人或者更少。

5 四種模型比較

傳統(tǒng)的瀑布式開發(fā)，也就是從需求到設(shè)計(jì)，從設(shè)計(jì)到編碼，從編碼到測試，從測試到提交大概這樣的流程，要求每一個(gè)開發(fā)階段都要做到最好。特別是前期階段，設(shè)計(jì)的越完美，提交后的成本損失就越少。

迭代式開發(fā)，不要求每一個(gè)階段的任務(wù)做的都是最完美的，而是明明知道還有很多不足的地方，卻偏偏不去完善它，而是把主要功能先搭建起來為目的，以最短的時(shí)間，最少的損失先完成一個(gè)“不完美的成果物”直至提交。然后再通過客戶或用戶的反饋信息，在這個(gè)“不完美的成果物”上逐步進(jìn)行完善。

螺旋開發(fā)，很大程度上是一種風(fēng)險(xiǎn)驅(qū)動(dòng)的方法體系，因?yàn)樵诿總€(gè)階段之前及經(jīng)常發(fā)生的循環(huán)之前，都必須首先進(jìn)行風(fēng)險(xiǎn)評估。

敏捷開發(fā)，相比迭代式開發(fā)兩者都強(qiáng)調(diào)在較短的開發(fā)周期提交軟件，但是，敏捷開發(fā)的周期可能更短，并且更加強(qiáng)調(diào)隊(duì)伍中的高度協(xié)作。敏捷方法有時(shí)候被誤認(rèn)為是無計(jì)劃性和紀(jì)律性的方法，實(shí)際上更確切的說法是敏捷方法強(qiáng)調(diào)適應(yīng)性而非預(yù)見性。

適應(yīng)性的方法集中在快速適應(yīng)現(xiàn)實(shí)的變化。當(dāng)項(xiàng)目的需求起了變化，團(tuán)隊(duì)?wèi)?yīng)該迅速適應(yīng)。這個(gè)團(tuán)隊(duì)可能很難確切描述未來將會(huì)如何變化。

6 軟件開發(fā)過程中的測試

在前面介紹的軟件開發(fā)過程中，測試都是一個(gè)重要的組成部分。尤其對于中大型項(xiàng)目，從項(xiàng)目開始指出就要制定測試計(jì)劃、對需求進(jìn)行測試、設(shè)計(jì)測試和測試用例、執(zhí)行測試，最后對測試的結(jié)果進(jìn)行總結(jié)和分析。軟件缺陷發(fā)現(xiàn)得越早，修復(fù)軟件缺陷所需的代價(jià)越小。

TDD（測試驅(qū)動(dòng)開發(fā)）的思路就是通過測試推動(dòng)整個(gè)開發(fā)的進(jìn)行，開發(fā)代碼之前，先編寫測試代碼。在明確要開發(fā)某個(gè)功能后，首先思考如何對這個(gè)功能進(jìn)行測試，并完成測試代碼的編寫，然后編寫相關(guān)的代碼滿足這些測試用例。并且，軟件測試的活動(dòng)貫穿整個(gè)軟件開發(fā)生命周期的始終。

7 軟件測試的目的與原則

測試的定義：使用人工或自動(dòng)手段來運(yùn)行或測定某個(gè)系統(tǒng)的過程，其目的在于檢查它是否滿足規(guī)定的需求或是弄清預(yù)期結(jié)果與實(shí)際結(jié)果之間的差別。

軟件測試的目的：發(fā)現(xiàn)程序中的錯(cuò)誤，保證軟件產(chǎn)品的最終質(zhì)量。

測試是程序的執(zhí)行過程，目的在于發(fā)現(xiàn)錯(cuò)誤

一個(gè)成功的測試用例在于發(fā)現(xiàn)至今未發(fā)現(xiàn)的錯(cuò)誤

一個(gè)成功的測試是發(fā)現(xiàn)了至今未發(fā)現(xiàn)的錯(cuò)誤的測試

確保產(chǎn)品完成了它所承諾或公布的功能，并且用戶可以訪問到的功能都有明確的書面說明。

確保產(chǎn)品滿足性能和效率的要求

確保產(chǎn)品是健壯的和適應(yīng)用戶環(huán)境的

軟件測試的原則：

測試用例中一個(gè)必須部分是對預(yù)期輸出或接口進(jìn)行定義

程序員應(yīng)避免測試自己編寫的程序

編寫軟件的組織不應(yīng)當(dāng)測試自己編寫的軟件

應(yīng)當(dāng)徹底檢查每個(gè)測試的執(zhí)行結(jié)果

測試用例的編寫不僅應(yīng)當(dāng)根據(jù)有效和預(yù)料到的輸入情況，而且也應(yīng)當(dāng)根據(jù)無效和未預(yù)料到的輸入情況

檢查程序是否“未做其應(yīng)該做的”僅是測試的一半，測試的另一半是檢查程序是否“做了其不應(yīng)該做的”

應(yīng)避免測試用例用后即棄，除非軟件本身就是個(gè)一次性的軟件

計(jì)劃測試工作時(shí)不應(yīng)默許假定不會(huì)發(fā)現(xiàn)錯(cuò)誤

程序某部分存在更多錯(cuò)誤的可能性，與該部分已經(jīng)發(fā)現(xiàn)錯(cuò)誤的數(shù)量成正比

8 軟件的可測性

軟件的可測性太差會(huì)導(dǎo)致測試的難度相當(dāng)大，甚至無法測試。這種情況往往是由于極差的軟件架構(gòu)設(shè)計(jì)和極為不規(guī)范的軟件開發(fā)工作導(dǎo)致的。

緊耦合。不把大半個(gè)系統(tǒng)實(shí)例化就無法測試。

弱內(nèi)聚。這個(gè)類實(shí)現(xiàn)了太多功能，導(dǎo)致測試非常復(fù)雜。

冗余。同一個(gè)方法在多處使用，每一處都得測。

好的軟件架構(gòu)應(yīng)該是松耦合、高內(nèi)聚的。提高軟件的測試性的同時(shí)也提高了軟件的可維護(hù)性和可管理性。

二、測試用例設(shè)計(jì)

測試用例是為特定的目的而設(shè)計(jì)的一組測試輸入、執(zhí)行條件和預(yù)期的結(jié)果。測試用例是執(zhí)行的最小實(shí)體。簡單地說，測試用例就是設(shè)計(jì)一個(gè)場景，使軟件程序在這種場景下，必須能夠正常運(yùn)行并且達(dá)到程序所設(shè)計(jì)的執(zhí)行結(jié)果。

1 黑盒測試與白盒測試

黑盒測試：已知產(chǎn)品的功能設(shè)計(jì)規(guī)格，可以進(jìn)行測試證明每個(gè)實(shí)現(xiàn)了的功能是否符合要求。白盒測試：已知產(chǎn)品的內(nèi)部工作過程，可以進(jìn)行測試證明每種內(nèi)部操作是否符合設(shè)計(jì)規(guī)格要求，所有內(nèi)部成分是否經(jīng)過檢查。

合理的測試策略是將這兩種測試要素組合起來。我們可以通過使用特定的面向黑盒測試的測試用例設(shè)計(jì)方法，而后使用白盒測試方法對程序的邏輯結(jié)構(gòu)進(jìn)行檢查以補(bǔ)充這些測試用例，借此來設(shè)計(jì)出一個(gè)相當(dāng)嚴(yán)格的測試。

白盒測試方法有語句覆蓋、判定覆蓋、條件覆蓋、判定/條件覆蓋、條件組合覆蓋、路徑覆蓋。黑盒測試方法有等價(jià)類劃分、邊界值分析、因果圖分析、錯(cuò)誤測試、狀態(tài)圖、場景法等。

2 白盒測試用例設(shè)計(jì)

白盒測試關(guān)注的是測試用例執(zhí)行的程度或覆蓋程序邏輯結(jié)構(gòu)（源代碼）的程度。完全的白盒測試是將程序中每條路徑都執(zhí)行到，然而對一個(gè)帶有循環(huán)的程序來說，完全的路徑測試并不切合實(shí)際。白盒測試的特點(diǎn)：依據(jù)軟件設(shè)計(jì)說明書進(jìn)行測試、對程序內(nèi)部細(xì)節(jié)的嚴(yán)密檢驗(yàn)、針對特定條件設(shè)計(jì)測試用例、對軟件的邏輯路徑進(jìn)行覆蓋測試。

語句覆蓋是最起碼的結(jié)構(gòu)覆蓋要求，語句覆蓋要求設(shè)計(jì)足夠多的測試用例，使得程序中每條語句至少被執(zhí)行一次。可以很直觀地從源代碼得到測試用例，無須細(xì)分每條判定表達(dá)式。由于這種測試方法僅僅針對程序邏輯中顯式存在的語句，但對于隱藏的條件和可能到達(dá)的隱式邏輯分支，是無法測試的。（遺漏隱藏的邏輯分支）

判定覆蓋要求必須編寫足夠的測試用例，使得每一個(gè)判斷都至少有一個(gè)為“真”和為“假”的輸出結(jié)果。判定覆蓋比語句覆蓋要多幾乎一倍的測試路徑，當(dāng)然也就具有比語句覆蓋更強(qiáng)的測試能力。同樣判定覆蓋也具有和語句覆蓋一樣的簡單性，無須細(xì)分每個(gè)判定就可以得到測試用例。往往大部分的判定語句是由多個(gè)邏輯條件組合而成（如，判定語句中包含AND、OR、CASE），若僅僅判斷其整個(gè)最終結(jié)果，而忽略每個(gè)條件的取值情況，必然會(huì)遺漏部分測試路徑。（遺漏組合判定中的某些條件取值）

條件覆蓋要求設(shè)計(jì)足夠多的測試用例，使得判定中的每個(gè)條件獲得各種可能的結(jié)果，即每個(gè)條件至少有一次為真值，有一次為假值。要達(dá)到條件覆蓋，需要足夠多的測試用例，但條件覆蓋并不能保證判定覆蓋。條件覆蓋只能保證每個(gè)條件至少有一次為真，而不考慮所有的判定結(jié)果。

判定/條件覆蓋要求設(shè)計(jì)足夠多的測試用例，使得判定中每個(gè)條件的所有可能結(jié)果至少出現(xiàn)一次，每個(gè)判定本身所有可能結(jié)果也至少出現(xiàn)一次。判定/條件覆蓋滿足判定覆蓋準(zhǔn)則和條件覆蓋準(zhǔn)則，彌補(bǔ)了二者的不足。判定/條件覆蓋準(zhǔn)則的缺點(diǎn)是未考慮條件的組合情況。

多重條件覆蓋要求設(shè)計(jì)足夠多的測試用例，使得每個(gè)判定中條件結(jié)果的所有可能組合至少出現(xiàn)一次。多重條件覆蓋準(zhǔn)則滿足判定覆蓋、條件覆蓋和判定/條件覆蓋準(zhǔn)則。更改的判定/條件覆蓋要求設(shè)計(jì)足夠多的測試用例，使得判定中每個(gè)條件的所有可能結(jié)果至少出現(xiàn)一次，每個(gè)判定本身的所有可能結(jié)果也至少出現(xiàn)一次。并且每個(gè)條件都顯示能單獨(dú)影響判定結(jié)果。缺點(diǎn)是線性地增加了測試用例的數(shù)量。

路徑覆蓋要求設(shè)計(jì)足夠的測試用例，覆蓋程序中所有可能的路徑。由于路徑覆蓋需要對所有可能的路徑進(jìn)行測試（包括循環(huán)、條件組合、分支選擇等），那么需要設(shè)計(jì)大量、復(fù)雜的測試用例，使得工作量呈指數(shù)級增長。而在有些情況下，一些執(zhí)行路徑是不可能被執(zhí)行的，這樣不僅降低了測試效率，而且大量的測試結(jié)果的累積，也為排錯(cuò)帶來麻煩。

3 黑盒測試用例設(shè)計(jì)

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

等價(jià)類劃分是把所有可能的輸入數(shù)據(jù),即程序的輸入域劃分成若干部分（子集）,然后從每一個(gè)子集中選取少數(shù)具有代表性的數(shù)據(jù)作為測試用例。等價(jià)類分為有效等價(jià)類和無效等價(jià)類，其中，有效等價(jià)類是指對于程序的規(guī)格說明來說是合理的，有意義的輸入數(shù)據(jù)構(gòu)成的集合；而無效等價(jià)類是指對于程序的規(guī)格說明來說是不合理的，沒有意義的輸入數(shù)據(jù)構(gòu)成的集合。設(shè)計(jì)測試用例時(shí),要同時(shí)考慮這兩種等價(jià)類。因?yàn)檐浖粌H要能接收合理的數(shù)據(jù),也要能經(jīng)受意外的考驗(yàn)，這樣的測試才能確保軟件具有更高的可靠性。劃分等價(jià)類有以下原則：

在輸入條件規(guī)定了取值范圍或值的個(gè)數(shù)的情況下,則可以確立一個(gè)有效等價(jià)類和兩個(gè)無效等價(jià)類。如：輸入值是學(xué)生成績，范圍是0～100；則小于0和大于100的為無效等價(jià)類，0~100之間的為有效等價(jià)類。

在輸入條件規(guī)定了輸入值的集合或者規(guī)定了"必須如何"的條件的情況下，可確立一個(gè)有效等價(jià)類和一個(gè)無效等價(jià)類。

在輸入條件是一個(gè)布爾量的情況下,可確定一個(gè)有效等價(jià)類和一個(gè)無效等價(jià)類。

在規(guī)定了輸入數(shù)據(jù)的一組值（假定n個(gè)）,并且程序要對每一個(gè)輸入值分別處理的情況下,可確立n個(gè)有效等價(jià)類和一個(gè)無效等價(jià)類。例：輸入條件說明學(xué)歷可為:專科、本科、碩士、博士四種之一，則分別取這四種這四個(gè)值作為四個(gè)有效等價(jià)類，另外把四種學(xué)歷之外的任何學(xué)歷作為無效等價(jià)類。

在規(guī)定了輸入數(shù)據(jù)必須遵守的規(guī)則的情況下,可確立一個(gè)有效等價(jià)類（符合規(guī)則）和若干個(gè)無效等價(jià)類（從不同角度違反規(guī)則）；

在確知已劃分的等價(jià)類中各元素在程序處理中的方式不同的情況下,則應(yīng)再將該等價(jià)類進(jìn)一步的劃分為更小的等價(jià)類。

在確立了等價(jià)類后,可建立等價(jià)類表,列出所有劃分出的等價(jià)類輸入條件：有效等價(jià)類、無效等價(jià)類，然后從劃分出的等價(jià)類中按以下三個(gè)原則設(shè)計(jì)測試用例：

為每一個(gè)等價(jià)類規(guī)定一個(gè)唯一的編號；

設(shè)計(jì)一個(gè)新的測試用例,使其盡可能多地覆蓋尚未被覆蓋地有效等價(jià)類,重復(fù)這一步，直到所有的有效等價(jià)類都被覆蓋為止；

設(shè)計(jì)一個(gè)新的測試用例,使其僅覆蓋一個(gè)尚未被覆蓋的無效等價(jià)類,重復(fù)這一步，直到所有的無效等價(jià)類都被覆蓋為止。

（2）邊界值分析

邊界值分析法就是對輸入或輸出的邊界值進(jìn)行測試的一種黑盒測試方法。通常邊界值分析法是作為對等價(jià)類劃分法的補(bǔ)充，這種情況下，其測試用例來自等價(jià)類的邊界。邊界值分析不是從某等價(jià)類中隨便挑一個(gè)作為代表，而是使這個(gè)等價(jià)類的每個(gè)邊界都要作為測試條件。邊界值分析不僅考慮輸入條件，還要考慮輸出空間產(chǎn)生的測試情況。

長期的測試工作經(jīng)驗(yàn)告訴我們，大量的錯(cuò)誤是發(fā)生在輸入或輸出范圍的邊界上，而不是發(fā)生在輸入輸出范圍的內(nèi)部。因此針對各種邊界情況設(shè)計(jì)測試用例，可以查出更多的錯(cuò)誤。使用邊界值分析方法設(shè)計(jì)測試用例，首先應(yīng)確定邊界情況。通常輸入和輸出等價(jià)類的邊界，就是應(yīng)著重測試的邊界情況。應(yīng)當(dāng)選取正好等于，剛剛大于或剛剛小于邊界的值作為測試數(shù)據(jù)，而不是選取等價(jià)類中的典型值或任意值作為測試數(shù)據(jù)。

（3）因果圖

因果圖是一種利用圖解法分析輸入的各種組合情況，從而設(shè)計(jì)測試用例的方法，它適合于檢查程序輸入條件的各種組合情況。

等價(jià)類劃分法和邊界值分析方法都是著重考慮輸入條件，但沒有考慮輸入條件的各種組合、輸入條件之間的相互制約關(guān)系。這樣雖然各種輸入條件可能出錯(cuò)的情況已經(jīng)測試到了，但多個(gè)輸入條件組合起來可能出錯(cuò)的情況卻被忽視了。如果在測試時(shí)必須考慮輸入條件的各種組合，則可能的組合數(shù)目將是天文數(shù)字，因此必須考慮采用一種適合于描述多種條件的組合、相應(yīng)產(chǎn)生多個(gè)動(dòng)作的形式來進(jìn)行測試用例的設(shè)計(jì)，這就需要利用因果圖（邏輯模型）。

（4） 錯(cuò)誤測試

錯(cuò)誤測試是基于經(jīng)驗(yàn)和直覺推測程序中所有可能存在的各種錯(cuò)誤, 從而有針對性的設(shè)計(jì)測試用例的方法。

如測試一個(gè)對線性表（比如數(shù)組）進(jìn)行排序的程序，可推測列出以下幾項(xiàng)需要特別測試的情況：

輸入的線性表為空表；

表中只含有一個(gè)元素；

輸入表中所有元素已排好序；

輸入表已按逆序排好；

輸入表中部分或全部元素相同。

4 測試用例設(shè)計(jì)綜合策略

Myers提出了使用各種測試方法的綜合策略：

在任何情況下都必須使用邊界值分析方法，經(jīng)驗(yàn)表明用這種方法設(shè)計(jì)出測試用例發(fā)現(xiàn)程序錯(cuò)誤的能力最強(qiáng)。

必要時(shí)用等價(jià)類劃分方法補(bǔ)充一些測試用例。

用錯(cuò)誤推測法再追加一些測試用例。

對照程序邏輯，檢查已設(shè)計(jì)出的測試用例的邏輯覆蓋程度，如果沒有達(dá)到要求的覆蓋標(biāo)準(zhǔn)，應(yīng)當(dāng)再補(bǔ)充足夠的測試用例。

如果程序的功能說明中含有輸入條件的組合情況，則一開始就可選用因果圖法。

測試用例的設(shè)計(jì)步驟：1)構(gòu)造根據(jù)設(shè)計(jì)規(guī)格得出的基本功能測試用例；2)邊界值測試用例；3)狀態(tài)轉(zhuǎn)換測試用例；4)錯(cuò)誤猜測測試用例；5)異常測試用例；6)性能測試用例；7)壓力測試用例。

三、軟件測試類型

單元測試

單元測試并不是對整個(gè)程序進(jìn)行測試，而是對構(gòu)成程序的較小模塊進(jìn)行測試。單元測試減小了調(diào)試的難度（一旦某個(gè)錯(cuò)誤被發(fā)現(xiàn)出來，我們就知道它在哪個(gè)具體的模塊中）；單元測試提供了同時(shí)測試多個(gè)模塊的可能，將并行工程引入軟件測試中。

在為模塊單元測試設(shè)計(jì)測試用例時(shí)，需要使用兩種類型的信息：模塊的規(guī)格說明和模塊的源代碼。規(guī)格說明一般都規(guī)定了模塊的輸入和輸出參數(shù)以及模塊的功能。單元測試總體上是面向白盒測試的，因此，單元測試的測試用例的設(shè)計(jì)過程如下：使用一種或多種白盒測試方法分析模塊的邏輯結(jié)構(gòu)，然后使用黑盒測試方法對照模塊的規(guī)格說明以補(bǔ)充測試用例。

集成測試

自頂向下集成和自底向上集成

功能測試

功能測試的目的是為了暴露程序的錯(cuò)誤以及與規(guī)格說明不一致之處，而不是為了證明程序符合其外部規(guī)格說明。

功能測試是一種黑盒測試，功能測試常用步驟有：根據(jù)需求來細(xì)分功能點(diǎn)，根據(jù)功能點(diǎn)派生測試需求，根據(jù)測試需求設(shè)計(jì)功能測試用例。

系統(tǒng)測試

系統(tǒng)測試的目的是為了證明程序不能實(shí)現(xiàn)其目標(biāo)，系統(tǒng)測試的測試用例設(shè)計(jì)有以下14種類型：

能力測試：是判斷目標(biāo)文檔提及的每一項(xiàng)能力（或功能）是否都確實(shí)已經(jīng)實(shí)現(xiàn)。

容量測試：使程序經(jīng)受大容量數(shù)據(jù)的檢驗(yàn)。容量測試的目的是為了證明程序不能處理目標(biāo)文檔中規(guī)定的數(shù)據(jù)容量。

強(qiáng)度測試：使程序承受高負(fù)載或強(qiáng)度的檢驗(yàn)。所謂高強(qiáng)度是指在很短的時(shí)間間隔內(nèi)達(dá)到的數(shù)據(jù)或操作的數(shù)量峰值。

易用性測試：試圖發(fā)現(xiàn)人為因素或易用性的問題。

安全性測試：設(shè)計(jì)測試用例來突破程序安全檢查的過程。舉例來說，我們可以設(shè)計(jì)測試用例來規(guī)避操作系統(tǒng)的內(nèi)存保護(hù)機(jī)制，破壞數(shù)據(jù)庫管理系統(tǒng)的數(shù)據(jù)安全機(jī)制。

性能測試：很多軟件都有特定的性能或效率目標(biāo)，這終特性描述為在特定負(fù)載和配置環(huán)境下程序的響應(yīng)時(shí)間和吞吐率。

存儲(chǔ)測試：

配置測試：

兼容性測試。

安裝測試：有些類型的軟件系統(tǒng)安裝過程非常復(fù)雜，測試安裝過程是系統(tǒng)測試中的一個(gè)重要部分。對于包含在軟件包中的自動(dòng)安裝系統(tǒng)而言，這尤其重要。安裝程序如果出現(xiàn)故障，會(huì)影響用戶對軟件的成功體驗(yàn)。

可靠性測試：所有類型的測試都是為了提高軟件的可靠性，但是如果軟件的目標(biāo)中包含了對可靠性的特別描述，就必須設(shè)計(jì)專門的可靠性測試。

可恢復(fù)性測試：諸如操作系統(tǒng)、數(shù)據(jù)庫管理系統(tǒng)和遠(yuǎn)程處理系統(tǒng)等軟件通常都有可恢復(fù)性目標(biāo)，說明系統(tǒng)如何從程序錯(cuò)誤、硬件失效和數(shù)據(jù)錯(cuò)誤中恢復(fù)過來。系統(tǒng)測試的一個(gè)目標(biāo)是證明這些恢復(fù)機(jī)制不能夠正確發(fā)揮作用。我們可以故意將程序錯(cuò)誤置入某個(gè)系統(tǒng)中，判斷系統(tǒng)是否可以從中恢復(fù)。

適用性測試

文檔測試：檢查用戶文檔的正確性。用戶文檔應(yīng)成為審查的對象，檢查其正確性和清晰性。在文檔中描述的任何范例應(yīng)編成測試用例，并提交給程序。

四、自動(dòng)化測試

自動(dòng)化測試：以程序測試程序、以代碼代替思維、以腳本運(yùn)行代替手工測試。

冒煙測試:就是在一個(gè)新版本出來的時(shí)候，將軟件的全部功能過一遍，看有沒有什么大問題。如果功能可以正常運(yùn)行，不會(huì)影響測試進(jìn)行，那么這個(gè)版本就可以真正開始測試了。如果功能有重大問題或影響測試進(jìn)行，那么這個(gè)版本就是不合格的，不用進(jìn)行進(jìn)一步的測試。比如，拿到QQ的app新版本，登陸都登陸不上，那么這個(gè)版本肯定無法繼續(xù)測下去。或者，游戲中新的模塊出現(xiàn)，但是新的模塊總是崩潰、卡死，測試進(jìn)行不下去，那么冒煙的結(jié)果就是不合格的。

回歸測試:就是以前版本中發(fā)現(xiàn)的bug在新的版本中驗(yàn)證是否存在且是否引發(fā)新的bug。

1 自動(dòng)化測試的優(yōu)勢

回歸測試更方便、可靠。由于回歸測試的業(yè)務(wù)流程操作和測試用例是預(yù)先設(shè)計(jì)好的，預(yù)期結(jié)果也是完全在項(xiàng)目人員掌握之中的，將回歸測試交給計(jì)算機(jī)自動(dòng)運(yùn)行，可以極大提高測試效率，縮短回歸測試時(shí)間。

可運(yùn)行更多更繁瑣的測試，且快速高效。

可執(zhí)行一些對于手工測試來說相當(dāng)困難或根本做不到的測試。比如，對大量用戶的并發(fā)測試等。

具有一致性和可重復(fù)性的特點(diǎn)。

自動(dòng)化測試腳本完全具有復(fù)用性。由于自動(dòng)化測試通常以腳本的方式實(shí)現(xiàn)，這樣在不同的版本之間，就可能只需要做少量的維護(hù)甚至不做任何修改，實(shí)現(xiàn)在不同的測試版本中使用相同的測試腳本執(zhí)行相同的測試用例。

2 自動(dòng)化測試的劣勢

永遠(yuǎn)不可能完全取代手工測試。自動(dòng)化測試無法做到手工測試的覆蓋率，不是每個(gè)測試用例都適合轉(zhuǎn)換成自動(dòng)化測試用例的。

無法保證測試的正確性。測試腳本本身也可能存在缺陷。

手工測試能發(fā)現(xiàn)的缺陷遠(yuǎn)比自動(dòng)化測試多。自動(dòng)化測試幾乎是無法發(fā)現(xiàn)新缺陷。

自動(dòng)化測試工具是死的，它本身沒有任何想象力。

自動(dòng)化測試對測試工程師來說必須有一定的開發(fā)技術(shù)背景。

3 引入自動(dòng)化測試的時(shí)機(jī)

項(xiàng)目周期長，系統(tǒng)版本不斷。主要在于回歸測試。

需求變更不頻繁。

系統(tǒng)中的測試對象基本可以正常識(shí)別，不存在大批量第三方控件。

需要反復(fù)測試，如可靠性測試需要進(jìn)行上千次的系統(tǒng)測試。

4 何時(shí)避免展開自動(dòng)化測試

項(xiàng)目周期短，需求變更頻繁。項(xiàng)目周期短的情況下引入自動(dòng)化測試，不但收不回成本，而且會(huì)延長產(chǎn)品的發(fā)布時(shí)間。需求頻繁改變會(huì)使老功能的業(yè)務(wù)邏輯被修改，從而導(dǎo)致相應(yīng)的測試腳本也需相應(yīng)修改。

軟件版本還沒穩(wěn)定。

多數(shù)對象無法識(shí)別以及腳本維護(hù)頻繁與艱難。

5 自動(dòng)化測試用例設(shè)計(jì)

在項(xiàng)目的測試過程中，測試工程師都會(huì)首先分析測試需求，產(chǎn)出測試計(jì)劃后，編寫和設(shè)計(jì)測試用例，設(shè)計(jì)開發(fā)測試腳本。

自動(dòng)化測試用例的范圍往往是核心業(yè)務(wù)流程或者重復(fù)執(zhí)行率較高的。并不需要覆蓋所有的手工測試用例。

自動(dòng)化測試用例的選擇一般以“正向”為主。正常情況即為“正向”，異常情況即為“反向”。功能自動(dòng)化測試主要還是用于回歸測試，回歸測試的目的就是保證新增功能后老功能是否能夠正常運(yùn)作。

手工測試用例可以不用回歸原點(diǎn)，而自動(dòng)化用例往往是必須的。所謂回歸原點(diǎn)就是執(zhí)行的測試用例最終需要恢復(fù)其在執(zhí)行前的初始狀態(tài)。比如添加用戶功能，由于用戶名是唯一的，第一次執(zhí)行時(shí)沒有問題，第二次執(zhí)行時(shí)程序就會(huì)出現(xiàn)用戶名重復(fù)而報(bào)錯(cuò)；這種情況下，就需要在自動(dòng)化測試用例最后增加刪除該用戶的步驟。

自動(dòng)化測試用例與手工測試用例不同，不需要每個(gè)步驟都寫預(yù)期結(jié)果。

五、測試文檔編寫與缺陷管理

測試文檔包括：測試計(jì)劃文檔，測試設(shè)計(jì)規(guī)格文檔，測試用例，軟件缺陷報(bào)告，狀態(tài)報(bào)告。

測試用例對一項(xiàng)特定的軟件產(chǎn)品進(jìn)行測試任務(wù)的描述，體現(xiàn)測試方案、方法、技術(shù)和策略。內(nèi)容包括測試目標(biāo)、測試環(huán)境、輸入數(shù)據(jù)、測試步驟、預(yù)期結(jié)果、測試腳本等，并形成文檔。測試用例一般包括驗(yàn)證測試用例和證偽測試用例；驗(yàn)證測試用例用于驗(yàn)證代碼是否按照預(yù)期執(zhí)行，得到預(yù)期結(jié)果；證偽測試用例驗(yàn)證代碼是否對異常和錯(cuò)誤條件進(jìn)行了適當(dāng)處理。

缺陷報(bào)告包括：問題/錯(cuò)誤的簡單描述，重現(xiàn)的環(huán)境配置要求，保證多次精確重復(fù)的特定輸入，期望結(jié)果與實(shí)際結(jié)果的對比，優(yōu)先級與嚴(yán)重性，對客戶的影響等。

六、常用的測試工具

1 功能測試UFT

UFT自動(dòng)化測試的原理

封裝真實(shí)被測對象并轉(zhuǎn)化為UFT對象到對象庫。

對比對象庫里的對象鑒別屬性和運(yùn)行時(shí)的真實(shí)被測對象的鑒別屬性。

對比結(jié)果一致，則說明對象成功匹配并可以繼續(xù)對該真實(shí)被測對象進(jìn)行后續(xù)操作；如果不一致則報(bào)錯(cuò)，提示對象無法識(shí)別。

封裝對象模型

在UFT里的封裝對象共分兩個(gè)概念，Test Objects（測試對象，TO）和Runtime Objects（運(yùn)行時(shí)對象，RO）。TO就是被被添加到對象庫中的對象，RO就是被測試軟件在運(yùn)行實(shí)際所運(yùn)行的對象。他們都是UFT封裝的對象，TO是為了識(shí)別RO而存在的。

UFT識(shí)別對象通常先在對象庫中添加測試對象，然后在被測軟件運(yùn)行的時(shí)候，根據(jù)腳本中調(diào)用的對象名稱，在對象庫中找到相應(yīng)的測試對象，并根據(jù)這些對象的特征屬性，在被測試軟件中搜索相匹配的正在運(yùn)行的對象，最后就可以對這些實(shí)際運(yùn)行的測試對象進(jìn)行操作。

GetTOProperty()
基本含義：獲取對象庫中某個(gè)對象的某個(gè)屬性的值。
公式：ReturnValue = 對象.GetTOProperty("封裝屬性名")

SetTOProperty()
基本含義：設(shè)置對象庫中某個(gè)對象的某個(gè)屬性的值。
公式：對象.SetTOProperty "封裝屬性名" "封裝屬性值"
注：使用代碼形式的修改對象屬性屬于臨時(shí)性的，只在腳本運(yùn)行時(shí)有效，一旦腳本運(yùn)行結(jié)束，對象庫里的屬性值就會(huì)還原。

GetROProperty()
基本含義：獲取實(shí)際運(yùn)行時(shí)的某個(gè)對象的某個(gè)屬性的值。
公式：ReturnValue = 對象.GetROProperty("封裝屬性名")
注：使用GetROProperty這個(gè)方法來動(dòng)態(tài)獲取實(shí)際運(yùn)行時(shí)的一些確認(rèn)信息，然后和所預(yù)期的測試數(shù)據(jù)做對比。如注冊功能，在提交一些注冊信息以后，一般都要到接下來的確認(rèn)頁面去驗(yàn)證一些信息，這就可以使用GetROProperty來動(dòng)態(tài)獲取實(shí)際運(yùn)行時(shí)的一些確認(rèn)信息。

對象無法識(shí)別的解決辦法

設(shè)置虛擬對象。不推薦，虛擬對象非常脆弱，難以維護(hù)；即使對象沒有發(fā)生變化，但只要對象在界面是那個(gè)的方位發(fā)生變化，虛擬對象就會(huì)識(shí)別失敗。

使用相對坐標(biāo)配合WSH去定位對象。

使用DOM組建接口應(yīng)用技術(shù)。只適用于Web項(xiàng)目。

使用UFT自定義擴(kuò)展SDK Customer來進(jìn)行二次開發(fā)使UFT能夠識(shí)別對象。難度大。

開發(fā)提供專屬插件。

把無法識(shí)別的對象的一些方法封裝到一個(gè)dll中并使用UFT調(diào)用。

數(shù)據(jù)驅(qū)動(dòng)與場景恢復(fù)

數(shù)據(jù)驅(qū)動(dòng)Data Table的應(yīng)用：實(shí)現(xiàn)測試數(shù)據(jù)和腳本業(yè)務(wù)的分離。
場景恢復(fù)：場景恢復(fù)可以應(yīng)對多種類型的錯(cuò)誤并進(jìn)行恢復(fù)操作。

2 性能測試LoadRunner

LoadRunner是一種適用于各種體系架構(gòu)的自動(dòng)負(fù)載測試工具，它能預(yù)測系統(tǒng)行為并優(yōu)化系統(tǒng)性能。LoadRunner的測試對象是整個(gè)企業(yè)的系統(tǒng)，它通過模擬實(shí)際用戶的操作行為和實(shí)時(shí)性能監(jiān)測，來幫助測試人員更快地查找和發(fā)現(xiàn)問題。

輕松創(chuàng)建虛擬用戶。Virtual User Generator能夠生成虛擬用于，以虛擬用戶的方式模擬真實(shí)用戶的業(yè)務(wù)操作行為。它先記錄下業(yè)務(wù)流程，然后將其轉(zhuǎn)化為測試腳本，并進(jìn)行參數(shù)化操作（Data Wizard直接連接數(shù)據(jù)服務(wù)器獲取數(shù)據(jù)）。利用虛擬用戶可以在不同操作系統(tǒng)上同時(shí)產(chǎn)生成千上萬用戶訪問，能極大的減少負(fù)載測試所需要的硬件和人力資源。

創(chuàng)建真實(shí)負(fù)載。建立虛擬用戶后，需要設(shè)定負(fù)載方案、業(yè)務(wù)流程組合和虛擬用戶數(shù)量。用Controller能夠很快地組織多用戶測試方案。

定位性能問題。LoadRunner內(nèi)含一個(gè)實(shí)時(shí)檢測器，在負(fù)載測試過程的任何時(shí)候都能觀察到應(yīng)用系統(tǒng)的運(yùn)行性能。

分析結(jié)果。一旦測試完畢，LoadRunner收集匯總所有的測試數(shù)據(jù)，并提供高級的分析和報(bào)告工具，一遍迅速找到性能問題并做出相應(yīng)的調(diào)整。

七、軟件測試面試題總結(jié)

1. 給你一個(gè)網(wǎng)站，你如何測試？

首先，查找需求說明、網(wǎng)站設(shè)計(jì)等相關(guān)文檔，分析測試需求。

制定測試計(jì)劃，確定測試范圍和測試策略，一般包括以下幾個(gè)部分：功能性測試；界面測試；性能測試；數(shù)據(jù)庫測試；安全性測試；兼容性測試

功能性測試可以包括，但不限于以下幾個(gè)方面：

鏈接測試。鏈接是否正確跳轉(zhuǎn)，是否存在空頁面和無效頁面，是否有不正確的出錯(cuò)信息返回。

提交功能的測試。

多媒體元素是否可以正確加載和顯示。

多語言支持是否能夠正確顯示選擇的語言等。

界面測試可以包括但不限于一下幾個(gè)方面：

頁面是否風(fēng)格統(tǒng)一，美觀

頁面布局是否合理，重點(diǎn)內(nèi)容和熱點(diǎn)內(nèi)容是否突出

控件是否正常使用

對于必須但未安裝的控件，是否提供自動(dòng)下載并安裝的功能

文字檢查

性能測試一般從以下兩個(gè)方面考慮：壓力測試；負(fù)載測試；強(qiáng)度測試

數(shù)據(jù)庫測試要具體決定是否需要開展。數(shù)據(jù)庫一般需要考慮連結(jié)性，對數(shù)據(jù)的存取操作，數(shù)據(jù)內(nèi)容的驗(yàn)證等方面。

安全性測試：

基本的登錄功能的檢查

是否存在溢出錯(cuò)誤，導(dǎo)致系統(tǒng)崩潰或者權(quán)限泄露

相關(guān)開發(fā)語言的常見安全性問題檢查，例如SQL注入等

如果需要高級的安全性測試，確定獲得專業(yè)安全公司的幫助，外包測試，或者獲取支持

兼容性測試，根據(jù)需求說明的內(nèi)容，確定支持的平臺(tái)組合：

瀏覽器的兼容性；

操作系統(tǒng)的兼容性；

軟件平臺(tái)的兼容性；

數(shù)據(jù)庫的兼容性

開展測試，并記錄缺陷。合理的安排調(diào)整測試進(jìn)度，提前獲取測試所需的資源，建立管理體系（例如，需求變更、風(fēng)險(xiǎn)、配置、測試文檔、缺陷報(bào)告、人力資源等內(nèi)容）。

定期評審，對測試進(jìn)行評估和總結(jié)，調(diào)整測試的內(nèi)容。

2. 在搜索引擎中輸入漢字就可以解析到對應(yīng)的域名，請問如何用LoadRunner進(jìn)行測試。

建立測試計(jì)劃，確定測試標(biāo)準(zhǔn)和測試范圍

設(shè)計(jì)典型場景的測試用例，覆蓋常用業(yè)務(wù)流程和不常用的業(yè)務(wù)流程等

根據(jù)測試用例，開發(fā)自動(dòng)測試腳本和場景：

錄制測試腳本：新建一個(gè)腳本（Web/HTML協(xié)議）；點(diǎn)擊錄制按鈕，在彈出的對話框的URL中輸入”about:blank”；在打開的瀏覽器中進(jìn)行正常操作流程后，結(jié)束錄制；調(diào)試腳本并保存，可能要注意到字符集的關(guān)聯(lián)。

設(shè)置測試場景：針對性能設(shè)置測試場景，主要判斷在正常情況下，系統(tǒng)的平均事務(wù)響應(yīng)時(shí)間是否達(dá)標(biāo)；針對壓力負(fù)載設(shè)置測試場景，主要判斷在長時(shí)間處于滿負(fù)荷或者超出系統(tǒng)承載能力的條件下，系統(tǒng)是否會(huì)崩潰；執(zhí)行測試，獲取測試結(jié)果，分析測試結(jié)果。

3. 一臺(tái)客戶端有三百個(gè)客戶與三百個(gè)客戶端有三百個(gè)客戶對服務(wù)器施壓，有什么區(qū)別?

300個(gè)用戶在一個(gè)客戶端上，會(huì)占用客戶機(jī)更多的資源，而影響測試的結(jié)果。線程之間可能發(fā)生干擾，而產(chǎn)生一些異常。300個(gè)用戶在一個(gè)客戶端上，需要更大的帶寬。

IP地址的問題，可能需要使用IP Spoof來繞過服務(wù)器對于單一IP地址最大連接數(shù)的限制。

所有用戶在一個(gè)客戶端上，不必考慮分布式管理的問題；而用戶分布在不同的客戶端上，需要考慮使用控制器來整體調(diào)配不同客戶機(jī)上的用戶。同時(shí)，還需要給予相應(yīng)的權(quán)限配置和防火墻設(shè)置。

4. 目前主要的測試用例設(shè)計(jì)方法是什么？

白盒測試：邏輯覆蓋、循環(huán)覆蓋、基本路徑覆蓋

黑盒測試：邊界值分析法、等價(jià)類劃分、錯(cuò)誤猜測法、因果圖法、狀態(tài)圖法、測試大綱法、隨機(jī)測試、場景法

5. 軟件的安全性應(yīng)從哪幾個(gè)方面去測試？

軟件安全性測試包括程序、數(shù)據(jù)庫安全性測試。根據(jù)系統(tǒng)安全指標(biāo)不同測試策略也不同。

用戶認(rèn)證安全的測試要考慮問題： 明確區(qū)分系統(tǒng)中不同用戶權(quán)限 、系統(tǒng)中會(huì)不會(huì)出現(xiàn)用戶沖突 、系統(tǒng)會(huì)不會(huì)因用戶的權(quán)限的改變造成混亂 、用戶登陸密碼是否是可見、可 、是否可以通過絕對途徑登陸系統(tǒng)（拷貝用戶登陸后的鏈接直接進(jìn)入系統(tǒng)）、用戶退出系統(tǒng)后是否刪除了所有鑒權(quán)標(biāo)記，是否可以使用后退鍵而不通過輸入口令進(jìn)入系統(tǒng) 、系統(tǒng)網(wǎng)絡(luò)安全的測試要考慮問題 、測試采取的防護(hù)措施是否正確裝配好，有關(guān)系統(tǒng)的補(bǔ)丁是否打上 、模擬非授權(quán)攻擊，看防護(hù)系統(tǒng)是否堅(jiān)固 、采用成熟的網(wǎng)絡(luò)漏洞檢查工具檢查系統(tǒng)相關(guān)漏洞（即用最專業(yè)的黑客攻擊工具攻擊試一下，現(xiàn)在最常用的是 NBSI 系列和 IPhacker IP ） 、采用各種木馬檢查工具檢查系統(tǒng)木馬情況 、采用各種防外掛工具檢查系統(tǒng)各組程序的外掛漏洞

數(shù)據(jù)庫安全考慮問題： 系統(tǒng)數(shù)據(jù)是否機(jī)密（比如對銀行系統(tǒng)，這一點(diǎn)就特別重要，一般的網(wǎng)站就沒有太高要求）、系統(tǒng)數(shù)據(jù)的完整性（我剛剛結(jié)束的企業(yè)實(shí)名核查服務(wù)系統(tǒng)中就曾存在數(shù)據(jù)的不完整，對于這個(gè)系統(tǒng)的功能實(shí)現(xiàn)有了障礙） 、系統(tǒng)數(shù)據(jù)可管理性 、系統(tǒng)數(shù)據(jù)的獨(dú)立性 、系統(tǒng)數(shù)據(jù)可備份和恢復(fù)能力（數(shù)據(jù)備份是否完整，可否恢復(fù)，恢復(fù)是否可以完整）

6. 簡述什么是靜態(tài)測試、動(dòng)態(tài)測試、黑盒測試、白盒測試、α測試 β測試

靜態(tài)測試是不運(yùn)行程序本身而尋找程序代碼中可能存在的錯(cuò)誤或評估程序代碼的過程。

動(dòng)態(tài)測試是實(shí)際運(yùn)行被測程序，輸入相應(yīng)的測試實(shí)例，檢查運(yùn)行結(jié)果與預(yù)期結(jié)果的差異，判定執(zhí)行結(jié)果是否符合要求，從而檢驗(yàn)程序的正確性、可靠性和有效性，并分析系統(tǒng)運(yùn)行效率和健壯性等性能。

黑盒測試一般用來確認(rèn)軟件功能的正確性和可操作性,目的是檢測軟件的各個(gè)功能是否能得以實(shí)現(xiàn),把被測試的程序當(dāng)作一個(gè)黑盒,不考慮其內(nèi)部結(jié)構(gòu),在知道該程序的輸入和輸出之間的關(guān)系或程序功能的情況下,依靠軟件規(guī)格說明書來確定測試用例和推斷測試結(jié)果的正確性。

白盒測試根據(jù)軟件內(nèi)部的邏輯結(jié)構(gòu)分析來進(jìn)行測試,是基于代碼的測試，測試人員通過閱讀程序代碼或者通過使用開發(fā)工具中的單步調(diào)試來判斷軟件的質(zhì)量，一般黑盒測試由項(xiàng)目經(jīng)理在程序員開發(fā)中來實(shí)現(xiàn)。

α測試是由一個(gè)用戶在開發(fā)環(huán)境下進(jìn)行的測試，也可以是公司內(nèi)部的用戶在模擬實(shí)際操作環(huán)境下進(jìn)行的受控測試，Alpha測試不能由程序員或測試員完成。

β測試是軟件的多個(gè)用戶在一個(gè)或多個(gè)用戶的實(shí)際使用環(huán)境下進(jìn)行的測試。開發(fā)者通常不在測試現(xiàn)場，Beta測試不能由程序員或測試員完成。

7. 軟件測試分為幾個(gè)階段，各階段的測試策略和要求是什么?

和開發(fā)過程相對應(yīng)，測試過程會(huì)依次經(jīng)歷單元測試、集成測試、系統(tǒng)測試、驗(yàn)收測試四個(gè)主要階段：

單元測試：單元測試是針對軟件設(shè)計(jì)的最小單位––程序模塊甚至代碼段進(jìn)行正確性檢驗(yàn)的測試工作，通常由開發(fā)人員進(jìn)行。

集成測試：集成測試是將模塊按照設(shè)計(jì)要求組裝起來進(jìn)行測試，主要目的是發(fā)現(xiàn)與接口有關(guān)的問題。由于在產(chǎn)品提交到測試部門前，產(chǎn)品開發(fā)小組都要進(jìn)行聯(lián)合調(diào)試，因此在大部分企業(yè)中集成測試是由開發(fā)人員來完成的。

系統(tǒng)測試：系統(tǒng)測試是在集成測試通過后進(jìn)行的，目的是充分運(yùn)行系統(tǒng)，驗(yàn)證各子系統(tǒng)是否都能正常工作并完成設(shè)計(jì)的要求。它主要由測試部門進(jìn)行，是測試部門最大最重要的一個(gè)測試，對產(chǎn)品的質(zhì)量有重大的影響。

驗(yàn)收測試：驗(yàn)收測試以需求階段的《需求規(guī)格說明書》為驗(yàn)收標(biāo)準(zhǔn)，測試時(shí)要求模擬實(shí)際用戶的運(yùn)行環(huán)境。對于實(shí)際項(xiàng)目可以和客戶共同進(jìn)行，對于產(chǎn)品來說就是最后一次的系統(tǒng)測試。測試內(nèi)容為對功能模塊的全面測試，尤其要進(jìn)行文檔測試。

單元測試測試策略：

自頂向下的單元測試策略：比孤立單元測試的成本高很多，不是單元測試的一個(gè)好的選擇。

自底向上的單元測試策略：比較合理的單元測試策略，但測試周期較長。

集成測試的測試策略：

大爆炸集成：適應(yīng)于一個(gè)維護(hù)型項(xiàng)目或被測試系統(tǒng)較小

自頂向下集成：適應(yīng)于產(chǎn)品控制結(jié)構(gòu)比較清晰和穩(wěn)定；高層接口變化較小；底層接口未定義或經(jīng)常可能被修改；產(chǎn)口控制組件具有較大的技術(shù)風(fēng)險(xiǎn)，需要盡早被驗(yàn)證；希望盡早能看到產(chǎn)品的系統(tǒng)功能行為。

自底向上集成：適應(yīng)于底層接口比較穩(wěn)定；高層接口變化比較頻繁；底層組件較早被完成。

基于進(jìn)度的集成

優(yōu)點(diǎn)：具有較高的并行度；能夠有效縮短項(xiàng)目的開發(fā)進(jìn)度。

缺點(diǎn)：樁和驅(qū)動(dòng)工作量較大；有些接口測試不充分；有些測試重復(fù)和浪費(fèi)。

系統(tǒng)測試的測試策略：數(shù)據(jù)和數(shù)據(jù)庫完整性測試；功能測試；用戶界面測試；性能評測；負(fù)載測試；強(qiáng)度測試；容量測試；安全性和訪問控制測試；故障轉(zhuǎn)移和恢復(fù)測試；配置測試；安裝測試；加密測試；可用性測試；版本驗(yàn)證測試；文檔測試

8. 軟件測試各個(gè)階段通常完成什么工作？各個(gè)階段的結(jié)果文件是什么？包括什么內(nèi)容？

單元測試階段：各獨(dú)立單元模塊在與系統(tǒng)地其他部分相隔離的情況下進(jìn)行測試，單元測試針對每一個(gè)程序模塊進(jìn)行正確性校驗(yàn)，檢查各個(gè)程序模塊是否正確地實(shí)現(xiàn)了規(guī)定的功能。生成單元測試報(bào)告，提交缺陷報(bào)告。

集成測試階段：集成測試是在單元測試的基礎(chǔ)上，測試在將所有的軟件單元按照概要設(shè)計(jì)規(guī)格說明的要求組裝成模塊、子系統(tǒng)或系統(tǒng)的過程中各部分工作是否達(dá)到或?qū)崿F(xiàn)相應(yīng)技術(shù)指標(biāo)及要求的活動(dòng)。該階段生成集成測試報(bào)告，提交缺陷報(bào)告。

系統(tǒng)測試階段：將通過確認(rèn)測試的軟件，作為整個(gè)給予計(jì)算機(jī)系統(tǒng)的一個(gè)元素，與計(jì)算機(jī)硬件、外設(shè)、某些支持軟件、數(shù)據(jù)和人員等其他系統(tǒng)元素結(jié)合在一起，在實(shí)際運(yùn)行環(huán)境下，對計(jì)算機(jī)系統(tǒng)進(jìn)行全面的功能覆蓋。該階段需要提交測試總結(jié)和缺陷報(bào)告。

9. 一條軟件缺陷（或者叫Bug）記錄都包含了哪些內(nèi)容？

一條Bug記錄最基本應(yīng)包含：

bug編號；

bug嚴(yán)重級別，優(yōu)先級；

bug產(chǎn)生的模塊；

首先要有bug摘要，闡述bug大體的內(nèi)容；

bug對應(yīng)的版本；

bug詳細(xì)現(xiàn)象描述，包括一些截圖、錄像....等等；

bug出現(xiàn)時(shí)的測試環(huán)境，產(chǎn)生的條件即對應(yīng)操作步驟；

10. 黑盒測試和白盒測試是軟件測試的兩種基本方法，請分別說明各自的優(yōu)點(diǎn)和缺點(diǎn)！

黑盒測試的優(yōu)點(diǎn)有：比較簡單，不需要了解程序內(nèi)部的代碼及實(shí)現(xiàn)；與軟件的內(nèi)部實(shí)現(xiàn)無關(guān)； 從用戶角度出發(fā)，能很容易的知道用戶會(huì)用到哪些功能，會(huì)遇到哪些問題；基于軟件開發(fā)文檔，所以也能知道軟件實(shí)現(xiàn)了文檔中的哪些功能；在做軟件自動(dòng)化測試時(shí)較為方便。

黑盒測試的缺點(diǎn)有：不可能覆蓋所有的代碼，覆蓋率較低，大概只能達(dá)到總代碼量的30%；自動(dòng)化測試的復(fù)用性較低。

白盒測試的優(yōu)點(diǎn)有：幫助軟件測試人員增大代碼的覆蓋率，提高代碼的質(zhì)量，發(fā)現(xiàn)代碼中隱 藏的問題。

白盒測試的缺點(diǎn)有：程序運(yùn)行會(huì)有很多不同的路徑，不可能測試所有的運(yùn)行路徑；測試基于代碼，只能測試開發(fā)人員做的對不對，而不能知道設(shè)計(jì)的正確與否，可能會(huì)漏掉一些功能需求；系統(tǒng)龐大時(shí)，測試開銷會(huì)非常大。

11. 如何測試一個(gè)紙杯？

功能度：用水杯裝水看漏不漏；水能不能被喝到
安全性：杯子有沒有毒或細(xì)菌
可靠性：杯子從不同高度落下的損壞程度
可移植性：杯子在不同的地方、溫度等環(huán)境下是否都可以正常使用
兼容性：杯子是否能夠容納果汁、白水、酒精、汽油等
易用性：杯子是否燙手、是否有防滑措施、是否方便飲用
用戶文檔：使用手冊是否對杯子的用法、限制、使用條件等有詳細(xì)描述
疲勞測試：將杯子盛上水（案例一）放24小時(shí)檢查泄漏時(shí)間和情況；盛上汽油（案例二）放24小時(shí)檢查泄漏時(shí)間和情況等
壓力測試：用根針并在針上面不斷加重量，看壓強(qiáng)多大時(shí)會(huì)穿透

12. 黑盒測試的測試用例常見設(shè)計(jì)方法都有哪些？請分別以具體的例子來說明這些方法在測試用例設(shè)計(jì)工作中的應(yīng)用。

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

2）邊界值分析法：是對等價(jià)類劃分方法的補(bǔ)充。測試工作經(jīng)驗(yàn)告訴我,大量的錯(cuò)誤是發(fā)生在輸入或輸出范圍的邊界上,而不是發(fā)生在輸入輸出范圍的內(nèi)部.因此針對各種邊界情況設(shè)計(jì)測試用例,可以查出更多的錯(cuò)誤.

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

3）錯(cuò)誤猜測法：基于經(jīng)驗(yàn)和直覺推測程序中所有可能存在的各種錯(cuò)誤, 從而有針對性的設(shè)計(jì)測試用例的方法.

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

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

5）正交表分析法：可能因?yàn)榇罅康膮?shù)的組合而引起測試用例數(shù)量上的激增，同時(shí)，這些測試用例并沒有明顯的優(yōu)先級上的差距，而測試人員又無法完成這么多數(shù)量的測試，就可以通過正交表來進(jìn)行縮減一些用例，從而達(dá)到盡量少的用例覆蓋盡量大的范圍的可能性。

6）場景分析方法：指根據(jù)用戶場景來模擬用戶的操作步驟，這個(gè)比較類似因果圖，但是可能執(zhí)行的深度和可行性更好。

7）狀態(tài)圖法：通過輸入條件和系統(tǒng)需求說明得到被測系統(tǒng)的所有狀態(tài)，通過輸入條件和狀態(tài)得出輸出條件；通過輸入條件、輸出條件和狀態(tài)得出被測系統(tǒng)的測試用例。

8）大綱法：大綱法是一種著眼于需求的方法，為了列出各種測試條件，就將需求轉(zhuǎn)換為大綱的形式。大綱表示為樹狀結(jié)構(gòu)，在根和每個(gè)葉子結(jié)點(diǎn)之間存在唯一的路徑。大綱中的每條路徑定義了一個(gè)特定的輸入條件集合，用于定義測試用例。樹中葉子的數(shù)目或大綱中的路徑給出了測試所有功能所需測試用例的大致數(shù)量。

13. 詳細(xì)的描述一個(gè)測試活動(dòng)完整的過程。（供參考，本答案主要是瀑布模型的做法）

項(xiàng)目經(jīng)理通過和客戶的交流，完成需求文檔，由開發(fā)人員和測試人員共同完成需求文檔的評審，評審的內(nèi)容包括：需求描述不清楚的地方和可能有明顯沖突或者無法實(shí)現(xiàn)的功能的地方。項(xiàng)目經(jīng)理通過綜合開發(fā)人員，測試人員以及客戶的意見，完成項(xiàng)目計(jì)劃。然后SQA進(jìn)入項(xiàng)目，開始進(jìn)行統(tǒng)計(jì)和跟蹤

開發(fā)人員根據(jù)需求文檔完成需求分析文檔，測試人員進(jìn)行評審，評審的主要內(nèi)容包括是否有遺漏或雙方理解不同的地方。測試人員完成測試計(jì)劃文檔，測試計(jì)劃包括的內(nèi)容上面有描述。

測試人員根據(jù)修改好的需求分析文檔開始寫測試用例，同時(shí)開發(fā)人員完成概要設(shè)計(jì)文檔，詳細(xì)設(shè)計(jì)文檔。此兩份文檔成為測試人員撰寫測試用例的補(bǔ)充材料。

測試用例完成后，測試和開發(fā)需要進(jìn)行評審。

測試人員搭建環(huán)境

開發(fā)人員提交第一個(gè)版本，可能存在未完成功能，需要說明。測試人員進(jìn)行測試，發(fā)現(xiàn)BUG后提交給BugZilla。

開發(fā)提交第二個(gè)版本，包括Bug Fix以及增加了部分功能，測試人員進(jìn)行測試。

重復(fù)上面的工作，一般是3-4個(gè)版本后BUG數(shù)量減少，達(dá)到出貨的要求。

如果有客戶反饋的問題，需要測試人員協(xié)助重現(xiàn)并重新測試。

14. 說說你對集成測試中自頂向下集成和自底向上集成兩個(gè)策略的理解，要談出它們各自的優(yōu)缺點(diǎn)和主要適應(yīng)于哪種類型測試

自頂向下集成

優(yōu)點(diǎn)：較早地驗(yàn)證了主要控制和判斷點(diǎn)；按深度優(yōu)先可以首先實(shí)現(xiàn)和驗(yàn)證一個(gè)完整的軟件功能；功能較早證實(shí)，帶來信心；只需一個(gè)驅(qū)動(dòng)，減少驅(qū)動(dòng)器開發(fā)的費(fèi)用；支持故障隔離。

缺點(diǎn)：柱的開發(fā)量大；底層驗(yàn)證被推遲；底層組件測試不充分。

適應(yīng)于產(chǎn)品控制結(jié)構(gòu)比較清晰和穩(wěn)定；高層接口變化較小；底層接口未定義或經(jīng)常可能被修改；產(chǎn)口控制組件具有較大的技術(shù)風(fēng)險(xiǎn)，需要盡早被驗(yàn)證；希望盡早能看到產(chǎn)品的系統(tǒng)功能行為。

自底向上集成

優(yōu)點(diǎn)：對底層組件行為較早驗(yàn)證；工作最初可以并行集成，比自頂向下效率高；減少了樁的工作量；支持故障隔離。

缺點(diǎn)：驅(qū)動(dòng)的開發(fā)工作量大；對高層的驗(yàn)證被推遲，設(shè)計(jì)上的錯(cuò)誤不能被及時(shí)發(fā)現(xiàn)。

適應(yīng)于底層接口比較穩(wěn)定；高層接口變化比較頻繁；底層組件較早被完成。

15. 設(shè)計(jì)測試用例時(shí)應(yīng)該考慮哪些方面，即不同的測試用例針對那些方面進(jìn)行測試？

設(shè)計(jì)測試用例時(shí)需要注意的是，除了對整體流程及功能注意外，還要注意強(qiáng)度測試、性能測試、壓力測試、邊界值測試、穩(wěn)定性測試、安全性測試等多方面。（測試用例需要考慮的四個(gè)基本要素是輸入、輸出、操作和測試環(huán)境；另外，測試用例需要考慮的是測試類型（功能、性能、安全……），這部分可以參照TP做答。此外，還需要考慮用例的重要性和優(yōu)先級）

16. 在windows下保存一個(gè)文本文件時(shí)會(huì)彈出保存對話框，如果為文件名建立測試用例，等價(jià)類應(yīng)該怎樣劃分？

單字節(jié)，如A；雙字節(jié)， AA、我我；特殊字符 /‘。‘；、=-等；保留字，如com；文件格式為8.3格式的；文件名格式為非8.3格式的；/,,*等九個(gè)特殊字符。

假設(shè)有一個(gè)文本框要求輸入10個(gè)字符的郵政編碼，對于該文本框應(yīng)該怎樣劃分等價(jià)類？

特殊字符，如10個(gè)*或￥；英文字母，如ABCDefghik；小于十個(gè)字符，如123；大于十個(gè)字符，如11；數(shù)字和其他混合，如123AAAAAAA；空字符；保留字符

17. 單元測試、集成測試、系統(tǒng)測試的側(cè)重點(diǎn)是什么？

單元測試針對的是軟件設(shè)計(jì)的最小單元--程序模塊（面向過程中是函數(shù)、過程；面向?qū)ο笾惺穷悺?#xff09;,進(jìn)行正確性檢驗(yàn)的測試工作,在于發(fā)現(xiàn)每個(gè)程序模塊內(nèi)部可能存在的差錯(cuò).一般有兩個(gè)步驟:人工靜態(tài)檢查\動(dòng)態(tài)執(zhí)行跟蹤

集成測試針對的是通過了單元測試的各個(gè)模塊所集成起來的組件進(jìn)行檢驗(yàn),其主要內(nèi)容是各個(gè)單元模塊之間的接口,以及各個(gè)模塊集成后所實(shí)現(xiàn)的功能.

系統(tǒng)測試針對的是集成好的軟件系統(tǒng)，作為整個(gè)計(jì)算機(jī)系統(tǒng)的一個(gè)元素,與計(jì)算機(jī)硬件\外設(shè)\某些支持軟件\數(shù)據(jù)和人員等其他系統(tǒng)元素結(jié)合在一起,要在實(shí)際的運(yùn)行環(huán)境中,對計(jì)算機(jī)系統(tǒng)進(jìn)行一系列的集成測試和確認(rèn)測試.

18. 你所了解的的軟件測試類型都有哪些，簡單介紹一下。

按測試策略分類：

1、靜態(tài)與動(dòng)態(tài)測試

2、黑盒與白盒測試

3、手工和自動(dòng)測試

4、冒煙測試

5、回歸測試；

按測試階段分類：單元測試、集成測試、系統(tǒng)測試；

其他常見測試方法：

1、功能測試

2、性能測試

3、壓力測試

4、負(fù)載測試

5、易用性測試

6、安裝測試

7、界面測試

8、配置測試

9、文檔測試

10、兼容性測試

11、安全性測試

12、恢復(fù)測試

19. 您認(rèn)為做好測試用例設(shè)計(jì)工作的關(guān)鍵是什么？

白盒測試用例設(shè)計(jì)的關(guān)鍵是以較少的用例覆蓋盡可能多的內(nèi)部程序邏輯結(jié)果

黑盒法用例設(shè)計(jì)的關(guān)鍵同樣也是以較少的用例覆蓋模塊輸出和輸入接口。不可能做到完全測試，以最少的用例在合理的時(shí)間內(nèi)發(fā)現(xiàn)最多的問題

20. 一套完整的測試應(yīng)該由哪些階段組成？

可行性分析、需求分析、概要設(shè)計(jì)、詳細(xì)設(shè)計(jì)、編碼、單元測試、集成測試、系統(tǒng)測試、驗(yàn)收測試

21. 面向?qū)ο蟮臏y試用例設(shè)計(jì)有幾種方法？如何實(shí)現(xiàn)？

給類中的每個(gè)構(gòu)造函數(shù)設(shè)計(jì)一組測試用例

組合類中的類變量、實(shí)例變量

組合類中的各種方法

根據(jù)前置條件和后置條件設(shè)計(jì)測試用例

根據(jù)代碼設(shè)計(jì)測試用例

總結(jié)

以上是生活随笔為你收集整理的今天有个做测试的朋友跳槽涨薪20k，我惊呆了的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。