软件测试从零开始之二：开启测试之旅（上）

首先根据行业的不同，我们将测试分为app测试，web测试，通信网络，游戏测试，服务器测试，无线测试等（欢迎补充）。

刚进入这个行业后，你可能从事功能测试或测试开发的工作（如果不是，请知会我，我完善下）。

功能测试我们暂且专指黑盒测试吧，瀑布模式下的黑盒测试工程师的工作大概如下：敏捷模式下，黑盒测试工程师的工作类似，不同的是我们将需求称为用户故事，简化了设计。对于测试来说，可能就是时间更紧了。

OK，根据上面的工作内容我们重新梳理下黑盒测试工程师的工作吧！

1、熟悉需求，参与需求的评审。

2、熟悉设计文档。

3、编写测试需求和用例。

4、执行测试用例。

5、执行用例过程中发现bug，根据规定找相关人员确认后提交上去。

6、研发修改好该bug后，根据一系列的过程来回归该bug。

7、过程中进行一些发散测试。

8、完成后根据模板编写测试报告。

9、一个新的模块重复昨天的故事，而且可能重复的时间比较长。

当然，对于一个刚入职到测试工程师来说，可能有些工作内容还不会去涉及（比如：需求评审和设计评审）。

虽然这些工作看起来是很苦逼的事情，并且没有什么技术含量，但是却是我们成为这个测试专家一个必须经历的阶段。重点是：我们如何利用好这个阶段，快速的积累好这个行业的一万个小时。

笔者的建议是：在做这些事情的时候比我们的同事多做一点，一段时间后相信我们比别人进步的肯定就不止一点了。还记得1.01^365和0.99^365的差别吗？下面以每项工作举例，看看我们除了做好本职工作外，还可以去主动做哪些事情吧！

一、熟悉需求，参与需求的评审

回到我们上章的课后练习题，大家看到问题后是不是马上开始根据要求去设计用例了呢？有没有人会去问，这个功能用在哪些场景，主要是为了满足用户的那些需求呢？对于需求，我们要做的就是多问几个为什么，因为有可能客户需要的是一个正方形，而不是三角形。

所以，建议我们如果参与了需求相关的工作时，我们就需要对需求进行分析，确认对应的需求点能够给客户带来的价值的什么，或者客户真正的原始需求是什么？（可能有人会有疑问：这不是产品经理或产品规划经理的工作吗？是的你答对了，但是这有什么问题呢），而且就算我们没有兴趣做产品经理，至少我们知道我们测试的产品是干嘛用的，也能让我们在测试的过程中更好的站在用户的角度去思考和测试（对于需求分析的方法后面会专门进行分享）。

二、熟悉设计文档

在这个阶段我们熟悉该模块原理，并且达到自己能够将该模块的业务流程图画出来，并且能够自己去尝试分析整个流程是否合理，能够提前发现问题就更好了（如果你去努力做到这点，我相信你的提升一定非常快，并且能够更好的得到开发的认可，因为大部分的测试人员都做不到）。

这样做的好处（不要问我都有什么意义）：

1、对被测模块业务逻辑的熟悉，能够让自己对后面的测试更加有信⼼心。

2、站在测试的角度去看设计，培养自己对代码设计的理解能力。

3、能够自己制定测试策略和挑选用例，并且让项目经理或者组长更好的让对方接受自己的测试策略。

4、过程中发现问题自己能够尝试去排查和定位，甚至告诉研发如何去修改—这是一件很cool的事情。

5、通过用例来分析哪些模块的逻辑已经覆盖到了，从而实时把握模块的质量，对整个质量分析更加有帮助。

6、培养自己分析问题的能力，这对测试工程师是很有帮助的（否则自己可能会感觉做执行用例的工具，这样确实会没有成就感）。

当然，过程中也可能存在的问题：

1、研发没有设计文档或者设计文档不对测试开放。碰到这样的情况，我只能说该公司对质量不重视，能够离开就赶紧离开吧！如果实在不能够离开就多跟开发去沟通，然后自己尝试将整个业务流程图画出来。

2、时间肯定是不够的（如果上面给了你这些时间更好），需要自己花费额外的时间来做这些事情，正常情况下，这些投入对自己应该是比较值得的，特别是刚进入该行业的同学。

三、编写测试需求和用例

对于一个测试新⼿手来说，最好的方法就是多练习，多总结，最后形成自己的一套用例设计方法。后面会分享自己总结的一套用例设计的方法（当然，等价类，边界值，正交等等一些用例设计的知识还是需要掌握的）。

四、执行测试用例

执行用例的时候一定要搞清楚用例的测试点是什么，为什么用例要这样设计以及是否有可能没有考虑到的地方或者不合理的地方，并且有自己的改进想法（最好是总结成为文档）。

五、发现和提交bug

发现bug后自己尝试去排查问题和定位，并且将自己的排查和定位问题的过程总结下来，然后自己搞不定了再去找相关人员，并且将其排查和定位的过程也记录下来，后面再整理成自己的定位问题的文档。提交的bug将整个环境，现象，自己的分析过程等等全部备注到bug里面。养成这个习惯，你会得到开发的尊重。

坚持一段时间后，你会发现：

1、自己定位问题的能力得到了快速的提升，并且养成定位问题的习惯。

2、节省其他人的时间，更好的得到了开发的信任。

3、更好的找到了成就感。

六、回归bug

研发修改好自己发现的bug后，自己去跟研发沟通是如何修改的，并且通过自己对业务逻辑的分析以及代码的熟悉程度来确认这样的修改是否有问题或者可能影响到的地方，并且根据分析进行相应的回归测试（能够直接根据代码改动分析就发现问题就更好了，也能够提⾼高开发对自己的认可）。

这样做的好处是：

1、能够直接根据代码改动分析就发现问题，也能够提⾼高开发对自己的认可。

2、更深入的去接触研发的设计和代码，对后面的进一步发展有很好的帮助。

3、更好的保证质量，避免开发的改动引发（不要说这不是自己的责任）。

七、发散测试（又叫探索性测试）

这里建议买一本探索性测试的书籍，然后直接将里面的方法拿出来尝试用下，也许你会发现另外一份天地以及测试的乐趣，甚至你可能会选择这个方向一直走下去（后面会专门去分享探索性测试技术）。

八、测试报告

测试报告其实是我们的一次总结的过程，我们可以总结下是否所有的业务逻辑都覆盖到了，bug都集中在哪些逻辑里等等。及时的通过分析来发现风险，养成分析的习惯，能够让我们提高自己的测试分析能力（作为测试人员一个最重要的能力，没有之一），而且擅长总结的人才会更好的进步。

OK，作为一个黑盒测试工程师的工作大概如上，按照笔者的方法去做，肯定是需要花费更多的时间的，但是这样坚持的做下去，很快你就能够在同事间脱颖而出了。