2015.12.4(周日)
是 6 号吧
@chenhengjie123 恩 最好是这样 不过这小公司 是没有文档的
@chenhengjie123 这个我就在这么多,尽量都走一遍,因为这边现在没有要求我具体什么时候做完,时间上还好,但是可悲的是,公司不给测试看开发代码的权限,所以每次都是测试功能的时候抓包再去准备测试 case。
接口成为了手段,验证点其实是功能。
在做接口测试也遇到很多问题,一个功能点要想怎么设计好测试 case,通常一个接口可能很多的错误返回码,每次都要把这些个返回码都走一遍,工作量真是很大,也在找快速的方法。谢分享总结。
UC 浏览器编辑的评论有表情符号,电脑上看就没有了,都是空白。
话说 UC 也不是阿里的。
让别人帮你是不可能的,有排期吗,就催? 排期的时候要不你老大顶住,要不你顶住,顶不住就别干了,这样就算测完了也不会是好产品,最后的黑锅还得给你背。
🐒
@lihuazhang 速度
找回密码给邮箱发邮件报错了
谢 分享 膜拜
@sunrise requests 针对 https post 请求报错 method GET 不被允许,有遇到过吗
貌似文档中心 -- 帮助文档里边,文章中的一些链接打不开,有报错
ERROR: Unknown parameter: spm
谢分享!
@chenhengjie123 七百多 太贵不去了
查查机票多钱
@lihuazhang 是这样,发现的情况是,主路径线上也有问题,但是测试环境就可以,也在找具体是什么问题;还有就是一些小的地方,这个主要是测试没有覆盖到,要想办法避免;兼容性的一些问题,只要老板看到了就没得说了,等骂,老板不管什么原因。。
我这现在就没有,现在有个问题很恶心,只要线上出了问题,立马就问责了,测试为什么没有注意到这个地方等等,然后惩罚。。显而易见的状况是,需求也早提出来了,大家都讨论过了,感觉需求没有问题,开发也给了充足的时间了,测试也给了充足时间测试了,可还是出问题了,大家一直在想问题出在哪,然后结果就是大家认为问题出在测试方面。我的想法是从测试覆盖程度入手,就是看测试用例的覆盖程度,测试用例的执行程度和测试的周期时间。
正常 23:00 下班回家,步行 1 小时 20 分钟
果然都是熬出来的