没有合适的资源?快使用搜索试试~ 我知道了~
首页自动化测试:现实挑战与误区解读
自动化测试:现实挑战与误区解读
需积分: 19 1 下载量 169 浏览量
更新于2024-07-21
收藏 862KB PDF 举报
"《走出自动化软件测试的乌托邦》一文深入探讨了自动化测试在现代测试行业的角色及其潜在挑战。作者作为"不懂管理的围观群众yijiubasi@163.Com",首先在第一章引言部分指出,自动化测试领域的观点存在多样化,常常伴随着不同的立场和价值观冲突,强调实践的重要性而非理论上的争论。 文章第二章关注的是识别测试模式和自动化准入条件。作者将测试分为产品测试、项目测试和运营测试,分析了它们之间的异同,并讨论了自动化测试的适用条件,如产品需求的明确性、软件开发的成熟度以及资源和需求的可控性。强调自动化并非一蹴而就,而是需要根据具体场景选择合适的策略。 接下来,章节讨论了自动化测试的目的和常见问题。自动化的优势在于提升测试效率、减少重复劳动、避免人为错误,但同时也强调了不能盲目迷信自动化,要理解自动化测试的根本目标,避免陷入误区,比如认为自动化是万能的、必须完全依赖或过度追求覆盖率。 在第三章,作者进一步探讨了自动化测试的管理和成效分析。如何构建和管理自动化测试框架成为关键,包括测试规范、资源、调度、对象、组件、数据和公共函数的管理,以及异常恢复和统计分析。作者提醒读者,真正的成本节省并非仅来自于工具的选择,而是如何有效地运用自动化来优化测试流程。 最后,作者在附录部分表达了对自动化测试实践中各种观念和现实问题的观察,倡导在讨论自动化时应尊重各方需求和实际场景,而不是简单地贴上商业主义或开源主义的标签,从而引导读者更客观、实用地看待自动化测试。 总结起来,这篇文章旨在提供一个实用的视角,帮助测试人员理性评估自动化测试的利弊,制定合理的自动化策略,以实现测试效率的提升和成本效益的最大化。"
资源详情
资源推荐
![](https://csdnimg.cn/release/download_crawler_static/9281763/bg7.jpg)
自动化杂谈
变更和界面改动在这个阶段内是比较少的,自动化开发和维护的成本非常低,并且应用于冒烟
测试、回归测试的效果是立竿见影的。
1) 如果在项目测试阶段已经完成自动化开发,那么在系统运营的时候只需稍微整理现有的功能
点、场景和流程分支,搭建用于每次发布的冒烟和回归测试集合即可。当然,补丁需求带来
新的功能点和关联的变更也是需要自动化工程师进一步自动化开发和维护的,不过比起整个
系统自动化测试的组建,这部分内容将不会消耗多少人力资源。
2) 还有一种情况是项目阶段某个(些)系统没有进行自动化功能测试或者没有进行完全的自动
化测试。这种情况下的自动化开发需要了解如下几点:
a) 固定时间内,版本发布的周期和 Staging 环境的修复移交次数将直接作用于投入产出比
例。版本发布越频繁冒烟、回归测试的次数自然也就越多,自动化测试带来的直接价值
越大;Staging 环境的修复移交次数越多,冒烟次数越多,用于每次移交版本的质量评估
操作越简单。例如,版本部署窗口在 17 点,部署 1 小时内完成,18 点半开始大规模的
自动化运行,次日早上即可得出一份较完整的测试报告。
b) 反之,相同周期内版本发布的次数越少……那么从上一段的论述是不是可以得出这么一
个结论呢:由于使用次数少自动化变得没有价值或者价值不大?事实上并不是这样的,
看自动化的价值不仅仅是看投入和产出在开发时间和运行次数上的比例!在项目周期内
这一点非常重要是因为它牵动着项目的各个方面,但是在项目之外除了单纯的考虑自动
化开发和应用时间比例之外还要考虑管理成本和质量目标,后者往往被大家所忽略,这
一点后文会继续分析。
c) 如果已经有了成熟的自动化测试体系框架,建议自动化工程师不要过多的参与运营测试
阶段内的自动化开发。首先,一般测试人员对系统逻辑更加熟悉,对测试过程中使用自
动化的需求更迫切。其次,让每个测试负责人都有机会学习一下自动化开发是一件好事,
尤其是在有锻炼机会的情况下测试技术和测试理念的提升会很快。第三,无休止的开发
和维护会把自动化测试工程师陷在某些系统中,虽然实践的机会比较多,但是或许有很
多更重要、难度更大的自动化开发在等着他们,把他们的精力分散在长期的多系统的补
丁测试开发和维护不利于人力的随时调度。第四,自动化测试工程师本身的职责应该偏
向于测试框架的修补升级、自动化测试管理协助、新技术和疑难技术的研究和解答、自
动化测试工具的开发,而不是单纯的做自动化测试的开发。
概括地看三种模式的测试自动化,我们先不妨下这么个结论:无论实在实验探索还是在成
熟应用阶段,如果自动化不能为测试带来收益,甚至变成了负担,那么自动化还是不做的好。
至于如何评估自动化到底是带来了收益还是带来了负担,我们再第三章将进一步讨论。
(3) 测试模式之外看拿来主义
这三种模式的手工测试和自动化测试特点与各自的公司体制和流程制度都有一定关系。经
常能在网上或者软件测试沙龙中听到不同的声音,大家对同一件事情同一个目标所做的事情也
都不尽相同,所以分歧和异议不可避免。笔者也发现有很多同行、同事喜欢照搬别人的“先进经
验”,比较信奉 Microsoft、Google 或者 SAP 的经验和理论,总喜欢讨论“别人这么做都怎么样
了,我们这么做也应该会怎么样”之类的事情,基本把公司运营模式和流程制度的整体建设等因
素抛在一边。例如,有人说 Microsoft 开发测试的比例是 1:1 甚至 1:2 应该是最合理的,是
![](https://csdnimg.cn/release/download_crawler_static/9281763/bg8.jpg)
自动化杂谈
重视测试的真正体现;有人说 Google 在开发测试比例 1:10 的情况下能够完成自动化测试对
敏捷开发的支持,说明人家的测试技术才真正是一流的;也有人说我们要引进 Microsoft 的测试
理念、Google 的测试技术,改一改我们的规范制度,也学习一下别人的敏捷开发、敏捷测试;
还有人会经常抱怨:我们的开发测试比例多么的不协调,公司把整个开发过程中的压力都往测
试周期内挪,还让我们做不简单、不务实的自动化……等等,诸如此类。其实这些言论大都是
不客观的,因为大家在说这些话的时候没有差异化看待各自公司的特点,有些公司是做产品的,
有些是做软件外包的,有的是做运营服务的,不能一概而论。虽然可能这些不同类型的公司所
做的事情有交集,但是主体的公司运营模式已经决定了、区分了开发和测试形态的大体走向。
笔者一个文思创新的朋友这么给笔者描述他在花旗软件做测试:测试工具种类很多,爱用什么
测试就用什么,给出测试报告就行……大家知道这样的公司或者部门可能一般是做软件(测试)
外包服务或者咨询服务的,之所以有这么大的灵活性那是因为他们要面对不同客户的需求,那
么别的类型的公司很明显不一定要满足这个特征——因为我们各自的客户需求是不一样的。
所谓实践出真知,“走有中国特色的社会主义道路”或许就是这么个理儿,既不能大跃进也不
能全盘西化,而是要结合实际情况量身定做一套适合自己的路子。同样自动化测试也是,万不
可照搬别人的东西,要知道“拿来主义”背后还有着“深思熟虑”四个字,不思考、不调研的“拿来”
是全无益处的,工具也好、技术也好、管理模式也好……都这样。
2. 自动化测试与软件系统开发
(1) 明确且严格遵循框架需求
咱们前文提到,在不同的情况下,自动化的作用和地位会有所不同,基于这个前提,我们
还需要弄清楚测试自动化在每一个独立的系统测试中应该起到什么样的作用,或者说要明确自
动化应该达到什么效果。请注意,这不是说自动化要投入多少、产出多少或者能带来什么效益,
而是说该系统使用自动化做测试要做到什么样一个程度。例如,笔者有一个系统测试任务,经
过调研知道了这个系统的测试可以使用自动化的方式来进行,那么测试自动化的作用点应该包
含哪些是需要明确的,如每次测试执行的报告是否自动化生成、是否要发送给相关领导和同事、
测试结果的多维分析度量是否也要一并执行、是否在执行失败的时候自动提交缺陷到缺陷管理
系统中等事宜都需要明确。
这正同做项目计划一样,如果事先没有明确要做什么,就可能会带来毫无目的的或者冗余
的工作。IBM360 之父 Brooks 在《人月神话》中提到对程序过分的修饰带来的“第二个系统”,
其实自动化开发也有类似的情况。如果没有明确哪些需要做、哪些可以不必做,那么测试人员
在做自动化开发的时候总会想着在既定的框架下增加一些额外的功能,而这些功能可能与系统
的测试没有多大关系,虽然它们会使自动化看起来更加强大、更具有兼容性和可移植性。笔者
犯过这样的错误:定好了计划并且汇报给了领导,但是在开发过程中不断的涌现“奇思妙想”并且
总是试图验证一下自己的想法是否正确,所以很多次在领导跟笔者要进度汇报的时候反倒落后
于自己的计划、落后于其他同事。后来想想,在公司现有的体系下去做这么一件事情,可以不
用太多的考虑“如果以后公司做了什么变动会导致笔者这儿要怎么办?”的问题;有前瞻性是好
事,但是最好不要过分“杞人忧天”,因为公司在做“什么变动”的时候会让大家都去厘清关联影响
的。但是那么多“奇思妙想”不用又是一个浪费!我们可以像系统开发一样,分一期、二期……先
保证需要使用的基本内容一定要按时开发完成,再找“合适的时候”去考虑增强测试框架和自
剩余37页未读,继续阅读
![rar](https://img-home.csdnimg.cn/images/20210720083606.png)
![](https://csdnimg.cn/download_wenku/file_type_ask_c1.png)
![](https://csdnimg.cn/download_wenku/file_type_ask_c1.png)
![](https://csdnimg.cn/download_wenku/file_type_ask_c1.png)
![](https://csdnimg.cn/download_wenku/file_type_ask_c1.png)
![](https://csdnimg.cn/download_wenku/file_type_ask_c1.png)
![](https://csdnimg.cn/download_wenku/file_type_ask_c1.png)
![](https://csdnimg.cn/download_wenku/file_type_ask_c1.png)
![](https://csdnimg.cn/download_wenku/file_type_ask_c1.png)
![](https://csdnimg.cn/download_wenku/file_type_ask_c1.png)
![pdf](https://img-home.csdnimg.cn/images/20210720083512.png)
![zip](https://img-home.csdnimg.cn/images/20210720083736.png)
![doc](https://img-home.csdnimg.cn/images/20210720083327.png)
![zip](https://img-home.csdnimg.cn/images/20210720083736.png)
![docx](https://img-home.csdnimg.cn/images/20210720083331.png)
![docx](https://img-home.csdnimg.cn/images/20210720083331.png)
![zip](https://img-home.csdnimg.cn/images/20210720083736.png)
![zip](https://img-home.csdnimg.cn/images/20210720083736.png)
![](https://profile-avatar.csdnimg.cn/default.jpg!1)
u010349453
- 粉丝: 0
- 资源: 6
上传资源 快速赚钱
我的内容管理 展开
我的资源 快来上传第一个资源
我的收益
登录查看自己的收益我的积分 登录查看自己的积分
我的C币 登录后查看C币余额
我的收藏
我的下载
下载帮助
![](https://csdnimg.cn/release/wenkucmsfe/public/img/voice.245cc511.png)
最新资源
- 多模态联合稀疏表示在视频目标跟踪中的应用
- Kubernetes资源管控与Gardener开源软件实践解析
- MPI集群监控与负载平衡策略
- 自动化PHP安全漏洞检测:静态代码分析与数据流方法
- 青苔数据CEO程永:技术生态与阿里云开放创新
- 制造业转型: HyperX引领企业上云策略
- 赵维五分享:航空工业电子采购上云实战与运维策略
- 单片机控制的LED点阵显示屏设计及其实现
- 驻云科技李俊涛:AI驱动的云上服务新趋势与挑战
- 6LoWPAN物联网边界路由器:设计与实现
- 猩便利工程师仲小玉:Terraform云资源管理最佳实践与团队协作
- 类差分度改进的互信息特征选择提升文本分类性能
- VERITAS与阿里云合作的混合云转型与数据保护方案
- 云制造中的生产线仿真模型设计与虚拟化研究
- 汪洋在PostgresChina2018分享:高可用 PostgreSQL 工具与架构设计
- 2018 PostgresChina大会:阿里云时空引擎Ganos在PostgreSQL中的创新应用与多模型存储
资源上传下载、课程学习等过程中有任何疑问或建议,欢迎提出宝贵意见哦~我们会及时处理!
点击此处反馈
![](https://img-home.csdnimg.cn/images/20220527035711.png)
![](https://img-home.csdnimg.cn/images/20220527035711.png)
![](https://img-home.csdnimg.cn/images/20220527035111.png)
安全验证
文档复制为VIP权益,开通VIP直接复制
![](https://csdnimg.cn/release/wenkucmsfe/public/img/green-success.6a4acb44.png)