緒論軟件測試的背景和意義軟件測試，是為了尋找缺陷，缺陷又稱BUG。從電腦被發(fā)明起，電腦就存在缺陷。第一個(gè)發(fā)現(xiàn)有bug是格蕾斯·哈珀（GraceHopper），她是編譯器的發(fā)明者。在1945年9月9日，當(dāng)時(shí)她和她的團(tuán)隊(duì)正在研究一個(gè)計(jì)算機(jī)，該計(jì)算機(jī)在當(dāng)時(shí)還不是一個(gè)完全的電子計(jì)算機(jī)，是一種復(fù)雜而又大型的電子機(jī)械裝置。實(shí)驗(yàn)環(huán)境并不可觀，天氣熱且實(shí)驗(yàn)室沒有散熱系統(tǒng)，在高溫環(huán)境下，計(jì)算機(jī)因無法散熱降溫宕機(jī)了。技術(shù)人員嘗試許多方案去解決，讓計(jì)算機(jī)重新運(yùn)作起來。嘗試了許多解決方案，排查問題，最終發(fā)現(xiàn)是第70號(hào)繼電器無法正常運(yùn)行。哈珀觀察這個(gè)出錯(cuò)的繼電器，發(fā)現(xiàn)一只被繼電器打死的飛蛾，她將飛蛾小心翼翼的拿了出來，記錄在記事本中，并注明“第一個(gè)發(fā)現(xiàn)bug的實(shí)例?！弊源酥?，在計(jì)算機(jī)發(fā)展歷史中，人們將在電腦系統(tǒng)或程序中的錯(cuò)誤稱為蟲子（bug），這就是‘bug’的由來?；仡欆浖y試的發(fā)展歷程，早期的軟件測試只是為了“調(diào)試”，檢測該系統(tǒng)是否可正常運(yùn)行；在軟件工程建立前，軟件測試是為表明程序正確而進(jìn)行測試；1972年，首屆軟件測試大會(huì)在北卡羅來納大學(xué)舉行，大會(huì)宣布：軟件測試作為一項(xiàng)正式而獨(dú)立的工作。1975年，《測試數(shù)據(jù)選擇的原理》這篇文章由JohnGoodEnough和SusanGerhart在IEEE上發(fā)表，軟件測試被確定為一種研究方向。1979年，Glenford?Myers著作《軟件測試藝術(shù)》一書，對(duì)測試重新做了定義：測試是為發(fā)現(xiàn)錯(cuò)誤而執(zhí)行的一個(gè)程序或者系統(tǒng)的過程。20世紀(jì)80年代早期，隨著用戶體驗(yàn)性的要求越來越大，軟件質(zhì)量的越來越受重視，測試不僅僅是一個(gè)發(fā)現(xiàn)錯(cuò)誤的過程，還包含軟件質(zhì)量評(píng)價(jià)的內(nèi)容。從此軟件測試定義發(fā)生了改變，并且制定了對(duì)軟件測試的各項(xiàng)標(biāo)準(zhǔn)。隨后在1983年，《軟件測試完全指南》著作的作者BillHetzel正式提出：以評(píng)價(jià)一個(gè)程序或者系統(tǒng)屬性為目標(biāo)的任何一種活動(dòng)都可稱之為軟件測試，測試是對(duì)軟件質(zhì)量的度量。20世紀(jì)90年代，測試工具逐漸發(fā)展且應(yīng)用了起來。到了2002年，《系統(tǒng)的軟件測試》的作者Rick和Stefan在書中對(duì)軟件測試做了進(jìn)一步完善的定義：測試是為了測量和提高被測軟件的質(zhì)量，對(duì)測試軟件進(jìn)行工程設(shè)計(jì)、實(shí)施和維護(hù)的整個(gè)生命周期過程。從軟件測試的發(fā)展過程中不難發(fā)現(xiàn)，從最初僅驗(yàn)證系統(tǒng)是否可正常運(yùn)行到發(fā)現(xiàn)錯(cuò)誤到保障軟件質(zhì)量，軟件測試在逐漸成熟且運(yùn)用到系統(tǒng)中?，F(xiàn)代測試的目的是為了系統(tǒng)投入使用前，模擬用戶真實(shí)操作，盡可能排查系統(tǒng)的故障點(diǎn)。軟件測試的理論基礎(chǔ)1.2.1軟件測試的定義軟件測試伴隨軟件開發(fā)而生。1979年，《TheArtofSoftwareTesting》的作者GlenfordJ.Myers，定義了軟件測試：“軟件測試就是為了發(fā)現(xiàn)錯(cuò)誤而執(zhí)行程序或者系統(tǒng)的過程”。在此定義中表明進(jìn)行軟件測試是為了發(fā)現(xiàn)程序中的錯(cuò)誤。在軟件工程運(yùn)用起來之前，開發(fā)軟件的規(guī)模比較小，軟件開發(fā)的過程雜亂無章，過程隨意。開發(fā)人員完成軟件編寫工作并自己完成調(diào)試與運(yùn)行，此時(shí)的測試過程不算嚴(yán)謹(jǐn)，測試工作內(nèi)容沒有明確的定義，開發(fā)人員測試自己寫的程序相當(dāng)于改正軟件中的已知錯(cuò)誤，這樣的模式需要等到代碼基本完成，產(chǎn)品已有基本雛形時(shí)才進(jìn)行測試。因此，在這種模式下的軟件開發(fā)，他定義的軟件測試在當(dāng)時(shí)被人們廣泛接受并投入運(yùn)用到項(xiàng)目中。到了上世紀(jì)80年代初期，軟件行業(yè)快速發(fā)展，軟件大且復(fù)雜，逐漸開始面向用戶使用，人們逐漸意識(shí)到軟件的質(zhì)量越來越重要。GlenfordJ.Myers定義的軟件測試已經(jīng)無法滿足當(dāng)前要求，在這個(gè)大環(huán)境下，在發(fā)展中人們對(duì)軟件測試的理論基礎(chǔ)和應(yīng)用已逐漸形成。于是在1983年，IEEE對(duì)軟件測試的定義做出了調(diào)整，即“使用人工或者自動(dòng)的手段來運(yùn)行或測量軟件系統(tǒng)的過程，以檢驗(yàn)軟件系統(tǒng)是否滿足定義的需求，并找出與預(yù)期結(jié)果之間的差異。”。新的軟件測試的定義繼承了之前對(duì)軟件測試定義中的精華，另外還完善了不足之處，軟件測試可作為保證軟件質(zhì)量的一個(gè)重要方法，其主要內(nèi)容是驗(yàn)證軟件中各個(gè)功能模塊，檢查整個(gè)系統(tǒng)是否可正確且完整地運(yùn)行預(yù)期的功能，以保障軟件質(zhì)量。同時(shí)，人們也應(yīng)需要而開始為軟件開發(fā)設(shè)計(jì)了更有效的管理流程的方法，軟件系統(tǒng)的研發(fā)模式也逐漸由起初的雜亂無章的系統(tǒng)研發(fā)過程逐漸過渡到規(guī)范清晰的結(jié)構(gòu)化開發(fā)過程，擁有規(guī)范的結(jié)構(gòu)化分析與設(shè)計(jì)、結(jié)構(gòu)化需求項(xiàng)目評(píng)審、結(jié)構(gòu)化程序設(shè)計(jì)以及結(jié)構(gòu)化測試為特征。最主要的是人們將“質(zhì)量”為主的概念融入整個(gè)項(xiàng)目周期中。測試工作不僅僅是一個(gè)發(fā)現(xiàn)錯(cuò)誤的過程，而是與整個(gè)軟件周期融合一體，將測試工作作為保障軟件質(zhì)量的主要職能。1.2.2軟件測試的目的關(guān)于軟件測試，GlenfordJ.Myers定義的軟件測試的目的是為了發(fā)現(xiàn)程序中更多的錯(cuò)誤。隨著軟件測試定義不斷完善，軟件測試的定義也相對(duì)清晰，人們意識(shí)到軟件測試不僅僅是找出軟件中的錯(cuò)誤，同時(shí)也是保障軟件質(zhì)量的過程。對(duì)于測試人員來說更重要的是分析錯(cuò)誤產(chǎn)生的原因與意識(shí)到錯(cuò)誤帶來隱患，這樣可以協(xié)助開發(fā)人員盡早發(fā)現(xiàn)缺陷并及時(shí)修正系統(tǒng)缺陷，從而保障軟件質(zhì)量。在軟件投入正式運(yùn)行前，盡可能的模擬用戶可能會(huì)發(fā)生的操作，排查系統(tǒng)缺陷并加以改正，確保軟件質(zhì)量，降低軟件缺陷給軟件系統(tǒng)帶來的風(fēng)險(xiǎn)。另一方面，達(dá)成軟件測試的目的，也提高用戶對(duì)軟件的使用感。1.2.3軟件測試的內(nèi)容軟件測試的主要工作內(nèi)容是“驗(yàn)證”和“確認(rèn)”兩部分，在整個(gè)軟件生命周期中，確保各個(gè)環(huán)節(jié)的正確性。1.驗(yàn)證：保證軟件正確的實(shí)現(xiàn)了既定的原有需求功能（1）確定軟件在生命周期中在完成階段的產(chǎn)品是否達(dá)到與預(yù)期需求一致的過程。（2）證明程序的正確性程，通過運(yùn)用軟件測試的方法來證明程序是否符合預(yù)期設(shè)計(jì)要求的過程。（3）通過評(píng)審、審查、測試、檢查等方式，對(duì)是否符合預(yù)期設(shè)計(jì)要求進(jìn)行判斷和提出相應(yīng)的報(bào)告。2.確認(rèn)：通過一系列的項(xiàng)目流程和測試方法，在特定的用戶場景中，確保軟件的運(yùn)行與預(yù)期結(jié)果一致。（1）靜態(tài)確認(rèn)，不在計(jì)算機(jī)上運(yùn)行程序，通過人工干預(yù)或分析程序的方法來證明該軟件系統(tǒng)的正確性。（2）動(dòng)態(tài)確認(rèn)，通過執(zhí)行程序，做出相關(guān)分析，觀察程序的動(dòng)態(tài)表現(xiàn)，來證明軟件是否正確。1.2.4軟件測試的原則軟件測試是在軟件生命周期中，在一定的需求下對(duì)程序進(jìn)行規(guī)范的操作，來發(fā)現(xiàn)程序的缺陷，保障軟件質(zhì)量，并評(píng)估該程序是否滿足預(yù)期的設(shè)計(jì)要求。軟件測試的基本原則貫穿整個(gè)軟件生命周期，幫助軟件測試人員盡早且盡可能多的發(fā)現(xiàn)問題，并盡早讓開發(fā)人員改正，有利于提高產(chǎn)品質(zhì)量，軟件測試人員負(fù)責(zé)尋找程序中的問題、評(píng)估、提出建議并加以跟進(jìn)，從而不斷改進(jìn)測試過程。軟件測試有以下幾種原則，分別為：測試證明系統(tǒng)有缺陷，無法證明系統(tǒng)不存在缺陷通過測試手段可以找出系統(tǒng)中的缺陷，減少軟件中存在缺陷的數(shù)量，但無法證明系統(tǒng)不存在缺陷。即便在測試過程中沒有發(fā)現(xiàn)任何缺陷，也不能完全的說這個(gè)系統(tǒng)不存在缺陷。無法進(jìn)行窮舉測試在軟件測試的過程中，大多數(shù)情況下進(jìn)行窮舉測試是無法實(shí)現(xiàn)的。如測試系統(tǒng)所有會(huì)發(fā)生的情況，軟件質(zhì)量并不會(huì)因此而提高，反而測試在某一功能點(diǎn)投入量太大，會(huì)影響整個(gè)項(xiàng)目進(jìn)度。此時(shí)應(yīng)遵循Good-enough的測試原則，來保證測試效果?？紤]用戶大概率可能輸入的情況，并加以組合，選取有代表性的輸入值作為一類的測試數(shù)據(jù)來進(jìn)行測試，有當(dāng)滿足一定的測試輸出結(jié)果時(shí)該類測試就需終止。3.測試的盡早介入通過大量的實(shí)驗(yàn)證明，在軟件開發(fā)生命周期中早期發(fā)現(xiàn)錯(cuò)誤的概率較大，修復(fù)缺陷的成本也較低。在軟件開發(fā)生命周期后期，缺陷有存在趨于放大的趨勢。因此，越在軟件生命周期后期，項(xiàng)目團(tuán)隊(duì)在軟件維護(hù)階段修復(fù)缺陷成本會(huì)越來越大。因此，在軟件投入使用前，測試人員要盡早的且不斷的對(duì)軟件進(jìn)行測試，盡可能的找出更多的缺陷，開發(fā)人員盡早的修復(fù)缺陷，提高軟件的整體質(zhì)量，降低軟件開發(fā)成本，提高用戶的使用感。4.缺陷的集群性根據(jù)實(shí)驗(yàn)表明：80%的錯(cuò)誤集中存在于20%的程序模塊中。缺陷不是平均分布而是集群分布的，因此在進(jìn)行測試過程中，如果在某一模塊或程序發(fā)現(xiàn)了很多缺陷，那么通常在這個(gè)模塊或類似功能模塊中可以發(fā)現(xiàn)更多的缺陷。因此要花費(fèi)更多的時(shí)間關(guān)注對(duì)這部分模塊，進(jìn)行反復(fù)且深入的測試，利用缺陷的集群性，關(guān)注相關(guān)測試點(diǎn)，進(jìn)行充分的測試。5.排除隨意性測試與缺陷發(fā)生的偶然性測試計(jì)劃的內(nèi)容包含進(jìn)行軟件測試的測試規(guī)范，測試方案，測試范圍等，一般包括會(huì)要求測試數(shù)據(jù)的規(guī)范，測試工具的使用，測試文檔的輸出。嚴(yán)格按測試計(jì)劃執(zhí)行，按時(shí)間完成各階段測試節(jié)點(diǎn)，避免測試的隨意性。在進(jìn)行測試過程中，在某個(gè)測試點(diǎn)上，如發(fā)現(xiàn)了缺陷，不應(yīng)立馬下結(jié)論是因某種操作引發(fā)的缺陷，應(yīng)在此至少驗(yàn)證兩次，來確定此缺陷的形成，避免缺陷的偶然性，影響開發(fā)定位問題，影響測試文檔的輸出。6.軟件測試以需求為依據(jù)每個(gè)軟件系統(tǒng)，即使復(fù)用率很高，但是根據(jù)不同品牌有不同的品牌背景需求，所以，即使是復(fù)用率很高的系統(tǒng)，也不能使用完全相同的測試方案來進(jìn)行測試。應(yīng)根據(jù)相關(guān)需求，定制個(gè)性化的測試方法，可復(fù)用大體流程的測試用例，不符合需求規(guī)定的均定義為改系統(tǒng)的缺陷。如在測試過程中發(fā)生理解歧義，所有問題都可以需求文檔為規(guī)定來說明。7.對(duì)測試結(jié)果做全面的檢查在完成缺陷修改后，不排除會(huì)引入新的問題，所以對(duì)于每個(gè)預(yù)期結(jié)果明確定義的同時(shí)，測試完成后還需對(duì)每個(gè)測試結(jié)果進(jìn)行全面的檢查與分析，盡可能多的發(fā)現(xiàn)缺陷。2軟件測試的分類軟件測試方法從不同角度思考有不同的種類劃分。在測試過程中，使用不同的測試方法可以更加快速且準(zhǔn)確的找出缺陷。2.1白盒測試以關(guān)注軟件內(nèi)部結(jié)構(gòu)和程序邏輯的測試方法稱為白盒測試。白盒測試好比一個(gè)打開的盒子，測試關(guān)注的是盒子內(nèi)部結(jié)構(gòu)的設(shè)計(jì)與構(gòu)成。著重檢查代碼的邏輯是否符合設(shè)計(jì)規(guī)格說明書，依據(jù)程序的結(jié)構(gòu)設(shè)計(jì)測試用例，對(duì)程序的邏輯進(jìn)行驗(yàn)證，相關(guān)的模塊和鏈路是否正常且有效。單元測試與集成測試通常運(yùn)用白盒測試做為測試方法，白盒測試的主要測試方法是邏輯覆蓋法。2.2黑盒測試黑盒測試又稱為功能測試。與白盒測試方法不同，黑盒測試相當(dāng)于把軟件程序當(dāng)做一個(gè)關(guān)閉狀態(tài)的盒子，測試人員不關(guān)注程序內(nèi)部結(jié)構(gòu)如何實(shí)現(xiàn)，僅關(guān)注軟件呈現(xiàn)的功能是否能正常運(yùn)行。根據(jù)需求文檔設(shè)計(jì)測試用例，并檢查程序的運(yùn)行是否與需求說明文檔中的預(yù)期實(shí)現(xiàn)功能一致，黑盒測試主要是對(duì)軟件的界面和軟件功能進(jìn)行測試，從而驗(yàn)證系統(tǒng)功能是否正確。2.2.1等價(jià)類劃分法因不可能進(jìn)行窮舉測試，所以可以將軟件程序中有可能會(huì)出現(xiàn)輸入的數(shù)據(jù)劃分成若干個(gè)等價(jià)類。等價(jià)類，顧名思義，從該類中選取具有代表性的數(shù)據(jù)作為一組測試數(shù)據(jù)進(jìn)行驗(yàn)證。用該類方法，可以將等價(jià)類劃分為有效等價(jià)類和無效等價(jià)類，有效等價(jià)類是指對(duì)于軟件程序來說，該類數(shù)據(jù)是合理的、能夠?qū)崿F(xiàn)正常功能的有意義的輸入數(shù)據(jù)集合，可以用來驗(yàn)證程序是否實(shí)現(xiàn)了正常流程的功能。無效等價(jià)類和有效等價(jià)類概念相反，無效等價(jià)類是指對(duì)于軟件需求說明而言，是不合理的輸入數(shù)據(jù)集合，使用無效等價(jià)類的方法設(shè)計(jì)測試用例，可以找出程序中的非正常流程情況，程序中是否對(duì)其做了相關(guān)判斷限制。也相應(yīng)的說明該功能的實(shí)現(xiàn)是否有與需求說明中要求不一致的功能點(diǎn)。兩種不同類型的數(shù)據(jù)代表組成相關(guān)的測試用例，從而使得測試用例具有代表性和完整性。2.2.2邊界值分析法 邊界值分析法是對(duì)等價(jià)類劃分法的一個(gè)詳細(xì)的補(bǔ)充，對(duì)需求說明文檔中要求功能的輸入或輸出的邊界值進(jìn)行測試的一種黑盒測試方法。使用邊界值分析法編寫測試用例中，根據(jù)需求說明文檔定義邊界值的情況，假設(shè)定義輸入的數(shù)值為N位字符，需選取：①正好為N位字符輸入，查看其輸出結(jié)果；②剛剛大于N位字符輸入：N+1，查看其輸出結(jié)果；③剛剛小于N位個(gè)字符的輸入：N-1，查看其輸出結(jié)果。邊界值分析法雖然屬于等價(jià)類劃分法的一種，但不完全等同。使用邊界值分析法，應(yīng)在等價(jià)類劃分好的基礎(chǔ)上，再將這個(gè)等價(jià)類的每個(gè)邊界值作為測試數(shù)據(jù)進(jìn)行編寫測試用例。2.2.3因果圖推斷法 因果圖推斷法，又稱因果圖分析法。根據(jù)需求說明文檔，分析定義該功能的因（輸入條件）與果（輸出條件），從而描繪出因果圖，進(jìn)而轉(zhuǎn)化為判斷表。因果圖法適用于多種輸入條件組合的功能，對(duì)需求加以分析，依據(jù)需求定義的輸入條件進(jìn)行劃分與組合，從而分析出相關(guān)的輸出結(jié)果，從而定制出高效的測試用例。同時(shí)，在使用因果圖推斷法的過程中，也能分析出程序規(guī)范是否存在缺陷。2.2.3錯(cuò)誤推斷法 在測試過程中，既需要驗(yàn)證功能的正常流程正確；也需驗(yàn)證在進(jìn)行非正常輸入流程的情況下，程序也做了相關(guān)的判斷限制，也是從側(cè)面驗(yàn)證該功能是否符合需求。在軟件測試過程中，測試人員依靠豐富的測試經(jīng)驗(yàn)與測試敏銳度，推測系統(tǒng)中可能存在的錯(cuò)誤即為錯(cuò)誤推斷法。利用錯(cuò)誤推斷法列出程序中所有可能出現(xiàn)的錯(cuò)誤，從而設(shè)計(jì)測試用例。如：提交字段為姓名、年齡、性別的表單，三個(gè)字段均為必填項(xiàng)，僅三個(gè)字段填寫正確且完整方可提交成功。我們可以運(yùn)用錯(cuò)誤推測法，設(shè)計(jì)測試用例：三個(gè)字段均不填，提交該表單，是否可以提交成功；如提交不成功，符合需求，測試通過；如提交成功，功能與需求不符合，即為缺陷。測試過程中，隨著測試人員在對(duì)產(chǎn)品的了解不斷的加深，豐富測試經(jīng)驗(yàn)，使用錯(cuò)誤推斷法設(shè)計(jì)的測試用例往往會(huì)更加的高效。2.3灰盒測試灰盒測試是介于白盒和黑盒測試之間的一種測試，不僅僅需要關(guān)注功能上輸入、輸出的正確性，還需關(guān)注程序內(nèi)部的邏輯情況，但不需要像白盒測試一樣那么詳細(xì)的了解程序內(nèi)部邏輯，灰盒測試結(jié)合了黑盒測試和白盒測試的思想核心和測試方法，它注重了程序內(nèi)部邏輯和用戶端操作性。2.4回歸測試在軟件生命周期中，只要軟件的任意部分發(fā)生了變化，就可能為軟件帶來新的問題。軟件的改變帶來的新問題可能是發(fā)現(xiàn)了缺陷并作以修改，也有可能是在功能完成或軟件維護(hù)階段有新的需求的加入或原有需求功能的變更?；貧w測試是為了在新的修改代碼被寫入后，重新測試以確定新的代碼有沒有引入新的錯(cuò)誤或?qū)е缕渌糠值墓δ墚a(chǎn)生錯(cuò)誤。軟件有所變化，也需相應(yīng)更新測試用例。在版本迭代的過程中，使用回歸測試會(huì)逐漸的頻繁，應(yīng)選擇正確的回歸測試策略來提高其有效性和效率。每當(dāng)軟件發(fā)生變化時(shí)，進(jìn)行回歸測試，需再重新測試全部的用例，優(yōu)先測試主流程、著重測試新的修改的部分。以便確認(rèn)新的修改沒有引入新的錯(cuò)誤，同時(shí)也驗(yàn)證修改后的代碼是否達(dá)到了預(yù)期的目的。2.5驗(yàn)收測試驗(yàn)收測試是在軟件投入使用之前最后一個(gè)測試任務(wù)。也稱為交付測試。驗(yàn)收測試的目的是再次驗(yàn)證確保軟件的功能與相關(guān)特性符合用戶使用要求。其面向?qū)ο笫怯脩簦層脩魜磉M(jìn)行測試，確認(rèn)軟件完成既定功能和業(yè)務(wù)要求。3軟件測試相關(guān)工具介紹3.1SQLServer數(shù)據(jù)庫本文介紹的是MicrosoftSQLServer2008，測試過程中將會(huì)使用到該數(shù)據(jù)庫及其可視化工具對(duì)相關(guān)數(shù)據(jù)進(jìn)行查看、編輯等操作。SQLServer是Microsoft公司推出的一個(gè)關(guān)系型數(shù)據(jù)庫管理系統(tǒng)。為企業(yè)提供了工具化的數(shù)據(jù)管理。企業(yè)可以管理更高性能且安全的數(shù)據(jù)，MicrosoftSQLServer數(shù)據(jù)庫提供更安全可靠的關(guān)系型數(shù)據(jù)和結(jié)構(gòu)化數(shù)據(jù)的存儲(chǔ)功能。MicrosoftSQLServer2008有三大特點(diǎn)是：1.可信任的：使得數(shù)據(jù)有更高的安全性、可靠性和擴(kuò)展性，MicrosoftSQLServer2008會(huì)對(duì)整個(gè)數(shù)據(jù)庫的數(shù)據(jù)進(jìn)行相關(guān)的加密，有相關(guān)權(quán)限的用戶才可訪問并查看數(shù)據(jù)。2.高效的：管理者可以降低對(duì)數(shù)據(jù)庫的開發(fā)、管理成本，更高效的對(duì)數(shù)據(jù)做管理。3.智能的：SQLServer2008有更強(qiáng)大的審計(jì)功能，CDC（捕捉變更數(shù)據(jù)）技術(shù)的運(yùn)用，它能自動(dòng)捕捉和記錄用戶在數(shù)據(jù)庫進(jìn)行的增刪查改動(dòng)作。通過使用CDC功能，我們可以知道用戶對(duì)數(shù)據(jù)庫做了何種的操作，還可以利用其功能還原因誤操作或程序錯(cuò)誤導(dǎo)致的丟失數(shù)據(jù)。為追蹤數(shù)據(jù)提供了依據(jù)。3.2SQLServer2008可視化工具SQLServer是數(shù)據(jù)庫管理工具，使用SQLServer2008R2ManagementStudio可視化管理工具，輸入服務(wù)器名稱、登錄名、密碼連接數(shù)據(jù)庫，對(duì)數(shù)據(jù)庫里的數(shù)據(jù)進(jìn)行相關(guān)操作。如圖3-2所示。圖3-2SQLServer2008R2ManagementStudio連接界面3.3接口測試工具：Postman3.3.1接口測試接口測試是用于測試不同軟件系統(tǒng)組件相互調(diào)用的一種測試。接口測試主要用于測試內(nèi)部系統(tǒng)與外部系統(tǒng)之間的接口交互點(diǎn)。接口測試的重點(diǎn)是檢查系統(tǒng)之間數(shù)據(jù)的傳遞、交換、返回?cái)?shù)據(jù)是否正確，以及各個(gè)系統(tǒng)直接的依賴關(guān)系。同時(shí)，還需關(guān)注通接口請(qǐng)求的異常情況處理的合理性。如：微信平臺(tái)對(duì)用戶提供對(duì)外統(tǒng)一接口文檔，項(xiàng)目人員通過接口文檔提供的信息設(shè)計(jì)基于微信平臺(tái)的需求功能，開發(fā)人員根據(jù)接口文檔中提供的參數(shù)調(diào)用完成基于微信平臺(tái)的公眾號(hào)或小程序開發(fā)，測試人員根據(jù)接口文檔設(shè)計(jì)接口測試用例，測試接口是否通暢等。通過接口，大大的提高了軟件產(chǎn)品的擴(kuò)展性。3.3.2postman的介紹與使用Postman最早是作為chrome的插件使用的，因強(qiáng)大的功能，后推出了客戶端版本，更方便使用。Postman本就是為了接口測試而設(shè)計(jì)的一款調(diào)試網(wǎng)絡(luò)程序工具，能夠模擬各種網(wǎng)絡(luò)請(qǐng)求，如：GET、POST、header、PUT等，能夠高效的幫助開發(fā)、測試人員進(jìn)行接口測試。在接口測試中，使用的最多的是GET請(qǐng)求和POST請(qǐng)求。1.GET請(qǐng)求一般用于請(qǐng)求獲取服務(wù)端的數(shù)據(jù)，在Apiurl后使用‘?’拼接需要請(qǐng)求的參數(shù)值，點(diǎn)擊發(fā)送按鈕，會(huì)返回相關(guān)的數(shù)據(jù)，顯示在Response的Body中。請(qǐng)求與返回?cái)?shù)據(jù)的速度很快，但數(shù)據(jù)安全性較低，請(qǐng)求的參數(shù)都顯示在了地址欄中。如圖所示GET請(qǐng)求的使用方法。（因數(shù)據(jù)保密性，故隱藏相關(guān)信息）圖GET請(qǐng)求示例2.POST請(qǐng)求一般用于向指定的資源提交表單。POST請(qǐng)求比GET請(qǐng)求安全性更高，POST請(qǐng)求不會(huì)被緩存，請(qǐng)求的數(shù)據(jù)不會(huì)直接暴露在URL中，它一般是在請(qǐng)求體的body中以鍵值對(duì)（“key”:”value”）的形式請(qǐng)求提交，點(diǎn)擊發(fā)送，response中會(huì)返回相關(guān)數(shù)據(jù)提交的結(jié)果。如圖所示POST請(qǐng)求的使用方法。（因數(shù)據(jù)保密性，故隱藏相關(guān)信息）圖POST請(qǐng)求示例4微信平臺(tái)會(huì)員中心小程序需求分析4.1系統(tǒng)目標(biāo)隨著微信逐漸融入人們的生活，智能手機(jī)的普及率已經(jīng)達(dá)到一個(gè)較高的水平，手機(jī)已經(jīng)成為人們生活中必不可少的一部分。對(duì)于手機(jī)用戶而言，品牌方向用戶推廣大部分都需用戶下載相關(guān)品牌APP，而APP在用戶手機(jī)上留存率、使用率較低，一般使用一次過后會(huì)為了釋放手機(jī)內(nèi)存或使用頻率較少而卸載APP，商家因此會(huì)損失大量的客戶，也無法實(shí)現(xiàn)客戶轉(zhuǎn)換率。這一情況下，微信平臺(tái)的誕生及普遍能夠很好的解決。在手機(jī)用戶中，幾乎每個(gè)用戶都有微信，社交網(wǎng)絡(luò)營銷成為品牌企業(yè)關(guān)注的重點(diǎn)部分。基于微信用戶量粘性高這一點(diǎn)，給品牌企業(yè)帶來無限機(jī)遇。品牌方在微信公眾號(hào)中內(nèi)嵌一個(gè)小程序，即開即用、免安裝、不占手機(jī)內(nèi)存、用完即走，再次使用只需通過‘搜一搜’功能即可再次打開使用，用戶體驗(yàn)性極好，小程序的功能也能基本實(shí)現(xiàn)客戶端的業(yè)務(wù)功能。為品牌方設(shè)立一個(gè)基于微信平臺(tái)的會(huì)員中心小程序，品牌方對(duì)粉絲及注冊(cè)的會(huì)員做相應(yīng)的個(gè)性化分析及推送，提高粉絲轉(zhuǎn)換率、忠實(shí)會(huì)員轉(zhuǎn)化率等，對(duì)用戶來說，可及時(shí)查看到品牌方的相關(guān)活動(dòng)及相關(guān)會(huì)員權(quán)益。因該程序面向適用對(duì)象是不同年齡階段的人群，不同階段的人對(duì)手機(jī)操作使用程度不一，設(shè)計(jì)會(huì)員中心小程序的目標(biāo)是應(yīng)遵循功能簡單且實(shí)用、安全性高、操作界面簡潔明了、用戶體驗(yàn)感好等原則。4.2需求分析需求分析階段是系統(tǒng)開發(fā)的基礎(chǔ)，在軟件開發(fā)生命周期中的任何活動(dòng)都是以需求為基礎(chǔ)，需求定義了該系統(tǒng)需要為品牌、用戶實(shí)現(xiàn)什么、如何呈現(xiàn)。需求分析從用戶提出的“要求”或“需要”出發(fā)，挖掘用戶真正實(shí)用的需求，以詳細(xì)的描述與清晰的且規(guī)范的文檔，轉(zhuǎn)換為產(chǎn)品需求的過程。在此過程中還需考慮到設(shè)計(jì)程序的約束條件，本文測試的程序是微信平臺(tái)中的小程序，小程序有平臺(tái)特點(diǎn)、可開放的接口文檔等，一切的需求都需基于微信平臺(tái)的約束而考慮設(shè)計(jì)。4.2.1功能性需求分析通過品牌方的業(yè)務(wù)背景，進(jìn)行調(diào)查和分析后，設(shè)計(jì)會(huì)員中心小程序系統(tǒng)的需求如下：1.線上用戶可通過微信‘搜一搜’搜索到該小程序；線下到店用戶也可通過掃描門店二維碼進(jìn)入小程序，并進(jìn)行注冊(cè)，成為品牌方的會(huì)員，獲得相關(guān)會(huì)員權(quán)益等。2.個(gè)人信息：注冊(cè)成為會(huì)員后，以手機(jī)號(hào)為唯一身份標(biāo)識(shí)，可查看相關(guān)個(gè)人信息3.積分兌禮：會(huì)員可在線下消費(fèi)，消費(fèi)金額根據(jù)1:1比例轉(zhuǎn)換為積分，通過累積積分，可在積分商城中使用積分兌換滿足現(xiàn)有積分充足的物品，若與兌換物品要求的積分不足，則不可兌換。4.我的禮遇：記錄與該會(huì)員相關(guān)已擁有的權(quán)益、獲取的禮品、禮品的狀態(tài)等，同時(shí)預(yù)約活動(dòng)的相關(guān)記錄也記錄在其中5.品牌活動(dòng)：展示品牌方所開展的活動(dòng)等，告知會(huì)員有興趣即可參加。4.2.2質(zhì)量與性能需求分析為了保障系統(tǒng)長期穩(wěn)定且安全的運(yùn)行，故對(duì)系統(tǒng)有以下性能與質(zhì)量方面的要求：1.系統(tǒng)的可靠性系統(tǒng)的設(shè)計(jì)需具有較高的可靠性，在系統(tǒng)發(fā)生故障情況下，需要確保用戶在使用基本流程上沒有較大的問題，且入數(shù)的準(zhǔn)確性和完整性，并有一套完整的系統(tǒng)解決方案2.系統(tǒng)的易用性流程簡單方便，界面友好。3.系統(tǒng)響應(yīng)的及時(shí)性系統(tǒng)響應(yīng)用戶的操作需有有及時(shí)性，基本流程操作應(yīng)在3秒內(nèi)系統(tǒng)給出相應(yīng)的處理結(jié)果。4.系統(tǒng)的可擴(kuò)展性在系統(tǒng)設(shè)計(jì)中需考慮到今后需求的增加，與第三方技術(shù)對(duì)接的需要，需具有可拓展的可能。5.系統(tǒng)的兼容性兼容市面上流行的手機(jī)，如iPhone、華為、oppo等，確保頁面顯示無誤，且可操作無兼容性問題。6.系統(tǒng)的安全性從系統(tǒng)錄入的數(shù)據(jù)應(yīng)具有保密性，且應(yīng)設(shè)立相關(guān)防止攻擊的策略，確保系統(tǒng)穩(wěn)定且安全的運(yùn)行。7.系統(tǒng)的約束基于微信平臺(tái)設(shè)計(jì)的會(huì)員中心小程序，數(shù)據(jù)庫要求使用SQLServer2008。開發(fā)語言為.NET8.系統(tǒng)的驗(yàn)收標(biāo)準(zhǔn)需求達(dá)標(biāo)率應(yīng)為100%。4.2.2數(shù)據(jù)需求用戶的數(shù)據(jù)錄入及更新體現(xiàn)在會(huì)員注冊(cè)、信息修改、參與會(huì)員活動(dòng)等操作上，因此需要要求在數(shù)據(jù)表結(jié)構(gòu)上有一定的關(guān)聯(lián)關(guān)系，通過需求分析，總結(jié)以下主要數(shù)據(jù)：1.會(huì)員信息數(shù)據(jù)：姓名、性別、手機(jī)號(hào)（唯一標(biāo)識(shí)，不可修改）、地址、生日。2.積分及等級(jí)相關(guān)數(shù)據(jù)：積分記錄、積分消耗記錄。3.兌換記錄：兌換物品、兌換狀態(tài)。5項(xiàng)目軟件測試過程5.1測試計(jì)劃制定軟件測試計(jì)劃，是進(jìn)行軟件測試的第一步。測試計(jì)劃設(shè)定與測試是否能順利執(zhí)行有重要的關(guān)系。首先，需確保功能的實(shí)現(xiàn)與需求一致，需利用黑盒測試的測試方法進(jìn)行功能測試。微信能在各個(gè)手機(jī)上有穩(wěn)定安全的運(yùn)行，并不代表內(nèi)嵌在微信平臺(tái)新開發(fā)的會(huì)員中心小程序也能完美的運(yùn)行。因此，對(duì)手機(jī)的兼容性測試也需要考慮到。該小程序面向?qū)ο笫菑V大群眾，使用小程序過程中，會(huì)存在訪問量的并發(fā)，因此對(duì)并發(fā)操作下服務(wù)器的承載量與相應(yīng)速度也需進(jìn)行性能測試。本文主要介紹對(duì)該小程序進(jìn)行功能測試、簡單兼容性測試。5.2測試內(nèi)容分析及測試用例的編寫5.2.1會(huì)員注冊(cè)如圖所示，是會(huì)員注冊(cè)頁頁面原型，根據(jù)需求可推測出會(huì)員注冊(cè)的流程邏輯，如圖所示。用戶通過搜索小程序或掃門店二維碼進(jìn)入，分已注冊(cè)和未注冊(cè)兩種身份人群，未注冊(cè)的用戶進(jìn)入小程序，進(jìn)入注冊(cè)頁面，注冊(cè)完成之后進(jìn)入會(huì)員中心首頁；已注冊(cè)用戶點(diǎn)擊小程序進(jìn)入，直接到會(huì)員中心首頁。因可根據(jù)這個(gè)思路設(shè)計(jì)會(huì)員注冊(cè)部分的測試用例，如表所示會(huì)員注冊(cè)部分測試用例。圖會(huì)員注冊(cè)頁頁面展現(xiàn)（原型）圖會(huì)員注冊(cè)流程圖測試模塊用例編號(hào)操作步驟預(yù)期結(jié)果實(shí)際結(jié)果會(huì)員注冊(cè)1未注冊(cè)用戶，進(jìn)入小程序進(jìn)入會(huì)員注冊(cè)頁2注冊(cè)頁，不填寫必填項(xiàng)（姓名、手機(jī)號(hào)、性別、生日、地址），點(diǎn)擊【提交】按鈕提示：請(qǐng)完整填寫信息3注冊(cè)頁，輸入不符合規(guī)范的手機(jī)號(hào)，如：123，點(diǎn)擊【提交】提示：手機(jī)號(hào)輸入不正確，請(qǐng)重新填寫4點(diǎn)擊【立即授權(quán)手機(jī)號(hào)】跳轉(zhuǎn)至授權(quán)頁面5在手機(jī)號(hào)授權(quán)頁，點(diǎn)擊【允許】手機(jī)號(hào)自動(dòng)填寫，無需再填寫驗(yàn)證碼（驗(yàn)證碼一欄消失）6在手機(jī)號(hào)授權(quán)頁，點(diǎn)擊【拒絕】需手動(dòng)輸入手機(jī)號(hào)及驗(yàn)證碼7輸入不正確的手機(jī)號(hào)：13234a提示：請(qǐng)輸入正確的手機(jī)號(hào)碼8不輸入手機(jī)號(hào)，點(diǎn)擊【獲取驗(yàn)證碼】提示：請(qǐng)輸入正確的手機(jī)號(hào)碼9輸入手機(jī)號(hào)，點(diǎn)擊驗(yàn)證碼手機(jī)端收取到驗(yàn)證碼10輸入錯(cuò)誤的驗(yàn)證碼提示：驗(yàn)證碼不正確，請(qǐng)核對(duì)后重新輸入11未勾選隱私條款，點(diǎn)擊【提交】提示：請(qǐng)先閱讀隱私條款并勾選12選擇生日，點(diǎn)擊【提交】不可選擇小于當(dāng)天的日期13輸入正確的相關(guān)信息，點(diǎn)擊【提交】1.進(jìn)入會(huì)員中心

2.同時(shí)查看數(shù)據(jù)庫中的用戶表新增一條數(shù)據(jù)，數(shù)據(jù)與操作時(shí)注冊(cè)的數(shù)據(jù)相同14已注冊(cè)用戶，進(jìn)入小程序直接進(jìn)入會(huì)員中心表會(huì)員注冊(cè)測試用例5.2.1積分兌禮根據(jù)積分商城的需求可畫出積分商城的流程邏輯，如圖5.2.1所示，用戶在積分商城進(jìn)行積分兌換，如用戶積分充足且禮品庫存充足，即可兌換成功，同時(shí)數(shù)據(jù)庫查看是否減去了所兌換數(shù)量的禮品庫存，我的禮遇模塊相應(yīng)新增一條兌換記錄，可至線下門店掃碼領(lǐng)??；如用戶積分不足，即提示兌換失?。蝗缬脩舴e分充足但禮品庫存不足，即提示兌換失敗。按照此邏輯思路可設(shè)計(jì)出積分兌禮模塊的測試用例，如表所示。圖5.2.1積分兌禮流程圖測試模塊用例編號(hào)操作步驟預(yù)期結(jié)果實(shí)際結(jié)果積分兌禮15用戶積分充足且禮品庫存充足兌換成功，兌換禮品庫存相應(yīng)扣除

2.我的禮遇模塊同時(shí)記錄相關(guān)兌換數(shù)據(jù)，狀態(tài)為：已兌換未領(lǐng)取3.積分相應(yīng)更新16用戶積分充足且禮品庫存不足提示兌換失敗17用戶積分不足提示兌換失敗18在我的禮遇中，點(diǎn)擊相關(guān)兌禮記錄，進(jìn)入詳情頁面，點(diǎn)擊【立即領(lǐng)取】調(diào)用手機(jī)攝像頭，掃描品牌門店二維碼隨后領(lǐng)取成功19掃非品牌門店二維碼領(lǐng)取提示：領(lǐng)取失敗表積分兌禮測試用例5.2.3品牌活動(dòng)品牌活動(dòng)模塊主要是展示品牌方的相關(guān)活動(dòng)，主要是靜態(tài)頁面，展示活動(dòng)內(nèi)容，吸引用戶線下參與。故此部分僅做兼容性測試，測試過程中，分別查看iPhonex、華為p30、OPPOfind等市面上較普遍的手機(jī)，需均能完整且無誤的顯示。5.2.4測試用例評(píng)審測試用例評(píng)審是進(jìn)行測試前一個(gè)重要的部分，由測試人員編寫完成測試用例，測試用例評(píng)審是一個(gè)必要的階段，它集齊了項(xiàng)目各個(gè)身份的人的思想，統(tǒng)一正確需求認(rèn)知，集思廣益，提高測試覆蓋率。本文所編寫的測試用例是經(jīng)已評(píng)審并修改后的最終版。6測試報(bào)告經(jīng)過前期充分的準(zhǔn)備，按照測試計(jì)劃，執(zhí)行測試用例，提出系統(tǒng)中的缺陷至開發(fā)人員，跟蹤缺陷，直至缺陷修復(fù)完成且無誤。按時(shí)完成測試任務(wù)，用例執(zhí)行率100%，測試通過率100%，符合項(xiàng)目上線要求。7驗(yàn)收測試及上線經(jīng)測試，需求功能實(shí)現(xiàn)率為100%，測試為覆蓋率100%，符合項(xiàng)目上線要求。提至公司團(tuán)隊(duì)中不了解該系統(tǒng)的人員當(dāng)做用戶來進(jìn)行驗(yàn)收測試，在驗(yàn)收測試過程中，用戶提出了一些建議性的優(yōu)化，經(jīng)項(xiàng)目團(tuán)隊(duì)評(píng)估后修改完成，部署正式環(huán)境，如期上線。上線后項(xiàng)目團(tuán)隊(duì)及時(shí)跟進(jìn)相應(yīng)的系統(tǒng)維護(hù)。8測試用例的復(fù)用性及意義隨著互聯(lián)網(wǎng)的高速發(fā)展，微信的普及，品牌方可借助社交媒體的各方面優(yōu)點(diǎn)及微信平臺(tái)的社交策略，設(shè)立基于微信平臺(tái)的會(huì)員中心系統(tǒng)，充分發(fā)揮微信公眾號(hào)及小程序的運(yùn)營優(yōu)勢，實(shí)現(xiàn)品牌與用戶實(shí)時(shí)互動(dòng)，增加信息的及時(shí)性與準(zhǔn)確性，對(duì)用戶展開精準(zhǔn)營銷，提高用戶對(duì)品牌的好感度，同時(shí)也為品牌方帶來更好的口碑，促進(jìn)銷量?，F(xiàn)在越來越多的品牌方都考慮在微信平臺(tái)上設(shè)立會(huì)員中心系統(tǒng)，據(jù)了解，品牌在營銷方面上的大方向是不變的，所以基于微信平臺(tái)的會(huì)員中心小程序的系統(tǒng)的開發(fā)與測試巨有很大的復(fù)用性。在測試過程中，測試用例是基礎(chǔ)，分析不同品牌方的背景需求，提取可共用的測試用例部分，加快測試進(jìn)度，提高效率，保障產(chǎn)品質(zhì)量。8.1復(fù)用測試用例維度分析建立高效實(shí)用的可復(fù)用測試用例，可從三個(gè)維度分析思考：1.時(shí)間維度：參考以前的類似軟件程序的測試用例作為基礎(chǔ)，可作為用例基礎(chǔ)模板及回歸測試時(shí)的復(fù)用。可為新的類似程序中為其編寫通用部分測試用例以及根據(jù)其需求添加個(gè)性化的測試點(diǎn)。2.通用維度：以相同平臺(tái)為基礎(chǔ)的軟件或類似邏輯性的軟件，其測試用例可以復(fù)用。3.應(yīng)用角度：以某類型的系統(tǒng)構(gòu)建基礎(chǔ)的測試用例，在同一領(lǐng)域不同應(yīng)用系統(tǒng)中的測試過程中可以復(fù)用。8.2可復(fù)用測試用例的建立與意義分析被測軟件的業(yè)務(wù)邏輯、軟件運(yùn)行平臺(tái)、測試需求、測試類型等，提取測試點(diǎn)并一一列出，查看待測項(xiàng)目與測試用例的復(fù)用庫有無相近的測試用例，如有，依據(jù)待測項(xiàng)目的需求，進(jìn)一步將該測試用例具體化，形成完整的測試用例。對(duì)于做一種領(lǐng)域的軟件系統(tǒng)的公司來說，建立測試用例的復(fù)用庫有重大的意義。可以大大縮短軟件測試的周期，提高軟件測試的效率，提高軟件測試質(zhì)量的可靠性，從而確保產(chǎn)品質(zhì)量。9總結(jié)本文結(jié)合了當(dāng)代互聯(lián)網(wǎng)背景與微信平臺(tái)的營銷模式下設(shè)計(jì)了會(huì)員中心小程序測試用例與測試方法。分析品牌的背景與需求，結(jié)合軟件測試的目的和原則，運(yùn)用軟件測試的各種測試方法，設(shè)計(jì)測試方案。高效的編寫了與需求相符的測試用例，項(xiàng)目組成員評(píng)估后完善測試用例，準(zhǔn)確高效的對(duì)系統(tǒng)進(jìn)行測試，提出缺陷，并跟蹤缺陷直至缺陷關(guān)閉。測試完成后，對(duì)測試工作進(jìn)行總結(jié)與評(píng)估，協(xié)助用戶進(jìn)行驗(yàn)收測試，項(xiàng)目順利上線。對(duì)測試用例的復(fù)用性淺談了自己些許理解，從對(duì)產(chǎn)品投入的時(shí)間成本和產(chǎn)品質(zhì)量角度來說，建立測試用例復(fù)用庫，且運(yùn)用在項(xiàng)目中有不可小覷的重要作用。致謝在我的論文編寫完成之際，首先我由衷的感謝我的論文指導(dǎo)老師李愛民老師，從對(duì)我的論文選題、主體思路、論文設(shè)計(jì)及內(nèi)容等各方面予以悉心的指導(dǎo)與幫助。在這一過程中，讓我感受到了李愛民老師的博學(xué)多識(shí)、嚴(yán)謹(jǐn)?shù)闹螌W(xué)風(fēng)范和誨人不倦的師長風(fēng)格讓我受益匪淺，李老師永遠(yuǎn)是我學(xué)習(xí)榜樣，老師的精神將一直激勵(lì)我在工作崗位上與學(xué)習(xí)方面不斷進(jìn)取。然后，感謝工作中的同事對(duì)我的幫助，在編寫論文過程中，與同事的不斷交流，更深層次的理解到了知識(shí)運(yùn)用到實(shí)踐中的真諦，順利的完成了論文的編寫。此外，我要感謝我所引用和轉(zhuǎn)載的文獻(xiàn)的學(xué)者，給予我啟發(fā)和引導(dǎo)，讓我更加深入的領(lǐng)悟到軟件測試的真諦與魅力。最后，感謝西安交通大學(xué)給予我學(xué)習(xí)提升與深造的機(jī)會(huì)，同時(shí)，向各位評(píng)審老師為評(píng)閱本文付出的辛勤勞動(dòng)表示由衷的感謝！參考文獻(xiàn)軟件測試技術(shù)的研究進(jìn)展[J].劉繼華,陳策.

微計(jì)算機(jī)信息.

2012(10)侯興云.基于微信的企業(yè)營銷模式創(chuàng)新研究[D].暨南大學(xué),2015.三元.成功軟件測試管理的九大原則.測試員[EB/OL].2004.3.33.郁蓮.軟件測試方法與實(shí)踐[M].清華大學(xué)出版.2008Aken.有關(guān)黑盒測試、白盒測試和灰盒測試的基本概念.