►►►
前言
软件测试 员是在项目的不同阶段一直从事着各种各样的测试，但是当需要测试所需技能状况时，却找不到一个合适的方法。
……面试时表现自信：一般说来，面试首先会从了解求职者的概况开始。 然后大多数就是技术问题了。
►►►
测试的整个流程有哪些
① 需求评审
阅读需求，理解需求，查看是否有不符合逻辑的需求，明确测试周期。
② 测试计划
根据项目计划和开发人员的时候指定测试计划，包含测试内容、测试规划、测试环境、项目的任务和目的。
③ 设计测试用例
核心模块，设计测试用例常用方式有：等价类、边界值、场景法、判定表等。
④ 用例评审
确认结果的准确性，避免遗漏。
⑤ 执行测试用例
搭建好环境后进行冒烟测试，功能测试，兼容性测试，接口测试，性能测试，系统测试等。
⑥ 测试报告
概述项目内容，报告测试用例的执行情况，统计测试结果，测试评估，判断是否符合用户标准。
►►►
测试中的测试流程？（结合自己的项目经历）
和上面差不多，主要是结合项目把上面具体化
例如：
需求评审：团队的人员（产品经理、项目经理、开发人员、测试人员）一起探讨，明确需求，确定需求的可行性；
指定测试计划：明确各个人员的工作内容和时间，同一测试使用的工具；
设计测试用例；
编码，执行测试用例，发现bug，并修改；
回归测试，验收测试。
►►►
对bug的描述？
表名bug的标题（尽可能详细，最好可以通过标题就看透bug）；
测试的版本；
测试环境：电脑版本号、浏览器版本、编译器类型等；
具体的测试步骤；
预期结果；
实际结果；
错误截图、日志等。
bug的周期
发现BUG–>提交BUG–>指派BUG–>研发确认BUG–>研发去修复BUG–>回归验证BUG–>是否通过验证–>关闭BUG
►►►与开发产生分歧，你会这么做？
例如：你觉得这个是bug，而开发觉得不是
首先明确一点就是开发和测试对bug的定义不一样，出发的角度不一样，开发可能对bug的敏感度低一点。
当出现分歧的时候，应该主动从自己的角度告诉他自己认为这是bug的原因以及可以支撑自己结论的截图等，并让他也说出她的观点和看法，根据产品的需求和最初的测试计划出发，判断这个是不是bug，也可以请来项目经理和产品经理从他们旁观者的角度做出他们的判断
►►►
http和ttps的区别？
http是用于传输HTML等超媒体文档的运行在TCP上的基于应用层的协议，是互联网应用最广泛的传输协议，端口号是80，是明文的无状态的，不需要证书的；
https是http的安全版本，加入了SSL层，比http更安全，端口号是443，传输，需要资金来申请证书。
►►►
get方法和post方法的区别？
get方法使用URL或者cookie传参，post把数据存在body里；
get的URL长度有限，post的数据可以很大；
get的可以在地址栏看见，不安全，机密信息用post传输；
get用户查数据，post用于增、删、改、提交数据。
►►►
接口测常出现的问题？
传递正确的参数，结果是否正确；
参数的类型和长度等有限制，在测试时应该总和考虑，进行排列组合，保证覆盖所有情况；
我提交订单的时候，传递金额的参数做出修改，后台是否有验证，付款的时候，利用抓包修改金额，如果我以这个金额付款了，说明接口有问题；
登录网站的时候会对我们的信息进行存储，如果信息不就会损害我们的利益；
设置密码的时候各种验证和条件；
特点用户的权限，普通用户是否可以。
►►►
依赖登录的接口如何处理？
登录后产生的token，将其存放在json等配置文件里，等其他接口想用的时候，直接引入这个配置文件的变量的参数就行，如果是cookie还可以引入session关联
►►►
fiddler如何抓包？
电脑端打开fiddler后，打开浏览器后，fiddler会自动开启本地代理，进行抓包，获取请求和参数。
手机端需要在网络处进行设置，设置成登录fiddler的电脑的IP地址和8888端口，把fiddler作为代理服务器，连接手机和fiddler后进行抓包
►►►
总结
想象困难做出的反应，不是逃避或绕开它们，而是面对它们，同它们打交道，以一种进取的和明智的方式同它们奋斗。
成功根本没有秘诀可言，如果有的话，就有两个：第一个就是坚持到底，永不言弃；第二个就是当你想放弃的时候，回过头来看看第一个秘诀，坚持到底，永不言弃。
一生中，只要心淡如菊，声名显著，就会守之以敛藏；人生，顺其自然，淡然处之，你的生活就会充满阳光，人生就会幸福快乐，生命就会精彩灿烂。
