如下观点，只代表我个人观点，如有偏差，还望各位同行提出相应观点和意见。
如果网友看过我以前写过的文章，就能理解我如是如何理解定义测试的。
谁是测试团队中的核心技术人员
我个人认为对于公司测试团队中最重要的人是设计优秀测试策略和设计优秀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个小时才能读懂或不能完全读懂你的测试方法和测试步骤。那公司将会为这样的测试用例付出非常大的成本代价，甚至会影响测试计划的执行和产品的研发计划。
总结：对于部分迷茫的测试工程师，如果你希望在测试领域发展而不是在代码开发领域发展，就不要误认为只有代码才是高手，只有代码才是好的测试工程师。要做一个对公司有最大价值的测试工程师，就应该尽量往成为一个好的测试策略设计者和测试用例设计者成长和发展，但这一切工作又很依赖一个很基础的因素——工作的责任心，只有把公司的大局发展放入自己的心中，才能真正做好工作的取舍，设计出有价值的测试策略和测试用例。