導語：如何才能寫好一篇自動化測試，這就需要搜集整理更多的資料和文獻，歡迎閱讀由公務員之家整理的十篇范文，供你借鑒。

篇1

【關鍵詞】控件ID 映射關系 自動化測試

在自動化測試領域中，傳統的自動化測試腳本的開發一般有兩種方法。第一種方法是通過手工運行一次測試，同時使用自動化測試工具的錄制功能，把所進行的操作記錄下來，生成測試腳本。這種技術生成的腳本回放成功率比較低，后期維護也比較困難。第二種方法是編寫測試框架，對測試需要的基礎操作提供接口供調用，測試人員根據用例操作需求，手工編寫調用接口的自動化測試腳本，這種方法對測試人員的代碼水平要求很高。

目前自動化測試中，測試小組成員編寫完用例以后，還需要腳本開發人員單獨編寫一條針對此用例的自動化測試腳本，然后使用自動化測試工具運行腳本進行測試。當測試用例變更后，還需要重新編寫這條測試腳本，資源耗費比較大。測試用例和測試腳本之間的維護比較復雜。

1 實施過程

1.1 項目介紹

針對現有技術中的缺陷，本想法要解決的技術問題是：如何將測試用例自動地轉化為自動化測試腳本，以減少自動化測試腳本的代碼量、資源消耗及測試用例和測試腳本之間的維護。

為解決上述技術問題，我和小組人員不斷的摸索以及通過實際工作中多次測試和聯調，探索出一種只要被測產品中沒有產生新的控件類型，就不需要修改自動化測試腳本的解決辦法。通過在實際項目中多次試驗，本控件類型在測試用例中可以任意制定被測產品的流程，不會局限某個系統、某個產品。

根據多次實驗結果得出一種自動化測試方法，包括如下步驟：

步驟1：定義控件屬性與預置測試腳本代碼之間的對應關系。本環節是通過設置的相應的對應關系，在前期就降低控件的可變化性。

步驟2：讀入測試用例的測試數據，其中，所述測試數據包括控件屬性。

該數據從項目實際運營過程中獲取，保證能夠在測試過程中發現更多的問題，確保一旦正式后在實際運行過程中避免出現類似錯誤。

步驟3：針對讀入的控制屬性，查找到對應的預置測試腳本代碼；大多數自動化測試并沒有這一步驟，通過讀入控件屬性，可以降低代碼的重復性，是本設計特有的環節。

步驟4：根據預置測試腳本代碼形成自動化測試腳本代碼；

步驟5：將預置測試腳本代碼添加到編寫的自動化測試代碼框架中，形成自動化測試腳本代碼，執行自動化測試腳本代碼，其中，自動化測試腳本代碼用于模擬手動執行測試用例中各個控件類型的動作。

以上二分部主要由軟件自動完成，無需手動進行，這也就是自動化測試的魅力所在，可以在很大程度上降低人力手動操作的時間，騰出更多時間去完成其他事情，增加工作效率。

2 附圖說明

2.1 測試流程

為了將思想的其它特征、目的和優點更明顯展示出來：通過閱讀參照圖1附圖將會更直觀。

2.2 解決辦法

下面結合具體實施例對本方案進行詳細說明。以下實施案例將有助于本領域的技術人員進一步理解本人的思想，但不以任何形式限制本思想。應當指出的是，對本領域的普通技術人員來說，在不脫離本方案構思的前提下，還可以做出若干變形和改進。

每個項目都需要人員的配合。需要需求人員、產品開發人員和自動化測試腳本代碼開發人員共同配合，產生控件ID與被測系統映射表、控件類型與代碼映射表，例如表1和表2所示，其中，控件ID與被測系統映射表記錄了控件名稱、測試用例中控件ID、被測系統中的控件ID之間的映射關系，控件類型與代碼映射表記錄了控件類型、測試用例中控件類型、被測產品中控件類型、測試腳本中控件類型的映射關系。

本方案的方法和系統可以連接測試用例管理工具，讀取測試用例，通過解析模塊解析測試用例信息，生成腳本可讀的信息，然后根據測試用例中的控件ID在控件ID與被測系統映射表中查找對應被測模塊，最后確定被測模塊；我的主要想法還是根據測試用例中的控件類型在控件類型與代碼映射表中查找對應的測試腳本代碼，執行自動化測試腳本來最終產生測試結果。具體步驟如圖1所示，包括：

步驟1：我們要先讀取用戶編寫的測試用例，例如可以連接測試用例管理工具，從存儲有用戶編寫測試用例的測試用例管理工具中讀取，測試用例中的控件類型和操作命令、自動化測試腳本中的控件類型和操作命令、被測試系統中控件類型和操作命令三者一致，測試用例中的控件ID與被測系統的控件ID一致。

步驟2：解析測試用例信息，生成腳本可讀的信息。

步驟3：根據測試用例中的控件ID在控件ID與被測系統映射表中查找對應被測模塊。具體地，根據測試用例中的控件ID，在控件ID與被測系統映射表中，首先查找到對應的被測系統中的控件ID，然后根據該被測系統中的控件ID再查找到對應的被測模塊，其中，所述被測模塊是被測系統的某個測試單元，例如，一個文本框、一個多選框、一個單選框等。

本組成員在項目中反復實踐發現了一致性的關鍵點。目前很多自動化測試都是由于忽略了一致性才導致腳本可用性降低從而人為的增加了測試的工作量，說是實現了自動化測試，反而卻是增加成本。

步驟4：根據測試用例中的控件類型在控件類型與代碼映射表中查找對應的自動化測試腳本代碼。具體為，根據測試用例中的控件類型，在控件類型與代碼映射表中，首先查找到對應的測試腳本中控件類型，然后根據該測試腳本中控件類型再查找到對應的自動化測試腳本代碼。

步驟5：執行步驟4的控件類型對應的自動化測試腳本代碼，該自動化測試腳本代碼用于模擬手動執行通過步驟3查找到的被測模塊的控件類型的動作。

步驟6：輸出自動化測試腳本代碼產生的實際結果。

步驟7：比較自動化測試腳本代碼產生的實際結果與測試用例中的預期結果是否一致，如果一致說明測試通過；如果不一致說明測試不通，并且指出不通過的原因

使用本方案的方法，即使當測試用例變更后，測試人員只需按照關鍵字規范，手工修改一次測試用例即可。

下面對本方案的一個優選具體實施方式進行描述，在本具體實施方式中，包括以下步驟：

Step1：需求人員、產品開發人員和自動化測試腳本代碼開發人員共同定義好被測產品中控件類型與控件的ID，產生相應的映射表，標準控件的使用標準定義。

共同定義是非常重要的，針對不同項目，前期應把控件類型和id定義成標準，并在開發過程中使用統一標準。

Step2：產品開發人員和自動化測試腳本代碼開發人員根據映射表為被測產品的每個控件設置控件類型、控件ID。

Step3：定義測試用例內容以及格式；測試用例內容包含：控件類型、控件ID等；測試用例的格式如：（系統模塊名稱，控件類型，控件ID，輸入內容，操作命令，預期輸出，時間輸出，測試結果）。

Step4：執行自動化測試腳本代碼，包括如下子步驟：

Step4.1：讀取用戶編寫的測試用例，所述測試用例中的控件類型和操作命令、自動化測試腳本中控件類型和操作命令、被測試系統中控件類型和操作命令三者一致，測試用例中的控件ID與被測系統的控件ID一致。例如，可以首先連接存儲有用戶編寫的測試用例的測試用例管理工具，然后從測試用例管理工具中讀取測試用例。

其中，Step4是自動化測試一個控件過程，在自動化測試腳本代碼中，分別實現模擬手動執行每個控件類型的動作，并且使每一個控件類型的動作成為一個獨立的模塊，根據控件類型可以查找到對應的測試腳本代碼。腳本代碼可以重復利用，只要被測產品中沒有產生新的控件類型，就不需要修改自動化測試腳本。測試用例中可以任意制定被測產品的流程，不會局限某個系統、某個產品。

其實優選具體實施方式和之前介紹的沒什么區別，這里要說的是不管哪種方案要強調的是測試用例中的控件類型和操作命令、自動化測試腳本中的控件類型和操作命令、被測試系統中控件類型和操作命令三者一致，這個是本文的重點，也是提出本方法的關鍵。

3 結論

篇2

關鍵詞 軟件測試 軟件自動化測試 測試用例

1軟件測試的相關概念

軟件測試是指在規定的條件下對程序進行操作，以發現程序錯誤，衡量軟件質量，并對其是否能滿足設計要求進行評估的過程。

軟件自動化測試是把以人為驅動的測試行為轉化為機器執行的一種過程。通常，在設計了測試用例并通過評審之后，由測試人員根據測試用例中描述的規程一步步執行測試，得到實際結果與期望結果的比較。在此過程中，為了節省人力、時間或硬件資源，提高測試效率，便引入了自動化測試的概念。

2軟件測試的步驟及前提條件

2.1軟件測試的步驟

軟件測試分為五步，依次為單元測試、集成測試、確認測試、系統測試和驗收測試。

2.2自動化測試的前提條件

實施自動化測試之前需要對軟件開發過程進行分析，以觀察其是否適合使用自動化測試。通常需要同時滿足以下條件：

（1）需求變動不頻繁。測試腳本的穩定性決定了自動化測試的維護成本。

（2）項目周期足夠長。自動化測試需求的確定、自動化測試框架的設計、測試腳本的編寫與調試均需要相當長的時間來完成，這樣的過程本身就是一個測試軟件的開發過程，需要較長的時間來完成。

（3）自動化測試腳本可重復使用。如果費盡心思開發了一套近乎完美的自動化測試腳本，但是腳本的重復使用率很低，致使其間所耗費的成本大于所創造的經濟價值，自動化測試便成為了測試人員的練手之作，而并非是真正可產生效益的測試手段了。

另外，在手工測試無法完成，需要投入大量時間與人力時也需要考慮引入自動化測試。比如性能測試、配置測試、大數據量輸入測試等。

3自動化測試的工具

3.1 QTP

QTP是quicktest Professional的簡稱，是一種自動測試工具。使用QTP的目的是想用它來執行重復的手動測試，主要是用于回歸測試和測試同一軟件的新版本。因此在測試前要考慮好如何對應用程序進行測試，例如要測試那些功能、操作步驟、輸入數據和期望的輸出數據等。

QuickTest針對的是GUI應用程序，包括傳統的Windows應用程序，以越來越流行的Web應用。它可以覆蓋絕大多數的軟件開發技術，簡單高效，并具備測試用例可重用的特點。其中包括：創建測試、插入檢查點、檢驗數據、增強測試、運行測試、分析結果和維護測試等方面。

3.2 WinRunner

Mercury Interactive公司的WinRunner是一種企業級的功能測試工具，用于檢測應用程序是否能夠達到預期的功能及正常運行。通過自動錄制、檢測和回放用戶的應用操作，WinRunner能夠有效地幫助測試人員對復雜的企業級應用的不同版進行測試，提高測試人員的工作效率和質量，確保跨平臺的、復雜的企業級應用無故障及長期穩定運行。

企業級應用可能包括Web應用系統，ERP系統，CRM系統等等。這些系統在之前，升級之后都要經過測試，確保所有功能都能正常運行，沒有任何錯誤。如何有效地測試不斷升級更新且不同環境的應用系統，是每個公司都會面臨的問題。

3.3 Rational Robot

是業界最頂尖的功能測試工具，它甚至可以在測試人員學習高級腳本技術之前幫助其進行成功的測試。它集成在測試人員的桌面IBM Rational Test Manager上，在這里測試人員可以計劃、組織、執行、管理和報告所有測試活動，包括手動測試報告。這種測試和管理的雙重功能是自動化測試的理想開始。

3.4 AdventNet QEngine

AdventNet QEngine是一個應用廣泛且獨立于平臺的自動化軟件測試工具，可用于Web功能測試、web性能測試、Java應用功能測試、Java API測試、SOAP測試、回歸測試和Java應用性能測試。支持對于使用HTML、JSP、ASP、.NET、PHP、JavaScript/VBScript、XML、SOAP、WSDL、e-commerce、傳統客戶端/服務器等開發的應用程序進行測試。此工具以Java開發，因此便于移植和提供多平臺支持。

3.5 SilkTest

是業界領先的、用于對企業級應用進行功能測試的產品，可用于測試Web、Java或是傳統的C/S結構。SilkTest提供了許多功能，使用戶能夠高效率地進行軟件自動化測試。這些功能包括：測試的計劃和管理；直接的數據庫訪問及校驗；靈活、強大的4Test腳本語言，內置的恢復系統（Recovery System）；以及具有使用同一套腳本進行跨平臺、跨瀏覽器和技術進行測試的能力。

3.6 QA Run

QARun的測試實現方式是通過鼠標移動、鍵盤點擊操作被測應用，即而得到相應的測試腳本，對該腳本可以進行編輯和調試。在記錄的過程中可針對被測應用中所包含的功能點進行基線值的建立，換句話說就是在插入檢查點的同時建立期望值。在這里檢查點是目標系統的一個特殊方面在一特定點的期望狀態。通常，檢查點在QARun提示目標系統執行一系列事件之后被執行。檢查點用于確定實際結果與期望結果是否相同

3.7 Test Partner

是一自動化的功能測試工具，它專為測試基于微軟、Java和Web技術的復雜應用而設計。它使測試人員和開發人員都可以使用可視的腳本編制和自動向導來生成可重復的測試，用戶可以調用VBA的所有功能，并進行任何水平層次和細節的測試。TestPartner的腳本開發采用通用的、分層的方式來進行。沒有編程知識的測試人員也可以通過TestPartner的可視化導航器來快速創建測試并執行。通過可視的導航器錄制并回放測試，每一個測試都將被展示為樹狀結構，以清楚地顯現測試通過應用的路徑。

3.8 Telelogic TAU

TAU第二代包含三個最新的、最強大的技術用來加速大規模軟件開發和測試：統一建模語言（UML）及它的許多最新修訂版本中的特性，UML2.0；功能強大的測試語言TTCN-3和新的構造系統的方法：Model Driven Architecture（模型驅動構架）。

4自動化測試的過程

4.1自動化測試需求分析

當測試項目滿足了自動化的前提條件，并確定在該項目中需要使用自動化測試時，我們便開始進行自動化測試需求分析。此過程需要確定自動化測試的范圍以及相應的測試用例、測試數據，并形成詳細的文檔，以便于自動化測試框架的建立。

4.2自動化測試框架的搭建

所謂自動化測試框架便是像軟件架構一般，定義了在使用該套腳本時需要調用哪些文件、結構，調用的過程，以及文件結構如何劃分。

而根據自動化測試用例，我們很容易能夠定位出自動化測試框架的典型要素：

4.2.1公用的對象

不同的測試用例會有一些相同的對象被重復使用，比如窗口、按鈕、頁面等。這些公用的對象可被抽取出來，在編寫腳本時隨時調用。當這些對象的屬性因為需求的變更而改變時，只需要修改該對象屬性即可，而無需修改所有相關的測試腳本。

4.2.2公用的環境

各測試用例也會用到相同的測試環境，將該測試環境獨立封裝，在各個測試用例中靈活調用，也能增強腳本的可維護性。

4.2.3公用的方法

當測試工具沒有需要的方法時，而該方法又會被經常使用，我們便需要自己編寫該方法，以方便腳本的調用。

4.2.4測試數據

一個測試用例需要執行很多個測試數據，我們便可將測試數據放在一個獨立的文件中，由測試腳本執行到該用例時讀取數據文件，從而達到數據覆蓋的目的。

5軟件自動化測試的優缺點

5.1軟件自動化測試的優點

測試活動自動化在許多情況下可提供其最大價值，如對軟件進行的功能性測試，是測試系統在做什么，這些測試可以明確知道應該在什么情況下輸入什么，會有什么樣的輸出。通過自動化測試，可以使某些測試任務提高執行效率，除此之外，還有以下優點：

（1）對程序的回歸測試更方便。軟件測試實行自動化進程是因為測試工作的需要，更準確地說是回歸測試和系統測試的需要。由于回歸測試的動作和用例是完全設計好的，測試期望的結果也是完全可以預料的，將回歸測試自動運行，可以極大提高測試效率，縮短回歸測試時間。

（2）可以執行一些手工測試困難或不可能進行的測試。比如，對于大量用戶的測試，不可能同時讓足夠多的測試人員同時進行測試，但是卻可以通過自動化測試模擬同時有許多用戶，從而達到測試的目的。

（3）更好地利用資源。將繁瑣的任務自動化，可以提高準確性和測試人員的積極性，將測試技術人員解脫出來投入更多精力設計更好的測試用例。有些測試不適合于自動測試，僅適合于手工測試，將可自動測試的測試自動化后，可以讓測試人員專注于手工測試部分，提高手工測試的效率。

（4）測試具有一致性和可重復性。由于測試是自動執行的，每次測試的結果和執行的內容的一致性是可以得到保障的，從而達到測試的可重復的效果。

（5）測試的復用性。由于自動測試通常采用腳本技術，這樣就有可能只需要做少量的甚至不做修改，實現在不同的測試過程中使用相同的用例。

（6）此外，手工不能做的事情，自動化測試能做，如負載、性能測試等。

5.2軟件自動化測試的缺點

在軟件測試自動化的實施過程中會遇到許多誤區，比較普遍的有如下幾種：

（1）不正確的觀念或不現實的期望。一般來說，人們對新技術的解決方案常常深信不疑，認為可以解決面臨的所有問題，對測試工具也不例外。事實上，如果期望不現實，無論工具如何，都滿足不了期望。

（2）希望測試發現大量新缺陷。測試運行第一次時最有可能發現新缺陷。如果測試已經運行，再次運行相同的測試發現新缺陷的概率就小得多。

（3）安全性錯覺。如果自動化測試沒有發現任何缺陷，并不意味著軟件沒有缺陷，可能測試設計本身就有缺陷。并且，測試覆蓋率也不會達到百分之百。

（4）自動化測試的維護性。當軟件修改后，通常也需要修改部分測試，這樣必然導致對自動化測試的修改，所以在自動化測試的設計和實現時，要防止自動化測試帶來的好處被高維護成本所淹沒。

（5）測試自動化可能會制約軟件開發。由于自動測試比手動測試更脆弱，所以維護會受到限制，從而制約軟件的開發。

6自動化測試的意義

自動化測試引入的原因是就把軟件測試人員從枯燥乏味的機械性手工測試勞動中解放出來，以自動化測試工具取而代之，使測試人員的精力真正花在提高軟件產品質量本身。

總之，軟件自動化測試還不能解決所有的測試問題，因此，在進行自動化測試前，首先要建立一個對軟件測試自動化的認識觀。軟件測試工具能提高測試效率、覆蓋率和可靠性等，但軟件測試的自動化過程是一個漸進的過程，并不需要一開始就對所有的測試實施自動化，也通常也是不現實的。自動化測試雖然具有很多點，但它只是測試工作的一部分，是對手工測試的一種補充。因此，如何合理地規范自動化測試，選擇適當的測試自動化工具，是測試管理人員必須解決的問題。

參考文獻

[1] 賀平.軟件測試教程[M].北京：電子工業出版社，2005.

篇3

關鍵詞:存儲過程;自動化測試;測試用例;Junit框架;XML

中圖分類號: TP311文獻標識碼:A文章編號:1009-3044(2009)36-10252-02

Research on Automated Testing of Stored Procedure

MA Zhu-gen

(Department of Computer Science and Technology, Huaihua University, Huaihua 418008, China)

Abstract: Stored procedure test is an extremely tedious work.Some database products provide some tools to be able to make the statistics of the execution time of a stored procedure, the number of records and other information, but these tools can not carry on batch and repeated testing. Moreover,the test result is not intuitive. This paper describes the implementation scheme of stored procedure automation test under the junit framework.The code-reuse technique based automatic testing framework of Junitrealizes the regression testing of procedure. The test cases are described and organized using XML to realize the separation between code and data in order to improve efficiency of test, and the test result using XML provides developers with an intuitive notation.

Key words:stored procedure; software automation testing; test case; junit framework; XML

軟件測試是保證軟件質量的重要手段,軟件測試在整個項目開發中所占的比重也越來越大。隨著軟件規模的擴大和軟件復雜性的提高,軟件測試技術不斷發展,自動化測試技術得到廣泛應用,并逐漸成為軟件測試發展的方向。單元測試是軟件開發過程中要進行的最基本的測試活動,是確保其他測試能夠順利進行的基礎。隨著增量開發模式和重構技術的發展,軟件自動化測試工具JUnit也隨之產生。目前Junit已經成為Java程序單元測試框架的標準,已有多種對其進行擴展的自動化測試工具[1]。

存儲過程被廣泛應用在各種與數據庫相關的應用系統中。在開發階段,對存儲過程進行測試是必不可少的工作。通常的測試過程是由測試人員通過命令窗口執行命令,再將命令窗口中的結果信息拷貝下來,保存到一個文件里,在以后再進行分析或者比較。測試工作也可以使用類似Rapid SQL等圖形化的工具來輔助做一些工作,但能完成的測試工作量較少。這種大部分依靠手工進行的存儲過程的單元測試存在很多缺點,如測試效率低,無法重用,無法進行自動化的回歸測試,沒有直觀的測試結果,需要程序員手工整理測試結果并生成測試報告。針對這些問題,本文在Eclipse中利用Junit測試框架來實現存儲過程測試的自動化。

1 Juit的框架結構

Junit是Erich Gamma和Kent Beck編寫的一個回歸測試框架,它是一個Java程序自動測試的框架[2],用在軟件測試的單元測試階段,即Java對象類的功能測試。JUnit共有七個包,核心的包就是junit.framework和junit.runner。Framework包中包含了Junit測試類所需的所有基類,它是整個Junit的基礎框架[3],負責整個測試對象的構架,Runner則負責測試驅動。JUnit框架中主要有以下幾個對象類[4-5]:

1) Assert類,它提供在編寫測試時要用到的所有assert方法。當條件成立時assert方法保持沉默,但若條件不成立就拋出異常。Assert類是TestCase的父類。

2) TestCase類

客戶測試類所要繼承的類,負責測試時對客戶類進行初始化,以及測試方法調用。類中的主要方法有:setUp()用于如變量賦值等測試的結果處理,tearDown()用于如文件關閉等測試的結束處理,run()測試實例的執行,并把測試結果放入測試結果對象TestResult中。

3) TestResult類

負責收集TestCase所執行的結果。一般來說,用戶不需要對TestResult進行操作,測試結果由系統提供的測試工具自動輸出。

4) TestSuite類

TestSuite對象是測試實例的集合,負責包裝和運行所有的TestCase。

2 存儲過程測試代碼的自動生成

Junit測試的實現流程就是繼承TestCase類,然后重載它的一些重要方法,如setUp()、tearDown(),最后將這些對象組裝到一個Testsuite對象中,交由TestRunner來運行。為了利用 JUnit 帶來的高效率,首先需要改變被測存儲過程的調用方式,即從手工調用改為使用 JDBC 來調用,把一個個存儲過程的調用寫成Java 代碼,以后需要進行回歸測試時,只需要運行這些 Java測試代碼就可以了。但是直接使用 JUnit,也會是一個煩瑣的過程,因為必須在每段測試代碼中編寫連接數據庫的代碼和調用存儲過程時的一大堆參數設置的代碼。對于存儲過程測試來說,這些代碼就顯得非常累贅了,于是設想把這些操作封裝為一個公用的類,只需要在測試代碼中提供數據庫連接信息、存儲過程名字和參數值就可以了,其他的工作由這個公用的類來處理。因此在實現存儲過程測試代碼的自動生成過程中,首先必須要解決如何獲得存儲過程名和存儲過程參數以及在生成的測試代碼中如何運行存儲過程,下面分別進行討論。

2.1 存儲過程名和參數的獲取

在存儲過程測試代碼生成過程中,第一個問題是要針對哪些存儲過程生成測試代碼。獲取存儲過程名可以有兩種方式,其一是由用戶手動指定,其二是將儲過程名稱保存在文件中,由系統自動從文件中分析出存儲過程名稱。這樣的文件可以是一個定義了 Java 常量的 .java 文件,也可以是一個 .properties 文件。文件中可用"="來定義存儲過程,系統將自動把"="右邊的部分識別為存儲過程的名稱。

要為存儲過程自動生成測試代碼,有一個前提條件是被測試的存儲過程已經在數據庫中創建。作為數據庫的對象,存儲過程的名稱、參數等信息也都有相應的數據字典表存放。只要知道存儲過程的名字,可以查詢數據字典來獲取存儲過程的參數信息,如參數名稱、數據類型、長度、出入參類型等。因此,在測試代碼生成過程中可以根據存儲過程的名稱查詢數據庫的系統表來獲取參數信息,例如DB2 的 SYSCAT.ROUTINEPARMS表,Oracle 的 USER_ARGUMENTS 表或者SQLServer的SYSCOLUMNS 表等。

2.2 測試代碼中存儲過程的運行

在已經生成的測試代碼中,如果將大批的數據庫操作寫在測試代碼中顯然是不合適的,這樣會造成代碼的混亂和維護困難。因此考慮封裝一個類,用它專門來運行存儲過程,它提供了以下主要方法:

1) SPProcesss (DBInfoObject dbConfig), 構造函數,根據傳入的數據庫配置信息,建立數據庫連接,初始化運行環境;2) getSPParmList(String routineSchema , String routineName) 根據存儲過程模式和存儲過程名獲取參數列表;3) runStoredProcedure(StoredProcedureInfo spInfo) 運行存儲過程,存儲過程信息包含在名為 StoredProcedureInfo 的類中。4) String (getDurationTime) 獲取存儲過程運行時間;5) object getReturnedObject (int parmIndex)獲取存儲過程輸出參數的值。

其中的 StoredProcedureInfo是記錄存儲過程信息的類,包括存儲過程名、存儲過程參數列表等。因此,只需要首先創建存儲過程信息,然后調用 runStoredProcedure 方法即可運行存儲過程。而這部分代碼也是自動生成的,程序員真正需要做的就是修改調用參數的值。

3 改進的Junit框架

采用Junit作為單元測試工具有許多優點,但也存在著不足。在實際的單元測試中,發現JUnit產生的測試代碼量是龐大的。為了提高測試代碼的復用,文獻[6]提出了一種改進的自動化單元測試框架。該框架設計的核心是實現測試用例與測試代碼的分離,運用XML文件作為測試數據存儲的容器,把每個測試用例中的數據裝入到對應的JavaBean中,最后構建一個JavaBean對象為元素的ArraList來存儲所有的測試用例。測試執行時,測試代碼只需要從ArrayList里面取得測試用例的數據,測試代碼僅僅完成驗證任務。這樣,如果測試用例增加了,只需修改相應的XML文件,而不必再修改測試代碼,就可完成相應的測試。

借鑒文獻[6]的方法,本文將測試用例和測試結果都存儲為 XML 文檔,使用方法writeToFile(String fileName, String time,ArrayList testResultList)將測試結果保存在XML文件中,測試結果可以包括存儲過程運行的時間、返回的記錄數、調用的參數列表或者出錯信息等。選擇把測試結果保存為 XML的一個重要原因是通過簡單的 XML編程即可實現對歷次的測試結果的比較分析。其實現方法就是將測試結果的XML文件命名為 TestCaseName_年_月_日_時_分_秒.xml,每次運行測試例后,都生成一個具有時間戳的測試結果文件,例如:

testSP_2009_10_18_17_27_00.xml

testSP_2009_10_18_17_30_00.xml

testSP_2009_10_18_17_32_00.xml

通過比較這三個文件中同一個存儲過程的運行耗時、返回記錄數等指標就能知道這次的測試結果比上次是否有所改進,或者系統在不同時間點的性能變化情況。

有了JUnit 測試代碼之后,在 Eclipse 中,左鍵雙擊將要運行的 Java 文件,選擇 Run As->JUnit Test 就可以在工作環境中運行測試文件了。運行完畢后,會生成一個XML文件,再配合以XSL樣式文件,就可以在瀏覽器中看到美觀的測試報告了。

4 結束語

Junit和Eclipse兩種軟件的源代碼都能從網上免費獲得,利用Junit基于XML存儲測試數據和測試結果的新測試框架真正提高了測試效率,簡化了測試步驟,從根本上提高了測試代碼的重用性。利用JUnit實現了以往存儲過程測試中很難進行的回歸測試,利用XML技術實現了測試數據和測試代碼分離,提高了測試效率,為開發人員提供了直觀的測試結果。

現有的測試框架可以擴展到Cactus(Apache Software開發的用來對服務器上的Java代碼進行測試的框架)框架上,實現從瀏覽器進行存儲過程測試用例的調用執行,可以克服因為開發和生產環境之間可能存在的網絡、安全等因素而影響測試準確性的問題。

參考文獻:

[1] 余波,王樹林,張大方.基于Junit自動生成類測試案例框架的實現[J].計算機工程與應用,2006,42(1):89-91.

[2] 王東剛.軟件測試與JUnit實踐[M].北京:人民郵電出版社,2004.

[3] 孔亮亮,殷兆麟.Java類測試工具Junit的分析與擴展[J].計算機工程與設計,2005,26(12):3413-3415.

[4] 何成萬,余秋惠.用JUnit實現Java程序自動測試[J].計算機應用,2002,22(3):93-94.

篇4

關鍵詞:自動化測試;測試儀器;整體化測試平臺框架

中圖分類號:TP311文獻標識碼:A

文章編號:1009-2374 (2010)22-0024-02

1自動化測試簡介

自動化測試的出現可以大大減少測試開銷,同時大幅提高有限時間內的測試覆蓋率。成熟的自動化測試機制,是可重復的、極少的人工資源投入的,可以做到“即使最小的改動也可以以最小的代價進行全面的測試”。

但是,在自動化測試實施與推廣過程中,常常會因為自動化測試手段與工具的多樣化與不統一化對自動化測試件設計/開發效率的影響等,導致自動化測試無法有效地推廣開來。

本文通過對數據通信領域的自動化測試平臺的探討,尋找到一種更好的搭建自動化測試平臺的方法,提高自動化測試效率。本文提到的實現方法,是以數據通信領域產品的自動化測試為例進行闡述與實際實現的,其他領域的軟件自動化測試可以依據自身的特點與情況對此進行一些修正與改造。

2自動化測試實現的常見問題

在通常的自動化測試實現中存在著一些常見的差異性:

自動化測試所使用的測試儀器或工具不同,如:使用PC作為測試工具,或者使用數通領域通用的測試儀器(如:思博倫公司的SmartBits或IXIA公司的IXIA測試儀)作為測試工具。

測試環境(或拓撲)不同,如:有的自動化測試環境為單臺被測設備,有的需要多臺輔助測試設備,所實現的自動化測試方法也相應有所不同。

2.1基于PC的自動化測試

由于業界有許多基于PC的開源工具或者工具包的支撐,因此在PC上編寫各種測試工具與測試軟件是一件相對方便且資源豐富的方法。基于PC的自動化測試,主要完成一致性/功能測試與部分性能測試。但由于PC功能較為單一,無法很好地模擬網絡的組網方式,因此常見的解決方法是通過PC對實際的組網進行測試,可以進行實際測試效果。

該測試方式的優點是較為直觀,自動化測試實現簡單易行。但由于不同測試用例的組網環境不同,切換用例需要手動改變組網,自動化無法連續進行,因而完成一系列測試需要相當長的時間,而且回歸和重現較為困難。另外,錯誤故障定位困難,由于測試時使用了不同的輔助設備,出現故障時,具體哪一臺設備出現故障難以確定。

2.2基于測試儀器的自動化測試

在數通測試領域,所使用的測試儀器一般都提供了強有力的自動化測試接口支撐,因此可以基于這些接口開發適用于被測設備(系統)的自動化測試軟件。

該測試的優點是能夠更好地進行路由仿真和性能測試,如OSPF(開放式最短路徑優先)協議的收斂時間測試可以模擬任何組網,組網結構可以可視化地改變,并以協議報文的形式反饋到被測設備。

其缺點在于無法深入到具體協議的內部實現交互過程的測試,大多數的軟件bug都集中于協議交互過程,導致測試覆蓋率不高,需要一致性測試作為補充。

2.3自動化測試的管理

隨著自動化測試規模的不斷擴大,帶來的自動化測試腳本管理、維護困難也會越來越突出。如何管理自動化測試,也成為一個大家愈發重視的問題

3整體化自動化測試平臺的設計

3.1測試環境的整體化

自動化測試的組網環境的簡化,可通過PC的網絡接口模擬實際的路由和交換設備,使用一個單獨鏈路作為被測設備配置鏈路,專門配置被測系統。測試鏈路用于測試報文收發,被測設備配置和報文收發和編解碼通過腳本控制

配置鏈路:測試PC通過配置鏈路對被測設備進行控制,這樣的配置鏈路可以是帶內(如:PC的控制口),也可是帶外(如:Telnet/HTTP等方式)。

測試鏈路:通過PC的網卡與被測設備通訊,在PC上運行各種模擬數據通信設備或協議的軟件,來達成減少測試環境中的測試設備的目的,所需模擬的測試設備多的時候可以增加PC的網絡接口。

這里提到的模擬數據通信設備的軟件,可以是一些來自于已有的商用或開源軟件,也可以是自行開發的一些測試軟件。這些工具與特定應用相關,可以在實踐過程不斷地擴充。

測試環境的整體化,對于一些不可避免的需要組網環境的測試,目前業界已經有一些比較常用的拓撲切換方法,如使用帶拓撲切換功能的網絡互連設備,通過對這樣的拓撲切換設備的自動化控制、操作來實現不同邏輯拓撲的切換功能,本文不做進一步的細節闡述。

3.2測試工具的整體化

PC測試可以細化編解碼和能夠進行一致性測試,具有較強的測試覆蓋率,測試儀器測試具有能夠進行性能測試、物理網絡仿真的優勢。二者結合后,可以達到通過PC實現協議交互過程,通過測試儀器在這些交互過程中進行所需的測試行為注入。

運用測試儀器提供的擴展命令接口,PC通過腳本控制測試儀器端口協議報文的流量發送,批量統計。同時可通過PC控制網卡適配器報文的收發,進行功能測試等。物理拓撲搭建圖如圖1所示:

如圖1所示,測試PC充當了兩個角色:

被測設備控制者:PC通過控制鏈路對被測設備進行配置、操作等控制。

測試儀器操作者:測試PC同時通過測試儀器提供的自動化測試接口,實現對測試儀器的自動化控制。

測試鏈路中存在2種測試方式:

測試PC對測試設備的測試鏈路:通過在PC上運行各種自動化軟件,來實現對被測設備的測試,如報文收發、協議模擬等。

測試儀器對測試設備的測試鏈路:自動化測試程序通過調用測試儀器提供的測試接口,實現對被測設備的各種測試操作,也包括報文收發、協議模擬等。

通過對兩者的有機結合,可以將測試PC對測試設備的測試鏈路與測試儀器對測試設備的測試鏈路進行統一控制,從而實現二者的交互。

3.3自動化測試管理的整體化

構造整體化的測試平臺,除了自動化測試本身外,還兼具測試用例管理、測試用例編輯、測試用例執行、測試結果分析與測試結果統計反饋等功能。將整個自動化測試實現、使用、管理的過程統一在一個平臺上實現。

3.4整體化測試平臺框架

本章節討論整個整體化測試平臺如何進行構建,形成整體統一的測試平臺框架。

3.4.1框架構成整體化測試平臺框架包含如下功能支持:自動化測試腳本編輯環境。腳本編輯界面,包括各種基本的編輯功能,語法美化、關鍵字識別、關鍵字自動提示等輔助功能。

(1)測試腳本調試環境。自動化測試腳本的調試器,可以通過集成當前通用的調試環境與工具來達成。

(2)測試管理界面。測試工程建立和管理:建立測試工程項目,生成相關的工程組織文件,并可添加/移除已編輯好的測試腳本和測試配置文件。測試參數設置和參數腳本生成:配置測試過程所需的參數,并生成相應的配置腳本文件。當測試環境改變時,測試人員只需更新相關參數。測試例執行規則設置:設置測試例執行的規則,如在何種條件下終止測試執行過程,測試過程希望察看的信息,測試用例按何種順序執行等。測試用例腳本,用例描述,拓撲的映射關系維護:測試人員可以根據用例列表,查看用例描述,物理和邏輯組網圖。測試結果的記錄和日志生成:對于測試失敗的用例,記錄錯誤的日志。測試結果處理:測試結果的查詢,并提供同問題記錄系統的接口,使得測試結果能夠及時上報;同時,也可視需求決定是否提供E-mail、短信等實時通知功能。

(3)測試執行操作界面。提供測試控制的界面,測試開始,暫停,繼續,停止等。

測試過程監視:在窗口界面顯示測試例執行的結果和統計,指定類型的協議報文的收發過程和編解碼等信息。對各種信息劃分等級,測試人員可以在測試執行過程屏蔽/顯示某一級別的信息。支持測試人員定義多個窗口顯示不同類型的信息。

(4)公用支持庫的支撐。提供自行定義的一套自動化測試公用庫,其基礎構成包括:被測設備的控制庫:用于控制不同的被測設備,將相同的操作歸類,提供統一接口。報文收發的通用庫,這里的報文收發可以通過PC網卡實現,也可通過測試儀器實現,目的是為不同的測試手段提供統一的接口。函數報文緩沖操作接口:提供一組申請、釋放和訪問內存緩沖區的命令,用于支持協議報文的編解碼,以及協議報文編解碼命令。利用報文緩沖區管理命令實現特定協議編解碼的過程。擴展接口規范的定義和擴展開發庫的提供:為后續新的協議支持或新的操作支持,提供兼容性以及統一的命名規則要求。

3.4.2框架實現簡述本文給出了具體框架的搭建模型和為實現相應的功能需要完成的內容,具體的實現平臺、方式可依據所需自動化測試環境的不同而變化,譬如:平臺運行的操作系統、實現平臺所使用的編程語言等等。筆者在實踐過程中,是在Windows操作系統下的使用C#進行工具實現,完成了對測試PC、思博倫公司的SmartBits測試儀器,以及被測設備的自動化測試。

在實際實現過程中,可以依據當前系統的自動化測試程度與水平,通過逐步疊加的方式來逐步實現框架中的不同功能。譬如:其中提到的自動化腳本編輯環境、測試執行失敗記錄的分析、測試結果的統計等功能,可以隨著自動化測試資源投入的增大,對自動化需求的增多,而逐步增加開發,并不一定需要一步到位地實現所有功能。

本文從數據通信領域自動化測試實現常見的一些問題入手,通過構建一個整體化的,不依賴于自動化測試實現方法、實現手段的自動化測試平臺與工具,以期達到解決這些常見的問題,提高自動化測試實現效率,改善自動化測試管理方式的目的。

參考文獻

篇5

關鍵詞：軟件 測試 自動化 技術

中圖分類號：TP311.5 文獻標識碼：A 文章編號：1007-9416（2016）06-0234-01

軟件測試技術從傳統的手工測試逐步發展為現在的自動化測試技術。手工測試往往需要技術人員付出大量的精力和體力，是一項工作量極大的過程。如今隨著社會的高速發展，信息技術的突飛猛進，軟件領域的競爭趨于白熱化，軟件正在向著復雜、尖端、多元化方向發展。大量的軟件程序開發出來，僅依靠效率低下的手工測試已經遠遠不能達到人們的需求。為了適應市場，自動化測試被開發出來，自動化測試的誕生極大的提高了工作效率，是測試用例的生成軟件測試是軟件質量保證的重要手段，也是目前軟件測試的發展方向。

1 軟件測試自動化基本概述

從上世紀六十年代開始人們就對軟件測試就行了研究，至今己有50余年的歷史。測試顧名思義就是對所開發的軟件產品進行檢查、評審和確認等過程，是對軟件產品質量所進行的自檢和自評。

（1）軟件測試的概念。軟件測試是軟件開發的過程中重要的一環，其工作一般是事先安排好工作計劃，然后較為全面系統的進行測試工作。是對軟件產品進行的自檢。該活動伴隨著軟件開發的每一步進行。通過軟件測試，可以檢測出軟件在運行過程中存在或者潛伏的各種錯誤或者缺陷，從而為開發者提供數據依據。

（2）軟件測試的種類。軟件測試的分類方法有很多，比如按軟件開發過程可分為單元測試、集成測試、系統測試及驗收測試；按軟件動作可分為升級變更的測試、重現故障測試、己有功能的測試、回歸測試、兼容性測試及恢復測試、安裝/卸載的測試等等；按測試方法，又可以分為黑箱測試及白箱測試；按用不用借助軟件，可以分為手動測試和自動化測試。

（3）典型的軟件測試問題。由于軟件系統的復雜性和不可預測性，在軟件測試過程中可能會出現一些問題，主要問題可歸結為以下幾個方面：項目存在風險性，在項目晚期才能真正降低；項目進度不易預測，加之項目負責人對所開發軟件實際狀況的了解程度不夠，造成管理上的問題。開發經費較高，如果在測試過程中錯誤沒被監測出來，后期的軟件錯誤修復費用會極高，同時也會造成整個項目的延遲，可能會導致開發項目成本的大幅度增加，據統計，近些年由軟件開發失誤所造成的經濟損失每年高達幾百億美元。

（4）自動化測試。測試自動化作為一種測試技術，通過設定的機制，可以自動對被測系統進行測試。測試自動化以較低的費用、徹底的測試、較高的產品質量作為目標。實現軟件測試自動化的趨勢己經不可逆轉了。自動化測試主要采用自動化工具提供的測試腳本對目標應用程序進行測試。自動化測試具有速度快、測試效率高、可靠性強、測試覆蓋率高通用性強、風險低信任度高、完成手工測試不能或難以完成的測試等特點。雖然自動化測試具有很多優點，但是其不是萬能的，也有其自身的局限性。

2 軟件測試自動化關鍵技術

（1）測試用例自動生成技術。測試用例的自動生成是實現自動化的關鍵所在，靠人為以及手工的方式產生測試用例是較傳統的方式，花費時間較長且質量不高，會有人為因素造成一定的錯誤，而自動生成的測試用例就可以避免此問題的生成。目前有面向路徑的測試用例及面向功能的測試用例兩種技術。面向路徑的技術是針對程序的內部結構的，需要對程序的邏輯路徑達到一定程度的覆蓋，是基于覆蓋的測試用例生成技術，通過覆蓋程序中所有路徑，找到程序的中隱秘的錯誤。面向路徑的方法主要有動態法、靜態法、隨機法及動態法。面向功能技術是以規格說明書作為支持，并根據說明書的需求生成相應的測試用例。面向功能技術可分為基于模型的、基于代數的以及基于有限狀態機的等。測試用例自動生成相關算法主要有遺傳算法、蟻群算法及粒子群算法。目前混合蛙跳算法在測試用例自動算法中也開始使用，此方法是一種全新群體智能算法，結合了模因算法和粒子算法兩者的優點。

（2）捕獲/回放。自動化測試使用的主要手段之一是捕獲/回放。技術人員通過對腳本進行捕捉回放，完成腳本的錄制工作。其主要記錄內容為所開發軟件的系統結構組件，以及所開發軟件對測試的具體操作步驟。測試結果一般是以文本格式存放。捕獲/回放一般有三種特定級別，即操作系統級別、硬件級別和進程級別。

（3）自動化測試模型選取。自動化測試模型一般可以分為三種，即合并式、獨立式及顧問式。其模型主要是為了在組織中實行自動化測試服務。合并式模型：主要工作有設計、開發、執行以及提交等。測試自動化工程師會參與到手工測試人員的每一項工作中，輔助其完成測試工作。獨立式模型：一個核心的測試自動化組負責進行自動化測試項目生命周期中的所有活動。這個小組要完成從自動化測試套件開始設計到間的所有任務。在顧問式模型中，負責給手工測試工程師培訓關于測試工具，測試方法的知識并為執行和鞏固活動提供基礎設施。

無論選取哪個模型，其最終的目的都是為了增加工作效率，提高軟件檢測過程的自動化水平。專門的測試自動化工程師被分配到每個測試項目中和手工測試人員一起工作，共同分擔著測試自動化項目的相關活動。在整個測試流程中，自動化測試工程師與手工測試工程師對需要進行自動化的測試用例進行研究討論，對原有的手工測試用例進行拆分使其符合自動化測試的需求。

3 結語

軟件測試是為了發現軟件錯誤以及潛在缺陷的過程，是保障軟件質量的關鍵技術之一。軟件自動化測試是軟件測試的一個重要組成部分，它可以完成許多手工測試無法實現或者難以實現的測試。對軟件測試自動化關鍵技術的分析具有很重要的意義。

參考文獻

[1]傅兵.軟件測試技術現狀與發展趨勢研究[J].電腦編程技巧與維護，2016（02）.

[2]林平榮.高校軟件測試自動化教學平臺的搭建[J].電腦知識與技術，2010（28）.

篇6

【關鍵詞】軟件 自動化 應用研究 測試

一款軟件從開發到，除了軟件設計編程之外，軟件測試也是不可或缺的一項中心環節。軟件測試在以往都是軟件開發人員自己檢測，但程序員卻無法將充足的時間用來測試，所以后來發展為軟件開發與測試兩者獨立，測試部分由測試部門負責。但這個過程人力物力消耗大，時間長，所以軟件自動化檢測技術也就應運而生。

1 軟件自動化測試

1.1 軟件自動化測試的概念

軟件的自動化測試是一種新的軟件測試技術，根據需要，可以將測試系統的運行環境進行調整，然后按照測試要求與目的設置相關程序功能，然后由系統按照設置好的程序對需要進行測試的軟件測試。其運用主要地方為：軟件開發完成后的測試以及維護測試。

1.2 軟件自動化測試的目標

通過軟件自動化測試技術進行新軟件測試，可以達到：用最少的經費，取得更完整徹底的測試結果，從而根據測試結果進行軟件的再修改，以此來提高軟件的質量。

1.3 軟件自動化測試的特點

較傳統的人工測試而言，軟件自動化測試具有如下特點：

1.3.1 在軟件版本升級后，進行再測試

其實這一點是這項檢測技術最基本也是最核心的任務。當一個軟件需要進行版本升級時，為了測試新版本軟件的性能，那么人工軟件測試與自動化軟件測試就無可比擬。版本更新周期短，不具有開發階段周期長這一特質。所以，利用軟件自動化測試技術，在省卻大量測試時間的同時，還可以加快新版本測試進度，降低版本升級的費用。

1.3.2 可持續測試

軟件自動化測試技術的另一大特點就是其可持續測試性，自動化測試只要機器運行，就可以一直測試下去，而手工測試卻無法具備測試持續性。這是人力測試無法解決的劣勢。

1.3.3 多任務性

人力有窮時，對于簡單軟件系統，人工測試還能勝任，但遇到諸如多元網絡傳輸系統，依靠人力對系統測試，是行不通的。但自動化軟件測試技術卻可以勝任，其可以同時對這些網元進行仿真模擬測試。所以，自動化測試具有多任務性。

1.3.4 人力資源利用率高

通過自動化軟件檢測技術，可以將更多地人力資源解放出來，讓有限的人力資源不再陷入繁瑣的測試當中。利用自動化檢測軟件可以讓工作人員只需要思考測試的目的，設計更好地測試方案，控制好測試軟件即可。

1.3.5 測試進程具有穩定性

利用軟件自動化測試技術，可以將測試的環境保持穩定一致，可以規避人力測試因外界因素影響測試過程，導致測試結果不準確這一問題。

1.3.6 測試過程與結果可做范例

軟件經過自動化測試之后，測試軟件就會將測試信息記錄下來，作為范例，當遇到相似測試項目時，這些信息也可以作參考或直接使用。這也是人力測試所不具備的。

1.4 軟件自動化測試所需技術

一款自動化測試軟件，其需要具備這幾樣必須條件：被測軟件信息輸入部、測試結果輸出部分以及多次測試結果對比部分。具備這三大部分，測試軟件才能實現自動化測試。

1.5 軟件自動化測試的不足

軟件自動化測試，其優點甚多，但并非萬能。自動化測試任然存在一些不足之處，這些都是自動化測試技術所無法具備的：

1.5.1 無法完全替代人工測試與測試工程師

有許多測試任務是自動化測試軟件無法完成的。這時候就需要用到人力測試以及測試工程師了。對于簡單的軟件測試，依靠人力測試即可解決，而不需要檢測軟件參與，檢測軟件每次測試，都需進行系統調試，對于簡單的測試，其調試時間與人力測試時間相當，這類情況檢測軟件的使用就不合時宜。還有一些類型也是軟件測試所無法替代的，例如：被測軟件運行不穩定，這時就需要人力進行測試，這樣方便調節。還有有一些需要人機交互的測試，測試軟件是一種設定好的程序，對于需要實時進行人機交互的測試來說，其自動化測試無法做到隨機應變。所以，自動化軟件測試是不能完全替代人工測試的。

1.5.2 軟件新版本的再測試沒人工發現bug多

自動化測試軟件的一大好處就是可重復測試，但當使用以往測試數據來測試同軟件的新版本之時，自動化軟件檢測所發現的bug往往會低于人工測試所發現的bug。

1.5.3 自動化軟件檢測對軟件開發存在一定制約

由于自動化軟件測試程序相對固定，當一些被測軟件有重大更新時，往往由于測試程序無法與新版本做到兼容，從而導致測試軟件崩潰。而自動化測試軟件的再設計與維護成本會比人工測試高，且自動化測試比人工測試影響要高，所以會對開發人員造成影響，綜合以上因素，會對一些被測軟件的重大更新部分造成修改限制。

所以，合理安排軟件自動化測試與人工軟件測試，將會更利于開發人員降低開發成本，減少測試時間，獲取高效益。

2 適合軟件自動化測試技術的領域與輔助測試工具

2.1 適用范圍

目前的軟件自動化測試適用于：單元/組件測試、BVT（版本測試）、集成測試、系統測試、回歸測試以及性能測試。

2.2 軟件自動化測試與人工測試使用環境總結

軟件自動化測試：該被測軟件項目無嚴格時間限制，有良好測試計劃與測試目的，測試內容涉及多平臺，涉及被測軟件運行所需硬件，被測軟件可以使用自動化軟件進行測試等這些情況下都可以使用軟件自動化測試。

人工軟件測試：沒有嚴格測試時間限制，沒有明確的測試目的與計劃，開發人員或軟件測試人員當中不會操作軟件自動化測試的，剛加入開發的新成員，沒有相關硬件等等這些情況就不是自動化軟件測試所能達到的。

2.3 軟件自動化測試所需工具

在軟件自動化測試進程中，還需要一些工具輔助軟件測試，目前按照使用環境可以分為：

2.3.1 管理型工具

管理型測試工具主要是對軟件測試的計劃、用到的測試用例、測試所需以及測試進程進行綜合管理，同時還能通過這些管理型工具發現自動化測試所存在的漏洞，并就這些測試漏洞進行管理跟蹤。而軟件的開發者和軟件測試人員能夠通過管理工具對被測軟件信息進行交流。

2.3.2 沙盒工具

所謂沙盒測試工具，就是在獨立環境下，對被測軟件內部代碼進行邏輯流程測試；而在測試中可以發現被測軟件的漏洞，并且能夠將這些缺陷定位，最高可定位至代碼級。

2.3.3 用來分析被測軟件在靜態環境下的工具

靜態軟件分析工具可以對被測軟件代碼直接掃描，在不需編譯的情況下進行測試分析。靜態軟件測試分析工具主要使用在：（1）代碼；對被測軟件進行語法掃描分析，找出代碼編寫錯誤的地方。（2）對被測軟件靜態情況下分析其結構，靜態測試工具會根據被測軟件代碼結構復雜程度，對軟件代碼的設計與模塊調用生成記錄圖表。

2.3.4 被測軟件動態環境運行分析工具

相對靜態軟件分析測試工具而言，動態分析工具的工作方式是利用釘釘子的方法，在被測軟件代碼中插入一段檢測代碼，這段代碼會在被測軟件運行時，對軟件數據與資源調用率進行統計分析。

2.3.5 功能測試分析工具

功能測試分析工具也可以稱之為黑盒工具，其工作流程是通過自動記錄被測軟件數據、檢測以及回溯客戶操作。通過對被測軟件測試前所預測結果進行對比，從而幫助開發人員與測試人員對不同版本的軟件進行功能測試分析，提高工作人員工作效率。黑盒工具其主要目的是：通過測試分析被測軟件程序能否達到預期設計目標以及穩定運行。

2.3.6 軟件性能測試分析工具

性能測試分析工具的目標是：分析測試被測應用軟件的可擴展性能。在測試過程中，通過性能測試分析工具可以幫助測試人員檢測軟件運行性能以及查找運行時所出問題。并且就檢測出的問題進行自動性能優化，保證應用軟件能夠正常進行測試運行。

2.3.7 輔助工具

這一類的測試工具其本身并不具備測試所需條件，輔助工具存在的目的就是將軟件測試過程中所搜集的數據信息生成記錄，為測試人員提供參考依據。

根據軟件測試過程所需工具，正確使用這些測試分析工具可以幫助測試人員更快，更高效完成軟件測試任務，縮短軟件周期。

3 合理設計軟件自動化的測試

3.1 設計中應當規避的情況

合理的自動化測試設計，可以提高工作效率，所以，在設計自動化測試時，應注意規避以下幾種情況：時間限制，沒有明確的測試目標，測試經驗不夠多，測試人員流動性高，對測試失去耐心和太偏重技術等。

3.2 測試軟件設計注意事項

在設計自動化測試軟件時，有幾點需要重點設計：

3.2.1 測試軟件的可維護性

過高的設備維護成本將會大大降低自動化測試軟件的實際應用性，所以，在設計自動化測試軟件的時候，軟件的可維護性是其中一大重點考慮對象。目前的自動測試軟件領域競爭激烈，而要想獲得高的市場占有率，那么具有低維護成本的測試軟件將占有極大優勢。維護包括測試軟件的日常維護以及測試軟件的版本更新，其中版本更新維護是維護重點。隨著軟件開發的深入，軟件自動化測試需要緊跟開發者的步伐，當測試軟件無法滿足測試需要時，那么自動化軟件將會逐漸丟棄淘汰。所以，保持更新步伐是需要重點考慮的。

3.2.2 可測性

可測性就是自動化測試對被測軟件的測試是否有效。所以，為了保證軟件的可測性，設計時應當使用擁有：CLI、API與GUI接口的測試軟件。

4 自動化測試與人工測試對比

自動化測試與人工軟件測試，其區別只是測試方式不同而已。從以上文章分析可以知曉自動化軟件測試其優點突出，但不足之處也是顯而易見。

自動化測試其根本性目的是將以往人工測試的過程精簡化、程序化和標準化。在一定程度上可以代替人工進行軟件測試。自動化測試的優點在于：自動化軟件測試可以按照軟件測試需要進行相應程序修改，然后利用符合測試需求的測試程序進行測試，在這過程中，相對簡單的測試部分可以依靠人工測試，對于那些有重復性，測試過程嚴謹的測試部分則可以利用自動化測試，達到測試目的。綜上，可以對軟件自動化測試與人工測試進行一個對比，首先是人工測試：

人工測試是一開始就使用的測試方式，人工測試需要測試人員有豐富的測試經驗。對于相對簡單的測試目標具有速度快，效率高的特點。尤其是在相關的人機交互測試這類靈活度較高，測試過程不可控的測試目標，人工測試具有快速反應，測試靈活等特點。相應的，人工測試也存在很大的弊端，人工測試人員受精力與時間限制，對于那些時間短、測試過程程序化與復雜化的測試目標，人工測試就需要耗費大量時間與人力資源來完成。這也導致了測試成本提高，效率低下。

軟件自動化測試與人工測試相比，自動化測試是按照測試程序對被測目標進行測試。所以對于那些重復性測試具有高效，測試過程嚴謹的特點。其所具備的強大數據處理能力對于那些測試過程中需要進行大量數據處理運算的測試任務具有高效的完成性。但其缺點也是明顯的，對于那些需要進行實時交互的測試目標來說，自動化測試的固定測試程序是無法勝任的。

綜上分析可以看出，人工測試與自動化測試之間有著明顯優缺點，但兩者也具有良好的互補性，所以合理搭配這兩種測試方式，將會極大提高測試任務的完成效率，有效降低測試成本與人工測試資源。

5 結束語

本文從軟件自動化測試的意義到應用進行了簡單討論分析，從各方面對比來看，軟件自動化測試在軟件測試行業中占有重要地位，在未來的發展中，應當加大對自動化測試的研究力度。讓自動化測試繼續發揮更大的作用。

參考文獻

[1]應杭.軟件自動化測試技術及應用研究[D]

[2]劉艷霞.軟件自動化測試技術應用研究[J]軟件導刊.2007，5：36-38

[3]蔡志賢.軟件自動化測試的研究與實踐[D]

[4]陳曉.軟件自動化測試的分析與實踐[J]計算機科學.2008.35（4）：282-322

[5]季淑引.軟件自動化測試工具的應用研究[J]科技向導.2012.20：59

[6]陳哲.軟件自動化測試系統的研究與實現[D]

作者簡介

張維利（1978-），男，山東省人。碩士學歷。主要研究方向為信息系統軟件測試、軟件可靠性等。

篇7

本文分析了虛擬儀器的特點，將模塊化設計思想引入到虛擬儀器的設計中，把分散、獨立的傳統儀器整合起來，設計出了滿足現有產品需求的液晶顯示器主板自動化測試系統。

【關鍵詞】液晶顯示器 自動化測試 虛擬儀器 儀器控制

隨著現代科學技術和現代工業生產的發展，對電子類產品測量和儀器技術的要求越來越高，測試對象和測試內容日益復雜，測試工作量與日俱增，對測試速度和測試精度的要求也不斷提高，這使得傳統的人工測試已經不適應甚至不能滿足實際測試的需求。因此，自動化測試技術成為了測控領域的重要發展方向之一。

1 國內外市場狀況

自動化測試系統的研制工作最早可追溯到20世紀50年代，美國為解決軍方在軍用電子設備維護中遇到的問題而開展了SETE計劃。現代測試內容日益復雜， 測試工作量激增，而且要求完成測試的時間越來越短，人工測試很難滿足這些要求，自動化測試技術因而得到迅速發展。較完善的自動化測試設備是 60 年代采用電子計算機以后才問世的。

自動化測試設備的發展經歷了三個階段：

（1）采用專用測試系統：這種測試主要用于小型化的工業測試，但不管是在接口上還是總線上，都沒有任何標準可言，因此也談不上通用性。

（2）臺式儀器積木型測試系統：采用標準化通用接口母線（GPIB）連接有關設備，系統中各組成部分均配標準化接口功能，用統一的無源母線電纜連接起來。不需要自行設計接口，可靈活地更改、增刪測試內容。計算機主要承擔系統的控制、計算和數據處理任務，基本上是模擬人工測試的過程，尚不能充分發揮計算機的功能。

（3）智能化測試系統：將計算機與測試設備融為一體，用計算機軟件代替傳統設備中某些硬件的功能，能用計算機產生激勵，完成測試功能，生成測試程序。

2 研究內容

基于以上探索，本文將深入研究以下幾個問題：

2.1 測試系統總體模型設計

將虛擬儀器與傳統儀器的特點做對比，找出虛擬儀器在液晶顯示器主板測試方面的優勢，把模塊化設計思想引入到虛擬儀器的開發中，綜合分析現有的硬件測試表單，設計、抽象出一種能滿足現有測試要求的設計模型。

2.2 多功能測試系統平臺搭建

在研究傳統儀器功能和操作基礎上，將分散的、獨立的、具有單一功能的傳統儀器，用獨立總線技術與計算機通訊接口建立連接，使單個儀器成為整個總線上的一個結點，從而搭建成一個符合目前液晶顯示器主板測試要求的多功能自動化測試系統。

2.3 系統總體調試和改進

在完成液晶顯示器主板測試系統平臺搭建后，在LabVIEW平臺上對整合后的虛擬儀器軟件系統進行測試，發現并修改其中的錯誤，直到其能正常無誤地運行。最后，再將自動化測試的結果與傳統儀器測試結果進行比對，進而對測試系統進行修正和改進。

2.4 測試數據智能處理

儀器直接采集到的測試數據，常常由于外界干擾造成數據不準確，或是單次抓到的數據不具有代表性，而造成得到的數據無效，不能滿足實際產品需要。為了過濾這些無效的測試數據，需要用其它手段對測試的數據進行智能處理，生成有效數據，再將測試的數據處理并寫入電子表格文件，生成測試報告。

3 技術路線

本課題的基本思路為：根據目前液晶顯示器主板測試要求和現有的測試表單，擬定系統需求方案書，抽象出系統總體模型。再選擇合適的總線和PC機，搭建硬件通訊平臺，實現對儀器的控制，然后設計自動化測試軟體前臺界面和后臺代碼。最后，將硬件平臺與軟件系統整合并調試，從而完成整個自動化測試系統的設計。

本課題可分為三大模塊，分別是TDS-3054示波器及Chroma 2325信號發生器控制模塊、液晶顯示器主板自動化測試模塊和測試數據智能處理模塊。系統總體框圖如圖1所示。

4 結論

通過把虛擬儀器與傳統儀器進行優缺點對比，將模塊化設計思想引入到虛擬儀器的設計中，把分散的、獨立的傳統儀器整合起來，設計并抽象出了滿足現有產品需求的液晶顯示器主板測試系統模型。利用LabVIEW圖形化編程軟件，在分析并總結現有產品測試表單的基礎上，開發出了符合要求的液晶顯示器主板測試平臺，包括自動化測試模塊和電子表格報告生成模塊。

參考文獻

[1]趙潔，張璐，李桃.論虛擬儀器LabVIEW的發展及應用[J].山西電子技術，2011（04）：87.

[2]舒梯翔.自動化測試技術的發展探討[J]. 宇航計測技術，2001，21（3）：46-59.

[3]Chen，S.，et al.，Application of virtual instrument technology in temperature control.Journal of Electronic Measurement and Instrument，2004（02）： p.1205-1207.25.

[4]傅大梅.液晶顯示驅動方法的探討[J].南京工業職業技術學報，2003，3（3）：27-30.

[5]趙高毅.通用串行總線在虛擬儀器技術中的應用研究[J].遵義師范學院學報，2008（0l）.

篇8

1提高電氣自動化控制設備可靠性的重要性

目前，隨著社會的不斷的發展，工業生產和人民生活對電氣產品的可靠性都提出了很高的要求。當然，在當前日益激烈的市場競爭中，可靠性較高的電氣產品在市場中所占的份額會有所增加。同時，電氣自動化設備的可靠性較高也會使得生產出的產品的質量較高。事實上，只有質量較好的產品才能在激烈的市場競爭中立于不敗之地。

2電氣自動化控制設備可靠性問題的分析

一般來講，電氣自動化控制設備中存在的一些可靠性的問題都是源于組成電氣控制設備的相關的元器件自身的質量有關。近年來，隨著電氣自動化的不斷的發展，元器件生產廠家的數量也在急劇增長，但是出現在市場上的元器件的質量是參差不齊的。因此，在制造電氣自動化設備的過程中，一定要嚴把元器件的質量關。因為，當前很多的企業中都存在著很多的管理問題。同時，市場上的惡性競爭也非常激烈，這就使得元器件不能得到企業的高度重視。因此一些元器件的參數指標的下降和壽命的縮短都對電氣控制設備帶來了極大的影響[1]。另外，當前電氣設備可靠性的問題與當前電氣設備使用的環境和維護的情況都有很大的關系。電氣設備的工作環境通常都是非常復雜的，同時多變的工作環境對電氣設備的影響也是有所不同的。目前，很重要的幾個因素就是氣候變化和電磁干擾。這樣會使得元器件的參數得到改變、損壞，進而使得設備的可靠性受到影響。

3電氣自動化控制設備可靠性的測試方法

上面我們對電氣自動化設備可靠性中存在的問題進行了分析，因此對電氣自動化控制設備的可靠性進行測試就顯得非常重要。下面筆者就當前比較科學的電氣設備測試方法進行闡述：

3.1保證試驗法

保證試驗法是一種非常常見的電氣設備可靠性檢測方法。它指的是在生產產品出廠之前，對其的一些參數指標進行測試，從而使得電氣設備能夠正常的使用。電氣自動化控制設備是由很多的器件組成的，因此電氣設備所出現的故障的種類也是非常多樣的。因此，可以根據電氣設備所生產出的產品中存在的不同的問題對其自身所出現的故障進行分析，從而來進行檢修和維護[2]。因此，企業可以通過保證試驗法來對電氣設備的可靠性進行檢測，從而能夠及時的發現其中所存在的問題。

3.2現場測試法

相對于前兩種測試方法，現場測試的方法的實用性是非常強的。這種方式是將電氣控制設備放置于一個真實的現場環境，來進行可靠性的測試。這種方式所得到的數據是非常科學有效的。通常是可以作為電氣控制設備可靠性測試的重要的參考依據。但是，這種測試方法對試驗條件或者周圍環境的要求比較高，對設備的質量的要求也比較高。因而，現場測試法的實現條件也是相對困難的。

3.3試驗室測試法

試驗室測試法主要指的是在可控制的環境中進行全方位的模擬測試。這種方式是將需要測試的設備放置于模擬環境中，這樣可以在模擬的環境中施加各種環境的壓力，并進行數據的測試。這樣就可以獲得一定的科學的數據記錄，并將數據在一定的系統中錄入，從而對數據進行科學、準確的分析，進而得到一套比較合理、可靠的參數體系。這種測試方法的可控性較強，可參考價值也比較高。但是試驗與實際環境還是存在著一定的差距的，因此試驗成本較高[3]。

4可靠性測試的建議

在對電氣設備可靠性進行測試的過程中會出現很多的問題，因而在這里我們就這些問題提出一些建議。即相關的工作者需要選擇質量較高的電氣元器件，同時還需要掌握一定的技術，從而使得電氣設備的工作環境比較適宜。另外，為保證器件的可靠性，需要在其應用于設備之前，逐個進行可靠性的測試。同時，器件的選擇也需要從優。除此之外，當前在電氣設備中存在的可靠性偏低的問題大都是由環境溫度所導致的[4]。通常在電氣設備運行的過程中，會散出大量的熱量，從而使得環境的問題提升，進而使得設備工作的適宜環境溫度超標，并導致器件的損壞。因此，在電氣設備工作的過程中，一定要控制好周圍環境，或者在設備上安裝散熱器，從而保證電氣設備的正常的運行。

5結語

篇9

關鍵詞：OA系統；軟件測試；測試方法；壓力測試

中圖分類號：TP393 文獻標識碼：A 文章編號：1009-3044（2014）25-6025-06

Research on Test Methods of Office Automation System

LI Zhu， JIANG Pan， LI Zhen-wei， DENG Hai-kang

（Office Automation Systems Management Office，Chongqing Jiaotong University， Chongqing 400074， China）

Abstract： With the popularization of computer， office automation system （OA system） development， obtained the widespread application in the organs， enterprises and institutions and other industries. However， due to high demand， the development of the office automation system function， the design and programming of OA system becomes more and more complex. The complexity of OA system design and make OA system testing more cumbersome and inefficient， so， how to achieve rapid， effective test of OA system has become an urgent problem to solve. Based on the OA system of Chongqing Jiao tong University as an example， the use of functional testing， conducted a comprehensive test of the system for 5 kinds of test methods for testing， security testing， reliability testing and stress testing， and achieved good results.

Key words： Office automation system； software test； test method； Stress test

1 概述

隨著計算機及網絡的迅速發展，人們為提高辦公效率，減少經費開支，開始尋求一種網上辦公方式，辦公自動化系統在此背景下應運而生。重慶交通大學辦公自動化系統的開發成功為學校實現雙校區協同運行、節約辦公成本、提高辦公效率做出了巨大貢獻。

然而，由于軟件系統規模和復雜程度的增加，使得OA系統規模巨大，編程復雜，為實現對辦公自動化系統改進，快速有效的OA系統軟件測試就成為重中之重。該文以重慶交通大學OA系統為例，通過功能測試、安全性測試、易用性測試、可靠性測試和壓力測試5種方法實現對該系統的測試，測試結果表明，以上測試快速、有效，能夠為OA系統的進一步改進提供依據。

2 OA系統概述

2.1 OA系統的概念及作用

辦公自動化系統是利用技術的手段提高辦公的效率，進而實現辦公自動化處理的系統。它采用Internet/Intranet技術，基于工作流的概念，使用戶方便快捷地共享信息，高效地協同工作；改變過去復雜、低效的手工辦公方式，實現迅速、全方位的信息采集、信息處理，為單位的管理和決策提供科學的依據。

2.2 重慶交通大學辦公自動化系統簡介

重慶交通大學辦公自動化系統（以下簡稱OA系統）是覆蓋校屬各單位的辦公信息管理系統。該系統是學校信息化建設與管理工作的重要組成部分，是實現網上辦公和信息資源共享，提高工作效率和管理水平的必要手段。

2.2.1 系統結構及組成

學校OA系統采用B/S結構。所有辦公數據，如公文、通知公告等信息均存放在服務器上。用戶通過瀏覽器登錄系統，進行相關事務的辦理，公文的運轉，文件、通知的查閱等操作。學校OA系統包括：待辦事務、日常辦公、網上審批、通知管理、信息、個人助理和系統維護七個部分。

2.2.2 黨政發文和校內來文運轉流程

黨政發文是學校黨委發文、行政發文和黨政辦公室發文的合稱，三種發文方式運轉流程大體一致，一個正常的黨政發文運轉流程見圖1。

校內來文是指校內運轉的各種請示、報告等。校內請示用于學校各職能部門、學院、直屬單位等二級單位向學校請示解決有關問題；校內報告用于以上單位向學校告知有關事項、事件。校內來文中請示一般要給出批復意見，報告要給出回復意見，具體流程見圖2。

3 軟件測試方法

3.1 軟件測試概述

3.1.1 軟件測試的定義及目的

軟件測試是在規定的條件下對程序進行操作，以發現程序錯誤，衡量軟件質量，并對其是否能滿足設計要求進行評估的過程，是使用人工或者自動手段來運行或測試某個系統的過程，其目的在于檢驗它是否滿足規定的需求或弄清預期結果與實際結果之間的差別。

3.1.2 軟件測試的原則

軟件測試的原則主要包含七個方面：1） 盡可能早的測試；2） 軟件測試應由第三方進行測試；3） 測試時要考慮全面，要盡量做到測試的全覆蓋，并要考慮一些嚴格狀況；4） 要特別注意測試中的群集現象；5） 當測試發現錯誤時，需要進一步進行確認；6） 為以后系統維護方便，要妥善保管測試資料；7） 測試要具有指導性，制定嚴格的測試計劃，同時要保證測試的時間。

3.1.3 軟件測試的目標

軟件測試的目標包括：（1） 發現一些可以通過測試避免的開發風險。2） 實施測試來降低所發現的風險。3） 確定測試何時可以結束。4） 在開發項目的過程中將測試看作是一個標準項目。

3.2 OA系統的測試方案及要求

3.2.1 OA系統測試方案設計

下面我們就針對 OA系統的特點從五個方面開展測試方案設計：功能測試、易用性測試[1]、安全性測試、可靠性測試和壓力測試。

3.2.2 OA系統測試要求

1） 只有企事業單位自身應用人員最熟悉辦公需求，因此專業設計人員在做測試設計之前需要充分和最終使用人員做好交流，以便真正能代表客戶驗收；其次，最好由本單位使用人員來進行測試執行，專業的測試人員在旁觀察。

2） 辦公 OA 系統自動化測試需要盡早考慮，需要在軟件需求分析階段就考慮好自動化測試需求。考慮到辦公 OA系統各工作流相對獨立，建議采用敏捷開發和測試流程，每迭代交付一個工作流。

4 重慶交通大學OA系統測試研究

4.1 功能測試

功能測試也叫黑盒測試，它不需要考慮整個軟件的內部結構及代碼，而是只需考慮軟件的各個功能。

4.1.1 單功能驗證

以重慶交通大學OA系統系統登錄為例，編寫測試用例。如要進入該系統，需輸入用戶名和密碼，只有當用戶名和密碼都正確時，才可登錄；當用戶名或密碼之一出現錯誤時，禁止用戶登錄[2]。

4.1.3 功能間交互驗證

功能間交互驗證是指當單功能點出現交互操作時，實現對系統功能的驗證。

4.2 易用性測試

重慶交通大學OA系統使用人員為校領導、各部門中層領導干部和各單位辦公室主任，因此，易用性測試主要在以上人員間開展。

4.2.1 校領導賬戶易用性測試

由于校領導平時工作繁忙，且要求較高，因此，校領導測試需要安排開發公司人員及辦公室人員陪同測試，由開發公司人員講解示范，校領導親手操作，黨政辦人員配合。當場提出修改意見，由黨政辦人員和開發公司人員記錄，然后修改。直到校領導滿意為止[4]。

4.2.2 處級領導干部賬戶易用性測試

處級領導干部賬戶易用性測試主要由校黨政辦人員進行當面指導，由處級領導干部親自操作，然后將使用感受及修改建議記錄，再送開發公司進行修改。

4.2.3 各部門OA秘書賬戶易用性測試

該部分主要測試由校黨政辦組織聯系開發公司人員對各部門OA秘書進行集中培訓，培訓過程中接受部門OA秘書提出的建議；由于培訓人員較多，且不能親手操作，因此，在培訓后，再由黨政辦人員對有疑問人員進行再次講解。查找易用性問題及建議，收集后送開發公司修改完善。

4.3 安全性測試

鑒于OA系統中運轉的公文都具有較高的安全性要求，因此如何保證OA系統安全就成為一個關鍵。安全性保證主要有兩個方面：網絡安全和賬戶安全，我校OA系統安全主要通過以下方法來保證：

4.3.1 網絡安全測試

網絡安全測試方法主要采用：（1）TCP和UDP連接測試：netstat （2）網絡鄰居信息探測工具：nbtstat （3）網絡主機掃描：HostScan （4）漏洞檢測：X-Scan （5）端口監控工具：Port Reporter五種方法進行測試。

經測試，我校OA系統網絡存在部分端口未屏蔽，存在安全隱患；其他方面的問題基本可以避免，系統采用了以下三種方法網絡安全防范手段：

1） 設置IP地址限定。鑒于OA系統用戶基本都是在上班時間進行OA系統訪問，因此，可以設置IP地址限定，非限定IP地址無法進行訪問，保證系統用戶均為設定用戶。

2） 加裝軟件防火墻。鑒于ESET NOD32防病毒軟件和360安全衛士在OA系統防護方面和木馬查殺方面的優秀表現，因此使用該軟件自帶防火墻和360防火墻相配合方式，對出入站通信規則進行設定，避免了非法數據的進入。

3） 邀請網絡安全專家對學校OA系統服務器網絡進行檢測，查找安全漏洞，修改組策略，保證系統網絡安全。

4.3.2 賬戶安全測試

賬戶安全測試主要采用病毒植入、盜號木馬、遠程控制等方式進行破壞性測試，測試結果表明：除非系統內部人員刻意破壞，否則基本可以保證賬戶安全。我校OA系統采用了如下方法：

1） 由于系統使用初期所有人員的密碼均為統一初始密碼，因此督促系統所有使用人員對密碼進行修改。且下發文件要求所有使用人員妥善保管用戶名及密碼并不定時修改，以避免用戶名和密碼遺失。

2） 在系統管理員賬戶中，對用戶登錄使用情況進行監控，若出現下班時間登錄或者頻繁操作者，則聯系相關人員進行確認，保證安全。

3） 邀請計算機安全專家對系統賬戶安全進行檢測，出具安全報告，保證用戶賬戶的安全穩定。

4.4 可靠性測試

4.4.1 工作流中斷

在系統使用過程中，經常出現工作流中斷場景，為保證各種流程的正常流轉，避免流程錯誤或中斷，在充分調研的基礎上，重慶交通大學OA系統采用E2Q Studio設計器，對流程進行跟蹤，隨時可根據需要對流程進行更改，保證了工作流的順利運轉。

4.4.2 硬件異常

硬件異常主要表現為網絡中斷、服務器斷電等，如何服務器在硬件異常時，保證系統及時恢復。

1） 當出現網絡中斷時，采用編程方式，在服務器使用ping命令檢測網絡，當網絡出現中斷時，服務器自動重啟，保證系統運轉正常

2） 當出現服務器斷電時，及時檢測斷電點，請后勤能源科及時修復。

4.4.3 數據可靠性測試

經測試，該系統為保證數據可靠性，采用了以下兩種機制：1） 定時數據備份機制，在系統中編程實現Oracle數據自動備份機制，每一個小時數據自動備份一次，保證系統數據隨時在最新狀態。2） 異地備份機制，數據備份后，將數據傳送到系統管理員計算機，進行異地備份，中午和晚上各一次，當OA系統服務器出現崩潰或數據丟失時，也可保證系統恢復后，數據在最新狀態。

4.5 壓力測試

本次采用MI公司的專業壓力測試工具LoadRunner 11，采用錄制＼回放的方法，即首先錄制系統用戶并發登錄，然后采用多線程的方式模擬大量客戶端向服務器方發送登錄請求，達到壓力測試的目的。

4.5.1 測試場景

表3

4.5.2 測試環境

服務器是一臺曙光服務器，安裝的軟件包括Tomcat 6.0 ，JAVA，Oracle 10g，使用2個筆記本模擬客戶端發出請求。

5 結束語

本文首先介紹OA系統的基本概念，然后對重慶交通大學OA系統進行了簡要論述，分析了OA系統測試方案及要求，然后根據上述方案，然后通過功能測試、易用性測試、安全性測試、可靠性測試和壓力測試5種測試方法對重慶交通大學OA系統進行了測試，實踐表明，以上測試結果快速有效，是OA系統測試提出的一種探索。然后限于OA系統規模巨大、編程復雜，因此，測試難免有一定的局限性，不可能形成一種通用測試方法。

參考文獻：

[1] 余麗萍，熊偉.淺析辦公自動化系統（OA）的測試[J].信息化建設，2012（5）.

[2] 范志琰.某公司OA系統的設計與測試[D]. 北京：北京郵電大學.2011

篇10

>> 基于Web的自動化測試框架研究 基于Selenium 的Web自動化測試框架 Web自動化測試框架的研究 PhantomJS在Web自動化測試中的應用 通過Selenium實現Web自動化測試的研究 基于Flex的自動化測試框架 軟件測試技術與自動化測試框架模型的研究與應用 基于RFT的企業自動化測試框架的構建和應用 結合Robot框架的Web Driver自動化測試解決方案 基于Java反射的APP自動化混合測試框架的研究與實現 自動化測試框架：自己的框架 基于WEB結構自動化的嵌入式測試平臺設計 基于JAVA的測試自動化設計應用 基于Smart的頁面自動化測試的研究 基于Python的軟件測試自動化平臺研究 基于AutoVue的自動化測試框架設計與實現 基于關鍵字的自動化軟件測試框架設計 基于U盤升級在自動化測試系統中的研究及應用 基于業務流程的SG―ERP自動化測試技術研究與應用 基于Appium的手機應用程序自動化測試研究 常見問題解答 當前所在位置：

[4]STAX Services User’s Guide,IBN Inc.

http：///current/staxug.pdf

[5]http：///

[6]Vincent Massol著,鮑志云譯.JUnit in Action[M].電子工業出版社,2004,11

[7]Giovanni Denaro,Andrea Polini,and Wolfgang Emmerich Performance Testing of Distributed Component Architectures.

/articles/2004

[8]Mark Fewster,Dorothy Graham.軟件測試自動化技術[M].北京:機械工業出版社

[9]Daniel Hofman."Boundary Values ang Automated Component Testing"Softw.Test Verif Relia b.9.3-26(1999)