软件测试面试题

1. 软件测试主要包括哪几类

• 单元测试、集成测试、系统测试、验收测试

2. 软件是由哪四项组成

• 程序、数据、文档、服务

3. 代码评审

• 定义
  • 代码评审也称代码复查，是指通过阅读代码来检查源代码与编码标准的符合性以及代码质量的活动。

4. 设计系统测试计划需要参考的项目文档有

• 软件测试计划、软件需求规范、迭代计划

5. β测试

• 定义：
  • 软件开发公司组织各方面的典型用户在日常工作中实际使用β版本，即发放给一部分用户进行测试，并要求用户报告异常情况，提出批评意见，然后软件开发公司再对β版本进行改错和完善。

6. 什么是软件缺陷

• 软件缺陷的定义：
  • 计算机系统或程序中存在的任何一种破坏正常运行的问题、错误，或者隐藏的功能缺陷、瑕疵。
• 什么样的可以定义为软件缺陷：
  • 1.软件未实现产品说明书要求的功能。
  • 2.软件出现了产品说明书指明不会出现的错误。
  • 3.软件超出实现了产品说明书提到的功能。
  • 4.软件未实现产品说明书未明确指出但是应该实现的目标。
  • 5.软件难以理解，不易使用，运行缓慢或者终端用户认为使用效果不佳。

7. 软件缺陷的种类

• 1.功能、特性没有实现或部分实现
• 2.设计不合理，存在缺陷
• 3.实际结果和预期结果不一致。
• 4.运行出错，包括运行终止，系统崩溃，界面混乱。
• 5.数据结果不正确，精度不够。
• 6.用户不能接受的其他问题，如存取时间过长，界面不美观。

8. 软件缺陷的级别

• 1.致命的

  • 造成系统或应用程序崩溃、死机，造成数据丢失、主要功能完全丧失。

• 2.严重的

  • 功能或特性没有实现，主要功能部分丧失，次要功能完全丧失，或致命的错误申明。

• 3.一般的

  • 次要功能丧失，提示信息不太准确或用户界面差，操作时间长等。

• 4.微小的

  • 对功能几乎没有影响，产品及属性仍可使用。

• 5.建议

  • 程序的易用性，设计合理性提出建议。

• 划分的原则：

  • 按照软件缺陷造成的恶劣程度划分。

9. 缺陷有哪些属性

• 严重等级、版本、模块、状态、描述、详细说明、建议、紧急程度等

10. 测试用例包括哪些属性

• 模块，子模块，编号，用例等级，输入，输出，测试结果

11. 软件缺陷的状态，按顺序列出

• 新建(New)： 测试中新报告的软件缺陷；
• 打开(Open)： 被确认并分配给相关开发人员处理；
• 修正(Fixed)： 开发人员已完成修正，等待测试人员验证；
• 拒绝(Declined)： 拒绝修改缺陷；
• 延期(Deferred)： 不在当前版本修复的错误，下一版修复；
• 重新打开(Reopen)： 错误未解决，重新开启；
• 关闭(Closed)： 错误已被修复

12. 软件测试的定义

• 定义一：
  • 软件测试时为了发现错误而执行程序的过程
• 定义二：
  • 软件测试时根据软件开发各个阶段规格说明书和程序的内部结构而精心设计的一批测试用例，并利用这些测试用例运行程序以及发现错误的过程。

13. 什么叫测试？

• 首先是项活动，在这项活动中某个系统或组成的部分将在特定的条件下运行，结果将被观察和记录，并对系统或组成部分进行评价。测试活动有两种结果：1.找出缺陷和故障；2.显示软件执行的正确。测试是一个或多个测试用例的集合。

14. 什么是测试用例？

• 是为了特定的目的而设计的一组测试输入、执行条件和预期的结果；测试用例是执行测试的最小实体。

15. 什么是测试步骤？

• 测试步骤详细规定了如何设置、执行、评估特定的测试用例。

16. 简述一下软件的生命周期

• 一个软件生命周期包括制定计划，需求分析定义，软件设计，程序编码，软件测试，软件运行，软件维护，软件停用，八个阶段。

17. 软件测试的对象是什么？

• 软件开发过程中所产生的需求说明书、概要设计说明书、详细设计说明书以及源程序。

18. 软件测试在软件生命周期的两个阶段

• 第一阶段：单元测试与集成测试阶段
• 第二阶段：综合测试阶段，即在完成单元测试后进行的测试。

19. 软件测试的原则

• 1.尽早地和不断地进行软件测试
• 2.设计测试用例时，包括合理输入条件和不合理的输入条件。
• 3.充分注意测试中的集群现象。
• 4.严格执行测试计划
• 5.应当对每个测试结果做全面的检查。
• 6.妥善保存测试计划，测试用例，出错统计和最终分析报告
• 7.测试用例应由测试输入数据，测试执行步骤和与之对应的预期结果三部分组成。
• 8.后期系统测试阶段（不包括单元测试），应当避免由程序员检查自己的程序。

20. 软件测试的分类是什么？

• 从执行被测软件角度
  • 静态测试和动态测试
    • 静态测试：通过被测程序的静态审查，对程序的数据流和控制流等信息进行分析，发现代码中潜在的错误，得出测试报告。
    • 动态测试：指通常意义的测试，即使用和运行被测软件。
• 21. 从测试用例设计方法
  • 黑盒测试、白盒测试、灰盒测试
    • 黑盒测试：称为功能测试，是一种从用户角度出发的测试，数据驱动测试和基于规格说明的测试。使用这种方法测试，把测试程序当做一个黑盒，忽略程序内部的结构的特性，只依靠被测程序输入和输出之间的关系或程序功能的测试用例。
    • 白盒测试：
      • 称为结构测试。是基于产品的内部结构来进行测试，检查内部操作是否按规格说明书的规定执行，软件各个部分功能是否得到充分利用。
    • 灰盒测试：
      • 是介于白盒测试与黑盒测试之间的一种测试，灰盒测试多用于集成测试阶段，不仅关注输出、输入的正确性，同时也关注程序内部的情况。
• 从软件测试的策略和过程
  • 单元测试，集成测试，确认测试，系统测试和验收测试

22. 如果执行完全的黑盒测试，还有必要执行白盒测试吗？

• 白盒测试可以发现软件设计结构的问题，而且白盒测试比黑盒测试在穷尽路径方面比黑盒测试效率高，尽早的防止问题，可以节约产品的研发成本。

23. 黑盒测试和白盒测试不同点

项目	黑盒测试法	白盒测试法
规划方面	功能测试	结构测试
优点	从用户角度出发进行测试	能够对程序内部特定部位进行覆盖性测试
缺点	1.无法测试程序内部特定部位 2.当规格说明有误，则不能发现问题	1.无法检查程序的外部特性 2.无法对未实现规格说明的程序内部欠缺部分进行测试
应用范围	等价划分法 边界分析法 因果图 决策表 错误推测法	语句覆盖，判断覆盖， 条件覆盖，判断条件覆盖， 路径覆盖，循环覆盖 模块接口测试

24. 黑盒测试主要是发现哪些错误？

• 1.是否有不正确的功能，是否有遗漏的功能
• 2.在接口上，是否能够正确地接收输入数据并产生正确的输出结果；
• 3.是否有数据结构错误或外部信息访问错误。
• 4.性能上是否能够满足要求
• 5.是否有程序初始化和终止方面的错误。

25. 黑盒测试用例方法

• 等价类划分法、边界值分析法、因果图法、决策表法、正交试验法、场景法、错误推测法

26. 白盒测试用例方法

• 语句覆盖；判断覆盖；条件覆盖；判断条件覆盖；条件组合覆盖；路径覆盖；模块接口测试；

27. 测试用例的特性

• 有效性
• 可复用性
• 易组织性
• 可评估性
• 可管理性

28. 设计测试用例的基本准则

• 代表性
• 简洁性
• 可判断性
• 可再现性

29. 测试用例的设计过程

• 1.分析系统程序的工作流程
• 2.确定并制定测试用例
• 3.确定测试用例数据
• 4测试用例的修改更新

30. 黑盒测试用例方法

• 等价类划分法
  • 定义：
    • 它将不能穷举的测试过程进行合理分类，从儿保证设计出来的测试用例具有完整性和代表性。
    • 把所有可能的输入数据划分为若按部分，然后从每个部分中选取少数具有代表性的数据作为测试用例。
  • 划分的依据：
    • 1.按照区间划分，可以确定一个有效等价类和两个无效等价类。
    • 2.按照数值划分，可以确定对个有效等价类和一个无效等价类。
    • 3.按照数值集合划分，可以确定一个有效等价类和一个无效等价类。
    • 4.按照限制条件或规则划分，可以确定一个有效等价类和多个无效等价类。
    • 5.细分等价类，对等价类进一步划分为更小的等价类，并建立等价类表。
  • 等价类测试的分类：
    • 1.弱一般等价类测试
      
           ^
    • 2.强一般等价类测试
      
           ^
    • 3.弱健壮等价类测试
      
           ^
    • 4.强健壮等价类测试。
• 边界值分析法
  • 定义：
    • 对输入会输出的边界值进行测试
  • 边界值分析法步骤：
    • 确定边界值情况
    • 选取正好等于，刚刚大于或刚刚小于边界的值作为测试数据。
• 决策表法
  • 定义：
    • 决策表是: 分析和表达多逻辑条件下执行不同操作情况的工具。
  • 决策表的组成：
    • 条件桩：列出问题的条件
    • 动作桩：列出可能采取的操作
    • 条件项：列出所有可能的取值
    • 动作项：根据各组取值下应该采取的动作
    • 在决策表中贯穿条件项和动作项的一列就是一条规则
  • 决策表法步骤：
    • 1.确定规则的个数，取2的n次方
    • 2.列出所有的条件桩和动作桩
    • 3.填入条件项
    • 4.根据条件项推导出动作项，得到初始决策表
    • 5.合并相似规则（合并条件项用“ - ”表示）
• 因果图法
  • 定义：
    • 一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法
  • 因果图法步骤：
    • 1.根据程序说明书描述，分析病区定因和果，画出因果图。
    • 2.将得到的因果图转化为判断表
    • 3.为判定表中每一类所表示的情况设计一个测试用例
• 正交试验法
  • 定义：
    • 从大量的试验点中挑选出适量的、有代表性的点，依据正交表，合理安排试验一种测试方法。
  • 正交试验法步骤：
    • 1.提取功能说明，构造因子——状态表
    • 2.加权筛选，生成因素分析表
    • 3.利用正交表构造测试数据集
    • 4.用正交表每行数据构造测试用例
• 错误推测法
  • 定义：基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性的设计测试用例的方法。

31. 上述几种测试方法该如何选择？

• 原则：
  • 1.根据程序的重要性和一旦发生故障将造成的损失来确定测试等级和测试重点。
  • 2.选择合理的测试策略，从中找到一个平衡点。
    • 参考原则
      • 1.任何情况下必须采用边界值分析法
      • 2.必要时采用等价类划分法作为补充
      • 3.采用错误推断法再追加测试用例
      • 4.检查设计出的测试用例在逻辑上负载程度，如果没有达到要求覆盖标准，应补充更多测试用例
      • 5.如果程序的功能说明中含有输入条件的组合情况，则应考虑选用决策表法 或 因果图法。
  • 3.时间、成本、质量

32. 单元测试

• 定义：
  • 对软件基本组成单元进行的测试。单元测试的对象是软件设计的最小单位——模块。单元测试的只要目标是确保各单元模块被正确地编码。

33. 集成测试

• 定义：
  • 是介于单元测试和系统测试之间的过度阶段。根据实际情况对程序模块采用适当的集成测试策略组装起来，对系统的接口以及集成后的功能进行正确校验的测试工作。
• 集成测试的层次
  • 1.对传统软件来讲
    • 模块内集成测试
    • 子系统内集成测试
    • 子系统间集成测试
  • 2.对于面向对象的应用系统来说
    • 类内集成测试
    • 类间集成测试

34. 确认测试

• 定义：
  • 也称合格性测试(有效性测试)，检验所开发的软件是否能按用户提出的要求运行，对软件的功能和性能要求在软件需求规格说明中已经明确规定。它的任务是验证软件的功能和性能及其特性是否与客户的要求一致。

35. 系统测试

• 定义：
  • 系统测试是最接近人们的日常测试实践。它是将已经集成好得软件系统与整个计算机系统结合在一起，在实际运行环境下，对计算机系统进行一系列的组装测试和确认测试。

36. 验收测试

• 定义：
  • 通过综合的测试之后，软件测试最后一步——验收测试即可开始，是向用户表明系统能够像预定要求运行。
• 验收测试流程（分为软件配置和可执行程序）
  • 文档审核——源代码审核——配置脚本审核——测试程序审核——可执行程序审核

37. 系统测试的方法有哪些？

• 1.恢复测试

  • 定义：
    • 是通过各种手段，强制性地使软件出错，使其不能正常工作，进而检验系统的恢复能力。
  • 恢复测试有哪些内容？
    • 平均修复时间
    • 重新初始化
    • 数据恢复
    • 重新启动

• 2.安全测试

  • 定义：
    • 设置一些测试用例试图突破系统的安全保密措施，检验系统是否有安全保密的漏洞。
  • 安全测试有哪些内容？
    • 用户管理和访问控制
    • 数据存储和数据通信的远程安全控制

• 3.强度测试

  • 定义：
    • 也称压力测试，在反常规数据量、频率或资源的方式下运行系统，以检验系统能力的最高实际限度。

• 4.性能测试

  • 定义：用来测试软件在系统集成中的运行的性能。
  • 性能测试有哪些测试内容？
    • 运行速度
    • 系统资源占有
    • 响应时间

• 5.容量测试

  • 定义：
    • 指系统正常运行的范围内测定系统能过处理的数据容量，测试系统承受超额数据容量的能力。

• 6.正确性测试

  • 定义：
    • 检查软件的各项功能是否符合规格说明书的要求。
  • 正确性测试有哪些测试内容？
    • 设计一些逻辑正确的输入值，检查运行结果是不是期望值。方法如下：
      • 枚举法
      • 边界值法

• 7.可靠性测试

  • 定义：
    • 是从验证的角度出发，检验系统的可靠性是否达到预期目标，同时要考虑当前系统可靠性增长情况。
  • 可靠性测试有哪些测试内容？
    • 首先，最关键测试数据包括失效间隔时间，失效修复时间，失效数量，失效级别。
    • 然后应用可靠性模型，得到系统的失效率及可靠性增长趋势。
  • 可靠性指标如何界定？
    • 采用平均故障时间
    • 生产环境中，系统最大出现故障数量。

• 8.兼容性测试

  • 定义：
    • 是检测各软件之间能否正确地交互和共享信息。
  • 兼容性测试有哪些测试内容？
    • 检测与操作系统，浏览器和应用软件的兼容
    • 检测与各软件之间共享数据的能力

• 9.Web网站测试

  • Web网站测试有哪些测试内容？
    • 文字测试、链接测试、图像测试、表单测试
    • 动态内容测试、数据库测试、服务器性能及负载测试、安全性测试
    • 配置测试、兼容测试、可用性测试、文档测试

38. 软件测试的过程

• 测试计划——测试设计——测试执行——测试总结
• 测试计划
  • 输入：软件测试任务书和需求说明书
  • 输出：软件测试计划
• 测试设计
  • 输入：软件测试计划
  • 输出：测试用例和测试数据
• 测试执行：
  • 输入：测试用例和测试数据
  • 输出：软件测试记录
• 测试总结
  • 输入：软件测试计划、测试用例、软件测试记录
  • 输出：测试报告

39. 测试计划的目的？包含哪些元素？

• 目的：
  • 定义测试活动的范围、方法、资源和进度，明确要测试的条目、要测试的特性、要实施的测试任务、对每个任务的个人反映，以及与计划相关的风险。
• 测试计划的组成部分：
  • 测试需求，测试策略，资源分配，工作量估算，测试时间计划表，风险评估，子计划制定，缺陷报告说明

40. 为什么要进行软件测试？软件测试的目的？

• 因为软件也是一种产品，是产品都得经过测试才可以上市。所以软件产品需要进行测试是无可厚非的。在项目生命周期中，测试是给软件进行把关的一个重要环节。
• 软件测试的目的：
  • 基于不同的立场，存在两种完全不同的测试目的。
    • 从用户的角度出发，希望通过软件测试是暴露软件中隐藏的错误和缺陷，以考虑是否接受该产品。
    • 从开发者的角度出发，希望成为表明软件产品中不存在错误的过程，验证该软件已正确地实现了用户的要求，确立人们对软件质量的信心。

41. 5w1h

• who 谁来测
  • 指出由谁来测
• what 做什么
  • 明确测试的范围和内容
• when 什么时候测试
  • 确定测试的开始和结束日期
• why 为什么做
  • 可以帮助测试团队理解测试的目的
• where 在哪里
  • 给出测试文档和软件的存放位置
• how 如何做
  • 指出测试的方法和工具

42. 5C原则

• Correct 准确
  • 每个组成部分的描述准确，不会引起误解
• Clear 清晰
  • 每个组成部分的描述清晰，易于理解
• Concise 简洁
  • 只包含必不可少的信息，不包括任何多余的内容
• Complete 完整
  • 包含复现该缺陷的完整步骤和其他本质信息
• Consistent 一致
  • 按照一致的格式书写全部缺陷报告

43. 软件测试的模型

• V
  
  

* X * W * H * 迭代 * 快速 * 瀑布 * 螺旋

44. 测试人员在软件开发过程中的任务是什么？

• 1.寻找bug
• 2.避免软件开发过程中的缺陷
• 3.衡量软件的品质
• 4.关注用户的需求

45. 软件测试的目的

• 测试的最终目的是为了避免错误的发生，确保应用程序能够正常高效的运行。
• 好的测试用例在于发现至今未发现的错误。
• 成功的测试是发现了至今未发现的错误的测试。
• 好的测试工程师应该做到不仅发现问题，还能帮助开发人员分析问题。

46. 什么是回归测试？

• 回归测试是指修改旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。自动回归测试将大幅降低系统测试、维护升级等阶段的成本。回归测试作为软件生命周期的组成部分，在整个软件测试过程中占有很大的工作量比重，软件开发的各个阶段都会进行多次回归测试。

47. 什么情况下进行回归测试？

• 每个环节都可能进行回归测试

48. 什么是冒烟测试？

• 在测试中发现问题，找到一个Bug，然后开发人员来修复这个Bug。这是想知道这次修复是否真的解决了程序的Bug，或者是否对其他模块造成影响，就需要针对此问题进行专门的测试，这个过程称为冒烟测试。冒烟测试优点节省测试时间，防止build失败。缺点是覆盖率比较低。冒烟测试是自由测试的一种。

49. 冒烟测试的流程？如何判断测试是否通过？

• 冒烟测试一般用于每日构建，首先从服务器下载最新的源代码，然后编译单元测试，运行单元测试通过后，编译可执行文件，可执行文件若可运行，并能执行最基本的功能，则认为通过了冒烟测试。

50. 冒烟测试和回归测试的区别？

• 冒烟测试就是完成一个新版本开发后，对该版本最基本的功能进行测试，保证基本的功能和流程能走通。如果不通过，则打回开发那里重新开发；如果通过测试，才会进行下一步的测试（功能测试，集成测试，系统测试）。冒烟测试优点是节省时间，防止build失败。缺点是覆盖率比较低。
• 51. 回归测试是在以前版本中发现bug在新版本中验证是否存在且是否引发新的bug.我对回归测试的理解：一是当你修复一个bug后，把之前的测试用例再次应用到修复后的版本上进行测试。二是当一个新版本开发好后，而且冒烟测试通过，此时可以先用上一个版本的测试用例对新版本进行测试，看是否有bug。

52. 什么是软件质量保证?如何保证？

• 软件质量保证是建立一套有计划，有系统的方法，来向管理层保证拟定出的标准、步骤、实践和方法能够正确地被所有项目所采用。软件质量保证的目的是使软件过程对于管理人员来说是可见的。它通过对软件产品和活动进行评审和审计来验证软件是合乎标准的。
• 如何保证

  • 质量是全面质量管理

    • 1.代码质量：开发通过单元测试保证

    • 2.使用质量: 让用户参与测试，保证用户体验

    • 3.引入QA，保存过程环节质量

    • 4.系统测试工程师保证系统质量满足需求

  • 测试人员人员的质量保证

    • 1.测试策略：质量是多维度的，功能测试、性能测试、兼容性测试等多种测试类型的结合

    • 2.用例质量：采用合适的用例方法，如何进行需求分析，用例评审

    • 3.执行质量：如何保证执行深度与广度

    • 4.缺陷质量：Bug评审，引入合适的Bug流程

    • 5.过程质量：合理的软件测试流程，测试过程监控

53. 简述软件项目测试全过程？

• 首先对软件的需求进行分析（需求文档），测试计划的制定（人员成本风险的分析阶段），测试用例的设计（最关键的阶段），测试用例的执行，回归测试，编写测试报告和总结。

54. 如何保障编写用例不会有功能遗漏？

• 功能测试中要保证测试不会有功能遗漏，首先要做好测试需求分析，测试需求获取方法包含了2种，显式需求及隐式需求。

• 做好需求分析，及时维护测试需求文档。将不同的需求来源划分成一个个需求点，针对每一点进行测试分析，界定测试范围，利用各种测试设计的方法产生功能测试节点。

• 用例设计阶段，首先要保证产品或项目在主要功能测试用例完全覆盖的情况下去对细节进行测试用例设计，可以运用多种测试用例设计方法来减少功能遗漏。

• 强化测试用例评审阶段的作用，以测试用例评审会议来检验功能是否覆盖完全，评审会成员需要有设计，开发，测试及专家组成员。

• 测试全面不等于全面测试，不要过分的追求高测试覆盖率，要结合实际情况去考虑

55. 项目测试结束后是否需要总结？总结有哪些方面？如何操作？

• 需要总结
• 在项目测试结束后还需要将测试工作产品归档，同时对测试过程和测试活动进行相关数据的收集和分析，总结经验和教训。这些内容可以帮助测试团队在以后的项目中尽量避免重复以前的错误。可以发现哪些方面需要改进，并把结果运动到以后的项目中，可以帮助后继项目的持续改进。当确定测试结束后，应当收集主要的输出成果，并且交给相应人员或归档，这些活动称为结束活动。
• 总结哪些方面：
  • 由于在测试的后期发现不曾预料的缺陷集群现象，和客户沟通，分析原因找出对策
  • 测试活动是否实现了测试计划测定的目标
  • 有哪些非期望的事情和风险发生、发生的原因是什么，是不是有效的解决了这些风险，是否存在没有解决的变更请求。
  • 测试过程中哪些方面做得不够好，为什么会存在这些问题，如何在下一个项目中做得更好。
  • 哪些方面做得比较好及相应的经验
  • 实际工作量和原来的工作量是否差距很大，分析原因
  • 缺陷趋势分析，引起缺陷的原因和影响的分析
• 记录测试过程中所有的经验教训，并且将经验教训文档化，避免以后测试中出现重复这些错误。

56. 测试用例如何设计，测试用例设计依据应该考虑到哪些方面？

• 首先应该有明确的需求，然后才进行思考如何设计测试用例。通常来讲，我们考虑一个测试对象的时候至少从下面六个方面来考虑：功能性、兼容性、易用性、可靠性、性能、安全
• 比如文本框输入一串数字后提交
  • 从功能方面考虑
    • 从需求中分析，比如最长最少输入字符是多少，输入字符类型是否有限制
  • 从兼容性方面考虑
    • 各浏览器是否显示正确，点击按钮是否有效。
    • 浏览器各版本显示是否正确，点击按钮是否有效
    • 是否支持手持移动设备，比如手机和平板
  • 从易用性方面考虑
    • web界面外观，风格是否合适
    • 文本输入框长度是否合适，是否应该默认提示如何输入
    • 输入错误时提示是否友好
  • 可靠性和性能方面考虑
    • 输入HTML和js相关标签字符，是否会破坏页面。
    • 这个应用是否在同一台服务器上运行多个实例，多个用户同时使用是否有问题
    • 在大并发下使用，计算速度是否满足要求。
  • 从安全性方面考虑
    • 输入的数据是否被保存，输入字符可能包含的敏感信息。
    • 是否可以复制粘贴字符串
    • 尝试快速点击提交按钮
    • 考虑是否有安全漏洞，请求是否被截取，导致返回失败