#34 楼 @seveniruby 你好,
其次,你说典型的后端测试上, 用录制回放的模式精确度很高. 而且很有效.
回答:即使是后端测试,纯粹的录制回放也是完全没有意义的,必须要通过脚本参数化、数据驱动等进行自动化脚本编写,我书里面真正批判的是纯粹的录制回放技术,希望以此替代黑盒脚本的做法,谢谢
#34 楼 @seveniruby 你好,
首先,你说目前做自动化的最大局限是由于自动化对功能的保证是通过 assert 等类似的断言实现的。
回答:通过 assert 等断言实现的是单元测试,而不是真正意义上的自动化测试。真正意义的自动化测试是可以根据功能上的验证点进行验证的,绝不仅仅是 assert 等断言,谢谢
#19 楼 @lihuazhang 回你了,谢谢提醒
#19 楼 @lihuazhang 回你了,谢谢提醒
反思 8:什么人适合做脚本执行?
节选自《深入理解 Android 自动化测试》。
反思 7:机器运行=手工执行?
节选自《深入理解 Android 自动化测试》。
反思 6:自动化效果=有效 bug 数?
节选自《深入理解 Android 自动化测试》。
反思 5:自动化=替代黑盒测试?
节选自《深入理解 Android 自动化测试》。
反思 4:什么才是强大的框架?
节选自《深入理解 Android 自动化测试》。
反思 3:什么才是强大的框架?
节选自《深入理解 Android 自动化测试》。
反思 2:要门槛还是要适配?
节选自《深入理解 Android 自动化测试》。
反思 1:关于录制/回放工具的幻想
节选自《深入理解 Android 自动化测试》。
软件自动化实施之八个反思(作者:许奔)
作为软件自动化测试从业者,从 2006 年至今,从 Windows 平台自动化测试到嵌入式系统自动化测试,再到 Android 系统与应用自动化测试。这些年来,除了对自动化测试框架封装、自动化工具开发、自动化脚本架构与撰写外,耗时最长的当属自动化在各黑盒测试团队的实施了。
对于自动化测试实施,相信每位自动化从业人员都有一肚子苦水要吐——黑盒测试团队不配合、实施结果差强人意、测试团队领导不认可、实施过程举步维艰、最终草草收场…这似乎是一个宿命,不断的轮回与无尽的折磨。
领导对自动化的看法见图 1-1,该图选自《深入理解 Android 自动化测试》。
黑盒测试人员对自动化的看法见图 1-2,该图选自《深入理解 Android 自动化测试》。
在很多技术大拿面前,这似乎不是个事——自动化实施不是团队内部技术最差的人做的吗?关我什么事?我只需把时间花在框架封装、工具开发、脚本架构上,甚至连脚本编写,也应该是菜鸟们的事。
对于这些技术大拿,我只能说他们是幸运的,也是不幸的。
幸运的是他们生活在这样一个组织架构中,这个架构是金字塔型的,如图 1-3 所示。
在这样一个技术壁垒森严的组织架构中,技术大拿和技术强人的确不用考虑脚本实施这样的小问题。但他们的不幸在于,由于没有具体参与实施、推广中,他们也很难发现自己封装的框架存在哪些缺陷。他们总觉得,如果真有缺陷,一定会一层一层地反馈到自己这里,然后自己一定会加以研究和修改。但事实是,反馈到技术大拿这里的问题,绝大多数是脚本编写或维护人员问题,而不是脚本实施过程中的问题。
当然,我们不能归责与技术大拿身上,一个成功的自动化实施,其中涉及到对工具、测试和人三者的反思,如图 1-4 所示。
其中不同角色对不同属性抱有不同幻想,许奔在此谈一下自己浅薄的看法,供大家讨论。
#16 楼 @lihuazhang 你写什么邮件?发我哪个邮箱?谢谢
#10 楼 @lihuazhang 你好,之前的帖子不是删掉了吗?麻烦确认下,谢谢
反思 8:什么人适合做脚本执行?
反思 7:机器运行=手工执行?
节选自《深入理解 Android 自动化测试》。
反思 6:自动化效果=有效 bug 数?
节选自《深入理解 Android 自动化测试》。
反思 5:自动化=替代黑盒测试?
节选自《深入理解 Android 自动化测试》。
反思 4:什么才是强大的框架?
节选自《深入理解 Android 自动化测试》。
反思 3:什么才是强大的框架?
节选自《深入理解 Android 自动化测试》。
反思 2:要门槛还是要适配?
节选自《深入理解 Android 自动化测试》。