?目錄

“中年危機”，更可怕的是自身危機

為什么會有危機感？

學習資源推薦

軟件測試所有方向的學習路線

?一、測試與軟件模型

二、測試用例設計

三、軟件測試類型

四、自動化測試

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

六、常用的測試工具

七、軟件測試面試題總結

---

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

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

“中年危機”，更可怕的是自身危機

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

為什么會有危機感？

從知識層面說：當你知之甚少，觀看龐大的信息流，超出你的認知上限，你會產生知識焦慮和危機感。解決的辦法就是學習，看系統的書籍，努力提升自我，根據自己的能力設定合理的計劃并去實踐。

實踐很重要，你會在這個過程中有所提升，提升的程度取決于你的專注程度和堅持不懈的結果，在學習和實踐的過程中會轉移你的危機意識（強烈的危機意識是一種溢出的精神能量，并且會造成焦慮以及不安）。

學習資源推薦

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

軟件測試所有方向的學習路線

?一、測試與軟件模型

軟件開發生命周期模型指的是軟件開發全過程、活動和任務的結構性框架。軟件項目的開發包括：需求、設計、編碼、測試、穩定、部署、維護等階段。

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

1 瀑布模型

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

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

由于開發模型是線性的，用戶只有等到整個過程的末期才能見到開發成果，從而增加了開發的風險；

早期的錯誤可能要等到開發后期的測試階段才能發現，進而帶來嚴重的后果。

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

2 迭代開發模型

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

降低風險。如果開發人員重復某個迭代，那么損失只是這一個開發有誤的迭代的花費。

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

持續的測試與集成，降低后期的工作量與風險。

3 螺旋開發模型

螺旋開發，將瀑布模型和快速原型模型結合起來，強調了其他模型所忽視的風險分析，特別適合于大型復雜的系統。“螺旋模型”剛開始規模很小，當項目被定義得更好、更穩定時，逐漸展開。 “螺旋模型”的核心就在于不需要在剛開始的時候就把所有事情都定義的清清楚楚。您輕松上陣，定義最重要的功能，實現它，然后聽取客戶的意見，之后再進入到下一個階段。如此不斷輪回重復，直到得到您滿意的最終產品。 螺旋開發分為以下四個階段：

制定計劃：確定軟件目標，選定實施方案，弄清項目開發的限制條件；

風險分析：分析評估所選方案，考慮如何識別和消除風險；

實施工程：實施軟件開發和驗證；

客戶評估：評價開發工作，提出修正建議，制定下一步計劃。

一個階段首先是確定該階段的目標，完成這些目標的選擇方案及其約束條件，然后從風險角度分析方案的開發策略，努力排除各種潛在的風險，有時需要通過建 造原型來完成。如果某些風險不能排除，該方案立即終止，否則啟動下一個開發步驟。最后，評價該階段的結果，并設計下一個階段。

4 敏捷開發模型

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

個體和互動重于流程和工具。

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

客戶協作重于合同談判。

應對變化重于遵循計劃。

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

敏捷開發小組主要的工作方式可以歸納為：作為一個整體工作；按短迭代周期工作；每次迭代交付一些成果；關注業務優先；檢查與調整。

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

5 四種模型比較

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

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

螺旋開發，很大程度上是一種風險驅動的方法體系，因為在每個階段之前及經常發生的循環之前，都必須首先進行風險評估。

敏捷開發，相比迭代式開發兩者都強調在較短的開發周期提交軟件，但是，敏捷開發的周期可能更短，并且更加強調隊伍中的高度協作。敏捷方法有時候被誤認為是無計劃性和紀律性的方法，實際上更確切的說法是敏捷方法強調適應性而非預見性。

適應性的方法集中在快速適應現實的變化。當項目的需求起了變化，團隊應該迅速適應。這個團隊可能很難確切描述未來將會如何變化。

6 軟件開發過程中的測試

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

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

7 軟件測試的目的與原則

測試的定義：使用人工或自動手段來運行或測定某個系統的過程，其目的在于檢查它是否滿足規定的需求或是弄清預期結果與實際結果之間的差別。

軟件測試的目的：發現程序中的錯誤，保證軟件產品的最終質量。

測試是程序的執行過程，目的在于發現錯誤

一個成功的測試用例在于發現至今未發現的錯誤

一個成功的測試是發現了至今未發現的錯誤的測試

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

確保產品滿足性能和效率的要求

確保產品是健壯的和適應用戶環境的

軟件測試的原則：

測試用例中一個必須部分是對預期輸出或接口進行定義

程序員應避免測試自己編寫的程序

編寫軟件的組織不應當測試自己編寫的軟件

應當徹底檢查每個測試的執行結果

測試用例的編寫不僅應當根據有效和預料到的輸入情況，而且也應當根據無效和未預料到的輸入情況

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

應避免測試用例用后即棄，除非軟件本身就是個一次性的軟件

計劃測試工作時不應默許假定不會發現錯誤

程序某部分存在更多錯誤的可能性，與該部分已經發現錯誤的數量成正比

8 軟件的可測性

軟件的可測性太差會導致測試的難度相當大，甚至無法測試。這種情況往往是由于極差的軟件架構設計和極為不規范的軟件開發工作導致的。

緊耦合。不把大半個系統實例化就無法測試。

弱內聚。這個類實現了太多功能，導致測試非常復雜。

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

好的軟件架構應該是松耦合、高內聚的。提高軟件的測試性的同時也提高了軟件的可維護性和可管理性。

二、測試用例設計

測試用例是為特定的目的而設計的一組測試輸入、執行條件和預期的結果。測試用例是執行的最小實體。簡單地說，測試用例就是設計一個場景，使軟件程序在這種場景下，必須能夠正常運行并且達到程序所設計的執行結果。

1 黑盒測試與白盒測試

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

合理的測試策略是將這兩種測試要素組合起來。我們可以通過使用特定的面向黑盒測試的測試用例設計方法，而后使用白盒測試方法對程序的邏輯結構進行檢查以補充這些測試用例，借此來設計出一個相當嚴格的測試。

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

2 白盒測試用例設計

白盒測試關注的是測試用例執行的程度或覆蓋程序邏輯結構（源代碼）的程度。完全的白盒測試是將程序中每條路徑都執行到，然而對一個帶有循環的程序來說，完全的路徑測試并不切合實際。白盒測試的特點：依據軟件設計說明書進行測試、對程序內部細節的嚴密檢驗、針對特定條件設計測試用例、對軟件的邏輯路徑進行覆蓋測試。

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

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

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

判定/條件覆蓋要求設計足夠多的測試用例，使得判定中每個條件的所有可能結果至少出現一次，每個判定本身所有可能結果也至少出現一次。判定/條件覆蓋滿足判定覆蓋準則和條件覆蓋準則，彌補了二者的不足。判定/條件覆蓋準則的缺點是未考慮條件的組合情況。

多重條件覆蓋要求設計足夠多的測試用例，使得每個判定中條件結果的所有可能組合至少出現一次。多重條件覆蓋準則滿足判定覆蓋、條件覆蓋和判定/條件覆蓋準則。更改的判定/條件覆蓋要求設計足夠多的測試用例，使得判定中每個條件的所有可能結果至少出現一次，每個判定本身的所有可能結果也至少出現一次。并且每個條件都顯示能單獨影響判定結果。缺點是線性地增加了測試用例的數量。

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

3 黑盒測試用例設計

（1）等價類劃分

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

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

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

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

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

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

在確知已劃分的等價類中各元素在程序處理中的方式不同的情況下,則應再將該等價類進一步的劃分為更小的等價類。

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

為每一個等價類規定一個唯一的編號；

設計一個新的測試用例,使其盡可能多地覆蓋尚未被覆蓋地有效等價類,重復這一步，直到所有的有效等價類都被覆蓋為止；

設計一個新的測試用例,使其僅覆蓋一個尚未被覆蓋的無效等價類,重復這一步，直到所有的無效等價類都被覆蓋為止。

（2）邊界值分析

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

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

（3）因果圖

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

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

（4） 錯誤測試

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

如測試一個對線性表（比如數組）進行排序的程序，可推測列出以下幾項需要特別測試的情況：

輸入的線性表為空表；

表中只含有一個元素；

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

輸入表已按逆序排好；

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

4 測試用例設計綜合策略

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

在任何情況下都必須使用邊界值分析方法，經驗表明用這種方法設計出測試用例發現程序錯誤的能力最強。

必要時用等價類劃分方法補充一些測試用例。

用錯誤推測法再追加一些測試用例。

對照程序邏輯，檢查已設計出的測試用例的邏輯覆蓋程度，如果沒有達到要求的覆蓋標準，應當再補充足夠的測試用例。

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

測試用例的設計步驟：1)構造根據設計規格得出的基本功能測試用例；2)邊界值測試用例；3)狀態轉換測試用例；4)錯誤猜測測試用例；5)異常測試用例；6)性能測試用例；7)壓力測試用例。

三、軟件測試類型

單元測試

單元測試并不是對整個程序進行測試，而是對構成程序的較小模塊進行測試。單元測試減小了調試的難度（一旦某個錯誤被發現出來，我們就知道它在哪個具體的模塊中）；單元測試提供了同時測試多個模塊的可能，將并行工程引入軟件測試中。

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

集成測試

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

功能測試

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

功能測試是一種黑盒測試，功能測試常用步驟有：根據需求來細分功能點，根據功能點派生測試需求，根據測試需求設計功能測試用例。

系統測試

系統測試的目的是為了證明程序不能實現其目標，系統測試的測試用例設計有以下14種類型：

能力測試：是判斷目標文檔提及的每一項能力（或功能）是否都確實已經實現。

容量測試：使程序經受大容量數據的檢驗。容量測試的目的是為了證明程序不能處理目標文檔中規定的數據容量。

強度測試：使程序承受高負載或強度的檢驗。所謂高強度是指在很短的時間間隔內達到的數據或操作的數量峰值。

易用性測試：試圖發現人為因素或易用性的問題。

安全性測試：設計測試用例來突破程序安全檢查的過程。舉例來說，我們可以設計測試用例來規避操作系統的內存保護機制，破壞數據庫管理系統的數據安全機制。

性能測試：很多軟件都有特定的性能或效率目標，這終特性描述為在特定負載和配置環境下程序的響應時間和吞吐率。

存儲測試：

配置測試：

兼容性測試。

安裝測試：有些類型的軟件系統安裝過程非常復雜，測試安裝過程是系統測試中的一個重要部分。對于包含在軟件包中的自動安裝系統而言，這尤其重要。安裝程序如果出現故障，會影響用戶對軟件的成功體驗。

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

可恢復性測試：諸如操作系統、數據庫管理系統和遠程處理系統等軟件通常都有可恢復性目標，說明系統如何從程序錯誤、硬件失效和數據錯誤中恢復過來。系統測試的一個目標是證明這些恢復機制不能夠正確發揮作用。我們可以故意將程序錯誤置入某個系統中，判斷系統是否可以從中恢復。

適用性測試

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

四、自動化測試

自動化測試：以程序測試程序、以代碼代替思維、以腳本運行代替手工測試。

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

回歸測試:就是以前版本中發現的bug在新的版本中驗證是否存在且是否引發新的bug。

1 自動化測試的優勢

回歸測試更方便、可靠。由于回歸測試的業務流程操作和測試用例是預先設計好的，預期結果也是完全在項目人員掌握之中的，將回歸測試交給計算機自動運行，可以極大提高測試效率，縮短回歸測試時間。

可運行更多更繁瑣的測試，且快速高效。

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

具有一致性和可重復性的特點。

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

2 自動化測試的劣勢

永遠不可能完全取代手工測試。自動化測試無法做到手工測試的覆蓋率，不是每個測試用例都適合轉換成自動化測試用例的。

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

手工測試能發現的缺陷遠比自動化測試多。自動化測試幾乎是無法發現新缺陷。

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

自動化測試對測試工程師來說必須有一定的開發技術背景。

3 引入自動化測試的時機

項目周期長，系統版本不斷。主要在于回歸測試。

需求變更不頻繁。

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

需要反復測試，如可靠性測試需要進行上千次的系統測試。

4 何時避免展開自動化測試

項目周期短，需求變更頻繁。項目周期短的情況下引入自動化測試，不但收不回成本，而且會延長產品的發布時間。需求頻繁改變會使老功能的業務邏輯被修改，從而導致相應的測試腳本也需相應修改。

軟件版本還沒穩定。

多數對象無法識別以及腳本維護頻繁與艱難。

5 自動化測試用例設計

在項目的測試過程中，測試工程師都會首先分析測試需求，產出測試計劃后，編寫和設計測試用例，設計開發測試腳本。

自動化測試用例的范圍往往是核心業務流程或者重復執行率較高的。并不需要覆蓋所有的手工測試用例。

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

手工測試用例可以不用回歸原點，而自動化用例往往是必須的。所謂回歸原點就是執行的測試用例最終需要恢復其在執行前的初始狀態。比如添加用戶功能，由于用戶名是唯一的，第一次執行時沒有問題，第二次執行時程序就會出現用戶名重復而報錯；這種情況下，就需要在自動化測試用例最后增加刪除該用戶的步驟。

自動化測試用例與手工測試用例不同，不需要每個步驟都寫預期結果。

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

測試文檔包括：測試計劃文檔，測試設計規格文檔，測試用例，軟件缺陷報告，狀態報告。

測試用例對一項特定的軟件產品進行測試任務的描述，體現測試方案、方法、技術和策略。內容包括測試目標、測試環境、輸入數據、測試步驟、預期結果、測試腳本等，并形成文檔。測試用例一般包括驗證測試用例和證偽測試用例；驗證測試用例用于驗證代碼是否按照預期執行，得到預期結果；證偽測試用例驗證代碼是否對異常和錯誤條件進行了適當處理。

缺陷報告包括：問題/錯誤的簡單描述，重現的環境配置要求，保證多次精確重復的特定輸入，期望結果與實際結果的對比，優先級與嚴重性，對客戶的影響等。

六、常用的測試工具

1 功能測試UFT

UFT自動化測試的原理

封裝真實被測對象并轉化為UFT對象到對象庫。

對比對象庫里的對象鑒別屬性和運行時的真實被測對象的鑒別屬性。

對比結果一致，則說明對象成功匹配并可以繼續對該真實被測對象進行后續操作；如果不一致則報錯，提示對象無法識別。

封裝對象模型

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

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

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

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

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

對象無法識別的解決辦法

設置虛擬對象。不推薦，虛擬對象非常脆弱，難以維護；即使對象沒有發生變化，但只要對象在界面是那個的方位發生變化，虛擬對象就會識別失敗。

使用相對坐標配合WSH去定位對象。

使用DOM組建接口應用技術。只適用于Web項目。

使用UFT自定義擴展SDK Customer來進行二次開發使UFT能夠識別對象。難度大。

開發提供專屬插件。

把無法識別的對象的一些方法封裝到一個dll中并使用UFT調用。

數據驅動與場景恢復

數據驅動Data Table的應用：實現測試數據和腳本業務的分離。
場景恢復：場景恢復可以應對多種類型的錯誤并進行恢復操作。

2 性能測試LoadRunner

LoadRunner是一種適用于各種體系架構的自動負載測試工具，它能預測系統行為并優化系統性能。LoadRunner的測試對象是整個企業的系統，它通過模擬實際用戶的操作行為和實時性能監測，來幫助測試人員更快地查找和發現問題。

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

創建真實負載。建立虛擬用戶后，需要設定負載方案、業務流程組合和虛擬用戶數量。用Controller能夠很快地組織多用戶測試方案。

定位性能問題。LoadRunner內含一個實時檢測器，在負載測試過程的任何時候都能觀察到應用系統的運行性能。

分析結果。一旦測試完畢，LoadRunner收集匯總所有的測試數據，并提供高級的分析和報告工具，一遍迅速找到性能問題并做出相應的調整。

七、軟件測試面試題總結

1. 給你一個網站，你如何測試？

首先，查找需求說明、網站設計等相關文檔，分析測試需求。

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

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

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

提交功能的測試。

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

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

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

頁面是否風格統一，美觀

頁面布局是否合理，重點內容和熱點內容是否突出

控件是否正常使用

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

文字檢查

性能測試一般從以下兩個方面考慮：壓力測試；負載測試；強度測試

數據庫測試要具體決定是否需要開展。數據庫一般需要考慮連結性，對數據的存取操作，數據內容的驗證等方面。

安全性測試：

基本的登錄功能的檢查

是否存在溢出錯誤，導致系統崩潰或者權限泄露

相關開發語言的常見安全性問題檢查，例如SQL注入等

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

兼容性測試，根據需求說明的內容，確定支持的平臺組合：

瀏覽器的兼容性；

操作系統的兼容性；

軟件平臺的兼容性；

數據庫的兼容性

開展測試，并記錄缺陷。合理的安排調整測試進度，提前獲取測試所需的資源，建立管理體系（例如，需求變更、風險、配置、測試文檔、缺陷報告、人力資源等內容）。

定期評審，對測試進行評估和總結，調整測試的內容。

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

建立測試計劃，確定測試標準和測試范圍

設計典型場景的測試用例，覆蓋常用業務流程和不常用的業務流程等

根據測試用例，開發自動測試腳本和場景：

錄制測試腳本：新建一個腳本（Web/HTML協議）；點擊錄制按鈕，在彈出的對話框的URL中輸入”about:blank”；在打開的瀏覽器中進行正常操作流程后，結束錄制；調試腳本并保存，可能要注意到字符集的關聯。

設置測試場景：針對性能設置測試場景，主要判斷在正常情況下，系統的平均事務響應時間是否達標；針對壓力負載設置測試場景，主要判斷在長時間處于滿負荷或者超出系統承載能力的條件下，系統是否會崩潰；執行測試，獲取測試結果，分析測試結果。

3. 一臺客戶端有三百個客戶與三百個客戶端有三百個客戶對服務器施壓，有什么區別?

300個用戶在一個客戶端上，會占用客戶機更多的資源，而影響測試的結果。線程之間可能發生干擾，而產生一些異常。300個用戶在一個客戶端上，需要更大的帶寬。

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

所有用戶在一個客戶端上，不必考慮分布式管理的問題；而用戶分布在不同的客戶端上，需要考慮使用控制器來整體調配不同客戶機上的用戶。同時，還需要給予相應的權限配置和防火墻設置。

4. 目前主要的測試用例設計方法是什么？

白盒測試：邏輯覆蓋、循環覆蓋、基本路徑覆蓋

黑盒測試：邊界值分析法、等價類劃分、錯誤猜測法、因果圖法、狀態圖法、測試大綱法、隨機測試、場景法

5. 軟件的安全性應從哪幾個方面去測試？

軟件安全性測試包括程序、數據庫安全性測試。根據系統安全指標不同測試策略也不同。

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

數據庫安全考慮問題： 系統數據是否機密（比如對銀行系統，這一點就特別重要，一般的網站就沒有太高要求）、系統數據的完整性（我剛剛結束的企業實名核查服務系統中就曾存在數據的不完整，對于這個系統的功能實現有了障礙） 、系統數據可管理性 、系統數據的獨立性 、系統數據可備份和恢復能力（數據備份是否完整，可否恢復，恢復是否可以完整）

6. 簡述什么是靜態測試、動態測試、黑盒測試、白盒測試、α測試 β測試

靜態測試是不運行程序本身而尋找程序代碼中可能存在的錯誤或評估程序代碼的過程。

動態測試是實際運行被測程序，輸入相應的測試實例，檢查運行結果與預期結果的差異，判定執行結果是否符合要求，從而檢驗程序的正確性、可靠性和有效性，并分析系統運行效率和健壯性等性能。

黑盒測試一般用來確認軟件功能的正確性和可操作性,目的是檢測軟件的各個功能是否能得以實現,把被測試的程序當作一個黑盒,不考慮其內部結構,在知道該程序的輸入和輸出之間的關系或程序功能的情況下,依靠軟件規格說明書來確定測試用例和推斷測試結果的正確性。

白盒測試根據軟件內部的邏輯結構分析來進行測試,是基于代碼的測試，測試人員通過閱讀程序代碼或者通過使用開發工具中的單步調試來判斷軟件的質量，一般黑盒測試由項目經理在程序員開發中來實現。

α測試是由一個用戶在開發環境下進行的測試，也可以是公司內部的用戶在模擬實際操作環境下進行的受控測試，Alpha測試不能由程序員或測試員完成。

β測試是軟件的多個用戶在一個或多個用戶的實際使用環境下進行的測試。開發者通常不在測試現場，Beta測試不能由程序員或測試員完成。

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

和開發過程相對應，測試過程會依次經歷單元測試、集成測試、系統測試、驗收測試四個主要階段：

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

集成測試：集成測試是將模塊按照設計要求組裝起來進行測試，主要目的是發現與接口有關的問題。由于在產品提交到測試部門前，產品開發小組都要進行聯合調試，因此在大部分企業中集成測試是由開發人員來完成的。

系統測試：系統測試是在集成測試通過后進行的，目的是充分運行系統，驗證各子系統是否都能正常工作并完成設計的要求。它主要由測試部門進行，是測試部門最大最重要的一個測試，對產品的質量有重大的影響。

驗收測試：驗收測試以需求階段的《需求規格說明書》為驗收標準，測試時要求模擬實際用戶的運行環境。對于實際項目可以和客戶共同進行，對于產品來說就是最后一次的系統測試。測試內容為對功能模塊的全面測試，尤其要進行文檔測試。

單元測試測試策略：

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

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

集成測試的測試策略：

大爆炸集成：適應于一個維護型項目或被測試系統較小

自頂向下集成：適應于產品控制結構比較清晰和穩定；高層接口變化較小；底層接口未定義或經常可能被修改；產口控制組件具有較大的技術風險，需要盡早被驗證；希望盡早能看到產品的系統功能行為。

自底向上集成：適應于底層接口比較穩定；高層接口變化比較頻繁；底層組件較早被完成。

基于進度的集成

優點：具有較高的并行度；能夠有效縮短項目的開發進度。

缺點：樁和驅動工作量較大；有些接口測試不充分；有些測試重復和浪費。

系統測試的測試策略：數據和數據庫完整性測試；功能測試；用戶界面測試；性能評測；負載測試；強度測試；容量測試；安全性和訪問控制測試；故障轉移和恢復測試；配置測試；安裝測試；加密測試；可用性測試；版本驗證測試；文檔測試

8. 軟件測試各個階段通常完成什么工作？各個階段的結果文件是什么？包括什么內容？

單元測試階段：各獨立單元模塊在與系統地其他部分相隔離的情況下進行測試，單元測試針對每一個程序模塊進行正確性校驗，檢查各個程序模塊是否正確地實現了規定的功能。生成單元測試報告，提交缺陷報告。

集成測試階段：集成測試是在單元測試的基礎上，測試在將所有的軟件單元按照概要設計規格說明的要求組裝成模塊、子系統或系統的過程中各部分工作是否達到或實現相應技術指標及要求的活動。該階段生成集成測試報告，提交缺陷報告。

系統測試階段：將通過確認測試的軟件，作為整個給予計算機系統的一個元素，與計算機硬件、外設、某些支持軟件、數據和人員等其他系統元素結合在一起，在實際運行環境下，對計算機系統進行全面的功能覆蓋。該階段需要提交測試總結和缺陷報告。

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

一條Bug記錄最基本應包含：

bug編號；

bug嚴重級別，優先級；

bug產生的模塊；

首先要有bug摘要，闡述bug大體的內容；

bug對應的版本；

bug詳細現象描述，包括一些截圖、錄像....等等；

bug出現時的測試環境，產生的條件即對應操作步驟；

10. 黑盒測試和白盒測試是軟件測試的兩種基本方法，請分別說明各自的優點和缺點！

黑盒測試的優點有：比較簡單，不需要了解程序內部的代碼及實現；與軟件的內部實現無關； 從用戶角度出發，能很容易的知道用戶會用到哪些功能，會遇到哪些問題；基于軟件開發文檔，所以也能知道軟件實現了文檔中的哪些功能；在做軟件自動化測試時較為方便。

黑盒測試的缺點有：不可能覆蓋所有的代碼，覆蓋率較低，大概只能達到總代碼量的30%；自動化測試的復用性較低。

白盒測試的優點有：幫助軟件測試人員增大代碼的覆蓋率，提高代碼的質量，發現代碼中隱 藏的問題。

白盒測試的缺點有：程序運行會有很多不同的路徑，不可能測試所有的運行路徑；測試基于代碼，只能測試開發人員做的對不對，而不能知道設計的正確與否，可能會漏掉一些功能需求；系統龐大時，測試開銷會非常大。

11. 如何測試一個紙杯？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

測試人員根據修改好的需求分析文檔開始寫測試用例，同時開發人員完成概要設計文檔，詳細設計文檔。此兩份文檔成為測試人員撰寫測試用例的補充材料。

測試用例完成后，測試和開發需要進行評審。

測試人員搭建環境

開發人員提交第一個版本，可能存在未完成功能，需要說明。測試人員進行測試，發現BUG后提交給BugZilla。

開發提交第二個版本，包括Bug Fix以及增加了部分功能，測試人員進行測試。

重復上面的工作，一般是3-4個版本后BUG數量減少，達到出貨的要求。

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

14. 說說你對集成測試中自頂向下集成和自底向上集成兩個策略的理解，要談出它們各自的優缺點和主要適應于哪種類型測試

自頂向下集成

優點：較早地驗證了主要控制和判斷點；按深度優先可以首先實現和驗證一個完整的軟件功能；功能較早證實，帶來信心；只需一個驅動，減少驅動器開發的費用；支持故障隔離。

缺點：柱的開發量大；底層驗證被推遲；底層組件測試不充分。

適應于產品控制結構比較清晰和穩定；高層接口變化較小；底層接口未定義或經常可能被修改；產口控制組件具有較大的技術風險，需要盡早被驗證；希望盡早能看到產品的系統功能行為。

自底向上集成

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

缺點：驅動的開發工作量大；對高層的驗證被推遲，設計上的錯誤不能被及時發現。

適應于底層接口比較穩定；高層接口變化比較頻繁；底層組件較早被完成。

15. 設計測試用例時應該考慮哪些方面，即不同的測試用例針對那些方面進行測試？

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

16. 在windows下保存一個文本文件時會彈出保存對話框，如果為文件名建立測試用例，等價類應該怎樣劃分？

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

假設有一個文本框要求輸入10個字符的郵政編碼，對于該文本框應該怎樣劃分等價類？

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

17. 單元測試、集成測試、系統測試的側重點是什么？

單元測試針對的是軟件設計的最小單元--程序模塊（面向過程中是函數、過程；面向對象中是類。）,進行正確性檢驗的測試工作,在于發現每個程序模塊內部可能存在的差錯.一般有兩個步驟:人工靜態檢查\動態執行跟蹤

集成測試針對的是通過了單元測試的各個模塊所集成起來的組件進行檢驗,其主要內容是各個單元模塊之間的接口,以及各個模塊集成后所實現的功能.

系統測試針對的是集成好的軟件系統，作為整個計算機系統的一個元素,與計算機硬件\外設\某些支持軟件\數據和人員等其他系統元素結合在一起,要在實際的運行環境中,對計算機系統進行一系列的集成測試和確認測試.

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

按測試策略分類：

1、靜態與動態測試

2、黑盒與白盒測試

3、手工和自動測試

4、冒煙測試

5、回歸測試；

按測試階段分類：單元測試、集成測試、系統測試；

其他常見測試方法：

1、功能測試

2、性能測試

3、壓力測試

4、負載測試

5、易用性測試

6、安裝測試

7、界面測試

8、配置測試

9、文檔測試

10、兼容性測試

11、安全性測試

12、恢復測試

19. 您認為做好測試用例設計工作的關鍵是什么？

白盒測試用例設計的關鍵是以較少的用例覆蓋盡可能多的內部程序邏輯結果

黑盒法用例設計的關鍵同樣也是以較少的用例覆蓋模塊輸出和輸入接口。不可能做到完全測試，以最少的用例在合理的時間內發現最多的問題

20. 一套完整的測試應該由哪些階段組成？

可行性分析、需求分析、概要設計、詳細設計、編碼、單元測試、集成測試、系統測試、驗收測試

21. 面向對象的測試用例設計有幾種方法？如何實現？

給類中的每個構造函數設計一組測試用例

組合類中的類變量、實例變量

組合類中的各種方法

根據前置條件和后置條件設計測試用例

根據代碼設計測試用例

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。