此问题，来自“软件测试圈”中某测试从业者的提问 。

提取出来，统一解答。

如果想实时深度讨论、每日主题交流，欢迎进圈子。

/

关于需求未确定，测试同学该如何做的问题 。

首先，

这是一个普遍存在的情况，除非是一个非常成熟的团队，流程非常完善，否则经常会存在需求迟迟未定，或者频繁变更，开发已经在撸代码了，测试这个时候应该是要写测试用例了 ？

这个时候，很多测试同学就苦恼了。“正常流程，不是跟着需求文档、拆解需求，然后再参照原型以及UI写用例么 ？”

如果这些都没有，该怎么写用例呢 ？

老徐给几个思路 ：

1. 有个词叫“测试点”

需求未定，或者需求频繁变更的团队，明显不适合写测试用例，写了也是浪费时间（你写的速度，还没有变更的速度快，每天都是在做无用功。或者说，需求未定，很多细节，你也写不了） 。

2. 测试点到底该怎么写呢 ？ 侧重点是什么 ？

重点关注业务逻辑、业务场景、异常测试等，至于具体UI细节，简单带过即可（因为此时，需求未定，后续确定后，做简单补充即可，因为UI层面的问题，视觉就可直观的看出来，不需要大篇幅的测试用例，浪费时间，产出并不高）

OK ，总结来看，就是 写更大颗粒度的测试点来代替测试用例。

由此减少需求变更带来的用例维护成本，又可测试前置，且还可以保证核心流程、功能、场景化、异常情况充分覆盖 。

/

End ，就是这么简单，此问题解决结束，还有问题，底部直接留言，老徐解答。

/

补充一个话题，

关于需求频繁变更，本身就是不合理的，特别是版本发布临界点，是不建议临时插播需求的。

此处，项目负责人，研发负责人应严格把关，整个团队一起来把控质量。

而不是，任由需求变更，最后出问题找测试。

源头没控制，最后出问题属正常现象，问题看本质，方是一个成熟的职场人。

By IDO老徐

2017-08-30

注：老徐所有原创文章，禁止任何形式转载，转发、分享随意。

此文适合产品、研发、测试、项目负责人、研发总监 等技术管理者阅读，希望对大家有点参考作用。

很多团队存在的问题，追溯本源，其实就是这么简单。很多团队，喜欢把简单问题复杂化，不去承认问题本质。

曾经老徐写过管理方面的文章：

技术团队管理经验谈：到底是管什么 ？ 人？事？技术？

测试管理：老徐是如何管理测试团队的？

最后 ，

文章，如果有帮助，欢迎转发 。

写自己认为有价值的文章，每天分享一点点 。

邀请你一起加入。

20000名软件测试工程师一起搞事情，你怕不怕 ？

最后，推荐几篇有价值的文章：

为何每次上线发布过程，总是各种坑 ？

学会使用Fiddler抓包

经常有人问微信怎么测 ？ 他们到底是想问什么 ？

测试用例评审，他们是这样做的。

福利，

后台回复"11D"，领取老徐送的圈子免费码

圈子内老徐正在发起 linux SQL 的每日一成长，计划发起持续集成方向的深度探讨，有兴趣者加入

<End>

我是IDO老徐，Tester，十年测试职业老鸟，分享原创职业观点，经验，答疑解惑。希望通过自己的文字分享能改变测试职业现状，让测试从业者整体水平提升一个Level 。

老徐所有原创文章

第一时间发布至此公众号

长按二维码/微信扫码  关注老徐

老徐私人微信isTester

有问题，可留言

老徐所有的文章，只在此公众号更新 。

文章如有用，欢迎 转发 、 分享 。

让更多测试从业者受益 。