软件测试人员一般要经历的几个阶段



一、执行测试用例

　　作为一个测试新手来说，最主要的工作应该就是执行测试用例，最基本的要求当然就是不能够出现执行漏测了。是的，达到这个要求毕竟简单，只要严格按照用例来执行就可以了，这里主要考验的就是一个测试人员的执行力和细心的能力。另外，这个阶段测试人员能够学习到自己测试模块的一些基本业务知识，以及如何去执行用例，提交和跟踪bug等等，这个阶段也很容易达到，甚至可能会跟第二个阶段一起进行，但是该阶段虽然简单却很重要

　　二、发现bug

　　经历第一个阶段后，这个时候测试人员可以开始在执行用例的基础上开始一些自己的发散测试（更好的叫法是探索性测试），来更好的发现一些通过执行用例无法测试到的bug。这个阶段就比较考察一个测试人员的发散思维了（个人觉得测试人员的发散思维恩能力是测试人员非常重要的一个能力，这也是软件测试的魅力所在），有的测试人员就是能够通过自己的一些想法来发现一些bug（甚至是隐藏很深的bug），并且很享受在其中。个人觉得这些能力（也可以叫对bug的敏感程度）是天生的，当然，并不是说这块能力不强的人在测试里面发展不好，因为测试也有技术（确定的因素）的成分，比如：自动化等。但是，这样的测试人员不太容易享受到发现bug给自己带来的成就感（即软件测试的艺术性）。当然，要达到这样的程度对于模块本身的业务逻辑也需要非常熟悉

　　三、保证质量

　　质量是一个测试人员的生命，当我们将一个功能模块交给一个测试人员负责的时候，我们肯定是希望对方能够给保证质量的。但是实际上要达到这个要求是很难的。首先，我们对于保证质量是如何定义的，是保证该模块到客户那里不会影响客户的业务还是在客户那里不出现问题？实际上两者是很难区分的，目前我们对于测试人员的要求大概都是能够发现所有的bug吧，虽然实际上不可能。其次，作为一个测试人员，我们自己对于该模块的测试策略该如何把握呢（因为测试时间是一定的）？根据个人经验，要达到这个目标，至少需要做到以下几点吧！

　　1、需求覆盖：对于的整个需求的理解程度：对于客户来说，为什么需要这个功能？主要是用使用习惯是怎样的？客户哪里可能会出现的一些异常情况等等

　　2、业务逻辑覆盖：对于整个业务逻辑的理解程度：通过看研发的设计文档和具体的实现逻辑图，来分析如何覆盖到所有的逻辑以及异常逻辑（这个时候还需要提前发现一些研发没有考虑到的地方），并且设计对应的逻辑测试用例，保证我们的测试业务逻辑的覆盖率（代码覆盖率非逻辑覆盖率）。当然，这个阶段是能够通过一些技术手段做的更好的，比如：接口测试、单元测试、代码的静态走读等等，后面再讨论...

　　3、性能压力覆盖：主要是在前面对业务逻辑非常熟悉的基础上，对于每个业务逻辑的性能测试点进行分析，看下这些逻辑是否可能有压力点，比如：当资源不足的时候是否有影响？当并发数或者流量很大的情况下是否会有影响？是否会涉及到多线程通信或者进程之间抢占资源等等，分析完成后还需要考虑如何去覆盖到这些地方（包括压力是否足够等等）

　　4、关联覆盖：大部分情况下一个模块总是会和整个系统的其他模块存在关联的地方，那么我们除了要分析出和哪些模块有关联，还需要分析具体的关联点是什么？这其实就要求我们对于与之关联的模块也足够的熟悉，这样才能够更好的分析到对应点上

　　5、当然，还会需要涉及到其他的，比如：模块的可靠性，安全性等等

　　6、发散测试：一般情况下，前面的几点很难分析到非常的全面和充分，这个时候就需要依赖自己的分析能力和发散思维能力了，如果这方面比较好的话应该是有意外惊喜的，而且前面的一些测试也需要依赖自己的发散思维能力