测试这行的客观规律总的来说是：入门容易，提升难。 有些人干测试8－9年了，其针对同一个产品的测试思路和方法，与干测试只有2－3年的人看不出有什么区别。于是行业中有了一种误区，认为测试技术的提升主要集中在对性能测试工具的使用及脚本开发，自动化测试开发，测试工具开发领域。仅个人愚见：测试工具开发和自动化测试开发 主要还是开发技术而不是测试技术，从没有做过测试分析，测试设计的开发人员也能胜任。如果仅狭义地认为测试技术的发展只在自动化测试框架开发或测试工具开发上，那么从逻辑上来说，任何一个开发人员都可以成为测试技术大拿。当然我想：没有人会真正这么认为。

　　就其我的感受而言，开发工作有时反而会简单一些。为什么呢？开发工作的目标从一开始是非常明确的，要实现什么要做什么做到什么程度大多数情况下都是清晰的，最大的困难则是如何实现如何做到，总的来说是一个不断聚焦的过程。而测试工作的目标呢？其实很多时候，并不如开发那么明确，例如：同样一个性能指标，开发很清楚要通过实现XX算法来达到目标；而测试则需要对该性能指标先进行测试分析，再进行测试设计，可是测试分析做到什么程度却是一个发散的过程， 2小时也可以，2天也不够，这就导致了测试质量的浮动范围是非常大的，由于开发和项目经理通常对测试设计并不了解，也无法了解（测试其实是一个专业度非常高的领域），因此会导致测试部的工作质量很难在过程中真正去度量和监督。

　　从哲学上来说：确定性的规律往往难度不大；不确定性的规律往往说明它是一个复杂系统。因此，我个人认为：测试技术领域最难的技术应该是测试分析和设计。从另一个角度来看，测试价值的体现最主要还是保障自己组织开发的软件在关键应用时不要出故障，给组织造成商业损失。所以，有效的测试覆盖率是最重要的测试工作目标（而不是自动化测试率），需要说明的是测试覆盖率不等于代码覆盖率。通过单元测试达到代码覆盖率100％了就能保障产品无bug其实是一个误区，因为很多组织会为了达到单元覆盖率而去开发单元测试代码，单元测试代码或单元测试设计的质量只能保障消除产品编码的问题，发现产品设计的问题则往往会很困难。而发现产品设计问题的最主要方法还得需要基于黑盒的测试分析和设计。

　　如何做好测试分析和测试设计，根据我的经验和体会，建议测试分析和测试设计主要通过3个维度来做，则可以大致达到一个比较高的有效测试覆盖率：

　　维度一：从用户实际使用的场景和习惯入手，开发一批测试用例；

　　优点：  可以覆盖到主要基本场景；

　　不足：  从事场景分析的人无法做到了解用户所有的场景，必定受参与测试分析资源限制会有场景遗漏；

　　维度二：通过测试对象内部实现流程的路径及依赖关系分析入手，开发一批测试用例；

　　优点：可填补维度一的部分遗漏场景，特别是异常处理和分支交互处理的场景；

　　不足：分析阶段主要精力会被局限在内部流程的熟悉和分析中，从而也会遗漏真实环境中的一些偶然小概率事件；

　　维度三：依赖基于经验的测试分析和设计，例如：错误猜测法或探索性测试法；

　　优点： 给维度二再做一次补充测试分析和设计；

　　不足： 维度三效果的质量高低取决于组织内部经验的积累量及测试人员思维的发散能力和创造性；

　　总得来说：无论是功能测试还是各种专项测试，依次使用以上3个维度的测试分析和设计，基本上能覆盖到被测对象的绝大部分应用场景，充分保障产品质量，减少问题遗漏。

　　因此：测试的核心技术是测试分析和测试设计的能力，它决定了后续所有测试活动的质量及效果。同时，要做好一个测试任务，掌握广泛的测试类型也是必要的核心技术，如：如何给每个测试对象做细做深压力测试，长时间测试，健壮性测试也是决定项目测试质量的关键所在。我本人不相信随便做做的压力测试设计和健壮性测试设计能够保障产品实际应用表现良好。

　　测试活动的质量或者一个测试工程师技术水平如何将主要取决于：测试分析和设计的深度及系统化，以及掌握广泛的专项测试类型。

　　一家之言，仅供参考，欢迎大家继续讨论。

版权声明：本文出自架构师Jack的51Testing软件测试博客：http://www.51testing.com/?293557

原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。