軟件測(cè)試基本流程與要求

軟件測(cè)試基本流程與要求（綱要）目標(biāo)擬訂完好且詳細(xì)的測(cè)試路線和流程，為迅速、高效和高質(zhì)量的軟件測(cè)試供給基礎(chǔ)流程框架。最后目標(biāo)是實(shí)現(xiàn)軟件測(cè)試規(guī)范化，標(biāo)準(zhǔn)化。測(cè)試流程說明需求剖析否評(píng)審、交流是編寫測(cè)試計(jì)劃否評(píng)審、完美是提取測(cè)試需求設(shè)計(jì)測(cè)試用例否評(píng)審、完美是搭建測(cè)試環(huán)境冒煙測(cè)試履行測(cè)試用例完美測(cè)試用例Bug追蹤辦理測(cè)試報(bào)告輸出測(cè)試需求剖析測(cè)試需求是整個(gè)測(cè)試過程的基礎(chǔ)；確立測(cè)試對(duì)象以及測(cè)試工作的范圍和作用。用來確立整個(gè)測(cè)試工作（如安排時(shí)間表、測(cè)試設(shè)計(jì)等）并作為測(cè)試覆蓋的基礎(chǔ)。并且被確立的測(cè)試需求項(xiàng)一定是可核實(shí)的。即，它們一定有一個(gè)可察看、可評(píng)測(cè)的結(jié)果。沒法核實(shí)的需求不是測(cè)試需求。所以我此刻的理解是測(cè)試需求是一個(gè)比較大的觀點(diǎn)，它是在整個(gè)測(cè)試計(jì)劃文檔中表現(xiàn)出來的，不是近似的一個(gè)用例或許其余.·測(cè)試需求是制定測(cè)試計(jì)劃的基本依照，確立了測(cè)試需求能夠?yàn)闇y(cè)試計(jì)劃供給客觀依照；·測(cè)試需求是設(shè)計(jì)測(cè)試用例的指導(dǎo)，確立了要測(cè)什么、測(cè)哪些方面后才能有針對(duì)性的設(shè)計(jì)測(cè)試用例；·測(cè)試需求是計(jì)算測(cè)試覆蓋的分母，沒有測(cè)試需求就沒法有效地進(jìn)行測(cè)試覆蓋；3.1測(cè)試方法與規(guī)范測(cè)試方法跟著軟件技術(shù)發(fā)展，項(xiàng)目種類愈來愈多樣化。依據(jù)項(xiàng)目種類應(yīng)采用針對(duì)性強(qiáng)的測(cè)試方法，適合的測(cè)試方法能夠讓我們事半功倍。以下是針對(duì)目前項(xiàng)目工程能夠參照的測(cè)試方法：β測(cè)試（beta測(cè)試）--非程序員、測(cè)試人員測(cè)試，英文是Betatesting。又稱Beta測(cè)試，用戶查收測(cè)試（UAT）。測(cè)試是軟件的多個(gè)用戶在一個(gè)或多個(gè)用戶的實(shí)質(zhì)使用環(huán)境下進(jìn)行的測(cè)試。開發(fā)者往常不在測(cè)試現(xiàn)場(chǎng)，Beta測(cè)試不可以由程序員或測(cè)試員達(dá)成。當(dāng)開發(fā)和測(cè)試根本達(dá)成時(shí)所做的測(cè)試，而最后的錯(cuò)誤和問題需要在最后刊行前找到。這種測(cè)試一般由最后用戶或其余人員達(dá)成，不可以由程序員或測(cè)試員達(dá)成。α測(cè)試（Alpha測(cè)試）--非程序員、測(cè)試人員α測(cè)試，英文是Alphatesting。又稱Alpha測(cè)試.Alpha測(cè)試是由一個(gè)用戶在開發(fā)環(huán)境下進(jìn)行的測(cè)試，也能夠是企業(yè)內(nèi)部的用戶在模擬實(shí)質(zhì)操作環(huán)境下進(jìn)行的受控測(cè)試，Alpha測(cè)試不可以由該系統(tǒng)的程序員或測(cè)試員達(dá)成。在系統(tǒng)開發(fā)靠近達(dá)成時(shí)對(duì)應(yīng)用系統(tǒng)的測(cè)試;測(cè)試后，仍舊會(huì)有少許的設(shè)計(jì)變更。這種測(cè)試一般由最后用戶或其余人員來達(dá)成，不可以由程序員或測(cè)試員達(dá)成。兼容性測(cè)試--測(cè)試人員兼容性測(cè)試是指測(cè)試軟件能否能夠成功移植到指定的硬件或許軟件環(huán)境中，比如在B/S項(xiàng)目中各個(gè)不同閱讀器之間的測(cè)試。?用戶界面測(cè)試-UI測(cè)試--測(cè)試人員用戶界面測(cè)試，英文是Userinterfacetesting。又稱UI測(cè)試。用戶界面，英文是Userinterface。是指軟件中的可見外觀及其基層與用戶交互的部分（菜單、對(duì)話框、窗口和其余控件）。用戶界面測(cè)試是指測(cè)試用戶界面的風(fēng)格能否知足客戶要求，文字能否正確，頁面能否雅觀，文字，圖片組合能否完滿，操作能否友善等等。UI測(cè)試的目標(biāo)是保證用戶界面會(huì)經(jīng)過測(cè)試對(duì)象的功能來為用戶供給相應(yīng)的接見或閱讀功能。確保用戶界面切合企業(yè)或行業(yè)的標(biāo)準(zhǔn)。包含用戶友善性、人性化、易操作性測(cè)試。用戶界面測(cè)試用戶剖析軟件用戶界面的設(shè)計(jì)能否符合用戶希望或要求。它經(jīng)常包含菜單，對(duì)話框及對(duì)話框上所有按鈕，文字，犯錯(cuò)提示，幫助信息(Menu和Helpcontent)等方面的測(cè)試。比方，測(cè)試MicrosoftExcel中插入符號(hào)功能所用的對(duì)話框的大小，所有按鈕能否對(duì)齊，字符串字體大小，犯錯(cuò)信息內(nèi)容和字體大小，工具欄地點(diǎn)/圖標(biāo)等等。冒煙測(cè)試--版本編譯者冒煙測(cè)試，英文是Smoketesting。冒煙測(cè)試的名稱能夠理解為該種測(cè)試耗時(shí)短，僅用一袋煙功夫足夠了。也有人以為是形象地類比新電路板功基本功能檢查。任何新電路板焊好后，先通電檢查，假如存在設(shè)計(jì)缺點(diǎn)，電路板可能會(huì)短路，板子冒煙了。冒煙測(cè)試的對(duì)象是每一個(gè)新編譯的需要正式測(cè)試的軟件版本，目的是確認(rèn)軟件基本功能正常，能夠進(jìn)行后續(xù)的正式測(cè)試工作。冒煙測(cè)試的履行者是版本編譯人員。隨機(jī)測(cè)試--測(cè)試人員隨機(jī)測(cè)試，英文是Adhoctesting。隨機(jī)測(cè)試沒有書面測(cè)試用例、記錄希望結(jié)果、檢查列表、腳本或指令的測(cè)試。主假如依據(jù)測(cè)試者的經(jīng)驗(yàn)對(duì)軟件進(jìn)行功能和性能抽查。隨機(jī)測(cè)試是依據(jù)測(cè)試說明書履行用例測(cè)試的重要增補(bǔ)手段，是保證測(cè)試覆蓋完好性的有效方式和過程。隨機(jī)測(cè)試主假如對(duì)被測(cè)軟件的一些重要功能進(jìn)行復(fù)測(cè)，也包含測(cè)試那些目前的測(cè)試樣例(TestCase)沒有覆蓋到的部分。此外，關(guān)于軟件更新和新增添的功能要要點(diǎn)測(cè)試。要點(diǎn)對(duì)一些特別點(diǎn)狀況點(diǎn)、特別的使用環(huán)境、并發(fā)性、進(jìn)行檢查。特別對(duì)從前測(cè)試發(fā)現(xiàn)的重要Bug，進(jìn)行再次測(cè)試，能夠聯(lián)合回歸測(cè)試(Regressivetesting)一同進(jìn)行。黑盒測(cè)試（功能測(cè)試）--測(cè)試人員黑盒測(cè)試，英文是BlackBoxTesting。又稱功能測(cè)試或許數(shù)據(jù)驅(qū)動(dòng)測(cè)試。黑盒測(cè)試是依據(jù)軟件的規(guī)格對(duì)軟件進(jìn)行的測(cè)試，這種測(cè)試不考慮軟件內(nèi)部的運(yùn)作原理，所以軟件對(duì)用戶來說就像一個(gè)黑盒子。軟件測(cè)試人員以用戶的角度，經(jīng)過各樣輸入和察看軟件的各樣輸出結(jié)果來發(fā)現(xiàn)軟件存在的缺點(diǎn)，而不關(guān)懷程序詳細(xì)怎樣實(shí)現(xiàn)的一種軟件測(cè)試方法。性能測(cè)試性能測(cè)試，英文是PerformanceTesting。性能測(cè)試是在交替進(jìn)行負(fù)荷和逼迫測(cè)試經(jīng)常用的術(shù)語。理想的“性能測(cè)試”(和其余種類的測(cè)試)應(yīng)在需求文檔或質(zhì)量保證、測(cè)試計(jì)劃中定義。性能測(cè)試一般包含負(fù)載測(cè)試和壓力測(cè)試。往?？甲C軟件的性能在正常環(huán)境和系統(tǒng)條件下重復(fù)使用能否還可以知足性能指標(biāo)?；蛟S履行相同任務(wù)時(shí)新版本不比舊版本慢。一般還檢查系統(tǒng)記憶容量在運(yùn)轉(zhuǎn)程序時(shí)會(huì)不會(huì)流失(memoryleak)。比方，考證程序保留一個(gè)巨大的文件新版本不比舊版本慢。測(cè)試規(guī)范測(cè)試規(guī)范是依據(jù)開發(fā)規(guī)范而擬訂的測(cè)試標(biāo)準(zhǔn)，測(cè)試規(guī)范也是后期測(cè)試用例編寫的重要依照。由于開發(fā)規(guī)范因企業(yè)而異，因產(chǎn)品而異，所以測(cè)試規(guī)范的標(biāo)準(zhǔn)程度每個(gè)企業(yè)都不相同。從理論到方法到各種流程到各種報(bào)告模版，都屬于測(cè)試規(guī)范的范圍，當(dāng)一整套規(guī)范形成以后，可使得測(cè)試工作進(jìn)行更為穩(wěn)重，所有問題有據(jù)可查。3.2軟件需求規(guī)格說明書軟件需求規(guī)格說明書是軟件達(dá)到的各項(xiàng)功能的目標(biāo)。是測(cè)試人員各項(xiàng)工作的依照，沒有需求就沒法判斷測(cè)試結(jié)果是正確的。3.3軟件設(shè)計(jì)說明（綱要與詳盡設(shè)計(jì)）設(shè)計(jì)說明書包含軟件的一些框架、字段、數(shù)據(jù)庫設(shè)計(jì)等。軟件設(shè)計(jì)說明對(duì)測(cè)試工作展開有很大影響，沒有軟件設(shè)計(jì)說明好多問題將沒法溯源，測(cè)試準(zhǔn)備的先期工作也是依據(jù)軟件設(shè)計(jì)說明來擬訂的。3.4頁面原型（demo）頁面原型是項(xiàng)目人員迅速熟習(xí)項(xiàng)目的最正確路徑。在需求不夠明確，設(shè)計(jì)說明書不夠全面的狀況下，頁面原型也是后期測(cè)試用例編寫思想的重要依據(jù)。測(cè)試過程設(shè)計(jì)明確測(cè)試目的，最后達(dá)成目的并考證結(jié)果是測(cè)試要做的事情。包含：測(cè)試范圍：描繪本次測(cè)試中的測(cè)試范圍，如：測(cè)試軟件功能范圍、測(cè)試種類等。簡(jiǎn)單的描繪怎樣搭建測(cè)試平臺(tái)以及測(cè)試的潛伏的風(fēng)險(xiǎn)。項(xiàng)目信息：說明要測(cè)試的項(xiàng)目的有關(guān)資料，如：輸入輸出文檔，產(chǎn)品描繪，軟件主要功能。人力資源的分派。測(cè)試需求：抽象說，就是測(cè)試中的所有設(shè)計(jì)和需求文檔。作為本次測(cè)試的依照4.1測(cè)試策略擬訂這一階段在于需求、詳盡設(shè)計(jì)、測(cè)試計(jì)劃達(dá)成以后，主假如本次測(cè)試的策略階段。好多企業(yè)少這個(gè)一個(gè)階段，需要有計(jì)劃性的分出產(chǎn)品的功能扣出測(cè)試的功能點(diǎn)，現(xiàn)階段大多企業(yè)都是直接拿著文檔就開始做用例設(shè)計(jì)。對(duì)需求進(jìn)行剖析，列出詳細(xì)的功能列表。（一般依據(jù)功能交互文檔就能明確出此功能的大概功能，一層層的分下去，向來到?jīng)]個(gè)功能表單。而后考慮到使用那些測(cè)試方法？工作一旦做到履行階段，我們能夠更好的依據(jù)這些功能表一點(diǎn)一點(diǎn)的覆蓋。也能讓我們?cè)谟美u(píng)審時(shí)，充分的證明我們的工作是有效的能夠保證產(chǎn)品的質(zhì)量。）一般在此從前，一些業(yè)務(wù)培訓(xùn)和需求評(píng)審是有必假如聽一下的。這樣能夠更早更熟練的理解需求，也能保證產(chǎn)品設(shè)計(jì)中出現(xiàn)的一些誤區(qū)。關(guān)于一個(gè)個(gè)測(cè)試該怎樣進(jìn)行測(cè)試？以下：功能測(cè)試功能范圍（區(qū)分出各自負(fù)責(zé)的功能模塊）使用測(cè)試方法（等價(jià)類、界限值等測(cè)試方法方法）測(cè)試標(biāo)準(zhǔn)（切合設(shè)計(jì)、需乞降規(guī)范文檔對(duì)該功能的描繪）界面測(cè)試兼容性測(cè)試4.2測(cè)試計(jì)劃1)要充分考慮測(cè)試計(jì)劃的適用性，即測(cè)試計(jì)劃與實(shí)質(zhì)之間的靠近程度和可操作性。編寫測(cè)試計(jì)劃的目的在于充分考慮履行測(cè)試時(shí)的各樣資源，包含測(cè)試內(nèi)容、測(cè)試標(biāo)準(zhǔn)、時(shí)間資源、人力資源等等，正確地說是要剖析履行時(shí)所能夠調(diào)用的全部資源以及受各樣條件限制，可能遇到的各樣影響。測(cè)試內(nèi)容：對(duì)一個(gè)軟件來說測(cè)試計(jì)劃中會(huì)明確本次測(cè)試做哪些測(cè)試？如：系統(tǒng)測(cè)試：在整個(gè)系統(tǒng)測(cè)試中會(huì)有（界面測(cè)試、功能測(cè)試、性能測(cè)試、兼容性測(cè)試、安裝卸載測(cè)試、靠譜性測(cè)試等測(cè)試）。b)測(cè)試目的：一般多為保證產(chǎn)質(zhì)量量能否達(dá)到預(yù)期的指標(biāo)。這個(gè)指標(biāo)也就是在測(cè)試中定義的結(jié)束標(biāo)準(zhǔn)。測(cè)試標(biāo)準(zhǔn)：需要考慮本次測(cè)試需要輸入那些文檔，該項(xiàng)目結(jié)束標(biāo)準(zhǔn)定義、測(cè)試結(jié)束標(biāo)準(zhǔn)的定義？bug級(jí)別定義、優(yōu)先級(jí)定義、bug管理流程定義。這個(gè)都需要在履行測(cè)試事明確。計(jì)劃中應(yīng)當(dāng)包含這些內(nèi)容。資源分派：這里分為人力資源、軟硬件資源等區(qū)分。一般會(huì)把人力資源的利用寫入一個(gè)測(cè)試人員任務(wù)分派表里，依照不同的階段，每個(gè)階段提交相應(yīng)的成就（難度很大）。軟硬件資源中主假如在做計(jì)劃時(shí)考慮到需要多少電腦或其余工具，列出清單。測(cè)試風(fēng)險(xiǎn)：大多考慮到的就是項(xiàng)目開發(fā)緩期、測(cè)試人員不足用例沒法全面覆蓋測(cè)試點(diǎn)、時(shí)間不足用例沒法所有履行、bug沒法實(shí)時(shí)改正致使沒法考證、測(cè)試人員技術(shù)不足致使測(cè)試進(jìn)度拉長(zhǎng)。軟件測(cè)試策略一般都是分開來做有關(guān)測(cè)試方案。。4.3測(cè)試附件用例模板、缺點(diǎn)報(bào)告模板測(cè)試環(huán)境的搭建缺點(diǎn)管理流程和缺點(diǎn)級(jí)別定義缺點(diǎn)狀態(tài)一般分為：新建、翻開、已分派、已修復(fù)、封閉、從頭翻開中間會(huì)有：緩期、重復(fù)、拒絕等狀態(tài)缺點(diǎn)管理流程：1.

測(cè)試人員或開發(fā)人員發(fā)現(xiàn)bug后，判斷輸入哪個(gè)模塊的問題，填寫bug報(bào)告后，系統(tǒng)會(huì)自動(dòng)經(jīng)過Email通知開發(fā)組長(zhǎng)和該模塊開發(fā)者。開發(fā)組長(zhǎng)依據(jù)詳細(xì)狀況，從頭reassigned分派給bug所屬的開發(fā)者。開發(fā)者收到email信息后，判斷能否為自己的改正范圍。若不是，從頭reassigned分派給開發(fā)組長(zhǎng)或應(yīng)當(dāng)分派的開發(fā)者。假如，進(jìn)行辦理，resolved并給出解決方法。（可創(chuàng)立補(bǔ)丁附件及增補(bǔ)說明）測(cè)試人員查問開發(fā)者已改正的bug，進(jìn)行回歸測(cè)試。經(jīng)考證無誤后，改正狀態(tài)為verified。待整個(gè)產(chǎn)品公布后，改正為closed。還有問題，reopened，狀態(tài)從頭變成“new”，并發(fā)送郵件通知。5.

假如這個(gè)bug一周內(nèi)一致沒被辦理過。Bugzilla就會(huì)向來用email騷擾它的屬主，直接采納行動(dòng)。管理員能夠設(shè)定最遲采納行動(dòng)的限期，比方3天，系統(tǒng)默認(rèn)7天。缺點(diǎn)等級(jí)區(qū)分：分級(jí)Bug等級(jí)Bug等級(jí)說明分類說明致使整個(gè)產(chǎn)品沒法進(jìn)行○模塊沒法啟動(dòng)或異樣退出測(cè)試。改正優(yōu)先級(jí)為最Blocker高，該級(jí)別需要程序員○其余致使沒法測(cè)試的錯(cuò)誤致命問題立刻改正死機(jī)，數(shù)據(jù)丟掉，主要○運(yùn)轉(zhuǎn)過程中系統(tǒng)崩潰/死機(jī)/重啟Critical功能完好喪失，系統(tǒng)懸○功能設(shè)計(jì)與需求嚴(yán)重不符掛等錯(cuò)誤。改正優(yōu)先級(jí)○嚴(yán)重花屏為最高，該級(jí)別需要程序員立刻改正主要功能喪失，致使嚴(yán)重的問題，或致命的錯(cuò)嚴(yán)重問題Major誤申明。改正優(yōu)先級(jí)為高，該級(jí)別需要程序員趕快改正次要功能喪失，不太嚴(yán)重，如提示信息不太準(zhǔn)Normal確。改正優(yōu)先級(jí)為中，該級(jí)別需要程序員改正一般問題細(xì)小的問題，對(duì)功能幾乎沒有影響，產(chǎn)品及屬M(fèi)inor性仍可使用。改正優(yōu)先級(jí)為低，該級(jí)別需要程序員改正或不改正提示信息格式不切合要求,違反正常風(fēng)俗習(xí)慣Trivial的，界面不雅觀，控件稍微問題擺列、格式不一致功能性建議，功能使用Enhancement性、方便性、易用性不

○內(nèi)存泄露○影響手機(jī)語音或數(shù)據(jù)通信等○嚴(yán)重的數(shù)值計(jì)算錯(cuò)誤○功能未實(shí)現(xiàn)或許存在錯(cuò)誤○稍微的數(shù)值計(jì)算錯(cuò)誤○系統(tǒng)所供給的功能或服務(wù)受顯然的影響○用戶數(shù)據(jù)丟掉或損壞○操作界面錯(cuò)誤（包含數(shù)據(jù)窗口內(nèi)列名定義、含義能否一致）○界限條件下錯(cuò)誤○功能存在錯(cuò)誤，但出現(xiàn)概率很低○提示信息錯(cuò)誤（包含未給出信息、信息提示錯(cuò)誤等）○長(zhǎng)時(shí)間操作無進(jìn)度提示○系統(tǒng)未優(yōu)化（性能問題）○界面格式等不規(guī)范○操作時(shí)未給用戶提示○文字?jǐn)[列不齊整等一些小問題○光標(biāo)跳轉(zhuǎn)設(shè)置不好，鼠標(biāo)（光標(biāo)）定位錯(cuò)誤○協(xié)助說明描繪不清楚○個(gè)別不影響產(chǎn)品理解的錯(cuò)別字○可輸入地區(qū)和只讀地區(qū)沒有顯然的區(qū)分標(biāo)記○建議夠測(cè)試實(shí)行5.1履行開發(fā)就會(huì)轉(zhuǎn)版本給我們測(cè)試部門進(jìn)行系統(tǒng)測(cè)試了。拿到版本我們第一搭建測(cè)試環(huán)境做一個(gè)展望試，目的是來評(píng)判這個(gè)版本能否是可測(cè)試的。假如展望試不經(jīng)過，打回開發(fā)部返工，假如經(jīng)過了，就開始我們第一輪的系統(tǒng)測(cè)試。第一輪系統(tǒng)測(cè)試我們會(huì)履行我們所編寫的所有測(cè)試用例，做好測(cè)試結(jié)果的記錄，發(fā)現(xiàn)缺點(diǎn)了提交缺點(diǎn)報(bào)告。當(dāng)?shù)谝惠啘y(cè)試結(jié)束后，我們把所有的bug單提交給開發(fā)人員，由他們進(jìn)行改正。在他們修復(fù)bug時(shí)期，我們會(huì)對(duì)第一輪系統(tǒng)測(cè)試做一個(gè)測(cè)試評(píng)估，出一個(gè)測(cè)試報(bào)告。還要依據(jù)實(shí)質(zhì)狀況，對(duì)我們寫的測(cè)試用例進(jìn)行改正和增添。開發(fā)改bug結(jié)束，提交一個(gè)新的版本給我們，我們從頭搭建測(cè)試環(huán)境開始第二輪系統(tǒng)測(cè)試。第一是回歸我們提交的缺點(diǎn)報(bào)告，而后會(huì)在用例中精選一些優(yōu)先級(jí)別比較高的用例來進(jìn)行測(cè)試，發(fā)現(xiàn)問題了持續(xù)提交缺點(diǎn)報(bào)告，只到缺點(diǎn)率低于用戶要求了，我們就進(jìn)行最后一輪的回歸測(cè)試，結(jié)束系統(tǒng)測(cè)試。詳細(xì)測(cè)試輪次是依據(jù)版實(shí)質(zhì)量和項(xiàng)目復(fù)雜度而決定的。測(cè)試評(píng)估?履行階段結(jié)束了進(jìn)入測(cè)試評(píng)估階段，我們會(huì)出一個(gè)總的測(cè)試報(bào)告對(duì)我們測(cè)試的這個(gè)過程和版本的質(zhì)量做一個(gè)詳盡的評(píng)估需求需要評(píng)審那些？用例需要評(píng)審那些？計(jì)劃應(yīng)當(dāng)評(píng)審那些？缺點(diǎn)評(píng)審那些？bug評(píng)估？測(cè)試總結(jié)報(bào)告文檔的輸出：1、能夠讓詳細(xì)的任務(wù)負(fù)責(zé)人對(duì)該