根据我对开发的观察，他们所谓的深度就是操作复杂度，比如一个 bug 在 A 情况下没问题，加上 B 情况才有问题，对他们来说就是有深度的，相反，他们对数据长度啊，输入类型啊，错别字和式样就认为是简单的。当然，我觉得这种混合场景用例的设计确实是一个值得思考的问题。

主要是为了方便维护数据，统一用文档维护方便些，不用修改代码

确实，excel 方便维护，其他的有一定门槛，不利于别人使用

好东西，挺全的

ddt 我感觉和自己写一个读取 excel 的方法区别不大呢。之前有用 ddt 读取 yaml，不晓得 ddt 独到之处是啥

下雨天去看一遍不就清楚了

我也在学 java，最近准备再学一点就去搞项目

这种细节分析确实好想法。但是我们这边测试看不到代码，所以数据层面测试不好分析，只能根据现象写用例。

往多了估，你估计 10 天，领导觉得一周，你估计一周，领导肯定觉得 4 天就行。而且测试时间越紧，根据我的经验，测试效果越垃圾。

这样的话，比正常情况少 3-40% 工资估计都有一堆人愿意干

确实集思广益也是不错的方式，但是现在任务项太多了，都让大家来评，时间上不允许。

技术层面还差的有亿点远

我们这边有安全部门，主要是他们从代码层面进行漏洞发掘，然后测试也会根据他们整理的一些方向进行业务层面的安全测试，还有一些漏洞发掘外包给 360 这样的大公司。安全部门那边还会配合测试搞一个安全测试用例，其他的我就不清楚了。

okhttp 据说不错

感觉有很多问题：1、准备图片问题。2、页面本来就存在的差异（比如编码）。

全部节点感觉可以整个方法遍历，如果是表结构，就遍历表格取 text 判断

不懂，但我觉得有意思

你应该说清楚你的情况，不然参考意见不大，跟梗图的全栈开发炒河粉一样就图一乐。

可以看下我做的这个分层设计哈：https://www.cnblogs.com/taokara/p/16394951.html

倒也不难，挺宽的，就是，，，招业务测试问这些干嘛?

作用挺大的，越复杂的系统，越需要测试。我在 OA 行业，如果没有测试，我觉得这玩意根本没法用，每天都有一堆问题出现，就这，系统还经常被用户吐槽垃圾（一想到我一个测试对接 10 个开发，我一点也不愧疚）。

你没有任何产品的能力，过去有什么竞争力呢？正儿八经要干好产品我觉得比测试难多了。

大佬，写用例的时候这三种用例是一起写还是分开写呢？我们是按模块分任务，很多时候一个功能三种用例都有，所以评审都是所有用例一起评审，感觉挺浪费时间的。

我其实也写得不多，根本不安排写用例的时间。

这个基本的我还是会的哈