重读《从菜鸟到测试架构师》-- 黑色的盒子里面有什么（上）

上一章提到，由于研发组工作繁忙，小艾被派遣过去协助做开发工作，在协助过程中，小艾明白了单元测试是怎么回事以及如何进行，也就是说，小艾接触到了白盒测试的相关知识。伴随着开发进度的有序进行，小艾回到了测试团队开启了新一轮的测试旅程。

可是在工作中，对着可执行的程序不知道从哪里入手，毕竟之前一边读代码，一边调试来找问题，十分得心应手，这下倒好，没有代码可以看可以调了……

小艾的功能测试第一课——准备手电

功能测试，其实是很简单但是又不那么简单的一件事，简单到一句话可以描述其定义，难却也难在要做到这句话说的事情可不简单：

功能测试，简单的理解就是黑盒测试，就是检测黑盒子，抓到里面的bug。

看吧，简单到可以理解成所谓的鼠标点点……不过，想做好黑盒测试需要一个好用的手电，作为自己的眼睛，来划破黑夜，找到bug，寻找到光明！

对于产品的学习

要做好功能测试，毫无疑问需要站在客户的角度去学习产品、看待问题。因为功能测试人员是代表用户在对产品进行把关，而不是帮助开发人员完成对功能的检查。因此这也就是为什么有话说测试人员在测试的时候一定要坚信任何产品都有bug存在，也有话说测试人员与开发人员是势不两立的~

通读产品的用户文档，也可以让我们了解用户为什么要使用这个产品及一些具体的商业流程实现。也能让测试人员真正站在用户的角度看待一些问题，这个是很重要的角度转换，而想要找到bug，很重要的一点也是对产品具体功能特征的学习。

通过学习需求说明书、设计文档等相关文档，也可以更好地了解用户为什么需要这些功能，这些功能是怎么设计的，每个功能点又是什么样的，这样就不至于开出一个bug却被告知这个是by design，而不是真正的问题……

当然，功能测试人员并不是简单地按照开发人员的设计文档去撰写测试相关文档的，而是必须认真学习需求说明书，审核设计文档，确保设计文档中包含了所有的需求说明，且该设计是能够满足需求的，即每个功能都需要严格地按照需求说明书实现。与此同时，要站在用户的角度去理解功能设计是否合理。

熟悉各种测试文档

完成了对产品的文档学习之后，由浅入深，由整体到局部，小艾对这个产品在功能上有了一定程度的理解，小艾开始了自己的工作，但对比测试文档的内容，小艾发现自己的测试角度和思维与有经验的测试人员有着不小的差距。

对产品功能学习不够深刻，很多小功能点没有考虑到，对功能的异常情况也考虑不周，缺乏产品运行时错误处理的测试意识，测试场景，用例的设计不够细化，不同的测试用例出现了测试冗余等等……

因此，小艾明白，原来熟悉各种测试文档这一块真的很重要，而自己做得远远不够~

了解功能测试的流程

如果说前面的学习是从横向了解这个产品，那么了解测试流程则是从纵向了解这个产品的生命周期及具体功能测试是如何进行的。

测试流程是整个软件开发生命周期的一部分，流程是做好事情的保障，无论是什么样的开发模式，都要了解流程，进而做好工作的规划。在敏捷开发模式的每一次迭代结束时，都需要通过相应的测试，迭代提交的产品是可工作的软件，而不是等到所有迭代过程都结束了才开始进行全面的功能测试：

在这个产品的开发模式下，产品的解决方案是由不同的user story组成的，不同的user story优先级不同。处于某一迭代过程中的高优先级的story的需求是明确的、详细的，低优先级的story在前面的迭代过程中需求往往是概略的，不确定的。即使是处于高优先级的story，它的设计也可以是由简单到完善的一个跨若干个迭代的过程。

所以最初的测试场景和测试用例的设计可能只是针对产品某一功能特征的一个设计雏形来进行的，需要在每次迭代的过程中不断完善，直到最后产生一个可交付的测试场景和测试用例，以及最终的测试计划书。

对产品整个安装包的各层软件的了解

要想做好功能测试，对所测产品的整个安装包的各层软件的了解是功能测试人员及其他测试人员必不可缺的基本技能。

一个大型的应用，它所涉及的各层软件种类繁多，通常是一个复杂的矩阵结构，这和不同的用户对软件及整个IT基础架构的不同需求和设计有关。

学习自动化测试工具

对于功能测试而言，自动化测试是提高工作效率、保证测试质量及减少积累的回归测试工作量的重要保证。随着对功能测试的越来越重视，自动化测试已经成为业界的一个重要考量指标。