一、怎么理解测试？你认为什么是测试？
答：测试是无处不在的，撇开软件，从生活来看比如买回来一个东西，会去检查质量问题，考试交卷前会检查等其实这都是在测试，目的就是为了发现错误，避免影响应用体验。回到程序中，测试是产品上线的最后一道把关，如果测试工作做得到位，就能避免很多的问题，像复工后钉钉系统短崩、12306高峰期买票老进不去，这其实就是性能做的不够好，测试人员在性能测试时也没测出来它的饱和值，所以说，测试在软件中是非常必要的，可以找出软件中存在的问题。
二、对测试了解多少？
答：在平时的不断积累中，我掌握了测试的基本理论，编写测试用例的方法、常用的测试模型、测试工具的简单使用，比如loadrunner、selenium、禅道等，还有一些简单的测试框架
三、你为什么想做测试而不做研发？你觉得自己为什么适合做测试？
兴趣很重要啊，这个参考一名优秀的测试人员应该具备哪些技能，主要从性格、能力、逆向思维、耐性等方面展开来讲
四、测试和研发的区别？测试和测开的区别？
测试和研发：两者在工作职责、难易程度、技能要求等方面都有所不同。测试主要职责是找出程序中存在的问题，相对开发来说广度大专业度低，技能要求更广泛，像测试手段以及测试工具使用代码走读、业务和架构分析以及用户需求方面都要有所掌握。研发的主要职责是实现产品的功能，相对测试来说广度低专业度高，专业技能要求也更高。工作环境基本类似、在敏捷开发下，两者的压力也差不多。
测试和测开：功能性测试主要是手工的去执行写好的测试用例，验证实际输出和预期结果是否一致。而测试开发是把手工要做的活编写成自动化测试脚本，代替手工测试的这个过程。
五、什么是bug?怎样描述一个bug?bug的生命周期
答：总的来讲，程序没有实现用户的合理需求时就说明有bug。规格说明书时，一般产品都会有规格说明书，在规格说明书合理且正确的情况下，这时要是程序和规格说明书不符就是bug；
一条bug记录最基本应该包含bug编号、bug所属模块和版本、bug的优先级、具体的问题描述还有预期行为的描述、bug的级别、还有它的发现日期以及谁发现的、修改日期怎么修改的谁修改的，以及回归结果等，有多个bug同时存在时应该条理化，必要时可以有错误截图和日志，帮助开发人员清晰的定位bug；
新发现一个bug提交到平台还没指派给开发时它的状态是new，分派给开发以后状态就变成了open。 如果开发直接认为这个bug不需要修改，就变成了rejected，要是开发觉得可以延迟修改，就是dalayed。要是直接修改的话，修改完就是fixed，测试回归通过以后就是closed，不通过在reopen。
六、你提交了一个bug，开发不认为这是bug，你该怎样处理这个冲突?在你看来,怎样的bug开发觉得不是bug?
答：开发认为这不是bug,可能是需求不明确，我和开发产生了歧义，可以找产品经理确认一下需求，然后再决定要不要修改。也有可能是我把bug描述不清，这个时候我会像开发解释我确定它是bug的依据是什么，站在用户的角度去评判看会不会影响使用体验，如果开发依然认为这不是bug，可以发起bug评审，像项目评审同行评审和用户评审。同时也要提升自己的业务能力，尽可能的附上bug相对应的解决方案。
像字体大小显示、图片有不明显色差、
七、产品上市前你发现了bug你会怎么做？会让产品上市吗？为什么？
答：首先看bug的等级，如果是影响使用的功能性bug，必须得辛苦开发人员及时修改，如果是不影响功能的建议性的bug，时间允许的话尽量完善后在上线，要是时间不允许，可以先上线，因为现在产品迭代更新比较快，可以再下一次的版本中进行修复。
八、测试和研发的生命周期？测试的流程？
研发的生命周期首先是对问题进行定义规划，讨论产品可行性，在进行需求分析，根据需求分析的结果对整个系统进行软件设计，比如数据库设计框架设计，设计完成以后就可以开始进行程序编码了，然后进行软件测试发现bug并加以纠正，最后进行长期的运行维护，主要包括纠错性维护和改进型维护。
测试的生命周期（我觉得流程也是这，不知道认识有偏差没）：先进行需求分析得出测试需求，测试计划阶段根据需求编写测试计划，测试设计主要搭建测试用例框架编写具体的测试用例，测试执行阶段就是拿自己写的测试用例去执行，最后是测试评估编写具体的测试报告。
九、说一下自动化测试和非自动化测试
答：自动化测试包括功能自动化、性能自动化、安全自动化。我们平常说的指功能自动化，就是把手工测试用例转化成脚本实现，主要是为了把人从重复的活动中解放出来，主要用于回归测试，出错率低。而非自动化测试就是手工去测试，执行效率慢，量大的时候容易出错，两者不可相互替代，他们是相辅相成的。
十、编写测试报告的主要元素？
答：应包括测试背景、测试范围、测试环境、测试方法、测试结果说明还有质量或风险评估。
十一、说一下黑盒测试和白盒测试？
黑盒测试就是功能性测试，比较简单，不关心程序的内部实现，从用户角度很容易理解，只看输出结果和预期的是否一致，它的主要测试方法有等价类边界值、因果图、错误推测，它的优点是执行起来比较快，不关心内部细节，缺点是很多程序路径都没有被测试到，这就会存在隐藏问题，测试用例不清晰的话，测试很难执行。
白盒测试是结构性测试，需要去关注程序的源代码和它的内部逻辑结构，主要测试方法包括代码检查、程序编译、路径覆盖、逻辑覆盖、循环覆盖、静态结构分析等，它能仔细考虑软件的实现，对代码的测试比较彻底，能揭示隐藏在代码中的错误，因为测试基于代码，只能知道开发人员实现的对不对，而不能得知设计是否正确，系统庞大时测试成本机会很高。
十二、编写测试用例的方法？
答：主要包括白盒测试（逻辑覆盖、循环覆盖、基本路径覆盖）和黑盒测试（等价类、边界值、错误推测法、因果图法、场景法、状态图、随机测试）
十三、测试终止的条件是什么？结束的标准？
答：系统在一定性能下平稳运行72小时，在bug提交平台里不存在一般级别以上的bug,普通bug数量不超过3个，bug的修复率在90%以上，项目经理和测试经理签字通过了这个版本。
十四、测试用例的要素？怎样的测试用例是好的测试用例？
答：测试用例的要素包括测试编号、模块名称、编写人和编写日期、操作说明、输入数据以及预期结果。好的测试用例是一个完备的集体，能够完全覆盖测试要求、等价类的划分也要准确。
十五、说一下敏捷模型？敏捷模型需要开那些会议？
答：敏捷开发是当下很流行的一种开发模式，主要特点是周期短迭代快，Scrum是当下比较常用的一种方式，它主要包括三个角色，product owner是产品经理，负责整理和讲解use story(用户故事)，制定这一期迭代要完成的任务，scrum master是项目经理，负责召开各种会议，成员在会议里回答任务进度和所遇到的问题，team是研发团队，由不同技能的成员组成，共同完成每一次迭代。
常开的会议包括四个，迭代计划会议主要是讨论这一期迭代应该完成哪些目标、每日例会主要是团队成员回答任务进度还有今天要完成什么、演示会议就是迭代完成后相关人员演示迭代的成果、回顾会议是对本期迭代进行总结并制定改进计划。
我先点赞为敬，你们看着办哈
