情景：测试同事执行测试的时候，发现仍有不好理解的点，不知道怎么测。抛出这个问题后，大家一起探讨，也找上开发人员沟通，终于理清思路，整理出好几个关系到主业务流程的关键用例。
对于某个软件特性，如果觉得含糊，觉得无法预知它的结果（有什么作用、在哪里使用），无法通过一个明确的方法进行验证，那就意味着这个测试需求分析是没有覆盖到位，这项测试存在极大风险。而缺陷往往隐藏在需求含糊的地方。
怎样梳理含糊的测试需求？
1. 组队： 找需求人员、开发人员沟通功能属性、业务逻辑，找经验较丰富的测试同事协助分析。
2. 搞事情：把不明确的需求先放大，再拆分细化，然后进行组合串联。
一般需要获取到的场景信息：用户在处理实际业务时都要作些什么，多个业务之间的先后顺序是怎样的，用户在处理业务时对于哪些地方有特别的要求，等等。
总结
正如软件测试的基本原则：尽早地介入测试；缺陷越早发现，则修复这个缺陷的成本越小。
同理，往前追溯，测试需求分析越细致，则测试覆盖率越高，则缺陷发现的概率越大，则缺陷越能在早期被发现，从而修复缺陷的成本越小。
延伸，分析遇到阻塞，越早抛出问题，解决问题所付出的代价越少。
这道理都好懂，但实际操作起来的时候，往往会因为侥幸心理选择暂时忽略之，导致阻塞被延迟，进而影响到其他模块功能的关联性用例设计，这影响是连环的。
因而，越含糊的需求，越早理清越好。
网友评论