1.測(cè)試與軟件模型

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

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

1.1 瀑布模型

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

• 各個(gè)階段的劃分完全固定，階段之間產(chǎn)生大量的文檔，極大地增加了工作量；
• 由于開發(fā)模型是線性的，用戶只有等到整個(gè)過(guò)程的末期才能見到開發(fā)成果，從而增加了開發(fā)的風(fēng)險(xiǎn)；
• 早期的錯(cuò)誤可能要等到開發(fā)后期的測(cè)試階段才能發(fā)現(xiàn)，進(jìn)而帶來(lái)嚴(yán)重的后果。

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

1.2 迭代開發(fā)模型

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

• 降低風(fēng)險(xiǎn)。如果開發(fā)人員重復(fù)某個(gè)迭代，那么損失只是這一個(gè)開發(fā)有誤的迭代的花費(fèi)。
• 適應(yīng)需求變更。由于用戶的需求并不能在一開始就作出完全的界定，它們通常是在后續(xù)階段中不斷細(xì)化的。
• 持續(xù)的測(cè)試與集成，降低后期的工作量與風(fēng)險(xiǎn)。

1.3 螺旋開發(fā)模型

螺旋開發(fā)，將瀑布模型和快速原型模型結(jié)合起來(lái)，強(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)分析：分析評(píng)估所選方案，考慮如何識(shí)別和消除風(fēng)險(xiǎn)；
• 實(shí)施工程：實(shí)施軟件開發(fā)和驗(yàn)證；
• 客戶評(píng)估：評(píng)價(jià)開發(fā)工作，提出修正建議，制定下一步計(jì)劃。

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

1.4 敏捷開發(fā)模型

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

• 個(gè)體和互動(dòng)重于流程和工具。
• 可工作的軟件重于求全而完備的文檔。
• 客戶協(xié)作重于合同談判。
• 應(yīng)對(duì)變化重于遵循計(jì)劃。

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

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

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

1.5 四種模型比較

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

迭代式開發(fā)，不要求每一個(gè)階段的任務(wù)做的都是最完美的，而是明明知道還有很多不足的地方，卻偏偏不去完善它，而是把主要功能先搭建起來(lái)為目的，以最短的時(shí)間，最少的損失先完成一個(gè)“不完美的成果物”直至提交。然后再通過(guò)客戶或用戶的反饋信息，在這個(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)評(píng)估。

敏捷開發(fā)，相比迭代式開發(fā)兩者都強(qiáng)調(diào)在較短的開發(fā)周期提交軟件，但是，敏捷開發(fā)的周期可能更短，并且更加強(qiáng)調(diào)隊(duì)伍中的高度協(xié)作。敏捷方法有時(shí)候被誤認(rèn)為是無(wú)計(jì)劃性和紀(jì)律性的方法，實(shí)際上更確切的說(shuō)法是敏捷方法強(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ì)可能很難確切描述未來(lái)將會(huì)如何變化。

1.6 軟件開發(fā)過(guò)程中的測(cè)試

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

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

1.7 軟件測(cè)試的目的與原則

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

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

• 測(cè)試是程序的執(zhí)行過(guò)程，目的在于發(fā)現(xiàn)錯(cuò)誤
• 一個(gè)成功的測(cè)試用例在于發(fā)現(xiàn)至今未發(fā)現(xiàn)的錯(cuò)誤
• 一個(gè)成功的測(cè)試是發(fā)現(xiàn)了至今未發(fā)現(xiàn)的錯(cuò)誤的測(cè)試
• 確保產(chǎn)品完成了它所承諾或公布的功能，并且用戶可以訪問(wèn)到的功能都有明確的書面說(shuō)明。
• 確保產(chǎn)品滿足性能和效率的要求
• 確保產(chǎn)品是健壯的和適應(yīng)用戶環(huán)境的

軟件測(cè)試的原則：

• 測(cè)試用例中一個(gè)必須部分是對(duì)預(yù)期輸出或接口進(jìn)行定義
• 程序員應(yīng)避免測(cè)試自己編寫的程序
• 編寫軟件的組織不應(yīng)當(dāng)測(cè)試自己編寫的軟件
• 應(yīng)當(dāng)徹底檢查每個(gè)測(cè)試的執(zhí)行結(jié)果
• 測(cè)試用例的編寫不僅應(yīng)當(dāng)根據(jù)有效和預(yù)料到的輸入情況，而且也應(yīng)當(dāng)根據(jù)無(wú)效和未預(yù)料到的輸入情況
• 檢查程序是否“未做其應(yīng)該做的”僅是測(cè)試的一半，測(cè)試的另一半是檢查程序是否“做了其不應(yīng)該做的”
• 應(yīng)避免測(cè)試用例用后即棄，除非軟件本身就是個(gè)一次性的軟件
• 計(jì)劃測(cè)試工作時(shí)不應(yīng)默許假定不會(huì)發(fā)現(xiàn)錯(cuò)誤
• 程序某部分存在更多錯(cuò)誤的可能性，與該部分已經(jīng)發(fā)現(xiàn)錯(cuò)誤的數(shù)量成正比

1.8 軟件的可測(cè)性

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

• 緊耦合。不把大半個(gè)系統(tǒng)實(shí)例化就無(wú)法測(cè)試。
• 弱內(nèi)聚。這個(gè)類實(shí)現(xiàn)了太多功能，導(dǎo)致測(cè)試非常復(fù)雜。
• 冗余。同一個(gè)方法在多處使用，每一處都得測(cè)。

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

2. 測(cè)試用例設(shè)計(jì)

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

2.1 黑盒測(cè)試與白盒測(cè)試

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

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

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

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

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

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

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

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

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

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

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

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

2.3.1 等價(jià)類劃分

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

• 在輸入條件規(guī)定了取值范圍或值的個(gè)數(shù)的情況下,則可以確立一個(gè)有效等價(jià)類和兩個(gè)無(wú)效等價(jià)類。如：輸入值是學(xué)生成績(jī)，范圍是0～100；則小于0和大于100的為無(wú)效等價(jià)類，0~100之間的為有效等價(jià)類。
• 在輸入條件規(guī)定了輸入值的集合或者規(guī)定了"必須如何"的條件的情況下，可確立一個(gè)有效等價(jià)類和一個(gè)無(wú)效等價(jià)類。
• 在輸入條件是一個(gè)布爾量的情況下,可確定一個(gè)有效等價(jià)類和一個(gè)無(wú)效等價(jià)類。
• 在規(guī)定了輸入數(shù)據(jù)的一組值（假定n個(gè)）,并且程序要對(duì)每一個(gè)輸入值分別處理的情況下,可確立n個(gè)有效等價(jià)類和一個(gè)無(wú)效等價(jià)類。例：輸入條件說(shuō)明學(xué)歷可為:專科、本科、碩士、博士四種之一，則分別取這四種這四個(gè)值作為四個(gè)有效等價(jià)類，另外把四種學(xué)歷之外的任何學(xué)歷作為無(wú)效等價(jià)類。
• 在規(guī)定了輸入數(shù)據(jù)必須遵守的規(guī)則的情況下,可確立一個(gè)有效等價(jià)類（符合規(guī)則）和若干個(gè)無(wú)效等價(jià)類（從不同角度違反規(guī)則）；
• 在確知已劃分的等價(jià)類中各元素在程序處理中的方式不同的情況下,則應(yīng)再將該等價(jià)類進(jìn)一步的劃分為更小的等價(jià)類。

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

1. 為每一個(gè)等價(jià)類規(guī)定一個(gè)唯一的編號(hào)；
2. 設(shè)計(jì)一個(gè)新的測(cè)試用例,使其盡可能多地覆蓋尚未被覆蓋地有效等價(jià)類,重復(fù)這一步，直到所有的有效等價(jià)類都被覆蓋為止；
3. 設(shè)計(jì)一個(gè)新的測(cè)試用例,使其僅覆蓋一個(gè)尚未被覆蓋的無(wú)效等價(jià)類,重復(fù)這一步，直到所有的無(wú)效等價(jià)類都被覆蓋為止。

2.3.2 邊界值分析

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

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

2.3.3 因果圖

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

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

2.3.4 錯(cuò)誤測(cè)試

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

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

1. 輸入的線性表為空表；
2. 表中只含有一個(gè)元素；
3. 輸入表中所有元素已排好序；
4. 輸入表已按逆序排好；
5. 輸入表中部分或全部元素相同。

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

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

1. 在任何情況下都必須使用邊界值分析方法，經(jīng)驗(yàn)表明用這種方法設(shè)計(jì)出測(cè)試用例發(fā)現(xiàn)程序錯(cuò)誤的能力最強(qiáng)。
2. 必要時(shí)用等價(jià)類劃分方法補(bǔ)充一些測(cè)試用例。
3. 用錯(cuò)誤推測(cè)法再追加一些測(cè)試用例。
4. 對(duì)照程序邏輯，檢查已設(shè)計(jì)出的測(cè)試用例的邏輯覆蓋程度，如果沒有達(dá)到要求的覆蓋標(biāo)準(zhǔn)，應(yīng)當(dāng)再補(bǔ)充足夠的測(cè)試用例。
5. 如果程序的功能說(shuō)明中含有輸入條件的組合情況，則一開始就可選用因果圖法。

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

3. 軟件測(cè)試類型

單元測(cè)試

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

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

集成測(cè)試

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

功能測(cè)試

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

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

系統(tǒng)測(cè)試

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

1. 能力測(cè)試：是判斷目標(biāo)文檔提及的每一項(xiàng)能力（或功能）是否都確實(shí)已經(jīng)實(shí)現(xiàn)。
2. 容量測(cè)試：使程序經(jīng)受大容量數(shù)據(jù)的檢驗(yàn)。容量測(cè)試的目的是為了證明程序不能處理目標(biāo)文檔中規(guī)定的數(shù)據(jù)容量。
3. 強(qiáng)度測(cè)試：使程序承受高負(fù)載或強(qiáng)度的檢驗(yàn)。所謂高強(qiáng)度是指在很短的時(shí)間間隔內(nèi)達(dá)到的數(shù)據(jù)或操作的數(shù)量峰值。
4. 易用性測(cè)試：試圖發(fā)現(xiàn)人為因素或易用性的問(wèn)題。
5. 安全性測(cè)試：設(shè)計(jì)測(cè)試用例來(lái)突破程序安全檢查的過(guò)程。舉例來(lái)說(shuō)，我們可以設(shè)計(jì)測(cè)試用例來(lái)規(guī)避操作系統(tǒng)的內(nèi)存保護(hù)機(jī)制，破壞數(shù)據(jù)庫(kù)管理系統(tǒng)的數(shù)據(jù)安全機(jī)制。
6. 性能測(cè)試：很多軟件都有特定的性能或效率目標(biāo)，這終特性描述為在特定負(fù)載和配置環(huán)境下程序的響應(yīng)時(shí)間和吞吐率。
7. 存儲(chǔ)測(cè)試：
8. 配置測(cè)試：
9. 兼容性測(cè)試。
10. 安裝測(cè)試：有些類型的軟件系統(tǒng)安裝過(guò)程非常復(fù)雜，測(cè)試安裝過(guò)程是系統(tǒng)測(cè)試中的一個(gè)重要部分。對(duì)于包含在軟件包中的自動(dòng)安裝系統(tǒng)而言，這尤其重要。安裝程序如果出現(xiàn)故障，會(huì)影響用戶對(duì)軟件的成功體驗(yàn)。
11. 可靠性測(cè)試：所有類型的測(cè)試都是為了提高軟件的可靠性，但是如果軟件的目標(biāo)中包含了對(duì)可靠性的特別描述，就必須設(shè)計(jì)專門的可靠性測(cè)試。
12. 可恢復(fù)性測(cè)試：諸如操作系統(tǒng)、數(shù)據(jù)庫(kù)管理系統(tǒng)和遠(yuǎn)程處理系統(tǒng)等軟件通常都有可恢復(fù)性目標(biāo)，說(shuō)明系統(tǒng)如何從程序錯(cuò)誤、硬件失效和數(shù)據(jù)錯(cuò)誤中恢復(fù)過(guò)來(lái)。系統(tǒng)測(cè)試的一個(gè)目標(biāo)是證明這些恢復(fù)機(jī)制不能夠正確發(fā)揮作用。我們可以故意將程序錯(cuò)誤置入某個(gè)系統(tǒng)中，判斷系統(tǒng)是否可以從中恢復(fù)。
13. 適用性測(cè)試
14. 文檔測(cè)試：檢查用戶文檔的正確性。用戶文檔應(yīng)成為審查的對(duì)象，檢查其正確性和清晰性。在文檔中描述的任何范例應(yīng)編成測(cè)試用例，并提交給程序。

4. 自動(dòng)化測(cè)試

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

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

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

4.1 自動(dòng)化測(cè)試的優(yōu)勢(shì)

• 回歸測(cè)試更方便、可靠。由于回歸測(cè)試的業(yè)務(wù)流程操作和測(cè)試用例是預(yù)先設(shè)計(jì)好的，預(yù)期結(jié)果也是完全在項(xiàng)目人員掌握之中的，將回歸測(cè)試交給計(jì)算機(jī)自動(dòng)運(yùn)行，可以極大提高測(cè)試效率，縮短回歸測(cè)試時(shí)間。
• 可運(yùn)行更多更繁瑣的測(cè)試，且快速高效。
• 可執(zhí)行一些對(duì)于手工測(cè)試來(lái)說(shuō)相當(dāng)困難或根本做不到的測(cè)試。比如，對(duì)大量用戶的并發(fā)測(cè)試等。
• 具有一致性和可重復(fù)性的特點(diǎn)。
• 自動(dòng)化測(cè)試腳本完全具有復(fù)用性。由于自動(dòng)化測(cè)試通常以腳本的方式實(shí)現(xiàn)，這樣在不同的版本之間，就可能只需要做少量的維護(hù)甚至不做任何修改，實(shí)現(xiàn)在不同的測(cè)試版本中使用相同的測(cè)試腳本執(zhí)行相同的測(cè)試用例。

4.2 自動(dòng)化測(cè)試的劣勢(shì)

• 永遠(yuǎn)不可能完全取代手工測(cè)試。自動(dòng)化測(cè)試無(wú)法做到手工測(cè)試的覆蓋率，不是每個(gè)測(cè)試用例都適合轉(zhuǎn)換成自動(dòng)化測(cè)試用例的。
• 無(wú)法保證測(cè)試的正確性。測(cè)試腳本本身也可能存在缺陷。
• 手工測(cè)試能發(fā)現(xiàn)的缺陷遠(yuǎn)比自動(dòng)化測(cè)試多。自動(dòng)化測(cè)試幾乎是無(wú)法發(fā)現(xiàn)新缺陷。
• 自動(dòng)化測(cè)試工具是死的，它本身沒有任何想象力。
• 自動(dòng)化測(cè)試對(duì)測(cè)試工程師來(lái)說(shuō)必須有一定的開發(fā)技術(shù)背景。

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

• 項(xiàng)目周期長(zhǎng)，系統(tǒng)版本不斷。主要在于回歸測(cè)試。
• 需求變更不頻繁。
• 系統(tǒng)中的測(cè)試對(duì)象基本可以正常識(shí)別，不存在大批量第三方控件。
• 需要反復(fù)測(cè)試，如可靠性測(cè)試需要進(jìn)行上千次的系統(tǒng)測(cè)試。

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

• 項(xiàng)目周期短，需求變更頻繁。項(xiàng)目周期短的情況下引入自動(dòng)化測(cè)試，不但收不回成本，而且會(huì)延長(zhǎng)產(chǎn)品的發(fā)布時(shí)間。需求頻繁改變會(huì)使老功能的業(yè)務(wù)邏輯被修改，從而導(dǎo)致相應(yīng)的測(cè)試腳本也需相應(yīng)修改。
• 軟件版本還沒穩(wěn)定。
• 多數(shù)對(duì)象無(wú)法識(shí)別以及腳本維護(hù)頻繁與艱難。

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

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

• 自動(dòng)化測(cè)試用例的范圍往往是核心業(yè)務(wù)流程或者重復(fù)執(zhí)行率較高的。并不需要覆蓋所有的手工測(cè)試用例。
• 自動(dòng)化測(cè)試用例的選擇一般以“正向”為主。正常情況即為“正向”，異常情況即為“反向”。功能自動(dòng)化測(cè)試主要還是用于回歸測(cè)試，回歸測(cè)試的目的就是保證新增功能后老功能是否能夠正常運(yùn)作。
• 手工測(cè)試用例可以不用回歸原點(diǎn)，而自動(dòng)化用例往往是必須的。所謂回歸原點(diǎn)就是執(zhí)行的測(cè)試用例最終需要恢復(fù)其在執(zhí)行前的初始狀態(tài)。比如添加用戶功能，由于用戶名是唯一的，第一次執(zhí)行時(shí)沒有問(wèn)題，第二次執(zhí)行時(shí)程序就會(huì)出現(xiàn)用戶名重復(fù)而報(bào)錯(cuò)；這種情況下，就需要在自動(dòng)化測(cè)試用例最后增加刪除該用戶的步驟。
• 自動(dòng)化測(cè)試用例與手工測(cè)試用例不同，不需要每個(gè)步驟都寫預(yù)期結(jié)果。

5. 測(cè)試文檔編寫與缺陷管理

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

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

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

6. 常用的測(cè)試工具

6.1 功能測(cè)試UFT

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

1. 封裝真實(shí)被測(cè)對(duì)象并轉(zhuǎn)化為UFT對(duì)象到對(duì)象庫(kù)。
2. 對(duì)比對(duì)象庫(kù)里的對(duì)象鑒別屬性和運(yùn)行時(shí)的真實(shí)被測(cè)對(duì)象的鑒別屬性。
3. 對(duì)比結(jié)果一致，則說(shuō)明對(duì)象成功匹配并可以繼續(xù)對(duì)該真實(shí)被測(cè)對(duì)象進(jìn)行后續(xù)操作；如果不一致則報(bào)錯(cuò)，提示對(duì)象無(wú)法識(shí)別。

封裝對(duì)象模型

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

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

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

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

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

對(duì)象無(wú)法識(shí)別的解決辦法

1. 設(shè)置虛擬對(duì)象。不推薦，虛擬對(duì)象非常脆弱，難以維護(hù)；即使對(duì)象沒有發(fā)生變化，但只要對(duì)象在界面是那個(gè)的方位發(fā)生變化，虛擬對(duì)象就會(huì)識(shí)別失敗。
2. 使用相對(duì)坐標(biāo)配合WSH去定位對(duì)象。
3. 使用DOM組建接口應(yīng)用技術(shù)。只適用于Web項(xiàng)目。
4. 使用UFT自定義擴(kuò)展SDK Customer來(lái)進(jìn)行二次開發(fā)使UFT能夠識(shí)別對(duì)象。難度大。
5. 開發(fā)提供專屬插件。
6. 把無(wú)法識(shí)別的對(duì)象的一些方法封裝到一個(gè)dll中并使用UFT調(diào)用。

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

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

6.2 性能測(cè)試LoadRunner

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

1. 輕松創(chuàng)建虛擬用戶。Virtual User Generator能夠生成虛擬用于，以虛擬用戶的方式模擬真實(shí)用戶的業(yè)務(wù)操作行為。它先記錄下業(yè)務(wù)流程，然后將其轉(zhuǎn)化為測(cè)試腳本，并進(jìn)行參數(shù)化操作（Data Wizard直接連接數(shù)據(jù)服務(wù)器獲取數(shù)據(jù)）。利用虛擬用戶可以在不同操作系統(tǒng)上同時(shí)產(chǎn)生成千上萬(wàn)用戶訪問(wèn)，能極大的減少負(fù)載測(cè)試所需要的硬件和人力資源。
2. 創(chuàng)建真實(shí)負(fù)載。建立虛擬用戶后，需要設(shè)定負(fù)載方案、業(yè)務(wù)流程組合和虛擬用戶數(shù)量。用Controller能夠很快地組織多用戶測(cè)試方案。
3. 定位性能問(wèn)題。LoadRunner內(nèi)含一個(gè)實(shí)時(shí)檢測(cè)器，在負(fù)載測(cè)試過(guò)程的任何時(shí)候都能觀察到應(yīng)用系統(tǒng)的運(yùn)行性能。
4. 分析結(jié)果。一旦測(cè)試完畢，LoadRunner收集匯總所有的測(cè)試數(shù)據(jù)，并提供高級(jí)的分析和報(bào)告工具，一遍迅速找到性能問(wèn)題并做出相應(yīng)的調(diào)整。

7. 軟件測(cè)試面試題總結(jié)

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

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

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

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

• 鏈接測(cè)試。鏈接是否正確跳轉(zhuǎn)，是否存在空頁(yè)面和無(wú)效頁(yè)面，是否有不正確的出錯(cuò)信息返回。
• 提交功能的測(cè)試。
• 多媒體元素是否可以正確加載和顯示。
• 多語(yǔ)言支持是否能夠正確顯示選擇的語(yǔ)言等。

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

• 頁(yè)面是否風(fēng)格統(tǒng)一，美觀
• 頁(yè)面布局是否合理，重點(diǎn)內(nèi)容和熱點(diǎn)內(nèi)容是否突出
• 控件是否正常使用
• 對(duì)于必須但未安裝的控件，是否提供自動(dòng)下載并安裝的功能
• 文字檢查

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

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

安全性測(cè)試：

• 基本的登錄功能的檢查
• 是否存在溢出錯(cuò)誤，導(dǎo)致系統(tǒng)崩潰或者權(quán)限泄露
• 相關(guān)開發(fā)語(yǔ)言的常見安全性問(wèn)題檢查，例如SQL注入等
• 如果需要高級(jí)的安全性測(cè)試，確定獲得專業(yè)安全公司的幫助，外包測(cè)試，或者獲取支持

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

• 瀏覽器的兼容性；
• 操作系統(tǒng)的兼容性；
• 軟件平臺(tái)的兼容性；
• 數(shù)據(jù)庫(kù)的兼容性

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

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

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

• 建立測(cè)試計(jì)劃，確定測(cè)試標(biāo)準(zhǔn)和測(cè)試范圍
• 設(shè)計(jì)典型場(chǎng)景的測(cè)試用例，覆蓋常用業(yè)務(wù)流程和不常用的業(yè)務(wù)流程等
• 根據(jù)測(cè)試用例，開發(fā)自動(dòng)測(cè)試腳本和場(chǎng)景：

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

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

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

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

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

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

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

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

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

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

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

用戶認(rèn)證安全的測(cè)試要考慮問(wèn)題： 明確區(qū)分系統(tǒng)中不同用戶權(quán)限 、系統(tǒng)中會(huì)不會(huì)出現(xiàn)用戶沖突 、系統(tǒng)會(huì)不會(huì)因用戶的權(quán)限的改變?cè)斐苫靵y 、用戶登陸密碼是否是可見、可 、是否可以通過(guò)絕對(duì)途徑登陸系統(tǒng)（拷貝用戶登陸后的鏈接直接進(jìn)入系統(tǒng)）、用戶退出系統(tǒng)后是否刪除了所有鑒權(quán)標(biāo)記，是否可以使用后退鍵而不通過(guò)輸入口令進(jìn)入系統(tǒng) 、系統(tǒng)網(wǎng)絡(luò)安全的測(cè)試要考慮問(wèn)題 、測(cè)試采取的防護(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ù)庫(kù)安全考慮問(wèn)題： 系統(tǒng)數(shù)據(jù)是否機(jī)密（比如對(duì)銀行系統(tǒng)，這一點(diǎn)就特別重要，一般的網(wǎng)站就沒有太高要求）、系統(tǒng)數(shù)據(jù)的完整性（我剛剛結(jié)束的企業(yè)實(shí)名核查服務(wù)系統(tǒng)中就曾存在數(shù)據(jù)的不完整，對(duì)于這個(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. 簡(jiǎn)述什么是靜態(tài)測(cè)試、動(dòng)態(tài)測(cè)試、黑盒測(cè)試、白盒測(cè)試、α測(cè)試 β測(cè)試

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

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

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

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

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

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

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

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

• 單元測(cè)試：?jiǎn)卧獪y(cè)試是針對(duì)軟件設(shè)計(jì)的最小單位––程序模塊甚至代碼段進(jìn)行正確性檢驗(yàn)的測(cè)試工作，通常由開發(fā)人員進(jìn)行。
• 集成測(cè)試：集成測(cè)試是將模塊按照設(shè)計(jì)要求組裝起來(lái)進(jìn)行測(cè)試，主要目的是發(fā)現(xiàn)與接口有關(guān)的問(wèn)題。由于在產(chǎn)品提交到測(cè)試部門前，產(chǎn)品開發(fā)小組都要進(jìn)行聯(lián)合調(diào)試，因此在大部分企業(yè)中集成測(cè)試是由開發(fā)人員來(lái)完成的。
• 系統(tǒng)測(cè)試：系統(tǒng)測(cè)試是在集成測(cè)試通過(guò)后進(jìn)行的，目的是充分運(yùn)行系統(tǒng)，驗(yàn)證各子系統(tǒng)是否都能正常工作并完成設(shè)計(jì)的要求。它主要由測(cè)試部門進(jìn)行，是測(cè)試部門最大最重要的一個(gè)測(cè)試，對(duì)產(chǎn)品的質(zhì)量有重大的影響。
• 驗(yàn)收測(cè)試：驗(yàn)收測(cè)試以需求階段的《需求規(guī)格說(shuō)明書》為驗(yàn)收標(biāo)準(zhǔn)，測(cè)試時(shí)要求模擬實(shí)際用戶的運(yùn)行環(huán)境。對(duì)于實(shí)際項(xiàng)目可以和客戶共同進(jìn)行，對(duì)于產(chǎn)品來(lái)說(shuō)就是最后一次的系統(tǒng)測(cè)試。測(cè)試內(nèi)容為對(duì)功能模塊的全面測(cè)試，尤其要進(jìn)行文檔測(cè)試。

單元測(cè)試測(cè)試策略：

• 自頂向下的單元測(cè)試策略：比孤立單元測(cè)試的成本高很多，不是單元測(cè)試的一個(gè)好的選擇。
• 自底向上的單元測(cè)試策略：比較合理的單元測(cè)試策略，但測(cè)試周期較長(zhǎng)。

集成測(cè)試的測(cè)試策略：

• 大爆炸集成：適應(yīng)于一個(gè)維護(hù)型項(xiàng)目或被測(cè)試系統(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)工作量較大；有些接口測(cè)試不充分；有些測(cè)試重復(fù)和浪費(fèi)。

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

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

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

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

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

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

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

• bug編號(hào)；
• bug嚴(yán)重級(jí)別，優(yōu)先級(jí)；
• bug產(chǎn)生的模塊；
• 首先要有bug摘要，闡述bug大體的內(nèi)容；
• bug對(duì)應(yīng)的版本；
• bug詳細(xì)現(xiàn)象描述，包括一些截圖、錄像....等等；
• bug出現(xiàn)時(shí)的測(cè)試環(huán)境，產(chǎn)生的條件即對(duì)應(yīng)操作步驟；

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

自頂向下集成

• 優(yōu)點(diǎn)：較早地驗(yàn)證了主要控制和判斷點(diǎn)；按深度優(yōu)先可以首先實(shí)現(xiàn)和驗(yàn)證一個(gè)完整的軟件功能；功能較早證實(shí)，帶來(lái)信心；只需一個(gè)驅(qū)動(dòng)，減少驅(qū)動(dòng)器開發(fā)的費(fèi)用；支持故障隔離。
• 缺點(diǎn)：柱的開發(fā)量大；底層驗(yàn)證被推遲；底層組件測(cè)試不充分。
• 適應(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)：對(duì)底層組件行為較早驗(yàn)證；工作最初可以并行集成，比自頂向下效率高；減少了樁的工作量；支持故障隔離。
• 缺點(diǎn)：驅(qū)動(dòng)的開發(fā)工作量大；對(duì)高層的驗(yàn)證被推遲，設(shè)計(jì)上的錯(cuò)誤不能被及時(shí)發(fā)現(xiàn)。
• 適應(yīng)于底層接口比較穩(wěn)定；高層接口變化比較頻繁；底層組件較早被完成。

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

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

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

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

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

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

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

• 單元測(cè)試針對(duì)的是軟件設(shè)計(jì)的最小單元--程序模塊（面向過(guò)程中是函數(shù)、過(guò)程；面向?qū)ο笾惺穷?。?進(jìn)行正確性檢驗(yàn)的測(cè)試工作,在于發(fā)現(xiàn)每個(gè)程序模塊內(nèi)部可能存在的差錯(cuò).一般有兩個(gè)步驟:人工靜態(tài)檢查\動(dòng)態(tài)執(zhí)行跟蹤
• 集成測(cè)試針對(duì)的是通過(guò)了單元測(cè)試的各個(gè)模塊所集成起來(lái)的組件進(jìn)行檢驗(yàn),其主要內(nèi)容是各個(gè)單元模塊之間的接口,以及各個(gè)模塊集成后所實(shí)現(xiàn)的功能.
• 系統(tǒng)測(cè)試針對(duì)的是集成好的軟件系統(tǒng)，作為整個(gè)計(jì)算機(jī)系統(tǒng)的一個(gè)元素,與計(jì)算機(jī)硬件\外設(shè)\某些支持軟件\數(shù)據(jù)和人員等其他系統(tǒng)元素結(jié)合在一起,要在實(shí)際的運(yùn)行環(huán)境中,對(duì)計(jì)算機(jī)系統(tǒng)進(jìn)行一系列的集成測(cè)試和確認(rèn)測(cè)試.

17. 你所了解的的軟件測(cè)試類型都有哪些，簡(jiǎn)單介紹一下。

按測(cè)試策略分類：1、靜態(tài)與動(dòng)態(tài)測(cè)試2、黑盒與白盒測(cè)試 3、手工和自動(dòng)測(cè)試 4、冒煙測(cè)試 5、回歸測(cè)試；

按測(cè)試階段分類：?jiǎn)卧獪y(cè)試、集成測(cè)試、系統(tǒng)測(cè)試；

其他常見測(cè)試方法：1、功能測(cè)試 2、性能測(cè)試 3、壓力測(cè)試 4、負(fù)載測(cè)試 5、易用性測(cè)試 6、安裝測(cè)試 7、界面測(cè)試 8、配置測(cè)試 9、文檔測(cè)試 10、兼容性測(cè)試 11、安全性測(cè)試 12、恢復(fù)測(cè)試

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

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

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

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

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

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

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

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

組合類中的各種方法

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

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