软件测试面试题大全（涵盖功能，接口，性能，自动化等等）

语雀地址（更全的面试题）：https://www.yuque.com/wangling-ux2hv

1. 1、你在测试中发现了一个 bug，但是开发经理认为这不是一个 bug，你应该怎样解决。
   a. 首先，将问题提交到缺陷管理库里面进行备案。
   b. 然后，要获取判断的依据和标准：
   c. 根据需求说明书、产品说明、设计文档等，确认实际结果是否与计划有不一致的地方，提供缺陷是否确认的直接依据；
   ⅰ. 如果没有文档依据，可以根据类似软件的一般特性来说明是否存在不一致的地方，来确认是否是缺陷；
   ⅱ. 根据用户的一般使用习惯，来确认是否是缺陷；
   ⅲ. 与设计人员、开发人员和客户代表等相关人员探讨，确认是否是缺陷；
   d. 合理的论述，向测试经理说明自己的判断的理由，注意客观、严谨，不参杂个人情绪。
   e. 等待测试经理做出最终决定，如果仍然存在争议，可以通过公司政策所提供的渠道，向上级反映，并有上级做出决定。
2. 2、给你一个网站，你如何测试？
   a. 首先，查找需求说明、网站设计等相关文档，分析测试需求。
   b. 制定测试计划，确定测试范围和测试策略，一般包括以下几个部分：
   ⅰ. 功能性测试
   ⅱ. 界面测试
   ⅲ. 性能测试
   ⅳ. 数据库测试
   ⅴ. 安全性测试
   ⅵ. 兼容性测试
   c. 设计测试用例：
   ⅰ. 功能性测试可以包括，但不限于以下几个方面：
   1. 链接测试。链接是否正确跳转，是否存在空页面和无效页面，是否有不正确的出错信息返回等。
   2. 提交功能的测试。
   3. 多媒体元素是否可以正确加载和显示。
   4. 多语言支持是否能够正确显示选择的语言等。
      ⅱ. 界面测试可以包括但不限于一下几个方面：
   5. 页面是否风格统一，美观
   6. 页面布局是否合理，重点内容和热点内容是否突出
   7. 控件是否正常使用
   8. 对于必须但为安装的空间，是否提供自动下载并安装的功能
   9. 文字检查
      ⅲ. 性能测试一般从以下两个方面考虑：
   10. 压力测试
   11. 负载测试
   12. 强度测试
       ⅳ. 数据库测试要具体决定是否需要开展。数据库一般需要考虑连结性，对数据的存取操作，数据内容的验证等方面。
       ⅴ. 安全性测试：
   13. 基本的登录功能的检查
   14. 是否存在溢出错误，导致系统崩溃或者权限泄露
   15. 相关开发语言的常见安全性问题检查，例如 SQL 注入等。
   16. 如果需要高级的安全性测试，确定获得专业安全公司的帮助，外包测试，或者获取支持
       ⅵ. 兼容性测试，根据需求说明的内容，确定支持的平台组合：
   17. 浏览器的兼容性
   18. 操作系统的兼容性
   19. 软件平台的兼容性
   20. 数据库的兼容性
       d. 开展测试，并记录缺陷。合理的安排调整测试进度，提前获取测试所需的资源，建立管理体系（例如，需求变更、风险、配置、测试文档、缺陷报告、人力资源等内容）。
       e. 定期评审，对测试进行评估和总结，调整测试的内容。
3. 3、在搜索引擎中输入汉字就可以解析到对应的域名，请问如何用 LoadRunner 进行测试。
   a. 建立测试计划，确定测试标准和测试范围
   b. 设计典型场景的测试用例，覆盖常用业务流程和不常用的业务流程等
   c. 根据测试用例，开发自动测试脚本和场景：
   ⅰ. 录制测试脚本
   ⅱ. 新建一个脚本（Web/HTML 协议）
   ⅲ. 点击录制按钮，在弹出的对话框的 URL 中输入”about:blank”。
   ⅳ. 在打开的浏览器中进行正常操作流程后，结束录制。
   ⅴ. 调试脚本并保存。可能要注意到字符集的关联。
   d. 设置测试场景
   ⅰ. 针对性能设置测试场景，主要判断在正常情况下，系统的平均事务响应时间是否达标
   ⅱ. 针对压力负载设置测试场景，主要判断在长时间处于满负荷或者超出系统承载能力的条件下，系统是否会崩溃。
   e. 执行测试，获取测试结果，分析测试结果
4. 4、一台客户端有三百个客户与三百个客户端有三百个客户对服务器施压，有什么区别？
   a. 300 个用户在一个客户端上，会占用客户机更多的资源，而影响测试的结果。
   b. 线程之间可能发生干扰，而产生一些异常。
   c. 300 个用户在一个客户端上，需要更大的带宽。
   d. IP 地址的问题，可能需要使用 IP Spoof 来绕过服务器对于单一 IP 地址最大连接数的限制。
   e. 所有用户在一个客户端上，不必考虑分布式管理的问题；而用户分布在不同的客户端上，需要考虑使用控制器来整体调配不同客户机上的用户。同时，还需要给予相应的权限配置和防火墙设置。
5. 5、软件都有多少种分类？
   根据功能的不同，电脑软件可以粗略地分成四个层次：
6. 最贴近电脑硬件的是一些小巧的软件。它们实现一些最基本的功能，通常固化在只读存储器芯片中，因此称为固件。
7. 系统软件包括操作系统和编译器软件等。系统软件和硬件一起提供一个平台。它们管理和优化电脑硬件资源的使用。
8. 支持软件。包括图形用户界面、软件开发工具、软件评测工具、数据库管理系统、中间件等。
9. 应用软件种类最多，包括办公软件、电子商务软件、通信软件、行业软件，游戏软件等等。
10. 6、什么是测试用例？什么是测试脚本？两者的关系是什么？
    a. 为实施测试而向被测试系统提供的输入数据、操作或各种环境设置以及期望结果的一个特定的集合。
    b. 测试脚本是为了进行自动化测试而编写的脚本。
    c. 测试脚本的编写必须对应相应的测试用例
11. 7、简述什么是静态测试、动态测试、黑盒测试、白盒测试、α测试、β测试
    a. 静态测试是不运行程序本身而寻找程序代码中可能存在的错误或评估程序代码的过程。
    b. 动态测试是实际运行被测程序，输入相应的测试实例，检查运行结果与预期结果的差异，判定执行结果是否符合要求，从而检验程序的正确性、可靠性和有效性，并分析系统运行效率和健壮性等性能。
    c. 黑盒测试一般用来确认软件功能的正确性和可操作性，目的是检测软件的各个功能是否能得以实现，把被测试的程序当作一个黑盒，不考虑其内部结构，在知道该程序的输入和输出之间的关系或程序功能的情况下，依靠软件规格说明书来确定测试用例和推断测试结果的正确性。
    d. 白盒测试根据软件内部的逻辑结构分析来进行测试，是基于代码的测试，测试人员通过阅读程序代码或者通过使用开发工具中的单步调试来判断软件的质量，一般白盒测试由程序员在开发过程中来实现。
    e. α 测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试，Alpha 测试不能由程序员或测试员完成。
    f. β 测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场，Beta 测试不能由程序员或测试员完成。
12. 8、软件质量保证体系是什么？国家标准中与质量保证管理相关的几个标准是什么？他们的编号和全称是什么？
    a. 来自 Wikipedia 对 SQA 的定义，软件质量保证（SQA）：
    Software Quality Assurance (SQA) consists of the software engineering processes and methods used to ensure quality. SQA encompasses the entire software development process, which may include processes such as reviewing requirements documents, source code control, code reviews, change management, configuration management, release management and of course, software testing.
    SQA 由一套软件工程过程和方法组成，以保证（软件的）质量。SQA 贯穿整个软件开发过程，（它）应包括需求文档评审、代码控制、代码评审、变更管理、配置管理、版本管理和软件测试。
    a. 国家标准：
    ⅰ. GB/T 8567-2006 计算机软件文档编制规范
    ⅱ. GB/T 11457-2006 信息技术 软件工程术语
    ⅲ. GB/T 16260.1-2006 软件工程　产品质量 第 1 部分：质量模型
    ⅳ. GB/T 16260.2-2006 软件工程　产品质量 第 2 部分：外部度量
    ⅴ. GB/T 16260.3-2006 软件工程　产品质量 第 3 部分：内部度量
    ⅵ. GB/T 16260.4-2006 软件工程 产品质量 第 4 部分：使用质量的度量
    ⅶ. GB/Z 20156-2006 软件工程　软件生成周期过程　用于项目管理的指南
    ⅷ. GB/T 20157-2006 信息技术 软件维护
    ⅸ. GB/T 20158-2006 信息技术　软件生成周期过程　配置管理
13. 9、软件产品质量特性是什么？
    a. 功能性：适应性、准确性、互操作性、依从性、安全性。
    b. 可靠性：成熟性、容错性、以恢复性。
    c. 可使用性：易理解性、易学习性、易操作性。
    d. 效率：时间特性、资源特性。
    e. 可维护性：易分析性、易变更性、稳定性、易测试性。
    f. 可移植性： 适应性、易安装性、遵循性、易替换性。
14. 10、软件测试的原则与策略是什么？
15. 软件测试的原则：
    教材的说法：
16. 软件测试应尽早执行，并贯穿于整个软件生命周期
17. 软件测试应追溯需求
18. 测试应由第三方来构造
19. 穷举测试是不可能的，要遵循 Good-enough 原则
20. 必须确定预期输出（或结果）
21. 必须彻底检查每个测试结果
22. 充分注意测试中的群集现象
23. 缺陷的二八定理
24. 严格执行测试计划，排除测试的随意性
25. 注意合法合理的输入，也要注意非法的非预期的输入
26. 检查程序是否是否做了不该做的
27. 测试应从小规模开始，逐步转向大规模13. 反复使用同样的测试会使软件具有抵抗力
28. 关注缺陷的修复
29. 另一种说法：
30. 应当把尽早和不断地测试作为开发者的座右铭。
31. 程序员应该避免检查自己的程序，测试工作应该由独立的专业的软件测试机构来完成。
32. 设计测试用例时，应该考虑到合法的输入和不合法的输入，以及各种边界条件，特殊情况下要制造极端状态和意外状态，比如网络异常中断、电源断电等情况。
33. 一定要注意测试中的错误集中发生现象，这和程序员的编程水平和习惯有很大的关系。
34. 对测试错误结果一定要有一个确认的过程。一般有 A 测试出来的错误，一定要有一个 B 来确认，严重的错误可以召开评审会进行讨论和分析。
35. 制定严格的测试计划，并把测试时间安排得尽量宽松，不要希望在极短的时间内完成一个高水平的测试。
36. 回归测试的关联性一定要引起充分的注意，修改一个错误而引起更多错误出现的现象并不少见。
37. 妥善保存一切测试过程文档，意义是不言而喻的，测试的重现性往往要靠测试文档。
38. 软件测试策略：在一定的软件测试标准、测试规范的指导下，依据测试项目的特定环境约束而规定的软件测试的原则、方式、方法的集合。
39. 11、结构化系统测试和功能性系统测试分别采用了哪些方法和技术？
    a. 结构化系统测试技术：用于验证所开发的系统及程序的运行情况。目标是要确保产品设计在结构上合理，功能上正确。为确定实现的配置及其各功能共同作用以完成特定任务提供了一种机制。结构化测试技术由以下几种：
    ⅰ. 压力测试：确定系统以期望的容量执行。
    压力测试技术用于检查系统面对意外情况下的大数据量时是否可以正常运行。所涉及的方面包括输入事务、内部表、磁盘空间、输出、通信、计算机容量以及人机交互等。
    当应用系统所能正常处理的工作量并不确定时需要使用压力测试。压力测试意图通过对系统施加超负载事务量来达到破坏系统的目的。弱点在于准备测试的时间与在测试的实际执行过程中所消耗的资源数量都非常之大，通常在应用程序投入使用之前这种技术是无法进行的。
    ⅰ. 执行测试：系统能达到期望的熟练性。
    举例：事务轮转时间充分；软硬件使用良好。
    执行测试技术用于检查系统是否达到了预期在产品状态下的成熟度。执行测试可以验证系统的响应时间、轮转时间及设计性能。
    在开发过程的早期就应该进行执行测试，尽早制定已经完成的系统没有达到性能指标是非常有价值的。在关键时间点进行。关键时间点指的是当前的结果会影响甚至改变系统结构的时间点。
    ⅰ. 恢复测试：系统失效之后可以恢复到可操作状态。
    举例：引入失败；评估备份数据的充分性。
    恢复测试技术用于确保系统在经历灾难后可以继续正常运行，它不仅可以验证恢复过程，而且可以验证过程各组件的有效性。
    当用户认为系统操作的连续性对于其所涉及领域的某些功能至关重要时，需要进行恢复测试。
    ⅰ. 操作测试：系统以正常操作状态执行。
    举例：确定系统可以依据文档进行运行；JCL（工作控制语言）充分。
    操作测试技术主要用于检查系统在正常的操作状态下是否可以执行。操作测试可以与其它测试联合执行。
    任何应用程序在成为产品之前都应进行操作测试。
    ⅰ. （与过程的）一致性测试：系统的开发与标准和规程相一致。
    举例：按标准执行；文档完整。
    一致性测试技术用于验证应用程序的开发是否与信息技术指标、过程及准则相一致。一致性测试最有效的方法是过程审查。
    系统开发标准和过程的一致性程度依赖于管理层对于所需遵循的特定过程和执行标准的重视程度。
    ⅰ. 安全性测试：根据组织的重要性对系统进行保护。
    举例：访问拒绝；规程适当。
    安全性测试技术用于评价保护性程序及安全对策的充分性。安全性缺陷不如其它类型的缺陷那么明显。安全性测试是测试过程中高度专业化的部分。分物理安全性（针对利用物理方法收集信息的手段）和逻辑安全性（针对使用计算机处理和通信能力进行非法活动信息的手段）。
    当系统保护信息和资产对于组织来说意义重大时，需要进行安全性测试。
    a. 功能性系统测试用于确保系统需求与定义都得到了满足。该过程通常包含创建用于评价应用程序正确性的测试条件。用于执行功能测试的几种测试技术包括：
    ⅰ. 需求测试：系统按制定方式执行。
    举例：证明系统需求；与政策、规则相一致。
    需求测试技术验证系统是否正确执行其功能，并且能保证在相当长的一段时间内保持其正确性。需求测试的执行主要通过执行创建的测试条件以及功能检查单来完成，通过需求得到测试条件，然后以类似于 SDLC 这种特定的方式表现，生成用于评价实现的应用系统的测试数据。
    任何应用程序都应该对需求进行测试，此过程应该开始于需求阶段，并一直持续到系统运行和维护阶段。
    ⅰ. 回归测试：验证系统中没有改变的部分仍能正确运行。
    举例：未变更的部分正常运行；未变更的人工规程正确。
    回归测试技术对已经测试过的部分进行重新测试，以保证它们在应用程序其它部分发生变更之后仍能正常运行。
    当变更会对应用程序中没有变更的部分产生高风险的影响时需要进行回归测试。
    ⅰ. 错误处理测试：错误可以得到防止或检测，并被修复。
    举例：将错误引入测试；错误的再次注入。
    人工系统与自动系统之间差别的特点之一就是预定义的错误处理特性。错误处理测试技术用于检查应用系统正确处理发生异常的能力。错误处理测试需要一组知识丰富的人员来预见应用系统可能发生的错误。它是测试错误的引入、错误的处理，控制条件以及条件的再次正确输入。
    在系统整个生命周期中都应该进行错误测试。在开发过程中，应该识别错误带来的问题并且采取相应的措施将错误减少到可以接受的程度。
    ⅰ. 人工支持测试：人机交互有效。
    举例：具备人工规程；人员接受过培训。
    人工支持测试技术主要包括人员在准备数据以及使用来源于自动程序数据的过程中执行所有功能。
    在生命周期的全过程都应该验证人工系统功能的正确性。
    ⅰ. 系统间测试：数据可以正确地在系统间传递。
    举例：系统间参数变化；系统间文档更新。
    系统间测试技术用于保证应用程序间相互管理的正确性。系统间测试的一个最好的工具是集成测试工具，它允许在产品环境下进行测试，可以以最小的代价测试系统间的耦合性。
    在应用系统间的参数发生变更时需要进行系统间的测试。测试的程度和类型依赖于与出错的参数相关联的风险情况。
    ⅰ. 控制测试：将系统风险控制降低到可以接受的级别。
    举例：文件一致性规程正常；人工控制正确。
    控制测试技术包括数据确认、文件完整性控制、评审追踪、备份和恢复、文档，以及与系统完整性相关的其它方面。主要用于确保对系统特定功能的检查。可以用于控制测试的一个方法是生成风险矩阵。
    控制测试是系统测试中的一个完整的部分，占测试时间的很大比例。
    ⅰ. 平行测试：发现原系统与新系统之间的意外差异。
    举例：原系统与新系统一致；原系统仍然可以工作。
    平行测试技术用于检查新应用程序的结果是否与原来的应用程序或者上一版本应用程序的处理相一致。它执行冗余处理以保证新版本或者新应用程序执行的正确性；给出同一应用程序不同版本之间一致的和不一致的地方。平行测试可以对整个应用程序进行，也可对应用程序的一部分进行。
    当不能确定新应用程序处理的正确性，或者当新旧版本的应用程序非常类似时，需要进行平行测试。
40. 12、软件测试分为几个阶段 各阶段的测试策略和要求是什么？
    a. 软件测试按阶段划分可以分为单元测试、集成测试、系统测试和《验收测试》（不一定有）几个阶段
    b. 单元测试测试策略：
    ⅰ. 自顶向下的单元测试策略
    方法：先对最顶层的基本单元进行测试，把所有调用的单元做成桩模块。然后再对第二层的基本单元进行测试，使用上面已测试的单元做驱动模块。依此类推直到测试完所有基本单元。
    优点：在集成测试前提供早期的集成途径。在执行上和详细设计的顺序一致。不需要开发驱动模块。
    缺点：随着测试的进行，测试过程越来越复杂，开发和维护成本增加。
    总结：比孤立单元测试的成本高很多，不是单元测试的一个好的选择。
    ⅰ. 自底向上的单元测试策略
    方法：先对最底层的基本单元进行测试，模拟调用该单元的单元做驱动模块。然后再对上面一层进行测试，用下面已被测试过的单元做桩模块。依此类推，直到测试完所有单元。
    优点：在集成测试前提供系统早期的集成途径。不需要开发桩模块。
    缺点：随着测试的进行，测试过程越来越复杂。
    总结：比较合理的单元测试策略，但测试周期较长。
    ⅰ. 孤立单元测试策略
    方法：不考虑每个单元与其它单元之间的关系，为每个单元设计桩模块或驱动模块。每个模块进行独立的单元测试。
    优点：简单、容易操作，可达到高的结构覆盖率。
    缺点：不提供一种系统早期的集成途径。
    总结：最好的单元测试策略。
    a. 集成测试的测试策略：
    ⅰ. 大爆炸集成
    优点：可以迅速完成集成测试；并且只要极少数的驱动和桩模块；用例也是最少的；简单；资源利用率高
    缺点：一次试运行成功的可能性不大，问题定位和修改比较困难，许多接口错误很容易躲过测试。
    适应于一个维护型项目或被测试系统较小
    ⅰ. 自顶向下集成
    优点：较早地验证了主要控制和判断点；按深度优先可以首先实现和验证一个完整的软件功能；功能较早证实，带来信心；只需一个驱动，减少驱动器开发的费用；支持故障隔离。
    缺点：柱的开发量大；底层验证被推迟；底层组件测试不充分。
    适应于产品控制结构比较清晰和稳定；高层接口变化较小；底层接口未定义或经常可能被修改；产口控制组件具有较大的技术风险，需要尽早被验证；希望尽早能看到产品的系统功能行为。
    ⅰ. 自底向上集成
    优点：对底层组件行为较早验证；工作最初可以并行集成，比自顶向下效率高；减少了桩的工作量；支持故障隔离。
    缺点：驱动的开发工作量大；对高层的验证被推迟，设计上的错误不能被及时发现。
    适应于底层接口比较稳定；高层接口变化比较频繁；底层组件较早被完成。
    ⅰ. 三明治集成
    优点：集合了自顶向下和自底向上两种策略的优点
    缺点：中间层测试不充分
    适应于大部分软件开发项目
    ⅰ. 基干集成
    优点：具有三明治集成的优点，更适合于大型复杂项目的集成。
    缺点：必须对系统的结构和相互依存性进行仔细的分析；驱动和桩开发量大；局部采用了大爆炸的策略，有些接口可能测试不充分。
    嵌入式系统中常用
    ⅰ. 分层集成
    适应于有明显层次关系的系统
    ⅰ. 基于功能的集成
    优点：优先验证关键功能的正确性；减少驱动的开发；进度要快。
    缺点：对接口测试不充分；有较大的冗余测试。
    ⅰ. 基于消息的集成
    优点：优先验证关键消息的正确性；减少驱动的开发；进度要快。
    缺点：对接口测试不充分；有较大的冗余测试。
    ⅰ. 基于风险的集成
    优点：最具有风险的组件最早进地验证，有助于系统的快速稳定。
    缺点：需要对各组件的风险有一个清晰的分析。
    ⅰ. 基于进度的集成
    优点：具有较高的并行度；能够有效缩短项目的开发进度。
    缺点：桩和驱动工作量较大；有些接口测试不充分；有些测试重复和浪费。
    a. 系统测试的测试策略：
    ⅰ. 数据和数据库完整性测试
    ⅱ. 功能测试
    ⅲ. 用户界面测试
    ⅳ. 性能评测
    ⅴ. 负载测试
    ⅵ. 强度测试
    ⅶ. 容量测试
    ⅷ. 安全性和访问控制测试
    ⅸ. 故障转移和恢复测试
    X. 配置测试
    Xⅰ. 安装测试
    Xⅱ. 加密测试
    Xⅲ. 可用性测试
    Xⅳ. 版本验证测试
    Xⅴ. 文档测试
41. 13、面向对象的测试用例设计有几种方法？如何实现？
42. Berard 提出了一些测试用例的设计方法，主要原则包括：
43. 每个测试用例应当给予特殊的标识，并且还应当与测试的类有明确的联系。
44. 测试目的应当明确。
45. 应当为每个测试用例开发一个测试步骤列表。这个列表应包含以下一些内容：
46. 列出所要测试对象的专门说明。
47. 列出将要作为测试结果运行的消息和操作。
48. 列出测试对象可能发生的例外情况。
49. 列出外部条件（即为了正确对软件进行测试所必须有的外部环境的变化）。
50. 列出为了帮助理解和实现测试所需要的附加信息。
51. 主要方法：
52. 基于故障的测试
    基于故障测试也可以用于组装测试，组装测试可以发现消息联系中可能的故障。
    可能的故障一般为意料之外的结果、错误地使用了操作 / 消息、不正确引用等。为了确定由操作（功能）引起的可能故障必须检查操作的行为。
    这种方法除用于操作测试外，还可用于属性测试，用以确定其对于不同类型的对象行为是否赋予了正确的属性值。因为一个对象的属性是由其赋予属性的值定义的。
53. 基于脚本的测试
    基于脚本的测试主要关注用户需要做什么，而不是产品能做什么，即从用户任务（使用用例）中找出用户要做什么及去执行。
    这种基于脚本的测试有助于在一个单元测试情况下检查多重系统。所以基于脚本测试用例测试比基于故障测试不仅更实际（接近用户），而且更复杂一点。
54. OO 类的随机测试
    如果一个类有多个操作（功能），这些操作（功能）序列有多种排列。而这种不变化的操作序列可随机产生，用这种可随机排列的序列来检查不同类实例的生存史，就叫随机测试。
55. 类层次的分割测试
    这种测试可以减少用完全相同的方式检查类测试用例的数目。这很像传统软件测试中的等价类划分测试。分割测试又可分三种。
56. 基于状态的分割。按类操作是否改变类的状态来分割（归类）。
57. 基于属性的分割。按类操作所用到的属性来分割（归类）。
58. 基于类型的分割。按完成的功能分割（归类）。
59. 由行为模型（状态、活动、顺序和合作图）导出的测试
    状态转换图（STD）可以用来帮助导出类的动态行为的测试序列，以及这些类与之合作的类的动态行为测试序列。
60. 14、在软件测试各个阶段通常完成什么工作？各个阶段的结果文件是什么？包括什么内容？
    a. 单元测试阶段。
    各独立单元模块在与系统地其他部分相隔离的情况下进行测试，单元测试针对每一个程序模块进行正确性校验，检查各个程序模块是否正确地实现了规定的功能。生成单元测试报告，提交缺陷报告。
    a. 集成测试阶段。
    集成测试是在单元测试的基础上，测试在将所有的软件单元按照概要设计规格说明的要求组装成模块、子系统或系统的过程中各部分工作是否达到或实现相应技术指标及要求的活动。该阶段生成集成测试报告，提交缺陷报告。
    a. 系统测试阶段。
    将通过确认测试的软件，作为整个给予计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结合在一起，在实际运行环境下，对计算机系统进行全面的功能覆盖。该阶段需要提交测试总结和缺陷报告。
61. 15、介绍一下整体项目流程
    a. 搭建缺陷管理的环境和测试环境以及配置管理的环境搭建；
    b. 编写测试计划；
    c. 设计测试用例；
    d. 编写测试用例；
    e. 测试用例的评审；
    f. 执行测试；
    g. 缺陷管理；
    h. 测试报告的输出
62. 16、在实际项目中你是如何做测试计划
    a. 对客户提供的或需求分析人员编写的用户需求文档或需求规格说明书进行分析，提炼出测试要点；
    b. 根据测试要点编写测试用例。
    c. 由评审组对测试用例进行评审 – 修改 – 再次评审 – 初步定稿
    d. 执行测试
    ⅰ. 按照测试用例对系统进行功能验证及客户的需求验证
    ⅱ. 将测试过程中产生的 Bug 录入缺陷管理系统
    ⅲ. 新版本发布后，对本次版本新增加的功能以及开发人员修正的 Bug 进行回归测试
    ⅳ. 根据项目需要提交测试报告。
63. 17、你是如何制定测试过程中的时间进度表的
    根据项目的需求、开发周期、开发人员的开发进度等时间安排来制定一个测试时间进度初稿，并将测试时间进度表交与整个项目团队成员大家一起讨论和分析，最终和所有人达成共识制定出一个大家都可以执行的测试时间进度表。
    时间表中包括了开发人员提交功能或功能模块的时间，以及为了更好的执行测试，配合测试人员进行功能培训的时间，以及测试执行时间等，都详细的写到 Word 中，并按照这个时间进度表来执行项目的测试任务。
64. 18、测试计划都包括那些项
    a. 测试计划目标
    b. 测试参考文档
    c. 测试术语与定义
    d. 测试内容
    e. 测试人员的分工
    f. 测试进度
    g. 测试流程
    h. 测试工具
    i. 测试缺陷管理
    j. 测试的风险分析
65. 19、测试用例如何设计的
    在测试用例设计之前首先要熟悉客户的需求文档或需求规格说明书，以做到对被测系统的熟悉，充分了解产品的详细功能，并在熟悉过程中即使与研发人员和客户人员进行有效的沟通。然后从需求中提炼中各个模块的详细功能点编写出一个测试要点的文档。
    根据测试要点设计测试用例，测试要点与测试用例是一个一对多的关系，一个测试要点可能会需要几个测试用例的验证，有正常的操作和异常的操作，甚至是几个正常与几个异常的操作，这要根据实际功能的要求来具体分析具体实现。
66. 20、测试用例包括那些项
    产品名称、功能模块、用例的编号、编写人、被测功能的简述，测试的预置条件，测试步骤，预期结果，实际结果。
67. 21、缺陷处理流程
    a. 讲缺陷的详细信息录入缺陷管理系统，并分配给对应的开发人员
    b. 如果遇到一些难以再现的缺陷，在开发人员修正过程中配合开发人员进行 Bug 的再现。
    c. 开发人员修正 Bug 后，会在缺陷管理系统中将修正后的 Bug 状态更改，通常为 Fixed 状态。
    d. 新版本发布后，测试人员会讲 bug 状态已经更改为 Fixed 的 Bug 进行回归测试。如果测试通过，则将该 Bug 关闭，如果仍未通过，则将该 Bug 从 Fixed 更改为 Reopen 状态，继续让开 发人员来修正。并等待下一个新版本发布后的二次回归测试。
68. 22、缺陷报告包括那些项
    编写人、被测系统的版本号、测试环境、预期结果、实际结果、对于实际结果如有必要附上截图、测试用例数、测试用例通过数，测试用例的通过率、对缺陷的一个分析汇总。
69. 23、缺陷报告严重级别的划分
    ○ 严重：影响系统整体基本流程运行的错误，由于某一操作造成系统死循环或服务器崩溃的错误
    ○ 较严重：功能实现错误、内部计算错误
    ○ 一般：UI 错误，一些易用性的错误或建议
70. 24、开发人员修复缺陷后，如何保证不影响其他功能
    Bug 的修复以及新功能的添加都有可能对版本造成一些影响，为了避免，在新版本发布以后，首先会对新版本做一个基础的流程测试也叫做冒烟测试，如果测试基本流程都顺利通过没有任何问题，那么测试人员可以继续进行详细的测试，否则就将冒烟测试中出现的问题以及问题有可能出现的原因反馈给开发人员，由开发人员修正后再次发版，进行测试。
    这是一个迭代的过程。
71. 25、发现问题后你是如何判断其是否是 BUG，你是如何提交的？
    测试用例是经过评审组严格的评审，完全按照客户的需求规格说明书作为最终依据来评审的，如果测试过程中，测试结果与实际结果不符就很可能是 Bug，如果一些比较明显的问题就直接录入缺陷管理系统，如果是一些边界问题不容易确定的，可以通过和开发人员甚至是设计人员等进行沟通最后得出一个结果究竟是否是 Bug，如果是 Bug 就录入，如果是一个需要增加的新功能等，可以录入缺陷管理系统，类型为新需求。
72. 26、修复一个 BUG 而导致其他的 BUG 出现，该如何处理
    帮助开发人员分析问题锁定原因然后进行新 Bug 的修正
73. 27、测试总结报告包括那些项
    测试用例的通过数，测试用例的未通过数，以及测试用例的通过率，未通过的功能都集中在哪几个功能模块，根据测试经验以及测试结果进行一个缺陷的分析和建议。
74. 28、测试工作进行到一半时候，发现时间不够，你如何处理
    a. 与客户沟通本次发布的版本什么是最重要的，什么是其次，我会安排一个优先级来对整体测试功能进行一个筛选。
    b. 我会和测试组全体人员一起加班
75. 29、开发与测试的关系
    开发和测试是一个整体，也可以说测试驱动着开发，开发配合着测试，相辅相成的，在一个完整的项目组中缺一不可。
76. 30、如果你是测试组长你如何对项目及组员进行管理
    首先要从需求开始，充分了解被测系统的功能以及业务需求，并在遇到问题的时候及时有效的与开发人员以及其他项目相关人员进行沟通，做到最被测系统的十分熟悉。并了解整个测试组的成员他们的测试技能以及擅长的工作，做到测试任务的合理分配，得以让测试工作快速，稳定高效的进行！
77. 31、如果你提交的 BUG 开发人员说这不是缺陷你该怎么办
    若遇到开发人员说提交 BUG 不是缺陷则跟项目组的需求人员，设计人员以及该功能的开发人员共同讨论做确认。
78. 32、为什么要在一个团队中开展软件测试工作？
    因为没有经过测试的软件很难在发布之前知道该软件的质量，就好比 ISO 质量认证一样，测试同样也需要质量的保证，这个时候就需要在团队中开展软件测试的工作。在测试的过程发现软件中存在的问题，及时让开发人员得知并修改问题，在即将发布时，从测试报告中得出软件的质量情况。
79. 33、你在以往的测试工作中都曾经具体从事过哪些工作？其中最擅长哪部分工作？
    我曾经做过 web 测试，后台测试，客户端软件，其中包括功能测试，性能测试，用户体验测试。最擅长的是功能测试。
80. 34、你所熟悉的软件测试类型都有哪些？请试着分别比较这些不同的测试类型的区别与联系（如功能测试、性能测试……）
    测试类型有：功能测试，性能测试，界面测试。
    ○ 功能测试在测试工作中占的比例最大，功能测试也叫黑盒测试。是把测试对象看作一个黑盒子。利用黑盒测试法进行动态测试时，需要测试软件产品的功能，不需测试软件产品的内部结构和处理过程。采用黑盒技术设计测试用例的方法有：等价类划分、边界值分析、错误推测、因果图和综合策略。
    ○ 性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试，两者可以结合进行。通过负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试。
    ○ 界面测试，界面是软件与用户交互的最直接的层，界面的好坏决定用户对软件的第一印象。而且设计良好的界面能够引导用户自己完成相应的操作，起到向导的作用。同时界面如同人的面孔，具有吸引用户的直接优势。设计合理的界面能给用户带来轻松愉悦的感受和成功的感觉，相反由于界面设计的失败，让用户有挫败感，再实用强大的功能都可能在用户的畏惧与放弃中付诸东流。
    区别在于，功能测试关注产品的所有功能上，要考虑到每个细节功能，每个可能存在的功能问题。性能测试主要关注于产品整体的多用户并发下的稳定性和健壮性。界面测试更关注于用户体验上，用户使用该产品的时候是否易用，是否易懂，是否规范（快捷键之类的），是否美观（能否吸引用户的注意力），是否安全（尽量在前台避免用户无意输入无效的数据，当然考虑到体验性，不能太粗鲁的弹出警告）？做某个性能测试的时候，首先它可能是个功能点，首先要保证它的功能是没问题的，然后再考虑该功能点的性能测试
81. 35、你认为做好测试用例设计工作的关键是什么？
    白盒测试用例设计的关键是以较少的用例覆盖尽可能多的内部程序逻辑结果
    黑盒法用例设计的关键同样也是以较少的用例覆盖模块输出和输入接口。
    不可能做到完全测试，以最少的用例在合理的时间内发现最多的问题
82. 36、请试着比较一下黑盒测试、白盒测试、单元测试、集成测试、系统测试、验收测试的区别与联系。

• 黑盒测试：
  已知产品的功能设计规格，可以进行测试证明每个实现了的功能是否符合要求。
• 白盒测试：
  已知产品的内部工作过程，可以通过测试证明每种内部操作是否符合设计规格要求，所有内部成分是否以经过检查。
  软件的黑盒测试意味着测试要在软件的接口处进行。这种方法是把测试对象看做一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明。因此黑盒测试又叫功能测试或数据驱动测试。黑盒测试主要是为了发现以下几类错误：

1. 是否有不正确或遗漏的功能？
2. 在接口上，输入是否能正确的接受？能否输出正确的结果？
3. 是否有数据结构错误或外部信息（例如数据文件）访问错误？
4. 性能上是否能够满足要求？
5. 是否有初始化或终止性错误？
   软件的白盒测试是对软件的过程性细节做细致的检查。这种方法是把测试对象看做一个打开的盒子，它允许测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。通过在不同点检查程序状态，确定实际状态是否与预期的状态一致。因此白盒测试又称为结构测试或逻辑驱动测试。白盒测试主要是想对程序模块进行如下检查：
6. 对程序模块的所有独立的执行路径至少测试一遍。
7. 对所有的逻辑判定，取真与取假的两种情况都能至少测一遍。
8. 在循环的边界和运行的界限内执行循环体。
9. 测试内部数据结构的有效性，等等。

• 单元测试（模块测试）是开发者编写的一小段代码，用于检验被测代码的一个很小的、很明确的功能是否正确。
  通常而言，一个单元测试是用于判断某个特定条件（或者场景）下某个特定函数的行为。
  单元测试是由程序员自己来完成，最终受益的也是程序员自己。可以这么说，程序员有责任编写功能代码，同时也就有责任为自己的代码编写单元测试。执行单元测试，就是为了证明这段代码的行为和我们期望的一致。
• 集成测试（也叫组装测试，联合测试）是单元测试的逻辑扩展。
  它的最简单的形式是：两个已经测试过的单元组合成一个组件，并且测试它们之间的接口。从这一层意义上讲，组件是指多个单元的集成聚合。在现实方案中，许多单元组合成组件，而这些组件又聚合成程序的更大部分。方法是测试片段的组合，并最终扩展进程，将你的模块与其他组的模块一起测试。最后，将构成进程的所有模块一起测试。
• 系统测试是将经过测试的子系统装配成一个完整系统来测试。
  它是检验系统是否确实能提供系统方案说明书中指定功能的有效方法。（常见的联调测试）
  系统测试的目的是对最终软件系统进行全面的测试，确保最终软件系统满足产品需求并且遵循系统设计。
• 验收测试是部署软件之前的最后一个测试操作。
  验收测试的目的是确保软件准备就绪，并且可以让最终用户将其用于执行软件的既定功能和任务。
  验收测试是向未来的用户表明系统能够像预定要求那样工作。经集成测试后，已经按照设计把所有的模块组装成一个完整的软件系统，接口错误也已经基本排除了，接着就应该进一步验证软件的有效性，这就是验收测试的任务，即软件的功能和性能如同用户所合理期待的那样。

1. 37、测试计划工作的目的是什么？测试计划工作的内容都包括什么？其中哪些是最重要的？
   软件测试计划是指导测试过程的纲领性文件，包含了产品概述、测试策略、测试方法、测试区域、测试配置、测试周期、测试资源、测试交流、风险分析等内容。借助软件测试计划，参与测试的项目成员，尤其是测试管理人员，可以明确测试任务和测试方法，保持测试实施过程的顺畅沟通，跟踪和控制测试进度，应对测试过程中的各种变更。
   测试计划和测试详细规格、测试用例之间是战略和战术的关系，测试计划主要从宏观上规划测试活动的范围、方法和资源配置，而测试详细规格、测试用例是完成测试任务的具体战术。所以其中最重要的是测试测试策略和测试方法（最好是能先评审）
2. 38、你认为做好测试计划工作的关键是什么？
3. 明确测试的目标，增强测试计划的实用性
   编写软件测试计划得重要目的就是使测试过程能够发现更多的软件缺陷，因此软件测试计划的价值取决于它对帮助管理测试项目，并且找出软件潜在的缺陷。因此，软件测试计划中的测试范围必须高度覆盖功能需求，测试方法必须切实可行，测试工具并且具有较高的实用性，便于使用，生成的测试结果直观、准确
4. 坚持5W规则，明确内容与过程
   5W规则指的是What（做什么）、Why（为什么做）、When（何时做）、Where（在哪里）、How（如何做）。利用5W规则创建软件测试计划，可以帮助测试团队理解测试的目的（Why），明确测试的范围和内容（What），确定测试的开始和结束日期（When），指出测试的方法和工具（How），给出测试文档和软件的存放位置（Where）。
5. 采用评审和更新机制，保证测试计划满足实际需求
   测试计划写作完成后，如果没有经过评审，直接发送给测试团队，测试计划内容的可能不准确或遗漏测试内容，或者软件需求变更引起测试范围的增减，而测试计划的内容没有及时更新，误导测试执行人员。
6. 分别创建测试计划与测试详细规格、测试用例
   应把详细的测试技术指标包含到独立创建的测试详细规格文档，把用于指导测试小组执行测试过程的测试用例放到独立创建的测试用例文档或测试用例管理数据库中。测试计划和测试详细规格、测试用例之间是战略和战术的关系，测试计划主要从宏观上规划测试活动的范围、方法和资源配置，而测试详细规格、测试用例是完成测试任务的具体战术。
7. 39、你所熟悉的测试用例设计方法都有哪些？请分别以具体的例子来说明这些方法在测试用例设计工作中的应用。
   a. 等价类划分
   划分等价类：等价类是指某个输入域的子集合。在该子集合中，各个输入数据对于揭露程序中的错误都是等效的。并合理地假定：测试某等价类的代表值就等于对这一类其它值的测试。因此，可以把全部输入数据合理划分为若干等价类，在每一个等价类中取一个数据作为测试的输入条件，就可以用少量代表性的测试数据。取得较好的测试结果。等价类划分可有两种不同的情况：有效等价类和无效等价类。
   a. 边界值分析法
   边界值分析方法是对等价类划分方法的补充。测试工作经验告诉我，大量的错误是发生在输入或输出范围的边界上，而不是发生在输入输出范围的内部。因此针对各种边界情况设计测试用例，可以查出更多的错误。
   使用边界值分析方法设计测试用例，首先应确定边界情况。通常输入和输出等价类的边界，就是应着重测试的边界情况。应当选取正好等于，刚刚大于或刚刚小于边界的值作为测试数据，而不是选取等价类中的典型值或任意值作为测试数据。
   a. 错误推测法
   基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性的设计测试用例的方法。
   错误推测方法的基本思想：列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据他们选择测试用例。例如，在单元测试时曾列出的许多在模块中常见的错误。以前产品测试中曾经发现的错误等，这些就是经验的总结。还有，输入数据和输出数据为 0 的情况。输入表格为空格或输入表格只有一行。这些都是容易发生错误的情况。可选择这些情况下的例子作为测试用例。
   a. 因果图方法
   前面介绍的等价类划分方法和边界值分析方法，都是着重考虑输入条件，但未考虑输入条件之间的联系，相互组合等。考虑输入条件之间的相互组合，可能会产生一些新的情况。但要检查输入条件的组合不是一件容易的事情，即使把所有输入条件划分成等价类，他们之间的组合情况也相当多。因此必须考虑采用一种适合于描述对于多种条件的组合，相应产生多个动作的形式来考虑设计测试用例。这就需要利用因果图（逻辑模型）. 因果图方法最终生成的就是判定表。它适合于检查程序输入条件的各种组合情况。
8. 40、详细的描述一次测试用例设计的完整的过程。
   就说最近的这次网站功能的测试吧
   首先：得到相关文档（需求文档和设计文档），理解需求和设计设计思想后，想好测试策略（测试计划简单点就 OK 了），考虑到测试环境，测试用例，测试时间等问题。
   第二步：设计测试用例，测试策略是：把网站部分的功能点测试完，然后在进行系统测试（另外个模块呢有另一个测试人员负责，可以进行联调测试），网站模块的测试基本是功能测试和界面测试（用户并发的可能性很小，所以不考虑）：这次的网站的输入数据呢是使用数据库中的某张表记录，如果表中某一数据记录中新加进来的（还没有被处理的，有个标志位），网站启动后会立刻去刷那张表，得到多条数据，然后在进行处理。处理过程中，会经历 3 个步骤，网站才算完成了它的任务。有 3 个步骤呢，就可以分别对这 3 个步骤进行测试用例的设计，尽量覆盖到各种输入情况（包括数据库中的数据，用户的输入等），得出了差不多 50 个用例。界面测试，也就是用户看的到的地方，包括发送的邮件和用户填写资料的页面展示。
   第三步：搭建测试环境（为什么这个时候考虑测试环境呢？因为我对网站环境已经很熟了，只有有机器能空于下来做该功能测试就可以做了），因为网站本身的环境搭建和其他的系统有点不同，它需要的测试环境比较麻烦，需要 web 服务器（Apache,tomcat），不过这次需求呢，网站部分只用到了 tomcat，所以只要有 tomcat 即可
   第四步：执行测试
9. 41、什么是桩模块？什么是驱动模块？
   桩模块：被测模块调用模块
   驱动模块 调用被测模块
10. 42、你以前工作时的测试流程是什么？
    公司对测试流程没有规定如何做，但每个测试人员都有自己的一套测试流程。
    我说下我 2 年来不断改正（自己总结，吸取同行的方法）后的流程吧。
    需求评审（有开发人员，产品经理，测试人员，项目经理）－>需求确定（出一份确定的需求文档）－>开发设计文档（开发人员在开始写代码前就能输出设计文档）－>想好测试策略，写出测试用例－>发给开发人员和测试经理看看（非正式的评审用例）－>接到测试版本－>执行测试用例（中间可能会补充用例）－>提交 bug（有些 bug 需要开发人员的确定（严重级别的，或突然发现的在测试用例范围之外的，难以重现的），有些可以直接录制进 TD）－>开发人员修改（可以在测试过程中快速的修改）－>回归测试（可能又会发现新问题，再按流程开始跑）。
11. 43、当开发人员说不是 BUG 时，你如何应付？
    开发人员说不是 bug，有 2 种情况，一是需求没有确定，所以我可以这么做，这个时候可以找来产品经理进行确认，需不需要改动，3 方商量确定好后再看要不要改。二是这种情况不可能发生，所以不需要修改，这个时候，我可以先尽可能的说出是 BUG 的依据是什么？如果被用户发现或出了问题，会有什么不良结果？程序员可能会给你很多理由，你可以对他的解释进行反驳。如果还是不行，那我可以给这个问题提出来，跟开发经理和测试经理进行确认，如果要修改就改，如果不要修改就不改。其实有些真的不是 bug，我也只是建议的方式写进 TD 中，如果开发人员不修改也没有大问题。如果确定是 bug 的话，一定要坚持自己的立场，让问题得到最后的确认。
12. 44、什么是兼容性测试？兼容性测试侧重哪些方面？
    兼容测试主要是检查软件在不同的硬件平台、软件平台上是否可以正常的运行，即是通常说的软件的可移植性。
    兼容的类型，如果细分的话，有平台的兼容，网络兼容，数据库兼容，以及数据格式的兼容。
    兼容测试的重点是，对兼容环境的分析。通常，是在运行软件的环境不是很确定的情况下，才需要做兼容。根据软件运行的需要，或者根据需求文档，一般都能够得出用户会在什么环境下使用该软件，把这些环境整理成表单，就得出做兼容测试的兼容环境了。
13. 45、测试的策略有哪些？
    黑盒 / 白盒，静态 / 动态，手工 / 自动，冒烟测试，回归测试，公测（Beta 测试的策略）
14. 46、正交表测试用例设计方法的特点是什么？
    用最少的实验覆盖最多的操作，测试用例设计很少，效率高，但是很复杂；
    对于基本的验证功能，以及二次集成引起的缺陷，一般都能找出来；但是更深的缺陷，更复杂的缺陷，还是无能为力的；
    具体的环境下，正交表一般都很难做的。大多数，只在系统测试的时候使用此方法。
15. 47、描述测试用例设计的完整过程？
    需求分析 + 需求变更的维护工作；
    根据需求 得出测试需求；
    设计测试方案，评审测试方案；
    方案评审通过后，设计测试用例，再对测试用例进行评审；
16. 48、单元测试的策略有哪些？
    逻辑覆盖、循环覆盖、同行评审、桌前检查、代码走查、代码评审、景泰数据流分析
17. 49、Beta 测试与 Alpha 测试有什么区别？
    Beta testing(β测试）, 测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场
    Alpha testing (α测试）, 是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试
18. 50、软件的评审一般由哪些人参加？其目的是什么？
    在正式的会议上将软件项目的成果（包括各阶段的文档、产生的代码等）提交给用户、客户或有关部门人员对软件产品进行评审和批准。其目的是找出可能影响软件产品质量、开发过程、维护工作的适用性和环境方面的设计缺陷，并采取补救措施，以及找出在性能、安全性和经济方面的可能的改进。
    人员：用户、客户或有关部门开发人员，测试人员，需求分析师都可以，就看处于评审那个阶段
19. 51、测试活动中，如果发现需求文档不完善或者不准确，怎么处理？
    测试需求分析 发现需求文档不完善或者不准确，应该立即和相关人员进行协调交流。
20. 52、阶段评审与项目评审有什么区别？
    阶段评审 对项目各阶段评审：对阶段成果和工作
    项目评审 对项目总体评审：对工作和产品
21. 53、阐述工作版本的定义？
    构造号： BUILD
22. 54、什么是扇入？什么是扇出？
    扇入：被调次数
    扇出：调其它模块数目
23. 55、你认为做好测试用例工作的关键是什么？
    需求和设计文档的理解程度，对系统的熟悉程度
24. 56、简述一下缺陷的生命周期？
    提交 ->确认 ->分配 ->修复 ->验证 ->关闭
25. 57、软件的安全性应从哪几个方面去测试？
    a. 用户认证机制：如数据证书、智能卡、双重认证、安全电子交易协议
    b. 加密机制
    c. 安全防护策略：如安全日志、入侵检测、隔离防护、漏洞扫描
    d. 数据备份与恢复手段：存储设备、存储优化、存储保护、存储管理
    e. 防病毒系统
26. 58、软件配置管理工作开展的情况和认识？
    软件配置管理贯穿于软件开发、测试活动的始终，覆盖了开发、测试活动的各个环节，它的重要作用之一就是要全面的管理保存各个配置项，监控各配置项的状态，并向项目经理及相关的人员报告，从而实现对软件过程的控制。
    软件测试配置管理包括 4 个最基本的活动：
    ○ 配置项标识
    ○ 配置项控制
    ○ 配置项状态报告
    ○ 配置审计
    软件配置管理通常借助工具来辅助，主要有 MS SourceSafe、Rational ClearCase 等
27. 59、你觉得软件测试通过的标准应该是什么样的？
    缺陷密度值达到客户的要求
28. 60、引入测试管理的含义？
    风险分析，进度控制、角色分配、质量控制
29. 61、一套完整的测试应该由哪些阶段组成？
    测试计划、测试设计与开发、测试实施、测试评审与测试结论
30. 62、单元测试的主要内容？
    模块接口测试、局部数据结构测试、路径测试、错误处理测试、边界测试
31. 63、集成测试也叫组装测试或者联合测试，请简述集成测试的主要内容？
    a. 在把各个模块连接起来的时候，穿越模块接口的数据是否会丢失；
    b. 一个模块的功能是否会对另一个模块的功能产生不利的影响；
    c. 各个子功能组合起来，能否达到预期要求的父功能；
    d. 全局数据结构是否有问题；
    e. 单个模块的误差累积起来，是否会放大，从而达到不能接受的程度。
32. 64、简述集成测试与系统测试关系？
    集成测试的主要依据概要设计说明书，系统测试的主要依据是需求设计说明书；
    集成测试是系统模块的测试，系统测试是对整个系统的测试，包括相关的软硬件平台、网络以及相关外设的测试。
33. 65、软件测试的文档测试应当贯穿于软件生命周期的全过程，其中用户文档是文档测试的重点。那么软件系统的用户文档包括哪些？
    ○ 用户手册
    ○ 安装和设置指导
    ○ 联机帮助
    ○ 指南、向导
    ○ 样例、示例和模板
    ○ 授权 / 注册登记表
    ○ 最终用户许可协议
34. 66、软件系统中除用户文档之外，文档测试还应该关注哪些文档？
    ○ 开发文档
    ○ 软件需求说明书
    ■ 数据库设计说明书
    ■ 概要设计说明书
    ■ 详细设计说明书
    ■ 可行性研究报告
    ○ 管理文档
    ■ 项目开发计划
    ■ 测试计划
    ■ 测试报告
    ■ 开发进度月报
    ■ 开发总结报告
35. 67、简述软件系统中用户文档的测试要点？
    ○ 读者群。
    文档面向的读者定位要明确。对于初级用户、中级用户以及高级用户应该有不同的定位
    ○ 术语。
    文档中用到的术语要适用与定位的读者群，用法一致，标准定义与业界规范相吻合。
    ○ 正确性。
    测试中需检查所有信息是否真实正确，查找由于过期产品说明书和销售人员夸大事实而导致的错误。检查所有的目录、索引和章节引用是否已更新，尝试链接是否准确，产品支持电话、地址和邮政编码是否正确。
    ○ 完整性。
    对照软件界面检查是否有重要的分支没有描述到，甚至是否有整个大模块没有描述到。
    ○ 一致性。
    按照文档描述的操作执行后，检查软件返回的结果是否与文档描述的相同。
    ○ 易用性。
    对关键步骤以粗体或背景色给用户以提示，合理的页面布局、适量的图表都可以给用户更高的易用性。需要注意的是文档要有助于用户排除错误。不但描述正确操作，也要描述错误处理办法。文档对于用户看到的错误信息应当有更详细的文档解释。
    ○ 图表与界面截图。
    检查所有图表与界面截图是否与发行版本相同。
    ○ 样例与示例。
    像用户一样载入和使用样例。如果是一段程序，就输入数据并执行它。以每一个模块制作文件，确认它们的正确性。
    ○ 语言。
    不出现错别字，不要出现有二义性的说法。特别要注意的是屏幕截图或绘制图形中的文字。
    ○ 印刷与包装。
    检查印刷质量；手册厚度与开本是否合适；包装盒的大小是否合适；有没有零碎易丢失的小部件等等。
36. 68、单元测试主要内容是什么？
    单元测试大多数由开发人员来完成，测试人员技术背景较好或者开发系统软件时可能会安排测试人员进行单元测试，大多数进行的单元测试都是开发人员调试程序或者开发组系统联合调试的过程。
    单元测试一般包括五个方面的测试：
    a. 模块接口测试：模块接口测试是单元测试的基础。只有在数据能正确流入、流出模块的前提下，其他测试才有意义。模块接口测试也是集成测试的重点，这里进行的测试主要是为后面打好基础。测试接口正确与否应该考虑下列因素：
    ■ 输入的实际参数与形式参数的个数是否相同；
    ■ 输入的实际参数与形式参数的属性是否匹配；
    ■ 输入的实际参数与形式参数的量纲是否一致；
    ■ 调用其他模块时所给实际参数的个数是否与被调模块的形参个数相同；
    ■ 调用其他模块时所给实际参数的属性是否与被调模块的形参属性匹配；
    ■ 调用其他模块时所给实际参数的量纲是否与被调模块的形参量纲一致；
    ■ 调用预定义函数时所用参数的个数、属性和次序是否正确；
    ■ 是否存在与当前入口点无关的参数引用；
    ■ 是否修改了只读型参数；
    ■ 对全程变量的定义各模块是否一致；
    ■ 是否把某些约束作为参数传递。
    如果模块功能包括外部输入输出，还应该考虑下列因素：
    ■ 文件属性是否正确；
    ■ OPEN/CLOSE 语句是否正确；
    ■ 格式说明与输入输出语句是否匹配；
    ■ 缓冲区大小与记录长度是否匹配；
    ■ 文件使用前是否已经打开；
    ■ 是否处理了文件尾；
    ■ 是否处理了输入 / 输出错误；
    ■ 输出信息中是否有文字性错误。
    ■ 局部数据结构测试；
    ■ 边界条件测试；
    ■ 模块中所有独立执行通路测试；
    a. 局部数据结构测试：检查局部数据结构是为了保证临时存储在模块内的数据在程序执行过程中完整、正确，局部功能是整个功能运行的基础。重点是一些函数是否正确执行，内部是否运行正确。局部数据结构往往是错误的根源，应仔细设计测试用例，力求发现下面几类错误：
    ■ 不合适或不相容的类型说明；
    ■ 变量无初值；
    ■ 变量初始化或省缺值有错；
    ■ 不正确的变量名（拼错或不正确地截断）；
    ■ 出现上溢、下溢和地址异常。
    b. 边界条件测试：边界条件测试是单元测试中最重要的一项任务。众所周知，软件经常在边界上失效，采用边界值分析技术，针对边界值及其左、右设计测试用例，很有可能发现新的错误。边界条件测试是一项基础测试，也是后面系统测试中的功能测试的重点，边界测试执行的较好，可以大大提高程序健壮性。
    c. 模块中所有独立路径测试：在模块中应对每一条独立执行路径进行测试，单元测试的基本任务是保证模块中每条语句至少执行一次。测试目的主要是为了发现因错误计算、不正确的比较和不适当的控制流造成的错误。具体做法就是程序员逐条调试语句。常见的错误包括：
    ■ 误解或用错了算符优先级；
    ■ 混合类型运算；
    ■ 变量初值错；
    ■ 精度不够；
    ■ 表达式符号错。
    比较判断与控制流常常紧密相关，测试时注意下列错误：
    ■ 不同数据类型的对象之间进行比较；
    ■ 错误地使用逻辑运算符或优先级；
    ■ 因计算机表示的局限性，期望理论上相等而实际上不相等的两个量相等；
    ■ 比较运算或变量出错；
    ■ 循环终止条件或不可能出现；
    ■ 迭代发散时不能退出；
    ■ 错误地修改了循环变量。
    a. 模块的各条错误处理通路测试：程序在遇到异常情况时不应该退出，好的程序应能预见各种出错条件，并预设各种出错处理通路。如果用户不按照正常操作，程序就退出或者停止工作，实际上也是一种缺陷，因此单元测试要测试各种错误处理路径。一般这种测试着重检查下列问题：
    ■ 输出的出错信息难以理解；
    ■ 记录的错误与实际遇到的错误不相符；
    ■ 在程序自定义的出错处理段运行之前，系统已介入；
    ■ 异常处理不当；
    ■ 错误陈述中未能提供足够的定位出错信息。
37. 69、如何理解强度测试？
    强度测试是为了确定系统在最差工作环境的工作能力，也可能是用于验证在标准工作压力下的各种资源的最下限指标。
    它和压力测试的目标是不同的，压力测试是在标准工作环境下，不断增加系统负荷，最终测试出该系统能力达到的最大负荷（稳定和峰值）, 而强度测试则是在非标准工作环境下，甚至不断人为降低系统工作环境所需要的资源，如网络带宽，系统内存，数据锁等等，以测试系统在资源不足的情况下的工作状态，通过强度测试，可以确定本系统正常工作的最差环境。
    强度测试和压力测试的测试指标相近，大多都是与时间相关的指标，如并发量（吞吐量）, 延迟（最大、最小、平均）以及顺序指标等
    强度测试需要对系统的结构熟悉，针对系统的特征设计强度测试的方法
38. 70、文档测试主要包含什么内容？
    在国内软件开发管理中，文档管理几乎是最弱的一项，因而在测试工作中特别容易忽略文档测试也就不足为奇了。要想给用户提供完整的产品，文档测试是必不可少的。文档测试一般注重下面几个方面：
    文档的完整性：主要是测试文档内容的全面性与完整性，从总体上把握文档的质量。例如用户手册应该包括软件的所有功能模块。
    描述与软件实际情况的一致性：主要测试软件文档与软件实际的一致程度。例如用户手册基本完整后，我们还要注意用户手册与实际功能描述是否一致。因为文档往往跟不上软件版本的更新速度。
    易理解性：主要是检查文档对关键、重要的操作有无图文说明，文字、图表是否易于理解。对于关键、重要的操作仅仅只有文字说明肯定是不够的，应该附有图表使说明更为直观和明了。
    文档中提供操作的实例：这项检查内容主要针对用户手册。对主要功能和关键操作提供的应用实例是否丰富，提供的实例描述是否详细。只有简单的图文说明，而无实例的用户手册看起来就像是软件界面的简单拷贝，对于用户来说，实际上没有什么帮助。
    印刷与包装质量：主要是检查软件文档的商品化程度。有些用户手册是简单打印、装订而成，过于粗糙，不易于用户保存。优秀的文档例如用户手册和技术白皮书，应提供商品化包装，并且印刷精美。
39. 71、功能测试用例需要详细到什么程度才是合格的？
    这个问题也是测试工程师经常问的问题。有人主张测试用例详细到每个步骤执行什么都要写出来，目的是即使一个不了解系统的新手都可以按照测试用例来执行工作。主张这类写法的人还可以举出例子：欧美、日本等软件外包文档都是这样做的。
    另外一种观点就是主张写的粗些，类似于编写测试大纲。主张这种观点的人是因为软件开发需求管理不规范，变动十分频繁，因而不能按照欧美的高标准来编写测试用例。这样的测试用例容易维护，可以让测试执行人员有更大的发挥空间。
    实际上，软件测试用例的详细程度首先要以覆盖到测试点为基本要求。举个例子：用户登陆系统的测试用例可以不写出具体的执行数据，但是至少要写出五种以上情况（），如果只用一句话覆盖了这个功能是不合格的测试用例。覆盖功能点不是指列出功能点，而是要写出功能点的各个方面（如果组合情况较多时可以采用等价划分）。
    另一个影响测试用例的就是组织的开发能力和测试对象特点。如果开发力量比较落后，编写较详细的测试用例是不现实的，因为根本没有那么大的资源投入，当然这种情况很随着团队的发展而逐渐有所改善。测试对象特点重点是指测试对象在进度、成本等方面的要求，如果进度较紧张的情况下，是根本没有时间写出高质量的测试用例的，甚至有些时候测试工作只是一种辅助工作，因而不编写测试用例。
    因此，测试用例的编写要根据测试对象特点、团队的执行能力等各个方面综合起来决定编写策略。最后要注意的是测试人员一定不能抱怨，力争在不断提高测试用例编写水平的同时，不断地提高自身能力。
40. 72、配置和兼容性测试的区别是什么？
    配置测试的目的是保证软件在其相关的硬件上能够正常运行，而兼容性测试主要是测试软件能否与不同的软件正确协作。
    配置测试的核心内容就是使用各种硬件来测试软件的运行情况，一般包括：
    a. 软件在不同的主机上的运行情况，例如 Dell 和 Apple；
    b. 软件在不同的组件上的运行情况，例如开发的拨号程序要测试在不同厂商生产的 Modem 上的运行情况；
    c. 不同的外设；
    d. 不同的接口；
    e. 不同的可选项，例如不同的内存大小；
    兼容性测试的核心内容：
    a. 测试软件是否能在不同的操作系统平台上兼容；
    b. 测试软件是否能在同一操作系统平台的不同版本上兼容；
    c. 软件本身能否向前或者向后兼容；
    d. 测试软件能否与其它相关的软件兼容；
    e. 数据兼容性测试，主要是指数据能否共享；
    配置和兼容性测试通称对开发系统类软件比较重要，例如驱动程序、操作系统、数据库管理系统等。具体进行时仍然按照测试用例来执行。
41. 73、没有产品说明书和需求文档地情况下能够进行黑盒测试吗？
    这个问题是国内测试工程师经常遇到的问题，根源就是国内软件开发文档管理不规范，对变更的管理方法就更不合理了。实际上没有任何文档的时候，测试人员是能够进行黑盒测试的，这种测试方式我们可以称之为探索测试，具体做法就是测试工程师根据自己的专业技能、领域知识等不断的深入了解测试对象、理解软件功能，进而发现缺陷。
    在这种做法基本上把软件当成了产品说明书，测试过程中要和开发人员不断的进行交流。尤其在作项目的时候，进度压力比较大，可以作为加急测试方案。最大的风险是不知道有些特性是否被遗漏。
42. 74、测试中的杀虫剂怪事是指什么？
    杀虫剂怪事一词由 BorisBeizer 在其编著的《软件测试技术》第二版中提出。用于描述测试人员对同一测试对象进行的测试次数越多，发现的缺陷就会越来越少的现象。就像老用一种农药，害虫就会有免疫力，农药发挥不了效力。这种现象的根本原因就是测试人员对测试软件过于熟悉，形成思维定势。
    为了克服这种现象，测试人员需要不断编写新的测试程序或者测试用例，对程序的不同部分进行测试，以发现更多的缺陷。也可以引用新人来测试软件，刚刚进来的新手往往能发现一些意想不到的问题。
43. 75、为什么尽量不要让时间有富裕的员工去做一些测试？
    表面上看这体现了管理的效率和灵活性，但实际上也体现了管理者对测试的轻视。测试和测试的人有很大关系。测试工作人员应该是勤奋并富有耐心，善于学习、思考和发现问题，细心有条理，总结问题，如果具备这样的优点，做其它工作同样也会很出色，因此这里还有一个要求，就是要喜欢测试这项工作。如果他是专职的，那么肯定更有经验和信心。国内的小伙子好象都喜欢做程序员，两者工作性质不同，待遇不同，地位不同，对自我实现的价值的认识也不同，这是行业的一个需要改善的问题。如果只是为了完成任务而完成任务，或者发现了几个问题就觉得满意了，这在任何其它工作中都是不行的。
44. 76、完全测试程序是可能的吗？
    软件测试初学者可能认为拿到软件后需要进行完全测试，找到全部的软件缺陷，使软件零缺陷发布。实际上完全测试是不可能的。主要有以下一个原因：

• 完全测试比较耗时，时间上不允许；
• 完全测试通常意味着较多资源投入，这在现实中往往是行不通的；
• 输入量太大，不能一一进行测试；
• 输出结果太多，只能分类进行验证；
• 软件实现途径太多；
• 软件产品说明书没有客观标准，从不同的角度看，软件缺陷的标准不同；
  因此测试的程度要根据实际情况确定。

1. 77、软件测试的风险主要体现在哪里？
   我们没有对软件进行完全测试，实际就是选择了风险，因为缺陷极有可能存在没有进行测试的部分。举个例子，程序员为了方便，在调试程序时会弹出一些提示信息框，而这些提示只在某种条件下会弹出，碰巧程序发布前这些代码中的一些没有被注释掉。在测试时测试工程师又没有对其进行测试。如果客户碰到它，这将是代价昂贵的缺陷，因为交付后才被客户发现。
   因此，我们要尽可能的选择最合适的测试量，把风险降低到最小。
2. 78、发现的缺陷越多，说明软件缺陷越多吗？
   这是一个比较常见的现象。测试工程师在没有找到缺陷前会绞尽脑汁的思考，但是找到一个后，会接二连三的发现很多缺陷，颇有个人成就感。其中的原因主要如下：

• 代码复用、拷贝代码导致程序员容易犯相同的错误。类的继承导致所有的子类会包含基类的错误，反复拷贝同一代码意味可能也复制了缺陷。
• 程序员比较劳累是可以导致某些连续编写的功能缺陷较多。程序员加班是一种司空见惯的现象，因此体力不只时容易编写一些缺陷较多的程序。而这些连续潜伏缺陷恰恰时测试工程师大显身手的地方。
  缺陷一个连着一个不是一个客观规律，只是一个常见的现象。如果软件编写的比较好，这种现象就不常见了。测试人员只要严肃认真的测试程序就可以了。

1. 79、所有的软件缺陷都能修复吗？所有的软件缺陷都要修复吗？
   从技术上讲，所有的软件缺陷都是能够修复的，但是没有必要修复所有的软件缺陷。测试人员要做的是能够正确判断什么时候不能追求软件的完美。对于整个项目团队，要做的是对每一个软件缺陷进行取舍，根据风险决定那些缺陷要修复。发生这种现象的主要原因如下：
   ○ 没有足够的时间资源。在任何一个项目中，通常情况下开发人员和测试人员都是不够用的，而且在项目中没有预算足够的回归测试时间，再加上修改缺陷可能引入新的缺陷，因此在交付期限的强大压力下，必须放弃某些缺陷的修改。
   ○ 有些缺陷只是特殊情况下出现，这种缺陷处于商业利益考虑，可以在以后升级中进行修复。
   ○ 不是缺陷的缺陷。我们经常会碰到某些功能方面的问题被当成缺陷来处理，这类问题可以以后有时间时考虑再处理。
   最后要说的是，缺陷是否修改要由软件测试人员、项目经理、程序员共同讨论来决定是否修复，不同角色的人员从不同的角度来思考，以做出正确的决定。
2. 80、软件测试人员就是 QA 吗？
   软件测试人员的职责是尽可能早的找出软件缺陷，确保得以修复。而质量保证人员（QA）主要职责是创建或者制定标准和方法，提高促进软件开发能力和减少软件缺陷。测试人员的主要工作是测试，质量保证人员日常工作重要内容是检查与评审，测试工作也是测试保证人员的工作对象。
   软件测试和质量是相辅相成的关系，都是为了提高软件质量而工作。
3. 81、如何减少测试人员跳槽带来的损失？
   在 IT 行业里跳槽已经是一种司空见惯的现象，而且跳槽无论给公司还是给个人都会带来一定的损失。测试队伍也无疑会面临跳槽的威胁，作为测试经理管理者，只有从日常工作中开始做起，最能最大限度的减少损失。建议我们从以下两个方面做起：
   ○ 加强部门内员工之间的互相学习，互相学习是建立学习型组织的基本要求，是知识互相转移的过程。在此基础上，可以把个人拥有的技术以知识的形式沉积下来，也就完成了隐性知识到显性知识的转化。
   ○ 通常情况下，企业能为员工提供足够大的发展空间时，如果不是待遇特别低，员工都不会主动离开企业。因此我们要想留住员工，管理者就应该把员工的个人成长和企业的发展联系起来，为员工设定合理发展规划并付诸实现。不过这项要求做起来比较，要有比较好的企业文化为依托。
4. 82、写出 bug 报告当中一些必备的内容。
   硬件平台和操作系统
   测试应用的硬件平台（Platform），通常选择PC。
   测试应用的操作系统平台（OS）。
5. 版本
6. Bug 报告优先级
7. Bug 状态
8. Bug 的编号
9. 发现人
10. 提交人
11. 指定处理人
12. 概述
13. 从属关系
14. 详细描述
15. 严重程度
16. 所属模块
17. 附件
18. 提交日期
19. 83、画出软件测试的 V 模型图。
    网络图片：https://liushilive.github.io/github_exercise_interview/screenshot/2018-09-30-17-25-39.png
20. 84、Windows 操作系统中 PATH 环境变量的作用是什么？
    PATH 是 Windows 操作系统环境变量，PATH 作用是用户在命令行窗口执行一个命令，则在 PATH 变量设置的目录下依次寻找该命令或对应的执行文件，若找到，则执行，若没有找到，则命令行窗口返回无效命令。
21. 85、简述一下 c/s 模式或者 b/s 模式？
    C/S 模式：客户端 / 服务器模式。工作原理：Client 向 Server 提交一个请求；Server 则使用一些方法处理这个请求，并将效果返回给 Client。
    B/S 结构，即 Browser/Server（浏览器 / 服务器）结构，是随着 Internet 技术的兴起，对 C/S 结构的一种变化或者改进的结构。在这种结构下，用户界面完全通过 WWW 浏览器实现，一部分事务逻辑在前端实现，但是主要事务逻辑在服务器端实现，形成所谓 3-tier 结构。B/S 结构，主要是利用了不断成熟的 WWW 浏览器技术，结合浏览器的多种 Script 语言 (VBScript、JavaScript…) 和 ActiveX 技术，用通用浏览器就实现了原来需要复杂专用软件才能实现的强大功能，并节约了开发成本，是一种全新的软件系统构造技术。
22. 86、持续集成是什么？
    持续集成指的是，频繁地（一天多次）将代码集成到主干。
    持续集成的目的，就是让产品可以快速迭代，同时还能保持高质量。
    它的核心措施是，代码集成到主干之前，必须通过自动化测试。只要有一个测试用例失败，就不能集成。
23. 87、持续交付是什么？
    持续交付（Continuous delivery）指的是，频繁地将软件的新版本，交付给质量团队或者用户，以供评审。如果评审通过，代码就进入生产阶段。
    持续交付可以看作持续集成的下一步。它强调的是，不管怎么更新，软件是随时随地可以交付的。
24. 88、持续部署是什么？
    持续部署（continuous deployment）是持续交付的下一步，指的是代码通过评审以后，自动部署到生产环境。
    持续部署的目标是，代码在任何时刻都是可部署的，可以进入生产阶段。
    持续部署的前提是能自动化完成测试、构建、部署等步骤。
25. 89、交付测试是什么
    交付过程中的重要一环就是交付测试，交付测试的目标是保证用户对所交付的系统的满意。交付测试主要的参与者应该是目标客户。客户参与越多越好。交付测试的内容一般包括安装测试、可用性测试、 alpha 测试、 beta 测试等。
26. 90、用例评审怎么去评审
    a. 测试用例本身的描述是否清晰，语言准确；是否存在二义性；
    b. 测试用例内容是否完整，是否清晰的包含输入和预期输出的结果；测试步骤是否清晰；
    c. 测试用例中使用的测试数据是否恰当，准确；
    d. 测试用例是否具有指导性，是否能灵活的指导软件测试工程师通过测试用例发现更多的缺陷，而不是限制他们的思维；
    e. 是否考虑到测试用例执行的效率。对于不断重复执行的步骤，是否保证了验证点相同；或者测试用例的设计是否存在冗余性等。这些都可能导致测试用例执行效率低下；
    f. 画出软件需求跟踪矩阵，验证测试用例是否完全覆盖了需求，验证测试用例的覆盖性；
    g. 测试用例是否完全遵守了软件需求的规定。这一点其实有一些难做到。考虑到时间 / 成本的关系，应该视具体情况而定。
27. 91、如何有效的对测试用例进行评审
    a. 评审之前，需要将即将评审的测试用例以及测试需求、测试分析的结果（测试点分析）等文档提前发送给相关的人员；最好能够让他们有时间提前阅读；
    b. 随时的问题沟通与反馈机制。评审之前做一些问题的沟通与反馈，以便于在测试用例评审会议上能够节省出来宝贵的时间；
    c. 评审会议的主持者，需要事前做好关于测试用例的疑问，问题点等记录，以便于在评审会上引导提问和解答；
    d. 评审期间做好详细的记录，需要对有关的疑问和问题及时进行澄清；
    e. 评审会议的主持者需要能够把控会议的进度，让参加评审的测试人员能够集中精力在测试用例上，而不要思维太发散而跑题。
    f. 评审会议结束之后，及时提交审核评审记录；并且与参加会议的人员分享评审记录。
28. 92、如何保证测试用例覆盖全面
    测试用例覆盖度一般是从以下几方面衡量的：
    a. 测试需求的覆盖：保证所有需求都已经设计用例
    b. 测试特性的覆盖：保证所有不同类型已覆盖，如：功能测试，性能测试等
    c. 平台与层次的覆盖：保证所有平台有用例覆盖，不同层次都有设计用例，如业务层、接口层等
    一般通过用例评审来完善用例，也可通过代码覆盖度工具（Java 平台比较多，如 JaCoCo）来检测用例的覆盖是否完整
29. 93、支付测试的现金是怎么模拟的（包括第三方接口，微信，支付宝）
    采用真实支付环境测试，记录好相关订单与金额记录，提交财务对账。
    如第三方支付有提供仿真测试环境可由开发修改支付网关配置为沙箱地址。

• 微信支付仿真测试环境* 支付宝沙箱

1. 94、软件测试与软件质量保证的区别
   软件测试只是质量保证工作中的一个环节，软件质量保证与软件测试是软件质量工程的两个不同层面的工作；
   ○ 质量保证
   通过预防、检查与改进来保证软件质量，采用全面质量管理和过程改进的原理来开展质量保证工作，主要关注软件质量的检查与测试，主要着眼于软件开发活动的过程、步骤和产物。
   ○ 软件测试
   通过执行软件来，对过程中的产物（开发文档和程序）进行走查，发现问题，报告质量
2. 95、请描述如何划分缺陷与错误严重性和优先级别？
   给软件缺陷与错误划分严重性和优先级的通用原则：
   a. 表示软件缺陷所造成饿危害和恶劣程度。
   b. 优先级表示修复缺陷的重要程度和次序。
   ○ 严重性：
   ■ 严重：系统崩溃、数据丢失、数据毁坏
   ■ 较严重：操作性错误、结果错误、遗漏功能
   ■ 一般：小问题、错别字、UI 布局、罕见故障
   ■ 建议：不影响使用的瑕疵或更好的实现。
   ○ 优先级
   ■ 最高优先级：立即修复，停止进一步测试。
   ■ 次高优先级：在产品发布之前必须修复。
   ■ 中等优先级：如果时间允许应该修复。
   ■ 最低优先级：可能会修复，但是也可能发布。
3. 96、BUG 信息应该包含那些内容。
   测试软件名称、测试版本号、测试人名称、测试事件、测试软件和硬件配置环境、
   发现软件错误的类型、错误的严重程度、详细步骤、必要的附图、测试注释。
4. 97、W 和 H 模型的区别
   W 模型强调的是测试伴随整个软件开发周期，而且测试的对象不仅是程序，需求也需要进行测试，测试与开发是同步进行的。
   H 模型是将测试活动玩却的独立出来，形成了完全独立的流程，可以实现迭代而 W 模型不支持迭代这是两者最大的区别。
5. 98、怎么处理无法再现的缺陷？
   首先，应当对这样的缺陷进行详细的记录，并尽快提交给开发人员。
   其次，对于寻找难以再现的缺陷要合理地安排时间，对一时难以再现的缺陷可以暂时搁置，以保证项目的正常进度。
   最后，在测试过程中对未再现缺陷予以关注。
6. 99、功能测试用例需要详细到什么程度才是合格的?
   测试软件名称、测试版本号、测试人名称、测试事件、测试软件和硬件配置环境、