有时候诞生的那一刻就是腐败的
工业界,PDCA、Lean manufacturing、 Agile Manufacturing 应该都是从丰田生产方式来的。管理是实践的艺术,这些事知难行易,真正花时间实践过很容易感受到重要性,纸上谈兵多了反而变得越来越玄。
一个会计术语,原文有维基百科的链接。
def add_one(num)
return 2
end
def test_add_one()
raise 'wrong result' unless add_one(1) == 2
end
这样代码覆盖率很高的
2013 年的文章,复式记账是个很妙的比喻。
翻译了另一篇:【译】为什么要相信测试?
把 page source 打印出来
自己写个有 toast 的 APP 试试
说不定你们 APP 里这个根本不是 toast
PDCA 循环式品质管理,是说这个吧。
开始学 Ruby 的一个原因就是翻来翻去只有 Ruby 社区爱讨论测试
见过的一些都是 istanbul、jacoco 这些本身用于单元测试的工具改的,一般是给手工测试或者接口测试用的。
典型场景大概是这样:
1、效果很差的单元测试、或者没有
2、两周到一个月发布一个版本、四、五个测试人员,反馈大部分靠手工测试、修缺陷期间会发布数次
3、iOS、Android、Web 三个客户端,后端几十个服务
4,一个版本多个进步不一的需求,一个需求可能需要三端、三、四个服务的改动
目的和场景都变了很多,比如想知道手工测试有没有执行到了被修改的代码、作为绩效指标、执行证明之类的
如果自动化 case 都不全,又花精力去搞什么 diff,那为什么不去多补补 case
工作也挺久了,除了一些开源项目,没有发现 case 全的情况,即使写得比较多,测试用例的质量也一言难尽
达到一定效果的情况下,两者成本差距非常大
这是个推荐语,你不输入直接点一下搜索按钮试一试
不在联想呀
自己公司的 App 可以用 ifuse
试试
需要的是执行测试时不影响真实用户,“测试环境” 这个词和现在常用的内涵会限制思路。
可以看看多活、多租户相关的东西有没有帮助,备份、同步、分流用到的那些组件方案。
基于二进制的应用层协议貌似没有长命的……
“你有怎样的社会结构,你就积累怎样的知识。”
"设计系统的架构受制于产生这些设计的组织的沟通结构。"
“下属批评让管理层更具创造力,因为下属无法影响管理者的薪酬和位置,从而不会触发管理者的不安全感;而来自上级的自上而下的批评,则会让管理者显示出较低的创造性”
看老书的时候就觉得,敏捷宣言呀、BDD、TDD 呀,这些的提出者在那个时代所处的公司的组织架构、评价方式,和现在国内这些互联网大厂差别太大了。
虽然有多有少,写过的的确蛮多了
vbs、Ruby、Java、JavaScript、ObjectiveC、Shell、Python
没压力的时候还是会觉得有意思,有的话就很心累
大概我看岔了,about-appium 下面把我换掉吧
├── about-appium
│ ├── intro.md
│ └── platform-support.md
├── drivers
│ ├── ios-xcuitest-real-devices.md
日志不全,用 markdown 文本,别截图
为什么不在回帖里说呢?
很久没弄了,试试呗
有看这个路径下的数据吗 /proc/uid_stat/
https://developer.android.com/reference/android/net/TrafficStats#getUidRxBytesint)(
HTTP 的话 Charles 有统计,可以和 proc 的比较看看
github 上头的工程有跑跑看吗