因为近期一直在接SKA的项目， 包括圣*， 满xx， 某某家， HT等等， 基本涉及了酷家乐所有的业务线。作为这类大型跨组项目的主测试在把控质量的过程中遇到了许多问题与挑战， 所以希望可以总结下来， 以便大家能共同探讨。
开始的我遇到的问题：
我要了解每个业务线的需求和实现逻辑， 异常场景；
我要知道每个线的影响的服务；
我要知道每个敏捷小组的迭代流程， 部署节奏；
我要知道每个业务在测试过程中遇到的问题；
我要串联本次需求的业务逻辑；
但是我没做过硬装项目， 不了解那么深的逻辑；项目时间那么紧， 没有那么多时间学习；项目还在继续并且持续增加， 每天重复劳动又没有结果......
这些问题要怎么解决？
首先， 我罗列了作为一个普通项目的owner， 应该如何保障质量，或者说， 应该关注的点：
- 在需求评审阶段， 要明确项目的角色和职责， 确定项目范围，明确产品功能；
- 在测试分析阶段， 能够明确本次项目的测试级别， 测试优先级， 测试范围以及服务依赖和阶段环境；
- 经过测试分析之后， 结合研发估时， 测试估时等， 确定本次项目的整体计划；
- 接着， 从时间， 质量， 成本的角度分析该项目的风险， 例如需求风险， 测试用例风险， bug风险， 代码质量风险， 测试环境风险，测试技术风险， 回归测试风险，沟通协调风险， 研发流程以及其他风险；
- 然后在过程中， 按照最初的计划执行， 不断细化， 调整测试用例， 把控项目风险， 直到项目上线；
- 项目上线后， 观察线上流程， 分析产品价值， 收集用户体验；
基于通用职责模型， 应用酷家乐的跨组项目中， 还有一些需要注意的点：
阶段目的注意点
需求立项
1.明确项目的角色和职责
SKA项目有铁三角模型， 项目立项开始， 就定义了明确的客户经理，解决方案经理， 交付经理以及此项目的TO：
时， SKA项目进入需求立项的时候， 涉及到的业务线也基本确定， 所以除了明确做决定的人的角色和职责， 还要落地每个线具体执行人。 PM一般会建立项目文档， 其中就包含了所有项目相关人员，例如：
2. 明确项目范围
(1) 由于SKA项目一般都是交付时间紧， 且客户比较重要。 所以这类项目一定要在开始的时候做好范围管理， 防止需求变更， 需求蔓延带来的延期风险， 以及需求遗漏的质量风险。
(2) 需求管理需要落地到每个线的jira任务，并且明确交付时间：
(3) 项目范围必须由各业务线产品拆分，并与交付经理明确落地后开始执行。
测试分析
- 明确测试级别
(1) 一般项目会分单元测试， 集成测试， 回归测试， 验收测试。 在判断测试级别的时候， 要考虑到测试时间， 以及最大的投入产出比。 例如， 单元测试可以发现问题， 但是如果这个项目比较紧急， 从接口测试可以覆盖代码逻辑， 那么本次迭代可以由接口测试代替单元测试。
(2) 在确定测试级别的时候， 还有一点是要考虑谁来做。 例如在验收测试阶段， 可以引入运营， 产品或者实施， 交付经理等角色。
(3) 同时也可以考虑用什么工具来做， 例如在测试openapi的时候， 要在postman 构造数据， 再去监控找日志， 查看调用链， 所以推动垚鑫优化openapi的测试工具
2. 服务依赖
跨组项目， 有个很头疼的问题是服务依赖。 这涉及到开发节奏， 部署依赖， 测试数据准备。 所以在测试分析阶段， 要推动TO把本次项目的服务依赖梳理清楚， 确定发布优先级。
测试人员要善于借助工具和伙伴提高分析深度， 例如利用监控来分析已有方案的依赖；咨询之前的测试人员；
3. 测试数据
酷家乐的产品离不开素材， 很多需求都是围着素材数据的操作和配置。所以在测试分析阶段， 要评估出该项目的测试数据来源， 测试数据包括账号， 方案， 模型。
依赖于上游数据的， 在测试分析的时候就要计划好， 这些数据怎么创建， 什么时候必须创建好， 是否可以利用现有数据， 是否可以利用运营或者其他测试数据等手段来缩短测试数据准备的投入
4. 环境统一
(1) 由于目前还在环境统一化的过程中， 并且每个组的部署节奏也有所不同， 所以最好在测试分析阶段， 定好每个测试阶段的服务部署环境， 统一大家的认识；
(2) 目前也有很多组使用单分支测试， 所以在测试分析阶段， 要预估搭建测试环境的时间以及环境配置的成本；
5 制定测试计划
- 经过上面的分析之后， 在提测之前， 要产出一版测试计划， 当中包括本次项目的各测试阶段的内容， 时间， 资源， 以及上线指标；
- 测试计划的评审要触达各线核心产品， 测试和研发， 这样才能在执行过程中共同维护，不要单兵作战；
风险管理
根据项目特性和背景， 分析并控制风险
- 从时间， 质量， 成本的角度分析该项目的风险， 例如需求风险， 测试用例风险， bug风险， 代码质量风险， 测试环境风险，测试技术风险， 回归测试风险，沟通协调风险， 研发流程以及其他风险。
- 建立项目质量看板， 项目提测后， 可以在群内每天同步项目质量和风险；
目前已经经历了几个SKA的项目， 总结了每个模块曾经遇到的一些问题：
户型工具
一个云图前端， 会分为pg， yuntu， kaf等几个不同的敏捷组维护。 当时生活家由于没有评估到这个需求还需要pg的资源， 所以项目后期时间比较赶。
- 需求评审需要邀请对应的TO， TO可以评估出该需求可能会涉及哪些小组的开发任务；
- 主测分在需求评审之后， 可以在场景链路中走一遍， 根据调用链可以查看涉及到的服务
- 可以在kaption中查看相关业务线的敏捷小组， 大致了解每个敏捷小组负责的模块
算法
在满屋需求时， 涉及到算法和硬装两个组。 这两个组无论是业务还是技术门槛都比较高， 很难快速的了解其中的风险和原理。 所以作为主测的时候， 无法准确的评估出问题。
- 这种类型的项目要从数据结构入手， 了解关键路径的数据转换， 这样能抓住主链路，起码听的懂他们在交流什么。
- 换主测分
- 运用进度， 质量， 资源三要素法则， 抓大放小， 定时跟踪
全景图
全景图有很多专业的术语， 这个不了解， 涉及到这个类型的项目， 从开始就可能被过滤
- 希望海鸟能整理一份关于全景图的术语表， 为大家打开沟通的大门渲染作为硬装， 定制， 工具的集体成像， 排查问题比较困难。 不清楚是哪块出现问题
- 用于闲的渲染平台排查数据
渲染的链路比较长，参数也很多， 后端服务又比较复杂， 所以测试的时候很容易忽略一些点 - 在做项目dev design的时候， 起码有主链路的时序图
渲染效果有很多的等级， 需求不能仅仅要求渲染出图， 要细化到支持多少像素， 支持在哪些终端展示， 场景切换的敏感度等
硬装
行业门槛比较高；
- 业务词汇表
- 数据结构图
业务线的P0项目比较多， 由于前期没有明确项目的优先级， 所以导致在研发后期， 发现测试资源很紧张。 - 公司所有业务线的P0项目应该统一PK， 有一个池子可以查看， 这样在确定紧急需求插入的时候， 和当前项目有个对比。
- 项目在立项的时候就要明确， 此需求的优先级和deadline， 到后期再提升， 空间太小
商业平台
每个产品的商业化转换如何完成？
- 在需求评审时， 应该主动咨询产品的商业价值， 帮助定位产品的测试重点，毕竟作为ToB的公司， 钱很重要。
openapi的账号如何创建？ - 每个业务线的测试可以总结一份业务入门资料，并将通用功能的平台化
有遇到问题， 也有学习到的地方：
项目
为非家居行业提供平台工具的解决方案。 只要是对空间有操作需求， 那么就可以使用这套方案解决。
它包括去酷家乐化， 屏蔽特定工具线， 给特定功能命名等。
这套解决方案的价值在于， 酷家乐不仅仅局限于家居设计工具平台， 我们同时可以为办公， 洗涤， 商装， 厂房等其他行业提供解决方案。
一些企业更专注于素材模型的管理， 不具备工具平台的开发能力或者战略计划。 这套解决方案， 就可以为此类企业提供全套的openapi方案。
企业可以从模型上传， 到方案渲染都使用酷家乐工具， 拓展了企业能力， 构建一站式服务。
为房产商渗透精装后市场提供武器。 改解决方案整合设计， 方案展示， 商品展示等环节， 通过讲设计方案形象的展示来降低终端对销售的门槛。
提供了商品授权的渠道，降低了门店建模门槛。 为品牌商构建完整的供应链生态提供任意门。
SKA-JL
为房地产商提供从户型导入到渲染全景图的功能。 现在头部的房产商例如链家， 我爱我家都提供了实景VR，一键装修，语音看房，数据看板等功能。
居里希望酷家乐能为其提供这样一套解决方案。
但是， 依然有几个难点要解决的：
- 和第三方联调时， 如果降低外部数据对内部系统的影响？
- 阶段性非发布的功能， 如何联调？在项目中期， 部分功能已经ready但是还不具备上线标准或者未达到发布窗口， 这个时候如何和外部环境打通联调链路？
- 主技术，主测试能够通过什么手段尽早的发现项目风险？
关注我们
酷家乐质量效能团队热衷于技术的成长和分享，几乎每个月都会举办技术分享活动（海星日），每半年举办一次技术专题竞赛分享（火星日），并将优秀内容写成技术文章。
我们尽可能保障分享到社区的内容，是我们用心编写、精心挑选的优质文章。如果您想更全面地阅读我们的文章，请您关注我们的微信公众号"酷家乐技术质量"。
