整理下几次面试被问到的问题：
1.linux 筛选命令，如何在压缩包中筛选文件，如何修改文件，grep，awk
- 非压缩包文件，可以用grep命令去搜索 grep –i "被查找的字符串" 文件名
grep test *file查找文件后缀为file且文件中有test的文件
- .gz压缩包类型的话，可以用zgrep命令去搜索 zgrep –i "被查找的字符串" 文件名
- 其它压缩类型，例如zip好像就不能直接这样去搜索了，可以用：zcat 文件名|grep -c '被查找字符串内容'
- 编辑文件 vi filename
awk命令自行百度
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.怎么编写用例，策略是什么。
测试用例编写策略可以从不同的角度分类
1)从测试内容角度可以分为流程用例和功能点用例。
-
- 流程用例指针对业务流程编写的测试用例，通常采用场景法，现在的软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流；
- 功能点用例指针对具体功能点编写的测试用例，可以采用等价类划分、边界值法、因果图等方法。
2)根据测试的策略又可以分为通过测试用例和失败测试用例
-
- 通过测试用例主要为了验证需求是否可以实现，一般采用等价类划分等测试方法。
- 失败用例的编写主要为了尽可能多的发现缺陷，一般采用错误推测法、边界值分析法等测试方法。
3)对于业务流程比较重要的系统，首先要考虑用场景法编写流程用例，要求覆盖所有的基本流和备选流。流程测试用例的完善，可以保证业务流程和业务数据流转正确无误，对软件的质量有了最基本的保障。其次需要编写功能点测试用例，要求覆盖所有的需求，保证需求的各个功能都能正常的实现。
4)对于所有的软件测试，我们首先要考虑通过测试用例，来证明软件可以满足需求。在保证软件可用的基础上，才会使用失败测试用例，来尽可能多的发现缺陷，保证软件的具有一定的容错和安全能力。
- 用例设计的结构安排是否清晰、合理，是否利于高效对需求进行覆盖。
- 用例描述是否清晰
- 优先极安排是否合理。
- 是否覆盖测试需求上的所有功能点。
- 用例是否具有很好可执行性。例如用例的前提条件、执行步骤、输入数据和期待结果是否清晰、正确；期待结果是否有明显的验证方法。
- 是否已经删除了冗余的用例。
- 是否包含充分的负面测试用例。充分的定义，如果在这里使用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）添加构建命令，然后保存项目
执行的时候在项目中点立即构建就行
13.怎么进行自动化测试