面试题

2.fiddler抓包后如何过滤

1)通过host过滤

• • Zone：指定只显示内网（Intranet）或互联网（Internet）的内容；
  • Host：指定显示某个域名下的会话；

2）通过客户端进程过滤（client process）

• •   Show only traffic from：你可以指定只捕获哪个Windows进程中的请求；
  •   Show only Internet Explorer traffic：只显示IE发出的请求；
  •   Hide Windows RSS platform traffic：隐藏Windows RSS平台发出的请求；

3）通过request header过滤

• •   经常使用：Show only if URL contains；
  •   Flag requests with headers：标记带有特定header的请求；
  •   Delete request headers：删除请求header；
  •   Set request header设置请求的header；

4）通过response status code进行过滤

5）通过响应类型和大小进行过滤（response type and size）

6）通过response header过滤

• •   Flag response that set cookies：标记会设置cookie的响应；
  •   Flag response with headers：标记带有特定header的响应；
  •   Delete response headers：删除响应header；
  •   Set response header：设置响应的header；

3.有没有测过请求头信息内容
4.描述bug的生命周期

New（新建/提交缺陷）:新发现的Bug，未经评审决定是否指派给开发人员进行修改。

Open（分配）：确认是Bug，并且认为需要进行修改，指派给相应的开发人员。

Fixed（处理）:开发人员进行修改后标识成修改状态，有待测试人员的回归测试验证。

Rejected（拒绝）：如果认为不是Bug，则拒绝修改。

Delay（延后）:如果认为暂时不需要修改或暂时不能修改，则延后修改。

Closed（关闭）：修改状态的Bug经测试人员的回归测试验证通过，则关闭Bug。

Reopen（重启）：如果经验证Bug仍然存在，则需要重新打开Bug，开发人员重新修改。

顺便了解下缺陷等级： 

Bug等级由高到低依次分为：致命Bug、严重Bug、一般严重Bug、低级Bug和建议性的Bug。

致命的Bug：导致软件停止运行，软件的重要部件无法运行，软件崩溃或者挂起等导致软件不能正常运行。

严重的Bug：严重地影响软件要求或基本功能的实现，且没有更正办法（重新安装或重新启动该软件不属于更正办法）。使软件不稳定、或破坏数据、或产生错误结果，或部分功能无法执行，而且是常规操作中经常发生或非常规操作中不可避免的主要问题，软件无法满足主要的业务需求，性能、功能或可用性严重降低。

一般严重的Bug：软件可以满足业务需求，软件性能或响应时间变慢、产生错误的中间结果但不影响最终结果等影响有限的问题。

低级的Bug：使操作者不方便或操作麻烦，但它不影响执行工作功能或重要功能。界面拼写错误或用户使用不方便等小问题或需要完善的问题。

建议性的Bug：希望提出的建议以及建议进行但不强制进行的修改。不会给发布的准确性或可用性带来任何严重影响。

5.访客机小票测试用例

小票上各项信息是否齐全

访客本人取票后，拿着小票后能否进入

访客取票后没有立刻进入，时隔一小时，一天，一礼拜，一个月再次凭该小票能否进入

访客出门后立刻再次凭该小票是否能够进入，若时隔一小时，一天，一礼拜，一个月再次凭该小票能否进入

不是访客本人，凭该小票是否能够进入

（出题者希望我回答的时2,3,4,5点）

6.是否了解过其他自动化测试框架
7.目前所在公司测试流程是否规范，为什么
8.怎么测的接口

• 通过性验证：首先肯定要保证这个接口功能是好使的，也就是正常的通过性测试，按照接口文档上的参数，正常传入，是否可以返回正确的结果。

• 参数组合：api文档中要求该接口有3个非必填的参数，发送请求时参数自由组合

• 接口安全：有些接口需要依赖登录接口，那么没有登录直接发送请求后是否可以返回正确结果；有些接口请求需要请求头，那么没有请求头时是否能返回正确结果
• 异常验证：不按照你接口文档上的要求输入参数，来验证接口对异常情况的校验。也就这三种，必传非必传、参数类型、入参长度。
• 性能测试：接口并发情况，如上面提到的：一个账号，同时（大于2个请求）对最后一个商品下单，或不同账号，对最后一个商品下单；接口响应时间，响应时间太长了，肯定需要优化，一般都是毫秒级别

9.shell命令会吗

10.怎么编写用例，策略是什么。

• 用例设计的结构安排是否清晰、合理，是否利于高效对需求进行覆盖。
• 用例描述是否清晰
• 优先极安排是否合理。
• 是否覆盖测试需求上的所有功能点。
• 用例是否具有很好可执行性。例如用例的前提条件、执行步骤、输入数据和期待结果是否清晰、正确；期待结果是否有明显的验证方法。
• 是否已经删除了冗余的用例。
• 是否包含充分的负面测试用例。充分的定义，如果在这里使用2&8法则，那就是4倍于正面用例的数量，毕竟一个健壮的软件，其中80%的代码都是在“保护”20%的功能实现。
• 是否从用户层面来设计用户使用场景和使用流程的测试用例。
•  是否简洁，复用性强。例如，可将重复度高的步骤或过程抽取出来定义为一些可复用标准步骤。

• • build periodically：周期性进行项目构建，这个是到指定的时间必须触发构建任务
  • poll scm：定时检查源码变更（根据SCM软件的版本号），如果有更新就checkout最新code下来，然后执行构建动作
  • Build after other projects are built：任务关联
  • 触发远程构建 (例如,使用脚本）
  • GitHub hook trigger for GITScm polling： 这个是管理github上代码有变动时构建

因为是定时构建所以用build periodically

4）添加构建命令，然后保存项目

执行的时候在项目中点立即构建就行