怎樣讓測試更全面

怎樣讓測試更全面付文龍軟件測試的現(xiàn)狀軟件產(chǎn)業(yè)發(fā)展到今天，如果還是用以前的思路、辦法（公司里絕大部分、甚至全部都是開發(fā)人員在做產(chǎn)品，只要能做出來可以用就行），企業(yè)的產(chǎn)品肯定沒有競爭力，從而導(dǎo)致這樣的軟件企業(yè)生存極其困難。正是因?yàn)檫@個原因，以前軟件測試以往一直被中小IT企業(yè)所忽視，只有一些知名企業(yè)才有門的軟件測試人員?，F(xiàn)在，更多的國內(nèi)企業(yè)認(rèn)識到測試的重要性，設(shè)立了軟件測試部門，配備了專業(yè)的軟件測試人員。既然我們有了測試部門，有了專職的測試人員，按理來說就不會再有質(zhì)量問題存在了，但客戶還是反饋有或多或少的問題存在。那么這是為什么呢？我們應(yīng)該從哪些方面來防止這些問題呢？

漏測的定義所謂漏測，是指軟件產(chǎn)品的缺陷沒有被測試組發(fā)現(xiàn)而遺漏到了用戶那里，最終被用戶所發(fā)現(xiàn)。進(jìn)行漏測分析的目的是為了促進(jìn)軟件質(zhì)量和開發(fā)測試過程得到持續(xù)改進(jìn)。具體來講，就是通過分析開發(fā)和測試過程中漏測的缺陷，制定相應(yīng)的預(yù)防措施以避免今后再發(fā)生類似的漏測。測試過程的持續(xù)改進(jìn)將提高測試環(huán)境的效果和測試執(zhí)行的效率、降低遺留到用戶處的缺陷數(shù)和缺陷解決成本，從而提升軟件的質(zhì)量、聲譽(yù)和銷售。在軟件產(chǎn)品開發(fā)過程中重視漏測分析并參與到漏測分析工作中的團(tuán)隊越多，漏測分析的效果就越好。如果開發(fā)和測試團(tuán)隊都重視漏測分析、并密切配合進(jìn)行漏測分析工作的話，漏測分析將取得非常好的效果。·需求評審·梳理需求·用例設(shè)計與評審·測試執(zhí)行·Bug回歸·發(fā)布前的功能回歸需求評審

參加需求評審會，理解需求文檔，在編碼前找出需求的bug，與客戶以及研發(fā)在需求的理解上達(dá)成一致的觀念。但是也可能存在以下的問題：沒有需求文檔？客戶對需要的產(chǎn)品目標(biāo)不明確，研發(fā)人員也不明確，這個時候，只能使用敏捷開發(fā)，把產(chǎn)品開發(fā)出來之后，先給用戶使用，然后再根據(jù)用戶提示的問題進(jìn)行修改，這樣的bug都比較難確定；需求總是不能固定？不固定需求就會引出問題，然后引出一系列的bug；需求已經(jīng)定義，是否吻合客戶實(shí)際應(yīng)用？

那么，這就需要我們在理解完需求之后，找負(fù)責(zé)人進(jìn)行確認(rèn)，并通知項(xiàng)目的參與人員，進(jìn)行一個有效的需求評審會議。是大家對需求都達(dá)到一致的認(rèn)識。日前一名張姓民眾到

南京市秦淮區(qū)的超市購買一款牛肉松營養(yǎng)面包，但仔細(xì)閱讀產(chǎn)品成分后，赫然發(fā)現(xiàn)小小一塊面包，成分竟高達(dá)20多種，但里面居然沒有牛肉相關(guān)成分。他憤而檢舉，認(rèn)為店家故意欺騙消費(fèi)者，痛斥“太不厚道了！”面對張先生的質(zhì)疑，食品業(yè)者回應(yīng)：“我們的意思是，這是很牛的肉松面包，而不是牛肉松面包”。業(yè)者表示，這個牛并非吃的牛，而是一種語氣詞，所以在包裝袋上宣傳并未不妥。而該公司的員工也認(rèn)為，食品名稱與成分其實(shí)沒有相對等的關(guān)系，“紅牛（redbull）里面有牛嗎？”需求評審軟件需求是開發(fā)工作和測試工作在制定計劃、開展工作時所共同參照的源頭和依據(jù)，而我們只有在源頭上控制好，才能保證下面工作的平穩(wěn)開展要保證軟件需求的可測試性。對于“可測試性”，就是要保證所有的需要實(shí)現(xiàn)的需求都是可以用某種方法來明確的判斷是否符合需求文檔中的描述既要熟悉需求人員的工作，又要熟悉軟件所涉及的行業(yè)的業(yè)務(wù)。需要對軟件產(chǎn)品所涉及的行業(yè)的業(yè)務(wù)有一個全面的、深入的了解及時檢測出軟件需求文檔中具有不可測試性的需求點(diǎn)。（某功能模塊輸入可見，輸出不可見，無法驗(yàn)證模塊功能是否正確；或是該功能模塊的輸出無參考標(biāo)準(zhǔn)來衡定）。及時發(fā)現(xiàn)軟件需求文檔的不完整性，從而提醒需求分析人員彌補(bǔ)描述。需求分析實(shí)例

題目：輸入三個數(shù)a、b、c分別作為三邊的邊長構(gòu)成三角形。通過程序判定所構(gòu)成的三角形是一般三角形、等腰三角形還是等邊三角形時。用等價類劃分方法為該程序設(shè)計測試用例。在三角形計算中，要求三角形的三個邊長：A

B

C。1、當(dāng)三邊不可能構(gòu)成三角形時提示錯誤，可構(gòu)成角形時計算三角形周長。

2、若是等腰三角形打印“等腰三角形”，若兩個等腰的平方和等于第三邊平方和，則打印“等腰直角三

角形”。

3、若是等邊三角形，則打?。骸暗冗吶切巍?。4、畫出程序流程圖并設(shè)計一個測試用例。

需求分析實(shí)例有效等價類：

輸入3個正整數(shù)或正小數(shù)：兩數(shù)之和大于第三數(shù)，如A<B+C；B<C+A；C<A+B兩數(shù)之和不大于第三數(shù)兩數(shù)相等，如A=B或B=C或C=A三數(shù)相等，如A=B=C三數(shù)不相等，如A！=B，B！=C，C！=A無效等價類：空負(fù)整數(shù)非數(shù)字

少于三個數(shù)梳理需求

在掌控了軟件項(xiàng)目的背景，了解了產(chǎn)品的質(zhì)量要求和軟件測試的基本需求之后，同時，測試人員也會閱讀相關(guān)軟件需求文檔，參與需求評審。在這些基礎(chǔ)之上，可以進(jìn)行測試的需求分析，即包括下面這些工作：明確測試范圍，了解哪些功能點(diǎn)要測試、哪些功能點(diǎn)不需要測試；知道哪些測試目標(biāo)優(yōu)先級高、哪些目標(biāo)優(yōu)先級低；要完成哪些相應(yīng)的測試任務(wù)才能確保目標(biāo)的實(shí)現(xiàn)。用例的設(shè)計與評審1、要參與需求評審，評審需求的過程實(shí)際也是熟悉業(yè)務(wù)需求的過程。只有對業(yè)務(wù)比較熟悉了，才能更好的，更充分的設(shè)計出高質(zhì)量的測試用例。2、要多閱讀文檔，其中包括產(chǎn)品策劃書、規(guī)格說明書、需求文檔，接口文檔等，我們可以收集一切相關(guān)的文檔來幫助理解所要測試的產(chǎn)品需要完成的目標(biāo)。3、盡量多參加項(xiàng)目組內(nèi)的會議。比如需求討論、設(shè)計討論、計劃討論等會議，這樣在討論過程中也能加深對產(chǎn)品的理解。4、要善于溝通，多和開發(fā)、PM進(jìn)行溝通。遇到不明確的問題、有疑問的需求，可以咨詢項(xiàng)目負(fù)責(zé)人或者客戶等。這樣才能提前解決需求理解偏差等。5、測試用例名稱，也叫測試用例標(biāo)題，一定要寫得簡潔、明了，需要用概括的語言描述該用例的出發(fā)點(diǎn)和關(guān)注點(diǎn)，使得測試人員第一眼看到測試用例名稱就能夠明白測試用例的目的。用例名稱中一般要求不能存在假設(shè)性的語句，并且原則上每個用例的名稱不能重復(fù)。用例的設(shè)計與評審6、預(yù)置條件要明確，包括測試環(huán)境、測試數(shù)據(jù)、測試場景。因?yàn)樵S多BUG只有在特定的環(huán)境、特定的場景下才可以重現(xiàn)。沒有正確的前提條件，就無法進(jìn)行后面的測試步驟或無法得到預(yù)期的結(jié)果。7、測試步驟描述要簡單、清晰，并且要清楚每一個步驟的描述，我們平常的鼠標(biāo)和鍵盤的每一動作都代表一個操作步驟。比如：第一步，輸入用戶姓名；第二步，輸入登錄密碼；第三步，用戶點(diǎn)擊登錄。步驟寫的明確時就利于提高用例的可操作性。8、用例的預(yù)期結(jié)果要完整而且清晰，并且要將各個輸出的結(jié)果寫出來，包括：返回值的內(nèi)容、數(shù)據(jù)庫相關(guān)字段的記錄、界面的響應(yīng)結(jié)果、輸出結(jié)果的規(guī)則符合度、日志的檢查和對其它業(yè)務(wù)影響的檢查。9、測試用例級別要劃分清楚，這樣在測試執(zhí)行時有主次之分。

總是有些缺陷的出現(xiàn)是出乎我們意料的，或者說是已有的測試需求和測試用例未能覆蓋的。那么，對于這部分缺陷，也應(yīng)當(dāng)添加到測試需求中，并設(shè)計相應(yīng)的測試用例，以便于下次版本迭代時進(jìn)行參考用例的設(shè)計與評審10、測試用例的劃分也要單一，一個測試用例只檢查功能點(diǎn)的一種情況。一個用例檢查的情況太多，會導(dǎo)致用例的目的不明確。而且這樣組織用例，有利于需求覆蓋率的統(tǒng)計。一個功能點(diǎn)我們測試了哪些情況，以及哪些功能點(diǎn)我們在重點(diǎn)測試，一目了然。11、評審用例很關(guān)鍵，因?yàn)榻?jīng)過測試用例的評審可以發(fā)現(xiàn)：用例設(shè)計的結(jié)構(gòu)安排是否清晰、合理；是否覆蓋所有的需求功能點(diǎn)；是否存在冗余的用例；是否具有很好的可執(zhí)行性；是否存在對需求理解上的差異等。評審需要項(xiàng)目經(jīng)理、需求分析人員、架構(gòu)設(shè)計人員、開發(fā)人員和測試人員都參與，也需要客戶方的開發(fā)人員和測試人員。12、召開測試用例評審會議，在會議上大家可以提問互答，對模糊不清的地方可以進(jìn)行討論。這樣可以站在不同的角度，站在很多人的思維和思考方式下設(shè)計用例。用例的設(shè)計與評審13、站在用戶的角度來設(shè)計用例，以用戶的使用邏輯及操作習(xí)慣為出發(fā)點(diǎn)，從用戶實(shí)際可能的操作場景考慮，一定要脫離系統(tǒng)提供功能。14、測試用例需要不斷更新和維護(hù)，不要認(rèn)為測試用例的設(shè)計是一個階段，測試用例的設(shè)計也需要迭代，在軟件開發(fā)的不同的階段都要回來重新審視和完善測試用例。并且需要在測試執(zhí)行時利用發(fā)散思維不斷的構(gòu)造和完善測試用例測試執(zhí)行在固定的時間內(nèi)，盡可能全面地執(zhí)行測試用例。1.在測試過程中不斷的添加遺漏的用例，一定要在發(fā)現(xiàn)時及時補(bǔ)充，有些用例是無意間操作發(fā)現(xiàn)的；2.詳細(xì)標(biāo)識每一個被執(zhí)行過的用例。問題回歸

測試過程中，遇到過一個小小的參數(shù)變動可能引起一個比較遠(yuǎn)的功能點(diǎn)的大bug，開發(fā)不知道，測試不清晰，勢必引發(fā)遺漏。在修改bug的這種情況下，有可能是牽一發(fā)而動全身的，是非常危險的。如果研發(fā)考慮的不周全，只修改了此bug，并沒有考慮到與它接口的功能，那將會引發(fā)更多的bug。發(fā)布前的功能回歸首先保證所有修改的bug驗(yàn)證通過，并且沒有引起別的bug；在測試的過程中，最好自己編寫checklist表，這樣到