軟件測試是軟件研發過程當中必不可少的環節，中培偉業《軟件自動化測試與持續集成實踐》培訓專家陸老師指出，要做好軟件測試，首先就需要理解軟解測試的內涵。對于軟件測試的認識，陸老師認為應該從以下幾個方面著手。

首先對于軟件測試和軟件開發的關系問題，首先要說明的是測試需要懂一些軟件開發方面的知識，而這些軟件開發知識里面最重要的又是數據庫和SQL，結構化編程和腳本語言，這些是測試人員上升到一個新高度的重要內容。可以是軟件開發轉入測試，這個時候強的是軟件開發方面的知識，但是若的是對業務和需求本身的理解，同時也容易卷入程序員的固有思維而不能從客戶的角度來看待問題；也可以是先從測試和業務熟悉做起，后面逐漸需求一些開發方面的知識，包括數據庫SQL和腳本語言，但是往往沒有真正做過開發又很難理解結構化編程的一些基本規則。這里面都存在一個轉換問題，都需要自己在這個轉換的環節多去思考，轉變思維，多多總結。

其次測試最核心的內容是什么？做軟件測試需要時刻的提醒自己來思考這個最重要的問題。軟件工程書里面我們學過來，測試最重要的就是找出至今為止別人沒有發現的Bug，找出盡可能多的有價值的問題，以最大限度的降低的缺陷泄露和現場故障。這個回答本身沒有問題，不過我們還需要做一些更加深測試的思考，特別是做了測試一兩年后更需要不斷思考，測試的核心和關鍵點究竟在哪里？

在這里我想談兩個比較重要的核心內容，一個就是拿到一個大的系統或復雜的業務功能后，這個時候第一個核心就是根據需求規格說明書進行測試分析，而不是一下切入到了測試用例和測試設計，測試分析的目的是讓測試人員真正的理解需求和業務場景本身，測試有個重要的概念是測試場景，而測試場景則來源于需求場景。做測試分析的目的就是根據需求和業務流程梳理清楚我對整個測試流程的總體規劃，搞清楚對于復雜的功能如何按一定的方法系統性的開展測試，如何更加有效的設計測試用例，如果加強測試用例和測試數據的復用，測試用例對需求和業務場景的覆蓋等諸多問題。

如果你還不能去考試測試分析，說明還在測試的一種初級階段，完全照搬著需求規格說明書的測試用例是無法帶來很好的測試效果和效率的。第二個重要內容要談的是測試用例的設計問題，一條測試用例涉及到編號，名稱，對應的需求點和業務規則，前置條件，測試步驟和預期輸出和優先級等諸多內容，那帶來的一個重要問題就是測試用例本身的核心是什么？

其實這里我想指出的則是通過前期的測試需求分析后所規劃的測試數據的準備問題，而測試數據準備的方法則來源于我們常說的黑盒測試場景方法，如等價類劃分，邊界值設定，因果分析等，這些都是為測試數據準備服務的，沒有準備的測試數據預期的測試輸出往往是一句空話，有了預先準備的測試數據測試的過程才是有計劃和有目的的，真正準備了測試數據的人才談得上在真正系統的使用各種黑盒測試方法。系統的規劃和準備測試數據是系統化的進行測試用例的靈魂，你考慮了這點才會發現到，需求里面啰嗦了半天的內容往往僅僅需要1-2條測試用例概括即可，而需求里面只有一句話的業務規則往往則需要準備上十條甚至更多的測試用例來進行測試。如果在測試用例的設計上考慮到了這些問題，基本表示對業務深入理解和對測試方法已經靈活應用了。

最后談下成為一個優秀的測試工程師，首先你要轉變思維，你代表的是用戶，你是整個軟件產品或系統版本發布的最后一關，對你的評價只有一個就是從你手出去的產品到了用戶現場的缺陷情況，這是唯一的一個有價值的目標。如果連對自己的工作績效如何衡量都還不清楚，更談不上如何做好測試，因此對于測試我們會談到一個重要的外延就是質量管理方面知識的學習，質量管理基礎理論，質量管理七工具，6Sigma等都可能是測試中需要時常用到的方法和工具，需要去拓展這個外延知識，加深對測試工作本身意義的理解。

優秀的測試工作師不僅僅是測試方法和各種測試工具的熟悉，更重要的一點需要意識到的是對某個業務領域業務的深入理解，沒有理解無法做好測試，理解一些可以做單個功能模塊的測試，全面理解才可能做集成測試和系統測試，你對業務理解的越深，就越容易測試出各種業務規則方面和數據方面的問題，到了這種層次后SQL和后臺數據的查詢就必不可少的，基于業務規則的數據校驗測試是測試人員上一個新臺階的重要內容。