軟件測試中如何深入功能測試
來淘寶實習3個月，剛開始來直接做功能測試，執行用例。覺得執行功能測試用例沒有什么技術含量，做測試還是做接口測試、自動化測試、性能測試才比較有前途。于是研究自動化工具，學習腳本語言ruby。一起來實習的同學看到我整天忙得沒閑下來，覺得我學習沒有重點，看的資料多，但什么都學得不精，我當時也很困惑，靜下來想了很多。
首先，我想到的是，什么才是“有技術含量”。一個“有技術含量”的東西就是你能做而別人不能做，或者你能把工作完成的又快又好。如果你的工作任何人隨時都能勝任，那就不算有技術含量。從這方面來看，很多人覺得手工完成功能測試沒有技術含量不足為奇。因為如果按照用例去執行，根據前置條件，執行步驟，預期結果,即使是一個從來沒有做過測試的人也可以很輕松的勝任。但是如果是設計、編寫用例，給出一個功能點，是不是每個人都能快速的設計出覆蓋率高、復用性能好的測試用例，而且語言簡潔，條例清晰。這個答案就不一定了。在我實習期間，第一次做了一個完整的項目，用例總體設計是師傅顧欣， 用例的2/3是師傅完成的。我明顯意識到了差距，不懂業務，不熟悉邏輯方法，自己只有努力看需求以及請教師傅和開發的同時，把邏輯搞清楚，把業務弄熟悉。
再次，不管什么工作，什么事情，，只要堅持做得深入·，就會有能力的提升。對于測試來說，我認為能力包含技術，還包括技術以外的東西，比如：交流能力、寫技術文檔的能力。技術方面的，比如如何定位BUG，追蹤BUG,就可以做的很深。這個問題，面試的時候，面試官也問過我。在項目中我碰到過這樣一個問題：瀏覽器交叉測試，我用FireFox發現了多行文本在超長字符校驗上有問題，但是IE上就沒有問題。開始準備直接提交BUG，定位為瀏覽器差異。后來請教師傅顧欣，她詳細校驗了空格、回車符在2種瀏覽器中的計數差別，很快定位到BUG是由于回車符在FF上是記做了2個字符，提交BUG。很明顯，第二種做法，BUG修復起來也快，而且開發也愿意配合，自己的能力也能得到提升。測試人員不能一味地只提BUG，有時可能將正確的東西誤認為是BUG，也是對開發人員的勞動成果不負責任的否定。的確，一開始反復確認BUG,慢慢細化問題的時候，會很花時間，而且效率并不高，但是有句話不是說“火車剛發明的時候比馬還慢”，當你積累了業務經驗、熟練運用工具后，你會發現BUG定位越來越快，處理問題越來越順手，自己的能力也得到了提升。
當碰到無法解決的問題時，要積極地和開發商量，不要自己鉆牛角尖。在項目中我也碰到過這樣的問題，后臺設置單選、多選選項的BUG，提交開發，發現是分詞方法使用有誤，開發修復之后，我詢問了他修復使用的方法。我們得承認，在編碼方面，開發人員確實比測試人員更專業，他們解決修復BUG的方法值得我們在后面的測試用例設計的時候好好借鑒。但我們也不能妄自菲薄，只有把測試工作做得更專業，才能得到別人的信服。
最后，其他能力的鍛煉�？梢钥隙ǖ囊稽c是，測試不是想象，想怎么測，就怎么測，不是你點點鼠標就能完成的一件事。我們總是在開始測試之前，就先把思路整理清楚，鍛煉了邏輯思維能力。我們總是在描述BUG的時候，擔心開發看不懂，每次以他人的眼光審視自己寫的BUG，是否有歧義，是否帶有截圖，是否有步驟的詳細描述，是否簡練直白，鍛煉了文字描述。我們總是和PD確認需求，和開發確認缺陷，鍛煉了溝通能力�？赡苡腥苏J為這不是一種能力的提升，不能稱之為收獲。但是如果沒有經歷這些情景，你是不是會在執行測試用例的時候，發現還有功能點沒有寫進TC里面，要重新再寫再測；你是不是提交BUG之后，開發過來問你，這個BUG是怎么回事；你是不是在需求了解的不是很清楚的時候，把一個不是錯誤的BUG提交給開發，開發立馬把BUG狀態改成invalid，等等。
任何工作，在BS他之前，先看看自己對他付出了多少。如果你只是簡單的學會怎么用自動化或者性能測試的工具，而不去深入了解內涵，也不會有什么能力的提升吧。
在經歷了淘寶實習期，我更了解測試工作，也堅定自己繼續在這個行業發展的目標，所以在剛來迷茫期的時候，我把自己的旺旺簽名改成了“一步一步來，不要焦慮”，我喜歡沒有焦慮，一步一個腳印的認真生活。
文章來源于領測軟件測試網 http://www.anti-gravitydesign.com/
