第一章 前端开发测试总览

1.1 软件测试

  • 定义

    • 再规定条件下对程序进行操作，以发现程序中的错误，衡量软件质量，并对其是否满足设计要求进行评估的过程。

  • 目的

    • 希望以最小的代价尽可能多地找出软件中潜在的错误和缺陷

1.2 传统开发流程的局限性

  • 瀑布模型

    • Winston W.Royce1970年提出的软件开发模型

    • 源自传统工业生产

    • 严格遵守预先计划的需求、分析、设计、编码、测试和部署的步骤顺序进行

    • 局限性

      1. 自由度低，缺乏灵活性

      2. 缺陷发现晚，无法及时反馈

      3. 协同合作缺失，容易引起团队冲突

      4. 产品质量无法保证

1.3 传统手工测试的局限性

  • 步骤

    1. 测试人员会针对开发人员开发的功能写出测试用例

    2. 测试人员按照用例一步步进行手工检验，如发现异常，则会在企业缺陷管理系统中提交缺陷记录，共开发人员进行修正

（如有新版本，重复上面的操作）

  • 缺陷

    1. 重复性工作，测试质量低

    2. 测试效率低

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

    4. 无法有限兼顾多浏览器、多平台

1.4 敏捷软件开发（Agile Software Development）

  • 为了应对需求快速变化而发展出的软件开发方法

  • 多种方法：

    • 极限编程
      Extreme Programming

    • 精益开发
      Lean Software Development

    • 特征驱动开发
      Feature-Driven Development

    • 概要: 共同特征

      • 1.迭代式开发

        • 整个过程分为几个迭代周期，每个迭代周期持续的时间一般较短，通常为1-4周

        • 产品在每个迭代周期结束时被逐步交付使用，每次交付都是可以被部署、能给用户带来即时效益和价值的产品

        • 敏捷软件开发主张用户能够全程参与整个开发过程。这使需求变化和用户反馈能被动态管理并及时集成到产品中

        1. 关注软件质量
        • 在开发的整个生命周期中关注产品质量

      • 及时反馈

        1. 增量交付

  • 优点

    1. 更强的灵活性

    2. 更短的开发周期

    3. 持续反馈

    4. 测试和开发技能的融合

1.5 全流程测试

1.5.1 单元测试（Unit Test）

  • 最基本的测试

  • 针对程序单元（是应用的最小可测试部件）

    • 单个程序

    • 函数

    • 过程等

    • 方法

    • 包括基类（超类）中的方法

    • 抽象类中的方法

    • 派生类（子类）中的方法

    • 概要: 过程化编程

    • 概要: 面向对象编程

  • 完成时间： 开发部门在软件提交测试部门前完成

  • 目标：

    • 打破程序单元间的依赖关系

    • 隔离单元并证明单个单元是正确的

    • 概要: 所以，单元测试应该是无依赖和隔离的

  • 操作方法：
    1） 把系统的依赖组件提取出来

    • 常见依赖组件如：

      • 网络

      • 数据库

      • 第三方类库

      • 文件系统等

2） 用测试替身（Test Double）取而代之

  • 单元测试的注意力应该集中在测试“单元”的逻辑上而不是和第三方系统的交互上

1.5.2 集成测试（Integration Test）

  • 方法：

    • 取出应用程序里可以独立运行的组件（通常是一些单元的集合）

  • 目的：

    • 测试这些单元作为一个整体的变现
      验证它们能否协调一致地运作

  • 时机：

    • 单元测试之后

    • 端到端测试之前

  • 例如：
    常见的集成测试场景
    使用数据组件对数据库进行操作的测试

    • 测试人员需要配置好数据库

    • 数据库里插入预先准备好的数据

    • 执行需要测试的组件

    • 运行完毕后检验数据库里的数据

1.5.3 端到端测试（End-To-End Test/E2E Test）

  • 把产品或服务当做一个整体进行验证

  • 做法：

    • 模拟真实的用户场景

    • 与系统的需求定义作比较

    • 发现产品与需求定义不符合或存在矛盾的地方

  • 目的：

    • 发布产品

  • 执行：

    • 测试部门完成

    • 方法：

      • 手工完成

      • 编写测试框架和测试代码自动执行

    • 流程：

      • 从用户界面开始

      • 核实用户和应用之间的交互

  • 特性：

    • 需要搭建专门的测试环境模拟真实的用户场景，成本较高

    • 测试用例复杂，运行时间长

    • 一旦测试发现问题，由于涉及模块较多，定位问题难度较高

1.5.4 测试自动化

  • 把以人为驱动的测试行为转化为机器执行的一种过程

  • 并不是完全摆脱测试人员，而是由人设计机器行为，让机器驱动测试的新模式

  • 优点：

    • 执行者是机器，可充分利用硬件资源，提高测试效率

    • 测试大量数据，提高测试用例的广度

    • 缩短回归测试的时间

1.5.5 持续集成（Continuous Integration）

  1. 定义:

    • 一种频繁持续的再团队内进行业务集成，自我反馈完善的软件开发实践

    • 要求团队开发人员经常集成他们的工作，每个人至少每天集成一次

  2. 方法：

    • 通过自动化构建，把包括编译、部署、测试、审计和反馈的一组流程用一体化方案驱动起来，整个流程不需要任何用户的人工干预

  3. 优点：

  1. 可以及早发现缺陷

  2. 通过自动化构建，减少开发测试人员的重复劳动

  3. 团队成员任何时间点上都可以进行集成，团队可随时发布部署

可实现分布式团队的协作沟通

1.5.6 DevOps（Development & Oparations）

  • 一种重视软件开发过程中各个团队之间沟通合作的文化、运动和惯例

  • 不是一种技术和工具，而是一种文化转变

  • 要求：

    • 运维人员要懂得产品的架构和功能

    • 开发测试人员要懂实际的运维（从实际部署、上线流程、到故障的定位与解决）

    • 运维所需的功能甚至基础设施要成为产品非功能性需求的一部分

    • 产品交付于运维需要集成到整个软件生命周期中

其他

  • javascript是1995年，netspace工程师Brendan Eich，花了10天的时间创造出来的