前端进阶之路: 前端架构设计(3) - 测试核心

可能不少人和我同样, 首次听到"前端架构"这个词, 第一反应是: "前端还有架构这一说呢?" 在后端开发领域, 系统规划和可扩展性很是关键, 所以架构师备受重视, 早在开发工做启动以前, 他们就被邀请加入到项目中, 并且他们会跟客户讨论即将建成的平台的架构要求, 使用还什么技术栈? 内容类型是什么? 这些内容如何被建立?软件架构师的职责就是要保证项目中每一步都在整体架构的指导下进行, 而不会随机决定.

如今的前端领域, 随着JS框架, UI框架和各类库的丰富, 前端架构也变得十分的重要. 若是一个大型项目没有合理的前端架构设计, 那么前端代码可能由于不一样的开发人员随意的引入各类库和UI框架, 致使代码量变得异常臃肿, 最终结果多是代码变得没法维护, 页面性能低下,不得已只能推翻重构. 因此咱们须要在项目开始前, 一样的须要对前端代码进行架构, 一旦前端架构师设计出全部前端开发人员都要遵循的检验机制, 创建起系统设计的规范, 那么项目就拥有了能够衡量代码质量的标准, 前端开发人员也能享受到更高效的工做流. 因此, 前端架构的定义能够用如下一句话来总结:

前端架构是一系列工具和流程的集合, 旨在提高前端代码的质量, 并实现高效, 可持续的工做流.

本系列的前端架构文章, 将分别围绕前端架构的四个核心展开, 分别是代码, 流程, 测试, 文档.

前端架构的四个核心

(一) 代码

归根到底, 全部的网站都是由一堆文本文件和资源文件组成的. 当咱们面对制做网站所产生的大量代码时, 就会发现为代码和资源设定一个指望是多么重要. 在代码部分, 咱们会专一于若是实现系统架构中的HTML, CSS, JavaScript.

(二) 流程

如今早已过了FTP上传文件的时代, 那么如今重要的是思考怎么用工具和流程构建一个高效且避免出错的工做流. 工做流变得愈来愈复杂, 那些用于它们的工具也一样如此. 这些工具在提升生产力, 加快效率和保持代码一致性上带来了惊人的效果, 但也伴随着过分工程化和抽象化的风险. 因此, 现有的工做流是须要改变的.

(三) 测试

要构建一个可扩展和可持续优化的系统, 必须保证新代码和老代码可以很好的兼容. 咱们的代码不会独立存在, 它们都是大型系统中的一部分. 建立覆盖面普遍的测试方案, 能确保老代码还能正常运做.

(四) 文档

通常而言, 若是不是团队中的重要成员要离开, 咱们几乎都不会意识到文档的重要性. 等到那个时候, 你们将不得不停下手头的工做, 优先编写全部的文档. 做为前端机构师, 你要善于在项目开发的同时编写良好的文档.

测试核心

(一) 传统手工测试的局限性

软件测试是在规定的条件下对程序进行操做, 以发现程序中的错误, 衡量软件质量, 并对其是否能知足设计要求进行评估的过程, 软件测试的目的是但愿以最小的代价尽量多地找出软件中潜在的错误和缺陷.

首先,测试人员会针对开发人员开发的功能写出测试用例, 例如表单应该填入的数据, 页面单击顺序, 以及最后页面期待的效果, 而后, 测试人员会按照用例一步步进行手工校验, 若是页面行为异常, 例如没法打开页面或生成的数据不许确, 则会在企业缺陷管理系统中提交缺陷记录, 供开发人员进行修正. 在开发过程当中, 若是有新版本编译出来, 测试人员须要根据测试用例从新测试, 确认是否有新缺陷, 或者老缺陷是否已经获得了修正.

长久以来, 这种传统手工测试在各大公司普遍应用, 并已被证实可以行知有效的保证产品质量, 但伴随着互联网技术的发展, 这种传统的测试模式已经显示出愈来愈多的瓶颈.

1. 重复性工做, 测试质量低

如今的互联网产品开发研究的是短平快, 小步快走, 短则两三天, 长则一星期就会发布新版本. 在这短短的时间里, 测试人员须要把新版本部署到测试环境, 更新数据库 而后对全部的测试用例进行手工校验. 这个过程事件紧迫, 工做量大, 并且具备很高的机械性和重复性, 当测试人员长期工做在重复性的验证事物上, 每每会由于思惟习惯而忽略新出现的问题, 最后致使不只测试人员自身缺少工做热情, 并且测试质量更难以保证.

2. 测试效率低

手工测试天生就决定了它的执行效率很低, 测试人员须要根据测试用例逐行逐字阅读, 而后在页面上一步步填写表单, 在单击按钮提交, 这是一个很是繁琐的过程. 而遇到复杂的业务流程更是涉及方方面面, 做者甚至见过一个多小时都没法完成的测试案例. 到了开发后期, 可能天天或每两天就要发布一个版本进行测试, 若是一个软件系统的功能点有几千甚至上万个, 手工测试将特别耗时和繁琐, 不只消耗了大量的人力, 还可能影响到产品的如期发布.

3. 没法保证覆盖代码全路径

是否有良好的测试覆盖是考核测试成熟度的重要指标, 其核心思想是对相同的业务逻辑提供多组甚至几十组输入, 全面覆盖到业务中的大多数路径, 重点考察软件的边界行为. 好比某个页面输入框的字符个数在开发中被限制为256个字符, 但测试人员极可能漏掉这样的极端输入状况. 因为手工测试效率很低, 不要说进行几十组数据的测试, 就是几组可能都难以实施. 另外, 有些软件缺陷须要在大量数据或者大量并发用户的状况下才会暴露, 很难经过手工测试保证代码的全路径覆盖.

4. 没法有效兼顾多浏览器, 多平台

Web前端的测试环境复杂, 兼容性要求高, 特别是要同时兼顾多种操做系统, 包括Window, Mac OS和Linux, 以及不一样的浏览器IE, Edege, Chrome, Safari等, 还要考虑移动端的IOS, Andorid等操做系统, 其排列组合以后将会是经过手工测试没法企及的数字. 很难想象有那个公司可以投入巨大的人力成本完成如此庞大的手工测试.

(二）前端测试的分类

1. 单元测试(Unit Test)

在软件开发过程当中, 最基本的测试就是单元测试, 这是针对程序单元(软件设计的最小单位)来正确性检验的测试工做. 程序单元是应用的最小可测试部件. 在过程化编程中, 一个单元就是单个程序, 函数, 过程等; 对于面向对象编程, 最小单元就是方法. 在企业的质量控制体系中, 单元测试是由开发部门在软件提交测试部门前完成.

单元测试的目标是打破程序单元间的依赖关系, 隔离单元并证实这些单个单元是正确的, 因此单元测试应该无依赖和隔离, 一般在单元测试中, 把系统的依赖组件提取出来, 用测试替身(Test Double)取而代之, 把单元测试把注意力集中放在测试"单元"的逻辑上面而不是和第三方系统的交互上.

2. 集成测试(Integration Test)

即便一个程序在单元测试中运做良好, 也不能肯定他们放在一块儿能正常工做, 集成测试是取出应用程序里能够独立运行的组件, 一般是一些单元的集合, 来测试这部分单元做为一个总体的表现, 以验证他们可否协调一致的运做. 集成测试通常位于单元测试以后 端到端测试以前.

例如一个常见的集成测试场景是使用数据组件对数据库进行操做的测试. 测试人员须要安装并配置好数据库, 而后在数据库里插入预先准备好的数据, 再执行须要测试的组件, 运行完毕后检验数据库里的数据. 在这个测试场景中, 被测单元依赖数据库访问模块, 因此它不是一个单元测试. 可是它也没有模拟一个完整的用户真实场景, 因此它也不是一个端到端的测试.

3. 端到端测试(End-to-End Test)

端到端测试(一般缩写为E2E)是把产品或服务当作一个总体进行验证, 典型的作法是模拟真实的用户场景, 经过与系统的需求定义作比较, 来发现产品和需求定义不符合或存在矛盾的地方, 其最终目的是为了发布产品. 例如在Web应用程序中, 测试人员会启动服务器, 打开浏览器, 访问被测网页, 并操做网页上须要测试的功能, 检查浏览器中发生的特定的事件, 以确保被测功能能够正常运行.

端到端测试一般由测试部门完成, 通常有如下特性:

• 须要搭建专门的测试环境模拟真实的用户场景, 成本较高
• 测试用例复杂, 运行时间长
• 一旦测试发现问题, 因为涉及的模块比较多, 定位问题难度较高

端到端测试能够手工完成, 也能够变现测试框架和测试代码自动执行. 在Web前端应用中, 端到端测试一般从用户界面开始, 核实用户与应用之间的交互, 确保用户界面向用户提供了适当的访问测试对象功能的操做, 同时还要确保内部的对象符合预期要求. 若是进行手工测试的话, 效率低下, 没法知足快速迭代的Web前端应用的测试需求, 因此迫切须要将Web前端应用的端到端测试自动化.

(三)测试驱动开发的理念(TDD: Test-Driven Development)

1. TDD的优点

TDD的基本思路就是经过测试来推进整个开发的进行。而测试驱动开发技术并不仅是单纯的测试工做。

需求向来就是软件开发过程当中感受最很差明确描述、易变的东西。这里说的需求不仅是指用户的需求，还包括对代码的使用需求。不少开发人员最惧怕的就是后期还要修改某个类或者函数的接口进行修改或者扩展，为何会发生这样的事情就是由于这部分代码的使用需求没有很好的描述。测试驱动开发就是经过编写测试用例，先考虑代码的使用需求（包括功能、过程、接口等），并且这个描述是无二义的，可执行验证的。

经过编写这部分代码的测试用例，对其功能的分解、使用过程、接口都进行了设计。并且这种从使用角度对代码的设计一般更符合后期开发的需求。可测试的要求，对代码的内聚性的提升和复用都很是有益。所以测试驱动开发也是一种代码设计的过程。

开发人员一般对编写文档很是厌烦，但要使用、理解别人的代码时一般又但愿能有文档进行指导。而测试驱动开发过程当中产生的测试用例代码就是对代码的最好的解释。

快乐工做的基础就是对本身有信心，对本身的工做成果有信心。当前不少开发人员却常常在担忧：“代码是否正确？”“辛苦编写的代码还有没有严重bug？”“修改的新代码对其余部分有没有影响？”。这种担忧甚至致使某些代码应该修改却不敢修改的地步。测试驱动开发提供的测试集就能够做为你信心的来源。

固然测试驱动开发最重要的功能还在于保障代码的正确性，可以迅速发现、定位bug。而迅速发现、定位bug是不少开发人员的梦想。针对关键代码的测试集，以及不断完善的测试用例，为迅速发现、定位bug提供了条件。

2. TDD的原理

测试驱动开发的基本思想就是在开发功能代码以前，先编写测试代码。也就是说在明确要开发某个功能后，首先思考如何对这个功能进行测试，并完成测试代码的编写，而后编写相关的代码知足这些测试用例。而后循环进行添加其余功能，直到彻底部功能的开发。

3. TDD的过程

测试驱动开发的基本过程以下：

• 明确当前要完成的功能。能够记录成一个 TODO 列表。
• 快速完成针对此功能的测试用例编写。
• 测试代码编译不经过。
• 编写对应的功能代码。
• 测试经过。
• 对代码进行重构，并保证测试经过。
• 循环完成全部功能的开发。

(四) 测试工具推荐

1. Jasmine

Jasmine应该算是最成熟的Javascript测试框架，它自带断言和测试执行环境, 并有拥有灵巧而明确的语法可让你轻松的编写测试代码。

2. Mocha

Mocha一样也是一个前端框架, 它上手简单且有丰富的插件.若是想学习的, 能够看一下阮一峰的教程:测试框架 Mocha 实例教程

3. Karma

Karma是由Google团队开发的一个测试工具, 它不是一个测试框架, 只是一个跑测试的驱动. 你能够经过karma的配置文件集合你喜欢的框架, 断言库和浏览器.

---

参考资料

1. Web前端测试与集成——Jasmine/Selenium/Protractor/Jenk
2. IBM: 测试驱动开发(TDD)