uat测试用例和sit测试用例_软件测试用例设计时的颗粒度

很多工作了好几年的测试工程师初次听到“用例的颗粒度”的时候会感觉很惊讶，这是个什么东西？我们工作里用到过？

其实在实际的工作当中已经有意无意的涉及到了“颗粒度”。比方说，用例编写的时候，可以写得很简单，也可以很复杂，就跟我们经常会听到的覆盖率差不多，简单的用例只需要指出要测试的内容、要测试产品的关键要素、要达到的质量目标、使用的测试方法等。而复杂的用例会指定每个逻辑分支的输入，期待的结果以及验证的方法，再具体到界面的操作顺序，测试的方法和工具、后台数据如何传输等等。

在上测试基础课单元测试的时候，学员们肯定都学过逻辑覆盖、路径覆盖、组合覆盖之类的。如果严格按照每个数据输入、每个条件、每个环境、每个逻辑都去设计用例的话那用例数量会非常的多，用例数量几乎是指数型上涨。虽然覆盖率得到了保证，项目出bug的风险也很小，但是面对严格的上线时间，海量的用例数量，是个人都会发怵：这么多用例，我7*24小时的测也测不完啊......除非有哪位大佬已经提前给你准备好了自动化脚本，就等你去点了，可惜并没有这样的大佬；可是如果用例写的很粗，到了执行的时候，有经验的测试工程师会发现bug，而没有经验的新人来测的时候，他就可能几十个用例都测不出一个bug，其实很多bug已经被他遗漏了，他只是呆板的按照用例写的去测，没发挥出自己的创造性思维。