有时候诞生的那一刻就是腐败的

工业界，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 上头的工程有跑跑看吗