前端进阶之路: 前端架构设计(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前端应用的端到端测试自动化.

1. TDD的优势

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

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

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

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

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

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

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

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

明确当前要完成的功能。可以记录成一个 TODO 列表。

快速完成针对此功能的测试用例编写。

测试代码编译不通过。

编写对应的功能代码。

测试通过。

对代码进行重构，并保证测试通过。

循环完成所有功能的开发。

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

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

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

Web前端测试与集成——Jasmine/Selenium/Protractor/Jenk

IBM: 测试驱动开发(TDD)