1、支付寶WAP支付平臺測試方案項目簡介支付寶WAP平臺從總體上分為子模塊，分別是登錄、注冊、賬戶管理、交易管理、繳費中心和交易接口，系統結構圖如下：測試方案組成部分根據我們對支付寶WAP平臺設計方案的分析，認為本測試方案應該由三個部分組成，即軟件驗證技術、軟件確認技術和 HYPERLINK / 軟件測試管理技術。它們內涵及相互之間的關系如下圖所示： 支付寶WAP支付平臺測試方案 HYPERLINK /TestTech/ 測試技術層面 測試管理層面 軟件驗證技術 需求規格說明驗證 HYPERLINK / 軟件測試團隊組織管理 設計規格說明驗證 代碼驗證 HYPERLINK / 軟件測試計劃管理 交

2、付驗證 軟件確認技術 單元測試 軟件缺陷（錯誤）跟蹤管理 集成測試 系統測試 HYPERLINK / 軟件測試件管理 交付測試 其中，軟件驗證技術著眼于排除軟件開發文檔中的錯誤。驗證活動涉及的文檔按開發流程主要涉及需求規格說明、設計規格說明（包括概要設計規格說明、詳細設計規格說明、數據庫設計規格說明）、編碼規格說明、產品交付文檔等一系列書面材料。目前驗證技術的實施在很大程度上是依靠測試人員手工完成的。驗證活動視實際需要有時還會涉及到開發人員和目標客戶，需要得到他們必要的理解和支持。驗證測試采用的主要測試手段有：面對面質詢、文檔抽查、非正式會議、同行評審等等。相對于軟件驗證技術，軟件確認技術則主

3、要著眼于排除程序代碼中的錯誤。活動涉及的對象主要是程序部件的代碼或軟件成品。在實施過程中，常常按被測代碼的規模和測試所處的層次將軟件確認測試分為四個階段，即：單元測試（也叫類測試）、集成測試（也叫組裝測試）、系統測試和交付測試。確認測試基本上由 HYPERLINK / 軟件測試人員對照相關開發文檔運行程序獨立完成的。必要時，也可讓設計人員帶領測試人員閱讀程序代碼共同發現其中的錯誤，（即所謂代碼評審會）。我們認為，在單元測試 ( 或類測試 ) 階段，應該有軟件編碼人員參與，這樣能減輕測試人員閱讀代碼障礙。原則上，測試理論不提倡程序作者負責把關自己編寫的程序的質量。在實際實施過程中，可視實際情況靈

4、活處理。（如成對編程可能會較好的處理單元測試這個難題，上面提到的代碼評審會也是為應對這個難題而想出的一個好辦法。），軟件確認技術目前已經部分地實現了 HYPERLINK /AutoTest/ 測試工具的自動化，市面上已有不少自動化工具能在測試人員的輔助下完成相應的測試工作（例如用于 Java 代碼單元測試的 Junit 工具，又如用于 GUI 測試的 Rational Visual Test 工具，等等）。 軟件驗證技術和軟件確認技術均屬于 HYPERLINK /TestTech/ 測試技術層面的東西。然而對于工程質量的保證而言，光靠軟件 HYPERLINK /TestTech/ 測試技術還遠

5、遠不夠，還需要技術管理層面上的東西。我們這里強調 HYPERLINK / 軟件測試管理技術的目的正是為彌補這個不足。按照管理的對象不同，測試管理技術大致涵蓋 HYPERLINK / 軟件測試團隊組織管理、 HYPERLINK / 軟件測試計劃管理、軟件缺陷（錯誤）跟蹤管理以及 HYPERLINK / 軟件測試件管理四大部分。下面，針對支付寶WAP平臺項目對該測試方案做一個詳細的詮釋。 三、在支付寶WAP平臺測試過程采用的測試內容3.1 在支付寶WAP平臺采用測試驗證技術我們將對支付寶WAP平臺采用軟件驗證技術，主要包括需求規格說明驗證、設計規格說明驗證、代碼驗證以及交付驗證。以下逐一說明。 需

6、求規格說明驗證的主要任務是保證用戶的功能需求、業務需求、以及其他的一些需求（如非功能性需求、約束性需求等等）都已經被分配到軟件需求規格說明的各需求項中。 設計規格說明驗證相對需求規格說明驗證而言，稍微復雜些，它包括 3 個部分的內容：即概要設計規格說明驗證、詳細設計規格說明驗證以及數據庫設計規格說明驗證。其中概要設計規格說明驗證的主要任務是確保軟件需求規格說明中的需求項全部已經分配到了概要設計規格說明的各軟件模塊之中并且無多余物，詳細設計規格說明驗證的主要任務是確保概要設計規格說明中的模塊已經全部分配到詳細設計規格說明的各軟件單元之中并且無多余物，數據庫設計規格說明雖然從范疇上講應該屬于詳細設

7、計規格說明范疇，但我們認為應該把它獨立出來實施驗證活動。（數據庫設計和軟件設計畢竟有很多不同之處。）數據庫設計規格說明驗證的重點任務是驗證數據庫與外部應用程序的接口是否正確、數據操作實現界面是否清晰、數據庫整體設計是否合理、數據表設計是否符合 3NF 要求（如違反范式要說明詳細理由）以及數據表中的字段（鍵）和索引的設計是否高效合理等等。代碼驗證的內容包括：代碼編寫規范審查、代碼審查和代碼靜態分析三個部分。代碼編寫規范審查主要是審核代碼排版的格式以及注解的格式是否符合開發團隊的相應規范；代碼審查的任務主要是驗證詳細設計中的軟件單元是否都已被代碼覆蓋并正確實現，并且代碼中不含冗余物；代碼靜態分析技

8、術主要任務是檢查變量或標號的定義與使用、表達式運算以及程序的流程設計上是否存在缺陷或錯誤。 做完代碼驗證以后，軟件系統需要依次做單元測試、集成測試和系統測試，這部分內容屬軟件確認技術范疇，下面有專門的論述。軟件系統在做完系統測試后，就面臨著交付使用的問題，在系統正式移交給用戶之前，還需要做交付驗證和交付測試。交付 HYPERLINK /TestTech/ 測試技術下文有專門的論述，不贅述，這里主要談交付驗證技術。交付驗證包括安裝驗證和使用驗證兩部分內容。其中，安裝驗證的主要任務是保證程序能按照用戶手冊的提示正確安裝到目標機器上，使用驗證的主要任務是確保程序能按照用戶手冊的提示的操作正確完成某項

9、功能或事務處理。這兩部分工作通常是由測試人員完成的，用以核實相關安裝和使用手冊是否正確無誤。3.2在支付寶WAP平臺中應用軟件確認技術 為了確保及時、盡早發現軟件中存在的問題，我們將在支付寶WAP平臺的測試過程使用的確認技術包括：單元 HYPERLINK /TestTech/ 測試技術、集成 HYPERLINK /TestTech/ 測試技術、系統 HYPERLINK /TestTech/ 測試技術和交付 HYPERLINK /TestTech/ 測試技術。 單元測試：主要任務是驗證詳細設計規格說明中所劃分出來的軟件單元是否被程序編制人員用代碼形式正確地實現了。這里軟件單元可能是某個函數（或稱

10、方法）也可能是某個抽象數據類型（如類、數據結構或者模板）。單元測試在實際測試當中也常常被稱為類測試（在面向對象的設計中）或白盒測試（白盒的意思是面向代碼）。測試人員輸入設計好的測試用例，測試被測單元能否按照設計要求處理這些測試用例，對出現異常的測試用例，測試人員將做記載并反饋給軟件開發團隊。 集成測試：對照軟件概要設計規格說明，驗證各軟件單元組裝后形成模塊能否達到概要設計規格說明中模塊的設計目標；在模塊級集成工作完成之后，測試人員還應測試各模塊組裝后形成的用戶系統內部存在沖突，各模塊能否正常工作。通常在做集成測試時先是從分系統內部的集成測試開始做起，做完以后再測試各分系統是否能集成為最終要實現

11、的大系統。也有其他做法（如自頂向下集成測試方法、核心系統先做集成測試或每日集成測試等等）。總之，萬變不離其宗。集成測試要保證模塊的內部正確性以及保證模塊能最終集成為大系統。系統測試：系統測試的主要任務是驗證經集成測試后形成的軟件系統是否滿足軟件需求規格說明中的各需求項。這些需求項包括：業務需求、功能需求、非功能性需求（如：性能、可靠性、安全性、系統維護等方面的要求）以及一些約束性需求（如開發標準、編程語言、通訊協議）等等。由于需求項涉及的領域很廣泛，這就導致了系統測試中對應的測試門類相當龐雜。如：功能測試、執行路徑測試、可靠性測試、壓力測試、可恢復性測試、可移植性測試等等。這些測試最顯著的特征

12、是在一定環境條件下（如：模擬現場或極端條件），設計各種測試用例，輸入并運行完整的軟件系統，根據軟件系統運行過程中的實際表現，評估軟件系統是否符合軟件需求項的各類要求。交付測試：在做完系統測試以后，軟件產品就到了交付用戶使用這個階段了。交付過程中的重要一環就是交付測試，交付測試的目標是保證用戶對所交付的系統的滿意。與前面所討論的測試不同，交付測試主要的參與者應該是目標客戶。客戶參與越多越好。交付測試的內容一般包括安裝測試、可用性測試、 alpha 測試、 beta 測試等。其中安裝測試的主要任務是測試軟件系統能否在模擬環境下或實際現場由目標用戶順利完成在目標機器上的安裝；可用性測試的主要任務是測

13、試軟件系統在完成安裝以后能否完成用戶的模擬任務或現場任務； alpha 測試采用的形式一般是由一個用戶在開發環境下對軟件系統進行類似于黑盒的測試，測試的目的是從用戶的角度評價軟件產品的功能、可使用性、可靠性、性能和支持，尤其注重產品的界面和特色； beta 測試采用的形式一般是先由軟件的多個用戶在實際使用環境下使用 beta 版軟件系統一段時間，然后把使用中出現的各類故障或缺陷反饋給 beta 測試負責人員，再由測試負責人員移交給軟件開發者，由開發人員負責修正并完善軟件系統。 Beta 測試的目的是確保軟件產品交付給全體用戶之前能部分或全面地修正其在實際應用中可能出現的各類 BUG 或不足。3

14、.3支付寶WAP平臺中采用用 HYPERLINK / 軟件測試管理技術如前文所述， HYPERLINK /TestTech/ 測試技術解決了測試采用的方法和技術問題，然而，對于一個工程而言，還需要相應的測試管理才能保證各項測試活動的有序開展。因此，在支付寶WAP平臺 HYPERLINK / 軟件測試管理技術要解決的問題是如何確保軟件 HYPERLINK /TestTech/ 測試技術（包括軟件驗證技術和軟件確認技術）能在軟件項目在軟件生命內得到順利實施，并產生預期的效果。 按照 HYPERLINK / 軟件測試管理面對的管理對象的差異， HYPERLINK / 軟件測試管理技術大致分為 HYP

15、ERLINK / 軟件測試團隊組織管理、 HYPERLINK / 軟件測試計劃管理、軟件缺陷（錯誤）跟蹤管理以及 HYPERLINK / 軟件測試件管理四大部分。以下一一詮釋： HYPERLINK / 軟件測試團隊組織管理通俗地講就是測試團隊應該如何組建。根據我們現有的測試隊伍，我們有測試領域專家，具有極為豐富 HYPERLINK / 軟件測試經驗，對軟件開發過程中常見的缺陷或錯誤了然于胸，此外，還具有較好的親和力和人格魅力。其次，我們的隊還具有很多具備一技之長的成員，如對某些 HYPERLINK /AutoTest/ 測試工具運用嫻熟或能輕而易舉地編寫測試腳本。另外，測試團隊還聘有兼職成員。

16、如驗證測試實施過程中，同行評審是最常使用的一種形式，這些同行專家就屬于兼職測試團隊成員的范疇。至于測試團隊里里的測試新手，這部分人可以安排去從事交付驗證或黑盒測試之類的工作。 HYPERLINK / 軟件測試計劃管理通俗地講就是安排好測試流程。這部分內容具體涵蓋 HYPERLINK / 軟件測試策劃、軟件 HYPERLINK /TestTech/ 測試技術剪裁、測試進度管理、成本管理等幾個部分。其中測試策劃工作主要是指具體測試活動實施之前做好策劃工作，如起草測試大綱以及測試計劃；軟件 HYPERLINK /TestTech/ 測試技術剪裁工作主要是指測試團隊應根據軟件項目的具體實際剪裁出所要實

17、施的 HYPERLINK /TestTech/ 測試技術；測試進度管理工作主要是指排出各項測試的時間進度及人員安排，如有變動時應做相應調整；測試成本管理工作的內容即開列出測試活動中會涉及到的資源需求。四、測試支付寶WAP平臺的流程圖五 功能性能測試方法 HYPERLINK javascript:; 1. 等價類劃分法：有效等價類：指輸入完全滿足 HYPERLINK javascript:; 程序輸入的規格說明，是由有效且有意義的輸入 HYPERLINK javascript:; 數據所構成的集合，利用有效等價類可以檢驗程序是否滿足規格說明所規定的功能和 HYPERLINK javascript

18、:; 性能。無效等價類：和有效等價類相反，即不滿足程序輸入要求或者由無效的輸入數據構成的集合。2. 邊界值分析法： 指對輸入的邊界條件進行分析，設計出針對邊界值的測試用例。數值的邊界值檢驗字符的邊界值檢驗如： ASCII和 Unicode編碼方式其他邊界值檢驗選上所有選項（最大值）不選上任何一項（空，零）只選一項 （最小值）3. 因果圖法：就是利用圖解法分析軟件輸入（原因）和輸出條件（結果）之間的關系，以設計測試用例的方法。因果圖法適合于檢查程序輸入條件的多種情況的組合，并最終生成判定表，來獲得對應的測試用例。4.功能圖法功能圖是描述程序狀態變化、轉移的過程，因為軟件運行或操作的過程可以看作是

19、其狀態不斷發生變化的過程。測試用例的設計就是如何覆蓋所有軟件表現出來的狀態，即在滿足輸入/輸出的一組條件下，軟件運行是一系列有次序的、受控制的狀態變化過程。5.錯誤推測法：推測法主要依賴經驗、直覺來作出簡單的判斷甚至是猜測，給出可能存在缺陷的條件、場景等，在找到缺陷后，設計出相應的測試用例。6.正交實驗設計方法：主要步驟是：（1） 對軟件 HYPERLINK javascript:; 需求規格說明中的功能要求進行劃分（層層分解與展開），分解成具體的、相對獨立的基本功能。（2） 根據基本功能的 HYPERLINK javascript:; 質量需求，找出影響其功能實現的操作對象和外部因素，每個因

20、素的取值可以看作水平，多個取值就存在多個水平。（3）確定待測試軟件中所有因素及其權值，這是測試用例設計的關鍵，確保全面、準確。權值是依據各因素的影響范圍、發生的頻率和質量的需求來確定的。（4） 加權篩選，生成因素分析表。 （5）利用正交表構造測試數據集，正交表的每一行，就是一條測試用例。考慮交互作用不可忽略的處理因素和不可混雜的原則，有交互作用的組合優先安排。利用正交實驗設計方法設計測試用例，可控制生成的測試用例數量，覆蓋率高且測試效率高。六 測試環境的搭建 本測試方案需要開發商提供的硬件和軟件如下： 6.1 硬件1）提供帶有WAP瀏覽器的不同類型的手機終端。 2）提供一定的筆記本電腦，和網絡

21、設備。6.2 軟件 1）提供軟件測試工具。 2）提供開發平臺的工具包七 測試方案工作量估算7.1測試技術方案根據該系統的運行環境，系統需求和系統設計，以及組成系統的各子模塊。我們必須編寫各個測試階段，各模塊的測試用例。 1）根據設計規格得出的基本功能測試用例；2)界值測試用例；3)態轉換測試用例；4)誤猜測測試用例；5)常測試用例；7.2 用例數量的估算 根據本系統的需求和系統設計，大約需要測試用例的數量如下：系統需要測試用例：13X216X13X4858個7.3 需要實行用例測試人員 根據本系統的完成期限，每個測試人員在12月內需要測試的功能模塊進行平均計算，需要測試人員為： 858/60=

22、14.3人，即14個人兩個月內完成測試。以每人月工資3000元計算，共需14X2X300084000元如果考慮到不同的手機終端，每一個類型的手機增加1/3X84000元28000元考慮到上稅：總花費需要：84000手機機型數X28000元稅率。附錄：系統開發和軟件測試高級工程簡介：1、學術總監：柏永林高級軟件工程師，從事軟件開發設計架構23年。目前擔任技術總監。具備扎實的計算機理論基礎。英國諾丁漢大學研究軟件構架模式技術多年。曾任國家級軟件園：西安軟件園西部數通公司總工程師和總構架師。在多年的軟件工程技術開發和集成過程中，成功組織、設計、管理、開發出了如CALL Center、SMS、WORK

23、FLOW的技術B/SC/S構架系統、嵌入式（如手機）開發應用等。在Middle-tiers技術開發方面，主持設計開發了綜合業務即時服務系統（CALL Center+WorkFLOW+SMS+FAX+C/S+B/S+DATABASE的大型綜合服務和監控系統）。熟練掌握WEB Services，XML Schema，XML，WSDL，SOAP，UDDI。精通企業級J2EE和嵌入式J2ME等技術規范（如EJB組件、Web技術JSP、Struts、JSF等）和MVC模式，精通UML建模語言和POWERDESIGNER、RATIONAL ROSE以及Jbuilder/Eclipse等開發平臺，精通世紀橋

24、架構開發系統，熟悉WAP開發。2、趙衛棟曾任高級嵌入式軟件工程師、項目經理等職，在國內著名通信公司、美資外企工作，先后擔任高級嵌入式軟件工程師、項目經理等職。精通C語言、Vxwork、linux、各種通信協議，3G系統和各種通信設備。技術方向：pSOS for PowerPC (開發過850 860 8260驅動) ，Tornado(vxworks) for Arm(開發過1200) for PowerPC( 8260 )， 開發過 DSP，網絡處理器（ixp1200 ixp2400 c5 c3e），數據鏈路層協議，網絡層協議，以太網交換機，路由器，三層交換機等Linux下開發過網絡安全產品。

25、項目經驗：REM 32E1板，3G REM 接口板（路由引擎模塊），MPA（媒體轉發）板，NGN 項目中的CA （呼叫代理）板，高密度語音板，155M ATM接口模塊。3、和征西安理工大學信息管理碩士。參與分析、設計和開發了陜西建設機械股份有限公司網上進銷存管理系統、企業Intranet管理系統、臨汾網絡通訊公司網站系統、西安理工大學圖書館網站、柏高酒店網站管理系統。以Oracle數據庫作為企業數據中心，通過J2EE技術和XML技術,以及Web Services技術，對企業不同信息系統進行集成，分析、設計和開發了陜西建設機械股份有限公司企業應用集成系統(簡稱EAI)，通過企業門戶網站的形式對企

26、業提供應用集成功能。精通Java語言、JSP以及J2EE技術,對J2EE架構以及基于J2EE架構的Web Services技術有深刻的理解,。精通C#語言、VB、VB.NET語言以及ASP、ASP.NET技術,熟悉XML技術和微軟的XML Web Services技術,。4、王曉鵬畢業于西安電子科技大學。多年從事通信行業.曾在NOKIA從事移動通信工程.在華為大學西安分部從事通信培訓。熟悉計算機通信網絡,獲得CISCO公司的CCNP資格證書.熟悉移動通信2G技術,在工程設計,實施.技術支持和培訓方面有豐富的積累和經驗,對3G標準WCDMA,CDMA2000制式的技術及設備比較熟悉。5、王永強西安理工大學計算機科學與技術碩士。曾擔任項目經理、軟件技術總監等職務。從事過智能溫控系統設計與維護，電力調度自動化通信軟件設