将软件系统或组件在指定条件下执行，观察或记录执行结果，并对系统或组件的某些方面进行评估的活动
v模型-与瀑布模型配套的软件测试过程模型
w模型-比v模型增加了各个软件开发阶段同步进行的验证和确认
敏捷测试模型-迭代地进行测试
单元测试 针对类、模块等代码单元的测试 开发者测试
集成测试 针对不同类或模块的逐步集成及相应的测试 开发者测试 策略：大爆炸式，自顶向下，自底向上，三明治
系统测试 将整个软件系统作为一个整体，考虑具体系统运行环境的测试
验收测试 确认软件系统是否完成了用户所提出的需求
给你一个xxx测试，让你分类？
功能测试
性能测试
兼容性测试
易用性测试-与人机交互有关
可靠性测试-在特定条件下及特定时间内，正常完成特定功能或提供特定服务的能力
信息安全测试
【具体的技术细节-09软件测试-2，不在这里深入了，我猜测也不会考】
功能测试，数据驱动的测试
被测软件=封闭黑盒 仅能通过外部接口进行交互 无法查看、无需了解实现细节
测试用例的设计依据：规格说明
将程序的输入划分为一组等价类：针对同一等价类中任何一个输入数据的测试 = 针对该等价类中其他输入数据的测试
有效等价类（合法输入），无效等价类（非法输入）
寻找一个能尽可能多覆盖尚未被覆盖的有效等价类的测试用例，重复该步骤直至所有的有效等价类都被覆盖为止 寻找一个只覆盖一个尚未被覆盖的无效等价类的测试用例，重复该步骤直至所有的无效等价类都被覆盖为止
在等价类划分基础上，(作为补充)围绕它们的边界设计测试用例
判定表：条件+动作
条件桩：列出问题的所有判断条件 动作桩：针对问题可能采取的所有操作 条件项：针对所有条件桩的具体取值组合，其中每个条件桩可以取true或false 动作项：针对每一个条件项应该采取的动作桩组合 规则：条件项和动作项的每一个组合形成一条规则 判定表中贯穿条件项和动作项的一列 每条规则对应产生一个测试用例
测试人员根据经验、知识和直觉来推测程序中可能存在的各种错误，从而开展有针对性测试
结构测试或逻辑驱动的测试 被测软件 = 透明的白盒 基于软件内部的代码实现、逻辑结构进行针对性的测试用例设计
理想情况下，尽可能多地覆盖代码内部的逻辑结构
语句覆盖：测试用例能够使得被测程序中的每条可执行语句都能被执行至少一次
分支覆盖：测试用例能够使得程序中每个判定的true分支和false分支都能被执行至少一次
条件覆盖：程序中每个判定中的每个原子条件的可能取值至少满足一次
分支-条件覆盖：每个判定的true分支和false分支都能被执行至少一次，且每个判定中每个原子条件的可能取值至少被满足一次
条件组合覆盖：每个判定中的所有条件组合至少被满足一次
路径覆盖：所有可能的执行路径都被至少执行一次
有可能给出一些测试案例，然后让你判断是什么样的覆盖，但是感觉好难
路径覆盖和分支覆盖的区别是什么？
