12.软件测试

下午题基本都是测试相关的；
上午一般10~20道；

本章节和上午题关联大，需要记忆；
软件测试模型：掌握每一种模型的特点、优缺点；
软件生命周期：
软件失效分类与管理：可以作为下午题考察；掌握软件失效的类别，软件管理的流程；
自动化测试：了解自动化带来的优缺点即可；

1.软件测试

为了发现软件中的错误而运行的程序；
好的测试用例、成功的测试能发现迄今为止没有发现的错误；
对象：软件、程序、文档、数据；

尽早测试：需求分析说明书写出来，就应当检查需求分析与用户实际需求是否统一；
由测试人员测试：因为开发人员有惯性思维；
群集现象：衡量一袋大米中沙子数量，随机取一把，看一把米中沙子含量；一段代码，发现的错误多，那没发现的错误也多；要重点测试这段代码；
下图上午题常考；

2.软件质量

软件测试强调的是软件开发的产物，对过程不关心；
软件测试只是质量保证领域的一部分内容；

3.单元测试

开发方测试，又称α测试；
用户方测试，又称β测试；

驱动模块：用以模拟被测模块的上级模块。驱动模块在集成测试中接受测试数据，把相关的数据传送给被测模块，启动被测模块，并打印出相应的结果。
桩模块：也有人称为存根程序，用以模拟被测模块工作过程中所调用的模块。桩模块由被测模块调用，它们一般只进行很少的数据处理，例如打印入口和返回，以便于检验被测模块与其下级模块的接口；
不一定要完成底层或上层模块的功能，但是一定要有数据的支持；

4.集成测试

在单元测试的基础上，把测试好的模块拼在一起，验证副功能级别是否达到要求；
涉及两个文档：概要设计文档、详细设计文档；

一次性组装方式：将所有模块组装在一起再进行测试；
优点：成本低；
缺点：难以定位bug；
增殖式组装方式：先测一部分，没问题后再组装一部分再测；
自顶向下：
优点：控制的分支、主干最先测量；
缺点：常发生问题的是在底层模块；这些模块往往到最后才开始测；
自底向上：
优点：常发生问题的底层模块最先才开始测；
缺点：控制的分支、主干最后测量；
混合式增殖方式：自顶向下、自底向上同时采用；

或者测试结果通过了专家小组的评审，专家说某些bug可以放到下个版本再改；

5.确认测试、系统测试、验收测试

确认测试还是软件人员来测的；验收测试是用户来测的；

6.开发方测试、用户测试、第三方测试

7.测试模型

记住每个模型的特点来备考即可；
V-模型
与软件开发的v模型一样；
每个阶段需要记；每个开发阶段对应的测试阶段，需要记；
单元测试、集成测试，对软件的编码、程序的设计阶段进行了测试；
确认测试、系统测试、验收测试，对需求分析进行了测试；

缺点：软件测试只是开发过程的扫尾阶段，开展晚；需求分析的偏差最后才会测，大量的非一致性成本（越早发现成本越低）；

W模型：
只要有测试对象出现，就对他进行测试；
缺点：软件测试过程不连续；没有反馈机制，测试完就进入下一个开发阶段；

H模型
只要测试事件（测试就绪点）出现，就可测试；
尽早准备，尽早执行；

X模型

前置模型
测试和开发紧密结合在一起的；
体现了软件生命周期的关键点；
独立区分验收测试和技术测试；

8.软件测试策略

单元测试，测试对象是程序代码；验证的是详细设计；
集成测试，测试对象是详细设计；验证的是概要设计；


测试信息流
软件配置：源程序、需求说明书、概要设计说明书、详细设计说明书等；
测试配置：测试计划、测试用例等；
测试工具；

下图只考过一次；

9.软件失效分类与管理

四个概念要记；
软件错误：不可接受的、人为的错误；导致软件产生缺陷；
软件缺陷：不希望、不可接受的偏差；导致软件故障；
软件故障：不希望、不可接受的内部状态；导致软件失效；
软件失效：不希望、不可接受的外部行为结果；
导致软件失效的原因：
1、产品说明书不够好；如需求分析做的不完整，遗漏了某些问题；
2、软件设计说明书不够好；导致程序员依照此写代码时出现偏差；


错误管理流程，需要记！！！！
新信息：发现了新错误；
打开：验证过，确实是错误；
修正：修好了；
拒绝：认为不是错误，或者不修改；
延期：这个错误在这个版本忽略，下个版本再修改；
关闭：已修正，回归测试也没问题；

10.自动化测试工具

看看就行；
局限性：测试用例还需要测试人员进行设计；