设计测试策略,测试用例

测试策略的制定：就好似公司的市场部要制定大的市场战略。

例如：这个测试方案的定位是什么？这轮测试的目的是什么？有多少资源可以进行测试？应集中资源先对哪些重要又紧急的功能进行测试？如何区分重要或紧急的功能？如何安排紧急而不重要的功能与重要而不紧急功能的测试顺序？等等。。。。。。

测试方案的设计：就好似公司的销售部针对每个具体的客户制定具体的销售计划和销售方案。例

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