時間：2023-06-01 09:46:31
開篇：寫作不僅是一種記錄，更是一種創造，它讓我們能夠捕捉那些稍縱即逝的靈感，將它們永久地定格在紙上。下面是小編精心整理的12篇單元測試方法，希望這些內容能成為您創作過程中的良師益友，陪伴您不斷探索和進步。
關鍵詞關鍵詞：軟件工程；軟件質量；單元測試；測試框架；面向對向程序
中圖分類號：TP302 文獻標識碼：A 文章編號文章編號：16727800（2013）008004503
0 引言
隨著現代軟件工程的不斷發展，人們對軟件質量和生產力的要求越來越高。軟件測試技術和框架復用技術作為提高軟件質量和生產力的有效手段，近年來倍受人們的重視。
傳統的“黑盒”、“白盒”測試技術主要應用于面向過程的程序設計中。隨著面向對象技術的發展，這種技術已不能滿足軟件測試的需要。自動化單元測試框架應用于面向對象單元測試中，通過它來實現單元測試自動化。
單元測試是對軟件進行正確性檢驗的測試工作，是軟件設計的最小單位。單元測試的目的主要是發現每個程序模塊內部可能存在的錯誤。程序員的基本職責是單元測試，單元測試能力是程序員基本能力的體現，程序員必須對自己所編寫的代碼認真負責，軟件的質量與程序員的工作效率直接受程序員單元測試能力高低的影響。
單元測試是一項很重要而且必要的工作。在實際工作中，許多程序員并不愿意對自己編寫的代碼進行測試。軟件開發的工作壓力大，大多數程序員們因為沒有時間測試自己的代碼，使程序的代碼質量得不到保證，有些代碼還需重新編寫，程序員根本沒有時間對代碼進行測試。自動化單元測試框架能夠從根本上解決這個問題，它可以使測試工作變得簡單，這樣更有助于程序員進行代碼開發工作。
1 自動化單元測試框架設計目標
自動化單元測試框架的設計應達到以下目標：首先，框架簡單，可以使測試程序的編寫更簡化。框架使用常見的工具設計，測試工作操作簡單；其次，測試框架應能夠使除作者以外的其他程序員進行代碼測試，并能解釋其結果，即將不同程序員的測試結合起來，且不發生相互沖突。最后，測試用例可以復用，可以以現有的測試為起點形成新的測試。
本文將以這些目標為指導，討論如何用以Kent Beck和Ralph Johnson提出的“模式產生體系結構”的方式來設計框架系統。自動化單元測試框架的設計思想是從0開始根據設計問題應用設計模式，一個接一個逐步設計，直至獲得最終合適的系統架構。其中實現部分采用Java語言來實現，并會使用UML圖來表示各種類及類間關系。
2 面向對象自動化單元測試分析
自動化測試定義為：管理與實施各種測試活動，包括開發測試腳本、執行測試腳本，這樣使驗證測試需求更加方便，通過這些腳本實現了自動測試，可以把它稱為自動測量工具。使用這種自動測試工具對增量軟件集成測試提供了巨大的方便，增加了巨大的價值。每一個新的構件可以重用先前開發的測試腳本，即使需求和軟件有變更，作為一個重要的控制機制，自動測試也能夠確保每一次重新構建的穩定性與準確性。
3 面向對象自動化單元測試框架
自動化測試框架實質是一種自動測試工具，單元測試的核心問題是實現測試自動化。一個完整的自動化測試過程通常包括5個測試活動，分別是測試標識、測試設計、測試實現、測試執行與評估。測試用例針對被測試系統的各項功能準確地開發與設計，而且每一個測試用例都要按順序執行這5個測試開發活動，測試開發活動如圖1所示。
圖1 測試活動
測試標識與測試設計這兩個測試活動主要為智力活動，分別標識測試條件和設計測試用例。測試執行與測試比較這兩個活動屬于比較機械的活動，它們的功能分別為：執行測試用例、將測試輸出結果并與期望輸出結果值相比較。前兩個活動決定了測試用例的質量，后兩個活動適合自動化。在單元測試中，測試執行和測試比較這兩個活動要重復多次，測試標識與測試設計通常只執行一次。因此，在單元測試過程中，重復性的活動特別需要自動化執行。
4 自動化單元測試設計與實現
首先構建對象來表達基本概念：Test Case（測試用例），然后將對象發送到測試框架，再由測試框架執行，最后報告測試結果。
采用Command命令模式將一個請求封裝成一個對象，Command模式可以為每一個操作生成一個與之對應的對象，同時能夠給出一個對應的執行方法。這樣可以對多個用戶請求進行排隊，也可以將多個請求記錄到日志，并使用不同的請求對客戶進行參數化。具體實現方法如下：
其中的run（）方法為模式中的執行方法，可以通過繼承來重用該類，為了便于在測試失敗時能夠識別出失敗的測試，每一個Test Case在創建時都要給出與之對應的名稱，這樣即可判斷出失敗的測試。
圖1展示了測試框架組成部分的快照，也展示了應用于TestCase中的標記。
圖1 測試框架組成部分
5 單元測試用例執行流程
在實際測試過程中，構造參數或資源、測試、釋放資源為測試的業務邏輯過程。例如，在測試數據庫的插入、更新、刪除、查詢等操作時，首先要對數據庫進行連接，然后測試，最后釋放連接。這樣，在一個Test Case中有多個測試，需要反復書寫代碼，這增加了測試人員的工作量，不符合設計目標。
建立測試支架即為所有的測試建立一個共同的結構，可以解決以上問題，初始化代碼、測試代碼和釋放資源的代碼均放在測試支架上，每次運行測試代碼之前，首先都運行初始化代碼，最后運行釋放資源代碼。這樣，每一個測試都會和與之對應的支架一起運行，而且測試結果互不影響，每一個結果都不會影響其它的測試結果。這樣便實現了代碼的復用，大大提高了軟件單元測試的工作效率。
以上通過模板方法實現，模板方法的Template Method靜態結構如圖3所示。
其中，setUp方法初始化測試信息，如數據庫的連接，cleanUp方法的功能是測試結束后釋放資源。runTest方法的功能是進行測試業務邏輯。TestCase的方法的功能為進行測試邏輯框架的設計，run為模板方法。在這里，setUp和cleanUp可以被用來重寫，由框架來進行調用。
6 測試結果收集
創建對象TestResult來收集運行的測試結果，實現代碼如下：
UTF使軟件開發者們更愿意接受測試代碼的工作。有種種好處：UIT使測試用例的實現簡單、一致且模塊化；測試實現與執行的特性支持迭代、增量開發；重新運行測試包的便利使高頻率的回歸測試成為可能；同時它還能保證單元測試的持久性。此外，單元測試框架UTF也是可擴展的，例如，利用Decorator模式，可以不斷向UTF添加新的功能；TestResult類也是框架的一個擴展點。客戶能夠自定義它們的TestResult類，例如， HTMLTestResult可將結果上報為一個HTML文檔等。
參考文獻參考文獻：
[1] （美）普雷斯曼.軟件工程：實踐者的研究方法[M].北京：機械工業出版社，2011.
[2] （美）麥格雷戈.面向對象的軟件測試[M].北京：機械工業出版社，2002.
關鍵詞：Testbed/Tbrun；軟件單元測試；嵌入式軟件
中圖分類號：TP311 文獻標識碼：A 文章編號：1009-2374（2013）18-0027-02
嵌入式軟件作為嵌入式系統的重要組成部分，嵌入式軟件質量問題可能會帶來設備的損壞和人員的傷亡，因而用戶對其質量有較高的要求。軟件測試是對軟件質量檢驗的一個非常重要的手段。而軟件測試中動態測試最基礎的測試就是單元測試。如何開展單元測試以及如何提高單元測試的效率是一個值得研究的問題。
1 軟件單元測試的要求及重點
軟件單元測試是對軟件基本組成單元進行測試，測試軟件單元是否正確地實現規定的功能，是否滿足軟件性能和接口要求。并驗證程序與詳細設計說明的一致性。因此在單元測試時，需要模擬被測單元與其他模塊之間的交互，開發驅動模塊和樁模塊兩種輔助模塊，構建一個可執行的環境，驅動模塊用于模擬被測單元的上層模塊，測試執行時由驅動模塊調用被測單元使其運行；樁模塊用于模擬被測單元在執行過程中所調用的模塊。
單元測試重點考慮的測試類型有：（1） 接口測試。接口測試主要檢查實參與形參的數目是否相等、實參與形參的屬性是否匹配、實參與形參的單位是否一致、傳到被調用模塊的實參的屬性是否與形參的屬性匹配、是否把常量當作變量傳遞等內容。（2）功能測試。功能測試主要是對照軟件單元的設計說明，驗證軟件是否完成了所需的功能。（3）重要執行路徑測試。應設計測試用例以發現錯誤的計算、不正確的比較和不正常的控制流向等錯誤。在計算中比較常見的錯誤是：誤解或錯誤處理算術運算的優先次序、混用不同類的操作、計算精度不夠等。另外在控制軟件執行流程的比較操作中比較常見的錯誤有：不同數據類型的比較、不正確的邏輯操作符或不正確的優先次序、因精度不夠使本應相等的數不相等（如浮點數）等。（4）軟件單元的局部數據結構測試。軟件單元的局部數據結構是一個主要的錯誤來源，應設計測試用例來發現不正確的或不一致的數據說明、初始化有錯或沒有賦初值、不正確的變量名、不一致的數據類型、上溢/下溢或引用錯誤等類型的錯誤。（5）錯誤處理路徑測試。一般軟件錯誤處理路徑測試應考慮下面幾種可能的錯誤：對錯誤的描述不易理解、指出的錯誤并不是所遇到的錯誤、出錯時還沒有進行出錯處理就先進行系統干預、錯誤邊界條件的處理不正確、描述錯誤的信息不正確從而不足以確定出錯的原因等。（6）邊界測試。邊界測試是檢測軟件在其輸入/輸出域、過程參數、狀態轉換、功能界限等具有一定范圍的邊界或端點條件下的運行情況，考核軟件的功能或性能在其邊界條件下或邊界的鄰近區域內是否依然滿足設計要求。按照上去要求進行單元測試時，為達到要求的覆蓋條件，還需采取一定的技術手段對測試覆蓋率進行記錄和分析，確保達到相應的覆蓋率指標。采用TBrun單元級測試工具，能自動產生軟件測試驅動、樁模塊，提供友好的輸入輸出人機交互和覆蓋率統計功能，能有效提高單元測試的測試效率。
2 Testbed在單元測試中的應用
使用 Testbed/TBrun的基本方法是：設計測試用例；在Testbed/TBrun中加載被測單元文件，通過Testbed/TBrun對被測軟件進行源程序自動插裝；根據測試用例設定輸入和預期的輸出，執行插裝好的源程序單元；分析輸入數據、預期輸出和實際輸出；得到被測軟件在當前的測試用例執行過程中代碼的覆蓋率。需要注意的是，每執行一個測試用例就需要重新編譯并執行。Testbed/TBrun的覆蓋率統計只具有累加的功能，因此不能查詢每一測試用例執行后的覆蓋率信息。在執行完所有的測試用例后會生成一個總的覆蓋率文件，Testbed/TBrun通過對覆蓋率文件的分析得出軟件單元相應語句的覆蓋情況，根據這些覆蓋情況可以較快確定冗余的測試數據并增補遺漏的測試數據，從而指導新的測試用例設計。在實際應用Testbed單元測試時，需注意以下三個方面：（1）數組和指針類型的變量的輸入。數組可以通過在Testbed/TBrun插裝后的源代碼中插入數組的初始化語句對數組賦值或者在 Testbed/TBrun 環境中對數
組的一部分賦值。因指針不能被直接賦一個地址，所以輸入指針可采用映射的方式來賦值，將指針變量映射成相應的自定義變量，然后對自定義變量賦值。在測試執行的過程中，這個自定義變量的值就是指針的輸入值。（2）被測單元代碼的必要修改。在實際的測試過程中，有的代碼單元不能直接使用Testbed/TBrun直接執行測試。須在分析之前對代碼單元做少量修改。如Testbed/TBrun 插裝源代碼時會生成 main（）函數，因此被測單元中的 main（）函數要改為其他的名稱以避免造成名字沖突；Testbed/TBrun 執行分析時會執行被測單元，因此被測單元中的 while（1）之類的死循環結構要去掉，否則分析將無法結束。（3）模塊測試后顯示最終整體覆蓋率，不能查詢每一測試用例執行后的覆蓋率信息。
3 結語
Testbed有效地支持了測試人員的測試工作，相對于完全人工測試提高了測試效率。該工具仍存在不足，還需在實踐中不斷完善使用方法。
參考文獻
功能測試主要通過單元測試和集成測試來完成系統的功能測試。單元測試的目的是測試源碼中最小單元的代碼是否正確處理它該處理的任務。單元測試重點測試了代碼中分支比較多的地方，以驗證程序是否能根據條件執行相應的分支；并重點測試了代碼對于異常情況的處理，以驗證代碼是否能對于發生的異常情況進行相應的處理；再就是對源碼中與數據庫相關的代碼和涉及用戶輸入輸出的代碼進行了重點測試。集成測試是在單元測試的基礎上，將已經通過單元測試的軟件單元組合起來，組成可以執行的功能單元，然后進行測試。通過測試的子功能單元再通過組合，組成更大一級的功能模塊進行測試。集成測試重點測試軟件單元的組合能否正常工作，模塊之間的組合能否集成起來工作，還要測試構成系統的所有模塊組合能否正常工作。集成測試主要有三種測試方案：自底向上進行測試，自頂向下進行測試，以及自底向上和自頂向下結合的方式進行測試。自底向上的集成測試方式是最常使用的方法，這種方式從程序模塊結構中最底層的單元模塊開始組裝和測試。自頂向下的集成測試方式正好與自底向上的方式相反，需要編寫樁模塊以支撐上層的測試。最理想的方案是能將這兩種集成方式結合起來，這樣在早期的時候，既能發現重大的問題，又能及早展開人力。但是這種方式實施起來有難度，需要軟件開發者一開始要做好合理的策劃和設計。由于系統在需求和設計階段做的工作比較扎實，本系統主要采用了自底向上的集成測試方式：先把最底層的軟件單元組合，組成高一級的功能單元進行測試；測試通過的功能單元再進行組合，組成更高一級的模塊單元，并對模塊單元進行測試；最后，模塊單元再集成到系統中進行測試。測試重點集中在各單元與各單元之間的接口和信息交互。
2.用戶界面測試
通過用戶界面測試來驗證用戶與系統的交互情況。界面測試的目標是確保系統向用戶提供適當的訪問和瀏覽被測對象功能的操作。測試方法，為每個窗口創建或修改測試，以核實各個應用程序窗口和對象都可正確進行瀏覽，并處于正常狀態。完成標準，證實各個窗口與基準版本保持一致，或符合接受標準；需考慮的特殊事項，并不是所有定制或第三方對象的特征都可訪問。
3.性能測試
性能測試采用了主觀評測和軟件評測相結合的方法，先部署上系統，在環保局內部試運行，通過工作人員的使用來了解系統的反應速度是否滿足客戶的需求。系統的性能需求主要是對系統web訪問的response時間和系統負載能力的要求。在性能測試過程中，我們利用Loadrunner模擬用戶向系統發送請求，并監控系統的CPU,Memory等參數。
4.安全性測試
本系統采用先登錄，后操作的方式。因此，必須測試有效和無效的用戶名和密碼，并注意到是否大小寫敏感。本系統是有超時的限制，也就是說，用戶登錄后在一定時間內（20分鐘）沒有點擊任何頁面，需要重新登錄才能正常使用。所以，也必須對其進行測試。
5.測試結果
功能測試結果：滿足環保局功能需求，與需求不相符或者后增加的功能，將在后續版本中加入，本版將不做修改。
【關鍵詞】軟件測試 白盒 黑盒 單元測試 組裝測試 確認測試 系統測試
一、軟件測試的常用方法
軟件測試就是在軟件投入運行前，對軟件需求分析、設計規格說明和編碼的最終復審，是軟件開發過程的重要組成部分，是軟件質量保證的關鍵步驟。采用面向對象技術進行軟件開發產生了兩個結果：一是開發出功能更強大更便于用戶使用的軟件產品，二是生成規模龐大的程序代碼和文檔，這也必然導致更大規模的軟件測試和維護工作。因此，規范化的軟件測試勢在必行。規范化不只是測試的需求（有效代碼量、結構/邏輯的復雜性、高性能/高精確性/高可靠性需求）和消耗資源（人力/時間/測試頻度）規模化，更要求在面對規模龐大的軟件測試需求，在合理的資源消耗基礎上，實施有效的測試。
1.人工測試的方法
（1）個人復查。個人復查是指程序員自行設計測試用例，對源代碼、詳細設計進行仔細檢查，并記錄錯誤、不足之處等。個人復查主要包括檢查變量的正確性、檢查標號的正確性、檢查子程序、宏、函數、常量檢查、標準檢查、風格檢查、比較控制流、選擇、激活路徑、對照詳細說明書，閱讀源代碼和補充文檔等方面的測試內容。
（2）走查。走查是指測試人員先閱讀相應的文檔和源代碼，然后人工將測試數據輸入被測試程序，并在紙上跟蹤監視程序的執行情況，人工沿著程序的邏輯走查運行一遍，跟蹤走查運行的進程來發現程序的錯誤。走查的具體測試內容包括模塊特性、模塊接口、模塊的對外輸入或輸出、局部數據結構、數據計算錯誤、控制流錯誤、處理出錯和邊界測試等方面。
（3）會審。會審是指測試人員在會審前仔細閱讀軟件的有關資料，根據錯誤類型清單（根據以往的經驗、對源程序的估計等，并在以后測試中給以豐富補充）填寫檢測表，提出根據錯誤類型要提出的問題。會審時，由程序設計人員講解程序的設計方法，由程序編寫人員逐個講解程序代碼的編寫，測試人員需要逐個審查，提問，討論可能出現的問題。會審對程序的功能、結構、邏輯和風格都要進行審定。會審的測試內容與“走查”的內容相同。
2.機器測試
（1）定義。機器測試的目的是檢查程序的動態性能，檢查程序在執行過程中存在的錯誤。尤其是發現程序在實現功能、邏輯通路、數值計算、數據處理、邊界處理、錯誤處理等方面存在的錯誤。機器測試分為白盒測試和黑盒測試。
（2）黑盒測試。黑盒測試即功能測試，這種方法是把軟件看成一個看不見里面內容的黑盒，在完全不考慮程序內部結構和特性的情況下，測試軟件的外部特性。根據軟件的需求規格說明書設計測試用例，從程序輸入和輸出特性上檢查程序是否滿足設定的功能。黑盒測試常采用的方法是設計適量有效和無效的輸入數據進行測試，以期用最小的代價發現最多的錯誤。
（3）白盒測試。白盒也稱結構測試，這是將軟件看成一個透明的白盒子，按照程序的內部結構和處理邏輯來選定測試用例，對軟件的邏輯路徑及過程進行測試，檢查它與設計是否相符。
二、軟件測試的流程
軟件測試雖然是一個獨立的階段，但在實際工作中，測試的流程主要包含單元測試、組裝測試、確認測試等階段。
1.單元測試。單元測試也叫模塊測試，單元指清晰定義了子功能的最小單位，如程序的最小編譯單位等，是測試工作的第一步，通常單元測試需要編寫樁程序及耙程序。單元測試是要保證每個獨立的模塊完成清晰定義的子功能，發現編碼和詳細設計的錯誤。它將整個系統分解，減少測試復雜度，在模塊范圍定位錯誤的位置，并且可以多個模塊并行測試。測試可以由編碼人員也可以由測試人員來完成。測試方法以白盒測試為主，輔以必要的黑盒測試。測試內容包括模塊接口、模塊內部數據結構、邏輯通路、邊界值、出錯處理等。
2.組裝測試。組裝測試也叫綜合測試、集成測試、聯合測試，它是在單元測試之后需要按照設計時做出的層次模塊圖把測試模塊連接起來，進行組裝測試。測試目的是檢查能夠獨立實現子功能的單元模塊能否在組裝過程中逐級實現組合起來的主功能。測試人員由編碼人員和測試人員共同進行。測試方法是黑盒測試。組裝測試的策略分為非增式測試和增式測試，增式測試又分為自頂向下、自底向上和混合式三種。
3.確認測試。確認測試也叫合格性測試、驗收測試，經過組裝測試后，所有模塊已連接成為一體，確認測試是將整個軟件作為測試對象，進一步檢查軟件是否符合需求規格說明書的要求。確認測試的目的是檢查系統是否能夠按預定要求工作。確認測試主要由測試人員完成。確認測試要進行以下幾方面的內容：在模擬的環境下，運用黑盒測試的方法，驗證測試可包括功能測試、可移植性、兼容性、錯誤恢復能力、可維護性等性能測試。有些確認測試還將軟件配置審查，α測試，β測試也包含進來。
三、結束語
在現實生活中，業界人員所熱衷追求的往往是高效的軟件開發技能，而高效的軟件測試技能卻相對為人們所冷落。在當今的大學，計算機專業均沒有開設任何軟件測試方面的課程，每年畢業進入業界的學生，幾乎全無軟件測試方面的知識，軟件測試的培訓與教育并無法滿足當今IT產業的需求。隨著敏捷開發方法等新一代軟件工程概念的風靡，軟件編碼和測試過程多次迭代，測試人員更積極地參與到軟件生命周期的各個階段中，使得整個項目團隊收取事半功倍的成效。編碼和測試人員越來越緊密地協同工作，優秀的程序必然需要了解測試的方法和概念，優秀的測試人員所具備的技能也不再是僅僅是對現成的程序進行直觀的功能測試，軟件測試的涵義和策略日益復雜，軟件質量風險控制涉及到愈來愈多的方面。
參考文獻：
[1]《淺析軟件測試技術現狀》 李靜 郭曉磊 《光盤技術》2009年第5期
[2]《軟件測試：跨越整個軟件開發生命周期》 （美國）愛弗里特 （Everett G.D.） （美國）Raymond MCleod 譯者：郭耀 清華大學出版社
關鍵詞:分類;規則;面向對象;繼承;封裝;多態
中圖分類號:TP311文獻標識碼:A文章編號:1009-3044(2010)08-2010-02
The Study of Object Oriented of the Unit Test Based on Rule
ZHANG Ke-hong
(School of Statistics, Lanzhou Commercial College, Lanzhou 730030, China)
Abstract: The Object Oriented of the unit test depend on rule,which is required and analysed by the software system of Testing case. The traditional unit tests analysis the internal logic structure of programs, but The Object Oriented's unit test I am talking about stress the tests of the inherit, encapsulation and diversity of the class in Object Oriented development besides the function of the ones.This document depends on Data Mining of rule classification.
Key words: classification; rule; object oriented; inherit; encapsulation diversity
面向對象的測試技術是面向對象開發的重要一環,也是軟件質量和成熟度的保證。單元測試的指導思想是:能自生編譯運行的最小程序單元[4]。這一理論對面向對象開發的軟件也是適用的,但它的不足是沒有明確在面向對象的測試中把方法還是把類看作單元,如果把方法看作單元會給以類為單元的面向對象的開發和測試帶來混亂,所以在軟件系統測試用例庫的單元測試中以類為單元進行測試。
數據挖掘是指在數據中發現有效的、新穎的、潛在有用的、最終可理解的模式。為了從大量數據的低層數據中抽取高層知識,數據挖掘利用其他學科知識:機器學習、模式識別、數據庫、統計理論、人工智能、專家系統中的知識獲取、數據可視化,高性能計算等[9]。基于規則的分類是數據挖掘的分類方法中比較有效的一種技術,它是適用于從少量信息和知識中獲取有用的信息,它的這一特點也可以在以類為單元進行測試中得到應用,也是對軟件測試技術的改進。
1 軟件系統測試用例庫介紹
軟件測試項目的管理活動包含測度、度量、估算、風險分析、進度安排、跟蹤和控制[6]等,而軟件測試項目管理的基本內容是計劃、組織和監控,從另一個角度來說它有八個工作領域,即測試范圍管理、時間管理、成本管理、質量管理、人力資源管理、溝通管理、風險管理和過程管理[10]。
軟件系統的開發工作有很大的工作量,軟件測試的工作占有很大的比重,因為軟件測試工作存在于軟件系統測試用例庫軟件開發的各個階段,所以軟件測試項目的管理活動也不是鎖定在那一個階段,而是存在于需求分析、概要設計、詳細設計、編碼階段、安裝與維護的各個階段[3]。
在軟件系統每一個測試階段,需要設計與之相關的測試用例,而測試用例設計和執行是軟件系統測試工作的核心,直接關系到測試的效率、結果,也是工作量最大的任務之一,同時BUG的管理一般由數據庫系統來支持,如果在軟件系統中沒有很好的測試管理系統也就不能提高測試的效率。軟件系統測試用例庫的建設也是基于上述目標,當然測試用例庫的建立有利于跟蹤和統計執行測試結果的報告 ,也有利于實現軟件系統測試用例的標準化、回歸測試和系統的質量分析。
軟件系統測試用例庫包括基本測試數據維護、測試信息查詢、安全、幫助、測試數據庫管理六個模塊,通過UML畫出軟件系統測試用例庫的用例圖1。
2 軟件系統測試用例庫單元測試中類測試的充分性
類測試充分性是面相對象中類測試的重要條件,也是質量的保障,我們在設計軟件系統測試用例庫單元測試用例的時候能不能保證對執行的語句每一條都考慮到,能不能找到程序中的每一個Bug,同時也要考慮到相反的問題,那就是在效率優先的前提下有沒有必要做到找出所有的Bug,也要考慮到類的繼承、多態、封裝等特點以及這些特點給測試帶來的在傳統測試中從沒遇到的新困難。為了有效地進行面向對象的單元測試就要考慮類測試的充分性,它有3個標準[6]:
1) 基于類的狀態轉換的充分性:類的狀態有很多,在設計測試用例的時候要考慮到要充分考慮了的狀態轉換,如果在測試用例中沒有體現出至少一次的狀態轉換,那就意味著測試是失敗的,同時也要說明就是測完所有的狀態也可能存在著Bug。
2) 基于限制的充分性:對每一個操作來說它都可能存在前置約束條件和后置約束條件。在設計測試用例時就要考慮到這些約束條件對操作的影響,特別是要注意約束條件出現的可能性。
3) 基于路徑的充分性:在設計測試用例時還要考慮基于路徑的測試是否完全,也就是說在測試用例都執行完時,程序中的每行代碼都盡可能執行一邊。但此時要強調測試的效率問題。
3 基于規則的單元測試技術研究
基于規則的分類法使用一組IF-THEN規則進行分類,其表達式為:IF 條件THEN 結論,規則的IF部分乘坐規則前件,THEN部分是規則的結論。條件是由一個或多個連接詞AND連接的屬性測試組成,規則的結論是包含一個類預測,如果給定的測試用例,其規則前件中的條件都成立,則規則前件被滿足,說明規則覆蓋該測試用例。一般規則的提取有決策樹和順序覆蓋算法,規則可以用覆蓋率和準確律來評價,其定義為[8]:
和
其中ncovers為規則覆蓋的測試用例數,ncorrect為規則正確分類的測試用例數,|D|為測試用例庫中D的測試用例數。
在設計軟件系統測試用例庫類的測試用例時,用基于規則的思想考慮路徑的測試是否完全,也就是說在測試用例都執行完時,程序中的每行代碼都盡可能執行一遍。但此時要強調測試的效率問題。例如:軟件系統測試用例庫的模糊查詢void CMainDialog::BlurTestSch(),主要是關鍵字KEY填寫和四個查詢類別的選擇,四個查詢類別是項目編號(XMBH)、優先級(FIRST)、是否通過(YN)、和時間(TIME),優先級又包括致命(D)、嚴重(S)、一般(U)、微小(M),用決策樹提取模糊查詢的規則如表1。
通過上述的規則,有關軟件系統測試用例庫的模糊查詢void CMainDialog::BlurTestSch()
的測試通過void CMainDialog::OnTest()實現,其主要步驟如下:
void CMainDialog::OnTest()
{
CTestingSet m_testingset;//定義CTestingSet類的對象
…
if(!m_input.IsEmpty())
{
if(pare("項目編號")==0)
{
CMainDialog::BlurTestSch();
MessageBox("選擇項目編號關鍵字成功!");
}
if(pare("優先級")==0)
{
CMainDialog::BlurTestSch());
MessageBox("選擇優先級關鍵字成功!");
}
if(pare("是否通過")==0)
{
CMainDialog::BlurTestSch();
MessageBox("選擇是否通過關鍵字成功!");
}
if(pare("時間")==0)
{
CMainDialog::BlurTestSch();
MessageBox("選擇時間關鍵字成功!");
} }
else
{CMainDialog::BlurTestSch();
MessageBox("請填寫查詢關鍵字成功!");
} }
通過測試程序的運行,我們發現通過基于規則的分類方法設計的測試用例是非常有效的,例如在本次測試中設計測試數據集D=10,其中規則2時人為設計的錯誤的規則,主要用于XMBH為空的測試。
它們的覆蓋率為:ncovers(1)=…= ncovers(9)=1/9。(下轉第2021頁)
(上接第2011頁)
它們的正確率有區別,主要是規則2覆蓋兩個測試用例,它的正確率 ncorrec(2)=1/2,其余的正確率是 ncorrec(1)=1/1,ncorrec(3)=…= ncorrec(9)=1/1。
從這些數據說明基于規則的分類方法使面向對象的測試的效率方面有很大的提高,這也是對軟件測試技術中白盒測試的比較有意義的探索,也是數據挖掘的方法和軟件測試技術有益的嘗試,從而促進軟件測試技術的發展。
4 結束語
從軟件的生存周期看,單元測試是指在程序文檔結束以后進行的測試,它在測試技術中主要是白盒測試,也就是說它是針對程序的邏輯結構進行的測試。從另一方面來說面向對象的開發技術下的面向對象的測試也是和傳統意義的測試有很多的不同點,尤其是面向對象類的繼承、封裝、和多態給測試造成了很大的困難,所以在本文中結合數據挖掘中的基于規則的分類技術這些特征的設計。又因為不管是傳統意義的測試還是面向對象的測試,設計測試的依據是軟件系統測試用例庫規格說明書、軟件系統測試用例庫設計文檔和軟件系統測試用例庫使用說明書,如果是設計文檔錯誤,不管哪種測試軟件質量就難以保證,當然測試的設計也就沒有保障。即使測試以后發現是設計的錯誤,這時修改的代價是相當昂貴的。因此,較理想的做法是深入了解軟件的特點,按軟件工程各階段形成的文檔,分別進行嚴格的審查和測試。總之應通過各種方法和新技術提高測試效率和軟件系統測試用例庫的健壯性、正確性和有效性!
參考文獻:
[1] 郭寧.UML及建模[M].北京:清華大學出版社,2007.
[2] 國剛,周峰,孫更新.UML與Rational Rose 2003 軟件工程統一建模原理與實踐教程[M].北京:北京電子工業出版社,2007.
[3] Fenton N E,Pfleeger S L.軟件度量[M].2版.北京:機械工業出版社,2004.
[4] Jorgensen P C.軟件測試[M].2版.北京:機械工業出版社,2003.
[5] Priestley M.面向對象設計UML實踐[M].2版.北京:清華大學出版社,2005.
[6] 古樂,史九林.軟件測試技術概論[M].北京:清華大學出版社,2004.
[7] 宮云戰.軟件測試[M].北京:國防工業出版社,2006.
[8] Han Jiawei,Kamber M.數據挖掘的概念與技術[M].北京:機械工業出版社,2008.
關鍵詞：軟件；測試；設計；技術
中圖分類號：TP311.52文獻標識碼 A 文章編號：1009-3044(2007)17-31323-02
Technique of Software Test and Design
GUO Qun
(Liaoning University of Intemational Business and Economics,Dalian 116024,China)
Abstract:Software test, the straightforward and rapid way to improve the quality of software, is the necessary condition for the improvement of the software quality. This paper, introducing the common concept, method and step of the software test, gives the solution to the software test.
Key words:software; test; design; technique
1 引言
在大型軟件開發過程中，人們使用了許多保證軟件質量的方法分析、設計和實現軟件。但由干問題的復雜性，人們對客觀事物認識的局限性及軟件開發人員配合不協調等因素，因而在軟件開發過程中難免有各種各樣的錯誤。如果在軟件投入生產性運行之前，沒有發現并糾正軟件中的大部分錯誤，則這些錯誤遲早會在生產過程中暴露出來，那時不僅改正這些錯誤的代價更高，而且往往會造成很惡劣的后果。因此，一定要高度重視軟件測試工作。軟件測試是為了發現故障而執行程序的過程。其目的是以盡可能少的時間和人力發現并改正軟件中潛在的各種故障及缺陷。所以，在軟件投入運行之前必須進行軟件測試，以盡可能多地發現軟件中的故障，提高軟件可靠性。
2 軟件測試定義
軟件測試就是在軟件投入運行前，對軟件需求分析、設計規格說明和編碼的最終復審，是軟件質量保證的關鍵步驟。軟件測試是為了發現錯誤而執行程序的過程。或者說，軟件測試是根據軟件開發各階段的規格說明和程序的內部結構而精心設計一批測試用例（即輸入數據及其預期的輸出結果），并利用這些測試用例去運行程序，以發現程序錯誤的過程。正確認識軟件測試的定義是十分重要的，它決定了測試方案的設計。軟件測試只能查找程序中的錯誤；不能證明程序中沒有錯誤。
3 軟件測試方法
怎樣對軟件進行測試呢？有兩種方法。一種稱為黑盒測試：如果知道了產品應該具有的功能，可以通過測試來檢驗是否每個功能都能正確使用，也叫功能測試；它是在程序的接口進行的，把軟件看成是一個黑盒，測試時僅僅關心如何尋找出使程序不按要求運行的情況，是最基本的測試法。另一種稱為白盒測試：如果知道產品內部工作過程，可以通過測試來檢驗產品內部動作是否按照規格說明書的規定正常進行，也叫結構測試。它是把軟件看成裝在一個透明的白盒子里，就是完全了解程序的結構和處理過程，按照程序內部的邏輯測試程序，檢驗程序中的每條通路是否都能按規定要求正確工作。
4 軟件測試步驟
一個大型軟件系統通常由若干個子系統構成，每個子系統又由若干個模塊構成。軟件測試分以下幾個步驟：
（1）單元測試：又稱模塊測試，是針對軟件設計的最小單位――程序模塊，進行正確性檢驗的測試工作。其目的在于發現各模塊內部可能存在的各種差錯。單元測試需要從程序的內部結構出發設計測試用例。多個模塊可以平行的獨立進行單元測試。
（2）組裝測試：又稱集成測試，通常，在單元測試的基礎上，需要將所有模塊按照設計要求組裝成為系統。這時需要考慮的問題是：在把各個模塊連接起來時，穿越模塊接口的數據是否會丟失；一個模塊的功能是否會對另一個模塊的功能產生不利的影響；各個子功能組合起來，能否達到預期要求的父功能；全局數據結構是否有問題；單個模塊的誤差累積起來，是否會放大，從而達到不能接受的程度。
（3）確認測試：又稱有效性測試。它的任務是驗證軟件的功能和性能及其他特性是否與用戶的要求一致。首先要進行有效性測試以及軟件配置復審，然后進行驗收測試和安裝測試，在通過了專家鑒定之后，才能成為可交付的軟件。
（4）系統測試：是將通過確認測試的軟件，作為整個基于計算機系統的一個元素，與計算機硬件、外設、某些支持軟件、數據和人員等其他系統元素結合在一起，在實際運行（使用）環境下，對計算機系統進行一系列的組裝測試和確認測試。系統測試的目的在于通過與系統的需求定義作比較，發現軟件與系統定義不符合或與之矛盾的地方。
5 軟件測試的策略
測試過程按4個步驟進行，即單元測試、組裝（集成）測試、確認測試和系統測試。如圖1所示。
圖1 軟件測試的過程
開始是單元測試，集中對用原代碼實現的每一個程序單元進行測試，檢查各個程序模塊是否正確地實現了規定的功能。然后，把已測試過的模塊組裝起來，進行組裝測試，主要對與設計相關的軟件體系結構的構造進行測試。為此。在將一個一個實施了單元測試并確保無誤的程序模塊組裝成軟件系統的過程中，對正確性和程序結構等方面進行檢查。確認測試則是要檢查已實現的軟件是否滿足了需求規格說明中確定了的各種需求，以及軟件配置是否完全、正確。最后是系統測試，把已經經過確認的軟件納入實際運行環境中，與其他系統成分組合在一起進行測試。
6 結束語
軟件測試是保證軟件可靠性的主要手段，是軟件開發過程中最艱巨、最繁重的任務。軟件開發人員要明確軟件測試的目標，掌握軟件測試的方法、策略，選用最少量的高效測試數據，做到盡可能完善的測試，從而盡可能多地發現軟件中的問題。降低軟件測試的成本，提高軟件測試效率。開發出用戶滿意的高質量的軟件。
參考文獻：
[1]張海藩.軟件工程導輪[M].北京:清華大學出版社，1992.6.
[2]鄭人杰,等.實用軟件工程[M]. 北京:清華大學出版社，1997.4.
筆者在課堂教學中建立了一套激發學生學習興趣和發展學生能力的“六項全能”的形成性評價方法，并把這種評價方法和傳統的終結性評價方法結合起來對學生進行評價。這“六項全能”的評價方法包括課堂活動評價、單元聽寫評價、單元測試評價、課文背誦評價、完成作業評價和課堂紀律評價。
一、課堂活動評價
學生參與課堂活動是形成性評價的一個重要內容，課堂活動包括課前have a speech，free talk，在課堂教學過程中開展的group work，pair work，教學游戲，回答上節課所學知識點等活動。在課堂上采用小組評價法，把學生分成若干小組，以小組為單位開展討論，進行比賽。采用記分制，完成任務的加3分，答錯不加分。但是回答上節課所學知識點錯了就扣3分。如果是個人完成的給個人加分，如果是小組合作完成的就給小組加分。
二、單元聽寫評價
把聽寫和形成性評價方法結合起來使用，幫助學生調控自己的學習過程，使學生獲得成就感，培養合作精神。
課堂聽寫前教師讓學生自己在家先聽寫，可以家長報也可以自己寫出漢語再默寫。聽寫的內容是本單元的單詞、詞組、句子或是課外閱讀中的詞匯，由學生自己定。課堂聽寫采用記分制，達到100分的同學加10分，90分以上的加5分，沒達到90分的就算不合格，不合格的同學要找課代表重新聽寫。他們可以找本組組長尋求幫助，也可以找一幫一結的對子弄清楚沒寫會的內容。重新聽寫達到90以上的可以補加3分，基礎差的同學可以降低標準，達到60分即可加5分。對于重新聽寫合格的學生，教師應及時給予表揚鼓勵，幫助學生建立自信，激發積極學習情感。
三、單元測試評價
單元測試作為階段性的測試結果是形成性評價的一種形式。教師在完成每個單元的教學后，運用單元測試對學生進行評價。
以上一次期中或期末考試成績作為評價標準。120分試卷，108分以上的加15分，96分以上的加10分，跟上次比較有進步的同學再加五分。96分以下的同學，跟上次比有進步的加5分。
每次單元測試后，還要求學生進行自我評價，寫出試卷分析，對自己試卷的得失進行一個小結。引導學生進行單元測試后的自我評價，對于強化學生對單元重點、難點的掌握起著至關重要的作用。
四、課文背誦的評價
背誦典型的對話或者課文是學習英語、培養語感的一種重要途徑。通過背誦幫助學生掌握生詞，養成英語思維的習慣，有助于提高聽說能力，還可以幫助學生提高閱讀理解能力。
對于課文背誦的評價，可采取小組合作的方式進行評價。在班上選出8個英語背誦小組長，組長先在教師這背。組員找組長背，不會讀的先向組長請教。全班基本完成后再進行抽查，檢查和督促組長的工作。采用記分的方式，在規定時間背完的同學可以加5分，抽查過關的同學再加3分。對于英語基礎較差的學生，降低要求，讓他們看著課文的漢語背。無法看漢語背出的同學，只要求朗讀。
五、完成作業評價
德國教育家第斯多惠說過：“教學的藝術不在于傳授本領，而在于激勵，喚醒和鼓舞。”對于完成作業的評價，筆者主要是通過口頭表揚并加分的方式。
對于按時交作業，并且書寫認真，正確率高的學生及時給予肯定，并加5分；對于沒按時交作業的學生扣5分。收作業的事情讓小組長參與，培養他們的責任心。
六、課堂紀律評價
形成性評價要求積極有效的課堂環境，而這與學生良好的紀律有著緊密聯系，有時課堂氣氛活躍，但課堂紀律卻難以控制，因此對課堂紀律評價尤為重要。
對于課堂紀律評價采取記分制，違反紀律一次扣10分。一個月內紀律扣分最多的同學會告知家長共同管理該生。課堂紀律評價不僅要成為約束學生的一種方式，也要成為服務課堂的工具，使其成為提高課堂效率的一種有效手段。
對于“六項全能”的評價方法，每個單元進行一次統計，由兩名英語課代表分工記載和統計“六項全能”評價的分數。總分排前15名的學生評為優秀學生，再選出10名有進步的學生。在班級表揚欄公布，并且在家長QQ群中表揚信息。每個月進行一次小結，給總分排名前15名的學生頒發小小獎勵。
關鍵詞：數學 教學步驟 認知結構 參照系
中圖分類號：G623.5 文獻標識碼：A 文章編號：1673-9795（2014）02（c）-0102-01
根據每個單元的知識結構，從小學生的心理特點和認知結構出發，由教師確定每個單元的教學目標，并找準該單元的知識重點，難點及關鍵，然后根據學生的認知水平，組織有效的課堂教學活動，完成重點、難點及關鍵的教學，教給學生學習的方法。
1 確定教學目標，把握教學內容
制定單元教學目標，實際上是為單元教學定方向。方向能否定得正確，關鍵在于能否根據數學的學科特點，正確處理好整體與部分，知識與能力的關系，使所定目標切實具有科學性、準確性和可測性。一旦所定目標具有上述“三性”，就能真正成為教師組織教學活動，判斷教學效果，調控教學過程的出發點和參照系。這樣目標備課，教學就會因方向明確而少走彎路。
2 抓關鍵、教給學生方法
首先弄清該單元所涉及的知識在新與舊、難與易，相互制約方面有哪些聯系，找準其中起關鍵作用的知識。其次在認真研究這一關鍵知識與哪些舊知識有密切聯系的基礎上，拿出3～5分鐘做好對舊知識的復習。一旦確認學生已經具備了學習新知識的認知前提，就要把重點、難點知識的教學放到中心位置，采用適合兒童智力活動規律的教學方法組織各種形式的教學活動，甚至使絕大多數學生對這一知識達到充分地理解，較好地掌握。
顯而易見，抓關鍵，主要包括兩層意思：一是研究教材的知識結構，找準在整個單元教學中能牽一發而動全局的重點、難點知識的教學，使學生切實掌握學習本單元的方法。
例如：北師大版小學數學四年級下冊，第二單元認識圖形中，教學重點：認識直角三角形，銳角三角形，等腰三角形和等邊三角形等，三角形的內角和等于180°，三角形任意兩邊的和大于第三邊。難點是：三角形內角和的探索，三角形任意兩邊的和大于第三邊的探索。
讓學生體會先“量一量，算一算”產生猜想，再“拼一拼，折一折”進行驗證的數學思想方法，體會通過操作獲得一些數據，并整理分析數據，從中歸納出結論。
3 抓自學，讓學生自己解答
自學，是學生在教師輔導下的學習。
由于學生在第二步的單元教學中，已經初步掌握了學習該單元的方法，因而進入第三步后，教師的主要任務就變成了有計劃，有目的地深入到學生的自學中去，認真觀察學生是怎樣運用已掌握的方法去解答數學題的。及時發現學生在解答過程中存在的問題，并根據反饋情況進行及時恰當的輔導。
學生自學時，往往會出現這樣一種現象：他們原以為已經掌握了重點、難點知識。在自學時，又會遇到若干意想不到的困難和障礙，暴露出個別學生對方法并未真正掌握。這就需要教師有的放矢地采取得力措施，組織學生再學習、再思考。在這個反復的、曲折的思維過程中，教師的輔導是舉足輕重的。因為恰當的啟發、點撥，可以指導學生及時走出迷谷，避免浪費時間，保證學生在課堂上做更多的題，從而培養學生運用關鍵知識解決實際問題的能力，達到熟能生巧，運用自如。
4 抓練習，讓學生舉一反三
學生通過自學，初步掌握了該單元的知識，但要培養學生思維的靈活性和深刻性，還要通過抓練習，讓學生多層次，多角度，多形式地練習，做到舉一反三。這種練習可分為三類：
（1）基本題。即與課本例題相似，且難度基本相同的單項練習題目。進行這種練習，目的是讓學生進一步鞏固和熟練單元的基礎知識，切實完成識記與理解這兩個層次的學習任務。
（2）變式題。源于例題，但形式與例題不盡相同，而解法與基本題又大致一樣的練習題。練習此類題目，可以深化本單元所學的知識，逐步使學生形成技能技巧，有利于培養學生的分析，判斷能力。
例如：第五單元小數除法練習四第10題。
10：哪種食用油便宜些？
第一種：每瓶2.5千克 花35.00元
依據：單價=總價÷數量
35÷2.5=14（元）
第二種：有兩瓶油
大瓶3千克 小瓶0.5千克
共需：48.30元
48.3÷（3+0.5）=13.8（元）
所以買第二種合算。
（3）綜合題。將本單元所學知識與有關知識混合編排而成的綜合型和智力型。做此類題，能培養學生解決實際問題的能力，使知識能靈活運用；能讓學生把本單元學到的知識與有關舊知識聯系起來，形成知識體系，標志著已完成綜合運用這一教學目標。
如：找座位（總復習）。
這道題綜合考察學生的小數加、減、乘、除計算的能力（見圖1）。
5 單元測試，及時評價學習情況
先根據單元教學目標，分類編制單元標準測試題，再于該單元學完之后，進行單元測試，以檢驗各層次教學目標的達成情況。編制可測性強的單元測試卷，是第五步驟的主要工作。在編制單元測試卷時，特別應注意以下三點：
（1）題型多樣。既有考察基礎知識的填充、判斷、選擇題，又有考察各種能力的計算題、操作題和應用題。
（2）覆蓋面廣。單元測試題能充分反映本單元教學目標的各個方面，有利于對學生的學習情況進行全面性診斷。
（3）呈階梯狀。既有與“識記、理解”相對應的基本題，又有與“簡單應用”相對應的綜合題，還有少量難度較大的能考查創新能力的思考題。
通過測試，可以從識記、理解、應用的不同層次上準確反饋出學生的學習情況。使教師能據此采取相應措施，及時進行矯正和補救，有的放矢地對學生進行重新講解和點撥，從而收到事半功倍的效果，使學生能扎實熟練地掌握并應用所學的知識。
參考文獻
[1] 張景中，曹培生.從數學教育到教育數學[M].中國少年兒童出版社，2011.
Abstract： With the increasing complexity of software engineering， software engineering quality requirements continue to improve. The teaching of the traditional software testing course can't meet the needs of the times. From the traditional software testing experimental teaching， aiming at the existing problems and the overall objectives of the experimental teaching requirements， this paper explores the significance of project driven software testing and experimental teaching reform， which with reasonable distribution of the curriculum system， the distribution of appropriate experimental content， can meet the requirements of personnel training program.
關鍵詞：軟件測試；項目驅動；實驗教學；教學改革
Key words： software testing；project driven；experimental teaching；teaching reform
中圖分類號：G642.0 文獻標識碼：A 文章編號：1006-4311（2017）03-0226-03
0 引言
軟件測試在很早以前就是軟件工程里的一個課程。但近幾年來才被國內的軟件行業及軟件公司所重視。因而出現需要大量軟件測試人員的需求。所以國內的很多高校因市場的需求，開設了相關的軟件測試專業或方向。但很多學校的開設的軟件測試的課程只停留在基本理論的學習，或者測試工具的介紹上，以至于畢業出來的學生只能滿足最底層的測試工作。而較高要求的測試崗位很難招到人。所以培養“高素質、復合型”的軟件測試人才，是學校的當務之急，軟件測試的教學改革勢在必行[1]。
1 傳統測試課程教學存在的問題
教學課時少，課程結構單一。傳統軟件測試是以軟件工程原理的一個章節來講的。講課的課時也就4個學分。老師授課只是對測試基本的概念及流程作講解，內容偏重理論且抽象。學生理解和掌握難度比較大，在實際測試工作中無法入手。現如今對軟件測試的工作越來越重視，對軟件測試的工作要求越來越高。如此單一教學內容，讓學生今后勝任軟件測試的相關工作是不現實的。
重理論，輕實踐。傳統軟件測試課程的教學一直以任課老師講授以主，學生被動接受知識，在理論的教學過程中，授課老師重點講解軟件測試的基本概念、原理及方法。但軟件測試的相關課程在實踐方面要求有較強的動手的實踐能力。如在講解黑盒測試、白盒測試中的測試方法來設計測試用例時，實際使用過程中需要結合多種方法來保證測試用例的完整性，這需要引入實際的生產案例來練習。再如在講解單元測試、集成測試時，在講解單一類的測試、容器內的測試、數據庫持久層的測試時，如果老師在授課時只是講理論，沒有引入實際的生產案例，學生很難體會到課程的挑戰和樂趣，缺少主觀主動性，學習效果較差。這樣的教學質量難以保證，學生很難學以致用。
2 項目驅動教學的內涵
“項目教學法”最早見于美國教育家凱茲和加拿大教育家查德合著的《項目教學法》。“項目教學法”的理論認為：知識可以在一定的條件下自主建構獲得；學習是知識、技能與行為、態度與價值觀等方面的長進；教育是滿足長進需要的有意識、有系統、有組織的持續交流活動。教育家陶行知先生說過：教、學、做應是一體化的，教、學、做是一件事，不是三件事[2]。
項目教學法由以下內容組成：有一定的教學內容，具有實際應用價值；能將理論知識和實際崗位技能結合起來；與企業實際生產或商業經營等活動有關系；學生可以獨立制定計劃并實施；學生可以運用所學知識克服、處理在項目工作中出現的困難和問題；有一定的難度，學生在完成過程中能掌握和運用新的知識和技能；要滲透情感、態度、價值觀的培養；有明確而具體的成果展示，師生能共同評價項目完成情況和工作成果[3][4]。
3 項目驅動的軟件測試實驗教學的意義
以軟件行業發展需要為依托，面向軟件開發（敏捷開發）過程中對軟件測試人才的迫切需求，以提高教學質量為核心，以教學改革為動力，以實現軟件開發與測試的學生知識、能力與素質協同發展為原則，以培養學生實踐能力為目標，結合學科優勢，以主干課程建設為突破點，開展項目驅動軟件測試實驗教學改革與研究，構建和實踐面向應用型本科軟件測試人才的專業實驗教學體系。具體的意義可歸納為以下四點：
①優化測試相關專業主干課程體系，打造以項目驅動軟件測試實驗教學的專業特色。測試相關主干課程體系優化與專業課程實驗教學改革是項目的核心。專業主干課程體系的建設能直接反映專業課程建設的目的和培養目標，是提高人才素質和保障教育質量的核心環節，也是衡量教學水平和教學質量的重要標志[5]。因此，面向軟件工程和軟件實踐背景，開展“項目驅動軟件測試實驗教學”，對于豐富和完善軟件測試課程教學改革，培養適應軟件測試行業中“高素質，高要求”的復合型、應用型管理人才，打造學科專業特色，形成學科專業競爭力，具有重要價值。
②以主干課程教學組織與團隊建設為著手點。制定主干課程建設的方案和措施，通過課程示范作用，帶動本專業相關其他課程的建設與改革。狠抓主干課程教材的選用與編寫、教學大綱的制定、應用案例的編寫、教學內容的精選、教學手段與教學方法的改革等環節，夯實了主干課程建設的基礎，并為該專業今后教學改革奠定基礎。
③以點帶面，擴展軟件工程專業實驗教學體系。通過在主干課程中適當引入綜合性實驗、設計性實驗、軟件工程案例分析，可加強學生的實踐技能、創新意識和團隊精神的培養，提高學生的綜合運用能力和競爭力。從長遠來講，這項成果會進一步提高我校該專業的人才綜合素質， 進一步提高該學科專業綜合競爭力。
④擴大畢業生就業率及提高就業檔次。通過該項目的建設，希望能推動該學科專業課程體系的優化，改善廣州大學該專業本科學生的知識結構，提高軟件測試學生的綜合素質和專業技能，擴大畢業生就業率及提高就業檔次。
不管是站在專業學科建設的角度，還是站在學生培養的角度，從培養“高素質、復合型”的軟件測試人才、解決學生就業的目標來看，教學改革研究均具有重要的意義，有必要開展系統、深入的研究。
4 項目驅動的軟件測試實驗教學改革方案
以培養“高素質、復合型”的軟件測試人才為目標，以專業主干課程體系優化主干課程教學團隊，強化主干課程配套的實踐教學環節，構建了理論教學和實踐教學相結合的、 “測試理論+測試方法+測試工程”三位一體的主干課程培養體系，并開展長期的跟蹤實踐，努力在應用型創新人才培養模式上形成自身的專業特色，完善“強基礎、重能力、多樣性、個性化”的人才培養方案。
4.1 軟件測試的課程體系的建立
隨著軟件行業對軟件測試重視，軟件測試對從業人員的要求也越來越高。傳統的教學內容已經不能滿足就業人員的需要。需對軟件測試的課程體系進行擴展、優化。如圖1軟件測試教改實踐課程體系所示。
軟件測試基礎：本課程從理論和實踐兩個層面引導學生學習軟件測試的基礎知識，涵蓋軟件測試的思想、流程和方法，主要內容包括軟件測試的基本概念和基本原理、白盒測試方法、黑盒測試方法以及面向對象軟件測試等知識點。
高效單元測試：課程以最典型的單元測試框架JUnit為例講述了單元測試的方法和最佳實踐，介紹了在java軟件開發中使用junit進行測試的原則、技巧與實踐，深入闡述如何編寫自動測試。課程討論了實踐中的測試技術，主要內容包括：用mock objects進行隔離測試、用ant和maven進行自動構建、Cactus進行容器內測試的方法、對java應用程序、數據庫應用程序等進行單元測試，以及Parasoft Jtest的使用。
WEB項目應用測試：由淺入深、全面、細致地闡述了如何使用開源測試工具來完成Web自動化測試，便于學生輕松掌握Web自動化測試的原理、方法和實際操作。課程將教如何使用Selenium、WebDriver、Jmeter、Badboy搭建起一整套穩定、高效、低成本的自動化測試平臺。結合應用實例展示web應用項目測試的過程。
軟件測試質量與保證：軟件測試質量與保證是面向軟件測試方向一門專業必修課，在學習軟件測試基礎理論與技術的基礎上，加強對軟件質量的認識及質量保證的重視，主要從軟件質量的概述、軟件質量工程體系、軟件質量度量、軟件可靠性測試、軟件質量標準、全面質量控制等多方面展開對軟件質量保證的深入學習。
性能測試與優化管理：從測試項目實戰需求出發，講述了性能測試技術和軟件性能測試工具應用的實戰知識。引入項目案例，詳細講述性能測試方案實施、性能測試計劃制定、性能測試用例設計、性能測試腳本開發、性能總結、性能優化管理及相關交付文檔。
軟件測試綜合項目實訓：本課程綜合應用軟件測試方向各門專業課程，以一個實際案例貫穿整個教學過程，使學生對軟件測試的過程有深刻地理解，包括測試需求的獲取、制定測試計劃，設計測試用例，測試執行、測試缺陷、測試評估及報告，并在實訓過程中加強對團隊協作的體會及文檔的協作能力。
移動應用程序測試：本課程將從實際應用角度出發，以智能終端和4G業務規劃為基礎，介紹手機測試的方法和實踐技術，主要內容；手機設備軟硬件的現狀與趨勢，手機軟件測試用例設計技術與方法，手機軟件體系結構與手機軟件測試技術和常用測試工具。
4.2 項目驅動實驗教學的實施方針
由于課程深度的不同，項目驅動實驗教學的方針與過程也不同。其主干課程項目驅動實驗教學的實施方針如下：
《軟件測試基礎》由于是基礎課程，課程涉及的基礎概念比較多，且為低年級的學生。所以實驗教學的案例要以單獨、經典的小應用實例為主，以鞏固和強化理論知識為目的。
《高效單元測試》軟件測試專業課。課程涉及代碼級軟件測試方法與技術。課程從應用程序的角度可分為三個方面的單元測試：表示層單元測試、運用層單元測試、數據層單元測試。從這三個方面再拆散成若干個小實驗以便對應相應的理論知識。在實驗案例選擇的原則要以高年級完成的課程設計或畢業設計為主，其原因是這樣的項目實例學生能更好的理解，上課的更有效果。
《WEB應用項目測試》軟件測試專業課。課程主要講解Web自動化測試的原理、方法和實際操作及測試工具的使用。在項目驅動實驗教學實例的選取了一些比較完善并同學比較熟悉的系統，比如學院的信息管理系統或學院的郵件系統。學生對這些系統的業務比較了解。做自動化測試比較容易上手。
《軟件測試綜合項目實訓》是一個以實際案例貫穿整個教學過程，以學生為主，教師為輔的綜合項目實訓課程。在實驗教學的實例選取上要求要接近企業的工作要求。所以項目組在設計用例時，直接向相關校企合作單位，要來需求和被測項目，并設計成實驗教學，以便學生在最接近現實的環境中作項目實訓。
《移動應用程序測試》軟件測試選修課。課程主要講解移動測試的原理、方法和實際操作及測試工具的使用。在項目驅動實驗教學實例的選取上，把學校組織參加比賽的移動應用項目拿來測試，這個項目影響較廣，學生對業務比較了解也比較。
5 小結
如何正確處理系統性理論知識體系與學生實際能力培養之間的矛盾？其解決的基本途徑是：重視實際能力培養，強化軟件測試工程案例教學，重視課程配套的課內課外各種實踐教學，強化學生人文素質培養。只有這樣，才能解決學生專業知識面過窄、適應能力差、滿足不了高要求的根本問題。如何搞好主干課程體系建設和主干課程師資隊伍建設，其解決的基本途徑是：以測試相關主干課程和教學團隊建設著手點，建立完善的主干課程體系，發揮主干課程的帶動效應，可達到以點帶面效果，解決課程教學內容不先進、教學方法單一、教學手段落后、教師業務能力不強等問題。
參考文獻：
[1]宰光軍，任兩品，劉燕.復合型軟件測試人才培養模式的探索與創新[J].計算機光盤軟件與應用，2012（20）.
[2]張世澤，劉同先，丁升選，呂淑敏.淺議項目教學法在我國的發展、應用和建議[J].教育教學論壇，2014（50）：168-169.
[3]鄭春瑛，郭偉青.項目教學法在管理信息系統課程中的應用探討[J].中國職業技術教育，2007（22）.
論文摘要:文章論述了軟件開發生命周期中每個階段添加的一系列關泣安全性的活動，提出將安奮瀏試整合到軟件開發生命周期中，分析了軟件安全性瀏試片祠試人員的要求，并以一個sql注入實例來具體說明安全性瀏試在軟。
信息網絡安全事件發生比例的不斷攀升、病毒利用軟件漏洞猖狂地傳播使得人們越發認識到信息安全的重要性。一般認為，傳統的信息安全技術可以借助防火墻(包括軟件和硬件防火墻)審核通過網絡的報文、限定用戶的訪問權限等來防止非授權用戶對重要數據的訪問，但是這一觀點是建立在軟件安全基礎上的。網絡應用軟件需要暴露在網絡環境下，并且授權外部用戶可以透過網絡來訪問此軟件。通過網絡，攻擊者有機會接觸到軟件，如果軟件本身存在漏洞，那么所有的防火墻就形同虛設。暴露于網絡的應用軟件往往成為被攻擊的目標，是網絡應用軟件安全的重災區。美國國家標準與技術研究院(nist)2002年的一項研究表明，美國花費在軟件缺陷方面的費用達到595億美元。公安部2008年全國信息網絡安全狀況與計算機病毒疫情調查分析報b說明，在發生的安全事件中，未修補或防范軟件漏洞仍然是導致安全事件發生的最主要原因。
1安全測試的定義
安全測試是鑒別信息系統數據保護和功能維護的過程。安全測試需要涵蓋的6個基本安全概念是:保密性、完整性、權限(身份驗證)、授權(權限分配)、可提供性、不可抵賴性陰。133229.Com軟件開發商都存在解決安全威脅方古的問題。對軟件開發商來說，安全性是其核心要求，這是由市場力量所驅動，也是由保護關鍵基礎結構及建立和保持計算的廣泛信任的需要所決定的。所有軟件開發商面對的一個主要挑戰就是創建更加安全的軟件，使其不需要頻繁地通過修補程序進行更新。軟件安全已經成為評判軟件質量的一個重要標準，軟件安全測試則成為保證軟件產品能夠符合這一標準的重要手段。軟件的安全性測試主要是測試在正常和非正常情況下，軟件能否對數據進行安全有效的操作。
2軟件開發生命周期流程(參見圖1)
對于軟件行業來說，要滿足當今提升安全性的需要，軟件供應商必須轉為采用一種更嚴格的、更加關注安全性的軟件開發流程。這種流程旨在盡量減少設計、編碼和文檔編寫過程中存在的漏洞，并在軟件開發生命周期中盡可能早地檢測到并消除這些漏洞。用于處理來自internet的輸人、控制可能被攻擊的關鍵系統或處理個人身份信息的企業和消費者軟件最需要實施這種流程。在很多實際的軟件開發項目中，安全測試已經成為sdl一個不可或缺的組成部分，并成為整個項目過程中的長期任務。黑盒一白盒測試方法往往執行在產品遞交客戶之前，但有的甚至在投人使用之后都未進行安全檢測和風險評估;在一些安全性要求較高的項目中，雖然將安全風險評估納人預算，但在實際操作中卻對其并未作過多考慮。這樣，所導致的直接后果是在開發工作幾近完成的情況下進行問題分析處理所造成的成本將遠遠大于在軟件開發階段進行缺陷修改的成本。即便是從充分利用現有的有限資金和資源的角度來考慮，也有必要將安全測試囊括到sdl中。這樣做雖然不能取代軟件開發后期的滲透測試和脆弱性測試，卻可以有效減少后者在施過程中的投人。
開發人員應該根據客戶的功能需求來制定相應的安全規約，利用內建的明確的控制機制來降低安全風險。開發人員可以根據風險評估的結果來確定測試項目:軟件能否可靠運行(safety)以及軟件運行結果是否可靠(security)。
軟件開發生命周期((sdl)中常用的測試方法有:單元測試、集成測試和驗收測試。
2.1需求、設計階段—安全性分析
在軟件項目的設計過程中，人們往往只是關注系統的特性和功能，而沒有充分考慮其他重要的非功能問題(例如性能、可用性、平臺支持、安全，及要在稍后的軟件開發生命周期中需要解決的安全性)，導致了項目中許多不必要的波動和延遲。由于安全性分析影響了整個的設計和架構，因此應該在項目設計階段充分地審查和了解它們。
安全性考慮包括一系列問題，例如訪問控制和授權、敏感數據的適當處理、數據和存儲器訪問的適當使用，以及加密方法。一些安全性需求不是非功能的需求，如所實施的加密類型。另外，許多安全性需求是更直接地面向用例的，并且需要定義主要場景，以及定義備選路徑和異常路徑。在沒有將功能的和非功能的需求適當地定義及并人軟件中的情況下，編碼錯誤和設計缺陷會表現出關鍵的信息和操作處于危險。我們應該像對待其他的需求那樣處理安全性需求，并將安全性需求劃分出優先級，設定范圍，同時作為整體用例和功能需求的一部分進行管理。
2.2實施階段—單元測試
受測試方式的影響，開發者對軟件安全風險的評估不可能面面俱到。最典型的就是在代碼設計階段，開發者可以通過單元測試來檢驗代碼行為，這些結果都是可以預知的，但是受到范圍的局限，不能測試這些類或者模塊集成后的行為。
實施單元測試可以從軟件基本單位(單個類)的檢測上保證輸人的有效性;在可能出現惡意攻擊的地方，也可以利用這一思想來組織針對單個類或者方法的單元測試，從而組織起軟件內部的縱深防御策略，防止惡意行為對軟件安全造成的損害。但是，這一方法將軟件各組件進行強制孤立，因此對于因大量組件交互而引起的軟件缺陷，利用此種方法無法檢測。
單元層的安全測試比較適合于防止緩沖區溢出，格式化字符串以及數據缺失的審核。
2.3驗證階段—集成測試
在集成層，軟件的整體安全屬性變得可見和可測試，使得這一層的可測試屬性數量相對單元層而言要多得多，但是對于跨站腳本和網絡服務器提供的一些服務(例如安全套接層ssl和url過濾)的測試，存在一定的困難。我們可以將實際案例和風險分析的結果作為組織集成測試的指南。
集成測試要求測試人員通過安全測試培訓，并且是有熟練技術的軟件開發人員。
在這一層，我們可以開展諸如注人缺陷驗證、旁路驗證以及訪問控制等方面的安全測試，來源于外部代碼的安全審查結果也應該以集成測試的方式加以確認。
2.4階段—驗收測試
驗收測試是軟件產品交付客戶之前的最后一個測試階段，是在真實的測試環境中，利用基于惡意事件的安全檢測模板，測試在典型的滲透活動中可被識別的安全缺陷。驗收測試的這一特性(基于安全檢測模板)，使得我們可以借助于強大的自動化測試軟件進行檢測，并且可以用驗收測試的結果來完善滲透測試報告內容，從而有助于開發人員理解軟件的脆弱性以及針對軟件脆弱性所采取的補救措施是否有效。
驗收測試針對軟件的外部api，因此不如單元測試和集成測試松散，并且只能測試當前已知且暴露的漏洞或者缺陷。非定制的商業軟件重新設計的關鍵功能或者其他改變都會影響到軟件的整體安全性，因此，如果改變會使得軟件產生不可預知的缺陷，針對這些缺陷的測試就應該在單元層或者集成層開展，而不是在驗收層。
在驗收層，我們可以測試針對解釋性程序(sql,xpath,ldap等)的注人式攻擊、跨站腳本攻擊、跨站請求偽造等。緩沖區溢出及格式化字符串等軟件缺陷也可以在驗收測試層得到檢測。
3安全測試隊伍
軟件測試一度被認為是編程能力偏低的員工的工作，直到今天，仍然有許多公司把優秀的人才安排在編碼工作上，也有更多公司讓優秀的人才進行設計，僅有很少公司讓優秀的人才進行測試工作。實際的軟件工程實踐證明，讓對軟件思想有深刻理解的工程師進行軟件測試，可以大幅度地提高軟件質量軟件供應商還必須認識到組織測試人員進行“安全進修”對安全測試的成功實施至關重要。在這些情況下，軟件供應商必須負責對其工程人員進行適當教育。根據組織的規模和可用的資源，擁有大批工程人員的組織可建立一個內部計劃對其工程師進行在職安全培訓，而小型組織則可能需要依賴外部培訓。
測試人員要像攻擊者那樣帶有“惡意的”想法去思考，而且在測試軟件時還要扮演攻擊者，攻擊自己的系統，以此來幫助發現軟件的安全漏洞。安全測試并不會總是直接導致安全溢出或者暴露可利用的漏洞，從而引出安全缺陷。要安全測試盡可能地發揮作用，測試人員需具備較強的分析能力，而這更多的是依靠熟練的開發技術和開發經驗。
4漏洞舉例:一個sql的注入式漏洞
有幾種情形使得sql注人攻擊成為可能。最常見的原因是，使用拼接形成的sql語句去操作數據庫。譬如，傳入用戶輸人的管理員用戶名和密碼，把這2個參數拼接形成sql語句，通過執行該sql語句，以便驗證用戶輸人的管理員用戶名和密碼的正確性。具體過程如下:
一般情況下，用戶傳人正常的用戶名和密碼進行驗證，如傳人“myname”和“mypassword”進行驗證，得到的sql語句將是:
這個sql語句很正常。但是，這只是開發人員預期的做法:通過管理員用戶名和密碼來驗證賬戶信息。但因為參數值沒有被正確地加碼，黑客可以很容易地修改查詢字符串的值，以改變sql語句的邏輯。譬如，分別傳人“myname’ori=1--”,"mypassword"，得到的sql語句將是:
在用戶名“myname’ori=i--”中，第一個“”’結束了原有字符串中第一個單撇號的配對，"or”后面的“i=i”會導致不管前面的驗證結果如何，都會返回真true值，而隨后的“一”將把其后的sql語句注釋掉。現在問題出現了，不管使用什么用戶名和密碼，都能驗證通過。在存在漏洞的數據顯示頁面，如果注人join語句，就能獲取數據庫里的所有數據，顯示在頁面上，如獲取用戶名、密碼等;而注入up-date/insert/delete語句將改變數據，如添加新的管理員賬號等。這樣，數據庫將不再安全。
sql注人安全漏洞的形成，根本在于sql語句的拼接，只要放棄sql語句拼接，適用規范的加碼訪問方式，問題自然迎刃而解。以下便是修改后的安全驗證方法:
[關鍵詞]《國際金融學》；教學模式 ；教學
[DOI]10.13939/ki.zgsc.2015.44.173
隨著信息技術的飛速發展，互聯網給我們的教育帶來了極大的便利，使得知識存儲、傳播的方式發生了質的改變，時代的變革引發了高校教師對于教學模式的新一輪思考，本文將介紹西北民族大學經濟學院在《國際金融學》課程的改革實踐過程以及改革帶來的啟示。
1 教學現狀
《國際金融學》是西北民族大學經濟學院學生的專業必修課，該課程以宏觀的視角洞悉國際金融市場的種種現象與原理。長期以來，《國際金融學》的講授采用的是傳統教學法，即一種“自上而下”的教學模式，這種模式并沒有充分調動起學生學習的自主性，即學生并沒有積極參與到課堂教學中來，此外，學生預習、復習知識的意識淡薄，不能主動借助互聯網等工具檢索相關知識，大部分學生仍然抱著僥幸心理，以為臨考前突擊學習或者背誦PPT中的內容便可大功告成，顯然，這很難適應計算機組卷的期末考試形式。有鑒于此，在2014―2015學年第二學期的教學中，《國際金融學》實施了教學模式和考核方式的改革，下文將具體闡述改革的具體實施過程。
2 改革措施
2.1 弱化單純講授，打造高效課堂
根據每節課的特點，借助教案合理安排課堂時間，完善課堂組織方式，抓重點，鼓勵學生融入到課堂中來。每堂課總共2學時，每學時45分鐘，如何將課堂合理地分為導入、提問、答疑、習題精講、討論幾個環節，就得益于課堂教案的設計。教案是對教學組織方式的安排，教師須明確課堂的重心，進而有計劃地編寫教案，將時間放在重點環節，使得鋼用在刀刃上。比如在《國際收支平衡表分析》一節中，可以在一學時中安排25分鐘左右的時間進行習題精講，將課堂的重點放在學生的應用操作能力，通過對具體例子的點撥和啟發，鼓勵學生能運用所學公式和原理對實際情況進行客觀分析；在《外匯與匯率》一節，可以酌情將課堂的重心放在提問環節，可就爬行釘住制、匯率目標區制、貨幣局制這幾種中間匯率制的概念、異同、聯系等進行發問，在這里需要指出的是，本課堂采取的提問絕非單純地背書，而是在已有的知識基礎上引發新一輪的思考，促進學生培養構建知識體系和總結歸納的能力。
2.2 拓寬知識來源，鼓勵學生思考
教學不應拘泥于一本教材，在借鑒多本國內經典教材的基礎上，《國際金融學》教學團隊編寫的講義博采眾長，這有利于學生從多角度思考問題。相比學生使用單一教材進行學習，該講義的優勢在于：①講義更具有針對性，一節課的內容在講義中分為名詞解釋、本節概要和重點問題解答三個部分，使學生能從各個角度完整、系統地學習本節課的內容；②講義的編織帶有鮮明的邏輯性，能夠有效地引導學生入門。名詞解釋部分作為本節課先導性知識，本節概要的內容很好地連接前后兩節課的內容，具有承上啟下的作用，而重點問題解析直擊本節課重難點；③為不同層次、特點的學生定制個性化學習方案。將一種名詞解釋改進了書本中晦澀的書面描述，通過互聯網等渠道引入例子，重點問題解答采用問題―解答的形式呈現，并在解答中采用文字說明、圖表分析、箭頭圖、口訣、案例分析等多元方式進行多角度深入分析。學生可各取所需，在學習資源充分的情況下選擇自己喜好的方式進行學習。
2.3 添加預習題目，調動學習自主性
習題作課前預習之用，旨在督促學生自主學習，在習題題目的編排上，教師注重考察學生的知識理解、遷移及檢索能力。如填空題目可以設置“2013年7月28日美元兌換人民幣的匯率是（）”或“20世紀90年代的亞洲金融危機是從（）貶值引發的”，簡答題中設置“金銀復本位制下有‘劣幣驅逐良幣’，今有‘良幣驅逐劣幣’的貨幣替代一說，試析這兩種說法是否沖突”等題目，鼓勵學生使用互聯網來檢索信息，獲取知識。
2.4 加入課堂討論環節，培養學生學習遷移能力及同伴合作能力
教師按照以往綜合成績排名，分為四個層次，并從每一層次隨機抽取若干學生進行分組，每組大約6～8人，在一學期的教學中，教師按分組順序組織討論。《國際金融學》課程中的討論環節為必要環節，具有以下幾個特點：
（1）學生組隊進行“有準備”的討論，力求做到“知識+能力”的最佳狀態。教師將討論題目附在講義上，如“蒙代爾-弗萊明模型之政策有效性分析”一節中，討論題可設置為“請結合所學試分析克魯格曼的‘三元悖論’”，學生在自學過講義后，完成預習題目的基礎之上，可進行分工，做有準備的討論；
（2）討論時長控制在25分鐘左右，其中搭配PPT演示、互動等環節，注重同組成員的同伴協作能力。在討論結束后，教師以及聽課學生可就與討論相關的問題進行提問，隨后教師就討論所涉及的知識作一總結歸納，并對討論組的表現進行點評并給出分數。
2.5 新增兩次單元測試，完善課程考核體系
本學期開創性地采用10%（平時成績）、50%（兩次單元測試平均分）、40%（期末考試成績），用分階段的兩次單元測試替代期中考查，定期追蹤成績，一方面可以完善考核體系，另一方面使得學生更有信心的面對最后的期末考試。一般來說，《國際金融學》的考核比例為20%（平時成績）、20%（期中考查）、60%（期末考試成績），實際上，該課程的期中考查以往都采用開卷的方式進行考查，故期中成績并不能準確反映學生的真實水平。此外，該課程期末考試已知采用計算機組卷，具有一定的難度與區分度，如一名學生期中成績為92分，期末為62分，這樣懸殊巨大，故很難形成學生學習成果的測評體系。在改革中，兩次單元測試的加入在一定程度上緩解了這個問題，單元測試為計算機組卷，題型、題目來源與期末考試一致。一學期采用兩次單元測試使得學生提前適應了計算機組卷的特點與考核方式，可以更有準備地應對最后期末考試的到來。
3 改革效果
3.1 課堂反應活躍，有力激發學生創新性思維
相比于傳統課堂模式，學生思維被打開，課堂不再死氣沉沉，學生可以自由地提出困惑，并且教師鼓勵其他同學為其解答。教師作為課堂中的引導者，讓全班同學都積極參與到主動學習的過程中，這個特點在討論環節表現得尤為明顯，如在討論“國際收支平衡與均衡的區別與聯系”中，該討論小組并沒有使用單調的概念解釋，而是用“一桿秤”的圖示來描述國際收支平衡的意義，即借貸平衡，表現為國際收支平衡表賬面差額為零，同時，用“相互制約并促進”的圖示來形容國際收支均衡，它是國內均衡與國際收支平衡相互作用后形成的均衡狀態。筆者認為，“同伴互教”的模式更能促進知識的記憶與理解，而這點在這次的教學改革嘗試中初見成效。
3.2 作業成績構建出學生學習效果反饋體系
根據對習題成績的觀察，大部分學生成績都處于良好態勢，這可以說明學生在適應教學改革的同時，不斷調整自身狀態并慢慢養成學習自覺性。教師親自批閱學生的預習作業，并針對筆記注釋、答題邏輯等幾個指標給出成績，并記錄在Excel表格，期末統一算出作業平均分，作為平時成績考核的一部分。Excel數據作為歷史記錄，一定程度上反映了該學生的學習態度和“自發性學習”的主動程度。筆者觀察到，大部分學生隨著課程的跟進，也在慢慢地調整學習狀態與習慣，開始適應自發學習的模式，作業成績也呈現出上升趨勢，形成了一套全面客觀有參考價值的教學反饋體系。
3.3 單元測試成績促進學生適應計算機組題
在所教授班級中，共有學生114人，筆者選取有效樣本110個，并對這110位同學的兩次單元測試成績計算平均分，繼而與其期末卷面成績進行對比分析。筆者運用Excel進行相關系數的計算，最后得到，單元測試成績與期末卷面成績的相關系數為0.7213，一般來說，為中度正相關。
由此可以看出，學生的單元測試成績與期末卷面成績之間存在正相關關系。這說明在兩次單元測試的基礎之上，學生通過總結、查漏補缺等方法，可以在期末考試中得到更為理想的成績。
4 啟 示
作者：韓冰 單位：東北石油大學 大慶油田有限責任公司
已開發油氣井及區塊效益評價模型的軟件系統工程設計1.系統設計的總體原則。為實現軟件系統研究的目的，系統設計總體原則為：（1）科學優選效益產量評價方法，以現金的方法，保證評價結果的準確性和科學性；（2）正確分析效益產量評價工作程序、確保系統的全面性、實用性和靈活性，提高開發和管理人員的工作效率，并便于推廣應用；（3）充分發揮現代科技技術，確保系統在應用技術上具有超前性，以功能齊全、用戶使用滿意為目標。軟件系統要充分利用企業現有各種信息平臺，實現企業資源的最佳利用，為改善企業經營管理，提高經濟效益和企業的綜合競爭力提供科學的決策信息庫。2.系統設計過程（1）系統啟動。本軟件系統項目比較復雜，需要大量的時間、精力和經濟投入。要解決的問題經常表述含糊，意味著初始的方案可能不成熟。因此，系統項目需要仔細的規劃。系統啟動階段確立解決問題所需的項目范圍、目標、進度和預算，或者項目帶來的機會。項目范圍定義了項目涉及的業務領域，以及要實現的目標。
本軟件系統的項目范圍是：油田開發、技術措施、生產管理、成本控制等。本軟件系統的項目目標是：為使油氣田效益產量評價分析工作簡便易行，同時便于各個層次員工隨時了解單井、區塊、行政管理單元的效益狀況并采取相應的措施提高油田開發的經濟效益。為開發技術人員、生產管理人員、經營管理人員提供一套效益產量評價系統，以提高油藏工程師分析研究解決問題的能力，并使領導能根據市場變化情況，及時調整生產經營策略，為領導的正確決策提供科學依據。本軟件系統的進度：（略）。本軟件系統的預算：（略）。系統分析。系統分析的目的是給項目團隊提供對觸發項目的問題和需求更全面的理解。該階段要求同系統用戶一起工作以便清楚地定義購買或開發的新系統的業務需求和期望。在系統分析階段結束后，通常可能揭示出需要修改業務范圍或項目目標、需要修改啟動階段提出的開發信息系統所具備的功能。本項目需要從環境配置要求、數據庫設計、系統配置、用戶管理以及系統與用戶維護管理等方面進行分析。在分析之前，根據涉及到的相關方我們采用了數據調查、文獻分析、德爾菲法以及頭腦風暴等方法，從用戶角度、系統所有人角度、軟件設計人員角度、軟件編制人員角度、結構設計角度、管理層角度、財務角度等分別進行分析。比如環境配置方面，我們進行了一線操作人員、技術主管、上層領導等的調查問卷，之后進行德爾菲法專家分析，確定了具體的環境配置方面的設計。
系統設計。系統設計初期需要探索不同的技術方案，選定并批準某個技術方案，并就實現該方案繪制出所需要的技術藍圖和規格說明。其他設計簡要敘述如下：首先，數據庫設計：系統采用Ora-cle數據庫，同時滿足用戶可創建系統運行所需要的數據庫；C/S設計模式，實現了數據的集中統一管理。其次，系統配置：對軟件環境、硬件環境、網絡環境的均可以在授權下進行配置。再次，用戶管理：在軟件系統啟動前，由系統管理員根據各崗位的分工及業務情況注冊相應的用戶，并賦予各用戶應有錄入、修改、刪除、查詢、分析、打印的權限，設置用戶口令，保護企業信心的安全，同時也可以進行口令的修改。最后，系統與用戶維護管理：該項設計用于管理各類基本參數的錄入，包括公用參數、采油礦（作業區）代碼、油品、基礎數據、措施內容和負效原因、自定義效益區間、區塊參數、提取開發數據字段、提取財務數據字段（編碼）、提供資產數據字段等十類參數。（4）系統實現。系統實現階段構造出新的信息系統，并投入使用。新的硬件和軟件都在該階段安裝和測試，購買的數據庫和應用軟件也在這個階段安裝和配置，定制軟件和數據庫則使用系統設計階段開發的技術藍圖和規格說明進行構造。在系統實現時，測試非常重要，獨立測試、系統測試等都需要進行。本軟件采用單元測試（白盒測試）、集成測試、確認測試和系統測試。在單元測試時主要采用邏輯覆蓋等方法，集成測試采用漸增式等方法，確認測試采用配置復查等方法，系統測試采用采用TestDirector等測試工具。（圖略）是本系統的軟件測試步驟。首先對每個單元進行單元測試，測試失敗需要進行完善和修正；測試成功后的軟件單元進行逐漸增加式的集成測試，接著進行組裝后的軟件進行功能確認，之后進行系統測試。在系統實現后還要進行系統支持和持續改進。
本文根據投入產出方法設計的已開發油氣井及區塊效益評價模型，借助系統設計一般原理和軟件工程相關理論對模型的軟件系統進行了設計分析。這些設計分析將有利于軟件的科學實現。
