如何做個合格的測試員

　　本來想用“優秀”，后來想想不過“合格”而已。最近工作與學習的想法，內容比較碎，先記錄下來。

　　由于有寫博客的習慣，寫了不少關于測試的東西，常常被別人加群或直接加QQ問問題?？赡苁且驗槲覍懥瞬簧贃|西的緣故吧!大多數提問者會認為我一定水平很高，然后，問我是做什么測試的?用什么工具?我的回答是：主要以功能測試為主，會用到一些輔助的工具，如 fiddler。他們無不大失所望。

　　關于我的第一份工作的情況，我在《一個測試員的工作與學習》中已經說的比較詳細了。第二份工作(目前的這份工作)的經歷等什么時候辭職的時候再整理吧!

　　這里可以簡單簡述一下自己目前工作情況，雖然我們公司的測試人員是坐在一起的，但我們每個人都會長期的跟不同的項目。剛工作時打了三個月的醬油(哪里需要就往哪里去)。后來一位大姐請產假，我就接替了網盤工作，再后來忙不過來，新招了一哥們跟著我做網盤。工作內容：

　　參加需求評審-->編寫測試計劃-->編寫測試用例-->用例評審(召集產品，開發)-->項目上線后進行輪次測試(每測試一輪，發郵件出一輪測試結論)-->幾輪過后沒什么問題項目上灰度(相當于內測)-->灰度測試過后上全網-->出測試報告。

　　好吧!我來說說這個過程中的注意點：

　　溝通

　　稿IT的嘛，一般典型的悶騷男(我也屬于)。在網絡都是文藝、憤青?，F實工作環境中什么狀態自己知道。我之前認識一稿開發的哥們技術沒得說，鉆研精神沒得說。我去向他請教問題，他跟我說話緊張，稿得我都提他著急。在工作中要與上級溝通，開發溝通，產品溝通，這方面確實需要注意加強。在需求評審中多發表自己對需求對產品的看法。在用例評審中是以測試為主導的會議，所以，一定要思路清晰，有條不紊的評審用例。在測試過程開發或產品確認問題，協助開發定位問題都需要溝通。兩個詞，淡定，謙虛。

　　用例設計

　　好的測試用例是用最恰當用例覆蓋更多的功能點。有些人寫用例粒度很細，簡單的幾個功能就能寫幾百條用例。寫得越細致，需求稍微一變。你的用例直接作廢。寫得太粗，很多功能點覆蓋不到。我的觀點是考慮要全面，用例要靈活?？紤]要全面很難，經驗再豐富的人難免百密一疏。這個只能在血和淚的教訓中去積累吧。多花時間研究被測的業務與需求。多看看別人寫的用例從中也會收獲不少。

　　用例要靈活，例如，我一般預期結果會寫“給出相應提示”“匹配輸入的內容”等模糊的預期結果，至于開發具體怎么設計是他的事兒。只要是合理的，不產生歧義的，使用戶很容易理解的設計。我都認為是正確的。當然，這可能會給讀用例的人帶來一點麻煩。還有，如果產品需求中有明確的要求的，一定要寫清楚。

　　仔細檢查你的文檔

　　測試人員最繁瑣的是一個項目下來要寫許多文檔，測試計劃文檔，測試用例文檔，測試論次報告，測試報告文檔，驗收方案文檔等等，相信你在長期的工作中已經完全具備了這點兒能力，我想說的是細心。我們習慣在之前的文檔上拷貝一份修改。這樣可以節省不少時間，但也容易出錯。我就是這樣，或日期，或數據忘記修改。好吧!身為一個測試員，這為自身能力表現打折不少。不要小看這點事兒。寫過的文檔最好要反復檢查兩遍。

　　積累你的技術

　　老在開發面前表現的“小白”，我要是開發，我也鄙視你!按我目前的工作，需要熟悉系統的結構，熟悉開發的語言，熟悉數據庫，除了測界面測功能，可以查一下數據庫，數據到底有沒有存儲成功，或者修改數據庫數據查看前面效果。如，我要測試網盤空間滿了之后，上傳文件的提示信息。通過功能你要上傳多少個大文件空間才滿呀?直接改數據庫里面文件的大小不就搞定了。

　　在前臺界面操作的時候，去查看一下服務器日志，是否有報錯信息。通過服務器日志有時候也能定位或判斷問題的原因。

　　多用頁面分析或抓包工具，例如，按鈕點擊無效，那用debug工具查看頁面上這個按鈕的屬性。用抓包工具看一下請求與響應?？傊?，在測之過程中試著去解剖被測系統。

　　發現問題之后

　　測試人員最激動人心的時刻就是發現bug了。當你發現一個bug的時候，不要急著就上報到缺陷管理系統或告訴開發人員。首先確定重現步驟。換個系統試試，換個瀏覽器再試試?；蛟S，是你忘記清理瀏覽器緩存導致某個問題還在。好吧，最好試著定位與解析這個bug的根源。

　　第二點我要說的是，發現一個模糊的問題，應該試著站在多個角度去看待這個問題，站在用戶的角度考慮這個問題的影響。站在開發角度去看待這問題的嚴重性與修復成本。向開發去說明這個問題對用戶的影響。這樣更能開發建立和諧的關系。

　　測試應該學些什么

　　這是常被問到的第二類問題，我不被重視，很少安排工作，應該學些什么?對于這個問題，我把測試人員的知識體系分兩大塊，一塊就是測試知識，一塊就是整個軟件知識。

　　先說測試知識，測試基礎類的，不少測試員是沒讀過什么軟件測試書籍(包括我個人也是最近讀了幾本)因為大學開軟件測試專業的不多，培訓學校更注重實踐，可能不會給你講太多理論性的東西(個人猜測，沒培訓過)。大多測試測試人員非科班出身。測試門檻確實不高，熟悉一下就直接做了測試。沒精力和必要花太多時間去學習基礎理論。好吧!這也是問得我做是功能測試時，大多數人表現出來的失望與不屑原因。好吧!我還是覺得你應該讀幾本測試的書《[軟件測試]Ron Patton》 《全程軟件測試》 《軟件測試paul C. Jorgensen》《有效性能測試--測試人員的50條建議》 《軟件測試技術經典教程+第2版》 ，當還有《微軟的軟件測試之道》以及最為經典的《軟件測試的藝術》 ，如果你不知道關于軟件測試都有哪些書的話，為什么不去當當網和china-pub輸入“軟件測試”幾個關鍵字搜索一下呢?

　　當然了，你對這些不感興趣，想學一些更實用，看上去很厲害的樣子的技術，可以搜索一下性能測試的書，自動化測試以及單元測試，探索性測試，敏捷測試等。不過，我還是建議打好測試的基礎!即使再多的花樣，再先進的技術都是為測試服務的，你都不了解測試的本質是什么?那就是盲目的追求。

原文轉自：http://www.cnblogs.com/fnng/archive/2013/01/07/2848502.html