軟體測試基礎大總結

1.測試與軟體模型

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

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

1.1 瀑布模型

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

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

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

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

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

1.2 迭代開發模型

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

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

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

持續的測試與整合，降低後期的工作量與風險。

1.3 螺旋開發模型

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

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

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

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

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

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

1.4 敏捷開發模型

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

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

可工作的軟體重於求全而完備的文件。

客戶協作重於合同談判。

應對變化重於遵循計劃。

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

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

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

1.5 四種模型比較

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

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

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

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

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

1.6 軟體開發過程中的測試

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

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

1.7 軟體測試的目的與原則

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

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

測試是程式的執行過程，目的在於發現錯誤

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

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

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

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

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

軟體測試的原則：

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

程式設計師應避免測試自己編寫的程式

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

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

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

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

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

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

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

1.8 軟體的可測性

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

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

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

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

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

2. 測試用例設計

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

2.1 黑盒測試與白盒測試

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

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

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

2.2 白盒測試用例設計

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

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

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

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

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

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

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

2.3 黑盒測試用例設計

2.3.1 等價類劃分

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

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

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

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

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

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

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

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

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

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

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

2.3.2 邊界值分析

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

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

2.3.3 因果圖

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

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

2.3.4 錯誤測試

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

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

輸入的線性表為空表；

表中只含有一個元素；

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

輸入表已按逆序排好；

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

2.4 測試用例設計綜合策略

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

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

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

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

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

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

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

3. 軟體測試型別

單元測試

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

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

整合測試

自頂向下整合和自底向上整合

功能測試

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

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

系統測試

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

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

容量測試： 使程式經受大容量資料的檢驗。容量測試的目的是為了證明程式不能處理目標文件中規定的資料容量。

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

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

安全性測試： 設計測試用例來突破程式安全檢查的過程。舉例來說，我們可以設計測試用例來規避作業系統的記憶體保護機制，破壞資料庫管理系統的資料安全機制。

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

儲存測試：

配置測試：

相容性測試。

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

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

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

適用性測試

文件測試： 檢查使用者文件的正確性。使用者文件應成為審查的物件，檢查其正確性和清晰性。在文件中描述的任何範例應編成測試用例，並提交給程式。

4. 自動化測試

自動化測試：以程式測試程式、以程式碼代替思維、以指令碼執行代替手工測試。

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

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

4.1 自動化測試的優勢

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

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

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

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

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

4.2 自動化測試的劣勢

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

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

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

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

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

4.3 引入自動化測試的時機

專案週期長，系統版本不斷。主要在於迴歸測試。

需求變更不頻繁。

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

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

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

專案週期短，需求變更頻繁。專案週期短的情況下引入自動化測試，不但收不回成本，而且會延長產品的釋出時間。需求頻繁改變會使老功能的業務邏輯被修改，從而導致相應的測試指令碼也需相應修改。

軟體版本還沒穩定。

多數物件無法識別以及指令碼維護頻繁與艱難。

4.5 自動化測試用例設計

在專案的測試過程中，測試工程師都會首先分析測試需求，產出測試計劃後，編寫和設計測試用例，設計開發測試指令碼。

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

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

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

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

5. 測試文件編寫與缺陷管理

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

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

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

6. 常用的測試工具

6.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的應用：實現測試資料和指令碼業務的分離。

場景恢復：場景恢復可以應對多種型別的錯誤並進行恢復操作。

6.2 效能測試LoadRunner

LoadRunner是一種適用於各種體系架構的自動負載測試工具，它能預測系統行為並優化系統效能。LoadRunner的測試物件是整個企業的系統，它通過模擬實際使用者的操作行為和實時效能監測，來幫助測試人員更快地查詢和發現問題。

輕鬆建立虛擬使用者。Virtual User Generator能夠生成虛擬用於，以虛擬使用者的方式模擬真實使用者的業務操作行為。它先記錄下業務流程，然後將其轉化為測試指令碼，並進行引數化操作（Data Wizard直接連線資料伺服器獲取資料）。利用虛擬使用者可以在不同作業系統上同時產生成千上萬使用者訪問，能極大的減少負載測試所需要的硬體和人力資源。

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

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

分析結果。一旦測試完畢，LoadRunner收集彙總所有的測試資料，並提供高階的分析和報告工具，一遍迅速找到效能問題並做出相應的調整。

7. 軟體測試面試題總結

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. 物件導向的測試用例設計有幾種方法？如何實現？

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

組合類中的類變數、例項變數

組合類中的各種方法

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

根據程式碼設計測試用例

如果你

①從事功能測試，想進階自動化測試

②在測試界混了1、2年，依然不會敲程式碼

③面試大廠卻屢屢碰壁

我邀你進群吧！來吧~~測試員，313782132（Q群裡有技術大牛一起交流分享，學習資源的價值取決於你的行動，莫做“收藏家”）獲取更多大廠技術、面試資料

如果對python自動化測試、web自動化、介面自動化、移動端自動化、面試經驗交流等等感興趣的測試人，可以關注微信公眾號：【傷心的辣條】，獲取軟體測試工程師大廠面試資料！

最後：

凡事要趁早，特別是技術行業，一定要提升技術功底，豐富自動化專案實戰經驗，這對於你未來幾年職業規劃，以及測試技術掌握的深度非常有幫助。