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

篇1

【關(guān)鍵詞】控件ID 映射關(guān)系 自動化測試

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

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

1 實施過程

1.1 項目介紹

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

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

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

步驟1：定義控件屬性與預(yù)置測試腳本代碼之間的對應(yīng)關(guān)系。本環(huán)節(jié)是通過設(shè)置的相應(yīng)的對應(yīng)關(guān)系，在前期就降低控件的可變化性。

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

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

步驟3：針對讀入的控制屬性，查找到對應(yīng)的預(yù)置測試腳本代碼；大多數(shù)自動化測試并沒有這一步驟，通過讀入控件屬性，可以降低代碼的重復(fù)性，是本設(shè)計特有的環(huán)節(jié)。

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

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

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

2 附圖說明

2.1 測試流程

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

2.2 解決辦法

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

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

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

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

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

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

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

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

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

步驟6：輸出自動化測試腳本代碼產(chǎn)生的實際結(jié)果。

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

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

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

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

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

Step2：產(chǎn)品開發(fā)人員和自動化測試腳本代碼開發(fā)人員根據(jù)映射表為被測產(chǎn)品的每個控件設(shè)置控件類型、控件ID。

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

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

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

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

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

3 結(jié)論

篇2

關(guān)鍵詞 軟件測試 軟件自動化測試 測試用例

1軟件測試的相關(guān)概念

軟件測試是指在規(guī)定的條件下對程序進行操作，以發(fā)現(xiàn)程序錯誤，衡量軟件質(zhì)量，并對其是否能滿足設(shè)計要求進行評估的過程。

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

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

2.1軟件測試的步驟

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

2.2自動化測試的前提條件

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

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

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

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

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

3自動化測試的工具

3.1 QTP

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

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

3.2 WinRunner

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

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

3.3 Rational Robot

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

3.4 AdventNet QEngine

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

3.5 SilkTest

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

3.6 QA Run

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

3.7 Test Partner

是一自動化的功能測試工具，它專為測試基于微軟、Java和Web技術(shù)的復(fù)雜應(yīng)用而設(shè)計。它使測試人員和開發(fā)人員都可以使用可視的腳本編制和自動向?qū)砩煽芍貜?fù)的測試，用戶可以調(diào)用VBA的所有功能，并進行任何水平層次和細節(jié)的測試。TestPartner的腳本開發(fā)采用通用的、分層的方式來進行。沒有編程知識的測試人員也可以通過TestPartner的可視化導(dǎo)航器來快速創(chuàng)建測試并執(zhí)行。通過可視的導(dǎo)航器錄制并回放測試，每一個測試都將被展示為樹狀結(jié)構(gòu)，以清楚地顯現(xiàn)測試通過應(yīng)用的路徑。

3.8 Telelogic TAU

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

4自動化測試的過程

4.1自動化測試需求分析

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

4.2自動化測試框架的搭建

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

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

4.2.1公用的對象

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

4.2.2公用的環(huán)境

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

4.2.3公用的方法

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

4.2.4測試數(shù)據(jù)

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

5軟件自動化測試的優(yōu)缺點

5.1軟件自動化測試的優(yōu)點

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

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

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

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

（4）測試具有一致性和可重復(fù)性。由于測試是自動執(zhí)行的，每次測試的結(jié)果和執(zhí)行的內(nèi)容的一致性是可以得到保障的，從而達到測試的可重復(fù)的效果。

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

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

5.2軟件自動化測試的缺點

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

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

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

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

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

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

6自動化測試的意義

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

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

參考文獻

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

篇3

關(guān)鍵詞:存儲過程;自動化測試;測試用例;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

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

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

1 Juit的框架結(jié)構(gòu)

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

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

2) TestCase類

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

3) TestResult類

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

4) TestSuite類

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

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

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

2.1 存儲過程名和參數(shù)的獲取

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

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

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

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

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

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

3 改進的Junit框架

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

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

testSP_2009_10_18_17_27_00.xml

testSP_2009_10_18_17_30_00.xml

testSP_2009_10_18_17_32_00.xml

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

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

4 結(jié)束語

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

現(xiàn)有的測試框架可以擴展到Cactus(Apache Software開發(fā)的用來對服務(wù)器上的Java代碼進行測試的框架)框架上,實現(xiàn)從瀏覽器進行存儲過程測試用例的調(diào)用執(zhí)行,可以克服因為開發(fā)和生產(chǎn)環(huán)境之間可能存在的網(wǎng)絡(luò)、安全等因素而影響測試準確性的問題。

參考文獻:

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

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

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

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

篇4

關(guān)鍵詞:自動化測試;測試儀器;整體化測試平臺框架

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

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

1自動化測試簡介

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

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

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

2自動化測試實現(xiàn)的常見問題

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

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

測試環(huán)境(或拓撲)不同,如:有的自動化測試環(huán)境為單臺被測設(shè)備,有的需要多臺輔助測試設(shè)備,所實現(xiàn)的自動化測試方法也相應(yīng)有所不同。

2.1基于PC的自動化測試

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

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

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

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

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

其缺點在于無法深入到具體協(xié)議的內(nèi)部實現(xiàn)交互過程的測試,大多數(shù)的軟件bug都集中于協(xié)議交互過程,導(dǎo)致測試覆蓋率不高,需要一致性測試作為補充。

2.3自動化測試的管理

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

3整體化自動化測試平臺的設(shè)計

3.1測試環(huán)境的整體化

自動化測試的組網(wǎng)環(huán)境的簡化,可通過PC的網(wǎng)絡(luò)接口模擬實際的路由和交換設(shè)備,使用一個單獨鏈路作為被測設(shè)備配置鏈路,專門配置被測系統(tǒng)。測試鏈路用于測試報文收發(fā),被測設(shè)備配置和報文收發(fā)和編解碼通過腳本控制

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

測試鏈路:通過PC的網(wǎng)卡與被測設(shè)備通訊,在PC上運行各種模擬數(shù)據(jù)通信設(shè)備或協(xié)議的軟件,來達成減少測試環(huán)境中的測試設(shè)備的目的,所需模擬的測試設(shè)備多的時候可以增加PC的網(wǎng)絡(luò)接口。

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

測試環(huán)境的整體化,對于一些不可避免的需要組網(wǎng)環(huán)境的測試,目前業(yè)界已經(jīng)有一些比較常用的拓撲切換方法,如使用帶拓撲切換功能的網(wǎng)絡(luò)互連設(shè)備,通過對這樣的拓撲切換設(shè)備的自動化控制、操作來實現(xiàn)不同邏輯拓撲的切換功能,本文不做進一步的細節(jié)闡述。

3.2測試工具的整體化

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

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

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

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

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

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

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

測試儀器對測試設(shè)備的測試鏈路:自動化測試程序通過調(diào)用測試儀器提供的測試接口,實現(xiàn)對被測設(shè)備的各種測試操作,也包括報文收發(fā)、協(xié)議模擬等。

通過對兩者的有機結(jié)合,可以將測試PC對測試設(shè)備的測試鏈路與測試儀器對測試設(shè)備的測試鏈路進行統(tǒng)一控制,從而實現(xiàn)二者的交互。

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

構(gòu)造整體化的測試平臺,除了自動化測試本身外,還兼具測試用例管理、測試用例編輯、測試用例執(zhí)行、測試結(jié)果分析與測試結(jié)果統(tǒng)計反饋等功能。將整個自動化測試實現(xiàn)、使用、管理的過程統(tǒng)一在一個平臺上實現(xiàn)。

3.4整體化測試平臺框架

本章節(jié)討論整個整體化測試平臺如何進行構(gòu)建,形成整體統(tǒng)一的測試平臺框架。

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

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

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

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

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

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

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

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

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

參考文獻

篇5

關(guān)鍵詞：軟件 測試 自動化 技術(shù)

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

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

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

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

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

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

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

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

2 軟件測試自動化關(guān)鍵技術(shù)

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

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

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

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

3 結(jié)語

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

參考文獻

[1]傅兵.軟件測試技術(shù)現(xiàn)狀與發(fā)展趨勢研究[J].電腦編程技巧與維護，2016（02）.

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

篇6

【關(guān)鍵詞】軟件 自動化 應(yīng)用研究 測試

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

1 軟件自動化測試

1.1 軟件自動化測試的概念

軟件的自動化測試是一種新的軟件測試技術(shù)，根據(jù)需要，可以將測試系統(tǒng)的運行環(huán)境進行調(diào)整，然后按照測試要求與目的設(shè)置相關(guān)程序功能，然后由系統(tǒng)按照設(shè)置好的程序?qū)π枰M行測試的軟件測試。其運用主要地方為：軟件開發(fā)完成后的測試以及維護測試。

1.2 軟件自動化測試的目標

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

1.3 軟件自動化測試的特點

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

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

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

1.3.2 可持續(xù)測試

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

1.3.3 多任務(wù)性

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

1.3.4 人力資源利用率高

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

1.3.5 測試進程具有穩(wěn)定性

利用軟件自動化測試技術(shù)，可以將測試的環(huán)境保持穩(wěn)定一致，可以規(guī)避人力測試因外界因素影響測試過程，導(dǎo)致測試結(jié)果不準確這一問題。

1.3.6 測試過程與結(jié)果可做范例

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

1.4 軟件自動化測試所需技術(shù)

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

1.5 軟件自動化測試的不足

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

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

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

1.5.2 軟件新版本的再測試沒人工發(fā)現(xiàn)bug多

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

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

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

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

2 適合軟件自動化測試技術(shù)的領(lǐng)域與輔助測試工具

2.1 適用范圍

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

2.2 軟件自動化測試與人工測試使用環(huán)境總結(jié)

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

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

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

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

2.3.1 管理型工具

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

2.3.2 沙盒工具

所謂沙盒測試工具，就是在獨立環(huán)境下，對被測軟件內(nèi)部代碼進行邏輯流程測試；而在測試中可以發(fā)現(xiàn)被測軟件的漏洞，并且能夠?qū)⑦@些缺陷定位，最高可定位至代碼級。

2.3.3 用來分析被測軟件在靜態(tài)環(huán)境下的工具

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

2.3.4 被測軟件動態(tài)環(huán)境運行分析工具

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

2.3.5 功能測試分析工具

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

2.3.6 軟件性能測試分析工具

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

2.3.7 輔助工具

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

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

3 合理設(shè)計軟件自動化的測試

3.1 設(shè)計中應(yīng)當規(guī)避的情況

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

3.2 測試軟件設(shè)計注意事項

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

3.2.1 測試軟件的可維護性

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

3.2.2 可測性

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

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

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

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

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

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

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

5 結(jié)束語

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

參考文獻

[1]應(yīng)杭.軟件自動化測試技術(shù)及應(yīng)用研究[D]

[2]劉艷霞.軟件自動化測試技術(shù)應(yīng)用研究[J]軟件導(dǎo)刊.2007，5：36-38

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

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

[5]季淑引.軟件自動化測試工具的應(yīng)用研究[J]科技向?qū)?2012.20：59

[6]陳哲.軟件自動化測試系統(tǒng)的研究與實現(xiàn)[D]

作者簡介

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

篇7

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

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

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

1 國內(nèi)外市場狀況

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

自動化測試設(shè)備的發(fā)展經(jīng)歷了三個階段：

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

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

（3）智能化測試系統(tǒng)：將計算機與測試設(shè)備融為一體，用計算機軟件代替?zhèn)鹘y(tǒng)設(shè)備中某些硬件的功能，能用計算機產(chǎn)生激勵，完成測試功能，生成測試程序。

2 研究內(nèi)容

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

2.1 測試系統(tǒng)總體模型設(shè)計

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

2.2 多功能測試系統(tǒng)平臺搭建

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

2.3 系統(tǒng)總體調(diào)試和改進

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

2.4 測試數(shù)據(jù)智能處理

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

3 技術(shù)路線

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

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

4 結(jié)論

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

參考文獻

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

[2]舒梯翔.自動化測試技術(shù)的發(fā)展探討[J]. 宇航計測技術(shù)，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]傅大梅.液晶顯示驅(qū)動方法的探討[J].南京工業(yè)職業(yè)技術(shù)學報，2003，3（3）：27-30.

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

篇8

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

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

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

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

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

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

3.1保證試驗法

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

3.2現(xiàn)場測試法

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

3.3試驗室測試法

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

4可靠性測試的建議

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

5結(jié)語

篇9

關(guān)鍵詞：OA系統(tǒng)；軟件測試；測試方法；壓力測試

中圖分類號：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 概述

隨著計算機及網(wǎng)絡(luò)的迅速發(fā)展，人們?yōu)樘岣咿k公效率，減少經(jīng)費開支，開始尋求一種網(wǎng)上辦公方式，辦公自動化系統(tǒng)在此背景下應(yīng)運而生。重慶交通大學辦公自動化系統(tǒng)的開發(fā)成功為學校實現(xiàn)雙校區(qū)協(xié)同運行、節(jié)約辦公成本、提高辦公效率做出了巨大貢獻。

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

2 OA系統(tǒng)概述

2.1 OA系統(tǒng)的概念及作用

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

2.2 重慶交通大學辦公自動化系統(tǒng)簡介

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

2.2.1 系統(tǒng)結(jié)構(gòu)及組成

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

2.2.2 黨政發(fā)文和校內(nèi)來文運轉(zhuǎn)流程

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

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

3 軟件測試方法

3.1 軟件測試概述

3.1.1 軟件測試的定義及目的

軟件測試是在規(guī)定的條件下對程序進行操作，以發(fā)現(xiàn)程序錯誤，衡量軟件質(zhì)量，并對其是否能滿足設(shè)計要求進行評估的過程，是使用人工或者自動手段來運行或測試某個系統(tǒng)的過程，其目的在于檢驗它是否滿足規(guī)定的需求或弄清預(yù)期結(jié)果與實際結(jié)果之間的差別。

3.1.2 軟件測試的原則

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

3.1.3 軟件測試的目標

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

3.2 OA系統(tǒng)的測試方案及要求

3.2.1 OA系統(tǒng)測試方案設(shè)計

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

3.2.2 OA系統(tǒng)測試要求

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

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

4 重慶交通大學OA系統(tǒng)測試研究

4.1 功能測試

功能測試也叫黑盒測試，它不需要考慮整個軟件的內(nèi)部結(jié)構(gòu)及代碼，而是只需考慮軟件的各個功能。

4.1.1 單功能驗證

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

4.1.3 功能間交互驗證

功能間交互驗證是指當單功能點出現(xiàn)交互操作時，實現(xiàn)對系統(tǒng)功能的驗證。

4.2 易用性測試

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

4.2.1 校領(lǐng)導(dǎo)賬戶易用性測試

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

4.2.2 處級領(lǐng)導(dǎo)干部賬戶易用性測試

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

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

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

4.3 安全性測試

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

4.3.1 網(wǎng)絡(luò)安全測試

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

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

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

2） 加裝軟件防火墻。鑒于ESET NOD32防病毒軟件和360安全衛(wèi)士在OA系統(tǒng)防護方面和木馬查殺方面的優(yōu)秀表現(xiàn)，因此使用該軟件自帶防火墻和360防火墻相配合方式，對出入站通信規(guī)則進行設(shè)定，避免了非法數(shù)據(jù)的進入。

3） 邀請網(wǎng)絡(luò)安全專家對學校OA系統(tǒng)服務(wù)器網(wǎng)絡(luò)進行檢測，查找安全漏洞，修改組策略，保證系統(tǒng)網(wǎng)絡(luò)安全。

4.3.2 賬戶安全測試

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

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

2） 在系統(tǒng)管理員賬戶中，對用戶登錄使用情況進行監(jiān)控，若出現(xiàn)下班時間登錄或者頻繁操作者，則聯(lián)系相關(guān)人員進行確認，保證安全。

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

4.4 可靠性測試

4.4.1 工作流中斷

在系統(tǒng)使用過程中，經(jīng)常出現(xiàn)工作流中斷場景，為保證各種流程的正常流轉(zhuǎn)，避免流程錯誤或中斷，在充分調(diào)研的基礎(chǔ)上，重慶交通大學OA系統(tǒng)采用E2Q Studio設(shè)計器，對流程進行跟蹤，隨時可根據(jù)需要對流程進行更改，保證了工作流的順利運轉(zhuǎn)。

4.4.2 硬件異常

硬件異常主要表現(xiàn)為網(wǎng)絡(luò)中斷、服務(wù)器斷電等，如何服務(wù)器在硬件異常時，保證系統(tǒng)及時恢復(fù)。

1） 當出現(xiàn)網(wǎng)絡(luò)中斷時，采用編程方式，在服務(wù)器使用ping命令檢測網(wǎng)絡(luò)，當網(wǎng)絡(luò)出現(xiàn)中斷時，服務(wù)器自動重啟，保證系統(tǒng)運轉(zhuǎn)正常

2） 當出現(xiàn)服務(wù)器斷電時，及時檢測斷電點，請后勤能源科及時修復(fù)。

4.4.3 數(shù)據(jù)可靠性測試

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

4.5 壓力測試

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

4.5.1 測試場景

表3

4.5.2 測試環(huán)境

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

5 結(jié)束語

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

參考文獻：

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

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

篇10

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

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

http：///current/staxug.pdf

[5]http：///

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

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

/articles/2004

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

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