面试——测试工程师（20191009）

小小的记录一下求职经历，一起加油呀~ ٩̋(•͈ω•͈)و

职位描述：

1. 依据需求文档及设计文档，编写测试用例；
2. 依据测试用例执行手工测试，反馈跟踪产品BUG及用例缺陷，协助开发人员定位及修复bug，并做好回归测试，并提交测试报告；
3. 对测试中发现的问题进行详细分析和准确定位，与开发人员讨论缺陷解决方案；
4. 协助开发人员定位及修复bug，并做好回归测试；
5. 对测试结果进行总结与统计分析，对测试进行跟踪，并提出反馈意见。

职位要求：

1. 本科以上学历，0~1年工作经验，计算机及相关专业毕业，有扎实的计算机基础知识；
2. 熟悉常用软件测试工具，熟悉测试分析技术，有较强的逻辑分析能力和总结能力；
3. 规范编写项目测试计划、测试用例、测试报告，熟悉常用缺陷管理工具；
4. 掌握基本的测试理论，熟悉软件测试的基本方法、流程和规范；
5. 热爱软件测试工作，工作耐心、细致、认真。

加分点：

1. 熟悉一门编程语言，比如java，python等；
2. 有web测试经验；
3. 具备相关产品（如小程序等）测试经验。

---

笔试题：

1. V模型

• V模型 大体可以划分为以下几个不同的阶段步骤：需求分析、概要设计、详细设计、软件编码、单元测试、集成测试、系统测试、验收测试。适用于一些传统信息系统应用的开发。
   (1) 需求分析：明确用户需求，并对需求进行分析。
   (2) 概要分析：对软件进行整体的概要的设计。
   (3) 详细设计：对软件进行伪码的设计。
   (4) 编码：具体实现详细设计说明书中的类、方法等。
   (5) 单元测试：验证和确认代码的开发是否符合详细设计的要求，记录测试结果。
   (6) 集成测试：验证和确认测试过的各模块是否能完好地结合到一起。
   (7) 系统测试：对最终软件系统进行全面的测试，从而验证和确认系统功能和性能的质量特性是否符合需求规格说明书的要求。
   (8) 验收测试：验证和确定软件的实现是否满足用户需要的要求。
  
• W模型 是由两个V模型组成，分别代表测试和开发的过程，表示 测试和开发是同时进行的。相对于V模型，增加了软件开发阶段中应同步进行的 验证 和 确认 活动。
  
• V模型详细讲解
• V模型和W模型详解

2. 冒烟测试

维基百科：
smoke testing is preliminary testing to reveal simple failures severe enough to, for example, reject a prospective software release. Smoke tests are a subset of [test cases] that cover the most important functionality of a component or system, used to aid assessment if main functions of the software appear to work correctly. When used to determine if a computer program should be subjected to further, more fine-grained testing, a smoke test may be called an intake test. Alternately, it is a set of tests run on each new build of a product to verify that the build is testable before the build is released into the hands of the test team. In the DevOps paradigm, use of a BVT step is one hallmark of the continuous integration maturity stage.

• 冒烟测试 设计用于确认代码中的更改会按预期运行，且不会破坏整个版本的稳定性。在检查了代码后，冒烟测试是确定和修复软件缺陷的最经济有效的方法。
• 冒烟测试是在软件开发过程中的一种针对软件版本包的 快速基本功能验证策略 ，是对软件基本功能进行 确认验证 的手段，并非对软件版本包的深入测试。冒烟测试也是针对软件版本包 进行详细测试之前的预测试 ，执行冒烟测试的主要目的是 快速验证软件基本功能是否有缺陷 。如果冒烟测试的测试例不能通过，则不必做进一步的测试。进行冒烟测试之前需要确定冒烟测试的用例集，对用例集要求覆盖软件的基本功能。这种版本包出包之后的验证方法通常称为软件版本包的 门槛用例验证 。
• 冒烟测试属于 HLT(highleveltest)测试 ，HLT通常指SDV(系统设计验证)/SIT(系统集成测试)/SVT(系统验证测试)等测试活动。HLT是站在系统的角度对整个版本进行测试，测试对象是 一个完整的产品 而不是产品内部的模块，常见的HLT测试包括 系统测试 和 验收测试 。
• 冒烟测试可以手动执行，也可以自动化执行。稳定的系统适合自动化冒烟测试，集成过程中的系统适合手工冒烟测试，因为冒烟测试内容在动态变化，变化中的自动化脚本维护工作量比较大。
• 冒烟测试的对象是 每一个新编译的需要正式测试的软件版本 ，目的是 确认软件基本功能正常 ，可以进行后续的正式测试工作。冒烟测试的执行者是 版本编译人员 。
• 冒烟测试是对软件质量的总体检验 ：通过冒烟测试，能够快速确认软件是否具备测试准入条件，避免出现正式测试阶段全面开展后甚至到测试中后期才才发现阻塞型缺陷等严重影响测试进度浪费人力物力的情况。
• 冒烟测试是测试人员对测试流程的熟悉 ：通过冒烟测试，测试人员可以迅速熟悉测试总体流程，这一方面有助于测试人员准确制定测试时间计划，合理安排工作进度；另一方面也有助于测试人员提前做好相关设备、数据的准备，为正式测试的开展奠定基础。
• 冒烟测试浅谈
• 冒烟测试详谈

3. http的5种状态码

• 消息：代表请求已被接受，需要继续处理。这类响应是临时响应，只包含状态行和某些可选的响应头信息，并以空行结束。由于 HTTP/1.0 协议中没有定义任何 1xx 状态码，所以除非在某些试验条件下，服务器禁止向此类客户端发送 1xx 响应。

状态码	名称	含义
100	Continue	客户端应当继续发送请求。
101	Switching Protocols	服务器已经理解了客户端的请求，并将通过Upgrade 消息头通知客户端采用不同的协议来完成这个请求。
102	Processing	由WebDAV（RFC 2518）扩展的状态码，代表处理将被继续执行。

• 成功：代表请求已成功被服务器接收、理解、并接受。

状态码	名称	含义
200	OK	请求已成功，请求所希望的响应头或数据体将随此响应返回。出现此状态码是表示正常状态。
201	Created	请求已经被实现，而且有一个新的资源已经依据请求的需要而建立，且其 URI 已经随Location 头信息返回。假如需要的资源无法及时建立的话，应当返回 ‘202 Accepted’。
202	Accepted	服务器已接受请求，但尚未处理。
203	Non-Authoritative Information	服务器已成功处理了请求，但返回的实体头部元信息不是在原始服务器上有效的确定集合，而是来自本地或者第三方的拷贝。当前的信息可能是原始版本的子集或者超集。
204	No Content	服务器成功处理了请求，但不需要返回任何实体内容，并且希望返回更新了的元信息。
205	Reset Content	服务器成功处理了请求，且没有返回任何内容。
206	Partial Content	服务器已经成功处理了部分 GET 请求。
207	Multi-Status	由WebDAV(RFC 2518)扩展的状态码，代表之后的消息体将是一个XML消息，并且可能依照之前子请求数量的不同，包含一系列独立的响应代码。

• 重定向：代表需要客户端采取进一步的操作才能完成请求。

状态码	名称	含义
300	Multiple Choices	被请求的资源有一系列可供选择的回馈信息，每个都有自己特定的地址和浏览器驱动的商议信息。用户或浏览器能够自行选择一个首选的地址进行重定向。
301	Moved Permanently	被请求的资源已永久移动到新位置，并且将来任何对此资源的引用都应该使用本响应返回的若干个 URI 之一。
302	Move Temporarily	请求的资源临时从不同的 URI响应请求。
303	See Other	对应当前请求的响应可以在另一个 URL 上被找到，而且客户端应当采用 GET 的方式访问那个资源。
304	Not Modified	如果客户端发送了一个带条件的 GET 请求且该请求已被允许，而文档的内容（自上次访问以来或者根据请求的条件）并没有改变，则服务器应当返回这个状态码。304响应禁止包含消息体，因此始终以消息头后的第一个空行结尾。
305	Use Proxy	被请求的资源必须通过指定的代理才能被访问。
306	Switch Proxy	在最新版的规范中，306状态码已经不再被使用。
307	Temporary Redirect	请求的资源临时从不同的URI 响应请求。

• 请求错误：这类的状态码代表了客户端看起来可能发生了错误，妨碍了服务器的处理。

状态码	名称	含义
400	Bad Request	(1) 语义有误，当前请求无法被服务器理解。 (2) 请求参数有误。
401	Unauthorized	当前请求需要用户验证。
402	Payment Required	该状态码是为了将来可能的需求而预留的。
403	Forbidden	服务器已经理解请求，但是拒绝执行它。
404	Not Found	请求失败，请求所希望得到的资源未被在服务器上发现。
405	Method Not Allowed	请求行中指定的请求方法不能被用于请求相应的资源。
406	Not Acceptable	请求的资源的内容特性无法满足请求头中的条件，因而无法生成响应实体。
407	Proxy Authentication Required	与401响应类似，只不过客户端必须在代理服务器上进行身份验证。
408	Request Timeout	请求超时。
409	Conflict	由于和被请求的资源的当前状态之间存在冲突，请求无法完成。
410	Gone	被请求的资源在服务器上已经不再可用，而且没有任何已知的转发地址。
411	Length Required	服务器拒绝在没有定义 Content-Length 头的情况下接受请求。
412	Precondition Failed	服务器在验证在请求的头字段中给出先决条件时，没能满足其中的一个或多个。
413	Request Entity Too Large	服务器拒绝处理当前请求，因为该请求提交的实体数据大小超过了服务器愿意或者能够处理的范围。
414	Request-URI Too Long	请求的URI 长度超过了服务器能够解释的长度，因此服务器拒绝对该请求提供服务。
415	Unsupported Media Type	对于当前请求的方法和所请求的资源，请求中提交的实体并不是服务器中所支持的格式，因此请求被拒绝。
416	Requested Range Not Satisfiable	如果请求中包含了 Range 请求头，并且 Range 中指定的任何数据范围都与当前资源的可用范围不重合，同时请求中又没有定义 If-Range 请求头，那么服务器就应当返回416状态码。
417	Expectation Failed	在请求头 Expect 中指定的预期内容无法被服务器满足，或者这个服务器是一个代理服务器，它有明显的证据证明在当前路由的下一个节点上，Expect 的内容无法被满足。
418	I’m a teapot
421	Too Many Connections	从当前客户端所在的IP地址到服务器的连接数超过了服务器许可的最大范围。
422	Unprocessable Entity	请求格式正确，但是由于含有语义错误，无法响应。
423	Locked	当前资源被锁定。
424	Failed Dependency	由于之前的某个请求发生的错误，导致当前请求失败，例如 PROPPATCH。
425	Too Early	代表服务器不愿意冒风险来处理该请求，原因是处理该请求可能会被“重放”，从而造成潜在的重放攻击。
426	Upgrade Required	客户端应当切换到TLS/1.0。
449	Retry With	由微软扩展，代表请求应当在执行完适当的操作后进行重试。
451	Unavailable For Legal Reasons	该请求因法律原因不可用。

• 服务器错误：这类状态码代表了服务器在处理请求的过程中有错误或者异常状态发生，也有可能是服务器意识到以当前的软硬件资源无法完成对请求的处理。

状态码	名称	含义
500	Internal Server Error	服务器遇到了一个未曾预料的状况，导致了它无法完成对请求的处理。
501	Not Implemented	服务器不支持当前请求所需要的某个功能。
502	Bad Gateway	作为网关或者代理工作的服务器尝试执行请求时，从上游服务器接收到无效的响应。
503	Service Unavailable	由于临时的服务器维护或者过载，服务器当前无法处理请求。
504	Gateway Timeout	作为网关或者代理工作的服务器尝试执行请求时，未能及时从上游服务器（URI标识出的服务器，例如HTTP、FTP、LDAP）或者辅助服务器（例如DNS）收到响应。
505	HTTP Version Not Supported	服务器不支持，或者拒绝支持在请求中使用的 HTTP 版本。
506	Variant Also Negotiates	由《透明内容协商协议》（RFC 2295）扩展，代表服务器存在内部配置错误：被请求的协商变元资源被配置为在透明内容协商中使用自己，因此在一个协商处理中不是一个合适的重点。
507	Insufficient Storage	服务器无法存储完成请求所必须的内容。
509	Bandwidth Limit Exceeded	服务器达到带宽限制。
510	Not Extended	获取资源所需要的策略并没有被满足。
600	Unparseable Response Headers	源站没有返回响应头部，只返回实体内容。

5. 样式属性

• 常用CSS样式属性

6. 有效类和无效类

7. 7×24小时会员免登陆的测试用例

• 七天免登陆的测试用例编写
• 用户登录的测试用例编写

---

面试题：

1. 对软件测试的了解程度

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

2. 用过哪些测试工具

• 开源测试管理工具：Bugfree、Bugzilla、TestLink、mantis zentaopms
• 开源功能自动化测试工具：Watir、Selenium、MaxQ、WebInject
• 开源性能自动化测试工具：Jmeter、OpenSTA、DBMonster、TPTEST、Web Application Load Simulator
• 其他测试工具与框架：Rational Functional Tester、Borland Silk系列工具、WinRunner、Robot等。
• 禅道测试管理工具：功能比较全面的测试管理工具，功能涵盖软件研发的全部生命周期，为软件测试和产品研发提供一体化的解决方案。是一款优秀的国产开源测试管理工具。
• Quality Center：基于Web的测试管理工具，可以组织和管理应用程序测试流程的所有阶段，包括指定测试需求、计划测试、执行测试和跟踪缺陷。
• QuickTest Professional：用于创建功能和回归测试。
• LoadRunner：预测系统行为和性能的负载测试工具。
• 国内免费软件测试工具有：AutoRunner和TestCenter。
• 常见的自动化测试工具

3. 做过哪些测试

4. 完整的软件测试流程
   (1) 需求评审：由项目经理、开发人员、测试人员、需求人员共同进行的对软件需求文档的评审，评审内容主要包括：“需求规格说明书”的内容是否完善，是否有描叙不清楚的地方或者有冲突，需求是否可以支持系统目标的实现，是否有无法实现的功能等。项目经理根据开发人员、测试人员、需求人员意见完成项目计划。
   (2) 需求分析：是开发人员根据需求文档完成需求分析文档，测试人员参与评审，评审的内容主要是看是否有遗漏或双方理解不一样的地方，测试人员要熟读需求，要多与开发、架构等多方多交流，深入了解需求。需求分析这一过程是主要确定系统必须完成哪些工作，对目标系统提出完整、准确、清晰具体的要求。
   (3) 测试计划：测试计划一般由测试经理编写，根据需求估算测试所需资源（人力，设备等）、所需时间、功能点划分、如何合理分配安排资源。
   (4) 用例设计：根据测试计划，修改好的需求分析文档开始写测试用例，同时开发人员完成概要设计文档和详细设计文档。测试人员根据这两份文档补充测试用例。
   (5) 测试环境：测试人员搭建测试环境。
   (6) 执行测试：开发人员提交第一个版本，如果存在未完成的功能，开发需跟测试人员说明，然后测试人员根据测试用例的详细步骤，执行测试用例，发现BUG提交缺陷库。
   (7) BUG追踪：开发人员提交第二个版本，包括修改的BUG以及增加的部分功能，测试人员进行第二轮测试和回归测试，跟踪BUG直到关闭。重复上面的工作，一般情况下3-4个版本后BUG数量减少。
   (8) 测试报告：通过不断测试，BUG跟踪，直到用例全部测试，覆盖率、缺陷率以及其他各项指标达到质量标准，即达到上线要求。（如果有客户反馈问题，需要测试人员协助重现和回归测试）。

5. 自动化测试
   一分钟了解自动化测试

6. bug的生命周期

• bug的生命周期：发现bug–>提交bug–>指派bug–>研发确认bug–>研发去修复bug–>回归验证bug–>是否通过验证–>关闭bug
• bug的等级：致命错误、严重错误、一般错误、细微错误。
• bug的类型： 功能问题、设计缺陷、界面优化、性能问题、配置相关、安装部署、安全相关、标准规范、测试脚本、其他。（或者说：功能类、界面类、性能类、易用性类、兼容性类、其他。）
• 如何提交bug：bug标题（功能模块+操作+结果）、重现步骤、bug类型和严重程度、bug测试环境、附件。
• 常见bug管理系统：禅道（zentao）、bugzilla、jira、bugfree、easybug、QC
  

7. 上线前几天突然发现bug，你会怎么处理？

8. 你觉得是bug，但是开发组不觉得是bug，你会怎么做？