软件=程序+数据库+文档+服务
软件测试：
使用人工或自动手段来运行或测试某个系统的过程，目的在于检验其是否满足规定的需要，或是弄清楚预期结果与实际结果之间的差别
软件测试目的：以最小的人力物力和时间找出软件中潜在的错误和缺陷。
测试的基本要求：外观界面测试 易用测试 兼容性测试 安全性测试 性能测试 功能测试
软件测试的原则：
1.尽早地和及时地进行测试，从需求阶段开始介入
软件测试应贯穿软件生命周期
2.测试前应当准备好测试数据和与之对应的预期结果两部分
3.测试输出数据应包括合理的输入条件和不合理的输出条件
4.严格执行测试计划，排除测试的随意性
5.测试用例的所有相关预期结果做全面的检查
6.充分注意测试当中的群集现象
7.保存测试计划，测试用例，出错统计和最终分析报告，为维护工作提供充分的资料
8.缺陷具有免疫性（修改3~4个缺陷，一般都会再产生一个缺陷）
为什么进行软件测试：
提高软件质量 确保软件满足需求
软件测试的发展历程：
第一阶段：初始阶段 第二阶段：定义阶段
第三阶段：集成阶段（软件开发方式逐渐由混乱无序的开发过程过渡到结构化的开发过程）
第四阶段：管理测量和最佳化阶段
测试环境搭建的原则：真实，干净，无毒，独立
软件测试的三种模式：现场测试模式，内部测试模式，设立联合研发中心模式
测试用例设计的基本原则：数量越少越好，典型性越高越好，对缺陷的定位性越强越好
软件测试分类：
从是否关心内部结构角度：黑盒测试、白盒测试
从是否运行被测程序角度：静态测试、动态测试
从执行时是否需要人工干预角度：人工测试、自动化测试
从软件开发的过程的角度：单元测试，集成测试，系统测试，验收测试
从测试实施组织的角度划分：开发方测试，用户测试，第三方测试
自动化测试适用场合
回归测试 更多更频繁的测试 跨平台的测试 手工测试无法实现的工作 测试过程和验证点比较稳定
不适用场合：
随机性测试 时间短/一次性的项目 需求变化多的项目，软件版本不稳定 涉及与物理设备交互的测试
软件开发模型：软件开发的全部过程、活动、任务和管理的结构框架。它给出了软件开发活动各阶段之间的关系
2.1软件开发生命周期模型（大爆炸模式，边写边改模式，瀑布模型，螺旋模型，敏捷模型）
大爆炸模式
优点：思路简单，通常可能是开发者的突发奇想
缺点：开发过程是非工程化的，随意性大，结果不可预知
测试：开发任务完成后，修复较困难
边写边改模式
优点：简单考虑到了软件的需求，产品周期短
缺点：没有计划和文档的编制
测试工作：由于新的版本不断产生，测试工作长期循环
瀑布模型
需求分析—概要设计—详细设计—编码—测试—上线运行及维护
优点：如同瀑布流水，逐级下落——样式；将软件生存周期各活动规定为依线性顺序联接的若干阶段的模型；易理解，阶段明显，强调需求分析，明确测试阶段，提供了一套模板；文档驱动
缺点：风险大；灵活性差；适应性差；代价大
适合场景：功能、性能明确完整；需求固定，无重大变动
4.螺旋模型
五个步骤：确定目标，选择方案；评估方案，解决风险；本阶段的开发和测试；计划下一阶段；确定下阶段方法；
优点：严格的全过程风险管理；强调各开发阶段的质量；提供机会评估项目是否有价值继续下去。
缺点：很难让用户确信这种演化方法的结果是可以控制的.经常出现无法满足客户需求的情况
5.敏捷模型
以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发
2.2软件测试过程模型（V模型，W模型,X模型，H模型）
V模型
特点：动态测试行为应与开发行为对应，每个测试阶段的基础是对应开发阶段的提交物，并通过低层测试确保源代码正确，通过高层测试保证整个系统满足用户需求
局限性：测试滞后，缺少静态测试
W模型
特征：静态测试和动态测试行为伴随整个开发阶段，并与开发行为对应，有助于早期发现缺陷、了解项目难度、评估测试风险，并加快项目进度，降低项目成本
W模型局限性：将软件开发看成需求分析、设计和编码等一系列串行的活动；开发、测试之间保持着线性的前后关系，无法支持迭代的开发模型，无法支持变更调整；未体现测试流程的完整性
H模型
测试流程应独立于其他流程，且应保持自身的完整性，即测试是一个独立的流程，与其他流程并发进行，且其本身的测试准备和执行活动是分离的，不同测试活动可按某个次序先后进行，也可能是重复的，只要测试准备工作完成，就可以开始测试执行
X模型
清晰地体现了单元测试→集成测试→系统测试的过程，该模型还能处理开发中包括交接、频繁重复的集成等工作，更加贴合实际的项目开发流程
综合策略
宏观上以W模型为基本框架，将软件开发和测试作为两个并行的过程，测试伴随整个开发过程
微观上对每个测试阶段则以H模型为指导，进行独立测试，即只要满足测试执行条件就可以进行独立的测试，并反复迭代测试，直至达到预定目标
当项目小组的开发过程中存在诸多不确定因素时(如需求的变更、对缺陷的修复等)，则可利用X模型，针对每个相对独立的系统组成部分，进行相互分离的编码和测试，经多次交接后集成为最终的版本
对于软件企业而言，则应以软件测试成熟度模型(TMM)为指导，努力建立规范的软件测试过程
2.3软件测试流程
软件测试计划：在软件测试工作正式实施之前明确测试的对象，并且通过对资源、时间、风险、测试范围和预算等方面的综合分析和规划，保证有效的实施软件测试
测试用例：为实施测试而向被测试系统提供的输入数据、操作或各种环境设置以及期望结果等信息的一个特定集合
搭建测试环境：环境分为：开发环境，测试环境，正式环境
3.1黑盒测试——等价类划分
黑盒测试，又称为功能测试或数据驱动测试。
黑盒测试的优势：方法简单有效；可以整体测试系统的行为；开发与测试可以并行；对测试人员要求相对低
等价类划分法产生的原因:对系统进行穷尽测试是不可能的;使用有限的数据对系统进行测试是可能的;我们可以选择少量测试用例来测试系统，并满足测试是完备的;测试是没有冗余的
等价类测试：依据需求对输入域/输出域进行细分，然后在分出的每一个子集内选取一个有代表性的测试数据开展测试
等价类划分的原理：分而不交、合而不变、类内等价
有效等价类：对于SRS而言，合理、有意义的输入数据构成的集合，即被测对象能接受的数据，用于考查软件的正常工作能力
无效等价类：对于SRS而言，不合理、无意义的输入数据构成的集合，即被测对象不能接受的数据，用于考查软件的容错能力
等价类划分的原则：
若输入条件规定了取值范围，且取值范围上、下限之间的数据是有意义的数据，则取值范围内的数据构成一个有效等价类，小于下限、或大于上限的所有数据分别构成两个无效等价类；
若输入条件规定了“必须如何”的条件，则满足必须条件的数据构成一个有效等价类，其他数据构成一个无效等价类；
若输入条件是一个逻辑量，即规定了输入数据的一组值，且系统要对每个输入值分别进行处理，则可为每一个输入值确立一个有效等价类，此外还要针对这组值确立一个无效等价类，它是所有不允许的输入值的集合
用户需求规定必须遵守某种规则时，可规定一个有效等价类及若干个不同角度违反规则的无效等价类
如果某个输入条件只有两种取值，是/否，则可以定义一个有效等价类和一个无效等价类，或者定义两个有效等价类。
3.2黑盒——边界值测试
整体输入域：多个输入条件共同构成的具有一定实际意义的输入域
个体输入域：输入条件分别构成的单个输入域的集合
边界点：可能导致被测系统内部处理机制发生变化的点
对于某个输入条件而言，边界的确定可参照如下原则：
若输入条件规定了取值范围，则以该范围作为边界；
若输入条件规定了值的个数，则以值的个数为边界；
若输入域是有序集合(如有序表、顺序文件等)，则选取集合中特定次序的数据作为边界，如第一个或最后一个数据等
3.3黑盒测试——决策表法
决策表通常由4个部分组成
条件桩（Condition Stub）：列出了问题的所有条件（输入区）
动作桩（Action Stub）：列出了问题规定可能采取的操作。这些操作的排列顺序没有约束（输出区）
条件项（Condition Entry）：列出针对它左列条件的取值。在所有可能情况下的真假值。（输入取值区）
动作项（Action Entry）：列出在条件项的各种取值情况下应该采取的动作（输出取值区）
例题：
某公司订购单的检查：如果金额超过500元，又未过期，则发出批准单和提货单；如果金额超过500元，但过期了，则不发批准单；如果金额低于500元，则不论是否过期都发出批准单和提货单，在过期的情况下还需要发出通知单
由题可知，条件桩：（1）金额是否超过500元 （2）是否未过期
动作桩：（1）发出批准单 （2）发出提货单 （3）发出通知单
决策表适用的范围
规格说明书以决策表的形式给出，或很容易转化成决策表
条件的排列顺序不会影响执行哪些操作
规则的排列顺序不会影响执行哪些操作
当某规则的条件已经满足，并确定要执行的操作后，不必检验别的规则
如果某一规则要执行多个操作，这些操作的执行顺序无关紧要
正交表：
适用场景：当输入条件较多，并且条件中参数值较多，若组合设计用例数量较大，则考虑使用正交实验法设计测试用例正交表的性质（整体可比，均匀分散）
整体可比：每一列中每个输入条件的各个测试数据出现的次数相同
均匀分散：任意两列所构成的各有序数对出现的次数相同
最少测试用例数量=∑（每列水平数－1）＋1
3.5黑盒测试——因果图法
3.6黑盒测试——场景法
场景法：通过分析不同事件的触发顺序和处理结果，构建各个事件流，并基于这些事件的触发控制业务流程，形成多个不同场景，最终基于场景设计测试用例
基本流是从系统的某个初始状态开始，经一系列状态变化后到达终止状态的过程中最主要的一个业务流程
备选流是以基本流为基础，在经过基本流上每个判定节点(包括条件判定和循环判定)处满足不同的触发条件，而导致的其他事件流
例题：插入卡，校验成功后，输入密码，确定；密码校验通过后，输入取款金额，通过校验金额数，取钱成功；如果不通过，则不成功
场景法使用注意事项
最少的场景数等于事件流的总数，基本流与备选流的总数
有且唯一有一个场景仅包含基本流
对应某个备选流，至少应有一个场景覆盖
使用要求：
要对所测试的软件的业务逻辑、主要功能非常精通
3.7黑盒测试——状态转换法
状态转换：
是一种基于产品规格分析，对系统的每个状态及与状态相关的函数进行测试，通过不同的状态验证程序的逻辑流程
任何一个系统，如果对同一个输入，根据不同的状态，可以得到不同的输出，就是一个有限状态系统
使用场合：多状态变化的情况
目标：设计测试用例达到对系统状态的覆盖，状态-条件组合的覆盖以及状态迁移路径的覆盖。
有限状态自动机是为研究有限内存的计算过程和某些语言类而抽象出的一种计算模型。有限状态自动机拥有有限数量的状态，每个状态可以迁移到零个或多个状态，输入字串决定执行哪个状态的迁移。有限状态自动机可以表示为一个有向图。有限状态自动机是自动机理论的研究对象。
进程的三种基本状态
进程在运行中不断地改变其运行状态。
（1）就绪(Ready)状态
当进程已分配到除CPU以外的所有必要的资源，只要获得处理机便可立即执行，这时的进程状态称为就绪状态。
（2）执行（Running）状态
当进程已获得处理机，其程序正在处理机上执行，此时的进程状态称为执行状态。
（3）阻塞(Blocked)状态
正在执行的进程，由于等待某个事件发生而无法执行时，便放弃处理机而处于阻塞状态。引起进程阻塞的事件可有多种，例如，等待I/O完成、申请缓冲区不能满足、等待信件(信号)等。
2.进程三种状态间的转换
一个进程在运行期间，不断地从一种状态转换到另一种状态，它可以多次处于就绪状态和执行状态，也可以多次处于阻塞状态。图3_4描述了进程的三种基本状态及其转换。
(1) 就绪→执行
处于就绪状态的进程，当进程调度程序为之分配了处理机后，该进程便由就绪状态转变成执行状态。
(2) 执行→就绪 就绪队列
处于执行状态的进程在其执行过程中，因分配给它的一个时间片已用完而不得不让出处理机，于是进程从执行状态转变成就绪状态。
(3) 执行→阻塞
正在执行的进程因等待某种事件发生而无法继续执行时，便从执行状态变成阻塞状态。
(4) 阻塞→就绪
处于阻塞状态的进程，若其等待的事件已经发生，于是进程由阻塞状态转变为就绪状态。
3.8黑盒测试总结
错误推测法：基于经验和直觉推测程序中所有可能存在的各种错误，有针对性的设计测试用例的方法。
优点：能够覆盖其他测试用例设计方法覆盖不到的功能
缺点：过分依赖于个人经验
其他测试方法：探索性测试
自由探索性测试：类似于自由测试，效果跟经验有很大关系
基于场景的探索性测试：给场景注入变化
基于策略的探索性测试：主要是根据对产品的熟悉程度和经验来进行有针对性的测试，目的是很快的发现软件存在的风险
基于反馈的探索性测试：在探索性测试的过程中通过分析当前的质量以及前面的测试情况来指导后面的探索性测试
随机测试
缺点：测试往往不太真实 不能达到一定的覆盖率 许多测试是多余的 需要使用同一的随机数种子才能重建测试
局部探索性测试全局探索性测试
用例方法使用总结
首先进行等价类几乎所有输入框都可以使用任何情况下都必须使用边界值所用涉及数值的，几乎都需要输入条件组合使用判定表/因果图不同级别的用户看视频业务流程清晰，事件触发，使用场景法涉及到使用流程的状态转移法不同状态相互转换参数配置类的软件，正交实验法输入条件排列组合过多比较多时错误推测法使用其他方法都已思考过，将错误推测法设计的用例作为补充
4.1白盒测试
白盒测试又叫结构测试。
优势：
针对性强，便于快速定位缺陷；在函数级别开始测试工作，缺陷修复成本低；有助于了解测试覆盖程度；有助于代码优化和缺陷预防
不足和弊端：
对测试人员要求高：测试人员需要具备一定的编程经验，白盒测试工程师需要具备广博的知识
成本高：白盒测试需要的时间长
静态白盒测试：对系统静态检查，这种检查通常不需要运行被测软件，而是直接对软件形式和结构进行分析
静态测试特点：静态测试不需要运行程序，不必设计测试用例和结果分析；静态测试可以人工执行，充分发挥人的思维优势；静态测试不需要特别的条件，容易展开；静态测试对测试人员的要求较高，需要具有编程经验
静态白盒测试的内容：代码检查；静态结构分析；代码质量度量
代码检查主要是通过同行评审来发现缺陷；
同行评审的核心：缺陷预防
目的：发现缺陷，改进开发过程
静态结构分析：通过引入不同形式的图表，帮助我们快速了解程序设计和结构，更好地理解源代码，有利于找到程序设计的缺陷和代码优化的方向
怎样进行静态结构分析
函数调用关系图：通过树形方式展示被测系统中各函数之间的调用关系
函数控制流图：从函数内部进行考察，由边和节点组成的有向图
程序图：压缩后的程序流程图，也是一种特殊形式的有向图
画程序图的压缩原则：
剔除注释语句
剔除所有数据变量声明语句
所有连续的串行语句压缩为一个节点
所有循环次数压缩为一次循环：无论某个循环结构将循环多少次，仅考虑执行循环体和不执行循环体这两种情况
单入口，单出口，如果有多个出口，需要虚拟化一个end节点
计算环复杂度三种方法：直观观察法， 公式计算法， 判定节点法
直观观察法公式计算法
V(G) = e–n+2（前提：单入口和单出口）
判定节点法
找判断结点的个数，V（G）=P+1；
1）P代表独立判定节点，即两分支的判定
2）如果判定节点是n分支（n>2），该判定节点应视为(n-1)个独立判定节点
ISO9126模型：（6个质量特性，21个质量子特性）
功能性（适合性、准确性、互用性、依从性、安全性）
可靠性（成熟性、容错性、可恢复性）
易使用性（易理解性、易学性、易操作性）
效率（时间特性、资源特性）
可维护性（易分析性、易改变性、稳定性、易测试性）
可移植性（适应性、易安装性、一致性、易替换性）
4.2代码审查
（1）编码风格（2）命名规范（3）功能性（4）测试覆盖
（5）复杂度（6）注释（7）设计（8）安全性
测试覆盖是衡量软件质量的一个重要指标，它是一种“白盒”测试方法，或者说是“白盒”测试的主要内容。覆盖的标准有逻辑覆盖、循环覆盖和基本路径测试。
动态覆盖测试需要三个要素：测试用例、插装过的被测代码、收集覆盖信息并进行分析的工具本身。
覆盖测试一般应用在软件测试的早期，即单元测试阶段。
JUnit下的覆盖测试工具EclEmma（特点：快速的开发和测试周期，非常丰
富的覆盖信息分析以及非入侵的测试方式。）
复杂度高会产生的问题:
可读性降低可维护性降低缺陷率高模块内聚性低
复杂度优化：
方法抽取反向表达单一职责使用多态
为什么要进行审查设计？
提升系统稳健性提升可读性/可维护性提升可扩展性
设计维度要审查什么？
是否足够解耦是否可以使用一些设计模式是否可以应对一些变化是否过度设计
安全性低有什么问题？
数据容易泄露程序运行异常资源消耗异常
安全维度需要审查什么？
源码库是否包含凭据敏感数据是否加密落库输出是否安全输入是否安全权限管控是否正确返回值谨慎使用null
4.3白盒测试——基于判定的覆盖
导致程序结构变得复杂主要因素是判定节点。
动态白盒测试包括：
对判定的测试对路径的测试对循环的测试对变量的测试
使用什么方式对判定进行测试？
逻辑覆盖（语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖、修正条件判定覆盖）
语句覆盖的基本思想：保证程序的每一条可执行语句至少执行一次
判定覆盖：使得程序中每个判定节点至少都获得一次“真值”和“假值”，每一个真假分支至少被执行一次，又称分支覆盖。
条件覆盖：设计若干测试用例，使得每个判定中每个条件的可能取值至少满足一次
局限性：条件覆盖不能保证100%的判定覆盖
条件判定覆盖：设计若干测试用例，使得判定中所有条件可能取值至少执行一次，同时，使得所有判定的可能至少执行一次。
条件组合覆盖：设计若干测试用例，使得判定中条件的各种组合都至少执行一次。
修正的判定/条件覆盖(Modified Decision/Condition Coverage)
在满足判定/条件覆盖的基础上，每个简单判定条件都应独立地影响到整个判定表达式的取值，实质是利用简单判定条件的独立影响性来消除测试用例的冗余
基于路径的测试
适用场景：单元测试阶段，基于独立路径测试主要用于对程序源代码的执行测试，在集成测试阶段，该方法主要用于对业务流程、页面跳转等类似动态执行路径测试。
路径：程序从起始执行到程序结束经过的所有节点和连接线
独立路径：从全路径集合中抽取一组线性无关的路径
独立路径测试的目标：测试的完备性，测试的无冗余性
不可行路径：
程序设计时，若存在缺陷将导致得到的路径是事实上完全不可能执行到的路径主要原因：多个简单判定条件之间存在一定关联
路径测试不一定满足条件覆盖，一定满足判定覆盖
为什么进行循环测试
（1）循环结构是程序设计时一类重要结构
（2）重复多次循环可能导致内存泄漏
（3）循环到边界位置可能出现错误
4.5白盒测试——基于循环的测试
白盒测试——对变量的测试
数据流测试的基本原理是以被测变量为中心，关注该变量的每条定义、使用路径，若该路径存在定义/引用异常缺陷，则该路径是一条高风险路径，需要重点进行测试
定义节点：
若被测变量v的值在某条包含该变量的语句n处发生改变，则称该语句是关于变量v的定义节点，记做DEF(v,n)
输入语句、赋值语句（对该变量赋值）、循环控制语句（循环变量） 都是定义节点
使用节点：
若被测变量v的值在某条包含该变量的语句n处被使用，则称该语句是关于变量v的使用节点，记做USE(v,n)
输出语句、赋值语句（变量v对其他变量的赋值）、条件语句、循环控制语句都是使用节点
定义/使用路径
从被测变量v的一个定义节点开始执行，到该变量的某个使用节点结束的一条路径称为该变量的一条定义/使用路径，记做du-path
定义清除路径
若被测变量v的一条定义/使用路径中不包含该变量的其他定义节点，则该路径称为定义清除路径，记做dc-path
对关键变量的数据流测试的一般步骤如下：
确定需要重点测试的变量V确定变量V的所有定义节点和使用节点确定变量V的所有定义/使用节点对对V的重要定义/使用路径判断每条定义/使用路径是否为高风险路径
一条定义/使用路径，若该路径不是定义清除路径，则认为该路径是高风险路径，应重点测试
7.1 单元测试
单元测试：指对软件中的最小可测试单元或基本组成单元进行检查和验证
单元选取的原则
对于面向过程的开发语言来说，单元常指一个函数或子过程
对于面向对象的开发语言来说，单元一般指一个类
图形化软件中，单元常指一个窗口或一个菜单
单元测试的主要任务包括5个方面的内容：
模块接口测试
模块局部数据结构测试
模块独立路径测试
错误处理路径测试
边界条件测试
模块的所有错误处理路径测试
输出的错误提示是否难以理解
错误提示是否信息不足，导致无法定位发现的缺陷
显示的错误是否与实际遇到的缺陷不符合
是否存在不当的异常处理
是否存在无法按预先自定义的出错处理方式来处理的情况
注：主要关注程序的逻辑分支问题。
单元测试的原则
单元测试通过的标准：语句覆盖率达到 70%；核心模块的语句覆盖率和分支覆盖率都 要达到 100%
设计原则：
7.2 Junit的使用
JUnit是一个Java语言的单元测试框架
JUnit 5 = JUnit Platform + JUnit Jupiter + JUnit Vintage
设计单元测试用例需要遵守 BCDE 原则，以保证被测试模块的交付质量。B：Border，边界值测试，包括循环边界、特殊取值、特殊时间点、数据顺序等C：Correct，正确的输入，并得到预期的结果D：Design，与设计文档相结合，来编写单元测试
E：Error，强制错误信息输入（如：非法数据、异常流程、非业务允许输入等），并得到预期的结果。
8集成测试
集成测试就是在单元测试的基础上，将所有已通过单元测试的模块按照概要设计的要求组装为子系统或系统，并进行测试的过程。
目的是确保各单元模块组合在一起后能够按既定意图协作运行，并确保增量的行为正确
单元测试通过后，是否需要集成在一起进行测试？
需要，每个模块可以单独工作，但是将多个模块聚在一起时，某些模块可能不会正常工作。
集成测试内容：
将各个具有相互调用关系的模块组装起来时，检查穿越模块接口的数据是否会丢失
判断各子功能组合起来能否达到预期要求的父功能
检查一个模块的功能是否会对其他模块的功能产生不利影响
检查全局数据结构是否正确，以及在完成模块功能的过程中是否会被异常修改
单个模块的误差累积起来，是否会放大到不可接受的程度
大爆炸集成：
基本思想：将所有经过单元测试的模块一次性组装到被测系统中进行测试，完全不考虑模块之间的依赖性和可能的风险
优点：测试规模小
缺点：违反了测试从小范围到大范围展开的原则，难以定位问题
适用场景：稳定的软件版本，或涉及模块和接口数量不多的情况下（小范围内）
自顶向下集成：
基本思想： 从主控模块(主程序，即根节点)开始，按照系统程序结构，沿着控制层次从上而下，逐渐将各模块组装起来
这种集成又分为深度优先和广度优先两种集成策略
优势优先从根节点开始测试，有助于早期实现并验证系统主要功能，给开发团队和用户带来成功的信心，也便于早期验证主要的控制和判断，避免主控程序的缺陷，确保开发进度单个测试用例包含多个模块，可从整体上降低测试用例规模采用递增方式展开测试，每个新的测试用例一般仅加入一个新的模块，便于缺陷定位不足桩模块的开发和维护工作量较大难以早期发现底层模块中复杂算法的缺陷，且随着测试的进行，系统越来越复杂，底层模块的测试很难保证充分性不利于测试的并行，难以充分展开人力
自底向上的集成(Bottom Up)
基本思想：从底层模块(即叶子节点)开始，按照调用图的结构，从下而上，逐层将各模块组装起来优势优先从叶子节点开始测试，有助于早期发现底层模块中复杂算法的缺陷，且驱动模块的开发有利于规范和约束系统上层模块的设计，在一定程度上增加系统可测试性单个测试用例包含多个模块，可从整体上降低测试用例规模多个集成测试可并行展开，确保测试工作进度不足驱动模块的开发和维护工作量较大难以早期发现上层模块中有关逻辑和控制方面的缺陷直至加入最后一个模块才能看到整个系统框架，难以早期发现时序问题和资源竞争问题
混合集成（又叫三明治集成）
基本思想：将自顶向下和自底向上集成方法结合起来的集成策略。在调用图上按照一定的策略，分别自顶向下和自底向上展开集成，并在子树上进行大爆炸集成
优势：
能尽早的发现错误测试效率高
不足：
中间的目标层可能得不到充分的测试需要同时开发桩和驱动模块，这部分工作量比较大需在子树上进行大爆炸集成，一旦发现缺陷，涉及的接口数量较多，增加了缺陷定位难度
9系统测试
系统测试与集成测试和单元测试的区别系统测试不仅限于软件系统测试不能省略
功能测试
功能测试(Function Testing)主要针对系统的功能需求展开测试，以确认被测系统是否满足用户的功能使用要求
功能测试是系统测试中最基本的测试
性能测试
性能测试(Performance Testing)就是对软件的运行性能指标进行测试，判断系统集成之后在实际的使用环境下能否稳定、可靠地运行
主要考虑系统的时间和空间性能
时间主要指软件的一个具体事务的响应时间
空间性能主要指软件运行时消耗的系统资源
安全性测试
安全性是指“使得伤害或损害的风险限制在可接受的水平内”
安全性测试(Security Testing)用于检验系统对非法侵入的防范能力
基于安全性测试的内容
资源：即业务功能或数据风险：可能导致损失或伤害的事件安全性控制：针对风险的保护措施安全性测试方法
功能验证
程序数据扫描
静态测试
动态测试
兼容性测试
兼容性测试(Capability Testing)就是检验被测软件与其他软、硬件相互是否能够正确交互和实现信息共享
这种交互可能不限于在同一台计算机上运行，而是通过网络与异地的不同计算机上运行的软件进行的交互
用户界面测试
用户界面(User Interface)是指提供给用户用于与软件进行交互的方式，即提供用户输入和系统输出
优秀用户界面的基本组成标准
规范化，灵活性，正确性，直观性，舒适性实用性，一致性，帮助，独特性，多窗口应用与系统资源
可安装性测试(Installation Testing)
是指广义的安装测试，包括安装和卸载
易用性测试：
从软件的使用合理性和方便性等角度对软件系统进行检查，来发现软件不方便用户使用的地方。
软件中的易用性？（易理解，易学习，易操作）
10测试过程管理
测试用例的管理：
测试用例的属性
项目/软件 程序版本 编制人 编制时间 功能模块
功能特性 测试需求 优先级 预置条件 测试环境 参考文档
用例序号(ID) 输入条件 操作步骤 预期输出 测试结果
测试结果
通过(Pass)失败(Fail)警告(Warn)阻塞(Block) 跳过(Skip)
（重点！！！）软件缺陷的定义
软件未达到需求规格说明书中指明的功能软件功能超出需求规格说明书中指明的范围软件出现了需求规格说明书中指明不应出现的错误软件未达到需求规格说明书中虽未指出但应达到的目标软件测试员认为软件难以理解、不易使用、运行速度缓慢，或者最终用户认为不好
缺陷的产生
技术问题
算法错误，语法错误，计算和精度问题，接口参数传递不匹配
团队工作误解、沟通不充分
软件本身
文档错误、用户使用场合 时间上不协调或不一致性所带来的问题 系统的自我恢复或数据的异地备份、灾难性恢复等问题
为什么需求阶段缺陷最多？
需求：沟通难度
未设计、开发在黑暗中摸索前行
忽视文档的重要作用
需求变动导致信息不一致
团队合作不够
软件在从需求、设计、编码、测试一直到交付用户公开使用后的过程中，都有可能产生和发现缺陷；随着整个开发过程的时间推移，更正缺陷或修复问题的费用呈几何级数增长
缺陷管理：
是在软件生命周期中识别和管理缺陷的过程（从缺陷的识别到缺陷的解决关闭），确保缺陷被跟踪管理而不丢失
一般的，需要跟踪管理工具来帮助进行缺陷的全流程管理
缺陷的属性
严重性（严重性等级：严重的，一般的，次要的）
优先级（指缺陷必须被修复的紧急程度，高，中，低 可能会随着项目的进展而变化）
可重现性（指缺陷应在同样的条件下可反复出现）
确保缺陷可重现性的措施
（1）在测试过程中随时记录操作步骤和被测系统的响应
（2）重复测试至少三次，确保每次执行同样的步骤可得到相同表现的缺陷
（3）对于随机性出现的缺陷，应尝试使用不同的测试数据、改变测试环境等，试图找到影响缺陷出现的根本原因
缺陷报告的用途是什么？
（1）记录缺陷（2）缺陷分类（为解决缺陷分配资源）（3）缺陷跟踪
解决方案分类已修复(Fixed)暂缓(Postponed或Later)外部原因(External或On hold)不修复(Don't fix)重复的(Duplicate)不可重现(Not repro)符合设计(By design或Not a bug)
11.1 测试中的其他知识
验收测试:分为α测试和β测试
参与人员：用户、测试人员（质量保证人员）、开发人员等
α测试：是由用户在开发环境下进行的测试，也可以是开发机构内部的用户在模拟实际操作环境下进行的测试(受控)
β测试：是由软件的多个用户在一个或多个用户的实际使用环境下进行的测试。（不受控）
回归测试
定义：对软件的新的版本测试时，对新版本进行重新测试，这时的测试不仅是验证被修复的软件缺陷是否被解决了，且要保证以前所有运行正常的功能依旧保持正常，而不要受到这次修改的影响。
冒烟测试
定义：“冒烟测试”这一术语描述的是在将代码更改嵌入到产品的源树中之前对这些更改进行验证的过程
做法：选取系统中重要功能，重要使用流程等进行测试
使用场景：发布上线后提交给用户前等
测试需求
定义：用户需求，系统需求，测试需求
测试需求可以看做系统需求和测试用例之前的桥梁
系统需求à测试需求à细化的测试需求à测试用例
持续集成
是一种软件开发实践，每次集成都通过自动化的构建（包括编译、发布、自动化测试）来验证，从而尽快地发现集成错误。
测试报告（test report）
就是把测试的过程和结果写成文档，对发现的问题和缺陷进行分析，为纠正软件存在的质量问题提供依据，同时为软件验收和交付打下基础
什么情况写测试报告
测试完毕或一个阶段完毕，需要写出测试报告
