軟體測試(實際輸出與預期輸出間的審核或者比較過程)

軟體測試（英語：Software Testing），描述一種用來促進鑑定軟體的正確性、完整性、安全性和質量的過程。換句話說，軟體測試是一種實際輸出與預期輸出之間的審核或者比較過程。軟體測試的經典定義是：在規定的條件下對程式進行操作，以發現程式錯誤，衡量軟體質量，並對其是否能滿足設計要求進行評估的過程。

基本介紹

• 中文名：軟體測試
• 外文名：software testing
• 目的：鑑定、審核軟體
• 方式：人工操作或者軟體自動運行
• 工作內容：驗證和確認
• 領域：IT行業、有信息化管理的各行業

發展歷程

軟體測試是伴隨著軟體的產生而產生的。早期的軟體開發過程中軟體規模都很小、複雜程度低，軟體開發的過程混亂無序、相當隨意，測試的含義比較狹窄，開發人員將測試等同於“調試”，目的是糾正軟體中已經知道的故障，常常由開發人員自己完成這部分的工作。對測試的投入極少，測試介入也晚，常常是等到形成代碼，產品已經基本完成時才進行測試。到了上世紀80年代初期，軟體和IT行業進入了大發展，軟體趨向大型化、高複雜度，軟體的質量越來越重要。這個時候，一些軟體測試的基礎理論和實用技術開始形成，並且人們開始為軟體開發設計了各種流程和管理方法，軟體開發的方式也逐漸由混亂無序的開發過程過渡到結構化的開發過程，以結構化分析與設計、結構化評審、結構化程式設計以及結構化測試為特徵。人們還將“質量”的概念融入其中，軟體測試定義發生了改變，測試不單純是一個發現錯誤的過程，而且將測試作為軟體質量保證(SQA)的主要職能，包含軟體質量評價的內容，Bill Hetzel在《軟體測試完全指南》(Complete Guide of Software Testing)一書中指出：“測試是以評價一個程式或者系統屬性為目標的任何一種活動。測試是對軟體質量的度量。”這個定義至今仍被引用。軟體開發人員和測試人員開始坐在一起探討軟體工程和測試問題。

軟體測試已有了行業標準(IEEE/ANSI )，1983年IEEE提出的軟體工程術語中給軟體測試下的定義是：“使用人工或自動的手段來運行或測定某個軟體系統的過程，其目的在於檢驗它是否滿足規定的需求或弄清預期結果與實際結果之間的差別”。這個定義明確指出:軟體測試的目的是為了檢驗軟體系統是否滿足需求。它再也不是一個一次性的，而且只是開發後期的活動，而是與整個開發流程融合成一體。軟體測試已成為一個專業，需要運用專門的方法和手段，需要專門人才和專家來承擔。

進入上世紀90年代，軟體行業開始迅猛發展，軟體的規模變的非常大，在一些大型軟體開發過程中，測試活動需要花費大量的時間和成本，而當時測試的手段幾乎完全都是手工測試，測試的效率非常低;並且隨著軟體複雜度的提高，出現了很多通過手工方式無法完成測試的情況，儘管在一些大型軟體的開發過程中，人們嘗試編寫了一些小程式來輔助測試，但是這還是不能滿足大多數軟體項目的統一需要。於是，很多測試實踐者開始嘗試開發商業的測試工具來支持測試，輔助測試人員完成某一類型或某一領域內的測試工作，而測試工具逐漸盛行起來。人們普遍意識到，工具不僅僅是有用的，而且要對今天的軟體系統進行充分的測試，工具是必不可少的。測試工具可以進行部分的測試設計、實現、執行和比較的工作。通過運用測試工具，可以達到提高測試效率的目的。測試工具的發展，大大提高了軟體測試的自動化程度，讓測試人員從繁瑣和重複的測試活動中解脫出來，專心從事有意義的測試設計等活動。採用自動比較技術，還可以自動完成測試用例執行結果的判斷，從而避免人工比對存在的疏漏問題。設計良好的自動化測試，在某些情況下可以實現 “ 夜間測試 ” 和 “ 無人測試 ” 。在大多數情況下，軟體測試自動化可以減少開支，增加有限時間內可執行的測試，在執行相同數量測試時節約測試時間。 而測試工具的選擇和推廣也越來越受到重視。在軟體測試工具平台方面，商業化的軟體測試工具已經很多，如捕獲/回放工具、Web測試工具、性能測試工具、測試管理工具、代碼測試工具等等，這些都有嚴格的著作權限制且價格較為昂貴，但由於價格和著作權的限制無法自由使用，當然，一些軟體測試工具開發商對於某些測試工具提供了Beta測試版本以供用戶有限次數使用。幸運的是，在開放源碼社區中也出現了許多軟體測試工具，已得到廣泛套用且相當成熟和完善。

測試理論

軟體測試是使用人工操作或者軟體自動運行的方式來檢驗它是否滿足規定的需求或弄清預期結果與實際結果之間的差別的過程。

它是幫助識別開發完成（中間或最終的版本）的計算機軟體（整體或部分）的正確度(correctness) 、完全度(completeness)和質量(quality)的軟體過程；是SQA(software quality assurance)的重要子域。

Glenford J.Myers曾對軟體測試的目的提出過以下觀點：

軟體測試

(1)測試是為了發現程式中的錯誤而執行程式的過程。

(2)好的測試方案是極可能發現迄今為止尚未發現的錯誤的測試方案。

(3)成功的測試是發現了至今為止尚未發現的錯誤的測試。

(4)測試並不僅僅是為了找出錯誤。通過分析錯誤產生的原因和錯誤的發生趨勢，可以幫助項目管理者發現當前軟體開發過程中的缺陷，以便及時改進。

(5)這種分析也能幫助測試人員設計出有針對性的測試方法，改善測試的效率和有效性。

(6)沒有發現錯誤的測試也是有價值的，完整的測試是評定軟體質量的一種方法。

(7)另外，根據測試目的的不同，還有回歸測試、壓力測試、性能測試等，分別為了檢驗修改或最佳化過程是否引發新的問題、軟體所能達到處理能力和是否達到預期的處理能力等。

測試原則

一，測試應該儘早進行，最好在需求階段就開始介入，因為最嚴重的錯誤不外乎是系統不能滿足用戶的需求。

二，程式設計師應該避免檢查自己的程式，軟體測試應該由第三方來負責。

三，設計測試用例時應考慮到合法的輸入和不合法的輸入以及各種邊界條件，特殊情況下還要製造極端狀態和意外狀態，如網路異常中斷、電源斷電等。

四，應該充分注意測試中的群集現象。

五，對錯誤結果要進行一個確認過程。一般由A測試出來的錯誤，一定要由B來確認。嚴重的錯誤可以召開評審會議進行討論和分析，對測試結果要進行嚴格地確認，是否真的存在這個問題以及嚴重程度等。

六，制定嚴格的測試計畫。一定要制定測試計畫，並且要有指導性。測試時間安排儘量寬鬆，不要希望在極短的時間內完成一個高水平的測試。

七，妥善保存測試計畫、測試用例、出錯統計和最終分析報告，為維護提供方便。

測試目標

1．發現一些可以通過測試避免的開發風險。

2．實施測試來降低所發現的風險。

3．確定測試何時可以結束。

4．在開發項目的過程中將測試看作是一個標準項目。

測試對象

1. 程式。
2. 數據。
3. 文檔。

測試過程

第一步：對要執行測試的產品/項目進行分析，確定測試策略，制定測試計畫。該計畫被審核批准後轉向第二步。測試工作啟動前一定要確定正確的測試策略和指導方針，這些是後期開展工作的基礎。只有將本次的測試目標和要求分析清楚，才能決定測試資源的投入。

第二步：設計測試用例。設計測試用例要根據測試需求和測試策略來進行，進度壓力不大時，應該設計的詳細，如果進度、成本壓力較大，則應該保證測試用例覆蓋到關鍵性的測試需求。該用例被批准後轉向第三步。

第三步：如果滿足“啟動準則”（EntryCriteria），那么執行測試。執行測試主要是搭建測試環境，執行測試用例。執行測試時要進行進度控制、項目協調等工作。

第四步：提交缺陷。這裡要進行缺陷審核和驗證等工作。

第五步：消除軟體缺陷。通常情況下，開發經理需要審核缺陷，並進行缺陷分配。程式設計師修改自己負責的缺陷。在程式設計師修改完成後，進入到回歸測試階段。如果滿足“完成準則”（ExitCriteria），那么正常結束測試。

第六步：撰寫測試報告。對測試進行分析，總結本次的經驗教訓，在下一次的工作中改進。

軟體測試過程管理，主要包括軟體測試是什麼樣的過程，如何評價一個軟體測試過程，如何進行配置管理和測試風險分析以及測試成本的管理。

心理依據

人類行為具有高度目標性，確立一個正確的目標有著重要的心理學影響。軟體測試的心理學問題就是如何擺正測試的兩個目標的關係，使得測試活動更加富有成效。

軟體測試工程師職業發展前景

1.程式測試的過程具有破壞性

每當測試一個程式時，人們總希望為程式增加一些價值。利用測試來增加程式的價值，是指通過測試，找出並修改儘可能多的程式缺陷，從而提高程式的可靠性或質量。

因此，不要只是為了證明程式能夠正確運行而去測試程式。相反，應該一開始就假設程式中隱藏著錯誤（這種假設幾乎對所有的程式都成立），然後測試程式，發現儘可能多的錯誤。

事實上，如果把測試目標定位於要證明程式中沒有缺陷，那么就會在潛意識中傾向於實現這個目標。也就是說，測試人員會傾向於挑選那些使程式失效的可能性較小的測試數據。另一方面，如果把測試目標定位於要證明程式中存在缺陷，那么就會選擇一些容易發現程式缺陷的測試數據。而後一種態度會比前者給程式增加更多的價值。

軟體測試技術

事實上，如果在測試某個程式段時發現了可以糾正的缺陷，或者測試最終確定再沒有其他缺陷，則應將這次合理設計並得到有效執行的測試稱作是“成功的”。而所謂“不成功的”測試，僅指未能適當地對程式進行檢查，未能找出程式中潛藏缺陷的測試。

“軟體測試就是證明軟體不存在錯誤的過程”。對幾乎所有的程式而言，甚至是非常小的程式，這個目標實際上是無法達到的。因為即使程式完全實現預期要求，仍可能包含有缺陷。也就是說，如果程式不按要求工作，它顯然有缺陷，但如果程式做了不要它做的事，它也有缺陷。

心理學研究告訴我們，當人們在乾一件已經知道是不合適的或不可能做到的事時，往往他們的表現就相當糟糕。把程式測試定義為在程式中找出錯誤的過程，就使測試成了可以做到的任務，從而克服了心理上存在的問題。雖然這看起來像是個微妙的文字遊戲，但對成功地進行軟體測試有很大的影響。

總之，軟體測試更適宜被視為試圖發現程式中錯誤（假設其存在）的破壞性的過程。一個成功的測試，通過誘發程式發生錯誤，可以在這個方向上促進軟體質量的改進。當然最終人們還是要通過軟體測試來建立某種程度的信心：軟體做了其應該做的，而沒有做其不應該做的。

2.程式設計師應避免測試自己的程式

由開發人員來測試自己的代碼是一件很不妥當的事情。開發和測試生來就是不同的活動。開發是創造或者建立某種事物的行為，如一個功能模組或整個系統。而測試的重要目的是證實一個模組或者一個系統工作不正常。這兩個活動之間有著本質的矛盾。一個人不太可能把兩個截然對立的角色都扮演地很好，因此應當限制開發人員在測試中的參與，給他們比較合適的任務是進行最底層的測試——單元測試。

軟體測試書籍

當一個程式設計師完成了設計與編寫程式的建設性工作後，要一夜之間突然改變他的觀點，設法對程式形成一個完全否定的態度，那是非常困難的。所以，大部分程式設計師都由於不能使自己進入必要的精神狀態（不是抱著要揭露出自己程式中錯誤的態度），就不能有效的測試自己的程式。除了這個心理學問題之外，還有一個重要的問題：程式中可能包含由於程式設計師對問題的敘述或說明的誤解而產生了錯誤。如果是這種情況，當程式設計師測試自己的程式時，往往還會帶著同樣的誤解致使問題難以發現。

3.程式設計組織不應測試自己的程式

在巨觀意義上，一個程式設計組織或一個工程項目是個有生命的有機體，它同樣有心理學問題。在大多數情況下，人們都以“在給定日期內，以一定代價完成程式編制任務的能力”來衡量程式設計組織和項目管理人員的。這樣做的理由是時間和成本指標便於衡量，而程式的質量很難度量。要程式設計組織在測試自己的程式時持客觀態度是很困難的，因為如果用正確的定義看待測試，就不大可能按預定計畫完成測試，也不大可能把耗費的代價限制在要求的範圍以內。

軟體生產的三個最重要的因素是：質量、進度和費用。由於費用和進度的限制，要開發一種高質量、快速交付和低成本的軟體產品並不容易。也就是說要同時達到三個目標是困難的。因此在軟體產品的開發中要權衡它們之間的關係，使軟體的特性能滿足用戶的要求，這意味著軟體產品的特性的度量和預計是必要的。

軟體測試由獨立測試機構承擔有很多好處。獨立測試是指軟體測試工作由在經濟上和管理上獨立於開發機構的組織進行。獨立測試可以避免軟體開發者測試自己開發的軟體，由於心理學上的問題，軟體開發者難以客觀、有效的測試自己的軟體，要找出那些因為對問題的誤解而產生的錯誤就更加困難。獨立測試還可以避免軟體開發機構測試自己的軟體，軟體產品的開發過程受到時間、成本和質量三者的制約，在軟體開發的過程中，當時間、成本和質量三者發生矛盾時，質量最容易被忽視，如果測試組織與開發組織來自相同的機構，測試過程就會面臨來自於開發組織同一來源的管理方面的壓力，使測試過程受到干擾。

客觀性——對軟體測試和軟體中的錯誤抱著客觀的態度，這種客觀的態度可以解決測試中的心理學問題，既能以揭露軟體中錯誤的態度工作，也能不受發現的錯誤的影響。經濟上的獨立性使測試有更充分的條件按測試要求去完成。

專業性——獨立測試作為一種專業工作，在長期的工作過程中勢必能夠積累大量實踐經驗，形成自己的專業知識。同時軟體測試也是技術含量很高的工作，需要有專業隊伍加以研究，並進行工程實踐。專業化分工是提高測試水平、保證測試質量、充分發揮測試效應的必然途徑。

權威性——由於專業優勢，獨立測試工作形成的測試結果更具信服力，而測試結果常常和對軟體的質量評價聯繫在一起，專業化的獨立測試機構的評價，更客觀、公正和具有權威性。

資源有保證——獨立測試機構的主要任務是進行獨立測試工作，這使得測試工作在經費、人力和計畫方面更有保證，不會因為開發的壓力減少對測試的投入，降低測試的有效性可以避免開發單位側重軟體開發而對測試工作產生不利的影響。

測試內容

軟體測試主要工作內容是驗證（verification）和確認（validation），下面分別給出其概念：

驗證(verification)是保證軟體正確地實現了一些特定功能的一系列活動， 即保證軟體以正確的方式來做了這個事件(Do it right)

1.確定軟體生存周期中的一個給定階段的產品是否達到前階段確立的需求的過程。

2.程式正確性的形式證明，即採用形式理論證明程式符合設計規約規定的過程。

3.評審、審查、測試、檢查、審計等各類活動，或對某些項處理、服務或檔案等是否和規定的需求相一致進行判斷和提出報告。

確認（validation）是一系列的活動和過程，目的是想證實在一個給定的外部環境中軟體的邏輯正確性。即保證軟體做了你所期望的事情。（Do the right thing）

1.靜態確認，不在計算機上實際執行程式，通過人工或程式分析來證明軟體的正確性。

2.動態確認，通過執行程式做分析，測試程式的動態行為，以證實軟體是否存在問題。

軟體測試的對象不僅僅是程式測試，軟體測試應該包括整個軟體開發期間各個階段所產生的文檔，如需求規格說明、概要設計文檔、詳細設計文檔，當然軟體測試的主要對象還是源程式。

測試方法

等價類

1.定義

是把所有可能的輸入數據，即程式的輸入域劃分成若干部分（子集），然後從每一個子集中選取少數具有代表性的數據作為測試用例。該方法是一種重要的，常用的黑盒測試用例設計方法。

2.劃分等價類

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

1)有效等價類

是指對於程式的規格說明來說是合理的、有意義的輸入數據構成的集合。利用有效等價類可檢驗程式是否實現了規格說明中所規定的功能和性能。

2)無效等價類

與有效等價類的定義恰巧相反。無效等價類指對程式的規格說明是不合理的或無意義的輸入數據所構成的集合。對於具體的問題，無效等價類至少應有一個，也可能有多個。

設計測試用例時，要同時考慮這兩種等價類。因為軟體不僅要能接收合理的數據，也要能經受意外的考驗，這樣的測試才能確保軟體具有更高的可靠性。

3.劃分等價類的標準

1)完備測試、避免冗餘；

2)劃分等價類重要的是：集合的劃分，劃分為互不相交的一組子集，而子集的並是整個集合；

3)並是整個集合：完備性；

4)子集互不相交：保證一種形式的無冗餘性；

5)同一類中標識（選擇）一個測試用例，同一等價類中，往往處理相同，相同處理映射到"相同的執行路徑"。

4.劃分等價類的方法

1)在輸入條件規定了取值範圍或值的個數的情況下，則可以確立一個有效等價類和兩個無效等價類。

如：輸入值是學生成績，範圍是0～100。

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

邊界值

1. 定義：邊界值分析法就是對輸入或輸出的邊界值進行測試的一種黑盒測試方法。通常邊界值分析法是作為對等價類劃分法的補充，這種情況下，其測試用例來自等價類的邊界。

2. 與等價劃分的區別

1) 邊界值分析不是從某等價類中隨便挑一個作為代表，而是使這個等價類的每個邊界都要作為測試條件。

2) 邊界值分析不僅考慮輸入條件，還要考慮輸出空間產生的測試情況。

3. 邊界值分析方法的考慮：

長期的測試工作經驗告訴我們，大量的錯誤是發生在輸入或輸出範圍的邊界上，而不是發生在輸入輸出範圍的內部。因此針對各種邊界情況設計測試用例，可以查出更多的錯誤。

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

4. 常見的邊界值

1) 對16-bit 的整數而言 32767 和 -32768 是邊界

2) 螢幕上游標在最左上、最右下位置

3) 報表的第一行和最後一行

4) 數組元素的第一個和最後一個

5) 循環的第 0 次、第 1 次和倒數第 2 次、最後一次

5. 邊界值分析

1) 邊界值分析使用與等價類劃分法相同的劃分，只是邊界值分析假定錯誤更多地存在於劃分的邊界上，因此在等價類的邊界上以及兩側的情況設計測試用例。

例：測試計算平方根的函式

--輸入：實數

--輸出：實數

--規格說明：當輸入一個0或比0大的數的時候，返回其正平方根；當輸入一個小於0的數時，顯示錯誤信息"平方根非法-輸入值小於0"並返回0；庫函式Print-Line可以用來輸出錯誤信息。

詳細分類

角度細分

從是否關心軟體內部結構和具體實現的角度劃分（按測試分類）

A.白盒測試

B.黑盒測試

C.灰盒測試

從是否執行程式的角度

A.靜態測試

B.動態測試

階段細分

從軟體開發的過程按階段劃分有

A.單元測試

B.集成測試

C.確認測試

D.系統測試

E.驗收測試

F.回歸測試

G.Alpha測試

H.Beta測試

* 測試過程按4個步驟進行，即單元測試、集成測試、確認測試和系統測試及發布測試。

* 開始是單元測試，集中對用原始碼實現的每一個程式單元進行測試，檢查各個程式模組是否正確地實現了規定的功能。

*集成測試把已測試過的模組組裝起來，主要對與設計相關的軟體體系結構的構造進行測試。

* 確認測試則是要檢查已實現的軟體是否滿足了需求規格說明中確定了的各種需求，以及軟體配置是否完全、正確。

* 系統測試把已經經過確認的軟體納入實際運行環境中，與其它系統成份組合在一起進行測試。

單元測試 (Unit Testing)

* 單元測試又稱模組測試，是針對軟體設計的最小單位 ─ 程式模組，進行正確性檢驗的測試工作。其目的在於發現各模組內部可能存在的各種差錯。

* 單元測試需要從程式的內部結構出發設計測試用例。多個模組可以平行地獨立進行單元測試。

1. 單元測試的內容

* 在單元測試時，測試者需要依據詳細設計說明書和源程式清單，了解該模組的I/O條件和模組的邏輯結構，主要採用白盒測試的測試用例，輔之以黑盒測試的測試用例，使之對任何合理的輸入和不合理的輸入，都能鑑別和回響。

(1) 模組接口測試

* 在單元測試的開始，應對通過被測模組的數據流進行測試。測試項目包括：

– 調用本模組的輸入參數是否正確；

– 本模組調用子模組時輸入給子模組的參數是否正確；

– 全局量的定義在各模組中是否一致

* 在做內外存交換時要考慮：

– 檔案屬性是否正確；

– OPEN與CLOSE語句是否正確；

– 緩衝區容量與記錄長度是否匹配；

– 在進行讀寫操作之前是否打開了檔案；

– 在結束檔案處理時是否關閉了檔案；

– 正文書寫/輸入錯誤，

– I/O錯誤是否檢查並做了處理。

(2) 局部數據結構測試

* 不正確或不一致的數據類型說明

* 使用尚未賦值或尚未初始化的變數

* 錯誤的初始值或錯誤的預設值

* 變數名拼寫錯或書寫錯

* 不一致的數據類型

* 全局數據對模組的影響

(3) 路徑測試

* 選擇適當的測試用例，對模組中重要的執行路徑進行測試。

* 應當設計測試用例查找由於錯誤的計算、不正確的比較或不正常的控制流而導致的錯誤。

* 對基本執行路徑和循環進行測試可以發現大量的路徑錯誤。

(4) 錯誤處理測試

* 出錯的描述是否難以理解

* 出錯的描述是否能夠對錯誤定位

* 顯示的錯誤與實際的錯誤是否相符

* 對錯誤條件的處理正確與否

* 在對錯誤進行處理之前，錯誤條件是否已經引起系統的干預等

(5) 邊界測試

* 注意數據流、控制流中剛好等於、大於或小於確定的比較值時出錯的可能性。對這些地方要仔細地選擇測試用例，認真加以測試。

* 如果對模組運行時間有要求的話，還要專門進行關鍵路徑測試，以確定最壞情況下和平均意義下影響模組運行時間的因素。

2. 單元測試的步驟

* 模組並不是一個獨立的程式，在考慮測試模組時，同時要考慮它和外界的聯繫，用一些輔助模組去模擬與被測模組相聯繫的其它模組。

– 驅動模組 (driver)

– 樁模組 (stub) ── 存根模組

* 如果一個模組要完成多種功能，可以將這個模組看成由幾個小程式組成。必須對其中的每個小程式先進行單元測試要做的工作，對關鍵模組還要做性能測試。

* 對支持某些標準規程的程式，更要著手進行互聯測試。有人把這種情況特別稱為模組測試，以區別單元測試。

集成測試（Integrated Testing）

* 集成測試 (組裝測試、聯合測試）

* 通常，在單元測試的基礎上，需要將所有模組按照設計要求組裝成為系統。這時需要考慮的問題是：

– 在把各個模組連線起來的時候，穿越模組接口的數據是否會丟失；

– 一個模組的功能是否會對另一個模組的功能產生不利的影響

– 各個子功能組合起來，能否達到預期要求的父功能；

– 全局數據結構是否有問題；

– 單個模組的誤差累積起來，是否會放大，從而達到不能接受的程度。

在單元測試的同時可進行集成測試，發現並排除在模組連線中可能出現的問題，最終構成要求的軟體系統。

* 子系統的集成測試特別稱為部件測試，它所做的工作是要找出集成後的子系統與系統需求規格說明之間的不一致。

* 通常，把模組集成成為系統的方式有兩種

– 一次性集成方式

– 增殖式集成方式

1. 一次性集成方式(big bang)

* 它是一種非增殖式組裝方式。也叫做整體拼裝。

* 使用這種方式，首先對每個模組分別進行模組測試，然後再把所有模組組裝在一起進行測試，最終得到要求的軟體系統。

2. 增殖式集成方式

* 這種集成方式又稱漸增式集成

* 首先對一個個模組進行模組測試，然後將這些模組逐步組裝成較大的系統

* 在集成的過程中邊連線邊測試，以發現連線過程中產生的問題

* 通過增殖逐步組裝成為要求的軟體系統。

(1) 自頂向下的增殖方式

* 這種集成方式將模組按系統程式結構，沿控制層次自頂向下進行組裝。

* 自頂向下的增殖方式在測試過程中較早地驗證了主要的控制和判斷點。

* 選用按深度方向組裝的方式，可以首先實現和驗證一個完整的軟體功能。

(2) 自底向上的增殖方式

* 這種集成的方式是從程式模組結構的最底層的模組開始集成和測試。

* 因為模組是自底向上進行組裝，對於一個給定層次的模組，它的子模組（包括子模組的所有下屬模組）已經組裝並測試完成，所以不再需要樁模組。在模組的測試過程中需要從子模組得到的信息可以直接運行子模組得到。

* 自頂向下增殖的方式和自底向上增殖的方式各有優缺點。

* 一般來講，一種方式的優點是另一種方式的缺點。

(3) 混合增殖式測試

* 衍變的自頂向下的增殖測試

– 首先對輸入/輸出模組和引入新算法模組進行測試；

– 再自底向上組裝成為功能相當完整且相對獨立的子系統；

– 然後由主模組開始自頂向下進行增殖測試。

* 自底向上-自頂向下的增殖測試

– 首先對含讀操作的子系統自底向上直至根結點模組進行組裝和測試；

– 然後對含寫操作的子系統做自頂向下的組裝與測試。

* 回歸測試

– 這種方式採取自頂向下的方式測試被修改的模組及其子模組；

– 然後將這一部分視為子系統，再自底向上測試。

關鍵模組問題

* 在組裝測試時，應當確定關鍵模組，對這些關鍵模組及早進行測試。

* 關鍵模組的特徵：

① 滿足某些軟體需求

② 在程式的模組結構中位於較高的層次（高層控制模組）

③ 較複雜、較易發生錯誤

④ 有明確定義的性能要求。

確認測試（Validation Testing）

* 確認測試又稱有效性測試。任務是驗證軟體的功能和性能及其它特性是否與用戶的要求一致。

* 對軟體的功能和性能要求在軟體需求規格說明書中已經明確規定。它包含的信息就是軟體確認測試的基礎。

1. 進行有效性測試（黑盒測試）

* 有效性測試是在模擬的環境 (可能就是開發的環境) 下，運用黑盒測試的方法，驗證被測軟體是否滿足需求規格說明書列出的需求。

* 首先制定測試計畫，規定要做測試的種類。還需要制定一組測試步驟，描述具體的測試用例。

* 通過實施預定的測試計畫和測試步驟，確定

– 軟體的特性是否與需求相符；

– 所有的文檔都是正確且便於使用；

– 同時，對其它軟體需求，例如可移植性、兼容性、出錯自動恢復、可維護性等，也都要進行測試

* 在全部軟體測試的測試用例運行完後，所有的測試結果可以分為兩類：

– 測試結果與預期的結果相符。這說明軟體的這部分功能或性能特徵與需求規格說明書相符合，從而這部分程式被接受。

– 測試結果與預期的結果不符。這說明軟體的這部分功能或性能特徵與需求規格說明不一致，因此要為它提交一份問題報告。

2. 軟體配置複查

軟體配置複查的目的是保證軟體配置的所有成分都齊全；

各方面的質量都符合要求；

具有維護階段所必需的細節；

而且已經編排好分類的目錄。

應當嚴格遵守用戶手冊和操作手冊中規定的使用步驟，以便檢查這些文檔資料的完整性和正確性。

系統測試（System Testing）

* 系統測試，是將通過確認測試的軟體，作為整個基於計算機系統的一個元素，與計算機硬體、外設、某些支持軟體、數據和人員等其它系統元素結合在一起，在實際運行環境下，對計算機系統進行一系列的組裝測試和確認測試。

* 系統測試的目的在於通過與系統的需求定義作比較， 發現軟體與系統的定義不符合或與之矛盾的地方。

驗收測試（Acceptance Testing）

* 在通過了系統的有效性測試及軟體配置審查之後，就應開始系統的驗收測試。

* 驗收測試是以用戶為主的測試。軟體開發人員和QA（質量保證）人員也應參加。

* 由用戶參加設計測試用例，使用生產中的實際數據進行測試。

* 在測試過程中，除了考慮軟體的功能和性能外，還應對軟體的可移植性、兼容性、可維護性、錯誤的恢復功能等進行確認。

*確認測試應交付的文檔有：

– 確認測試分析報告

– 最終的用戶手冊和操作手冊

– 項目開發總結報告。

測試流程

1、制定測試計畫

2、編輯測試用例

3、執行測試用例

4、發現並提交BUG

5、開發組修正BUG

6、對已修正BUG進行返測

7、修正完成的BUG將狀態置為已關閉，未正確修正的BUG重新激活

測試階段

單元測試

單元測試是對軟體組成單元進行測試，其目的是檢驗軟體基本組成單位的正確性，測試的對象是軟體設計的最小單位：模組。

集成測試

集成測試也稱聯合測試，將程式模組採用適當的集成策略組裝起來，對系統的接口及集成後的功能進行正確性檢測的測試工作。其主要目的是檢查軟體單位之間的接口是否正確，集成測試的對象是已經經過單元測試的模組。

系統測試

系統測試主要包括功能測試、界面測試、可靠性測試、易用性測試、性能測試。 功能測試主要針對包括功能可用性、功能實現程度（功能流程&業務流程、數據處理&業務數據處理）方面測試。

回歸測試

回歸測試指在軟體維護階段，為了檢測代碼修改而引入的錯誤所進行的測試活動。回歸測試是軟體維護階段的重要工作，有研究表明，回歸測試帶來的耗費占軟體生命周期的1/3總費用以上。

與普通的測試不同，在回歸測試過程開始的時候，測試者有一個完整的測試用例集可供使用，因此，如何根據代碼的修改情況對已有測試用例集進行有效的復用是回歸測試研究的重要方向，此外，回歸測試的研究方向還涉及自動化工具，面向對象回歸測試，測試用例優先權，回歸測試用例補充生成等。

測試模型

V模型

測試階段:

單元測試

集成測試

系統測試

實現意義

V模型是軟體開發瀑布模型的變種，它反映了測試活動與分析和設計的關係 。

從左到右，描述了基本的開發過程和測試行為，非常明確地標明了測試過程中存在的不同級別，並且清楚地描述了這些測試階段和開發過程期間各階段的對應關係 。

左邊依次下降的是開發過程各階段，與此相對應的是右邊依次上升的部分，即各測試過程的各個階段。

用戶需求 驗收測試

需求分析和系統設計 確認測試和系統測試

概要設計 集成測試

詳細設計 單元測試

編碼

V模型問題

軟體測試V模型

1.測試是開發之後的一個階段。

2.測試的對象就是程式本身。

3.實際套用中容易導致需求階段的錯誤一直到最後系統測試階段才被發現。

4.整個軟體產品的過程質量保證完全依賴於開發人員的能力和對工作的責任心，而且上一步的結果必須是充分和正確的，如果任何一個環節出了問題，則必將嚴重的影響整個工程的質量和預期進度

W模型

W模型由Evolutif公司公司提出，相對於V模型，W模型增加了軟體各開發階段中應同步進行的驗證和確認活動。W模型由兩個V字型模型組成，分別代表測試與開發過程，圖中明確表示出了測試與開發的並行關係。 W模型強調：測試伴隨著整個軟體開發周期，而且測試的對象不僅僅是程式，需求、設計等同樣要測試，也就是說，測試與開發是同步進行的。W模型有利於儘早地全面的發現問題。例如，需求分析完成後，測試人員就應該參與到對需求的驗證和確認活動中，以儘早地找出缺陷所在。同時，對需求的測試也有利於及時了解項目難度和測試風險，及早制定應對措施，這將顯著減少總體測試時間，加快項目進度。 但W模型也存在局限性。在W模型中，需求、設計、編碼等活動被視為串列的，同時，測試和開發活動也保持著一種線性的前後關係，上一階段完全結束，才可正式開始下一個階段工作。這樣就無法支持疊代的開發模型。對於當前軟體開發複雜多變的情況，W模型並不能解除測試管理面臨著困惑。

軟體測試

H模型

H模型中， 軟體測試過程活動完全獨立，貫穿於整個產品的周期，與其他流程並發地進行，某個測試點準備就緒時，就可以從測試準備階段進行到測試執行階段。軟體測試可以儘早的進行，並且可以根據被測物的不同而分層次進行。

這個示意圖演示了在整個生產周期中某個層次上的一次測試“微循環”。圖中標註的其它流程可以是任意的開發流程，例如設計流程或者編碼流程。也就是說， 只要測試條件成熟了，測試準備活動完成了，測試執行活動就可以進行了。

軟體測試

H模型揭示了一個原理：軟體測試是一個獨立的流程，貫穿產品整個生命周期，與其他流程並發地進行。H模型指出軟體測試要儘早準備， 儘早執行。不同的測試活動可以是按照某個次序先後進行的，但也可能是反覆的，只要某個測試達到準備就緒點，測試執行活動就可以開展。

X模型

X模型也是對V模型的改進，X模型提出針對單獨的程式片段進行相互分離的編碼和測試，此後通過頻繁的交接，通過集成最終合成為可執行的程式。X模型的左邊描述的是針對單獨程式片段所進行的相互分離的編碼和測試，此後將進行頻繁的交接，通過集成最終成為可執行的程式，然後再對這些可執行程式進行測試。己通過集成測試的成品可以進行封裝並提交給用戶，也可以作為更大規模和範圍內集成的一部分。多根並行的曲線表示變更可以在各個部分發生。由圖中可見，X模型還定位了探索性測試，這是不進行事先計畫的特殊類型的測試，這一方式往往能幫助有經驗的測試人員在測試計畫之外發現更多的軟體錯誤。但這樣可能對測試造成人力、物力和財力的浪費，對測試員的熟練程度要求比較高。

軟體測試

測試工具

Test Platform軟體測試平台，簡稱TP，是業界唯一的對軟體測試全過程進行支撐的軟體測試工具。

業界已有的軟體測試工具基本上都局限在測試執行階段，只能支撐測試執行階段的活動，而測試分析、測試設計、測試實現這三個前期階段的活動缺乏有效的測試工具支撐，直接影響了軟體測試的完整性和充分性，從而影響最終研發的軟體質量。David.yuan這樣說：企業使用了博為峰TP測試平台，整個軟體測試過程的 測試覆蓋率提高到前所未有的高度和廣度，可以極好的達成軟體在安全性、健壯性、穩定性和功能、性能方面的要求，即使是沒有很多年測試經驗的管理和測試人員，通過TP測試平台就可以完成智慧型化地管理、設計、分析、執行整個測試過程，達到一流測試管理專家所做到的效果。

引入缺陷分析

在業界首先將各種有效的缺陷分析模型引入到該軟體平台中，包括ODC分析、Gompertz分析、Rayleigh分析、四象限分析、缺陷注入分析、DRE/DRM等工程方法，幫助管理者建立軟體研發過程的質量基線、測試能力基線，並幫助管理者將項目實際缺陷、能力數據和基線數據進行對比分析，發現軟體過程中的改進點，判斷測試是否可以退出、軟體是否可以發布，並對軟體中殘留缺陷數進行預測；

利用理論分析

建立了測試分析和設計的理論框架和一整套工程方法，能夠很好的支撐測試的輔助分析和設計；

建立測試關係

建立“開發需求項－>測試項－>測試子項－>測試用例－>缺陷”的測試跟蹤關係，能夠及時的反應開發需求和設計的變更對測試的影響範圍，保證軟體的一致性和測試的充分性，從而保證軟體的質量；

使用管理工具

能夠全面的管理軟體質量工作，具有高度的集成性，一款TestPlatform能夠完成多款其他各類的相關質量管理工具集成在一起才能完成的軟體質量管理工作。它集成了需求跟蹤、靜態測試、動態測試、測試人員管理、測試環境管理、測試計畫管理、測試用例管理、缺陷管理、缺陷分析等軟體質量相關的流程。

AutoRunner是國內第一款自動化測試工具，可以用來完成功能測試、回歸測試、每日構建測試與自動回歸測試等工作。是具有腳本語言的、提供針對腳本完善的跟蹤和調試功能的、支持IE測試和Windows native測試的自動化測試工具。

TestCenter是一款功能強大測試管理工具，它可以幫助您：實現測試用例的過程管理，對測試需求過程、測試用例設計過程、業務組件設計實現過程等整個測試過程進行管理。實現測試用例的標準化即每個測試人員都能夠理解並使用標準化後的測試用例，降低了測試用例對個人的依賴；提供測試用例復用，用例和腳本能夠被復用，以保護測試人員的資產；提供可伸縮的測試執行框架，提供自動測試支持；提供測試數據管理，幫助用戶同意管理測試數據，降低測試數據和測試腳本之間的耦合度。

TAR(Terminal AutoRunner)適用於VT100、VT220等標準的套用系統，支持命令行模式和視窗模式（使用Cursors編寫的應用程式），支持自動錄製腳本、所見即所得的資源和腳本編輯，穩定的自動同步功能。是目前國內最好的銀行業務測試工具.

TestDirector是全球最大的軟體測試工具提供商Mercury Interactive公司生產的企業級測試管理工具，也是業界第一個基於Web的測試管理系統，它可以在您公司內部或外部進行全球範圍內測試的管理。通過在一個整體的套用系統中集成了測試管理的各個部分，包括需求管理，測試計畫，測試執行以及錯誤跟蹤等功能，TestDirector極大地加速了測試過程。

程式測試

外包軟體測試就是指軟體企業將軟體項目中的全部或部分測試工作，交給提供軟體外包測試服務的公司，由他們為軟體進行專門的測試。這樣做的好處有兩個：一方面軟體企業可以更好地專注核心競爭力業務，同時降低軟體項目成本；另一方面，由第三方專業的測試公司進行測試，無論在技術上還是管理上，對提高軟體測試的有效性都具有重要意義。

外包軟體測試行業前景非常看好，發展空間很大。IDG的數據顯示，最近幾年，中國的軟體外包產業年均增長率為36.5%，正處於快速發展的階段，2008年預計已達到16.9億美元的市場規模。韓日、歐美國家的軟體企業紛紛關注中國市場，而作為軟體外包強國的印度，在其國內處於前幾位的軟體外包服務商也準備來“分一杯羹”。從市場來看，選擇將部分軟體測試工作進行外包的公司主要是微軟、IBM等國際軟體旗艦企業，他們利用第三方專業軟體測試公司，在產品發布前對軟體進行一系列的集成測試和系統測試，既保證了測試工作的全面性，又節省了人力、物力的開銷。最重要的是，測試結果往往好於這些軟體企業最初的預期，效果非常令人滿意。軟體企業和提供軟體外包測試服務的公司進行合作，只要達成雙贏，兩方皆大歡喜，這樣的合作就會越來越多，項目也會越做越大。

主要業務類型

·本地化軟體測試

·國際化軟體測試

主要測試範圍

·本地化語言質量測試

·國際化軟體的功能和性能測試

測試主要方式

·公司內部（Off site）執行的測試

·派駐客戶開發中心的現場測試（On site）。

現狀前景

現狀

軟體開發中出現錯誤或缺陷的機會越來越多，市場對軟體質量重要性的認識逐漸增強。所以，軟體測試在軟體項目實施過程中的重要性日益突出。但是，現實情況是，與軟體編程比較，軟體測試的地位和作用，還沒有真正受到重視，對於很多人（甚至是軟體項目組的技術人員）還存在對軟體測試的認識誤區，這進一步影響了軟體測試活動開展和真正提高軟體測試質量。

（1）誤區之一：軟體開發完成後進行軟體測試

人們一般認為，軟體項目要經過以下幾個階段：需求分析，概要設計，詳細設計，軟體編碼，軟體測試，軟體發布。據此，認為軟體測試只是軟體編碼後的一個過程。這是不了解軟體測試周期的錯誤認識。軟體測試是一個系列過程活動，包括軟體測試需求分析，測試計畫設計，測試用例設計，執行測試。因此，軟體測試貫穿於軟體項目的整個生命過程。在軟體項目的每一個階段都要進行不同目的和內容的測試活動，以保證各個階段的正確性。軟體測試的對象不僅僅是軟體代碼，還包括軟體需求文檔和設計文檔。軟體開發與軟體測試應該是互動進行的，例如，單元編碼需要單元測試，模組組合階段需要集成測試。如果等到軟體編碼結束後才進行測試，那么，測試的時間將會很短，測試的覆蓋面將很不全面，測試的效果也將大打折扣。更嚴重的是如果此時發現了軟體需求階段或概要設計階段的錯誤，如果要修復該類錯誤，將會耗費大量的時間和人力。

（2）誤區之二：軟體發布後如果發現質量問題，那是軟體測試人員的錯

這種認識很打擊軟體測試人員的積極性。軟體中的錯誤可能來自軟體項目中的各個過程，軟體測試只能確認軟體存在錯誤，不能保證軟體沒有錯誤，因為從根本上講，軟體測試不可能發現全部的錯誤。從軟體開發的角度看，軟體的高質量不是軟體測試人員測出來的，是靠軟體生命周期的各個過程中設計出來的。出現軟體錯誤，不能簡單地歸結為某一個人的責任，有些錯誤的產生可能不是技術原因，可能來自於混亂的項目管理。應該分析軟體項目的各個過程，從過程改進方面尋找產生錯誤的原因和改進的措施。

（3）誤區之三：軟體測試要求不高，隨便找個人做都行

很多人都認為軟體測試就是安裝和運行程式，點點滑鼠，按按鍵盤的工作。這是由於不了解軟體測試的具體技術和方法造成的。隨著軟體工程學的發展和軟體項目管理經驗的提高，軟體測試已經形成了一個獨立的技術學科，演變成一個具有巨大市場需求的行業。軟體測試技術不斷更新和完善，新工具，新流程，新測試設計方法都在不斷更新，需要掌握和學習很多測試知識。所以，具有編程經驗的程式設計師不一定是一名優秀的測試工程師。軟體測試包括測試技術和管理兩個方面，完全掌握這兩個方面的內容，需要很多測試實踐經驗和不斷學習的精神。

（4）誤區之四：軟體測試是測試人員的事情，與程式設計師無關

開發和測試是相輔相成的過程，需要軟體測試人員、程式設計師和系統分析師等保持密切的聯繫，需要更多的交流和協調，以便提高測試效率。另外，對於單元測試主要應該由程式設計師完成，必要時測試人員可以幫助設計測試樣例。對於測試中發現的軟體錯誤，很多需要程式設計師通過修改編碼才能修復。程式設計師可以通過有目的的分析軟體錯誤的類型、數量，找出產生錯誤的位置和原因，以便在今後的編程中避免同樣的錯誤，積累編程經驗，提高編程能力。

（5）誤區之五：項目進度吃緊時少做些測試，時間富裕時多做測試

這是不重視軟體測試的表現，也是軟體項目過程管理混亂的表現，必然會降低軟體測試的質量。一個軟體項目的順利實現需要有合理的項目進度計畫，其中包括合理的測試計畫，對項目實施過程中的任何問題，都要有風險分析和相應的對策，不要因為開發進度的延期而簡單的縮短測試時間、人力和資源。因為縮短測試時間帶來的測試不完整，對項目質量的下降引起的潛在風險，往往造成更大的浪費。克服這種現象的最好辦法是加強軟體過程的計畫和控制，包括軟體測試計畫、測試設計、測試執行、測試度量和測試控制。

（6）誤區之六：軟體測試是沒有前途的工作，只有程式設計師才是軟體高手

由於我國軟體整體開發能力比較低，軟體過程很不規範，很多軟體項目的開發都還停留在“作坊式”和“壘雞窩”階段。項目的成功往往靠個別全能程式設計師決定，他們負責總體設計和程式詳細設計，認為軟體開發就是編寫代碼，給人的印象往往是程式設計師是真正的牛人，具有很高的地位和待遇。因此，在這種環境下，軟體測試很不受重視，軟體測試人員的地位和待遇自然就很低了，甚至軟體測試變得可有可無。隨著市場對軟體質量的不斷提高，軟體測試將變得越來越重要，相應的軟體測試人員的地位和待遇將會逐漸提高。在軟體過程比較規範的大公司，軟體測試人員的數量和待遇與程式設計師沒有多大差別，優秀測試人員的待遇甚至比程式設計師還要高。軟體測試將會成為一個具有很大發展前景的行業，軟體測試大有前途，市場需要更多具有豐富測試技術和管理經驗的測試人員，他們同樣是軟體專家。

前景

隨著軟體產業的發展，軟體產品的質量控制與質量管理正逐漸成為軟體企業生存與發展的核心。幾乎每個大中型IT企業的軟體產品在發布前都需要大量的質量控制、測試和文檔工作，而這些工作必須依靠擁有嫻熟技術的專業軟體人才來完成。軟體測試工程師就是這樣的一個企業重頭角色。業內人士分析，該類職位的需求主要集中在沿海發達城市，其中北京和上海的需求量分別占去33%和29%。民企需求量最大，占19%，外商獨資歐美類企業需求排列第二，占15%。然而，現狀是：一方面企業對高質量的測試工程師需求量越來越大越大，另一方面國內原來對測試工程師的職業重視程度不夠，使許多人不了解測試工程師具體是從事什麼工作。這使得許多IT公司只能通過在實際工作中進行淘汰的方式對測試工程師進行篩選，因此國內在短期將出現測試工程師嚴重短缺的現象。根據對網路招聘IT人才情況的了解，許多正在招聘軟體測試工程師的企業很少能夠在招聘會上順利招到合適的人才。在具體工作過程中，測試工程師的工作是利用測試工具按照測試方案和流程對產品進行功能和性能測試，甚至根據需要編寫不同的測試用例，設計和維護測試系統，對測試方案可能出現的問題進行分析和評估。對軟體測試工程師而言，必須具有高度的工作責任心和自信心。任何嚴格的測試必須是一種實事求是的測試，因為它關係到一個產品的質量問題，而測試工程師則是產品出貨前的把關人，所以，沒有專業的技術水準是無法勝任這項工作的。同時，由於測試工作一般由多個測試工程師共同完成，並且測試部門一般要與其他部門的人員進行較多的溝通，所以要求測試工程師不但要有較強的技術能力而且要有較強的溝通能力。

涉及問題

程式測試的過程具有破壞性

人類的活動具有高度的目的性，建立適當的目標具有重要的心理作用。如果我們的目的是要證明程式中沒有錯誤，那我們就會不自覺地朝這個方向去做；也就是說，我們會傾向於挑選那些使程式出錯的可能性較小的測試數據。另一方面，如果我們的目標是要證明程式中有錯，那就會選擇一些易於發現程式所含錯誤的測試數據。而後一種態度會比前者給程式增添更多的價值。

日常工作

1. 熟悉軟體測試流程，有智慧型產品/網路套用經驗者優先考慮；
2. 熟悉軟體測試理論和方法，能夠熟練套用多種測試工具；
3. 熟悉 C/C++/C#/Java編程， 有網路協定測試經驗；
4. 有較強的邏輯分析能力和學習能力，具備較強的總結能力；
5. 熱愛軟體測試工作，可以勝任重複性工作。
6. 編寫用例

軟體測試員是指根據測試計畫和測試方案進行軟體測試；能夠針對軟體需求開發測試模型，制定測試方案，安排測試計畫，並對測試項目進行管理的專業人員。每一階段的測試都是為了減少軟體的bug和提升軟體的功能需求，所以測試人員必須具備良好的編程功底。

專業優勢

就業競爭小

人才供不應求讓軟體測試人員的就業競爭壓力明顯小於同類其它職業，有利於從業者的身心健康。另外，由於軟體測試在我國起步較晚，獨立設定測試部門、對測試人員有強烈需求的多為獨具慧眼的大中型IT企業。軟體測試人才不需要在小企業積累經驗就能獲得知名企業的入門通行證，工作起點高於同類其它職業。

高薪

剛入行的軟體測試人員，起步的月薪就在7000-15000元左右，平均薪資8000/月以上，隨著工作經驗的豐富以及能力的提升，這份薪水將一路看漲。

就業質量高

與其他IT職位相比，軟體測試人員最大的優勢就是發展方向太多了。由於工作的特殊性，測試人員不但需要對軟體的質量進行檢測，而且對於軟體項目的立項、管理、售前、售後等領域都要涉及。在此過程中，測試人員不僅提升了專業的軟體測試技能，還能接觸到各行各業，從而為自己的多元化發展奠定了基礎。

無性別歧視

如果把軟體開發領域比作“男子單打”，那么，軟體測試領域就是“混合雙打”。由於工作的特殊性，軟體測試人員更要具有認真、耐心、細緻、敏感等個性元素，而這在一定程度上與女性的個性氣質相吻合。據了解，很多IT企業中軟體測試人員的比例更趨向男女平衡，甚至出現女性員工成主流的情況。

學習方法

1. 自學，去相關網站學習基礎的計算機語言，收集軟體測試教程學習。
2. 參加培訓機構進行專業的培訓與實踐。

自動化測試

測試需要覆蓋到企業應用程式產品線的所有套用。通常，首先是去【問】“風險最大的套用是哪個？”並且一個個單獨查看。但是如果所有的低風險應用程式加起來有無數漏洞，也會造成災難。”

配對，但是要更為靈活，測試人員需要將代碼自動化的任務留給開發人員。這是開發人員得到反饋最為迅速的方式，如果我們讓測試人員整天做自動測試，這是浪費時間。相反，應該讓測試人員和開發人員配對，並且幫助他們（開發人員）學習如何進行測試。一個優秀的測試人員能給團隊帶來什麼？很多很多。

配對，然後真正的配對，就像mob編程團隊一樣。在mob編程里，一組有六到八名開發人員，他們集中到一個屋子裡，一起狂熱地寫代碼。其實這一理念也可以用在測試上（有人稱之為mob測試），或者作為將測試人員和開發人員集中到同一個房間的方式，來一起找到解決問題的方法 。