【軟測測試的案例分析及技術(shù)發(fā)展趨勢探究11000字（論文）】

I軟測測試的案例分析及技術(shù)發(fā)展趨勢探究TOC\o"1-3"\h\z\t"0-1級標題1,1,0-2級標題1,2"30169引言 1118961軟件測試業(yè)現(xiàn)狀 1274502軟件測試的目的 2196532.1測試的目的 2157732.2軟件測試的原則 2214693軟件測試分類 269693.1白盒測試 365253.2黑盒測試 324544測試用例設計實例 32074.1黑盒測試 3276574.1.1等價類劃分法 43454.1.2邊界值分析法 480364.1.3因果圖方法 5170234.1.4錯誤推測方法 5235314.2白盒測試 6225615測試案例分析 7225255.1軟硬件環(huán)境 7207625.1.1網(wǎng)絡拓撲 8146255.1.2Bug趨勢圖 837465.1.3Bug嚴重程度 1036645.1.4Bug引入階段 12214785.1.5Bug引入原因 1296495.1.6Bug狀態(tài)分布 13141715.2測試結(jié)論 13248735.2.1功能性 13111495.2.2易用性 1321515.2.3可靠性 14172735.2.4兼容性 14195415.2.5安全性 14140095.3分析摘要 1438655.3.1覆蓋率 1430785.3.2遺留缺陷的影響 15238145.4軟件測試存在的問題 17176325.4.1軟件測試工作質(zhì)量低,造成糾正性維護工作數(shù)量多 1797745.4.2測試團隊測試用例設計能力不足,無法暴露被測軟件缺陷 17315815.4.3軟件測試缺乏分析工作,無法給軟件維護提供數(shù)據(jù)支持 1714015.4.4維護工作量大,維護工作內(nèi)容記錄過于簡略 18111066軟件測試技術(shù)未來發(fā)展趨勢 1824016.1自動化軟件測試的優(yōu)勢 18273616.2新時代軟件測試技術(shù)的發(fā)展趨勢 19214617總結(jié) 1912497參考文獻 2120931致謝 22第第7頁共9頁引言軟件測試是一種用來描述、促進和鑒定軟件的正確性、完整性、安全性和質(zhì)量的過程，它是一種將實際輸出與期望輸出進行審核或者比較的過程，因此通過軟件測試可以更快速的發(fā)現(xiàn)軟件開發(fā)過程中的各種問題，幫助人們更加高效率的對軟件進行完善，使得軟件的性能逐步提高?，F(xiàn)今社會，隨著大數(shù)據(jù)和云計算的飛速發(fā)展，傳統(tǒng)的軟件測試技術(shù)很難支撐現(xiàn)代軟件的發(fā)展，軟件測試技術(shù)如今面對著新的挑戰(zhàn)。1軟件測試業(yè)現(xiàn)狀近年來，盡管國內(nèi)應用軟件的開發(fā)取得了突飛猛進的發(fā)展，但是離國際先進水平仍然有不小的差距，人們對于軟件質(zhì)量的重視程度越來越高，就導致了測試在軟件開發(fā)中的地位將越來越重要，畢竟測試是目前用來驗證軟件是否能夠完成所期望的功能的唯一有效方法。隨著計算機應用領域的迅速擴大，計算機軟、硬件新技術(shù)的不斷涌現(xiàn)，人們對軟件質(zhì)量提出了新的更高的要求。軟件測試是軟件開發(fā)過程的一個重要組成部分，對于質(zhì)量保證具有舉足輕重的作用，軟件測試的實質(zhì)是根據(jù)軟件開發(fā)各階段的規(guī)格說明和程序的內(nèi)部結(jié)構(gòu)精心選取一批測試數(shù)據(jù)，形成測試用例，并用這些測試用例去驅(qū)動被測程序，觀察程序的執(zhí)行結(jié)果，驗證所得結(jié)果與預期結(jié)果是否一致，然后做相應的調(diào)整。與國外的狀況相比，國內(nèi)在軟件測試方面的研究內(nèi)容相對較少，因為軟件測試在我國起步較晚，起初只是簡單的手工測試，也很少見到各種軟件測試模型，軟件測試時間預測方面的研究也較少，但近幾年來隨著軟件在各個行業(yè)的應用，軟件測試也得以迅速發(fā)展。現(xiàn)代大規(guī)模軟件系統(tǒng)開發(fā)中，多層次分布式結(jié)構(gòu)因其可伸縮性好、可管理性強、安全性高、軟件重用性好以及節(jié)省開發(fā)時間等諸多優(yōu)點而得到廣泛應用。在系統(tǒng)的性能測試過程中，為了取得完整的性能數(shù)據(jù)，測試要求在不同的參數(shù)配置下反復運行、分析和調(diào)試:在同一組參數(shù)配置下，往往還要重復運行多次以收集到更可靠的數(shù)據(jù)，為了模擬系統(tǒng)真實的工作情形或者取得系統(tǒng)的極限狀態(tài)，必須進行強壓力測試，即大批量，長時間地向系統(tǒng)施加負荷。軟件開發(fā)過程中，迭代式的開發(fā)過程己經(jīng)顯示出了與瀑布式開發(fā)相比巨大的好處，并己逐漸取代傳統(tǒng)的瀑布式開發(fā)成為目前最流行的軟件開發(fā)過程。目前的GUI等開發(fā)技術(shù)己經(jīng)非常先進，它提供給開發(fā)人員快捷開發(fā)的能力。保證軟件質(zhì)量關鍵的軟件測試必然需要更多的關注與投入。2軟件測試的目的從不同的立場出發(fā)，對測試目的的理解是不同的，可以從軟件開發(fā)者和用戶兩個角度出發(fā)看看軟件測試的目的。軟件開發(fā)者：希望通過軟件測試驗證該軟件產(chǎn)品達到了用戶的要求，軟件質(zhì)量是有保證的。用戶：希望經(jīng)過軟件測試，暴露出軟件中的錯誤和缺陷，是否完全實現(xiàn)了所期望的軟件功能，從而判斷能否接受該軟件產(chǎn)品。2.1測試的目的（1）證明軟件的功能和性能是否符合規(guī)定的需求（2）為軟件可靠性的分析奠定了基礎；（3）以最少的時間和人力，弄清預期結(jié)果與實際結(jié)果之間的差別。在用戶使用之前，通過發(fā)現(xiàn)并修正錯誤、缺陷來提高軟件質(zhì)量，以避免日后軟件的錯誤和缺陷帶來難以估計的風險。2.2軟件測試的原則（1）軟件開發(fā)者要把“及早地、不斷地進行軟件測試”這一信條付諸行動；（2）由測試輸入數(shù)據(jù)、對應的預期輸出結(jié)果組成測試用例；（3）設計測試用例時，應包括不合理的輸入條件、合理的輸入條件；（4）由于存在盲目的自信，所以程序員應避免檢查自己的程序；（5）排除測試的隨意性，對每一個測試都嚴格執(zhí)行測試計劃；（6）測試后，殘存的缺陷數(shù)和已發(fā)現(xiàn)的缺陷數(shù)成正比，所以測試過程中，要重點測試群集的程序；（7）為了更好地維護軟件，要妥善保存測試計劃、測試用例、出錯統(tǒng)計和分析報告。3軟件測試分類隨著軟件測試技術(shù)的發(fā)展，測試方法更加多樣化，針對性更強;選擇合適的軟件測試方法可以讓我們事半功倍。以下是一些常用的軟件測試方法。比較常見的軟件測試方法為白盒測試與黑盒測試。本文主要以黑盒測試與白盒測試進行說明。3.1白盒測試白盒測試是根據(jù)被測程序的內(nèi)部結(jié)構(gòu)及有關信息來設計測試用例，并測試程序的邏輯路徑，所以白盒測試又稱作結(jié)構(gòu)測試。在全面清楚了解軟件產(chǎn)品的內(nèi)部工作處理過程、程序的語句和結(jié)構(gòu)的前提下，白盒測試要求針對程序模塊的結(jié)構(gòu)特性的達到一定覆蓋率，以檢測軟件工作處理過程的細節(jié)為基礎，通過對程序模塊完成以下工作來對軟件進行驗證：（1）測試程序中每條路徑、所有內(nèi)部成分是否按照規(guī)定和要求進行工作；（2）測試程序內(nèi)部的運行路徑、變量狀態(tài)、邏輯關系等；（3）檢驗程序的運行是否滿足需求設計。3.2黑盒測試黑盒測試是根據(jù)程序的功能來設計測試用例。把被測程序視為一個不能打開的黑盒子，重點放在程序外部結(jié)構(gòu)，不關心內(nèi)部邏輯結(jié)構(gòu)和特性，只針對軟件功能及界面開展測試。4測試用例設計實例隨著軟件測試技術(shù)的發(fā)展，測試方法更加多樣化，針對性更強;選擇合適的軟件測試方法可以讓我們事半功倍。以下是常用的黑盒、白盒測試方法。4.1黑盒測試黑盒測試有時也叫作為功能測試.在這種測試方法中更多的關注于程序的外部結(jié)構(gòu)，不過多考慮內(nèi)部邏輯結(jié)構(gòu)，主要針對軟件界面和軟件功能進行測試。在黑盒測試中，形象的把程序比作一個不能打開的盒子，在不考慮代碼的內(nèi)部流程和內(nèi)部優(yōu)化性能的情況下，對程序的接口各個功能塊等進行測試。它只檢查程序功能是否按照需求規(guī)格說明書的規(guī)定正常使用，不考慮性能是否優(yōu)化合理，只考慮程序是否能正確地接收輸入數(shù)據(jù)而產(chǎn)生正確的輸出信息，不考慮信息處理優(yōu)化性能等。黑盒測試法主要試圖發(fā)現(xiàn)的錯誤有:界面圖形化錯誤，功能模塊錯誤或者遺漏，初始化和終止錯誤，數(shù)據(jù)庫訪問錯誤等;用于黑盒測試的常用方法有如下幾種洲:等價類劃分法、邊界值分析法、因果圖方法、決策表法、錯誤推測方法等。4.1.1等價類劃分法等價類劃分法是指把所有可能的輸入數(shù)據(jù)劃分成若干部分，即將輸入域劃分為若干個子集。在該子集合中，各個輸入數(shù)據(jù)對于發(fā)現(xiàn)程序中的缺陷都是等效的，它們具有等價特性，也就是說從每個子集中選取少量具有代表性的數(shù)據(jù)作為測試用例輸入數(shù)據(jù)，它們就代表了此子集的整個類別。每一類的代表性數(shù)據(jù)在測試中的作用都等價于這一類中的其它數(shù)據(jù)。等價類劃分是黑盒測試用例設計中的常用設計方法，它將本來就不可能窮舉完的測試過程進行合理的分類，從而保證設計出來的測試用例具有典型的代表性和完整性。等價類劃分方法在使用過程中有兩個步驟:第一為分類，分類就是將輸入域輸入空間，按照具有相同特性或者類似功能劃分成各個類或者等價子域;第二為抽象，就是在各個子類中抽象出相同特性，并用要用實例來表征這個特性。等價類劃分可有兩種不同的情況:有效等價類和無效等價類。舉例，在輸入條件規(guī)定了取值范圍或值的個數(shù)的情況下，則可以確立一個有效等價類和兩個無效等價類。4.1.2邊界值分析法邊界值分析法是作為對等價類劃分方法的補充，因為它是對輸入或輸出的邊界值進行測試的一種黑盒測試方法。由于它是對于等價類劃分方法的補充，所以其測試用例數(shù)據(jù)也就來自等價類的邊界。根據(jù)實際項目經(jīng)驗，大部分的問題會出現(xiàn)在輸入域或者輸出域的邊界上，而出現(xiàn)在輸入域或者輸出域的內(nèi)部的情況較少，因此邊界值分析法在實際項目的實施測試過程中很有實用價值。邊界值分析當然不是從某個等價類中隨便挑一個數(shù)據(jù)作為代表，而是將這個等價類的每個邊界都要作為測試條件。一般情況下，邊界值分析不僅考慮輸入條件輸入域，還要考慮輸出空間輸出域產(chǎn)生的測試結(jié)果情況。利用邊界值分析方法設計測試用例，首先要確定邊界情況。別外還要分析規(guī)格說明，找出邏輯中的邊界條件。通常輸入域和輸出域等價類的邊界，就是要著重測試的邊界情況。在數(shù)據(jù)選取時應當選取正好等于這個邊界值，正好小于或正好大于邊界的值作為測試數(shù)據(jù)，而不是選取等價類中的典型值或任意值作為測試數(shù)據(jù)。當然在測試的過程中，這些典型的數(shù)據(jù)也是要測試的。只是在等價類劃分方法中它們不是重點測試對象而已。下面是對于不同的測試項邊界值分析選取典型值的分類總結(jié)（表4.1）。表4.1邊界值分析方法項邊界值設計思路字符起始減去1個字符/結(jié)束加上1個字符假設某個格式輸入?yún)^(qū)域允許輸入1個到1024個字符，輸入1個和1024個字符作為有效等價類，輸入0個和1025個字符作為無效等價類，這幾個數(shù)值都屬于邊界條件值。數(shù)值最小值減去1/最大值加上1假設一個軟件的數(shù)據(jù)輸入4位數(shù)值，可以使用1000作為最小值，9999作為最大值，然后使用剛剛小于4位和大于四位的值作為邊界條件空間小于空余空間一點/大于滿空間一點例如在用硬盤存儲數(shù)據(jù)時，使用比剩余磁盤空間剛好大一點（及KB）的文件作為邊界條件4.1.3因果圖方法因果圖方法是一種利用圖解法分析輸入的各種組合情況，是利用因果圖解法分析輸入組合后從而設計測試用例的方法囚，它適合于要檢查程序輸入條件的各種組合的情況。為何會出現(xiàn)因果圖方法，這還要從等價類劃分法和邊界值分析法說起，因為等價類劃分法和邊界值分析法它們兩個都是著重考慮輸入條件，但沒有考慮輸入條件的各種組合，沒有考慮輸入條件之間的相互制約關系。這樣雖然各種輸入條件可能出錯的情況已經(jīng)測試到了，但多個輸入條件組合起來可能出錯的情況卻容易被忽視，這個問題就要因果圖法來解決。另外一個因果圖法存在的理由是如果在測試時必須考慮輸入條件的各種組合，組合數(shù)目可能會相當大，我們不可能將所有的組合都試一遍，而因果圖是一種適合于描述多種條件的組合邏輯模型，可以產(chǎn)生多個動作的形式來進行測試用例的設計。采用因果圖法設計測試用例的一般需要三個步驟:第一步:根據(jù)需求規(guī)格說明書描述，畫出因果圖。第二步:將因果圖轉(zhuǎn)換為判定表。第三步:將判定表轉(zhuǎn)換為測試用例。4.1.4錯誤推測方法錯誤推測法是基于測試人員的經(jīng)驗和直覺推測程序中所有可能存在的各種錯誤，從而有針對性的去設計測試用例的方法。錯誤推測方法的最基本思想是列舉出程序中所有可能的錯誤和最容易發(fā)生錯誤的特殊情況，從這一點就可以看出經(jīng)驗在這個方法里的要求是很高的，根據(jù)羅列出的的條件來選擇測試用例。以上列舉了黑盒測試常用的方法，下面是黑盒測試的流程:黑盒測試的簡要流程，第一步:測試計劃。第二步:測試設計。第三步:測試開發(fā)。第四步:測試執(zhí)行。第五步:測試評估4.2白盒測試白盒測試也稱結(jié)構(gòu)性測試或者邏輯驅(qū)動測試，它是按照程序內(nèi)部的結(jié)構(gòu)來測試程序，通過測試來檢測軟件內(nèi)部是否按照需求規(guī)格說明書與設計規(guī)格說明書的規(guī)定正常進行，檢測程序代碼中的每條路徑是否都能按預定的要求正確工作。白盒測試最主要關注的是測試用例執(zhí)行的程度，或者覆蓋程序源代碼邏輯結(jié)構(gòu)的程度。白盒測試法要試圖發(fā)現(xiàn)的缺陷與錯誤如下:對程序模塊的所有獨立的執(zhí)行路徑至少測試一次，看各個獨立模塊是否正確。對所有的邏輯判定，將所有真假情況都要遍歷到，取“真”與取“假”的兩種情況都最少測試一次。在循環(huán)的邊界和運行界限內(nèi)執(zhí)行循環(huán)體，測試循環(huán)體是否正確。測試程序內(nèi)部數(shù)據(jù)結(jié)構(gòu)的有效性等。用于白盒測試的常用方法有如下幾種:白盒測試的測試方法有代碼檢查法、靜態(tài)結(jié)構(gòu)分析法、靜態(tài)質(zhì)量度量法、邏輯覆蓋法、基本路徑測試法、域測試、符號測試、Z路徑覆蓋、程序變異。白盒測試法的覆蓋標準有邏輯覆蓋、循環(huán)覆蓋和基本路徑測試。常用的六種覆蓋標準語句覆蓋、判定覆蓋、條件覆蓋、判定/條件覆蓋、條件組合覆蓋和路徑覆蓋，它們發(fā)現(xiàn)錯誤的能力呈由弱至強的變化趨勢（表4.2，圖4.1）。表4.2六種覆蓋標準定義對比表語句覆蓋指的是每條語句最少執(zhí)行一次判定覆蓋指的是每個判定的分支最少執(zhí)行一次條件覆蓋每個判定的每個條件都要取到可能的值判定判定/條件覆蓋顧名思義同時滿足判定覆蓋與條件覆蓋的情況條件組合覆蓋每個判定中各條件的每一種組合最少出現(xiàn)一次路徑覆蓋使程序中每一條可能的路徑最少執(zhí)行一次采用白盒測試設計測試用例的一般需要三個步驟:第一步:根據(jù)代碼的功能、程序控制流程圖，規(guī)劃測試用例;第二步:統(tǒng)計覆蓋率，比較理想的覆蓋率是實現(xiàn)100%;第三步:捕捉可能未處理的某些特殊輸入所形成的錯誤或者缺陷來補充測試用例。路徑測試利用流圖標識獨立路徑等路徑測試分支測試域測試等控制結(jié)構(gòu)測試路徑測試包含循環(huán)和嵌套選擇路徑的策略路徑測試簡單循環(huán)嵌套串接無結(jié)構(gòu)循環(huán)路徑選擇圖4.1控制結(jié)構(gòu)測試方法5測試案例分析5.1軟硬件環(huán)境硬件環(huán)境應用服務器數(shù)據(jù)庫服務器客戶端硬件配置CPU：Intel(R)Celeron(R)CPU2.40GHzstepping01Memory：1048256kHD：ST380817AS80GSATACPU：Intel(R)Celeron(R)CPU2.40GHzstepping01Memory：1048256kHD：ST380817AS80GSATACPU：Intel(R)Celeron(R)CPU2.40GHzstepping01Memory：1048256kHD：ST380817AS80GSATA軟件配置OS：CentOS4.2JDK1.5.0_06Apache2.2.0Tomcat5.5.15OS：CentOS4.2MySQL5.0.17LinuxWindow2000Professional（SP2）IE6.0.2900.2180.xpsp_sp2網(wǎng)絡環(huán)境10MLAN10MLAN10MLAN5.1.1網(wǎng)絡拓撲5.1.2Bug趨勢圖此次黑盒測試總共發(fā)布11個版本，B1—B5為計劃內(nèi)迭代開發(fā)版本（針對項目計劃的基線標識），B6-B11為進行的回歸測試版本，bug版本趨勢圖如下圖所示：第一階段，增量確認測試。時間從2011年7月2日到2011年8月3日。從Bug趨勢圖中可以看出，每個版本的bug數(shù)基本維持在60個左右。B1：從圖中看到B1共有33個BUG，因為B1版本有一個功能模塊在B2版本才開始測試，B1測試模塊相對較少，所以B1版本bug相對較少。B2：由于B1中的一個功能模塊增加到Build2中進行測試，這一版本除了對B1中的BUG進行驗證同時對B1進行了回歸測試，所以B2中的bug數(shù)相對B1出現(xiàn)了明顯的增長趨勢，B3：B3版本因為有B2版本的bug驗收測試，以及B1,B2的回歸測試，共發(fā)現(xiàn)67個bug，和B2基本保持一致。B4：B4版本bug數(shù)有一個下降的趨勢，是因為B4版本推遲發(fā)布，新增加了測試人員參與測試，對系統(tǒng)不夠熟悉，以及測試時間緊張，部分測試用例沒有執(zhí)行，測試覆蓋度不夠，所以發(fā)現(xiàn)bug數(shù)呈下降趨勢。B5：B5版本bug數(shù)又有一個增加的趨勢，主要是由于開發(fā)功能模塊多，該版本需求定義不明確。第二階段，BUG驗證和功能回歸確認測試。時間從2011年8月4日到2011年8月14日。B6和B7進行了回歸測試，B8沒有進行回歸測試，只驗證了B1－B7的bug。B6：進行第一輪回歸測試，發(fā)現(xiàn)的bug數(shù)為33個，遺留一個問題，為數(shù)據(jù)字典種類默認值問題B7：進行第二輪回歸測試，第一次回歸測試沒有涉及到權(quán)限控制菜單按鈕的測試，在本次回歸測試的時候，重點進行了這個方面的測試，又發(fā)現(xiàn)了大量的權(quán)限相關的bug。B8：B8沒有進行全面的回歸測試，只驗證了B1－B7未通過驗證的bug，所以該版本的bug數(shù)明顯比較少。B9：B9版本進行了全面的回歸測試，同時重點測試了權(quán)限控制，所以發(fā)先的bug數(shù)又呈現(xiàn)上升的趨勢。測試發(fā)現(xiàn)44個bug，嚴重級別的bug為14個，嚴重級別的bug集中在權(quán)限控制上，功能性嚴重bug沒有發(fā)現(xiàn)，說明權(quán)限控制依舊不穩(wěn)定，但是系統(tǒng)功能已經(jīng)穩(wěn)定。B10：B10版本驗證了B9版本發(fā)現(xiàn)得bug，沒有進行全面的回歸測試。B10版本在驗證bug的時候，重現(xiàn)打開Bug6個，新增bug2個，重新打開bug有5個為嚴重級別bug，是關于權(quán)限控制的bug，而新發(fā)現(xiàn)的bug，1個為嚴重級別的bug，也是屬于權(quán)限控制的。說明，權(quán)限控制還存在著問題，需要修改權(quán)限管理bug，重新發(fā)布版本后進行全面的回歸測試。B10版本新發(fā)現(xiàn)的bug詳細分析見HYPERLINK遺留bug分析。B11：B11中驗證了B1—B10未驗證的bug，重點測試了權(quán)限控制，同時進行了查詢，添加，刪除，修改的功能測試，測試過程中未發(fā)現(xiàn)bug。5.1.3Bug嚴重程度測試發(fā)現(xiàn)的bug主要集中在normal和minor階段，屬于一般性的缺陷，但是測試的時候，出現(xiàn)了68個嚴重級別的bug，出現(xiàn)嚴重級別的bug主要表現(xiàn)在以下幾個方面（1）系統(tǒng)主要功能沒有實現(xiàn)（2）添加數(shù)據(jù)代碼重復后，出現(xiàn)的找不到頁面的錯誤（3）多語言處理，未考慮非語種代碼的情況（4）數(shù)據(jù)庫設計未考慮系統(tǒng)管理員角色，導致用系統(tǒng)管理員進行操作的時候出現(xiàn)找不到頁面錯誤（5）權(quán)限控制異常（6）嚴重級別bug按版本分布如下：由嚴重bug版本分布圖可以看出，嚴重級別的bug版本趨勢和bug版本趨勢基本是一致的，但是，在B7和B9版本中年，嚴重級別的bug明顯增多，主要原因是B7和B9版本測試了權(quán)限控制按鈕功能，權(quán)限問題出現(xiàn)的嚴重級別的bug比較多。權(quán)限bug主要表現(xiàn)：（1）具有相應按鈕操作的權(quán)限，頁面無相應按鈕，無法執(zhí)行該功能（2）無相應按鈕操作權(quán)限，頁面有相應按鈕，點擊按鈕能出現(xiàn)權(quán)限異常錯誤（3）有相應按鈕操作權(quán)限，有相應按鈕，執(zhí)行該功能出現(xiàn)權(quán)限異常錯誤5.1.4Bug引入階段由上圖可以看出，主要為前臺編碼和頁面設計方面的bug，占到了全部bug的2/3。5.1.5Bug引入原因由上圖可以看出，主要為前臺編碼和易用性方面的bug，占到了全部bug的2/3。5.1.6Bug狀態(tài)分布由bug狀態(tài)圖可以看出，未解決的bug有4個，主要是B8中新提交的bug，是關于用戶管理的bug，因為用戶權(quán)限管理需要重新設計所以，該部分的bug暫時沒有解決。5.2測試結(jié)論5.2.1功能性系統(tǒng)正確實現(xiàn)了通過數(shù)據(jù)字典管理基礎數(shù)據(jù)的功能，實現(xiàn)了數(shù)據(jù)內(nèi)容的多語言功能，實現(xiàn)了中英文界面。實現(xiàn)了基礎數(shù)據(jù)管理，酒店集團管理，酒店基礎信息管理，渠道管理，代理管理，用戶管理的查詢，添加，修改，刪除的功能，系統(tǒng)還實現(xiàn)了將權(quán)限控制細化到菜單按鈕的功能。系統(tǒng)在實現(xiàn)用戶管理下的權(quán)限管理功能時，存在重大的缺陷，權(quán)限控制不嚴密，權(quán)限設計有遺漏。5.2.2易用性現(xiàn)有系統(tǒng)實現(xiàn)了如下易用性：（1）查詢，添加，刪除，修改操作相關提示信息的一致性，可理解性（2）輸入限制的正確性（3）輸入限制提示信息的正確性，可理解性，一致性現(xiàn)有系統(tǒng)存在如下易用性缺陷：（1）界面排版不美觀（2）輸入，輸出字段的可理解性差（3）輸入缺少解釋性說明（4）中英文對應的正確性（5）中英文混排5.2.3可靠性現(xiàn)有系統(tǒng)的可靠性控制不夠嚴密，很多控制是通過頁面控制實現(xiàn)的，如果頁面控制失效，可以向數(shù)據(jù)庫插入數(shù)據(jù)，引發(fā)錯誤?，F(xiàn)有系統(tǒng)的容錯性不高，如果系統(tǒng)出現(xiàn)錯誤，返回錯誤類型為找不到頁面錯誤，無法回復到出錯前的狀態(tài)5.2.4兼容性現(xiàn)有系統(tǒng)支持window下的IE瀏覽器和傲游瀏覽器，支持linux系統(tǒng)下的IE瀏覽器和火狐瀏覽器。5.2.5安全性現(xiàn)有系統(tǒng)控制了以下安全性問題：（1）把某一個登錄后的頁面保存下來，不能單獨對其進行操作不進行登錄（2）直接輸入某一頁面的Url能否打開頁面并進行操作不應該允許?，F(xiàn)有系統(tǒng)未控制以下安全性問題：（3）用戶名和密碼應對大小寫敏感（4）登陸錯誤次數(shù)限制5.3分析摘要5.3.1覆蓋率此次測試，所有測試用例都是在中文界面下執(zhí)行，未在英文界面下執(zhí)行，測試不包括英文界面下的測試，也不包括正對英文翻譯的測試。此次測試，部分頁面需求描述無明確的定義，對輸入限制無詳細定義，無明確的測試依據(jù)，在測試過程中，測試是根據(jù)輸入字段含義，測試人員理解，以及和項目經(jīng)理，開發(fā)人員溝通獲得測試依據(jù)，無法保證測試依據(jù)的正確性和完整性，因此，沒有進行完整的，正確的無效數(shù)據(jù)的測試，測試覆蓋率不夠，無法保證測試的有效性和正確性。下面為此次測試測試用例覆蓋率分析圖：5.3.2遺留缺陷的影響缺陷描述：酒店娛樂項添加頁面，“距離”字段無單位，建議增加單位缺陷影響：距離字段無單位說明，無衡量標準，用戶易用性不好推遲原因：需求定義無單位定義，統(tǒng)一在升級版本中解決缺陷描述：酒店基礎信息管理模塊，默認語言設置不一致。用中文查詢酒店，進入酒店基礎信息模塊后，如下模塊，語言顯示為“請選擇”列表頁面添加頁面取消政策停留政策擔保政策機場參照點會議室詳情打包促銷服務Rate而其他模塊語言顯示“中文語言”缺陷影響：相同功能模塊默認語言設置不一致，一致性不好推遲原因：默認語言設置，目前無統(tǒng)一標準，升級版本中統(tǒng)一缺陷描述：tomcat日志有亂碼，日志無項目名稱，查看不方便缺陷影響：其他項目日志都有項目名稱，日志無項目名稱，查看不方便推遲原因：目前的日志為了調(diào)試方便，顯示了很多其它信息，在項目正式發(fā)布時會統(tǒng)一處理的。缺陷描述：取消政策管理要么，取消時間“天/小時”缺少單位補充字段缺陷影響：該處因為是兩個不同的單位時間，需要有另外一個單位補充字段補充所所填寫內(nèi)容的單位推遲原因：該缺陷單位補充字段本來存在，翻譯不夠準確，不能理解為補充單位的字段，需要等翻譯完畢后再確認。缺陷描述：數(shù)據(jù)字典種類修改，默認值設置后，在調(diào)用該數(shù)據(jù)字典種類的數(shù)據(jù)字典，默認值無顯示缺陷影響：數(shù)據(jù)字典種類的默認值設置后，不能顯示設置的默認值，相當于數(shù)據(jù)字典種類默認值設置功能未實現(xiàn)推遲原因：該功能暫時不好實現(xiàn)，需要和和系統(tǒng)的默認語種一起處理。缺陷描述：擔保政策管理頁面，“EdpositDue”缺少解釋行輸入描述信息缺陷影響：缺少解釋性輸入描述信息，用戶不理解應該輸入什么內(nèi)容推遲原因：需求沒有描述，需要解釋性說明文字由項目經(jīng)理整理后，在升級版本中添加缺陷描述：多媒體添加，文件上傳功能未實現(xiàn)缺陷影響：文件上傳功能未實現(xiàn)推遲原因：該功能暫時不好完成，在下個版本中完成缺陷描述：參照點添加權(quán)限和修改權(quán)限單獨控制出現(xiàn)權(quán)限異常錯誤缺陷影響：用戶執(zhí)行添加，修改時，出現(xiàn)權(quán)限異常，無法完成任務推遲原因：B9版本發(fā)現(xiàn)該權(quán)限，B10版本未通過驗證，目前該模塊開發(fā)人員調(diào)休，無法修改bug，缺陷描述：酒店渠道綁定關系權(quán)限控制出現(xiàn)權(quán)限異常錯誤缺陷影響：a>權(quán)限控制易用性不好，會引起用戶誤操作;b>權(quán)限控制錯誤推遲原因：B9版本發(fā)現(xiàn)該權(quán)限，B10版本未通過驗證。該模塊后臺無insert權(quán)限,只有Update權(quán)限，與其他模塊不同，需要重新設置權(quán)限控制方式。缺陷描述：酒店Rate綁定關系權(quán)限控制出現(xiàn)權(quán)限異常錯誤缺陷影響：a>權(quán)限控制易用性不好，會引起用戶誤操作;b>權(quán)限控制錯誤推遲原因：B9版本發(fā)現(xiàn)該權(quán)限，B10版本未通過驗證。該模塊后臺無insert權(quán)限,只有Update權(quán)限，與其他模塊不同，需要重新設置權(quán)限控制方式。缺陷描述：新建業(yè)務管理員權(quán)限用戶，進入打包促銷頁面出現(xiàn)權(quán)限異常錯誤缺陷影響：除系統(tǒng)管理員外，其他用戶無法進行打包促銷操作推遲原因：B10版本發(fā)現(xiàn)該bug，目前該模塊開發(fā)人員調(diào)休，無法修改bug5.4軟件測試存在的問題5.4.1軟件測試工作質(zhì)量低,造成糾正性維護工作數(shù)量多根據(jù)公司的維護數(shù)據(jù)記錄，每天至少出現(xiàn)9次軟件缺陷引起的維護問題，說明軟件系統(tǒng)存在很多缺陷，影響用戶的正常使用。大多數(shù)軟件缺陷是在軟件測試過程中發(fā)現(xiàn)的。維護數(shù)據(jù)反映了軟件測試工作相對較低的質(zhì)量。5.4.2測試團隊測試用例設計能力不足,無法暴露被測軟件缺陷測試團隊測試用例設計能力不足,體現(xiàn)在兩個方面:（1）有效測試用例數(shù)量不足；（2）缺乏“非功能性”測試對比。此外，該公司平均每千行代碼有8.06個有效測試用例，這僅滿足行業(yè)平均最低要求，正常的用戶操作會導致錯誤。經(jīng)過調(diào)查，發(fā)現(xiàn)模塊在測試時沒有考慮客戶的一些要求。一個操作過程，然后發(fā)現(xiàn)操作過程中沒有缺陷。5.4.3軟件測試缺乏分析工作,無法給軟件維護提供數(shù)據(jù)支持非標準的管理軟件測試團隊的測試文檔和數(shù)據(jù)主要反映在以下幾個方面:(1)項目團隊中有三個測試工程師團隊，只有一團隊寫了實驗文件和測試數(shù)據(jù)，使項目經(jīng)理難以成功通過測試。(2)由于上述原因，測試小組難以提供足夠的數(shù)據(jù)來分析不足之處，結(jié)果H公司沒有管理管理來管理測試中發(fā)現(xiàn)的不足之處。無論是單元格測試還是組裝測試，理想的軟件測試都需要工具，如缺陷表，以發(fā)現(xiàn)故障，進行統(tǒng)計分析和數(shù)據(jù)匯編。下表描述有缺陷的軟件故障，并詳細闡述了若干原因。軟件測試工程師需要分析在測試中發(fā)現(xiàn)的軟件缺陷，并在最初披露后予以記錄。表5.1“缺陷登記匯總表”內(nèi)容說明5.4.4維護工作量大,維護工作內(nèi)容記錄過于簡略目前公司的年生產(chǎn)能力為4200(萬/天)。據(jù)此計算，每個終端的年平均吞吐量為600(萬/天)，日平均吞吐量分別為600/365(百萬/天)和16438(百萬/天)。如果軟件故障率為萬分之一，則平均每個集裝箱碼頭每天有164個集裝箱出現(xiàn)問題;在上海以外，現(xiàn)在有幾十個港口使用同樣的產(chǎn)品，而且出現(xiàn)錯誤的概率相同。這可能導致每天維護幾十個(萬/天)。再加上支持生產(chǎn)系統(tǒng)的各種調(diào)度平臺和數(shù)據(jù)傳輸接口，每一個錯誤都可能導致問題。公司承諾客戶系統(tǒng)必須提供7×24小時的維護支持，要求在1小時內(nèi)接聽維護電話，公司全年因各種軟硬件故障關閉時間不得超過4小時。在這種情況下，當處理維護請求時，維護團隊首先要確?？焖俳鉀Q客戶問題。因此，維護工程師經(jīng)常在很大的壓力下工作，沒有太多的時間來改進和記錄維修。失敗的簡要記錄。在測試環(huán)境中，用戶沒有足夠的時間收集、記錄、組織詳細的故障數(shù)據(jù)，分析故障原因，無法復制用戶報告，導致軟件運行中出現(xiàn)各種各樣的問題。6軟件測試技術(shù)未來發(fā)展趨勢6.1自動化軟件測試的優(yōu)勢與人工測試相比，自動化軟件測試能較大程度地提高了軟件測試的整體效率。但很多企業(yè)往往采取人工結(jié)合自動化的方式去開展測試相關的工作，而不是讓自動化測試全面取代人工測試，這也側(cè)面反映出了自動化測試雖然有很大的優(yōu)勢，但也不是萬能的。自動化測試的另一個優(yōu)勢是它能夠降低軟件測試的風險，避免一些人為因素致使的測試問題的發(fā)生。當自動化測試擔當測試的主體時，人工就能更加專注地去設計測試案例并分析結(jié)果，分工明確會讓一些原本很復雜的測試項目變得簡單很多，尤其是進行回歸測試消耗的時間成本下降，也能大大提高工作效率。6.2新時代軟件測試技術(shù)的發(fā)展趨勢軟件技術(shù)在發(fā)展，軟件測試技術(shù)也在發(fā)展，就目前軟件測試技術(shù)的發(fā)展現(xiàn)狀而言，未來軟件測試的發(fā)展趨勢主要體現(xiàn)在三個方面，包括易測試性、構(gòu)建測試、Web測試。易測試性就是在軟件設計和開發(fā)中就考慮測試問題，包括：內(nèi)建式測試問題、內(nèi)建式自測試問題、合約式測試問題等。構(gòu)建測試是未來軟件測試的主要趨勢，在軟件測試中，存在很多問題，如：測試人員經(jīng)驗不足，發(fā)現(xiàn)問題后無法及時采取有針對性的解決辦法，從而影響了軟件測試的效率，但軟件測試具有很強的綜合性和技術(shù)性，培養(yǎng)一名合格的軟件測試員，需要花費大量時間和精力。而通過軟件測試復用技術(shù)可有效解決這一問題，軟件構(gòu)建測試就是軟件復用的基礎和關鍵，可通過軟件構(gòu)建技術(shù)，來獨立完成軟件一些功能的有效測試，并交付使用這些封裝的測試用例，提升軟件測試的有效性和規(guī)范性。Web測試可很好的適應現(xiàn)代化軟件行業(yè)的發(fā)展需求，在現(xiàn)代化大環(huán)境下，軟件產(chǎn)品的研發(fā)模式，已經(jīng)從最開始的單純制造，轉(zhuǎn)變?yōu)橐钥蛻魹橹行牡膭漳Ｊ?。比如：WWW從最開始的兩層體系，逐步轉(zhuǎn)變?yōu)槿龑臃謱蛹夹g(shù)，甚至是四層分層