呃 这算是纯广告了吧。。。

广告嫌疑太重，希望能在社区分享更多技术，谢谢

杨元庆是 2015 年 明星高管坚挺的代名词了。

#3 楼 @monkey 书籍推广，我们是允许的。

#5 楼 @lihuazhang ok

这个是不是那个很水的书^{_^}

扫码完，84.9 元，嗯

亚马逊买了一本，本来想看看录制回放怎么做的，结果没什么实质收货，放一边闲置中。亚马逊和淘宝会便宜一些

#9 楼 @sandman lol

#9 楼 @sandman 适合还在用百度的同学们入手，能提速不少。

#11 楼 @anikikun 确实，适合初入手自动化的闲时翻翻，工作忙时没时间看， 我就是挑标题感兴趣的点看了看。回复只是为了顺便说下想买的没必要去 jd，jd 贵。

#12 楼 @sandman 我就不评价了。。不方便评价

#13 楼 @monkey 我评价下吧，我还没看过

#14 楼 @doctorq 好，等你看了再说

我写了邮件给 @xuben ，他没回。如果 5 天内他不在这边出现，或者没回我邮件，说明他也就随便宣传下的。。。。

#16 楼 @lihuazhang 你是写了啥。。＝ ＝

#16 楼 @lihuazhang 你写什么邮件？发我哪个邮箱？谢谢

#18 楼 @xuben Email: xuben222@126.com 你注册的邮箱，如果你不用的话，那也没办法。

软件自动化实施之八个反思（作者：许奔）

作为软件自动化测试从业者，从 2006 年至今，从 Windows 平台自动化测试到嵌入式系统自动化测试，再到 Android 系统与应用自动化测试。这些年来，除了对自动化测试框架封装、自动化工具开发、自动化脚本架构与撰写外，耗时最长的当属自动化在各黑盒测试团队的实施了。

对于自动化测试实施，相信每位自动化从业人员都有一肚子苦水要吐——黑盒测试团队不配合、实施结果差强人意、测试团队领导不认可、实施过程举步维艰、最终草草收场…这似乎是一个宿命，不断的轮回与无尽的折磨。
领导对自动化的看法见图 1-1，该图选自《深入理解 Android 自动化测试》。

黑盒测试人员对自动化的看法见图 1-2，该图选自《深入理解 Android 自动化测试》。

在很多技术大拿面前，这似乎不是个事——自动化实施不是团队内部技术最差的人做的吗？关我什么事？我只需把时间花在框架封装、工具开发、脚本架构上，甚至连脚本编写，也应该是菜鸟们的事。

对于这些技术大拿，我只能说他们是幸运的，也是不幸的。

幸运的是他们生活在这样一个组织架构中，这个架构是金字塔型的，如图 1-3 所示。

在这样一个技术壁垒森严的组织架构中，技术大拿和技术强人的确不用考虑脚本实施这样的小问题。但他们的不幸在于，由于没有具体参与实施、推广中，他们也很难发现自己封装的框架存在哪些缺陷。他们总觉得，如果真有缺陷，一定会一层一层地反馈到自己这里，然后自己一定会加以研究和修改。但事实是，反馈到技术大拿这里的问题，绝大多数是脚本编写或维护人员问题，而不是脚本实施过程中的问题。

当然，我们不能归责与技术大拿身上，一个成功的自动化实施，其中涉及到对工具、测试和人三者的反思，如图 1-4 所示。

其中不同角色对不同属性抱有不同幻想，许奔在此谈一下自己浅薄的看法，供大家讨论。

反思 1：关于录制/回放工具的幻想




节选自《深入理解 Android 自动化测试》。

反思 2：要门槛还是要适配？









节选自《深入理解 Android 自动化测试》。

反思 3：什么才是强大的框架？




节选自《深入理解 Android 自动化测试》。

反思 4：什么才是强大的框架？




节选自《深入理解 Android 自动化测试》。

反思 5：自动化=替代黑盒测试？




节选自《深入理解 Android 自动化测试》。

反思 6：自动化效果=有效 bug 数？




节选自《深入理解 Android 自动化测试》。

反思 7：机器运行=手工执行？




节选自《深入理解 Android 自动化测试》。

反思 8：什么人适合做脚本执行？







节选自《深入理解 Android 自动化测试》。

#9 楼 @sandman 如果你认真看我这本书，我一直在批判录制/回放，我们做过很多尝试，包括将 monkey 改装为录制/回放，把 UIAutomator 改装为录制/回放，玩票很好玩，实战很失败

#7 楼 @kasi 是吗？希望你不是纯吐槽，如果看完后针对技术点进行吐槽，我愿意虚心采纳大牛建议，谢谢

#19 楼 @lihuazhang 回你了，谢谢提醒

#19 楼 @lihuazhang 回你了，谢谢提醒

#1 楼 @xuben 杨元庆这个只能代表作者的人脉关系强. 是个噱头跟测试没什么关系.
我们这是个技术社区. 你就算找到美国总统奥巴马签名我们也是无视的. 不过我会买本书看看作者写的如何. 从技术上给予公正的评论.

#26 楼 @xuben 上面贴的这些问答很有意思. 赞一个. 讲解的挺耐心. 不过我得提醒你, 部分结论是错的.

自动化工具你可以看看 twitter 的 diffy, 以及一些 diff 测试理论.
自动化测试不只是保证回归功能, 还能发现新的 bug. 这两个维度都有, 而且并不会产生谁比谁少的问题.
好的自动化工具覆盖的是特定功能点的功能 对功能的保证是通过 assert 等类似的断言实现的. 而实际上这就是目前做自动化测试的团队面临的最大局限. 验证功能是否正确不能仅仅通过断言. 还需要做到历史对比, 参考对比和类型校验等更多手段.

录制回放是测试行业普遍认可的"反模式", 不过这个理论也是错的. 在测试实践上, 只能说明端的录制回放有效性低而已, 并不能证明这个模式是错的. 比如典型的后端测试上, 用录制回放的模式精确度很高. 而且很有效. 现有的实践错不代表这个模式错. 每个团队都需要根据行业的技术发展而量力而行.

测试和研发的实践本质是一直的, 验证质量, 业务和代码的正确, 本质就是用数据来验证过程的正确. 从这个维度上, 你能发现更多有价值的观念.

#34 楼 @seveniruby 你好，
首先，你说目前做自动化的最大局限是由于自动化对功能的保证是通过 assert 等类似的断言实现的。
回答：通过 assert 等断言实现的是单元测试，而不是真正意义上的自动化测试。真正意义的自动化测试是可以根据功能上的验证点进行验证的，绝不仅仅是 assert 等断言，谢谢

#34 楼 @seveniruby 你好，
其次，你说典型的后端测试上, 用录制回放的模式精确度很高. 而且很有效.
回答：即使是后端测试，纯粹的录制回放也是完全没有意义的，必须要通过脚本参数化、数据驱动等进行自动化脚本编写，我书里面真正批判的是纯粹的录制回放技术，希望以此替代黑盒脚本的做法，谢谢

#29 楼 @xuben 我们在实践简化生成 case 的方式，使手工测试人员使用录制方式设计 uiautomator 的 case，使用回放工具解析录制的 xml 进行 case 的执行。出发点还是让不懂代码的可以直接设计简单的 uiautomator case。实现简单 case 可独立完成自动化测试及多次压力。

#20 楼 @xuben 暗自庆幸，我的领导自上而下都是重视自动化，而且也对自动化程度的认知很到位，在推动自动化上支持力度很高。在推动手工组执行，我是从压力测试入手，解决手工压力他们的配合程度很高的。至于自动化 smoke 和 mtbf 我们是 cover 在自己的手里控制，稳定成熟后才交付。

#21 楼 @xuben 我们的录制回放根本需求是：解决手工测试组可以简单的建立测试脚本实现多次压力测试及多 case 的依次测试的需求，易于生成脚本执行，易于维护。把简单自动化用例的编写及执行放给手工组测试人员。

#24 楼 @xuben 我们的自动化团队是测试需求服务团队，从测试需求出发提供辅助的自动化测试方案和测试工具，除了自己 cover 测试任务，也要交付稳定的自动化测试方案。还有就是测试工具方案推动研发自测的需求，具体的实现入口就是 apk 启动选择测试 case 启动测试任务。

#25 楼 @xuben 我的理解：自动化是服务于手工测试，解放重复性固定的测试工作，及稳定的专项测试的自动化。机械化的自动化思维可以减少固定 case 的漏测。

#26 楼 @xuben 我们这的自动化效果是从满足测试需求出发，不服务于项目测试需求的自动化都是白搭。

#38 楼 @sandman 你很幸运啊，在什么公司？

#43 楼 @xuben 乐视致新，TV，手机，盒子，安卓设备端的系统测试。目前主要负责性能测试，也涉及自动化和测试脚本方案和服务具体测试需求的测试工具的设计。
之前也在联想测过半年的 TV 项目，S 系列的 TV 项目当时跟的三方预装测试。我在乐视完成的手工测试到自动化到性能测试的转变。

#44 楼 @sandman 哈哈，不错，乐视很多联想人呢，我好多同事都在那边，不过你们自动化环境这么好，的确出乎我的想象。你们现在自动化测试的 case 覆盖率如何？

#45 楼 @xuben 按任务需求做的自动化，没统计具体的覆盖率，用例本身也是动态在变化的，根据测试需求能做的都会尽量做。

#46 楼 @sandman 大概有多少呢？你们黑盒用例分优先级吗？优先级最高的用例是否都已覆盖？

#47 楼 @xuben 我们是按自动化专项处理，smoke 是按总量要求完成 1000 条自动化测试用例，能做的都会做，安排人负责维护。其他也是按自动化专项进行的测试，根据手工组提的需求逐步增加。
目前我个人主要是转向带性能测试，不涉及功能自动化部分。

最近看了这本书，收益颇多，👍～

#49 楼 @350705144 谢谢

@xuben 感谢分享

@xuben 错了

亚马逊上购买了一份电子书，看着很好，图文并茂! 内容也很连贯，循序渐进！

#52 楼 @xuben 请问，你们的 UI 自动化脚本，回归测试中的成功率是多少？

#52 楼 @xuben 又仔细看了一遍，有 2 点非常赞同：1.做技术的不能华而不实，有影响力的人更应如此，很多同行的技术和认知没有达到一定高度，容易被误导；2.有技术实力的，能不用第三方工具的尽量不要用，能不用第三方插件的尽量不要用，主动权要掌握在自己手里。上面的问题愿意的话也请解答，谢谢

是不是太卡通了点?

#53 楼 @lihuazhang 收到

#57 楼 @ansonwoo 我喜欢这种风格，没法让大家都喜欢，抱歉

#56 楼 @quqing @xuben 还是要尽量用第三方优秀的东西 就算是大厂 也要谨慎的评估 一个产品是否优秀 其实就是看他自身的开放性和生产力

#59 楼 @xuben 公司采购把你的书名报上去了，准备看。感觉测试尤其是功能测试受到业务的局限性比较大，比如说做手机测试的去面试金融、游戏测试，就可能被直接拒掉，对方觉得你没有经验。这不像开发，你有一些项目经验之后去哪里都可以接手。当然，这只是我的一种感受，可能还很片面。总之，如果可以选择，我宁可往开发技术方向发展，也不想把业务往深了研究下去，因为我不确定这个业务还能走多久。

84.9..

我推荐个下载地址：http://www.quzhuanpan.com，哈哈，请叫我雷锋

不错不错