基本概括了深圳与广州，上干家公司的面试问题并结合编写与整理的面试文档，基本盖了，95%以上的面试问题进行知识点复习与面试指导。
有很多的萌新小伙伴呢面试很紧张，这个是千万不能有的哦，不说别的，你一紧张工资这方面就比较难谈了，所以千万不能紧张，这只是一个简简单单的面试而已。
这里就提前先祝各位小伙伴们面试成功咯。
面试宫，您好，我叫XXX，来自于XXXX，目前从事软件测试工作，已经三年工作经验，个人性格，比较开朗，跟人关系比较好，做事也比较细心三年测试工作经验中，过了不少项目，积累不少项目经验，前面1-2年主要是功能测试，后面这一年主要做接口测试，app自动化测试能够独立完成软件产品测试工作，能够独立编写测试文档，包括用例，计划，报告等，熟悉lnux跟数据库，熟悉jmeter与python+request进行接口测试，也可以使用pytest框架进行接口自动化测试，python+selenium+pytest框架进行自动化测试，python+appnium+pytest移动app自动化测试框架，熟悉使用Jenkins持续集成，熟悉app专项测试与小程序测试，熟悉抓包工具。
我个人平常喜欢…看书…
我个人觉得测试这一块，主要是对需求了解，需求理解到位，工作当中，一定细心耐心，技术这块，不断学习能力
如果面试没有说话，这个是我的一个简单自我介绍，看面试官还有什么需要了解的
①、尽量谈化敏感答案比如，人际关系不好处理，与上司相处不好、工作压力大等。
人际关系复杂，现代企业讲求团队精神，要求所有成员都能有与别人合作的能力，你对人际关系的胆怯和避讳，可能会被认为是心理状况不佳，处于忧郁焦躁孤独的心境之中，从而妨碍了你的从业取向。
收入太低，这样回答会使对方认为你是单纯为了收入取向，很计较个人得失，并且会把“如有更高的收入，会毫不犹豫地跳槽而去的”这种观念形成对你的思维定势。
分配不公平。现在企业中实行效益薪金、浮动工资制度是很普遍的，旨在用物质刺激手段提高业绩和效率；同时，很多单位都开始了员工收入保密的措施，如果你在面试时将此作为离开原单位的借口，则一方面你将失去竟争优势，另一方面你会有爱打探别人收入乃至隐私的嫌疑。
工作压力太大。现代企业生存状况是快节奏的，企业中的各色人等皆处于高强度的工作生存状态下，有的单位在招聘启事上干脆直言相告，要求应聘者能在压力下完成工作，这是越来越明显的趋向
②、尽量采用与工作能力关系不大、能为人所理解的离职原因。
寻求更大的发展：现有的企业岗位设置难以满足自身职业进一步发展的要求，
换一个更好的平台来挑战自我。
原公司发生了重大客观变化：公司重组或部内部变动，导致工作内容发生重大变化，
无法再继续履行劳动合同，或者直接被裁员等
与公司文化无法融合：每一家企业其实都有自己特有的“文化”，如果你在这家公司里工作，
却无法认可这家公司提倡的一些文化，这就会对企业的发展以及对自己的发展都非常的不利。
所以你想要走出企业的束缚，找到一家跟你更契合的公司工作也是可以的。
个人原因：上班太远影响工作、家中有事、充电、休假、生病等等。注意：避免敏感答案，
并不意味着欺骗，如招聘人员问及细节问题，应如实回答。否则求职者的诚信度可能大打折扣，
成功可能性更小。
③、不要诋毁你的老东家
相信很少会有人犯这样的错误，这的确是一个不可取的方式，你应该把你的离职原因集中表述
在“寻找新机会或新的平台”以及尝试在新的岗位上提升自己。职场虽然没有战争那么血腥，
但也有很多委屈、不被理解或被无故受伤，这些都很正常的。我们要用一颗阳光的心去面对，
用一颗阳光的心去照耀。
④、体现你的忠诚度
如果你轻描淡写地就离开了之前的团队，那么面试官会觉得你在新公司也可能会轻易走人，
所以，在体现忠诚度的时候，你可以试着谈谈你离开上一家公司时有多么痛苦依依不舍（即使并没有)，聊聊如果有办法使你能在原来的岗位上持续得到提升或者如果不是因为股东之间的权利斗争（可适当显得痛心疾首些），你肯定不会离开。
而在体现责任感时，你需要表达两层意思：
首先，你从上家公司离职时已经为继任者做了充分的交接。你需要清楚地表明：你在上家公司也很认真尽职，并且同事之间一直保持互助互利的工作氛围。也许你可以说说你也想过要早些辞职，但是考虑某个未完成的重要项目、或是继任者短期内还不能胜任角色所以晚了一些。
其次，就是你很期望承担新的职责，并表现出你的热枕，这种热枕除了对工作的热忱之外，
也可以适当的通过向你的面试官（不仅是HR）提问表现出来对面试官的兴趣、对他们技能的
认可以及共鸣，例如，“那么，你是如何做到现任职位的”或：“如果我有幸担任这个职位，
你会给我哪些建议”
通用说法：家人在这边，或者想到大城市发展。
1、(将问题抛给HR，)在回答您的问题之前我想了解一下贵公司的加班制度是怎样的。
(这种回答，其实是把问题抛回给HR，让HR表明公司对于加班的态度，其实很多大公司
对于加班都有明确的规定，什么情况该加班，加班会有什么福利等等问题都是确定的，
而小公司就随意很多，往往是老板要求加班员工就得无条件加斑。因此，如果公司的加班制度明确，
那么HR就能够明确地向你介绍，你在了解过后再给出回应也不迟。面试本就是双向选择的过程，
你也没必要为了通过面试，满口答应自己愿意加斑。)
项目进度或者是站在重要的关键节点上需要加班，我会站守自己的岗位，把自己手上的事做好，
和团队一起加班，让公司按预期的进度推进项目，这在我看来是必要的加班，
如果是其他的原因，比如个人原因，我会努力不加班，在保证工作质量的前提下，
我会提高自己的工作效率，避免加班。
如果说公司基本上天天都要加班，加班的频车较高，我希望可以减少不必要的加班，让员工
得到充分的休息，有休息才会把工作效率提升上来，工作才会更有效率，另外有些工作上的
能力炼可以在其它地方，而不在工作的本身，比如对生活的理解和感悟等之类，
是从工作中学习不到的，正所谓功夫在诗外嘛。
通用说法：如果项目组比较忙，加班是没有问题的。
1.公司现在做什么项目2.公司目前做哪方面测试3.公司这边测试人员分配比例
4.进入公司，我这边大概的工作安排5，公司这么后续发展机会还有培养
6，有没有培训7，面试没有回答上的问题，再去请教
根据公司况，个人原因来说：看公司的岗位要求，招岗位就是攻能
公司只做功能测过
3-5年内系统成为自动化或者性能，成为资深技术人员
公司做自动化与性能测试
1-2年内熟恐自动化或者性能，3-5系统成为自动化或者性能，成为资深技术人员性能与自动测试
找一个比较稳定平台，跟公司长期发展，后期走管理或者产品路线
工作中积累，查看网站论坛(51testing)，CSDN，书籍《性能测试专家》，《性能之巅》
偏开发，python自动化，selenium自动化
1.自己先去研究2，找会的去请教3，百度去找资料4，工具原始文档
3年的测试经验，对我来说也是3年的工作经验，在这3年的工作经验当中，我觉得态度比能力要重要，做好一个测试，最主要是性格，信心，耐心，细心还需要良好的沟通能力。不断学习的能力，产品质量，测试流程这块很关键，好的计划加好的执行才能成就好的产品。
非专业
1、培训，不要说刚培训出来2019年底开始
2、自学，不断一直学习
3、家里有关系，带你入行，后面学习过程很勤奋
1，实习开始，公司分配到做测试，做测试过程，比较喜欢测试，一直做下来
根据你简历上面写的，公司详细地址
产品1、项目1个、架构师1个、前端3个、后端5个、0os1个、Android1个，
测试3个(测试主管，核心测试人员)、运维1个、ui1个
1，期望薪资不要说区间比如说：6-8，那肯定是6
2，如果原来公司在二线城市原有薪资不要说太高，
3，深圳那边薪资，比广州高10%-15%
1，公司比较满意，直接随时过去。
2，不是很满意，下周一，个人有点事情，比如说回家一趟等等。
1、个人性格合适2、前景还可以3、个人技能也匹配
我觉得，IT行业，没有具体的界限，后期，开发也要懂测试，测试也要懂开发，
如果公司有机会，愿意去尝试
了解公司主要是什么项目，百度查下，
如果公司主营产品跟你项目不匹配
比如：原来公司做医疗设备，那就说：我们是项目外包的部门，专门接项目
暂时没有结婚的计划与打算，如果已经有小孩，说暂时不考虑二胎，
有小孩，可以说小孩在老家(原来有学员因为这个问题，被公司pas过)
我们的测试流程主要有三个阶段：需求了解分析、测试准备、测试执行。
1、需求了解分析阶段
我们的SE会把需求文档给我们自己先去了解一到两天这样，之后我们会有一个需求澄清会议，
我们会把不明白不理解的需求在会议上说出来，包含需求的合理性还有需求的可测性等，
产品这边解答，目的是让我们测试这边和开发对需求的理解达到一致。
2、测试准备阶段
会议结束之后我们开始准备测试工作，我们测试这边会写一个测试计划，分配每个人负责的模块，
然后我们就根据自己负责的模块用xmind(思维导图)进行测试需求分析，分析测试点，
以及编写测试用例，之后我们会在自己的组内先进行评审，评审修改之后还会在我们的项目组评审，
评审完后进行修改测试用例。
3、测试执行阶段
开发人员编写好代码之后，我们会把代码包通过Jelkins部署到测试环境提测，进行SIT测试，
在正式测试之前我们会先做一个冒烟测试，冒烟测试通过之后我们才转测，在执行测试的过程中，
我们如果发现bug就会用tapd(或者禅道)记录并且提交bug，也会进行bug复测，以及回归测试，
每一轮测试结束之后我们都会写一个测试报告，一般情况下，测试4-5轮之后会达到上线要求，
当达到上线的标准后，测试报告会认为测试通过，上线前我们会做预发布测试，预发布通过后，
总结我们在上一个版本中遇到的问题以及今后有哪些地方需要改进，在产品选代过程中，
我们会跑自动化用例来进行回归测试。
需求不明确的话我会在需求澄清会议上面提出来，问清楚这个需求只有明确需求，
才能更好的完成工作，后续工作中还是不清楚，可以找产品再去确认这个需求。
1、xmind思维导图评审，主要是测试人员
2、测试用例需要评审，测试人员，开发人员，产品人员
3、需求文档，项目组所有的人员，都会到场
参考答案1：
测试计划内容：
(1)目的和范围(2)规程(3)测试方案和方法(4)测试的准入和准出
参考答案2
我们公司之前按照考核要求写过测试计划，不过后面老大觉得太耽误工作进度，
后面一般都不再写测试计划，而是写版本计划，这个在版本计划，每个人的任务列出来，
原来我们用例包含
测试项目，用例编号、测试标题、优先级、预置条件、操作步骤、测试数据、预期结果
黑盒测试用例设计方法：主要是等价类、边界值、错误推测法、判定表、因果图、正交表、
流程分析法、状态迁移法、异常分析法。
常用的：等价类、边界值、判定表、流程分析法、错误推测法。
等价类是指某个输入域的子集合，在该子集合中，
各个输入数据对于揭露程序中的错误都是等效的，
并合理地假定：测试某等价类的代表值就等于对这一类其它值的测试，因此，可以把全部
输入数据合理划分为若干等价类，在每一个等价类中取一个数据作为测试的输入条件，
就可以用少量代表性的测试数据取得较好的测试结果，
等价类划分可有两种不同的情况有效等价类和无效等价类。
边界值的话就是对等价类划分方法的补充。测试工作经验告诉我，大量的错误往往是发生在输入或输出范围的边界上而不是发生在输入输出范围的内部，因此的话针对各种边界情况来设计测试用例，可以查出更多的错误，使用边界值分析方法设计测试用例的话，首先应该确定边界情况，通常输入和输出等价类的边界，就是应着重测试的边界情况应当选取正好等于，刚刚大于或刚刚小于边界的值作为测试数据，而不是选取等价类中的典型值或任意值作为测试数据。
对于错误推断法，这个是基于经验和直觉推测程序中所有可能存在的各种错误，
从而有针对性的去设计测试用例的方法的，主要就是列举出程序中所有可能有的错误和容易发生错误的特殊情况去根据这些情况来选择测试用例，例如，在单元测试时曾列出的许多在模块中常见的错误以前产品测试中曾经发现的错误等，这些就是经验的总结。还有，输入数据和输出数据为0的情况。
输入表格为空格或输入表格只有一行。这些都是容易发生错误的情况，可选择这些情况下的例子作为测试用例。
前面介绍的等价类划分方法和边界值分析方法都是着重考虑输入条件但都没有考虑输入条件之间的联系，相互组合等等的情况。考虑输入条件之间的相互组合，可能会产生一些新的情况，
但是要检查输入条件的组合并不是一件容易的事情，即使把所有输入条件划分成等价类，
他们之间的组合情况也相当多，因此的话可以考虑采用一种适合于描述对于多种条件的组合，
相应产生多个动作的形式来考虑设计测试用例，这就需要用到因果图(逻辑模型)。
因果图方法最终生成的就是判定表它适合检查程序输入条件的各种组合情况。
(1)创建用户，并给新创建的用户指定权限。
(2)创建测试用例，对测试用例进行增、删、改、查
(3)把测试用例关联到对应的测试计划中。
(4)把测试用例指派给对应的测试人员。
(5)对应的测试人员，查看被指派的测试用例，并执行测试用例。
对BUG有一个清晰明了的描述；详细描述BUG重现的步骤
定位好BUG的等级；将预期结果与实际结果进行对比。
1)不要急着提交，先跟开发说明bug的情况，定位分析下bug。
是前端问题还是后端问题再去提交bug。
2)简单明了的概括bug标题，清晰的描述bug重现步骤，分析bug和预期正确结果，附加bug的截图或者日志。描述bug的时候。
3)在不能确认该情况是否为bug的时候，可以请教其他人。
4)提交完bug以后，后面还要跟踪bug修复情况。
原来bug是用禅道来管理的
原来我们公司bug，提交bug直接给对应的开发人员，对应开发人员修复完成，交给测试复测，
复测通过关闭bug，不通过打回给对应开发。
提交-开发人员(已激活未确认)-开发进行确认，状态变成已激活，已确认，开发修复完成，
标注状态是已修复，测试人员复测通过，已关闭，打回给对应开发，已经激活。
所属产品、所属模块、所属项目、影响版本、指派人员
截止日期、严重程度、优先级、bug类型、bug环境
Bug标题、重现步骤、附件
首先我会再看需求文档，是不是我的理解有误，如果是我对需求理解错的话我就去关闭bug。
如果是bug再去让其他测试人员看看听下他们的意见，然后自己先再三去复测，并目保存好截图和日志，确定这是一个bug之后我就去跟开发说明白，并且给他看bug重现的截图以及日志，如果开发还是不认可的话我就跟产品或项目经理说明白情况。
首先，我会多测几次，测了好多次都无法重现的话我就先把bug挂起，并且留意一下，看看往后的测试中，如果在后面的测试中重现bug就激活，如果经过几个版本都还没发现的话就关闭bug。
(1)数据库中的编码设置(2)前端页面编码(3)后台代码也会编码
1、致命：对业务有至关重要的影响，业务系统完全丧失业务功能，无法再继续进行，
或业务系统丢失了业务数据且无法恢复，影响公司运营的重要业务数据出错。
2、严重：对业务有严重的影响，业务系统已经丧失可部分的重要的业务功能，或业务系统
丢失了业务数据且可以恢复，一般业务数据出错。
3、一般：对业务有较小的影响，业务系统丧失了较少的业务功能，
例如：界面错误，打印或显示格式错误。
4、提示：对业务没有影响，不影响业务过程正常进行，
例如：辅助说明描述不清楚，提示不明确的错误提示。
通常可以利用抓包工具来进行分析。可以从三个方面进行分析：请求接口、传参数、响应。
1）请求接口un是否正确如果请求的接口ur错误，为前端的bug
2）传参是否正确如果传参不正确，为前端的bug
3）请求接口u和传参都正确，查看响应是否正确如果响应内容不正确，为后端bug
4）也可以在浏览器控制台输入js代码调试进行分析
看严重级别：严重还是不严重
严重的：紧急变更上线
不严重：修复好后跟下个版本一起上线
用户会通过运维反馈到项目组这边，项目经理会根据功能模块的负责人，分给对应的开发与测试。
测试人员：编写对应的测试用例、测试环境中重现bug、提交bug、
交给开发进行修复、修复完成bug、进行bug的复测。
如果测试环境无法重现，可以导入生产环境的包到测试环境中测试，
还是不能复现，查看生产环境的日志去定位问题。
(1)需求要吃透，多问，多去了解。
(2)严格按照测试流程去执行：多考虑用户测试场景，使用测试用例设计方法，多评审。
(3)要有良好的测试执行：要求用例执行率达到100%，多轮测试，进行探索性测试，
需要测试之间交叉测试，用工具来管理我们的测试工作(禅道，testlink，excel，tapd)
(4)不断的反思与提升。
一般我们会选择晚上上线，开发测试还有产品全部到场，进行上线测试。
首先，开发将代码打包到生产环境的服务器中，如果数据表有变化，就会运行sql文件，
对表的一些操作，接着，我们测试就开始先测试主体业务功能以及新增的功能模块;
测试通过之后，我们会在界面上把上线测试的数据删除，正常上线。
如果发现bug，开发人员当场修复bug，修复成功之后我们测试再复测，通过就可以正常上线
如果严重就延期上线，如果我们是迭代版本的话我们还需要版本回滚。
如果不严重，产品跟客户觉得可以上线，就正常上线。
(1)一般都是我们测试人员在测试过程自己造的测试数据，如果大量数据，我们可以用到存储过程。
直接是不能导出。
1)用Jmeter或者其他自动化测试工具造大量数据
2)让开发修改概率的比例
1)提高测试效率2)提高测试覆盖率3)监控测试进度情况4)也是质量的标准指标
CMM质量体系(用例数也是一个度量标准QA岗位)
原来我们主要是用exce编写的，当然也用过用禅道，testlink去编写，禅道都是excel表格编写完成，导入禅道系统，testlink也可以Exce表格，编写，编写测试，导入testlink
1)项目背景和目的2)测试用例设计3)测试环境4)测试过程用到的工具
5)测试范围6)测试用例执行情况7)测试缺陷分析和总结8)测试结果
参考答案2：
这个是写过的，测试报告，其实就是把我们测试的整个过程情况，数据统计，做成报告，包括用例执行情况，测试了哪些模块，多少用例，会哪里模块，自动化通过率，自动化跑了多少，是否全部通过，发现了多少bug，bug的情况，是否遗漏bug，测试结论等等这些，基本就这些。
测试报告里面有个测试结论：
1）bug的情况、bug级别、bug分布情况(分布哪些模块)、
bug产生原因(设计问题，需求问题，代码问题)
2）测试是否通过
能够发现bug的用例就是一个好的测试用例
当然我们在编写测试用例的时候，一定要步骤、场景清晰、尽量去覆盖所有的测试场景
冒烟测试一般我们是在系统测试之前，对所有主体的业务功能，测试看是否存在严重bug，
如果存在严重bug，表示，冒烟测试不通过
1）功能的回归
优先测试用例级别比较高的功能模块，可以进行自动化测试
2）bug回归
1）测试，需求理解上面有偏差
2）测试人员水平不够，测试人员覆盖点不全
4)测试环境上面不足，导致测试点不能完全测试完成
把需求了解通透，引用用例评审机制，然后编写测试用例的时候用边界值，用等价类补充一些用例，根据过往经验用错误推断法来追加一些用例，如果存在组合情况的话我会用因果图或者判断表来编写，如果业务场景清晰的情况下我会用流程分析法，如果状态有发生改变的话我就会用状态迁移法。编写用例一个极其考验耐心的事情，要考虑到各种场景，全面覆盖到会出现的场景。
先跟面试官确定，产品什么是转测；
1）测试用例执行率100%，通过率95%
2）1-2级bug修复率达到100%，3-4级bug修复率达到95%
如果是同一个横块，重复用例，我们可以考虑不再进行重复测试，如果不同模块，引用相同的测试用例，我们还是需要重复测试
有：我们会去单独去编写测试用例，只是主体流程用例，新增功能的用例
没有：我们会挑选原来测试用例中，级别比较高的用例去执行，或者我们建立一个checklist列表，去检查功能是否正常使用。
git工具相当于svn工具，分支开发每个版本或者模块，开发不同模块，分支合并，把所有的功能全部整合起来，其实就划分功能模块去开发。
Web：
不同的浏览器，E，谷歌，火狐，浏览器显示比例，浏览器前进，后退，刷新按钮。
App：
不同手机厂商，型号，系统版本，内存大小，分辨率，屏幕的大小，高端机与低端机，考虑平板
1）对于测试来说，还是良好耐心，问题无法避免事情，重复的事情还是要去执行
2）重复事情，我们用自动化测试来进行替代
1）确定下，我们几个项目是否可以同步发布完成
确定下项目的优先级，跟客户这边商量优先级低一些项目推迟发布(产品跟客户)
1）开发人员发邮件告知对应的测试人员：新的代码地址、最新的sql文件、需求开发完成的情况。
2）测试人员把最新的代码和sql脚本更新到测试环境中，并进行冒烟测试，
要是冒烟测试不通过则转测失败。
java后台开发：
SSMspring+springy+mybaits（数据的封装）
SSHsprint+springmvc+hibernate
springboot
fianl极速开发框架
maven项目pom.xml文件...中央仓库
python后台开发框架
Djangoflask
前端开发语言：
JavaScript+css+htmlbootstrap框架常用库：jquery简称JQEs6/E57
phpThinkPHP框架
根据自己的项目整理完成，要点：
1）项目背景、业务、需求、核心业务的流程
2）项目架构，B/S还是C/5，数据库用的什么中间件用的什么？后台什么语言开发的？
是否有做App端，是否有H5是否开发小程序等等。
3）项目前端有哪些功能模块，后台有哪些功能模块？
根据自己的项目整理完成，核心要点：
1）拿一个你负责过的模块，核心业务模块讲解
2）业务流程是怎样的，需求怎么样，有什么规则没，规则简单介绍
3）你是如何分析的，讲明分析思路，测试点，主要怎么考虑测试的，主要核心测试重点在哪里，
用了什么测试方法等等。
1）在这个项目中，主要是以功能测试跟后台接口测试为主，主要参加了需求评审会议，用例的编写，
参与用例的评审，执行测试。
2）协助开发定位问题解决发现的bug，编写测试报告，协助上线。
[这个具体根据你自己的简历上写的来说]
[公司具体人数，可以不太清楚，项目组多少一定清楚]
[这个一定要根据自己的简历项目大小来说，不能乱说]
产品1、项目1个、架构师1个、前端3个、后端5个、ios1个、Android1个、
测试3个(测试主管，核心测试人员)、运维1个、UI一个
1）我们测试组3人，1个测试组长，2个测试，一般都是根据需求的复杂程度大小来，
尽量是自己熟悉哪个版块的就继续做那个版块。
2）比如：我这边主要是负责前端大部分的功能模块，还有接口测试跟ui自动化测试，另一个同事主要是功能测试这边，组长这边也负责一些功能测试，包括一些性能跟安全测试。
3）其实测试工作也划分的没有那么细，后期我们也会做交叉测试，相互测试功能，性能跟安全测试我也会参与一下。
[切记工具自己所选择的项目来回答]
我们公司是这样的，迭代还是蛮快的，一般是两个星期一个迭代，迭代测试两轮。Bug的话不一定哦，关键还得看开发，哈哈，开发的版本质量好的话，BUG就会少些，整个版本比较好的情况下大概也就二十来个BUG，当然如果遇到开发是个新手，那么找到60-70个也是很常见的，比如之前的那个金融项目，足足发现了72个BUG，这样的情况下追踪BUG的工作量都比较的大，如果是版本选代的话，那么基本就不会出现多少BUG了。
因为我们项目的用户活动和三方合作平台比较多，一般半个月或者1个月肯定会有一个迭代版本，
假如用户或者合作方突然有很紧急的需求，那一般老大他们会向上发邮件和OA呈批给(产品经理，项目经理)，如果通过了就会马上加急处理这个需求，测试完成直接上线。
现在都是维护为主，但新需求也不断有，一般一个版本上百个bug是有的。
[切记己根据自己的项目及负责的模块来]
答：这个得根据项目的复杂程度，我们最近做的这个也还好，整个项目写了大概2干3百多条(有点多了)，我负责的模块就写了一千多条(你要思考，你负责了哪些模块，大概评估下，不要乱喊)。
总结注意点：没有标准答案，先说你的前置条件，再说数据，只要你前置条件和数据匹配即可。
(总结注意点：没有标准答案，先说你的前置条件，再说数据，只要你前置条件和数据匹配即可
特别注意：你如果是半个月的版本，一般给你两天写用例，你自己评估下写多少。
最近的版本因为没有特别的用户活动，产品那边也没有给特别大的改动需求，我负责的
有5个模块吧，大概有180多条用例。
备注说明：uat：测试人员提供用例，uat环境已搭建好，他就开始来执行，如果发现问题，
需要协助，谁负责这个需求，就找对应的人，发现bug，提交到uat版本里面，修复完了，
客户需要回归验证的，我们公司只是辅助他去执行测试。
答案：
看他需要的数据能不能从上个版本，或者生产环境导入数据进来测试，如果没有，我们看能不能批量修改数据去测试，如果不行，我们只能通过存储过程造数据了。
根据自己的项目来准备，核心要点：
2）具体怎么分析，讲明你的分析过程。如何定位的......
比如:业务逻辑漏洞；
支付功能:
1）商品选择支付的时候，实际已扣款成功，但是用户后台显示该商品没有付款，
导致不能使用该商品提供的服务。
2）商品所显示的价格是x元，但是实际支付的时候显示和扣款的价格是y元(x≠y)
找密码流程：
按照常规操作，会直接跳跃了某个必须的流程(流程缺失)，但是通过url修改参数又可以访问到该流程，存在安全和逻辑漏洞。
安全漏洞：
2）搜索功能：前端页面的搜索输入框中输入特殊敏感符号
cookie信息直接以弹框的形式暴露出来。
3）新增功能：一开始没有限制字符的类型和数量，当输入特殊符号、超长的字符，
提交后直接抛出包含有INSERTINTO的完整SQL语句。
4）前端搜索：以敏感字符直接搜索后，客户端和服务端都没有任何字符过滤or转义处理，
直接把数据库和网站服务器的名称、版本暴露。
数据调用/加载异常:
1）翻页功能：有时候会出现前面几页翻页和数据显示都是正常的，往后再翻页就会
出现翻页不了or加载的数据异常。
2）前端页面有几级菜单的情况下，程序都已经调用过，第一级是正常展示的，但是第二级、
三级有可能被折叠而没有显示在浏览器显示。
3）定位到某个导航主题，调用的数据并不是该主题分类的数据，而是调用成了其他分类的数据。
不可逆操作，导致流程受阻：
1）APP测试，orH5页面测试，触发某个操作，比如手机触屏下滑刷新页面，不能恢复到操作前的正常页面。
4）删除异常：正常情况下可以从列表中删除记录，但是若先对列表记录执行了搜索功能之后，再次删除的时候可能出现删除无响应而删除不了数据。
5）弹框阻止：当触发某个操作，如“保存”、提交”or某个开关按钮，界面中弹单出一个提示框，此提示框不管怎么操作都无法关闭，直接阻碍了页面上其他功能的操作。
附件上传时，未控制格式尺寸和容量大小，系统处理出现异常：
缺少非空判断，服务器报500错误：
1）编辑包含多个字段的页面时，有一些字段在程序中控制是必填的(事先未知)，但是没有任何说明提示，当不填写这些字段，直接保存时会出现服务器异常页面，报500状态错误。(特别是在管理后台容易出现此场景)
2）在形如以下结构的if函数中，关系表达式的条件没有对某个变量(该变量因代码疏漏未作初始化赋值)进行非空判断，就直接执行语句体，程序已空值null进行参与运算而出现异常，如500错误if(关系表达式)样式导致异常。
3）某个功能(如：金额输入和统计)在A页面程序限制只能输入正整数，而在B页面却没有相应控制，若不小心在B页面输入了非正整数，比方小数，A和B的数据分别传递到到同一个C页面时数据处理会出现异常。
[经典bug：前端申请借款中，用户没有信用额度或者借款金额超过了用户信用额度但是却能成功提交审核]
[发现途径：我是在模拟借款人，借款金额提示我的可用额度为0，但是我输入5000的借款金额点击提交审核提示我提交成功，等待审核]
[解决：首先我去数据库查找到对应的表，比对我的信用额度跟界面显示的数据是否一样，一样我就把数据库的记录，填写的借款信息和我借款成功的界面显示截图都保存好。之后提交这个bug，开发人员通过修改代码，我再复测，有没有重现bug]
[还有一个是在产品上线后，运维人员在统计数据时发现少了一条数据，我们去数据库检查发现0分0秒的数据没有统计，后来开发人员修改了代码之后就解决了]
1）服务费计算错误，计算公式开发这边写错，本来是利息0.3，写成003，开发修复bug。
3）重新选择下拉框，输入信息全部清空，原因，修改类型，重新刷新界面，输入数据，并没有保存缓存里面，导致一刷新，原来信息没有，解决，开发选择不同借款类型，不再进行刷新。
4）借款标题，输入xss攻击代码，导致接口所有的数据不存在显示，因为xss脚本，当然代码处理，开发这边进行转义字符串。
1）需求阶段，大家都在了解需求
2）测试准备，
测试编写用例，开发做概要设计，详细设计，然后就是编写代码，编写接口文档，设计文档。
3）测试执行阶段，
测试人员执行用例，发现bug、提交bug、开发修复bug(开发还有可能在开发未完成的功能)
可以说是，也可以说不是。[具体看你了不了解敏捷开发模式]
[问了我有没有做过敏捷测试]
扩展知识储备：
1、什么是敏捷开发
敏捷开发以用户的需求进化为核心，采用达代、循序渐进的方法进行软件开发。
在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，
具语可视、可集成和可运行使用的特征，换言之，就是把一个大项目分为多个相互联系，
但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。
2、敏捷开发优缺点：
特点：
1、能适应快速的客户需求变化，快速的交付，注重与客户的沟通。最优先要做的是通过尽早的、
持续的交付有价值的软件，把项目拆分成各个小的子项目，快速开发快速交付，有问题及时调整，适合高风睑项目。
不过每个选代版本的需求不会太多，注重项目持续选代开发交付。
3、整个项目开发期间，业务人员和开发人员必须天天都在一起工作，团队规模不能太大，
团队间强调面对面的交谈。
5、对团队技术要求高，能快速适应客户对需求的变化。
6、敏捷团队只专注于开发项目中当前最需要的、最具价值的部分。这样能很快地投入开发，另外，较短的迭代周期使团队成员能迅速进入开发状态。
优点：
1、敏捷开发的高适应性，以人为本的特性，适应客户的更快需求变化，更快的交付成果。
2.更加的灵活并且更加充分的利用了每个开发者的优势，调动了每个人的工作热情。
缺点：
1、由于其项目周期很长，所以很难保证开发的人员不更换，而没有文档就会造成在交
接的过程中出现很大的困难。
2.特别项目存在新手比较多时，老员工比较累.(对开发团队人员的技木要求高)
3、敏捷开发流程图：
我们会从几个方面去测试：界面、功能、兼容性、易用性、安全、性能、异常。
1）界面我们会测试下是否跟界面原型图一致，考虑浏览器不同显示比例，屏幕分辨率。
3）兼容性：不同手机型号，厂商，不同系统版本，屏幕大小，分辨率，内存大小
4）易用性：操作是否说的越多越好
功能测试：
1、水杯是否可以正常装水
2、水杯是否可以正常喝水
3、水杯是否有盖子，盖子是否可以正常盖住
4、水杯是否有保温功能，保温功能是否正常保温
5、水杯是否会漏水，盖住盖子拧紧后是否会漏水
界面测试：
1、外观是否完整
2、外观是否舒适
3、颜色搭配及使用是否让人感到舒适
4、杯子外观大小是否适中
5、杯子是否有图案，图案是否易磨损
易用性测试：
1、水杯喝水时否方便
2、水杯拿起放下是否方便，这里会行注到水杯形状的测试
3、水杯装水是否方便
4、水杯携带是否方方便
5、水杯是否有防清功能
6、水杯装有低温或者高温水时，是否会让手感到不适
性能测试：
1、水杯装满水时，是否会露出来
2、水杯最大使用次数
3、水杯的保温性是否达到要求
4、水杯的耐寒性是否达到要求
5、水杯的耐热性是否达到要求
6、水杯掉落时时，是否可以正常使用
兼容性测试：
可移植性测试：
1、将水杯放在常温环境中，使用是否正常
2、将水杯放在零下的环境中，使用是否正常
3、将水杯放在高于正常温度的环境中，使用是否正常
安全性测试：
1、当水杯装满热水时，水杯是否会烫手
2、当水杯装上水后，是否会产生有毒物质
3、把水杯放在零下环境时，是否会产生有毒物质
4、把水杯放在高温环境时，是否会产生有毒物质
1.检查图片上传路径
2.检查图像上传和修改功能
3.检查各种扩展图像文件的上传（例如JPEG、PNG、BMP等）
4.检查文件名中含有空格或其他可用特殊字符的图片的上传
5.检查重复名称图片上传
6.图片尺寸大于最大允许值，上传时应该显示适当的错误消息
7.检查上传的图片文件类型外的其它文件时(例如txt、doc、pdf、exe等等)，
应该显示适当的错误消息。
8.检查如果上传的图片满足指定的高度和宽度(如果有定义的话)则可以成功上传，否则不能上传。
9.上传大尺寸图片时应显示上传进度条
10.检查上传过程中的取消按钮是否有效
11.检查文件选择对话框中的文件列表是否只显示支持文件类型
12.检查上传多个图像的功能
13.上传后检查图像质量，图像质量不应该改变
14.检查用户是否能够使用/查看上传的图像
1)搜索按钮功能是否能够实现，验证搜索框的功能是否与需求一致
2)点搜索后，原先的搜索条件是否清空。
3)直看比较长的名称是否能查到输入过长查询数据，看其有没判断，报错系统是否会截
取允许的长度来检索结果。
4)是否有忽略空格的功能，需要有忽略前置空格和后置空格的功能，但不能把中间空格忽略
5)不输入任何内容点击搜索看查询的结果
6)查看搜索框内的默认内容是否与设置的一致，焦点放置搜索框中，搜索框默认内容是否自动被清空
7)输入系统中存在的与之匹配的条件看其的查询后数据的完整性显示记录条数正确、文字折行显示正确页面布局美观列标题项、列显示内容、排序方式符合需求定义。
8)组合中文和各种特殊符号输入查看能否正确搜索到合的内容
9)输入系统中不存在的与之匹配的条件，是否搜索出信息或者给予提示信息
10)使用复制粘贴，测试搜索框是否能执行
11)注意在光标停留的地方输入信息时，光标和所输入的信息会否跳到别的地方
12)反复输入相同的数据(5次以上)看是否报错
13)敏感词汇，提示用户为敏感词汇
{
语句提1；
}else{
语句提2
}
3.某个被调用的方法中缺少某些参数的定义，在不知情的情况下，直接调用时传递了未定义过的参数or类型不匹配的参数到该方法，如果对应网站是处理批量的业务，则可能会导致大面积的500异常页面，对网站正常业务和SEO排名损失风险比较大。
4.新增、编辑->保存，对所提交的字段有的末作非空限制，可以直接保存成功，保存后以空内容展示，可能存在不确定性，比如操作已保存成功的空记录时，是否会影响其他正常添加的记录，是相互独立的，还是会牵连到其他所有的类型。
服务器配置错误(漏配or错配)，更新后出现500or404：
1.服务器配置文件，如web.config中把前端访问的url地址写错，直接发布更新之后，前端页面访问可能会出现404错误。
2.程序代码中的某些逻辑错误和服务器配置相冲突时，前端页面触发某些特定按钮or页面可能会出现500错误。
数据传递过程无控制，导致数据输出到界面功能异常or样式变形：
1.搜索功能：有的页面本身有回显所搜索关键词的功能，搜索输入框填写的keywords字符较长
(如：100字符)，直接搜索后这些长字符显示在页面中，使得页面原来的样式变形，
甚至有的功能按钮被挤到页面之外而不能使用。
2.新增功能：对于新增字段的长度没有任何限制，超长字符新增可以保存成功，回到列表页也没有对显示的字符长度进行控制，所有字符长度都展示在列表，挤压其他字段的
14)不同搜所的条件之间来回选择，查看是否出现页面错误
15)测试多个搜所条件时，要注意搜所条件的组合测试，可能不同组合的测试会报错
直达搜索结果页
17)点击搜索框时，到有搜所历史时，能显示历史搜所内容，历史搜所内容应从上到下按