本來想用“優秀”，后來想想不過“合格”而已。最近工作與學習的想法，內容比較碎，先記錄下來。
由於有寫博客的習慣，寫了不少關於測試的東西，常常被別人加群或直接加QQ問問題。可能是因為我寫了不少東西的緣故吧！大多數提問者會認為我一定水平很高，然后，問我是做什么測試的？用什么工具？我的回答是：主要以功能測試為主，會用到一些輔助的工具，如 fiddler。他們無不大失所望。
關於我的第一份工作的情況，我在《一個測試員的工作與學習》中已經說的比較詳細了。第二份工作（目前的這份工作）的經歷等什么時候辭職的時候再整理吧！
這里可以簡單簡述一下自己目前工作情況，雖然我們公司的測試人員是坐在一起的，但我們每個人都會長期的跟不同的項目。剛工作時打了三個月的醬油（哪里需要就往哪里去）。后來一位大姐請產假，我就接替了網盤工作，再后來忙不過來，新招了一哥們跟着我做網盤。工作內容：
參加需求評審-->編寫測試計划-->編寫測試用例-->用例評審（召集產品，開發）-->項目上線后進行輪次測試（每測試一輪，發郵件出一輪測試結論）-->幾輪過后沒什么問題項目上灰度（相當於內測）-->灰度測試過后上全網-->出測試報告。
好吧！我來說說這個過程中的注意點：
溝通
搞IT的嘛，一般典型的悶騷男（我也屬於）。在網絡都是文藝、憤青。現實工作環境中什么狀態自己知道。我之前認識一搞開發的哥們技術沒得說，鑽研精神沒得說。我去向他請教問題，他跟我說話緊張，搞得我都提他着急。在工作中要與上級溝通，開發溝通，產品溝通，這方面確實需要注意加強。在需求評審中多發表自己對需求對產品的看法。在用例評審中是以測試為主導的會議，所以，一定要思路清晰，有條不紊的評審用例。在測試過程開發或產品確認問題，協助開發定位問題都需要溝通。兩個詞，淡定，謙虛。
用例設計
好的測試用例是用最恰當用例覆蓋更多的功能點。有些人寫用例粒度很細，簡單的幾個功能就能寫幾百條用例。寫得越細致，需求稍微一變。你的用例直接作廢。寫得太粗，很多功能點覆蓋不到。我的觀點是考慮要全面，用例要靈活。考慮要全面很難，經驗再豐富的人難免百密一疏。這個只能在血和淚的教訓中去積累吧。多花時間研究被測的業務與需求。多看看別人寫的用例從中也會收獲不少。
用例要靈活，例如，我一般預期結果會寫“給出相應提示”“匹配輸入的內容”等模糊的預期結果，至於開發具體怎么設計是他的事兒。只要是合理的，不產生歧義的，使用戶很容易理解的設計。我都認為是正確的。當然，這可能會給讀用例的人帶來一點麻煩。還有，如果產品需求中有明確的要求的，一定要寫清楚。
仔細檢查你的文檔
測試人員最繁瑣的是一個項目下來要寫許多文檔，測試計划文檔，測試用例文檔，測試論次報告，測試報告文檔，驗收方案文檔等等，相信你在長期的工作中已經完全具備了這點兒能力，我想說的是細心。我們習慣在之前的文檔上拷貝一份修改。這樣可以節省不少時間，但也容易出錯。我就是這樣，或日期，或數據忘記修改。好吧！身為一個測試員，這為自身能力表現打折不少。不要小看這點事兒。寫過的文檔最好要反復檢查兩遍。
積累你的技術
老在開發面前表現的“小白”，我要是開發，我也鄙視你！按我目前的工作，需要熟悉系統的結構，熟悉開發的語言，熟悉數據庫，除了測界面測功能，可以查一下數據庫，數據到底有沒有存儲成功，或者修改數據庫數據查看前面效果。如，我要測試網盤空間滿了之后，上傳文件的提示信息。通過功能你要上傳多少個大文件空間才滿呀？直接改數據庫里面文件的大小不就搞定了。
在前台界面操作的時候，去查看一下服務器日志，是否有報錯信息。通過服務器日志有時候也能定位或判斷問題的原因。
多用頁面分析或抓包工具，例如，按鈕點擊無效，那用debug工具查看頁面上這個按鈕的屬性。用抓包工具看一下請求與響應。總之，在測之過程中試着去解剖被測系統。
發現問題之后
測試人員最激動人心的時刻就是發現bug了。當你發現一個bug的時候，不要急着就上報到缺陷管理系統或告訴開發人員。首先確定重現步驟。換個系統試試，換個瀏覽器再試試。或許，是你忘記清理瀏覽器緩存導致某個問題還在。好吧，最好試着定位與解析這個bug的根源。
第二點我要說的是，發現一個模糊的問題，應該試着站在多個角度去看待這個問題，站在用戶的角度考慮這個問題的影響。站在開發角度去看待這問題的嚴重性與修復成本。向開發去說明這個問題對用戶的影響。這樣更能開發建立和諧的關系。
測試應該學些什么
這是常被問到的第二類問題，我不被重視，很少安排工作，應該學些什么？對於這個問題，我把測試人員的知識體系分兩大塊，一塊就是測試知識，一塊就是整個軟件知識。
先說測試知識，測試基礎類的，不少測試員是沒讀過什么軟件測試書籍（包括我個人也是最近讀了幾本）因為大學開軟件測試專業的不多，培訓學校更注重實踐，可能不會給你講太多理論性的東西（個人猜測，沒培訓過）。大多測試測試人員非科班出身。測試門檻確實不高，熟悉一下就直接做了測試。沒精力和必要花太多時間去學習基礎理論。好吧！這也是問得我做是功能測試時，大多數人表現出來的失望與不屑原因。好吧！我還是覺得你應該讀幾本測試的書《[軟件測試]Ron Patton》 《全程軟件測試》 《軟件測試paul C. Jorgensen》《有效性能測試--測試人員的50條建議》 《軟件測試技術經典教程+第2版》 ，當還有《微軟的軟件測試之道》以及最為經典的《軟件測試的藝術》 ，如果你不知道關於軟件測試都有哪些書的話，為什么不去當當網和china-pub輸入“軟件測試”幾個關鍵字搜索一下呢？
當然了，你對這些不感興趣，想學一些更實用，看上去很厲害的樣子的技術，可以搜索一下性能測試的書，自動化測試以及單元測試，探索性測試，敏捷測試等。不過，我還是建議打好測試的基礎！即使再多的花樣，再先進的技術都是為測試服務的，你都不了解測試的本質是什么？那就是盲目的追求。
另外一個要學的是軟件知識，測試是為軟件服務的，軟件工程，編程語言，架構，網絡，一切與開發有關的知識，你都要學，這里要學的東西非常多，不要求深度但要求廣度。我們在需求評審的時候，有時開發人員會說到技術實現，功能的邏輯，內部處理機制，架構層級等，如果你全部不懂那多“見外”呀，當然，這些知識無形中潛移默化的作用你的測試行為，對被測系統的理解深度以及發現問題的深度。我曾多次用“隔衣撓癢”來說不懂開發的測試，什么感覺，你自己體會去吧！
當然，每個人都有自己的知識架構和自我的學習路線。不要猶豫哪個技術好學，哪個技術有前途，哪個技術工資高。比對吧！看看各種技術社區相互吐槽。只能是沒完沒了吐槽。不管你學與不學，技術就在那里，你的技術水平不增不減。當然，也不能一直悶頭苦學，學一段時間應該停下來總結與思考。我要走什么路線？我所走的路線還欠缺哪些能力？我還有哪些方面需要加強。當然，也應該關注一下未來的技術趨勢。
職責決定價值
最近讀的51testing《 軟件測試，想說愛你不容易》一文，感受頗深。作者以工作七年測試員的感受來談軟件測試。
其中有一例子頗為深刻，一語道明其中的道理。如果做為一個努力並掙扎中的測試員依然不明白為測試為什么低於開發。拿護士與醫生來比喻測試與開發的關系再明了不過了。一個醫院中最常見的兩個職位就是醫生與護士。即使再優秀再專業的護士，治愈不了病人的病。同樣，一個再優秀的測試員做不出軟件來。名醫很多，也許你隨口就能叫出幾個來，有誰能細數一下有名的護士，除了開創者南丁格爾。恐怕叫不上一個來。其實測試與開發也是這樣的關系。因為職責不同，當然有輕重之分。
存在既有價值，醫院不能沒有護士，軟件開發中需要測試。好吧！請正確看待自己職業。也許，你會轉向更有價值的開發人員，或者架構師。或者不着邊的工作。我想大多會繼續選擇在測試的道路上繼續前行。那就盡量讓自己的價值最大化吧。帶個測試團隊，或做測試講師，或出幾本書，成為一個測試專家，探索一下測試的新技術，新模式。既然選擇了並熱愛那就努力前行吧！
敏捷測試
由於最近項目的情況，越來越決得流程的繁瑣。在這么繁瑣的流程下，並沒有很好的保證產品的質量，測試人員的大部分時間都消耗在各種文檔中。所以，開始了解敏捷測試。也想從中尋找想要的答案。
敏捷測試對測試人員提出了更高的要求。測試不再是流程中的一個環節，而是高度的融入項目的整個流程。也許這可以使測試人員的價值更大化，但需要你有足夠的能力去迎接它。
敏捷測試人員的定義
我們這樣定義敏捷測試人員：專業的測試人員，適應變化，與技術人員和業務人員展開良好協作，並理解利用測試記錄需求和驅動開發的思想。敏捷測試人員往往具有優秀的技術能力，知道如何與他人合作以實現自動化測試，同時也擅長探索性測試。他們希望了解客戶在做什么，以此更好地理解客戶的軟件需求。