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

篇1

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

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

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

1 實(shí)施過程

1.1 項(xiàng)目介紹

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

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

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

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

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

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

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

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

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

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

2 附圖說明

2.1 測試流程

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

2.2 解決辦法

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

每個(gè)項(xiàng)目都需要人員的配合。需要需求人員、產(chǎn)品開發(fā)人員和自動(dòng)化測試腳本代碼開發(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í)行自動(dòng)化測試腳本來最終產(chǎn)生測試結(jié)果。具體步驟如圖1所示，包括：

步驟1：我們要先讀取用戶編寫的測試用例，例如可以連接測試用例管理工具，從存儲有用戶編寫測試用例的測試用例管理工具中讀取，測試用例中的控件類型和操作命令、自動(dòng)化測試腳本中的控件類型和操作命令、被測試系統(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)的某個(gè)測試單元，例如，一個(gè)文本框、一個(gè)多選框、一個(gè)單選框等。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3 結(jié)論

篇2

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

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

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

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

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

2.1軟件測試的步驟

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

2.2自動(dòng)化測試的前提條件

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

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

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

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

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

3自動(dòng)化測試的工具

3.1 QTP

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

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

3.2 WinRunner

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

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

3.3 Rational Robot

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

3.4 AdventNet QEngine

AdventNet QEngine是一個(gè)應(yīng)用廣泛且獨(dú)立于平臺的自動(dò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)用程序進(jìn)行測試。此工具以Java開發(fā)，因此便于移植和提供多平臺支持。

3.5 SilkTest

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

3.6 QA Run

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

3.7 Test Partner

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

3.8 Telelogic TAU

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

4自動(dòng)化測試的過程

4.1自動(dòng)化測試需求分析

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

4.2自動(dòng)化測試框架的搭建

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

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

4.2.1公用的對象

不同的測試用例會(huì)有一些相同的對象被重復(fù)使用，比如窗口、按鈕、頁面等。這些公用的對象可被抽取出來，在編寫腳本時(shí)隨時(shí)調(diào)用。當(dāng)這些對象的屬性因?yàn)樾枨蟮淖兏淖儠r(shí)，只需要修改該對象屬性即可，而無需修改所有相關(guān)的測試腳本。

4.2.2公用的環(huán)境

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

4.2.3公用的方法

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

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

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

5軟件自動(dòng)化測試的優(yōu)缺點(diǎn)

5.1軟件自動(dòng)化測試的優(yōu)點(diǎn)

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

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

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

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

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

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

（6）此外，手工不能做的事情，自動(dòng)化測試能做，如負(fù)載、性能測試等。

5.2軟件自動(dòng)化測試的缺點(diǎn)

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

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

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

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

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

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

6自動(dòng)化測試的意義

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

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

參考文獻(xiàn)

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

篇3

關(guān)鍵詞:存儲過程;自動(dòng)化測試;測試用例;Junit框架;XML

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

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

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

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

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

2) TestCase類

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

3) TestResult類

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

4) TestSuite類

TestSuite對象是測試實(shí)例的集合,負(fù)責(zé)包裝和運(yùn)行所有的TestCase。

2 存儲過程測試代碼的自動(dòng)生成

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

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

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

要為存儲過程自動(dòng)生成測試代碼,有一個(gè)前提條件是被測試的存儲過程已經(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 測試代碼中存儲過程的運(yùn)行

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

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

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

3 改進(jìn)的Junit框架

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

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

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

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

4 結(jié)束語

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

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

參考文獻(xiàn):

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

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

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

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

篇4

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

中圖分類號:TP311文獻(xiàn)標(biāo)識碼:A

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

1自動(dòng)化測試簡介

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

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

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

2自動(dòng)化測試實(shí)現(xiàn)的常見問題

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

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

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

2.1基于PC的自動(dòng)化測試

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

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

2.2基于測試儀器的自動(dòng)化測試

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

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

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

2.3自動(dòng)化測試的管理

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

3整體化自動(dòng)化測試平臺的設(shè)計(jì)

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

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

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

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

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

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

3.2測試工具的整體化

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

運(yùn)用測試儀器提供的擴(kuò)展命令接口,PC通過腳本控制測試儀器端口協(xié)議報(bào)文的流量發(fā)送,批量統(tǒng)計(jì)。同時(shí)可通過PC控制網(wǎng)卡適配器報(bào)文的收發(fā),進(jìn)行功能測試等。物理拓?fù)浯罱▓D如圖1所示:

如圖1所示,測試PC充當(dāng)了兩個(gè)角色:

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

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

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

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

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

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

3.3自動(dòng)化測試管理的整體化

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

3.4整體化測試平臺框架

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

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

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

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

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

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

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

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

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

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

參考文獻(xiàn)

篇5

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

中圖分類號：TP311.5 文獻(xiàn)標(biāo)識碼：A 文章編號：1007-9416（2016）06-0234-01

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

1 軟件測試自動(dòng)化基本概述

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

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

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

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

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

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

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

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

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

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

3 結(jié)語

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

參考文獻(xiàn)

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

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

篇6

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

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

1 軟件自動(dòng)化測試

1.1 軟件自動(dòng)化測試的概念

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

1.2 軟件自動(dòng)化測試的目標(biāo)

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

1.3 軟件自動(dòng)化測試的特點(diǎn)

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

1.3.1 在軟件版本升級后，進(jìn)行再測試

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

1.3.2 可持續(xù)測試

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

1.3.3 多任務(wù)性

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

1.3.4 人力資源利用率高

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

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

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

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

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

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

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

1.5 軟件自動(dòng)化測試的不足

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

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

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

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

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

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

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

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

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

2.1 適用范圍

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

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

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

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

2.3 軟件自動(dòng)化測試所需工具

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

2.3.1 管理型工具

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

2.3.2 沙盒工具

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

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

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

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

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

2.3.5 功能測試分析工具

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

2.3.6 軟件性能測試分析工具

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

2.3.7 輔助工具

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

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

3 合理設(shè)計(jì)軟件自動(dòng)化的測試

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

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

3.2 測試軟件設(shè)計(jì)注意事項(xiàng)

在設(shè)計(jì)自動(dòng)化測試軟件時(shí)，有幾點(diǎn)需要重點(diǎn)設(shè)計(jì)：

3.2.1 測試軟件的可維護(hù)性

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

3.2.2 可測性

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

4 自動(dòng)化測試與人工測試對比

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

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

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

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

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

5 結(jié)束語

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

參考文獻(xiàn)

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

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

[3]蔡志賢.軟件自動(dòng)化測試的研究與實(shí)踐[D]

[4]陳曉.軟件自動(dòng)化測試的分析與實(shí)踐[J]計(jì)算機(jī)科學(xué).2008.35（4）：282-322

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

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

作者簡介

張維利（1978-），男，山東省人。碩士學(xué)歷。主要研究方向?yàn)樾畔⑾到y(tǒng)軟件測試、軟件可靠性等。

篇7

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

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

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

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

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

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

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

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

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

2 研究內(nèi)容

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

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

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

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

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

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

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

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

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

3 技術(shù)路線

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

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

4 結(jié)論

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

參考文獻(xiàn)

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

[2]舒梯翔.自動(dòng)化測試技術(shù)的發(fā)展探討[J]. 宇航計(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ū)動(dòng)方法的探討[J].南京工業(yè)職業(yè)技術(shù)學(xué)報(bào)，2003，3（3）：27-30.

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

篇8

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

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

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

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

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

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

3.1保證試驗(yàn)法

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

3.2現(xiàn)場測試法

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

3.3試驗(yàn)室測試法

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

4可靠性測試的建議

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

5結(jié)語

篇9

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

中圖分類號：TP393 文獻(xiàn)標(biāo)識碼：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 概述

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

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

2 OA系統(tǒng)概述

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

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

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

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

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

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

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

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

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

3 軟件測試方法

3.1 軟件測試概述

3.1.1 軟件測試的定義及目的

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

3.1.2 軟件測試的原則

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

3.1.3 軟件測試的目標(biāo)

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

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

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

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

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

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

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

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

4.1 功能測試

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

4.1.1 單功能驗(yàn)證

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

4.1.3 功能間交互驗(yàn)證

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

4.2 易用性測試

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

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

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

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

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

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

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

4.3 安全性測試

鑒于OA系統(tǒng)中運(yùn)轉(zhuǎn)的公文都具有較高的安全性要求，因此如何保證OA系統(tǒng)安全就成為一個(gè)關(guān)鍵。安全性保證主要有兩個(gè)方面：網(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ò)主機(jī)掃描：HostScan （4）漏洞檢測：X-Scan （5）端口監(jiān)控工具：Port Reporter五種方法進(jìn)行測試。

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

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

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

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

4.3.2 賬戶安全測試

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

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

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

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

4.4 可靠性測試

4.4.1 工作流中斷

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

4.4.2 硬件異常

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

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

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

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

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

4.5 壓力測試

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

4.5.1 測試場景

表3

4.5.2 測試環(huán)境

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

5 結(jié)束語

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

參考文獻(xiàn)：

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

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

篇10

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

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