前端架构设计3：测试核心
测试核心
(一) 传统手工测试的局限性
软件测试是在规定的条件下对程序进行操做, 以发现程序中的错误, 衡量软件质量, 并对其是否能知足设计要求进行评估的过程, 软件测试的目的是但愿以最小的代价尽量多地找出软件中潜在的错误和缺陷.html
首先,测试人员会针对开发人员开发的功能写出测试用例, 例如表单应该填入的数据, 页面单击顺序, 以及最后页面期待的效果, 而后, 测试人员会按照用例一步步进行手工校验, 若是页面行为异常, 例如没法打开页面或生成的数据不许确, 则会在企业缺陷管理系统中提交缺陷记录, 供开发人员进行修正. 在开发过程当中, 若是有新版本编译出来, 测试人员须要根据测试用例从新测试, 确认是否有新缺陷, 或者老缺陷是否已经获得了修正.前端
长久以来, 这种传统手工测试在各大公司普遍应用, 并已被证实可以行知有效的保证产品质量, 但伴随着互联网技术的发展, 这种传统的测试模式已经显示出愈来愈多的瓶颈.git
1. 重复性工做, 测试质量低
如今的互联网产品开发研究的是短平快, 小步快走, 短则两三天, 长则一星期就会发布新版本. 在这短短的时间里, 测试人员须要把新版本部署到测试环境, 更新数据库 而后对全部的测试用例进行手工校验. 这个过程事件紧迫, 工做量大, 并且具备很高的机械性和重复性, 当测试人员长期工做在重复性的验证事物上, 每每会由于思惟习惯而忽略新出现的问题, 最后致使不只测试人员自身缺少工做热情, 并且测试质量更难以保证.github
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的配置文件集合你喜欢的框架, 断言库和浏览器.