软件测试从零开始之三：测试执行

  作为一个黑盒测试工程师，进入软件测试行业的第一件事情应该就是执行测试用例了。基本的工作内容大概如下：
1、已经有一堆测试用例了（一般情况下是别人写的），项目的测试经理或者项目经理或者项目组长或者自己的导师每天给自己一些测试用例，自己的工作就是按照测试步骤严格执行完成这些测试用例(当然，前面可能会给少量时间去熟悉下该模块)。
2、执行用例过程中发现bug，根据规定找相关人员确认后提交上去。
3、研发修改好该bug后，根据一系列的过程来回归该bug。
4、过程中进行一些发散测试。
5、完成后根据模板编写测试报告。
6、一个新的模块重复昨天的故事，而且可能重复的时间比较长。
 
  虽然这些工作看起来是很苦逼的事情，并且看起来没有什么技术含量，但是却是我们成为这个测试专家一个必须经历的阶段。重点是：我们如何利用好这个阶段，快速的积累好这个行业的一万个小时。
先说说熟悉业务对我们有哪些帮助吧。
l 对被测模块业务逻辑越熟悉，肯定越对自己负责该模块的测试有帮助
l 站在测试的角度去看设计，培养自己对代码设计的理解能力
l 能够自己制定测试策略和挑选用例，并且让项目经理或者组长更好的让对方接受自己的测试策略
l 过程中发现问题自己能够尝试去排查和定位，甚至告诉研发如何去修改--这是一件很cool的事情
l 通过用例来分析哪些模块的逻辑已经覆盖到了，从而实时把握模块的质量，对整个质量分析更加有帮助
l 培养自己分析问题的能力，这对测试工程师是很有帮助的（否则自己可能会感觉做执行用例的工具，这样确实会没有成就感）
 
那么我们应该怎样去熟悉模块的业务呢？
首先，看开发的设计文档，一般来说一个规范的设计文档应该是对整个业务的逻辑都描述的比较清晰了的（当然，没有也没有关系，只是需要自己花费更多的时间），这个时候，我们可以尝试根据开发的设计文档自己去画出业务逻辑图，并且以数据流为对象（而不是以模块为对象）。
然后在过程中我们肯定会有很多的疑问，可以等我们初步完成后跟对应的开发一起确认下整个业务逻辑图是否正确，并且顺便将自己的疑问提出来让开发回答下。一般来说，开发应该还是比较愿意回答这些问题的，而且过程中也可能发现自己设计上面的一些问题，这样也能够帮助开发早期就发现这些问题。
继续完善，直到自己完全理解了该业务逻辑为止。这个时候，我们可以进一步分析下可能哪些逻辑处理的有问题，或者哪些逻辑复杂度比较高，可能是我们的测试重点来着。如果能够直接将这些点分析出来并且后面证明自己的分析是正确的话这块就算是做的比较好了。
 
当然，这里也会存在几个问题。
l 研发没有设计文档或者设计文档不对测试开放。碰到这样的情况，我只能说该公司对质量不重视，能够离开就赶紧离开吧！如果实在不能够离开就多跟开发去沟通，然后自己尝试将整个业务流程图画出来
l 跟开发沟通的时候，开发因为种种原因不愿意告诉自己（比如：开发时间比较紧或者觉得测试知道也没有什么用等等）。这个时候就需要发挥自己的沟通技巧了，比如：跟开发搞好关系、尽量找开发空闲的时间，并且过程中尝试去帮助开发等等。
l 时间肯定是不够的（如果上面给了你这些时间更好），需要自己花费额外的时间来做这些事情。正常情况下，这些投入对自己应该是比较值得的，特别是刚进入该行业的同学。                  
用例的执行和分析：
     首先，我们要明确的是我们执行一个模块的用例目的是保证该模块的质量。经过前面我们对业务的熟悉后，这个时候再去分析自己执行的用例时就更加有效果了，这个时候我们可能发现该模块的用例无法去覆盖到所有的逻辑或者很多用例都是冗余的。这个时候我们就可以跟上面进行沟通了，将自己的业务逻辑图给上面进行讲解，并且明确说明哪些是没有覆盖到的。哪些是冗余的以及对应的原因，一般情况下上面应该会认可我们的方案。
当然，如果我们不愿意去沟通或者觉得没有把握去说服上面的话也可以采取另外一种方法：将用例没有覆盖到的点或者觉得可能有问题的地方自己提前列出来。并且在执行用过程中或者执行用例完成后专门花时间去发散测试。来证明自己当时的分析是否正确，也能够更好的保证质量。
确认好用例后，再去执行用例的时候一个最基本原则的就是不能够出现执行漏测。所以，一定要严格按照用例描述的测试步骤来执行和检查。否则如果出现执行漏测的问题后果是比较严重的，也可能让你失去信任。

问题的排查：
不得不说，排查问题是测试人员一个很必要的能力。一个好的排查问题的方法能够大量的节省时间。那么如何去培养自己排查问题的能力呢？
1、   发现bug后一定要自己尝试去排查问题和定位，并且将自己的排查和定位问题的过程总结下来。当然，这里要控制自己的时间，否则可能会影响到自己的其他工作。
2、   当自己搞不定了再去找相关人员，并且将其排查和定位的过程也记录下来，不懂的地方及时的询问，不要觉得不好意思。
3、   将这些方法总结起来，形成该模块一个排查问题的步骤，后面再出现问题就可以按照这样的步骤去排查和定位。并且将这些步骤能够分享给团队的其他人员。当团队的其他人也能够这样去分享的话，那么整个团队的定位问题的能力也会提高很多。
bug的回归：
开发修改完bug后，我们需要保证该bug已经完全修改好并且不会引发其他新的bug。所以，回归bug的质量对我们的产品质量影响很大的，极有可能因为我们回归不充分导致该问题遗漏给客户，相信每个产品都有这样的例子吧。
那么，如果去保证我们回归bug的质量呢？
1、 根据自己前面对该模块的理解，来确认该bug产生的原因。只有完全理解了bug产生的原因才会更好的分析修改方式是否合理
2、   跟研发沟通是如何修改的，并且通过自己对业务逻辑的分析以及代码的熟悉程度来确认这样的修改是否有问题或者可能影响到的地方。
3、   根据分析进行相应的回归测试（能够直接根据代码改动分析就发现问题就更好了，也能够提高开发对自己的认可）。
这样做的好处是：
n 能够直接根据代码改动分析就发现问题，也能够提高开发对自己的认可。
n 更深入的去接触研发的设计和代码，对后面的进一步发展有很好的帮助。
n 更好的保证质量，避免开发的改动引发（不要说这不是自己的责任）。
测试的总结：
当我们负责的一个模块完成测试后，上面应该最希望我们提交的文档能够详细的分析出该模块可能存在的风险并且有充分发数据支撑吧。这里的一个要求是我们自己需要知道该模块测试完成后的整体质量如何以及可能的风险。
我们可以从多个维度来进行分析，比如：业务逻辑、用户场景、关联模块、异常等等

下面重点从业务逻辑、用户场景和关联模块3个维度来进行分析。
基于业务逻辑分析的质量模板。
 
业务逻辑
用例覆盖分析
测试覆盖分析
发现bug分析
当前风险分析
子业务1
未覆盖逻辑XXX
未覆盖逻辑XXX
Bug主要集中在xxx逻辑
XXX逻辑复杂，问题比较多等，可能未覆盖的逻辑
 
 
 
 
 
 
基于用户场景的质量分析模板
功能点
用户场景分析
测试覆盖分析
发现bug分析
当前风险分析
功能XXX
用户会按照xxx的过程来使用
覆盖了XXX的方式
Bug 1分析：通过XXX步骤发现
可能未覆盖的场景
 
 
 
 
 
 
基于关联模块的质量分析模板
关联模块
关联点分析
测试覆盖分析
发现bug分析
当前风险分析
模块XX
该模块的xx处理方式会影响到该模块的xx功能点
覆盖了XXX的关联测试
Bug 1分析：通过与XXX的关联发现
可能与该模块未覆盖的关联点
 
 
 
 
 
 
 
   通过从多个维度的分析，我们能够更加直观的得到该模块的质量情况以及可能的风险，更重要的是让我们养成了好的模块质量分析的习惯，并且提高了我们质量分析的技能。

   这里简单介绍下笔者个人的经历，期望对大家有点帮助。
  整个实习期间大概就知道了测试主要是干什么的以及怎样去测试。回学校后一直纠结要不要继续跟公司签约，或者重新找一份开发的工作，最后看在待遇的份上以及受到一些培训机构将软件测试吹到天上去了的影响，还是在毕业后来到了公司，做测试一直做到现在（当然，你永远无法知道如果你选择了另外一条路现在会是怎样的，所以，谈不上后悔和不后悔，人生大抵如此）。
 
 毕业后，实习期间参与的项目已经到后期了，功能问题也相对比较少，于是导师让我去测试下性能，顺便学习下loadrunner工具的使用。基本上又打了一个月的酱油（没有干什么实事，主要还是学习，因为实习期间学的东西差不多回学校后忘光了）。顺便说下，这个时候部门已经有7个人了（3个应届生）
 
 很快一个全新的版本开始了，自然是没有用例编写的资格，因为前面学习过一个月的性能测试（主要是知道怎么用loadrunner），于是开始同时测试版本的功能和性能。当时做了一件个人觉得很正确的事情，花了很大的精力去熟悉整个产品的架构和业务原理并且自己尝试去将整个业务图画出来并且分享给大家（当时开发是没有做这件事情的），方法就是根据现有的文档和自己的理解去画逻辑，不停的去问对应的开发（平时时间多聊天搞好关系）。做完这件事后，自己的性能测试分析能力确实有了很大的提升，对于自己的测试质量分析也帮助比较大。
 
  当然，当时除了去执行性能用例外，是没有去专门的执行功能用例任务的，这样的一个好处是自己有足够的时间去按照自己的想法（或者说根据自己的分析）去发散测试（以发现bug为目标），当时的考核大部分也是根据bug数来考核的。所以，当时基本上每天就在找哪个地方还可能有bug而去针对性的测试，整个人都沉迷在寻找bug的快乐中，当自己找到一个很深入的bug时，成就感还是比较高的。包括后面的负责整个产品的性能测试，这个过程大概持续了超过半年的世界，直到后面开始带项目（就没有足够的时间投入到里面了）。