软件测试概述

1、发展历程

2、测试模式

3、测试理论

4、测试技术

5、测试展望

6、下期预告

主讲人： 严骏（平台部）

原来软件测试也能追本溯源（不是程序员拍脑袋想出来的），也有其存在的必然性与合理性

主要分成五个阶段:

1、调试为主(Debugging Oriented)

2、证明为主(Demonstration Oriented)

3、破坏为主(Destruction Oriented)

4、评估为主(Evaluation Oriented)

5、预防为主(Prevention Oriented)

调试为主(1957年以前)
20世纪50年代，计算机刚诞生不久，只有科学家级别的人才会去编程，需求和程序本身也远远没有现在这么复杂多变，但是严谨的科学家们已经在开始思考 “怎么知道程序满足了需求？”这类问题了。
证明为主(1957-1978)
1957年，Charles Baker在他的一本书中对调试和测试进行了区分：
　　 调试(Debug)：确保程序做了程序员想它做的事情
　　 测试(Testing)：确保程序解决了它该解决的问题
这是软件测试史上一个重要的里程碑，它标志测试终于自立门户师出有名了。
当时计算机应用的数量，成本和复杂性都大幅度提升，随之而来的经济风险也大大增加，测试就显得很有必要了，这个时期测试的主要目就是确认软件是满足需求的，也就是我们常说的“做了该做的事情”
破坏为主(1979-1982)
1979年，《软件测试的艺术》 (The Art of Software Testing)第一版问世，这本书是测试界的经典之作。书中给出了软件测试的经典定义：
　　The process of executing a program with the intent of finding errors.
　　测试是为发现错误而执行程序的过程。
这个观点较之前证明为主的思路，是一个很大的进步。我们不仅要证明软件做了该做的事情，也要保证它没做不该做的事情，这会使测试更加全面，更容易发现问题。
评估为主(1983–1987)
1983年，美国国家标准局(National Bureau of Standards)发布“Guideline for Lifecycle Validation, Verification and Testing of Computer Software”，也就是我们常说的VV&T。VV&T提出了测试界很有名的两个名词：验证(Verification)和确认(Validation)
　Verification: Are we building the product right?
　Validation: Are we building the right product?
人们提出了在软件生命周期中使用分析，评审，测试来评估产品的理论。软件测试工程在这个时期得到了快速的发展：
1. 出现测试经理(test manager)，测试分析师(test analyst)等职称
2. 开展正式的国际性测试会议和活动
3. 发表大量测试刊物
4. 发布相关国际标准
以上种种都预示着：软件测试正作为一门独立的，专业的，具有影响力的工程学发展起来了。
预防为主(1988–至今)
　　预防为主是当下软件测试的主流思想之一。STEP(Systematic Test and Evaluation Process)是最早的一个以预防为主的生命周期模型，STEP认为测试与开发是并行的，整个测试的生命周期也是由计划，分析，设计，开发，执行和维护组成，也就是说，测试不是在编码完成后才开始介入，而是贯穿于整个软件生命周期。我们都知道，没有100%完美的软件，零缺陷是不可能的，所以我们要做的是：尽量早的介入，尽量早的发现这些明显的或隐藏的bug，发现得越早，修复起来的成本越低，产生的风险也越小。
　　虽然每一个发展阶段对软件测试的认识都有其局限性，但是前辈们一直在思考和总结前人的经验，创造性地提出新的理论和方向，这种精神非常值得尊敬和学习。所谓以铜为镜，可正衣冠；以史为镜，可明得失。知道了从哪里来，方能更好的明白该到哪里去。

当下主流测试模式

在目前较流行的敏捷开发模式中，推崇“测试驱动开发）”—测试在先、编码在后的开发实践。
同时，在IBM Rational Unified Process(RUP)中也把这种模式称为“测试优先的设计（test-first design）”。
  • 促进开发人员思考功能特性的应用场景、异常情况或边界条件，写出更完善的代码，避免犯较多的错误。
  • 确保测试具有独立性，不受实现思维的影响，确保测试的客观、全面。如果是倒过来，先写产品代码（即功能实现在前）再进行测试，那么测试会受实现思维影响。
  • 确保所有代码的可测试性，每一行代码得到了测试，比较彻底地确保代码的（微观）质量。
许多研发人员不习惯UTDD这种模式，推行UTDD会遇到比较大的困难，那TDD的实施可以移到业务层，推行ATDD，即在设计、写代码之前，明确系统功能特性的验收标准，这比较容易推广实施。
从ATDD演化出来一种具体落地的开发模式就是BDD（Behavior Driven Development，行为驱动开发）。BDD只是将验收标准更加明确化，可以看作是ATDD的实例化，即列出所有可能遇到的应用场景，而且将这种应用场景的表达方式规定为GWT格式
需求越明确，用户、产品经理、开发与测试等之间的理解就越一致（on the same page），更不产生偏差和误解，有利于开发和测试的工作。基于RBE，开发人员写产品的代码，测试人员可以独立写测试的代码，产品经理的工作也会变得轻松，不需要太多的解释、不需要回答开发和测试的各种问题。
从需求角度看，BDD和需求实例化比较彻底地明确需求，统一用户、产品经理、开发与测试等认识，让大家处在一个层面上，使研发工作更高效。
从测试角度看，需求即测试，产品的需求就是测试的需求，需求可以被执行，即一步到位，将需求变为自动化测试脚本，开发出来的功能特性随时可以被自动验证
TDD一改以往的破坏性测试的思维方式，测试在先、编码在后，更符合“缺陷预防”的思想。这样一来，编码的思维方式发生了很大的变化，编写出高质量的代码去通过这些测试，在进行每项设计、写每一行代码时都要想想用户的真实需求、应用场景和一些例外等，确保实现的功能特性符合预期，并具有健壮性。
在这种良性的测试模式的影响下，开发人员的工作效率和产品的质量都会有显著的提高，真正实现“质量是内建的（Quality is built in）”的目标。
测试理论
  • 黑盒测试
  • 白盒测试
  • 测试阶段划分
  • 负载压力测试
  • 接口测试

黑盒测试

黑盒测试，也称功能测试，通过测试来检测每个功能是否都能正常使用。在测试中，把程序看作一个不能打开的黑盒子，在完全不考虑内部结构和内部特性的情况下，在程序接口进行测试， 它只能检查功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息。

主要试图发现的几类错误

  • 功能不正确或遗漏
  • 界面错误
  • 输入和输出错误
  • 数据库访问错误
  • 性能错误
  • 初始化和终止错误等

测试方法

白盒测试

它也称结构测试或逻辑驱动测试， 它是按照程序内部的结构测试程序，通过测试来检测产品内部动作是否按照设计规格说明书的规定正常进行，检验程序中的每条通路是否都能按预定的要求正确工作。

测试方法

测试阶段划分（分单元测试，集成测试， 系统测试 不仅包括软件本身， 而且还包括计算机硬件及其相关的外围设备、实际运行时大批量数据、非正常操作(如黑客攻击)等，通常意义上的系统测试包括压力测试、容量测试、性能测试、安全测试、容错测试等）
负载压力测试（性能测试的重要组成部分，包括并发性能测试，疲劳强度测试、大数据量测试等内容）
接口测试（函数级别， 对象级别， http协议接口，测试的重点检查数据的交换，传递和控制管理过程，还包括处理的次数）

测试技术

  • 测试引擎（Node.js）
  • 测试用例
  • 单元测试（Jest）
  • 集成测试（Nightmare）
  • 测试报告

测试展望（机遇&挑战）

挑战：目前测试存在的“提前测试”、“期望结果明确”这个两个特点，但随着云计算，大数据，人工智能的发展业务繁杂度进一步增加，“提前测试”已经力不从心，所以测试人员如何能基于大数据智能调整哪些功能展现给哪些用户？如何在测试一个人工智能产品也能设计出用户常用case？
机遇：虽然新的技术、思想层出不穷，但是一个产品要顺利交付给客户，质量把关是必不可少的，测试人员时刻要牢记测试的最终目的是为了快速成功的交付所测试的产品，为了这个最终目的，测试人员需要通过各种方式增加测试的价值。另外，测试人员还需牢记，你不仅仅是测试，你是整个产品团队的一部分，应对整个团队效率负责，你存在的价值是帮助组织快速交付。
未来随着人工智能技术趋于成熟，测试这个职位可能会消失，但是每个客户对于软件质量的要求不仅不会消失，反而会不断增强，这将会是测试人员最好的时代，是属于我们测试的改革开放！

下期预告

  • Node环境的搭建
  • Jest、Nightmare基本使用方法
  • 单元测试方法讲解
  • 基于型云平台集成测试讲解

谢谢观赏

Excelsior