测试面试题

测试面试题(总9页)

-本页仅作为预览文档封面，使用时请删除本页-

1、什么是兼容性测试？兼容性测试侧重哪些方面

参： 参： 兼容测试主要是检查软件在不同的硬件平台、软件平台上是否可以正常的运行，即是通常说的软件的可移植性。 兼容的类型，如果细分的话，有平台的兼容，网络兼容，数据库兼容 以及数据格式的兼容。 兼容的类型，如果细分的话，有平台的兼容，网络兼容，数据库兼容，以及数据格式的兼容。 兼容测试的重点是，对兼容环境的分析。通常，是在运行软件的环境不是很确定的情况下， 兼容测试的重点是 ，对兼容环境的分析 。通常， 是在运行软件的环境不是很确定的情况下， 才需要做兼 根据软件运行的需要，或者根据需求文档，一般都能够得出用户会在什么环境下使用该软件。兼容和配置测试的区别在于，做配置测试通常不是 Clean OS 下做测试，而兼容测试多是在 Clean OS 的环 境下做的。

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

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

3、测试的策略有哪些？ 参： 黑盒/白盒，静态/动态，手工/自动，冒烟测试，回归测试，公测（ 测试的策略） 4、正交表测试用例设计方法的特点是什么

参： 用最少的实验覆盖最多的操作 测试用例设计很少，效率高，但是很复杂； 对于基本的验证功能，以及二次集成引起的缺陷，一般都能找出来；但是更深的缺陷，更复杂的缺陷， 还 是为力的；具体的环境下，正交表一般都很难做的。大多数，只在系统测试的时候使用此方法。

5、描述使用 bugzilla 缺陷管理工具对软件缺陷（BUG）跟踪的管理的流程 参： 就是 Bugzilla 的状态转换图。

6、你觉得 bugzilla 在使用的过程中，有什么问题 参：界面不稳定； 根据需要配置它的不同的部分，过程很烦琐。流程控制上，安全性不好界定， 进行误操作； 没有综合的评分指标，不好确认修复的优先级别。

7、描述测试用例设计的完整过程？参： 需求分析 + 需求变更的维护工作； 根据需求 得出测试需求； 设计测试方案，评审测试方案； 方案评审通过后，设计测试用例，再对测试用例进行评审；

8、单元测试的策略有哪些？ 参： 逻辑覆盖、循环覆盖、同行评审、桌前检查、代码走查、代码评审 9、LoadRunner 分哪三部分

参： 用户动作设计； 场景设计； 测试数据分析；

10、LoadRunner 进行测试的流程 参： 1、 测试测试 2、 创建虚拟用户脚本 3、 创建运行场景 4、 运行测试脚本 5、 监视场景 6、 分析测试的结果 以上，最好是结合一个案例，根据以上流程来介绍。在 lordrunner 中，如何进行并发的测试集合点失败了会怎么样 参： 在同一时间点，支持多个不同的操作。 伪装，集合点，配合虚拟用户的设计，以及在多台电脑上设置，

LoadRunner 中提供 IP 伪装，可以比较好的模拟 真实的并发。集合点失败， 集

2

合点，即是多个用户在某个时刻，某个特定的环境下同时进行虚拟用户的操作的。集合点失败，则集合 点的才操作就会取消 测试就不能进行。

12、使用 QTP 做功能测试，录制脚本的时候，要验证多个用户的登录情况/查询情况，如何操作 参： 分析用户登录的基本情况，得出一组数据，通过性测试/失败性测试的都有（根据 TC 来设计这些数据） ， 然后录制登录的脚本，将关键的数据参数化，修改脚本，对代码进行加强，调试脚本。

13、QTP 中的 Action 有什么作用有几种 、参： Action 的作用 用 Action 可以对步骤集进行分组 6 步骤重组，然后被整体调用 拥有自己的 sheet 组合有相同需求的步骤，整体操作 具有的对象仓库 具有的对象仓库 Action 的种类 可复用 Action 不可复用

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

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

参：：Compatibility Testing（兼容性测试） 也称 （兼容性测试） 也称“Configuration testing（配置测试）”，测试软件是 ， （配置测试） ， 否和系统的其它与之交互的元素之间兼容， 浏览器、操作系统、硬件等。 否验证测试对象在不同的软件和硬 件 配 置 中 的 运 行 情 况 。 Functional testing (功能测试 ，也称为 behavioral testing（行为测试） 根据产品特征、操作描述和用户方案， 功能测试)， ，根据产品特征 功能测试 （行为测试） 根据产品特征、操作描述和用户方案， ， 测试一个产品的特性和可操作行为以确定它们满足设计需求。本地化软件的功能测试，用于验证应用程序或网 站对目标用户能正确工作。使用适当的平台、浏览器和测试脚本，以保证目标用户的体验将足够好，就像应用 程 序 是 专 门 为 该 市 场 开 发 的 一 样 。 Performance testing（性能测试）评价一个产品或组件与性能需求是否符合的测试。包括负载测试、 ， 数据库容量测试、基准测试等类型。

17、Beta 测试与 Alpha 测试有什么区别

参：Beta testing(β 测试 测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。 开 发 者 通 常 不 在 测 试 现 场 Alpha testing (α 测试 是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作 测试),是由一个用户在开发环境下进行的测试 是由一个用户在开发环境下进行的测试， 环境下进行的受控测试

3

18、软件的评审一般由哪些人参加其目的是什么 参：人员：用户、客户或有关部门开发人员，测试人员，需求分析师都可以，就看处于评审那个阶段 人员：

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

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

20、阶段评审与项目评审有什么区别 、阶段评审与项目评审有什么区别 参： 阶段评审 对项目各阶段评审：对阶段成果和工作 项目评审 对项目总体评审：对工作和产品

21、阐述工作版本的定义？参： 构造号： 构造号： BUILD

22、什么是桩模块什么是驱动模块 参： 桩模块：被测模块调用模块 驱动模块 调用被测模块

23、什么是扇入？什么是扇出 参： 扇入：被调次数，扇出：调其它模块数目

24、你认为做好测试计划工作的关键是什么 参： 软件测试计划就是在软件测试工作正式实施之前明确测试的对象， 并且通过对资源、时间、 风险、 围和预算等方面的综合分析和规划，保证有效的实施软件测试；做好测试计划工作的关键 ：目的，管理，规范 1. 明 确 测 试 的 目 标 ， 增 强 测 试 计 划 的 实 用 性 编写软件测试计划得重要目的就是使测试过程能够发现更多的软件缺陷，因此软件测试计划的价值取决于 它对帮助管理测试项目，并且找出软件潜在的缺陷。因此，软件测试计划中的测试范围必须高度覆盖，测试方法必须切实可行，测试工具并且具有较高的实用性，便于使用，生成的测试结果直观、准确 2 “5W” ． 坚 持 规 则 ， 明 确 内 容 与 过 程 “5W”规则指的是 规则指的是“What（做什么）”、“Why（为什么做）”、“When（何时做）”、“Where（在哪里）”、 规则指的是利用“5W”规则创建软件测试计划，可以帮助测试团队理解测试的目的（Why）测试的范围和内容给 测试的范围和内容（What） 确定测试的开始和结束日期（When） 指出测试的方法和工具（How） 给 ） 确定测试的开始和结束日期（ ， ） 指出测试的方法和工具（ ， ） ， Where 出 测 试 文 档 和 软 件 的 存 放 位 置 （ ） 。 3 ． 采 用 评 审 和 更 新 机 制 ， 保 证 测 试 计 划 满 足 实 际 需 求 测试计划写作完成后，如果没有经过评审，直接发送给测试团队， 测试计划写作完成后，如果没有经过评审，直接发送给测试团队，测试计划内容的可能不准确或遗漏测试 内容，或者软件需求变更引起测试范围的增减， 测试计划的内容没有及时更新，误导测试执行人员。4. 分 别 创 建 测 试 计 划 与 测 试 详 细 规 格 、 测 试 用 例 应把详细的测试技术指标包含到创建的测试详细规格文档， 测试技术指标包含到创建的测试详细规格文档 用例放到创建的测试用例文档或测试用例管理数据库 数据库中 测试计划和测试详细规格、 用例放到创建的测试用例文档或测试用例管理数据库中。。 25、你认为做好测试用例工作的关键是什么 参： 需求和设计文档的理解程度， 需求和设计文档的理解程度，对系统的熟悉程度 26、简述一下缺陷的生命周期？

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

4

27、软件的安全性应从哪几个方面去测试？参： 用户认证机制：如数据证书、智能卡、双重认证、 (1) 用户认证机制：如数据证书、智能卡、双重认证、安全电子交易协议 (2) 加密机制 安全防护策略：如安全日志、入侵检测、隔离防护、 (3) 安全防护策略：如安全日志、入侵检测、隔离防护、漏洞扫描 (4) 数据备份与恢复手段：存储设备、存储优化、存储保护、存储管理 (5) 防病毒系统

28、软件配置管理工作开展的情况和认识？ 参： 软件配置管理贯穿于软件开发、测试活动的始终，覆盖了开发、测试活动的各个环节，它的重要作用 之一就是要全面的管理保存各个配置项，监控各配置项的状态，并向项目经理及相关的人员报告，从而实 现对软件过程的控制。软件测试配置管理包括 4 个最基本的活动： 配置项标识 配置项控制 配置项状态报告 配置审计 软件配置管理通常借助工具来辅助， SourceSafe、 软件配置管理通常借助工具来辅助，主要有 MS SourceSafe、Rational ClearCase 等 9

29、你觉得软件测试通过的标准应该是什么样的？参： 缺陷密度值达到客户的要求 缺陷密度值达到客户的要求

30、引入测试管理的含义 参：风险分析，进度控制、角色分配、质量控制

31、一套完整的测试应该由哪些阶段组成

参：测试计划、测试设计与开发、测试实施、测试评审与测试结论 32、单元测试的主要内容？参： 模块接口测试、局部数据结构测试、路径测试、错误处理测试、边界测试

33、集成测试也叫组装测试或者联合测试，请简述集成测试的主要内容 参：（1）在把各个模块连接起来的时候，穿越模块接口的数据是否会丢失； 一个模块的功能是否会对另一个模块的功能产生不利的影响 （2）一个模块的功能是否会对另一个模块的功能产生不利的影响；（3）各个子功能组合起来，能否达到预期要求的父功能； （4）全局数据结构是否有问题； 5）单个模块的误差累积起来，是否会放大，从而达到不能接受的程度。

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

35、软件测试的文档测试应当贯穿于软件生命周期的全过程，其中用户文档是文档测试的重点。那么软件系统 的用户文档包括哪些 包括哪些 的用户文档包括哪些 参： 用户手册 安装和设置指导 联机帮助 指南、 指南、向导 样例、 样例、示例和模板 授权/ 授权/注册登记表 最终用户许可协议

36、软件系统中除用户文档之外，文档测试还应该关注哪些文档 参： 开发文档 软件需求说明书 10 数据库设计说明书 概要设计说明书 详细设计说明书 可行性研究报告 管理文档 项目开发计划 测试计划 测试报告 开发进度月报 开发总结报告

37、简述软件系统中用户文档的测试要点？参： 读者群。文档面向的读者定位要明确。对于初级用户、 （1）读者群。（2）术语。（3）正确性。（4）完整性。（5）一致性。（6）易用性。（7）图表与界面截图。（8）样例与示例。（9）语言。10）印刷与包装。

5

38、单元测试主要内容是什么（1）模块接口测试：（2）局部数据结构测试：（3）边界条件测试： （4）模块中所有路径测试：

39、如何理解强度测试？参：强度测试是为了确定系统在最差工作环境的工作能力,也可能是用于验证在标准工作压力下的各种资 源的最下限指标。它和压力测试的目标是不同的,压力测试是在标准工作环境下,不断增加系统负荷,最终测试出该系统能力 达到的最大负荷(稳定和峰值),而强度测试则是在非标准工作环境下 ) 达到的最大负荷(稳定和峰值),强度测试和压力测试的测试指标相近,大多都是与时间相关的指标,如并发量(吞吐量),延迟(最大\\最 平均) 小\\平均)以及顺序指标等 强度测试需要对系统的结构熟悉, 强度测试需要对系统的结构熟悉,针对系统的特征设计强度测试的方法

40、如何理解压力、负载、性能测试测试 参： 性能测试是一个较大的范围，实际上性能测试本身包含了性能、强度、压力、负载等多方面的测试内，压力测试是对服务器的稳定性以及负载能力等方面的测试，是一种很平常的测试。增大访问系统的用 户数量、或者几个用户进行大数据量操作都是压力测试。负载测试是压力相对较大的测试，主要是测试 系统在一种或者集中极限条件下的相应能力，是性能测试的重要部分。100 个用户对系统进行连续半个小 时的访问可以看作压力测试， 个小时就可以认为负载测试，实际上压力测试和负载测试没有明显的区分。测试人员应该站在关注整体性能的高度上来对系统进行 测试。

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

44、配置和兼容性测试的区别是什么？参： 配置测试的目的是保证软件在其相关的硬件上能够正常运行， 配置测试的目的是保证软件在其相关的硬件上能够正常运行，而兼容性测试主要是测试软件能否与不同的 软件正确协作。配置测试的核心内容就是使用各种硬件来测试软件的运行情况，一般包括： 软件在不同的主机上的运行情况 机上的运行情况（1）软件在不同的主机上的运行情况，例如 Dell 和 Apple； （2）软件在不同的组件上的运行情况，例如开发的拨号程序要测试在不同厂商生产的 Modem 上的运行情 况；（3）不同的外设； 不同的接口； （4）不同的接口； （5）不同的可选项，例如不同的内存大小； 兼容性测试的核心内容： 兼容性测试的核心内容： 测试软件是否能在不同的操作系统平台上兼容； （1）测试软件是否能在不同的操作系统平台上兼容； （2）测试软件是否能在同一操作系统平台的不同版本上兼容；（3）软件本身能否向前或者向后兼容； （4）测试软件能否与其它相关的软件兼容；（5）数据兼容性测试，主要是指数据能否共享； 14 配置和兼容性测试通称对开发系统类软件比较重要，例如驱动程序、操作系统、数据库管理系统等。 46、没有产品说明书和需求文档地情况下能够进行黑盒测试吗？参： 这个问题是国内测试工程师经常遇到的问题，根源就是国内软件开发文档管理不规范，对变更的管理 方法就更不合理了。实际上没有任何文档的时候，测试人员是能够进行黑盒测试的，这种测试方式我们可 以称之为探索测试，具体做法就是测试工程师根据自己的专业技能、 以称之为探索测试 ，具体做法就是测试工程师根据自己的专业技能 、 领域知识等不断的深入了解测试对 理解软件功

6

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

47、测试中的“杀虫剂怪事”是指什么？参： “杀虫剂怪事”一词由

BorisBeizer 在其编着的《软件测试技术》第二版中提出。用于描述测试人员 对同一测试对象进行的测试次数越多，发现的缺陷就会越来越少的现象。

49、为什么尽量不要让时间有富裕的员工去做一些测试 参：表面上看这体现了管理的效率和灵活性，但实际上也体现了管理者对测试的轻视。测试和测试的人有 很大关系。测试工作人员应该是勤奋并富有耐心，善于学习、思考和发现问题，细心有条理，总结问题， 如果具备这样的优点，做其它工作同样也会很出色，因此这里还有一个要求，就是要喜欢测试这项工作。如果他是专职的，那么肯定更有经验和信心。 50、完全测试程序是可能的吗？

参： 软件测试初学者可能认为拿到软件后需要进行完全测试，找到全部的软件缺陷，使软件“零缺陷”发 实际上完全测试是不可能的。。 51、软件测试的风险主要体现在哪里？

参： 我们没有对软件进行完全测试，实际就是选择了风险，因为缺陷极有可能存在没有进行测试的部分。

53、所有的软件缺陷都能修复吗所有的软件缺陷都要修复吗

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

、软件测试人员就是 QA 吗？

参： 软件测试人员的职责是尽可能早的找出软件缺陷，确保得以修复。而质量保证人员（QA）主要职责是 创建或者制定标准和方法，提高促进软件开发能力和减少软件缺陷。测试人员的主要工作是测试， 创建或者制定标准和方法，提高促进软件开发能力和减少软件缺陷。测试人员的主要工作是测试，质量保 证人员日常工作重要内容是检查与评审，测试工作也是测试保证人员的工作对象。软件测试和质量是相辅相成的关系，都是为了提高软件质量而工作。 55、如何减少测试人员跳槽带来的损失？

参因此我们要想留住员工，管理者就应该把员工的个人成长和企业的发展联系起来，为员工设定合理 发展规划并付诸实现。不过这项要求做起来比较，要有比较好的企业文化为依托。 发展规划并付诸实现。不过这项要求做起来比较，要有比较好的企业文化为依托。 56、测试产品与测试项目的区别是什么

56、测试产品与测试项目的区别是什么？

参： 习惯上把开发完成后进行商业化、几乎不进行代码修改就可以售给用户使用的软件成为软件产品，也 就是可以买“卖拷贝”的软件，

Windows2000。 就是可以买“卖拷贝”的软件，例如 Windows2000。而通常把针对一个或者几个特定的用户而开发的软件 成为软件项目，软件项目是一种个性化的产品，可以是按照用户要求全部重新开发， 成为软件项目，软件项目是一

7

种个性化的产品，可以是按照用户要求全部重新开发，也可以修改已有的软 件产品来满足特定的用户需求。。 项目最后要和用户共同验收测试，这是产品测试不具有的特点。此外，测试产品与测试项目在缺陷管理方面、测试策略制定都会有很大不同，测试管理者应该结合具 17 体的环境，恰如其分的完成工作。 体的环境，恰如其分的完成工作。

57、和用户共同测试（ 测试）的注意点有哪些

参：， （1）用户现场测试不可能测试全部功能，因此要测试核心功能。这需要提前做好准备，这些核心功 能一定要预先经过测试，证明没有问题才可以和用户共同进行测试。（2）如果某些模块确实有问题，我们可以演示其它重要的业务功能模块，必要时要向用户做成合理的解 争得时间后，及时修改缺陷来弥补。3）永远不能欺骗用户，蒙混过关。 58、如何编写提交给用户的测试报告？

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

参：国测试工具在测试工作中起的是辅助作用，一般用来提高测试效率。 试 。自动化测试弥补了手工测试的不 减轻一定的工作量。实际上测试工具是无法替代大多数手工测试的，而一些诸如性能测试等自动化测也是手工所不能完成的。 对于自动测试技术，应当依据软件的不同情况来分别对待， 对于自动测试技术，应当依据软件的不同情况来分别对待，一般自动技术会应用在引起大量重复性工 作的地方、系统的压力点、以及任何适合使用程序解决大批量输入数据的地方。 作的地方、系统的压力点、以及任何适合使用程序解决大批量输入数据的地方。然后再寻找合适的自动测 试工具，或者自己开发测试程序。一定不要为了使用测试工具而使用。 试工具，或者自己开发测试程序。一定不要为了使用测试工具而使用。 。

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

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

69、您认为做好测试用例设计工作的关键是什么 、

参： 白盒测试用例设计的关键是以较少的用例覆盖尽可能多的内部程序逻辑结果 黑盒法用例设计的关键同样也是以较少的用例覆盖模块输出和输入接口。70、、请试着比较一下黑盒测试、白盒测试、单元测试、集成测试、系统测试、验收测试的区别与联系。 参： 黑盒测试：已知产品的功能设计规格，可以进行测试证明每个实现了的功能是否符合要求。白盒测试：已知产品的内部工作过程，可以通过测试证明每种内部操作是否符合设计规格要求，所有内部 成 分 是 否 以 经 过 检 查 。软件的黑盒测试意味着测试要在软件的接口处进行。这种方法是把测试对象看做一个黑盒子，测试人员完 全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，查程序的功能是否

8

符合它的功能 说明。因此黑盒测试又叫功能测试或数据驱动测试。软件的白盒测试是对软件的过程性细节做细致的检查。这种方法是把测试对象看做一个打开的盒子，它允 许测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。 许测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。通过 在不同点检查程序状态，确定实际状态是否与预期的状态一致。 在不同点检查程序状态 ，确定实际状态是否与预期的状态一致。 因此白盒测试又称为结构测试或逻辑驱动测 试 。 白 盒 测 试 主 要 是 想 对 程 序 模 块 进 行 如 下 检 查 ： 1 、 对 程 序 模 块 的 所 有 独 立 的 执 行 路 径 至 少 测 试 一 遍 。 2、 对 所 有 的逻 辑 判 定 ，取 “ 真” 与 取 “ 假” 的 两种 情 况 都 能至 少 测一 遍 。 3 、 在 循 环 的 边 界 和 运 行 的 界 限 内 执 行 循 环 体 。 4 、 测 试 内 部 数 据 结 构 的 有 效 性 ， 等 等 。 单元测试（模块测试）是开发者编写的一小段代码，用于检验被测代码的一个很小的、 单元测试（模块测试）是开发者编写的一小段代码，用于检验被测代码的一个很小的、很明确的功能是否 正确。通常而言，一个单元测试是用于判断某个特定条件（或者场景）下某个特定函数的行为。 单元测试是由程序员自己来完成，最终受益的也是程序员自己。可以这么说， 单元测试是由程序员自己来完成， 最终受益的也是程序员自己。 可以这么说 ，程序员有责任编写功能代 同时也就有责任为自己的代码编写单元测试。执行单元测试， 码，同时也就有责任为自己的代码编写单元测试。执行单元测试，就是为了证明这段代码的行为和我们期望的 21 一 致 。 集成测试（也叫组装测试，联合测试）是单元测试的逻辑扩展。 的最简单的形式是： 集成测试（也叫组装测试，联合测试）是单元测试的逻辑扩展。它的最简单的形式是：两个已经测试过的 单元组合成一个组件，并且测试它们之间的接口。从这一层意义上讲，组件是指多个单元的集成聚合。 单元组合成一个组件，并且测试它们之间的接口。从这一层意义上讲，组件是指多个单元的集成聚合。在现实 方案中，许多单元组合成组件，而这些组件又聚合成程序的更大部分。方法是测试片段的组合， 方案中，许多单元组合成组件，而这些组件又聚合成程序的更大部分。方法是测试片段的组合，并最终扩展进 程，将您的模块与其他组的模块一起测试。最后，将构成进程的所有模块一起测试。 系统测试是将经过测试的子系统装配成一个完整系统来测试。 系统测试是将经过测试的子系统装配成一个完整系统来测试。它是检验系统是否确实能提供系统方案说明 书 中 指 定 功 能 的 有 效 方 法 。 （ 常 见 的 联 调 测 试 ） 系统测试的目的是对最终软件系统进行全面的测试，确保最终软件系统满足产品需求并且遵循系统设计。 系统测试的目的是对最终软件系统进行全面的测试，确保最终软件系统满足产品需求并且遵循系统设计。 验收测试是部署软件之前的最后一个测试操作。验收测试的目的是确保软件准备就绪， 验收测试是部署软件之前的最后一个测试操作。验收测试的目的是确保软件准备就绪，并且可以让最终用 户 将 其 用 于 执 行 软 件 的 既 定 功 能 和 任 务 。 验收测试是向未来的用户表明系统能够像预定要求那样工作。经集成测试后， 验收测试是向未来的用户表明系统能够像预定要求那样工作。经集成测试后，已经按照设计把所有的模块组装 成一个完整的软件系统，接口错误也已经基本排除了，接着就应该进一步验证软件的有效性， 成一个完整的软件系统，接口错误也已经基本排除了，接着就应该进一步验证软件的有效性，这就是验收测试 的任务，即软件的功能和性能如同用户所合理期待的那样。 的任务，即软件的功能和性能如同用户所合理期待的那样。

9

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

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

73、请以您以往的实际工作为例，详细的描述一次测试用例设计的完整的过程。 、请以您以往的实际工作为例，详细的描述一次测试用例设计的完整的过程。 设计的完整的过程 参：

参： 首先：得到相关文档（需求文档和设计文档） 理解需求和设计设计思想后，想好测试策略， 考 虑 到 测 试 环 境 ， 测 试 用 例 ， 测 试 时 间 等 问 题 。 第二步：设计测试用例，测试策略是：把网站部分的功能点测试完，然后在进行系统测试四步：执行测试

75、你对测试最大的兴趣在哪里为什么 、你对测试最大的兴趣在哪里为什么 参： 最大的兴趣就是测试有难度，有挑战性！做测试越久越能感觉到做好测试有多难。

76、你以前工作时的测试流程是什么 参： 灵活回答）公司对测试流程没有规定如何做，但每个测试人员都有自己的一套测试流程。我说下我 1 年来不断改正 自己总结，吸取同行的方法）后的流程吧。需求评审－ 需求确定－ 开发设计文档－>－ 想好测 试策略，写出测试用例－－ 接到测试版本－－>执行测试 中间可能会补充用例）－ ）－>－ 提交 bug－>开发人员修改－>回归测试。

77、当开发人员说不是 BUG 时，你如何应付 、 你如何应付

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

10