希望閱讀本文的朋友是做過測試並有一定經驗的，不然，你明白我說的什麼意思，但你對本文並不一定深有體會。
這其實是個有趣味且值的問題，包括經常跟測試人員打交道的開發人員，甚至測試人員自己都沒弄清楚自己職位到底該如何的定位。當別人問人什麼是軟體測試時？ 噢！等等，我翻翻書，「軟體測試是通過一定的測試方法和工具發現軟體的中的缺陷從而來提高軟體質量。」
噢？測試發現軟體中的所有缺陷麼？不能！
噢？測試真的可以提高軟體質量麼？這個還真不敢保證。
詢問者輕蔑的的走開了，處於禮貌，他們可能沒有笑出聲來，但他們的眼神已經告訴了測試人員答案，測試是個可有可無的工作。留下測試員非常的窩火，但貌似真的找不出非常有力的證據，來證明自己的存在「不可或缺」和「不可代替」的價值。
軟體測試人員接受專門的培訓來發現並報告問題，他們通過發現和報告軟體的異常問題和存在的風險，進而幫助公司、開發團隊、客戶和終端使用者。
那麼我們可以把測試人員比作警察嗎？在軟體開發過程中並沒鐵定的「憲法」，他們並不能依照「法律」是去「逮捕」任何人，儘管軟體開發的世界裡完全可以制定出一定的法律。在法律的世界裡，一方受到懲罰，一定有另一方面受到的傷害。但軟體缺陷不是這樣，也許這個缺陷會造成巨大的傷害，也許一定傷害也沒有。也許我們的「法律」根本無法評估乙個的傷害到底有多大。
好吧！既然不能做警察，那來做法管好了，讓測試人員來做「質量把關人」。這其實操作起來很困難，也不太公平。所謂「質量把關人」，就是在軟體發布前將該軟體看做乙個商品。由測試人員來權衡風險、必要性、市場需求和成本開銷。噢！測試人員的高度不夠，評估和承擔風險其實是專案管理者或公司管理層的任務。
到後面可能測試人員已經拋棄了測試人員的本質工作（發現並提交問題），而是花費大量的時間在權衡和評估每乙個問題。其實，測試人員清楚地知道不客發現和解決多少問題。軟體**裡總是還潛伏著一些問題，所以，他們一般不太情願蓋那個質檢合格的紅印。這就是說等「質量把關人」去確定產品合格，可能要猴年馬月了。
測試人員其實更願意做偵查取證小組或驗屍法醫。他們只提取證據。接下來的你們看著辦吧。
好吧！軟體測試人員的工作遠不至這個，以下任何要求都可能決定測試人員的使命，你（測試人員）期望的是哪種要求？
快速找出重要的軟體問題
對產品質量提出總體評估
確認產品達到某種具體標準
幫助客戶改進產品質量和可測試性
保證測試過程能夠達到可分清責任的標準
幫助**和控制支援成本
幫助開發人員完成測試工作
參與需求並從測試的角度提高軟體的可測性
為滿足特定客戶要求，完成所有必要的工作
對於測試人員來說這太囉嗦（複雜）了，他們只是單純的喜歡找缺陷（bug），並像探秘一樣的把缺陷定位出來。這就像好玩的尋寶遊戲。沒人事先知道答案，這樣對測試人員來說才是有趣的挑戰。
好吧！為了完成這項有趣的挑戰，測試人員應該具備什麼樣的特質呢？
首先要有好奇心，想弄清楚事物是怎麼執行的；其次喜歡動手試驗，想知道嘗試使用功能演示時不同的使用者場景和試驗會發生什麼。
再次，需要一點膽大精神，不害怕會破壞什麼東西，不管你有多位高權重，他們也不害怕把發現的事實告訴你，他們更不害怕站出來據理力爭，一定要把他們相信可能影響到產品成功的問題解決掉。
善於分析，善於學習，事實上，測試人員一直在學習，他們的工作性質要求如此。技術總是在變化，接到的每個專案或多或少跟上乙個專案不一樣。有時候有很好的文件，有時候卻沒有，必須問出正確的問題，研究正確的問題，把謎題的各個碎片聯絡在一起，然後得出正確的結論。
當然，測試人員也有不好的特質，尤其對於那些經驗豐富的人為說，不容易信任人，這是從實踐中歷練出來的，別人總是告訴他們模組x不需要測試，或**y「沒動過」，這種資訊錯的數多到數不清了。所以，就算你告訴測試人員草是綠的他們也要親自過目才敢相信。當然了，不是所有的測試人員都具備這些特質。好吧！也許你做測試是為了乙份穩定的工作來生活。也許你不是「真正的」測試員。
只懂執行其他人測試想法的人，不能算是乙個真正意義上的測試人員。當乙個測試人員執行一大堆已有的測試用例時，容易心生厭煩。可能會快執行這些測試，只是想讓他們從眼前消失，這意味者他們可能不會非常關注執行的測試，當然也就不能像認真徹底的執行者一樣找出某些問題。
很多測試人員覺得單調乏味而不屑執行回歸測試，雖然大部分測試員都理解甚至同意回歸測試的必要性。
乙個「真正的」測試人員一定會把這些已有測試看作自己的職責範圍，重新考慮其中的想法，提出問題，充實和改變測試，**原來的分析沒有考慮到的地方。如果原來的分析實在很棒，尋阿能他們也找不出來太多可有更新充實的內容，進而增加了無聊指數。
雖然，看到這個結果會打擊測試人員的積極性，但這是真的。最有經驗的的測試人員會同情地拍拍你的肩膀說：地球人都知道事情不僅僅是發現問題那麼簡單。他們也會充分理解、會力支援你的決定：問題a、b、c 可以不解決，並不會有人對這樣的決定怪罪你。擁有多年工作經驗的測試人員會說出大家都愉悅的意見，因為他們從這家公司的專案經驗中學乖了，知道這樣會給他們（以及他們部門）帶來最好的質量結果。但是需要記住，他們之所以肯犧牲問題a、b、c ，很可能是為了說服你解決更嚴重的問題d 和e 。當然，大多數測試員是希望發現的所有問題都能夠得到處理，現實總沒希望的那麼好。
所有的測試人員都會告訴你，缺陷是存在的，然後缺陷就真的存在了。一般來說，讓事情變得好玩並非缺陷的數目。比如乙個測試人員可以在大的**應用程式中發現上千個表面錯誤，就是語句與錯別字，給使用者看的文字有語法錯誤，圖示上的顏色不對，或都螢幕上有東西位置放得不對。
測試人員非常討厭這樣的錯誤，特別是發現有很多的時候。因為記錄這類錯誤比發現它們所花費的時間更長。而且他們一般屬於低優先順序，很容易得到解決。對！測試人員就是**的喜歡讓開發員束手無策的問題，這樣似乎更能體驗他們的能力與價值。
在it領域經驗豐富的前輩會告訴你，某個應用程式的終端使用者可能會對你覺得微不足道的問題深切關注。這跟人的「煩惱因素」有很大關係，乙個錯別字或字型用得不恰當可能不會影響使用者的使用，專案組的所有人都認為這是個小問題。但是對於每天要看兩千遍的使用者來說，「煩惱因素」是非常高的。
例乙個雙擊滑鼠就可以完成的操作，我設計成了三擊，只是多點了乙個滑鼠而已。這也許有趣，但對於每天操作幾百遍的使用者來說，他會破口大罵地拿起滑鼠甩到地上。這太令人討厭了。這影響的他們的工作效率，也行效率與績效、獎金掛鉤。
測試人員報告他們發現的一切問題，其中經驗豐富的人員會根據其理解來報告嚴重程度，但一般來說不要試圖**業務優先順序。他們理解中的業務優先順序通常就像開發團理解的一樣，是不太完整的，並不是基於使用者的個人體驗做出的。經常有使用者願意「將就」使用有嚴重錯誤的**，卻在最後一刻強迫要求修改或新增看起來並不重要的東西。
測試人員的工作是尋找、發現、報告，而不是用神一樣的能力去評判，測試人員應該隨心所欲的提供他們的專業意見，事實上，專案組的所有人都應該隨心所欲地提供專業意見。
有乙個令人遺憾的現實，那就是測試人員不將他們發現的所有錯誤報告出來。原因可能有很多，但最常見的是他們覺得報告某一種或某一類錯誤沒有意義，因為反正都不會被解決的。這是從實踐中「學」來的，你通常會發現有這類態度的測試人員不抱幻想、厭倦、憤世嫉俗、對工作不感興趣。他們報告缺陷的興趣和熱情已經被工作環境慢慢消磨掉了。另乙個原因也許是他們相信從政治上和實際上來說，報告他們發現的一切東西是不「聰明」的，他們應該只報告那些公司在乎的東西。那麼，如果公司看不到整個大局，怎麼知道在不在乎呢？每個人都明白很多錯誤是不能（或者從財務的角度來說不應該）在產品發布前解決的。成功專案管理的「藝術和工藝」的乙個要素是對推遲和解決哪些缺陷做出正確的決策。比如，專案組決定解決1 4 個缺陷，推遲另外3 2 個。但是測試人員選擇不報告3 2 4 個缺陷，因為開發團隊「從不解決」字段錯誤，這意味著專案經理和上層的管理者正在根據錯誤、不全面的資訊作決策。在這個例子裡，使用者介面就不能在萬眾矚目的**時段隆重登場。
另外，就算是在乙個並不解決某類錯誤的公司，報告每個錯誤也可能會最終改變公司的政策（或稱之為「一直實行的陳規」）。如果乙個測試人員報告了4 0 個錯誤，乙個都沒解決，應用程式就發布了，然後使用者以緊急的優先順序報告同樣的錯誤並要求盡快地解決它們，那麼開發團隊和專案經理以後就會開始注意這類缺陷
好的測試人員同時是富有創造力和想象力的。測試通常是乙個破壞的過程，正因為如此，在正式產品環境下執行測試需要非常謹慎的決策。好的測試人員不必試圖證明軟體執行正常，他們是來證明軟體不能正常執行的。這一態度差異是測試人員能發現如此多缺陷的主要原因，他們就是想發現缺陷。他們分析手上所有的資訊，坐下來思考怎麼才能破壞應用程式。專案組裡沒有其他人有這樣的使命。開發人員一般甚至沒有足夠的時間持續寫**，更不要說試圖擠出足夠的時間來想怎麼破壞**了。終端使用者通常只是執行日常工作的操作，如果有東西「壞掉了」，他們可能陷入恐慌和沮喪之中。另一方面，只有測試人員勇敢地參與進來，使出**的勁兒去發現軟體中的缺陷，他們卻為發現另開發人員痛苦的缺陷而興奮不已。
這正好應驗了媽媽一直告訴我們的話，要是你只盯人身上壞的一面，那你就只能發現壞的東西。測試人員全面地盯著系統**錯的一面找問題，順便也就檢驗了執行正常的部分。但他們關注的焦點總是向著錯的東西，而不是對的東西
很久之前，就有關於測試人員的角色的爭論，我們再來總結性的說說測試角色的本質。
一些人認為測試人員的角色是保證質量，如果有人能決定到底「質量」指什麼？ 這個似乎很難說清。
另一些人認為他們的角色是通過訓練開發人員的尋找缺陷幫助他們編寫出更好的**----在開始編寫的時候就不存在錯誤的編碼；
還有一些測試專家集中精研究為何以及如何找到缺陷：在不同的環境下尋找缺陷所涉及的策略、技術和術語。
所有這些說法都很有趣，在某種意義上都是對業界有溢的。但是，從本質上來說，測試的意義就是發現缺陷。測試人員通過專案組和管理層展示缺陷、問題或瑕疵「保證質量」，進而幫助他們做出更好的決策；他們通過向開發人員展示其**中的錯誤，使其知錯就改引以為戒，進而幫助他們改進工作；他們學習新的策略和技術以便發現更多的（或者更重要的）缺陷，他們把工作歸類到新的策略裡，如遊歷式，進而幫助 其他人發現缺陷。如果在測試過程中沒有發現（或者只發現了很少的）錯誤，那麼這也是重要的資訊。
注：本文內容取自《測試之美》第1章 「這對你有好處麼」，這是一本很好的書，讀完第1章收穫頗多，但正如不少人說話，作者寫得太散了，沒有條理。好吧！我把這一部分的精彩抽取出來與各位分享。
程式設計師的生活你不懂
做為乙個程式設計師，沒有誰能說比自己更了解程式設計師的生活是什麼樣子的了，每個程式設計師都有自己的理想，可是除了那台破電腦還有什麼陪伴呢。如果你要準備做程式設計師了，那麼在你大學畢業前一定要把妹子把到手，不然你上班了就剩下好 了 程式設計師幹了好幾年了還沒物件？笨啊，你在大學幹什麼了啊，當時是不是就...
寫給測試員的話之測試手段（二）
測試員應該做什麼，除了我們所說的觀察和學習思考，接下來我們談一談測試員應該知道的測試手段有哪些？書中提到了一種測試手段的分類系統，叫做 五要素測試系統 five fold testing system 主要有 測試員 覆蓋率 潛在問題 活動和評估。測試任務常常按乙個要素分配，但是完成任務要涉及所有五...
武裝你的測試
武裝你的測試 陳能技2007 8 23 原文 boost your testing super powers secret tools to add to your utility belt james bach 當我還是3歲的時候，我最喜歡的 片是 the fantastic four 當我的媽媽...