【文章末尾给大家留下了大量的福利】

十、面试总结

1. 你的优势在哪里？我为什么要录用你？

我也许不是最优秀的人，但我认为我很适合这一岗位。我以往的工作经历都与之息息相关，在这一领域不断发展也是我的目标。我相信我的专业水平和工作能力能够在这个岗位上为公司道的业绩和发展做出贡献。我到这个公司来面试也是看到了公司的发展前景，而我相信自己可以给公司带来更多地利益。比方说公司需要的接口测试我也是比较有经验的，而自动化测试方面我觉得做个初级的项目应该是没问题的，如果公司需要， 我是有能力去进修完善自动化知识，然后把这些知识运用到项目上来，以上是我总结的

个人优势。

1. 你如果进来公司了，重心放在哪里？

我个人认为重心是技术方面，比方说接口和自动化这方面，如果公司有要求，业务还有管理方面我也会尽我最大的努力去做好。

1. 你们是怎么写用例的？

首先对需求进行分析，提取测试点，熟悉项目流程。然后，根据测试点来编写测试用例， 测试用例要考虑到功能、用户体验、性能、兼容性和一些异常的场景。我们一个测试用例包含：用例编号、测试项目、测试标题、重要级别、预置条件、测试输入、测试步骤、     预期结果这些要素，编写完后还要进行用例的评审。

1. 你会数据库吗？

数据库我们主要用的是增删改查，比如：我们在前台下做了充值操作，除了在用户中心和系统后台查看这笔金额是否正确，我们也会到数据库中查询该记录的数据是否正确。

1. 为登录设计一个全面的测试用例

功能性用例设计点：

1. 1. 输入已注册的用户名和正确的密码，验证是否成功登录
   2. 输入已注册的用户名和不正确的密码，验证是否登录失败，且提示信息正确
   3. 输入未注册的用户名和任意密码，验证是否登录失败，且提示信息正确
   4. 使用未激活账户登录，验证是否登录失败
   5. 使用被停用用户登录，验证是否登录失败
   6. 用户名和密码两者都为空，验证是否登录失败，且提示信息正确
   7. 用户名和密码两者之一为空，验证是否登录失败，并且提示信息正确
   8. 如果登录功能启用了验证码功能，在用户名和密码正确的情况下，输入正确的验证码，验证是否登录成功
   9. 如果登录功能启用了验证码功能，在用户名和密码正确的情况下，输入错误的验证码，验证是否登录失败，且提示信息正确
   10. 用户名和密码是否大小写敏感
   11. 页面上的密码框是否加密显示、或者是否需要有明暗码切换按钮
   12. 后台系统创建的用户第一次登录成功时，是否提示修改密码
   13. 忘记用户名和忘记密码的功能是否可用
   14. 前端页面是否根据设计需求限制用户名和密码长度
   15. 如果登录功能需要验证码，点击验证码图片或者点击换一张是否可以更换验证码， 更换后的验证码是否可用
   16. 刷新页面是否会刷新验证码
   17. 如果验证码有时效性，需要分别时效性内和时效性外验证码的有效性
   18. 用户登录成功但是会话超时后，继续操作是否会重定向到用户登录界面
   19. 不同级别的用户，比如管理员和普通用户，登录系统后权限是否正确
   20. 页面默认焦点是否定位在用户输入框中
   21. 快捷键 Tab 和 Enter 等，是否可以正常使用
   22. 为空和输入空格字符串的校验是否一致
   23. 使用中文键盘输入字母和使用英文键盘输入字母传入后端的字符长度是否一致

1. 1. 成功登录后的 session 的时效设置
   2. 输入栏是否设置快速删除按钮
   3. 用户名和密码是否支持特殊字符和中文
   4. 浏览器的前进后退按钮，是否有效
   5. 成功登出后，点击浏览器回退按钮，是否可以继续操作系统
   6. 需求中是否有登录时间限制，如果有验证时间限制是否有效
   7. 验证不同登录方式的正确性：扫码、账号密码、第三方……
   8. 若支持手机号+验证码登录，验证码是否有时间限制，移动设备是否可以直接获取验证码
   9. 操作错误提示信息是否简单明了

兼容性测试用例设计点：

1. 不同浏览器下，验证登录页面的显示以及功能正确性
2. 相同浏览器的不同版本下验证登录页面的显示以及功能正确性
3. 不同移动设备终端的不同浏览器下，验证登录页面显示以及功能的正确性
4. 不同分辨率的界面下，验证登录页面的显示以及功能正确性

安全性测试用例设计点：

1. 用户密码后台存储是否加密
2. 用户密码在网络传输过程中是否加密
3. 密码是否具有有效期，密码有效期到期后，是否提示需要修改密码
4. 不登录的情况下，在浏览器中直接输入登录后的 URL 地址,验证是否会重新定向到用户登录界面
5. 密码输入框是否不支持复制粘贴
6. 密码输入框内输入的密码是否都可以在页面源码模式下被查看
7. 用户名和密码输入框分别输入典型的“SQL 注入攻击”字符串，验证系统的返回页面
8. 用户名和密码输入框分别输入典型的“XSS 跨站脚本攻击”字符串，验证系统行为是否被篡改
9. 连续多次登录失败的情况下，系统是否会阻止后续的尝试以应对暴力破解
10. 同一用户在同一终端的多种浏览器上登录，验证登录功能的互斥性是否符合设计预期
11. 同一用户先后在多台终端的浏览器上登录，验证登录是否具有互斥性
12. 是否可以记住密码，记住的密码保存是否加密，记住的密码是否有有效期，过了有效期后是否清空密码
13. 是否支持第三方登录
14. 密码的强弱性，复杂度校验
15. 异地登录校验、更换设备登录校验、登陆信息异常是否考虑账户冻结停用、是否允许第三方平台存储密码
16. 是否可以使用登录的 api 发送登录请求，并绕开验证码校验
17. 是否可以用抓包工具抓到的请求包直接登录
18. 截取到的 token 等信息，是否可以在其他终端上直接使用，绕开登录，token 过期时间校验
19. 登录错误后的提示是否存在安全隐患

性能压力测试的用例设计点：

1. 单用户登录的响应时间是否小于 3 秒
2. 单用户登录时，后台请求数量是否过多
3. 高并发场景下用户登录的响应时间是否小于 5 秒
4. 高并发场景下服务端的监控指标是否符合预期
5. 高集合点并发场景下，是否存在资源死锁和不合理资源等待
6. 长时间大量用户连续登录和登出，服务器是否存在内存泄露
7. 输入内容校验是否加入了函数防抖

1. 你平常会看日志吗, 一般会出现哪些异常

这个主要是面试官考察你会不会看日志，是不是看得懂 java 里面抛出的异常，Exception 一般面试中 java Exception（runtimeException ）是必会被问到的问题

app 崩溃的常见原因应该也是这些了。常见的异常列出四五种，是基本要求。常见的几种如下：

NullPointerException - 空指针引用异常ClassCastException - 类型强制转换异常。IllegalArgumentException - 传递非法参数异常。ArithmeticException - 算术运算异常

ArrayStoreException - 向数组中存放与声明类型不兼容对象异常IndexOutOfBoundsException - 下标越界异常NegativeArraySizeException - 创建一个大小为负数的数组错误异常NumberFormatException - 数字格式异常

SecurityException - 安全异常

UnsupportedOperationException - 不支持的操作异常

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

1. 单元测试的重点是系统的模块，包括子程序的正确性验证等。
2. 集成测试的重点是模块间的衔接以及参数的传递等。
3. 系统测试的重点是整个系统的运行以及与其他软件的兼容性。

1. 白箱测试和黑箱测试是什么?什么是回归测试?

1. 白箱测试：对程序的内部结构与算法进行的测试
2. 黑箱测试：不考虑程序的内部结构，只检查程序是否实现了需求的功能
3. 回归测试：BUG 修正重新测试，关联其他模块测试。

1. 全部回归与部分回归的区别？

1. 全部回归：对软件的新版本测试时，重复执行上一个版本测试时使用的测试用例，防止以前没有的问题现在出问题了
2. 部分回归：当开发修复某个 bug 时，我们需要去检查该 bug 是否被修复，还需要检查与之相关联的模块是否受到影响。

1. 设计用例的方法、依据有那些？

1. 白盒测试用例设计有如下方法：基本路径测试\等价类划分\边界值分析\覆盖测试\循环测试\数据流测试\程序插桩测试\变异测试.这时候依据就是详细设计说明书及其代码结构吧；
2. 黑盒测试用例设计方法：基于用户需求的测试\功能图分析方法\等价类划分方法\边界值分析方法\错误推测方法\因果图方法\判定表驱动分析方法\正交实验设计方法.依据是用户需求规格说明书，详细设计说明书

1. 一个测试工程师应具备那些素质和技能？

1. 掌握基本的测试基础理论
2. 本着找出软件存在的问题的态度进行测试,即客观吧,不要以挑刺形象出现
3. 可熟练阅读需求规格说明书等文档
4. 以用户的观点看待问题
5. 有着强烈的质量意识
6. 细心和责任心
7. 良好的有效的沟通方式（与开发人员及客户）
8. 具有以往的测试经验
9. 能够及时准确地判断出高危险区在何处.

1. 集成测试通常都有那些策略？

大爆炸集成；自顶向下集成；自底向上集成；三明治集成；分层集成；基干集成；基于功能的集成；基于消息的集成；基于风险的集成；基于进度的集成.

1. .一个缺陷测试报告的组成？

缺陷跟踪报告:

1. 编号，如：ut-dt00016
2. 标题，如：文字排版功能.字间距.MarchCalculator 计算错误
3. 版本号，如：V1.3
4. 执行状态，如：空白/草稿/提交/审批/分发/正在修改/修改完毕/正在确认/关闭…
5. 修改记录，如：2003 年 7 月 2 日；肖睿编制/修改；原因
6. 测试环境和版本号码、程序编写人员
7. 错误严重程度和优先级别
8. 错误详细描述
9. 重现步骤和方式、对应的测试记录编码

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

软件测试计划是指导测试过程的纲领性文件，包含了产品概述、测试策略、测试方法、测试区域、测试配置、测试周期、测试资源、测试交流、风险分析等内容。借助软件测

试计划，参与测试的项目成员，尤其是测试管理人员，可以明确测试任务和测试方法， 保持测试实施过程的顺畅沟通，跟踪和控制测试进度，应对测试过程中的各种变更。测试计划和测试详细规格、测试用例之间是战略和战术的关系，测试计划主要从宏观上规划测试活动的范围、方法和资源配置，而测试详细规格、测试用例是完成测试任务的具体战术。所以其中最重要的是测试策略和测试方法（最好是能先评审）

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

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

编写软件测试计划得重要目的就是使测试过程能够发现更多的软件缺陷，因此软件测试计划的价值取决于它对帮助管理测试项目，并且找出软件潜在的缺陷。因此，软件测试

计划中的测试范围必须高度覆盖功能需求，测试方法必须切实可行，测试工具并且具有较高的实用性，便于使用，生成的测试结果直观、准确

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

“5W”规则指的是“What（做什么）”、“Why（为什么做）”、“When（何时做）”、“Where

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

（Where）。

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

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

有及时更新，误导测试执行人员。

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

应把详细的测试技术指标包含到独立创建的测试详细规格文档，把用于指导测试小组执行测试过程的测试用例放到独立创建的测试用例文档或测试用例管理数据库中。测试计

划和测试详细规格、测试用例之间是战略和战术的关系，测试计划主要从宏观上规划测试活动的范围、方法和资源配置，而测试详细规格、测试用例是完成测试任务的具体战术。

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

1. 等价类划分

划分等价类: 等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并合理地假定:测试某等价类的代表值就等于对这一类其它值的

测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作   为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可    有两种不同的情况:有效等价类和无效等价类.

1. 边界值分析法

边界值分析方法是对等价类划分方法的补充。测试工作经验告诉我,大量的错误是发生    在输入或输出范围的边界上,而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例,可以查出更多的错误. 使用边界值分析方法设计测试用例,首先应确定边界情况. 通常输入和输出等价类的边界, 就是应着重测试的边界情况.应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据.

1. 错误推测法

基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法. 错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况, 根据他们选择测试用例. 例如, 在单元测试时曾列出的许多在模块中常见的错误. 以前产品测试中曾经发现的错误等, 这些就是经验的总结. 还有, 输入数据和输出数据为 0 的情况. 输入表格为空格或输入表格只有一行. 这些都是容易发生错误的情况. 可选择

这些情况下的例子作为测试用例.

1. 因果图方法

前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条    件之间的联系, 相互组合等. 考虑输入条件之间的相互组合,可能会产生一些新的情况.

但要检查输入条件的组合不是一件容易的事情, 即使把所有输入条件划分成等价类,他们之间的组合情况也相当多. 因此必须考虑采用一种适合于描述对于多种条件的组合, 相应产生多个动作的形式来考虑设计测试用例. 这就需要利用因果图（逻辑模型）. 因果图方法最终生成的就是判定表. 它适合于检查程序输入条件的各种组合情况.

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

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

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

第二步：设计测试用例，测试策略是：把网站部分的功能点测试完，然后在进行系统测试（另外个模块呢有另一个测试人员负责，可以进行联调测试），网站模块的测试基本

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

第三步：搭建测试环境（为什么这个时候考虑测试环境呢?因为我对网站环境已经很熟了，只有有机器能空于下来做该功能测试就可以做了），因为网站本身的环境搭建和其

他的系统有点不同，它需要的测试环境比较麻烦，需要  web  服务器（Apache,tomcat），不过这次需求呢，网站部分只用到了 tomcat，所以只要有 tomcat 即可

第四步：执行测试

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

测试工作的完整过程。

是的，曾经做过网站方面的性能测试，虽然做的时间并不久（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 ：尝试链接数；

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

最大的兴趣就是测试有难度，有挑战性！做测试越久越能感觉到做好测试有多难。曾经在无忧测试网上看到一篇文章，是关于如何做好一名测试工程师。一共罗列了十一二点， 有部分是和人的性格有关，有部分需要后天的努力。但除了性格有关的 1、2 点我没有

把握，其他点我都很有信心做好它。

刚开始进入测试行业时，对测试的认识是从无忧测试网上了解到的一些资料，当时是冲着做测试需要很多技能才能做的好，虽然入门容易，但做好很难，比开发更难，虽然当

时我很想做开发（学校专业课我基本上不缺席，因为我喜欢我的专业），但看到测试比开发更难更有挑战性，想做好测试的意志就更坚定了。

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

我觉得做测试整个过程中有 2 点让我觉得很有难度（对我来说，有难度的东西我就非常感兴趣），第一是测试用例的设计，因为测试的精华就在测试用例的设计上了，要在版本出来之前，把用例写好，用什么测试方法写?（也就是测试计划或测试策略），如果你 刚测试一个新任务时，你得花一定的时间去消化业务需求和技术基础，业务需求很好理

解（多和产品经理和开发人员沟通就能达到目的），而技术基础可就没那么简单了，这需要你自觉的学习能力，比如说网站吧，最基本的技术知识你要知道网站内部是怎么运作的的，后台是怎么响应用户请求的?测试环境如何搭建?这些都需要最早的学好。至少在开始测试之前能做好基本的准备，可能会遇到什么难题?需求细节是不是没有确定好? 这些问题都能在设计用例的时候发现。

第二是发现 BUG 的时候了，这应该是测试人员最基本的任务了，一般按测试用例开始测试就能发现大部分的 bug，还有一部分 bug 需要测试的过程中更了解所测版本的情

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

1. 你的测试职业发展是什么?

测试经验越多，测试能力越高。所以我的职业发展是需要时间累积的，一步步向着高级测试工程师奔去。而且我也有初步的职业规划，前 3 年累积测试经验，按如何做好测试 工程师的 11，12 点要求自己，不断的更新自己改正自己，做好测试任务。

1. 你自认为测试的优势在哪里

优势在于我对测试坚定不移的信心和热情，虽然经验还不够，但测试需要的基本技能我有信心在工作中得以发挥。

1. 你以前工作时的测试流程是什么?

公司对测试流程没有规定如何做，但每个测试人员都有自己的一套测试流程。我说下我

1 年来不断改正（自己总结，吸取同行的方法）后的流程吧。需求评审（有开发人员， 产品经理，测试人员，项目经理）－>需求确定(出一份确定的需求文档)－>开发设计文档（开发人员在开始写代码前就能输出设计文档）－>想好测试策略，写出测试用例－>    发给开发人员和测试经理看看（非正式的评审用例）－>接到测试版本－>执行测试用例（中间可能会补充用例）－>提交 bug（有些 bug 需要开发人员的确定（严重级别

的，或突然发现的在测试用例范围之外的，难以重现的），有些可以直接录制进 TD）－>

开发人员修改（可以在测试过程中快速的修改）－>回归测试（可能又会发现新问题，      再按流程开始跑）。

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

开发人员说不是 bug，有 2 种情况，一是需求没有确定，所以我可以这么做，这个时候 可以找来产品经理进行确认，需不需要改动，3 方商量确定好后再看要不要改。二是这种情况不可能发生，所以不需要修改，这个时候，我可以先尽可能的说出是 BUG 的依

据是什么?如果被用户发现或出了问题，会有什么不良结果?程序员可能会给你很多理由， 你可以对他的解释进行反驳。如果还是不行，那我可以给这个问题提出来,跟开发经理和测试经理进行确认,如果要修改就改,如果不要修改就不改。其实有些真的不是 bug，我

也只是建议的方式写进 TD 中，如果开发人员不修改也没有大问题。如果确定是 bug

的话，一定要坚持自己的立场，让问题得到最后的确认。

1. 你为什么想离开目前的职务?

因为公司运作情况并不理想，公司需要调整部门体系，公司考虑到缩减部门人员，所以大批量的裁员（有 6，7 个），这是我的第一份工作，对公司也有较深的感情，因为在这里我找到了职业理想（就是测试），所以公司需要精简人员，我自愿退出。虽然很舍不

得，但我将会有新的发挥能力的舞台。

1. 你找工作时，最重要的考虑因素为何?

工作的性质和内容是否能让我发挥所长，并不断成长。

1. 为什么我们应该录取你?

您可以由我过去的工作表现所呈现的客观数据，明显地看出我全力以赴的工作态度。

1. 请谈谈你个人的最大特色。

我的坚持度很高，事情没有做到一个令人满意的结果，绝不罢手。

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

因为没有经过测试的软件很难在发布之前知道该软件的质量，就好比 ISO 质量认证一样，测试同样也需要质量的保证，这个时候就需要在团队中开展软件测试的工作。在测

试的过程发现软件中存在的问题，及时让开发人员得知并修改问题，在即将发布时，从测试报告中得出软件的质量情况。

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

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

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

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

功能测试在测试工作中占的比例最大，功能测试也叫黑盒测试。是把测试对象看作一个黑盒子。利用黑盒测试法进行动态测试时，需要测试软件产品的功能，不需测试软件产

品的内部结构和处理过程。采用黑盒技术设计测试用例的方法有：等价类划分、边界值分析、错误推测、因果图和综合策略。

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

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

界面测试，界面是软件与用户交互的最直接的层，界面的好坏决定用户对软件的第一印象。而且设计良好的界面能够引导用户自己完成相应的操作，起到向导的作用。同时界

面如同人的面孔，具有吸引用户的直接优势。设计合理的界面能给用户带来轻松愉悦的感受和成功的感觉，相反由于界面设计的失败，让用户有挫败感，再实用强大的功能都可能在用户的畏惧与放弃中付诸东流。

区别在于，功能测试关注产品的所有功能上，要考虑到每个细节功能，每个可能存在的功能问题。性能测试主要关注于产品整体的多用户并发下的稳定性和健壮性。界面测试

更关注于用户体验上，用户使用该产品的时候是否易用，是否易懂，是否规范（快捷键之类的），是否美观（能否吸引用户的注意力），是否安全（尽量在前台避免用户无意输入无效的数据，当然考虑到体验性，不能太粗鲁的弹出警告）?做某个性能测试的时候，首先它可能是个功能点，首先要保证它的功能是没问题的，然后再考虑该功能点的性能测试

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

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

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

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

求。

白盒测试：已知产品的内部工作过程，可以通过测试证明每种内部操作是否符合设计规

格要求，所有内部成分是否以经过检查。

软件的黑盒测试意味着测试要在软件的接口处进行。这种方法是把测试对象看做一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说

明书，检查程序的功能是否符合它的功能说明。因此黑盒测试又叫功能测试或数据驱动测试。黑盒测试主要是为了发现以下几类错误：

1、是否有不正确或遗漏的功能?

2、在接口上，输入是否能正确的接受?能否输出正确的结果?

3、是否有数据结构错误或外部信息（例如数据文件）访问错误?

4、性能上是否能够满足要求?

5、是否有初始化或终止性错误?

软件的白盒测试是对软件的过程性细节做细致的检查。这种方法是把测试对象看做一个打开的盒子，它允许测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用

例，对程序所有逻辑路径进行测试。通过在不同点检查程序状态，确定实际状态是否与预期的状态一致。因此白盒测试又称为结构测试或逻辑驱动测试。白盒测试主要是想对程序模块进行如下检查：

1、对程序模块的所有独立的执行路径至少测试一遍。

2、对所有的逻辑判定，取“真”与取“假”的两种情况都能至少测一遍。

3、在循环的边界和运行的界限内执行循环体。

4、测试内部数据结构的有效性，等等。

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

单元测试是由程序员自己来完成，最终受益的也是程序员自己。可以这么说，程序员有责任编写功能代码，同时也就有责任为自己的代码编写单元测试。执行单元测试，就是

为了证明这段代码的行为和我们期望的一致。

集成测试（也叫组装测试，联合测试）是单元测试的逻辑扩展。它的最简单的形式是： 两个已经测试过的单元组合成一个组件，并且测试它们之间的接口。从这一层意义上讲， 组件是指多个单元的集成聚合。在现实方案中，许多单元组合成组件，而这些组件又聚

合成程序的更大部分。方法是测试片段的组合，并最终扩展进程，将您的模块与其他组的模块一起测试。最后，将构成进程的所有模块一起测试。

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

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

验收测试是部署软件之前的最后一个测试操作。验收测试的目的是确保软件准备就绪， 并且可以让最终用户将其用于执行软件的既定功能和任务。

验收测试是向未来的用户表明系统能够像预定要求那样工作。经集成测试后，已经按照设计把所有的模块组装成一个完整的软件系统，接口错误也已经基本排除了，接着就应

该进一步验证软件的有效性，这就是验收测试的任务，即软件的功能和性能如同用户所合理期待的那样。

1. 阶段评审与同行评审的区别？

1. 同行评审目的：发现小规模工作产品的错误，只要是找错误；
2. 阶段评审目的：评审模块 阶段作品的正确性 可行性 及完整性

1. 同行评审人数：3-7 人 人员必须经过同行评审会议的培训，由 SQA 指导
2. 阶段评审人数：5 人左右 评审人必须是专家 具有系统评审资格
3. 同行评审内容：内容小 一般文档 < 40 页， 代码 < 500 行
4. 阶段评审内容： 内容多，主要看重点
5. 同行评审时间：一小部分工作产品完成
6. 阶段评审时间： 通常是设置在关键路径的时间点上

1. 什么是软件测试及其目的？

软件测试是使用人工或自动化手段来运行或测定某个系统的过程。其目的是： 在于检验它是否能满足规定的需求或是弄清楚预期结果与实际结果之间的差别。

1. 简述集成测试的过程？

在完成软件的概要设计后，即开始制定集成测试计划-》设计集成测试用例和测试过程-》实施集成测试，设计所需驱动和桩-》执行集成测试，记录测试结   果-》评估集成测试，根据测试结果评估此次测试，生成评估报告文档。(驱动或

桩函数是做单元测试时要用到的。驱动函数是所测 4 函数的主程序，它接收测试数据，并把数据传送给所测试单元，最后再输出实测结果。当被测单元能完成相关功能时，也可以不要驱动单元。桩，是用来代替所测试单元调用的子单元。)

1. 白盒测试有哪几种方法？

代码审查，语句覆盖，判定覆盖，条件覆盖，组合覆盖，基本路径，形式化方法，符号执行

1. 简述测试目标有哪些类型？

功能测试，负载测试，性能测试，安全性测试，恢复测试，安装测试，兼容性测试，可用性测试，可靠性测试，国际化测试，本地化测试。

1. 怎么样做好文档测试？

文档的测试主要采用静态测试即走查的方法，可以依据的是同行评审，列出一个检查表，然后大家一起坐下来对着被测试的文档进行阅读排错。通常文档都很长，而一般的建议是一

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

从项目周期看：

1、超出了所分配的测试时间；

2、用尽了分配的测试资源；

3、到达了某一个固定的里程碑（如合同规定的交付日期）。从测试角度看：

1、测试需求覆盖率；

2、测试代码覆盖率；

3、测试用例度量；

4、缺陷检查度量

1. Alpha 测试与 Beta 测试的区别？

Alpha 测试是由一个用户在开发环境下进行的测试，也可以是公司内部

的用户在模拟实际操作环境下进行的受控测试，Alpha 测试不能由程序员或测试员完成。

Alpha 测试发现的错误，可以在测试现场立刻反馈给开发人员，由开发

人员及时分析和处理。目的是评价软件产品的功能、可使用性、可靠性、性能和    支持。尤其注重产品的界面和特色。Alpha 测试可以从软件产品编码结束之后开始，或在模块（子系统）测试完成后开始，也可以在确认测试过程中产品达到一    定的稳定和可靠程度之后再开始。有关的手册（草稿）等应该在 Alpha 测试前准备好。

Beta 测试是软件的多个用户在一个或多个用户的实际使用环境下进行

的测试。开发者通常不在测试现场，Beta 测试不能由程序员或测试员完成。因而，Beta 测试是在开发者无法控制的环境下进行的软件现场应用。在 Beta 测试中，由用户记下遇到的所有问题，包括真实的以及主管认定的，定期向开发者报告，开发者在综合用户的报告后，做出修改，最后将软件产品交付给全体用户使用。Beta 测试着重于产品的支持性，包括文档、客户培训和支持产品的生产能

力。只有当 Alpha 测试达到一定的可靠程度后，才能开始 Beta 测试。由于 Beta 测试的主要目标是测试可支持性，所以 Beta 测试应该尽可能由主持产品发行的人员来管理。

1. 系统测试计划是否需要同行审批，为什么？

需要，系统测试计划属于项目阶段性关键文档，因此需要评审。

1. 比较负载测试，容量测试和强度测试的区别？

1. 负载测试：在一定的工作负荷下，系统的负荷及响应时间。
2. 强度测试：在一定的负荷条件下，在较长时间跨度内的系统连续运行给系统性能所造成      的影响。
3. 容量测试：容量测试目的是通过测试预先分析出反映软件系统应用特征

的某项指标的极限值（如最大并发用户数、数据库记录数等），系统在其极限值状态下没有出现任何软件故障或还能保持主要功能正常运行。容量测试还将确定测试对象在给定时间内能够持续处理的最大负载或工作量。容量测试的目的是使系统承受超额的数据容量来发现它是否能够正确处理。容量测试是面向数据的， 并且它的目的是显示系统可以处理目标内确定的数据容量。次同行评审步的时间不能超过两个小时，因此可以对被测试文档执行测试时，列个计划，将总的文档分解，按照计划多次对被测试的文档进行走查。

十一、开放性思维题

1. 购物车怎么测试？多久能测完？
   1. 功能测试

① 未登录时：将商品加入购物车，页面跳转到登录页面，登录成功后购物车数量增加。

② 登录后：

1. 1. 1. 所有链接是否跳转正确；
      2. 商品是否可以成功加入购物车；
      3. 购物车商品总数是否有限制；
      4. 商品总数统计是否正确；
      5. 全选功能是否可用；
      6. 删除功能是否可用；
      7. 价格总计是否正确；

1. 1. 1. 商品文字太长时是否显示完整；
      2. 购物车中下架的商品是否有标识，是否还能支付；
      3. 新加入购物车商品排序（添加购物车中存在的店铺的商品和购物车中不存在的店铺的商品）；
      4. 是否支持快 TAB、ENTER 等快捷键；
      5. 商品删除后商品总数是否减少；
      6. 收藏功能是否可用；
      7. 购物车结算功能是否可用。

1. 1. 兼容性测试

① BS 架构：不同浏览器测试，比如：IE，火狐，谷歌，360 这些。

② APP：在主流的不同类型，不同分辨率，不同操作系统的手机上测试，华为， vivo，oppo 等

1. 1. 用户体验测试

① 删除商品是否有提示；

② 是否支持快捷键功能；

③ 是否有回到顶部的功能；

④ 商品过多时结算按钮是否可以浮动显示；

⑤ 购物车有多个商品时，能不能只对单个商品结算；

⑥ 界面布局、排版是否合理；

⑦ 文字是否显示清晰；

⑧ 不同卖家的商品是否区分明显。

1. 1. 性能测试

① 打开购物车页面要多长时间

1. 1. 安全性测试

① 加入购物车时，抓包拦截数据

1. 1. 如果当天没有其他加急的事情，优先安排测试的话，我觉得两个小时可以测试完成。

1. 支付功能怎么测试？

1. 从功能方面考虑：
   1. 正常完成支付的流程；
   2. 支付中断后继续支付的流程；
   3. 支付中断后结束支付的流程；
   4. 单订单支付的流程；
   5. 多订单合并支付的流程；
   6. 余额不足；金额的最小值 ：如 0.01；金额为 0；金额为负数
   7. 未绑定银行卡；
   8. 密码错误；
   9. 密码错误次数过多；
   10. 找人代付；
   11. 弱网状态下，连续点击支付功能，会不会支付多次；

1. 1. 有优惠券、折扣、促销价进行结算是否正确；
   2. 不同终端上支付：包括 PC 端的支付、笔记本电脑的支付、平板电脑的支付、手机端的支付等；
   3. 不同的支付方式：银行卡网银支付、支付宝支付、微信支付等；
   4. 支付失败后，再次支付。

1. 从性能方面考虑：

1. 多个用户并发支付能否成功；
2. 支付的响应时间；

1. 从安全性方面考虑

(1)   使用 Fiddler 拦截订单信息，并修改订单金额，或者修改订单号，(下两个订单 A,B，付款时拦截订单 B，并把订单 B 的订单号改为 A 订单的订单号)无法完成支付；

1. 从用户体验方面考虑

1. 是否支持快捷键功能；
2. 点击付款按钮，是否有提示；
3. 取消付款，是否有提示；
4. UI 界面是否整洁；
5. 输入框是否对齐，大小是否适中等。

1. 兼容性

1. BS 架构：不同浏览器测试。
2. APP：不同类型，不同分辨率，不同操作系统的手机上测试

1. 搜索功能怎么测试？

1. 功能方面的测试：

1. 搜索单个字，词语，句子，检索到的内容是否准确，链接是否准确
2. 长度：例如输入框支持 100 字符， 那需要测试 100 字符、101 字符，最大长度的显示是否正常；
3. 哪些是支持的字符类型：数字、字母、汉字、字符！@！#、特殊字符；
4. 是否支持换行；
5. 字符串前后中带空格，前后的空格是否过滤， 中间的空格是否保留
6. 全角半角的字母、数字

1. 性能方面的测试

1. 点击搜索按钮后，搜索结果多长时间能够显示
2. 进入搜索页面需要多久

1. 安全性方面的测试

(1) 能否防止 SQL 注入攻击,否防止 XSS 攻击

1. 用户体验测试：

1. 页面布局是否合理，输入框和按钮是否对齐

1. 输入框的大小和按钮的长度，高度是否合理
2. 快捷键：能不能全选，部分选择，复制剪切粘贴是否可用，粘贴超过最大长度的字符串      怎么显示，table 键盘是否可用；

1. 兼容性测试

1. BS 架构：不同浏览器测试，比如：IE，火狐，谷歌，360 这些。
2. APP：在主流的不同类型，不同分辨率，不同操作系统的手机上测试，华为，vivo，oppo

等

1. 文件上传功能怎么测试？

1. 功能测试

1. 选择符合要求的文件，上传 上传成功；
2. 上传成功的文件名称显示 显示正常（根据需求）
3. 查看，下载上传成功的文件 上传的文件可查看或下载
4. 删除上传成功的文件 可删除
5. 替换上传成功的文件 可替换
6. 上传文件是否支持中文名称 根据需求而定
7. 文件路径是否可手动输入 根据需求而定
8. 手动输入正确的文件路径，上传 上传成功
9. 手动输入错误的文件路径，上传 提示，不能上传

1. 文件大小测试

1. 符合格式，总大小稍小于限制大小的文件 上传成功
2. 符合文件，总大小等于限制大小的文件 上传成功
3. 符合文件总大小稍大于限制大小的文件 在上传初提示附件过大
4. 小为 0kb 的 txt 文档 不能上传

1. 文件名称测试

1. 文件名称过长。Win2000 标准：255 个字符（指在英文的字符下），如果是中文不超过 127 个汉字 提示过长
2. 文件名称达到最大长度（中文，英文或混在一起）上传后名称显示，页面排版-----------

页面显示正常

1. 文件名称中包含特殊字符 根据需求而定
2. 文件名全为中文 根据需求而定
3. 文件名全为英文 根据需求而
4. 文件名为中、英混合 根据需求而定

1. 文件格式测试

1. 上传正确格式 上传成功
2. 上传不允许的格式 提示不能上传
3. 上传 rar,zip 等打包文件（多文件压缩） 根据需求而定

1. 安全性测试

1. 上传可执行文件（exe 文件） 根据需求而定

1. 上传常见的木马文件 提示不能上传
2. 上传时服务器空间已满 有提示

1. 性能测试

1. 上传时网速很慢（限速） 当超过一定时间，提示
2. 上传过程断网 有提示是否上传成功
3. 上传过程服务器停止工作 有提示是否上传成功
4. 上传过程服务器的资源利用率 在正常范围

1. 界面测试

1. 界面美观性、易用性（键盘和鼠标的操作、tab 跳转的顺序是否正确） 显示正常

（根据需求）

1. 按钮文字是否正确 正确
2. 正确/错误提示的文字是否正确 正确
3. 说明性文字是否正确 正确

1. 其他测试

1. 有多个上传框时，上传相同名称的文件 根据需求而定
2. 上传一个正在打开的文件 可以上传
3. 文件路径是手工输入的是否限制长度 限制一定的长度
4. 上传过程中是否有取消正在上传文件的功能 有
5. 保存时有没有已经选择好，但没有上传的文件 提示上传
6. 选择好但是未上传的文件是否可以取消选择 可以取消选择

1. 登录功能怎么测试？

1. 功能方面的测试：

1. 输入正确的用户名和密码，点击提交按钮，验证是否能正确登录，能否能跳转到正确的      页面
2. 输入错误的用户名, 验证登录失败，并且提示相应的错误信息
3. 输入错误的密码, 验证登录失败，并且提示相应的错误信息
4. 用户名为空, 验证登录失败，并且提示相应的错误信息
5. 密码为空, 验证登录失败，并且提示相应的错误信息
6. 用户名和密码都为空，点击登陆
7. 用户名和密码前后有空格的处理

1. 性能方面的测试

1. 打开登录页面，需要多长时间
2. 输入正确的用户名和密码后，登录成功跳转到新页面，需要多长时间

1. 安全性方面的测试

1. 密码是否在前端加密，在网络传输的过程中是否加密
2. 用户名和密码的输入框，能否防止 SQL 注入攻击
3. 用户名和密码的输入框，能否防止 XSS 攻击

1. 错误登陆的次数限制（防止暴力破解）
2. 是否支持多用户在同一机器上登录
3. 一个用户在不同终端上登陆
4. 用户异地登陆

1. 用户体验测试：

1. 页面布局是否合理，输入框和按钮是否对齐
2. 输入框的大小和按钮的长度，高度是否合理
3. 是否可以全用键盘操作，是否有快捷键
4. 输入用户名，密码后按回车，是否可以登陆
5. 牵扯到验证码的，还要考虑文字是否扭曲过度导致辨认难度大，考虑颜色（色盲使用者），刷新或换一个按钮是否好用

1. 兼容性测试

1. BS 架构：不同浏览器测试，比如：IE，火狐，谷歌，360 这些。
2. APP：在主流的不同类型，不同分辨率，不同操作系统的手机上测试，华为，vivo，oppo

等

1. 还款功能怎么测试？

1. 功能

1. 正常还款流程
2. 逾期还款
3. 不同的还款账户
4. 余额不足还款
5. 弱网状态下，连续点击还款按钮
6. 弱网状态，或系统不稳定，支付服务方未把支付结果返回给下单发起方(如果发生这种     问题，结果是，钱扣了，还款状态未发生变化)
7. 金额不输，为 0，为负数
8. 提前还款
9. 第三方还款

1. 性能：

(1) 还款的响应时间是否过长

1. 用户体检：

1. 系统提示是否容易理解
2. 界面是否友好，输入框是否对齐，按钮大小是否适中，是否有错别字等

1. 安全性：

1. 是否能防止 SQL 注入，防 XSS 攻击
2. 还款金额是否会被拦截篡改
3. 还款密码等敏感信息是否加密

1. 兼容性：

1. BS 架构的系统，要考虑不同浏览器的兼容性

1. APP：考虑在不同分辨率，不同操作系统，不同类型的手机的兼容性

1. 订单功能怎么测试?

我们系统的订单生成的流程是这样子的，用户下单后，系统会在用户端和卖家端生成一个待付款的订单，同时在数据库也会生成一个待付款的订单；当用户付款之后，用户端显示       待发货状态，卖家端显示已付款待发货状态，订单在数据库的状态为待发货，产品相应的库       存量会减少，用户的账户金额减少相应的金额；当卖家发货后，用户端和卖家端的订单状态       都显示为配送中，数据库中的订单状态也同时发生变化；当用户确认收货后，订单状态会显       示为已完成，待评价状态，数据库中的订单状态也同时发生变化，买家支付的款项会打入到       卖家的账户；当用户评论完后，订单状态显示为已结束，数据库中的订单状态也同时发生变       化。这是一个正常的流程，我们测试的时候，要优先把这个流程测试通过。

然后再考虑用户的其他使用场景，比如：

1. 用户下单后，取消订单；
2. 下单后，一直不付款，检查订单超时不付款的场景下，会不会自动取消订单；
3. 在订单快超时时，付款；
4. 下单后，在不同的终端登录，一端取消订单，同时一端对该订单进行付款；
5. 弱网状态下，多次点击提交订单按钮，检查是否会生成多个订单；
6. 用户付款后，申请退款，买家端的订单状态为退款申请中，卖家端显示为退款审核；申请退款通过后，订单状态为已关闭状态，买家收到退还的金额；卖家拒绝退款，订单状态为待发货状态；卖家超时不处理退款申请，自动退款，订单自动设置为已退款状态， 买家收到退还的金额；
7. 当卖家发货后，买家申请退款，买家端的订单状态为退款申请中，卖家端显示为退款审核；申请退款通过后，订单状态为已关闭状态，买家收到退还的金额；卖家拒绝退款， 订单状态为待发货状态；卖家超时不处理退款申请，自动退款，订单自动设置为已退款状态，买家收到退还的金额；
8. 买家收货后，买家申请退款/退货，买家端的订单状态为退款申请中，卖家端显示为退    款审核；申请退款通过后，订单状态为已关闭状态，买家收到退还的金额；卖家拒绝款

/退货，订单状态为已确认收货状态；卖家超时不处理退款/退货申请，自动退款，订单     自动设置为已退款状态，买家收到退还的金额；

1. 买家长时间不确认收货，系统自动确认收货，系统自动设为好评，订单状态为已结束，      卖家收到买家的货款；
2. 收货后，超时不评论，系统自动设为好评，订单状态为已结束。

这些是功能测试的场景，每个场景，我们都要检查数据库对应订单的数据变化。

1. 用户体验：

1. 订单界面是否整洁，清晰，文字大小是否适中，订单编号是否能复制；
2. 下单，取消订单，申请退款等功能是否有相应的提示，提示是否合理；
3. 超时时长是否有倒计时提示；
4. 只对订单的部分商品进行发货，订单里的商品发货状态是否分开展示；
5. 是否支持 Enter，tab 等快捷键。

1. 安全性：

(1) 使用 Fiddler，检查是否能拦截篡改修改订单的信息。

1. 兼容性：

1. web 端，在不同的浏览器，比如：谷歌，IE，火狐，360 上测试；
2. app 端，在主流的不同的机型，不同的分辨率，不同的操作系统的手机上进行测试，比如：xxx；

1. 性能：

1. 多用户并发下单；
2. 提交订单，取消订单，申请退款的响应时间。

1. 可靠性：

(1) 多用户长时间运行提交订单功能。

1. 对电梯进行测试用例设计

套用万能公式（也就是质量模型，也叫软件质量的 6 大特性）

界面测试：

查看电梯外观，按钮位设计是否合理、大方、美观，是否有温馨提示的标语。是否有检修标牌和紧急求助联系方式。

功能测试：

1. 测试电梯能否实现正常的上升和下降功能。
2. 电梯的按钮是否都可以使用。
3. 电梯门的打开，关闭是否正常。
4. 报警装置是否可用。
5. 与其他电梯之间是否协作良好。
6. 通风状况如何。
7. 突然停电时的情况。
8. 上升途中的响应。

1. 电梯本来在 1 楼，如果有人在 18 楼按，那么电梯在上升到 5 楼的时候，有人在 10 楼按，

这时候是否会在 10 楼先停下来；

1. 电梯下降到 10 层时显示满员，此时若 8 层有人等待电梯，是否在 8 层停。

可靠性（安全性）：

1. 门关上的一刹那出现障碍物。
2. 同时按关门和开门按钮。
3. 点击当前楼层号码。
4. 多次点击同一楼层的号码等等。
5. 同时按上键和下键会怎样。

易用性：

1. 电梯的按钮的设计符合一般人使用的习惯吗．