軟體測試工程師

按其級別和職位的不同，可分為三類：

高級軟體測試工程師，熟練掌握軟體測試與開發技術，且對所測試軟體對口行業非常了解，能夠對可能出現的問題進行分析評估；

中級軟體測試工程師，編寫軟體測試方案、測試文檔，與項目組一起制定軟體測試階段的工作計劃，能夠在項目運行中合理利用測試工具完成測試任務；

初級軟體測試工程師，其工作通常都是按照軟體測試方案和流程對產品進行功能測驗，檢察產品是否有缺陷。

軟體項目開發是個分工明確的系統工程，不同的人員扮演了不同的角色，包括部門經理、產品經理、項目經理、系統分析師、程序員、測試工程師、質量保證人員等。可見，軟體測試工程師只是軟體項目開發中的一個角色而已。

測試工程師承擔的任務角色決定工作內容和承擔的任務。測試工程師的角色應該承擔什麼任務呢？這沒有統一的答案。因為，這與軟體公司的規模，軟體項目管理制度，公司領導和項目經理的管理風格，以及具體軟體項目自身的特點有很大關係。而且，測試工程師也有普通和高級之分。

籠統的答案列舉如下：

設置軟體測試環境，安裝必要的軟體工具。

運行軟體，發現和報告軟體缺陷或錯誤。尤其需要快速定位軟體中的嚴重的錯誤。

對軟體整體質量提出評估

確認軟體達到某種具體標準

以最低的成本，最短的時間，完成高質量的測試任務

在這其中，最重要的是要明確程序員的責任和目標。在執行任何具體測試任務前，都要在項目組內對於責任和目標達成共識，以免帶來後續工作的相互推諉。

提高測試質量的要訣

另外一個值得注意的方面就是工作效率和質量，或許高級測試工程師與普通測試工程師的主要區別在於高級測試工程師可以更快地發現更多軟體中的嚴重錯誤。對此，有什麼可以借鑒的訣竅嗎？請嘗試以下方法，保證不會使您失望。

首先測試程序的核心功能，然後測試輔助功能。

首先測試功能，然後測試性能。

首先測試常見情況，然後測試異常情況。

首先測試經過變更的部分，然後測試沒有變更的部分。

首先測試影響大的問題，然後測試影響小的問題。

首先測試必須測試的部分，然後測試可選或沒有要求測試的部分。

服務員

需要強調的一點是，無論你是多麼高級的測試工程師，都要明白無論測試需要的工具多麼複雜，測試步驟多麼冗長，測試工程師在軟體項目開發中始終都是扮演服務員的角色，這是由測試工作的特點決定的。任何服務都有被服務對象—客戶，測試工程師的服務對象有哪些呢？

最重要的客戶是軟體的用戶。測試工程師需要站在客戶的使用和需求角度測試軟體，報告問題。

項目經理也是客戶。測試工程師需要報告測試工作進度和發現的問題，尤其是嚴重的問題。

程序員是最經常打交道的客戶。為了便於程序員重複報告的錯誤，盡量提供良好的軟體問題報告，以便程序員可以更快的修復軟體錯誤。

技術文檔工程師、市場開發人員和技術支持工程師也都是測試工程師的服務對象。

避免錯誤

前文已經指出測試工程師應該明確角色，明確任務和責任。知道哪些是自己分內的事，哪些是不屬於自己的事。一定要盡最大努力完成分內的事，不要做不屬於自己的事情，以免弄巧成拙。

為了更好的扮演軟體測試工程師的角色，盡量避免犯下面的錯誤：

⒈承諾完成測試的軟體沒有質量問題

軟體測試只是保證質量的一種方法，軟體測試工程師的工作不會直接提高軟體質量，因為絕大多數軟體錯誤都需要程序員修復。軟體測試只能證明軟體存在錯誤，不能保證軟體沒有錯誤，不可能找出全部軟體錯誤。個人的能力和對質量的影響範圍很小，軟體質量的提高要靠軟體項目團隊全體成員的共同努力。

⒉承擔軟體的發布權利

不要因為軟體中存在還沒有修復的錯誤，而試圖提出更改軟體發布的計劃。也不要認為已經完成了測試計劃，自己決定可以發布軟體。因為，改變軟體發布計劃可能要失去進入市場的良機和很多客戶，對此造成的經濟和公司市場的損失將不是測試工程師能夠承擔的。另外，軟體發布后，如果用戶發現了新的軟體錯誤，公司領導或項目經理可能將過錯加在軟體測試人員的頭上，因為他們同意發布軟體。通常軟體發布的權利由產品經理、項目經理、測試經理、市場經理共同集體討論決定。

⒊扮演過程改進成員的角色

軟體測試工程師必須報告錯誤，有時也要分析錯誤的類型、特徵和產生錯誤的原因。但是，不要主動提出改進軟體過程的具體改進措施，更不要直接干涉程序員的工作方式，以免出力不討好，影響今後的愉快合作。軟體過程改進的方法是軟體質量控制部門的事情，這是他們的本職工作。

軟體測試就是使用人工或自動手段，來運行或測試某個系統的過程。其目的在於檢驗它是否滿足規定的需求或弄清預期結果與實際結果之間的差別。開發工作的根本是盡量實現軟體用戶的需求，測試工作的根本是檢驗軟體系統是否滿足軟體用戶的需求。

軟體測試工程師簡單的說是軟體開發過程中的質量檢測者和保障者，負責軟體質量的把關工作。軟體測試工程師 具體工作有：

1 、使用各種測試技術和方法來測試和發現軟體中存在的軟體缺陷。測試技術主要分為黑盒測試和白盒測試兩大類。其中黑盒測試技術主要有等價類劃分法、邊界值法、因果圖法、狀態圖法、測試大綱法以及各類典型的軟體故障模型等；白盒測試的主要技術有語句覆蓋、分支覆蓋、判定覆蓋、基本路徑覆蓋等；

2 、測試工作需要貫穿整個軟體開發生命周期。完整的軟體測試工作包括單 元測試、集成測試、確認測試和系統測試工作。單元測試工作主要在編碼階段完成，由開發人員和軟體測試工程師共同完成，其主要依據是詳細測試。集成測試的主要工作測試軟體模塊之間的介面是否正確實現，基本依據是軟體體系結構設計。確認測試和系統測試是在軟體開發完成後，驗證軟體的功能與需求的一致性、驗證軟體在相應的硬體條件下的系統功能是否滿足用戶需求，其主要依據是用戶需求。

3 、測試人員將發現的缺陷編寫成正式的缺陷報告，提交給開發人員進行缺陷的確認和修復。缺陷報告編寫最主要的要求是保證缺陷的重現。要求測試人員具有很好的文字表達能力和語言組織能力。

4 、測試人員需要分析軟體質量。在測試完成後，測試人員需要根據測試結果來分析軟體質量，包括缺陷率、缺陷分佈、缺陷修復趨勢等。給出軟體各種質量特性包括有功能性、可靠性、易用性、安全性、時間與資源特性等的具體度量。最後給出一個軟體是否可以發布或提交用戶使用的結論。

5 、測試過程中，為了更好地組織與實施測試工作，測試負責人需要制定測試計劃，包括有測試資源、測試進度、測試策略、測試方法、測試工具、測試風險等。

6 、測試人員為了更好更有效地進行測試，保證測試工作質量，需要在執行測試工作之前首先需要設計測試用例，形成測試用例報告。設計測試用例是保證測試質量的核心工作，很多測試技術都可以用來指導設計用例。為了提高測試用例的設計效率，BTEST培訓課程專門開設了高效設計測試用例一門課來講授各種設計用例的技術與方法。

7 、為了提高工作效率或提高測試水平，測試工作需要引進自動化測試工具，測試人員需要學會使用自動化測試工具，編寫測試腳本，進行性能測試等。

8 、測試負責人在測試工作中，還需要根據實際情況不斷改進測試過程，提高測試水平，進行測試隊伍的建設等。

測 試組長這類測試人員通常是測試項目的負責人，既要具備較高的測試技術能力，還要具備一定的管理能力。主要職責是制定測試計劃、編寫測試計劃、監控和管理整個測試過程。測試組長可以向上發展為測試部經理、質量經理，也可以橫向發展為項目經理，而且通常待遇相對較高些。

主要職責是對系統的測試結果進行綜合的分析，例如缺陷分析、性能分析等。測試分析師不但測試技術能力較強，還要具備資料庫、操作系統等多方面的技術知識。這類職務的發展空間也不錯，可以發展成系統設計師等。

主要職責是編寫測試程序、執行自動化測試任務。這類職位的測試人員至少要達到初級程序員的能力，因為經常和程序打交道。發展空間也不錯，例如可以發展為程序員。

入門門檻低

大中專學歷即可，是不是計算機專業都可以。如果是其他有業務背景的專業更有優勢，例如：會計、金融、辦公自動化、酒店管理、網站設計等。對於有行業背景的人來說入門更快，因為對於測試工作來說，有時懂業務比懂技術還重要，你會了技術，去各行各業做測試都是要學習業務知識的，這是很正常的事。

初級技術要求低

目前大部分測試技術還屬於手工測試，手工測試要求入門門檻很低。你只要會寫用例，會提缺陷就可以了。測試人員需要簡單了解業務知識，學習所開發系統的使用，也就是會使用系統就可以了。照著用例執行測試，發現缺陷直接提交缺陷就可以了。

很大的薪酬優勢

剛開始工作時月薪最低4000多，但工作半年，對工作流程了解后，再去換工作，五六千沒問題。如果做銀行業務測試起薪六七千沒問題，有一點銀行業務知識的再去換工作八千以上沒問題，現在銀行測試人員缺口很大。尤其是在大的外包公司做好的項目，比如銀行項目等待遇和同等工作經歷的開發差不多。

就業好

國外開發與測試的比例是1:2。目前國內開發與測試的比例是6:1。所以測試行業人才缺口很大，就業前景很好。基本屬於供不應求。

工作比較輕鬆

比起軟體開發工程師來說，軟體測試工程師的工作就相對輕鬆多了

測試分為三個階段：手工測試、自動化測試、性能測試。這是一個逐步提升的過程。最初工作可能做手工測試，也是目前絕大部分測試人員所從事的工作。自動化測試是測試的發展趨勢，而且現在自動化測試人員急缺，且薪資很高。現在最稀缺的是性能測試人員，目前性能測試人員的待遇比同等經歷的開發可能還要高，因為現在性能測試人員屬於稀缺狀態。

（1）手工測試：現在比較普及，大多數測試都還停留在手工測試階段。（2）自動化測試：是趨勢，但目前用自動化測試的還比較少，需要適當的代碼編寫工作。做一段手工測試后，積累一定經驗，可以慢慢步入自動化測試階段，如果自動化測試比較熟練，月薪1萬沒問題，和開發工資差不多。

（3）性能測試：性能測試人員現在稀缺人群，一般能做性能測試，且做得可以的一般月薪都在1.6萬以上，比開發要高。

軟體測試工程師對性別沒有特定要求，因此是一相對來說比較適合女性的IT職業。

軟體測試工作是對質量的把關，其中包含技術及管理等方面的工作，工作相對穩定，對年齡沒有限制，而且隨著經驗的積累，工齡越長越吃香。

軟體測試人員的主要職責是對軟體產品的整個開發過程進行監督和檢驗，使之能夠達到滿足客戶的需求，因此對於企業來講是十分重要的崗位。在國外，一般軟體測試人員與軟體開發人員的崗位設置比例是1：1，像微軟在開發windows2000時候使用的軟體開發人員是1700名，而專業的測試工程師有3200名，測試開發人員比例高到1.7：1，由此可見軟體測試崗位重要性的不一般。

計 算機領域的專業技能是測試工程師應該必備的一項素質，是做好測試工作的前提條件。儘管沒有任何IT背景的人也可以從事測試工作，但是一名要想獲得更大發展空間或者持久競爭力的測試工程師，則計算機專業技能是必不可少的。計算機專業技能主要包含三個方面：

⒈ 測試專業技能

測試專業知識很多，本書內容主要以測試人員應該掌握的基礎專業技能為主。測試專業技能涉及的範圍很廣：既包括黑盒測試、白盒測試、測試用例設計等基礎測試技術，也包括單元測試、功能測試、集成測試、系統測試、性能測試等測試方法，還包括基礎的測試流程管理、缺陷管理、自動化測試技術等知識。

⒉ 軟體編程技能

軟體編程技能實際應該是測試人員的必備技能之一，在微軟，很多測試人員都擁有多年的開發經驗。因此，測試人員要想得到較好的職業發展，必須能夠編寫程序。只有能夠編寫程序，才可以勝任諸如單元測試、集成測試、性能測試等難度較大的測試工作。

此外，對軟體測試人員的編程技能要求也有別於開發人員：測試人員編寫的程序應著眼於運行正確，同時兼顧高效率，尤其體現在與性能測試相關的測試代碼編寫上。因此測試人員要具備一定的演演算法設計能力。依據資深測試工程師的經驗，測試工程師至少應該掌握Java、C#、C++之類的一門語言以及相應的開發工具。

⒊ 網路、操作系統、資料庫、中間件等知識

與開發人員相比，測試人員掌握的知識具有“博而不精”的特點，“藝多不壓身”是個非常形象的比喻。由於測試中經常需要配置、調試各種測試環境，而且在性能測試中還要對各種系統平台進行分析與調優，因此測試人員需要掌握更多網路、操作系統、資料庫等知識。

在網路方面，測試人員應該掌握基本的網路協議以及網路工作原理，尤其要掌握一些網路環境的配置，這些都是測試工作中經常遇到的知識。

操作系統和中間件方面，應該掌握基本的使用以及安裝、配置等。例如很多應用系統都是基於Unix、linux來運行的，這就要求測試人員掌握基本的操作命令以及相關的工具軟體。而WebLogic、Websphere等中間件的安裝、配置很多時候也需要掌握一些。

資料庫知識則是更應該掌握技能，現在的應用系統幾乎離不開資料庫。因此不但要掌握基本的安裝、配置，還要掌握SQL。測試人員至少應該掌握Mysql、Sqlserver、Oracle等常見資料庫的使用。

行業主要指測試人員所在企業涉及的行業領域，例如很多IT企業從事石油、電信、銀行、電子政務、電子商務等行業領域的產品開發。行業知識即業務知識，是測試人員做好測試工作的又一個前提條件，只有深入地了解了產品的業務流程，才可以判斷出開發人員實現的產品功能是否正確。

很多時候，軟體運行起來沒有異常，但是功能不一定正確。只有掌握了相關的行業知識，才可以判斷出用戶的業務需求是否得到了實現。

行業知識與工作經驗有一定關係，通過時間即可以完成積累。

作為一名優秀的測試工程師，首先要對測試工作有興趣：測試工作很多時候都是顯得有些枯燥的，因此熱愛測試工作，才更容易做好測試工作。因此，除了具有前面的專業技能和行業知識外，測試人員應該具有一些基本的個人素養，即下面的“五心”。

1.專心：主要指測試人員在執行測試任務的時候要專心，不可一心二用。經驗表明，高度集中精神不但能夠提高效率，還能發現更多的軟體缺陷，業績最棒的往往是團隊中做事精力最集中的那些成員。

2.細心：主要指執行測試工作時候要細心，認真執行測試，不可以忽略一些細節。某些缺陷如果不細心很難發現，例如一些界面的樣式、文字等。

3.耐心：很多測試工作有時候顯得非常枯燥，需要很大的耐心才可以做好。如果比較浮躁，就不會做到“專心”和“細心”，這將讓很多軟體缺陷從你眼前逃過。

4.責任心：責任心是做好工作必備的素質之一，測試工程師更應該將其發揚光大。如果測試中沒有盡到責任，甚至敷衍了事，這將會把測試工作交給用戶來完成，很可能引起非常嚴重的後果。

5.自信心：自信心是現在多數測試工程師都缺少的一項素質，尤其在面對需要編寫測試代碼等工作的時候，往往認為自己做不到。要想獲得更好的職業發展，測試工程師們應該努力學習，建立能“解決一切測試問題”的信心。

“五心”只是做好測試工作的基本要求，測試人員應該具有的素質還很多。例如測試人員不但要具有團隊合作精神，而且應該學會寬容待人，學會去理解“開發人員”，同時要尊重開發人員的勞動成果——開發出來的產品。

1、質量意識：在整個軟體測試的各個環節中，質量意識一定要貫穿其中。理解功能需求，書寫測試案例，執行測試計劃，發現問題，提交問題，描述問題，協助解決問題，以及問題的跟蹤等，在所有的環節中，一定要注重質量，並且從質量的角度來思考問題。

2、細心並且系統：軟體測試可能每天要重複同樣的操作，其工作可能會枯燥無味，並且發現的問題可能很微小或者很雜亂無章、現象不一。在這樣的情況下，軟體測試人員一定要細心不放過任何微小的錯誤，並且從很多雜亂的現象中找出一定的規律和復現性。並且在測試中有很好的規劃性，先測什麼而後測什麼，不放過任何軟體的死角。在測試中，一定要系統的看待問題，功能模塊A的改動會否影響到其他模塊的功能，不能想當然，一定要系統性的看待。有時候一個內存地址的改變，都有可能引起准給軟體的崩潰。所以一定要系統性的去處理和看待軟體中修改的任意一處代碼。

3、軟體測試理論的掌握以及開發工具和平台的應用：黑盒測試，白盒測試，功能/系統/壓力/性能等等。但不管測試任何東西，基本理論是不變的。需求文檔，設計文檔，根據文檔製作測試用例（劃分等價、邊界測試、路徑測試、用戶體驗、等等），執行測試，提交並跟蹤問題。當然，行業的不同，其測試用的工具和方法也不太一樣。手機App該如何測試，無線通訊產品該如何測試，C/B-S應用該如何測試，這些產品的差異性很大，其用到的工作也很不一樣，但是其基本的測試理論還是一致的。

4、站的高看的細：不能光有理論，對測試的很多文檔可以提出很多有建設性的意見，但當執行測試時卻不能發現問題。這其中有幾個原因，一是可能提出的意見並沒有寫進測試案例中，二是有可能執行不仔細總是忽視問題的存在，三可能就是沒有去實施。所以一定要站在一定的高度去看待軟體測試，但是又要很細緻的實施。只有通過實踐，才能發現問題改進問題到最後解決問題。

5、團隊合作：這個無需多講，在這個產品日漸複雜的年代，很難有一己之力就可以在各個方面做的最好。要充分發揮團隊每個人員的工作能力和效率。

6、懷疑：有些書是這樣定義軟體測試的，軟體測試不會去證明軟體是正確的，而是去證明是錯誤的，但是我們不可能發現所有的錯誤。所以有很多時候要去懷疑要去假設。

（Software Engineering Skills)

軟體工程技能可以分成三大塊：理解軟體工程的規則，了解計算機編程和操作系統知識。

理解軟體工程“規則”。有一種過時的眼光認為軟體工程只是由一些在工作期限之前瘋狂編程、靠著非凡的協調能力和超人般的咖啡消耗整夜不睡，不停地設計和測試程序的“專家”們組成的。這種現象確實存在，但你只有了解了軟體開發的真正過程，才會是一個專業人員。

從哪開始呢？先到圖書館去走一走。你需要建立軟體測試知識的軟體工程基礎。我的建議是閱讀Roger Pressman的軟體工程：A Practitioner's Approach,fifth edition （職業入門，第五版，McGraw Hill,2000年版）和 Glenford Myers的The Art of Software Testing(軟體測試藝術，John Wiley & Sons,1979年版)。Pressman的書是一個對軟體工程原理的全面介紹。有很多關於軟體技巧、項目管理、要求分析和軟體設計等軟體工程方面的好書，但Pressman對這些方面在一本書里作了介紹。Glenford Myers不到二百頁，1979年發行，卻是軟體測試方面的聖經。Myers定義及詮釋的測試方法論已成為軟體測試的基本模塊。

Myers還考查了軟體測試中的經濟（缺陷的代價）和心理學方面（測試的目標就是發現失誤及不成功之處），以及主導軟體開發和測試的基本原則。

對參考書進行基本研究是一個好的開端，但這只是單方對話。如果你能和上千個直接具有軟體工程和測試經驗的人以及想進入這一領域的人對話是不是再好不過了呢？感謝那些網路電子部落，你已經可以做到了。Comp.software-eng覆蓋了設計、編程、項目管理等軟體工程的各個方面。Comp.software.testing涵蓋了軟體測試的自動化、培訓、技巧等方面。

等等，別只停留在這裡！你是不是應當經常訪問這些網址呢？Bug-Net(http://65.54.244.250/cgi-bin/linkrd...%2ebugnet%2ecom）是有關軟體缺陷的在線雜誌。閱讀有關缺陷的文章是學習如何工作及失敗的極好方式。你也應當查閱軟體測試及質量工程雜誌（http://65.54.244.250/cgi-bin/linkrd...ww%2estqe%2ecom）。STQE 是確定網路軟體測試資源很好的始發站。

計算機編程。不能想像有的人喜歡測試產品卻從不閱讀、檢查和理解組成產品的軟體一樣。

不要誤解我的意思。你不必花所有的時間去讀源代碼，但任何你做過的有關自己程序的設計、編寫和糾錯都能大大地有助於測試別人編寫的程序。

你怎樣學習編程？通過編程。可以嚴肅地說，開始學習寫計算機程序是最簡單的事。記住我說的是“開始學習”。軟體編程環境，例如 Microsoft Windows Foundation Classes (MFC) or Sun's Java Foundation Classes (JFC,also called "Swing")不斷變得越來越複雜，越來越難跟得上。

但我在努力超越自己。你應當怎樣學習編程呢？

首先，買Microsoft Visual Basic。不要讓名字騙了你。你能用這套組件建立相當複雜的程序。而且它只要一百元左右。下一步呢？等等，是visual編程警告的時候了！

現在你為你的PC買一個程序語言的時候，你其實是買了一個集成開發系統或稱為IDE。這些IDE通過對編程的簡化把開發過程流水線化。這些IDE其實會幫你寫很多編碼。這非常有利於儘早開發出一個產品，卻不利於你學習編程。如果你用Windows產生程序，你別無選擇，因為環境介入太多使你無法從頭編程。如果你從Unix系統產生程序，你能自己寫所有的編碼。

一旦你習慣了與參量、控制結構、對象、輸入輸出及更重要的Visual Basic糾錯打交道的時候，你就可以開始學習C語言了。學習C能使你熟悉十六進位系統，通過指針分配和參考內存，存取個體位碼及建立程序模塊。

我總是認為在學Java之前最好先學會C，因為C強迫你自己去完成許多任務而Java會自動處理（例如，釋放未用的空間）。用C工作比Java難，但你能學到編程更多的基本方面。你其實能用Visual C++IDE從頭寫C程序，但最好還是在Unix系統中學C。

操作系統知識。你已經把它交給了在Redmond,Washington的那些人了。在短短的幾年內，Windows NT已經成為世界上大部分計算機的標準操作系統。如果你要用NT工作，你需要了解它的寄存地址。（它是一種用於存儲你的系統結構的各個方面的資料庫。）我發現Peter Norton寫的InsideWindows NT 4.0(SAMS,1998）是一本很好的介紹書。但是，如果你的應用或系統要求高的保密度、產出、可靠性及靈活性，Unix依然是最好的選擇。

如果你想成為一個成功的軟體工程師，你必須能在Unix的世界里工作，如果你想從頭學習編程，也要在Unix下進行。

你的選擇是什麼？你可以到當地的學校或大學學習課程，或者在家建立一個Unix系統。別昏過去了，你所需要的只是一台PC和一份能讓你從網路免費下載的Linux拷貝。（你大約花二十九元能買一份在一個CD-ROM中帶了所有文件的拷貝。）Linux不是Unix的“玩具”版，它是真實的。它已經發行了七百萬份拷貝，一些主要的PC生產商甚至先替你裝載了它。

好了，你已經到了Unix或Linux系統了。你應當學些什麼？文件和目錄結構，標準輸入輸出和錯誤流，背景（background，也稱為"daemon")處理，從C調用系統功能，好，我可以接下去了。一個好的開端是讀Arnold Robbins的Unix in a Nutshell (O'Reilly & Associates,1999）或者是Ellen Siever的Linux in a Nutshell (O'Reilly & Associates,1999）。

（Communications Skills)

能寫出計算機程序卻寫不出一個完整句子的軟體工程師現在還有。但不幸的是，要成為一個成功的軟體測試工程師，你需要清楚的交流。

你怎麼去學習寫？通過寫。如果文字水平太粗糙，上一門創造性寫作的課。每天寫工程流水記錄或發email。關鍵是學習（或重新學習）怎樣用清晰可懂的語言表達你的思想。一個好的寫作參謀是William Strunk Jr.和E.B. White寫的The Elements of Style(Allyn & Bacon,2000），它一點也不象初中教科書。

測試工程師必須把產品測試的技術寫成文件。測試計劃提供指導並把測試設計轉化為設置、實現測試和評估結果的步驟指導。具有一般軟體和產品特性不同層次經驗的工程師都能使用這樣一個詳細的測試計劃。如此測試設計者或測試方案作者之外的工程師也能能進行測試。

測試計劃也幫著佐證測試策略的正確性。項目中的每個人都應當參與審查（即市場、開發、支持、技術寫作及測試人）。計劃的審查是必不可少的，因為儘管測試工程師盡最大努力來達成一個對產品的全面定義，這一測試設計者所基於的定義不一定是完整或準確的。此外，就象開發者很難測試他們自己的編碼一樣，測試工程師也很難明確評估他們自己的測試計劃。每一個計劃審查者都可能根據其經驗及專長建議修改，有時候審查者還能提供測試工程師在組織產品定義時不具備的信息。例如，一個市場人員可能了解到了新的客戶要求，一個軟體支持專家可能從有關的產品領域了解到了一個新的缺陷報告。

測試計劃強調測試計劃和執行的原則。在測試計劃中描述進行測試所需的測試設計和步驟是另一層關於測試設計和計劃的原則。在測試設計和計劃中的錯誤與欠缺在設計轉化成測試計劃中特定的結構和測試步驟后就經常是再已無法彌補。

測試計劃可作為其它項目，例如為不同的產品準備測試時的參考資料。當被測試軟體找到缺陷解決並證實后，測試計劃所述的測試可以用於證實缺陷的解決方案。同時，一個主要的測試設計信息來源，特別對於舊產品的新版本而言，是相關產品或前版本的測試計劃。在建立新版本時，舊版本的軟體測試計劃都應當被重新審查。

與功能與設計說明不同，測試計劃將從測試的角度來描述產品的功能操作。從這方面說，測試計劃構成了公司公共檔案的一部分。隨著時間的流逝人們會離開公司，帶走他們的知識。以前產品的測試計劃就能幫助你定義新產品的測試。

軟體測試工程師還要寫測試結果報告。測試結果必須寫成文檔，這樣就能確定被測軟體的狀態，提供關於必須要解決的缺陷的記錄。產品測試中發現的所有缺陷的記錄是測試部門最顯眼、保存時間最長的文檔。測試計劃和測試報告在項目的最後常被遺忘，但現存缺陷的清單（或資料庫）代表項目未完成的議程。這一議程沒完成是因為一些缺陷必須在對原來產品的一個patch或maintenance release的時候糾正，或者它們在這個產品作為後續產品的基礎之前被修復。

在與軟體產品打交道的過程中，測試工程師比其他部門的人參與項目的更多方面。測試部門應當記錄項目過程中重大事件（例如設計決定）的信息。這個信息應能幫助測試部門和其他部門避免在後續項目中犯同樣的錯誤。錯誤是不可避免，在一個項目中可能出問題。從這些經驗中學習就可能避免問題，避免今後的同樣錯誤。從錯誤中學習的第一步就是記住它們，記憶的第一步就是把它們寫下來。

（Organizational Skills)

每當執行一個軟體項目的測試計劃，幾乎不可能不遇到至少會阻礙一些測試而必須解決的缺陷。一個測試工程師應當能靈活地停止測試產品的一部分而開始測試其他部分。有時被測軟體需要做根本變動引起大量的測試結果失效，測試也許得重做不止一次。在問題被查找和改變在進行的過程中，測試工程師必須有條理，保持對執行測試的軟體的前後關係的明確感受（例如目前被測試的程序特定版本的不同部分）。

網路時代要求的動態開發和測試模式使組織性的工作方式對測試工程師越來越重要。在整個開發過程中被測試軟體可能會不斷地改進。測試工程師在計劃和實施測試的時候必須考慮這些變化因素，必須控制測試環境來保證測試結果的有效性。

記住計劃是一個動詞。作為一個軟體工程師，你永遠不會有你想要的所有時間和資源。你總是必須通過理解技術和產品，開發組織方式，從你和其他人的錯誤中學習，以及在設計必須改變和出問題的時候的迅速調整，使你的測試效果和效率最大化。如何能做到這點呢？基本代數：量化任務、目標和結果來減少方程中的變數數。把產品的功能定義成要求。在測試計劃和測試中量化測試及其預期的和實際的結果，把信息提供給項目組。你東點一下西點一下是不能完成整個測試的。未來軟體開發的組織模式要求有靈活的設計和不斷進化的開發周期。對產品測試必須隨著產品的進化而進化。

（Hands-On Experience)這是個典型的兩難問題。你需要軟體測試經驗來找工作，你沒工作你就沒經驗。你該怎麼辦？

Be careful! 這需要勇氣和你的PC的小心備份。

作為自願者參與beta測試。怎樣發現需要beta測試員的公司呢？首先，給你在軟體公司工作的親友打電話。偶爾有人會需要beta的測試人員。如果這不行，到你最喜歡的網路搜索引擎上去找“beta test”。你會發現很多小（和不那麼小的）公司亟需beta測試員。為什麼？這得感謝網際網路，競爭的加劇使公司必須做出產品模型貼到他們的網址上作為“beta”版推出。這些公司希望人們不僅測試他們的產品，而且對這些免費品感興趣進而購買他們的產品。

（Attitude）

“我希望你幸福的夢想，被你打破了！”

我打賭這句話能勾起一些人童年記憶的創傷。我不是心理學家，但我還敢說這種說法是因為我們渴望看到成功。在軟體測試中，你不僅要證實軟體在做它該做的，還要證實它不會做它不該做的。為了做到這一點，你得找出軟體的失敗之處。

進行軟體測試需要很多人的眼光要進行一百八十度的轉變，因為測試的目標是要讓被測軟體失敗，由此產生出等同於其他東西工作正確時的成功。在軟體測試中，一個成功的測試揭示一個缺陷。進行軟體測試也是因為網際網路的來臨要求人們用一種大不同以往的眼光來看待動態的開發和測試模型。

軟體測試工程師除了技術，還要求具有否定性的創造力；探測技巧；總體理解產品的能力；用客戶的眼光進行評估；懷疑的而不是敵意的態度；能經受得住壞消息而保持目標；擁抱新技術的熱望等特徵。

否定性的創造力

一個軟體工程師不能怕引起一個產品的癱瘓或燒毀。在軟體測試中，邊界意味著被超越而不是被遵從。如果一個程序對某個值的極限為10（例如，可以在一時間被打開的最大文件數），測試工程師的第一想法應當是“如果我把那個值取11，或0，或10.1，甚至不設這個值會如何？”

在我的早期的工作生涯中，有一次我測試一個開發和QA工程師遺漏下來的PC資料庫。有問題的資料庫是2.01版。這本身就說明產品有問題。2.0版沒解決1.0版的所有缺陷嗎？或者2.0版又加入了新的缺陷？很遺憾因為時間緊我沒有調查這些，只是證實了最後的缺陷修復后就告捷了。

這是很大的錯誤。我應當重測開發人員所謂“沒有變化”的所有產品功能。2.0版本中的缺陷確實復修了，但在修復的過程中，有人破壞了請求。事實就是如此，在資料庫里不能搜索數據了，第一個收到這項產品的beta客戶發現了這個缺陷。

我宣布以前的測試無效，要求對產品進行全面測試。找到幾個缺陷之後，我發現這個資料庫讀取防寫文件或防寫了的磁碟的時候就會引起癱瘓。開發人員很吃驚我會試著防寫一個資料庫。他們的反應就是：“沒人會這麼乾的！”產品的市場經理很快用他們的方式承認了錯誤。

探測技巧

在一個理想的世界中，軟體測試應當在一個經常更新的寫得很清楚的功能與設計說明文件（一般被稱為“specifications”）中被完整而精確地描述。不幸的是，這一完善被開發程序每一方面文件的任務，包括記錄在開發中對程序不可避免的改變，要花很多的時間和精力以至於人們無法完成編程。而且花費也太大。

正式與非正式的信息源

正式系統

要求文件

功能說明書

設計說明書

非正式系統

用戶文件

與其他開發人員的交流

與軟體支持人員的交流

有關產品的文件

有關產品的缺陷

從工作於相關或早期版本產品獲得的“局部知識”

因為我們不是在理想世界里編程，測試工程師應當能夠自己找出工作的方式。典型的是，總會有一些設計和功能說明書讓測試工程師用於開始他的研究。這些文件能看成為描述被測試軟體的“正式”系統。測試工程師應當能用更廣大的“非正式”系統的信息來擴展“正式”系統的信息。同時，在項目周期的任何一個點，任何文件都可能是正確或不正確的，所以測試工程師必須根據對軟體工作模式的觀察，與開發人員和其他項目人員的交談，或對有關或看上去不那麼相關文件的審核，來確定文件的精確性。

總體理解產品

在一個程序項目是，軟體開發工程師主要把他們的精力和注意力集於自己的項目部分。結果當這些項目部分組合在一起進行測試的時候，就會碰到兼容性的問題。到產品寄給一個客戶之前，唯一能見到整個產品的就是測試工程師。因此測試工程師必須能夠對整個產品的操作與使用保持一種“系統”的眼光。

測試工程師對產品的任何一部分的操作可能不是最好的專家，但他必須是產品整體操作的專家。例如，如果被測的產品是一個類似於Microsoft Office的由文字處理、擴展頁和其他有關程序組成的辦公室自動組件，測試工程師必須了解每個程序的操作，各個程序之間的相互作用和客戶其他的軟體硬體和軟體環境。

測試工程師必須是客戶的擁護者。被測程序有可能運行可靠滿足所有的設計要求，但在客戶的軟體環境中未必能夠用。產品被送到客戶之前的測試之一就是要證實產品達到了客戶的要求與期望。在這項測試中，測試工程師必須模擬用戶的軟體環境，把自己放到他們的位置上。

關於軟體功能“正確”而不能滿足客戶需要的一個悲劇性的例子就是美國航空公司965航班1995年在哥倫比亞卡利市的一次失事。在飛行著陸時，空中信號控制系統指示機組人員朝一個叫“Rozo”的航空信號燈飛。這個信號燈在航空圖中標為R。機組人員把R輸入到飛行管理計算機中，看到了明顯是由近到遠列出的六個航空信號燈。機組人員選了第一個信號燈，以為這就是Rozo。但那不是。自動駕駛儀把飛機向左轉了九十度，撞到了山上。

什麼地方出錯了呢？當航空表裡把Rozo列為R的時候，飛行管理計算機要求機組人員輸入信號燈的全名調出它的方位。同時，計算機只顯示了信號燈的編碼字母和方位。計算機功能“正確”，但不滿足用戶的需求。

項目剛開始時的要求與最終項目完成時的要求一致的情況是極少見的。有時技術變化了，產品必須改變以適應於技術。有時競爭對手的產品具有你的產品所沒有的功能。很多情況下，客戶的或潛在客戶的要求需要變化。這些因素合在一起的一個例子就是目前Microsoft Internet Explorer和Netscape的競爭。

隨著計算機首次用戶的迅速增加，今天的測試工程師比以往更需要把自己置於客戶的位置上。這些新的非技術用戶不願意接受缺陷，對缺陷的解釋或理性思考，或通過“升級”修正缺陷。他們只希望他們所買產品的軟體和硬體都是能工作的。

測試工程師不能按表面值接受事物，必須執著地對一切提出疑問直到被證實。工程師必須用一種與項目的其他的人合作精神來平衡這種懷疑性與執著性。測試部門與其有關部門的關係可能會變得緊張，特別是在大量缺陷被發現后，或者在每個找出的缺陷會潛在地延遲產品的發貨時間而延遲了項目時。測試工程師應當記住要攻擊程序的整體性，而不是程序員。

一個測試工程師必須忠實地彙報產品中的缺陷。這一信息應當被項目組歡迎，因為每一個測試工程師遇到的問題（除非加入新的問題）都意味著減少客戶會面臨的問題。但不幸的是很多人不想聽到有問，特別是在程序項目的後期。

測試工程師應當能處理因為工作做得太好而引起責備的情況。這對有些人來說是很難做到的，會嚴重地影響鬥志與自尊。

看起來常常是測試工程師阻撓了向客戶交貨。客觀的項目經理才能感覺到測試工程師是在對項目提供有價值的服務。我清楚地記得一個項目經理舉起他的手求我他要的是：“解決方案，不是問題！”（他不明白解決方案的實現有時要求一個問題的解決。）有時項目經理在項目計劃不方便的時候對於因為發現缺陷而打折是有壓力的。在這些情況下，測試工程師應當能基於他對產品的經驗和知識進行辯護，但他不應表現為象是他個人受到了威脅。

如何避免這些情形呢？就測試的內容、時間及如何更新測試結果和缺陷信息，設定其他項目組成員的期望。我曾經為一個希望延遲產品發送日期的QA經理工作過。他的目的不是為了產品成功，而是政治權力的操縱。他確信自己能被提升，把一些為他工作的工程師指定為“manager”，開始自稱為“director”，還要大樓管理人員把他的辦公隔間加寬一英尺。（這沒有實現，但至少他的座位有了更多伸腳的餘地。）

對多數人來說，年齡越大越難學習。在商業世界里，人員越往公司的食物鏈高處走，越遠離他們所建立的技術基礎。這一部分是因為他們需要把精力集中於其他的經營和指導其下屬的任務中。有時也是因為他們不幸地認為自己已不需要進行實踐的技術工作了。網際網路增加了技術變化的速度。不繼續學習或跟著發展就無法做出商務與技術的決斷。

從前的一個經理給我樹立了如何對待新技術的榜樣。我跟他工作的時候他年近六十，但他象新手一樣地熱心於學習新技術。他大量地獲取信息，不斷補充在網路伺服器、防火牆、和Perl或Expect等新語言的知識。他還重視做QA或測試組織的工作。他的最初背景是軟體開發和開發管理，但他並不認為做QA經理是在降低他的聲望。他明白一個獨立的測試或QA組所進行的完整測試能使開發經理的工作變得多簡化。

正象我所說的，當你生活於網路時代，只要原地不動就很容易落伍了。

相對於其他軟體工程人員，軟體測試工程師的知識面應該非常寬廣，但最重要的品質應該是能夠在第一時間內接受新技術。

由於公司之間的競爭日益集中在質量方面，所以公司對軟體測試人員的需求量也越來越大，這一點，在北美尤為明顯，這決定了軟體測試行業的前景可喜，同時也為願意不斷進取、學習新技術的華人移民提供了廣闊的就業空間，軟體測試工程師的就業機會一直都是非常多的，最關鍵，要善於抓住機遇並肯付出努力，踏踏實實的學起來、做起來。

搭建 Windows測試環境

主要講解搭建 Windows 測試環境所要具備的軟、硬體及網路知識。包括計算機中各種硬體和介面。軟體的分類、分發和授權等方式；操作系統的初步知識；註冊表、病毒、安全等知識； TCP/IP 協議和 DNS 、活動目錄等知識。從而讓學員可以在實際工作環境當中搭建一個基於 Windows活動目錄的區域網環境。

使用 C 語言開發簡單應用

設置本課程的目的主要是使學員掌握軟體開發的技術，掌握編程的方法、思想，了解軟體開發過程當中常犯的錯誤，為後面的測試課程以及編寫測試腳本打下語言基礎。課程中主要包括 C 語言的語法、程序基本結構、函數、指針、數組、數據結構、演演算法等程序設計所涉及到的知識。課程注重實用性、重在培養學員對代碼分析的能力，掌握編碼規範，掌握調試知識和分析程序錯誤的能力。同時學習內存檢查工具和軟體配置管理等知識。該課程中貫穿了一個開發“軟體測試工程師管理系統”的項目，增加學員開發項目的經驗。

測試計劃與軟體缺陷

本課程是軟體測試重點課程。本課程主要介紹軟體測試的基本概念和基礎知識、如何編寫測試計劃、識別軟體缺陷、編寫缺陷報告等。通過學習，學員可以掌握軟體測試的流程、軟體測試的策略和分類，掌握缺陷的分類和優先順序等，從而對測試有一個整體的認識。本課程中介紹了 Bugzilla 缺陷跟蹤管理系統（測試工具）。總體來說，本課程將使學員掌握大部分軟體測試相關的基礎知識。

高效設計測試用例

本課程是軟體測試重點課程。本課程主要通過引入的大量案例講解如何編寫測試用例。講解設計測試用例的技術包括等價類劃分、邊界值分析、因果圖方法、狀態圖方法、測試大綱等的方法以及正交排列表、測試矩陣等。測試特性包括：功能、性能、兼容性、易用性等。測試對象包括軟體功能、 GUI 界面、文檔測試、安裝和卸載測試等。通過本課程，主要是培養學員設計測試用例的視角，在最短的時間內針對功能寫出恰當的測試用例。本課程和《測試計劃與軟體缺陷》課程中貫穿了對“軟體測試工程師管理系統”編寫測試計劃、測試設計和開發，實施測試及測試評估的項目，增加學員軟體測試相關經驗。

白盒測試

本課程主要講解白盒測試技術。主要內容包括邏輯驅動覆蓋和基本路徑覆蓋兩個方面，在邏輯驅動覆蓋中主要介紹了語句覆蓋、判定覆蓋、條件覆蓋、判定 / 條件覆蓋、條件組合覆蓋、路徑覆蓋和循環語句覆蓋；在基本路徑覆蓋中介紹了繪製控制流圖及程序複雜性相關概念，最後重點介紹了單元測試技術。通過學習，學員可以了解白盒測試的理論，組織方式，已經如何評估一個白盒測試的效果。本課程中介紹了Logiscope和 C++ Test 兩個白盒測試工具。

Linux 與網路應用環境

本課程主要講解搭建 Linux測試環境所應具備的知識。通過學習 Linux 的安裝和配置、 Linux 常用命令、 Linux 下軟體安裝、卸載和使用、常見的 Linux 的服務（Apache 、 Mysql 、 Squid 、 Iptables 等）、 Linux軟體開發環境等，讓學員能夠使用 Linux 實現一個提供常見服務的網路環境。本課程中在前期通過在 Linux 當中搭建 Bugzilla 缺陷跟蹤管理系統來講解 Linux 的使用和配置。

WEB 技術與資料庫

本課程通過對資料庫、 HTML 、 XML 、 HTTP 、 J2EE 、 .NET 等基礎知識的講解，讓學員掌握這些技術，以便於建立分散式軟體的測試環境。資料庫是以 SQL Server 作為重點講解，同時也介紹了 Oracle 和 MySQL 資料庫。

高效使用自動測試工具

本課程主要介紹了國際測試工具佔有率最高的 MI 的三大測試工具：功能測試工具 QuickTest Professional 、性能測試工具 LoadRunner 、測試管理工具TestDirector。學員掌握這些流行的測試工具，從而進一步提高測試的效率。

軟體測試實訓

本課程是最後一門課程，該課程主要是通過運用前面所學習的課程，指導學員完成一個項目的測試過程，從而鞏固所學知識。在該課程中將完成分組分工、編寫測試計劃、寫工作日誌和開例會、設計測試用例、執行測試、填寫和處理缺陷報告的過程。使用的項目通過三個版本來進行回歸測試，通過分工與合作來完成測試工作，通過講師和學員分別模擬測試組成員角色，鍛煉學員實踐的能力。該項目是一個百萬行代碼級別的類 Office 系統。

職業導向訓練

職業導向訓練，簡稱COT課程，即Career oriented Training，是對學員進行職業引導，包括就業指導和職前引導。通過就業指導以及就業專員、就業明星與學員的座談會等日常輔助訓練明確就業方向，進一步了解就業形式。詳細介紹如何寫簡歷，通過強化面試訓練，以及模擬面試等方式，提升學員應對面試的能力，從而加強學員就業競爭力。

華為軟體測試工程師學習大綱

一、軟體測試的原理

v 軟體工程：軟體的含義、軟體開發過程的特性、軟體生命周期模型、軟體管理過程軟體質量和質量保證：軟體質量就是客戶的滿意度、質量的概念、軟體質量的內涵、質量管理體系、SQA、SCM、SEPG

v軟體測試概念：軟體危機、軟體測試產生的背景，軟體缺陷是什麼、軟體測試職業發展，軟體測試人員應具備的素質和技能、軟體測試基本概念、軟體測試的目的、軟體測試的重要性、軟體測試的原則、軟體開發與軟體測試

v軟體測試依據和規範：軟體質量標準、軟體測試規範、界面規範、編碼規範、CMM和ISO9001思想結構體系、CMM VS ISO

二、軟體測試的技術

v軟體測試技術概述：軟體測試的基該方法，黑盒測試、白盒測試、靜態測試、動態測試、測試策略

v軟體測試流程：軟體測試流程、通用測試文檔模板、軟體測試的分類、軟體包的質量特性

v 單元測試和集成測試：什麼是單元測試、單元測試的目標和任務、單元測試方法、調試與評估、什麼是集成測試、集成測試目標和任務、集成測試的模式與方法

v 系統測試和驗收測試：什麼是系統測試，系統測試的目標和任務，系統測試方法，系統測試中工具的應用、什麼是驗收測試、驗收測試的目標、驗收測試的過程和主要內容、產品規格說明書的驗證

v 特定類型的軟體測試：面向對象軟體的測試、面向對象軟體的特點、面向對象測試的層次與數據流、面向對象的單元測試、面向對象的集成測試、基於應用伺服器的測試、應用伺服器的分類和特徵、基於Web伺服器應用的測試、基於資料庫應用伺服器的測試、基於J2EE平台的測試、軟體本地化測試：什麼是軟體本地化、軟體本地化的翻譯問題、軟體本地化測試的技術問題、本地化測試的重點

三、軟體測試的實踐

v測試環境的部署：測試環境的重要性、測試環境的各要素、建立測試實驗室、測試環境的維護和管理

v軟體測試用例的設計：測試用例來源、測試需求提取、測試用例設計、白盒測試用例設計方法、邏輯覆蓋法/基本路徑測試法、黑盒測試用例設計方法、等價類劃分法/邊界值分析法/因果圖法/錯誤推測法 /功能圖法、測試用例的組織和跟蹤、使用實際項目實踐

v 報告所發現的軟體缺陷：軟體缺陷的描述、軟體缺陷相關的信息、軟體缺陷的處理和跟蹤

v軟體測試和質量分析報告：軟體產品的質量度量、評估系統測試的覆蓋程度、軟體缺陷分析方法、基於缺陷分析的產品質量評估、軟體質量的可靠性評估、軟體可靠性模型、可靠性評估過程

v軟體測試自動化：測試自動化的內涵、測試工具的分類和選擇、測試工具的主流產品介紹、IBM-Rational產品的整體解決方案、Mercury Interactive產品的整體解決方案，測試管理工具TD實操演示及指導、功能測試工具Robot實操演示及指導、腳本語言perl實操演示及指導、性能測試工具LR

v 網路基礎知識：協議概念、常見的網路協議及層次、TCP/IP協議、Arp協議等報文分析、常見的網元設備及工作原理、常用的網路操作相關命令、客戶機伺服器模型、抓包工具使用

v 資料庫簡介及SQL語句：資料庫系統概念、數據管理的發展階段、資料庫系統的特點、SQL概述、SQL數據定義功能、SQL數據查詢功能、SQL數據修改功能、嵌入式SQL

v Linux操作系統簡介及常用命令：Linux系統介紹、Linux系統歷史及發展、Linux系統特點、Linux系統安裝與配置、Linux系統命令的使用方式、文件及目錄操作命令、文件壓縮命令、聯機幫助命令、進程管理的命令

四、軟體測試管理

v 組織和管理測試團隊：基於ISO的測試管理體系構成、測試團隊的地位和責任、測試團隊的構成、測試團隊的管理和發展

v軟體測試項目管理：軟體測試項目管理的概述、軟體測試項目的組織、軟體測試項目的過程管理、軟體測試項目的資源管理、測試項目的進度管理、測試項目的風險管理、測試項目的質量和配置管理、軟體測試文檔的管理

v 理解CMM：KPA簡介、CMM的五個等級及關鍵過程域、CMM實例簡介、CMM的發展、CMMI2級詳細講解

五、軟體測試人員面臨的機會和挑戰

v軟體測試職位在IT行業的現狀

v軟體測試職位到底是幹什麼？

v軟體測試行業的背景

v軟體測試人員需要具備的基本素質

v軟體測試工程師需掌握的技術技能大綱

v軟體測試人員後期的發展機會和挑戰

附錄（基礎技能版，本內容為華為公司指定培訓內容）：

一、基礎技能方面：

Unix/Linux操作系統：

⒈熟悉UNⅨ環境

⒉掌握UNⅨ常用命令

⒊了解並掌握Vi的一些常用命令

⒋了解基本的shell

Informix：

⒈熟悉並掌握informix常用命令

⒉掌握SQL相關的一些知識

Oracle：

⒈掌握Oracle的基本操作

⒉掌握在unix/Linux系統下安裝Oracle資料庫

二、網路基礎知識

⒈熟悉TCP/IP、HTTP、UDP協議

⒉掌握常用的網路命令

⒊抓包工具的熟悉與學習

三、測試理論

⒈軟體及其開發過程

⒉軟體測試的基本概念與方法

⒊質量保證與策略

⒋測試依據與規範

⒌單元測試

⒍集成測試與系統測試

⒎驗收測試

⒏基於應用伺服器的測試

⒐測試計劃的制定、用例的設計與執行、缺陷的跟蹤

四、模擬項目練習

⒈理解需求，設計測試用例、測試用例評審

⒉測試執行

⒊提單規範

有關模擬項目的需求、用例模板、測試版本。