1. 软件测试定义：度量和提高被测软件质量，是对软件需求分析、设计和编码的最终复查的一系列过程。目的：验证被测软件是否满足需求。 2. 测试目标：发现缺陷、预防缺陷、建立团队对软件的信心。
3. 测试原则：1）尽早介入；2）显示缺陷的存在；3）穷尽测试不可能；4）缺陷集群性；5）杀虫剂悖论；6）测试依赖于测试背景；7）无缺陷谬论。 4. 软件生命周期：需求—设计—编程—测试—集成—维护
5. 风险：事件、危险、威胁或情况等发生的可能性以及由此产生的不可预料的后果，即一个潜在的问题。
6. 质量控制：决定软件产品正确性的过程和动作；一组功能基线，保证产品符合标准/需求所做的工作
7. 缺陷：偏离需求规格说明，三种表现：遗漏、错误、多余
8. 验证：在整个软件生命周期中的全部之类控制活动，确保交付的中间产品符合输入规格说明。
9. 确认：软件生命周期中的测试阶段，保证最终产品符合规格说明 10. 静态测试：在系统编码之前进行的测试
11. 动态测试：在系统编码之后进行的验证和确认；运行被测程序，检查运行结果与预期的差异，并分析运行效率。
12. 代码审查：测试人员参与的代码会审。由一组人通过阅读、讨论和争议对程序进行静态分析的过程。
13. 单元测试：对单一的独立的模块或代码进行的测试。目的在于发现各模块内部可能存在的各种差错。
14. 集成测试：对一组模块进行的测试，确保模块之间的数据和控制能正常的传递。是将模块安装设计要求组装起来同时进行的测试。
15. 系统测试：一个预先确定的测试组合，当执行成功时，系统符合需求；与单元测试不同的各种更高等级测试类型的通用术语。目的是保证系统在实际的环境中能够稳定、可靠的运行下去，包括恢复性测试、安全测试、强度测试、性能测试等。 16. 验收测试：保证系统符合最终用户要求的测试。
17. 回归测试：在系统改变后进行的测试，以确保不希望的变化不引入系统
18. 功能测试：认为系统应该做什么的业务需求测试。目的是向未来的用户表面系统能够按预定要求的功能那样工作，这是的测试是直接操作完整的软件系统，需要战争用户的角度上，尽量模拟用户使用的各种情况，甚至让用户参与测试。 19. 确认系统是如何实现的系统结构测试
20. 黑盒测试：数据驱动的、基于外部规格说明而不需了解系统是如何构造的测试。 21. 白盒测试：逻辑驱动的、基于编码内部的结构和逻辑的测试。
22. 软件测试度量：提取软件测试过程中可计量的属性，在测试过程进行中以一定频度不断采集这些属性的值，并采用一些恰当的分析方法对得到的这些数据进行分析，建立可度量的指标，从而量化的评定测试过程的能力和性能，提高测试过程的可视性，帮助软件组织管理以及改进软件测试过程。
23. 常用测试度量指标：测试覆盖率、测试执行率、测试执行通过率、测试缺陷解决率 24. 测试设计：将概括的测试目标转换问具体的测试条件和用例的一系列活动。（依据、可测性、条件、用例、说明说）
25. 测试用例=<输入数据、期望结果、测试对象、边界条件+>
26. 软件测试文档的作用：验证需求的正确性、检验测试资源、明确任务的 风险、生成测试用例、评估测试结果、再测试
27. 测试用例：是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。构成了设计和制定测试过程的基础，决定着测试设计和测试开发的类型以及所需的资源。
28. 测试数据：实在测试中使用的实际值或执行测试所需要的元素。测试数据创建要测试的条件，并且用于核实特定的用例或需求是否已经成功得到实施。
29. 测试配置管理的目标：1）在测试过程中控制盒审计测试活动的变更；2）再测试过程中随着测试项目的里程碑，同步建立相应的基线；3）在测试过程中记录并跟踪测试活动过程中的变更请求；4）在测试过程中针对相应的软件测试活动或者产品，测试人员应将他们标识为被标识和控制并且是可用的。
30. 质量特性六要素：功能性、可用性、可靠性、效率、维护性、可移植性
31. 评审：是对软件产品进行评估的活动，用以确定于预期结果之间的偏差和相应的改进意见，通常由人来执行。
32. 同行评审：是由开发软件产品作者以外的其他人检查工作产品，以发现缺陷病寻找改进的机会。
33. 等价类划分法：是把程序的输入域划分成若干部分，然后从每个部分中选取少数有代表性数据当作测试用例。
34. 猜错法：是基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性地设计测试用例的方法。
35. 决策表/判定表：试分析和表达多逻辑条件下执行不同操作的情况的工具。（适用范围：a.所有软件的行为由一些逻辑决策所决定的情况；b.记录一个系统要实施的复杂业务规则。）
36. 软件需求：1）用户解决问题或达到目标所需条件或全能；2）系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或全能；3）一种反应上面（1）、（2）所述条件或全能的文档说明。 测试流程问题
1. 测试过程：开始—控制（计划--分析&设计—实现&执行）--评估出口准则&报告—测试结束活动—结束
2. 测试过程主要活动：提取测试需求—确定测试策略—制定测试计划—开展测试设计—执行测试用例—分析测试结果
3. V模型：1）用户需求—需求分析与系统设计—概要设计—详细设计—编码；2）验收测试—确认测试与系统测试—集成测试—单元测试；V模型的局限性：仅仅将测试作为软件生命周期的一个阶段，不能体现测试的尽早介入，依照此模型进行测试，容易导致在早期的缺陷不能够被发现。
4. W模型：1）用户需求—需求分析与系统设计—概要设计—详细设计—编码—集成—实施—交付；2）用户需求V&V/验收测试设计—需求分析与系统设计/V&V—概要设计V&V/集成测试设计—详细设计V&V/单元测试设计—单元测试—集成测试—确认测试与系统测试—验收测试
5. 测试过程管理：1）测试计划&控制：测试计划、测试进度表；2）测试分析&设计：需求分析、相关设计、测试用例执行顺序设计；产出物：测试设计规格说明书、测试用例规格说明书、测试规程规格说明书；3）测试实现&执行：对测试环境、用
例进行实现，测试脚本、数据实现等；产出物：测试日志&事件报告；4）测试总结&报告：测试评审，编写测试总结报告；产出物：测试总结报告；5）测试结束：对测试进行总结，进行测试结束活动。 (1) 计划和控制阶段 工作内容 确定测试范围、策略、方法；风险的监生成文档 测试计划 测试进度表 特征 测试计划也要经过起草、讨论、审查等；不同的测试阶段可能有不同的测试计划。 (2)分析和设制定测试技术方案，计阶段 对需求进行分析、设计测试用例。 (3) 实现和执行阶段 实现测试用例脚本和规程规格说明书，设置测试环境，准备测试数据，执行测试用例。 (4) 评估出口准则和报告阶段 (5) 测试活动结束阶段
6. 软件测试需求分析过程 输入 需求规格说明书 测试要点分析、功能交互点分析、质量特性分析、测试类型过程 需求采集 需求分析 输出 原始测试需求表 测试需求跟踪矩阵 检测对象是否符合标准；对缺陷进行报告、分析、跟踪。 测试总结报告 测试执行完成，对测试结果进行综合分析，对质量的审查。 测试规程规格说明；测试日志；缺陷事件报告 测试设计文档 测试用例文档 将需求转换为测试用例的过程；是一个要求高的关键阶段。 手工测试和自动化测试。 控，进度的监控等。 分析 测试需求 7. 测试用例设计过程：测试需求分析（功能点分析）--业务流程分析（场景）--测试用例设计—测试用例评审—测试用例更新完善—测试用例开发与实现（完善用例操作步骤、期望结果）
8. 边界值划分流程：分出输入数据；识别边界；选择数据（数据个数4n+1） 测试内容问题
1. 生命周期各个阶段测试工作划分： 1） 2） 3） 4） 5） 6）
需求：决定验证的方法、决定需求的 充分程度、生成功能测试、决定与需设计：决定设计的充分程度、生成结构和功能测试数据、决定设计与需求的编程：决定实现的充分程度、生成各种程序/单元的结构和功能测试数据、测试：决定测试计划的充分性、测试应用系统 安装/集成：把经测试的系统放入产品 维护：修改和重新测试 求符合的设计 一致性
决定与设计的一致性
需求评审 评审结论 2. 软件测试过程中的内容：基于项目目标，制定测试计划，确定测试策略，选定测试方法，排定优先级，建立里程碑，组织测试资源等；然后，以测试计划为基础，明确测试需求、测试对象和测试目标及功能和性能指标；最后，依据测试计划和测试设计，测试人员展开测试相关活动。
3. 测试计划控制阶段：1）标识测试项；2）（不）需要测试特征；3）测试方法；4）入/出口准则；5）暂停准则&恢复要求；6）完成所需交付项；7）测试任务；8）测试环境要求；9）测试职责；10）人员配置及培训；11）测试进度；12）测试风险及应对措施。 4. 各阶段测试的测试内容 1）组件测试：
（1）定义：组件测试（Component Testing）是对构成软件最底层的软件代码进行的测试，这些代码可能是C代码、C++代码、VB代码等，有时该测试又被叫做单元测试（Unit Testing）。
（2）测试对象：独立的函数、方法和过程、独立的类 （3）测试环境：开发环境
（4）测试目标：保证测试对象完整地、正确地执行了详细设计中所定义的功能，进行一些非功能测试。
（5）测试策略：白盒测试、测试驱动开发 （6）测试依据：详细设计说明书 2）
集成测试：
（1）定义：集成测试(Integration Testing)是对组件之间的接口进行测试，以及测试一个系统内不同部分的相互作用，比如操作系统、文件系统、硬件或系统之间的接口。根据集成的粒度可分为，组件集成（Component Integration）、系统集成（System Integration）。
（2）测试对象：待集成的组件、待集成的系统。 （3）测试环境：开发环境、系统集成环境。
（4）测试目标：揭示组件与组件之间、系统与系统之间数据交换，状态传递以及控制传递之间的错误，验证模块集成与调用是否与概要设计说明一致 （5）测试策略：自上而下、自下而上 （6）测试依据：概要设计说明书 3）系统测试：
（1）定义：是将已经集成好的软件系统作为计算机系统的一部分，以计算机系统硬件、某些支持软件、数据和人员等系统元素结合起来，在实际运行环境下对计算机系统进
行一系列严格有效的测试。目的在于通过与系统的需求定义作比较，发现软件与系统定义不符合或与之矛盾的地方
（2）测试对象：完整的、集成的计算机系统。 （3）测试环境：独立的测试环境，接近用户真实环境。
（4）测试目标：确认整个系统是否满足了系统需求规格说明书中的功能和非功能需求，以及满足程度，侦测一切该定义在系统需求中却被遗漏的需求。 （5）测试策略：黑盒测试
（6）测试依据：系统结构设计、软件规格说明书 4）验收测试：
（1）定义：用户依照需求规格说明书对软件进行的功能性和非功能性测试。验收测试是部署软件之前的最后一个测试操作。验收测试的目的是确保软件准备就绪，并且可以让最终用户将其用于执行软件的既定功能和任务 （2）测试对象：经过系统测试的软件。 （3）测试环境：用户环境。
（4）测试目标：确保系统功能、系统的某部分或特定的系统非功能特征满足验收准则，建立信心，评估系统对于部署和使用的准备情况。 （5）测试策略：黑盒测试、用例测试/场景法 （6）测试依据：用户需求说明书、合同 测试方法问题
1. 基于风险分析的测试方法：1）列出一个风险列表；2）对每个风险进行分析和评估，确定风险级别；3）进行考察每项风险的测试；4）当风险消失而新的风险出现的时候，调整测试策略
2. 评估出口准则：1）按测试计划定义的出口准则检查测试日志；2）评估是否要更多的测试或更改出口准则；3）为利益相关者提供一个测试总结报告。
3. 审查的内容和流程：
1) 计划：选择评审员，分配角色，制定评审标准（入/出口准则），选择需要评审的文档
2) 预备会：分发文档，向评审参与者解释评审目标、过程、文档
3) 个人准备：评审参与者进行评审前的准备，标注可能的缺陷，标注可能的问题，标注建议
4) 评审会议：讨论评审对象，记录评审过程中的结果和会议纪要 5) 返工：修复评审中发现的缺陷
6) 跟踪结果：检查缺陷是否已经得到解决，收集/度量数据，核对出口准则 4. 白盒测试的方法：
逻辑覆盖（包括语句覆盖、分支覆盖、条件覆盖、分支-条件覆盖、路径覆盖）、路径测试、数据流测试、信息流分析。 5. 黑盒测试的方法：
等价类划分、边界值分析、因果图、随机测试、猜错法、决策表测试、状态转换测试、场景法测试、探索性测试等等。 6. 构建等价类步骤： 1） 2） 3）
确定基本类：为每个变量/参数确定其定义域，构建有效值类和无效值类。 细分类：对每个等价类，将可能会被不同处理的类元素分配一个新的类。 选定代表值。
条件项（2） 动作项（4） 7. 决策表设计用例方法： 条件桩（1） 动作桩（3） （1） 列出问题的所有条件（无序） （2） 由不同规则可能采取的操作（无序）
（3） 列出（1）的取值（所有组合），一个组合形成规则（任一（2）的组合及
其（4）称为规则）
（4） 列出(3)的取值（由（2）决定）
（5） 化简：合并两或多相同动作的组合，且条件项间存在极为相似的关系。 缺陷管理问题
1. 软件缺陷：存在于软件中的实际结果与预期结果之间的偏差
2. 导致软件缺陷的原因：1）需求定义不完善；2）客户—开发者通信失败；3）对软件需求的故意偏离；4）逻辑设计错误；5）编码错误；6）不符合文档编制与编码规定；7）测试过程不足；8）规程错误；9）文档编制错误
3. 缺陷管理的依赖关系：1）依赖关联；2）重复关联；3相关关联；4）重复相关关联。
4. 缺陷生命周期：new、Open（Reopen）、Rejected、Fixed、Closed
5. 缺陷报告必要要素：1）简明扼要的标题；2）精确的问题描述；3）确认缺陷版本号；4）简明 的复现步骤；5）必要的附件
6. 复现步骤的特点：精简无冗余、其他人可据此复现缺陷；3）一步对应一个操作；4）使用简单句；5）语言描述客观。 文档问题
1. 测试计划包含内容：产品基本情况、目标、范围、策略、资源配置、进度计划表、缺陷跟踪报告、风险、测试准入/出准则、计划的目的、项目估算、跟踪和控制机制。
2. 测试用例应该包含的内容：
测试用例项主要包含：用例编号、用例名称、用例描述/测试目的、测试数据、前置条件、测试步骤、期望结果、注释、优先级、测试对象(配置)等。
测试用例设计的步骤：
1）测试需求分析、业务流程分析 2）测试用例设计
3）测试用例评审 4）测试用例更新完善 5）测试用例开发与实现 3. 缺陷报告应该包含的内容： 4. 测试总结报告应该包含的内容： 测试注意事项问题
1. 测试人员测试时的注意事项：1）永远不要许诺或保证什么；2）文档反映了自己的精神面貌；3）要学会逆向思维；4）编写缺陷一定要保证重视；5）测试要依据需求，关注对客户不利的缺陷；6）尽量使用测试工具；7）牢记服务意识。 2. 测试人员应具备的素质：1）牢固的软件测试知识；2）较强的沟通能力；3）良好的心理素质（专心、细心、耐心、责任心、自信心，构造心理、批判心理）；4）全面的技术。
3. 测试度量原则：SMART原则：Specific（明确）、Measurable（可度量）、Available（可达到）、Relevant（相关）、Time-bound（有时限）
4. 编写测试用例注意事项：1）功能检查；2）面向用户的考虑；3）数据处理；4）软件流程测试 5. 测试管理问题
1. 软件测试管理目标： 帮助测试团队决定最佳实践。有效、全方位的提高测试覆盖率的手
段。应考虑：1）可用测试资源；2）使用适当的测试技术和方法；3）明确具体软件测试任务（a.测试准备：制定测试计划、编写测试用例、建立测试环境、确定工具方法出入口准则、风险变更控制；b.单元测试：单元测试计划、明确测试用例、执行单元测试、缺陷分析；c.集成测试：集成测试计划、明确测试用例、执行集成测试、缺陷分析；d.功能测试：系统测试计划、明确测试用例、执行系统测试、缺陷分析；e.内部验收测试：内部验收准备、执行内部验收、问题处理、交付与确认）
2. 软件测试分类：1）需求管理；2）质量管理；3）团队管理；4）文档管理；5）缺陷管理；
6）环境管理；7流程管理；8）执行管理；9）风险管理；10）成本管理
3. 软件测试管理要素：质量、人员、流程、技术、资源（团队建设、成本管理、测试架构、
基础设施、项目管理）。
4. 软件测试管理策略：在一定的软件测试标准、测试规范的指导下，依据测试项目的特定环
境约束而规定的软件测试管理原则、方式、方法的集合，需在测试流程、测试计划文档、测试完成标准等信息中体现。
5. 需求管理：一种获取，组织并记录系统需求的系统化方案，以及一个使客户和项目团队对
不断变更的系统需求达成并保持一致的过程。 6. 测试需求管理流程：理解---组织---建档
7. 测试需求分析的两个任务：1）通过对测试活动需要解决问题及其环境的理解、分析和综
合，简历分析模型；2）在完全弄清所有测试活动干系人对测试的确切要求的基础上，用“软件测试需求规格说明书”把测试需求以正式书面形式确定下来。 8. 软件开发变化的原因：客户需求变更/市场需求变更/技术或非技术的其它原因
9. 测试需求状态转换：Open、Analyzed、Reviewed、Resolved、Unresolved、Passed、
Failed、Closed、Canceled
10. 软件质量度量FCM模型：第一层：质量要素：描述性和评价软件质量的一组属性；第二
层：衡量标准，衡量标准的组合，放映某一件质量要素；3）第三层：亮度量度标准可由各使用单位自定义。
11. 质量管理三个关键阶段：质量计划定制；质量控制；质量保证
12. PDCA：Plan（分析现状--找出原因—找主要原因制定措施）---Do（实施计划与措施）---Check（实施结果与目标对比）---Act（对实施结果总结分析—未决问题转入下一循环） 13. 测试文档必要性：1）提高项目测试过程的透明度；2）文档化能规范测试，提高测试效率；
3）便于团队成员之间的交流合作；4）对于“项目”传承的重要性；5）是测试人员禁言提升的最好途径；6）有利于项目测试的监控左右。
因篇幅问题不能全部显示，请点此查看更多更全内容