个人技术分享

前端自测规范

4/20/2022 自测规范

# 前端自测规范

# 背景

  • 最近跟大家review 项目bug的时候，发现很多都是因为自测不充分导致的。其中，一些场景自测是可以完全避免bug的出现，因此把这些场景列出来，减少这里场景的bug出现率。
  • 另外，前几个项目review下来，大家过冒烟用例的时候，重视程度不够，一些问题，是冒烟用例中可以覆盖的，但是最终还是出现在了正式提测过程中。
  • 开发自测是保证代码质量的最基本方法和最低要求。测试用例评审完后，就需要明确自己负责的用例。冒烟测试、以及自测，大家都要重视起来。

# 自测用例

自测case应该由测试同学提供，现阶段即冒烟用例。

  • 要保证该模块需求中要求的功能是否正确实现。
  • 要保证该模块主要功能逻辑、主流程主路径能正常运行。
  • 要保证和该模块耦合度较高的模块，没有明显异常。
  • 要保证自测case通过后，不会有大块的测试用例无法执行。（例如某个逻辑有30条测试用例需要执行，那么这个逻辑的生效性验证就需要加入自测case；如果某个逻辑只有2~3条测试用例需要执行，那么这个逻辑的生效性验证就可以考虑不用加入自测case）
  • 可以考虑在自测case中，增加一些测试认为容易出现bug的路径。这个事情需要依赖测试经验的积累。
  • 针对质量较差的开发，可以增加自测case的数量级。如果某些开发同学的提测质量一直不高或者bug较多，可以在给他的自测case中多增加一些内容。但这么做之前需要跟开发同学或开发leader达成共识，这个过程中可以通过以下方式作为说服对方的辅助手段：
    1. 开发同学提测质量低的实际案例。
    2. 开发同学负责的模块bug数量多的案例。

# 执行

  • 通过提供自测case的格式，约束开发同学的行为。比如在自测case中，加入明确的测试结果一项，让开发回复时必须填写是否通过。
  • 冒烟用例提前执行，并监督执行。
  • 针对提测质量较差的开发同学或新加入的开发同学，在其提测后增加测试验收环节，确保开发同学自测到位。这过程发现实际效果与开发自测的反馈结果存在差异，需要及时反馈，当然需要@上一条中的那些能够管控开发同学的负责人。
  • 如果提测时涉及多名开发同学（如需要前后端交互），那么需要约定好主负责人，自测由该主负责人进行，避免提测出现问题时各种扯皮。

# 自测场景

# 交互规范

  1. 涉及到删除等一些重要的操作，需要添加二次弹窗。
  2. 涉及表单取值的地方，默认对字符串类型的值进行 trim 操作，去掉两边的空格。

# 分页列表

# 验证细则

  1. 入参、出参确保正确，需要打开调试工具，进行验证。
  2. 时间参数传参正确，容易出错，需要在系分阶段跟后端约定好日期的格式。
  3. 翻页正确。第一页、第二页，翻页请求，数据正常。
  4. 包括PC，Pad，H5，小程序中的类似场景。
  5. 加强筛选条件的边界测试。例如：输入框刷选条件：有值、空值；下拉框：单值、多值、空值；个案端缓存查询条件的，跳转新页面后，复写查询条件；搜索后，点击重置；下拉加载，上拉加载等传参正确。

# bug案例

# 字段展示

跟后端同学明确取值字段，包括是否需要做格式化。

# UI稿还原

开发过程中，确保还原度。 推动UI自测流程。

# 兼容性

APP端真机测试 小程序真机测试

# 埋点自测

埋点测试后截图，确认参数无误。

# 异常处理

对返回数据为 null 或 空的情况，做判断。

# 需求遗漏

仔细阅读PRD和交互稿，不要遗漏。

# 测试用例

测试用例评审的时候，保持专注，明确自己的用例。

# 代码遗漏

  • 因为测试某个场景，把部分代码注释掉，比如一些条件、一些配置信息，后面功能开发完成后，忘记恢复，从而导致了bug。
  • 解决方案：
    • 提交每次提交代码前，做一次diff对比，每次commit 要有区分，比如完成一个小的模块或组件，就做一次提交，不要一次提交太多的文件。
    • 做好Code Review

# 执行试点

家属信息（测试用例评审）