尧图网站建设 
11-质量保证QA流程小团队轻量化代码审查、自测、轮测规范这是CMMI3系列的第七篇聊一个所有人都觉得重要但经常被牺牲的环节——质量保证。“先上线再说”“测试回头补”“代码审查太慢了”——这些话在小团队里天天听到。CMMI3的PPQA过程域就是专门治这个病的核心思想很简单质量不是测出来的是做出来的是管出来的。一、CMMI3 PPQA过程域核心要求1.1 什么是PPQAPPQAProcess and Product Quality Assurance过程和产品质量保证是CMMI3的一个支持类过程域。它包含两个层面过程质量保证开发者是否按照既定流程和标准干活有没有走代码审查有没有写单元测试有没有走变更流程产品质量保证产出的工作产品是否符合标准代码规范吗文档齐全吗固件通过测试了吗通俗理解PPQA既是流程警察检查你有没有按规矩来也是产品质检员检查做出来的东西合格不。1.2 PPQA的两个特定目标目标内容一句话理解SG1 客观评价过程和产品按标准评价过程执行情况和工作产品拿尺子量一量合不合格SG2 提供客观洞察不符合项要记录、沟通、解决不合格的要跟踪整改1.3 小团队QA的困境与出路困境没有专职QA人员开发兼任测试代码审查形同虚设“LGTM”Looks Good To Me一句话通过没有时间写单元测试全靠手动点固件测试只能在设备上手动操作没法自动化出路轻量化QA体系——不追求大而全但关键环节必须有。轻量QA体系 代码审查必有 自测规范必有 轮测机制必有 静态扫描自动化 质量度量看数据二、代码审查规范2.1 为什么需要代码审查代码审查Code Review简称CR是成本最低、收益最高的质量保证手段。根据行业统计代码审查能发现60%-90%的软件缺陷远高于测试阶段发现的缺陷比例。代码审查的核心价值价值说明发现缺陷别人更容易看到你的盲点知识共享团队成员了解彼此的代码质量提升代码规范性提升技术债降低瓶颈消除避免只有一个人懂这段代码2.2 代码审查的三种形式形式一自查清单Self-Check开发者在提交代码审查前先对照自查清单逐项检查。自查清单模板□ 代码是否实现需求文档中描述的全部功能 □ 是否处理了边界条件空值/越界/异常输入 □ 是否有硬编码的魔法数字应该用常量 □ 日志是否充分关键路径有INFO异常有ERROR □ 是否有SQL注入/XSS等安全风险 □ 是否有未关闭的资源文件流/数据库连接/网络连接 □ 接口返回值是否与接口文档一致 □ 是否有重复代码超过3处相同逻辑应抽取 □ 命名是否清晰可读变量名/方法名/类名 □ 是否有TODO/FIXME未处理形式二交叉审查Peer Review由另一位开发者审查代码这是最核心的审查形式。交叉审查规范规范说明审查人至少1人核心模块需2人审查工具GitLab Merge Request / GitHub Pull Request审查时限提交后24小时内完成审查审查粒度每次MR不超过400行代码超过拆分审查结果Approve / Request Changes / Comment交叉审查关注点清单□ 逻辑正确性算法是否正确条件判断是否完整 □ 架构一致性是否遵循项目架构分层是否有跨层调用 □ 接口兼容性接口变更是否影响其他端是否更新了接口文档 □ 异常处理异常是否被正确捕获和处理是否有吞异常 □ 性能影响是否有N1查询是否有大循环中做IO □ 并发安全是否有竞态条件是否需要加锁 □ 固件特有是否有内存泄漏风险是否有死锁风险形式三静态扫描Static Analysis用工具自动扫描代码发现人工审查容易遗漏的问题。静态扫描工具推荐语言工具扫描内容JavaSonarQube Checkstyle SpotBugs代码规范/Bug/安全漏洞/重复代码PythonPylint Bandit Black(format)代码规范/安全/格式化C/C固件Cppcheck clang-tidy内存泄漏/未定义行为/代码规范安卓Android Lint Detekt(Kotlin)性能/安全/无障碍/代码规范通用SonarQube集成多语言统一质量门禁CI/CD集成静态扫描# .gitlab-ci.yml 静态扫描配置sonarqube-check:stage:testscript:-sonar-scanner-Dsonar.projectKeyvend-backend-Dsonar.sourcessrc-Dsonar.java.binariestarget/classes-Dsonar.qualitygate.waittrueonly:-develop-release-merge_requests静态扫描设置质量门禁Quality Gate代码异味Code Smell超过阈值、新增Bug不为0、覆盖率低于阈值——任一条件不满足CI流水线失败MR不允许合并。这就是自动化QA。2.3 代码审查的三不原则不审查不可运行的代码MR必须先通过编译和基础测试不审查过大的MR单次MR超过400行要求拆分成多个MR不审查没有描述的MRMR必须写明改了什么、为什么改、如何测试三、自测流程规范3.1 为什么要自测开发完功能直接扔给测试是效率最低的做法。开发自测能过滤掉80%的低级bug让测试团队把精力集中在复杂场景和集成测试上。3.2 单元测试规范Java后端JUnit 5 MockitoExtendWith(MockitoExtension.class)classProductServiceTest{MockprivateProductRepositoryproductRepository;MockprivateAIRecognitionClientaiRecognitionClient;InjectMocksprivateProductServiceproductService;TestDisplayName(商品识别-正常流程-返回正确商品信息)voidtestRecognizeProduct_Success(){// GivenStringimageBase64base64_encoded_image;ProductmockProductnewProduct(1L,可乐,3.5);when(aiRecognitionClient.recognize(imageBase64)).thenReturn(newRecognitionResult(1L,0.98));when(productRepository.findById(1L)).thenReturn(Optional.of(mockProduct));// WhenProductresultproductService.recognizeProduct(imageBase64);// ThenassertNotNull(result);assertEquals(可乐,result.getName());assertEquals(3.5,result.getPrice());verify(aiRecognitionClient,times(1)).recognize(imageBase64);}TestDisplayName(商品识别-AI识别失败-抛出业务异常)voidtestRecognognizeProduct_AIError_ThrowsException(){when(aiRecognitionClient.recognize(anyString())).thenThrow(newAIServiceException(AI服务超时));assertThrows(BusinessException.class,()-{productService.recognizeProduct(image);});}}覆盖率要求模块类型行覆盖率要求分支覆盖率要求核心业务逻辑≥80%≥70%工具类≥90%≥80%Controller层≥60%≥50%AI推理适配层≥70%≥60%固件通信协议层≥80%≥70%Python AI服务pytest# test_recognition_service.pyimportpytestfromservices.recognition_serviceimportRecognitionServicefromexceptionsimportModelLoadErrorclassTestRecognitionService:pytest.fixturedefservice(self):returnRecognitionService(model_pathmodels/yolov8s_v2.1.rknn)deftest_recognize_single_product(self,service):测试单商品识别resultservice.recognize(test_images/cola.jpg)assertresult.product_name可乐assertresult.confidence0.9deftest_recognize_empty_image_raises(self,service):测试空图片输入抛异常withpytest.raises(ValueError):service.recognize()deftest_recognize_low_confidence_returns_unknown(self,service):测试低置信度返回未知商品resultservice.recognize(test_images/blur.jpg)assertresult.product_name未知3.3 开发自测清单提交测试前开发者对照清单逐项确认功能自测 □ 所有需求文档中的功能点是否全部实现 □ 正常流程是否走通主路径测试 □ 异常流程是否处理错误输入/网络异常/服务超时 □ 边界条件是否测试空列表/最大值/最小值/并发 接口自测 □ 接口入参和返回值是否与接口文档一致 □ 接口异常返回是否规范错误码/错误信息 □ 接口是否做了权限校验 数据自测 □ 数据库读写是否正确 □ 事务是否正常提交/回滚 □ 数据一致性是否保证 三端联调自测 □ 后端接口变更是否同步更新了安卓端调用 □ 固件通信协议变更是否同步更新了后端解析 □ AI模型版本是否与推理代码兼容四、轮测机制4.1 什么是轮测轮测 轮流测试团队成员轮流担任测试角色对系统进行功能测试、回归测试和兼容性测试。小团队没有专职测试或测试人手不足轮测是最高效的替代方案。每个人既是开发又是测试换个视角看系统往往能发现开发时看不到的问题。4.2 轮测组织方式轮值安排周次轮值测试人测试范围W1开发A后端API 后台管理W2开发B安卓工控端 固件W3开发CAI识别 小程序W4开发D全链路集成测试轮值测试期间测试人的开发任务适当减少减量30%-50%保证有足够时间做测试。4.3 功能测试规范测试用例编写每个功能点至少编写以下类型的测试用例用例类型说明示例商品识别正向用例正常操作流程放入一瓶可乐→识别成功→正确扣费反向用例异常操作流程放入未注册商品→提示未知商品→不扣费边界用例边界条件同时放入5件商品→全部识别→批量扣费性能用例响应时间要求单商品识别≤3秒5商品≤8秒兼容用例不同环境不同光照条件/不同商品摆放角度测试用例模板字段内容用例编号TC-RECOG-001用例标题单商品正常识别前置条件设备已联网、AI模型已加载、商品已注册操作步骤1.扫码开门 2.取出一瓶可乐 3.关门预期结果识别出可乐扣费3.5元生成订单实际结果_____测试结果□通过 □失败 □阻塞4.4 回归测试规范每次版本提测除了测试新功能还必须做回归测试——确保新代码没有破坏老功能。回归测试策略全量回归每个大版本Minor版本升级执行全部测试用例 冒烟回归每次提测执行核心路径用例约20%的高优先级用例 受影响回归只执行受变更影响的模块的用例回归测试用例优先级优先级说明执行频率P0核心路径开门→识别→扣费→关门每次提测P1重要功能商品管理/订单查询/设备管理每次提测P2一般功能报表导出/日志查询大版本回归P3边缘功能系统设置/帮助文档全量回归4.5 兼容性测试规范无人售货柜项目三端涉及多种环境兼容性测试不可少。后端兼容性□ 数据库版本兼容MySQL 5.7 / 8.0 □ JDK版本兼容JDK 11 / 17 □ Docker版本兼容 □ 操作系统兼容CentOS 7 / Ubuntu 22.04安卓工控端兼容性□ 不同屏幕分辨率1920x1080 / 1280x720 □ 不同Android版本Android 9 / 11 / 13 □ 不同硬件平台RK3566 / RK3588 □ 摄像头型号兼容USB摄像头/MIPI摄像头固件兼容性□ 不同硬件版本HWV1 / HWV2的板子 □ 不同传感器型号称重传感器/门磁传感器 □ 通信模块兼容4G模块/WiFi模块AI模型兼容性□ 不同RKNN模型格式RK3588/RK3566 □ 不同模型版本的后处理代码兼容 □ 模型文件完整性校验MD5五、质量度量指标5.1 度量指标体系没有数据支撑的QA就是凭感觉。以下是必须关注的质量度量指标代码质量指标指标定义目标值单元测试覆盖率被测试覆盖的代码行数/总行数≥80%核心模块代码异味数SonarQube检测到的Code Smell新增代码0重复代码率重复代码行数/总行数≤3%技术债比率修复技术债预估时间/开发时间≤5%测试质量指标指标定义目标值测试用例覆盖率已编写用例数/需求功能点数≥95%测试通过率通过用例数/执行用例数≥98%缺陷逃逸率线上发现的缺陷数/总缺陷数≤5%缺陷密度每千行代码缺陷数≤5个/KLOC固件/设备质量指标指标定义目标值设备崩溃率每日崩溃设备数/总设备数≤0.1%固件OTA成功率成功升级设备数/总升级设备数≥99%识别准确率正确识别次数/总识别次数≥97%识别响应时间从关门到识别完成的平均时间≤3秒5.2 质量看板建议在项目管理工具中建立质量看板每周更新┌─────────────────────────────────────────────────┐ │ 质量看板 (W32) │ ├─────────────────┬───────────┬───────────────────┤ │ 代码覆盖率 │ 82% │ ↑2% (目标80%) │ │ 代码异味(新增) │ 0 │ ✓ 达标 │ │ 本周Bug数 │ 12 │ ↓3 (上周15) │ │ Bug修复率 │ 92% │ ↑5% │ │ 缺陷逃逸率 │ 3.2% │ ✓ 达标 (≤5%) │ │ 识别准确率 │ 97.3% │ ↑0.3% │ │ 设备崩溃率 │ 0.05% │ ✓ 达标 (≤0.1%) │ │ 本周CR审查数 │ 18 │ 平均1.3天完成 │ └─────────────────┴───────────┴───────────────────┘六、无人售货柜三端QA实战6.1 后端SaaS端QAQA重点接口正确性、并发安全、数据一致性。后端QA清单 □ 单元测试覆盖率 ≥80% □ 接口契约测试Pact/Spring Cloud Contract □ 数据库迁移脚本测试升级回退 □ 并发场景测试多设备同时开门识别 □ 接口性能压测JMeter核心接口QPS≥100 □ 安全扫描SQL注入/XSS/越权访问6.2 安卓工控端QAQA重点稳定性、硬件交互、异常恢复。安卓端QA清单 □ UI功能测试各界面操作流程 □ 摄像头交互测试开关门拍照/连续拍照/弱光环境 □ 串口通信测试与STM32的通信稳定性 □ 网络异常恢复测试断网重连/弱网超时 □ 内存泄漏检测LeakCanary长时间运行不泄漏 □ ANR/Crash监控Firebase Crashlytics □ 7×24小时稳定性测试monkey 自动化脚本6.3 固件端QAQA重点硬件安全、通信可靠性、功耗。固件QA清单 □ 功能测试传感器采集/电机控制/LED指示 □ 通信测试串口/CAN/I2C稳定性7×24小时不丢包 □ 异常恢复测试看门狗复位/断电恢复/通信超时重连 □ 功耗测试待机电流/工作电流/峰值电流 □ 量产测试产线烧录全功能测试老化测试 □ 固件升级测试OTA正常升级/升级中断恢复/版本回退 □ 电磁兼容测试如有条件6.4 三端联调QA联调QA清单 □ 开门→识别→扣费→关门全链路测试 □ 后端服务不可用时安卓端降级策略验证 □ 固件通信协议版本兼容性验证 □ AI模型更新后三端联动验证 □ 设备掉网后离线模式验证数据缓存上线补传 □ 多设备并发场景验证100台设备同时在线小结小团队QA的核心不是全面覆盖而是关键环节不放过。核心要点代码审查三件套自查清单自己查 交叉审查别人查 静态扫描工具查缺一不可自测规范单元测试是基础覆盖率要有量化要求自测清单是提测前的最后一道关卡轮测机制开发轮流当测试换视角发现问题功能/回归/兼容三类测试缺一不可质量度量用数据说话覆盖率/缺陷密度/逃逸率/识别准确率指标达不到不准发布三端差异化QA后端重接口和并发安卓重稳定和硬件交互固件重通信和功耗联调重全链路自动化优先静态扫描CI化、单元测试CI化、能用工具做的就不靠人——小团队最缺的就是人 11-质量保证QA流程：小团队轻量化代码审查、自测、轮测规范
11-质量保证QA流程小团队轻量化代码审查、自测、轮测规范这是CMMI3系列的第七篇聊一个所有人都觉得重要但经常被牺牲的环节——质量保证。“先上线再说”“测试回头补”“代码审查太慢了”——这些话在小团队里天天听到。CMMI3的PPQA过程域就是专门治这个病的核心思想很简单质量不是测出来的是做出来的是管出来的。一、CMMI3 PPQA过程域核心要求1.1 什么是PPQAPPQAProcess and Product Quality Assurance过程和产品质量保证是CMMI3的一个支持类过程域。它包含两个层面过程质量保证开发者是否按照既定流程和标准干活有没有走代码审查有没有写单元测试有没有走变更流程产品质量保证产出的工作产品是否符合标准代码规范吗文档齐全吗固件通过测试了吗通俗理解PPQA既是流程警察检查你有没有按规矩来也是产品质检员检查做出来的东西合格不。1.2 PPQA的两个特定目标目标内容一句话理解SG1 客观评价过程和产品按标准评价过程执行情况和工作产品拿尺子量一量合不合格SG2 提供客观洞察不符合项要记录、沟通、解决不合格的要跟踪整改1.3 小团队QA的困境与出路困境没有专职QA人员开发兼任测试代码审查形同虚设“LGTM”Looks Good To Me一句话通过没有时间写单元测试全靠手动点固件测试只能在设备上手动操作没法自动化出路轻量化QA体系——不追求大而全但关键环节必须有。轻量QA体系 代码审查必有 自测规范必有 轮测机制必有 静态扫描自动化 质量度量看数据二、代码审查规范2.1 为什么需要代码审查代码审查Code Review简称CR是成本最低、收益最高的质量保证手段。根据行业统计代码审查能发现60%-90%的软件缺陷远高于测试阶段发现的缺陷比例。代码审查的核心价值价值说明发现缺陷别人更容易看到你的盲点知识共享团队成员了解彼此的代码质量提升代码规范性提升技术债降低瓶颈消除避免只有一个人懂这段代码2.2 代码审查的三种形式形式一自查清单Self-Check开发者在提交代码审查前先对照自查清单逐项检查。自查清单模板□ 代码是否实现需求文档中描述的全部功能 □ 是否处理了边界条件空值/越界/异常输入 □ 是否有硬编码的魔法数字应该用常量 □ 日志是否充分关键路径有INFO异常有ERROR □ 是否有SQL注入/XSS等安全风险 □ 是否有未关闭的资源文件流/数据库连接/网络连接 □ 接口返回值是否与接口文档一致 □ 是否有重复代码超过3处相同逻辑应抽取 □ 命名是否清晰可读变量名/方法名/类名 □ 是否有TODO/FIXME未处理形式二交叉审查Peer Review由另一位开发者审查代码这是最核心的审查形式。交叉审查规范规范说明审查人至少1人核心模块需2人审查工具GitLab Merge Request / GitHub Pull Request审查时限提交后24小时内完成审查审查粒度每次MR不超过400行代码超过拆分审查结果Approve / Request Changes / Comment交叉审查关注点清单□ 逻辑正确性算法是否正确条件判断是否完整 □ 架构一致性是否遵循项目架构分层是否有跨层调用 □ 接口兼容性接口变更是否影响其他端是否更新了接口文档 □ 异常处理异常是否被正确捕获和处理是否有吞异常 □ 性能影响是否有N1查询是否有大循环中做IO □ 并发安全是否有竞态条件是否需要加锁 □ 固件特有是否有内存泄漏风险是否有死锁风险形式三静态扫描Static Analysis用工具自动扫描代码发现人工审查容易遗漏的问题。静态扫描工具推荐语言工具扫描内容JavaSonarQube Checkstyle SpotBugs代码规范/Bug/安全漏洞/重复代码PythonPylint Bandit Black(format)代码规范/安全/格式化C/C固件Cppcheck clang-tidy内存泄漏/未定义行为/代码规范安卓Android Lint Detekt(Kotlin)性能/安全/无障碍/代码规范通用SonarQube集成多语言统一质量门禁CI/CD集成静态扫描# .gitlab-ci.yml 静态扫描配置sonarqube-check:stage:testscript:-sonar-scanner-Dsonar.projectKeyvend-backend-Dsonar.sourcessrc-Dsonar.java.binariestarget/classes-Dsonar.qualitygate.waittrueonly:-develop-release-merge_requests静态扫描设置质量门禁Quality Gate代码异味Code Smell超过阈值、新增Bug不为0、覆盖率低于阈值——任一条件不满足CI流水线失败MR不允许合并。这就是自动化QA。2.3 代码审查的三不原则不审查不可运行的代码MR必须先通过编译和基础测试不审查过大的MR单次MR超过400行要求拆分成多个MR不审查没有描述的MRMR必须写明改了什么、为什么改、如何测试三、自测流程规范3.1 为什么要自测开发完功能直接扔给测试是效率最低的做法。开发自测能过滤掉80%的低级bug让测试团队把精力集中在复杂场景和集成测试上。3.2 单元测试规范Java后端JUnit 5 MockitoExtendWith(MockitoExtension.class)classProductServiceTest{MockprivateProductRepositoryproductRepository;MockprivateAIRecognitionClientaiRecognitionClient;InjectMocksprivateProductServiceproductService;TestDisplayName(商品识别-正常流程-返回正确商品信息)voidtestRecognizeProduct_Success(){// GivenStringimageBase64base64_encoded_image;ProductmockProductnewProduct(1L,可乐,3.5);when(aiRecognitionClient.recognize(imageBase64)).thenReturn(newRecognitionResult(1L,0.98));when(productRepository.findById(1L)).thenReturn(Optional.of(mockProduct));// WhenProductresultproductService.recognizeProduct(imageBase64);// ThenassertNotNull(result);assertEquals(可乐,result.getName());assertEquals(3.5,result.getPrice());verify(aiRecognitionClient,times(1)).recognize(imageBase64);}TestDisplayName(商品识别-AI识别失败-抛出业务异常)voidtestRecognognizeProduct_AIError_ThrowsException(){when(aiRecognitionClient.recognize(anyString())).thenThrow(newAIServiceException(AI服务超时));assertThrows(BusinessException.class,()-{productService.recognizeProduct(image);});}}覆盖率要求模块类型行覆盖率要求分支覆盖率要求核心业务逻辑≥80%≥70%工具类≥90%≥80%Controller层≥60%≥50%AI推理适配层≥70%≥60%固件通信协议层≥80%≥70%Python AI服务pytest# test_recognition_service.pyimportpytestfromservices.recognition_serviceimportRecognitionServicefromexceptionsimportModelLoadErrorclassTestRecognitionService:pytest.fixturedefservice(self):returnRecognitionService(model_pathmodels/yolov8s_v2.1.rknn)deftest_recognize_single_product(self,service):测试单商品识别resultservice.recognize(test_images/cola.jpg)assertresult.product_name可乐assertresult.confidence0.9deftest_recognize_empty_image_raises(self,service):测试空图片输入抛异常withpytest.raises(ValueError):service.recognize()deftest_recognize_low_confidence_returns_unknown(self,service):测试低置信度返回未知商品resultservice.recognize(test_images/blur.jpg)assertresult.product_name未知3.3 开发自测清单提交测试前开发者对照清单逐项确认功能自测 □ 所有需求文档中的功能点是否全部实现 □ 正常流程是否走通主路径测试 □ 异常流程是否处理错误输入/网络异常/服务超时 □ 边界条件是否测试空列表/最大值/最小值/并发 接口自测 □ 接口入参和返回值是否与接口文档一致 □ 接口异常返回是否规范错误码/错误信息 □ 接口是否做了权限校验 数据自测 □ 数据库读写是否正确 □ 事务是否正常提交/回滚 □ 数据一致性是否保证 三端联调自测 □ 后端接口变更是否同步更新了安卓端调用 □ 固件通信协议变更是否同步更新了后端解析 □ AI模型版本是否与推理代码兼容四、轮测机制4.1 什么是轮测轮测 轮流测试团队成员轮流担任测试角色对系统进行功能测试、回归测试和兼容性测试。小团队没有专职测试或测试人手不足轮测是最高效的替代方案。每个人既是开发又是测试换个视角看系统往往能发现开发时看不到的问题。4.2 轮测组织方式轮值安排周次轮值测试人测试范围W1开发A后端API 后台管理W2开发B安卓工控端 固件W3开发CAI识别 小程序W4开发D全链路集成测试轮值测试期间测试人的开发任务适当减少减量30%-50%保证有足够时间做测试。4.3 功能测试规范测试用例编写每个功能点至少编写以下类型的测试用例用例类型说明示例商品识别正向用例正常操作流程放入一瓶可乐→识别成功→正确扣费反向用例异常操作流程放入未注册商品→提示未知商品→不扣费边界用例边界条件同时放入5件商品→全部识别→批量扣费性能用例响应时间要求单商品识别≤3秒5商品≤8秒兼容用例不同环境不同光照条件/不同商品摆放角度测试用例模板字段内容用例编号TC-RECOG-001用例标题单商品正常识别前置条件设备已联网、AI模型已加载、商品已注册操作步骤1.扫码开门 2.取出一瓶可乐 3.关门预期结果识别出可乐扣费3.5元生成订单实际结果_____测试结果□通过 □失败 □阻塞4.4 回归测试规范每次版本提测除了测试新功能还必须做回归测试——确保新代码没有破坏老功能。回归测试策略全量回归每个大版本Minor版本升级执行全部测试用例 冒烟回归每次提测执行核心路径用例约20%的高优先级用例 受影响回归只执行受变更影响的模块的用例回归测试用例优先级优先级说明执行频率P0核心路径开门→识别→扣费→关门每次提测P1重要功能商品管理/订单查询/设备管理每次提测P2一般功能报表导出/日志查询大版本回归P3边缘功能系统设置/帮助文档全量回归4.5 兼容性测试规范无人售货柜项目三端涉及多种环境兼容性测试不可少。后端兼容性□ 数据库版本兼容MySQL 5.7 / 8.0 □ JDK版本兼容JDK 11 / 17 □ Docker版本兼容 □ 操作系统兼容CentOS 7 / Ubuntu 22.04安卓工控端兼容性□ 不同屏幕分辨率1920x1080 / 1280x720 □ 不同Android版本Android 9 / 11 / 13 □ 不同硬件平台RK3566 / RK3588 □ 摄像头型号兼容USB摄像头/MIPI摄像头固件兼容性□ 不同硬件版本HWV1 / HWV2的板子 □ 不同传感器型号称重传感器/门磁传感器 □ 通信模块兼容4G模块/WiFi模块AI模型兼容性□ 不同RKNN模型格式RK3588/RK3566 □ 不同模型版本的后处理代码兼容 □ 模型文件完整性校验MD5五、质量度量指标5.1 度量指标体系没有数据支撑的QA就是凭感觉。以下是必须关注的质量度量指标代码质量指标指标定义目标值单元测试覆盖率被测试覆盖的代码行数/总行数≥80%核心模块代码异味数SonarQube检测到的Code Smell新增代码0重复代码率重复代码行数/总行数≤3%技术债比率修复技术债预估时间/开发时间≤5%测试质量指标指标定义目标值测试用例覆盖率已编写用例数/需求功能点数≥95%测试通过率通过用例数/执行用例数≥98%缺陷逃逸率线上发现的缺陷数/总缺陷数≤5%缺陷密度每千行代码缺陷数≤5个/KLOC固件/设备质量指标指标定义目标值设备崩溃率每日崩溃设备数/总设备数≤0.1%固件OTA成功率成功升级设备数/总升级设备数≥99%识别准确率正确识别次数/总识别次数≥97%识别响应时间从关门到识别完成的平均时间≤3秒5.2 质量看板建议在项目管理工具中建立质量看板每周更新┌─────────────────────────────────────────────────┐ │ 质量看板 (W32) │ ├─────────────────┬───────────┬───────────────────┤ │ 代码覆盖率 │ 82% │ ↑2% (目标80%) │ │ 代码异味(新增) │ 0 │ ✓ 达标 │ │ 本周Bug数 │ 12 │ ↓3 (上周15) │ │ Bug修复率 │ 92% │ ↑5% │ │ 缺陷逃逸率 │ 3.2% │ ✓ 达标 (≤5%) │ │ 识别准确率 │ 97.3% │ ↑0.3% │ │ 设备崩溃率 │ 0.05% │ ✓ 达标 (≤0.1%) │ │ 本周CR审查数 │ 18 │ 平均1.3天完成 │ └─────────────────┴───────────┴───────────────────┘六、无人售货柜三端QA实战6.1 后端SaaS端QAQA重点接口正确性、并发安全、数据一致性。后端QA清单 □ 单元测试覆盖率 ≥80% □ 接口契约测试Pact/Spring Cloud Contract □ 数据库迁移脚本测试升级回退 □ 并发场景测试多设备同时开门识别 □ 接口性能压测JMeter核心接口QPS≥100 □ 安全扫描SQL注入/XSS/越权访问6.2 安卓工控端QAQA重点稳定性、硬件交互、异常恢复。安卓端QA清单 □ UI功能测试各界面操作流程 □ 摄像头交互测试开关门拍照/连续拍照/弱光环境 □ 串口通信测试与STM32的通信稳定性 □ 网络异常恢复测试断网重连/弱网超时 □ 内存泄漏检测LeakCanary长时间运行不泄漏 □ ANR/Crash监控Firebase Crashlytics □ 7×24小时稳定性测试monkey 自动化脚本6.3 固件端QAQA重点硬件安全、通信可靠性、功耗。固件QA清单 □ 功能测试传感器采集/电机控制/LED指示 □ 通信测试串口/CAN/I2C稳定性7×24小时不丢包 □ 异常恢复测试看门狗复位/断电恢复/通信超时重连 □ 功耗测试待机电流/工作电流/峰值电流 □ 量产测试产线烧录全功能测试老化测试 □ 固件升级测试OTA正常升级/升级中断恢复/版本回退 □ 电磁兼容测试如有条件6.4 三端联调QA联调QA清单 □ 开门→识别→扣费→关门全链路测试 □ 后端服务不可用时安卓端降级策略验证 □ 固件通信协议版本兼容性验证 □ AI模型更新后三端联动验证 □ 设备掉网后离线模式验证数据缓存上线补传 □ 多设备并发场景验证100台设备同时在线小结小团队QA的核心不是全面覆盖而是关键环节不放过。核心要点代码审查三件套自查清单自己查 交叉审查别人查 静态扫描工具查缺一不可自测规范单元测试是基础覆盖率要有量化要求自测清单是提测前的最后一道关卡轮测机制开发轮流当测试换视角发现问题功能/回归/兼容三类测试缺一不可质量度量用数据说话覆盖率/缺陷密度/逃逸率/识别准确率指标达不到不准发布三端差异化QA后端重接口和并发安卓重稳定和硬件交互固件重通信和功耗联调重全链路自动化优先静态扫描CI化、单元测试CI化、能用工具做的就不靠人——小团队最缺的就是人