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