1，什么是回归测试
回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。自动回归测试将大幅降低系统测试、维护升级等阶段的成本。
回归测试作为软件生命周期的一个组成部分，在整个软件测试过程中占有很大的工作量比重，软件开发的各个阶段都会进行多次回归测试
2，在测试中发现了一个bug，但是开发经理认为这不是一个bug，你应该怎样解决？
首先，将问题提交到缺陷管理库里面进行备案。
然后，要获取判断的依据和标准：
根据需求说明书、产品说明、设计文档等，确认实际结果是否与计划有不一致的地方，提供缺陷是否确认的直接依据；
如果没有文档依据，可以根据类似软件的一般特性来说明是否存在不一致的地方，来确认是否是缺陷；
根据用户的一般使用习惯，来确认是否是缺陷；
与设计人员、开发人员和客户代表等相关人员探讨，确认是否是缺陷；
合理的论述，向测试经理说明自己的判断的理由，注意客观、严谨，不参杂个人情绪。
等待测试经理做出最终决定，如果仍然存在争议，可以通过公司政策所提供的渠道，向上级反映，并有上级做出决定。
3，当开发人员说不是BUG时，你如何应付？
开发人员说不是bug，有2种情况，一是需求没有确定，所以我可以这么做，这个时候可以找来产品经理进行确认，需不需要改动，3方商量确定好后再看要不要改。二是这种情况不可能发生，所以不需要修改，这个时候，我可以先尽可能的说出是BUG的依据是什么？如果被用户发现或出了问题，会有什么不良结果？程序员可能会给你很多理由，你可以对他的解释进行反驳。如果还是不行，那我可以给这个问题提出来,跟开发经理和测试经理进行确认,如果要修改就改,如果不要修改就不改。其实有些真的不是bug，我也只是建议的方式写进TD中，如果开发人员不修改也没有大问题。如果确定是bug的话，一定要坚持自己的立场，让问题得到最后的确认。
4，测试流程、测试的生命周期
首先，我们在正式测试之前会有三次评审，需求评审、设计评审、用例评审。
需求评审是由产品发起的，主要看需求是否能实现，分析功能点完善需求。
在需求评审后， 我们就可以制定好测试计划，根据功能点写测试用例，写的差不多的时候，参与由开发发起的设计评审，开发提开发思路看和需求有无偏差，设计中遇到的问题提出，
同时，我们也可以把在设计用例时遇到的问题提出来并解决。
设计评审后，编写接口测试脚本并执行测试。
用例评审，提出用例思路，完善用例，把设计用例时遇到的问题解决。
冒烟测试，功能测试，主接口测试，跑用例（有BUG提BUG，验证BUG）。
专项测试（弱网测试、手机适配、前端耗时）。
UAT测试（验收测试，由提需求的产品进行验收测试）。
回归测试
5，测试计划包含：
写用例的时间、用例评审的时间、接口测试时间、冒烟测试时间、功能测试时间、专项测试时间、回归测试时间、产品发布时间
6，怎么把控测试进度：
在需求评审后会制定测试计划，根据测试计划对每个阶段有预估的时间，时间有偏差的话就调整测试计划
7，测试报告：
需求文档链接、设计文档链接、用例文档链接或附件、测试计划、专项测试结果、测试环境使用数据、测试中的问题及解决思路
8，在测试中发现BUG怎么处理：
首先复现，看是必现的BUG，还是偶现的BUG，再BUG定位，并定位截图找出原因，然后去禅道提BUG单，并指定相关开发人员，用即时工具通知一下。
开发修改BUG后验证BUG是否修复，通过就关闭，不通过重新打开。
9，BUG不承认怎么处理：
证据拿出，发邮件并抄送领导
BUG不需要处理：
设计如此，BUG单汇总邮件告知开发人员和相关领导
BUG暂时不解决：
汇总BUG单，标明原因，再把BUG单状态改掉（延期）
10，接口自动化框架：
我们是基于java语音做接口自动化的，用的工具是idea，还有其他的一些基础配置JDK、maven、和git，做自动化要用到的框架有testNG、fastjson、httpclient还有关于美化测试报告的Allure。
11，怎么做接口自动化：
首先结合接口规范和swagger将请求和响应报文转成javabean,正式写自动化代码是先给请求的javabean设值，再将请求javabean转成转成json格式，再调用httpclient方法去发送请求并接受响应，
再将响应转成响应javabean后做断言
12，注册，登录的测试用例，大概有哪些？
输入已注册的用户名和正确的密码，验证是否登录成功；
输入已注册的用户名和不正确的密码，验证是否登录失败，并且提示信息正确；
输入未注册的用户名和任意密码，验证是否登录失败，并且提示信息正确；
用户名和密码两者都为空，验证是否登录失败，并且提示信息正确；
用户名和密码两者之一为空，验证是否登录失败，并且提示信息正确；
如果登录功能启用了验证码功能，在用户名和密码正确的前提下，输入正确的验证码，验证是否登录成功；
如果登录功能启用了验证码功能，在用户名和密码正确的前提下，输入错误的验证码，验证是否登录失败，并且提示信息正确
用户名和密码是否大小写敏感；
页面上的密码框是否加密显示；
后台系统创建的用户第一次登录成功时，是否提示修改密码；
忘记用户名和忘记密码的功能是否可用；
前端页面是否根据设计要求限制用户名和密码长度；
如果登录功能需要验证码，点击验证码图片是否可以更换验证码，更换后的验证码是否可用；
刷新页面是否会刷新验证码；
如果验证码具有时效性，需要分别验证时效内和时效外验证码的有效性；
用户登录成功但是会话超时后，继续操作是否会重定向到用户登录界面；
不同级别的用户，比如管理员用户和普通用户，登录系统后的权限是否正确；
页面默认焦点是否定位在用户名的输入框中；
快捷键 Tab 和 Enter 等，是否可以正常使用。
用户密码后台存储是否加密；
用户密码在网络传输过程中是否加密；
密码是否具有有效期，密码有效期到期后，是否提示需要修改密码；
不登录的情况下，在浏览器中直接输入登录后的 URL 地址，验证是否会重新定向到用户登录界面；
密码输入框是否不支持复制和粘贴；
密码输入框内输入的密码是否都可以在页面源码模式下被查看；
用户名和密码的输入框中分别输入典型的“SQL 注入攻击”字符串，验证系统的返回页面；
用户名和密码的输入框中分别输入典型的“XSS 跨站脚本攻击”字符串，验证系统行为是否被篡改；
连续多次登录失败情况下，系统是否会阻止后续的尝试以应对暴力破解；
同一用户在同一终端的多种浏览器上登录，验证登录功能的互斥性是否符合设计预期；
同一用户先后在多台终端的浏览器上登录，验证登录是否具有互斥性。
不同浏览器下，验证登录页面的显示以及功能正确性；
相同浏览器的不同版本下，验证登录页面的显示以及功能正确性；
不同移动设备终端的不同浏览器下，验证登录页面的显示以及功能正确性；
不同分辨率的界面下，验证登录页面的显示以及功能正确性。
以下是我根据自己在测试过程中所遇到的问题及发挥了一些自己的想象所做的补充（主要针对APP登录测试）：
1、登录失败后二次登录
（1）输入正确的用户名，不输入密码，点击登录；登录失败后，再次输入正确的密码登录并观察登录情况
（2）输入正确的用户名和错误的密码登录失败后，再次输入正确的密码登录并观察登录情况
（3）输入未注册的用户和任意密码登录失败后，再次输入正确的用户名和密码，观察登录情况
2、修改密码后
（1）修改完密码后是否重定向到登录界面
（2）修改完密码后，分别使用原密码和新密码登录
（3）在其他终端修改密码后，本终端是否自动下线？下线后，使用原密码能否继续登录？
3、退出登录
（1）退出登录是否有记住账号或记住密码功能
（2）退出登录后，再次输入密码登录
4、数据同步
（1）第一次登录时，数据的同步情况，如个人头像，好友列表等
（2）本终端切换其他账号登录后，数据的同步情况，日志记录情况，如：用户文件夹是否自动创建
5、账号互踢
（1）不同页面下被踢，如：后台运行时被踢，进入前台查看反应；前台运行时一级、二级页面下被踢能否提示正确并重 定向到登录界面
（2）本终端被踢下线后点击登录能否再次登录
6、密码错误限制次数
（1）密码输入错误是否有最大次数限制？分别测试最大值-1、最大值、最大值+1时的输错密码情况
（2）超过最大次数限制后，是否采取强制手段限制登录或对账号暂时冻结处理
（3）超过最大次数限制后，分别输入正确的密码和错误的密码再次登录
7、安全性
（1）本终端用户已登录，在其他终端尝试登录本用户账号登录失败时、本终端是否有账号异常操作的安全提示
（2）输入密码时是否有安全键盘模式？点击密码输入框是否能调起安全键盘？（参考各大手机银行APP）
8、网络相关
（1）无网络模式下登录，是否给出“网络未连接”或“网络异常”的提示及提示是否正确
（2）第一次登录请求超时后（服务器出问题，随后恢复正常），再次请求登录能否登录成功
（3）第一次无网络情况下登录失败后，再次连接网络并登录
（4）正在登录过程中，遇到网络切换，如（4G切换到WiFi环境时）能否正常登录
9、其他
（1）已登录的用户，杀死APP进程后，再次打开APP是否依然为已登录状态
