4662人阅读
软件测试-自动化测试Selenium（7）
软件测试-测试理论（5）
中华传统文化源于《易》，成于孝，孝为德之本。孝顺：孝则顺，不孝则不顺。
不久前，参加Thoughtworks组织的一场自动化测试的分享，同事由于出差国外不能参加，特意嘱托我提问两个问题：
在互联网这个将“敏捷”与“持续集成”进行积极实践的环境里，“敏捷测试”与“自动化测试”成了一个大家经常探讨的话题，
那么自动化测试最佳的实行时间是在什么时候？如何推行最有效的自动化测试？
以下谨代表个人观点：
个人整理了一些测试最佳实践并参考查阅了一些测试理论的书籍，又综合了个人工作经历的一些经验，总结了以下几点：
1、测试人员尽可能早的进入产品或项目的相关工作(这里指的产品或项目，指的都是从头开始的)，从产品的计划、需求调研、评审工作的开始测试人员就进行参与，这么做的目的有如下几点：a.让测试人员尽可能多的了解需求、了解业务，积极的提出问题，b.在下一步系统架构和接口设计之后，测试人员可以进行尽早设计系统的接口测试用例，c.还可以为下一步编码工作的单元测试做一个良好的铺垫，在后期设计单元测试用例的同时，懂代码的测试人员可以直接的检查开发人员的代码逻辑和业务逻辑是否符合要求，这也就实现了用最少成本“双人编程”。
2、综合一些实际情况考虑：根据一些实际调研，一般开发与测试的比例在1:6--1:10左右，能达到1:6的已经很不容易了，暂时不去讨论这个比例问题，因为这个需要根据项目的实际情况来看，个人看来：一些大型的互联网公司是不差钱的，所以他们会尽可能的在测试方面多投入或者说投入较高的，还有一些公司是不愿意在测试方面多投入但是又想多做测试的，还有一些就是尽可能少投入的，其实这些都可以调整，调整的依据是两个方面：一是确保公司对这个项目的重视和公司是真正的做测试，如果没有领导的支持，准确的说没有大领导的支持，测试工作是很难有效推进的，二是有效的安排测试人员，就是在项目的不同阶段安排不同测试人员，在测试不是很多是时候，可以使用半个人或者更少的测试人员，实现这一点的方法就是让一个测试人员去服务多个项目即可，当然这个多个也是有数量限制的，因为一个人的精力也是有限。
3、从第前2条提出来的一个疑问：作者一直提倡让测试人员尽可能早的接触产品和项目，这样能让测试人员充分了解项目，那么如何让一个人服务于多个测试项目？首先：明确一点，不是测试人员不从项目的开始就介入，测试人员就不能了解需求、不会测试。对于一个有经验的测试人员来说，快速的熟悉项目的需求并不是一件难事，如果说项目的各种逻辑真的是很复杂，项目经理也可以根据用户故事或者进行一些更为细致的安排来让这些协调过来的测试人员开展测试工作。一人服务于多个项目，这种事情在国内应该是屡见不鲜的。
4、如何安排人员也是一个如何花钱的问题：这种体会最深的就应该是外包公司，是先花钱还是后花钱还是超支还是项目失败，想必外包公司对这方面算的是最细的了。早期发现问题早解决问题，后面的压力就会小，不能早期的发现的问题，后面的团队压力就会像滚雪球一下越来越大。早期的测试投入看成一份成本的话，用这一份成本，来提早的发现问题的降低风险，后期才开始投入测试的话，也算是用一份成本，但是如果发现问题，开发人员就追踪、修改的成本是要远远大于初期的，项目的庞大和不稳定是让开发人员准确定位问题最大的困扰，还有测试人员做测试验证、回归测试、自动化脚本的修改这一切成本。
5、在项目的中后期如何做好自动化测试工作？在项目中期的时候，问题会逐渐积累，测试的东西也会越来越多，开发和维护的东西越来越多，维护是指测试人员测试出来的bug需要修复，但是又不能因为修复bug就停止项目开发工作。随着项目的推进，测试的效率保证是一个关键问题，这个时候自动化的推进和效率却成了一个矛盾的问题。原因有三：1.自动化代码需要编写和调试 2.自动化代码测试结果需要和手动测试结果进行比对 (自动化测试结果和手动测试结果不一致会有发生)3.自动化测试代码需要维护，尤其是在需求变更和设计变更的时候，手动测试只需要肉眼对比，而自动化测试可能会将代码进行较大改动。这三个问题大大降低了测试效率，这是手动测试必须成为项目的主导。解决这一问题的办法就是在项目测试集中的阶段调整手动和自动测试人员的比例，自动化人员测试的范围需要有一个合理的规划，必须定时的提交自动化测试代码，在手动测试完成后必须尽快的补充自动化测试代码，在完成测试工作的同时也自然的与手动测试的结果进行了比较，相当于进行了1次回归测试。也就说还是全部由手动测试人员进行第一轮全面覆盖的测试。
6、在“敏捷”开发过程中，自动化工程师先对哪一部分功能进行优先的用例实现：可以从以下几个方面进行考虑：1.优先考虑数据对比类型的功能，这种功能人工操作比较费眼力和时间 2.优先考虑已经测试出问题的功能，这样可以有效的对bug的功能进行回归检查 3.用户使用比较频繁的功能 4.项目优先级比较高，比较核心的功能
7.强调一点：手动测试和自动化测试对于项目来说同等重要，不存在自动化测试人员高级于手动测试人员。如果说一定要说哪个最重要的话，只能是看项目的不同阶段，在项目前中期的时候的时候，手动测试占据了核心地位，在后期的时候，自动化的全面覆盖保证了回归测试的有效进行。
8.总结：关于敏捷开发和敏捷测试的一点心得：敏捷现在已经被推向了一个高潮，何为敏捷？太多人有不同的见解，说到最后与敏捷最分不开的一词就应该是“实践”，敏捷是实践出来的，不是效仿出来的，现在太多的公司和团队在盲目的追求敏捷，拿scrum来说，有多少公司在做的只是scrum最最表象的一些东西，安排站会，制定sprint，总结会等等，但是这些真的给你的团队带来了改善了吗？想必答案只有他们自己清楚。我心中的敏捷：敏捷---敏-结，敏就是敏捷，简单的说就是要一个高效率，结：是指项目团队的协作和内部团结,这一点非常重要。看那些成功实施敏捷的团队和诸多的最佳实践团队他们都是团结一心的，整个项目团队都有一个共同的目标和追求，而不是每天项目经理在驱使着大家在前进，每个人都积极上进学习，遇到不懂的问题去总结、去学习，去突破，再去分享，而不是说，“这个问题太难了，这个技术太难了，这个。。。我可做不了”，如果每个成员都采用这种排斥的心里，那么这个团队就永远都敏捷不起来，还有就是在需要协作的时候，两个项目组不要互相“踢皮球”，而是要勇于承担责任，最普遍的现象就是项目出现了问题，然后大家在会上开始掐架。这时候有人会问，自己出来担责任不是傻吗？其实不然，一个明智的老板当然看的懂到底是谁的责任，是否真正的需要人来承担责任。如果这都做不到，证明这个老板也就。。。再谈实践，笔者看来，很难有一个很细致的又可以公用的敏捷方法，即使现在最流行的scrum，也是一个非常抽象的概念，所以才有诸多屡实施又不见成效的团队，最好的推进敏捷的方法就是实践，只有实践才能发现问题，才能解决问题，最好找到一个适合自己的敏捷方法。
&&相关文章推荐
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：782388次
积分：5065
积分：5065
排名：第5415名
原创：79篇
评论：119条
文章：14篇
阅读：479136
阅读：67108
文章：12篇
阅读：94798
(1)(1)(1)(6)(1)(2)(1)(6)(14)(3)(6)(5)(5)(2)(3)(1)(1)(2)(1)(1)(2)(1)(2)(3)(7)(4)(1)发现和了解你未来的雇主单纯技术角度看自动化测试误区是什么？
全部答案（共1个回答）
下是个人对自动化测试的一些经验和总结，仅供参考！考试大免费提供大量实用资料，本次辅导将全部采用视频授课的形式呈现给广大学员,考生可以随时报名参加学习，不用东奔西跑搜寻资料，备考费用更加低廉！欲报丛速！　　自动化的最终目标是什么?　　很多人以为是像工业革命一样消灭手工劳动者，在这里等于手工测试人员。但是测试存在一个目前来看还算正确的、其他行业不多见的悖论：任何时候，你都不能准确知道还有多少bug，就像警察不能准确知道还有多少贼一样。所以自动化的最终目标——目前来说——是解放尽量多的人手去进行更多的测试，除非有一种手段能像《少数派报告》里面的预言少女一样预知所有的bug。因为永远有bug，有未知的bug，所以目前不存在能覆盖所有bug的手段，这意味着总需要人的参与。现代化手段只是减少了而不是杜绝对人员的需求。所以如果认为自动化工作一做完就没活干，那你就大错特错了。正认为这些人闲下来，他们有空发现更难发现的bug。这本来没什么大不了的，但是搁在计划阶段如果过分乐观，牛皮吹得太大的话，到后面就不容易圆回去了。因为按上面分析，自动化测试总有些地方是力有不逮的，如果这些地方没有安排好人手时间，只要在这些地方出大问题，那你就玩完了。　　能否/怎样自动验证?　　这个问题每次复审测试计划的时候我都会问，针对每一个提出要实施自动化的地方。每个人、每个工具谈论自动化的时候都在说如何真实模拟用户使用产品的情况，这很好，绝对需要关心。不过我得问一句：测试的最后结果是什么?如果你回答“各种使用产品的场景已经运行过“就嘎然而止的话，你就漏掉了一大块：最起码还得加上“产品能工作/不能工作“!所以模拟用户使用产品的各种情况，只是解决上述问题的第一部分;如何得出测试通过/不通过的最终结论，才是解决问题第二部分的基础部分，还有详细缺陷描述、上下文数据收集等没做到呢!　　所以让机器像人一样使用产品，并没有解决全部问题，剩下的事情还有多少，这是需要视情况而定的。如果只是解决了第一个问题就认为万事大吉，那简直就是在赌运气——有些时候自动验证是小菜一碟，但很多时候不是。　　令事情恶化的是，自动验证了产品的一些指标，并不能反映产品的真实质量。有时验证过的指标通过了，其实其他地方暴露了问题却没有检查：比如说界面说没有查询结果，这是期望的，实际上查询请求根本没有发过去，不去检查底下做了什么的话是发现不了这种bug的;有时验证过的指标不通过，其实只是个小问题，大问题需要通过别的指标暴露出来的：比如说返回结果跟预期的不一致，实际上该有的都有，只是没有排好顺序而已，但是被标记成重要的测试用例没有通过，把开发人员搞个鸡飞狗跳。　　这个话题深入下去，那就涉及到白箱测试策略、逻辑推演、嗅探和代码注入以及布景伪造(environment mockup)等领域，但我想强调的只是，如果考虑自动化测试，自动验证绝对不是可忽略的问题。　　整合现有还是自力更生?　　这个话题用于辩论赛是最好不过的，它符合“没有定论“这个要求 。所以我只谈一下使用每种手段时的一些不正确的假设。　　“现有的工具多少经过测试，质量比自己做的更有保证“。先不在“是不是更有保证”这个话题上钻牛角尖，我们先关注几个问题：整个测试方案里面哪些部分是关键，质量不好会导致致命后果的?这些部分有专人保证质量吗?出事的时候反应时间和修复效果如何?如果这些问题的答案是“我充分了解”或者“没问题”，那我也同意这个观点(我敢打赌，回答“不清楚”或者“很不妙”的人已经跑去重新考虑整个测试方案了)。　　“整合现有的工具省时间和人力”。类似的几个问题：你能在这些工具中自由地调试产品的缺陷吗?整合方案能适应产品的演变吗?几个月后呢?几个版本后呢?有需要变动的话代价多少?(哗啦啦又跑掉一大队人了)　　“自力更生好控制”。投入产出比如何?引用的技术可靠吗?如果你是开发者(之一)，别人都觉得好控制吗?谁来测试你的自力更生成果?　　“有些事情必须得自力更生“。剪裁现有工具难度如何?时间允许吗?　　其实，纵观所有提出的问题，我想强调的一点是，自动化测试的开发跟产品开发一样，也是需要规划和管理的，回答这些问题也是自动化测试项目管理的一部分。
误区2：发展方向从儿童期圈定众所周知，人的发展，不管是智力上、心理上和情绪上，由于受许多不确定因素的影响，是无法完全准确地预测其发展方向和程度的
答: 什么是手部肌腱损伤？
答: 青岛连邦是连邦教育的青岛分校连邦教育隶属于天津市连邦教育投资控股有限公司，连邦教育成立于2001年，是一家以教育培训为核心的连锁培训机构，以职场人的教育培训为主...
答: 地理信息科学，
答: 当考学成为学校的最高目标时，学校的教育形式必将变得单一，课堂教学成为主流，各种活动成为掩人耳目的摆设，只在应付检查时临时上场便马上收兵
大家还关注
确定举报此问题
举报原因(必选)：
广告或垃圾信息
激进时政或意识形态话题
不雅词句或人身攻击
侵犯他人隐私
其它违法和不良信息
报告，这不是个问题
报告原因(必选)：
这不是个问题
这个问题分类似乎错了
这个不是我熟悉的地区2011年8月 移动平台大版内专家分月排行榜第二2011年7月 移动平台大版内专家分月排行榜第二2011年3月 移动平台大版内专家分月排行榜第二
2012年8月 移动平台大版内专家分月排行榜第三2012年7月 移动平台大版内专家分月排行榜第三
本帖子已过去太久远了，不再提供回复功能。}