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

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