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

前面的章节中，我们说到，在导师的讲解下，小艾明白了测试的策略及流程，但依然不知道应该如何做以及具体做什么。这时导师告诉小艾，功能测试人员除了之前学到的基本技能和策略/流程之外，最重要的是要理解和掌握各种各样的文档。

 

文档

能够很好地理解别人写的文档，是对功能测试人员最基本的要求。而能够写出好的文档，则是资深功能测试人员，特别是测试组长/测试架构师的基本素质。

功能测试计划书

功能测试计划书涵盖了整个产品的功能测试范围及各种相关条件。

在敏捷开发模式下，具体功能特征的功能测试计划书是一个按照迭代周期迭代开发的测试计划书。

 

测试场景

测试场景是功能测试中一个非常重要的概念，只有设计好的功能测试场景，才能够真正代表客户，站在客户的立场上进行测试。

每一个功能测试场景都是由一个或多个用例组成的：Scenario(S)={UC1, UC2,... UCN}

因为功能测试场景是功能测试用例的逻辑，要完成功能测试用例，功能测试人员需要创建数据和结果验证。不同的功能测试用例可以是同一个测试场景，但是有不同的数据和结果验证，因此，功能测试用例可以定义为：Test Case = (Sf, D, RV), 其中，Sf 为功能测试场景(由一个设计文档中的一组用例按照一定的逻辑组织起来的场景)，D为数据（输入信息或者场景中需要的材料），RV为结果验证（一系列步骤）。

在功能测试场景中列出的每一步，都需要有一对一的数据和结果验证的对应。

好的测试设计需要对测试产品和目标用户的商业需求有深入的理解，同时要对产品的功能非常熟悉，好的测试场景和测试用例的设计对于测试的质量和测试执行的效率是非常有好处的。一个好的测试用例将清楚地描述什么会被测试，将产生什么样的结果以及为什么会产生这样的结果。

完整的测试用例至少要包含以下几个方面：输入、期望值、系统运行的前置条件或说明。

听完导师的介绍之后，小艾开始动手写起了第一个功能测试用例，看着自己对功能测试策略、流程的初步理解，小艾也感到很有成就感。

编写自动化测试脚本

搭建好测试环境后，小艾正式开始了执行功能测试用例的工作，产品开发初期的迭代过程，主要是以手动执行的方式执行功能测试用例，同时对这些功能测试用例进行自动化的开发，而在后面的迭代过程中，则会借助于各种工具进行对执行过程的跟踪、记录。

开发自动化测试脚本还能够帮助功能测试人员更好地理解测试用例的逻辑，突出对功能测试用例中的功能点的理解。自动化开发出了要熟悉相关编程技巧，还要有相应的自动化开发的框架作为支撑，并有完备的自动化测试策略和流程保证自动化代码的重用性和代码质量。

还是同样的，书中使用的是JUnit + Selenium的方式用java编写自动化脚本，但本人比较熟悉使用C#语言，很便捷的是，Visual Studio 提供了相应的dll组件帮助我们完成自动化脚本的开发。

只需要在项目中引用 SHDocVw 以及Microsoft.mshtml，然后使用using将其包含在项目程序中，即可以使用最简单的方式编写代码运行了，例如：

当然，也可以借助已有的框架，如NUnit, WatiN, Selenium等等框架支持自动化脚本的开发，其原理都差不多，不过相比较而言，使用这些市场上使用较广的框架对测试脚本的支持度会比较高~

 

找到了第一条虫子

通过了上述的讲解及自己的亲身实践，小艾很快就发现了产品的第一个bug，小艾的欣喜之情自不必说，然而小艾依然忽略了一些小问题，诸如用户的体验度。尽管一个产品的一个功能能够正常使用，但若是体验不够好，也依然是测试人员在测试过程中需要指出来的~

 

执行高手

在导师的帮助下，在自己的实践中，小艾总结到：一个好的功能测试人员需要掌握以下技能并加以持续的锤炼。

 

文档的理解

功能测试最重要的是理解业务需求，熟悉产品，熟悉具体的功能模块，功能特征的设计文档，熟悉功能测试场景和用例。

 

产品框架和数据结构的了解

更好地寻找问题及分析/定位问题发生的原因

产品环境的理解和技能的培养

兼容测试用例策略，更好地排除是否由环境引起问题的发生

 测试工具的理解和技能掌握

效率的提升

问题分析能力

对功能测试中出现的问题的分析能力，是一个功能测试人员的一个重要衡量指标。

尾声

在组长的带领下，小艾走过了对功能测试知识从初步理解到具体执行的过程，完成了从菜鸟到一个合格的功能测试执行人员的成长。此时，组长又会用怎么样的方式带着小艾继续从更全面的角度去了解功能测试，带领小艾成长呢？请听下回分解~

 

想要第一时间看到这一系列文章的更新及更多精彩内容可以扫描下面二维码关注微信公众号: 倚楼听风雨的如月