專利名稱：一種軟件測試的方法
技術領域：
本發(fā)明涉及一種軟件測試的方法，尤其涉及一種基于腳本語言的測試含有通信接口的軟件的方法。
背景技術：
當前，軟件越來越復雜，其規(guī)模越來越大。開發(fā)一個軟件往往要做若干版本，經過每個版本的詳細測試和缺陷(bug)修改后，軟件才會逐步穩(wěn)定，達到可用的程度。一個大型軟件每個版本測試的工作量都是很大的，在人力資源成本日益增加的今天，如何減少測試的工作量，或者實現大部分測試工作的自動化，是本領域技術人員所要研究的重要課題。
目前，使用測試工具對軟件TCP/IP接口進行測試時，一般可以分為數據輸入、結果輸出、結果比較三步。首先，測試工具發(fā)送命令幀給被測軟件，被測軟件根據收到的命令幀，輸出相應的應答消息幀給測試工具，然后，進行結果的比較。目前，結果比較需要人工完成，即手工測試。
在手工測試方案中測試工具收到被測軟件發(fā)出的應答幀后，通過一定的方式把應答幀顯示在屏幕上，由測試人員肉眼觀察應答幀內容，并與預期結果比較。如果收到的應答幀與預期結果一致，則該測試用例的測試結果為通過。否則為不通過。在這種方案中，結果比較這一步在測試人員的大腦中完成，有的應答幀內容非常復雜，結果比較的時候就非常吃力，也容易出錯，使得測試人員容易疲勞，測試效率較低。
因而，現有的技術存在著測試效率低，且長時間工作后容易出錯，需要使用大量的測試工程師，人力成本高的缺點。

發(fā)明內容
本發(fā)明的目的是提供一種軟件測試的方法，實現特定軟件的自動化測試，提高測試效率，并提高測試的準確性。
為實現上述目的，本發(fā)明提供了一種軟件測試的方法，包括以下步驟1)建立與被測軟件的連接；2)構造測試用例的測試命令幀并將所構造的測試命令幀發(fā)送給被測軟件；3)生成所述測試命令幀的等待幀，所述等待幀中包含所述測試用例的預期結果；4)比較所述等待幀和所述被測軟件返回的執(zhí)行結果幀，如果兩者一致，則判斷測試結果為通過，否則為不通過。
優(yōu)選地，所述等待幀和所述執(zhí)行結果幀的比較方法為如果所述兩個幀每個字節(jié)都一樣，則認為這兩個幀一致，否則為不一致。
優(yōu)選地，所述等待幀和所述執(zhí)行結果幀的比較方法為只比較關心的字段，如果所關心的字段都一樣，則認為兩個幀一致，否則為不一致。
優(yōu)選地，在所述步驟2)之后進一步包括設定等待所述被測軟件返回執(zhí)行結果幀的時間，如果在設定的時間內，未收到所述執(zhí)行結果幀，則判斷測試結果為不通過，否則執(zhí)行步驟4)進行所述等待幀和所述執(zhí)行結果幀的比較。
具體地，所述幀結構包括幀頭和數據區(qū)，所述幀頭長度固定，包含命令字字段、數據區(qū)長度字段，所述數據區(qū)長度是可變的，由所述幀頭中的數據區(qū)長度指定。
優(yōu)選地，所述被測軟件的通信接口為TCP/IP接口、E1線接口或串口線接口。
優(yōu)選地，所述方法用于對所述被測軟件的通信接口進行測試。
優(yōu)選地，所述測試命令幀由腳本語言創(chuàng)建和/或發(fā)送。
優(yōu)選地，所述等待幀由腳本語言創(chuàng)建。
優(yōu)選地，所述腳本語言為工具命令語言(TCL)或腳本語言“龍蛇”(python)。
使用本發(fā)明的方法，可以避免每個版本測試中的重復勞動，從而提高測試效率。并且由于工具是不會疲勞的，只要測試腳本正確，那么測試工具的測試結果是可靠的，因而可以提高測試的準確率，降低人力資源成本。


圖1是應用本發(fā)明一個實施例的軟件測試的方法的測試工具與被測軟件的連接關系示意圖；圖2是本發(fā)明的軟件測試的方法的一個實施例的流程圖；圖3是本發(fā)明所使用的幀的幀結構一個實施例的示意圖。
具體實施例方式
下面結合附圖對本發(fā)明的優(yōu)選實施例進行詳細的說明，附圖僅用于說明，不是對本發(fā)明保護范圍的限制。
圖1示出了應用本發(fā)明一個實施例的軟件測試的方法的測試工具與被測軟件的連接關系示意圖。其中測試工具一般為軟件，可以與被測軟件在不同的硬件上也可以在同一硬件上。測試工具可以運行于普通PC上，如果被測軟件是一完整系統(tǒng)，如一路由器，則被測軟件與測試工具在不同的硬件上。如果被測軟件是一純軟件，則可以在同一計算機上。在圖1所示的實施例中，應用本發(fā)明的軟件測試的方法的自動化測試工具通過TCP/IP協(xié)議與被測軟件通訊，其發(fā)出測試命令幀，接收被測軟件的相應執(zhí)行輸出，并與預期結果(在軟件測試中，執(zhí)行一個測試用例后，希望得到的結果)比較。在其它的實施例中，也可以通過串口線、E1線等接口與被測軟件連接。
圖2是本發(fā)明的軟件測試的方法的一個實施例的流程圖。如圖2所示，在本發(fā)明的一個實施例中，軟件測試的方法包括的具體步驟為1.被測軟件初始化；即被測軟件的啟動，如果被測軟件是一個嵌入式系統(tǒng)，則包括硬件初始化和軟件的啟動，如網口的初始化、TCP/IP協(xié)議棧初始化等；如果被測軟件是純軟件，則是指軟件的啟動。
2.建立與被測軟件連接；
3.構造并發(fā)送測試用例的測試命令幀；4.生成上述測試命令幀的等待幀，所述等待幀中含有所述測試用例的預期結果；5.被測軟件收到測試命令幀后，經過一系列運算或操作，返回執(zhí)行結果幀；6.收到被測軟件的執(zhí)行結果幀后，比較被測軟件的執(zhí)行結果幀和含有預期結果的等待幀，如果兩者一致，則該測試用例的測試結果為PASS(通過)，否則為FAILED(不通過)；7.重復所述步驟3到6，直到所有的測試用例執(zhí)行完畢。
下面對上述步驟進行詳細的說明。
建立連接的方法是公知的。依據被測軟件所具有的通信接口，建立測試工具與被測軟件的連接。以對具有TCP/IP接口的軟件進行測試為例，建立連接可以是在被測軟件與測試工具之間建立套接字(socket)連接，在一方建立服務器套接字(Server Socket)，在另一方建立客戶機套接字(Client Socket)。可以使用TCL(工具命令語言，一種腳本語言)擴展命令建立套接字連接，也可以使用其它的方法建立套接字連接，這些建立套接字的方法是本領域的技術人員所公知的，所以本文不予贅述。當然，也可以不采用套接字連接，而直接使用TCP/IP?？傊梢圆捎帽绢I域技術人員所公知的任何方法來建立測試工具與被測軟件建立連接。
建立連接以后，構造并發(fā)送測試命令幀。圖3示出了本發(fā)明所使用的命令幀的幀結構的一個示例。如圖3所示，幀結構包括幀頭和數據區(qū)。幀頭長度固定，包含幀序號(表示第幾個幀)、幀類型(表示二進制或文本類型，取值0～1)、命令字(命令含義，100～10000，四個字節(jié))、數據區(qū)長度、IP地址、端口號等，數據區(qū)長度是可變的，由幀頭中的數據區(qū)長度指定。對于命令幀，數據區(qū)存放除了命令字外命令的其他參數(需要時)。例如，如果一個測試用例是啟動OSPF協(xié)議，該被測軟件中定義的啟動OSPF協(xié)議的命令碼是1001，則測試工具構造一個命令幀，在命令字字段填上1001(此用例不用填寫數據區(qū))。后文描述的等待幀、執(zhí)行結果幀與命令幀的幀結構是相同的。應該注意，圖3所示的幀結構只是一個示例而已，可以依據本發(fā)明的原理對其進行各種修改，這對于本領域的技術人員來說，都是顯而易見的，因而本文不一一列舉。
在構造并發(fā)送測試命令的步驟中，構造命令幀可以采用TCL擴展命令NewCurFrame和FillCurFrame實現。其中NewCurFrame新建一個空的幀，FillCurFrame用指定的內容填充由NewCurFrame新建的空幀。所謂指定的內容即根據具體的測試用例確定要填充的內容。發(fā)送命令幀由TCL擴展命令send實現。發(fā)送命令幀之后，等待被測軟件的應答。使用腳本語言建立和發(fā)送命令幀，可以比較靈活地修改命令幀(以及后文所述的等待幀)中內容，一般修改時無需重新修改源代碼、重新編譯測試工具，可以有效地提高效率。
隨后，創(chuàng)建用來放置預期結果的等待幀，根據測試用例的內容，用測試用例的預期結果填充所創(chuàng)建的等待幀。仍以上文所述的啟動OSPF協(xié)議的測試用例為例，如被測軟件支持OSPF協(xié)議，且還沒有啟動OSPF協(xié)議，則測試工具發(fā)送啟動OSPF協(xié)議命令后，被測軟件如果執(zhí)行成功，將返回一個結果(例如0000)，則在該例中，預期結果就是0000。將0000填入等待幀的數據區(qū)中。等待幀的創(chuàng)建、填充優(yōu)選地由TCL擴展命令NewWaitFrame、FillWaitFrame實現。其中，NewWaitFrame新建用來放置預期結果的等待幀，就是在內存中開辟一塊區(qū)域，用來存放等待幀。FillWaitFrame用指定的內容填充所創(chuàng)建的等待幀，即給幀頭的各個字段賦值，并把預期結果存放到數據區(qū)。
被測軟件在收到命令幀之后，會根據命令幀中的內容進行一系列的運算，并返回含有執(zhí)行結果的執(zhí)行結果幀。
如果在指定的時間內未收被測軟件返回的執(zhí)行結果幀，則認為該測試用例為不通過(FAILED)，如果在指定的時間內收到了執(zhí)行結果幀，則與前面創(chuàng)建的等待幀比較。如果兩者一致，則通過(PASS)，否則為不通過。
具體地，比較的過程為，測試工具收到來自被測軟件的執(zhí)行結果幀后，在內存中開辟一塊區(qū)域，存放結果幀；然后比較該執(zhí)行結果幀和等待幀?？梢圆捎弥鹱止?jié)比較的方法進行比較，即如果每個字節(jié)都一樣，則認為這兩個幀一致，否則為不一致；也可以采用關心字段比較法，即只比較關心的字段，如果所關心的字段都一樣，則認為兩個幀一致，否則為不一致。仍以上文所述的啟動OSPF協(xié)議的測試用例為例，可以只關心命令字字段和數據區(qū)中的內容，如果被測系統(tǒng)返回的幀中，命令字字段為啟動OSPF命令(1001)，且數據區(qū)內容為0000，則認為啟動OSPF這個測試用例執(zhí)行成功。
本領域的技術人員應該意識到，本發(fā)明的方法中所涉及的TCL擴展命令的部分也可使用其他腳本語言，如python(龍蛇)語言，來實現。其中，python語言的編程可以參見O’Reilly于1999年4月出版的MarkLutz等箸的《Learning Python》(ISBN1-56592-464-9，384pages)以及O’Reilly于2001年5月出版的Fredrick Lundh箸的《PythonStandard Library》(ISBN0-596-00096-0)。
雖然本發(fā)明是通過優(yōu)選實施例進行說明的，但是本領域技術人員應當理解本發(fā)明并不限于這些實施例，而是可以在不脫離本發(fā)明實質的情況下對其進行各種變化和修改。因此，本發(fā)明的范圍只由權利要求及其等同物來確定。
權利要求
1.一種軟件測試的方法，包括以下步驟1)建立與被測軟件的連接；2)構造測試用例的測試命令幀并將所構造的測試命令幀發(fā)送給被測軟件；3)生成所述測試命令幀的等待幀，所述等待幀中包含所述測試用例的預期結果；4)比較所述等待幀和所述被測軟件返回的針對所述測試命令幀的執(zhí)行結果幀，如果兩者一致，則判斷測試結果為通過，否則為不通過。
2.根據權利要求1所述的方法，其特征在于，所述等待幀和所述執(zhí)行結果幀的比較方法為比較兩個幀的每個字節(jié)，如果所述兩個幀每個字節(jié)都一樣，則認為這兩個幀一致，否則為不一致。
3.根據權利要求1所述的方法，其特征在于，所述等待幀和所述執(zhí)行結果幀的比較方法為只比較關心的字段，如果所關心的字段都一樣，則認為兩個幀一致，否則為不一致。
4.根據權利要求1所述的方法，其特征在于，在所述步驟2)之后進一步包括設定等待所述被測軟件返回執(zhí)行結果幀的時間，如果在設定的時間內，未收到所述執(zhí)行結果幀，則判斷測試結果為不通過，否則執(zhí)行步驟4)進行所述等待幀和所述執(zhí)行結果幀的比較。
5.根據權利要求1所述的方法，其特征在于，所述各幀的結構包括幀頭和數據區(qū)，所述幀頭長度固定，包含命令字字段、數據區(qū)長度字段，所述數據區(qū)長度是可變的，由所述幀頭中的數據區(qū)長度指定。
6.根據權利要求1所述的方法，其特征在于，所述被測軟件帶有從包括TCP/IP接口、串口線接口和E1線接口的組中選出的通信接口。
7.根據權利要求6所述的方法，其特征在于，所述方法用于對所述被測軟件的通信接口進行測試。
8.根據權利要求1到7任一項所述的方法，其特征在于，所述測試命令幀由腳本語言創(chuàng)建和/或發(fā)送。
9.根據權利要求1到7任一項所述的方法，其特征在于，所述等待幀由腳本語言創(chuàng)建。
10.根據權利要求8或9所述的方法，其特征在于，所述腳本語言為工具命令語言或腳本語言“龍蛇”。
全文摘要
本發(fā)明公開了一種軟件測試的方法，包括以下步驟1)建立與被測軟件的連接；2)構造測試用例的測試命令幀并將所構造的測試命令幀發(fā)送給被測軟件；3)生成所述測試命令幀的等待幀，所述等待幀中包含所述測試用例的預期結果；4)比較所述等待幀和所述被測軟件返回的針對所述測試命令幀的執(zhí)行結果幀，如果兩者一致，則判斷測試結果為通過，否則為不通過。使用本發(fā)明的方法，可以提高測試效率，降低人力資源成本。
文檔編號H04L12/26GK1755643SQ20041008091
公開日2006年4月5日 申請日期2004年9月27日 優(yōu)先權日2004年9月27日
發(fā)明者孫孟杰, 張曉翔, 劉波 申請人:華為技術有限公司