一起养成写作习惯！这是我参与「掘金日新计划 · 4 月更文挑战」的第29天，点击查看活动详情。
大家好，我是阿萨。上一次聊到上线需求范围不明确该怎么办？有同学描述了一种场景：客户原始需求是由销售或者售后提出。测试无法接触到第一手需求，如何保证不漏测？
问：测试接触不到第一手需求，了解到的需求都是分解过的需求，该怎么做才能保证不漏测？
答：这个问题还是挺普遍的。因为随着分工越来越精细，每个人可能只能接触到全局的一部分，再加上信息传递过程中的信息丢失，就很容易造成如下场景。
\
看完是不是觉得，这不就是我们项目的写照吗？
今天我们先来看看如何避免这类问题：
-
使用文档承载 客户原始需求。不管是什么文档，我们必须要有一个记录客户最原始需求的地方。确保沟通过程中的信息不丢失。
-
如果产品没有，测试就要积极主动找项目经理去沟通，或者找销售/售后去积极了解这个需求。同时需要补充这一信息到研发系统里。只要用心，是可以找到这个最开始接手的人的。
-
除了事前分析，测试在测试需求分析，设计测试用例时要考虑以下方面：
- 用户实际业务实现的基本功能场景是什么？
- 需要考虑前置条件吗？比如老人，残障人士，儿童等需求。
- 功能涉及的数据流，数据从哪里来，经过什么样的处理，要流向哪里？数据范围，数据依赖关系。功能是哪个模块的输出？被哪个模块调用或者引用？
- 易用性方面，是否支持纯键盘操作？是否遵守从左往右，从上往下的操作顺序？
- 功能本身的约束条件，只支持数字，不支持日期，字符串，等其他条件。
- 权限，谁可以用，谁不能用？
- 性能需要达到的要求是什么？
- 异常情况有哪些？如何处理？
磨刀不误砍柴工。考虑了以上场景后，实际执行过程中就会遗漏较少。
4. 组织销售或者售后验收。测试基本完成验证后。拉通销售或者售后组织一次 验收，确保收集需求以及给研发下需求的销售或者售后在场。收集销售或者售后的反馈。这个测试一定要主动团结可以团结的力量和资源 提高产品质量。
通过事前分析，事中精准执行，事后总结来保证确实不会有遗漏。当然，漏测不可怕，可怕的是不会从漏测中发现问题根因并分析改进，这个才是最害怕的，日复一日地掉进同一个坑里。
感谢您的耐心阅读，如果今天的文章让你有所收获，欢迎点赞，关注和在看。
