高内聚低耦合
高内聚指的是将相关的功能或数据组织在一起，使得模块内部的各个元素紧密地联系在一起，完成特定的任务。
低耦合指的是模块之间的依赖关系尽可能地降低，模块之间的接口简单清晰，减少模块之间的相互影响。

整个项目开发过程中有哪些需要测试参与的环节

需求评审、代码设计评审、代码评审、测试评审、测试执行、缺陷跟进、上线评估、上线后的测评、线上数据分析、线上问题跟踪、回归测试自动化、定期的缺陷分析和用例/流程改进

如何预估测试工作量

根据测试计划，预估测试用例设计及评审、测试计划制定及评审、测试执行及缺陷跟进、上线准备、上线后的跟踪和数据分析、回归测试自动化分别所需要的时间，同事考虑测试过程中可能存在的风险（比如首次提测无法达到测试开始标准、对其他团队的依赖导致的延迟、可能的需求变更导致的测试范围变化等）给出对应的可能结果和应对方案

测试过程中如何保障测试用例能够及时更新

1、借助测试用例管理工具，比如禅道、testrail对测试用例进行版本管理
2、需求、设计或者实现发生变更时即使更新用例
3、定期的测试用例评审保证测试用例有效性

测试计划应该与哪些利益相关人员沟通

测试计划及相关开销、排期估计，需要与包括开发团队、产品经理、市场运营团队、项目经理、测试团队等所有利益相关者沟通，以确保测试范围和测试排期与项目的整体预期保持一致

如何与开发沟通一个开发不认为是缺陷的问题

1、从用户体验的角度看目前的行为是否合理
2、竞品比较，行业内其他类似的产品是如何处理的
3、邀请产品经理介入，询问他的意见

如何与开发沟通一个不总是能复现的缺陷

1、通过不同的测试条件(设置、数据、账号等)的组合尝试找出可能触发问题的场景
2、保留问题发生时的完整日志，尝试从日志中发现可能的错误
3、在缺陷报告中提供完整的场景描述、截图录屏、日志以及发生概率，配合开发人员做后续测试和分析

如何衡量和保证测试覆盖率

1、根据业务流程图、数据处理时序图、类图等设计文档检查用例对主要分支的覆盖程度
2、邀请产品经理、项目经理、开发团队、测试团队审核测试用例
3、根据测试过程中发现的问题对出现问题较多的功能加强用例覆盖

beta测试的作用

beta测试通常是指测试和缺陷修复完成之后，组织人力资源对项目进行集中测试。

组织形式可以是会议，也可以是发送请求测试邮件和在系统中搜集反馈，参与人员可以包括所有项目相关人员，也通常邀请其他图阿奴地人员来交叉测试和验收。

主要目的是尽可能的在上线之前发现可能遗漏的问题或者提升用户体验的建议

冒烟测试后发现交付的软件达不到开始测试的标准怎么办

冒烟测试用于验证软件的关键功能工作正常，通常是执行详细的功能测试或者回归测试的前提条件

1、测试计划中应该明确标注测试开始的标准（如冒烟测试中无重大问题，没有阻碍测试的重大缺陷）
2、冒烟测试后发现无法达到测试开始的标准，应该果断拒绝继续测试并且将问题反馈给所有相关人员
3、要求开发团队给出明确的下个版本交付的时间并说明对测试工作和整体项目排期可能造成的影响
4、对测试资源和进度进行重新安排和沟通已确保整体项目进度

a/b测试如何保证覆盖率

a/b测试是一种用户体验研究方法，通常针对两到三个不同的用户体验方案给出不同的代码实现，按比例随机分配用户到其中的某个方案，根据上线后的用户数据（点击率、购买率、存活率、注册率等）来决定哪个方案更受用户青睐

测试计划应该覆盖不同入口条件下的不同方案的组合测试，从而保证任何路径下用户的体验是完整合乎期待的

如果出现排期紧张，上线之前大量测试可能无法按时测试怎么办

1、根据现有数据提前预警和告知所有相关人员，提示可能的风险
2、提出可能的应对方案，包含合并和精简测试，扩充人员、倒休
3、对每种方案带来的优劣点做充分沟通保证团队达成一致
4、确定方案后给出新的估计和可能存在的风险

测试中需要收集哪些日志，什么作用

• 服务端测试：需要收集服务器日志，以便出现问题时，开发人员可以从日志中获取堆栈信息定位问题
• 自动化测试：采集测试执行的日志，追踪执行的步骤和可能抛出的异常
• 性能测试：采集系统资源使用数据和时间戳
• 客户端测试：再发现问题时需要采集发送的完整请求和响应消息内容