無線上網移動增值業務終端管理系統的設計與實現畢業論文-資料下載頁

　　

【正文】 后以此為技術核心進行了設計與實現。最終達到了對框架的黑盒進化，在開發管理信息系統時生成增、刪、改、查等操作的可執行代碼，且生成的代碼在需要增加其他功能時能方便地擴展的目的。最后對框架進化前后進行了對比測試和開發工作量的比較，性能測試數據顯示進化后的框架在多用戶、大流量時占優，但是仍然存在一定的缺點。在編程工作量、代碼可讀性和可維護性方面，進化后的框架則占有絕對的優勢。利用現代的設計技術和正式的技術復審可以減少代碼中存在的初始錯誤，但是錯誤總是存在的，如果開發者找不到錯誤，那么，客戶就會找到它們。越來越多的軟件組織認識到軟件測試是軟件質量保證的重要元素之一，很多軟件開發組織將30%—40%甚至更多的項目資源用在測試上，軟件測試技術和軟件測試策略受到了高度的重視和廣泛的應用。基于Web的系統測試與傳統的軟件測試既有相同之處，也有不同的地方，對軟件測試提出了新的挑戰。基于Web的系統測試不但需要檢查和驗證是否按照設計的要求運行，而且還要評價系統在不同用戶的終端的顯示是否合適。重要的是，還要從最終用戶的角度進行安全性和可用性測試。 軟件開發過程各階段都可能產生錯誤。據國外對一些大型軟件系統的統計，需求分析與設計階段產生的錯誤占64％，編碼錯誤占36％。因此，測試工作越早進行，發現和解決錯誤的代價越小，風險越小。根據這個觀點，Systeme Evolutif公司提出了“W－模型”，如圖421所示。 “Ｗ－模型”由兩個“V”重疊而成。其中一個“V”表示開發過程，另一個“V”表示測試過程。軟件測試的各項測試活動與開發過程的各個階段相對應。同樣安全性測試也貫穿于軟件開發的全過程[18]。 圖421 軟件測試的Ｗ模型 在圖421所示的模型中，應用系統開發人員一般關注于提供正常工作的應用軟件，而測試人員應該從一個用戶的角度去考察，看一看是否能打破它。所以，Web應用系統安全性測試的目標應該是：核實操作者只能訪問其所屬用戶類型已被授權訪問的那些功能或數據，同時檢測用戶操作對應用系統的危害性[19] [20]。 壓力測試壓力測試是為了發現在什么條件下Web應用程序的性能會變得不可接受。也就是測試應用程序會不會崩潰，在什么情況下會崩潰。非法用戶常常使用錯誤的超常規的數據負載，直到Web應用程序崩潰，接著獲得系統的控制權。 在測試環境中，壓力測試可以通過改變應用程序的輸入以對應用程序施加越來越大的負載并測量在這些不同的輸入時性能的改變來實現的。這種操作也稱為負載測試。負載測試通常描述為一種特定類型的壓力測試——增加用戶數量以對應用程序進行壓力測試。 對應用程序進行壓力測試最簡單的方法是手工改變輸入（客戶機數量、需求大小、請求的頻率、請求的混合程度等等）并描繪性能的變化。但是如果有許多輸入，或者需要在大的范圍內改變輸入，那么就可以借助一個自動化的壓力測試工具如QALoad、loadrunner等來完成此測試。測試的內容有：Web應用程序同時允許多少用戶在線？能否處理大批用戶同時對同一頁面的訪問？如果出現異常，會出現什么情況等[21]。圖422是采用loadrunner軟件進行事務響應時間測試結果。 圖422 響應時間測試結果圖壓力測試是黑盒測試的一種。黑盒測試工具適用于黑盒測試的場合，黑盒測試工具包括功能測試工具和性能測試工具。黑盒測試工具的一般原理是利用腳本的錄制(Record)/回放(Playback)，模擬用戶的操作，然后將被測系統的輸出記錄下來同預先給定的標準結果比較。黑盒測試工具可以大大減輕黑盒測試的工作量，在迭代開發的過程中，能夠很好地進行回歸測試。本次測試的目的是：進行單個應用服務器的壓力測試，找出單個應用服務器能夠支持的最大客戶端數。測試壓力估算的依據是：假定在實際環中，用戶只啟用一個應用服務器進行所有的業務處理。方法是：按照正常業務壓力估算值的1~10倍進行測試，考察應用服務器的運行情況。隨著軟件測試的地位逐步提高，測試的重要性逐步顯現，測試工具的應用已經成為了普遍的趨勢。目前用于測試的工具已經比較多了，這些測試工具一般可分為白盒測試工具、黑盒測試工具、性能測試工具，另外還有用于測試管理（測試流程管理、缺陷跟蹤管理、測試用例管理）的工具。 總的來說，測試工具的應用可以提高測試的質量、測試的效率。但是在選擇和使用測試工具的時候，我們也應該看到，在測試過程中，并不是所有的測試工具都適合我們使用，同時，有了測試工具、會使用測試工具并不等于測試工具真正能在測試中發揮作用。 本系統使用的壓力測試工具是QA Center Edition 。工具的功能與性能： QACenter是完整的跨企業的自動測試產品，專為提高軟件質量而設計。QACenter可以在整個開發生命周期、跨越多種平臺、自動執行測試任務。 能夠模擬成百的用戶執行關鍵業務、能夠直接向服務器發送請求、能夠模仿用戶的操作、能夠測試系統的響應時間。包括:Script：測試執行時的腳本文件名字、PId:檢測點號碼、Checkpoint description:檢測點描述、Trans:檢測點的總交易數、Min:檢測點的最小響應時間、Mean:檢測點的平均響應時間、Max:檢測點的最大響應時間、StdDev:檢測點所有響應時間的標準偏離值、Median:響應時間的中間值、Percentile:N%的響應值小于所示的值、Pacing：腳本執行交易的速率、VU39。s：腳本執行的虛擬用戶數、Average Transaction per Time Unit:總交易數和測試時間的商數、Totals:每一個檢測點響應時間的和。 用戶登錄測試在軟件研發中，為方便調試程序，開發人員通常在訪問權限中，會主動建立一個超級用戶賬號來完成軟件的總體設計與研發。但在安全設計中，有一個很重要的原則是給用戶盡可能少的訪問權限以便他們可以執行與其身份相對應的操作，但不能執行非法操作。如果有超級用戶的存在，最終用戶就有可能利用此賬號進行創建、修改、刪除等一系列對數據表的操作，也可利用SQL語句改變URL，從而進行許多惡意的操作。 現在的Web應用系統基本采用先注冊，后登錄的方式。 對于用戶登錄和賬戶密碼，可以從以下幾個方面進行安全測試： 測試有效和無效的用戶名和密碼，測試是否大小寫敏感，是否有最大字符數的限制規則等。 測試重試次數的限制，如果登錄失敗的次數超過允許值，應用程序將會做出何種反應 （譬如拒絕此IP地址在短時間內的登錄）。 測試是否可以利用歷史登錄信息或以前的URL來繞開登錄程序。 測試執行添加、刪除、修改等動作中是否需要登錄操作，退出系統之后的操作是否仍可繼續等。 對于用戶的認證，可以從以下幾個方面進行安全測試： 測試是否所有的合法用法都可以訪問程序，非法用戶都不能訪問程序，如果非法用戶企圖登錄，其難易程序有多大。 測試用戶密碼是否符合指定要求（字符、長度），如果不符合，對有什么影響，新用戶自己修改密碼后，創建時分配的密碼是否會失效。 測試用戶賬戶過期后，是否完全、正確的刪除其信息或使其失效。 手動修改URL參數的測試經常使用SQL調用來訪問后臺數據庫中的數據，通過猜測或查閱歷史記錄，惡意用戶可能會獲得合法用戶ID和密碼列表。例如，如果在應用程序中采用下面的語句進行用戶身份的驗證： Select * from userInfo where Login=’admin’ and password=’1234’ 如果非法用戶使用下面的ID和密碼 Username admin Password no’or1 則用戶登錄時應用程序后臺調用的的SQL語句會變成： Select * from userInfo where Login=’admin’ and password=’ no’or1’ 此時，password的值有可能被賦為‘no’or 1，因為＃號可能會使數據庫忽略其后的字符。此時，由于任何值與1進行邏輯或運算，結果為真，所以系統會把該入侵者當作系統管理員，并將返回記錄。這是很可怕的。 還有一種手動修改的方法，例如，用合法用戶身份登錄后，訪問的的網頁是 ，手動將其修改為 :// 。 與此類似，Web應用程序中有很多的數據庫訪問目的地址是做為URL中的一個參數，這些信息可以輕易地被非法用戶得到，甚至猜測與它相鄰的地址。通過手動修改或調用，可能會在未經授權的情況下訪問系統。 客戶端測試客戶端測試在Web應用程序的安全測試中，是最容易被忽略的，因為測試人員往往關心的這種B/S結構中的服務器端的安全性，客戶端只是瀏覽，只是訪問，而所有的后臺程序都在服務端運行。但在實際運行中，但客戶端同樣會影響Web應用程序的安全性。Web用戶越來越精于使用各種設置來保護自己，web應用程序的開發不能強迫用戶接受自己的設置。如果客戶端瀏覽器安全參數高為高，會不會對應用程序有什么影響；用戶自定義每種動態內容（如Java、ActiveX、cookie等）行為，又會對應用程序產生什么影響等等。 要測試客戶端，可以從以下幾個方面入手： 檢查客戶端各種安全設置參數對應用程序的影響，尤其對Java、ActiveX、cookie的影響。 檢查應用程序不完全依賴客戶端腳本編程來進行錯誤檢查。 檢查應用程序不完全依賴客戶端腳本編程來進行驗證，因為用戶可以通過自寫或修改Web頁跳過這個驗證。 檢查直接輸入URL，能否跳過驗證而進入系統的某個頁面。 檢查用戶登錄的有效時間，長時間不操作會不會因為超時而強行退出等。 單元測試白盒測試工具一般是針對代碼進行測試，測試中發現的缺陷可以定位到代碼級，根據測試工具原理的不同，又可以分為靜態測試工具和動態測試工具。靜態測試工具直接對代碼進行分析，不需要運行代碼，也不需要對代碼編譯鏈接，生成可執行文件。靜態測試工具一般是對代碼進行語法掃描，找出不符合編碼規范的地方，根據某種質量模型評價代碼的質量，生成系統的調用關系圖等。動態測試工具與靜態測試工具不同，動態測試工具的一般采用“插樁”的方式，向代碼生成的可執行文件中插入一些監測代碼，用來統計程序運行時的數據。其與靜態測試工具最大的不同就是動態測試工具要求被測系統實際運行。本文系統使用PHP單元測試工具PHPUnit進行了單元測試部分。調試程序是一個漫長的過程，程序越長越復雜，調試起來就愈加困難。我們要調試的是php程序，采用的工具是phpUnit，它可以大大加快調試速度。Phpunit 脫胎于Fred Yankowski編寫的著名的Junit測試框架。利用phpUnit編寫一套測試軟件包。保證你的程序代碼正確無誤。只需一步便可自動完成所有的測試。如果監測到bug，可以再寫一小段測試代碼來找出錯誤之所在。日后若再有相同的bug出現，只要運行你先前的測試包，馬上就可以抓到它。經常運行測試包便可以保證你的程序代碼的強壯性。 本章小結本章介紹的是系統具體的實現過程，包括終端管理、日志功能、首頁設計、產品控制、產品設計幾個部分。其中終端管理模塊又包括支持格式維護子模塊（）、終端UA維護子模塊（）、CUI維護子模塊（）。以及系統測試。要讓應用程序開發商和客戶對基于Web的應用程序充滿信心，就必須讓他們對系統的安全性充滿信心。軟件是Web系統的關鍵組件之一，在軟件中存在的Bug就最暴露了Web應用程序的安全隱患，所以web應用程序的安全測試非常重要。但由于軟件錯誤的絕對性，任何一個系統都不可能是完全安全的，安全工作是一個不斷進行變化、測試和改善的動態過程。所以Web應用程序的安全測試，應該滿足軟件錯誤的相對性，即測試通過后的軟件需要保證在特定需求（用戶需求）下說是足夠安全的。 61 哈爾濱工業大學本科畢業設計（論文）結論本文完成的無線上網移動增值業務平臺的設計和實現，使用的編程語言為PHP，數據庫服務器使用了MySQL， WEB服務器使用了Apache。本系統主要實現后臺的終端管理系統、首頁設計、產品控制、產品設計和系統日志。終端管理包括支持格式維護、終端UA維護、CUI維護三個對象的管理。終端UA維護模塊管理手機的各種參數、適配信息、適配方式。支持格式維護模塊管理手機的適配類型。CUI維護模塊用來管理維護CUI，實現了對運營商的定義。系統日志模塊用來查看添加系統日志。 首頁設計模塊也就是用戶用手機上網后所顯示的，用來添加、修改、產品的首頁。產品控制模塊控制產品的一些開關操作，用來區分不同級別的客戶，對不同的客戶級別提供不同的內容版本。產品設計模塊用來添加、修改、設置產品的屬性。，調整了數據結構，實現了前后臺的分開部署，能夠有效的管理各種數據資源；清晰劃分前、后臺管理功能，使管理更加清晰，使后臺易于管理和維護；操作更加靈活、簡單，使資源得到有效的管理和利用，增加管理界面的友好性，嚴格劃分了管理權限，減少人為錯誤的發生幾率。，可以滿足用戶需求，實現主要業務操作，系統到目前為止運行正常，沒有重大漏洞，基本沒有出現過崩潰的情況。本系統的優勢方向在于系統的安全性和穩定性，因為系統直接涉及到通信費用問題，所以需要極高的安全性和保密性，我們使用的技術都是比較成熟和穩定，同時系統設計也比較清晰簡潔，系統經過了多方面的測試，從而保證了數據的安全、穩定。系統的不足在于，系統還不夠智能化和全面化，隨著業務的發展，必然有諸多的地方需要進行進一步的擴展，我們雖然在其中留下了其進一步的拓展空間，但并不能完全保證，系統能適應今后很長時間的需求。致謝感謝在整個畢業設計中曾經給與我幫助的老師、家人、同學、同事、朋友以及很多不認識的熱心人！首先特別要感謝的是王宇穎老師，她能夠在百忙之中給與我悉心的指導，并對我進行鼓勵。那認真敬業的精神值得我一生學習。感謝我的父母，是他們使我有了這樣一個機會去念大學，而且念的衣食無憂。不能有一份好的成績回報，將使我終生愧疚。感謝在北京愛迪通信有限責任公司，實習基地的導師陳顯飄和實習基地的各位同事們，他們給予了我不少的幫助和鼓勵。感謝姐姐、姐夫在北京對我生活的照顧。感謝周圍的一切讓我的生活如此美好！也祝周圍的所有人跟我一樣快樂！參考文獻1. Sandeep Singhal. 移動互聯應用開發技