⚠️各位考生注意，选择官方合作机构进行考试！请勿盲目选择～
1.关于缺陷错误失效：
当存在缺陷的代码被执行时，可能引发的是软件失效，不是错误； （人为）错误，（内在）缺陷，（外部）失效。失效是缺陷在外部的反映； 静态测试，不运行程序，发现的是缺陷； 动态测试，运行程序，发现的是失效； 程序期望结果和实际结果有所偏差称为失效； 失效也可能是外部环境造成的，如电磁场辐射的影响； 缺陷有可能会导致失效，但不是必然的。如果程序不被运行的话，失效也就不会发生。
2.关于测试不同阶段的目标： 早期测试（静态测试）的目标：预防缺陷。 开发阶段的测试（组件测试，集成测试，系统测试）目标：发现缺陷。 验收测试的目标：建立信心。 运行阶段的测试（维护测试）目标：提供信息。
3.关于测试原则： 1） 所有的软件测试都应追溯到用户需求； 2） 应当把“尽早的和不断地进行软件测试”作为软件测试者的座右铭。 3） 完全测试是不可能的，测试需要终止； 4） 测试无法显示软件潜在的缺陷； 5） 充分注意测试中的群集现象； 6） 程序员应该避免检查自己的程序； 7） 尽量避免测试的随意性； 8） 测试应尽早介入。
4.关于独立测试： 测试人员具有专业测试知识背景，独立测试可以更高效地发现软件缺陷和软件存在的失效； 软件测试与软件开发的思维方式不同。由于思维定势，开发人员难于发现自己的错误； 测试通常被认为是破坏性的活动，而软件开发通常被认为是建设性的活动； 独立测试可以应用在任何级别的测试活动中。
5.关于杀虫剂悖论和缺陷集群性： 定期对TC进行Review并持续改善更新，体现了杀虫剂悖论原则。 很多缺陷会集中在某一模块上，体现了缺陷集群性原则。
6.关于测试类型： 结构性测试又称逻辑驱动测试，功能测试又称数据驱动测试。 与变更相关的测试包括确认测试和回归测试。 可移植性测试属于非功能测试。 非功能测试包括性能，负载，可用性，交互性，可维护性，可靠性及可移植性等方面的测试。 功能测试不考虑程序的具体执行路径，仅关注功能是否实现。 安全性测试和互操作性测试属于功能测试的一种。 交互性测试属于非功能测试。
7.各个类型测试的目的： 集成测试的目的是发现接口和集成后组件间协同工作的缺陷。 系统测试的目的是验证系统是否符合用户需求。 验收测试的目的是对系统或子系统建立信心。 组件测试的目的是检查代码是否符合设计和规范。确认所有的错误处理路径属于组件测试的目的。
8. 关于迭代-增量开发模型： 验证和确认可以在每个增量模块中进行。 在完成第一次迭代后，对所有的迭代进行回归测试会变得越来越重要。 在每次迭代过程中，对迭代产生的系统可能需要在不同的测试级别上进行测试。 迭代开发是先开发大体的框架，后开发具体的详细内容。 增量开发是先开发一个详细的模块，再开发另一个详细的模块，形成一个逐渐增大的系统。
9. 系统测试的测试依据： 系统测试的测试依据：1. 系统和软件需求规格说明 2. 用例 3. 功能规格说明 4. 风险分析报告 集成测试的测试依据：1. 软件和系统设计文档 2. 系统架构 3. 工作流 4. 用例
10. 桩模块与驱动模块相关： 桩模块：对顶层或上层模块进行测试时所编写的替代下层模块的程序。 驱动模块：对底层或子层模块进行测试所编写的调用这些模块的程序。
渐增式测试模式自顶向下集成时，前期完成的模块将是后期模块的驱动程序。 渐增式测试模式自底向上集成时，前期完成的模块将是后期模块的桩程序。
非渐增式测试模式：先分别测试每个模块，再把所有模块按设计要求一次全部组装起来所要的系统，然后进行整体测试。非渐增式集成测试是不科学的集成测试方式。 渐增式测试模式：把下一个要测试的模块同已经测试好的模块结合起来进行测试，测试完以后再把下一个模块结合进来测试。
Alpha测试：潜在客户/用户在开发现场进行的测试。 Beta测试：潜在客户/用户在自己的环境下测试。
11.关于评审相关： 1）正式评审:1. 走查 2. 技术评审 3. 审查。 2）工具支持的静态测试（静态分析）: 1. 词法和语法分析 2. 静态错误分析（控制流分析和数据流分析）。 3） 非正式评审没有正式的过程。 走查由作者主持开会。 技术评审可能是没有管理者参与的同行评审。 审查由专门培训的主持人来领导。根据入口、出口准则的检查列表和规则定义正式的评审过程。
12. 3个测试术语相关： 测试条件—-》能通过1个或多个测试用例进行验证的一个条目或事件（比如功能，事物处理，质量特征或结构元素等。） 测试用例—-》一组输入值，执行的前提条件，预期结果和执行的后置条件等元素组成，以覆盖一定的产生目标或测试条件。 测试规程—-》描述测试用例的执行顺序
补充： 测试条件：组件或系统中能被一个或多个测试用例验证的条目或事件。例如：功能、事物、特性、质量属性或者结构化元素。 测试用例：为特定目标或测试条件而制定的一组输入值，执行入口条件，预期结果和执行出口条件。 测试规程：描述测试用例的执行顺序。 测试设计规格说明：为一个测试条目指定测试条件，具体测试方法，并识别相关高层测试用例的文档。 测试用例规格说明：为测试项指定一套测试用例的文档。 测试规程规格说明：规定了执行测试一系列行为的文档，也称为测试脚本或手工测试脚本。
1.关于缺陷错误失效：
当存在缺陷的代码被执行时，可能引发的是软件失效，不是错误； （人为）错误，（内在）缺陷，（外部）失效。失效是缺陷在外部的反映； 静态测试，不运行程序，发现的是缺陷； 动态测试，运行程序，发现的是失效； 程序期望结果和实际结果有所偏差称为失效； 失效也可能是外部环境造成的，如电磁场辐射的影响； 缺陷有可能会导致失效，但不是必然的。如果程序不被运行的话，失效也就不会发生。
2.关于测试不同阶段的目标： 早期测试（静态测试）的目标：预防缺陷。 开发阶段的测试（组件测试，集成测试，系统测试）目标：发现缺陷。 验收测试的目标：建立信心。 运行阶段的测试（维护测试）目标：提供信息。
3.关于测试原则： 1） 所有的软件测试都应追溯到用户需求； 2） 应当把“尽早的和不断地进行软件测试”作为软件测试者的座右铭。 3） 完全测试是不可能的，测试需要终止； 4） 测试无法显示软件潜在的缺陷； 5） 充分注意测试中的群集现象； 6） 程序员应该避免检查自己的程序； 7） 尽量避免测试的随意性； 8） 测试应尽早介入。
4.关于独立测试： 测试人员具有专业测试知识背景，独立测试可以更高效地发现软件缺陷和软件存在的失效； 软件测试与软件开发的思维方式不同。由于思维定势，开发人员难于发现自己的错误； 测试通常被认为是破坏性的活动，而软件开发通常被认为是建设性的活动； 独立测试可以应用在任何级别的测试活动中。
5.关于杀虫剂悖论和缺陷集群性： 定期对TC进行Review并持续改善更新，体现了杀虫剂悖论原则。 很多缺陷会集中在某一模块上，体现了缺陷集群性原则。
6.关于测试类型： 结构性测试又称逻辑驱动测试，功能测试又称数据驱动测试。 与变更相关的测试包括确认测试和回归测试。 可移植性测试属于非功能测试。 非功能测试包括性能，负载，可用性，交互性，可维护性，可靠性及可移植性等方面的测试。 功能测试不考虑程序的具体执行路径，仅关注功能是否实现。 安全性测试和互操作性测试属于功能测试的一种。 交互性测试属于非功能测试。
7.各个类型测试的目的： 集成测试的目的是发现接口和集成后组件间协同工作的缺陷。 系统测试的目的是验证系统是否符合用户需求。 验收测试的目的是对系统或子系统建立信心。 组件测试的目的是检查代码是否符合设计和规范。确认所有的错误处理路径属于组件测试的目的。
8. 关于迭代-增量开发模型： 验证和确认可以在每个增量模块中进行。 在完成第一次迭代后，对所有的迭代进行回归测试会变得越来越重要。 在每次迭代过程中，对迭代产生的系统可能需要在不同的测试级别上进行测试。 迭代开发是先开发大体的框架，后开发具体的详细内容。 增量开发是先开发一个详细的模块，再开发另一个详细的模块，形成一个逐渐增大的系统。
9. 系统测试的测试依据： 系统测试的测试依据：1. 系统和软件需求规格说明 2. 用例 3. 功能规格说明 4. 风险分析报告 集成测试的测试依据：1. 软件和系统设计文档 2. 系统架构 3. 工作流 4. 用例
10. 桩模块与驱动模块相关： 桩模块：对顶层或上层模块进行测试时所编写的替代下层模块的程序。 驱动模块：对底层或子层模块进行测试所编写的调用这些模块的程序。
渐增式测试模式自顶向下集成时，前期完成的模块将是后期模块的驱动程序。 渐增式测试模式自底向上集成时，前期完成的模块将是后期模块的桩程序。
非渐增式测试模式：先分别测试每个模块，再把所有模块按设计要求一次全部组装起来所要的系统，然后进行整体测试。非渐增式集成测试是不科学的集成测试方式。 渐增式测试模式：把下一个要测试的模块同已经测试好的模块结合起来进行测试，测试完以后再把下一个模块结合进来测试。
Alpha测试：潜在客户/用户在开发现场进行的测试。 Beta测试：潜在客户/用户在自己的环境下测试。
11.关于评审相关： 1）正式评审:1. 走查 2. 技术评审 3. 审查。 2）工具支持的静态测试（静态分析）: 1. 词法和语法分析 2. 静态错误分析（控制流分析和数据流分析）。 3） 非正式评审没有正式的过程。 走查由作者主持开会。 技术评审可能是没有管理者参与的同行评审。 审查由专门培训的主持人来领导。根据入口、出口准则的检查列表和规则定义正式的评审过程。
12. 3个测试术语相关： 测试条件—-》能通过1个或多个测试用例进行验证的一个条目或事件（比如功能，事物处理，质量特征或结构元素等。） 测试用例—-》一组输入值，执行的前提条件，预期结果和执行的后置条件等元素组成，以覆盖一定的产生目标或测试条件。 测试规程—-》描述测试用例的执行顺序
补充： 测试条件：组件或系统中能被一个或多个测试用例验证的条目或事件。例如：功能、事物、特性、质量属性或者结构化元素。 测试用例：为特定目标或测试条件而制定的一组输入值，执行入口条件，预期结果和执行出口条件。 测试规程：描述测试用例的执行顺序。 测试设计规格说明：为一个测试条目指定测试条件，具体测试方法，并识别相关高层测试用例的文档。 测试用例规格说明：为测试项指定一套测试用例的文档。 测试规程规格说明：规定了执行测试一系列行为的文档，也称为测试脚本或手工测试脚本。
不错
