軟件測試大全11篇

緒論：寫作既是個人情感的抒發，也是對學術真理的探索，歡迎閱讀由發表云整理的11篇軟件測試范文，希望它們能為您的寫作提供參考和啟發。

篇（1）

1.組件測試

組件測試又稱單元測試，其目的就是驗證應用程序能夠很好的工作，以及盡早的發現錯誤。所謂組件測試其實就是測試單個組件的過程，是一種細粒度的測試。組件測試其實就是一個缺陷測試的過程，基本上使用結構化測試即白盒測試來對組件進行測試。在軟件中，組件算是最小的單元，因此，組件測試可以對多個組件來進行。

1.1組件測試的類型

在組件測試階段，需要測試不同類型的組件（對象內的單個函數或方法、有多個屬性和方法的對象類、有不同對象或是函數組成的復合組件）。組件測試的內容主要有模塊接口、局部數據結構測試、路徑測試、錯誤處理測試以及邊界測試。從測試的類型可以看出，比較簡單的就是對單個函數或方法的測試，但是當測試多個組件組成的復合組件時，測試組件間的接口是否能正確執行是首要關心的問題，而這個測試中的關鍵就是對組合組件的接口測試。

1.2接口測試

接口測試是組件測試中最常用的一種測試。測試符合組件間的接口就是接口測試。由于在符合組件之間存在很多交互行為，因此，在對復合組件中的單個組件進行訪問時，是要通過接口來對它們進行調用。所以，接口測試就成為組件測試中的重點。

復雜系統中最常見的錯誤形式包括接口錯誤，接口錯誤主要指接口誤用、計時錯誤、接口誤解等等。一般情況在不尋常的條件下、交互雙方都存在接口缺陷，而這是很難發現的，因此，接口測試是非常重要的。

組件的開發和測試都是交叉進行的，組件的設計者對組件是十分熟悉的，因此，由組件的設計者來進行組件測試是在合適不過了。

2.集成測試

所謂集成測試就是指測試時將組件集成為系統來進行。集成測試的目的就是檢查在一起的組件是否工作，能否正確及時進行組件與組件間的交互。集成測試就是將與接口相關的錯誤找出，從而使得添加的功能模塊確保沒有傳播不期望的副作用，并且使得由于新模塊的添加引起的變更不引入需求外的行為或是增加額外的錯誤。集成測試過程如圖1所示。

圖1 集成測試過程

2.1集成系統的策略

集成順序不同，集成測試也將不同，二者密切相關。集成系統的策略從理論上來講，其可分為自上而下的集成和自底而上的集成。但是在實際中，大多數的集成策略都是混合型的。自上而下的集成就是指先把系統框架開發出來，然后再向其中添加組件。這種方法存在一個非常普遍的問題，即在測試下一層時，還要兼測上一層。自底而上的集成就是指集成和測試都是從組件開始。不管使用哪種策略，開發額外的代碼是必須的，通過額外代碼的開發來仿真其他組件，從而使得系統運行起來。

對錯誤的定位就是集成測試中存在的主要問題。由于組件之間有復雜的交互行為存在，因此，當發現一個錯誤時，很難將其出錯的位置找到。

2.2集成測試的方法

集成測試通常采用增量法來進行測試，從而使得集成測試中的主要問題得以解決。使用增量法，從一個集成度最小的系統配置開始，然后測試這個系統，測試完成后，一個增量一個增量地往系統中增加組件，每次增加組件后再進行測試。這種方法其優點在于易于分離和糾正錯誤以及徹底測試接口。這種方法的缺點在于在測試過程中經常會出現重復測試。

2.3回歸測試

回歸測試就是指把測試過的再進行測試?；貧w測試雖然出現重復測試，但是其能夠保證新增模塊后不會給原系統組件間的行為產生不期望的變更。回歸測試是保證軟件的正確運行的必要條件，但是，對測試過的再進行重新測試明顯會產生不必要的浪費。

要想在使用回歸測試時減少系統資源的浪費，可以從以下幾個方面進行：（1）引進自動化測試。這種方法的引入，使得測試自動地重復，從而回歸測試對系統資源的浪費得以減少；（2）嚴格規定增加快增加順序。先增加最常用的功能塊，從而對最常用的組件進行多次測試，確保在各種情況下常用功能能夠實現。

集成測試的必要性還在于一些模塊雖然能夠單獨地工作，但并不能保證連接起來也能正常工作。程序在某些局部反映不出來的問題，有可能在全局上會暴露出來，影響功能的實現。此外，在某些開發模式中，集成測試的意義還在于它能間接地驗證概要設計是否具有可行性。

3.性能測試

性能測試就是測試系統對在非正常條件下的運行情況。它的任務是驗證軟件的功能和性能及其他特性是否達到了需求規格書上的要求。一般情況下包括恢復測試、安全測試、壓力測試、性能測試?；謴蜏y試是通過各種方式強制地讓系統發現故障并驗證其能夠重新恢復的一種系統測試。安全測試是驗證在系統內的保護機制是否能夠實際保護系統不受非法入侵。壓力測試是以一種要求反常數量、頻率或容量的方式執行系統的測試方法。

4.接收測試

接收測試是對將要分給客戶的系統版本的測試過程。通常是一個黑盒測試過程，將軟件與計算機的其他系統元素結合在一起，在實際運行環境下，由用戶通過真實的數據測試對軟件在內的計算機系統，以求能發現系統需求定義中的錯誤和遺漏。同時也期望能發現因系統的設施不能滿足用戶的需求或系統的性能無法接受的錯誤。

4.1接收測試的方法

接收測試的最好測試方法是基于腳本的測試，先設計出多個腳本然后再從腳本中開發錯測試用例。

4.2接收測試的分類

接收測試根據用戶的不同可以分為α測試和β測試。無論是α測試還是β測試都是在實際的使用環境下進行的。α測試是測試為特定的用戶開發的系統，且由最終用戶在開發者在場的情況下進行的，開發者在旁邊記錄用戶所遇到的錯誤和使用問題，α測試要持續進行直到開發者和用戶雙方都對最后交付的系統滿意。β測試的對象是一個將要在市場上銷售的軟件產品，β測試是所有愿意使用該軟件的用戶在使用該軟件是所遇到的所有問題，然后在反饋給開發者，開發者再根據反饋回來的信息決定對軟件做如何處理。通常情況下β測試能暴露開發者無法預見得錯誤。

隨著軟件應用越來越廣，所要求的設計也越來越復雜，所需的開發周期越來越短，而質量要求越來越高，那么軟件企業目前面臨著巨大的挑戰。由此，軟件測試變得越來越重要，軟件測試可以有效地提高軟件質量。重視軟件測試過程和技術是軟件企業快速發展的有效途徑。

篇（2）

居住地：上海

電　話：153********（手機）

E-mail：

最近工作 [ 1年7個月 ]

公　司：XX計算機軟件有限公司

行　業：計算機服務(系統、數據服務、維修)

職　位：軟件測試

最高學歷

學　歷：本科

?！I：軟件測試

學　校：西北大學

自我評價

本人熟悉軟件開發測試流程，豐富的自動化測試經驗，善于學習。能在成功與失敗中完善自己，活潑開朗，樂觀向上，適應力強，勤奮好學，認真負責。待人誠懇，做事踏實細心，對工作有熱情有責任心。

求職意向

到崗時間： 一周之內

工作性質： 全職

希望行業： 計算機軟件

目標地點： 上海

期望月薪： 面議/月

目標職能： 軟件測試

工作經驗

2012 /12—至今：XX計算機軟件有限公司[ 1年7個月]

所屬行業：計算機服務(系統、數據服務、維修)

測試部 軟件測試

1.負責需求分析，制定測試計劃，編寫測試計劃和測試案例；

2.負責測試環境的搭建；

3.負責使用JIRA 缺陷管理系統, 管理跟蹤BUG；

4.負責系統的功能測試，以及處理客戶的回饋，重現問題；

5.負責熟練使用LINUX腳本語言，實現測試環境的自動安裝和定時運行，并進行日志的查看及排錯等；

6.負責根據用戶需求，編寫用戶使用說明手冊；

7.負責系統的安裝及配置,負責客戶版本升級。

2011 /1—2011 /12：XX軟件科技有限公司[ 11個月]

所屬行業：計算機軟件

事業部 軟件測試

1、負責根據軟件開發年度進程表，與美國微軟測試及開發團隊溝通，確定各階段測試目標；

2、負責在項目測試過程中，制定測試計劃，參與測試用例的編寫、修改和審核；

3、負責定期組織技術交流會議，以提高組員工作效率；

4、負責及時處理客戶對軟件提出的問題，執行測試定位問題,以幫助產品的修復。

2010 /7—2011 /1：XX網絡游戲有限公司[ 6個月]

所屬行業：娛樂/休閑/體育

技術部 軟件測試

1、負責了解軟件的測試流程，并制定測試流程；

2、負責編寫測試用例，BUG提交給開發人員；

3、負責開發人員修復，進行回歸測試；

4、負責根據需求寫測試大綱、編寫測試用例、測試報告。

教育經歷

2006 /9--2010 /7 西北大學 軟件測試 本科

證 書

2009 /6 大學英語六級

篇（3）

0 概述

（1）軟件測試現狀

隨著軟件的快速發展，軟件產品質量面臨著前所未有的挑戰，提高測試的效率、降低測試的成本，對軟件產品提高質量和應對日趨激烈的市場競爭有著重要意義，而軟件質量的提升主要靠軟件測試來實現。

統計表明，在典型的軟件開發項目中，軟件測試的工作量往往占到總工作量的40%以上，而在總成本中，測試成本要占30%～50%。盡管目前大部分公司已經非常重視軟件測試，但軟件質量提升的實際效果不盡人意，一部分原因是軟件測試方面的投入不足，更大一部分原因是軟件開發人員、甚至軟件測試人員的測試意識不足，測試時間不足，導致無法展開快速、有效的軟件測試。

（2）軟件測試面臨的問題

首先，國內軟件相對起步較晚，現在在軟件開發上投入了大量的人力物力，相對而言在軟件測試方面]有引起足夠的重視，更沒有進行成熟的軟件測試研究，軟件測試環境等測試資源國內暫時沒有形成完善的氛圍。

其次，軟件測試人員較少，難以投入足夠的人力展開大規模的、規范的軟件測試，甚至在大部分公司軟件測試人員地位收入要低于軟件研發人員，軟件測試遠遠沒有引起重視。

第三，軟件時間緊湊，開發時間緊張，測試時間就會被大大縮短。測試的效果會大打折扣。

軟件日益復雜，軟件錯誤日益增多，軟件測試手段不成熟，測試人員不足，測試時間緊張等種種原因導致目前國內測試水平較差，軟件測試沒有完全展開。針對現狀思考，綜合考慮測試時間和測試效果兼顧，制定程序靜態掃描的單元測試與探索性測試的系統測試相結合，先進行程序靜態掃描的單元測試，通過后再進行探索性測試的系統測試的快速測試策略。

1 快速軟件測試策略

軟件測試是為了更快、更早的將軟件產品中存在的缺陷找出來，并敦促軟件開發人員盡快解決軟件缺陷，向客戶提供高質量的產品。確定有效的軟件測試策略可快速找出軟件中的缺陷。

1.1 單元測試

單元測試是檢查軟件單元是否正確實現了詳細設計中的各項功能、性能要求，發現軟件單元內可能存在的各種缺陷。

1.1.1 測試策略

針對單元測試目的，結合實際開發現狀，擬采用靜態測試工具對源代碼進行程序靜態掃描。

程序靜態分析是：在不運行代碼的前提下，通過詞法分析、語法分析、控制流等白盒測試技術對軟件源代碼進行掃描，驗證源代碼是否滿足規范性、安全性的一種代碼分析技術。

1.1.2 常用靜態分析技術

1.1.3 程序靜態掃描的優缺點

程序的靜態分析與動態分析是相對應的兩種代碼分析技術，主要實現方式是通過對程序代碼的自動掃描發現隱含的程序缺陷，主要具有以下兩條優點：

a）不執行程序，對源程序不會產生任何破壞。程序靜態掃描不運行源代碼，只是通過靜態掃描對源代碼進行語法、結構等方面的分析；

b）執行速度快、效率高。成熟的程序靜態分析工具每秒可完成上萬行代碼的掃描，具有執行速度快、效率高的特點。

程序靜態掃描的缺點也比較明顯：誤報率比較高，目前國際最好的程序靜態分析工具誤報率在5-10%之間，還是比較高的一個狀態。

在軟件程序實現的過程中使用程序靜態分析工具對程序進行掃描，有助于快速發現代碼缺陷，提高代碼的質量，是一種在節省人力物力的前提下快速的提升源代碼質量的有效手段。

1.2 系統測試

系統測試的目的是：在真實或者仿真環境下檢驗軟件程序是否滿足“軟件研制任務書”和“軟件需求規格說明”規定的功能、性能等要求。

1.2.1測試策略

針對系統測試目的，結合人員緊張、開發時間短的實際開發現狀，擬采用使用探索性測試的測試策略對軟件程序進行功能、性能的合格性驗證。

探索性測試首先假設軟件存在某缺陷，然后對提出的假設進行逐步驗證。在進行探索性測試的過程中，學習知識、測試設計和測試執行是在同一時間交叉進行的。探索性測試的核心是依據測試的實際情況，即時設計測試用例并在軟件程序上進行驗證，測試結束后將測試的結果整理形成“軟件測試報告”。

1.2.2探索性測試常用方法

探索性測試是對傳統測試技術的補充，它的關注點更多是有目的性地驗證程序是否存在某個缺陷。所以，探索性測試適用于所有的系統測試，但作為一種新興的軟件測試理論，它有著自己獨特的測試方法和管理方式。一般使用如下兩種方法來進行測試：

（1）結對測試法

結對測試的一般測試形式是兩名測試人員共同對一套軟件程序或者一臺機器展開測試。它要求必須有一名測試組長來負責統籌測試全程，進行合理的測試安排。測試組長制定合理的軟件測試計劃，依據計劃，測試成員兩兩組隊，分工合作。在測試過程中，兩位測試人員各有分工，一位進行測試操作，另一位主要負責提出建議、記錄測試發現的缺陷、提出測試過程中對程序的探索性問題等。

結對測試要求測試人員都能清晰地進行交流，因為當一名測試人員將自己的探索性想法與其他測試人員進行溝通時，極有可能會觸發其他測試人員的靈感，這種發散性的交流方式會碰撞出更多的思維火花，設計出更加準確、完整、符合實際測試情況的的軟件測試用例，這比傳統測試中要求測試人員按照固定的測試計劃進行軟件測試更有效率。除了以上優點，結對測試還有以下優點：

a）輕松的測試環境：輕松的測試環境將避免測試過程中測試人員產生的的枯燥和無聊情緒，明顯提高軟件測試效率；

b）良好的連續性：結對測試中，兩位測試人員分工明確，一名軟件測試人員專注于執行測試，另一名軟件測試人員負責記錄及文檔整理，分工明確將大大增加測試的連續性，使測試具有更好的可持續性；

c）降低外界干擾：兩人組成一個小的團隊，其他無關人士前來打擾測試的機會將會大大降低，排除外界干擾 ，提高工作效率；

d）清晰的報告測試結果：結對測試中一人專注負責記錄和整理測試結果，這將使測試報告的數據清晰完整；

e）有利于培養新的測試人員：結對測試，兩兩結對，有經驗的測試前輩趁此機會將探索性測試中規律性的經驗傳授給新的測試人員，新的測試人員一邊學習一邊實踐，幫助新人快速成長，提升測試技能。

（2）會話測試法

探索性測試的創始人James Bach提出過另一種有效的測試方法：會話測試法。這種測試方法的優點是既不影響探索性測試靈活性和探索性的特點，又能避免探索性測試人員松散不服從統一管理。目前是探索性測試所有方法中比較公認的一個有效的測試方法。

會話測試法中的會話主要包括兩部分：一部分是明確的測試主題，另一部分是可以被檢查的測試過程?！皽y試主題”指的是測試中想要發現的軟件缺陷或計劃完成被測試的功能?！翱梢员粰z查”是指階段性的軟件測試報告，該軟件測試報告來表征會話測試期間的工作成果。

持續時間1.5小時的會話測試為最優會話測試，但這不是絕對的時間限制，一般而言小于45分鐘的會話測試稱之為短會話測試，大于2個小時的會話測試稱之為長會話。一般情況，每天可以使用會話測試法對軟件程序進行三輪測試。

會話測試中沒有固定的模式對測試步驟及測試用例進行規定和限制，依據測試人員和測試主題來進行靈活選擇和執行，例如測試人員可能會從某項功能開展測試，也有可能從頻繁出現的缺陷打開測試入口。

1.2.3 探索性測試的優缺點

探索性測試最大的特點是具有強大的缺陷發現能力，作為一種高效率的測試方法，主要具有以下優點：

a）測試方式靈活、富有創造性和主觀能動性。它比傳統的測試方法更加靈活，例如探索性測試對測試文檔的要求沒有傳統測試那么嚴格，但是它能夠發現正常測試用例執行以外的缺陷，更有效地發現隱性缺陷，發現很多正常途徑無法發現的缺陷也能夠激發測試人員的創造性和主觀能動性。

b）測試時間短，執行效率高。測試學習、測試設計和測試執行交叉進行，只對測試缺陷進行詳細的記錄，會大大縮短測試時間，為項目的整體開發節省大量時間。據統計，有經驗的測試人員在使用探索性測試方法進行測試時，執行測試的時間能占到測試總時間的80%，而測試設計只占總測試的20%。

探索性測試的缺點也是顯而易見的：對軟件測試工作沒有一個整體的規劃，不利于測試的規范化、標準化；重復性測試的幾率比傳統測試要大很多，很難確定哪些測試已經執行過。

在測試時間短、測試資源不充足的情況下，使用探索性的測試策略展開系統測試，可以有效快速地發現軟件缺陷，提高軟件質量。

2 結論

軟件質量是軟件的生命，由于軟件缺陷而造成經濟損失、導致嚴重后果的事例屢見不鮮，軟件測試作為軟件質量保證的重要手段一直都是軟件工程研究和應用的熱點。在有限的人力物力情況下，如何展開有效的軟件測試，顯著提升軟件質量更是每個軟件研發人員的關注重點。

程序靜態掃描提升源代碼質量、探索性測試保證軟件功能的合格性，二者有效地結合，在極短的時間內，節省開發人員精力的前提下，可以有效地_到軟件測試的目的，是一種有效的測試策略。

【參考文獻】

[1]張曉明，黃琳譯.軟件測試的藝術，機械工業出版社.

[2]朱少民編.軟件測試方法和技術，清華大學出版社，2005.

[3]汪穎譯.人月神話，清華大學出版社.

篇（4）

0　引言

隨著Intemet的普及和電子商務應用的深入。Web應用程序得到越來越廣泛的應用，B／$架構也逐漸代替C／S架構成為主流的應用模式。與傳統軟件相比，Web應用程序具有分布式、并發、多用戶異構等特點，這些特點對軟件測試提出了新的要求。Web測試是保證Web應用程序質量的有效手段，目前在Web測試的方法和技術以及相關工具等方面的研究已進行了一些嘗試。軟件測試的自動化技術有助于開發出更高質量的產品，并且可以節省開發時間和開支。

1　Web軟件體系結構

Web應用程序采用B／S結構，它是伴隨著Intemet技術的不斷進步，由C／S結構改進和發展起來的新型體系結構。B／S結構利用不斷成熟和普及的瀏覽器技術實現原來需要復雜專用軟件才能實現的強大功能。是一種全新的軟件系統構造技術。這種結構已成為當今應用軟件開發的首選體系結構。

Web系統的基本工作過程是：在客戶端，用戶通過瀏覽器向Web服務器中的控制模塊和應用程序輸入查詢要求，Web服務器將用戶的數據請求提交給數據庫服務器中的數據庫管理系統DBMS；在服務器端，數據庫服務器將查詢的結果返回給Web服務器，再以網頁的形式發回給客戶端。在此過程中，對數據庫的訪問要通過Web服務器來執行。Web系統的基本體系結構及工作過程如圖1所示。

從上面的體系結構可以看出，Web測試應該分為三個層次，客戶端測試、服務器端測試和數據庫測試?？蛻舳酥饕獪y試用戶瀏覽器的基本功能和頁面現實情況；服務器端主要測試用戶請求響應情況；數據庫端主要測試數據一致性和輸出錯誤。

2　Web軟件測試的主要特點與難點

Web軟件由于其分布式應用、具有各種運行時行為、涉及多種標準協議，可能在硬件、軟件、通信、對象管理等環節出現各種缺陷。其體系結構和應用的復雜性，以及技術和規范不斷地發生變化，對測試提出了新的挑戰。Web軟件測試的特點與難點主要體現在以下幾個方面：

(1)Web軟件的開發環境與其應用環境有很大的不同，在之前，很難對其實際的運行場景進行預測，如用戶類型、并發用戶數量、Web服務調用的裝載模式和訪問方式等，這些差異和應用的不確定性都增加了Web服務測試的困難。

(2)Web軟件測試主要基于軟件接口進行設計和實現，因此必須采用自動化測試方法，與傳統的需要大量人工干預的測試方法截然不同。

(3)Web軟件由于其分布特征，會出現大量用戶通過不同的環境訪問同一個服務的情形，因此，性能和可擴展性是Web軟件測試的重要方面。

(4)Web軟件及軟件集成的、發現和綁定都是動態完成的，其過程的不確定性和不可見性增加了測試難度。

(5)Web軟件訪問接口和訪問方法后增加了Web軟件的安全隱患，提高了被系統攻擊的機會。此外，對于所調用的分散、異構的外部Web服務的安全性的管理也非常困難。如何提高Web軟件的安全性也是測試者要考慮的重要問題。

(6)Web軟件的應用通常涉及到軟件提供者、者和使用者三種角色，都需要參與到測試的不同階段，其分布式合作的特征使得測試的組織、缺陷管理、結果評估等活動都更加困難。

目前。針對Web軟件的測試方法和技術的研究還處于初始階段，代表性的研究主要有基于形式化方法對協議及規格說明的驗證(如WSFL驗證技術、SOAP驗證)和Web服務的集成測試。

3　傳統軟件測試與Web軟件測試

傳統軟件測試經常是靜態、離線的測試，盡管這些傳統的測試技術也可以應用到Web服務的測試當中，然而相當有意義的一部分Web軟件測試都必須是動態的和在運行時間內的即時測試。Web軟件這種動態和即時測試對傳統的測試理論提出了新的挑戰和要求。表1比較了傳統軟件和Web軟件測試的差別。

4 Web軟件測試的內容和方法

Web測試主要目標是確保提交高質量的Web軟件。對于錯綜復雜的Web軟件，從什么地方開始測試。哪些方面是測試的核心，有限的測試資源如何分配，這些都是Web軟件測試需要重點考慮的問題。下面介紹Web軟件測試的主要內容和方法。

4.1　功能測試

鏈接測試　鏈接是Web應用系統的一個主要特征，它是在頁面之間切換和指導用戶去一些不知道地址的頁面的主要手段。鏈接測試可分為三個方面：①測試所有鏈接是否按指示的那樣確實鏈接到了該鏈接的頁面。②測試所鏈接的頁面是否存在。③測試Web應用系統上有無孤立的頁面。所謂孤立頁面是指沒有鏈接指向的頁面，只有知道正確的URL地址才能訪問。

表單測試　單元當用戶給Web應用系統管理員提交信息時，就需要使用表單操作。例如用戶注冊、登陸、信息提交等。在這種情況下，我們必須測試提交操作的完整性，以校驗提交給服務器的信息的正確性。例如：用戶填寫的出生日期與職業是否恰當，填寫的所屬省份與所在城市是否匹配等。

Cookies潮試Cookies通常用來存儲用戶信息和用戶在某應用系統的操作。當一個用戶使用Cookies訪問了某一個應用系統時，Web服務器將發送用戶的信息，把該信息以Cookies的形式存儲在客戶端計算機上，這可用來創建動態和自定義頁面或者存儲登錄等信息。如果Web應用系統使用了Cookies。就必須檢查Cookies是否能正常工作而且對存儲的信息已經加密。測試的內容可包括Cookies是否起作用，是否按預定的時間進行保存，刷新對Cookies有什么影響等。

設計語言測試　Web設計語言版本的差異，例如使用不同版本的HTML等，可以引起客戶端或服務器端嚴重的問題。在分布式開發環境中，開發人員都不在一起，這個問題就顯得尤為重要。除了HTML的版本問題外，不同的腳本語言，例如Java、JavaSeript、ActiveX、VBScript或Perl等也要進行驗證。

數據庫測試　數據庫為Web應用系統的管理、運行、查詢和實現用戶對數據存儲的請求等提供空間。在使用了數據庫的Web應用系統中，一般情況下，可能發生兩種錯誤，分別是數據一致性錯誤和輸出錯誤。數據一致性錯誤主要是由于用戶提交的表單信息不正確而造成的，而輸出錯誤主要是由于網絡速度或程序設計問題等引起的。針對這兩種情況，可分別進行測試。

4.2　性能測試

網站的性能測試對于網站的運行而言異常重要，但是目前對于網站的性能測試做得不夠，我們在進行系統設計時也沒有一個很好的基準可以參考，因而建立一整套網站的性能測試方案將是至關重要的。

連接速度測試　用戶連接到Web應用系統的速度根據上網方式的變化而變化，他們或許是電話撥號，或是寬帶上網。當下載一個程序時，用戶可以等較長的時間，但如果僅僅訪問一個頁面就不會這樣。連接速度太慢。還可能引起數據丟失，使用戶得不到真實的頁面。

負載測試　負載測試是為了測量Web系統在某一負載級別上的性能，以保證Web系統在需求范圍內能正常工作。負載級別可以是某個時刻同時訪問Web系統的用戶數量，也可以是在線數據處理的數量。例如：Web應用系統能允許多少個用戶同時在線；如果超過了這個數量，會出現什么現象。

壓力測試　壓力測試是指實際破壞一個Web應用系統，測試系統的反映。壓力測試是測試系統的限制和故障恢復能力，也就是測試Web應用系統會不會崩潰，在什么情況下會崩潰。黑客常常提供錯誤的數據負載，直到Web應用系統崩潰，接著當系統重新啟動時獲得存取權。

4.3接口測試

服務器接口　第一個需要測試的接口是瀏覽器與服務器的接口。測試方式一般是，測試人員提交事務，然后查看服務器記錄，并驗證在瀏覽器上看到的正好是服務器上發生的。測試人員還可以查詢數據庫，確認事務數據已正確保存。

外部接口有些Web系統有外部接口，例如，網上商店可能要實時驗證信用卡數據以減少欺詐行為的發生，測試的時候，要使用Web接口發送一些事務數據，分別對有效信用卡、無效信用卡和被盜信用卡進行驗證。

錯誤處理　最容易被測試人員忽略的地方是接口錯誤處理。通常我們試圖確認系統能夠處理所有錯誤，但卻無法預期系統所有可能的錯誤。為此，可以嘗試在處理過程中中斷事務，看看會發生什么情況，訂單是否完成，嘗試中斷用戶到服務器的網絡連接，系統能否正確處理這些錯誤。

4.4　兼容性測試

平臺測試市場上有很多不同類型的操作系統，最常見的有Windows、Unix、Macintosh、Linux等。Web應用系統的最終用戶究竟使用哪一種操作系統，取決于用戶系統的配置。這樣，就可能會發生兼容性問題，同一個應用可能在某些操作系統下能正常運行，但在另外的操作系統下運行可能會失敗。因此，在Web系統之前，需要在各種操作系統下對其進行兼容性測試。

瀏覽器測試　瀏覽器是Web客戶端最核心的構件。來自不同廠商的瀏覽器對JavadavaScript、ActiveX或不同的HTlML規格有不同的支持，例如，ActiveX是Microsoft的產品，是為Intemet Explorer而設計的，JavaScript是Netscape的產品，Java是Sun的產品等等。測試瀏覽器兼容性的一個方法是創建一個兼容性矩陣，在這個矩陣中，測試不同廠商、不同版本的瀏覽器對某些構件和設置的適應性。

4.5　安全測試

景登　現在的Web應用系統基本采用先注冊，后登錄的方式，因此，必須測試有效和無效的用戶名和密碼。要注意到系統是否對大小寫敏感，可以試行登錄多少次，是否可以不登錄而直接瀏覽某個頁面等。

日志文件為了保證Web應用系統的安全性，日志文件是至關重要的。需要測試相關信息是否寫進了日志文件、是否可追蹤。

篇（5）

正確性測試又稱功能測試，它檢查軟件的功能是否符合規格說明。由于正確性是軟件最重要的質量因素，所以其測試也最重要。

基本的方法是構造一些合理輸入，檢查是否得到期望的輸出。這是一種枚舉方法。倘若枚舉空間是無限的，那可慘了，還不如回家種土豆有盼頭。測試人員一定要設法減少枚舉的次數，否則沒好日子過。關鍵在于尋找等價區間，因為在等價區間中，只需用任意值測試一次即可。等價區間的概念可表述如下：

記（A,B）是命題f(x)的一個等價區間，在（A,B）中任意取x1進行測試。

如果f(x1)錯誤，那么f(x)在整個（A,B）區間都將出錯。

如果f(x1)正確，那么f(x)在整個（A,B）區間都將正確。

上述測試方法稱為等價測試，來源于人們的直覺與經驗，可令測試事半功倍。

還有一種有效的測試方法是邊界值測試。即采用定義域或者等價區間的邊界值進行測試。因為程序員容易疏忽邊界情況，程序也“喜歡”在邊界值處出錯。

例如測試的一段程序。憑直覺等價區間應是（0,1）和（1,+∞）?？扇=0.5以及x=2.0進行等價測試。再取x=0以及x=1進行邊界值測試。

有一些復雜的程序，我們難以憑直覺與經驗找到等價區間和邊界值，這時枚舉測試就相當有難度。

在用“白盒測試”方式進行正確性測試時，有個額外的好處：如果測試發現了錯誤，測試者（開發人員）馬上就能修改錯誤。越早改正錯誤，付出的代價就越低。所以大多數軟件公司要求程序員在寫完程序時，馬上執行基于單步跟蹤的“白盒測試”。

2容錯性測試

容錯性測試是檢查軟件在異常條件下的行為。容錯性好的軟件能確保系統不發生無法意料的事故。

比較溫柔的容錯性測試通常構造一些不合理的輸入來引誘軟件出錯，例如：

（1）輸入錯誤的數據類型，如“猴”年“馬”月。

（2）輸入定義域之外的數值，上海人常說的“十三點”也算一種。

粗暴一些的容錯性測試俗稱“大猩猩”測試，除了不能拳打腳踢嘴咬，什么招術都可以使出來。這里我舉不出例子，因為我沒有對程序粗暴過，并且這輩子也不打算學會粗暴。

3性能與效率測試

性能與效率測試主要是測試軟件的運行速度和對資源的利用率。有時人們關心測試的“絕對值”，如數據送輸速率是每秒多少比特。有時人們關心測試的“相對值”，如某個軟件比另一個軟件快多少倍。

在獲取測試的“絕對值”時，我們要充分考慮并記錄運行環境對測試的影響。例如計算機主頻，總線結構和外部設備都可能影響軟件的運行速度；若與多個計算機共享資源，軟件運行可能慢得像蝸牛爬行。

在獲取測試的“相對值”時，我們要確保被測試的幾個軟件運行于完全一致的環境中。硬件環境的一致性比較容易做到（用同一臺計算機即可）。但軟件環境的因素較多，除了操作系統，程序設計語言和編譯系統對軟件的性能也會產生較大的影響。如果是比較幾個算法的性能，就要求編程語言和編譯器也完全一致。

性能與效率測試中很重要的一項是極限測試，因為很多軟件系統會在極限測試中崩潰。例如，連續不停地向服務器發請求，測試服務器是否會陷入死鎖狀態不能自拔；給程序輸入特別大的數據，看看它是否吃得消。

4易用性測試

易用性測試沒有一個量化的指標，主觀性較強。調查表明，當用戶不理解軟件中的某個特性時，大多數人首先會向同事、朋友請教。要是再不起作用，就向產品支持部門打電話。只有30%的用戶會查閱用戶手冊。[Cusumano1995]

一般認為，如果用戶不翻閱手冊就能使用軟件，那么表明這個軟件具有較好的易用性。

5文檔測試

文檔測試主要檢查文檔的正確性、完備性和可理解性。好多人甚至不知道文檔是軟件的一個組成部分。

正確性是指不要把軟件的功能和操作寫錯，也不允許文檔內容前后矛盾。

篇（6）

頭信息包括：測試軟件名稱、版本號、缺陷或錯誤類型、可重復性、測試平臺、平臺語言、缺陷或錯誤范圍。要求填寫完整、準確。

簡述是對缺陷或錯誤特征的簡單描述，可以使用短語或短句，要求簡練、準確。

操作步驟是描述該缺陷或錯誤出現的操作順序，要求完整、簡潔、準確。對命令、系統變量、選項要用大寫字母，對控件名稱等加雙引號。

注釋一般是對缺陷或錯誤的附加描述，一般包括缺陷或錯誤現象的圖像，包括其他建議或注釋文字。

書寫專業軟件問題報告的技巧

書寫軟件問題報告的目的是為了正確地重復缺陷或錯誤，從而在后續工作中可以準確驗證并加以處理。因此，基本要求是準確、簡潔、完整、規范。為了正確書寫專業的軟件問題報告，應該注意以下要點：

每個軟件問題報告只書寫一個缺陷或錯誤

這樣可以每次只處理一個確定的錯誤，定位明確，提高效率，也便于修復錯誤后方便的進行驗證。

對錯誤的描述要做到簡潔、準確、完整，揭示錯誤實質

描述要準確反映缺陷或錯誤的本質內容，簡短明了。為了便于在答數據庫中尋找，包含錯誤發生時的用戶界面是個良好的習慣。例如記錄對話框的標題、菜單、按鈕等控件的名稱。

明確指明錯誤類型和嚴重程度

根據錯誤的現象，總結判斷錯誤的類型和嚴重程度，例如，是功能錯誤？還是界面布局錯誤？該錯誤是屬于特別嚴重的錯誤還是一般錯誤？是否影響軟件的后續開發和？

每一個步驟盡量只記錄一個操作

簡潔、條理井然，容易重復操作步驟，以便確認、修復、驗證該錯誤.

復現的操作步驟要完整，準確，簡短

保證快速準確的重復錯誤，完整即沒有缺漏，準確即步驟正確，簡短即沒有多余的步驟。

附加必要的錯誤特征圖像

為了直觀的觀察缺陷或錯誤現象，通常需要附加錯誤出現的界面，作為附件附著在記錄的附件部分。為了節省空間，又能真實反映缺陷或錯誤本質，可以捕捉缺陷或錯誤產生時的全屏幕，活動窗口和局部區域。

附加必要的測試用例

篇（7）

拋開具體的軟件工程的具體模型，一般的產品周期流程可以如下劃分

篇（8）

3、第2階段：功能測試；工作方向：功能/手工測試；市場價值：薪資可達到7000元/月以上

篇（9）

一般地，項目啟動過程組包括兩個過程:即制定項目章程和制定項目初步范圍說明書;而項目規劃過程組則會綜合項目的成本、范圍、時間、質量、風險、人力、溝通、采購等因素制定項目計劃，該項目計劃將用于指導項目的實際執行。

對任一項目而言，有三個文件是非常重要的。即:項目章程、項目范圍說明書，項目管理計劃。這三個文件均產生于項目啟動階段和項目規劃階段。其中項目章程被認為是三大文件之首（項目章程、項目范圍說明書，項目管理計劃）。一個項目，不論大小，都應該有項目章程。

項目章程由項目發起人(Sponsor)簽發，自簽發之日起，項目經理即獲得法定權力。

項目經理在獲得法定權力之后的第一動作是制定項目初步范圍說明書。為了制定這份文檔，他/她將廣泛地收集來自項目發起人的需求，以便在項目計劃正式編制之前，與項目發起人在項目范圍的理解上達成一致。項目初步范圍說明書還將在后續項目范圍規劃過程中進一步細化，并融入項目客戶、執行組織、項目干系人等各方面需求，進而形成完整的項目范圍說明書。

項目初步范圍說明書編制完成以后，項目經理將進入項目計劃編制階段。這個階段將會涉及項目管理方方面面的規劃、計劃。有經驗的項目經理在此過程中總是會認真聽取和吸收團隊骨干成員和同行們的經驗意見，從而形成廣為認可和接受的規劃、計劃。

經過權衡和必要的調整，這些文檔最終將被集成到一個完整的項目管理計劃中。項目管理計劃經由項目發起人、高級管理層審批以后，即可生效。

此后，項目經理將召開項目開工會議，宣布項目正式開始進入執行階段。

項目啟動階段的項目章程和項目初步范圍說明書，也可以體現在分包或采購合同中。這在軟件外包服務型企業中最為常見。

通常，伴隨合同到達項目經理手中的還有項目建議書，項目建議書由項目發起人制定，內容和項目章程中有關產品、可交付成果的描述大致類似，此外，還應包括對項目經理成功完成此項目的一些指導性建議。項目經理進行綜合考慮，與相關干系人磋商，在項目團隊相關專家的幫助下，制定出合適的項目管理計劃。

上面討論的是一般項目啟動過程組與規劃過程組。具體到測試項目的啟動與規劃，工作內容也是類似的。讀者朋友請根據所在測試項目的特點做適當調整。需要交待清楚的是測試項目啟動與規劃過程組有可能與其他六個過程組（測試需求分析、測試設計、測試執行、測試項目收尾、測試交付、測試項目監控與調整）在項目實施過程中有頻繁的迭代關系（參見圖1）。

比如，規劃過程組有可能在整個項目生命期內都有更新和完善。

對于整周期軟件開發項目的測試而言，上述過程組的內容會有較大的差異。

比如:項目章程將重點關注開發，而不會過多討論測試相關的工作。對于這一類型的軟件測試，筆者建議在任命開發項目經理的同時，由項目經理[適用于項目型或強矩陣組織]或高層經理[適用于弱矩陣或職能型組織]指定項目測試經理。測試經理應根據項目章程、項目初步范圍說明書和項目建議書盡早開始軟件測試相關規劃和設計，并和項目經理溝通、協調，以將一些重要的信息及時反映給項目經理，從而使項目計劃能較好地支持測試工作的開展。

軟件測試需求分析

理論上，軟件測試需求是源于軟件需求的，而軟件需求又是源于用戶需求的。然而，有些時候在分析軟件測試需求時并不存在已經文檔化的軟件需求規格說明。

在這種情況下，要分析軟件測試需求可能仍然需要追溯到用戶需求。由于后者涉及需求工程的專門知識，本文略過不做細述;這里重點討論前者。在一個規范化的軟件需求規格說明中，用戶需求是由更高層次的業務需求（體現在項目章程、SOW、項目建議書等文檔中）細化而成，它通常描述了用戶使用該軟件系統會涉及到的不同的執行路徑、工作邏輯以及所預期的處理結果。在UML表示方法中，用戶需求通常通過Use Case來進行刻畫。

接下來，用戶需求將進一步轉化為三類需求項，即功能需求項、性能需求項以及約束性需求項。這三類需求項就是通常意義上的軟件需求項。管理這三類需求項的矩陣被稱為需求矩陣。

理論上，在測試資源許可并且確有必要的前提下，測試的使命將是驗證和確認待開發的軟件及其中間產品滿足需求矩陣各個需求項。（注意:為了簡化討論，這里筆者沒有把需求的驗證與確認納入進來，實際上這部分工作也是軟件測試工作的重要組成部分。）

然而，幾乎沒有幾個公司或開發團隊能夠提供這類測試所需的諸多的資源，此時，一種可行的策略是將待測試的軟件需求項按照優先關系進行排序，以幫助測試經理決策在既定資源的情況下，應該如何統籌安排測試工作。

軟件需求項是測試需求分析的起點，這一點在工程實踐中并不絕對。對于不同階段的測試（這里主要指單元測試、集成測試、系統測試和驗收測試，暫不考慮驗證技術和需求和設計的確認），測試需求開發所涉及的工作內容和方法都會略有差異。例如，如果是一個驗收測試，那么，除了個別的需求需要做進一步明確外，幾乎可以將測試需求等同于用戶需求和業務需求（由于該類測試是以客戶為主體，因此并不需要向下追溯到軟件需求）。

又如，如果是系統測試，除了需要對不具備可測試性的軟件需求項進一步開發外，幾乎可以對軟件需求和測試需求不做區分。

再如，如果是集成測試，測試需求應該從概要設計規格說明中導出。如果尚不存在概要設計規格說明，就需要從軟件需求規格說明出發，與軟件設計人員協同工作，具體定出構成系統的各個模塊、子系統、分系統的功能、性能、約束性條件以及相互接口關系。根據協同工作的結果，開發出對應的測試需求。

最后，如果是單元測試，測試需求應該從詳細設計規格說明中導出。如果項目不存在概要設計規格說明，就需要從概要設計規格說明出發，與軟件設計人員明確每個模塊內部的對象屬性與方法以及對象與對象間的通信關系。根據此結果，進一步開發相應的測試需求。相應地，上一節所說的對軟件需求項進行優先關系排序在實踐中要變通地理解為對測試需求項進行優先關系排序。

讀者朋友可能會問，對于整周期的開發項目，以上論述是否意味著測試需求開發的依據文檔是否要根據測試所處的階段而不斷調整呢？是的，筆者認為這也是完全必要的。我們不能指望軟件需求項能夠描述清楚集成或單元測試階段的測試需求。測試需求的開發總是有賴于相應層次的軟件規格說明書

只有在開發團隊不能提供的情況下才確有必要循著“詳細設計規格說明->概要設計規格說明->軟件需求規格說明->用戶需求規格說明->項目章程、合同、項目建議書、工作說明書等”的順序往前追溯。通常相關依據文檔的可測試性越好，測試需求開發所需要的工作量越少。

篇（10）

軟件測評是保證軟件質量的重要步驟，它在軟件運行之前對軟件進行分析、預測、試用等一系列的方法，找到軟件存在的問題和缺陷，以免為以后造成不必要的麻煩和損失。這樣可以使軟件穩定、正常地運行，提高其可靠性。軟件可靠性評估是對軟件正確評估的重要手段。軟件的可靠性主要是指軟件在一定的時間和條件下達到預期的目的的能力。軟件的可靠性是軟件的固有特性，它表明的是軟件用戶對軟件的滿意度，可靠的軟件是完整的、能夠滿足用戶需求、正確的。它的要素主要有：一定的時間限制、特定的環境、特定的功能。

1 軟件測試與可靠性評估的現狀

就目前來看，軟件測試并沒有受到人們的充分重視，還存在著許多的誤區，這樣不利于軟件質量和性能的提高。首先，人們普遍認為軟件測試實在軟件開發后進行的，其實并不是這樣，軟件測試是貫穿整個軟件項目中的，在的每一個軟件活動中都要進行不同的測試，用以保證每個階段的正確性，從而來保證軟件的質量。其次，在軟件發現問題之后，往往將責任歸咎于軟件測試人員，這是不正確的。軟件出現錯誤應該要從多方面考慮，要查清楚原因再做定奪，否則會挫敗軟件測試人員的工作積極性。然后就是，對軟件測試的要求過低，工作人員的職業素質比較低下。絕大多數人認為軟件測試是一項簡單的工作，任何人都有能力勝任，其實不然，軟件測試工作需要具備專業技能的人才，掌握了相關的知識，具有很強的責任心。此外，大部分人認為軟件測評只與測試人員有關。實際上，軟件測試還與程序員有關。因為軟件測試需要各個工作人員保持密切的聯系。最后，軟件測評往往會在時間比較緊時做少量的測試，而有充足的時間會做比較多大測試。

我國在軟件可靠性評估這一塊發展得比較晚，還存在著許多的不足。首先對軟件評估沒有一個完整規范的管理系統，在軟件項目工作安排上缺乏科學有效性，導致各種評估誤差，影響軟件的進一步發展，影響到軟件占據市場的份額。此外，目前我國的軟件可靠性評估一般將重點放在軟件的研制階段，對軟件的評估程度不到位，導致軟件項目后期出現一定的誤差。而且我國關于軟件評估的可靠性沒有相對其他國家嚴謹規范的標準，對軟件的評估存在著許多的問題，再加上軟件評估人員的職業素質有限，對其認識具有不一致性，導致無法有實際意義、正確、有效地進行評估，相關的部門得不到有用的信息，從而誤導軟件公司做出錯誤的決策，不利于企業的競爭與發展。

2 軟件測試與可靠性評估的意義

軟件測評與可靠性評估能夠發現軟件存在的錯誤與缺陷，促進軟件的完善與改進，讓其更好地為軟件用戶服務，滿足軟件用戶的需求。然后，能夠有效定義軟件成分有低層到高層的組裝過程，便于日后軟件的維護與修改。此外，能夠有效驗證軟件那是否符合原有和相關規定要求，迫使企業軟件從開發到軟件投放市場，都有利于是軟件正規化，符合相關規章制度，避免一些非法操作的軟件投入市場，損害某些個人以及集體的利益。

3 使得軟件測試與可靠性評估有效的措施

軟件的測試與可靠性評估的方法是極為重要的，如何讓其高效、正確的為軟件服務，是軟件研發、研究組織應該為之努力的目標。其一，要科學的管理系統，對軟件人員進行很好的管理，讓其充分發揮優勢，使整個系統有組織、有次序的運行，既能節約資源，又能提高工作效率。其二，軟件人員要充分認識到軟件測試與可靠性評估的重要性，在工作當中認真負責，不能因為個人原因而影響了整個軟件開發運行的進度和質量。其三，要注意對軟件測試與評估的宣傳，讓其他人認識到這不僅僅只是軟件檢測員與軟件評估員的事情，要求大家團結合作，避免某一環節出現錯誤。其四，要培養出一批具備專業水平的軟件測試與評估人才，充分發揮其作用。所以組織要對其進行定期的培訓，并要保證培訓的質量，不能僅僅將其當成一種形式與任務，要將培訓工作落到實處，真正提高工作人員的職業技能，要對培訓過程中不認真的人進行一定程度的懲罰，每次培訓完后要進行考核，檢測培訓質量，并為下一次的培訓提供經驗。這樣就能夠在很大程度上提高培訓的效果，不至于培訓無效，浪費人力、物力、財力。

4 軟件測試與軟件可靠性評估的原則

首先，軟件測試與評估應該要及時，并且要增加測試、評估的力度，盡可能地多進行測試，進行評估。此外，要注意軟件開發過程的整體性，保證軟件測試貫穿于整個軟件設計當中，與其他步驟結合起來，及時發現錯誤的早期階段，降低組織軟件的成本，測試時要將相關的數據結合起來，比如說：測試的輸入數據與其對應的輸出數據。要防止軟件工作人員檢測自己所設計的程序。要按計劃、全面地實施軟件測試。軟件評估要保證客觀、科學，不能以主觀心態來評判，要有科學依據。采納一些比較科學的方法來進行評估。要遵循謹慎原則，不能過于隨意，要加強重視，以防止評估出現誤差，造成不必要的損失。

5 小結

軟件測試與可靠性評估對于軟件的進步發展有著重大的意義，相關的部門、組織要高度引起重視，客觀、正確、科學地看待軟件測試與評估，針對自己關于軟件測試與評估所出現的問題采取相關的措施，從而促進軟件自身的完善與發展，提高軟件的市場競爭力。由于本人的學識有限，如果本文存在著任何的缺點和不足，請大家諒解。

參考文獻

[1]科教導刊編輯部；軟件測試外包一站式人才培養模式的探索與實踐[J]；科教導刊；2013年第33期

[2]易敏捷；基于多平臺的計算機軟件測試方法分析[J]；科技傳播；2013年第20期

[3]王文斌、劉方舟、劉雪；基于云計算平臺的軟件測試策略[J]；計算機光盤軟件與應用；2013年第17期

作者簡介

篇（11）

1.課程的定位與教學設計

1.1 課程定位

《軟件測試》課程作為軟件專業二年級下學期的專業課，它的前導課程是《數據庫設計》、《數據結構》、《軟件工程實施》，后續課程是課程實訓及畢業實習。通過本課程的學習，使學生加深對軟件測試基本理論和基本方法的理解與應用，能熟練使用常用軟件測試工具，并能運用軟件測試工具完成應用軟件的測試工作，提高學生對軟件的測試與維護能力，并進一步培養學生的的團隊協作能力。

1.2 課程設計思路

軟件測試是高職計算機軟件專業學生在以后的工作崗位上要用到的核心技能。因此，本課程應該作為專業必修課程和核心課程，重點培養學生在以后的工作崗位上所需的職業能力：白盒測試、黑盒測試、自動化功能測試與性能測試。

《軟件測試》課程的總體設計思路是，轉變傳統的學科課程模式，不再以知識傳授為主，構建以工作任務為中心的企業培訓體系，引入企業項目，讓學生在真實的企業項目中完成相應的工作任務，從而儲備相關的專業知識，發展職業能力。授課內容重點突出對學生職業能力的培養。課堂上不再單純地只講授理論知識，而是圍繞實際工作任務的需要來選取，這充分考慮了高職學生動手能力強，理論知識薄弱的特點。

2.教學設計

2.1 教學情境設計

本課程小組通過學院專業指導委員會、重慶亞德科技、重慶大佳、重慶港澳大家等軟件公司的企業技術人員進行實際調查，制定了適合高職學生的軟件測試課程體系與職業能力，確定了軟件測試課程典型的教學情景與子情景，在教學情景中給出具體的工作任務、工作方法以及要求學生掌握的知識與技能等，在教學中貫徹理論實踐一體化的教學模式，做到教、學、做三結合，充分體現工學結合的優勢，培養學生的職業素質。本課程的5個工作過程及11個典型工作任務如表1所示。

2.2 教材設計

（1）教材應充分考慮軟件測試的實踐特性，以工作任務為導向，引入必須的軟件測試理論知識，讓學生在實際測試的過程中，循序漸進地掌握必要的理論知識。

（2）編寫的內容要以項目驅動為原則，以企業的實際案例、場景模擬、工作過程錄像為載體，增強課后的能力拓展，并根據高職學生的職業能力所需知識的深度和廣度來編寫，并在具體的工作任務中使學生逐漸形成團隊協作意識。

（3）教材應突出軟件測試技術的實用性、前瞻性和開放性，不能只是簡單地介紹一些技術上的操作，而忽略了軟件學生所需的職業能力，在教材中應融入軟件測試技術中所用到的新規范、新技術、新標準、新工具、新知識，讓學生能系統地掌握軟件測試的前沿知識。

（4）教材應充分引領學生主動、積極地去學習，因此，文字表述要簡明扼要，內容展現應圖文并茂，內容應詳略得到。

2.3 教學方法設計

由于本課程的主要教學內容涉及白盒測試、黑盒測試、自動化功能測試與性能測試等操作性很強的教學環節，必須通過課程實訓才能達到對項目作規范需求分析的培養目標。具體教學方法設計如下：

（1）全班學生分為N個項目小組，3人一小組，1人任組長，組長要求協調溝通能力比較強。

（2）在教學過程中應加強學生對軟件總體的測試能力，采用任務驅動教學，注重以任務引領，提高學生學習興趣；

（3）組建軟件外包中心，引進企業項目，讓學生真實地體驗在軟件公司的測試流程。外包中心作為理論實踐一體化教室，達到理論和實際不脫節。

（4）教學過程中可參考軟件測試評師考試中規定的知識要求和技能等級職業標準。

（5）教師模擬企業的項目經理，必須具有開拓精神，帶領團隊完成工作任務，并在完成工作任務的過程中，探索基于工作過程的職業教育新模式，培養學生的軟件測試能力，構建軟件測試知識體系。

2.4 教學評價設計

（1）突出過程評價，結合課堂提問、實作測試、課后拓展、任務考核等手段，加強實訓教學環節的考核，并注重平時考核。

（2）強調目標評價和理論與實踐一體化評價，注重引導學生進行學習方式的改變。

（3）每個項目小組在完成課程后，要將所學的內容做ppt，匯報本小組項目完成的情況以及體會。

（4）實行學習過程的過程化考核。平時作業、期中與期末考試均采用上機實訓的方式考核，對于不合格者，在團隊的協作幫助下持續練習，直至過關。這樣可以督促學生不斷地練習，真正提高動手能力。

（5）課程的學期成績=平時作業（10%）+上課考勤（10%）+小組項目測試情況（30%）+小組ppt總結情況（10%）+期末成績（40%）

3.課程資源的開發與利用

（1）圍繞軟件測試課程，收集教師和學生必備的軟件測試工具，制作適宜教學的多媒體教學課件。

（2）組建軟件外包中心，搭建實訓工作平臺，為學生實訓提供真實的工作環境，從而提高其職業素養。

（3）要充分開發網絡課程，讓學生在課余時間可以自主學習，彌補學生課本知識的不足。

（4）充分利用和開放實訓中心，將教學與實訓合一，將理論與實踐合一，滿足學生綜合能力培養的要求。

（5）積極利用電子書籍、電子期刊、數字圖書館、校園網、各大網站等網絡資源，使教學內容從單一化向多元化轉變，通過企業技術人員的指導，課程教師的輔導，使學生知識和能力的拓展成為可能。

4.課程的實施效果

（1）基于項目化的授課內容

建立軟件外包中心，引入企業項目內容，軟件測試的授課內容緊緊圍繞企業項目的典型工作任務開展，學生的能力與素質參照軟件測試工程師的崗位要求，讓學生真實感受企業環境，就業零距離上崗。

（2）基于過程化的授課方式

老師授課不再單純地講解理論，完全按照企業的軟件測試流程開展，制定規范的軟件測試計劃、編寫測試用例、利用測試工具測試、編制測試報告，有利于學生養成職業化的學習習慣與工作習慣。

（3）基于理論實踐一體化的教學設備

學生在軟件外包中心上課以及實驗，真正實現了“做中學，學中做”的企業工作環境。

（4）基于能力化的學習評價

學生的評價不再單純地以理論考試為依據，而是從學生的軟件測試專業能力、利用軟件測試工具的能力、團隊溝通協調能力進行綜合地評價。

參考文獻

[1]鄭泳.基于工作過程系統化的高職《軟件測試》課程設計[J].漯河職業技術學院學院，2010（9）.

[2]程茂，溫靜，吳玉潔.《軟件測試》課程的教學研究[J].河北師范大學學報，2010（4）.