赏金任务每周更新，请持续关注哦 
题目
- 模拟面试场景，面试官提问以下问题，你如何回答。
- 测试人员如何为项目的质量保障兜底？
参与方式
- 本帖下方回复你的答案即可
赏金
- 100元京东购物卡
活动时间
- 2023年2月20日 - 2023年2月26日
本周赏金任务汇总：🌈 赏金任务发布 2023-02-20
本问题参与赏金活动，详情点击
赏金活动上线啦 丨做赏金任务挑战千元奖金 查看活动介绍
-
测试人员如何为项目的质量保障兜底？
- 测试人员是质量保障团队中非常重要的一部分，他们的工作是确保软件开发项目交付的产品达到预期的质量标准，防止产品出现缺陷或错误。以下是测试人员可以采取的措施，以兜底项目的质量保障：
- 制定详细的测试计划和测试用例，包括功能测试、性能测试、安全测试等多种类型，确保所有的测试情况都被充分覆盖。
- 确保所有的缺陷和问题都被及时记录、跟踪和解决，以便问题及时得到解决，避免问题在后期出现。
- 对软件进行不同维度的测试，例如跨平台兼容性测试、多语言测试、不同用户角色测试等，确保软件在不同环境下都能正常工作。
- 对产品的可用性进行测试，例如易用性、用户体验和界面设计等，确保产品的易用性和用户体验满足用户的期望。
- 与开发团队紧密合作，及时地反馈测试结果和问题，确保问题得到及时解决，并确保软件的质量。
通过自动化测试等工具来加速测试工作，确保测试效率和测试质量。
- 测试人员是质量保障团队中非常重要的一部分，他们的工作是确保软件开发项目交付的产品达到预期的质量标准，防止产品出现缺陷或错误。以下是测试人员可以采取的措施，以兜底项目的质量保障：
1：首先要写好好的测试用例,一个“好的”测试用例，必须具备以下三个特征。
整体完备性： “好的”测试用例一定是一个完备的整体，是有效测试用例组成的集合，能够完全覆盖测试需求。
等价类划分的准确性： 指的是对于每个等价类都能保证只要其中一个输入测试通过，其他输入也一定测试通过。
等价类集合的完备性： 需要保证所有可能的边界值和边界条件都已经正确识别。
2:做好测试计划与测试策略得安排
一份成功的测试计划，必须清楚地描述：测试范围、测试策略、测试资源、测试进度和测试风险预估这五个最重要的方面。
测试范围需要明确“测什么”和“不测什么”；测试策略需要明确“先测什么后测什么”和“如何来测”；测试资源需要明确“谁来测”和“在哪里测”；测试进度是需要明确各类测试的开始时间，所需工作量和预计完成时间；测试风险预估是需要明确如何有效应对各种潜在的变化。
前半部分------上线前层层保障
01文档管理
关键词：需求文档、设计文档、测试文档
1.需求和设计产出方为产品、开发，测试需要做好流程监督，这里重点说下测试文档。
2.测试文档，从业务领域来说，一般有测试计划、测试用例、业务总结文档。
3.测试计划，描述测试活动的规划、策略，运筹帷幄，防患于未然。里面重要的几个点，测试范围、测试策略、测试进度、准入准出标准、风险评估。测试范围，内部需要细化到模块，外部是否有依赖方或被依赖方，需要提前告知对方，安排联调。测试策略，人员的安排，每一阶段的测试活动，工具的使用、自动化、性能的介入。测试进度，需要固定的跟踪，如定期同步测试进度，告知风险。可提测的准入标准，测试后期是否符合上线条件的准出标准，业务人员的及时验收、反馈。风险评估，一般是时间规划不足，不能按时交付。
4.测试用例，是测试执行文档，不建议做迭代维护，可读性差，描述更多的是对业务细则的如何测试，包含边界值、有效等价类等测试方法，过于琐碎，不适合提炼维护。所以，我对测试用例的定义是，当前版本有效。
5.业务总结文档，是对当前系统业务的描述、汇总，通过该文档，可以一目了然当前系统的基础逻辑。更侧重于从业务逻辑角度描述系统，是测试人员的帮助文档，需要在每次迭代后及时更新，无需去翻看测试用例。熟悉、掌握系统核心业务，是测试人员的一项基础能力。
02评审机制
1.信息的传递具有时效性，一份需求从产品->项目经理->研发团队->测试团队，如果测试团队在最后测试准备阶段接入，会丢失很多的信息。软件的生命周期如果用W模型来定义，那么每个阶段，测试的活动都是联动的。
2.所以，每个阶段的产出对应的评审是必不可少的：需求评审、开发技术方案评审、测试计划评审、测试用例评审
03准入、准出标准
1.准入标准，即提测标准，为冒烟测试用例通过，验收人为测试人员，通过率可以酌情而定，比如超过70%的通过率则提测通过，否则打回。冒烟测试用例会维护并分享给开发人员，提测前，开发人员内部自测下，提高沟通效率。
2.制定提测标准的目的是为了约束开发工作能按时交付，如果测试的周期为10天，开发提测质量较差，导致修复阻塞性问题花费了两三天，这样会影响版本按时上线。出于质量的考虑，项目会顺延上线，每个环节都是螺丝钉，环环相扣，不能顾此失彼。
3.准出标准，即符合上线的标准，一般参考点有两个：测试报告、业务验收。例如通过率超过95%才能符合上线，遗留缺陷登记P3的数量，是否影响业务功能。业务验收，介入越早越好，可以分批验收。
4.生产验证，一般是在发布后，使用测试账号在生产进行可测试性验证。生产的发布比较复杂，包括代码的发布、配置变更、DB变更、运维操作、网络层通信等，每个环节的疏忽或误操作，都会影响到本次发布。
04测试执行
1.根据开发交付的可测试产品，制定好测试执行的顺序。
2.开发提测后，应该有对应的冒烟测试，如果提测功能没有实现，或者已有功能失效，要打回重新编码。
3.根据产品需求，进行探索性测试，会发现仅执行测试用例更多的bug。
4.把功能界面变动比较小的产品，建立自动化测试框架，包括UI自动化和接口自动化。
05回归测试
1.版本测试是为了保证当前版本需求的质量，而回归测试时保证整个系统业务的质量，重要性不言而喻。
2.测试人员的一个盲点，愿意花费大部分时间在了版本测试上，而用少量的时间做回归测试，这个习惯是致命的。需求的改动，是小范围的，影响可能是全局的，对于支付类的业务更是不能有一丝的轻视。
3.所以，测试团队要重视回归测试，基于重要业务的场景设计业务场景化，并预留足够的时间比重来做这一块。一定要维护、写好回归用例，从业务影响上设定用例的优先级，这样才能有足够的信心应对每一次的版本发布。
后半部分------上线后复盘及监控
06监控报警
1.这里有个灰度的概念，新版本的更新，可以先开放给少部分用户使用，运行一段时间后，没有问题，再开放给全部用户。
2.版本发布生产环境成功后，一定要监控新版本系统的运行健康情况。
3.监控包括：数据库监控、应用服务监控、异常日志报警、数据量暴或暴减异常预警。
07问题复盘
1.问题复盘，包括潜在风险、已暴露、漏测等问题。
2.潜在风险，如排期过短、流程不规范等，需要提前介入，重新评估，避免风险在最后暴露。
3.已暴露问题，一般为生产问题，需要做团队内部的复盘整理，参与方，包括产品、研发、测试。建议一个月至少一次，总结问题，进而完善质量保障体系。
2 个赞
测试人员如何为项目的质量保障兜底？
1、首先要充分了解需求：了解清楚需求的背景，要逐字逐句的阅读找出需要测试的功能点，也需要从整体上把握需要实现的主要功能以及影响范围。
2、设计全面的测试方案：设计覆盖全面的测试用例并进行评审。将测试用例进行优先级划分，先执行优先级高的用例。
3、即时跟踪问题，深入了解设计：bug及时形成闭环，深入了解开发设计，争对bug的影响点要做到心中有数。
4、制定上线后测试方案，紧急回退方案：上线后保障主要流程的无误，并在上线前提前考虑影响范围，做好兜底方案。
为了为软件项目的质量保障兜底，需要采取以下几个措施：
- 制定合理的测试计划：在软件项目开发的早期，需要制定合理的测试计划，包括测试目标、测试范围、测试时间、测试资源、测试方法、测试工具等。测试计划需要充分考虑项目特点和业务需求，以确保测试的全面性、有效性和高效性。
- 执行全面的测试：在测试过程中，需要执行全面的测试，包括功能测试、性能测试、安全测试、稳定性测试等。测试需要充分覆盖软件项目的所有功能和业务场景，以发现和解决潜在的问题和缺陷。
- 引入自动化测试：为了提高测试效率和准确性，可以引入自动化测试。自动化测试可以减少人工测试的工作量和测试误差，提高测试覆盖率和测试质量。
- 定期进行代码审查：代码审查可以帮助发现代码中存在的问题和潜在的风险，提高代码质量和稳定性。定期进行代码审查，可以保障软件项目的质量。
- 建立缺陷管理机制：建立缺陷管理机制，可以帮助对软件项目的缺陷进行有效的跟踪和管理，及时发现和解决问题，提高软件项目的质量。
- 进行持续集成和持续交付：持续集成和持续交付可以帮助及时发现和解决软件项目中的问题和缺陷，提高软件项目的质量和稳定性。采用自动化工具实现持续集成和持续交付，可以提高开发效率和软件质量。
总之，为了兜底软件项目的质量保障，需要采取多种措施，从测试计划、测试执行、自动化测试、代码审查、缺陷管理、持续集成和持续交付等多个方面入手，全面提升软件项目的质量和稳定性。
问题分为测试前中后期三个阶段。
前期
测试前期对于测试的工作分为两块，一块是日常工作，一个是制造发布卡点，首先我们先说日常工作这块，我们都会经过预评审，技术评审，终审。
一.日常流程
1.需求评审
在测试评审阶段，测试对需求进行可行性的评估，对于需求的内容提出可以通过异常情况和逻辑来对需求进行质疑，对于开发初步的方案要提出反问。
ps：这里需要讲一下测试不但需要拥有测试或者开发的能力，还需要产品的能力和了解自己产品的规划。
2.技术评审
新功能：技术方案个人觉得是非常容易找到逻辑漏洞的情况，在需求评审之后测试初步case成型，可以在技术方案中把初步的case和异常情况抛出，
牵扯历史功能：如果有包含历史内容需要有自己的测试文档对历史兼容问题进行发问。
3.测试用例，通过业务了解对测试用例进行边界值、有效等价类等测试方法进行编写。这里提一个小点，总结自己的测试用例BVT用例方便确定核心范围。
4.用例评审
用例评审往往在技术评审之后，在评审时因为很多人为原因开发心不在焉导致后续各种扯皮，为了避免此类问题，根据模块拆分用例提供给开发，或者制定定时任务提醒进行冒烟自测。
5.冒烟测试用例
在冒烟测试用例中分为开发冒烟和测试冒烟，开发冒烟必须全部通过才能达到提测标准，测试冒烟为发布初期的测试用例如不通过则进行打回。
二.制造发布卡点
前面说的是日常工作这个基本都是一个流程大家都可以做到但是人为永远会有问题，那么我们需要用CICD来进行发布卡口
1.卡点设置
现在部署基本都是容器化，在这个过程中测试需要在开发环境或者测试环境进行卡口，分别为push流水线和MR流水线，当开发进行push代码或者MR代码的时候触发流水线，然后进行安全扫描，UT，soner扫描和自动化BVT测试用例执行，每当开发提交时对应的检测开始，这样开发可以从中发现很多自己不注意的问题。
中期
测试用例执行
开发交付完成后，测试通过测试用例执行用例，在这里会遇到几个问题：
1.bug修复时间过长造成阻塞
2.增加临时需求进行开发
3.bug过多质量差
当遇到此类问题作为QA需要有预知风险的能力，通过与产品和项目经理进行沟通说明风险并提前预警。
测试过程中尽量考虑在接口层面边测试边做自动化，这样可以对增量的代码或者bug方便回归。
回归测试
1.增量回归
因为在中期我们顺势对接口做了自动化，加上ui上的回归基本可以快速的保证回归的质量。
2.历史回归
这里采取的是自动化的方式进行回归，自动化有BVT的用例集，根据BVT用例集进行回归减少了人为的操作，增加了效率
后期
复盘
1.问题复盘
开发
针对开发bug多的情况下如何进行处理，UT的执行成功率和是否有效UT，冒烟自测是否有效执行，对于bug触发的情况为什么会发生，如何后期进行处理。
测试
自动化用例失败过多，如何增加可维护性，对于新版本功能的自动化用例如何增加，怎么取保证有效的自动化用例。
产品
临时需求是否合理，产品文档中的歧义如何进行解决。
测试人员如何为项目的质量保障兜底？
1. 建立严格的测试计划：定义测试策略和测试目标，完善测试流程，明确每个步骤的责任、时间和期限。
-
专注于缺陷：分析发现的缺陷，建立及时的缺陷识别和跟踪机制，并及时上报到开发团队，并确保项目定义的缺陷解决方案的顺利实施。
-
执行质量前瞻控制措施：实施质量控制的工作，持续的监察项目进展情况，及时发现和记录质量问题，并根据法定要求组织质量改善活动。
-
执行项目复核活动：负责进行审阅活动，确保项目文档的正确性，确保在项目开发过程中，每个步骤都会进行全面的质量检查。
-
进行项目总结：定期对项目进行总结，及时发现项目中存在的质量问题，及时进行修订和改进。
回答的很全面，从需求评审，用例执行到线上监控都有考虑到。 可以在增加对测试人员测试用例覆盖率的统计以及混沌工程的内容，在产品上线前模拟线上故障，来测试产品的稳定性，发现系统的弱点和漏洞，减少上线后的故障率。
好的，这块确实可以加进去，作为补充点，为质量保障兜底了
考虑到了引入代码扫描是个很好的点。
嗯嗯 主要自己在公司已经实践逻辑 做发布卡点效果很好