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

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

 

文档

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

功能测试计划书

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

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

 

测试场景

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

每个功能测试场景都是由一个或多个用例组成的：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，小艾的欣喜之情自没必要说，然而小艾依然忽略了一些小问题，诸如用户的体验度。尽管一个产品的一个功能可以正常使用，但如果体验不够好，也依然是测试人员在测试过程当中须要指出来的~

 

执行高手

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

 

文档的理解

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

 

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

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

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

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

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

效率的提高

问题分析能力

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

尾声

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

 

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