如下觀點，只代表我個人觀點，如有偏差，還望各位同行提出相應觀點和意見。
如果網友看過我以前寫過的文章，就能理解我如是如何理解定義測試的。
誰是測試團隊中的核心技術人員
我個人認為對于公司測試團隊中最重要的人是設計優秀測試策略和設計優秀ROI（ROI：投入產出比）測試方案的測試工程師，當然自動化測試腳本開發工程師和測試工具開發者對于測試部也是非常重要和不可或缺的。
為什么我認為測試部最重要的人是測試策略和測試用例的設計者？
首先從相關人才的來源來分析：
自動化測試開發工程師：可以由只畢業3－4個月或才進入項目1－2個月的工程師就能從事。測試工具開發：甚至不需要對測試了解多少也能從事。而設計測試策略和好的測試方案設計者則需要至少2－3年的相關業務黑盒測試經驗的工程師，才有可能做好。
其次從相關人才發揮的作用分析：
測試策略的制定就好似公司的市場部要制定大的市場戰略。例如：這個測試方案的定位是什么？這輪測試的目的是什么？有多少資源可以進行測試？應集中資源先對哪些重要又緊急的功能進行測試？如何區分重要或緊急的功能？如何安排緊急而不重要的功能與重要而不緊急功能的測試順序？等等......
測試方案的設計：就好似公司的銷售部針對每個具體的客戶制定具體的銷售計劃和銷售方案。例如：對于這個case我們的目標期望是什么？如何達到這個目標？是否還有更好的方法來達到這個目標？如何利用現有的有限資源取得最大化的結果？這個case的ROI是否高效？而測試工具的開發和自動化測試腳本的開發則類似于公司中的研發部，提供必須的高效武器與公司市場部，銷售部一起攻城拔寨。
如何成為一個合格優秀的測試策略的設計者呢。我的觀點是：
1：一切測試策略的目的是什么？是為了滿足公司市場銷售策略。因此我們應該設法保證測試策略既能按期完成研發計劃，又能不影響銷售的產品質量。
2：將有限的資源先用到緊急又重要的測試任務中，再評估其他任務的優先級。但一定要以市場銷售計劃為依據。一個脫離市場銷售的測試策略是一個誤國誤民的策略。
3：測試策略不是測試計劃。我的看法是：以市場銷售計劃為依據，先制定測試策略，再按任務的優先級和資源情況來制定測試計劃。現在常有不少朋友誤認為測試計劃就是測試策略，測試策略就是schedule
時間表；計劃表；一覽表，這種觀點我個人并不認同。
4：測試策略不是一個人設計出來的。它一定是先聽取了市場人員的意見和要求，再結合研發的要求得出的一個平衡取舍的產物。
5：好的測試策略設計者是一個以公司利益為第一位，而不只局限在測試部門利益的員工。辦公事政治玩多了，設計的測試策略有可能就是一個對公司利益有害的策略。
6：一定要最大化的接近客戶的真實應用來定義重要的模塊功能，而不簡單依據模塊的復雜度來定義。
7：能知己知彼。對自己的測試資源有多少，要有準確清晰的認識才能知道量體裁衣。而不要打腫臉撐胖子，最后實施時，卻完成不了測試策略。
接下來，如何成為一個合格優秀的測試用例設計者。我的觀點是：
好的測試用例至少要滿足如下要求：（這里只討論功能測試用例的要求）
1：粒度一定要細，對功能需求中的每個小點，每個數據都要覆蓋到。并盡量多的想到更多的測試方法來對被測試項進行拷打。
2：測試方法不能過度測試。大家容易想到測試不充分對公司有害，但往往會忘記過度測試對公司也是有害的，這點在我的測試經歷中感受非常深刻。例如：因為你的過度測試，浪費了你的有效測試時間，這個時間原本是可以拿來發現更多真正有意義對銷售有影響的bug。因為你的過度測試發現的bug，開發人員有時必須為這些意義不大的bug花時間來修改，浪費了修改其他更有意義bug的時間，影響了項目的進度，影響了產品的銷售計劃。說不定公司甚至因為你的幾個過度測試，延遲了1個月推出產品，導致公司在這1個月中損失1億的訂單。而這些都是真正有可能發生的。所以，要避免在不漏測的前提，走向另一個極端－過度測試。
3：你的測試用例是否容易轉化為自動化測試。如果你在進行測試用例設計時，根本沒有把將來進行自動化測試的開發做為一個考慮因素。那么，你的測試用例永遠只能用手工進行回歸測試，將大大浪費公司的資源并影響產品發布時間。如果回歸測試的手工執行是你自己來做的話，那么以后你的苦日子可就長了。
4：測試用例應該考慮執行時資源和時間的安排。例如：千萬不要出現有的test case執行完一遍只需要1小時，有的test case執行完一遍卻需要20個小時。為了便于測試管理和計劃安排，應設法讓測試用例未來執行的時間保持在一個參考值左右。假設一個標準test case的執行時間為4小時，那么設計的test case應盡量保持在3－5小時內。這樣非常容易量化并管理測試用例執行者的工作，更有利于測試計劃的安排，測試策略的制定，研發計劃的按時執行。
5：理想狀態下，最好你的測試用例也要有好的易讀性。例如：test case的執行者拿到你的case后能在半小時或1個小時左右就能讀懂并執行。否則，如果執行者還需要4－5個小時才能讀懂或不能完全讀懂你的測試方法和測試步驟。那公司將會為這樣的測試用例付出非常大的成本代價，甚至會影響測試計劃的執行和產品的研發計劃。
總結：對于部分迷茫的測試工程師，如果你希望在測試領域發展而不是在代碼開發領域發展，就不要誤認為只有代碼才是高手，只有代碼才是好的測試工程師。要做一個對公司有最大價值的測試工程師，就應該盡量往成為一個好的測試策略設計者和測試用例設計者成長和發展，但這一切工作又很依賴一個很基礎的因素——工作的責任心，只有把公司的大局發展放入自己的心中，才能真正做好工作的取舍，設計出有價值的測試策略和測試用例。