1）功能测试

1、测试用例怎么保证覆盖率

***测试用例对需求的覆盖率；

*需求的理解分析

需求来源又分为显式需求和隐式需求，显式需求顾名思义是明面上的需求，比如产品人员从用户那里搜集的原始需求、转换后的产品需求、原型图、设计文档等；那隐式需求包含了用户的体验等。那我们如何保证需求分析的全面性呢？

从业务角度进行分析：通过业务流程、业务数据、业务操作等分析，明确要验证的功能、数据、场景等内容，从而确定业务方面的测试需求；

从技术角度分析：通过研究系统架构设计、数据库设计、代码实现等，分析其技术特点，了解设计和实现要求，包括系统稳定可靠、分层处理、接口集成、数据结构、性能等方面的测试需求；

基于以上分析，拆分需求点，形成测试点。

*需求评审：参与需求的评审，保证需求的正确性和完整性；

*用例测试：根据对需求的分析、利用专业的测试用例设计方法编写测试用例，保证测试用例的设计覆盖所有的测试需求。

*用例评审：组织产品设计人员、开发人员、测试人员等参与测试用例的评审，吸取别人的意见，减少遗漏，补全测试用例。

*执行测试：　● 对测试用例进行100%执行。●在测试执行过程中，需求都是会变的，要继续对测试用例补充完善，确保提高测试覆盖率。

2、测试用例包含哪些部分

*前提---用例名称---用例步骤---期望---等级

*用例等级如何定义？冒烟【来源于特高】特高【核心功能点】高【重要功能点】中【异常功能点】低【界面相关】

3、提bug包含哪些部分

*项目---bug类型---严重等级---出现概率---缺陷简述---缺陷详情（包含复现详细步骤）---缺陷证据（日志等）

4、怎么避免开发不自测的情况

*测试端 转测（发测后优先测试自研用例，作为正式发测的前提，不存在fail和block用例）

5、系统测试，回归测试，UAT测试，从测试角度需要注意的部分

*系统测试：模拟系统的运行以验证系统是否达到功能和性能要求；关注测试用例的覆盖率。【实际项目中对应第一轮的测试（第一轮需求全实现时）】

*回归测试：修改bug；需求变更；环境变更。导致软件程序的变动。关注影响【实际项目中的非首轮测试；以及基于基线项目的定制需求】

*UAT测试：用户验收测试；关注用户真实的使用。

6、在写测试用例之前，怎么预测一个项目的测试时间

*当前公司 发测试时间（开发评估）结合TR4（项目经理评估）时间即可知测试时间。【根据项目节点（TR4阶段为系统测试结束时间）；结合与开发一起评估需要测试的轮数；若发布最后一轮需要稳定性测试至少7天】

7、如果自我预计测试时间为3天 ，项目组要求2天测完的情况下，应该如何处理？

*首先，原测试策略不变下，反馈风险【若未能按时完成，提供风险评估（未测低等级用例对应哪些风险）】；若风险不可接受，调整测试策略至风险可接受为止。

*其次，测试内部调整参与测试的人员；测试人员预测试和提前准备测试环境，提高正式测试时的效率；组织测试人员加班。

8、bug怎么分级

*致命：阻碍开发或测试工作的问题

1）系统崩溃/死机/无法退出死循环；2）安全相关：用户数据受到破坏【篡改，丢失等】；3）基本模块完全未实现；4）其他导致功能无法测试的问题。

*严重：

1）重要功能不能实现（例如：用户所要求的功能缺失，该有的页面未实现，逻辑不通，重要图表数据未开发，等）

2）错误的波及面广，影响到其他重要功能正常实现

3）非常规操作导致的程序崩溃、死机、死循环 (非常规操作：用户使用软件时不会进行的操作）

4）系统中数据保存后数据库中显示错误

5）密码明文显示

6）页面无显示白屏，无数据

7）地图数据和图表数据不一致

*一般：不影响产品的运行、不会成为故障的起因、但对产品外观和下道工序影响较大的缺陷

1）次要功能不能正常实现

2）操作界面错误（包括数据窗口内列名的定义，含义不一致）  例如：列名与列名下的内容不一致

3）查询错误、数据错误显示

4）简单的输入限制未放在前端进行控制；（格式显示，如登录和注册中的格式判断可由前端判断）

5）删除操作未给出提示

6）边界条件错误或者未做限制

7）系统未做优化，数据页面加载慢，操作卡顿之类（性能层面问题）

8）兼容性问题（分辨率，系统版本等等）

*轻微：程序在一些显示上不美观，不符合用户习惯，或者是一些文字的错误

1）界面不规范

2）辅助说明描述不清楚

3）提示窗口文字未采用行业术语

4）界面存在文字错误

5）操作时未给用户提示

6）文字排列不整齐等一些小问题

*建议：

1）对于产品设计方面的意见和建议

2）对于产品界面优化方面的意见和建议

3）对于产品需要优化增强用户体验方面的意见和建议

结合bug出现频率：偶现【特定测试环境下，>=5%出现】，必现

9、如果在上线前，还有bug未解决，产品又必须要求上线，应该怎么处理

1）首先，产品不可能不存在bug，只是带bug发布，需要根据bug严重程度及其影响进行评估；

2）正常情况下，产品线会存在发布标准，以及项目组内对bug的评估及应对方案；

3）若存在测试不同意的bug存在，意见不同意，测试结论仍为不通过，若发布需要上升到领导层决策，含风险发布。

10.给出登录，注册的测试点

1）登录

界面相关：账号输入框（输入内容校验最长最短字符？超过最长或少于最短提示？合法字符有哪些？非法字符输入提示？中文占几个字符长度？特殊字符有哪些，重点关注SQL注入等安全？）/密码输入框（密码长度？超过最长或少于最短提示？合法字符有哪些？非法字符输入提示？不合理组合密码提示？非明文显示）。

功能相关：正确账号+正确密码/错误密码（空/不对应的密码）+正确账号/错误账号（空/不对应的密码）+存在的密码/都为空，关注提示信息不能太明确

安全相关：登录非明文传输；

性能压力：并发多用户登录跳转/进入登录页面耗时/登录成功，跳转耗时

兼容性：不同系统不同浏览器不同版本不同分辨率登录

国际化：不同语言