深入到系统组件是否白盒测试_软件测试第一讲--测试基础概述

软件测试就是一系列活动，这些活动是为了评估一个程序或软件系统的特性或能力，并确定其是否达到了预期结果。软件测试的目的是为了把控软件的质量，提升用户的使用体验。

迄今为止，软件测试的发展一共经历了五个重要时期：

· 1957年之前－调试为主(Debugging Oriented)：确保程序做了期望的事情。

· 1957–1978－证明为主(Demonstration Oriented)：确保程序能够解决事情。

· 1979–1982－破坏为主(Destruction Oriented)：确保程序没有做不该做的事情。

· 1983–1987－评估为主(Evaluation Oriented)：确保有独立人员能够保证程序所做的事情。

· 1988–至今－预防为主(Prevention Oriented)：确保尽早发现程序的不该做的事情。

当今无论是一线大厂，还是小的创业公司，都有自己的一套测试流程，其实它们的测试流程都大同小异。基本都会包括下面的流程步骤：

需求分析不仅包括客户提出来期望达到的使用效果，而且也要保证其他隐形的客户需求(包括稳定，界面，安全，易用等)。

测试策略就是要知道“测试什么”和“怎么测试”，测试策略制定的时候需要确认测试目标以及重点和难点，另外测试的深度和广度(深度就是需要选择是否进行单元测试，集成测试，系统测试，选择哪一种测试作为通过的标准；广度就是测试满足基本功能测试外，是否需要进行其他非功能测试(安全测试 压力测试 负载测试等))。

测试计划，测试的具体工作时间安排，描述了要进行的测试活动的范围、方法、资源和进度的文档。

测试用例设计，针对需求设计的检查步骤，描述输入、动作、或者时间和一个期望的结果，其目的是确定应用程序的某个特性是否正常的工作。

测试用例评审，项目中各个干系人对测试用例设计的具体步骤进行走查，检查步骤的不足和缺陷，并且给出修改意见。

测试用例执行，测试人员对设计的用例进行手工执行或通过自动化脚本自动执行。

回归测试，开发人员对测试用例执行后提交的bug进行修复，测试人员对失败的测试用例再次执行并确认是否执行成功。

测试评估，测试人员完成测试用例执行，编写测试报告，提交项目管理人员进行审核。

软件测试的生命周期跟软件的开发周期匹配，软件测试的生命周期依赖软件的开发周期。迄今为止，软件的开发周期经历了好几个阶段：瀑布模型，V模型，W模型，螺旋模型，迭代模型等。我们就软件开发的这些周期详细谈谈软件测试的生命周期。

瀑布模型：

优点：瀑布模型为项目提供了按阶段划分的检查点，只需按照顺序来关注测试的节点。

缺点：由于项目各个阶段之间很少有反馈，在项目周期后期才看到测试结果，测试发现问题后修复成本高。

V模型：

优点：过程从左到右，描述了基本的开发过程和测试行为，明确了测试过程中存在的不同级别和开发过程和测试阶段对应关系。

缺点：正式进入测试时，有些BUG不容易找到根源，代码修改困难，需求变更大就返工量也大，软件测试不能很好的贯穿整个开发阶段，导致最后阶段才是测试。

W模型：

优点：测试和开发是同步进行的，测试的对象不仅包含程序，还有需求和设计，可尽早发现软件缺陷，降低软件开发成本。

缺点：需求，设计，编码是串行的，测试和开发需要上阶段完全结束，才正式开始下一阶段。

螺旋模型：

优点：由于螺旋模型强调软件的重用，从而减少了多个测试，减少资源浪费。

缺点：项目比较大，测试成本较高。

迭代模型：

优点：测试聚焦在某一部分，在较小的迭代中进行测试和调试很容易。

缺点：可能会引入一些回归测试，从而需要更多资源，

软件测试的分类

相信大家很多答案，例如单元测试，集成测试，白盒测试，黑盒测试，回归测试，冒烟测试等，其实这些不同的答案就是源于不同的划分标准，软件测试的分类导图如下：

单元测试：单个组件内部测试。

集成测试：两个或以上的组件集成在一起进行测试。

系统测试：多个组件组成一个整体系统，再进行测试。

验收测试： α测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试，Alpha测试不能由程序员或测试员完成。

β测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试，开发者通常不在测试现场，Beta测试不能由程序员或测试员完成。

正式测试：一项管理严格的过程，它通常是系统测试的延续。正式验收测试则完全由最终用户组织执行，或者由最终用户组织选择人员组成一个客观公正的小组来执行。

静态测试：不运行代码进行的测试，包括代码走查，检查代码编写规范，编写语法等。

动态测试：运行代码进行的测试，检查代码是否满足需求。

白盒测试：编写测试用例对代码内部实现进行测试。

黑盒测试：把待测试内容看成一个黑盒子，关注输入输出是否满足需求。

灰盒测试：又称为接口测试，白盒测试只关注单个组件内部的测试，没有关注到多个组件的交互测试，黑盒测试是主要关注是多个组件集成在一起的功能测试，测试的反馈较晚。接口测试介于白盒和黑盒测试之间，它的优势包括测试的成本低，测试发现的问题可以更早发现，另外接口规范的定义有利于开发效率和质量。

负载测试：模拟实际软件系统所承受的负载条件的系统负荷，通过不断加载(如逐渐增加模拟用户的数量)或其它加载方式来观察不同负载下系统的响应时间和数据吞吐量、系统占用的资源(如CPU、内存)等。

压力测试：在强负载(大数据量、大量并发用户等)下的测试，查看应用系统在峰值使用情况下操作行为，从而有效地发现系统的某项功能隐患、系统是否具有良好的容错能力和可恢复能力。

回归测试：不管是修复缺陷或新的功能修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。

冒烟测试：针对每个版本或每次需求变更后，在正式测试前，对产品或系统的一次简单的验证性测试。未正式测试前，验证是否产品或系统的主要需求或预置条件是否存在bug。

探索测试：一种测试思维技术。它没有很多实际的测试方法、技术和工具，但是却是所有测试人员都应该掌握的一种测试思维方式。探索性强调测试人员的主观能动性，抛弃繁杂的测试计划和测试用例设计过程，强调在碰到问题时及时改变测试策略。

测试分层的模型：

常见的测试分层模型包括金字塔模型和橄榄模型(不倒翁模型)。

金字塔模型：

金字塔模型想告诉我们的几个道理：

1. 越底层，越稳定；越底层，成本越低；越早发现问题，修复的成本自然越低。

2. 越底层，越高效。越底层，测试执行越快。

3. 越底层，越难实施。越底层的实现对技术专业性要求越高。

橄榄模型：

综合下金字塔模型的一些不足，提出了橄榄模型(不倒翁模型)，拿接口测试和UI层测试以及单元测试做了比较，最终认定接口(API)测试可以获得较高的投资回报。

接口测试和UI/单元测试相比有很多优势，通常单元测试是针对代码进行的测试，而接口测试是在测试一个经过部署的系统。另外，单个接口测试与单个单元测试用例相比，也可以覆盖更多的代码。

而相比UI自动化用例，接口测试更加的简单直接，执行效率更高。 某些情况下，API的测试条件覆盖率甚至可以多过UI。

测试用例设计：

测试用例：是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，用于核实是否满足某个特定软件需求。

测试用例通常包括下面一些元素：用例编号、用例标题、用例级别、测试数据、测试步骤、前提条件、预期结果、实际结果、状态、测试人、测试时间、备注等。

常用的测试用例设计方法：

常用的三种方法是等价类划分、边界值分析、错误推测法。下面就结合具体的实际例子，详细介绍一下这几种方法。

等价类划分：

一个输入框字段A的取值范围是-99 和 99 之间的整数。

边界值分析：

针对上面的例子，边界值就是找出上面取值范围中的边界值进行测试。

错误推测法：

错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例. 例如年龄不能为负数，手机号码有效等。

场景法：

一个网站需要用户注册，注册页面包括输入项手机号码和验证码，基本流程就是输入正确的手机号码和验证码后用户注册成功(a -> b -> d)，当出现异常情况，比如验证码输入错误后，提示用户输入正确验证码，两个输入字段都正确后再提示注册成功(a -> b -> c -> e)。

如何设计好的测试用例：

有的人说 “发现bug的测试用例”就是好用例，有的人说 “发现bug可能性大的测试用例”就是好用例。好的测试用例一定是一个完备的集合，它能够覆盖所有等价类以及各种边界值，而跟能否发现缺陷无关。

引用网上一个很好的例子， “如果把被测试软件看作一个池塘，软件缺陷是池塘中的鱼，建立测试用例集的过程就像是在编织一张捕鱼网。“好的”测试用例集就是一张能够覆盖整个池塘的大鱼网，只要池塘里有鱼，这个鱼网就一定能把鱼捞上来。如果鱼网本身是完整的且合格的，那么捞不到鱼，就证明池塘中没有鱼，而鱼网的好坏与池塘中是否有鱼无关。”

编写测试用例的最终目标是：一个对于产品毫无所知的人员，也能够快速的熟悉用例并执行用例。

好的测试用例必须具备以下三个特征：

1. 有效测试用例组成的集合，能够完全覆盖测试需求。

2. 对于每个等价类都能保证只要其中一个输入测试通过，其他输入也一定测试通过。

3. 需要保证所有可能的边界值和边界条件都已经正确识别。