軟件測試從零開始
本文分別講一講從測試前的準(zhǔn)備工作、測試需求了解、測試用例設(shè)計、測試用例執(zhí)行到測試結(jié)果分析的五個階段中，測試新手需要注意的幾個要點。1、測試前準(zhǔn)備工作 我們測試人員的工作，就是為質(zhì)量保證提供信息。
作為一名軟件測試新手，如何才能發(fā)現(xiàn)所有的 BUG ？如何開始測試工作？即便面對的是一個很小的軟件項目，測試需要考慮的問題也是方方面面的，包括硬件環(huán)境、操作系統(tǒng)、產(chǎn)品的軟件配置環(huán)境、產(chǎn)品相關(guān)的業(yè)務(wù)流程、用戶的并發(fā)容量等等。該從何處下手呢？
1.1 向有經(jīng)驗的測試人員學(xué)習(xí) 這幾年在帶新人的過程中，整理了一些軟件測試技術(shù)、測試流程、測試工具和質(zhì)量管理相關(guān)文檔資料，有興趣的朋友可以評論里說一下。 跟有經(jīng)驗的人學(xué)習(xí)大家都知道，不過需要注意的是，應(yīng)時刻保持質(zhì)疑和尋根究底的態(tài)度去學(xué)習(xí)。 1.2 閱讀軟件測試相關(guān)書籍 有人整理過一篇介紹測試書籍的文章。另外，多看看論壇和測試方面的公眾號。
1.3 查看歷史bug 現(xiàn)在多數(shù)公司都有bug管理工具，里面的bug對我們了解項目是非常有價值的。這些bug是軟件產(chǎn)品問題的集中體現(xiàn)。一般來說，我們需要關(guān)注這幾個點：
bug描述：照著葫蘆畫瓢。
開發(fā)對bug的解決方法：理解原理，積累經(jīng)驗。
常見問題有哪幾類，都是什么原因?qū)е拢嚎偨Y(jié)并作bug預(yù)防
哪些模塊容易出問題：問題多的重點測
哪些開發(fā)出的問題多：判斷開發(fā)水平，水平低的重點測
誰提的bug多/好：以后多跟他學(xué)習(xí)
1.4 走讀歷史用例 走讀別人的用例來提升自己的用例編寫水平。走讀測試用例也是有技巧的。走讀用例時除了學(xué)習(xí)別人的語言描述技巧，更重要的是多問幾個為什么，為什么他要寫這條用例，為什么把這個模塊自動化而不是另一個？
測試用例編寫有幾個原則：準(zhǔn)確性、簡潔性、可重用性、適用性、可跟蹤性、純凈性。當(dāng)然這幾個原則并不是在所有情況下都要遵守的，這取決于項目、執(zhí)行人等多種情況。我計劃于近期在我的qq群開一次測試用例的課程，歡迎有興趣的來一起學(xué)習(xí)。
1.5 學(xué)習(xí)產(chǎn)品相關(guān)的業(yè)務(wù)知識 軟件測試人員不僅要掌握軟件測試技術(shù)相關(guān)知識，對產(chǎn)品相關(guān)的業(yè)務(wù)知識也要學(xué)習(xí)。這很好理解，如果從事財務(wù)軟件的測試工作，一定要學(xué)習(xí)財務(wù)知識；如果從事通訊產(chǎn)品測試工作，那么相關(guān)的通訊理論知識也是必須的；如果從事銀行軟件的測試，銀行的業(yè)務(wù)流程也是不可或缺的知識點。
2、識別測試需求 識別測試需求是軟件測試的第一步。
如果開發(fā)人員能夠提供完整的需求文檔和接口文檔，那固然好。可以根據(jù)需求文檔中描述的每個功能項目的輸入、處理過程和輸出，來設(shè)計測試用例。如果開發(fā)人員沒有提供軟件需求文檔，那該如何是好？下面給出幾個有效的方法：
2.1主動獲取需求 開發(fā)人員通常不會更好地考慮軟件測試，如果沒有開發(fā)流程的強(qiáng)制規(guī)定，他們通常是不愿意提供任何開發(fā)文檔，即便有強(qiáng)制規(guī)定，需求文檔也未必能夠真正指導(dǎo)軟件系統(tǒng)測試工作。因此，需要測試人員發(fā)揮主觀能動性，與相關(guān)的軟件開發(fā)項目經(jīng)理和軟件開發(fā)人員保持溝通，了解軟件實現(xiàn)的主要功能是什么，并記錄得收集到的信息。一般來說，開發(fā)人員即便沒有提供相關(guān)需求文檔，也會保存一些簡單的過程文檔，主動向開發(fā)人員索要這些文檔，可以作為測試的參考。此外，可以與公司的技術(shù)支持（業(yè)務(wù)/客服）人員交流，技術(shù)支持（業(yè)務(wù)/客服）人員是最貼近用戶的人，因此，通過交流可以獲取第一手的用戶使用感受，在測試的過程中會更加貼近用戶。
當(dāng)拿到相關(guān)的資料后，從哪些方面分析需求？如何與開發(fā)人員交流需求？其實，只要把握需求分析的幾個關(guān)鍵的點就可以解決問題：輸入、處理過程、輸出、性能要求、運(yùn)行環(huán)境，下面針對每一個項目逐一分析： 輸入： 與該需求相關(guān)的一切可能輸入，可以從這幾方面考慮，輸入來源、輸入?yún)?shù)的數(shù)量、輸入?yún)?shù)的度量單位、輸入?yún)?shù)的時間要求、輸入?yún)?shù)的精度和輸入?yún)?shù)的有效輸入范圍。在測試用例設(shè)計中，這部分內(nèi)容作為測試用例輸入的依據(jù)。 處理過程： 描述對輸入數(shù)據(jù)所執(zhí)行的所有操作和如何獲得輸出的過程。測試人員了解處理過程即可，在測試過程中發(fā)現(xiàn) BUG 時候，如果對處理過程了解的深入，對定位問題根源有很大的幫助。 輸出： 描述每個需求的輸出結(jié)果，包括輸出的位置，輸出參數(shù)的數(shù)量、輸出參數(shù)的度量單位、輸出參數(shù)的時序、輸出參數(shù)精確度、輸出參數(shù)的有效輸出范圍、錯誤消息。在測試用例設(shè)計中，這部分內(nèi)容作為測試用例的預(yù)期輸出。 性能要求： 與該需求相關(guān)的性能要求，比如 “ 插入 ATM 取款卡后， 3 秒鐘內(nèi)彈出提示用戶取款的圖形界面 ” 。 3 秒鐘這一限制，就是對需求的基本性能要求。 運(yùn)行環(huán)境： 軟件的運(yùn)行所需的環(huán)境，包括硬件平臺的要求、操作系統(tǒng)的要求、數(shù)據(jù)庫的要求，以及其它相關(guān)支撐軟件的要求。
2.2 確認(rèn)需求的優(yōu)先級 確認(rèn)需求的優(yōu)先級是很必要的，在產(chǎn)品進(jìn)度比較緊的情況下，需要根據(jù)優(yōu)先級來安排迭代頻次。
有可能的話，推動公司規(guī)范的開發(fā)流程，讓開發(fā)人員在編寫軟件需求文檔的時即對需求排優(yōu)先級。但是開發(fā)未能提供，那么需求的優(yōu)先級只能由測試人員完成了。2.3 加入開發(fā)小組的（郵件）群組 測試人員需要通曉被測試產(chǎn)品，但是，產(chǎn)品在開發(fā)的過程中往往是不斷變化的。如果軟件開發(fā)團(tuán)隊有一套變更控制流程，測試人員會對產(chǎn)品的變更了如指掌。如果沒有變更控制，那就要采用其他的土方法了，不如申請加入開發(fā)的聊天群，或者郵件群組。當(dāng)開發(fā)人員討論問題、通知召開技術(shù)會議的時候，測試人員可以及時知曉，如果必要，可以參加開發(fā)人員的技術(shù)會議。 即便公司里面有了軟件變更控制流程，加入到開發(fā)郵件群組也是一個很好的習(xí)慣。2.4 與開發(fā)人員為鄰 盡可能跟開發(fā)搞好關(guān)系，盡可能座次靠近開發(fā)。
頁:
[1]