在實際項目過程中溪北，存在不少對測試的誤會，聽著無傷大雅夺脾，但是如果真的這么做了之拨，可能測試朋友們就要和你友盡了。我們這里摘錄幾條劳翰，看起來都好“有道理”岸匦俊馒疹！
說法一佳簸、測試在開發(fā)結束后才開始
這樣的說法在多年前一度很占上風。開發(fā)都沒結束颖变，測試怎么進行啊生均，測什么呢？想想真的好有道理啊腥刹，我還能說什么呢马胧。
不過經過這么多年的教育和熏陶，現在官方場合的言論中衔峰，已經很少這么提及了佩脊，畢竟這樣的提法多少有些“政治不正確”蛙粘。我們知道開發(fā)結束后，開始的是測試執(zhí)行威彰，而不是整個測試出牧。按照偉大的測試生命周期理論，我們也是有測試需求歇盼、測試計劃舔痕、測試設計、測試環(huán)境準備等很多工作要做的啊豹缀。
只是到了實際的工作中伯复，一些行動最能體現這個想法。
比如項目資源分配的時候邢笙，各類測試服務器往往在測試執(zhí)行前夜才如“及時雨”般就緒啸如，畢竟支持部門也很忙，前面給你們也用不上啊氮惯。還別不高興组底，你看隔壁的項目組是進入測試執(zhí)行階段，我們才把測試環(huán)境的準備提上日程的筐骇。
比如我們不少客戶找上門的時候债鸡，都是萬分焦急；為什么呢铛纬？因為開發(fā)已經基本結束厌均，測試該進場了啊，不然趕不上上線時間表了告唆。碰到這種情況棺弊，我真想補一句：大哥，早些時候干嘛去了扒苄模她；現在這個點進去要趕上這個時間點，臣妾表示做不到啊懂牧。
說法二侈净、測試的意義就是發(fā)現缺陷
這個提法，我相信現在也非常有市場僧凤。不少測試團隊一直有著“以發(fā)現BUG為榮”的指導思想畜侦。這個無可厚非，能夠發(fā)現BUG躯保，尤其能夠發(fā)現別人不能發(fā)現的BUG旋膳，顯然是一種技能，甚至是一種天分途事。一些測試團隊的績效验懊、以及一些測試大賽也都是以發(fā)現BUG的個數（或者加權個數）為指標的擅羞。
只是，如果過于強調這一塊义图，甚至讓測試的意義與發(fā)現BUG劃上等號祟滴，則有違質量保證的宗旨了。
舉個例子歌溉，大家知道在功能測試中會有回歸測試的部分垄懂，側重于對原有功能的再次確認，這部分測試大概率是不會有缺陷的痛垛。那么草慧，以缺陷為價值評判指標的話，這部分測試會顯得沒啥意義匙头。但是漫谷，真相并非如此，要知道現在市場上的自動化測試絕大部分是以回歸測試為對象的蹂析；如此大的投入舔示，絕對不會用在一個沒有意義的事情上。而且哪怕是全新功能的測試电抚，但凡所測軟件不是“極品巨作”惕稻，能夠發(fā)現BUG而通不過的測試用例所占的也是小比例。所以蝙叛，不得不很抱歉地說一句：我們又做了好多無用功啊俺祠。
其實，測試工作有很大一部分的作用是給產品蓋一個“質量已檢疫”之類的印章借帘，而不是一定要證明這個產品哪里不行蜘渣。江湖上有一個說法：功能測試前期是抱著懷疑的態(tài)度和找茬的信念去找系統的BUG，而后期回歸測試是以嚴謹的作風去驗證這個系統是無錯的肺然。
眾所周知蔫缸，在一個系統提交上線前，往往會進行多輪測試际起。因為第一輪測試完后拾碌，會有缺陷；那么修復缺陷后加叁，顯然得再測一輪去驗證倦沧。這里問一個問題：如果系統今天就要上線了，在“最后一輪”終極驗證中它匕，作為測試的你是祈禱測試用例全部愉快地通過，系統可以順利上線呢窖认？還是說希望能找出一個BUG從而揚名立萬豫柬，然后陪著開發(fā)加班改完BUG又來一輪終極測試呢告希？【請注意，一臉壞笑的測略君絕對沒有誘導大家刻意去放過一些缺陷烧给，我們的討論是以職業(yè)操守為前提的】
說法三燕偶、提交缺陷是測試的事
看到這個說法的時候，大家是否覺得：這不是廢話么? 提BUG是上帝賦予測試的神圣使命啊础嫡。感謝這個神圣的安排指么，提交缺陷這個事情，測試人員本來就責無旁貸啊榴鼎。
我們一直在強調一個共識伯诬，就是保證質量是整個軟件團隊的事情，而不僅僅是測試人員的事情巫财。那么換言之盗似，人人都有責任去提交自己發(fā)現的缺陷。事實上平项，幾乎所有的缺陷管理工具赫舒，對于提交BUG這個事情都是不限角色的；這些工具創(chuàng)造者們的理念領先我們好多團隊的實踐闽瓢。
在這點上接癌，用戶往往是除了測試以外最熱心的了。我們有好幾個用JIRA或者Redmine工具的團隊扣讼，經橙咏В看到用戶在系統上提交各個階段發(fā)現的BUG，只要他們在某個環(huán)境上發(fā)現了問題届谈。與之相對的枯夜，在軟件團隊內部，可能做得就不夠好艰山。
前幾天湖雹，在一個調研聊天中，與一位開發(fā)聊起Peer Code Review和開發(fā)測試曙搬。我就問了一下“如果發(fā)現了問題或者缺陷怎么辦摔吏？”“和對方說一下，然后改掉纵装≌鹘玻”我不死心地追問：“不會記錄到JIRA里么？”“這個太麻煩了橡娄，開發(fā)改起來很快诗箍，馬上就發(fā)新版本的。我們一般是測試發(fā)現的BUG才登JIRA挽唉÷俗妫”看起來是我太過于認真了筷狼，盡管團隊實施敏捷有一段時間了，但是距離人人都是QA的境界還有很長的路匠童。
不過埂材，身邊還是有一些開發(fā)非常熱心，喜歡報一些BUG的汤求。最近俏险，公司在推一個問題反饋系統，反饋的對象也包括公司使用的內部系統扬绪。一段時間后竖独，我們對于熱心提問題的同事發(fā)了一些獎品，排名第一的是一位QA勒奇，畢竟是本色表現么预鬓；而緊隨其后的則是一位開發(fā)，這個就不得不點贊了赊颠。所以各位QA們格二，如果身邊有樂意報BUG的開發(fā)，一定要記得對他好啊~
說法四竣蹦、自動化測試就是使用工具
很多次顶猜，我在和人聊起自動化測試這個話題。對方就會問起：你們用什么工具的痘括？也有一些場合建議一些測試小伙伴學點自動化測試长窄，他們也會很直接地問：學哪個工具有前途呢？每次面臨這個場景纲菌，我竟有種無言以對的尷尬挠日。
這個就比如某外專業(yè)的同學立志轉行學計算機，一上來就問：學哪種開發(fā)語言翰舌、用什么開發(fā)工具好嚣潜？殊不知得提前補一下數據結構、編譯原理椅贱、操作系統懂算、數據庫原理等基礎知識。
而自動化本身的內容也遠不是一兩個工具可以涵蓋的：從自動化對象上庇麦，會有測試管理计技、測試數據準備、測試環(huán)境搭建山橄、測試執(zhí)行等各個環(huán)節(jié)垮媒；從測試類別上，可以應用在功能測試、性能測試涣澡、安全測試贱呐、兼容性測試等丧诺；從實施方式上入桂，可以自寫腳本、可以使用工具驳阎、可以搭建框架等等抗愁；從方法上，諸如錄制回放呵晚、數據驅動蜘腌、關鍵字驅動等等；……
基本上饵隙，但凡你能想到的所有測試工作撮珠，能夠替換手工的動作和方法，應該都是在自動化測試的范疇中金矛。所以每次有客戶提起要做自動化芯急，我都會問清楚具體目標是什么，以免產生誤會驶俊。
當然娶耍，通常概念上的自動化測試主要是指測試執(zhí)行的自動化。具體實施確實離不開工具饼酿，所以對于工具的精通和使用絕對是一個必備技能榕酒。至于哪個工具更好，只能具體問題具體分析了故俐。而且工具也絕對不僅僅是我們所熟知的那些被貼上自動化標簽的想鹰。要知道自動化測試的本質是用代碼代替手工，即我們把測試當作一個業(yè)務對象去開發(fā)一個或一套支持系統药版，因此任何編程工具都可能成為有效的自動化測試的工具辑舷。
舉個例子，在編程界很不起眼VBA就是一個自動化測試界的神器刚陡，用以支持測試中的數據收集惩妇、數據對比等各項數據處理流程和動作，方便快捷筐乳。比如我之前團隊就有成員用VBA寫了一個蘊含相當復雜業(yè)務邏輯的風控報表比對測試工具歌殃，大量基于數據的計算和對比都蘊含在那一個外表平常的Excel文件中；又比如也有QA Lead覺得收集各類測試報告太麻煩蝙云，用一個宏實現特定目錄下固定格式的測試執(zhí)行數據收集氓皱，生成測試報告不是難事。
