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