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个小时才能读懂或不能完全读懂你的测试方法和测试步骤。那公司将会为这样的测试用例付出非常大的成本代价，甚至会影响测试计划的执行和产品的研发计划。

　　总结：对于部分迷茫的测试工程师，如果你希望在测试领域发展而不是在代码开发领域发展，就不要误认为只有代码才是高手，只有代码才是好的测试工程师。要做一个对公司有最大价值的测试工程师，就应该尽量往成为一个好的测试策略设计者和测试用例设计者成长和发展，但这一切工作又很依赖一个很基础的因素——工作的责任心，只有把公司的大局发展放入自己的心中，才能真正做好工作的取舍，设计出有价值的测试策略和测试用例。

版权申明：本文出自cuittx的51Testing软件测试博客：http://www.51testing.com/?67485

本文全部版权归原文作者董杰全部所有，且第一次发布是在51testing，如果其他朋友或机构要转载请先得到原文作者董杰的书面允许，否则将诉诸法律。