Testing源头结构化

既有流程

1. 迭代期间既有流程，暂未全面的从立项初始阶段进行考虑，所经流程概括如下:
   prd评审 -> 用例评审 -> Coding阶段 -> 自测 -> 提测 ->走查-> 测试 -> 验收 -> beta -> 上线 <=> 监控(测试左移、测试右移)
2. 抽取流程节点中共同点以及相似点：
   2.1、prd —— 需求list、交互list、逻辑list
   2.2、用例输出 —— 用例设计list
   2.3、coding —— 实现及细节list
   2.4、自测、走查 —— list
3. 各种list有交集、有差异性、有重复性：
   痛点1：理解上的差异、各环节重复性的工作导致同一个需求在理解、实现、验证上的差异
   痛点2：case之间的未结构化进的行管理，进行持续扭转和复用(各公司之间已有较多的解决方案)
   痛点3：case产出重复性、耗时
   3.1、Case的生成
   3.2、Case的管理
   3.3、Case的复用

流程分析

暂以总体需求或拆分的需求粒度出发

1. 工作的源头在一定程度上来说就是PRD文档
2. PRD文档完善性、合理性也和PD的经验有一定关系
3. 目前都是以Prd文档为基础生成测试用例，并再以此生成自测checkList、进行测试case复用和管理
4. prd交互的输出和用例case的生成有重复性
5. 根据代码实现智能化的生产用例case(未体验过)

流程优化

本着以自动化、结构化、规范化的思路：
去除重复性事件并能够结构化的在流程间扭转的

1. PD以BDD或者ATDD模式进行PRD书写，也可结合用例元，加快输出(对应的管理工具，自研或者利用现有的)使得源头结构化 ->（规范化、结构化）
2. QA在PRD的基础上进行细节的完善和丰富的user story场景的设计(如果PD在PRD经验丰富，这一步只要提炼下可测点)，以此成为测试计划的一部分
3. QA、RD、PD都在一份源数据文档进行工作、处理；粒度还需考虑
   初步把一份文档能以多种视角展示：产品视角 QA视角 PD视角
   生成之后能够隔离在独自的视角进行操作

优点：

1. 所有相关人员都以一份数据为基础，进行工作，减少歧义性以及重复性的沟通和操作；RD明确实现，PD明确自己的验收标准
2. 数据结构化便于QA后续数据的复用，数据的追踪，数据的分析
3. QA减少流程上的重复时间，符合敏捷测试的标准
4. 明确相关人员的关注点，提升关注度

难点：

1. 多人操作一份数据，如何进行标示或标注，相关人员如何进行扩展和维护、明确关注的重点和减少歧义性
2. 操作上是否便捷，易用，给用户带来惊喜
3. 推动时，如果不能很满足用户使用场景带来输出的便捷，反而容易导致效率的低下和用户的排斥
   ......

现有产物：
WYSIWYG
Gherkin
MBT https://bitbar.com/blog/model-based-testing-the-advanced-level-of-test-automation/
MBT ensures the possibility to trace the correspondence between requirements,models,code and test cases used for tested system.

技术栈
功能模块

常用Case管理工具

CaseManagement.png

图片.png

<<<<<<持续实现和优化中>>>>>>