财务网站建设,百度云服务器安装wordpress,南宁网站建设电话咨询,微信小程序开发文档 菜鸟教程上线前层层保障
01文档管理 关键词#xff1a;需求文档、设计文档、测试文档
1.需求和设计产出方为产品、开发#xff0c;测试需要做好流程监督#xff0c;这里重点说下测试文档。
2.测试文档#xff0c;从业务领域来说#xff0c;一般有测试计划、测试用例、业务总结文…上线前层层保障
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.已暴露问题一般为生产问题需要做团队内部的复盘整理参与方包括产品、研发、测试。建议一个月至少一次总结问题进而完善质量保障体系。
笔者创建了一个测试交流群如果对软件测试、接口测试、自动化测试、面试经验交流感兴趣可以加测试交流群可以点击文末小卡片处还会有同行一起技术交流。
