type
status
date
summary
slug
tags
category
icon
password
往年题
《软件测试技术》复习大纲
第一章
软件测试学科的发展
1957年之前，调试为主
1957～1978年，证明为主：以功能验证为导向，测试是证明软件是正确的（正向思维）。
1978～1983年，破坏为主：以破坏性检测为导向，测试是为了找到软件中的错误（逆向思维）
1983～1987年，评估为主：以质量评估为导向，测试是提供产品的评估和质量度量。
1988年起，预防为主：以缺陷预防为导向，测试是为了展示软件符合设计要求，发现缺陷、预防缺陷。
正向测试与反向测试的定义，关系
正向测试（思维）：
- 验证软件正常工作
- 评价一个程序或系统的特性或能力并确定是否达到预期的结果
- 在设计规定的环境下运行软件的所有功能，直至全部通过
反向测试（思维）：
- 假定软件有错误
- 测试是为发现错误而针对某个程序或系统的执行过程
- 寻找容易犯错误的地方和系统的薄弱环节，试图破坏系统，直至找不出问题
从从经济视角认知软件测试
测试的经济观点就是以最小的代价获得最高的软件产品质量。经济观点也要求软件测试尽早开展工作，发现缺陷越早，返工的工作量就越小，所造成的损失就越小。测试的成本< 缺陷造成的损失，测试才有意义。
SQA，与软件测试关系
这个SQA定义不需要背，用来理解SQA软件质量保证（Software Quality Assurance，SQA）活动是通过对软件产品有计划的进行评审和审计来验证软件是否合乎标准的系统工程，通过协调、审查和跟踪以获取有用信息，形成分析结果以指导软件过程。
联系：
① SQA指导、监督软件测试的计划和执行，督促测试工作的结果客观、准确和有效，并协助测试流程的改进。
② 软件测试是SQA重要手段之一，为SQA提供所需的数据，作为质量评价的客观依据。
区别：
① SQA是一项管理工作，侧重于对流程的评审和监控
② 测试是一项技术性的工作，侧重对产品进行评估和验证
第二章
缺陷定义，现象，判定准则
IEEE 软件缺陷的一个标准定义：
从产品内部看，软件缺陷是软件产品开发或维护过程中所存在的错误、毛病等各种问题；
从外部看，软件缺陷是系统所需要实现的某种功能的失效或违背。
现象：
- 功能、特性没有实现或部分实现
- 设计不合理，存在缺陷
- 实际结果和预期结果不一致
- 运行出错，包括运行中断、系统崩溃、界面混乱
- 数据结果不正确、精度不够
- 用户不能接受的其他问题，如存取时间过长、界面不美观
判定准则
- 需求规格说明书和其它需求、设计规范文档
- 竞争对手的产品
- 启发式测试预言
- 统计测试预言
- 一致性测试预言
- 基于模型的测试预言
- 人类预言
软件缺陷产生的原因有哪？
- 技术问题：算法错误，计算和精度问题，接口参数传递不匹配；系统的自我恢复或数据的异地备份、灾难性恢复等问题
- 团队工作：沟通不充分，误解
- 软件本身
- 文档错误，用户使用场合
- 时间上不协调、或不一致性导致的问题
产品质量的内容，内部，外部，使用质量
产品质量是人们实践产物的属性和行为，是可以认识，可以科学地描述的。并且可以通过一些方法和人类活动，来改进质量。
内部质量：代码的规范性，复杂性，耦合性
在内部质量和外部质量的属性上，两者是一致的，但实践中，可以将内部质量等同于开发人员自己发现的代码或设计缺陷的问题集合；将外部质量等同于测试人员在实验室测试所发现bug的集合。
使用质量：是从客户或用户使用的角度去感知到的质量。
如何理解软件规格说明书缺陷
软件规格说明书缺陷最多
- 开发与用户沟通存在困难，对产品理解不一样
- 靠想象描述系统的实现结果，有些特性不清楚
- 需求变化的不一致性，用户的需求不断变化，不能及时在需求中得到正确描述
- 对规格说明书不够重视，对其投入人力，时间不足
- 沟通不够
verification,validation
verification（验证）
是否正确地构造了软件？即是否正确地做事，验证开发过程是否遵守已定义好的内容。验证产品满足规格设计说明书的一致性
Validation（有效性确认）
是否构造了正是用户所需要的软件？即是否正在做正确的事。验证产品所实现的功能是否满足用户的需求
软件测试不同层次测试的对象和任务
四个层次
- 单元测试针对程序系统中的最小单元---模块或组件进行测试，一般和编码同步进行。主要采用白盒测试方法，从程序的内部结构出发设计测试用例，检查程序模块或组件的已实现的功能与定义的功能是否一致、以及编码中是否存在错误。通常要编写驱动模块和桩模块
- 集成测试，也称联调，在单元测试的基础上，将模块按照设计要求组装起来同时进行测试，主要目标是发现与接口有关的模块之间问题。现在提倡持续集成测试
- 一般在完成集成测试后进行系统功能测试，而且基于产品功能说明书，针对产品所实现的功能，从用户角度来进行功能验证，以确认每个功能是否都能正常使用
- 验收测试的目的是向未来的用户表明系统能够像预定要求那样工作，验证软件的功能和性能如同用户所合理期待的那样
静态测试的内容包括什么？开展相关活动时采用的形式有哪些？
内容
静态测试包括对软件产品的需求和设计文档、代码的评审（技术评审、文档评审等），以及对代码的静态分析等；
静态分析的查错和分析功能是其他方法所不能替代的，可以采用人工检测和计算机辅助静态分析手段进行检测，但越来越多地采用工具进行自动化分析
评审的主要形式：
桌面检查(Desk Checking)、互为评审 (Peer review)、走查 (walk-through)、会议评审 (Inspection)；
测试工作的流程
软件测试工作的组织与管理：制定测试策略、测试计划，确认所采用的测试方法与规范，控制测试进度，管理测试资源。
测试工作的实施：编制符合标准的测试文档，搭建测试环境，开发测试脚本、与开发组织协作实现各阶段的测试活动
软件测试的工作范畴
测试需求分析、测试策略指定、测试计划、测试设计、测试执行、测试结果和过程评估
第三章
等价类划分法
将输入数据分成若干个等价类，从每个等价类选取一个代表性的数据作为测试用例。
等价类分为有效等价类（合理的数据）和无效等价类（异常的数据）
- 有效等价类：输入完全满足程序输入的规格说明，有意义的输入数据所构成的集合，可检验程序是否满足规格说明规定的功能和性能
- 无效等价类：不满足程序输入要求或无效的输入数据构成的集合，可测试程序/系统的容错性——对异常输入情况的处理
❗根据等价类创建测试用例的步骤 
❓ 例题：
一报表处理系统，要求用户输入处理时间，假设时间限制在2000年1月至2020年12月，如果不在该范围内，显示错误；且规定日期由6位数字组成，前4位代表年，后两位代表月
答案：
写测试用例时，需要只覆盖1个无效等价类
边界值分析法
在某个输入输出变量范围的边界上，验证系统功能是否正常运行的测试方法
设计方法：
- 确定边界情况（输入或输出等价类的边界）
- 选取正好等于、刚刚大于或小于边界值作为测试数据
❓ 例题：
用边界值方法设计下列测试数据
Username，规则：
- 12个字符以内，不能为空
- 只能用字母、数字、_ 、-，不能用空格
- 以字母开始
- 大小写不敏感
Password，规则：
- 不少于6个字符
- 大小写敏感
答案：
判定表方法
对于多因素，有时可以直接对输入条件（成立或不成立）进行组合设计，不需要进行因果分析，这时就采用判定表方法。
判定表由“条件和活动”两部分组成，即列出一个测试活动执行所需的条件组合，所有可能的条件（输入）组合定义了一系列的选择，而测试活动（结果输出）需要考虑每一个选择。
❗判定表方法步骤：
❓ 例题：
对于（功率大于50马力的机器且维修记录不全）或已运行10年以上的机器，应优先维修处理。
答案：
1）列出所有的条件和和动作
条件：功率大于50马力？/维修记录不全？/已运行10年以上？
动作：优先维修处理/其他处理方式
2）确定规则个数
这里有3个条件，每个条件有2个取值，故应有8中规则
3）填写判定表
4）化简判定表
因果图方法
针对更为复杂的“多种输入条件、产生多种结果”设计组合测试用例。
借助图形，着重分析输入条件的各种组合，每种组合条件就是因，其必然的输出就是果
❗ 设计方法：
因果图的基本符号 
条件之间的关系
R a→b 指a出现b必定出现；但b的值与a无关
M a→b 指a出现，b一定不出现；a不出现，b值不确定
分析软件Spec描述的哪些是原因（输入条件）、哪些是结果（输出），给每个原因和结果赋予一个标示符。
找出原因与结果、原因与原因之间的对应关系，画出因果图
在因果图上标上哪些不可能发生的因果关系，表明约束或限制条件
根据因果图，创建（转化为）判定表，将复杂的逻辑关系转化为简单的组合矩阵
把判定表的每一列转化为测试用例。
❓ 例题-1：某个软件规格说明书中包含以下要求：
i.第一列字符必须为A或B
ii.第二个字符必须为一个数字
iii.在1,2条件下进行文件修改
iv.如1不正确，输出信息L
答案：
❓ 例题-2：
有一个处理单价为1元5角钱的盒装饮料的自动售货机软件。若投入1元5角硬币，按下“可乐”、“雪碧”、或“红茶”按钮，相应的饮料就送出来。若投入的是2元硬币，在送出饮料的同时退还5角硬币。
答案：
各种逻辑覆盖法：
判定/分支覆盖
判定覆盖：设计若干用例，运行被测程序，使得程序中每个判断的取真分支和取假分支至少经历一次，即判断真假值均曾被满足。
一个判定代表着程序的一个分支，所以判定覆盖也被称为分支覆盖。
条件覆盖
条件覆盖的基本思想是设计若干测试用例，执行被测程序以后，要使每个判断中每个条件的可能取值至少满足一次。
判定-条件覆盖
判定-条件覆盖是判定和条件覆盖设计方法的交集，即设计足够的测试用例，使得判断条件中的所有条件可能取值至少执行一次，同时，所有判断的可能结果至少执行一次
❓ 例题：对以下流程，写出判定条件覆盖法的一组用例
条件组合覆盖
条件组合覆盖的基本思想是设计足够的测试用例，使得每个判定中条件结果的所有可能组合至少出现一次。
它与条件覆盖的差别是它不是简单地要求每个条件都出现“真”与“假”两种结果，而是要求让这些结果的所有可能组合都至少出现一次
❓ 例题：对以下流程，写出判定条件组合覆盖法的一组用例
基本路径覆盖
❗ 基本路径覆盖的设计过程
i.依据代码绘制流程图
ii.确定流程图的圈复杂度（cyclomatic complexity ）
iii.确定线性独立路径的基本集合( basis set )
iv.设计测试用例覆盖每条基本路径
❓ 如何求圈复杂度
圈复杂度（Cyclomatic complexity）: 代码逻辑复杂度的度量，提供了被测代码的路径数量。复杂度越高，出错的概率越大
表示覆盖所有可能的情况最少需要的测试用例数量。
V(G) = 区域数量(由节点、连线包围的区域，包括图形外部区域)
V(G) = 连线数量 - 节点数量 + 2
V(G) = 简单可预测节点数量 + 1
❓ 例题-1
❓ 例题-2
功能图法
每个程序的功能通常由静态说明和动态说明组成
- 静态说明描述了输入条件和输出条件之间的对应关系
- 动态说明描述了输入数据的次序或者转移的次序
功能图法就是为了解决动态说明问题的一种测试用例的设计方法
功能图由状态迁移图（state transition diagram，STD）和逻辑功能模型（logic function model， LFM）构成
❓ 例题-1
❓ 例题-2
EFSM 扩展有限状态机
有限状态机（FSM）是一种数学模型，用于描述系统在不同状态之间的转换。FSM 由以下几个部分组成：
- 状态（State）：系统在某一时刻所处的具体条件或情况。
- 事件（Event）：触发状态转换的输入或条件。
- 转换（Transition）：从一个状态到另一个状态的变化，通常由事件触发。
- 初始状态（Initial State）：系统开始时的状态。
- 终止状态（Final State）：系统结束时的状态（可选）。
EFSM 在 FSM 的基础上增加了以下元素：
- 变量（Variables）：EFSM 可以包含变量，这些变量可以在状态转换过程中被读取或修改。
- 条件（Conditions）：状态转换不仅仅依赖于事件，还可以依赖于变量的值和条件表达式。
- 动作（Actions）：在状态转换时，可以执行一些动作，如修改变量的值或执行特定操作。
第四章
测试左移和右移，贯穿全生命周期的测试思想
测试左移：不仅让开发人员做更多的测试，而且需要做需求评审、设计评审，以及第1章介绍的验收测试驱动开发（ATDD）；
测试右移：是在线测试（Test in Production，TiP），包括在线性能监控与分析、A/B测试和日志分析等，可以和现在流行的DevOp联系起来。
软件测试贯穿于软件开发全过程，不仅可以在第一时间内发现缺陷，降低缺陷带来的成本，而且能有效预防缺陷的产生，构建更好的软件产品质量。所以，软件测试不再是事后检查，而是缺陷预防和检查的统一，将软件测试扩展到软件质量保证的全过程中，从而大大减少软件缺陷的数量，提供软件质量。而且可以大大缩短开发周期，降低软件开发的成本
w模型
- 测试过程和开发过程是同时开始、同时结束的,两者保持同步的关系
- 测试过程是对开发过程中阶段性成果和最终的产品进行验证的过程,所以两者相互依赖的。
- 前期,测试过程更多地依赖于开发过程
- 后期,开发过程更多地依赖于测过程。
- 测试过程中的工作重点和开发工作的重点可能是不一样的,两者有各自的特点，无论在资源管理,还是在风险管理,两者都存在着差异
TMAP定义，几个阶段，模型基石及关系
定义
TMap (Test Management Approach，测试管理方法)是一种结构化的、基于风险策略的测试方法体系, 目的能更早地发现缺陷，以最小的成本、有效地、彻底地完成测试任务，以减少软件发布后的支持成本。
TMap所定义的测试生命周期由计划和控制、准备、说明、执行和完成等阶段组成
- 计划和控制：设计测试计划的创建，定义了执行测试活动的“who,what,when,where and how”。在测试过程中，通过定期和临时的报告，用户可以经常收到关于产品质量和风险的更新。
- 准备：准备阶段。决定软件说明书质量是否足以实现说明书和测试执行的成功。
- 说明：定义测试用例和构建基础设施。一旦测试目标确定，测试执行阶段就开始。
- 执行：需要分析预计结果的区别，发现缺陷并报告缺陷
- 完成：包括对测试用例的维护以及再利用，创建一个最终报告以及为了更好的控制将来的测试过程对测试过程进行评估
基石：三大基石支持整个生命周期
（L）软件开发生命周期一致的测试活动生命周期，描述了在开发的过程中的某些特殊阶段需要的活动。
（O）坚实的组织融合，强调测试小组必须融合到项目组织中，而且每个测试成员都必须被分配任务和承担责任。
（I）正确的基础设施和工具，它说明了为了获得最优化的结果需要适当的基础设施和工具。其中“测试环境”必须是稳定的、可控制和有必要通过工具的使用提高测试的有效性。
（T）支持测试过程的技术，这些技术用于定义基于风险的测试策略，支持有计划的测试过程，研究和审查测试基准，详细说明测试用例以及如何提交报告
SBTM基本要素，结果，原理
SBTM：基于会话的测试管理
基本要素：
- Session（会话）是一段不受打扰的测试时间（通常是90分钟），是测试管理的最小单元。
- Charter（章程）：对每个session如何执行进行简要的描述，相当于每个session需要一个简要的计划（提纲）
- A session sheet (测试报告) ： 相当于测试报告，供第三方（如测试经理、ScrumMaster等）进行检查的材料。它最好能被工具扫描、解析和合成。
- Debriefing（听取口头报告）：口头汇报，更准确地说，是测试人和其lead/Manager之间的对话。
测试几个学派的特点
- 分析流派：认为测试是严格的和技术性的，在学术界有许多支持者
认为软件是逻辑性的，将测试看做计算机科学和数学的一部分，结构化测试，代码覆盖率就是其中一些典型的例子。他们认为测试工作是技术性很强的工作，侧重利用UML等分析和建模
- 标准流派：将测试视为衡量进度的一种方法，强调成本和可重复的标准
从分析学派分离出来，并得到IEEE支持，把测试看做侧重劣质成本控制并具有可重复标准的，旨在衡量项目进度的一项工作，测试是对产品需求的确认，每个需求需得到验证
- 质量流派：强调过程规范性，监督开发人员并充当质量的看门人
软件质量需要规范，测试就是过程的质量控制、揭示项目的质量风险的活动，确认开发人员是否遵守规范，测试人员扮演产品质量的守门员
- 上下文驱动流派：强调人的价值，寻找涉众关心的bug
- 测试所发现的每个缺陷都和相关利益者相关
- 认为测试是一种有技巧的心理活动
- 强调人的能动性和启发性测试思维
- 探索性测试是典型代表
- 敏捷流派：强调自动化测试，使用测试来快速验证开发是完整的
认为软件就是持续不断的对话，而测试就是验证开发工作是否完成，强调自动化测试。TDD是典型代表
TMMi，TPI，CTP, STEP定义，特点
TMMi (Testing Maturity Model integration 测试成熟度模型集成）是一个测试成熟度模型，它是与国际标准相一致的、由业务驱动（目标驱动）的。
TMMi1级—初始
TMMi2级—已管理
TMMi3级—已定义
TMMi4级—已测量
TMMi5级—优化
充分吸收、CMM/CMMi的精华；
基于历史演化的测试过程；
业界的最佳实践。
TPI
TPI（Test Process Improvement）是基于连续性表示法的测试过程改进的参考模型，是在软件控制、测试知识以及过往经验的基础上开发出来的
TPI级别：
为了了解过程在每个关键域所处的状态，即对关键域的评估结果，通过级别是来体现。模型提供了4个级别，由A到D，A是最低级。根据测试过程的可视性改善、测试效率的提高、或成本的降低以及质量的提高，级别会有所上升。
CTP
关键测试过程（Critical Test Process，CTP）:内容参考模型、上下文相关的方法，并能对模型进行裁剪
使用CTP的过程改进，始于对现有测试过程的评估，通过评估以识别过程的强弱，并结合组织的需要提供改进的意见
计划（Plan）、准备（Prepare）、执行（Perform）和完善 (Perfect)；计划和完善主要是管理工作，准备和执行是实践工作
STEP
STEP（Systematic Test and Evaluation Process，系统化测试和评估过程）是一个内容参考模型
基于需求的测试策略
在生命周期初始开始进行测试
测试用作需求和使用模型
由测试件设计导出软件设计（测试驱动开发）
及早发现缺陷或完全的缺陷预防
对缺陷进行系统分析
测试人员和开发人员一起工作
比较：STEP与CTP比较类似，而不像TMMI和TPI，并不要求改进需要遵循特定的顺序。某些情况下，STEP评估模型可以与TPI成熟度模型结合起来使用
第五章
代码评审的形式及各自特点
- 互查：在复审前，代码作者应该对代码进行注释；使用检查表（checklist）肯定能改进双方（作者和复审者）的结果；验证缺陷是否真正被修复
- 走查（Walk Through）：采用讲解、讨论和模拟运行的方式进行的查找错误的活动。
- 引导小组成员在走查前通读设计和编码。
- 限时，避免跑题
- 发现问题适当记录，避免现场修改
- 检查要点是代码是否符合标准和规范，是否有逻辑错误
- 怀疑过程中发现的缺陷比通过测试实例本身发现的缺陷更多
代码走查是相对比较正式的代码评审过程。
注意：
- 会议评审（审查） Inspection
- 以会议形式，制定目标、流程和规则
- 按缺陷检查表（不断完善）逐项检查
- 发现问题适当记录，避免现场修改
- 发现重大缺陷，改正后会议需要重开。
单元测试定义，作用，目标
定义
单元测试是对软件基本组成单元进行的测试。
目标
- 单元模块被正确实现：包括功能、性能、安全性等，但一般主要介绍单元功能测试。
- 确保代码在结构上可靠且健壮，能在各种条件下给予正确的响应
- 输入是否正确传递和得到保护（容错），输出是否正常
- 内部数据能否保持其完整性，包括变量的正确定义与引用、内存及时释放、全局变量的正确处理和影响最低
- 代码行、分支覆盖或MC/DC达到要求，如高于80%或95%
作用
① 尽早发现错误
- 错误发现越早,成本越低.
- 发现问题比较容易
- 修正问题更容易
② 检查代码是否符合设计和规范，有利于将来代码的维护
单元质量是系统质量的基石，单元测试可以比系统测试测得更彻底
桩程序，驱动程序
驱动程序
也称驱动模块，用于模拟被测模块的上级模块，可以调用被测模块，在测试过程中，被测模块接收测试数据，调用测试模块并把相关的数据传送给被测模块。
桩程序
用于模拟被测模块工作工程中所调用的下层模块。桩模块由被测模块调用，一般只进行很少的数据处理。以便于检验被测模块与其下层模块的接口。
集成测试的概念
集成测试是将软件集成起来，对模块之间的接口进行测试。
课本：集成测试是将已分别通过测试的单元按照设计要求集成起来再进行的测试，以检查这些单元之间的接口是否存在问题，包括接口参数的一致性引用、业务流程端到端的正确性。
顾名思义，集成测试是将软件集成起来后进行测试。集成测试又叫子系统测试、组装测试、部件测试等。
- 模块内的集成，主要是测试模块内各个接口间的交互集成关系
- 子系统内的集成，测试子系统内各个模块间的交互 关系；
- 系统内的集成，测试系统内各个子系统和模块间的集成关系。
单一系统的集成测试的集成模式及优缺点
集成模式
- 非渐增测试模式：先分别测试每个模块，再把所有模块按照设计要求放在一起结合成所需要的程序，如大棒模式。
- 渐增测试模式：把下一个要测试的模块与已经测试好的模块结合起来进行测试，测试是在模块一个一个的扩展下进行，其测试的范围逐步扩大。
优缺点比较
- 渐增模式需要编写的软件较多，工作量大；非渐增模式测试开销小
- 渐增模式发现模块间接口错误早；非渐增模式晚
- 非渐增模式发现错误，较难诊断；渐增模式中发生错误往往和最近加进来的那个模块有关
- 渐增模式测试更彻底
- 渐增模式需要更多的机器时间
- 非渐增模式可以并行测试
具体实践中一般采用渐增模式，具体的实践有自顶向下、自底向上、混合策略。
微服务特点，测试目标？测试基本步骤？
特点
- 自主性：可以对微服务架构中的每个组件服务进行开发、部署、运营和扩展，而不影响其他服务的功能。这些服务不需要与其他服务共享任何代码或实施。各个组件之间的任何通信都是通过明确定义的 API 进行的。
- 专用性：每项服务都是针对一组功能而设计的，并专注于解决特定的问题。如果开发人员逐渐将更多代码增加到一项服务中并且这项服务变得复杂，那么可以将其拆分成多项更小的服务。
微服务架构的集成测试
①测试外部的通信以确认通信是否通畅，检查核心功能即可，有助于发现任何协议层次的错误，如丢失 HTTP 报头、SSL 使用错误，以及请求/响应不匹配等
②数据库访问测试旨在确保微服务所使用的数据结构与数据库相符，以及检查 ORM 中 设置的映射关系、数据库访问模块能否妥善地处理网络出错等
一个微服务和外部服务的集成测试的步骤
- 启动被测微服务和外部服务的实例
- 调用被测微服务，该服务会通过外部服务提供的API读取响应数据
- 检查被测微服务是否能正确解析返回结果
集成测试的目标
目标在于检验与软件设计相关的程序结构问题。
- 数据穿过接口时可能丢失；
- 一个模块与另一个模块可能有由于疏忽的问题而造成有害影响；
- 把子功能组合起来可能不产生预期的主功能；
- 个别看起来是可以接受的误差可能积累到不能接受的程度；
- 全程数据结构可能有错误等。
第六章
功能测试的基本思路
- 明确测试目标和质量要求
- 测试需求分析，输出测试项
- 选择合适的测试方法、工具
- 设计测试用例、开发测试脚本
- 执行测试、观察结果、报告缺陷
- 评估测试过程与结果
- 提交测试报告
回归测试需要解决的问题。回归测试的策略和方法
回归缺陷：原来正常工作的功能，没有发生需求变化，而由于受其它改动影响而产生的问题。
要解决的问题
回归测试就是为了发现回归缺陷而进行的测试，如果没有回归测试，产品就带着回归缺陷被发布出去了，造成严重后果。
策略和方法
- 再测试全部用例：成本高
- 基于风险选择测试：基于一定的风险标准从测试用例库中选择回归测试用例。根据哪些功能被修改部分影响的可能性来选择
- 基于操作剖面选择测试：测试用例是基于操作剖面开发，测试用例的分布情况反映了系统的实际使用情况；选择那些针对重要功能或用户频繁使用功能的测试用例
- 再测试修改的部分：效率最高，风险最大
更智能的选择方法：综合基于风险选择测试和基于操作剖面选择测试
第七章
性能测试目标
- 获取系统性能某些指标数据
- 为了验证系统是否达到用户提出的性能指标
- 发现系统中存在的性能瓶颈，优化系统的性能
什么是性能测试？
性能测试就是为了发现系统性能问题或获取系统性能相关指标而进行的测试。一般在真实环境、特定负载条件下，通过工具模拟实际软件系统的运行及其操作，同时监控性能各项指标，最后对测试结果进行分析以确定系统的性能状况。
系统性能表现
- 请求响应时间：客户浏览器向web服务器提交一个请求到收到响应之间的间隔时间
- 事务响应时间：一系列请求完成处理所花费的时间
- 数据吞吐量：单位时间内web服务器成功处理的HTTP页面或HTTP请求数量
按照测试目的分，性能测试类型
- 性能基准测试：在系统标准配置下获得有关的性能指标数据，作为将来性能改进的基线
- 性能验证测试：验证系统是否达到事先已定义的系统性能指标、能否满足系统的性能需求
- 性能规划测试：在多种特定的环境下，获得不同配置的系统性能指标，从而决定系统部署的软硬件配置选型
- 容量测试：可以看作性能的测试一种，因为系统的容量可以看作是系统性能指标之一
- 压力测试：模拟实际应用的软硬件环境及用户使用过程的高负载、异常负载、超长时间运行，从而加速系统崩溃，以检查程序对异常情况的抵抗能力，找出性能瓶颈、不稳定等问题。
- 渗入测试：通过长时间运行，使问题逐渐渗透出来，从而发现内存泄漏、垃圾回收（GC）或系统的其他问题，以检验系统的健壮性
- 峰谷测试：采用高低突变加载方式进行，先加载到高水平的负载，然后急剧降低负载，稍微平息一段时间，再加载到高水平的负载，重复这样过程，容易发现问题的蛛丝马迹，最终找到问题的根源
什么是压力测试
模拟实际应用的软硬件环境及用户使用过程的高负载、异常负载、超长时间运行，从而加速系统崩溃，以检查程序对异常情况的抵抗能力，找出性能瓶颈、不稳定等问题。
性能测试的基本过程
- 确定性能测试需求
- 根据测试需求，选择相应的测试工具和开发相应的脚本。
- 建立性能测试负载模型：
- 确定并发虚拟用户数量，每次请求的数据量，思考时间，加载方式和持续加载的时间等
- 是个迭代完善的过程
- 执行性能测试
- 提交性能测试报告
什么是安全性测试
安全测试就是全面检验软件在需求规格说明中规定的防止危险状态措施的有效性和在每一个危险状态下的反应，对软件设计中用于提高安全性的结构、算法、容错、冗余、中断处理等方案进行针对性测试，并对安全性关键的软件单元和软件部件单独进行加强的测试，以确认其满足安全性需求。
渗透测试实施策略
全程监控：采用类似wireshark的嗅探软件进行全程抓包嗅探
择要监控：对扫描过程不进行录制，仅仅在数据分析后，准备发起渗透前才开启软件进行嗅探
主机监控：仅监控受测主机的存活状态
指定攻击源：多方监控指定源（某主机）进程、网络连接、数据传输等
对关键系统，可以采用对目标的副本进行渗透测试
软件安全性测试有哪两种？有什么关系和区别？
软件安全测试分为：
- 安全功能测试：数据机密性、完整性、可用性、不可否认性、身份认证、授权、访问控制、审计跟踪、委托、隐私保护、安全管理等
- 安全漏洞测试：从攻击者的角度, 以发现软件的安全漏洞为目的。安全漏洞是指系统在设计、实现、操作、管理上存在的可被利用的缺陷或弱点
关系和区别：
功能性测试：软件做它应该做的事，验证正确的输出；发现不正确的输出 /行为 / 缺陷(Bug)
安全性测试：软件不做它不应该做的事，应用输入的验证，以避免不安全的事情发生。在测试软件系统中对危险防止和危险处理设施进行的测试，以验证其是否有效
安全性测试的任务
- 全面检验软件在需求规格说明中规定的防止危险状态措施的有效性和在每一个危险状态下的反应
- 对软件设计中用于提高安全性的结构、算法、容错、冗余、中断处理等方案，进行针对性测试
- 在异常条件下测试软件，以表明不会因可能的单个或多个输入错误而导致不安全状态
- 对安全性关键的软件单元、组件，单独进行加强的测试，以确认其满足安全性需求
安全性测试方法按内外部分为哪两种？
- 基于威胁的方法
从软件外部考察其安全性，识别软件面临的安全威胁并测试其是否能够发生
- 基于漏洞的方法
从软件内部考虑其安全性，识别软件的安全漏洞，如借助特定的漏洞扫描工具
什么是XSS攻击和sql注入攻击，如何进行测试和防范
XSS攻击
XSS可以让攻击者在页面访问的浏览器中执行JS脚本，从而获得用户会话的安全信息，插入恶意的信息或植入病毒等。
允许恶意用户将代码植入到“供其它用户使用的web页面” 中
测试和规范方法：
每个输入域都要用标准的机制验证，长度、数据类型等符合设定要求，不允许输入JS代码，包括验证从数据库中检索的数据、传递到组件或者web服务的参数等。
sql注入攻击
根据SQL语句的编写规则，附加一个永远为“真”的条件，使系统中某个认证条件总是成立，从而欺骗系统、躲过认证，进而侵入系统
防范：
使用预编译语句
使用存储过程
输入验证和清理
web安全性测试可从哪些方法开展（没找到）
Web/数据库 渗透测试点
- 检查应用系统架构,防止用户绕过系统直接修改数据库
- 检查身份认证模块，用以防止非法用户绕过身份认证
- 检查数据库接口模块，用以防止用户获取系统权限
- 检查文件接口模块，防止用户获取系统文件
- 检查其他安全威胁
数据加密；登录或身份验证；输入验证；注入攻击（Injection）；跨站点脚本攻击（XSS）；跨站点请求伪造(CSRF)；未能限制URL访问 (Failure to Restrict URL Access)；超时限制；目录；操作留痕
什么是软件可靠性？可从哪几个指标度量？各自的定义
软件可靠性
在规定的一段时间和条件下，软件能维持其性能水平的能力有关的一组属性，可用成熟性、容错性、易恢复性三个基本子特性来度量。
指标
- 成熟性：通过错误发现率DDP（Defect Detection Percentage）来表现。DDP越小，软件越成熟。
- 容错性：指系统在出现硬件故障、软件错误或其他异常情况下，仍能继续正常运行并维持其预期功能的能力。
- 易恢复性：指系统在遭遇故障、错误或其他中断情况下，能够快速恢复到正常运行状态的能力。
容错测试的要点？
定义：容错测试是一种对抗性的测试过程。在这种测试中，通过各种手段让软件强制性地发生故障，或将把应用程序或系统置于（模拟的）异常条件下，以产生故障，例如设备输入/输出（I/O）故障或无效的数据库指针和关键字等。
要点：
- 故障转移：确保测试对象在出现故障时能成功完成故障的转移，并能从导致意外数据损失或数据完整性破坏的各种硬件，软件和网络故障中恢复
- 数据恢复：对于必须持续运行的系统，一旦发生故障，备用系统将不失时机接替发生故障的系统，以避免丢失任何数据或事务
- 测试目标：
- 确保恢复进程将数据库，应用程序和系统正确地恢复到预期的已知状态
- 客户机，服务器断电
- 通过网络服务器产生的通信中断或控制器中断
什么是A/B测试？有什么特点
A/B测试是易用性测试的一种
A/B测试（ABTest） 是将用户分成不同的组，同时在线试验产品的不同版本，通过用户反馈的真实数据来确定哪一个方案更好
特点
- 先验性：采用流量分割与小流量测试的方式，先让线上部分小流量用户使用以验证设计，再根据数据反馈来推广到全流量，减少产品损失
- 并行性：同时运行两个或两个以上版本的试验完成对比分析，而且保证每个版本所处的环境一致的，避免流程周期长的问题，节省验证时间
- 科学性：基于统计的数据来做出决策，避免主观或经验的错误决策
第八章
软件本地化，国际化，全球化，相互关系
L10N表示本地化，因为Localization从L到N有10个字母
L10N是将一个软件产品按特定国家/地区或语言市场的需要进行加工，使之满足特定市场上的用户对语言和文化的特殊要求的软件生产活动。
I18N表示国际化，因为Internalization从I到N有18个字母
I18N是借助功能设计和代码实现中软件系统有能力处理多种语言和不同文化，使创建不同语言版本时，不需要重新编写代码的软件工程方法。
G11N (globalization)= I18N + L10N
关系如上：国际化是核心工作，只有满足国际化之后才能容易实现本地化，翻译只是本地化中的一部分工作。全球化是一个产品市场的概念。
- 国际化是本地化的基础和前提，为本地化做准备
- 本地化是国际化向特定本地语言环境的转换
- 国际化是软件产品源语言开发的一部分，属于Engineering
- 本地化可以独立于Engineering，可由第三方完成
unicode与utf-x关系，特点
unicode 为世界上所有字符都分配了一个唯一的数字编号，相当于一张表，建立了字符与编号之间的联系。但只规定了每个字符的数字编号是多少，并没有规定这个编号如何存储。
所以有了Unicode实用的编码体系：就是UTF-x。
utf-x解决了Unicode编码在不同计算机直接的传输、保存，使得双字节的unicode能够在现存的处理单字节的系统上正确传输。
utf-x可以将unicode代码点编码成可以直接在计算机中存储的二进制编码
软件本地化基本步骤
- 建立配置管理体系，跟踪目标语言各个版本的源代码
- 创造和维护术语表
- 源语言代码和资源文件分离、或提取需要本地化的文本
- 把分离或提取的文本、图片等翻译成目标语言
- 把翻译好的文本、图片重新检入目标语言的源代码版本
- 如果需要，编译目标语言的源代码
- 测试翻译后的软件，调整UI 以适应翻译后的文本
- 测试本地化后的软件，确保格式和内容都正确
本地化测试主要有哪些工作
- 功能性测试：所有基本功能、安装、升级等测试
- 翻译测试：包括语言完整性、术语准确性等的检查
- 可用性测试：包括用户界面、度量衡和时区
- 兼容性测试：包括硬件兼容性、版本兼容性等测试
- 文化、宗教、喜好等适用性测试
- 手册验证：联机文件、在线帮助、PDF文件等
软件本地化测试完整路线
I18n 测试
L10n 测试
语言/翻译的 测试
美观/界面 测试
功能 测试
发布 测试
第九章
自动化测试与测试自动化
通过平台、系统或工具自动地完成测试的某类工作都可以归为测试自动化，测试自动化意味着测试全过程的自动化和测试管理工作的自动化
自动化测试：把以人为驱动的测试行为转化为机器执行的一种过程，即模拟手工测试步骤，通过执行由程序语言编制的测试脚本，自动完成软件的单元测试，功能测试，负载测试或性能测试等全部工作 ；体现在实际测试被自动执行的过程上
自动化测试更侧重的测试用例或测试数据生成、测试执行和测试结果呈现等自动化
自动化测试为评审提供辅助工具和代码静态分析
自动化测试可以覆盖系统的接口测试、UI功能测试和专项测试
如何理解测试自动化
不现实的期望注定测试自动化的失败
测试自动化能：
- 显著降低重复手工测试的时间
- 建立可靠、重复的测试，减少人为错误
- 增强测试质量和覆盖率
测试自动化不能：
- 完全替代手工测试和手工测试师
- 保证100%的测试覆盖率
- 弥补测试实践的不足
测试自动化实现的原理，几种技术
- 代码分析：类似于高级编译系统，在工具中定义类/对象/函数/变量等定义规则、语法规则等，在分析时对代码进行语法扫描，找出不符合编码规范的地方。
- 捕获和回放: 代码分析是一种白盒测试的自动化方法，捕获和回放则是一种黑盒测试的自动化方法。
- 直接编写脚本来操作、控制、验证对象：包括对象识别、脚本技术、对运行结果进行比较
- 对象识别 ：对于页面对象的识别，分为Windows 对象 、Mac 对象、Web DOM对象
- 脚本技术： 脚本是一组测试工具执行的指令集合，也是计算机程序的一种形式，可以通过录制测试的操作产生，然后再做修改。
- 自动比较技术：
- 静态比较和动态比较
- 简单比较和复杂比较
- 敏感性测试比较和健壮性测试比较
- 比较过滤器
自动化测试的流程
计划：计划自动化测试，收集测试信息测试需求是什么哪里能得到用到的数据
创建：记录用户操作，形成基本测试记录用户的操作核实成功回放
核实和提高：对回放和测试提高自动化测试插入测试点驱动测试用例
整合：运行多种测试检查数据流关联数据建立综合的测试场景
几种脚本技术
- 线性脚本：是录制手工执行的测试用例得到的脚本，这种脚本包含所有的击键、移动、输入数据等，所有录制的测试用例都可以得到完整的回放
- 结构化脚本 ：类似于结构化程序设计，具有各种逻辑结构、函数调用功能
- 数据驱动脚本：将测试输入存储在独立的（数据）文件中，而不是存储在脚本中
- 关键字驱动脚本 ：脚本用一个简单的表格表示，是数据驱动脚本的逻辑扩张，实际封装了各自基本操作，每个操作由相应函数实现，开发脚本时，不需要关心这些基础函数，直接使用已定义好的关键字
自动化功能测试基本构成
- 录制测试脚本：对象识别
- 编辑测试脚本：加验证点优化脚本
- 调试脚本
- 执行：验证
- 结果分析：确定缺陷
TA框架的构成及各部分特点
TA框架就是测试自动化框架
- Harness/IDE：TA框架的核心，相当于“夹具”，其他组成部分作为插件与之集成
- 脚本语言：包括公共脚本库、项目归类的脚本库，可以与github这样的代码管理工具集成
- 代理：负责harness与工具的通信，控制测试工具的运行
- 工具
- 任务安排：安排和提交定时任务，事件触发任务，以便实现无人值守的自动化测试执行
- 报告
- Author:Rainnn
- URL:https://blog.rainnn.top//article/218eefba-b209-8029-90d9-fb93832d9464
- Copyright:All articles in this blog, except for special statements, adopt BY-NC-SA agreement. Please indicate the source!
