问题1：请介绍下你所在公司的项目的测试流程 1.拿到需求文档后，写测试用例 2.审核测试用例 3.等待开发包 4.部署测试环境 5.冒烟测试（网页架构图） 6.页面初始化测试（查看数据库中的数据内容和页面展示的内容是否一致，并且是否按照某些顺序排列） 7.具体执行测试用例（几乎所有的功能测试、流程法、场景法） 8.发现缺陷就要再填写缺陷表 9.非功能性测试（sql、js注入、页面效率、绕过js验证直接添加数据到数据库） 10.书写最终的测试报告
问题2：请介绍下测试用例设计方法 等价类、边界值、正交试验法、状态迁移法、因果图、场景测试法、异常分析法、因果图、错误猜测法、判定表
问题3：测试用例的要素 Id 主题、测试名称、创建日期、设计者、描述、步骤名、步骤描述、预期结果、执行状态
问题4：拿到一个差评后，请介绍下测试的优先级 1.先测试经过变更的部分，然后测试没有变更的部分； 2.先测试程序的核心功能，然后测试一般功能； 3.先测试逻辑性的功能，然后测试业务性的功能； 4.先测试常规情况，然后测试异常情况； 5.先测试功能，然后测试性能。
问题5：测试报告包含哪些内容？ 1.写测试背景 2.测试目标 3.测试范围 4.测试环境 5.测试数据 6.测试标准（重点） 7.测试进度 8.测试结果 9.测试结论 有的公司会采用非标准的测试报告，大致会包含：测试所用时间、测试环境、测试人员、测试发现bug数量、已修复bug数量、遗留bug、遗留bug原因、测试结果等。
问题6：请介绍下BUG的生命周期。 提交--开发验证--接受--拒绝--开发解决--测试人员验证--关闭--不通过打开。
问题7：app测试的主要内容有哪些？
- 功能测试 业务逻辑正确性的测试
- 兼容性测试 系统版本、分辨率、网络情况
- 异常测试 热启动、网络切换、电话信息终端恢复
- 升级、安装、卸载
- 健壮性测试 手机资源消耗、流量消耗、电量测试、崩溃恢复
问题8：WEB测试与APP测试的区别
- 架构不同 web端是b/s架构的，b/s架构是基于浏览器地址访问的； app端是c/s架构的，c/s架构是要有客户端作为载体的。 2.版本发布的方式和流程不同 web发版本，开发部署新的代码到对应服务器地址，就可统一实现web端的更新； app发版本，开发需要打包（apk包和ipa包），打包之后需要发布到对应的渠道。
- 兼容性 web，测试不同浏览器的兼容性（ie、chrome、firefox、360、QQ）； app，测试不同的分辨率、屏幕尺寸、手机品牌、系统版本。
- 性能方面 web，测试响应的时间； app，测试响应时间、流量、耗电量、CPU、GPU、memory。
- 安全性 web，sql注入。xss攻击等； app，https加密、签名、加固、密码加密等。 6、app测试特点 适配性测试、网络测试、在线升级测试、中断测试、耗电量测试、弱网测试、安装卸载测试、流量测试
问题9：如果一个bug，开发认为不是一个bug，怎么处理？
- 将问题提交到缺陷管理库里面进行备案。
- 获取判断的依据和标准 根据需求说明书、产品说明、设计文档等，确认实际结果是否与计划有不一致的地方，提供缺陷是否确认的直接依据； 如果没有文档依据，可以根据类似软件的一般特性来说明是否存在不一致的地方，来确认是否是缺陷； 根据用户的一般使用习惯，来确认是否是缺陷； 与设计人员、开发人员和客户代表等相关人员探讨，确认是否是缺陷。
- 合理的论述，向测试经理说明自己的判断的理由，注意客观、严谨，不参杂个人情绪。
- 等待测试经理做出最终决定，如果仍然存在争议，可以通过公司政策所提供的渠道，向上级反映，并由上级做出决定。
问题10：请介绍下你们公司测试用例评审过程及相关参与人员。 1、评审的过程 A:开始前做好如下准备：确定需要评审的原因、确定进行评审的时机、确定参与评审人员、明确评审的内容、确定评审结束标准、提前至少一天将需要评审的内容以邮件的形式发送给评审会议相关人员。并注明详审时间、地点及参与人员等、在邮件中提醒评审会议相关人员至少简读一遍评审内容，并记录相关的疑问，以便在评审会议上提出、会议主持者(一般为用例编写人员)应在会议前整理相关疑问，以便在会议上提出。 B：开始评审：召开评审会议。与会者在设计人员讲解之后给出意见和建议，同时进行详细的评审记录、通用邮件与相关人员沟通、通用IM工具直接与相关人员交流、根据评审内容进行评审。 2、评审内容 A.用例设计的结构安排是否清晰、合理，是否利于高效对需求进行覆盖。 B.优先级安排是否合理。 C.是否覆盖测试需求上的所有功能点。 D.用例是否具有很好可执行性。例如用例的前提条件、执行步骤、输入数据和期待结果是否清晰、正确；期待结果是否有明显的验证方法。 E.是否已经删除了冗余的用例。 F.是否包含充分的负面测试用例。充分的定义，如果在这里使用2&8法则，那就是4倍于正面用例的数量，毕竟一个健壮的软件，其中80%的代码都是在“保护”20%的功能实现。 G.是否从用户层面来设计用户使用场景和使用流程的测试用例。 H.是否简洁，复用性强。例如，可将重复度高的步骤或过程抽取出来定义为一些可复用标准步骤。 3、参与评审人员（这里会分为多个级别进行评审） A.部门评审，测试部门全体成员参与的评审。 B.公司评审，这里包括了项目经理、需求分析人员、架构设计人员、开发人员和测试人员。 C.客户评审，包括了客户方的开发人员和测试人员。这种情况在外包公司比较常见
