對於軟體測試員（有的公司叫qa或質量控制員）而言，在不同的公司文化或體制下，往往對自己的職責或定位都會存在很大的差異，導致軟體測試員，甚至是公司管理員都存在疑惑： 軟體測試員是否真的有存在的必要？如何才能發揮他們的最大價值？
什麼是軟體測試的目的？問題不是很簡單嗎？但是，我相信仍然有不少人都不一定能夠答對。做事沒有目標，就會像無頭的蒼蠅，到處亂撞。船在海中行駛，不能沒有燈塔（現在或許有導航儀了，^_^），軟體測試，也不能沒有目標。對於軟體測試員，你執行測試的任務，要達到什麼目標？對於管理者，你招收軟體測試員，用他們來幹什麼？要他們發揮什麼價值？
下面就是軟體測試的目標層次，看你達到了哪層？
第一層：軟體測試的目標就是發現軟體產品是否存在bug（缺陷或錯誤）。
第二層：軟體測試的目標就是檢驗軟體產品是否滿足終端使用者需求。
第三層：軟體測試的目標是保證軟體產品如期按需按質交付，保證產品的商業成功，獲取最大利潤。
下面我簡單分析下各層次的狀況。
如果你在第一層，你應該是初入測試行業的菜鳥，不錯，就是菜鳥，不管你是否樂意接受。軟體測試不僅是發現錯誤，還有使用者需求（包括行業或操作慣例等隱性需求，例如預設 ctrl + c 是複製，若你的文字編輯器非要用它實現關閉程式，那只能留著自己用了）
如果你在第二層，應該在測試行業工作了幾年，知道站在使用者的角度去驗證產品了。保證產品能夠滿足使用者需求，離成功已經不遠了，作為測試員，你也已經盡力了。
如果在第三層，你已經跳出了測試員的束縛，能夠用管理者的眼光來審視軟體測試，至少有幾年工作經驗或者管理者思維了。這個層次，測試已非測試，測試和開發不分彼此，都是為了產品的商業成功而努力。
這個就沒有統一的答案了，具體問題具體分析，沒有放之四海而皆準的銀彈。不同的公司（資源，人力，物力，財力等），不同的文化（保守，進取，激進，誠信，嚴謹，虛偽，欺詐等），不同的產品（移動嵌入式，伺服器端，web前端，桌面應用，單使用者，多使用者等），不同的產品階段（預研調研階段，需求階段，開發階段，後期收尾階段，維護階段等），所使用的測試方法策略都是不一樣的。這麼多因素組合在一起，你就知道為何同樣是做測試，換個公司或者部門，感覺完全顛覆了你積累的「測試觀」，這個是正常現象，如果都是千篇一律，那才怪呢！
1. 引入自動化測試：對於伺服器端要求穩定性高，軟體生命週期長，軟體需求變化不大，測試用例巨大，操作繁瑣易錯等場景，引入自動化測試是明智之舉，絕對是「磨刀不誤砍柴工」。有些公司領導摳門，認為自動化測試開發周期長，自動化測試人員薪資要求高，不捨得投入人力，財力和時間， 只顧眼前利益看眼前成果，匆忙讓手工測試佔主導。當後續隨著測試用例的增加，執行週期越來越長，想搞自動化測試，已經來不及了！
2. 引入持續整合體系：對於採用敏捷開發的團隊，持續整合必不可少！甚至可以說，持續整合做到什麼程度，敏捷開發的成功就是它的程度。試想一下，若無持續整合，每天提交編譯的**，誰能保證能夠執行正常？
3. 產品資訊要公開明確：此處的產品資訊包括產品需求（user story，效能要求，環境要求，相容性等），發布計畫（包含週期，里程碑，rc，ga等時間點），測試資源（人力，時間，裝置等）。有些公司為了所謂的保密，產品需求不給測試人員看（甚至普通開發人員都沒權看），導致最終的產品不能滿足使用者需要，這種情況你還真不能怨測試人員。資訊公開明確，便於制定計畫，知道哪些測試點，需要多少時間和人力，統一協作（這也是團隊精神的體現啊），上下齊心，才能最大限度地保證產品成功。
4. 開發與測試本不分彼此：開發與測試人員，根本不是矛盾和敵對的團隊，而是相互依存分工不同的乙個團隊整體。如果開發與測試團隊矛盾重重，一般都是體制獎罰的問題（例如以缺陷數來考核測試和開發的績效，發現bug多，測試的功勞，開發的汙點，反之亦然。），需要管理者深思變革考核機制。純粹以**行數，製造和發現的bug數或嚴重度來考核，真的是很失公允的考核方式，而且會造成開發和測試的矛盾，影響團隊的團結。最佳的考核，應該是以專案是否成功來同時考核開發和測試，與公司其他產品比較考核，讓大家榮辱與共，大家就團結了（區域性團結，有可能會造成所謂的」部門牆「，但總比內訌強很多了）。
5.手工測試和自動化測試相輔相成： 手工測試和自動化測試，就像開發和測試，魚和水一樣，不可分離，相輔相成，才能達到最優效果。
對手工測試的誤解
對自動化測試的誤解
對於自動化測試，有人愛有人恨。有人認為自動化測試是萬能的，什麼都要實現自動化測試（ui布局，視覺感觀等）；有人認為自動化耗時費力，寫自動化的功夫，手工測試都已經做完好幾遍了。這些認識都是片面的。自動化測試不是萬能的，但沒有自動化測試，是萬萬不能的！對於長時間的壓力測試，重複成百上千遍的測試，自動化測試的優勢就明顯了；但是對於只是ui介面變化很快或者只是一次性測試的場景，還要進行ui介面錄製或編寫自動化用例，就得不償失了。
總之，手工測試和自動化測試，要把握乙個度，因地制宜，根據產品的特性等方面，進行綜合規劃，才能達到良好的效果。手工測試是為了發現bug和驗證是否滿足使用者需求，使用者體驗是否良好；自動化測試是為了回歸驗證，或者彌補手工測試無法勝任的工作（成千上萬的併發操作，持續7*24小時操作，大容量和吞吐量測試，低時延驗證等）。兩者各有所長，不能顧此失彼，有個微妙的平衡關係，就看管理者如何把握了。
這裡的管理者，指測試組長，測試經理，產品經理，公司總裁等能夠支配或影響測試人員的管理者。若管理者制定以發現bug數為重要指標，大家就會拼命發現bug，甚至不會放過任何錯別字。別高興太早，這有可能造成揀了芝麻丟了西瓜的局面。既然以數量為指標，估計沒人願意去發現長時間執行造成的記憶體洩露問題，大併發量造成的響應延遲或拒絕服務等缺陷，因為這些bug發現費時費力，還不如提提錯別字或者ui布局來得實在。
所以，要想最大限度地發揮測試人員的價值，管理者提倡什麼，大家就會做什麼。作為管理者，應當提倡大家創新，改進流程，提高效率，讓大家皆大歡喜，而不是讓大家每天苦著臉麻木機械地執行測試用例，活幹不完就要求大家沒日沒夜地加班。如果是那樣的話，作為管理者，你是在扼殺人才，浪費公司資源，而且你將會面臨大量員工流失的問題，最後導致無人幹活，進行惡性迴圈。
作為測試人員，特別是有思想有抱負的測試人員，無論面對什麼局面，你在投入執行測試任務之前，一定要想想能否通過開發工具來減少重複的勞動，磨刀不誤砍柴工。哪怕一條case提高一秒，100條case也能夠提高100秒，你就可以少加班100秒，減少電費100秒，自己支配的生命多了100秒，日復一日的話，又節省多少呢？想想吧，多划算啊^_^
軟體測試，不是凡人眼中的」沒啥技術含量「，它是軟體工程中的一部分，不可或缺。沒有萬能的軟體測試方法，只有最合適自身的測試策略和手段。無論採用什麼方式方法，別忘了我們的最終目標：取得產品的商業成功！軟體產品在商業上不成功，神馬流行的高大上技術（雲計算，機器視覺，人工智慧，大資料分析等等）都是浮雲，當然嘍，純粹搞科研的不在此討論範圍。
軟體測試人員如何提公升自身價值？
軟體測試的真正價值並不體現在 中找出了多少缺陷，而是發現設計和程式設計人員解決問題方法上的侷限，思路中的狹隘的技能方面的不足。托尼 霍爾 前段時間在管理層的年度覆盤會議上，提到了員工績效考核的事情，績效考核也是乙個老生常談的話題了，畢竟任何乙個公司的晉公升加薪或培養人才都要經過考核。那考評結果多數不...
如何讓ERP發揮它應有的價值？
在論證erp的價值時，erp給企業帶來的最大希望就是，從公司接到訂單直到訂單的完成這個過程中，erp可以起到很好的促進作用。這也就是我們為什麼稱erp為後台系統的原因。在接到一張訂單後，erp會根據系統的流程在訂單履行的不同階段實現一些自動化的處理。當乙個客戶服務代表往erp系統裡輸入一張訂單資訊後...
讓測試人員參與軟體設計
專案測試過程中我們的任務也許僅僅只是找出bug，但是對於bug產生的本身可能並不關心，因為績效考核只關心bug的質量和數量，所以使得我們測試人員的眼光變得很狹隘，甚至可以說是膚淺。最近在接手乙個專案測試任務時，發現我們的工作是如此的單調，而且不愉快，原因在哪兒呢，大家一致總結是因為沒有需求，或者說有...