第二章 软件测试理论进阶
本章重点
1、了解软件测试复杂性与经济性
2、掌握软件测试的阶段
3、掌握软件测试的方法
4、掌握软件测试的分类
5、理解常见软件测试过程模型
一、软件测试复杂性与经济性
软件测试的复杂性
(1)、完全测试是不现实的
(2)、软件测试是有风险的
(3)、杀虫剂现象
(4)、缺陷的不确定性
软件测试的经济性
测试费用除了测试的直接消耗外，还包括其它的相关费用。测试费用的主要因素有：
(1)、软件面向的目标用户
(2)、可能出现的用户数量
(3)、潜在缺陷造成的影响
(4)、开发机构的业务能力
软件测试的充分性
软件测试的充分性与软件的需求、软件的实现都相关；软件测试的充分性准则有以下几点：
(1)、有限的充分测试集合 对任何软件都存在；
(2)、软件测试的单调性 当一个测试的数据集和对于一个被测的软件系统的测试是充分的，那么再多增加一些测试数据仍然是充分的；
(3)、软件测试的非复合性 即使对软件所有成分都进行了充分的测试，也并不意味着整个软件的测试已经充分了；
(4)、软件测试的非分解性 即使对一个软件系统整体的测试是充分的，也并不意味着软件系统中各个成分都已经充分地得到了测试；
(5)、软件测试的复杂性 软件测试的数据量正比于软件的复杂度；
练习：
1、自动化测试能代替人工测试？
2、现在软件测试人员比较紧缺，可以让其他时间富裕的员工来做这项工作？
3、软件发布后出现了问题，是软件测试人员没有测试好。
二、软件测试的阶段
单元测试
又称模块测试，指对软件中的最小可测试单元进行检查和验证。
（1）、什么时候进行单元测试
常在程序员编码之后，代码已经通过编译后进行单元测试，且在前期就应该做一些准备工作（撰写单元测试计划、编写单元测试用例等）
（2）、由谁来进行单元测试
一般由白盒测试工程师或开发人员来测试
（3）、单元测试的依据是什么
源程序本身，包括代码和注释，项目的《详细设计》文档
（4）、单元测试的通过标准是什么
程序通过所有单元测试的用例，语句的覆盖率达到100%，分支的覆盖率达到85%
（5）、如何进行单元测试
主要用白盒测试方法，一般先静态地检查代码是否符合规范，然后动态地运行代码，检查其实际运行结果
集成测试
将通过测试的单元模块组装成系统或子系统，再进行测试，又称接口测试；重点测试不同模块的接口部分（如函数间的参数传递是否正确）。
（1）、什么时候进行集成测试
常是单元和集成同步进行，是单元测试的下一个阶段
（2）、由谁来进行集成测试
一般由白盒测试工程师或开发人员来测试
（3）、集成测试的依据是什么
单元测试的模块及《概要设计》文档
系统测试
指的是将整个软件系统看作1个整体进行测试，包括对功能、性能，以及软件所运行的软硬件环境进行测试
（1）、什么时候进行系统测试
在整个系统集成完成后进行测试；前期主要测试系统的功能是否满足需求；后期主要测试系统运行的性能是否满足需求及系统在不同的软硬件环境中的兼容性等
（2）、由谁来进行系统测试
黑盒测试工程师
（3）、系统测试的依据是什么
主要依据是《系统需求规格说明书》文档
验收测试
指的是在系统测试的后期，以用户测试为主，或有测试人员等质量保障人员共同参与的测试，它也是软件正式交给用户使用的最后一道工序
重要性：涉及用户能否最终验收签字并付款
【项目软件的运营方式：20%定金?中期评审50%?最终验收30%】
验收测试又分为α测试和β测试，
α测试：指的是由用户、测试人员、开发人员等共同参与的内部测试
β测试：指的是内侧后的公测，即完全交给最终用户测试（也叫UAT测试）
测试阶段与测试用例类型关系表：
测试阶段 测试类型 执行人员
单元测试 模块功能测试，包含部分接口测试、路径测试 开发人员
集成测试 接口测试、路径测试，含部分功能测试 开发人员，如果测试人员水平较高可以由测试人员执行
系统测试 功能测试、健壮性测试、性能测试、用户界面测试、安全性测试、压力测试、可靠性测试、安装/反安装测试 测试人员
验收测试 对于实际项目基本同上，并包含文档测试；对于软件产品主要测试相关技术文档 测试人员，可能包含用户
三、软件测试的方法
静态测试
不实际运行被测软件，而只是静态地检查程序代码、界面或文档中可能存在的错误的过程。
动态测试
实际运行被测软件，输入相应的测试数据，检查实际输出结果和预期结果是否相符的过程。
黑盒测试
这种方法是把测试对象看做一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明。因此黑盒测试又叫功能测试或数据驱动测试。
白盒测试
这种方法是把测试对象看做一个打开的盒子，它允许测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。通过在不同点检查程序状态，确定实际状态是否与预期的状态一致。因此白盒测试又称为结构测试或逻辑驱动测试 。
灰盒测试
是介于黑、白盒测试之间的，关注输出对于输入的正确性，同时也关注内部表现。灰盒测试结合了白盒测试盒黑盒测试的要素.它考虑了用户端、特定的系统知识和操作环境。
四、软件测试的分类
不同测试分类的关系如下图
功能测试
是黑盒测试的一方面，它检查实际软件的功能是否符合用户的需求。
功能测试又可以细分为很多种：
1、逻辑功能测试 【最重要】
需要编写一系列的测试用例来测试各种逻辑功能。
2、界面测试
一般把软件的界面测试用例同软件的逻辑功能测试用例分开写，用一种简化的测试用例形式（检查单）；检查单中不涉及具体逻辑功能实现，只是关于菜单布局、字体、风格等界面上的问题
3、易用性测试
指从软件使用的合理性和方便性等角度对软件系统进行检查，来发现软件中不方便用户使用的地方
4、安装测试
包括安装和卸载 ；安装是用户使用软件的第一步，也是用户对软件的第一印象；要把安装测试作为一个独立的任务，编写软件的安装、卸载测试用例
5、兼容性测试：
包括硬件兼容性测试和软件兼容性测试
硬件兼容性测试：软件运行在不同硬件平台的兼容性，如PC机、笔记本、服务器等
软件兼容性测试：项目软件的软硬件环境相对固定，只需要在最终用户的使用环境下测试即可，一般不用考虑兼容性测试
性能测试
软件的性能包括很多方面，主要有时间性能和空间性能两种
时间性能：主要指软件的一个具体事务的响应时间（请求响应间隔时间为3秒）
空间性能：主要指软件运行时所消耗的系统资源（某软件安装要求）
1、一般性能测试
指的是让被测系统在正常的软硬件环境下运行，不向其施加任何压力的性能测试。
2、稳定性测试
也叫可靠性测试，指连续运行内测系统，检查系统运行时的稳定程度
3、负载测试
指让被测系统在其能忍受的极限范围之内连续运行，来测试系统的稳定性
4、压力测试
指连续不断地给被测系统增加压力，直到将被测系统压垮为止，用来测试系统所能承受的最大压力
关于性能测试的生活案例：
假设一个人很轻松的就能背一袋米，背两袋米很吃力，最多就能背三袋米，那么：
一般性能测试：我就让他背一袋米
稳定性测试：我让他背一袋米，但是让他去操场上跑圈，看多久累倒。
负载测试：我让他背两袋米去操场上跑圈，看多久累倒。
压力测试：我让他背两袋米，三袋米，四袋米…发现他最多就能背三袋米。
回归测试
指对软件的新的版本测试时，重复执行上一个版本测试时的用例
冒烟测试
指在对一个新版本进行大规模的测试之前，先验证一下软件的基本功能是否可以实现，是否具备可测性
随机测试
指测试中所有的输入数据都是都是随机生成的，其目的是模拟用户的真是操作，并发现一些边缘的错误
五、软件测试过程模型
软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试、运行维护。
瀑布模型
传统的瀑布模型，软件测试的地位和价值并没有体现出来，测试只能作为一个事后补救工作。早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果。由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加 了开发的风险。
V模型
V模型是最广为人知的测试模型，非常明确地标明了测试过程中存在的不同级别，描述了这些测试阶段和开发过程期间各阶段的对应关系
V模型的缺点：
存在局限性，仅仅把测试过程作为在需求分析、系统设计及编码之后的一个阶段，只针对程序进行的寻找错误的活动，忽视了测试活动对需求分析,系统设计等活动的验证和确认的功能。
W模型
W模型是测试伴随整个软件开发周期，而且测试的对象不仅仅是程序，需求、设计等同样要测试，测试与开发是同步进行的。W模型从V模型演化过来，相对于V模型，W模型增加了软件各开发阶段中应同步进行的验证和确认活动。
对于当前软件开发复杂多变的情况，W模型并不能解除测试管理面临着困惑。
H模型
在H模型中，软件测试过程是一个独立的流程，贯穿于整个产品周期，与其他流程并发地进行。
