工行业务架构实践
15
15
1.0x
00:00/00:00
登录|注册

09|划定测试小圈圈:基于业务架构的需求验收设计方法

你好,这里是工行架构,我是任长清。
这节课是我们《工行业务架构实践》系列课程的最后一课,我们来到了业务研发中的最后一个流程环节:需求验收,也就是测试。完成了需求验收,也就完成了业务研发流程的闭环,可以将我们的产品投向市场。
谈到需求验收的设计,你很可能也有这样的困扰:怎样才能更合理、更准确地划定验收的范围?我们都知道,做需求验收会面临一个很大的挑战,那就是测试是无法穷尽的。资源的限制导致我们不可能做到把所有的功能点全部覆盖一遍,因此划定范围就特别重要。范围划得过小,可能会造成业务功能或业务场景的遗漏,无法保障需求投产的质量;范围划得过大,又会浪费了业务研发资源。
在传统的需求验收方法中,范围划定和测试设计主要都是依赖测试人员自身的经验,经验的局限性和个人的思维惯性容易导致投产风险,并且在不同的人员间会出现较大的差异,难以执行统一的标准。
一个更理想的状态是,我们希望需求验收设计在使用个人经验的同时,可以尽可能地将组织级的资产用起来,将组织级的智慧给到个人,帮助他又快又好地完成这项工作。所以今天,我来给你介绍一套基于业务架构的需求验收设计方法,既能帮助你找准测试范围,又能帮助你高质高效的设计案例。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

基于业务架构的需求验收设计方法是一种旨在提高测试效率和质量的创新方法。文章首先指出了需求验收设计的挑战,即测试无法穷尽,因此划定范围至关重要。传统方法依赖测试人员经验,容易导致个人差异和投产风险。基于业务架构的方法则结合业务资产和IT资产,提供了自动推送测试案例和提示测试范围的两种方法。这些方法旨在提供有效补充,增强验收测试效果,为读者提供了实用的需求验收设计思路和操作方法。 工行的实践案例展示了该方法在实际设计过程中的应用效果。通过自动生成测试案例的方法,测试设计能够原原本本地、清晰且有结构地体现出需求改造的内容,有效提升了需求验收环节的质效。另外,该方法还在识别“紧密相关”的内容时发挥作用,通过综合运用资产识别范围和关注要点,识别并补充了测试范围,有效降低了投产风险。 总结来看,需求验收设计包含两个部分:“必须要测”的需求提出当期改造的内容,与“紧密相关”的扩大识别的测试范围。该方法不仅提供了操作指引,更能帮助拓展方向的思维方法。读者可以通过该方法梳理要验收的业务需求、审视对应的业务场景,从而带来不一样的设计思路。 文章内容深入浅出,通过实例生动展示了方法的应用效果,为读者提供了实用的需求验收设计思路和操作方法。

该试读文章来自《工行业务架构实践》,如需阅读全部文章,
请先领取课程
免费领取
登录 后留言

精选留言

由作者筛选后的优质留言将会公开显示,欢迎踊跃留言。
收起评论
显示
设置
留言
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部