重读《从菜鸟到测试架构师》-- 测试专家的第一步

无论是大学毕业的第一份工作还是工作多年后重新入职新公司，我们都不可避免的会遇到上班第一天，在这第一天的时间里我们需要完成领设备、装系统等准备工作，当然，不可或缺的还有新人培训，这本书的第一章也直白地使用了这样的标题：第 1 章 上班第一天，新人培训。

测试专家第一步

这一短篇概述了测试行业的基本功及专业技能的描述，当然，毫无意外，要介绍下本书的主人公，小艾，他从某名牌大学计算机科学专业以硕士头衔毕业，就职于IBM，顺便标榜自己为菜鸟。既可以让自己像个菜鸟一样跟着主人公一起成长，也可以如同一个过来人一般看着这个菜鸟成长，不得不说，这个设计，个人还是蛮喜欢的~

既然是菜鸟嘛，那什么都不懂也就情有可原了，不过这只菜鸟蛮幸运的，一路走过来，总有老鸟教导着他，这不，面试的时候面试经理就开始给他解释什么是软件测试了：其实测试是软件开发过程中必不可少的重要流程。然后将看似枯燥的软件测试解释成值得思考和探索的有趣旅程，最终将小艾纳入麾下成为了一名软件测试工程师。到这里，主人公的成长之旅正式要展开了，因为主人公入职了~

可是主人公毕竟只是一枚菜鸟，对这一切都无从下手，但是充满热情的他主动开始找别人聊天，不，请教去了~ 小艾的提问也蛮值得我们学习的，他的第一个问题不是问什么是软件测试，而是问，软件测试的工作包含什么内容，再紧接着才问，如何做测试。

书中并没有直接长篇大论描述给小艾做解释的导师的话，而是通过谈话结束后小艾自己的体会总结学到的东西，先说明测试的种类与步骤多种多样，而这么多的花招其实无非是为了寻找到问题和bug并对其进行修复。剩下的内容可以分为如下几点：

测试的目的

测试其实是发现并解决问题的过程，而其目标则是让软件产品以尽可能高的质量交付给客户，使软件产品中存在的问题尽可能少，这样，软件的用户可以得到最完美的使用体验。

测试可行性

除了小型项目，进行完全（各种输入和前提条件的组合）的测试是不可行的。因此只能运用风险分析和不同系统功能的测试优先级来确定测试的关注点，从而替代无穷测试，考虑测试的内容和方式，应当以高产出投入比作为最终目标，最大化地利用现有资源排除潜在的问题。

测试的过程

软件测试是一个严谨、全面且有条理的过程，这个过程中包含了多种测试类型，每种测试类型都有针对性地验证软件，发现相应的问题。

测试的种类（部分）

单元测试：验证单元模块是否得出预期结果，是粒度最小的软件测试。其中有一种流行的开发模型：TDD(Test Driven Development) 测试驱动开发。

功能测试：关注的重点是系统的功能（完整的业务功能），通过执行自动或者手动的测试用例，验证相应的功能点是否正确。

性能测试：重点验证软件的非功能性需求的测试，通过自动化的方法模拟真实用户并发访问的场景，验证系统的性能指标或发现性能瓶颈。

测试基本功

大家一定很好奇，测试的种类那么多，小艾到底是在什么样的项目上开启自己的成长之旅的呢，书上交代了，这是一个电子商务平台。别的先撇开，我们看下在本书中做电子商务需要哪些测试基本功呢？ 

操作系统

操作系统毫无疑问是平台的基础，测试环境的搭建便是要在操作系统的基础上安装测试需要的应用程序，部署测试的功能代码，因此，往往一个测试岗位对测试人员的要求中总归少不了对操作系统的要求。

小艾也同样没能逃离操作系统的折磨，在耗时费事的安装测试环境折磨下，喜欢思考的本性让他明白这难以保障软件测试的质量，而在耐心的导师解说下才明白，解决环境安装问题的方式是执行构建测试（BVT Build Verification Testing）。 

为了有效搭建环境，避免人为原因的错误，采取的策略是最大程度上地使用构建过程自动化。

那么看到这里，我们知道了 BVT的一个好处是可以验证环境安装的正确性，加上个人之前的经验也可以知道BVT的另一个好处是确保待测产品的可测性。

中间件

说到测试基本功，中间件在某些项目中也是不可或缺的，它是提供系统软件和应用软件之间连接的软件，以便于各种部件之间的沟通，特别是应用软件对于系统软件的集中的逻辑。

中间件不提供具体的功能，但它却是系统中各个部件有机连接的桥梁。中间件可以提供对外围服务器，包括数据库服务器、应用服务器、Web服务器等的支持和管理。中间件技术建立在对应用软件部分常用功能的抽象上，将常用且重要的过程调用、分布式组件、消息队列、事务、安全、连接器、商业流程、网络并发、HTTP服务器、Web服务器等功能集于一身或者分别在不同品牌的不同产品中分别完成。

小艾在工作中训练了一些基本能力之后，又进入了新一轮的思考，可见小艾确实是个喜欢思考的孩子，这一次他思考的内容是如何确保项目顺利达到预期效果？当然，作为菜鸟的他知道凭自己得不到好的答案，于是继续找别人聊天，不，请教去了~ 这次在请教的过程中小艾第一次接触到了敏捷。

敏捷

使用敏捷项目管理的目的是为了提高开发效率，激发团队的积极性并尽可能降低项目失败的风险。

提到敏捷开发，人们总是习惯用传统的瀑布模型来做对比，这本书也不例外，依然毫无意外地说明了什么是瀑布模型：它将整个系统的开发划分为需求分析、设计、实现、测试、集成和维护等阶段，但是这样按照单一流程的划分却很容易带来资源浪费和失败风险的增加，项目过程中无关的人员无事可做不说，项目的成果最后阶段才能完成，而中间一旦任何步骤出现差错，项目可能就会全盘失败，这个风险实在太大。那么敏捷开发呢？

敏捷开发有两个核心点：迭代开发（Iterative Development）和增量开发（Incremental Development）。什么意思？

迭代开发把一个完整的瀑布模型开发流程分为多个迭代，每一个迭代可以看作独立的开发过程，包含项目的主要步骤。这样生产的周期就变短了，每一个完整的周期都会有相应的产品出现，一旦出现不正确，可以立即调整方案，这种方式有利于在完整项目开发的过程中跟踪和控制开发进度及产品质量。

增量开发则使用分段完成的策略，系统中的不同部分被安排在多个阶段完成，各个部分完成之后再集成到系统中，往往增量开发与迭代开发统称为迭代开发。

说到敏捷，就避不开提到的是敏捷的项目周期，这个周期在敏捷中称为sprint。每个sprint 大约是2~4周时间（书上说的是2~6周，但根据个人经验，一般以2~4周居多，每个公司标准不一样，或许IBM是2~6周吧~），前期会有sprint计划会议，后期会有sprint回顾会议，而每一天会有站立会议。

或许对敏捷不甚了解的你会和小艾一样觉得开会就是浪费时间，开发周期的缩短已经让时间变得好像不怎么够用了，怎么还要开那么多会，其实不然，站立会议的持续时间很短，通常为15~20分钟，而且一般情况下都是早上进行，而在这个会议中可以让所有成员都了解彼此的进度以及项目的总进度，因此还是很有必要的。如果有问题怎么办，问题不应该放在这个会议中讨论解决，而应该在会后找到相关人员一起进行讨论。

在敏捷中，除了在聊单元测试时提到的TDD之外，还存在其他很多方法诸如XP（极限编程）等，不同的项目会使用不同的方式，而这些方式的基础无外乎是两个：计划和流程。

好的计划是项目成功的基础，而流程则是项目成功的保障。

培养专业技能

我写过一篇文章，说自己转行做测试的缘由是想逃避写代码，因为我也像很多人一样，对软件测试充满了误解，以为只要鼠标点点，以为简单到可以泡杯茶看看报就打发一天的工作，然而接触这行业时间越长，越是发现，软件测试的水很深……那么，有哪些专业技能也是我们不得不让自己去学习的呢？

脚本编程

作为一名测试工程师， 我们的工作应该专注在测试上，这是正确的，但并不代表我们不需要掌握开发技术，恰恰相反，开发技术是测试工程师应该掌握的基本专业技能之一。一名专业的测试工程师，应该把开发技能作为其技能体系的基础。

掌握开发技能有利于理解功能实现的方法和逻辑，从而更容易设计出有效的测试场景和用例。

测试专业技能

测试专业技能是测试工程师技能体系的核心。

理论上，任何方法，只要发现的错误或bug确实存在的，都是可行的测试方法。然而项目实践中，我们只能采取最有效和可控的方法。有效，是指这种方法有效模拟真实的应用并有效暴露出潜在的问题。可控，指的是使用方法有明确的步骤，通过相应的步骤可以使暴露的问题重现。真正的测试中，有效可控的测试方法通常有两类：白盒测试和黑盒测试。

作为测试人员，相信每个人都对手动测试并不陌生，其方便灵活，只需要有明确的测试用例作为指导便能执行，并不需要花额外的时间准备完备的自动化测试材料。但不停的重复相同的工作是个无法摆脱的梦魇。于是很多人选择转战自动化测试，它弥补了手动测试在重复开销方面的不足，测试过程中不需要人工干预，但对测试团队的组织和技术要求更高。

作为一个成熟高效的测试团队，手动测试和自动化测试都是不可或缺的测试执行方法。两者优势互补，可以有效保障软件产品的质量。

作为软件测试工程师，只要掌握了测试执行的方法，就可以认为已经掌握了基本的专业技能了。然而高质量的测试要求工程师掌握更多的技术，包括架构设计、软件开发技术等。更好地掌握这些专业技术，目的是更好地服务于测试 ，测试的目的则是发现和排除软件中存在的问题。

尾声

从菜鸟到测试架构师，第一章的第一节，刚入职的菜鸟小艾清楚地认识到自己的菜鸟身份，通过不断思考不断提问不断总结，获得了软件测试工程师最基本的知识技能以及了解到自己今后要学习的方向。在接下来的工作中，小艾观察到团队中的每个人似乎都在做不同的事情，这到底是为什么呢？开发团队及测试团队又会有多少种角色？请听下回分解咯~

 

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