現(xiàn)在，幾乎所有接觸IT行業(yè)的人都開始熟悉軟件測試了。但似乎所有人的評(píng)判標(biāo)準(zhǔn)似乎還停留在“能更多更快找出bug的才是好的測試工程師”血柳。仔細(xì)思考這句話员淫，有錯(cuò)嗎映皆？好像邏輯上挺能說得過去步淹，于是不光別人這樣認(rèn)為辛燥，測試工程師自己也開始這樣考量自己了榴都。

這樣下來拴驮，測試工程師就直接與“找bug的人”劃上了等號(hào)。我挺想用本末倒置來形容這種現(xiàn)象，當(dāng)然回想自己這2年多的工作袄琳，與這也比較類似嘿辟。對(duì)測試工程師來說召调，目的是要保證產(chǎn)品質(zhì)量，找bug只是其中比較重要的一個(gè)環(huán)節(jié)，但絕不是做好了這個(gè)環(huán)節(jié)就能代表自己很出色饶唤，因?yàn)槟阋欢ㄟ€聽說過“bug是找不完的”這么個(gè)預(yù)言性穿。

那么問題來了，軟件測試到底是要做什么！

這個(gè)問題有些糾結(jié)，因?yàn)榉_書，都會(huì)先把軟件工程大篇幅描述一遍抖誉，然后告訴你一整套規(guī)范的軟件企業(yè)流程孽文，具體怎么用，幾乎沒有涉及愕贡。當(dāng)你了解之后，進(jìn)了公司问拘，發(fā)現(xiàn)“我X蕾久，完全不一樣”栅迄，說好的這些規(guī)范怎么都不執(zhí)行，這個(gè)公司是不是不靠譜啊礁鲁。

答案當(dāng)然是否定的，leader當(dāng)然知道需求的變更、開發(fā)的延遲都會(huì)對(duì)軟件質(zhì)量帶來風(fēng)險(xiǎn)锅棕，但是對(duì)當(dāng)下的市場來說朋其，按照流程按部就班肯定不符合大局几蜻。那么測試工程師要怎樣適當(dāng)?shù)貙L(fēng)險(xiǎn)降低呢？分享一些小經(jīng)驗(yàn)急波，對(duì)于大牛來說直接跳過吧。

• 熟悉產(chǎn)品各個(gè)模塊

  對(duì)任何一個(gè)產(chǎn)品，增加對(duì)產(chǎn)品的熟知程度總歸不是壞事用踩。當(dāng)知道產(chǎn)品的開發(fā)邏輯是怎樣的恰梢，便能很好的響應(yīng)需求變更嵌言。

  舉個(gè)例子，產(chǎn)品的需求原本使用A方案實(shí)現(xiàn)焚虱，卻由于需求進(jìn)行了微調(diào)谍咆，使用B方案將更適合。對(duì)于沒有經(jīng)驗(yàn)的產(chǎn)品經(jīng)理誓焦，往往從開發(fā)那里獲取方案，此時(shí)開發(fā)流程已經(jīng)開始越平，調(diào)整方案將會(huì)增加工作量频蛔，帶來風(fēng)險(xiǎn)是必然的，那么對(duì)測試來說秦叛，該如何給出建議晦溪？

  如果對(duì)產(chǎn)品邏輯不知曉，當(dāng)然是任由開發(fā)“擺布”书闸，后期二次改動(dòng)同樣需要工作量尼变。但如果熟悉產(chǎn)品邏輯，可以將兩種實(shí)現(xiàn)方案進(jìn)行比較浆劲，列出優(yōu)缺點(diǎn)進(jìn)行評(píng)估嫌术，最終采用更合理的方式解決問題。

  所以牌借，對(duì)產(chǎn)品各個(gè)模塊的熟悉是測試人員一個(gè)非常必要的能力度气。

• 對(duì)于測試用例的優(yōu)先級(jí)明確劃分

  在測試時(shí)，大家總是會(huì)忽略測試用例的重要性膨报。一個(gè)產(chǎn)品動(dòng)輒上千的用例實(shí)在讓人頭疼磷籍。但是，好的測試用例能夠幫助測試工程師在時(shí)間緊急的時(shí)候提高測試效率现柠。

  測試工程師對(duì)測試用例一定不陌生院领，但是挑選待執(zhí)行的用例時(shí)往往比較隨意，有一句話特別好够吩，“差不多就行了”比然。但這個(gè)差不多往往是坑了自己，工作量變大周循，有效性可能降低强法，反而得不償失。

• 能做成自動(dòng)化測試要努力

  如果你有想法把產(chǎn)品的部分功能做成自動(dòng)化測試湾笛，那么恭喜你饮怯，至少為自己減少工作量提高效率找了一個(gè)好思路。But嚎研，自動(dòng)化沒有想象中那么簡單蓖墅。

  首先，得要研究不同的自動(dòng)化測試框架，并且找到當(dāng)前產(chǎn)品適用的

  第二置媳，區(qū)分好產(chǎn)品模塊于樟，哪里適合公条，哪里不適合拇囊，比如UI自動(dòng)化和功能自動(dòng)化有可能選擇不同的框架

  第三，區(qū)分優(yōu)先級(jí)靶橱，一般來說寥袭，使用頻率高的模塊優(yōu)先考慮

  另外，實(shí)現(xiàn)時(shí)一定要考慮方案是否完善关霸，一個(gè)半成品的自動(dòng)化測試代碼更加坑人传黄。

• 介入需求一定要早早早

  千萬不要認(rèn)為測試工作開始于開發(fā)的動(dòng)工，了解需求對(duì)于測試工作太重要了队寇。工作中膘掰，經(jīng)常會(huì)出現(xiàn)產(chǎn)品經(jīng)理描述需求不明確，或者產(chǎn)品佳遣、開發(fā)识埋、測試三方理解不一致，提前統(tǒng)一戰(zhàn)線必然有利于降低風(fēng)險(xiǎn)零渐。

  同時(shí)窒舟，討論評(píng)估需求時(shí)，測試工程師可以從需求的來源進(jìn)行分析诵盼，提出這個(gè)需求是不是該這么做惠豺，雖然沒有太多的工作量，但是對(duì)于產(chǎn)品的質(zhì)量和可用性是很有好處的风宁。

亂七八糟說了不少洁墙，總得看來沒啥太強(qiáng)的邏輯性，不過以上是在工作中切實(shí)體會(huì)到的戒财，如果大家還有其他的方法热监，歡迎在專題“被遺忘的軟件測試”中分享~