软件测试基础-概念篇——慕课网
软件测试基础-概念篇——慕课网
测试用例
测试用例 = 输入+输出+测试环境
- 输入：包括测试数据和操作步骤
- 输出：指的是期望结果
- 测试环境：指的就是系统环境配置
4W ：Why、When、Who、What
- Why（我们为什么要写测试用例）
便与团队交流
便于重复测试
便于跟踪统计
便于用户自测 - When（什么时候写测试用例）
通常会在测试阶段来写用例，即《需求规格说明书》和《测试计划》都已完成之后 - Who（由谁来写用例）
- What（根据什么来写用例）
编写测试用例的唯一标准就是用户需求，具体参考资料就是《系统需求规格说明书》和软件原型，其中软件原型指的是没有嵌入全部源代码的软件界面
软件测试的分类
- 按测试阶段来分类
- 按测试手段来分类
- 按测试模式来分类
- 按测试类型来分类
1、按测试阶段来分类：
- 单元测试
- 集成测试
- 系统测试
- 验收测试
单元测试
定义：对软件中的最小可测试单元进行检查和验证。
单元测试的原则
- 尽可能保证各个测试用例是互相独立的
- 一般由代码的开发人员来实施，用以检验所开发的代码功能符合自己的设计要求
单元测试的益处
- 尽早的发现缺陷
- 有利于重构
- 简化集成
- 文档
- 用于设计
单元测试的限制
- 不可能覆盖所有的执行路径，所以不可能保证捕捉到所有路径的错误
- 每一段代码，一般需要3-5行测试代码才能完成单元测试，所以存在投入和产出的一个平衡
桩模块和驱动模块
- 桩模块(Stub)是指模拟被测模块所调用的模块
- 驱动模块(Driver)是指模拟被测模块的上级模块，驱动模块用来接受测试数据，启动被测模块并输出结果
集成测试
定义：是在单元测试的基础上，测试在将所有的软件单元按照概要设计规格说明书的要求组装成模块、子系统或系统的过程中各部分工作是否达到或实现相应技术指标及要求的活动。
集成测试的主要实施方案
- Big Bang ：一次性集成
- 自顶向下：从主程序开始，沿控制层，逐层向下来测试
- 自底向上(最常用)： 针对已经组装过的测试，优点是 能够比较好的锁定软件故障的所在位置
- 核心系统集成：先把核心的软件部分挑选出来，并对这些部件进行集成测试，在测试通过的基础上，再逐步扩展到外围的一些部件，直到形成稳定的软件产品
- 高频集成：同步于软件开发过程，每隔一段时间，开发成员就对现有的代码进行一次集成测试
集成测试的单元测试区别
- 测试对象不同
单元测试针对的是软件的基本单元，最小的单元所进行的测试
集成测试是以模块和子系统为单元进行的测试，主要测试模块和模块之间接口的关系 - 测试的依据不同
单元测试主要针对软件的详细设计来做测试，测试用例主要的依据为详细设计的文档
集成测试主要针对软件的概要设计来做测试，测试用例的主要依据为概要设计文档 - 测试方法不同
集成测试关注的是模块之间接口的集成，而单元测试只关心在单元的内部
系统测试
定义：是将经过集成测试的软件，作为计算机系统的一个部分，与系统中其他部分结合起来，在实际运行环境下对计算机系统进行一系列严格有效地测试，以发现软件潜在的问题，保证系统的正常运行。
功能测试、性能测试、稳定性测试
测试人员主要针对系统测试
关注点
- 关注系统本身的使用
- 关注系统与其他相关系统之间的连通
- 关注系统在不同使用压力下的表现
- 关注系统在真实使用环境下的表现
系统测试和集成测试的区别
- 测试对象不同
集成测试：由通过了单元测试的各个模块所集成起来的构件
系统测试：除了软件之外，还包括计算机硬件及相关的外围设备、数据采集和传输机构、支持软件、系统操作人员等整个系统 - 测试时间不同
集成测试介于单元测试和系统测试之间的测试
系统测试在集成测试之后 - 测试内容
集成测试：各个单元模块之间的接口
系统测试：整个系统的功能和性能 - 测试角度
集成测试：偏于技术角度的验证
系统测试：偏于业务角度的验证
验收测试
定义：也称交付测试，针对用户需求、业务流程的正式的测试，确定系统是否满足验收标准，由用户、客户或其他授权机构决定是否接受系统。
细分：
- 用户验收测试：在开发方移交产品之前来运行的测试，测试的执行人还是我们的开发方
- 运行验收测试：更多从运维的方面来看我们这个系统是否可以被正常运行和正常维护
- 合同和规范验收测试
- alpha测试：在开发者所提供的场所和环境中来运行，一般由用户来执行，但场所和环境由开发者提供
- Beta测试：完全脱离了开发者的环境，在用户提供的场所或环境下来进行测试。
复习：
单元测试是我们各个阶段测试的基础，测试的对象时最小的可测试单元
集成测试关注的是各个最小单元模块之间的接口和子系统的集成
系统测试是把整个系统组装以后置于真实的运行环境，对这个系统进行全面的评估
验收测试强调的是从用户角度来对系统软件的认可和验收
按测试手段来分类
2、按测试手段来分类：
- 黑盒测试、白盒测试
- 静态测试、验收测试
- 手工测试、自动化测试
黑盒测试
定义：在测试中把我们被测的系统或者软件看成是一个不能打开的盒子，在完全不考虑程序内部结构和内部特性的情况下，通过相关暴露出来的接口来对程序进行测试
只检查程序的功能是否能够按照需求规格说明的规定能够正常的使用，程序是否能接受适当的输入数据并产生正确的输出信息
黑盒测试是对程序的外部结构，不考虑内部的逻辑，一般来说，是针对软件外面的界面，或者说是可见的功能来进行测试
黑盒测试更多的根据用户的视角，通过不同的数据和事件来驱动我们的系统，并通过输出结果来进行判断
黑盒测试的优缺点
优点：
- 容易实施，不需要关注内部的实现
- 更贴近用户的使用角度
缺点：
- 测试覆盖率较低，一般只能覆盖到代码量的不到40%
- 针对黑盒的自动化测试，复用率较低，维护成本较高
黑盒测试主要测试什么
- 是否有不正确或遗漏的功能
- 在接口上，输入是否能正确的接受，能否输出正确的结果
- 是否有数据结构的错误或外部信息(例如数据文件)访问错误
- 性能上是否能够满足要求
一般来说，在系统测试阶段我们会更多的使借助黑盒测试来实施我们的软件测试
黑盒测试的主要设计方法
白盒测试
定义：内部的逻辑结构对测试人员是透明的，白盒测试又称为结构化测试和透明盒测试
白盒测试是针对程序的逻辑结构来设计测试用例，用逻辑的覆盖率来测试程序的完整性
主要的逻辑单位
语句、条件、条件组合、分支、路径
白盒测试的优缺点
优点：
1、迫使测试人员去仔细思考软件的实现，理解原理
2、可以检测代码中的每条分支和路径
3、揭示隐藏在代码中的错误
4、对代码的测试比较彻底
缺点：
1、昂贵(要做到较高的覆盖率，工作量很大，成本高)
2、无法检测代码中遗漏的路径和数据敏感性错误
3、不能直接验证需求的正确性
白盒测试的主要测试方法
灰盒测试
介于黑、白盒测试之间的，关注输出对于输入的正确性，同时也关注内部表现
静态测试
定义：指无需执行被测程序，而是通过评审软件文档或代码，度量程序静态复杂度，检查软件是否符合编程标准，借以发现编写的程序的不足之处，减少错误出现的概率
静态测试的方式
动态测试
定义：指通过运行被测程序，检查运行结果与预期结果的差异，并分析运行效率、正确性和健壮性等。
手工测试
定义：由专门的测试人员从用户视角来验证软件是否满足设计要求的行为。更适用针对深度的测试和强调主观判断的测试。
如：众包测试、探索式测试
自动化测试
定义：使用单独的测试工具软件控制测试的自动化执行以及对预期和结果进行自动检查。
如：单元测试、接口测试、性能测试等
总结：
黑盒测试：指的是把测试的对象看成一个黑盒，不了解内部的逻辑和结构，从用户的角度来对软件进行测试的方法
白盒测试：测试人员完全了解程序的内部结构和设计逻辑的，通过逻辑的覆盖来保证测试的完整性
静态测试：指不运行被测软件，通过静态的检查代码、文档来进行测试
动态测试：把软件运行起来，通过运行的表现来判断软件运行的功能是否正常
手工测试：由专门的测试人员根据测试用例来实施的测试
自动化测试：借助第三方的测试工具，来自动化的运行和检查我们的测试
3、按测试模式来分类：
- 瀑布模型
- V模型
- W模型
- 敏捷测试
传统的瀑布模型
瀑布模型每一个阶段都是以上一个阶段的输出作为下一个阶段的输入。
项目计划阶段：制定项目整体的研发计划，确定主要的里程碑结点，这个阶段需要输出项目计划书
需求分析阶段：明确用户的需求定义，并对这个定义进行清晰的描述，是充分理解客户需求，了解产品功能的重要阶段，这个阶段会输出产品的规格说明书
软件设计阶段：会根据需求的定义，来确定产品实现的方案，包括定义软件、硬件的结构，组件、模块的实现方法，接口、界面、数据如何进行组织，这个阶段会输出包括概要设计、详细设计在内的多份设计说明书
程序开发阶段：由开发团队来根据需求和设计来具体的实现产品，来根据编程规范构建各类的组件模块，最后输出我们的产品版本
软件测试阶段：通过独立的测试小组来评估我们的产品是否满足需求的定义，最后输出测试结果、测试报告
集成维护阶段：产品经过测试以后交付给用户，根据用户的使用情况来对产品进行维护、以及必要的修改、升级的操作
瀑布模型的优点：
- 强调需求、设计的作用
- 前一阶段完成后，只需关注后续阶段
- 为项目提供了按阶段划分的检查点，里程碑清晰
- 文档规范
瀑布模型的缺点：
- 难以适应需求的频繁变化
- 项目周期后段才能看到成果
- 强制的里程碑、完成时间点
- 文档工作量大
从测试的角度来看，瀑布模型并没有体现出软件测试的地位和价值，测试阶段只是一个补救的工作阶段，因为软件测试阶段是在研发阶段的后期，缺陷发现的比较晚，从缺陷和研发的关系，成本会很高V模型
V模型是目前使用最广泛的一种模型，它是在80年代，由Paul Rock提出的，是瀑布模型的变种，在V模型中明确表明了测试过程的不同阶段(单元测试、集成测试、系统测试、验收测试)，并且描述了这些阶段与开发过程各个阶段的对应关系
单元测试、集成测试：检测程序是否满足设计上的要求
系统测试：检测软件在功能、性能这些质量特性上是否能够满足系统要求的一些指标
验收测试：确定软件是否满足用户的最后需求以及合同的规定
在V模型里强调了软件开发的协作和速度，反映测试活动和分析设计的关系，并且将软件的实现和验证有机的结合起来，V模型中明确的界定测试过程是存在不同阶段的，明确了不同的测试阶段和研发过程当中每个阶段的对应关系
V模型的局限性
仅仅把测试过程作为在需求分析、系统设计和编码之后的一个阶段，忽视了测试对于需求的分析和验证，对需求的验证和对系统验证要一直到后期的验收测试才能够发现。在测试当中“测试需要尽早的执行”，在V模型中没有体现
W模型
W模型也称双V模型，它是由Evolutif公司提出的对于V模型的改进，相对于V模型，W模型增加了软件开发各个阶段中同步来进行验证和确认工作，测试是伴随着整个开发周期来进行的，测试的对象也不再仅仅是程序，它对需求、设计都要进行相应的测试，基本上开发和测试是两个并行的流程，W模型有利于我们尽早的来发现问题，同时对V模型只能在后期发现问题进行了改进，W模型有利于及时的了解项目的测试风险，来及早的制定相应的应对方案，加快项目的进度。
W模型的局限性
在W模型中，需求、设计、编码仍然是串行的，测试和开发保持着一种线性的先后关系，再上一个阶段完成之后才能进行下一个阶段，所以W模型不能很好的支持像迭代这样的开发模型
X模型
Marrick针对V模型提出的改进，主要是解决交接和频繁集成的周期的问题
X模型的左边描述的是针对单独的程序片段所进行的相互分离的编码和测试，此后进行频繁的一个交接，再通过集成最终合成可执行的程序，对这些程序进行测试，像右上半部分一样，这些可执行程序还是需要测试，已经通过集成测试的成品可以进行封版提交给用户，也可以作为更大规模集成的一部分。
X模型还定位了探索式测试，探索式测试是不进行事先计划的一种特殊类型的测试，它能够帮助测试人员在测试计划之外发现更多的软件错误。
H模型
把软件测试看成是完全独立的流程，贯穿在整个产品的生命周期当中，与其他的流程并发的进行，这里的其它流程可以是软件的其它的开发流程，比如设计流程、编码流程，也可以是测试流程。
H模型强调把测试流程分为测试准备和测试执行两个不同的阶段，只要由于其他流程的进展引发了测试就绪点的到位，这个时候，只要测试准备活动完成，测试执行活动就可以或者说需要开展，在H模型当中，因为测试是一个完全独立的流程，所以它可以和其它的流程交叉的进行，也便于我们尽早的来执行测试
4、按测试类型来分类：
功能测试
是软件测试中最主要的一种测试类型
根据产品特性、操作描述和用户方案，测试一个产品特性和可操作行为以确定它们满足满足设计需求
针对的问题
功能错误或遗漏、界面问题、性能问题、数据及访问错误初始化及终止错误
功能测试工具：QTP/winrunner、silkTest、Rational robot、selenium、Watir、Sikuli
性能测试
负载测试：指的是在测试过程中来逐步增加负载，并且记录下被测系统相应的性能表现，最终确定出系统在正常的指标范围下最大的负载
压力测试：测试系统在极限情况下的压力情况，也就是要确定我们的系统在什么样的负载压力下会导致系统的失效，不能够正常运行，确定出系统的最大的极限
稳定性测试：一般以稍大于正常业务量的一个负载，对系统进行持续的、长时间的测试，以确定系统在较长时间运行下的稳定性的情况
性能指标
并发用户数VU
美妙事务数TPS
系统响应时间
设备性能
性能测试工具
LoadRunner、Silkperformer、Jmeter、WebLoad、Apache Bench、LoadUI
静态性能评估
开发Web应用时，基于一系列Web应用页面性能优化的最佳实践对Web应用的页面进行静态分析，并给出评估结果的性能分析方法
工具：YSlow、PageSpeed
应用性能管理(APM)
Application performmance Mangement，提供对系统的实时监控以实现性能管理、故障管理的方案
安全测试
定义：对软件产品进行测试以确保其符合产品安全需求和质量标准
渗透测试
定义：通过模拟对软件系统的恶意攻击行为来评估系统安全性的一种测试
兼容性测试
软件本身的兼容性
不同平台下的兼容性
软件对运行设备的兼容性
软件互操作性
浏览器兼容性测试工具
BrowerShots：基于模拟和真实浏览器进行截图比对的工具
Browser Sandbox
Google 浏览器兼容测试插件
文档测试
定义：针对软件产品的交付品，配套的文档类部件的测试。如用户手册、使用说明、用户帮助文档等
文档测试关注要点
完整性、正确性、一致性、易理解性、易浏览性
可靠性测试
软件的可靠性
硬件的可靠性
易用性测试
易用性测试是指测试用户使用软件时是否感觉方便，是否能保证用户使用体验的测试类型
本地化测试
针对软件的本地化版本实施的针对性测试
主要测试内容
语言、书写习惯
时区、日期格式、货币
当地风俗、法律法规
在不同环境下的部署验证
参照部署文档执行、过程的合理、正确性
基础数据
无障碍测试
Accessibility Test. 也称为可访问性测试。是指软件需要提供便于特殊人群使用的功能，包括视障、听障、老年人、身体残疾用户等，无障碍测试则是针对这部分功能的测试