根据我对开发的观察,他们所谓的深度就是操作复杂度,比如一个 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 个开发,我一点也不愧疚)。
你没有任何产品的能力,过去有什么竞争力呢?正儿八经要干好产品我觉得比测试难多了。
大佬,写用例的时候这三种用例是一起写还是分开写呢?我们是按模块分任务,很多时候一个功能三种用例都有,所以评审都是所有用例一起评审,感觉挺浪费时间的。
我其实也写得不多,根本不安排写用例的时间。
这个基本的我还是会的哈