再说测试

做测试年头不算多,偶有思考,提笔写时却全无印象,快消时代,记忆也消失的如此之快,趁此时记忆还好,写上几笔。 相信每一个测试人都有过如此的经历: 那些年,技术不好的人,细心一点,去做了测试工程师。 那些年,招聘的时候,测试工程师的薪水低于其他工程师。 那些年,一个项目组里,好像测试有种信心不足,又被忽视的感觉。 这些年,迷惘,测试人力争上游,努力学好技术,却从事着所谓的“点点点”的操作。 这些年,彷徨,敏捷测试,测试向前走,自动化,到底测试的方向是什么。 这些年,迷失,当初为什么选择测试,是自己的理想,还是为了一份工作,已经记不得了。 一年一年的事情,一年一年的匆匆过去,一年一年的,迷惘,彷徨,迷失从未停止过。开了好多次的会,听了好多次的分享,每次都有人问方向,路线,... 详情

实现WCF RESTful及一些感悟

最近温故知新了一下SOAP 和RESTful, 这篇文章主要讲三个地方 1. 比较一下SOAP 和 RESTful 2. 还是那句话,纸上得来终觉浅,绝知此事要躬行,代码实现一下 3. 半夜时自己对测试的一些粗浅认识 1. 比较一下SOAP 和 RESTful 比较我找了之前看过的一篇个人认为比较好的文章,链接分享下,不翻译了 http://msdn.microsoft.com/en-us/magazine/dd942839.aspx 2. 代码实现一下,这里我用WCF 4.0,新增的功能也没怎么用到,毕竟只是个Demo,IDE用 VS2010,技术发展的快,新的东西毕竟有它好的地方,不用体会不到它的好与不好,个人认为学习新的东西靠胆量更靠毅力,也可以锻炼下自己。 IDE 2... 详情

1:10之惑

    去参加QCon北京交流会之前,我已经知道Google的测试开发比是1:10,心中一直有些疑惑,想知道Google的测试工程师是怎样做到这一点的。借着这次北京之行,与Google中国测试经理段念先生进行了一次面对面的交流,使我对Google的测试有了更多的一些认识。     经过与段念先生的交流,我了解到Google中国的测试工程师只有十多个,外包大约二十多个。从绝对数量上看,测试工程师的数量确实不多。但,在Google,测试有一个721的原则:70%的测试工作在底层接口测试和单元测试;20%的测试工作在集成测试;10%的测试工作在界面测试。之所以做这样的选择,源于Google工程师对测试的一些看法。Google工程师认为底层接口测试及单元测试的自动化成本比较低,自动化的程度高、... 详情

测试架构白皮书

淘宝测试架构白皮书V1.0        在软件的生产环节中,会产生许多和测试相关的问题,相应的也会出现很多的解决方法,在一个肩负102年使命的公司中做测试工作,在102年宏大的软件生命周期中,测试问题解决方法也会以爆炸性的速度增加,结果会导致解决方法的数量是惊人的,方式却又是多样的,行为时分散的。        一种声音会出现,停止解决不断出现的问题,我们需要一种系统的解决方案使测试更加专业,更加适应一个长期发展,不断创新的软件环境。        2010年3月,淘宝测试架构组诞生。        测试架构提供了在技术上结构化指导测试的方法,它的出现: 为测试管理者和测试人员找到技术上的解决方案 优化测试流程 标准化测试工作,探索新的测试技术 团队中测试技术信息的对称 更好... 详情

测试用例PK后总结分享2——团队合作

我们的这次测试用例PK大赛,有些同学叫它“全民运动”,有人叫它是“研讨会”,还有些人说,与其叫PK,不如是一场盛大的“测试经验交流会”,每个组都有其特点,或优化或创新或集百家所长,把最好的展现给了大家,每位同学都美美的饱餐了一顿;最后,在大家的申明、辩论、反驳声中,提取其精华,弃其糟粕,总结出适合自己的一套规范、流程,也是我们这次PK的目的。   因为上周休年假,第二期总结迟了一周。   第二期分享主题:团队合作&明确分工 看一下这个加法1+1=2  。团队的力量却不是按这个加法法则在走。1+1>2,也有可能1+12.,如何让1+1>2, 甚至大于3,大于4,大于100呢? 需要有一个良好的团队,需要有良好的团队合作,而良好的团队合作需要以下基础: ... 详情

测试用例PK之1——明确目标

      轰轰烈烈的测试用例PK已经渐渐硝烟散尽。。。      这过程中有太多的喜悦、激烈的碰撞。有成功的喜悦,有失败的暗然。但是,从测试用例PK本身来说,在过程中,每个有收获的人,都是成功者。       收到大家很多收获的心声。前段时间说要组织一次总的“测试用例PK交流会”,无奈预定不到场地,加上最近公司半年会,研发中心Q2大会,测试组Q2大会。现采用全新的分享方式——系列邮件分享,展示给大家。     在陆续的一段时间内,会每周发出一份分享邮件,相信对大家有帮助的。 第一期分享主题:明确目标 拿破仑·希尔告诉我们有了目标才会成功。 目标如同海航中的灯塔,给我们指明方向。正如空气对于生命一样,目标对于成功也有绝对的必要。如果没有空气,没有人能够生存;如果没有目标,没... 详情

QTP右击鼠标事件的实现

'-----------about------------------ ' @funcname:Common_MicRightMouse ' @brief: QTP右击鼠标选择菜单并回车 ' @param:obj:具体的操作对象; rows:第几行菜单; ' @rtnval:无 ' @register:无 ' @register方式:无 Public Function Common_MicRightMouse(obj,rows) 'set obj= Browser("浏览器").Page("member/login_登录页面").WebElement("登录页面空白处") '拿到环境变量配置文件 cur_replay_type = Setting.WebPackage("Replay... 详情

一个BUG引起的一件小事

时间:项目监控期第二天   起因:项目上线后发现了一个bug   经过: TL:XX,今天下午把TK后台再回归一下! 测试:啊?!为什么? TL:我们对超时处理的那部分代码做了优化,因为当时时间比较紧,那部分代码写得逻辑比较混乱,可能会存在隐蔽的问题,所以优化了一下,理论上不会影响原来功能。 测试:嗯。那能否解决那个bug呢? TL:不一定,可能会解决。 测试:你们说,理论上不影响原来功能,那实际上你们对自己修改的那部分代码有多少把握呢? TL:把握不是很大。 测试:不是吧?!那我要回归哪些地方呢? TL:最好TK后台的功能全部再走一遍! 测试:哇!不是吧!这么多!改之前怎么没有通知我们测试?影响范围这么大,我觉得改之前应该先评估一下风险还有测试的工作量吧! TL:……测试大概需要多少... 详情

自动化测试体系整体解决方案探讨

自动化测试已经越来越深入人心,其重要性也是不言而喻的。性能测试中大规模并发的要求,压力测试中的大规模压力的模拟,回归测试中的大规模测试用例的反复执行都要求实现一个高可用、高可扩展性的自动化测试框架体系。因此,如何在一个开放的框架下,构建一个完整的自动化测试体系是我们需要研究的方向。 一个完整的自动化测试框架体系包含以下几个部分:1、自动化测试框架;2、测试脚本以及测试数据管理;3、测试脚本的执行管理系统;4、测试结果的显示与分析系统。其中最重要的是自动化测试框架部分。 第一部分,自动化测试框架。自动化测试框架要解决的问题,从本质上来说,是实现分布式资源透明化的过程。由于性能测试、压力测试的要求,我们往往需要构建一个分布式的测试环境,在这个分布式的测试环境中,我们需要多种测试平台(例如:... 详情

学习笔记之Java Annotation学习总结

   按照自己定的学习计划,今天是该写点什么了。   在上篇文章里提到的是JUnit的学习,其中就涉及到了一些内置的annotation,如@Test、@Ignore等。现在我就结合个人的理解谈下如何自定义自己的annotation。   annotation能被用来为某个程序元素(类、方法、成员变量等)关联任何的信息,但annotaion不能影响程序代码的执行,无论增加、删除annotation,代码都始终如一的执行。另外,尽管一些annotation通过java的反射api方法在运行时被访问,而java语言解释器在工作时忽略了这些annotation。正是由于java虚拟机忽略了annotation,导致了 annotation类型在代码中是“不起作用”的;只有通过某种配套的工... 详情

读自在《读牛柳“从开发到测试”有感》有感

非常感谢自在对我的文章进行了认真思考,自在也提出了更加深刻的观点,我也不禁有感而发,啰嗦几句。 对于自在描述的测试团队的进步,我看得非常清楚,团队成员的努力和成果都有目共睹。自在说不知道开发人员怎么看,其实我可以以前开发人员的身份说一下,你们做得非常棒!只是这个行业的起步比较晚,缺乏现成的东西,更没有形成体系,所以我看到它的成熟度还比较低,也正因为此,我很想投入到这个事业中,把它做好,和自在的想法——“我们携手去打造一个最强的互联网的测试团队,完成这个目标此生足矣”不谋而合,我跑来携你的手了(两个男人携手是不是有点奇怪)。 “没有开发,没有测试”,这句话有点禅味,像“色即是空,空即是色”一样。我更想换个表达方式,“我们都是在做开发,也都在做测试”,开发不仅是开发工程师的事情,同样,... 详情

从开发到测试

做了4年的软件开发,现在我到了测试部门。 很多人对此不太理解。 选择软件开发这份职业的时候,有人告诉我:这是一份很苦的职业。我说,这也是一份很酷的职业。4年以来,在苦与酷中磨练着,享受着。能够在淘宝做开发是一件很幸福的事情,你写的每一行代码每天都有几万到几千万的人在用,你在改变着中国的网络购物环境,这种美妙的感觉很难在其他地方找到。 当我来到淘宝的时候,只有两个PD,三个测试工程师,十来个开发工程师,四五个UI。所有事情都是大家一起做的,谁都要干点其他角色要做的事情,也没有那么多的模板、规范、会议和流程,网站的结构也非常简单。随着流量的增长,这么做不够了,开发不够了补开发,测试不够了补测试,功能不够了加功能。人多了,怎么让大家有效的配合就是个问题,于是我们需要管理的工具,需要工作... 详情

做你想做的自己

今天一位同学跟我沟通了自己的一些困惑,如何规划自己在测试路上的发展。我记得我曾经鬼使神差的邀请了当年的HR的老大丁典来跟我们讲测试的职业规划,为了丁典能讲的更加符合我们的这个测试这个职业,我当时还千辛万苦的google了一个有模有样的测试工程师职业发展方向的那么一副图发给丁典。现在的丁典继续鬼使神差的成了我们质量部门的头,我也不知道丁典是否就是通过这么一次演讲,然后把自己规划到质量部门来了。 回想下以前自己的状况,也确实是这样,天天做项目,天天很努力很“充实”的保证项目质量,做了一年多的样子,自己确实是有进步,但是进步的步伐却逐渐被自己发展所困惑。我的方向在哪里?我发展下去会是什么样子?甚至是我跳槽的话我拿什么去申请更高的工资? 接着心态开始乱,工作效果开始变差,激情各个方面开始也开始... 详情

返回首页 博客 技术交流 产品 期刊下载 关于我们 意见反馈 无障碍

浙ICP备09109183号-14 Copyright © 2003-2015 TaobaoTesting.com 版权所有