【10w字】超详细【百分百拿offer】的面试教程，集合5000多家软件测试公司面试题。
一、引言
1.1 文档目的
【百分百解决在面试中遇到的些问题】
1.2 背景
此文档历经1年的时间，基本概括了深圳与广州，上干家公司的面试问题并结合基本盖了，95%以上的面试问题，文章内容比较多耐心看完必能拿下心仪的offer。在这里祝每一个面试人顺利拿下面试。
二、职业规划
2.1 简单的自我介绍下
面试宫，您好，我叫XXX，来自于XXXX，目前从事软件测试工作，已经三年工作经验，个人性格，比较开朗，跟人关系比较好，做事也比较细心三年测试工作经验中，过了不少项目，积累不少项目经验，前面1-2年主要是功能测试，后面这一年主要做接口测试，app自动化测试能够独立完成软件产品测试工作，能够独立编写测试文档，包括用例，计划，报告等，熟悉lnux跟数据库，熟悉 jmeter与 python + request进行接口测试，也可以使用 pytest框架进行接口自动化测试， python + selenium + pytest框架进行自动化测试，python + appnium + pytest移动app自动化测试框架，熟悉使用Jenkins持续集成，熟悉app专项测试与小程序测试，熟悉抓包工具。
我个人平常喜欢…看书…
我个人觉得测试这一块，主要是对需求了解，需求理解到位，工作当中，一定细心耐心，技术这块，不断学习能力
如果面试没有说话， 这个是我的一个简单自我介绍，看面试官还有什么需要了解的
2.2 为什么离职
①、尽量谈化敏感答案比如，人际关系不好处理，与上司相处不好、工作压力大等。
人际关系复杂，现代企业讲求团队精神，要求所有成员都能有与别人合作的能力，你对人际关系的胆怯和避讳，可能会被认为是心理状况不佳，处于忧郁焦躁孤独的心境之中，从而妨碍了你的从业取向。
收入太低，这样回答会使对方认为你是单纯为了收入取向，很计较个人得失，并且会把“如有更高的收入，会毫不犹豫地跳槽而去的”这种观念形成对你的思维定势。
分配不公平。现在企业中实行效益薪金、浮动工资制度是很普遍的，旨在用物质刺激手段提高业绩和效率；同时，很多单位都开始了员工收入保密的措施，如果你在面试时将此作为离开原单位的借口，则一方面你将失去竟争优势，另一方面你会有爱打探别人收入乃至隐私的嫌疑。
工作压力太大。现代企业生存状况是快节奏的，企业中的各色人等皆处于高强度的工作生存状态下，有的单位在招聘启事上干脆直言相告，要求应聘者能在压力下完成工作，这是越来越明显的趋向
②、尽量采用与工作能力关系不大、能为人所理解的离职原因。
寻求更大的发展：现有的企业岗位设置难以满足自身职业进一步发展的要求，
换一个更好的平台来挑战自我。
原公司发生了重大客观变化：公司重组或部内部变动，导致工作内容发生重大变化，
无法再继续履行劳动合同，或者直接被裁员等
与公司文化无法融合：每一家企业其实都有自己特有的“文化”，如果你在这家公司里工作，
却无法认可这家公司提倡的一些文化，这就会对企业的发展以及对自己的发展都非常的不利。
所以你想要走出企业的束缚，找到一家跟你更契合的公司工作也是可以的。
个人原因：上班太远影响工作、家中有事、充电、休假、生病等等。注意：避免敏感答案，
并不意味着欺骗，如招聘人员问及细节问题，应如实回答。否则求职者的诚信度可能大打折扣，
成功可能性更小。
③、不要诋毁你的老东家
相信很少会有人犯这样的错误，这的确是一个不可取的方式，你应该把你的离职原因集中表述
在“寻找新机会或新的平台”以及尝试在新的岗位上提升自己。职场虽然没有战争那么血腥，
但也有很多委屈、不被理解或被无故受伤，这些都很正常的。我们要用一颗阳光的心去面对，
用一颗阳光的心去照耀。
在离职后，永远要用赞美的词语来评价你的老东家，哪怕他在公开场合去骂你，你都要用最美的词语去评价他。别忘记，你赞美他，是你素养高;他骂你，是他素质的问题。你永远改变不了别人，但你有能力改变自己。
④、体现你的忠诚度
如果你轻描淡写地就离开了之前的团队，那么面试官会觉得你在新公司也可能会轻易走人，
所以，在体现忠诚度的时候，你可以试着谈谈你离开上一家公司时有多么痛苦依依不舍（即使并没有)，聊聊如果有办法使你能在原来的岗位上持续得到提升或者如果不是因为股东之间的权利斗争（可适当显得痛心疾首些），你肯定不会离开。
而在体现责任感时，你需要表达两层意思：
首先，你从上家公司离职时已经为继任者做了充分的交接。你需要清楚地表明：你在上家公司也很认真尽职，并且同事之间一直保持互助互利的工作氛围。也许你可以说说你也想过要早些辞职，但是考虑某个未完成的重要项目、或是继任者短期内还不能胜任角色所以晚了一些。
其次，就是你很期望承担新的职责，并表现出你的热枕，这种热枕除了对工作的热忱之外，
也可以适当的通过向你的面试官（不仅是HR）提问表现出来对面试官的兴趣、对他们技能的
认可以及共鸣，例如，“那么，你是如何做到现任职位的?”或：“如果我有幸担任这个职位，
你会给我哪些建议?”
通用说法：家人在这边，或者想到大城市发展。
2.3 加班的看法
1、(将问题抛给HR，)在回答您的问题之前我想了解一下贵公司的加班制度是怎样的。
(这种回答，其实是把问题抛回给HR，让HR表明公司对于加班的态度，其实很多大公司
对于加班都有明确的规定，什么情况该加班，加班会有什么福利等等问题都是确定的，
而小公司就随意很多，往往是老板要求加班员工就得无条件加斑。因此，如果公司的加班制度明确，
那么HR就能够明确地向你介绍，你在了解过后再给出回应也不迟。面试本就是双向选择的过程，
你也没必要为了通过面试，满口答应自己愿意加斑。)
2、在IT行业里，加班是比较正常的，首先我会了解加班的原因，如果公司近段时间需要赶
项目进度或者是站在重要的关键节点上需要加班，我会站守自己的岗位，把自己手上的事做好，
和团队一起加班，让公司按预期的进度推进项目，这在我看来是必要的加班，
如果是其他的原因，比如个人原因，我会努力不加班，在保证工作质量的前提下，
我会提高自己的工作效率，避免加班。
如果说公司基本上天天都要加班，加班的频车较高，我希望可以减少不必要的加班，让员工
得到充分的休息，有休息才会把工作效率提升上来，工作才会更有效率，另外有些工作上的
能力炼可以在其它地方，而不在工作的本身，比如对生活的理解和感悟等之类，
是从工作中学习不到的，正所谓功夫在诗外嘛。
还有，我之前在上一个公司上班，住的地方离公司较远，作为一个女生，出于个人人身安全考虑，
我更希望不加班，毕竟生命健康是从事一切活动的前提嘛。
通用说法：如果项目组比较忙，加班是没有问题的。
2.4 你还有什么问题要问?
少问一些福利相关的问题
1.公司现在做什么项目 2.公司目前做哪方面测试 3.公司这边测试人员分配比例
4.进入公司，我这边大概的工作安排 5，公司这么后续发展机会还有培养
6，有没有培训 7，面试没有回答上的问题，再去请教
2.5 你的职业发展规划和职业目标
根据公司况，个人原因来说：看公司的岗位要求，招岗位就是攻能
公司只做功能测过
接下来一年时间内，更加完善自己的功能测试，2-3年内熟自动化或者性能，
3-5年内系统成为自动化或者性能，成为资深技术人员
公司做自动化与性能测试
1-2年内熟恐自动化或者性能，3-5系统成为自动化或者性能，成为资深技术人员性能与自动测试
找一个比较稳定平台，跟公司长期发展，后期走管理或者产品路线
2.6 你最近测试的论坛和网站是什么?
工作中积累，查看网站论坛(51 testing)，CSDN，书籍《性能测试专家》，《性能之巅》
偏开发， python自动化， selenium自动化
2.7 对于一个新的工具你有什么看法
1.自己先去研究 2，找会的去请教 3，百度去找资料 4，工具原始文档
2.8 你做了3年测试收获，你的测试心得
3年的测试经验，对我来说也是3年的工作经验，在这3年的工作经验当中，我觉得态度比能力要重要，做好一个测试，最主要是性格，信心，耐心，细心还需要良好的沟通能力。不断学习的能力，产品质量，测试流程这块很关键，好的计划加好的执行才能成就好的产品。
2.9 怎么转行的，毕业之后一直从事软件测试吗
非专业
1、培训，不要说刚培训出来
2、自学，不断一直学习
3、家里有关系，带你入行，后面学习过程很勤奋
计算机相关专业
1，实习开始，公司分配到做测试，做测试过程，比较喜欢测试，一直做下来
2.10 以前在哪里上班，公司地址，测试多少人，开发多少人【个人编写】
根据你简历上面写的，公司详细地址
产品1、项目1个、架构师1个、前端3个、后端 5个、0os 1个、Android 1个，
测试3个(测试主管，核心测试人员)、运维1个、ui 1个
2.11 你的期望薪资是多少?
1，期望薪资不要说区间比如说：10-12，那肯定是10
2，如果原来公司在二线城市原有薪资不要说太高，
3，深圳那边薪资，比广州高10% - 15%
2.12 多久能入职?
1，公司比较满意，直接随时过去。
2，不是很满意，下周一，个人有点事情，比如说回家一趟等等。
2.13 是怎么考虑做软件测试呢?
1、个人性格合适 2、前景还可以 3、个人技能也匹配
2.14 是否有考虑往开发方面测试?
我觉得，IT行业，没有具体的界限，后期，开发也要懂测试，测试也要懂开发，
如果公司有机会，愿意去尝试
2.15 计算机专业课程有哪些?
公共课程：数学(高等数学、线性代数、概率论与数理统计、离散数学、数值分析)，
政治(马克思主义思想概论、毛泽东思想概论与中国特色社会主义思想、
思想道德修养与法律基础、中国近现代史纲要)、大学英语、体育。
专业基础课程：电路原理、模拟电子技术、数字逻辑、微机原理、汇编语言、操作系统原理、
编译原理、算法与数据结构、面向对象方法、C语言/C++语言等。
专业方向课程：计算机数据库原理、python语言、图形学、人工智能，多媒体技术、
网络安全、人机交互、无线互联网技术、软件开发方法、高性能技术系统仿真和虚拟现实等。
大专3年、本科4年，
本科四级、大学英语四级及格425分、总分710
2.16 说一下上一个公司背景?
了解公司主要是什么项目，百度查下，
如果公司主营产品跟你项目不匹配
比如：原来公司做医疗设备，那就说：我们是项目外包的部门，专门接项目
2.17 超过26岁女孩子，目前有没有打算结婚 【无歧视女性】
暂时没有结婚的计划与打算，如果已经有小孩，说暂时不考虑二胎，
有小孩，可以说小孩在老家(原来有朋友因为这个问题，被公司pas过)
三、测试理论
3.1 你们原来项目的测试流程是怎么样的?
我们的测试流程主要有三个阶段：需求了解分析、测试准备、测试执行。
1、需求了解分析阶段
我们的SE会把需求文档给我们自己先去了解一到两天这样，之后我们会有一个需求澄清会议，
我们会把不明白不理解的需求在会议上说出来，包含需求的合理性还有需求的可测性等，
产品这边解答，目的是让我们测试这边和开发对需求的理解达到一致。
2、测试准备阶段
会议结束之后我们开始准备测试工作，我们测试这边会写一个测试计划，分配每个人负责的模块，
然后我们就根据自己负责的模块用 xmind(思维导图)进行测试需求分析，分析测试点，
以及编写测试用例，之后我们会在自己的组内先进行评审，评审修改之后还会在我们的项目组评审，
评审完后进行修改测试用例。
3、测试执行阶段
开发人员编写好代码之后，我们会把代码包通过 Jelkins部署到测试环境提测，进行SIT测试，
在正式测试之前我们会先做一个冒烟测试，冒烟测试通过之后我们才转测，在执行测试的过程中，
我们如果发现bug就会用tapd(或者禅道)记录并且提交bug，也会进行bug复测，以及回归测试，
每一轮测试结束之后我们都会写一个测试报告，一般情况下，测试4-5轮之后会达到上线要求，
当达到上线的标准后，测试报告会认为测试通过，上线前我们会做预发布测试，预发布通过后，
由项目组与产品决定时间上线，上线完成，一周左右我们会写一个项目总结测试报告，
总结我们在上一个版本中遇到的问题以及今后有哪些地方需要改进，在产品选代过程中，
我们会跑自动化用例来进行回归测试。
3.2 如果需求不明确的话你怎么办?
需求不明确的话我会在需求澄清会议上面提出来，问清楚这个需求只有明确需求，
才能更好的完成工作，后续工作中还是不清楚，可以找产品再去确认这个需求。
3.3 有哪些需要评审，哪些人在
1、 xmind思维导图评审，主要是测试人员
2、测试用例需要评审，测试人员，开发人员，产品人员
3、需求文档，项目组所有的人员，都会到场
阶段总结：
现阶段很多人都在说软件测试太内卷了，工作太难找了，竞争太激烈了。那么如何在这样的现状下使得自己更具有竞争力呢？笔者认为大家需要迅速学习软件测试的硬技能，提升自己的业务能力，早日摆脱初中级测试的Title，虽然测试人员众多，但是高级的软件测试人员还是很稀缺，有很多人挂着高级测试的头衔却还在干着初中级测试的活。在掌握这些硬技能的同时，软技能的培养同样重要，沟通能力、自主学习能力越来越被企业看重。
如果不想被这个时代淘汰，就要做好持续学习的准备。下方给大家准备了全套的软件测试，自动化测试全套教程。
【需要的可以点击文章末尾官方推广小卡片扫码备注000免费领取】
3.4 有没有写过测试计划，具体包括哪些内容?
参考答案1：
测试计划内容：
(1)目的和范围 (2)规程 (3)测试方案和方法 (4)测试的准入和准出
(5)测试计划(流程、时间安排、对应人员) (6)测试的环境配置和人员安排 (7)交付件
参考答案2
我们公司之前按照考核要求写过测试计划，不过后面老大觉得太耽误工作进度，
后面一般都不再写测试计划，而是写版本计划，这个在版本计划，每个人的任务列出来，
负责人列出来，自己根据自己的情况分配时间，然后汇总，大家一起开个小会评审就可以了。
3.5 用例包含哪些部分，哪些用例设计方法，你一般常用哪些方法?
原来我们用例包含
测试项目，用例编号、测试标题、优先级、预置条件、操作步骤、测试数据、预期结果
黑盒测试用例设计方法：主要是等价类、边界值、错误推测法、判定表、因果图、正交表、
流程分析法、状态迁移法、异常分析法。
常用的：等价类、边界值、判定表、流程分析法、错误推测法。
等价类是指某个输入域的子集合，在该子集合中，
各个输入数据对于揭露程序中的错误都是等效的，
并合理地假定：测试某等价类的代表值就等于对这一类其它值的测试，因此，可以把全部
输入数据合理划分为若干等价类，在每一个等价类中取一个数据作为测试的输入条件，
就可以用少量代表性的测试数据取得较好的测试结果，
等价类划分可有两种不同的情况有效等价类和无效等价类。
边界值的话就是对等价类划分方法的补充。测试工作经验告诉我，大量的错误往往是发生在输入或输出范围的边界上而不是发生在输入输出范围的内部，因此的话针对各种边界情况来设计测试用例，可以查出更多的错误，使用边界值分析方法设计测试用例的话，首先应该确定边界情况，通常输入和输出等价类的边界，就是应着重测试的边界情况应当选取正好等于，刚刚大于或刚刚小于边界的值作为测试数据，而不是选取等价类中的典型值或任意值作为测试数据。
对于错误推断法，这个是基于经验和直觉推测程序中所有可能存在的各种错误，
从而有针对性的去设计测试用例的方法的，主要就是列举出程序中所有可能有的错误和容易发生错误的特殊情况去根据这些情况来选择测试用例，例如，在单元测试时曾列出的许多在模块中常见的错误以前产品测试中曾经发现的错误等，这些就是经验的总结。还有，输入数据和输出数据为0的情况。
输入表格为空格或输入表格只有一行。这些都是容易发生错误的情况，可选择这些情况下的例子作为测试用例。
前面介绍的等价类划分方法和边界值分析方法都是着重考虑输入条件但都没有考虑输入条件之间的联系，相互组合等等的情况。考虑输入条件之间的相互组合，可能会产生一些新的情况，
但是要检查输入条件的组合并不是一件容易的事情，即使把所有输入条件划分成等价类，
他们之间的组合情况也相当多，因此的话可以考虑采用一种适合于描述对于多种条件的组合，
相应产生多个动作的形式来考虑设计测试用例，这就需要用到因果图(逻辑模型)。
因果图方法最终生成的就是判定表它适合检查程序输入条件的各种组合情况。
3.6 TestLink工具使用?
(1)创建用户，并给新创建的用户指定权限。
(2)创建测试用例，对测试用例进行增、删、改、查
(3)把测试用例关联到对应的测试计划中。
(4)把测试用例指派给对应的测试人员。
(5)对应的测试人员，查看被指派的测试用例，并执行测试用例。
3.7 如何提交一个好的BUG
对BUG有一个清晰明了的描述； 详细描述BUG重现的步骤
对于产生BUG的环境进行描述； 提交BUG相关的图片和日志;
定位好BUG的等级； 将预期结果与实际结果进行对比。
3.8 提bug需要注意哪些问题?
- 不要急着提交，先跟开发说明bug的情况，定位分析下bug。
是前端问题还是后端问题再去提交bug。
- 简单明了的概括bug标题，清晰的描述bug重现步骤，分析bug和预期正确结果，附加bug的截图或者日志。描述bug的时候。
- 在不能确认该情况是否为bug的时候，可以请教其他人。
- 提交完bug以后，后面还要跟踪bug修复情况。
3.9 bug怎么管理的，bug的生命周期或者是bug的状态
原来bug是用禅道来管理的
原来我们公司bug，提交bug直接给对应的开发人员，对应开发人员修复完成，交给测试复测，
复测通过关闭bug，不通过打回给对应开发。
提交-开发人员(已激活未确认)-开发进行确认，状态变成已激活，已确认，开发修复完成，
标注状态是已修复，测试人员复测通过，已关闭，打回给对应开发，已经激活。
3.10 提交bug包含哪些内容
所属产品、所属模块、所属项目、影响版本、指派人员
截止日期、严重程度、优先级、bug类型、bug环境
Bug标题、重现步骤、附件
3.11 你提交的bug，开发不认可怎么办?
首先我会再看需求文档，是不是我的理解有误，如果是我对需求理解错的话我就去关闭bug。
如果是bug再去让其他测试人员看看听下他们的意见，然后自己先再三去复测，并目保存好截图和日志，确定这是一个bug之后我就去跟开发说明白，并且给他看bug重现的截图以及日志，如果开发还是不认可的话我就跟产品或项目经理说明白情况。
3.12 对应无法重现bug，应该怎么处理?
首先，我会多测几次，测了好多次都无法重现的话我就先把bug挂起，并且留意一下，看看往后的测试中，如果在后面的测试中重现bug就激活，如果经过几个版本都还没发现的话就关闭bug。
3.13 界面中的乱码可以是哪里导致的?
(1)数据库中的编码设置 (2)前端页面编码 (3)后台代码也会编码
3.14 bug的级别有哪些，级别如何判断
1、致命：对业务有至关重要的影响，业务系统完全丧失业务功能，无法再继续进行，
或业务系统丢失了业务数据且无法恢复，影响公司运营的重要业务数据出错。
2、严重：对业务有严重的影响，业务系统已经丧失可部分的重要的业务功能，或业务系统
丢失了业务数据且可以恢复，一般业务数据出错。
- 一般：对业务有较小的影响，业务系统丧失了较少的业务功能，
例如：界面错误，打印或显示格式错误。
- 提示：对业务没有影响，不影响业务过程正常进行，
例如：辅助说明描述不清楚，提示不明确的错误提示。
3.15 测试中，如何判断是前端的bug还是后端的bug呢?
通常可以利用抓包工具来进行分析。可以从三个方面进行分析：请求接口、传参数、响应。
1）请求接口un是否正确如果请求的接口ur错误，为前端的bug
2）传参是否正确如果传参不正确，为前端的bug
3）请求接口u和传参都正确，查看响应是否正确如果响应内容不正确，为后端bug
4）也可以在浏览器控制台输入js代码调试进行分析
3.16 项目上线后发现bug，测试人员应该怎么办
看严重级别：严重还是不严重
严重的：紧急变更上线
不严重：修复好后跟下个版本一起上线
用户会通过运维反馈到项目组这边，项目经理会根据功能模块的负责人，分给对应的开发与测试。
测试人员：编写对应的测试用例、测试环境中重现bug、提交bug、
交给开发进行修复、修复完成bug、进行bug的复测。
如果测试环境无法重现，可以导入生产环境的包到测试环境中测试，
还是不能复现，查看生产环境的日志去定位问题。
3.17 如何保证质量
(1)需求要吃透，多问，多去了解。
(2)严格按照测试流程去执行：多考虑用户测试场景，使用测试用例设计方法，多评审。
(3)要有良好的测试执行：要求用例执行率达到100%，多轮测试，进行探索性测试，
需要测试之间交叉测试，用工具来管理我们的测试工作(禅道， testlink， excel，tapd)
(4)不断的反思与提升。
3.18 产品是怎么上线的?
一般我们会选择晚上上线，开发测试还有产品全部到场，进行上线测试。
首先，开发将代码打包到生产环境的服务器中，如果数据表有变化，就会运行sql文件，
对表的一些操作，接着，我们测试就开始先测试主体业务功能以及新增的功能模块;
测试通过之后，我们会在界面上把上线测试的数据删除，正常上线。
如果发现bug，开发人员当场修复bug，修复成功之后我们测试再复测，通过就可以正常上线
如果发现了bug开发人员在上线规定时间之前都还没有修复好的话，就看问题的严重性，
如果严重就延期上线，如果我们是迭代版本的话我们还需要版本回滚。
如果不严重，产品跟客户觉得可以上线，就正常上线。
3.19 你测试数据是从哪里获得?怎么获得的，假如不告诉你，你怎么处理?
- 一般都是我们测试人员在测试过程自己造的测试数据，如果大量数据，我们可以用到存储过程。
- 也可以让运维人员帮忙从生产环境导出相关的测试数据，如果测试数据中涉及安全性的数据，
直接是不能导出。
3.20 如何测试万分之一概率问题
- 用 Jmeter或者其他自动化测试工具造大量数据
- 让开发修改概率的比例
3.21 为什么要写测试用例?
1)提高测试效率 2)提高测试覆盖率 3)监控测试进度情况 4)也是质量的标准指标
CMM质量体系(用例数也是一个度量标准QA岗位)
3.22 那你们测试用例是怎么编写的
原来我们主要是用exce编写的，当然也用过用禅道， testlink去编写，禅道都是excel表格编写完成，导入禅道系统， testlink也可以Exce表格，编写，编写测试，导入 testlink
3.23 有没有写过测试报告，具体包括哪些内容?
参考答案1：
1)项目背景和目的 2)测试用例设计 3)测试环境 4)测试过程用到的工具
5)测试范围 6)测试用例执行情况 7)测试缺陷分析和总结 8)测试结果
参考答案2：
这个是写过的，测试报告，其实就是把我们测试的整个过程情况，数据统计，做成报告，包括用例执行情况，测试了哪些模块，多少用例，会哪里模块，自动化通过率，自动化跑了多少，是否全部通过，发现了多少bug，bug的情况，是否遗漏bug，测试结论等等这些，基本就这些。
3.24 测试报告中测试的结论是什么?
测试报告里面有个测试结论：
- bug的情况、bug级别、bug分布情况(分布哪些模块)、
bug产生原因(设计问题，需求问题，代码问题)
2）测试是否通过
3.25 如何写好一个测试用例
能够发现bug的用例就是一个好的测试用例
当然我们在编写测试用例的时候，一定要步骤、场景清晰、尽量去覆盖所有的测试场景
3.26 什么是冒烟测试? 在什么时候进行冒烟测试?
冒烟测试一般我们是在系统测试之前，对所有主体的业务功能，测试看是否存在严重bug，
如果存在严重bug，表示，冒烟测试不通过
3.27 回归测试策略
1）功能的回归
优先测试用例级别比较高的功能模块，可以进行自动化测试
如果时间够，进行全量测试
2）bug回归
复测这个bug，并且相关联的模块与功能也会测试一遍，以免由于修改bug导致其他问题产生
3.28 和开发沟通。是怎么沟通的
一般我在提bug的时候跟开发沟通最多，比如有一些不清晰的内容会去问开发，还有提完bug后会跟踪bug的进度，提醒开发尽快修复bug，还有测接口的时候去找开发拿接口文档，其实我们的工作跟开发都是息息相关的所以都经常都会有沟通的。
3.29 测试中有哪些风险
1）测试，需求理解上面有偏差
2）测试人员水平不够，测试人员覆盖点不全
3）测试人员时间不够，导致测试不完全
4)测试环境上面不足，导致测试点不能完全测试完成
3.30 怎么保证测试质量或者你怎么保证你100%覆盖了需求
把需求了解通透，引用用例评审机制，然后编写测试用例的时候用边界值，用等价类补充一些用例，根据过往经验用错误推断法来追加一些用例，如果存在组合情况的话我会用因果图或者判断表来编写，如果业务场景清晰的情况下我会用流程分析法，如果状态有发生改变的话我就会用状态迁移法。编写用例一个极其考验耐心的事情，要考虑到各种场景，全面覆盖到会出现的场景。
3.31 一个需求，7天要上线，你怎么做？
先跟面试官确定，产品什么是转测；
1）如果转测时间，在最近1-2天，直接了解需求开始测试。
2）如果三天后转测，一天半时间了解需求，一天写测试点和写测试用例，一天进行评审和修改测试用例，2天执行试用例与理交bug，最后一天半进行回归测试与编写测试报告。
3）如果4-5天后进行转测试，边开发边测试，一天半时间了解需求，一天写测试点和写测试用例，一天进行评审和修改测试用例，开始执行测试，开发一部分，我们就测试一部分。
3.32 产品上线评判的标准?
1）测试用例执行率100%，通过率95%
2）1-2级bug修复率达到100%，3-4级bug修复率达到95%
3.33 测试过程中，发现很多用例重复的，有的人认为没必要再测，你怎么看?
如果是同一个横块，重复用例，我们可以考虑不再进行重复测试，如果不同模块，引用相同的测试用例，我们还是需要重复测试
3.34上线后有没有另外的测试用例在生产环境里测试
有：我们会去单独去编写测试用例，只是主体流程用例，新增功能的用例
没有：我们会挑选原来测试用例中，级别比较高的用例去执行，或者我们建立一个 checklist列表，去检查功能是否正常使用。
3.35 什么是多分支开发和单分支开发?
git工具相当于svn工具，分支开发每个版本或者模块，开发不同模块，分支合并，把所有的功能全部整合起来，其实就划分功能模块去开发。
3.36 兼容性测试你们是怎么测的? app与web
Web：
不同的浏览器，E，谷歌，火狐，浏览器显示比例，浏览器前进，后退，刷新按钮。
App：
不同手机厂商，型号，系统版本，内存大小，分辨率，屏幕的大小，高端机与低端机，考虑平板
3.37 功能测试重复测试比较高，怎么看待这个问题?
1）对于测试来说，还是良好耐心，问题无法避免事情，重复的事情还是要去执行
2）重复事情，我们用自动化测试来进行替代
3.38 项目同时发布，你怎么处理?
1）确定下，我们几个项目是否可以同步发布完成
2）如果确定项目不是同时发布(时间问题，人员问题)
确定下项目的优先级，跟客户这边商量优先级低一些项目推迟发布(产品跟客户)
3.39 你们开发转测试怎么转的
1）开发人员发邮件告知对应的测试人员：新的代码地址、最新的sql文件、需求开发完成的情况。
2）测试人员把最新的代码和sql脚本更新到测试环境中，并进行冒烟测试，
要是冒烟测试不通过则转测失败。
3.40 你们的开发语言是什么？
java后台开发：
SSM spring + springy + mybaits（数据的封装）
SSH sprint + springmvc + hibernate
springboot
fianl极速开发框架
maven项目 pom.xml文件 ...中央仓库
python后台开发框架
Django flask
前端开发语言：
JavaScript + css+ html bootstrap框架 常用库： jquery简称JQ Es6/E57
php ThinkPHP框架
四、项目
4.1 简单介绍下最近做过的项目
根据自己的项目整理完成，要点：
1）项目背景、业务、需求、核心业务的流程
2）项目架构，B/S还是C/5，数据库用的什么? 中间件用的什么？后台什么语言开发的？
是否有做App端，是否有H5是否开发小程序等等。
3）项目前端有哪些功能模块，后台有哪些功能模块？
4.2 拿一个你所负责的模块，讲下具体怎么测的?
根据自己的项目整理完成，核心要点：
1）拿一个你负责过的模块，核心业务模块讲解
2）业务流程是怎样的，需求怎么样，有什么规则没，规则简单介绍
3）你是如何分析的，讲明分析思路，测试点，主要怎么考虑测试的，主要核心测试重点在哪里，
用了什么测试方法等等。
4.3 你在这个项目里面主要做了些什么工作？
- 在这个项目中，主要是以功能测试跟后台接口测试为主，主要参加了需求评审会议，用例的编写，
参与用例的评审，执行测试。
- 协助开发定位问题解决发现的bug，编写测试报告，协助上线。
- 另外就是做了APP的一些相关项测试，像兼容性测试、稳定性测试、安装卸载版本覆盖测试和app性能都是有做过的，例外后期有做过接口自动化等。主要就是做了这些工作。
[这个具体根据你自己的简历上写的来说]
4.4 你们项目组有多少人、开发多少个、测试多少个?
[公司具体人数，可以不太清楚，项目组多少一定清楚]
[这个一定要根据自己的简历项目大小来说，不能乱说]
产品1、项目1个、架构师1个、前端3个、后端5个、ios1个、Android 1个、
测试3个(测试主管，核心测试人员)、运维1个、UI一个
4.5 测试人员怎么分工的?
1）我们测试组3人，1个测试组长，2个测试，一般都是根据需求的复杂程度大小来，
尽量是自己熟悉哪个版块的就继续做那个版块。
- 比如：我这边主要是负责前端大部分的功能模块，还有接口测试跟ui自动化测试，另一个同事主要是功能测试这边，组长这边也负责一些功能测试，包括一些性能跟安全测试。
- 其实测试工作也划分的没有那么细，后期我们也会做交叉测试，相互测试功能，性能跟安全测试我也会参与一下。
4.6 项目的送代周期? 多久一选代? 一个版本你们发现多少bug
[切记工具自己所选择的项目来回答]
我们公司是这样的，迭代还是蛮快的，一般是两个星期一个迭代，迭代测试两轮。Bug的话不一定哦，关键还得看开发，哈哈，开发的版本质量好的话，BUG就会少些，整个版本比较好的情况下大概也就二十来个BUG，当然如果遇到开发是个新手，那么找到60-70个也是很常见的，比如之前的那个金融项目，足足发现了72个BUG，这样的情况下追踪BUG的工作量都比较的大，如果是版本选代的话，那么基本就不会出现多少BUG了。
参考答案2
因为我们项目的用户活动和三方合作平台比较多，一般半个月或者1个月肯定会有一个迭代版本，
假如用户或者合作方突然有很紧急的需求，那一般老大他们会向上发邮件和OA呈批给(产品经理，项目经理)，如果通过了就会马上加急处理这个需求，测试完成直接上线。
现在都是维护为主，但新需求也不断有，一般一个版本上百个bug是有的。
4.7 你们整个项目写了多少用例，你负责的模块大概写了多少用例?
[切记己根据自己的项目及负责的模块来]
答：这个得根据项目的复杂程度，我们最近做的这个也还好，整个项目写了大概2干3百多条(有点多了)，我负责的模块就写了一千多条(你要思考，你负责了哪些模块，大概评估下，不要乱喊)。
总结注意点：没有标准答案，先说你的前置条件，再说数据，只要你前置条件和数据匹配即可。
4.8 最近的版本写了多少用例?
(总结注意点：没有标准答案，先说你的前置条件，再说数据，只要你前置条件和数据匹配即可
特别注意：你如果是半个月的版本，一般给你两天写用例，你自己评估下写多少。
半个月的版本：1-2天需求分析，1-2天写用例，1天评审用例，其余的时间就是执行回归bug，编写测试报告)
最近的版本因为没有特别的用户活动，产品那边也没有给特别大的改动需求，我负责的
有5个模块吧，大概有180多条用例。
4.9 你的需求分析一般几天，用例大概写了多长时间?执行了多长时间?
如果按照2周一个版本来算的话，我们需求分析一般是由产品SE先组织我们开会，讲清新版本需求，然后我们再花1天到1天半时间去详细分析需求，另外有2天左右时间来写用例，写完用例会进行用例评审，后面的时间基本就是在执行用例，提bug，并跟进bug修复问题。
4.10 在uat测试的时候，突然客户临时要大量的数据
备注说明：uat：测试人员提供用例，uat环境已搭建好，他就开始来执行，如果发现问题，
需要协助，谁负责这个需求，就找对应的人，发现bug，提交到uat版本里面，修复完了，
客户需要回归验证的，我们公司只是辅助他去执行测试。
答案：
看他需要的数据能不能从上个版本，或者生产环境导入数据进来测试，如果没有，我们看能不能 批量修改数据去测试，如果不行，我们只能通过存储过程造数据了。
4.11 发现哪些映像比较深刻bug/经典bug?
根据自己的项目来准备，核心要点：
1）有哪些经典或者说影响比较深刻的Bug，最好是与业务相关的Bug，不要举例说前端的Bug
2）具体怎么分析，讲明你的分析过程。如何定位的......
比如:业务逻辑漏洞；
支付功能:
1）商品选择支付的时候，实际已扣款成功，但是用户后台显示该商品没有付款，
导致不能使用该商品提供的服务。
2）商品所显示的价格是x元，但是实际支付的时候显示和扣款的价格是y元(x≠y)
找密码流程：
按照常规操作，会直接跳跃了某个必须的流程(流程缺失)，但是通过url修改参数又可以访问到 该流程，存在安全和逻辑漏洞。
安全漏洞：
1）登录账户：退出or注销之后，浏览器返回键回退之后又可以回到已登录的页面继续操作，识 别用户身份的信息并没有失效，用登录后才能访问的url直接访问也可以登录，安全漏洞。
2）搜索功能：前端页面的搜索输入框中输入特殊敏感符号
(如script> alert(document.cookie)
cookie信息直接以弹框的形式暴露出来。
3）新增功能：一开始没有限制字符的类型和数量，当输入特殊符号、超长的字符，
提交后直接抛出包含有 INSERT INTO的完整SQL语句。
4）前端搜索：以敏感字符直接搜索后，客户端和服务端都没有任何字符过滤or转义处理，
直接把数据库和网站服务器的名称、版本暴露。
数据调用/加载异常:
1）翻页功能：有时候会出现前面几页翻页和数据显示都是正常的，往后再翻页就会
出现翻页不了or加载的数据异常。
- 前端页面有几级菜单的情况下，程序都已经调用过，第一级是正常展示的，但是第二级、
三级有可能被折叠而没有显示在浏览器显示。
3）定位到某个导航主题，调用的数据并不是该主题分类的数据，而是调用成了其他分类的数据。
不可逆操作，导致流程受阻：
1）APP测试，orH5页面测试，触发某个操作，比如手机触屏下滑刷新页面，不能恢复到操作前 的正常页面。
2）输入某个异常值提交之后，程序没有相关的处理机制，导致页面保存，没法继续进行其他操 作。
3）登录方式切换：登录时有几种不同的方式，如：密码登录&短信验证码登录，但同一时刻默认 只能显示一种登录方式，当从密码登录界面点击短信登录切换到短信验证码登录界面之后， 没有切换返回密码登录界面的功能。
4）删除异常：正常情况下可以从列表中删除记录，但是若先对列表记录执行了搜索功能之后， 再次删除的时候可能出现删除无响应而删除不了数据。
5）弹框阻止：当触发某个操作，如“保存”、提交”or某个开关按钮，界面中弹单出一个提示框， 此提示框不管怎么操作都无法关闭，直接阻碍了页面上其他功能的操作。
附件上传时，未控制格式尺寸和容量大小，系统处理出现异常：
1）文件上传功能：没有限制上传的文件格式、尺寸和大小，当上传非常规文件(如js文件)、大 容量文件(如：图片大小>20M)，较大分辨率(如：1600×1200)，服务器没有相应的异常处理 机制，导致网站出现持续长时间的卡顿，影响后续操作。
2）上传的是非常规的文件，如js格式文件，程序无相关控制，直接将js文件上传到数据库， 前端页面访问时若不能解析则出现异常页面。
缺少非空判断，服务器报500错误：
1）编辑包含多个字段的页面时，有一些字段在程序中控制是必填的(事先未知)，但是没有任何 说明提示，当不填写这些字段，直接保存时会出现服务器异常页面，报500状态错误。(特别 是在管理后台容易出现此场景)
2）在形如以下结构的if函数中，关系表达式的条件没有对某个变量(该变量因代码疏漏未作初 始化赋值)进行非空判断，就直接执行语句体，程序已空值null进行参与运算而出现异常， 如500错误if(关系表达式)样式导致异常。
3）某个功能(如：金额输入和统计)在A页面程序限制只能输入正整数，而在B页面却没有相应 控制，若不小心在B页面输入了非正整数，比方小数，A和B的数据分别传递到到同一个C 页面时数据处理会出现异常。
4）文章上传/图片上传：超长字符的文章内容or较大尺寸的图片上传，程序没有进行相关的压 缩和截取，直接完全调取到前端页面，导致浏览样式异常，
App测试过程中常Bug: https：/www.cnblogs.com/123456ww/12198075.html
[经典bug：前端申请借款中，用户没有信用额度或者借款金额超过了用户信用额度但是却能成功提交审核]
[发现途径：我是在模拟借款人，借款金额提示我的可用额度为0，但是我输入5000的借款金额点击提交审核提示我提交成功，等待审核]
[解决：首先我去数据库查找到对应的表，比对我的信用额度跟界面显示的数据是否一样，一样我就把数据库的记录，填写的借款信息和我借款成功的界面显示截图都保存好。之后提交这个bug，开发人员通过修改代码，我再复测，有没有重现bug]
[还有一个就是在借款流程中，我们通过修改数据库中的数据，把借款时间修改了，制造出一个逾期未还款的数据，结果显示还款的金额比借款金额还少，而且管理要收得特别高，存在不合理性]
[还有一个是在产品上线后，运维人员在统计数据时发现少了一条数据，我们去数据库检查发现0分0秒的数据没有统计，后来开发人员修改了代码之后就解决了]
1）服务费计算错误，计算公式开发这边写错，本来是利息0.3，写成003，开发修复bug。
2）退出用户，后退还可以进入到原来的登录完成操作后的界面，原始，退出用户，没有删除用 户对应的 session，导致后退完成后，用户用户 cookie可以进行操作。
3）重新选择下拉框，输入信息全部清空，原因，修改类型，重新刷新界面，输入数据，并没有 保存缓存里面，导致一刷新，原来信息没有，解决，开发选择不同借款类型，不再进行刷新。
4）借款标题，输入xss攻击代码，导致接口所有的数据不存在显示，因为xss脚本，当然代码 处理，开发这边进行转义字符串。
5）谷歌浏览器登录不成功，显示验证码。
4.12 每个阶段测试开发在干嘛（比如你写用例的时候开发在干嘛？）
1）需求阶段，大家都在了解需求
2）测试准备，
测试编写用例，开发做概要设计，详细设计，然后就是编写代码，编写接口文档，设计文档。
- 测试执行阶段，
测试人员执行用例，发现bug、提交bug、开发修复bug(开发还有可能在开发未完成的功能)
4.13 你们公司是否敏捷开发
可以说是，也可以说不是。[具体看你了不了解敏捷开发模式]
[问了我有没有做过敏捷测试]
扩展知识储备：
1、什么是敏捷开发
敏捷开发以用户的需求进化为核心，采用达代、循序渐进的方法进行软件开发。
在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，
具语可视、可集成和可运行使用的特征，换言之，就是把一个大项目分为多个相互联系，
但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。
2、敏捷开发优缺点：
特点：
- 能适应快速的客户需求变化，快速的交付，注重与客户的沟通。最优先要做的是通过尽早的、
持续的交付有价值的软件，把项目拆分成各个小的子项目，快速开发快速交付，有问题及时调整， 适合高风睑项目。
- 交付周期短，交付的时间间隔越短越好，一周一个迭送代，甚至有时候一周多个选代，
不过每个选代版本的需求不会太多，注重项目持续选代开发交付。
- 整个项目开发期间，业务人员和开发人员必须天天都在一起工作，团队规模不能太大，
团队间强调面对面的交谈。
4、更关注可交付可以使用的软件，而非文档。
5、对团队技术要求高，能快速适应客户对需求的变化。
6、敏捷团队只专注于开发项目中当前最需要的、最具价值的部分。这样能很快地投入开发，另外， 较短的迭代周期使团队成员能迅速进入开发状态。
优点：
1、敏捷开发的高适应性，以人为本的特性，适应客户的更快需求变化，更快的交付成果。
2.更加的灵活并且更加充分的利用了每个开发者的优势，调动了每个人的工作热情。
缺点：
1、由于其项目周期很长，所以很难保证开发的人员不更换，而没有文档就会造成在交
接的过程中出现很大的困难。
2.特别项目存在新手比较多时，老员工比较累.(对开发团队人员的技木要求高)
3、敏捷开发流程图：
4.14 你这个项目做了多久? 你这个项目现在的用户里有多少? 活跃量多少?
时间根据简历来
比如：一年时间，金融项目：100W用户2W活跃用户
五、测试思维
5.1 打电话功能怎么去测？
我们会从几个方面去测试：界面、功能、兼容性、易用性、安全、性能、异常。
1）界面我们会测试下是否跟界面原型图一致，考虑浏览器不同显示比例，屏幕分辨率。
2）功能：给不同人员打电话，不同号码打电话，不同运营商，测试每个按钮是否正常使用，拨打号 码，是输入还是，复制过程，还是其他地方跳转过来，多次拨打电话，双卡选择不同电话卡。
3）兼容性：不同手机型号，厂商，不同系统版本，屏幕大小，分辨率，内存大小
4）易用性：操作是否说的越多越好
5.2 给你一个杯子怎么测？
功能测试：
主要关注水杯基本功能
1、水杯是否可以正常装水
2、水杯是否可以正常喝水
3、水杯是否有盖子，盖子是否可以正常盖住
4、水杯是否有保温功能，保温功能是否正常保温
5、水杯是否会漏水，盖住盖子拧紧后是否会漏水
界面测试：
主要关注水杯外观、颜色、设计等方面
1、外观是否完整
2、外观是否舒适
3、颜色搭配及使用是否让人感到舒适
4、杯子外观大小是否适中
5、杯子是否有图案，图案是否易磨损
易用性测试：
主要关注水杯使用是否方便
1、水杯喝水时否方便
2、水杯拿起放下是否方便，这里会行注到水杯形状的测试
3、水杯装水是否方便
4、水杯携带是否方方便
5、水杯是否有防清功能
6、水杯装有低温或者高温水时，是否会让手感到不适
性能测试：
1、水杯装满水时，是否会露出来
2、水杯最大使用次数
3、水杯的保温性是否达到要求
4、水杯的耐寒性是否达到要求
5、水杯的耐热性是否达到要求
6、水杯掉落时时，是否可以正常使用
7、水杯长时间放置时，是否会发生泄露
兼容性测试：
主要关注水杯是否可以装其他液体，如果汁、汽油、酒精等
可移植性测试：
主要关注水杯放置环境等
1、将水杯放在常温环境中，使用是否正常
2、将水杯放在零下的环境中，使用是否正常
3、将水杯放在高于正常温度的环境中，使用是否正常
安全性测试：
主要关注水杯外观和各种异常条件下是否释放有毒物质等
1、当水杯装满热水时，水杯是否会烫手
2、当水杯装上水后，是否会产生有毒物质
3、把水杯放在零下环境时，是否会产生有毒物质
4、把水杯放在高温环境时，是否会产生有毒物质
5.3 图像上传功能的测试点
1.检查图片上传路径
2.检查图像上传和修改功能
3.检查各种扩展图像文件的上传（例如JPEG、PNG、BMP等）
4.检查文件名中含有空格或其他可用特殊字符的图片的上传
5.检查重复名称图片上传
6.图片尺寸大于最大允许值，上传时应该显示适当的错误消息
7.检查上传的图片文件类型外的其它文件时(例如txt、doc、pdf、exe等等)，
应该显示适当的错误消息。
8.检查如果上传的图片满足指定的高度和宽度(如果有定义的话)则可以成功上传，否则不能上传。
9.上传大尺寸图片时应显示上传进度条
10.检查上传过程中的取消按钮是否有效
11.检查文件选择对话框中的文件列表是否只显示支持文件类型
12.检查上传多个图像的功能
13.上传后检查图像质量，图像质量不应该改变
14.检查用户是否能够使用/查看上传的图像
5.4 搜索框的测试
1)搜索按钮功能是否能够实现，验证搜索框的功能是否与需求一致
2)点搜索后，原先的搜索条件是否清空。
3)直看比较长的名称是否能查到输入过长查询数据，看其有没判断，报错系统是否会截
取允许的长度来检索结果。
4)是否有忽略空格的功能，需要有忽略前置空格和后置空格的功能，但不能把中间空格忽略
5)不输入任何内容点击搜索看查询的结果
6)查看搜索框内的默认内容是否与设置的一致，焦点放置搜索框中，搜索框默认内容是否自动被清空
7)输入系统中存在的与之匹配的条件看其的查询后数据的完整性显示记录条数正确、文字折行显示正 确页面布局美观列标题项、列显示内容、排序方式符合需求定义。
8)组合中文和各种特殊符号输入查看能否正确搜索到合的内容
9)输入系统中不存在的与之匹配的条件，是否搜索出信息或者给予提示信息
10)使用复制粘贴，测试搜索框是否能执行
11)注意在光标停留的地方输入信息时，光标和所输入的信息会否跳到别的地方
12)反复输入相同的数据(5次以上)看是否报错
13)敏感词汇，提示用户为敏感词汇
{
语句提1；
}else{
语句提2
}
3.某个被调用的方法中缺少某些参数的定义，在不知情的情况下，直接调用时传递了未定义过的参数or类型不匹配的参数到该方法，如果对应网站是处理批量的业务，则可能会导致大面积的500异常页面，对网站正常业务和SEO排名损失风险比较大。
4.新增、编辑->保存，对所提交的字段有的末作非空限制，可以直接保存成功，保存后以空内容展示，可能存在不确定性，比如操作已保存成功的空记录时，是否会影响其他正常添加的记录，是相互独立的，还是会牵连到其他所有的类型。
服务器配置错误(漏配or错配)，更新后出现500 or 404：
1.服务器配置文件，如 web.config中把前端访问的url地址写错，直接发布更新之后，前端页 面访问可能会出现404错误。
2.程序代码中的某些逻辑错误和服务器配置相冲突时，前端页面触发某些特定按钮or页面可能 会出现500错误。
数据传递过程无控制，导致数据输出到界面功能异常or样式变形：
- 搜索功能：有的页面本身有回显所搜索关键词的功能，搜索输入框填写的keywords字符较长
(如：100字符)，直接搜索后这些长字符显示在页面中，使得页面原来的样式变形，
甚至有的功能按钮被挤到页面之外而不能使用。
2.新增功能：对于新增字段的长度没有任何限制，超长字符新增可以保存成功，回到列表页也没有对 显示的字符长度进行控制，所有字符长度都展示在列表，挤压其他字段的
14)不同搜所的条件之间来回选择，查看是否出现页面错误
15)测试多个搜所条件时，要注意搜所条件的组合测试，可能不同组合的测试会报错
16)点击搜索框，看能否在搜索栏下方显示提供设置好的最近热门搜索词，点击任一可以
直达搜索结果页
17)点击搜索框时，到有搜所历史时，能显示历史搜所内容，历史搜所内容应从上到下按
时间排序，点击清空历史清空所有搜索记录
18)直看搜索框最大输入字符数
5.5 给你一个电梯，你怎么测
功能测试：
1)测试电梯能否实现正常的上升和下降功能
2)电梯的按钮是否都可以使用
电梯内分楼层键是否正常
电梯内开关门键是否正常
电梯内的报鳘键是否正常使用
电梯外的上下键是否正常
3)电梯门的打开，关闭是否正常
4)报警装置是否可用
5)与其他电梯之间是否协作良好
6)通风状况如何
7)突然停电时的情况。
8)关注显示屏，电梯内外的显示屏显示的电梯层数、运行方向是否正常
9)有障碍物时，电梯门的感应系统是否有效
10)上升途中的响应
电梯本来在1楼，如果有人按18楼，那么电梯在上升到5楼的时候，有人按了10楼
这时候是否会在10楼先停下来;
电梯下降到10层时显示满员，此时若8层有人等待电梯，是否在8层停
11)是否有手机信号
可靠性测试：
1)门关上的一刹那出现障碍物。
2)同时按关门和开门按钮。
3)点击当前楼层号码
4)多次点击同一楼层号码
5)同时按上键和下键
易用性测试：
1)电梯的按钮的设计符合般人的习惯吗
2)楼层按键高度(小孩和一些身高矮的用户会按键不方便)
3)电梯是否有地毯、夏天是否有空调、通风条件、照明条件、手机信号是否通畅
4)电梯是否有扶手，是否有专针对残疾人的扶手等等
压力测试：
1)看电梯的最大承重量，在负载过重时报警装置是否有提醒
2)在一定时间内不断让电梯上升、下降
稳定性测试：
1)看电梯在最大负载下平稳运行的最长时间
安全性测试:
1)下坠时是否有制动装置
2)暴力破坏电梯时是否报警，超重是否报警
3)停电情况下电梯是否有应急电源装置
性能测试：
1)测试电梯负载单人时的运行情况(基准测试)
2)多人时的运行情况(负载测试)
3)一定人数下较长时间的运作(稳定性测试)
4)更长时间运作时的运行情况(疲劳测试)
5)不断增加人数导致电梯报警(拐点压力测试)
5.6 更换头像的测试点（站在app的角度来分析）
功能测试：
1，点击头像可以放大观看
2，查看头像是否支持放大，缩小
3，刚创建账号时是否显示默认头像
4，查看头像之后点击其它区域自动退出
5，头像支持的图片格式，图片大小
6，支持相机拍摄的图片和从网上下载的图片
7，选择完图片后是否有一个定框
8，选择相片方式，从手机相册获取
9，选择相片方式，用手机照相机拍照
10，头像显示的是方形还是圆形
11，选择图片范围时图片是否支持放大/缩小
12，选择好图片区域后保存，头像是否居中显示，还是只显示选择图片区域的某个角落
13，保存完图片后是否会有提示更换头像成功
14，修改头像后去app其它模块时是否马上刷新显示最新的头像
15，进入更换头像界面时可以取消更换头像
16，选择从相册选取图片还是从照相机时都能取消，返回到修改头像界面
17，头像是否支持本地缓存，断开网络之后是否还能显示头像
18，网络异常时，修改头像失败，是否会有提示
弱网测试：
双卡的情况下，切换到另一张卡
连接到一个假热点
用 fiddler模拟2G、3G、4G情况下的弱网情况
从手机流量切换到wifi
性能测试：
上传的时间
上传过程中
手机死机? 手机没电? 手机卡停机?
上传成功以后，去数据库查看有没有
上传成功后，退出登录，在登录看是否是更新后的头像
上传成功后，删除头像，切换到其他页面，再切换回来看头像的展示情况
兼容性测试：
更换成功后，在不同手机屏幕，不同分辨率，不同手机型号，不同系统版本的情况下，头像的展示
5.7 qq登陆界面怎么测试，分析
主要考察：测试者是否熟悉各种测试方法，是否有丰富的 App/eb测试经验，以及相关开发经验，以及设计 Test case的能力
功能测试( Function test)
1)输入正确的用户名和密码，点击提交按钮，验证是否能正确登录
2)输入错误的用户名或者密码，验证登录会失败，是否有相应的错误提示信息
3)登录成功后是否跳转到正确的页面
4)用户名和密码，如果太短或者太长，应该怎么处理
5)用户名和密码，中有特殊字符，和其他非英文的情况
6)记住用户名和密码的功能
7)登陆失败后，不能记录密码的功能
8)用户名和密码输入时前后有空格的处理
9)密码是否可见，是否用星号标识
界面测试(U|Test)
1)布局是否合理，2个 Testbox和个按钮是否对齐
2) Textbox和按钮的长度、高度是否复合要求
3)界面是否美观
4)图片，颜色，字体，超链接，是否都显示正确
性能测试( performance test)
1)打开登录页面，需要几秒
2)输入正确的用户名和密码后，登录成功跳转到新页面，不超过5秒
3)能支持多少个用户同时登陆
安全性测试( Security test)
1)登录成功后生成的Cookie，是否是httponly(否则容易被脚本盗取)
2)用户名和密码是否通过加密的方式，发送给Web服务器
3)用户名和密码的验证，应该是用服务器端验证，而不能单单是在客户端用 javascript验证
4)用户名和密码的输入框，应该屏蔽SQL注入攻击
5)用户名和密码的的输入框，应该禁止输入脚本(防止XSS攻击
6)错误登陆的次数限制(防止暴力破解)
兼容性测试( Compatibility Test)
1)不同的平台是否能正常工作，比如 Windows，Mac
2)移动设备上是否正常工作，比如 iPhone， Andriod
3)不同的分辨率
4)不同的浏览器大小(浏览器最大化，和非最大化)
5.8 微信点赞
功能测试：
1)给某个好友点赞，点赞数+1，点赞栏显示具体点赞人的名字，该用户手动点赞回馈
2)点完赞后，共同好友在点赞区能看到该人是不是点赞了，非共同好友看不到
3)两个头像一样的人点赞，能否正确显示
4)点完赞后，在点击点变成点赞取消
5)取消点赞-不通知用户
6)点赞后，通知用户，取消，在点赞，此时不通知用户
7)多个用户同时对其点赞，点赞数正常
8)最多能点多少个赞-边界值测试
9)可以从点击点赞区头像，进入相应人的主页查看
10)点赞是否按照时间顺序排序
11)点赞后是否能够正常评论
app端测试：
1)弱网情况下，点赞能否实时更新
2)点赞时，有短信或者电话进来，能否显示点赞情况
3)耗电量，耗流量关注
性能测试：
1)大量用户并发点赞时，该接口的响应时间，最大承受的qps
2)大量用户并发点赞时，此时界面进行点赞，点赞功能是否正常
兼容性测试：
1)不同手机型号，点功能，显示功能是否正常
5.9 微信发红包测试点
1、功能测试
1)发给单个好友
①正确的金额+无留言+无表情
②错误的金额+无留言+无表情
③正确的金额+有留言+无表情
④错误的金额+有留言+无表情
⑤正确的金额+无留言+有表情
⑥错误的金额+无留言+有表情
⑦正确的金额+有留言+有表情
⑧错误的金额+有留言+有表情
其中，金额(001-200)可以测试以下数据
数字：测试0.0.009、0.01、0.011、01、199.99、200、200.01这些边界值
中文、英文、特殊字符或者这几种的组合
是否支持复制黏贴
为空/包含空格
金额的增删查改
留言可以测试以下数据
数字、中文、英文、特殊字符、表情或者他们的组合
输入超长文本时，是否会给出相应的限制或提示
包含空格
是否支持复制黏贴
留言的增删查改
表情可以测试以下数据
选择收藏的表情测试(动图/静图)
选择下载的表情测试(动图/静图)
录制表情，并添加进行测试
表情的增删查改
⑨点击塞钱进红包，选择零钱付款，此时需要考虑金额>零钱，金额<零钱，金额=零钱，三种情况。
⑩点击塞钱进红包，选择已添加的银行卡付款，此时同样需要考虑金额>银行卡余额，金额<银行卡余额，金额=银行卡余额三种情况
11、点击塞钱进红包，选择使用新卡付款，按照流程添加新卡，此时同样需要考虑金额>新卡余额，金额<新卡余额，金额=新卡余额三种情况
12、使用指纹确认付款(正确的/不正确的指纹)
13、使用密码确认付款(正确的/不正确的密码)
14、发送成功之后，对应的途径会减少相应的金额
15、发送者接受者可以点击红包查看到红包的具体信息，且金额，留言，表情均能正确显
16、好友点击红包之后，零钱中将增加相应的金额，再次点击之后，只能查看到红包的信息
17、24小时之内没有领取的红包，将退回原账户，此时原账户的零钱将增加相应金额的金钱24小时后好友点击红包，显示红包已过期，无法查看到红包的余额
18、右上角的红包记录中，可以查看刚刚发出的红包的金额
19、检测帮助中心中链接是否均可以正常跳转，查看
20、当红包超过24小时之后，则无法查看红包被每个人领取的详细信息
2)发送群红包(与发给好友的测试点相似，以下仅写出不同的部分)
①选择为拼手气红包时，群中每个人收到的金额随机(但加起来为红包的总金额)，为普通红包时，群中每个人收到的金额相同
②红包个数(1-100)：0，1，2，大于群成员人数，小于群成员人数，等于群成员人数，99.100，101，小数，中文、英文、特殊字符、表情或者他们的组合
③但红包没有被抢完时，此时首次点击该红包的人可以抢到一定金额的红包，不是首次点击该红包的人只能查看该红包的信息;当红包抢完时，所有人只能查看该红包的信息
④在24小时之内红包的金额被完全抢完，且此时为拼手气红包时，金额最多的人会显示为最佳手气(若有两个人取得红包的最大值时，则只有一个人会显示为最佳手气);若没有被完全抢完，则没有最佳手气，且余额会退还到原账户
⑤群中所有人均可以抢红包(包括自己)，每个人最多只有一次抢该红包的机会
⑥测试当红包个数使得每个红包分到钱小于0.01，即总金额为0.02，而红包个数为3时的情况
2、兼容性测试
1)苹果手机和安卓手机
2)苹果手机的不同版本
3)安卓手机不同的机型
4)不同分辨率
3、性能测试
1)打开红包的响应时间不能超过三秒，高并发场量下不能超过5秒
2)耗电量
3)消耗流量的多少
4)所占内存
4、ui测试&易用性测试
1)界面的设计风格是否统
2)界面中文字是否简洁，没有错别字
3)是否易操作，易学习，易理解
5、中断测试：前后台切换，网络异常，低电量，断电，来电，短信等
6、网络测试
1)网络兼容性：2G/3G/4G，WIFI，热点，移动/联通/电信
2)无网测试
3)弱网：延时&丢包
5.10 微信聊天功能测试用例
消息发送(单聊，群聊，语音，文字，图片，表情，链接，字符及长度)
成员管理(加人，被加，退出，被动退出，编辑，删除)
群组管理(创建群，消息设置，申请入群，扫二维码入群，退群，通知提醒，头像编辑，名称编辑，简介编辑，权限编辑，成员编辑)
消息管理(发布通知，接收通知，发文件，消息提醒，通知提醒，声音，震动，好友请求，请求处理)隐私管理(黑名单，允许好友查看动态，允许陌生人查看动态，允许通过手机号查找，允许真实姓名查找)
权限管理(开放群(任何人入群)、半开放群(验证入群)验证加好友不需验证加好友)
登录退出(忘记密码，更换账号)
好友管理(扫二维码加人，加好友，查好友，好友推荐，群组推荐，联系人导入，拉黑名单，解除好友，备注名)
动态管理(发动态，发投票，点赞，表情，评论，增加，删除，分享，隐藏，编辑
消息推送(在线，离线，收发，时序)
文件管理(接收，离线接收，预览，删除，分享，转存，文件格式，大小)
5.11 给你一个界面怎么测
这个具体看什么界面了，首先要搞清楚界面上有哪些功能点，一定要弄清楚哪些是展示性的信息，哪些可操作性的东西。然后从上到下根据界面上的一些功能进行逐一测试。具体的话：
1)首先肯定是做界面ui测试，主要检查看界面布局是否合理，是否美观，图片，颜色，字体，超链接，是否都显示正确，界面数据是否展示正常等等。
2)然后根据界面上的各个功能点需求逐一检查，各个功能是否有问题。
3)考虑到时界面，所以得考虑兼容性问题，对于Web端要不同的浏览器展示问题，浏览器缩放比例问题，不同屏幕大小问题，看是否都能正常展示，对于App端当然要考虑不同的手机屏幕大小，分辨率等等。
5.12 你说原来充值功能，你是怎么测试的?
一、首先我们先测试充值的主体功能，看看能否充值成功;(等价类，边界值，判定表，流程分析法，状态迁移法，错误推测法，异常处理法来测试)
用边界值的方法测试充值限定的额度能否充值成功
用特殊字符在充值输入框输入是否有提示语提醒
充值输入框为空时点击充值是否有提示
在输入框里输入金额，再后退网页再进入充值页面，是否还保存着输入的金额数
多次往返充值界面，是否还可以正常充值
选择多个充值支付方式能否充值成功
选择各银行网银能否充值成功
充值成功时，有没有相关的提示和页面是否正确跳转
充值成功后，相关联的金额是否正确显示
充值成功后，查看数据库的相关数据是否有存在和正确
点击第三方支付(如支付宝，微信)是否有相关的连接页面跳转
能否同时选择多个支付方式来充值
交叉选择支付方式后，再选择其中一个支付方式能否充值成功
充值输入框多次修改充值金额，能否充值正确
二、我们再测试充值的性能，用 jmeter模拟大量用户同时充值，看看能否充值成功;
三、我们再对充值的安全性进行测试，
(1)绑定银行卡充值和未绑定银行卡能否充值成功;
(2)绑定多张同名的银行卡以及一个用户绑定多张不同名的银行了能否绑定充值成功
(3)实名认证和未实名认证能否充值成功
(4)用边界值的方法测试每天充值限额，次数
(5)测试一天之内最多可以输入密码错误次数是多少，次数达到多少次锁卡，是否需要到银行解锁方能再进行充值
(6)输入充值金额后需要输入多少次密码，是否有加密，不输入密码能否充值成功;
(7)使用其他的支付方式支付能否充值成功
(8)测试充值金额的类型
(9)充值之后所充值的账户以及平台的余额额度是否有增加;
(10)单次点击，多次点击会不会充值成功;以及多次点击会不会多次充值;
(11)同时打开多个充值界面，能否充值成功;
(12)不登陆用户的情况下是否充值成功;
(13)不选择银行卡或其他方式支付是否能充值成功;
(14)跨站攻击，数据泄密;
四、我们还要对兼容性进行测试，看看不同的版本、分辨率，不同的浏览器，能否正常充值
五、对易用性进行测试，测试充值的整个流程是否易用，遇到一些不懂的有没有相应的温馨提示
六、我们还会考虑测试异常的情况：(网络异常和设备异常)
比如说：
(1)充值的过程中突然没网或者网络中断或弱网情况下是否充值成功;
(2)充值过程中突然断电了，能否充值成功;
(3)充值过程中设备卡顿能否充值成功;
(4)银行卡挂失，被注销，卡内余额不足，卡里金额被冻结，额度超过限额的情况能否充值成功
七、我们再对界面进行测试
(1)界面是否美观，格式是否正确，中文是否有错别字
(2)在其他浏器能否打开我们这个充值界面，能否正常显示并且正常充值
(3)界面上的按钮是否符合用户的使用习惯，主要关键的功能按钮是否容易找到，操作是否便捷;
(4)在不同的浏览器里界面缩放后，界面排版是否正常显示
5.13 电商的库存逻辑怎么测。
比如客户下订单，库存减少，规定时间内未支付定单就取消，库存又加回来，
我会先测一下界面，比如界面的排版是否美观，有没有错别字，颜色适不适合等。然后再测试一下功能，提交订单页面，我会测试购买商品数量，自己输入的边界值和点击加就加或者减少修改数量，不选择数量会不会有默认数量，不选择商品类型以及选择多个商品类型，然后测试正确提交订单后，看库存是否有减少相应的数量。再测试规定时间的边界值，比如规定时间是1个小时，那1个小时内完成支付，库存有没有变化，61分钟还是否能去支付，订单有没有关闭，接着会测试一下1个小时内取消订单，单库存有没有增加相应的数量以及1小时内没有去支付，系统自动取消订单，库存有没有加上相应的数量。再测安全性，涉及到支付，用fiddler工具抓包拦截数据，看能否修改参数，再发送请求支付成功，测逻辑的话大概就这些。
六、 Linux
6.1 Linux系统你是怎么用的?
[在测试1、执行的过程中，我们发现的bug，有时候需要定位bug，协助开发修复bug时需要在linux里通过命令tail-200或tail-500查看当天的日志的后面多少行或者前面多少行定位bug或者通过tail -f来查看日志里的关键字 exception(异常) error(错误)。
[后台程序运行久了会对系统造成卡顿等诸多隐患或我们做性能测试的时候我们都会通过linux的命令Ps -ef显示所有进程)、top(监控程序执行状况)、free -m显示内存使用情况)
来查看系统资源如果服务器出现故障时我们也会用（service httpd status）看下服务器是否启动，用ps -ef|grep httpd查看apache进程是否启动，用ps -ef|grepjava查看jdk进程是否启动如果服务器起不来，常见的问题有端口可能被占用，用 netstat- an|grep 8080查看端口是否已被占用。]
[搭建测试环境的时候我们在是在linux下进行的，搭建LAMP时在线用命令 yum install
安装 apache，php以及mysql;或通过 xshell来导入需要的环境包来搭建LTMJ(Tomcat、Mysql、jdk)
6.2 Linux是什么工具连接的， Linux版本是多少
Xshell、CRT、SSH用的ssh协议连接，端口是22
传输文件用xftp工具，占用的端口是21
Linux版本 centos6.5版本64位
6.3 日志具体是怎么看的
1、我们根据日志目录找到对应的日志文件，用tail -200，或者tail-500查看文件内容
也可以重定向导出来查看。
如果是系统出现了异常导致的错误，我们跟去查找关键字，比如说error或者 exception等
如果是逻辑错误，会把操作对应时间的日志跟对应开发一起去定位bug
6.4 监控资源命令用到哪些
查着进程ps -ef过滤添加grep来着
杀掉进程 kill 强制杀掉 -9
监控资源top vmstat
磁盘 df -h
内存 free -m
6.5 nmon工具是如何使用的
1、下载安装包()
2、安装(不需要安装-解压即可) nmon_linux_14i.tar.gz
1）把文件传输到 linux服务器
2）解压xftp
tar -zxvf nmon_linux 14i.tar.gz
3）解压文件中，找到你系统版本对应的运行文件
比如：你们的操作系统 centos6.5 64位系统， ./nmon_x86_64_centos6文件
4）运行对应的监控资源的文件
./nmon_x86_64_centos6
按字母c查看cpu，m查看内存，n查看网络，q退出
3、运行命令把数据保存到文档中
./nmon_x86_64_sles11 -s1 -c350 -f -m /home/
-s1每1秒采集一次数据
-c350采集350次，即为采集十分钟的数据。
-f生成的数据文件名中包含文件创建的时间
-m生成的数据文件的存放目录
这样就会生成一个nmon文件，并每十秒更新一次，直到分钟后。
生成的文件名如：_090824_1306nmon,””是这台主机的主机名， nmon -h查看更多帮助信息。
4、把生成nmon工具，导出到 windows
5、用 office运行分析工具
6、生成一个xlsx文件
6.6 测试环境是如何搭建的(弱项)
前提条件：租服务器或者买服务器-仅搭建一次，
1、搭建环境 linux+ apache+php+ mysql， linux+ tomcat+java+ mysql
2、每一次选代，每一次测试( apache)html目录下
1）替换代码包(覆盖代码包)-配置文件已经编辑好-压缩包
2）运行sql文件
3）重启服务
tomcat(java语言) ---代码在 webapps目录下
1，替换代码包(覆盖代码包)·配置文件已经编辑好-压缩包，war包(重启 tomcat服务，自动化解压)
2，运行SQL文件
3，重启服务
6.7 linux常见命令有哪些，说出10条左右
查看实时日志：tall 、 head -20 查看前20行 、 tail -20 查看前20行
查看进程：ps -ef 、查看当前系统端口：netstat -an 、查看哪些端口被打开：netstat -anp
重启数据库服务：systemctl restart mysql service
重启网卡：service network restart
解压包：.zip包 unzip 包名 .tar tar -xzf 包名
在线安装用 yun
6.8 如何查看端口是否被占用
Netstat -anolgrep 8080
6.9 data目录下找到所有txt的文件的命令
Find /data -name “*.txt”
6.10 怎么把lnux服务器的文件拷贝到另外一台 linux服务器
scp要拷贝的文件目标主机ip：/目录/
scp startup.sh 192.168.1.157： /home/
[email protected]'s password:
startup.sh
七、数据库
7.1 你们数据库怎么用
[原来我们数据库用的比较多的，就是数据结果检查，测试一些数据准备，性能测试造大量数据。]
[测试执行到的结果，我们需要通过sql语句 select来查找数据库对应的表，看看数据库信息跟我们执行的结果是否一致，比如：生成申请借款后，我们会去数据库里面去检查下,数据库中数据是否跟申请订单数据一致。]
[我们在测试执行时需要做一些测试数据准备，我们就用 insert into输入数据或(者update set修改数据)，我们需要到数据库查看有没有相关记录保存，保存的数据跟我们输入或者修改的记录是否一致;比如：原来我们一个初审功能里面有个分页功能，测试分页功能，需要100条数据，我们就通过数据库操作添加100，可以用 insert into。也可以用脚本实现，或者存储过程]
[还有在做性能测试时，模拟用户场景时需要用到大量的数据，这时就需要我们到数据库中制造大量的数据出来。比如说，测试充值，需要大量用户数据，充值表中大量数据，比如10W条数据，我们就用存储过程去造。]
7.2 存储过程是怎么编写的
delimiter∥
create procedure存储过程名(n int)
BEGIN
declare i int default 0;
while i <= n do
Insert into表名 values(值1，值2...)
set i=i+1;
end while;
end∥
delimiter;
cal存储过程名(数据量(n));
7.3 常见的关系型数据库有哪些
mysql、SQL Server、Oracle、Sybase、DB2等
MySQL是开源免费的;
SQL Server是由微软公司开发的关系型数据库管理系统，一般用于Web上存储数据;
Oracle数据的大量性数据的保存的持久性;
7.4 你们用的什么数据库连接工具
Navicat，数据库版本 mysql 5.6，端口默认是3306
7.5 左连接与右连接有什么区别
左连接：以左边的表(employ)为主，显示左边表列的全部数据，如果右边表没有对应的数据，
则为NULL
右连接：以右边的表(student)为主，显示右边表列的全部数据，如果左边表没有对应的数据，
则为NULL
7.6 索引有哪些，如何建立索引，素引的优缺点
MySQL索引的建立对手 MySQL的高效行是很重要的，索引可以大大提高MySQL的检素速度
缺点：虽然索引大大提高了查询速度，同时却会降低更新表的速度，如对表进行 INSERT、
UPDATE和 DELETE，因为更新表时，MySQL不仅要保存数据，还要保存一下索引文件，建立索引会占用磁盘空间的索引文件。
索引份分单列索引和组合索引，单列索引，即一个索引只包含单个列，一个表可以有多个单列素引，但这不是组合素引，组合索引，即一个索引包含多个列。
主键索引 PRIMARY KEY，唯一索引 UNIQUE，普通素引 INDEX
组合索引INDEX，全文索引 FULLTEXT
7.7 having是干嘛的?
是一个条件查询，一般是跟着分组以后，比如
select title， count(title) as t from titles group by title having t>=2;
7.8 where与 having的区别?
having是在分组后对数据进行过滤
where是在分组前对数据进行过滤
having后面可以使用聚合函数
where后面不可以使用聚合
7.9 查询数据库的前100行数据，你sq怎么写
Select * from user limit 0,100
7.10 如何进行多表查询
Select * from A,b where a,id=b,id
7.11 in与 exist的区别
1.in()适合B表比A表数据小的情况
2.exists()适合B表比A表数据大的情况
7.12 数据库测试有没有发现什么问题
原来我们做的一个功能，生成订单，在数据库中没有添加创建时间，导致后续根据时间点,去查询订单的时候，找到对应的数据
八、抓包与网络协议
8.1 抓包工具怎么用
我原来的公司对于抓包这块，在App的测试用得比较多。我们会使用fiddler抓取数据检查结果，定位问题，测试安全，制造弱网环境;
如：抓取数据通过查看请求数据，请求行，请求报头，请求正文，信息是否正确去检查结果,
如果是以4开头的话就有可能是前端问题一般我会到前端排查，以5开头就有可能是后端
问题我就会到后端排查;如果是200的话，就需要检查请求行，请求报头，请求正文是否正确，
如果请求错误就是前端问题，如果请求没有问题，那就是后端问题，看后端问题服务器运行日志，
是否包含 exception，error或根据时间点去看日志。
测试安全，抓取数据查看用户的感敏信息有没有进行加密显示，还有就是把发送请求的数据篡改是否成功。
弱网环境，诵过 fiddler工具选择 Customize Ruels...(Ctr+R)调出定义脚本编辑器找到
“if (m_SimulateModem)”设置上行下行网速，然后把
Rules-> Performance-> Simulate Modem Speeds选中生效
常用抓包工具有：浏览器中F12， fiddler， Charles(青花瓷)， wireshark
8.2 如何抓取https的包
1、设置 Tools=> Option=>勾选 Decrypt Https traffic=>勾选 lgnore server
certificate errors(unsafe)
2、打开https网页就可以成功抓取了
3、还可以 Fiddler添加过滤器(Filters)：只抓取指定iP的数据
8.3 如何抓取手机的包
1、开启 Fiddler的远程连接
Fiddler主菜单Toos- Options-> Connections>勾选 Allow remote computers to
2、重启 Fiddler，更新刚开启的远程配置
3、然后手机和电脑需要在同一个局域网，抓取http手机设置代理就可以，要抓取https包，手机需要安装一个fiddler证书
1、fder工具生成一个证书，发送手机上面安装
2、通过手机浏览器打开安装证书界面192.168.3.197：8888
ip地址是用 fiddler工具的电脑的ip地址，fiddler工具端口号的8888
3、点击下载证书，会提示，输入手机锁屏密码
4、给证书命名，名字随意，其他默认就ok
5、点击确定，安装成功，然后就可以抓取https的包了
8.4 网络协议了解多少?
原来我们用得比较多的协议是http和https以及tcp协议
http和https都是超文本协议，浏览器发送数据请求基本用的都是他们，不同的是https
在http的基础上增加了ssl加密协议,http的默认端口是80，http：的默认端口是443，
https收费，http免费。
tcp协议的话，作用在传输层，在发送请求前会有三次握手，是面向连接的协议，传输过程比较可靠
udp协议的话，作用在传输层，面向非连接协议，传输过程相对tcp不可靠，传输大量数据
8.5 请求方式有哪些?
常用：get、post
不常用：delete、put、head、option
8.6 get跟post请求的区别
1)get请求的参数有长度限制，post没有
2)get请求参数在url上传输，post的参数在请求正文中传输。post比get传输更安全
3)get只能接收ascall码参数，而post没有限制
4)get请求的时候，只请求一次，而post请求两次，第一发送请求头相关信息，第二次
再发送请求正文，(只有部分浏览器2次请求)
8.7 http跟https的区别
1.https协议需要到ca申请证书，一般免费证书较少，因而需要一定费用
2.http是超文本传输协议，信息是明文传输https则是具有安全性的ssl加密传输协议
3.http和https使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443
4.http的连接很简单，是无状态的;Https协议是由SSL + HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全。
8.8 为什么要使用cookie和session：http是无状态协议
第一次登录，发送用户信息给到服务器，服务器把用户信息保存在session中服务器响应数据给客户端，响应数据中有包含session的先关用户信息
客户端接收到服务器session信息，把session中相关的用户信息保存在cookie中
第二次登录，客户端发送请求，并携带cookie，服务端可以直接验证cookie值，如果用户已经登录过，可以免登录
8.9 cookie跟 session的区别
在网站中http请求是无状态的，也就是说即使第一次和服务器连接后并且登录成功后，
第二次请求服务器依然不能知道当前请求是哪个用户，cookie的出现就是为了解决这个问题，
第一次登录后服务器返回一些数据(cookie)给浏览器，然后浏览器保存在本地，当该用户发送第二次请求的时候，就会自动的把上次请求存储的 cookie数据自动的携带给服务器，服务器通过浏览器携带的数据就能判断当前用户是哪个了。cookie存储的数据量有限，不同的浏览器有不同的存储大小，但一般不超过4KB，因此使用 cookie只能存储一些小量的数据。
session和 cookie的作用有点类似，都是为了存储用户相关的信息，不同的是，cookie是存储在本地浏览器，而session存储在服务器.存储在服务器的数据会更加的安全，不容易被窃取。但存储在服务器也有一定的弊端，就是会占用服务器的资源，但现在服务器已经发展至今，一些session信息还是绰绰有余的
8.10 OSI七层网络模型
(1)参考模型：只是提供给生产商或者软件开发商参考的模型
(2)开发系统互联
(3)有七层
8.11 TCP模型
有四层:
应用层 (telnet.stp.htp)，传输层( CP UDP)、网络层，中数据链路层
8.12 TCP和UDP的区别?
(1)TCP面向连接、而UDP面向非连接
(2)TCP相对UDP更可靠
(3)TCP应用场景，用于传输少量数据，而UDP用于传输大量数据
(4)TCP传输的数据相对UDP慢
8.13 tcp的三次握手是怎么实现的?
(1)客户端给服务器发送报文syn=1和序列号Seq=x
(2)服务器接收到客户端的请求，服务器响应syn=1，ack=x+1,seq=y
(3)客户端接收到服务器的响应，返回给服务器，ack=y+1，seq=z
8.14 http协议包含哪些内容
(1)请求信息
1）请求行：请求方式、请求地址http版本1.1
2）请求头
HTTP消息报头包括普通报头、请求报头、响应报头、实体报头
Cache- Control：no- cache 缓存
Connection：close/keep-aive 是否关闭或者保持连接
Accept-Charset：ios-859-1 字符集
Accept-Encoding：gzip.deflate 编码格式
Accept-Language：zh-cn 语言
Authorization：服务器授权验证
Host：主机
User-Agent：
Location：重定向
Server：服务器版本信息
Content-Encoding：实体报头的编码格式
请求正文
data
(2)响应信息
1）状态行：http版本、状态码、状态信息
2）响应头：跟请求头一样
3）响应正文：
8.15 http状态码有哪些
1xx需要继续发送请求
2xx成功
3xx需要重定向
4xx客户端请求数据有误
5xx服务器响应错误
6xx服务器响应错误
常见状态码：400、404、200、500、302、501、504
101服务器根据客户端的请求切换协议，只能切换到更高级的协议，
例如，切换到HTTP的新版本协议
102(代表处理将被继续执行)由 WebDAV(RFC 2518)扩展的状态码，代表处理将被继续执行
2开头这一类型的状态码，代表请求已成功被服务器接收、理解、并接受。
200(成功)服务器已成功处理了请求，通常，这表示服务器提供了请求的网页
201(已创建)请求成功并且服务器创建了新的资源
202(已接受)服务器已接受请求，但尚未处理
203(非授权信息)服务器已成功处理了请求，但返回的信息可能来自另一来源
204(无内容)服务器成功处理了请求，但没有返回任何内容
205(重置内容)服务器成功处理了请求，但没有返回任何内容
206(部分内容)服务器成功处理了部分GET请求
207(代表之后的消息体将是一个XML消息)，并且可能依照之前子请求数量的不同，包含
系列独立的响应代码
3开头(请求被重定向)表示要完成请求，需要进一步操作。通常，这些状态代码用来重定向。
300(多种选择)针对请求，服务器可执行多种操作。服务器可根据请求者(user agent)选择一项操作，或提供操作列表供请求者选择。
301(永久移动)请求的网页已永久移动到新位置.服务器返回此响应(对GET或HEAD请求的响应)时，会自动将请求者转到新位置
302(临时移动)服务器目前从不同位置的网页响应请求，
但请求者应继续使用原有位置来进行以后的请求
303(查看其他位置)请求者应当对不同的位置使用单独的GET请求来检索响应时，服务器返回此代码。
304(未修改)自从上次请求后，请求的网页未修改过。服务器返回此响应时，不会返回网页内容
305(使用代理)请求者只能使用代理访问请求的网页。如果服务器返回此响应，
还表示请求者应使用代理。
307(临时重定向)服务器目前从不同位置的网页响应请求，但请求者应继续使用原有位置来进行以后的请求
4开头(请求错误)这些状态代码表示请求可能出错，妨碍了服务器的处理。
400(错误请求)服务器不理解请求的语法
401(未授权)请求要求身份验证，对于需要登录的网页，服务器可能返回此响应
403(禁止)服务器拒绝请求
404(未找到)服务器找不到请求的网页
405(方法禁用)禁用请求中指定的方法
406(不接受)无法使用请求的内容特性响应请求的网页
407(需要代理授权)此状态代码与401(未授权)类似，但指定请求者应当授权使用代理
408(请求超时)服务器等候请求时发生超时
409(冲突)服务器在完成请求时发生冲突。服务器必须在响应中包含有关冲突的信息
410(已删除)如果请求的资源已永久删除，服务器就会返回此响应。
411(需要有效长度)服务器不接受不含有效内容长度标头字段的请求
412(未满足前提条件)服务器未满足请求者在请求中设置的其中一个前提条件
413(请求实体过大)服务器无法处理请求，因为请求实体过大，超出服务器的处理能力
414(请求的URL过长)请求的URL(通常为网址)过长，服务器无法处理
415(不支持的媒体类型)请求的格式不受请求页面的支持
416(请求范围不符合要求)如果页面无法提供请求的范围，则服务器会返回此状态代码
417(未满足期望值)服务器未满足期望请求标头字段的要求
5开头(服务器错误)这些状态代码表示服务器在尝试处理请求时发生内部错误
这些错误可能是服务器本身的错误，而不是请求出错
500(服务器内部错误)服务器遇到错误，无法完成请求
501(尚未实施)服务器不具备完成请求的功能，例如，服务器无法识别请求方法时可能会返回此代码。
502(错误网关)服务器作为网关或代理，从上游服务器收到无效响应，(比如：nginx里
设置了反向代理，自己代理给自己，形成了死循环，造成大量的访问日志，每秒上万)
503(服务不可用)服务器目前无法使用(由于超载或停机维护)，通常，这只是暂时状态。
504(网关超时)服务器作为网关或代理，但是没有及时从上游服务器收到请求
505(HTTP版本不受支持)服务器不支持请求中所用的HTTP协议版本
8.16 post申请方式，用get会报什么错误。
404 Not Found
请求失败，请求所希望得到的资源未被在服务器上发现，没有信息能够告诉用户这个状况到底是暂时的还是永久的，假如服务器知道情况的话，应当使用410状态码来告知旧资源因为某些内部的配置机制问题，已经永久的不可用，而且没有任何可以跳转的地址，404这个状态码被广泛应用于当服务器不想揭示到底为何请求被拒绝或者没有其他适合的响应可用的情况下，出现这个错误的最有可能的原因是服务器端没有这个页面。
8.17 http协议提交请求头内容
Accept-Charset：浏览器能够显示的字符集
Accept- Encoding：浏览器能够处理的压缩编码
Accept-Language：浏览器当前设置的语言
Connection：浏览器与服务器之间连接的类型
Cookie：当前页面设置的任何 Cookie
Host：发出请求的页面所在的域
Referer：发出请求的页面的URL
User-Agent：浏览器的用户代理字符串
Content-Type：请求数据的格式或者是类型
九、接口测试
9.1 接口测试怎么测
（jmeter版本）
首先开发会给我们一个接口文档，我们根据开发给的接口文档，进行测试点的分析，主要是考虑正常场景与异常场景，正常场景，条件的组合，参数的格式校验等价边界值;异常场景，多一个参数，少个必填参数，参数为空;接着编写测试用例，用的 Jmeter工具去运行，创建线程组，建立http请求，输入测试用例，请求参数，建立察看结果树，运行，看返回的结果，是否跟接口文档里面要求的返回结果一致，其他用例，值需要修改里面的参数，请求地址这些信息。
举例说明：(不要登录跟注册)
比如说原来我们做一个申请借款的接口，对接口进行测试分析，考虑正常场景与异常场景，正常场景，考虑不同参数组合，比如说，不同借款方式，还款期限，还款曰期，借款的利率等参数组合;也要测试每个参数格式校验，异常场景，：多一个参数，少一个必填参数，比如没有借款的利率，参数为空的，比如借款标题为空，编写测试用例
在 jmeter中执行，填写参数，更地址就ok，发送请求
（python + request）
原来我们接口主要是用的 python + requests去运行的
首先，开发会给我们一个接口文档，拿到接口文档后，我们就进行测试点的分析，
考虑正确场景，条件的组合，
异常场景，多一个参数，少一个参数，参数为空的情况
比如原来我们做一个生成订单的接口，考虑正常场景，异常场景
正常场景就是不同的订单类型，订单金额，能不能申请订单，每个参数的格式类型的校验，
异常场景，多一个参数，少一个必填参数的时候，还有参数为空的情况
原来我们是用 python + request去做的接口
首先，导入 request包
建立一个 headers，保存请求头的信息，因为订单请求方式是post类型，数据格式是form表单格式，我们把数据保存到data的字典里面
这个时候我们还需求登录的 cookie值跟登录后产生的 token值
我们会去通过动态关联去获取登录的 token跟 cookies，
cookies值的话，我们是直接调用登录返回的 cookies、token值的时候，我能是通过导入re模块，通过正则表达式去提取
当参数， headers、cookies输入完成以后，我们就发送请求，打印返回结果，检返回结果是否跟我们测试用例一致
当运行其他测试用例时，我们去修改data里面的参数就行，在发送请求
有的请求时htps协议的时候，我们发送请求的时候还会very= false去忽略掉证书验
证对应多个接口调用 cookies我们会用到 session去保存接口发现比较多的问题，就是格式校验这块
比如说我们提交订单，订单数据没有显示，订单格式也没有显示，输入字母，汉字都可以
订单类型为空，也会生成订单成功
我觉得接口可以发现接口更多的bug，还可以提早进行测试，提高测试的质量
9.2 两个接口有关联， jmeter具体怎么做
另外两种问法：上个接口的返回值是下个接口的请求参数，这种如何处理?动态关联有没有了解过?
这个涉及到动态关联，首先要搞清楚后一个接口需要用到上一个接口的什么数据，例外要看数据是在哪里取的，是在head还是在body里，然后如果要取的数据是json格式我会在发请求用json提取器去取这个数据，如果是其他格式的就用边界提取器或正则表达式去取数据
就拿我当时做的那个下单接口来说吧，因为下单接口需要先登录，需要用到登录接口的
cookies来做鉴权，首先就是把登录接口调试通过，然后在登录接口的http请求中添加一
个边界值提取器或者也可以用正则表示式提取器去提取登录接口的响应头中的 cookies值
然后在下单接口中需要添加一个http cookies管理器，在http cookies管理器中引用登录
接口提取出来的 cookies，这样就可以了
如果是不同的线程组的话，那在登录接口中还得添加一个 Beanshell取样器，在
Beanshell取样器中，利用函数助手中的 SetProperty()函数把提取出来的 cookies设置为全局变量，然后在下单接口的http cookies管理器中利用函数助手中的Property()函数引用登录接口中设置的全局变量，这样就可以了。
9.3 接口测试主要目的是什么?
例外两种问法：接口测试的价值，意义?为什么要做接口测试?
主要就是验证后台服务端的业务逻有没有问题，提高测试的效率
①越底层发现bug，它的修复成本是越低的
②前端页面修改频繁情况下，接口测试不受页面元素改变而影响
③检查系统的安全性，前端传参不可信，比如京东购物，前端价格不可能传入-1元，但是
通过接口可以传入-1元
④如今的系统复杂度不断上升，传统的测试方法成本急剧增加且测试效率大幅下降，接口自动化测试可以提高测试效率
⑤接口测试相对容易实现自动化持续集成，且相对U自动化也比较稳定，可以减少人工，回归测试人力成本与时间，缩短测试周期
9.4 接口测试的流程
1，首先分析开发给到的接口文档
2，接口文档分析完成，编写测试用例
3，然后借助接口测试工具去测试执行测试用例
4，发现bug提交bug，并跟进bug修复
9.5 接口测试和平常的Ul测试有什么区别?
其实这两者测试的侧重点是不同的，接口因为没有界面，更多考虑后台服务器对请求的，处理逻辑问题，业务交互，检测的是后台“容错机制”是否完整；
而ui更多会去关注页面展示，数据转换，界面排序这些功能，当然也会后台数据处理的问题，ui测试其实已经包含了接口测试。系统功能的用例更全面，不仅有界面的，也有业务功能用例，还有其他用户场景的用例功能入口用例，流程用例，而接口测试主要根据各种入参场景来设置用例。
9.6 给你一个新的接口，你怎么去设计用例?
首先要对于每个要测的接口都要先搞清楚这个接口的功能，它的作用是什么，熟悉这个业务功能需要用到什么协议，请求方式是什么，接口有哪些参数。对于每个参数的作用都要搞清楚，像数的类型，是否有约束限制，是否为必填的，长度，其他的限制等等，如果两个参数之间有关联我们还要考虑参数的组合场景，对于参数不理解的，一般都会跟开发沟通下，然后考虑返回数据的类型，返回数据中的返回码和返回信息是什么，通过以上几个点去提炼测试点，设计用例。
参数约束——长度、必选项、格式、数据类型
业务场最——正确的业务场景;错误的业务场景；异常场景：服务器空间不足
组合场景——相互依赖：手机和验证码、用户名和验证码；
相互排斥：二选一当然还有边界值等价类等等
Jmeter测试流程，步骤如下：
创建 jmeter线程组一添加HPPT请求-输入协议-域-端口-路径-编码-请求方式-请求参数-启动
Jmeter测试流程：
先需求，再根据需求写测试点转换成测试用例，根据测试用例编写测试脚本；执行测试脚本；
提交BUG，跟踪BUG
9.7 接口文档主要包含哪些内容?
接口文档一般两种形式的，要不就是word版本的要不就是htm的形式，具体内容
1．URL(接口地址)
2．接口功能
3．请求方式：post
4．请求参数，以及接口中每个参数的详细说明，类型，是否为必填，约束条件等等
5．响应数据及格式，返回码，返回码解释等等
9.8 你们什么时候测试接口
一般有需求就会做，后台的接口开发好，就可以开始测。例外，如果增加了新需求，也要做接口测试，还有就是开发对后台的接口做了修改，交互逻辑发生变化，我们也要重新对接口进行测试。
9.9 你怎么去检查，分析
我们主要是根据入参情况，去看接口的返回值，对于返回值，我主要关注的几个点：1.状态码
2.提示信息3.返回数据的具体内容。根据接口文档的说明去检查这个3个点是否满足接口需求文档，4.有些如果要检查数据库的，就连接数据库获取数据与返回的数据做对比。
如果不满足就是有问题，如果满足则通过，如果有Bug我们会先大概分析下，是什么原因，
并进行复测，如果还是有问题，提交Bug给开发，让开发修复，之后再回归测试
9.10 什么是api接口测试
接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点测试的重点，
是要检查数据的交换，传递和控制管理过程，以及系统间的相互逻辑依赖关系等
9.11 什么情况下开展接口测试?
1、项目处于开发阶段
2、有接口需求文档，开发已完成联调，功能测试展开之前
3、专项测试：参数约束测试，业务场景测试，测试接口请求响应时间（性能）
4、版本上线前，进行整体回归测试，查看接口是否有异常(如404等)
9.12 依赖于第三方的接口如何测试
1，需要第三方接口的，接口文档
2，发送请求到第三方接口，检查第三方接口返回的数据是否正确
3，不正确的时候，要跟第三方接口联调，看是请求问题，还是第三方接口返回数据有误，
这个我们公司的第三方接口，我们都是打通的，比如电商，我们通过调用微信接口等等，都是打通的，比如要测试下单第三支付，我们自己开店，收款设置我们自己的账号，然后通过商品设计1分钱，去测试的。
如果不打通的话，基本也只能抓包，主要保证我们发送出去的数据符合需求文档就行，然后真正的上线之前，我们会在预生产环境做一个联调测试，把各自系统连在一起，做一个联调测试没有问题了
我们就可以上线，基本就这么做的
联调测试怎么做的：
其实联调测试就是数据拉通测试，两个子系统，连在一起，形成一个完整的系统，然后从上游下数据，下游接到数据看传过来的数据是否符合下游的系统要求然后下游做了操作，把数据返回给上游，通知上游说数据返回了，上游看返回的数据是否符合要求，如果没有问题，就这个数据就拉通成功这个都是按照用例来执行，上游和下游一起出一份用例，两边都评审通过，然后按照测试用例执行，每条用例测试通过那么联调测就完成了。
9.13 你们接口怎么鉴权的?
(1)通过用户和密码，auth鉴权
(2)通过 cookie和 session
(3)通过 token
(4)通过sign签名
现在app一般是通过 token鉴权，有些是通过把 token放在请求头里面，有些是通过 singn签名这个字段放在body里面去鉴权的，一般的web是通过 session去鉴权的
9.14 接口传输格式有哪些
常见的媒体格式类型如下：
text/html：HTML格式
text/plain：纯文本格式
text/xm：XML格式
Image/gif：gif图片格式
mage/jpeg：jpg图片格式
Image/ng：png图片格式
以 application开头的媒体格式类型
application/xhtm + xml： XHTML格式
application/ml：XML数据格式
application/atom + xml： Atom XML聚合格式
application/json：JsoN数据格式
application/pdf：pdf格式
application/msword：Word文档格式
application/octet-stream：二进制流数据(如常见的文件下载)
application/x-www-form-urlencoded：encoded：