测试基础

1. 什么是软件测试？

为了发现程序中的错误而执行程序的过程

2. 软件测试的目的？

首先，测试并不仅仅是为了要找出错误。通过分析错误产生的原因和错误的分布特征，可以帮助项目管理者发现当前所采用的软件过程的缺陷，以便改进。同时，这种分析也能帮助我们设计出有针对性地检测方法，改善测试的有效性。

其次，没有发现错误的测试也是有价值的，完整的测试是评定测试质量的一种方法。详细而严谨的可靠性增长模型可以证明这一点。

测试的目的是按照用户所需软件的质量，检查开发软件过程出现的 bug, 使得开发人员及时修改，可以避免在开发结束的时候发现软件存在质量问题，避免公司不必要的损失。赢得用户对公司产品的认可。

测试的目的是以最少人力、物力和时间找出软件中潜在各种错误和缺陷，通过修正种错误和缺陷提高软件质量，回避软件发布后由于潜在的软件缺陷和错误造成的隐患带来的商业风险。

测试的附带收获是，它能够证明软件的功能和性能与需求说明相符合。实施测试收集到的测试结果数据为可靠性分析提供了依据。

测试不能表明软件中不存在错误，它只能说明软件中存在错误。

3. 软件测试的目标

发现尽可能多的错误

测试是一个为了寻找错误而运行程序的过程。

一个好的测试案例是指很可能找到迄今为止尚未发现的错误的用例。一个成功的测试是指揭示了迄今为止尚未发现的错误的测试。

4. 软件测试的原则

1. 应当把尽早地和不断地进行软件测试作为软件开发者的座右铭。
2. 测试用例应由测试输入数据和对应的预期输出结果这两部分组成。
3. 程序员应避免检查自己的程序。
4. 在设计测试用例时，应包括合理的输入条件和不合理的输入条件。
5. 软件测试的原则
6. 充分注意测试中的群集现象。经验表明，测试后程序中残存的错误数目与该程序中已发现的错误数目成正比。
7. 严格执行测试计划，排除测试的随意性。
8. 应当对每一个测试结果做全面检查。
9. 妥善保存测试计划，测试用例，出错统计和最终分析报告，为维护提供方便。

5. 测试的工作流程

测试的功能点都是来自于需求文档从产品的需求文档中提炼出来的，等产品完成需求文档并完成需求文档的评审会就开始测试用例的编写工作，一般项目半个月迭代一次的话设计测试的时间一般是 3 天就要完成，我们设计测试用例的时间还是比较充足案例设计一般都会和产品的开发并行。

在案例完成编写之后大家会开会一起来评审你的案例。在评审的过程中大家会提出一些问题，会后要把这些遗漏的测试点补充上，但是这时并不是大功告成哦。痛苦的案例执行才刚刚开始，哈哈哈，在这个里我为什么用痛苦来形容呢，大家也知道开发一般只是把功能开发好自己可能都没有自测过就发给测试，这时候测试发现和自己想象中的 APP 差距太大，有的时候会发现一眼都能看到的问题为什么还要等着测试来发现，小编遇到这样的问题也表示无奈。但是只能硬着头皮测下去。在测试的过程中每天在下班的时候还需要发测试日报告诉项目中的成员现在案例执行的情况，当然了测试完成之后发测试报告也是必须的了，算是对这次项目跌代测试完成的一个交代。

6. 测试工程师的职责

测试经理：

1. 制定测试计划。
2. 确保测试过程正常进行。测试工程师
3. 编写测试用例
4. 搭建测试环境
5. 执行测试

7. 软件都有多少种分类？

根据功能的不同，电脑软件可以粗略地分成四个层次：

1. 最贴近电脑硬件的是一些小巧的软件。它们实现一些最基本的功能，通常“固化”在只读存储器芯片中，因此称为固件。
2. 系统软件包括操作系统和编译器软件等。系统软件和硬件一起提供一个“平台”。它们管理和优化电脑硬件资源的使用。
3. 支持软件。包括图形用户界面、软件开发工具、软件评测工具、数据库管理系统、中间件等。
4. 应用软件种类最多，包括办公软件、电子商务软件、通信软件、行业软件，游戏软件等等。

8. 软件的分类

• 按功能分类
  • 系统软件
  • 支撑软件
  • 应用软件
• 按服务对象的范围分类
  • 项目软件
  • 产品软件
• 按软件规模分类
  • 微型
  • 小型
  • 中型
  • 大型
  • 甚大型
  • 极大型
• 按软件工作方式分类
  • 实时处理软件
  • 分时软件
  • 交互式软件
  • 批处理软件
• 按技术架构分类
  • 单机版软件
  • C/S 架构软件
  • B/S 架构软件

9. 测试的主要方面

1. 功能测试：
   • 链接测试
   • 表单测试
   • Cookies 测试
   • 设计语言测试
   • 数据库测试
   • 性能测试：
     • 连接速度测试
     • 负载测试
     • 压力测试
2. 接口测试：
   • 服务器接口
   • 外部接口
   • 错误处理
3. 可用性测试：
   • 导航测试
   • 图形测试
   • 内容测试
   • 整体界面测试
4. 兼容性测试：
   • 平台测试
   • 浏览器测试
   • 视频测试
   • Modem / 连接速率测试
   • 打印机测试
   • 组合测试
5. 安全测试：
   • 目录设置
   • 登录
   • Session
   • 日志文件
   • 加密
   • 安全漏洞
   • 代码合法性测试：
     • 程序代码合法性检查
     • 显示代码合法性检查
6. 文档测试：

10. 软件测试的对象

软件测试并不等于程序测试。软件测试应贯穿于软件定义与开发的整个期间。需求分析、概要设计、详细设计以及程序编码等各阶段所得到的文档，包括需求规格说明、概要设计规格说明、详细设计规格说明以及源程序，都应成为软件测试的对象

11. 什么是“测试案例”？

测试案例是一份文档，它描述了一个输入、反应、或者是与其相应的预期的响应，以便来判断应用软件的工作是否正常。测试案例应当包括测试标识、测试案例的名称、目标、测试条件 / 设置、输入数据要求、步骤、以及预期的结果。

注：开发一个应用软件的测试案例的过程，需要全面、深入地考虑该软件的操作，所以有助于发现在其需求或设计里面的问题。因此，如果有可能，在开发周期中应当尽早准备测试案例。

12. 怎么编写案例？

案例的编写与测试阶段的定义有很大的关系。系统测试和 unit 测试的案例可能不同。总体而言测试案例根据系统的需求而定。

13. 软件测试的两种方法

黑盒测试和白盒测试

• 黑盒：这种方法是把测试对象看做一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明。黑盒测试又叫做功能测试或数据驱动测试。
• 白盒：此方法把测试对象看做一个透明的盒子，它允许测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。通过在不同点检查程序的状态，确定实际的状态是否与预期的状态一致。因此白盒测试又称为结构测试或逻辑驱动测试。

14. 测试结束的标准是什么？

1. 用例全部执行。
2. 覆盖率达到标准。
3. 缺陷率达到标准。
4. 其他指标达到质量标准

15. 软件的生命周期

软件生命周期是指一个计算机软件从功能确定、设计，到开发成功投入使用，并在使用中不断地修改、增补和完善，直到停止该软件的使用的全过程（从酝酿到废弃的过程）

16. 什么是软件的生命周期？

生命周期从收到应用软件开始算起，到该软件不再使用为止。它有如下各方面的内容：初始构思、需求分析、功能设计、内部设计、文档计划、测试计划、文档准备、集成、测试、维护、升级、再测试、逐步淘汰 (phase-out)、等等。

17. 软件测试按过程分为三个步骤

• 单元测试：单元测试又称模块测试，是针对软件设计的最小单位 ─ 程序模块，进行正确性检验的测试工作。其目的在于发现各模块内部可能存在的各种差错。单元测试需要从程序的内部结构出发设 计测试用例。多个模块可以平行地独立进行单元测试。
• 集成测试：在运行（可能是不完整）的应用中保证软件单元被结合后能正常操作的测试执行的阶段
• 系统测试：当应用作为整体运行时的测试执行阶段

18. 面向对象的设计如何影响测试？

好的面向对象的工程设计使得从代码追溯内部设计、再到功能测试，最后追溯到需求，成为一件容易的事。因为它对黑盒测试的影响很少（不需要了解应用软件的内部设计），而白盒测试只需针对该应用软件的对象。如果该应用软件设计得好，就可简化测试设计。

19. 软件带来错误的原因很多。主要的原因有哪些？

1. 交流不够、交流上有误解或者根本不进行交流
2. 软件复杂性
3. 程序设计错误
4. 需求变化
5. 时间压力
6. 代码文档贫乏
7. 软件开发工具

20. 做好软件测试的一些关键点

1. 测试人员必须经过测试基础知识和理论的相关培训。
2. 测试人员必须熟悉系统功能和业务。
3. 测试必须事先要有计划，而且测试方案要和整个项目计划协调好
4. 必须事先编写测试用例，测试执行阶段必须根据测试用例进行
5. 易用性，功能，分支，边界，性能等功能性和非功能性需要都要进行测试
6. 对于复杂的流程一定要进行流程分支，组合条件分析，再进行等价类划分准备相关测试数据
7. 测试设计的一个重要内容是要准备好具体的测试数据，清楚这个测试数据是测哪个场景或分支的
8. 个人任务平均每三个测试用例至少应该发现一个 BUG，否则只能说明测试用例质量不好
9. 除了每日构建的冒烟测试可以考虑测试自动化外，其它暂时都不要考虑去自动化。

21. 软件测试的步骤是什么？

1. 测试过程按 4 个步骤进行，即单元测试（Unit Testing）、集成测试（Integrated Testing）、确认测试（Validation Testing）和系统测试（System Testing）及发版测试。
2. 开始是单元测试，集中对用源代码实现的每一个程序单元进行测试，检查各个程序模块是否正确地实现了规定的功能。
3. 集成测试把已测试过的模块组装起来，主要对与设计相关的软件体系结构的构造进行测试。
4. 确认测试则是要检查已实现的软件是否满足了需求规格说明中确定了的各种需求，以及软件配置是否完全、正确。

22. 如何录制测试脚本？

1. 新建一个脚本（Web/HTML 协议）
2. 点击录制按钮，在弹出的对话框的 URL 中输入”about:blank”。
3. 在打开的浏览器中进行正常操作流程后，结束录制。
4. 调试脚本并保存。可能要注意到字符集的关联。
5. 设置测试场景
6. 针对性能设置测试场景，主要判断在正常情况下，系统的平均事务响应时间是否达标
7. 针对压力负载设置测试场景，主要判断在长时间处于满负荷或者超出系统承载能力的条件下，系统是否会崩溃

23. 应该考虑进行如何测试的测试方法

• 黑盒测试 ── 不考虑内部设计和代码，根据需求和功能进行测试。
• 白盒测试 ── 根据应用软件的代码的内部逻辑，按照代码的语句、分支、路径和条件进行测试。
• 功能测试 —— 对一个应用软件的功能模块进行黑盒测试。这种测试应当由测试人员进行。但这并不意味着程序员在推出软件之前不进行代码检查。（这一原则适用于所有的测试阶段。）系统测试 ── 针对全部需求说明进行黑盒测试，包括系统中所有的部件。
• 回归测试 ── 每当软件经过了整理、修改、或者其环境发生变化，都重复进行测试。很难说需要进行多少次回归测试，特别是是到了开发周期的最后阶段。进行此种测试，特别适于使用自动测试工具。
• 负荷试验 ── 在大负荷条件下对应用软件进行测试。例如测试一个网站在不同负荷情况下的状况，以确定在什么情况下系统响应速度下降或是出现故障。
• 压力测试 ── 经常可以与“负荷测试”或“性能测试”相互代替。这种测试是用来检查系统在下列条件下的情况：在非正常的巨大负荷下、某些动作和输入大量重复、输入大数、对数据库进行非 常复杂的查询，等等。
• 性能测试 ── 经常可以与“压力测试”或“负荷测试”相互代替。理想的“性能测试”（也包括其他任何类型的测试）都应在质量保障和测试计划的文档终予以规定。
• 可用性测试 ── 是专为“对用户友好”的特性进行测试。这是一种主观的感觉，取决于最终用户或顾客。可以进行用户会见、检查、对用户会议录像、或者使用其他技术。程序员和测试人 员通常不参加可用性测试。
• 安装 / 卸载测试 ── 对安装 / 卸载进行测试（包括全部、部分、升级操作）。
• 安全测试 ── 测试系统在应付非授权的内部 / 外部访问、故意的损坏时的防护情况。这需要精密复杂的测试技术。
• 兼容性测试 ── 测试在特殊的硬件 / 软件 / 操作系统 / 网络环境下的软件表现。
• α 测试 ── 在开发一个应用软件即将完成时所进行的测试。此时还允许有较小的设计修改。通常由最终用户或其他人进行这种测试，而不是由程序员和测试人员来进行。
• β 测试 ── 当开发和测试已基本完成，需要在正式发行之前最后寻找毛病而进行的测试。通常由最终用户或其他人进行这种测试，而不是由程序员和测试人员来进行。

24. 怎样估计测试工作量？

• 效率假设：即测试队伍的工作效率。对于功能测试，这主要依赖于应用的复杂度，窗口的个数，每个 窗口中的动作数目。对容量测试，主要依赖于建立测试所需数据的工作量大小。
• 测试假设：为了验证一个测试需求所需测试动作数目。应用的维数：应用的复杂度指标。例如要加入一个记录，测试需求的维数就是这个记录中域的数目。
• 所处测试周期的阶段：有些阶段主要工作都在设计，有些阶段主要是测试执行。

25. 测试设计的问题

1. 不做测试设计，测试过程也是胡乱建立的。
2. 测试设计不详细，不是基于可量度的测试策略，例如测试计划覆盖一个集合或者测试需 求的一个子集。
3. 测试过程没有采用最好的技术来检验 Windows C/S 结构的测试需求。
4. 测试用例的选择规则。
5. 选择与测试需求的实质部分最相关的测试用例。
6. 选择的测试用例应该不容易应用程序的改变的影响。

26. 当测试过程发生错误时，有哪几种解决办法？

1. 跳转到别的测试过程
2. 调用一个能够清除错误的过程
3. 退出过程，启动另一个
4. 退出过程和应用程序，重新启动启动 Windows，在失败的地方重新开始测试

27. 测试执行的问题

测试执行的问题

1. 自动化测试没有有效的利用，使得手工测试太多。
2. 测试结果的捕获没有系统性，而且没有查看或调查
3. 缺陷报告必须用手工加入缺陷跟踪系统错误分类
   • 测试用例失败正常错误
   • 脚本命令失败
4. 致命错误导致测试停止，这种情况最好重起 Windows。

28. 测试评估的目标

1. 量化测试进程
2. 生成缺陷和测试覆盖率的总结报告

测试评估的问题

1. 没有把测试覆盖率作为报告测试进程的根据，使得不知测试是否结束；
2. 没有做缺陷评估，缺陷评估是量度软件可行性的重要指标；
3. 不使用专门的软件工具进行数据输入任务和相应的评估活动，使得这些任务变得繁重累人。

29. 如何提高测试？

提高测试需要从几个方面着手，其实只是自己的一些感觉，不一 定就需要按部就班，需要找自己适合的点。

制定完备的测试计划 清楚的认识测试计划，测试计划是一个文档，能够保证整个研发过程中顺利执行的一个指导性文档，它描述了几个方面的问题。

1. 描述了项目的的
2. 描述了项目的开发周期
3. 描述了在测试中遇到的技术
4. 描述了测试案例的设计周期
5. 描述测试案例的执行周期
6. 描述了测试过程中用到的工具或者技术
7. 描述了测试过程中用到的资源情况
8. 描述了测试过程中可能遇到的风险以及规避方法 9） 提高案例设计水平

30. C/S 模式的优点和缺点

C/S 模式的优点

• 由于客户端实现与服务器的直接相连，没有中间环节，因此响应速度快。
• 操作界面漂亮、形式多样，可以充分满足客户自身的个性化要求。
• C/S 结构的管理信息系统具有较强的事务处理能力，能实现复杂的业务流程。

C/S 模式的缺点

• 需要专门的客户端安装程序，分布功能弱，针对点多面广且不具备网络条件的用户 群体，不能够实
• 现快速部署安装和配置。
• 兼容性差，对于不同的开发工具，具有较大的局限性。若采用不同工具，需要重新 改写程序。
• 开发成本较高，需要具有一定专业水准的技术人员才能完成。

31. B/S 模式的优点和缺点

B/S 模式的优点

• 具有分布性特点，可以随时随地进行查询、浏览等业务处理。
• 业务扩展简单方便，通过增加网页即可增加服务器功能。
• 维护简单方便，只需要改变网页，即可实现所有用户的同步更新。
• 开发简单，共享性强。

B/S 模式的缺点

• 个性化特点明显降低，无法实现具有个性化的功能要求。
• 操作是以鼠标为最基本的操作方式，无法满足快速操作的要求。
• 页面动态刷新，响应速度明显降低。
• 无法实现分页显示，给数据库访问造成较大的压力。
• 功能弱化，难以实现传统模式下的特殊功能要求。

32. 测试结束的标准是什么？

1. 测试超过了预定时间，则停止测试。
2. 执行了所有的测试用例，但并没有发现故障，则停止测试。
3. 使用特定的测试用例设计方案作为判断测试停止的基础。
4. 正面指出停止测试的具体要求，即停止测试的标准可定义为查出某一预订 数目的故障。
5. 根据单位时间内查出故障的数量决定是否停止测试。

33. 怎么才能够全面的测试到每一个点？

测试的全面性主要需要在设计测试计划的时候考虑，从测试策略，产品需求等等 多个角度考虑从而定义全部的测试点

34. 开发与测试的关系

开发和测试是一个有机的整体！在产品的发布之前，开发和测试是循环进行的，测出的缺陷要经开发人员修改后继续测试。在开发的同时测试经理开始编写测试用例，测试文档要参考开发文档，所 以开发和测试是不可分割的，少了任何一个都不能开发出产品。

从角色方面看，像理论和实验的关系，开发人员通过自己的想象创造出一套思想，之后测试人员 再对它进行检验、证伪，开发人员再修改的过程从而不断丰富产品。从方法方面看，是演绎和归纳的 关系，一个要掌握大量的技术，一个要不断的从实例中学习。因这 两方面的不同，所以开发和测试看上去做的工作很不一样。

开发与测试是相辅相承、密不可分的，开发人员开发出新的产品后要通过测试判断产品是否完全满足用户的需求。如果发现缺陷，提交给开发人员进行修复，然后再转交测试人员进行回归测试，直 到产品符合需求规格说明。一个符合用户需求的产品是开发和测试共同努力的成果。

35. 怎么和开发沟通

测试和开发沟通大部分都在讨论 bug，测试说是 bug 但是开发认为这个不是 bug，对于测试来说就很头痛了明明是问题但是为什么开发不主动修改呢？这时候测试应该去需求文档中找出有关这个功能 的描述或者去询问产品经理，总之不要正面冲突，要拿出证据来说服开发。

36. 测试过程

1. 制定系统测试计划
2. 编写系统测试用例
3. 执行系统测试用例
4. 跟踪管理缺陷
5. 总结测试

37. 测试出口准则

1. 所有的缺陷已经解决
2. 项目规定测试阶段时间结束
3. 执行完成测试计划中的系统测试内容，修正了所发现的错误，未修正的错误被项目经理允许留到下一版本
4. 高级经理和项目经理均同意结束测试
5. 测试结果经过了专门的评审

38. 测试完成标准

1. 系统功能与用户需求说明书一致
2. 功能性测试用例通过率达到 100%
3. 非功能性测试用例通过率达到 95%
4. 一、二级错误修复率应达到 100%。
5. 三、四级错误修复率应达到 80% 以上。
6. 五级错误修复率应达到 60% 以上。

39. 测试活动中统计了哪些数据？

工作量 bug 数量

40. 如何选择用户测试的工作产品？

在用户有需求得到签字确认之后，我们选择用户测试的工作产品。我们几乎所有的项目都进行了测试， 我们是在项目立项公告中得知需要对工作产品进行测试。

41. 测试环境描述在哪儿？

测试环境在测试计划里面进行描述，测试计划是由测试经理编写，我们在测试计划中了解到自己是此 次项目组的测试工程师。

42. 进行测试时产生了哪些文档或记录？

测试的整个过程有系统测试计划、系统测试用例、系统测试报告、缺陷报告、产 品发布说明 在执行测试的过程中 只有缺陷报告，这个还是用在缺陷管理工具中进行的，最后在工具中导出缺陷报告

43. 测试人员需要何时参加需求分析？

如果条件循序原则上来说 是越早介入需求分析越好 因为测试人员对需求理解越深刻 对测试工作的开展越有利 可以尽早的确定测试思路 减少与开发人员的交互 减少对需求理解上的偏差

44. 产品测试完以后由谁来发布？

这个不定 开发发布 还是技术支持发布都有可能

45. 软件测试与调试的关系

1. 测试条件已知，规程可定义，结果可预知
2. 测试可以计划，过程可控
3. 测试是检验，调试是推理过程
4. 测试表明程序失败，调试表明正确
5. 测试可不了解设计细节
6. 测试由非设计人员完成
7. 测试有理论依据
8. 测试可自动化

46. 质量的八大特性是什么？各种特性的定义？

1. 功能性：软件所实现的功能达到它的设计规范和满足用户需求的程度
2. 性能：在规定条件下，实现软件功能所需的响应时间和计算机资源（CPU、内存、磁盘空间和数据吞吐量）的使用程度
3. 可靠性：在满足一定条件的应用环境中，软件能够正常维持其工作的能力，在出现一些错误操作时，软件可以具有容错性，如果软件意外退出，重新启动后可以恢复最近的软件数据
4. 安全性：为了防止意外或人为的破坏，软件应具备的自身保护能力
5. 使用性：用户在理解、学习和操作软件的过程中的付出的努力的难易程度
6. 维护性：软件在运行维护过程中，如果出现了运行故障或者扩展新功能和性能，软件系统是否具有可分析性和良好的扩展性，重新设计后的软件的稳定性和可测试性
7. 移植性：软件从现有运行平台向另一个运行平台过度的适应程度和平台可替换性
8. 重用性：整个软件或其中一部分能作为软件包而被再利用的程度

47. 什么是软件的“质量”？

高质量的软件是适当的、无错误的，能在预算内按时交货，满足需求 / 或期望，并且是可维护的。所以，质量是一个主观的术语。它取决于谁是客户以及客户对项目计划的影响。对一个软件开发项目来说，“客户”的范围很广，包括最终用户、客户所接受的测试者、与客户合同有关的官员、客户管理、 开发机构的管理者 / 会计 / 测试人员 / 销售人员、未来的软件维护工程师、股票持有者、杂志专栏记者， 等等。每一类客户对“质量”都有自己的倾向性 – 会计部门判断质量会从其收益来考虑，而最终用户则重视友好的用户界面和没有错误。

48. 软件质量应该从哪些方面来评价？

可靠性、安全性、性能、易用性、外观、稳定性

49. 什么是“软件质量保障”？

软件质量保障涉及到整个软件开发过程，包括监视和改善过程、确保任何经过认可的标准和步骤 都被遵循、并且保证问题被发现和被处理。从本质上说，软件质量保障是“预防”。

50. 为什么软件会有毛病？

1. 交流错误或者没有进行交流，

2. 软件的复杂性

   编程错误

3. 需求变更

   客户恐怕不明白改变需求的影响，也许是知道但依然需要变更 ──会导致重新设计、重订工程进度表、对其他项目的影响、已完成的工作需要重做或者放弃、对硬件需求的影响等等。如果在 项目中出现许多小的改变或一个大的改变，在项目各部分中出现已知或未知的相关的问题，可能会相 互影响并导致出现问题。而且，不断地变更也会增加软件的复杂性，可能会导致错误的出现。这样就 会影响技术人员的积极性。在一些快速变化的商业环境里，持续变更需求的影响是致命的。在这种情 况下，管理者必须知道它的危险性。质量保障和测试工程师必须与此相适应，并安排持续的广泛的测 试，以克服不可避免产生的问题。

4. 时间压力

   因为有许多猜测成分，软件开发项目的进度很难安排得理想。当最后期限快到的时候，压力逐渐增大，错误随之产生

5. 自负心理、代码文档质量差、软件开发工具

51. 什么是 UML？

Unified Modeling Language 它是一种用于描述，构造软件系统以及商业建模的语言。简单的理解就是它可以以一种直观的方式表示出一个系统的各项内容

52. 什么是 CMM？

CMM：Capability Maturity Model，即“能力成熟度模型”。它是一个分 5 级的、可以描述结构完善程度的模型，用它来说明所交付的软件的效能。

53. 比较一下黑盒测试、白盒测试、单元测试、集成测试、系统测试、验收测试的区别与联系

• 黑盒测试：把测试对象当成一个黑盒子，测试人员完全不考虑逻辑结构和内部特性，只依据程序的需求说明书来检查程式的功能是否满足它的功能说明。

• 白盒测试：把测试对象当成一个透明的盒子，允许测试人员利用程序内部逻辑结构及相关信息，设计或选择测试用例，对程式所有逻辑路径进行测试。

• 单元测试：白盒测试的一种，对软件设计中的单元模块进行测试。

• 集成测试：在单元测试的基础上，对单元模块之间的连接和组装进行测试。 系统测试：在所有都考虑的情况下，对系统进行测试。

• 验收测试：第三方进行的确认软件满足需求的测试。

54. 比较负载测试、压力测试，容量测试和强度测试区别

• 负载测试：在一定的工作负荷下，系统的负荷及响应时间。通过逐步增加系统负载，最终确定在满足 性能指标的情况下，系统能承受的最大负载量的测试。
• 强度测试：又称疲劳强度测试，在系统稳定运行的情况下能够支持的最大并发用户数，持续执行一段时间业务，通过综合分析，确定系统处理最大工作量强度性能的过程。一定负荷条件下，在较长时间跨度内的系统连续运行给系统性能所造成的影响。
• 容量测试：容量测试目的是通过测试预先分析出反映软件系统应用特征的某项指标的极限值（如最大 并发用户数、数据库记录数等），系统在其极限值状态下没有出现任何软件故障或还能保持主要功能 正常运行。容量测试还将确定测试对象在给定时间内能够持续处理的最大负载或工作量。容量测试的 目的是使系统承受超额的数据容量来发现它是否能够正确处理。容量测试是面向数据的，并且目的是 显示系统可以处理目标内确定的数据容量。
• 压力测试：通过逐步增加系统负载，最终确定在什么负载条件下系统性能将处于崩溃状态，以此获得 系统能提供的最大服务级别的测试。

55. 测试执行过程的三个阶段

1. 初测期

   测试主要功能和关键的执行路径，排除主要障碍。

2. 细测期

   依据测试计划和测试大纲、测试用例，逐一测试大大小小的功能、方方面面的特性、性能、用户 界面、兼容性、可用性等等；预期可发现大量不同性质、不同严重程度的错误和问题。

3. 回归测试期

   系统已达到稳定，在一轮测试中发现的错误已十分有限；复查已知错误的纠正情况，确认未引发 任何新的错误时，终结回归测试。

56. 什么是验证、评价、预排、检查？

• 验证 (verification) 涉及了回顾和会议，以评估文档、计划、代码、需求和说明书。可以通过检查表、调查表、排练、和检查会来进行。
• 评价 (validation) 则指在检察完成之后的实际测试。术语“IV”和“V”分别代表验证和评价。预排是一个非正式的会议，用来进行评估和信息交流。通常不需要或者只需很少一点准备。
• 检查比预排更正式一点，通常有 3-8 个人参加会议，包括一个仲裁者 (moderator)、读者 （可以是作者或者任何评论者）、一个记录员作记录。典型的检查对象是一个文件，例如需求说明或者测试计划，目的在于发现问题和查找遗漏，而不是去对任何东西进行实际的修改。会议的参加者应当有准备，应当通读文件，大多数的问题会在准备的过程中被发现。检查会的结果应写成书面报告。对检查会进行 全面准备是困难而艰苦的工作，但它是保证质量最有用的方法。在检查过程中，最有经验的雇员的作 用就向‘大哥哥’一样，他们的技能也许不大显眼，但对任何软件开发机构是最重要的，这是因为预防错误要比发现错误在费用方面更加有效。

57. 什么是兼容性测试？兼容性测试侧重哪些方面？

兼容测试主要是检查软件在不同的硬件平台、软件平台上是否可以正常的运行，即是通常说的软 件的可移植性。

兼容的类型，如果细分的话，有平台的兼容，网络兼容，数据库兼容，以及数据格式的兼容。兼容测试的重点是，对兼容环境的分析。通常，是在运行软件的环境不是很确定的情况下，才需要做兼容。根据软件运行的需要，或者根据需求文档，一般都能够得出用户会在什么环境下使用该软件，把这些环境整理成表单，就得出做兼容测试的兼容环境了。

兼容和配置测试的区别在于，做配置测试通常不是 Clean OS 下做测试，而兼容测试多是在 Clean OS 的环境下做的。

58. 我现在有个程序，发现在 Windows 上运行得很慢，怎么判别是程序存在问题还是软硬件系统存在问题？

1. 检查系统是否有中毒的特征；
2. 检查软件 / 硬件的配置是否符合软件的推荐标准；
3. 确认当前的系统是否是独立，即没有对外提供什么消耗 CPU 资源的服务；
4. 如果是 C/S 或者 B/S 结构的软件，需要检查是不是因为与服务器的连接有问题，或者访问有问题造成的；
5. 在系统没有任何负载的情况下，查看性能监视器，确认应用程序对 CPU/ 内存的访问情况。

59. 测试的策略有哪些？

黑盒 / 白盒，静态 / 动态，手工 / 自动，冒烟测试，回归测试，公测（Beta 测试的策略）

60. 正交表测试用例设计方法的特点是什么？

用最少的实验覆盖最多的操作，测试用例设计很少，效率高，但是很复杂；

对于基本的验证功能，以及二次集成引起的缺陷，一般都能找出来；但是更深的缺陷，更复杂的缺陷，还是无能为力的；

具体的环境下，正交表一般都很难做的。大多数，只在系统测试的时候使用此方法。

61. 描述使用 bugzilla 缺陷管理工具对软件缺陷（BUG）跟踪的管理的流程？

就是 Bugzilla 的状态转换图。

62. 你觉得 bugzilla 在使用的过程中，有什么问题？

界面不稳定；

根据需要配置它的不同的部分，过程很烦琐。

流程控制上，安全性不好界定，很容易对他人的 Bug 进行误操作；没有综合的评分指标，不好确认修复的优先级别。

63. 描述测试用例设计的完整过程？

需求分析 + 需求变更的维护工作； 根据需求 得出测试需求；

设计测试方案，评审测试方案；

方案评审通过后，设计测试用例，再对测试用例进行评审；

64. 单元测试的策略有哪些？

逻辑覆盖、循环覆盖、同行评审、桌前检查、代码走查、代码评审、景泰数据流分析

65. 使用 QTP 做功能测试，录制脚本的时候，要验证多个用户的登录情况 / 查询情况，如何操作？

分析用户登录的基本情况，得出一组数据，通过性测试 / 失败性测试的都有（根据 TC 来设计这些数据），然后录制登录的脚本，将关键的数据参数化，修改脚本，对代码进行加强，调试脚本。

66. QTP 中的 Action 有什么作用？有几种？

Action 的作用

• 用 Action 可以对步骤集进行分组
• 步骤重组，然后被整体调用
• 拥有自己的 sheet
• 组合有相同需求的步骤，整体操作
• 具有独立的对象仓库

Action 的种类

• 可复用 Action
• 不可复用 Action
• 外部 Action

67. TestDirector 有些什么功能，如何对软件测试过程进行管理？

需求管理

• 定义测试范围
• 定义需求树
• 描述需求树的功能点测试计划
• 定义测试目标和测试策略。
• 分解应用程序，建立测试计划树。
• 确定每个功能点的测试方法。
• 将每个功能点连接到需求上，使测试计划覆盖全部的测试需求。
• 描述手工测试的测试步骤
• 指明需要进行自动测试的功能点测试执行
• 定义测试集合。
• 为每个测试人员制定测试任务和测试日程安排。
• 运行自动测试。缺陷跟踪
• 记录缺陷
• 查看新增缺陷，并确定哪些是需要修正的
• 相关技术人员修改缺陷
• 回归测试
• 分析缺陷统计图表，分析应用程序的开发质量。

68. 你所熟悉的软件测试类型都有哪些？请试着分别比较这些不同的测试类型的区别与联系（如功能测试、性能测试……）？

Compatibility Testing（兼容性测试），也称“Configuration testing（配置测试）”，测试软件是否和系统的其它与之交互的元素之间兼容，如：浏览器、操作系统、硬件等。验证测试对象在不同的软件和 硬件配置中的运行情况。

Functional testing （功能测试），也称为 behavioral testing（行为测试），根据产品特征、操作描述和用户方案，测试一个产品的特性和可操作行为以确定它们满足设计需求。本地化软件的功能测试，用 于验证应用程序或网站对目标用户能正确工作。使用适当的平台、浏览器和测试脚本，以保证目标用 户的体验将足够好，就像应用程序是专门为该市场开发的一样。

Performance testing（性能测试），评价一个产品或组件与性能需求是否符合的测试。包括负载测试、强度测试、数据库容量测试、基准测试等类型。

69. 软件的评审一般由哪些人参加？其目的是什么？

在正式的会议上将软件项目的成果（包括各阶段的文档、产生的代码等）提交给用户、客户或有关部门人员对软件产品进行评审和批准。其目的是找出可能影响软件产品质量、开发过程、维护工作 的适用性和环境方面的设计缺陷，并采取补救措施，以及找出在性能、安全性和经济方面的可能的改进。

人员：用户、客户或有关部门开发人员，测试人员，需求分析师都可以，就看处于评审那个阶段

70. 测试活动中，如果发现需求文档不完善或者不准确，怎么处理？

测试需求分析 发现需求文档不完善或者不准确，应该立即和相关人员进行协调交流。

71. 阶段评审与项目评审有什么区别？

阶段评审：对项目各阶段成果和工作评审

项目评审：对项目工作和产品总体评审

72. 什么是桩模块？什么是驱动模块？

桩模块：被测模块调用模块驱动模块

调用被测模块

73. 什么是扇入？什么是扇出？

扇入：被调次数，扇出：调其它模块数目

74. 你认为做好测试计划工作的关键是什么？

软件测试计划就是在软件测试工作正式实施之前明确测试的对象，并且通过对资源、时间、风险、测试范围和预算等方面的综合分析和规划，保证有效的实施软件测试；做好测试计划工作的关键 ：目的，管理，规范

1. 明确测试的目标，增强测试计划的实用性

   编写软件测试计划得重要目的就是使测试过程能够发现更多的软件缺陷，因此软件测试计划的价值取 决于它对帮助管理测试项目，并且找出软件潜在的缺陷。因此，软件测试计划中的测试范围必须高度 覆盖功能需求，测试方法必须切实可行，测试工具并且具有较高的实用性，便于使用，生成的测试结果直观、准确

2. 坚持“5W”规则，明确内容与过程

   “5W”规则指的是“What（做什么）”、“Why（为什么做）”、“When（何时做）”、“Where（在哪里）”、 “How（如何做）”。利用“5W”规则创建软件测试计划，可以帮助测试团队理解测试的目的（Why），明确测试的范围和内容（What），确定测试的开始和结束日期（When），指出测试的方法和工具（How），给出测试文档和软件的存放位置（Where）。

3. 采用评审和更新机制，保证测试计划满足实际需求

   测试计划写作完成后，如果没有经过评审，直接发送给测试团队，测试计划内容的可能不准确或遗漏测试内容，或者软件需求变更引起测试范围的增减，而测试计划的内容没有及时更新，误导测试 执行人员。

4. 分别创建测试计划与测试详细规格、测试用例

   应把详细的测试技术指标包含到独立创建的测试详细规格文档，把用于指导测试小组执行测试过 程的测试用例放到独立创建的测试用例文档或测试用例管理数据库中。测试计划和测试详细规格、测 试用例之间是战略和战术的关系，测试计划主要从宏观上规划测试活动的范围、方法和资源配置，而 测试详细规格、测试用例是完成测试任务的具体战术。

75. 你觉得对于测试有哪些基本素质要求

1. 细心，只有细心才能保证不遗漏测试点并及时发现问题。
2. 善于怀疑，在测试的过程中总会遇到开发会说这个功能肯定没有问题，这个时候就要小心开 发给你埋下的坑了。
3. 要有追根究底的精神，我们有的时候发现一些不好复现的 bug，对于这样的 bug 一定要有不找出问题不罢休的精神。
4. 考虑问题要周到，需要测试结合需求业务流程，和不同手机的兼容等多个方面来考虑问题。
5. 要有良好的沟通能力，不要让开发说服你这个问题修补修改，如果你认为这个问题比较严重 需要说服开发来修改他 / 她认为不用修改的问题。

76. 一套完整的测试应该由哪些阶段组成？

测试计划、测试设计与开发、测试实施、测试评审与测试结论

77. 软件测试的流程是什么？

• 需求调查：全面了解您的系统概况、应用领域、软件开发周期、软件开发环境、开发组织、时间安排、功能需求、性能需求、质量需求及测试要求等根据系统概况进行项目所需的人员、时间和工作量估计及项目报价。
• 制定初步的项目计划：在与您充分共同和协商的基础上制定我们的测试计划。测试准备：组织测试团队、培训、建立测试和管理环境等。
• 测试设计：按照测试要求进行每个测试项的测试设计，包括测试用例的设计及测试脚本的开发等。测试实施：按照测试计划进行实施测试。
• 测试评估：根据测试的结果，出具测试评估报告。

78. 说说你对 SQA 的职责和工作活动（如软件度量）的理解

SQA 就是独立于软件开发的项目组，通过对软件开发过程的监控，来保证软件的开发流程按照指定的 CMM 规程（如果有相应的 CMM 规程），对于不符合项及时提出建议和改进方案，必要是可以要高层经理汇报以求问题的解决。通过这样的途径来预防缺陷的引入，从而减少后期软件的维护成本。ＳＱＡ主要的工作活动包括制定 SQA 工作计划，参与阶段产物的评审，进行过程质量、功能配置及物理配置的审计等；对项目开发过程中产生的数据进行度量等等；

79. 单元测试的主要内容？

模块接口测试、局部数据结构测试、路径测试、错误处理测试、边界测试

80. 集成测试也叫组装测试或者联合测试，请简述集成测试的主要内容？

1. 在把各个模块连接起来的时候，穿越模块接口的数据是否会丢失；
2. 一个模块的功能是否会对另一个模块的功能产生不利的影响；
3. 各个子功能组合起来，能否达到预期要求的父功能；
4. 全局数据结构是否有问题；
5. 单个模块的误差累积起来，是否会放大，从而达到不能接受的程度。

81. 简述集成测试与系统测试关系？

1. 集成测试的主要依据概要设计说明书，系统测试的主要依据是需求设计说明书；
2. 集成测试是系统模块的测试，系统测试是对整个系统的测试，包括相关的软硬件平台、网络以 及相关外设的测试。

82. 软件测试的文档测试应当贯穿于软件生命周期的全过程，其中用户文档是文档测试的重点。那么软件系统的用户文档包括哪些？

• 用户手册
• 安装和设置指导联机帮助
• 指南、向导
• 样例、示例和模板授权 / 注册登记表最终用户许可协议

83. 软件系统中除用户文档之外，文档测试还应该关注哪些文档？

• 开发文档
• 软件需求说明书
• 数据库设计说明书概要设计说明书 详细设计说明书 可行性研究报告
• 管理文档
• 项目开发计划测试计划
• 测试报告
• 开发进度月报开发总结报告

84. 简述软件系统中用户文档的测试要点？

1. 读者群。文档面向的读者定位要明确。对于初级用户、中级用户以及高级用户应该有不同的定位
2. 术语。文档中用到的术语要适用与定位的读者群，用法一致，标准定义与业界规范相吻合。
3. 正确性。测试中需检查所有信息是否真实正确，查找由于过期产品说明书和销售人员夸大事实而导致的错误。检查所有的目录、索引和章节引用是否已更新，尝试链接是否准确，产品支持电话、地址和邮政编码是否正确。
4. 完整性。对照软件界面检查是否有重要的分支没有描述到，甚至是否有整个大模块没有描述到。
5. 一致性。按照文档描述的操作执行后，检查软件返回的结果是否与文档描述的相同。
6. 易用性。对关键步骤以粗体或背景色给用户以提示，合理的页面布局、适量的图表都可以给用 户更高的易用性。需要注意的是文档要有助于用户排除错误。不但描述正确操作，也要描述错误处理 办法。文档对于用户看到的错误信息应当有更详细的文档解释。
7. 图表与界面截图。检查所有图表与界面截图是否与发行版本相同。
8. 样例与示例。像用户一样载入和使用样例。如果是一段程序，就输入数据并执行它。以每一个模块制作文件，确认它们的正确性。
9. 语言。不出现错别字，不要出现有二义性的说法。特别要注意的是屏幕截图或绘制图形中的文字。
10. 印刷与包装。检查印刷质量；手册厚度与开本是否合适；包装盒的大小是否合适；有没有零 碎易丢失的小部件等等。

85. 单元测试主要内容是什么？

单元测试大多数由开发人员来完成，测试人员技术背景较好或者开发系统软件时可能会安排测试人员 进行单元测试，大多数进行的单元测试都是开发人员调试程序或者开发组系统联合调试的过程。讨论 这个问题主要是扩充一下读者的视野。

单元测试一般包括五个方面的测试：

1. 模块接口测试：模块接口测试是单元测试的基础。只有在数据能正确流入、流出模块的前提下， 其他测试才有意义。模块接口测试也是集成测试的重点，这里进行的测试主要是为后面打好基础。

   测试接口正确与否应该考虑下列因素：

   • 输入的实际参数与形式参数的个数是否相同；
   • 输入的实际参数与形式参数的属性是否匹配；
   • 输入的实际参数与形式参数的量纲是否一致；
   • 调用其他模块时所给实际参数的个数是否与被调模块的形参个数相同；
   • 调用其他模块时所给实际参数的属性是否与被调模块的形参属性匹配；
   • 调用其他模块时所给实际参数的量纲是否与被调模块的形参量纲一致；
   • 调用预定义函数时所用参数的个数、属性和次序是否正确；
   • 是否存在与当前入口点无关的参数引用；
   • 是否修改了只读型参数；
   • 对全程变量的定义各模块是否一致；
   • 是否把某些约束作为参数传递。

   如果模块功能包括外部输入输出，还应该考虑下列因素：

   • 文件属性是否正确；
   • OPEN/CLOSE 语句是否正确；
   • 格式说明与输入输出语句是否匹配；
   • 缓冲区大小与记录长度是否匹配；
   • 文件使用前是否已经打开；
   • 是否处理了文件尾；
   • 是否处理了输入 / 输出错误；
   • 输出信息中是否有文字性错误。
   • 局部数据结构测试；
   • 边界条件测试；
   • 模块中所有独立执行通路测试；

2. 局部数据结构测试：检查局部数据结构是为了保证临时存储在模块内的数据在程序执行过程中完 整、正确，局部功能是整个功能运行的基础。重点是一些函数是否正确执行，内部是否运行正确。局 部数据结构往往是错误的根源，应仔细设计测试用例，力求发现下面几类错误：

   • 不合适或不相容的类型说明；
   • 变量无初值；
   • 变量初始化或省缺值有错；
   • 不正确的变量名（拼错或不正确地截断）；
   • 出现上溢、下溢和地址异常。

3. 边界条件测试：边界条件测试是单元测试中最重要的一项任务。众所周知，软件经常在边界上失 效，采用边界值分析技术，针对边界值及其左、右设计测试用例，很有可能发现新的错误。边界条件 测试是一项基础测试，也是后面系统测试中的功能测试的重点，边界测试执行的较好，可以大大提高 程序健壮性。

4. 模块中所有独立路径测试：在模块中应对每一条独立执行路径进行测试，单元测试的基本任务是 保证模块中每条语句至少执行一次。测试目的主要是为了发现因错误计算、不正确的比较和不适当的 控制流造成的错误。具体做法就是程序员逐条调试语句。常见的错误包括：

   • 误解或用错了算符优先级；
   • 混合类型运算；
   • 变量初值错；
   • 精度不够；
   • 表达式符号错。

   比较判断与控制流常常紧密相关，测试时注意下列错误：

   • 不同数据类型的对象之间进行比较；
   • 错误地使用逻辑运算符或优先级；
   • 因计算机表示的局限性，期望理论上相等而实际上不相等的两个量相等；
   • 比较运算或变量出错；
   • 循环终止条件或不可能出现；
   • 迭代发散时不能退出；
   • 错误地修改了循环变量。

5. 模块的各条错误处理通路测试：程序在遇到异常情况时不应该退出，好的程序应能预见各种出错条件， 并预设各种出错处理通路。如果用户不按照正常操作，程序就退出或者停止工作，实际上也是一种缺陷，因此单元测试要测试各种错误处理路径。

   一般这种测试着重检查下列问题：

   • 输出的出错信息难以理解；
   • 记录的错误与实际遇到的错误不相符；
   • 在程序自定义的出错处理段运行之前，系统已介入；
   • 异常处理不当；
   • 错误陈述中未能提供足够的定位出错信息。

86. 如何理解强度测试？

强度测试是为了确定系统在最差工作环境的工作能力，也可能是用于验证在标准工作压力下的各种 资源的最下限指标。

它和压力测试的目标是不同的，压力测试是在标准工作环境下，不断增加系统负荷，最终测试出该系 统能力达到的最大负荷（稳定和峰值）, 而强度测试则是在非标准工作环境下，甚至不断人为降低系统工作 环境所需要的资源，如网络带宽，系统内存，数据锁等等，以测试系统在资源不足的情况下的工作状态，通过 强度测试，可以确定本系统正常工作的最差环境。

强度测试和压力测试的测试指标相近，大多都是与时间相关的指标，如并发量（吞吐量）, 延迟（最大、最 小、平均）以及顺序指标等

强度测试需要对系统的结构熟悉，针对系统的特征设计强度测试的方法

87. 如何理解压力、负载、性能测试测试？

性能测试是一个较大的范围，实际上性能测试本身包含了性能、强度、压力、负载等多方面的测 试内容。

压力测试是对服务器的稳定性以及负载能力等方面的测试，是一种很平常的测试。增大访问系统 的用户数量、或者几个用户进行大数据量操作都是压力测试。而负载测试是压力相对较大的测试，主 要是测试系统在一种或者集中极限条件下的相应能力，是性能测试的重要部分。100 个用户对系统

进行连续半个小时的访问可以看作压力测试，那么连续访问 8 个小时就可以认为负载测试，1000 个用户连续访问系统 1 个小时也可以看作是负载测试。

实际上压力测试和负载测试没有明显的区分。测试人员应该站在关注整体性能的高度上来对系统 进行测试。

88. 什么是系统瓶颈？

瓶颈主要是指整个软硬件构成的软件系统某一方面或者几个方面能力不能满足用户的特定业务要 求，“特定”是指瓶颈会在某些条件下会出现，因为毕竟大多数系统在投入前。

严格的从技术角度讲，所有的系统都会有瓶颈，因为大多数系统的资源配置不是协调的，例如 CPU 使用率刚好达到 100％时，内存也正好耗尽的系统不是很多见。因此我们讨论系统瓶颈要从应用的角度讨论：关键是看系统能否满足用户需求。在用户极限使用系统的情况下，系统的响应仍然正常，我们 可以认为改系统没有瓶颈或者瓶颈不会影响用户工作。

因此我们测试系统瓶颈主要是实现下面两个目的：

• 发现“表面”的瓶颈。主要是模拟用户的操作，找出用户极限使用系统时的瓶颈，然后解决瓶颈， 这是性能测试的基本目标。
• 发现潜在的瓶颈并解决，保证系统的长期稳定性。主要是考虑用户在将来扩展系统或者业务发生 变化时，系统能够适应变化。满足用户目前需求的系统不是最好的，我们设计系统的目标是在保证系 统整个软件生命周期能够不断适应用户的变化，或者通过简单扩展系统就可以适应新的变化。

89. 文档测试主要包含什么内容？

在国内软件开发管理中，文档管理几乎是最弱的一项，因而在测试工作中特别容易忽略文档测试也就不足为奇了。要想给用户提供完整的产品，文档测试是必不可少的。文档测试一般注重下面几个 方面：

• 文档的完整性：主要是测试文档内容的全面性与完整性，从总体上把握文档的质量。例如用户手 册应该包括软件的所有功能模块。
• 描述与软件实际情况的一致性：主要测试软件文档与软件实际的一致程度。例如用户手册基本完 整后，我们还要注意用户手册与实际功能描述是否一致。因为文档往往跟不上软件版本的更新速度。
• 易理解性：主要是检查文档对关键、重要的操作有无图文说明，文字、图表是否易于理解。对于 关键、重要的操作仅仅只有文字说明肯定是不够的，应该附有图表使说明更为直观和明了。
• 文档中提供操作的实例：这项检查内容主要针对用户手册。对主要功能和关键操作提供的应用实 例是否丰富，提供的实例描述是否详细。只有简单的图文说明，而无实例的用户手册看起来就像是软件界面的简单拷贝，对于用户来说，实际上没有什么帮助。
• 印刷与包装质量：主要是检查软件文档的商品化程度。有些用户手册是简单打印、装订而成，过于粗糙，不易于用户保存。优秀的文档例如用户手册和技术白皮书，应提供商品化包装，并且印刷精 美。

90. 功能测试用例需要详细到什么程度才是合格的？

这个问题也是测试工程师经常问的问题。有人主张测试用例详细到每个步骤执行什么都要写出来， 目的是即使一个不了解系统的新手都可以按照测试用例来执行工作。主张这类写法的人还可以举出例子：欧美、日本等软件外包文档都是这样做的。

另外一种观点就是主张写的粗些，类似于编写测试大纲。主张这种观点的人是因为软件开发需求管理不规范，变动十分频繁，因而不能按照欧美的高标准来编写测试用例。这样的测试用例容易维护， 可以让测试执行人员有更大的发挥空间。

实际上，软件测试用例的详细程度首先要以覆盖到测试点为基本要求。举个例子：“用户登陆系 统”的测试用例可以不写出具体的执行数据，但是至少要写出五种以上情况（），如果只用一句话覆 盖了这个功能是不合格的测试用例。覆盖功能点不是指列出功能点，而是要写出功能点的各个方面（如 果组合情况较多时可以采用等价划分）。

另一个影响测试用例的就是组织的开发能力和测试对象特点。如果开发力量比较落后，编写较详细的测试用例是不现实的，因为根本没有那么大的资源投入，当然这种情况很随着团队的发展而逐渐有所改善。测试对象特点重点是指测试对象在进度、成本等方面的要求，如果进度较紧张的情况下， 是根本没有时间写出高质量的测试用例的，甚至有些时候测试工作只是一种辅助工作，因而不编写测试用例。

因此，测试用例的编写要根据测试对象特点、团队的执行能力等各个方面综合起来决定编写策略。 最后要注意的是测试人员一定不能抱怨，力争在不断提高测试用例编写水平的同时，不断地提高自身能力。

91. 配置和兼容性测试的区别是什么？

配置测试的目的是保证软件在其相关的硬件上能够正常运行，而兼容性测试主要是测试软件能否 与不同的软件正确协作。

配置测试的核心内容就是使用各种硬件来测试软件的运行情况，一般包括：

1. 软件在不同的主机上的运行情况，例如 Dell 和 Apple；
2. 软件在不同的组件上的运行情况，例如开发的拨号程序要测试在不同厂商生产的 Modem 上的运行情况；
3. 不同的外设；
4. 不同的接口；
5. 不同的可选项，例如不同的内存大小； 兼容性测试的核心内容：
6. 测试软件是否能在不同的操作系统平台上兼容；
7. 测试软件是否能在同一操作系统平台的不同版本上兼容；
8. 软件本身能否向前或者向后兼容；
9. 测试软件能否与其它相关的软件兼容；
10. 数据兼容性测试，主要是指数据能否共享；

配置和兼容性测试通称对开发系统类软件比较重要，例如驱动程序、操作系统、数据库管理系统 等。具体进行时仍然按照测试用例来执行。

92. 软件文档测试主要包含什么？

随着软件文档系统日益庞大，文档测试已经成为软件测试的重要内容。文档测试对象主要如下：

• 包装文字和图形；
• 市场宣传材料、广告以及其它插页；
• 授权、注册登记表；
• 最终用户许可协议；
• 安装和设置向导；
• 用户手册；
• 联机帮助；
• 样例、示范例子和模板；

文档测试的目的是提高易用性和可靠性，降低支持费用，因为用户通过文档就可以自己解决问题。 因文档测试的检查内容主要如下：

• 读者对象——主要是文档的内容是否能让该级别的读者理解；
• 术语——主要是检查术语是否适合读者；
• 内容和主题——检查主题是否合适、是否丢失、格式是否规范等；
• 图标和屏幕抓图——检查图表的准确度和精确度；
• 样例和示例——是否与软件功能一致；
• 拼写和语法；
• 文档的关联性——是否与其它相关文档的内容一致，例如与广告信息是否一致；

文档测试是相当重要的一项测试工作，不但要给予充分的重视，更要要认真的完成，象做功能测 试一样来对待文档测试。

93. 没有产品说明书和需求文档地情况下能够进行黑盒测试吗？

这个问题是国内测试工程师经常遇到的问题，根源就是国内软件开发文档管理不规范，对变更的 管理方法就更不合理了。实际上没有任何文档的时候，测试人员是能够进行黑盒测试的，这种测试方 式我们可以称之为探索测试，具体做法就是测试工程师根据自己的专业技能、领域知识等不断的深入了解测试对象、理解软件功能，进而发现缺陷。

在这种做法基本上把软件当成了产品说明书，测试过程中要和开发人员不断的进行交流。尤其在作项目的时候，进度压力比较大，可以作为加急测试方案。最大的风险是不知道有些特性是否被遗漏。

94. 测试中的“杀虫剂怪事”是指什么？

“杀虫剂怪事”一词由 BorisBeizer 在其编著的《软件测试技术》第二版中提出。用于描述测试人员对同一测试对象进行的测试次数越多，发现的缺陷就会越来越少的现象。就像老用一种农药，害虫 就会有免疫力，农药发挥不了效力。这种现象的根本原因就是测试人员对测试软件过于熟悉，形成思维定势。

为了克服这种现象，测试人员需要不断编写新的测试程序或者测试用例，对程序的不同部分进行 测试，以发现更多的缺陷。也可以引用新人来测试软件，刚刚进来的新手往往能发现一些意想不到的 问题。

95. 在配置测试中，如何判断发现的缺陷是普通问题还是特定的配置问题？

在进行配置测试时，测试工程师仍然会发现一些普通的缺陷，也就是与配置环境无关的缺陷。因 此判断新发现的问题，需要在不同的配置中重新执行发现软件缺陷的步骤，如果软件缺陷不出现了，就可能是配置缺陷；如果在所有的配置中都出现，就可能是普通缺陷。

需要注意的是，配置问题可以在一大类配置中出现。例如，拨号程序可能在所有的外置 Modem 中都存在问题，而内置的 Modem 不会有任何问题。

96. 为什么尽量不要让时间有富裕的员工去做一些测试？

表面上看这体现了管理的效率和灵活性，但实际上也体现了管理者对测试的轻视。测试和测试的人有很大关系。测试工作人员应该是勤奋并富有耐心，善于学习、思考和发现问题，细心有条理，总结问题，如果具备这样的优点，做其它工作同样也会很出色，因此这里还有一个要求，就是要喜欢测试这项工作。如果他是专职的，那么肯定更有经验和信心。国内的小伙子好象都喜欢做程序员，两者工作性质不同，待遇不同，地位不同，对自我实现的价值的认识也不同，这是行业的一个需要改善的问题。如果只是为了完成任务而完成任务，或者发现了几个问题就觉得满意了，这在任何其它工作中都是不行的。

97. 完全测试程序是可能的吗？

软件测试初学者可能认为拿到软件后需要进行完全测试，找到全部的软件缺陷，使软件“零缺陷” 发布。实际上完全测试是不可能的。主要有以下一个原因：

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

98. 软件测试的风险主要体现在哪里？

我们没有对软件进行完全测试，实际就是选择了风险，因为缺陷极有可能存在没有进行测试的部分。举个例子，程序员为了方便，在调试程序时会弹出一些提示信息框，而这些提示只在某种条件下会弹出，碰巧程序发布前这些代码中的一些没有被注释掉。在测试时测试工程师又没有对其进行测试。 如果客户碰到它，这将是代价昂贵的缺陷，因为交付后才被客户发现。

因此，我们要尽可能的选择最合适的测试量，把风险降低到最小。

99. 发现的缺陷越多，说明软件缺陷越多吗？

这是一个比较常见的现象。测试工程师在没有找到缺陷前会绞尽脑汁的思考，但是找到一个后， 会接二连三的发现很多缺陷，颇有个人成就感。其中的原因主要如下：

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

“缺陷一个连着一个”不是一个客观规律，只是一个常见的现象。如果软件编写的比较好，这种 现象就不常见了。测试人员只要严肃认真的测试程序就可以了。

100. 所有的软件缺陷都能修复吗？所有的软件缺陷都要修复吗？

从技术上讲，所有的软件缺陷都是能够修复的，但是没有必要修复所有的软件缺陷。测试人员要

做的是能够正确判断什么时候不能追求软件的完美。对于整个项目团队，要做的是对每一个软件缺陷 进行取舍，根据风险决定那些缺陷要修复。发生这种现象的主要原因如下：

• 没有足够的时间资源。在任何一个项目中，通常情况下开发人员和测试人员都是不够用的，而且 在项目中没有预算足够的回归测试时间，再加上修改缺陷可能引入新的缺陷，因此在交付期限的强大 压力下，必须放弃某些缺陷的修改。
• 有些缺陷只是特殊情况下出现，这种缺陷处于商业利益考虑，可以在以后升级中进行修复。
• 不是缺陷的缺陷。我们经常会碰到某些功能方面的问题被当成缺陷来处理，这类问题可以以后有 时间时考虑再处理。

最后要说的是，缺陷是否修改要由软件测试人员、项目经理、程序员共同讨论来决定是否修复， 不同角色的人员从不同的角度来思考，以做出正确的决定。

101. 软件测试人员就是 QA 吗？

软件测试人员的职责是尽可能早的找出软件缺陷，确保得以修复。而质量保证人员（QA）主要职责是创建或者制定标准和方法，提高促进软件开发能力和减少软件缺陷。测试人员的主要工作是测试， 质量保证人员日常工作重要内容是检查与评审，测试工作也是测试保证人员的工作对象。

软件测试和质量是相辅相成的关系，都是为了提高软件质量而工作。

102. 如何减少测试人员跳槽带来的损失？

在 IT 行业里跳槽已经是一种司空见惯的现象，而且跳槽无论给公司还是给个人都会带来一定的损失。测试队伍也无疑会面临跳槽的威胁，作为测试经理管理者，只有从日常工作中开始做起，最能最大限度的减少损失。建议我们从以下两个方面做起：

• 加强部门内员工之间的互相学习，互相学习是建立学习型组织的基本要求，是知识互相转移的过程。在此基础上，可以把个人拥有的技术以知识的形式沉积下来，也就完成了隐性知识到显性知识的转化。
• 通常情况下，企业能为员工提供足够大的发展空间时，如果不是待遇特别低，员工都不会主动离开企业。因此我们要想留住员工，管理者就应该把员工的个人成长和企业的发展联系起来，为员工设定合理发展规划并付诸实现。不过这项要求做起来比较，要有比较好的企业文化为依托。

103. 测试产品与测试项目的区别是什么？

习惯上把开发完成后进行商业化、几乎不进行代码修改就可以售给用户使用的软件成为软件产品， 也就是可以买“卖拷贝”的软件，例如 Windows2000。而通常把针对一个或者几个特定的用户而开发的软件成为软件项目，软件项目是一种个性化的产品，可以是按照用户要求全部重新开发，也可以修改已有的软件产品来满足特定的用户需求。项目和产品的不同特点，决定我们测试产品和测试项目仍然会有很多不同的地方：

• 质量要求不同。通常产品的质量要高一些，修复发布后产品的缺陷成本较高，甚至会带来很多负 面的影响。而做项目通常面向某一用户，虽然质量越高越好，但是一般只要满足用户要求就可以了。
• 测试资源投入多少不同。做软件产品通常是研发中心来开发，进度压力要小些。同时由于质量要 求高，因此会投入较多的人力、物力资源。
• 项目最后要和用户共同验收测试，这是产品测试不具有的特点。

此外，测试产品与测试项目在缺陷管理方面、测试策略制定都会有很大不同，测试管理者应该结 合具体的环境，恰如其分的完成工作。

104. 和用户共同测试（UAT 测试）的注意点有哪些？

软件产品在投产前，通常都会进行用户验收测试。如果用户验收测试没有通过，直接结果就是拿不到“Money”，间接影响是损害了公司的形象，而后者的影响往往更严重。用户验收测试一定要让用户满意。

实际上用户现场测试更趋于是一种演示。在不欺骗用户的前提下，我们向用户展示我们软件的优 点，最后让“上帝”满意并欣然掏出“银子”才是我们的目标。因此用户测试要注意下面的事项：

1. 用户现场测试不可能测试全部功能，因此要测试核心功能。这需要提前做好准备，这些核心功能 一定要预先经过测试，证明没有问题才可以和用户共同进行测试。测试核心模块的目的是建立用户对软件的信心。当然如果这些模块如果问题较多，不应该进行演示。
2. 如果某些模块确实有问题，我们可以演示其它重要的业务功能模块，必要时要向用户做成合理的 解释。争得时间后，及时修改缺陷来弥补。
3. 永远不能欺骗用户，蒙混过关。道理很简单，因为软件是要给用户用的，问题早晚会暴露出来， 除非你可以马上修改。

和用户进行测试还要注意各种交流技巧，争取不但短期利益得到了满足，还要为后面得合作打好 基础。

105. 如何编写提交给用户的测试报告？

随着测试工作越来越受重视，开发团队向客户提供测试文档是不可避免的事情。很多人会问：“我 们可以把工作中的测试报告提供给客户吗？”答案是否定的。因为提供内部测试报告，可能会让客户 失去信心，甚至否定项目。

测试报告一般分为内部测试报告和外部测试报告。内部报告是我们在测试工作中的项目文档，反 映了测试工作的实施情况。

这里主要讨论一下外部测试报告的写法，一般外部测试报告要满足下面几个要求：

1. 根据内部测试报告进行编写，一般可以摘录；
2. 不可以向客户报告严重缺陷，即使是已经修改的缺陷，开发中的缺陷也没有必要让客户知道；
3. 报告上可以列出一些缺陷，但必须是中级的缺陷，而且这些缺陷必须是修复的；
4. 报告上面的内容尽量要真实可靠；
5. 整个测试报告要仔细审阅，力争不给项目带来负面作用，尤其是性能测试报告。 总之，外部测试报告要小心谨慎的编写。

106. 测试工具在测试工作中是什么地位？

国内的很多测试工程师对测试工具相当迷恋，尤其是一些新手，甚至期望测试工具可以取代手工 测试。测试工具在测试工作中起的是辅助作用，一般用来提高测试效率。自动化测试弥补了手工测试 的不足，减轻一定的工作量。实际上测试工具是无法替代大多数手工测试的，而一些诸如性能测试等 自动化测试也是手工所不能完成的。

对于自动测试技术，应当依据软件的不同情况来分别对待，一般自动技术会应用在引起大量重复 性工作的地方、系统的压力点、以及任何适合使用程序解决大批量输入数据的地方。然后再寻找合适 的自动测试工具，或者自己开发测试程序。一定不要为了使用测试工具而使用。

107. 简述负载测试与压力测试的区别

压力测试的主要任务就是获取系统正确运行的极限，检查系统在瞬间峰值负荷下正确执行的能力。 例如，对服务器做压力测试时就可以增加并发操作的用户数量；或者不停地向服务器发送请求；或一次性向服务器发送特别大的数据等。看看服务器保持正常运行所能达到的最大状态。人们通常使用测试工具来完成压力测试，如模拟上万个用户从终端同时登录，这是压力测试中常常使用的方法。

负载测试（Volume Testing）用于检查系统在使用大量数据的时候正确工作的能力，即检验系统的能力最高能达到什么程度。 例如，对于信息检索系统，让它使用频率达到最大；对于多个终端的分时系统，让它所有的终端都开 动。在使整个系统的全部资源达到“满负荷”的情形下，测试系统的承受能力。

108. 写出 bug 报告流转的步骤，每步的责任人及主要完成的工作

（要结合自己实际的工作经验进行回答，不同公司略有区别） 测试人员提交新的 Bug 入库，错误状态为 New。

高级测试员 / 测试经理验证错误，如果确认是错误，分配给开发组。设置状态为 Open。如果不是错误， 则拒绝，设置为 Declined 状态。

开发经理分配 bug 至对应的模块开发人员。

开发人员查询状态为 Open 的 Bug，如果不是错误，则置状态为 Declined；如果是 Bug 则修复并置状态为 Fixed。不能解决的 Bug，要留下文字说明及保持 Bug 为 Open 状态。

对于不能解决和延期解决的 Bug，不能由开发人员自己决定，一般要通过某种会议（评审会）通过才能认可。

测试人员查询状态为 Fixed 的 Bug，然后验证 Bug 是否已解决，如解决，置 Bug 的状态为 Closed， 如没有解决，置 bug 状态为 Reopen。

109. 写出 bug 报告当中一些必备的内容

测试应用的硬件平台（Platform），通常选择“PC”。 测试应用的操作系统平台（OS）。

1. 版本

   提交缺陷报告时通过该字段标识此缺陷存在于被测试软件的哪个版本。

2. Bug 报告优先级

3. Bug 状态

4. Bug 的编号

5. 发现人

6. 提交人

7. 指定处理人

8. 概述

9. 从属关系

10. 详细描述

11. 严重程度

12. 所属模块

13. 附件

14. 提交日期

110. 开发人员老是犯一些低级错误怎么解决？

这种现象在开发流程不规范的团队里特别常见，尤其是一些“作坊式”的团队里。解决这种问题 一般从两个方面入手：

• 一方面从开发管理入手，也就是从根源来解决问题。可以制定规范的开发流程，甚至可以制定惩 罚制度，还有就是软件开发前做好规划设计。
• 另一方面就是加强测试，具体做法就是加强开发人员的自己测试，把这些问题“消灭”在开发阶段，这是比较好的做法。

此外，还可以通过规范的缺陷管理来对开发人员进行控制，比如测试部门整理出常见的缺陷，让开发人员自己对照进行检查，以减少这类低级错误的发生。

开发人员犯错误是正常的现象，作为测试人员一定不能抱怨，要认认真真的解决问题才是上策。

111. 软件的构造号与版本号之间的区别？BVT(BuildVerificationTest)

版本控制命名格式：主版本号.子版本号[.修正版本号[.编译版本号]] Major.Minor[.Revision[.Build]]

应根据下面的约定使用这些部分：

• Major ：具有相同名称但不同主版本号的程序集不可互换。例如，这适用于对产品的大量重写， 这些重写使得无法实现向后兼容性。
• Minor ：如果两个程序集的名称和主版本号相同，而次版本号不同，这指示显著增强，但照顾到了向后兼容性。例如，这适用于产品的修正版或完全向后兼容的新版本。
• Build ：内部版本号的不同表示对相同源所作的重新编译。这适合于更改处理器、平台或编译器的情况。
• Revision ：名称、主版本号和次版本号都相同但修订号不同的程序集应是完全可互换的。这适用于修复以前发布的程序集中的安全漏洞。
• BVT(BuildVerificationTest)：作为 Build 的一部分，主要是通过对基本功能、特别是关键功能的测试，保证新增代码没有导致功能失效，保证版本的持续稳定。

实现 BVT 方式是有以下几种：

1. 测试人员手工验证关键功能实现的正确性。

   • 特点：这是传统开发方法中，通常采用的方式。无需维护测试脚本的成本，在测试人力资源充足，测试人员熟悉业务、并对系统操作熟练情况下效率很高，比较灵活快速。
   • 缺点：人力成本较高； 对测试人员能力有一定要求；测试人员面对重复的工作，容易产生疲倦懈怠，从而影响测试质量。

2. 借助基于 GUI 的自动化功能测试工具来完成，将各基本功能操作录制成测试脚本，每次回放测试脚本验证功能实现的正确性。

   • 特点：能够模拟用户操作完成自动的测试，从 UI 入口到业务实现，每一层的代码实现都经过验证；节约人力成本；降低测试人员重复劳动的工作量，机器不会疲倦；
   • 缺点：对于 UI 变动比较频繁的系统来说，这种方式的维护成本很高，实施起来非常困难。另外，在项目周期较短且后续无延续性或继承的情况下，也不推荐使用此方式。

3. 由开发人员通过自动化测试工具完成业务 层的 BVT 测试。

   • 特点：通过对业务层关键功能的持续集成测试，保证系统功能的持续稳定。可以结合 DailyBuild，做为 Build 的一部分，自动实现并输入 BVT 报告。
   • 缺点：仅对业务规则实现的正确性进行了测试，对表现层无法测试到，对于诸如：前台页面控件各种事件响应、页面元素变化等方面的问题无法保证。

112. 测试在开发阶段的作用

1. 项目规划阶段：负责从单元测试到系统测试的整个测试阶段的监控。
2. 需求分析阶段：确定测试需求分析、系统测试计划的制定，评审后成为管理项目。
3. 详细设计和概要设计阶段：确保集成测试计划和单元测试计划完成。
4. 编码阶段：由开发人员进行自己负责部分的测试代码。在项目较大时，由专人进行编码阶段的测试 任务。
5. 测试阶段（单元、集成、系统测试）：依据测试代码进行测试，并提交相应的测试状态报告和测试结 束报告。

113. 在软件开发过程中 5 个常见的问题是什么？

1. 需求说明差 ── 需求不清楚、不完整、太概括、或者不可测试，都会造成问题。
2. 不切实际的时间表 ── 如果在很短的时间里要求做许多事，出现错误是不可避免的。
3. 测试不充分 ── 只能根据客户意见或者系统崩溃来判断系统质量的高低。
4. 不断增加功能 ── 在开发正在进行过程中要求增加许多新的功能。这是常见的问题。
5. 交流问题 ── 如果开发人员对客户的要求不了解，或者客户由不恰当的期望，必然会导致错误。

114. 针对软件开发过程中的问题，有哪些解决方法？

1. 可靠的需求 (solid requirements) —— 应当有一个经各方一致同意的、清楚的、完整的、详细的、整体的、可实现的、可测试的需求。为帮助确定需求，可使用模型 (prototypes)。
2. 合理的时间表 (realistic schedules) —— 为计划、设计、测试、改错、再测试、变更、以及编制文档留出足够的时间。不应使用突击的办法来完成项目。
3. 适当的测试 (adequate testing) —— 尽早开始测试；每次改错或变更之后，都应重新测试。项目计划中要为测试和改错留出足够的时间。
4. 尽可能坚持最初的需求 (stick to initial requirements as much as possible) —— 一旦开发工作开始，要准备防止修改需求和新增功能。要说明这样作的后果。如果必须进行变更，必须在时间表上有相应 的反映。如果可能，在设计阶段使用快速的模型，以便使客户了解将会得到的东西。这将会使他们对 他们的需求有较高的信心，减少以后的变更。
5. 沟通 (communication ) —— 在适当时机进行预排和检查；充分利用团组通信工具 —— 电子邮件、群件 (groupware)、网络故障跟踪工具、变更管理工具、以及因特网的功能。要确保文件是可用的和最新的。优选电子版文档，避免纸介质文档；进行远距离联合作业及协作；尽早使用模型，使得客 户的预想是清楚的。

115. 阐述软件生命周期都有哪些阶段？ 常见的软件生命周期模型有哪些？

软件生命周期是指一个计算机软件从功能确定、设计，到开发成功投入使用，并在使用中不断地 修改、增补和完善，直到停止该软件的使用的全过程（从酝酿到废弃的过程）

生命周期从收到应用软件开始算起，到该软件不再使用为止。它有如下各方面的内容： 初始构思、需求分析、功能设计、内部设计、文档计划、测试计划、文档准备、集成、测试、维护、升级、再测试、逐步淘汰 (phase-out)、等等

瀑布模型，迭代式模型，快速原型模型，螺旋模型

116. Beta 测试与 Alpha 测试有什么区别？

Beta testing（β测试）, 测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场

Alpha testing （α测试）, 是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试

117. 你认为做好测试用例工作的关键是什么？

需求和设计文档的理解程度，对系统的熟悉程度

118. 简述一下缺陷的生命周期？

提交 -> 确认 -> 分配 -> 修复 -> 验证 -> 关闭

119. 软件的安全性应从哪几个方面去测试？

• 用户认证机制：如数据证书、智能卡、双重认证、安全电子交易协议
• 加密机制
• 安全防护策略：如安全日志、入侵检测、隔离防护、漏洞扫描
• 数据备份与恢复手段：存储设备、存储优化、存储保护、存储管理
• 防病毒系统

120. 软件配置管理工作开展的情况和认识？

软件配置管理贯穿于软件开发、测试活动的始终，覆盖了开发、测试活动的各个环节，它的重要作用之一就是要全面的管理保存各个配置项，监控各配置项的状态，并向项目经理及相关的人员报告，从而实现对软件过程的控制。

软件测试配置管理包括 4 个最基本的活动：

1. 配置项标识
2. 配置项控制
3. 配置项状态报告
4. 配置审计

软件配置管理通常借助工具来辅助，主要有 MS SourceSafe、Rational ClearCase 等

121. 你觉得软件测试通过的标准应该是什么样的？

缺陷密度值达到客户的要求

122. 引入测试管理的含义？

风险分析，进度控制、角色分配、质量控制

123. 什么是版本控制，常用的版本控制系统有哪些？

版本控制（Revision control）是一种软体工程技巧，籍以在开发的过程中，确保由不同人所编辑的同一档案都得到更新。

Git 是一个开源的分布式版本控制系统，可以有效、高速的处理从很小到非常大的项 目版本管理。Git 是 Linus Torvalds 为了帮助管理 Linux 内核开发而开发的一个开放源码的版本控制软件。https://git-scm.com/doc

SVN 是 Subversion 的简称，是一个开放源代码的版本控制系统，相较于 RCS、CVS，它采用了分支管理系统，它的设计目标就是取代 CVS。互联网上很多版本控制服务已从 CVS 迁移到 Subversion。https://tortoisesvn.net/support.html

124. 简述软件测试与软件开发之间的关系？

1. 项目规划阶段：负责从单元测试到系统测试的整个测试阶段的监控。
2. 需求分析阶段：确定测试需求分析、系统测试计划的制定，评审后成为管理项目。测试需求分析是对产品生命周期中测试所需求的资源、配置、每阶段评判通过的规约；系统测试计划则是依据软件的需求规格说明书，制定测试计划和设计相应的测试用例。
3. 详细设计和概要设计阶段：确保集成测试计划和单元测试计划完成。
4. 编码阶段：由开发人员进行自己负责部分的代码的测试。在项目较大时，由专人进行编码阶段的测试任务。
5. 测试阶段（单元、集成、系统测试）：依据测试代码进行测试，并提交相应的测试状态报告和测试结束报告。

开发和测试是一个有机的整体！在产品的发布之前，开发和测试是循环进行的， 测出的缺陷要经开发人员修改后继续测试。在开发的同时测试经理开始编写测试用例， 测 试文档要参考开发文档，所以开发和测试是不可分割的，少了任何一个都不能开发出产品。

从角色方面看，像理论和实验的关系，开发人员通过自己的想象创造出一套思想，之后测试人员再对它进行检验、证伪，开发人员再修改的过程从而不断丰富产品。从方法方面看，是演绎和归纳的关系，一个要掌握大量的技术，一个要不断的从实例中学习。因这两方面的不同，所以开发和测试看上去做的工作很不一样。

开发与测试是相辅相承、密不可分的，开发人员开发出新的产品后要通过测试判断产品是否完全满足用户的需求。如果发现缺陷，提交给开发人员进行修复，然后再转交测试人员进行回归测试，直到产品符合需求规格说明。一个符合用户需求的产品是开发和测试共同努力的成果。

125. 为什么要在一个团队中开展软件测试工作？

因为没有经过测试的软件很难在发布之前知道该软件的质量，就好比 ISO 质量认证一样，测试同样也需要质量的保证，这个时候就需要在团队中开展软件测试的工作。在测试的过程发现软件中存在的 问题，及时让开发人员得知并修改问题，在即将发布时，从测试报告中得出软件的质量情况。

126. 您在以往的测试工作中都曾经具体从事过哪些工作？其中最擅长哪部分工作？

（根据项目经验不同，灵活回答即可）

我曾经做过 web 测试，后台测试，客户端软件，其中包括功能测试，性能测试，用户体验测试。最擅长的是功能测试

127. 您所熟悉的软件测试类型都有哪些？请试着分别比较这些不同的测试类型的区别与联系（如功能测试、性能测试……）

测试类型有：功能测试，性能测试，界面测试。

功能测试在测试工作中占的比例最大，功能测试也叫黑盒测试。是把测试对象看作一个黑盒子。利用黑盒测试法进行动态测试时，需要测试软件产品的功能，不需测试软件产品的内部结构和处理过程。采用黑盒技术设计测试用例的方法有：等价类划分、边界值分析、错误推测、因果图和综合策略。

性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指 标进行测试。负载测试和压力测试都属于性能测试，两者可以结合进行。通过负载测试，确定在各种

工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。压力测试是 通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试。

界面测试，界面是软件与用户交互的最直接的层，界面的好坏决定用户对软件的第一印象。而且 设计良好的界面能够引导用户自己完成相应的操作，起到向导的作用。同时界面如同人的面孔，具有 吸引用户的直接优势。设计合理的界面能给用户带来轻松愉悦的感受和成功的感觉，相反由于界面设 计的失败，让用户有挫败感，再实用强大的功能都可能在用户的畏惧与放弃中付诸东流。

区别在于，功能测试关注产品的所有功能上，要考虑到每个细节功能，每个可能存在的功能问题。 性能测试主要关注于产品整体的多用户并发下的稳定性和健壮性。界面测试更关注于用户体验上，用户使用该产品的时候是否易用，是否易懂，是否规范（快捷键之类的），是否美观（能否吸引用户的注意力），是否安全（尽量在前台避免用户无意输入无效的数据，当然考虑到体验性，不能太粗鲁的弹出警告）？做某个性能测试的时候，首先它可能是个功能点，首先要保证它的功能是没问题的，然后再考虑该功能点的性能测试

128. 您认为做好测试用例设计工作的关键是什么？

白盒测试用例设计的关键是以较少的用例覆盖尽可能多的内部程序逻辑结果

黑盒法用例设计的关键同样也是以较少的用例覆盖模块输出和输入接口。不可能做到完全测试， 以最少的用例在合理的时间内发现最多的问题

129. 请试着比较一下黑盒测试、白盒测试、单元测试、集成测试、系统测试、验收测试的区别与联系

黑盒测试：已知产品的功能设计规格，可以进行测试证明每个实现了的功能是否符合要求。

白盒测试：已知产品的内部工作过程，可以通过测试证明每种内部操作是否符合设计规格要求，所有内部成分是否以经过检查。

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

1. 是否有不正确或遗漏的功能？
2. 在接口上，输入是否能正确的接受？能否输出正确的结果？
3. 是否有数据结构错误或外部信息（例如数据文件）访问错误？
4. 性能上是否能够满足要求？
5. 是否有初始化或终止性错误？

软件的白盒测试是对软件的过程性细节做细致的检查。这种方法是把测试对象看做一个打开的盒 子，它允许测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路 径进行测试。通过在不同点检查程序状态，确定实际状态是否与预期的状态一致。因此白盒测试又称 为结构测试或逻辑驱动测试。

白盒测试主要是想对程序模块进行如下检查：

1. 对程序模块的所有独立的执行路径至少测试一遍。
2. 对所有的逻辑判定，取“真”与取“假”的两种情况都能至少测一遍。
3. 在循环的边界和运行的界限内执行循环体。
4. 测试内部数据结构的有效性，等等。

单元测试（模块测试）是开发者编写的一小段代码，用于检验被测代码的一个很小的、很明确的 功能是否正确。通常而言，一个单元测试是用于判断某个特定条件（或者场景）下某个特定函数的行 为。

单元测试是由程序员自己来完成，最终受益的也是程序员自己。可以这么说，程序员有责任编写 功能代码，同时也就有责任为自己的代码编写单元测试。执行单元测试，就是为了证明这段代码的行 为和我们期望的一致。

集成测试（也叫组装测试，联合测试）是单元测试的逻辑扩展。它的最简单的形式是：两个已经 测试过的单元组合成一个组件，并且测试它们之间的接口。从这一层意义上讲，组件是指多个单元的 集成聚合。在现实方案中，许多单元组合成组件，而这些组件又聚合成程序的更大部分。方法是测试 片段的组合，并最终扩展进程，将您的模块与其他组的模块一起测试。最后，将构成进程的所有模块 一起测试。

系统测试是将经过测试的子系统装配成一个完整系统来测试。它是检验系统是否确实能提供系统 方案说明书中指定功能的有效方法。（常见的联调测试）

系统测试的目的是对最终软件系统进行全面的测试，确保最终软件系统满足产品需求并且遵循系 统设计。

验收测试是部署软件之前的最后一个测试操作。验收测试的目的是确保软件准备就绪，并且可以

让最终用户将其用于执行软件的既定功能和任务。

验收测试是向未来的用户表明系统能够像预定要求那样工作。经集成测试后，已经按照设计把所有的模块组装成一个完整的软件系统，接口错误也已经基本排除了，接着就应该进一步验证软件的有效性， 这就是验收测试的任务，即软件的功能和性能如同用户所合理期待的那样。

130. 测试计划工作的目的是什么？测试计划工作的内容都包括什么？ 其中哪些是最重要的？

软件测试计划是指导测试过程的纲领性文件，包含了产品概述、测试策略、测试方法、测试区域、 测试配置、测试周期、测试资源、测试交流、风险分析等内容。借助软件测试计划，参与测试的项目成员，尤其是测试管理人员，可以明确测试任务和测试方法，保持测试实施过程的顺畅沟通，跟踪和控制测试进度，应对测试过程中的各种变更。

测试计划和测试详细规格、测试用例之间是战略和战术的关系，测试计划主要从宏观上规划测试 活动的范围、方法和资源配置，而测试详细规格、测试用例是完成测试任务的具体战术。所以其中最 重要的是测试测试策略和测试方法（最好是能先评审）

131. 您所熟悉的测试用例设计方法都有哪些？请分别以具体的例子来说明这些方法在测试用例设计工作中的应用

1. 等价类划分

   划分等价类：等价类是指某个输入域的子集合。在该子集合中，各个输入数据对于揭露程序中的错误都是等效的。并合理地假定：测试某等价类的代表值就等于对这一类其它值的测试。因此，可以把全部输入 数据合理划分为若干等价类，在每一个等价类中取一个数据作为测试的输入条件，就可以用少量代表性 的测试数据。取得较好的测试结果。等价类划分可有两种不同的情况：有效等价类和无效等价类。

2. 边界值分析法

   边界值分析方法是对等价类划分方法的补充。测试工作经验告诉我，大量的错误是发生在输入或输 出范围的边界上，而不是发生在输入输出范围的内部。因此针对各种边界情况设计测试用例，可以查出更多的错误。

   使用边界值分析方法设计测试用例，首先应确定边界情况。通常输入和输出等价类的边界，就是应着重测试的边界情况。应当选取正好等于，刚刚大于或刚刚小于边界的值作为测试数据，而不是选取等价类 中的典型值或任意值作为测试数据。

3. 错误推测法

   基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性的设计测试用例的方法。

   错误推测方法的基本思想：列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据他们选择测试用例。例如，在单元测试时曾列出的许多在模块中常见的错误。以前产品测试中曾经发现的错误等，这些就是经验的总结。还有，输入数据和输出数据为 0 的情况。输入表格为空格或输入表格只有一行。这些都是容易发生错误的情况。可选择这些情况下的例子作为测试用例。

4. 因果图方法

   前面介绍的等价类划分方法和边界值分析方法，都是着重考虑输入条件，但未考虑输入条件之间的 联系，相互组合等。考虑输入条件之间的相互组合，可能会产生一些新的情况。但要检查输入条件的组合不是一件容易的事情，即使把所有输入条件划分成等价类，他们之间的组合情况也相当多。因此必须考虑采用一种适合于描述对于多种条件的组合，相应产生多个动作的形式来考虑设计测试用例。这就需要利用因果图（逻辑模型），因果图方法最终生成的就是判定表。它适合于检查程序输入条件的各种组合情况。

132. 说说你对软件配置管理的理解？

项目在开发过程中要用相应的配置管理工具对配置项（包括各个阶段的产物）进行变更控制，配置管 理的使用取决于项目规模和复杂性及风险的水平。软件的规模越大，配置管理就越显得重要。还有在 配置管理中，有一个很重要的概念，那就是基线，是在一定阶段各个配置项的组合，一个基线就提供 了一个正式的标准，随后的工作便基于此标准，并只有经过授权后才能变更这个标准。配置管理工具 主要有 CC，VSS,CVS,SVN 等，我只用过 SVN，对其他的工具不是很熟悉。

133. 请以您以往的实际工作为例，详细的描述一次测试用例设计的完整的过程

就说最近的这次网站功能的测试吧

首先：得到相关文档（需求文档和设计文档），理解需求和设计设计思想后，想好测试策略（测试计划简单点就 OK 了），考虑到测试环境，测试用例，测试时间等问题。

第二步：设计测试用例，测试策略是：把网站部分的功能点测试完，然后在进行系统测试（另外 个模块呢有另一个测试人员负责，可以进行联调测试），网站模块的测试基本是功能测试和界面测试（用户并发的可能性很小，所以不考虑）：这次的网站的输入数据呢是使用数据库中的某张表记录， 如果表中某一数据记录中新加进来的（还没有被处理的，有个标志位），网站启动后会立刻去刷那张 表，得到多条数据，然后在进行处理。处理过程中，会经历 3 个步骤，网站才算完成了它的任务。有 3 个步骤呢，就可以分别对 这 3 个步骤进行测试用例的设计，尽量覆盖到各种输入情况（包括数据库中的数据，用户的输入等），得出了差不多 50 个用例。界面测试，也就是用户看的到的地方，包括发送的邮件和用户填写资料的页面展示。

第三步：搭建测试环境（为什么这个时候考虑测试环境呢？因为我对网站环境已经很熟了，只有 有机器能空于下来做该功能测试就可以做了），因为网站本身的环境搭建和其他的系统有点不同，它 需要的测试环境比较麻烦，需要 web 服务器（Apache,tomcat），不过这次需求呢，网站部分只用到了 tomcat，所以只要有 tomcat 即可

第四步：执行测试

134. 您以往是否曾经从事过性能测试工作？如果有，请尽可能的详细描述您以往的性能测试工作的完整过程

参考答案：（以自己最熟悉的性能测试项目为例）

是的，曾经做过网站方面的性能测试，虽然做的时间并不久（2 个月吧），当时呢，是有位网站性能测试经验非常丰富的前辈带着我一起做。

性能测试类型包括负载测试，强度测试，容量测试等

负载测试：负载测试是一种性能测试指数据在超负荷环境中运行，程序是否能够承担。强度测试： 强度测试是一种性能测试，他在系统资源特别低的情况下软件系统运行情况容量测试：确定系统可处理同时在线的最大用户数在网站流量逐渐加大的情况下，开始考虑做性能测试了，首先要写好性能测试计划，根据运营数 据得出流量最大的页面（如果是第一次的话，一般是首页，下载页，个人帐户页流量最大，而且以某种百分比），

Web 服务器指标指标：

• Avg Rps: 平均每秒钟响应次数＝总请求时间 / 秒数；
• Successful Rounds：成功的请求；
• Failed Rounds ：失败的请求；
• Successful Hits ：成功的点击次数；
• Failed Hits ：失败的点击次数；
• Hits Per Second ：每秒点击次数；
• Successful Hits Per Second ：每秒成功的点击次数；
• Failed Hits Per Second ：每秒失败的点击次数；
• Attempted Connections ：尝试链接数；

135. 你对测试最大的兴趣在哪里？为什么？

最大的兴趣就是测试有难度，有挑战性！做测试越久越能感觉到做好测试有多难。曾经在无忧测 试网上看到一篇文章，是关于如何做好一名测试工程师。一共罗列了 11，12 点，有部分是和人的性格有关，有部分需要后天的努力。但除了性格有关的 1，2 点我没有把握，其他点我都很有信心做好它。刚开始进入测试行业时，对测试的认识是从无忧测试网上了解到的一些资料，当时是冲着做测试需要很多技能才能做的好，虽然入门容易，但做好很难，比开发更难，虽然当时我很想做开发（学校 专业课我基本上不缺席，因为我喜欢我的专业），但看到测试比开发更难更有挑战性，想做好测试的 意志就更坚定了。

不到一年半的测试工作中，当时的感动和热情没有减退一点（即使环境问题以及自身经验，技术 的不足，做测试的你一定也能理解）。

我觉得做测试整个过程中有 2 点让我觉得很有难度（对我来说，有难度的东西我就非常感兴趣）， 第一是测试用例的设计，因为测试的精华就在测试用例的设计上了，要在版本出来之前，把用例写好， 用什么测试方法写？（也就是测试计划或测试策略），如果你刚测试一个新任务时，你得花一定的时间去消化业务需求和技术基础，业务需求很好理解（多和产品经理和开发人员沟通就能达到目的）， 而技术基础可就没那么简单了，这需要你自觉的学习能力，比如说网站吧，最基本的技术知识你要知道网站内部是怎么运作的的，后台是怎么响应用户请求的？测试环境如何搭建？这些都需要最早的学好。至少在开始测试之前能做好基本的准备，可能会遇到什么难题？需求细节是不是没有确定好？这些问题都能在设计用例的时候发现。

第二是发现 BUG 的时候了，这应该是测试人员最基本的任务了，一般按测试用例开始测试就能发现大部分的 bug，还有一部分 bug 需要测试的过程中更了解所测版本的情况获得更多信息，补充测试用例，测试出 bug。还有如何发现 bug？这就需要在测试用例有效的情况下，通过细心和耐心去发现 bug 了，每个用例都有可能发现 bug，每个地方都有可能出错，所以测试过程中思维要清晰（测试过程数据流及结果都得看仔细了，bug 都在里面发现的）。如何描述 bug 也很有讲究，bug 在什么情况下会产生， 如果条件变化一点点，就不会有这个 bug，以哪些最少的操作步骤就能重现这个 bug，这个 bug 产生的规律是什么？如果你够厉害的话，可以帮开发人员初步定位问题。

136. 你以前工作时的测试流程是什么？

（灵活回答）

公司对测试流程没有规定如何做，但每个测试人员都有自己的一套测试流程。我说下我 1 年来不断改正（自己总结，吸取同行的方法）后的流程吧。需求评审（有开发人员，产品经理，测试人员， 项目经理） -> 需求确定（出一份确定的需求文档） -> 开发设计文档（开发人员在开始写代码前就能输出 设计文档） -> 想好测试策略，写出测试用例 -> 发给开发人员和测试经理看看（非正式的评审用例） -> 接到测试版本 -> 执行测试用例（中间可能会补充用例） -> 提交 bug（有些 bug 需要开发人员的确定（严重级别的，或突然发现的在测试用例范围之外的，难以重现的），有些可以直接录制进 TD） -> 开发人员修改（可以在测试过程中快速的修改） -> 回归测试（可能又会发现新问题，再按流程开始跑）。

137. 当开发人员说不是 BUG 时，你如何应付？

开发人员说不是 bug，有 2 种情况，一是需求没有确定，所以我可以这么做，这个时候可以找来产品经理进行确认，需不需要改动，3 方商量确定好后再看要不要改。二是这种情况不可能发生，所以不需要修改，这个时候，我可以先尽可能的说出是 BUG 的依据是什么？如果被用户发现或出了问题，会有什么不良结果？程序员可能会给你很多理由，你可以对他的解释进行反驳。如果还是不行，那我可 以给这个问题提出来，跟开发经理和测试经理进行确认，如果要修改就改，如果不要修改就不改。其实有些 真的不是 bug，我也只是建议的方式写进 TD 中，如果开发人员不修改也没有大问题。如果确定是 bug 的话，一定要坚持自己的立场，让问题得到最后的确认。

138. 测试总结报告包括那些项

测试用例的通过数，测试用例的未通过数，以及测试用例的通过率，未通过的功能都集中在哪几个功能模块，根据测试经验以及测试结果进行一个缺陷的分析和建议。

139. 测试工作进行到一半是，发现时间不够，你如何处理

1. 与客户沟通本次发布的版本什么是最重要的，什么是其次，我会安排一个优先级来对整体测 试功能进行一个筛选。
2. 我会和测试组原体人员一起加班

140. 开发与测试的关系

开发和测试是一个整体，也可以说测试驱动着开发，开发配合着测试，相辅相成的，在一个完整的项目组中缺一不可。

141. 如果你是测试组长你如何对项目及组员进行管理

首先要从需求开始，充分了解被测系统的功能以及业务需求，并在遇到问题的时候及时有效的与 开发人员以及其他项目相关人员进行沟通，做到最被测系统的十分熟悉。并了解整个测试组的成员他 们的测试技能以及擅长的工作，做到测试任务的合理分配，得以让测试工作快速，稳定高效的进行！

142. 缺陷报告严重级别的划分

严重级别的错误：影响系统整体基本流程运行的错误，由于某一操作造成系统死循环或服务器崩溃的错误

较严重：功能实现错误、内部计算错误

一般：UI 错误，一些易用性的错误或建议

143. 开发人员修复缺陷后，如何保证不影响其他功能

Bug 的修复以及新功能的添加都有可能对版本造成一些影响，为了避免，在新版本发布以后，首先会对新版本做一个基础的流程测试也叫做冒烟测试，如果测试基本流程都顺利通过没有任何问题，那么测试人员可以继续进行详细的测试，否则就将冒烟测试中出现的问题以及问题有可能出现的原因反馈给开发人员，由开发人员修正后再次发版，进行测试。这是一个迭代的过程。

144. 发现问题后你是如何判断其是否是 BUG，你是如何提交的、

测试用例是经过评审组严格的评审，完全按照客户的需求规格说明书作为最终依据来评审的，如 果测试过程中，测试结果与实际结果不符就很可能是 Bug，如果一些比较明显的问题就直接录入缺陷管理系统，如果是一些边界问题不容易确定的，可以通过和开发人员甚至是设计人员等进行沟通最后得 出一个结果究竟是否是 Bug，如果是 Bug 就录入，如果是一个需要增加的新功能等，可以录入缺陷管理系统，类型为新需求。

145. 修复一个 BUG 而导致其他的 BUG 出现，该如何处理

帮助开发人员分析问题锁定原因然后进行新 Bug 的修正。

146. 缺陷处理流程

1. 讲缺陷的详细信息录入缺陷管理系统，并分配给对应的开发人员
2. 如果遇到一些难以再现的缺陷，在开发人员修正过程中配合开发人员进行 Bug 的再现。
3. 开发人员修正 Bug 后，会在缺陷管理系统中将修正后的 Bug 状态更改，通常为 Fixed 状态。
4. 新版本发布后，测试人员会讲 bug 状态已经更改为 Fixed 的 Bug 进行回归测试。如果测试通过，则将该 Bug 关闭，如果仍未通过，则将该 Bug 从 Fixed 更改为 Reopen 状态，继续让开 发人员来修正。并等待下一个新版本发布后的二次回归测试。

147. 缺陷报告包括那些项

编写人、被测系统的版本号、测试环境、预期结果、实际结果、对于实际结果如有必要附上截图、 测试用例数、测试用例通过 数，测试用例的通过率、对缺陷的一个分析汇总。

148. 介绍一下整体项目流程

1. 搭建缺陷管理的环境和测试环境以及配置管理的环境搭建；
2. 编写测试计划；
3. 设计测试用例；
4. 编写测试用例；
5. 测试用例的评审；
6. 执行测试；
7. 缺陷管理；
8. 测试报告的输出

149. 在实际项目中你是如何做测试计划

1. 对客户提供的或需求分析人员编写的用户需求文档或需求规格说明书进行分析，提炼出测试要点；
2. 根据测试要点编写测试用例。
3. 由评审组对测试用例进行评审 -- 修改 -- 再次评审 -- 初步定稿
4. 执行测试
5. 按照测试用例对系统进行功能验证及客户的需求验证
6. 将测试过程中产生的 Bug 录入缺陷管理系统
7. 新版本发布后，对本次版本新增加的功能以及开发人员修正的 Bug 进行回归测试
8. 根据项目需要提交测试报告。

150. 你是如何制定测试过程中的时间进度表的

根据项目的需求、开发周期、开发人员的开发进度等时间安排来制定一个测试时间进度初 稿，并

将测试时间进度表交与整个项目团队成员大家一起讨论和分析，最终和所有人达成共识制定出一个大 家都可以执行的测试时间进度表。

时间表中包括了开发人员提交功能或功能模块的时间，以及为了更好的执行测试，配合测试人员 进行功能培训的时间，以及测试执行时间等，都详细的写到 WBS 中，并按照这个时间进度表来执行项目的测试任务。

151. 测试计划都包括那些项

1. 测试计划目标
2. 测试参考文档
3. 测试术语与定义
4. 测试内容
5. 测试人员的分工
6. 测试进度
7. 测试流程
8. 测试工具
9. 测试缺陷管理
10. 测试的风险分析

152. 说说你对软件配置管理的理解

项目在开发的过程中要用相应的配置管理工具对配置项（包括各个阶段的产物）进行变更控制， 配置管理的使用取决于项目规模和复杂性能及风险的水平。软件的规模越大，配置管理就显得越重要。 还有在配置管理中，有一个很重要的概念，那就是基线，是在一定阶段各个配置项的组合，一个基线就提供了一个正式的标准，随后的工作便基于此标准，并且只有经过授权后才能变更这个标准。配置管理工具主要有 CC,VSS,CVS 等，偶只用过 CVS，对其它的不熟悉

153. 根据你的经验说说你对软件测试 / 质量保证的理解？

软件质量保证与测试是根据软件开发阶段的规格说明和程序的内部结构而精心设计的一批测试用 例（即输入数据和预期的输出结果），并利用这些测试用例去运行程序，以发现错误的过程。它是对 应用程序的各个方面进行测试以检查其功能、语言有效性及外观排布。

154. QA 和 QC 的区别是什么？

质量保证（QA）: 是指确保产品符合预定质量要求而作出的所有有组织、有计划活动的总和。

质量控制（QC）：即实验室控制系统，它涉及取样、质量标准、检验、产品批准放行程序等方面 内容。

一般是 QA 为领导地位。

QA：主要是事先的质量保证类活动，以预防为主，期望降低错误的发生几率。

QC：主要是事后的质量检验类活动为主，默认错误是允许的，期望发现并选出错误。

QA 是为满足顾客要求提供信任，即使顾客确信你提供的产品能满足他的要求，因此需从市场调查开始及以后的评审客户要求、产品开发、接单及物料采购、进料检验、生产过程控制及出货、售后服 务等各阶段留下证据，证实工厂每一步活动都是按客户要求进行的。

QC 是为使产品满足质量要求所采取的作业技术和活动，它包括检验、纠正和反馈，比如 QC 进行检验发现不良品后将其剔除，然后将不良信息反馈给相关部门采取改善措施。

用通俗的话来说，QA 比作起草法律的法官，QC 比作警察。

QA 比作产品经理，QC 比作测试人员

155. 软件测试的目的是什么？

软件测试的定义：为了发现程序中的错误而执行程序的过程 测试的目的：

1. 发现程序员在开发中存在的代码以及逻辑错误
2. 审核产品的完成是否符合用户需求
3. 提高用户体验
4. 交付更高质量的产品

156. 如何定义所提交 bug 的严重等级和优先等级的？

Bug 有四种级别，分别为：致命的（Fatal），严重的（Critical），一般的（Major），微小的（Minor）。

• A 类 - 致命的（Fatal）：造成系统或应用程序崩溃、死机、系统挂起，或造成数据丢失，主要功能完全丧失，导致本模块以及 相关模块异常等问题。如代码错误，死循环，数据库发生死锁、与数据库连接错误或数据通讯错误， 未考虑异常操作，功能错误等
• B 类 - 严重错误（critical）：系统的主要功能部分丧失、数据不能保存，系统的次要功能完全丧失。问题局限在本模块，导致模块功能失效或异常退出。如致命的错误声明，程序接口错误，数据库的表、 业务规则、缺省值未加完整性等约束条件
• C 类 - 一般错误（major）：次要功能没有完全实现但不影响使用。如提示信息不太准确，或用户界面差，操作时间长，模块功能部分失效等，打印内容、格式错误，删除操作未给出提示，数据库表中有过多的空字段等
• D 类 - 较小错误（Minor），使操作者不方便或遇到麻烦，但它不影响功能过的操作和执行，如错别字、界面不规范（字体大小不统一，文字排列不整齐，可输入区域和只读区域没有明显的区分标志）， 辅助说明描述不清楚。

常用的缺陷的优先级表示方法可分为：立即解决 P1、高优先级 P2、正常排队 P3、低优先级 P4. 立即解决是指缺陷导致系统几乎不能使用或者测试不能继续，需立即修复；高优先级是指缺陷严重影响 测试，需要优先考虑；正常排队是指缺陷需要正常排队等待修复；而低优先级是指缺陷可以在开发人 员有时间的时候再被纠正。

157. Web 和 APP 测试的异同有哪些？

单纯从功能测试的层面上来讲的话，APP 测试、web 测试 在流程和功能测试上是没有区别的。

根据两者载体不一样，则区别如下：

系统结构方面

• web 项目，b/s 架构，基于浏览器的；web 测试只要更新了服务器端，客户端就会同步会更新。
• app 项，c/s 结构的，必须要有客户端；app 修改了服务端，则客户端用户所有核心版本都需要进行一遍。

性能方面

• web 项目 需监测 响应时间、CPU、Memory
• app 项目 除了监测 响应时间、CPU、Memory 外，还需监测 流量、电量等

兼容方面

• web 项目：

  1. 浏览器（火狐、谷歌、IE 等）
  2. 操作系统（Windows7、Windows10、Linux 等）

• app 项目：

  1. 设备系统：iOS（iPad、iPhone）、Android（三星、华为、联想等） 、Windows（Win7、Win8）、OSX （Mac）
  2. 手机设备可根据 手机型号、分辨率不同

相对于 web 项目，APP 有专项测试

1. 干扰测试：中断，来电，短信，关机，重启等

2. 弱网络测试（模拟 2g、3g、4g，wifi 网络状态以及丢包情况）；网络切换测试（网络断开后重连、3g 切换到 4g/wifi 等）

3. 安装、更新、卸载

   安装：需考虑安装时的中断、弱网、安装后删除安装文件等情况

158. 怎么理解回归测试？是否思考过如何减少回归测试工作量？

回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。

回归测试作为软件生命周期的一个组成部分，在整个软件测试过程中占有很大的工作量比重，自动回归测试将大幅降低系统测试、维护升级等阶段的成本。

159. 一条软件缺陷（或 BUG）包括哪些内容？请完整列出

1. 和 BUG 对应的软件版本
2. 开发的借口人员，测试人员
3. BUG 的优先级
4. BUG 的严重程度
5. BUG 可能属于的模块
6. BUG 的标题
7. BUG 的描述
8. BUG 的截图
9. BUG 的状态
10. BUG 的错误类型（数据，界面。）

160. 软件测试方法有哪些分类？

软件测试方法分类：白盒、黑盒、灰盒；单元测试、集成测试、系统测试、验收测试、回归测试、Alpha 测试、Beta 测试；静态测试和动态测试。

161. 设计测试用例的主要方法有哪些？

设计测试用例的主要方法有：等价类划分；边界值分析法；因果图法；场景法。

162. 单元测试、集成测试、系统测试的侧重点是什么？

单元测试的重点是系统的模块，包括子程序的正确性验证等。集成测试的重点是模块间的衔接以及参数的传递等。

系统测试的重点是整个系统的运行以及与其他软件的兼容性。

163. 怎样才能成为一个优秀的测试工程师

软件测试工程师需要具有一些逆向思维的能力，想别人所不想，测别人所不测，这样才可以找到更多的软件中的错误。这是作为一名优秀的软件测试工程师最基本的素质。善于同软件开发人员沟通沟 通是当今软件项目中需要掌握的最关键技术之一。软件测试人员要善于同软件开发人员沟通，软件测试人员与开发人员搞好关系，使测试人员不成为开发人员的眼中钉，这对于提高整个软件项目质量是十分重要的。沟通主要包括：讨论软件的需求，设计：通过这样的沟通，你可以更好的了解所测试的软件系统，以至于尽可能少的测试出软件中不是错误的“错误”，从而降低给软件开发人员带来的压力。报告好的测试结果：作为一个测试人员，发现错误往往是测试人员最愿意而且引以自豪的结果，但是一味地给开发人员报告软件错误，会给他们造成厌恶感，降低整个软件的质量和开发进度。所以作为一名软件测试工程师，当你测试的模块没有严重的错误或者错误很少的时候，你不妨跑到开发人员那里告诉他们这个好消息，这会给你带来意想不到的结果。

讨论一些与工作无关的事情：作为一个测试人员经常和开发人员讨论一些与工作无关的事情，比如大家可以谈谈新闻，趣事，家庭…这样可以加强相互间的默契程度，许多统计表明，这样可以更好的提高软件工作质量。善于同领导沟通 测试人员往往是领导的眼和耳，领导根据测试人员的测试结果可以了解公司的产品质量，从而调整其他的工作。领导工作一般比较繁忙，所以作为一名优秀的测试人员要学会把测试结果进行总结，最好以图表的形势给领导看。掌握一些自动化测试工具 测试工作往往是比较繁琐，枯燥无味的工作，测试人员长期处于重复的手工工作，会降低测试效率，并且对于测试质量也往往是不利的；况且许多测试不使用测试工具是不可以进行的，比如性能测试，压力测试等等。 目前市场上有许多测试工具供你使用，你可以根据自己的需要选择一些测试工具来辅助你的测试。但是要记住一点，不是说有了测试工具就不要人工测试了，测试工具不是万能的。善于学习的能力 软件测试技术随着时间的变化也在做一些提高和改进，作为一名优秀的测试人员要善于利用书籍，网站， 论坛，交流等各种途径不断提高自己的软件测试水平。提高自己的表达能力 软件测试人员当发现软件中存在缺陷的时候，往往要书写缺陷报告，缺陷报告要写得详尽清楚，使开发人员能够尽快定位错误， 修改错误，所以作为一名优秀的测试人员提高自己的写作能力是非常必要的。了解业务知识 更好的了

解你说测试软件的业务知识是非常重要的，对业务知识了解得越深入，越能够找出更深入，更关键， 更隐蔽的软件错误。所以作为一名优秀的软件测试工程师，要多向该领域专家，同行学习，提高自己 的业务知识水平。

164. 测试计划要安排哪些方面？

1. 引言：目的、背景、范围、定义、参考资
2. 测试内容：测试功能清单
3. 测试规则：进入准则，暂停 / 退出准则、测试方法、测试手段、测试要点、测试工具
4. 测试环境：硬件环境、软件环境、特定测试环境要求
5. 项目任务：测试规划，测试设计，测试执行准备，测试执行，测试总结
6. 实施计划：工作量估计、人员需求及安排、进度安排、其它资源需求及安排。
7. 风险管理

165. 为什么要有测试报告？一份日常的测试报告通常需要说明哪些内容？

1. 概述，包括本次测试的目的，测试的背景介绍；
2. 测试环境，包括测试软硬件环境及配置，以及测试环境的网络拓扑图；
3. 测试的一些参考资料；
4. 测试参与人员，以及投入的时间情况说明；
5. 测试的进度情况，包括计划进度和实际进度；
6. 测试情况介绍，包括测试的内容项说明。如功能测试具体的测试项，测试通过情况；性能测试的测 试项，测试通过情况等；
7. 缺陷的统计和分析，包括迭代次数，缺陷的分布情况，缺陷的覆盖情况，缺陷的发展趋势等；
8. 本次测试的结论；
9. 测试人员就本次测试的一些建议。

166. 在您参与或负责的项目测试中，发生过哪些棘手的问题，最后是如何解决的？您在这个过程中做了什么？

例子：迭代开发后期，开始对整个系统从头回归一遍，这时候又发现了许多以前从未出现的 BUG。这个时期大家都很烦躁困惑，曾经运转良好的页面，突然出现存储问题；曾经更新正常的功能，突然无法更新；曾经显示正常的 Excel，突然显示错误… …这些都让人苦恼，当然，这些应该都是正常现象。测试人员在测试后期尤其需要提高警惕，不能漏过任何一个功能点，更不能忽略任何一次貌似无用的查询、翻页、按键。

最后，是大家一起进行的交付测试，人员包括了所有的编程人员及测试人员。这期间，除了对基 本功能的回归测试外，还包括了并发测试及性能测试（这主要是编程人员在做），除此之外，我将过 去提交修正过的所有 BUG 重新验证了一遍。在并发测试中，我们发现了很多之前单人测试难以发现的并发问题（包括多人一起提交，一起选择，一起修改等等），并发问题可以说层出不穷，甚至包括了 同一台电脑打开两个页面分别进行修改的问题（由于我从一开始就是打开两个页面来测，一个为用户 本人，一个为该用户代理人 delegator，所以有些问题在早期已经暴露），这是测试中的一个重点，也是比较严重的漏洞，需要在以后多加留意。

167. 在测试工作中，您常使用的测试方法有哪些？它们都是在什么场景下使用的？

1. 等价类划分

   划分等价类：等价类是指某个输入域的子集合。在该子集合中，各个输入数据对于揭露程序中的错误都是等效的。并合理地假定：测试某等价类的代表值就等于对这一类其它值的测试。因此，可以把全部输入 数据合理划分为若干等价类，在每一个等价类中取一个数据作为测试的输入条件，就可以用少量代表性 的测试数据。取得较好的测试结果。等价类划分可有两种不同的情况：有效等价类和无效等价类。

2. 边界值分析法

   边界值分析方法是对等价类划分方法的补充。测试工作经验告诉我，大量的错误是发生在输入或输 出范围的边界上，而不是发生在输入输出范围的内部。因此针对各种边界情况设计测试用例，可以查出更多的错误。

   使用边界值分析方法设计测试用例，首先应确定边界情况。通常输入和输出等价类的边界，就是应着 重测试的边界情况。应当选取正好等于，刚刚大于或刚刚小于边界的值作为测试数据，而不是选取等价类 中的典型值或任意值作为测试数据。

3. 错误推测法

   基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性的设计测试用例的方法。

   错误推测方法的基本思想：列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据他们选择测试用例。例如，在单元测试时曾列出的许多在模块中常见的错误。以前产品测试中曾经发现的错误等，这些就是经验的总结。还有，输入数据和输出数据为 0 的情况。输入表格为空格或输入表格只有一行。这些都是容易发生错误的情况。可选择这些情况下的例子作为测试用例。

4. 因果图方法

   前面介绍的等价类划分方法和边界值分析方法，都是着重考虑输入条件，但未考虑输入条件之间的 联系，相互组合等。考虑输入条件之间的相互组合，可能会产生一些新的情况。但要检查输入条件的组合不是一件容易的事情，即使把所有输入条件划分成等价类，他们之间的组合情况也相当多。因此必须考虑采用一种适合于描述对于多种条件的组合，相应产生多个动作的形式来考虑设计测试用例。这就需要利用因果图（逻辑模型）. 因果图方法最终生成的就是判定表。它适合于检查程序输入条件的各种组合情况。

168. 什么是测试用例，设计测试用例时，您常用的设计方法有哪些？应如何设计才能保证测试用例的覆盖率？

测试用例就是测试人员用以测试被测软件的某个特性或特性组合的一组数据。这组数据可能是从 用户处得来的实际的一组数据，也可能是测试人员专门设计出来的测试软件某些功能的一组数据。

等价类划分法、边界值分析法、错误推测法、判定表法、正交实验法。

要保证测试用例能够全面覆盖测试需求，要包含所有的情况。测试用例设计上划分为单功能测试用例和测试场景设计，单功能测试覆盖的需求中的功能点，测试场景覆盖需求中的业务逻辑。 在设计测试用例的时候，可以使用多种测试用例设计方法。

1. 首先进行等价类划分，包括输入条件和输出条件的等价类划分，合理设置有效等价类和无效等价类，这是减少工作量和提高测试效率最有效的方法。
2. 必须使用边界值分析，经验表明，这种方法设计出的用例能发现很多程序错误。
3. 可以使用错误推测法追加一些测试用例，这需要依靠您的智慧和经验。
4. 对照程序逻辑检查已设计出的测试用例的逻辑覆盖度，如果没有达到覆盖标准应当再补充足够的测 试用例。
5. 如果程序的功能说明中含有输入条件的组合情况，一开始就可选因果图和判定表驱动法。
6. 对于参数配置类的软件，要用正交试验法选择较少的组合方式达到最佳效果。
7. 对于业务流清晰的系统，可以利用场景法贯穿整个测试方案过程，在案例中综合使用各种测试方法。 当测试用例设计完成后，要组织测试用例的评审，这样可以吸取别人的意见，减少遗漏，补全测试用例。

169. 黑盒测试主要是为了发现那几类错误？

1. 基于规格说明的功能错误
2. 基于规格说明的构件或系统行为错误
3. 基于规格说明的性能错误
4. 面向用户的使用错误
5. 黑盒接口错误

170. 测试工作的流程？缺陷状态有什么？设计测试用例有几种方法？

测试工程师的实际工作流程（以 P2P 中型版本为例，一个月一个版本）：

1. 产品经理或者 SR 把需求书发下来给开发和测试
2. 测试先看一遍，进行需求分析。测试组长编写测试计划，并且分配测试任务给测试人员（2 天时间）（此时开发也在进行需求分析）
3. 过了 2 天，产品经理再把测试和开发召集在一起，进行需求讲解（或者说需求评审），有问题可以直接问，如果发现需求有问题，也可以提出来，SR 回去会修改。（需求讲解时间 0.5 天）
4. 讲完需求后，测试同事要进行测试场景的梳理和案例的编写了（XMind 和 Excel 就要用上了），一共
5. 个工作日。（此时开发在编写代码）
6. 之后就要进行案例评审了，评审时候有 SR、测试同事、开发同事，评审时候一般 SR、测试组长、对应模块的开发同事会提出一点意见，评审完之后，回去修改、补充一下案例。（案例评审 0.5 天）
7. 修改完以后，有两种处理情况：
   • 对大项目有时候要进行案例的第二次评审。
   • 对小项目，在时间紧的时候，一般不会二审，但是要以邮件的形式把修改或者新增后的案例发 出来，给领导看，并抄送给其他同事。（案例评审 0.5 天，修改案例 0.5 天，案例二审 0.5 天）
8. 案例评审完就要开始测试了，一般测试环境开发搭建好（要说自己也会搭建，搭建流程背老师总结 的）：
   • 中型版本的测试一般分 2 轮：第一轮：5 天；第二轮：3 天；回归测试 2 天；（共 10 个工作日）。
9. 回归测试完后，达到了上线标准，就会如期上线，一般当天晚上 12 点上线