基于Web的系統測試方法

      Yogesh Deshpande和Steve Hansen在1998年就提出了Web工程的概念。Web工程作為一門新興的學科，提倡使用一個過程和系統的方法來開發高質量的基于Web的系統。它" 使用合理的、科學的工程和管理原則，用嚴密的和系統的方法來開發、發布和維護基于 Web的系統"。目前，對于web工程的研究主要是在國外開展的，國內還剛剛起步。
　　在基于Web的系統開發中，如果缺乏嚴格的過程，我們在開發、發布、實施和維護 Web的過程中，可能就會碰到一些嚴重的問題，失敗的可能性很大。而且，隨著基于Web 的系統變得越來越復雜，一個項目的失敗將可能導致很多問題。當這種情況發生時，我們對Web和Internet的信心可能會無法挽救地動搖，從而引起Web危機。并且，Web危機可能會比軟件開發人員所面對的軟件危機更加嚴重、更加廣泛。
　　在Web工程過程中，基于Web系統的測試、確認和驗收是一項重要而富有挑戰性的工作?；赪eb的系統測試與傳統的軟件測試不同，它不但需要檢查和驗證是否按照設計的要求運行，而且還要測試系統在不同用戶的瀏覽器端的顯示是否合適。重要的是，還要從最終用戶的角度進行安全性和可用性測試。然而，Internet和Web媒體的不可預見性使測試基于Web的系統變得困難。因此，我們必須為測試和評估復雜的基于Web的系統研究新的方法和技術。
　　一般軟件的發布周期以月或以年計算，而Web應用的發布周期以天計算甚至以小時計算。Web測試人員必須處理更短的發布周期，測試人員和測試管理人員面臨著從測試傳統的C/S結構和框架環境到測試快速改變的Web應用系統的轉變。

　　一、功能測試
　　1、鏈接測試
　　鏈接是Web應用系統的一個主要特征，它是在頁面之間切換和指導用戶去一些不知道地址的頁面的主要手段。鏈接測試可分為三個方面。首先，測試所有鏈接是否按指示的那樣確實鏈接到了該鏈接的頁面；其次，測試所鏈接的頁面是否存在；最后，保證Web應用系統上沒有孤立的頁面，所謂孤立頁面是指沒有鏈接指向該頁面，只有知道正確的URL地址才能訪問。
　　鏈接測試可以自動進行，現在已經有許多工具可以采用。鏈接測試必須在集成測試階段完成，也就是說，在整個Web應用系統的所有頁面開發完成之后進行鏈接測試。 　　

2、表單測試
　　當用戶給Web應用系統管理員提交信息時，就需要使用表單操作，例如用戶注冊、登陸、信息提交等。在這種情況下，我們必須測試提交操作的完整性，以校驗提交給服務器的信息的正確性。例如：用戶填寫的出生日期與職業是否恰當，填寫的所屬省份與所在城市是否匹配等。如果使用了默認值，還要檢驗默認值的正確性。如果表單只能接受指定的某些值，則也要進行測試。例如：只能接受某些字符，測試時可以跳過這些字符，看系統是否會報錯。

?
3、Cookies測試
　　Cookies通常用來存儲用戶信息和用戶在某應用系統的操作，當一個用戶使用Cookies訪問了某一個應用系統時，Web服務器將發送關于用戶的信息，把該信息以Cookies的形式存儲在客戶端計算機上，這可用來創建動態和自定義頁面或者存儲登陸等信息。
　　如果Web應用系統使用了Cookies，就必須檢查Cookies是否能正常工作。測試的內容可包括Cookies是否起作用，是否按預定的時間進行保存，刷新對Cookies有什么影響等。

4、設計語言測試
　　Web設計語言版本的差異可以引起客戶端或服務器端嚴重的問題，例如使用哪種版本的HTML等。當在分布式環境中開發時，開發人員都不在一起，這個問題就顯得尤為重要。除了HTML的版本問題外，不同的腳本語言，例如Java、JavaScript、 ActiveX、VBScript或Perl等也要進行驗證。

5、數據庫測試
　　在Web應用技術中，數據庫起著重要的作用，數據庫為Web應用系統的管理、運行、查詢和實現用戶對數據存儲的請求等提供空間。在Web應用中，最常用的數據庫類型是關系型數據庫，可以使用SQL對信息進行處理。

　　在使用了數據庫的Web應用系統中，一般情況下，可能發生兩種錯誤，分別是數據一致性錯誤和輸出錯誤。數據一致性錯誤主要是由于用戶提交的表單信息不正確而造成的，而輸出錯誤主要是由于網絡速度或程序設計問題等引起的，針對這兩種情況，可分別進行測試。

三、 經驗與教訓

　　從項目規模中可以看出，該項目的時間還是比較緊張的；另外一方面，項目交付是在合同規定日期之前完成，而且通過了所有的功能測試。從一定意義上的講，項目的開發是取得了一定的成功的。

　　3.1 經驗

　　在項目開發前，項目開發商已經通過其它項目，實施了以XP為代表的敏捷軟件開發方法的部分最佳實踐，并取得了很大的成功。因此，在該項目的執行過程中，項目開發商繼續采用了XP的部分實踐以及其它軟件開發方法中的推薦做法[1][2]：

　　每日晨會：在項目實施過程中，每天早晨開發小組都要參加一個持續15分鐘左右的會議，由項目經理主持，聽取每個成員的進度，并根據進展情況，對于進度和資源進行調整。

由于會議是每天進行的，PM很容易從中獲得真實的項目情況－"掀開地毯下面的東西"[4]，從而對風險有了較好的控制。

　　交叉審核：項目組在最初的時候原本是想采取"成對編程"的實踐，但是沒有獲得物理和管理上的支持，因此，只能采取交叉審核的方式進行。

　　需求獲?。河蒔M和一名對于原有系統較熟悉的開發人員進行需求獲取和SRS (Software Requirement Specification) 的撰寫。技術經理和其它開發人員進行需求的審核。

　　分析與設計：由一名開發人員進行系統框架的設計，其它人員進行審核；在系統框架設計進行過程中，由于系統去除訂單處理以外的其它部分比較獨立，因此，將其它模塊分配給開發人員，而將核心部分交與技術經理進行分析與設計。開發人員在每個迭代周期內，都會在分析與設計做完后，每2人一組進行審核。

　　編碼：每天下班前，2人一組，對對方的代碼進行Review，發現問題及時解決。代碼Review的時候，語法與規則的檢查，通過Check Style的工具進行；開發人員將審查的重點放在功能實現與性能優化等方面。

　　測試：在需求文檔形成以后，2個測試人員分布編寫分配模塊的Test Case；而在具體測試的時候，兩人交叉測試對方的模塊和更新文檔。

　　在系統開發Verification的各個階段，都有Check List，詳細的信息請查看參考文獻[3]。

　　測試先行：測試在軟件開發中的重要作用已經得到了越來越多的重視，但是，由于習慣勢力的影響和對于"Test-Driven Development"的不熟悉，開發小組并沒有實施完全意義上的測試先行。

　　對于系統框架的核心類設計過程中，項目小組采取了TDD的方式進行開發。在后續的系統開發中，每個開發人員在進行開發前，首先要完成一個功能測試 ( Function Test ) 列表，將要完成的Use Case中的主要業務邏輯以及關聯邏輯都要羅列出來，在提交測試人員進行集成測試之前，開發人員需要保證完成Function List中的所有選項。

　　在每個開發人員的模塊完成并通過個人的功能測試后，測試人員進行集成測試，同時編寫測試腳本，并通過自動測試工具 (Rational Robot) 進行記錄。每天下班之前，測試人員會啟動測試工具，進行回歸測試。在第二天向PM和技術經理提交測試報告并將Bug提交至Bug Trace系統（Rational Clear Quest），由PM進行Bug的分發。每個開發人員需要在下一個迭代周期完成前，修正前一個迭代內分配的Bug。

　　持續集成：在測試先行的基礎上，開發一組平均每天都會進行已經完成模塊與以后系統的集成。集成由專門的人員，在開發人員將已經通過功能測試的源碼Check in到源碼控制系統 (ClearCase) 中以后進行，在部署應用結束以后，通知測試人員進行集成測試。

　　小步發布：項目有專門的測試與發布服務器，每天都有集成的系統在運行和接受測試。由于沒有現場客戶，對于已經發布的系統，是由"客戶領域專家"（這個項目是由Business Development人員來充當這個角色）來進行審查的。他對于系統的意見和發現的問題，在經過PM和技術經理審核后，進入ClearQuest，分配給開發人員進行修改。

　　由于項目一開始就注意組織內部以及與客戶的溝通和交流，同時采用了很多敏捷軟件開發過程的實踐，項目如期交付使用。

　　3.2 教訓

項目在交付以后，最初的兩個訂貨季節沒有出現功能與性能上的問題。但是，由于合同中有數據遷移的條款，在項目交付2月后，項目開發商將舊應用系統中的數據導入新系統以后，在下一個大的訂貨季節中，持續的出現性能上的問題。在代碼修改和硬件環境提高以后，系統性能目前獲得了一定的改善。

　　從項目驗收日期的日益推遲中，我們可以看出，該項目還是有很多地方做的不夠，例如：系統二次開發效應："第二個系統效應"是Brooks在《人月神話》中提出的一個普遍的問題，一般而言，第二個系統會傾向于過分設計[4]。對于這個項目而言，沒有犯這個錯誤，卻發生了另外一種情況：舊系統中，對于訂單信息以及產品信息的展示，不管是多是少（系統頁面最多顯示上千條記錄），都是在一個頁面中顯示。這對于沒有明顯的層次結構，直接在Script中調用數據庫記錄的PHP來說，性能還是可以接受的。但是，新系統的設計中客戶提出考慮系統用戶習慣一致性的問題，就照搬了舊系統的頁面設計；同時，在架構設計上，對于這種頁面顯示大量數據的情況，也沒有給予充分的考慮，為后來的性能問題，埋下了伏筆。

　　教訓一：沒有考慮新平臺的影響，照搬舊系統的功能以及頁面設計。

　　非功能性需求：項目合同中主要描述的是系統功能性的需求，而沒有非功能性需求的規定；同時，在需求獲取解決，也沒有明確的了解系統的性能指標等非功能性需求。主要原因在于項目開發商之前沒有大規模業務系統開發的經驗，對于非功能性需求沒有足夠的重視；同時，在測試階段，也沒有對于系統負載和性能做過測試。

　　因此，在項目交付以后，由于舊系統數據遷移后，數據量有了很大的增長，同時，在秋季的定購高峰中，有大量的并發用戶訪問，出現了下列問題：

　　數據庫死鎖；

　　大量數據計算與顯示頁面速度很慢，頁面要經過5～10分鐘才能夠完全顯示；上述兩種情況在少量負載的單元測試和集成測試中是不可能出現的。

　　教訓二：對于企業應用系統，尤其是業務系統，沒有切實注意負載、性能等非功能性需求。

　　效率與設計：在J2EE中，已經成功的運用了很多設計模式的思想，為系統的開發提供了一個很好框架。但是，在項目的架構設計中，除了考慮可維護性、可復用性等問題以外，還要考慮代碼執行效率的問題[5]。

　　隨著計算機硬件技術的發展，"莫爾定律"被一再的驗證，系統硬件的價格逐漸降低。對于很多使用J2EE架構或者JAVA技術的項目來說，解決性能與效率問題的解決方案就是增加硬件方面的投入。而實際上，軟件開發過程中優劣算法之間的差是靠硬件的投入平衡不了的。

　　該項目在系統維護期間，對代碼進行走查，修改了很多對于性能有影響的語句；同時，在框架設計中，尤其是數據庫操作方法，利用Cache原理，從一定程度上解決了性能的問題。

　　教訓三：系統框架設計只考慮面向對象和可維護性，沒有在完美的設計與高效率的代碼之間做出權衡。

　　數據庫設計：JAVA是純粹的面向對象語言，利用J2EE開發的項目，也強調首先進行OOAD的分析，首先有對象，然后再有數據庫的設計。DBA在項目中的作用，已經遠遠沒有傳統的結構性編程中重要。而實際情況卻是遠非如此：大部分的業務系統，如果要對系統的性能做出優化，對數據庫層或者SQL語句進行優化是關鍵的步驟之一。

　　對于這個PRM系統，在數據庫的設計上并沒有經過DBA的審查就開始進行開發；而在性能問題出現以后，客戶增加了512M的內存，也沒有請求DBA對Oracle的參數做相應的調整，造成了很大的資源浪費。

　　在項目維護過程中，依靠DBA的幫助，開發商對于數據庫系統參數、索引、存儲過程和SQL語句都做了一定的調整，這對于系統性能的提高起了很大的作用。

　　教訓四：在面向對象的軟件系統構建中，忽視數據庫設計以及DBA的重要作用。

　　客戶參與：在傳統的軟件開發過程中，一般情況下，客戶在簽訂合同后，項目交付前是很少有機會看到系統的，這樣就造成了系統交付后，客戶抱怨很多的情況；而在以XP為代表的敏捷軟件開發方法中，強化了客戶在軟件開發中的重要作用，XP更是提出了"現場客戶"的實踐，將客戶作為項目小組的一員，客戶對于項目的發布計劃、內容和優先級等方面有絕對的控制權。

　　對于這個PRM項目，由于客戶的原因，不可能采取"現場客戶"的實踐，但是，開發商的BD對于該客戶十分熟悉，完全可以作為客戶代表參與到項目中來，因此，開發商將客戶經理作為項目組的一員。

　　實際情況是：開發過程中，客戶經理由于業務拓展的原因，并沒有在項目上分配多少時間進行審查；而客戶在交付前也沒有花費很多的時間研究系統，也沒有提交很多的反饋報告。在系統交付出現性能等問題后，客戶經理與開發人員一起對于系統需求進行審查，提出了很多有參考性的意見。如果從一開始，就強化"現場客戶"的最佳實踐，就可以很早發現問題。

　　教訓五：客戶或者客戶經理對于項目的參與力度不夠。

　　四、 結論

　　在基于J2EE的企業應用項目開發中，要注意以下問題：

　　權衡系統設計與性能指標，關注非功能性需求；

　　采取敏捷軟件開發過程，關注人（客戶和開發人員）在項目實施中的重要作用，如果可以的話，聯合實施XP的所有實踐； 。

怎樣理解這種說法呢？

　　首先，測試并不僅僅是為了要找出錯誤。分析錯誤產生的原因和錯誤在開發的哪一個階段產生，具有非常重要的意義。

　　通過分析錯誤的原因，我們可以立即在開發行動中對其進行改正。同時，這種分析也能幫助我們推理出 與所分析的錯誤有關聯的潛在錯誤，從而有針對性地設計出檢測的方法。

　　通過分析錯誤產生于哪一個開發階段、而又在哪一個階段被發現，我們可以判斷從錯誤的產生到錯誤的發現，跨越了多少個開發階段。軟件開發的一條重要原則是盡早發現與修正錯誤。（當然，更高的一條原則是盡量預防錯誤的出現。）一個錯誤能夠超越本開發階段而不被發現，就指明了該開發階段的檢測手段有缺陷，從而也不難有針對性地制定出加強的措施與辦法。這也就是軟件過程改進的一項重要內容。如果能做到在同一開發階段發現及修正錯誤，該開發機構就可以預期有一個高質量的產品及一個低成本、高效率的軟件過程。

　　有些項目的主持人，認為以盡快的速度把測試之前的所有開發階段完成（實際并沒有完成），早日開始測試，以圖達到快速和高質量（因為似乎有更長的時間可用于測試）。實際的效果將會是俗語所說的“欲速不達”。從常識就可以知道，花開發時間去繼續擴大發展前面階段引入的錯誤，得出的只能是更大量的需要耗時修正的錯誤。

　　因此，正確分析與利用測試的結果，我們可以非常有效地進行軟件過程改進。

　　軟件開發全過程檢測，力爭本階段修正錯誤

　　從上面的討論，我們很自然的就能領會到，軟件錯誤的發現絕不能等到測試才開始（按常規，最早的測試就是編碼后的單元測試）。因此，筆者提出一個軟件工程的守則：軟件開發全過程檢測，力爭本階段修正錯誤。單元測試是在軟件開發的“實現階段” 才開始的，在此之前的“可行性研究與計劃階段”，“需求分析階段”，“概要設計階段”，和“詳細設計階段”，都必須有非常明確切實的手段與措施對開發結果進行檢驗，以保證階段的正確完成。

　　怎樣判斷一個軟件過程的優劣，怎樣進行軟件過程改進，都可以在這個守則的指導下進行。這個守則是簡單明確的，但因企業背景、條件的不同，開發環境條件的不同，項目產品的不同，實際的軟件過程的實現方法就會變化無窮?？紤]實現這個原則的方法的時候，可以盡量多參考各種理論及經驗，但在選擇制定本企業開發實踐中使用的軟件過程時，就必須處處根據是否能給自身的項目帶來好處，以及自身的條件進行考慮。千萬不要僅僅為了滿足某個“標準”的提法而做一些無實際意義的工作。要盡量避免煩瑣，爭取做到簡單、有條理和有最大的效果。

　　軟件測試的自動化

　　軟件測試的工作量很大（據統計，會用到40% 的開發時間；一些可靠性要求非常高的軟件，測試時間甚至占到總開發時間的60% ），但測試卻是在整個軟件過程中極有可能應用計算機進行自動化的工作，原因是測試的許多操作是重復性的、非智力創造性的、需求細致注意力的工作。計算機就最適合于代替人類去完成這些任務。企業在這方面的投資，會對整個開發工作的質量、成本、和周期帶來非常明顯的效果。一些適于考慮進行自動化的測試操作為：

　　1.測試個案的生成（包括測試輸入，標準輸出，測試操作指令等）。

　　2.測試的執行寫控制（包括單機與網絡多機分布運行；夜間及假日運行。測試個案調用控制；測試對象、范圍、版本控制等。）。

　　3.測試結果與標準輸出的對比。

　　4.不吻合的測試結果的分析、記錄、分類、和通報。

　　5.總測試狀況的統計，報表的產生。

　　測試自動化與軟件配置管理是密不可分的。與測試有關的資源都應在配置管理中進行統一的計劃考慮。另外，測試工具的采用也是一個提高質量的關鍵，有些專用的測試 工具能幫助發現一些用任何測試個案都難以觸及的錯誤。?

總的來說，基本的測試還是和神馬那里的單元測試比較類似，問題在于web測試的頁面輸入問題不知道有沒有什么好的測試工具能代替，也許基于structs的框架里有吧？

原文轉自：http://www.anti-gravitydesign.com