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