软件测试培训之测试赛需要开发的一些技能

软件测试培训之测试赛需要开发的一些技能

为什么说测试需要开发技能，测试策略和开发 技能到底哪个重要?

对测试来说，开发技能是基础。我特别不喜欢”代码能力不行就去做测试”这样的论调，别的不说，如果测试一点代码能力都没有，你该要怎么和开发沟通?完全不在一个频道上又何谈协做。

无论产品开发的方式如何演进，用户对产品质量的期望都是客观存在的。质量=符合要求，而探索和评估质量最有效的方式就是测试，20年前如此，20年后还是如此。对被测对象的准确把握，是探索产品迷宫的罗盘，关键因素包括代码复杂度，开发的技能和经验准备度，需求的质量等。有了这些，就可以判断风险的所在，在把握失效规律和失效影响的前提下，有的放矢的来开展各种测试活动。而实际的情况却是，我们太缺少对被测对象的分析和思考，这让我们做了很多看起来必要实际却很低效的事情。

举一个回归测试的例子。如果开发修改问题改得非常好，我们的bug 99%都可以回归通过，那么我认为测试没有必要再做回归测试，因为投入产出比非常小。我们可以这样算一笔账，假设一个周期为两个月的产品有200个bug，测试人员一天可以验证10个bug，这就是20人天的工作量，这还不算回归测试中的测试设计或者是发散测试的工作量。我们完全可以把这个时间放在测试其他的更值得测试的地方，或者干脆把发布周期提前一周又为何不可呢。

所以，我个人认为，测试策略是测试技术中最核心的部分。测试，简单来说就是，测什么和怎么测，这都是策略的范畴。相比自动化、工具、测试设计等，测试策略往往更能更举足轻重地影响测试的质量和效率——测什么和怎么测决定了质量，实际也决定了效率。如果能在深入分析的基础上大幅度减少测试用例，测试效率提升一定比自动化还高。

然后再对最值得自动化的部分进行自动化，而不是为了自动化而自动化，测试效率又会大幅度提高。实际上，系统越来越复杂，我们总有分析不清楚的时候，如果自动化平台足够强大，我们多测试一些也没有关系，可以避免一些低级遗漏。所以，策略是重要的，但是毕竟是基于经验的，总会有不完善的地方，工具和自动化可以很好的补充。测试还没有达到科学或者工程定量的程度，但也不是只有少数人才会的艺术，而是一门基于经验，可复制性的工艺学科，只是还没有达到可以给出明确标准的批量复制程度。也正是因为如此，才更需要我们去做深入的思考和分析。

这个的确是个好问题，但我觉得很多会问这个问题的主要问题在于自己根本就没有怎么做过测试，跟风问题，对测试策略的理解太浅。在我看来测试策略其实已经是一个很高等级的词汇了，能做到这个根本就是屈指可数，其根本就和所谓的开发技能不在一个水平面上，所以不能去做一定的对比。行业中很多次拿出来对比在我看来就是大家的理解太过浅层次。

其次就来讨论下开发技能，这里的开发技能更多的其实指的就是看代码能力和写代码能力，现在行业里基本上都是考核写代码能力了。我们撇开所谓的自动化(因为在我看来，很多测试做的最多只不过是半自动化，远远达不到自动化的程度)和测试工具来讲，我们要了解一个复杂的项目的时候必须去深入了解其技术设计和实现，那么对于一个测试人员的研发能力就有着很高的要求。无论是代码能力还是架构思维都是为了能够更快的更准确的去理解被测对象打下扎实基础的，从而才能够制定出正确的测试策略。所以从我的理解上来讲，测试人员越往上走就需要越强的研发技能，否则只会依赖于PRD或者与研发鸡同鸭讲，最终只了解产品的皮毛。

最后来谈下测试策略吧，在我理解的测试策略并不是你掌握了一个很厉害的用例设计方法或者看看几个PRD，会写几行代码就能够制定出来的，测试人员制定一个真正的测试策略应该至少满足以下几点：

拥有不错的代码能力和架构思维

经历过大项目复杂业务，对业务有深入的理解

深入正确的理解PRD和项目架构

了解项目在企业中的定位

了解项目需要哪些团队来合作

测试团队目前资源分配的现状

等等

只有一个测试人员同时了解这些的情况才可能真正的去制定所谓的测试策略，所以无论我们说的研发技能还是测试用例设计方法还是沟通交流能力等等这一切都是制定测试策略的基础。对测试人员真正重要的就现在而言真的就是一个综合的能力，而不是单独的某一个技能。