我也遇到了，你是怎么解决的呢？

一次参加一次沙龙，里面说的自动化也需要分成，70% 单元测试，20% 接口测试，10% 的 ui，上次面试新蛋，他们也说他们 UI 还是是手动测试，接口，单元自动化，感觉流程类冒烟测试和回归用 UI 自动化意义要大点

说的我在网上了解的一些看法哈，理论上这种都是算 bug，但是实际设计用例的时候会进行一下讨论：
1.输入中哪些在后端限制，哪些在前端限制，因为有些在后端处理反而受益不高，这些就需要加强前端输入的验证
2.有些参数是不可能存在空值，比如登录这种，接口登录后才能调用，用户名自己就获取到了，就不会存在字符串类型，字符格式不对
3.通过 1,2 对参数进行筛选，在通过他们说的正交表生成测试用例，在进行适当的增减，基本都可以了
4.你说的情形如果开发说的情形确实不存在就可以忽略，否则你可以自己设计正式使用场景来推翻他，以例子为证
5.其实我们公司也是，开发说是啥，就是啥，虽然公司说改革，改了几次，感觉变化并不大，因为项目太多，永远都是在老项目上修改，要验收了，才开始测试，受够了这种模式，加上家庭原因，辞职了

直接用代码调用接口，也学要知道接口返回值得规律吧

你说得这两种方式都可以，还是可以这么干，只是没有实践过

恩，谢谢回答，这个以前我搜索过，但是没找到工具，后来自己手工计算四个参数的情况，但是算到后来就不明白为什么这种方式就能很好的代替全覆盖的情况

我觉得他那个走设计的角度来说很完善，但是在实际操作中不太现实，，如果结合他前面说的，当一个方法有多个参数（>4）,每种可能一条用例，那个数量还是很吓人，所以很想知道在设计数据的时候是不是有什么比较好的门道，平衡覆盖率和收益

分析的和全面，但是这样写出的测试用例会不会太多了，效率不高，受益也不高呢，可以看哈你后面写出来的测试文档不呢

Xunit 是不需要对测试类进行标记的