Let's Go!

发布新日志

  • 百度搜索研发部官方博客(http://www.baidu-tech.com)

    2011-11-23 11:43:32



    http://stblog.baidu-tech.com/


    http://stblog.baidu-tech.com/?p=755

  • 转载:测试流程——眼熟

    2011-07-24 22:41:28

    在国外做软件测试工作的体会



    经常在网上看到有在国内从事软件测试的同行抱怨:测试不受重视,测试管理混乱,产品质量差等问题。说到底这都是管理上的问题。

      我想谈谈自身的经历。

      我毕业后在外包公司工作,客户是一家美国公司,产品发展前景挺好,也有一笔不菲的风险投资。我想说说他们的测试管理制度。

      首先,他们有一个很好的资源共享平台,我们叫Wiki,上面包括每一个版本的任务,每一项任务的开发负责人及测试负责人,相关的Spec以及其他开放文档。而且,每当这一版本的任务快完成时,下一版本的任务的雏形就出来了。

      其次,开发和测试严格按照软件生命周期执行。

      第一阶段:

      需求出来后,开发和测试同步进行,开发完成代码实现,测试完成test outline和test case,这些文档都会上传到Wiki上。我们在理解Spec和完成testcase的时候,会及时提出自己的问题,这些问题一般在第二天就能从开发人员 得到反馈。而test outline和test case最终完成后也要经过开发人员的验证,有时他们会提出自己的意见,测试要点和一些你未曾想到的case。

      第二阶段:

      新功能的测试阶段,测试提交bug,开发修改bug,这一过程由JIRA管理。

      第三阶段:

      回归测试:

       每一个版本的下半阶段都是做回归测试,这是一个比较漫长的过程,一般分两部分,一是执行所有的case(一万之多,有赶超两万之势),二是执行任意测 试。在执行case的时候,我们还要同时更新case,有些是更新内容,有些是添加新的bug,有些case可能会过时。当然,新的bug也会提交到 JIRA。在这个阶段,测试人员会安排在不同的平台上测试。可以说,在做回归测试的时候,测试覆盖率极高。

      第四阶段:

      预发布版本测试:

       做完回归测试会形成一个较稳定的版本作为预发布版本,预发布版本会被部署到另一台测试服务器上。这时候需要在不同平台上做一次QL(Quick Look)及任意测试。预发布版本上一般不会再迁入changlist,除非在此之上发现了较严重的bug,就会有新的r2的预发布版本以及再一次的测 试。

      第五阶段:

      内部测试:

      新版本发布前一两天可以说是全民皆兵,公司里大大小小所有人都进行测 试,包括CEO。(当然CEO不会自己来报bug,她会把问题反馈给我们的技术副总裁)。当然他们所报的bug也会成为我们的谈资。作为测试人员,我们不 仅追求bug数量,更要追求bug被fix的概率。当发现一个bug时,首先我们得确定它不会成为won't fix或invalid的问题,并且它can be reproduced,然后它不会duplicate某个已有的bug,如果这个已有的bug已经被close了,就应该reopen它。而这些非测试部 的人不管三七二十一,看到是个问题的就报,一天下来新加的bug数就该让相关的开发人员头疼死了。好在这些问题都会一个个地得到它们应有的解决方式。

      第六阶段:

      产品发布测试:

      产品发布前会在和产品环境相同的服务器上做一次QL(Quick Look)和任意测试,产品发布后又会在产品服务器上做一次QL(Quick Look)和任意测试。

      第七阶段:

      测试整理:

      这一阶段主要是整理在这一版本生成的测试文档和测试用例,新功能的用例和一些之前未覆盖的用例会被导入测试用例管理工具。

      ----------------------------------------------------

      可以说,以上测试流程都是经过计划并且严格执行的,和大家一起分享,也许你会从中有所收获。


    http://www.51testing.com/html/69/n-240369.html



  • 你的测试

    2011-05-07 23:03:47

    下面转几个帖子,也谈谈个人最近的一些感受:

    1. 样样通样样松,永远也不能成为某方面的专家。

    2. 尽早的考虑自己的优劣势和发展方向,有目的的努力

    3. 如果你在做性能测试,那么就我个人的感受而言,相对整体而言,loadrunner只是一个工具而已,虽然这个工具本身也还是有一些东西在里面的,但也仅此而已,需要构建的核心能力在此之外。



    也谈测试的核心技术(转贴)
    http://bangpai.taobao.com/group/thread/186587-11286247.htm

     
    测试这行的客观规律总的来说是:入门容易,提升难。 有些人干测试8-9年了,其针对同一个产品的测试思路和方法,与干测试只有2-3年的人看不出有什么区别。于是行业中有了一种误区,认为测试技术的提升主要集中在对性能测试工具的使用及脚本开发,自动化测试开发,测试工具开发领域。仅个人愚见:测试工具开发和自动化测试开发 主要还是开发技术而不是测试技术,从没有做过测试分析,测试设计的开发人员也能胜任。如果仅狭义地认为测试技术的发展只在自动化测试框架开发或测试工具开发上,那么从逻辑上来说,任何一个开发人员都可以成为测试技术大拿。当然我想:没有人会真正这么认为。

      就其我的感受而言,开发工作有时反而会简单一些。为什么呢?开发工作的目标从一开始是非常明确的,要实现什么要做什么做到什么程度大多数情况下都是清晰的,最大的困难则是如何实现如何做到,总的来说是一个不断聚焦的过程。而测试工作的目标呢?其实很多时候,并不如开发那么明确,例如:同样一个性能指标,开发很清楚要通过实现XX算法来达到目标;而测试则需要对该性能指标先进行测试分析,再进行测试设计,可是测试分析做到什么程度却是一个发散的过程, 2小时也可以,2天也不够,这就导致了测试质量的浮动范围是非常大的,由于开发和项目经理通常对测试设计并不了解,也无法了解(测试其实是一个专业度非常高的领域),因此会导致测试部的工作质量很难在过程中真正去度量和监督。

      从哲学上来说:确定性的规律往往难度不大;不确定性的规律往往说明它是一个复杂系统。因此,我个人认为:测试技术领域最难的技术应该是测试分析和设计。从另一个角度来看,测试价值的体现最主要还是保障自己组织开发的软件在关键应用时不要出故障,给组织造成商业损失。所以,有效的测试覆盖率是最重要的测试工作目标(而不是自动化测试率),需要说明的是测试覆盖率不等于代码覆盖率。通过单元测试达到代码覆盖率100%了就能保障产品无bug其实是一个误区,因为很多组织会为了达到单元覆盖率而去开发单元测试代码,单元测试代码或单元测试设计的质量只能保障消除产品编码的问题,发现产品设计的问题则往往会很困难。而发现产品设计问题的最主要方法还得需要基于黑盒的测试分析和设计。

      如何做好测试分析和测试设计,根据我的经验和体会,建议测试分析和测试设计主要通过3个维度来做,则可以大致达到一个比较高的有效测试覆盖率:

      维度一:从用户实际使用的场景和习惯入手,开发一批测试用例;

      优点:  可以覆盖到主要基本场景;

      不足:  从事场景分析的人无法做到了解用户所有的场景,必定受参与测试分析资源限制会有场景遗漏;

      维度二:通过测试对象内部实现流程的路径及依赖关系分析入手,开发一批测试用例;

      优点:可填补维度一的部分遗漏场景,特别是异常处理和分支交互处理的场景;

      不足:分析阶段主要精力会被局限在内部流程的熟悉和分析中,从而也会遗漏真实环境中的一些偶然小概率事件;

      维度三:依赖基于经验的测试分析和设计,例如:错误猜测法或探索性测试法;

      优点: 给维度二再做一次补充测试分析和设计;

      不足: 维度三效果的质量高低取决于组织内部经验的积累量及测试人员思维的发散能力和创造性;

      总得来说:无论是功能测试还是各种专项测试,依次使用以上3个维度的测试分析和设计,基本上能覆盖到被测对象的绝大部分应用场景,充分保障产品质量,减少问题遗漏。

       对"依次使用",有疑虑,一上来就测大的场景,认为不妥,还是先从基本模块/逻辑流程开始测试认为妥当些。

      因此:测试的核心技术是测试分析和测试设计的能力,它决定了后续所有测试活动的质量及效果。同时,要做好一个测试任务,掌握广泛的测试类型也是必要的核心技术,如:如何给每个测试对象做细做深压力测试,长时间测试,健壮性测试也是决定项目测试质量的关键所在。我本人不相信随便做做的压力测试设计和健壮性测试设计能够保障产品实际应用表现良好。

      测试活动的质量或者一个测试工程师技术水平如何将主要取决于:测试分析和设计的深度及系统化,以及掌握广泛的专项测试类型。

      一家之言,仅供参考,欢迎大家继续讨论。

     

    淘宝性能测试白皮书V1.0 隆重发布http://bangpai.taobao.com/group/thread/186587-6541778.htm

     

    网上已经有一个外部版可以下载

     

     

    春天,生机盎然、百花盛开。

    踏着希望的步伐,淘宝网性能测试团队隆重推出《淘宝性能测试白皮书V1.0》。

     

    淘宝性能测试白皮书,旨在以理论指导实践,以实践修正理论,从性能测试指标、淘宝性能测试模型、性能测试策略、性能测试评估、性能测试类型、性能测试执行方法、性能监控和性能分析、性能测试通过标准,以及性能测试流程和文件模版。同时,也是让更多的人更好地了解淘宝性能测试和性能调优,参与性能测试,共同将淘宝网做得更大、更强、更稳定,并且期望淘宝的性能测试能成为电子商务性能测试业界的标准。

     

    引用郭芙序言中的一段话,道出意义,“每览昔人性能测试成就之由,若合一契,未尝不临技能嗟悼,不能喻之于怀。固知一技术名利为虚诞,齐知识业绩为妄作。后之视今,亦犹今之视昔。憾夫!故列叙性能理论实践,录其指标模型策略,虽世殊事异,性能技术,其致一也。”

     

    借此机会,非常感谢为白皮书提出建议和意见的同学们!

    性能测试白皮书的编写,充分体现了团队合作精神,从初稿、review、修订、交叉review、定稿,每个细节我们都加以控制和把关,精益求精,5个版本,历时8个月。又猛又持久!。

     

    非常感谢丘虚的指导,感谢郭芙的精彩序言,感谢为白皮书编写付出辛勤汗水的性能测试团队成员――悟石、耿电、云帅、元壮、词馨、武彻、冷之!

    PDF文件链接地址:http://twork.taobao.net/docs/淘宝性能测试白皮书V1.0_内部.pdf

     

    **********************************************************************************************************************************

    淘宝性能测试白皮书导读

    白皮书包含以下章节:

    1.      序言;

    2.      目录;

    3.      引言;

    4.      性能测试指标;

    5.      性能测试模型;

    6.      性能测试策略;

    7.      性能测试评估;

    8.      性能测试类型;

    9.      性能测试执行方法;

    10.  性能监控;

    11.  性能分析;

    12.  性能测试通过标准;

    13.  性能测试流程;

    14.  性能测试文件模版;

    15.  结束语;

    16.  参考文献;

    17.  版本更新说明;

    18.  作者介绍

    序言由淘宝技术研发-测试部掌门人郭芙执笔,文言风格,酣畅淋漓。

    **************************************************************************

     

    转)自动化利器之JWebUint --- 就当做多了解一个东东吧
    http://bangpai.taobao.com/group/thread/186587-22186432.htm

     

    性能测试的注意点:

    http://qa.taobao.com/?p=1032


    性能计划:
    数据准备,脚本调试要列入性能测试时间计划。
    性能测试需求分析:服务器数量,每天PV量,业务数据量,基础数据量等等。
    性能测试目标:
    通过每天的平均PV、高峰PV,采用淘宝80/40公式计算每台服务器每秒的平均PV和高峰PV。
    性能测试类型:
    序号 测试类型 目的 是否执行 备注
    1 性能测试 测试被测系统是否满足预期性能目标 是
    2 负载测试 测试被测试系统的最大负载值 是 CPU: <75% Load:<4(4核)
    MEM:1w)时,保存数据包文件,脚本运行从数据包读取数据。
    3. 数据包文件超出LOADrunner规定大小时,运行单脚本时提示数据包文件无法打开,此时采用数据拆分成,分别关联即可。
    测试场景设置:
    根据生产环境的实际并发量,设置测试场景。通常情况下,测试并发用户和实际并发用户的比例为1:10,通过LR场景设置-不间隔的对目标接口加压,从而达到10倍测试用户的并发压力,测试结果真实有效。


    招聘信息
    http://qa.taobao.com/?page_id=110

    通过解读招聘信息,你可以了解到相关要求,互相比较,知道自己的位置和努力的方向

    公司名称:淘宝(中国)软件有限公司

    公司规模:1000 人以上

    公司行业:互联网·电子商务

    工作地点:杭州

    职位信息

    无线应用高级测试工程师(急招!) 6人:
    移动互联网将是互联网时代的有一个浪潮. 淘宝的移动电子商务,将会引领这个行业的大发展. 目前,淘宝无线事业部正在开展无线wap、各手机平台上客户端产品这2个方向的研发突破和应用。 加入淘宝无线,你实现的价值绝不仅仅是一份单纯的测试工作,您将与团队所有成员一起,逐步改变并创造着另外一种改变人们生活习惯的快速便捷的购物方式;您所参与研发的产品, 将会影响所有网上购物的人. 您所承担的将不仅仅是工作的责任, 更是一种社会责任. 您将有机会成为测试行业的标杆领军人物。
    无线的美,无限美!
    加入我们,在这里您将有机会接触到:
     前沿的无线客户端电子商务软件产品;
     与电子商务行业和无线应用行业最优秀的工程师一起工作, 设计研发出引领行业的优秀产品, 影响并改变中国4亿网民的网上生活.
     您将参与淘宝无线电子商务应用产品的设计研发, 作为测试工程师, 你还将负责无线应用软件的功能测试, 性能测试,安全测试,并设计研发高效的自动化测试方法和测试框架.

    加入淘宝无线测试, 把握时代的机遇与挑战.

    岗位职责:
    1、 参与淘宝无线应用的设计研发;
    2、 负责淘宝手机无线应用的软件测试,保证其软件质量.
    3、 能快速深入理解系统内部的工作原理,有对测试需求做透彻分析的能力;
    4、 对bug的清晰描述及快速准确定位bug原因的能力;
    5、 对项目的测试进度把控及风险有足够的处理、预防能力;

    岗位要求:
    1、 具备3年及以上测试工作经验。具有在wap、手机终端产品上的测试经验者优先考虑(Android /J2ME/Symbian/Windows Mobile/MTK等);具有手机自动化测试经验,并能对工具测试开展创新优化者优先;
    2、 掌握QC、Bugfree、JUNIT等测试工具、测试框架的使用;熟练掌握Linux基础命令、Mysql、Oracle等的操作使用;熟悉Java,C,Ruby/Rails,JS,HTML等编程语言。
    3、 熟悉软件工程中产品的研发流程,深刻了解测试工作的责任;
    4、 为人踏实敬业,乐观开朗,思维敏捷,善于发现问题。具备良好的沟通和合作能力,并且乐于分享。

    SNS高级测试工程师(急招!) 8人
    淘宝SNS技术质量团队和门户,淘江湖两大产品一起,在超过2亿消费者的大淘宝平台上迅猛增长
    淘江湖社区, 致力于发展成为电子商务购物的大型社区, 分享和交流购物体验,引导优质的网上购物生活.
    我们拥有强大的产品阵容, 包括
    1. 团购产品”聚划算”, 2010年中国团购网排行第一, 成交额超2亿.
    2. 淘江湖, 基于购物分享,方便淘宝买家借助朋友力量决策购物,实现淘宝从“搜索引擎流量”转向“社会化分享流量”
    3. 淘帮派, 超级人气的产品购物论坛
    4. …

    在这个世界顶级的技术和商业云集之地, 你的技术将直接提升亿万消费者的生活满意度
    岗位要求:
    1. 精通测试方法和测试流程,擅长解决复杂问题和指导新员工
    2. 有开发经验者优先. 至少熟悉一种编程语言, 比如java/ruby等
    3. 有基于SNS或者门户相关的开发测试经验优先
    4. 有自己创新的测试方法和测试流程或者在业界有影响力的技术贡献优先
    5. 享受激情的分享,坦诚的接纳,勇敢的承担

    商品中心资深测试工程师(急招!) 10人
    网上购物在电子商务巨头淘宝网的带领下迅猛发展。UV,PV,交易额一路飙升,这背后离不开技术的突破与创新。这里有自由开放的平台让你释放激情,有无限的空间让你发挥创意,淘宝商品中心测试团队期待您加入:
     参与淘宝海量商品中心系统的研发设计和测试;
     挑战海量数据处理的超级分布式系统. 目前淘宝商品在6亿以上,4亿日PV的高并发访问,并保持高速增长.
     你将参与研发测试该系统的全过程, 并为此系统设计研发高效的自动化测试框架和测试工具.
    岗位职责:
    1. 负责淘宝商品中心的大型产品和项目的测试管理, 包括需求/技术方案评审, 测试计划, 测试方案, 测试跟踪等.
    2. 把握商品中心的产品特性, 负责复杂产品测试设计,并指导其他测试工程师的测试设计;
    3. 参与产品的性能评估,分析系统性能瓶颈和安全隐患;
    4. 研究并设计开发适合商品中心的特定产品的的自动化测试框架和测试工具以及测试方法等
    岗位要求:
    1. 有1年以上JAVA/C++开发经验,参加过大型项目研发;
    2. 有1年以上测试经验,独立承担过大型项目测试负责人;
    3. 熟悉Linux/Unix操作系统,熟悉J2EE架构;
    4. 掌握至少一门自动化测试语言,(RUBY/Junit/SHELL / PERL/PYTHON等)
    5. 对Internet/web相关知识有深入了解,如,Http,Html,js,css等
    6. 精通测试设计,掌握单元测试/接口测试/压力测试脚本设计,掌握系统性能测试方法;
    7. 良好的沟通能力
    8. 热爱技术,热爱测试,有积极主动的心态和高效的做事风格

    底层平台测试开发工程师(急招!) 6人
    淘宝网拥有海量的数据和用户,背后支撑着这些巨大的访问量和数据量的是我们业内领先、规模庞大的分布式存储、控制、通信系统。在这里你将能够参与到这些核心系统的研发工作中去,与其他业内顶尖的工程师共同合作,创造出淘宝数据量、访问量的一个个新的奇迹。我们鼓励创新和思考,鼓励成长和学习,期望你的到来和淘宝一起高速成长。
    岗位职责:
    1、 参与淘宝核心系统的设计研发, 包括分布式文件系统, 分布式缓存系统, 海量存储系统,分布式远程调用系统, 分布式消息中间件等一系列淘宝最核心的产品系统.
    2、 为淘宝核心系统提供质量保证, 探索和研究分布式系统的测试和开发方法
    3、 为分布式系统设计和开发高效的自动化测试框架, 测试工具和平台等
    职位要求:
    1、 熟悉至少一种编程语言(C/C++/JAVA/PERL/PHP),具备扎实的计算机系统知识,了解软件开发技术和软件开发流程
    2、 熟悉Linux系统,能够地在Linux环境下进行开发/测试工作,具备对于Linux系统架构和原理的了解更佳
    3、 乐于从事web服务、数据存储、分布式控制、网络通信等技术的研究,能够关注以上方面的最新技术动向,具备良好的快速学习能力和反应能力。
    4、 为人乐观开朗,思维敏捷,善于发现问题,责任心强。具备良好的沟通和合作能力,并且乐于分享。

    资深测试架构师(急招!) 4人
    岗位职位:
    1、设计、开发测试框架,测试平台等;
    2、全面把握产品的功能及非功能需求,定制有效的测试策略;
    3、负责研发特定的测试技术,提高整体测试效率和质量;
    4、规划/设计测试平台,优化产品测试过程;
    5、领导公司测试技术的发展和测试策略的方向, 提高测试团队的技术影响力;
    6、测试领域新技术、方法的研究、应用与推广, 提升淘宝测试的行业影响力。
    职位要求:
    1、计算机相关专业,本科或以上学历;
    2、5年以上工作经验(2年以上开发(java/c/c++)、3年以上测试) ;
    3、精通性能测试、自动化测试、安全测试、白盒测试领域之一;
    4、熟悉开源测试工具以及扩展;
    5、熟悉大型软件架构,熟悉Linux 操作系统和Oracle数据库;
    6、具备丰富的大型复杂系统的测试经验;
    7、有较强的共性技术抽取能力、分析设计能力和方案整合能力;
    8、良好的沟通技能,团队合作能力

    淘宝网 – 性能评测工程师(3-5人)
    职位描述:
    1、 参与淘宝网系统的研发和设计
    2、 参与淘宝网性能评测设计和实施
    2、 开发性能测试自动化和容量规划平台
    3、 探讨和研究性能评测前沿技术

    职位要求:
    1、 3年以上性能测试和性能评估经验
    2、 具有性能解决方案设计和性能调优经验
    3、 熟练使用性能测试工具,如loadrunner、tsung、jmeter
    4、 熟练oracle和mysql数据库操作,熟悉mysql存储引擎和性能分析
    5、 良好驾驭测试环境的能力
    (1)熟练使用linux操作系统,具有shell脚本编写能力
    (2)具有搭建和维护复杂测试环境能力,包括apache,nginx,jboss等web测试环境
    6、 扎实的JAVA/C/C++编程能力,熟悉JVM性能,具有2年以上开发经验者优先

    手机测试开发工程师 2人

    岗位职责:

    手机自动化测试框架的开发
    手机自动化测试工具的开发
    降低手机测试自动化的成本,提高自动化测试的效率
    岗位技能:

    具有手机开发或自动化测试经验
    熟悉C++/java,熟悉objective C/Android开发
    了解其它智能手机开发平台者(Symbian,WindowsMobile等)优先。
    有优秀的学习能力,具有强烈的主观能动性
    优秀的文档编写和语言表达能力,熟练阅读英文文档
    高级Web自动化测试开发工程师 2人

    岗位职责:

    自动化测试框架的开发
    Web自动化测试工具的开发
    提供创新的自动化测试手段
    降低全网回归自动化的成本,提高自动化测试的效率
    岗位技能:

    拥有2年以上的Web开发或自动化测试经验
    熟悉WEB技术,如DOM,HTML/Css,JavaScript
    熟悉JAVA/C++/RUBY,有较强的开发实践经验
    熟悉常用的数据库Oracle/Mysql/SQL
    具有IE插件或FireFox插件开发经验者优先
    具有Eclipse等IDE插件开发经验者优先

    Hadoop测试开发工程师 2人

    岗位职责 :
    1. 对hadoop、hive等相关产品升级进行测试;
    2. 负责整体hadoop集群的高可用性、高性能测试;
    3. 运用Hadoop等相关技术构建云测试平台;

    岗位技能 :
    1. 熟练使用java集合类,IO,并发编程;
    2. 熟悉jvm运行机制及内存管理;

    3. 对分布式原理有较深的理解
    4. 有精读开源框架代码的习惯;
    5. 熟悉Linux/Unix操作系统;
    6. 有优秀的学习能力,具有强烈的主观能动性;

    7 熟悉MapReduce及Hadoop的使用,能解决Hadoop的复杂问题者优先考虑

    高级Web(前端)测试工程师 2人
    岗位职责:

    负责淘宝网前端测试;
    设计前端测试方案及流程,并推广实施;
    提供自动化测试工具和自动化测试框架,帮助测试工程师提供测试效率和质量;
    岗位技能:

    熟悉WEB开发技术,如java, DOM, HTML, Css, JavaScript
    熟悉软件测试,有丰富的自动化测试实施经验
    有良好的沟通能力和快速学习能力
    熟悉前端测试,包括性能测试,熟悉前端测试技术或框架者优先;
    高级测试开发工程师 3人

    工作职责:

    1. 设计开发测试框架或测试管理系统,帮助测试团队利用技术手段把产品测试做得更快更好;

    2. 搜集挖掘测试团队的需求,提供技术解决方案;

    3. 在测试团队中善于创新与分享,为测试团队提供技术支持;

    4. 有过大型系统,分布式系统测试经验者优先

    5. 有过性能测试调优经验者优先

    职位要求:

    1. 热爱计算机事业,掌握1~2门开发语言,具备良好的web应用或自动化测试框架的开发设计能力;

    2. 至少3年软件测试岗位工作经验和2年的开发岗位工作经验,或者4年以上测试开发经验;

    3. 具备丰富的自动化测试框架或者测试管理系统开发经验;

    4. 工作中善于创新,喜欢分享,能够有效解决遇到的问题;

    5. 具备java EE,Ruby on Rails或其他语言开发经验者。

    测试开发专家 (人数不限)

    工作职责:

    1. 设计开发测试框架或测试管理系统,帮助测试团队利用技术手段把产品测试做得更快更好;

    3. 规划测试技术的发展路线并实施

    4. 领导质量部的开发团队开发测试工具和框架平台

    5. 管理测试产品,打造测试工作的标准,扩大测试团队的影响;

    职位要求:

    1. 热爱计算机事业,具备独立领导开发web应用或者自动化测试框架的能力;

    2. 至少3年软件测试岗位工作经验,3年以上开发工作经验;

    3. 了解在测试行业技术动态,有技术革新和贡献;

    4. 设计开发能力熟练,曾经给大规模测试团队设计开发过测试工具和系统平台

    5. 工作中善于创新,喜欢分享,能够有效解决遇到的问题;

    6. 有带领团队工作能力和经验者优先.

    安全工程师:3人
    职位描述:
    1. 负责项目日常发布前的安全测试;
    2. 负责引导和辅助开发人员修复安全问题;
    职位要求:
    1. 熟悉常见的web漏洞类型和原理;
    2. 有网站攻击或者防御经验者优先;
    3. 较强的好奇心,学习能力强,责任心强,沟通能力好;

    招聘联系人:铁花

    简历请发送至: tiehua@taobao.com,邮件主题请注明应聘职位“应聘xx工程师”

    更多职位信息:http://job.taobao.com

     
     
     
     
     
    淘宝正式员工
    请在投递简历时,邮件标题为“[姓名]-应聘-[职位名称]”。职位名称选用下述职位说
    明!!投递信箱为boxin@sillinfo.com

    如有任何疑问可与我联系,以下为具体联系方式:
    TEL: 010-68158195-802      
    MSN:jiabx624@hotmail.com   QQ:1297473617  
    更多职位可参见:http://blog.sina.com.cn/s/articlelist_1878098885_0_1.html
    薪资范围:以下所有职位年薪为12-30W之间及相应期权(不包括架构师及专家)

    职位1:软件测试开发工程师(SDET)
    部门:淘宝-技术研发部-广告技术-测试
    工作地点: 北京/杭州
    招聘人数:若干
    工作职责
    - 参与互联网软件产品的测试,包括参与需求设计评审,设计和执行测试用例,进行缺陷跟踪等
    - 开发和维护自动化测试脚本工具,提升测试的质量和效率
    - 执行软件产品的性能测试并分析结果
    - 可能涉及的工作领域包括广告业务系统,广告投放引擎和算法,淘宝新业务系统,淘宝搜索引擎和匹配排序算法,分布式存储和CDN等核心系统,分布式计算及淘宝海量数据的分析和挖掘等
    职位要求
    - 计算机或其他相关专业本科以上学历
    - 一年以上软件开发、自动化测试或白盒测试工作经验
    - 熟悉基本测试流程和测试方法,掌握基本的性能测试工具、方法、性能指标等
    - 熟悉C/C++或Java编程,有Shell或PHP/Perl/Python/Ruby等使用经验者优先
    - 熟悉Linux/Unix操作系统和Oracle/MySQL数据库基本操作者优先
    - 很强的学习能力,良好的沟通能力,善于团队合作
    - 工作积极主动,执行能力强,善于推进问题解决

    职位2:高级软件测试开发工程师(Senior SDET)
    部门:淘宝-技术研发部-广告技术-测试
    工作地点: 北京/杭州
    招聘人数:25人
    工作职责
    - 参与互联网软件产品测试的全流程,包括参与需求分析、设计评审,制定测试计划并评估风险
    - 独立或带领其他工程师执行项目测试,包括分配测试资源,构建测试环境,设计和执行测试用例,进行缺陷跟踪和软件质量分析等
    - 执行软件产品的性能测试并分析结果,预测系统性能瓶颈,风险和安全隐患
    - 设计和开发自动测试工具和系统,提升测试的质量和效率
    - 在项目中保持和项目经理、产品经理、开发工程师等成员的积极有效沟通,推动问题解决
    - 可能涉及的工作领域包括广告业务系统,广告投放引擎和算法,淘宝新业务系统,淘宝搜索引擎和匹配排序算法,分布式存储和CDN等核心系统,分布式计算及淘宝海量数据的分析和挖掘等
    职位要求
    - 计算机或其他相关专业本科以上学历
    - 至少三年以上软件开发、自动化测试或白盒测试工作经验
    - 精通测试流程和测试方法
    - 精通C/C++/Java等至少一种编程语言,熟悉Shell或PHP/Perl/Python/Ruby等脚本语言优先
    - 很强的学习能力和技术钻研能力,良好的沟通能力,善于团队合作
    - 工作积极主动,执行能力强,努力推进问题解决
    - 有以下工作经验者优先考虑:熟悉Linux或Unix操作系统;熟悉DOM/HTML/CSS/JavaScript等Web技术;精通Oracle/MySQL数据库操作;有大型网络运维经验;有大型项目的自动化测试、性能测试或安全测试经验

    职位3:测试架构师(Test Architect)
    部门:淘宝-技术研发部-广告技术-测试
    工作地点: 北京/杭州
    招聘人数:8人
    工作职责:
    - 按照产品架构和业务要求,制定和推进测试策略,测试计划和测试方法
    - 参与产品需求和架构设计评审,保证产品的可测试性
    - 参与测试效果评估和软件质量核查
    - 通过测试相关流程、策略、方法和工具等创新,努力提升测试的质量和效率
    - 解决测试过程中复杂技术问题
    - 负责测试团队的测试方法和技术培训,领导团队测试技术的发展
    职位要求:
    - 计算机或其他相关专业本科以上学历
    - 至少五年以上软件开发、自动化测试或白盒测试工作经验,有分布式测试,专业的性能测试、安全测试经验者优先
    - 精通C/C++/Java等至少一种编程语言,熟悉Shell或PHP/Perl/Python/Ruby等脚本语言
    - 精通Linux或Unix操作系统
    - 很强的技术前瞻性,了解测试技术的发展,熟悉敏捷开发和测试流程
    - 很强的技术钻研、问题分析和解决能力
    - 熟练的文档、沟通表达和培训技巧

    职位4:高级性能测试工程师(杭州)
    部门:技术研发部-开放平台与新业务-新业务
    岗位描述:
    1、负责系统架构和需求分析、性能方案制定、测试脚本开发与实施;
    2、评估性能测试风险;
    3、搭建、维护性能测试环境、执行性能测试用例;
    4、熟悉性能和压力测试的整体流程、方法,概念明确,思路清晰,具备性能测试需求分析和设计规划能力;
    5、编写和维护各种类型的性能测试方案,如接口,数据库,应用产品的性能测试;
    6、根据测试结果,分析、定位性能瓶颈并推动问题的解决;
    岗位要求:
    1、具有5年以上的开发或测试经验,并有3年以上软件项目性能测试经验,曾经负责过独立的性能、压力测试项目;
    2、至少会使用2种以上性能测试工具,如LoadRunner,Jmeter 等;
    3、熟悉java 开发环境及会运用相关的工具,如eclipse,maven,hudson 等;
    4、熟练运用Linux, windows 等操作系统;
    5、熟悉HTTP, Soap, socket 等通讯协议
    6、熟悉Oracle,MySQL 等数据库的知识及基本操作
    7、工作积极主动,乐于思考,善于总结分享,执行能力强,并具有良好的推动能力,和团队合作精神
    8、有软件开发经验优先
    另:主要关注以下四个方面 1,数据库分析,定义;2,综合的,性能测试工具开发;3,分析性能测试结果,定义问题;4,性能调优
    杭州此职位候选人最好有2年以上java或c++开发经验者

    以下测试职位工作地点为——【杭州】

    手机测试开发工程师  2人
    岗位职责:
    1.手机自动化测试框架的开发
    2.手机自动化测试工具的开发
    3.降低手机测试自动化的成本,提高自动化测试的效率
    岗位技能:
    1.具有手机开发或自动化测试经验
    2.熟悉C++/java,熟悉objective C/Android开发
    3.了解其它智能手机开发平台者(Symbian,WindowsMobile等)优先。
    4.有优秀的学习能力,具有强烈的主观能动性
    5.优秀的文档编写和语言表达能力,熟练阅读英文文档

    高级Web自动化测试开发工程师   2人
    岗位职责:
    1.自动化测试框架的开发
    2.Web自动化测试工具的开发
    3.提供创新的自动化测试手段
    4.降低全网回归自动化的成本,提高自动化测试的效率
    岗位技能:
    1.拥有2年以上的Web开发或自动化测试经验
    2.熟悉WEB技术,如DOM,HTML/Css,JavaScript
    3.熟悉JAVA/C++/RUBY,有较强的开发实践经验
    4.熟悉常用的数据库Oracle/Mysql/SQL
    5.具有IE插件或FireFox插件开发经验者优先
    6.具有Eclipse等IDE插件开发经验者优先

    Hadoop测试开发工程师 2人
    岗位职责 :
    1. 对hadoop、hive等相关产品升级进行测试;
    2. 负责整体hadoop集群的高可用性、高性能测试;
    3. 运用Hadoop等相关技术构建云测试平台;
    岗位技能 :
    1. 熟练使用java集合类,IO,并发编程;
    2. 熟悉jvm运行机制及内存管理
    3. 对分布式原理有较深的理解
    4. 有精读开源框架代码的习惯;
    5. 熟悉Linux/Unix操作系统;
    6. 有优秀的学习能力,具有强烈的主观能动性;
    7  熟悉MapReduce及Hadoop的使用,能解决Hadoop的复杂问题者优先考虑

    高级Web(前端)测试工程师 2人
    岗位职责:
    1.负责淘宝网前端测试;
    2.设计前端测试方案及流程,并推广实施;
    3.提供自动化测试工具和自动化测试框架,帮助测试工程师提供测试效率和质量;
    岗位技能:
    1.熟悉WEB开发技术,如java, DOM, HTML, Css, JavaScript
    2.熟悉软件测试,有丰富的自动化测试实施经验
    3.有良好的沟通能力和快速学习能力
    4.熟悉前端测试,包括性能测试,熟悉前端测试技术或框架者优先;

    高级测试开发工程师   3人
    工作职责:
    1.设计开发测试框架或测试管理系统,帮助测试团队利用技术手段把产品测试做得更快更好;
    2.搜集挖掘测试团队的需求,提供技术解决方案;
    3.在测试团队中善于创新与分享,为测试团队提供技术支持;
    4.有过大型系统,分布式系统测试经验者优先
    5.有过性能测试调优经验者优先
    职位要求:
    1.热爱计算机事业,掌握1~2门开发语言,具备良好的web应用或自动化测试框架的开发设计能力;
    2.至少3年软件测试岗位工作经验和2年的开发岗位工作经验,或者4年以上测试开发经验;
    3.具备丰富的自动化测试框架或者测试管理系统开发经验;
    4.工作中善于创新,喜欢分享,能够有效解决遇到的问题;
    5.具备java EE,Ruby on Rails或其他语言开发经验者。

    测试开发专家(人数不限)
    工作职责:
    1.设计开发测试框架或测试管理系统,帮助测试团队利用技术手段把产品测试做得更快更好;
    3.规划测试技术的发展路线并实施
    4.领导质量部的开发团队开发测试工具和框架平台
    5.管理测试产品,打造测试工作的标准,扩大测试团队的影响;
    职位要求:
    1.热爱计算机事业,具备独立领导开发web应用或者自动化测试框架的能力;
    2.至少3年软件测试岗位工作经验,3年以上开发工作经验;
    3.了解在测试行业技术动态,有技术革新和贡献;
    4.设计开发能力熟练,曾经给大规模测试团队设计开发过测试工具和系统平台
    5.工作中善于创新,喜欢分享,能够有效解决遇到的问题;
    6.有带领团队工作能力和经验者优先.
     
     
     
     
     

  • 编程是测试人员必备的技能-Zee(转载)

    2009-05-21 22:39:39

     

    转自:http://www.51testing.com/?uid-17369-action-viewspace-itemid-91155

    在不断的讨论中到现在,有一些人已经清楚的承认了这一点。

    编程是测试人员必备的技能。
    还记得一年前我写帖子的时候,就说过:编程只是测试人员一种技能。
    而现在还有些人是想逃避编程而选择测试行业,其实这样是不太现实的。不管做哪一类的测试,如果想做好,这是逃不过的一个阶段。就算是你只想处理一个文件,就算你只想写一个简单的小程序发送数据包,也可以提高你对测试的理解。功能测试性能测试都是这样。
    边强老师对我说,你工作时间不长,这一关你是躲不过去的,没有近路可以走。这是每次电话,吃饭,聊天,他必训我的几句话,其实以前,我承认这一观点,但是我一直觉得:不学编程,我照样做好测试。2年10个月18天的经验告诉我,多学一些确实只有好处。并且要尽早的多学一些,而不要等到逼到头上。如果你学的比别人高,你会走的比别人更快,更稳。就在我一直固执的认为不学编程照样做好测试的时候,我还是要在脚本上下功夫。因为那是我天天要遇到的东西。我把那些看做是我必做的事情,仅是为了工作。但是那些脚本的东西,要写的很少,并且称不上为程序。但是,我喜欢那种解决问题的方式。
    而想更进一步做好测试,在这个自己喜欢的行业里,把爱好发挥得淋漓尽致,我还要把自己的日程里加入一个编程的里程。写一个简单的程序给自己测试,是很有意思的事情。可以把很多内容都考虑的清清楚楚的。这几天,一个同事,一直在让我教他用LoadRunner,我建议他自己搭建一个环境,写一个非常简单的应用。自己去测试,分析。遇到问题,我们再一块解决。我觉得这种方式是学习工具最好的方式,并且为以后的更深的理解别人的应用,打下非常好的基础。就性能测试这一块来说,我建议所有想学习的人,自己写一个非常简单的应用,来分析。
    并且,我建议学两种类型的编程,一种就是像C++/java/.net这样的,还有一种是脚本。
    为什么建议学这两种类型的呢?第一种我认为对理解整体的应用非常有利,因为应用很多是用这种的语言来写的。而脚本只是为了达到测试目标。
    不知道现在的测试人员,还有多少认为测试人员不需要编程功底的。如果有的话,还是尽量的改吧。

    非常赞成,好办法,回去可以试一下。谢谢!
    燃灯斋 引用 删除 zengyixun   /   2008-12-18 13:03:08
    其实当测试人员在进行编程时,做的很多事都是初级的,所以才有IBM测试产品与HP LR,QTP等的出现,但其实你想想,开发这些工具的人,他们是测试人员?还是开发人员?对他们来说,只不过是把测试行业(注意行业二字)的事用工具与软件来提高效率,就如同搞财务软件的用工具与软件去提高了财会们的效率是一个道理!财会们会用财会软件是很重要,甚至如果有财会能用VB脚本进行复杂的财会计算就更牛,但财会就是财会,你本身的财会知识才是你一切的本源!
    燃灯斋 引用 删除 zengyixun   /   2008-12-18 12:56:10
    但测试还有另一个方向,正是我们最缺少的,就是业务专家级的测试,比如财务专家对财务系统的测试,管理专家对管理系统的测试,还有多媒体体验测试,可能需要心理学与人文背景的专家,如果是想要把黑盒测试做得很好,除了业务专家的方向,还有统计学,也就是对测试方法的研究方向,这些都不需要编程,编程是测试中功能自动化,性能测试中的脚本,单元白盒测试等这几个方向必须具备的技能,测试不是只有这几个方向,否则开发一定能比你做得更好,何必搞出一个专门的测试行业来!一家之言!
    红色蒲公英的个人空间 引用 删除 Helen_px   /   2008-09-03 15:25:32
    说的很又道理,曾从事过开发,写过一些代码,但是没有坚持下来,每天都感到自己没有进步
    引用 删除 星空   /   2008-09-02 09:24:43
    Zee大侠人气很旺啊,呵呵,抽空出来给大家解答疑难问题吧,期待哦.....
    引用 删除 joeyu22   /   2008-08-29 11:19:43
    我怎么今天才发现呢?看了几篇zee的文章,很是赞同。今天到此为止,以后继续向zee大哥学习。
    不甘心 引用 删除 xuwh   /   2008-08-29 08:47:02
    会听取大家的意见,好好去研究一下程序,一直在学编程,一直没有进展
    carry1986的个人空间 引用 删除 carry1986   /   2008-08-28 15:02:57
    我也赞同Zee的看法,只就知道编程对测试也很重要,现在很多企业也都在招会编辑的测试人员,还有一些工具,现在学脚本真的有点困难,感觉没有什么环境,但这个东西要自己去搞,应该是逼自己去学习呀,这东西没有人会让你学习了,现在不学习,不知道还有多时间学习,人生是很短的..
    引用 删除 星空   /   2008-08-28 11:36:48
    5
    楼主说的我很赞成,我也很想学编程,但是现在做的是黑盒,根本接触不到代码。以前在学校学过C/C++/Java,但是没做过什么大点项目,现在好多都忘了。但是在学校没学过脚本语言。现在真不知道该怎么学。希望各位高手给点建议,先谢过啦!!!
    引用 删除 xiaoyaoke   /   2008-08-28 10:16:01
    我导师对我说的最多的一句话:大家都是做IT的,不分研发和测试。操作系统、数据库、编程语言(高级+脚本)、应用服务、网络等都是做IT的基础,都是必须在一定程度上掌握的...汗
    春天是花儿的季节 引用 删除 江南飞雪   /   2008-08-26 16:43:07
    说的很好,我也一直想学,可有些人一直说重要的是测试技巧,不过我是在自己一有能力有时间的情况下就去学习
    引用 删除 ipopo   /   2008-08-26 15:17:59
    sorry,提交误操作,请博主删除其多余的一条,以提高阅读性,辛苦~

    呵呵,还有一条,英语也很重要,不光是针对测试来说的;
    引用 删除 ipopo   /   2008-08-26 15:16:05
    测试人员不光要具备开发技术的,还有测试技术,这条是测试人员的看家本领,不应该被大家遗忘的;
    其实,还有很多的方面是作为合格的测试人员要具备的,做一个合格的测试人员其实很不简单!~
    引用 删除 ipopo   /   2008-08-26 15:16:05
    测试人员不光要具备开发技术的,还有测试技术,这条是测试人员的看家本领,不应该被大家遗忘的;
    其实,还有很多的方面是作为合格的测试人员要具备的,做一个合格的测试人员其实很不简单!~
    学会洒脱的个人空间 引用 删除 学会洒脱   /   2008-08-26 14:15:27
    赞同
    chenyunjun169的个人空间 引用 删除 chenyunjun169   /   2008-08-26 09:55:57
    我非常赞同Zee的看法,如果总是做不需要编程的黑盒测试,时间长了是提不高的。

     
  • 测试培训引发的感想-Zee(转载)

    2009-05-21 22:03:15

    如果不把已知的东西放出去,我就会固步自封。----Zee

    转自:http://www.51testing.com/?uid-17369-action-viewspace-itemid-102117

     

    原文:http://www.7dtest.com/archives/1714

         病初愈,最近做了几次培训,性能测试和测试工具。现在自己弄了一个论坛也把很多的心思放到性能测试上,个人喜好所在。

         在这几培训和最近别人问的问题中,感觉到有这么几件事情:

    1.        有些人很想接触性能测试,但是一到具体的细节,兴趣索然。不管是工具的操作,还是理论的理解。要说我讲课能力有限,可以把人讲的没有兴趣,这是我个人问题。这个因素在实际的操作中,总不会有吧。实际的操作还是有些人觉得没什么意义。有的人就像是见了刺猬,不知道从哪下口。要说工具有多麻烦,我觉得也不至于。至少LoadRunner比word简单多了。我曾经说:一周时间完全可以掌握LoadRunner的操作,其他的就要看练习和经验了。这么说,是不是有经验的过来人,感觉对?当然人不可能都一样的。我想强调的就是工具并不复杂。复杂的是应用。

    2.        理论对性能测试的指导作用容易被忽视。很多时候,技术人在考虑问题的时候,都是技术细节,觉得只要是理论都挺无聊的。大而泛,忽悠人用的。从我自己的感受来说,我觉得完全不是这样。当然对某个词的定义这样的理论问题,我们用不着太细究。但是性能测试理论,真的对我们的实际工作没有指导意义吗?或者说意义不大?比如,在讨论基准测试的时候,很多人都知道基准测试是什么意思?但是很少有人能把基准测试的范围和程度说清楚。应该测试什么?做到什么程度?这些仅是技术问题吗?在相应的位置上的测试人员,有没有考虑过你的职位能做或不能做什么事?能做到或做不到什么事情?应该做或不应该做什么事情?这些都会对项目的质量产生影响的。

    3.        面对性能测试过程、结果、数据,真的理解清楚了吗?针对同一个数据和过程不同的人感觉到的层面是不一样的。这就是经验和能力的区别,就算是两个人做的结果完全一样,我想由于能力不同,也会这一结果的理解不同。在多次培训的过程中,我解释最大、最小、平均、标准方差等值的时候,都会有人有醒悟的样子。我们说为什么这几个值,重要到放在summary里面,为什么不是中位数?为什么不取个微分放那儿?其实,这都是有设计上的原因的。所以说,我们面对这些东西的时候,要知道它具体的含义,从而把握的更清楚。也对我们做的事情更确定。不会经常出现别人问几句就问倒了的现象。

    写这个文章就是想告诉大家:
    1.        技术是一步步积累的;
    2.        理解自己做的事情。


    希望看这篇文章的人,09年牛气冲天。

     

    原来我写的一个LR面试题-Zee

     

    1,EBCDIC translation有什么用?

    2,编译器和解释器有什么区别?

    3,需要关联的数据怎么确定?

    4,LR的协议包分为多少类?

    5,树视图和脚本视图各有什么优点?

    6,LR中的API分为几类?

    7,action和init、end除了迭代的区别还有其他吗?

    8,HTTP的超时有哪三种?

    9,在什么地方设置HTTP页面filter?

    10,pot mapping的原理是什么?

    11,如何设置可以让一个虚拟IP对应到一个Vuser?

    12,什么是contentcheck?如何来用?

    13,network中的speed simulation是模拟的什么带宽?

    14,进程和线程有什么区别?

    15,生成WEB性能图有什么意义?大概描述即可。

    16,如果刷新controller里的脚本?

    17,WAN emulation是模拟什么的?

    18,如何把脚本和结果放到load generator的机器上?

    19,如何设置才能让集合点只对一半的用户生效?

    20,在设置windows资源图监控的时候,用到的是什么端口和协议?在这一过程中,会有大概哪些问题?(大概描述)

     

    对一个确定的产品的性能测试要求

     

    对一个确定的产品来说性能测试的要求如下:

    1,产品通信模型;
    2,要测试的系统通信协议;
    3,网络架构;
    4,统计信息;
    5,复杂信息的图例;
    6,应用分析;
    7,系统监控和管理;
    8,功能;
    9,业务分析;
    10,人为因素分析;
    11,系统的开发语言;
    12,数据库设计和管理;

    这上面列到的也已经超出了很多人的个人能力范围。所以我觉得这样要求一个人的话,也是非常不理智.
    如果一个团队拥有这样的能力,就可以了.

     

     

    LoadRunner中Regenerate Script功能的使用-Zee

     

    如果你想回到原始录制的脚本,可以使用Regenerate scrīpt功能.这个功能对调试和修复一个已经损坏的脚本是非常有用的.regenerator一个脚本时,它会移除所有手工加入到脚本中的内容.如果你添加参数到脚本中,VuGen保存录制时的参数,用参数列表来替换后,原有的参数并不会被删除.你可以重新插入原来建立的参数列表.

    注意在使用这个功能时,只会整理录制的脚本,不会整理手工加入的脚本.

    点击Regenerate scrīpt之后,有几个按钮可用:

    第一个:OK

    从原始的录制日志中重新生成脚本.此功能将移除所有在脚本中手工加入的关联/参数化代码.

    第二个:Options

    当使用多协议时,可以指定哪些协议需要重新生成,如果需要自定义重新生成的选项,可以点击Options打开录制选项.选择协议,并指定哪些协议要重新生成哪些不需要.

    例子:

    这里,我录制了一个页面,

            web_url("zeeslo",

                      "URL=http://blog.csdn.net/zeeslo",

                      "Resource=0",

                      "RecContentType=text/html",

                      "Referer=",

                      "Snapshot=t2.inf",

                      "Mode=HTML",

                      EXTRARES,

                      "Url=http://hi.images.csdn.net/css/Valentine/images/header_bg.gif", ENDITEM,

                      "Url=http://www.csdn.net/images/share-add.gif", ENDITEM,

                      "Url=http://counter.csdn.net/pv.aspx?id=26", ENDITEM,   

                      LAST);

     

    加入事务和参数:

     

            lr_start_transaction("事务一");

     

            web_url("zeeslo",

                      "URL=http://blog.csdn.net/zeeslo",

                      "Resource=0",

                      "RecContentType=text/html",

                      "Referer=",

                      "Snapshot=t2.inf",

                      "Mode=HTML",

                      EXTRARES,

                      "Url=http://hi.images.csdn.net/css/Valentine/images/header_bg.gif", ENDITEM,

                      "Url=http://www.csdn.net/images/share-add.gif", ENDITEM,

                      "Url=http://counter.csdn.net/pv.aspx?id={参数}", ENDITEM,     

                      LAST);

     

     

            lr_end_transaction("事务一", LR_AUTO);

    当使用Regenerate scrīpt功能之后:

            web_url("zeeslo",

                      "URL=http://blog.csdn.net/zeeslo",

                      "Resource=0",

                      "RecContentType=text/html",

                      "Referer=",

                      "Snapshot=t2.inf",

                      "Mode=HTML",

                      EXTRARES,

                      "Url=http://hi.images.csdn.net/css/Valentine/images/header_bg.gif", ENDITEM,

                      "Url=http://www.csdn.net/images/share-add.gif", ENDITEM,

                      "Url=http://counter.csdn.net/pv.aspx?id=26", ENDITEM,   

                      LAST);

    我们看到,使用了Regenerate scrīpt之后,脚本回到刚录制后的状态.

     

     

    其他:

    VC中多线程使用

    http://www.51testing.com/?uid-17369-action-viewspace-itemid-89315

     

    MSDN中的C/S代码实例--Socket

    增进测试初学者对代码的理解,这里我添加了客户端从文本读字符的功能:
    有兴趣的可以添加自己想要的功能看看,比如,实现多线程等等。


    Server:
    // Server.cpp : Defines the entry point for the console application.
    #include "stdafx.h"
    #include <stdio.h>
    #include "winsock2.h"
    #pragma comment(lib, "WS2_32.LIB")


    void main() {
        // Initialize Winsock.
        WSADATA wsaData;
        int iResult = WSAStartup( MAKEWORD(2,2), &wsaData );
        if ( iResult != NO_ERROR )
            printf("Error at WSAStartup()\n");
        // Create a socket.
        SOCKET m_socket;
        m_socket = socket( AF_INET, SOCK_STREAM, IPPROTO_TCP );
        if ( m_socket == INVALID_SOCKET ) {
            printf( "Error at socket(): %ld\n", WSAGetLastError() );
            WSACleanup();
            return;
        }
        // Bind the socket.
        sockaddr_in service;
        service.sin_family = AF_INET;
        service.sin_addr.s_addr = inet_addr( "127.0.0.1" );
        service.sin_port = htons( 27015 );
        if ( bind( m_socket, (SOCKADDR*) &service, sizeof(service) ) == SOCKET_ERROR ) {
            printf( "bind() failed.\n" );
            closesocket(m_socket);
            return;
        }
       
        // Listen on the socket.
        if ( listen( m_socket, 1 ) == SOCKET_ERROR )
            printf( "Error listening on socket.\n");
        // Accept connections.
        SOCKET AcceptSocket;
        printf( "Waiting for a client to connect...\n" );
        while (1) {
            AcceptSocket = SOCKET_ERROR;
            while ( AcceptSocket == SOCKET_ERROR ) {
                AcceptSocket = accept( m_socket, NULL, NULL );
            }
            printf( "Client Connected.\n");
            m_socket = AcceptSocket;
            break;
        }
       
        // Send and receive data.
        int bytesSent;
        int bytesRecv = SOCKET_ERROR;
        char sendbuf[32] = "Server: Sending Data.";
        char recvbuf[32] = "";
       
        bytesRecv = recv( m_socket, recvbuf, 32, 0 );
        printf( "Bytes Recv: %ld\n", bytesRecv );
       
        bytesSent = send( m_socket, sendbuf, strlen(sendbuf), 0 );
        printf( "Bytes Sent: %ld\n", bytesSent );
        return;
    }
     
    Client:
     
    // client.cpp : Defines the entry point for the console application.
    //
    #include "stdafx.h"
    #include <stdio.h>
    #include "winsock2.h"
    #pragma comment(lib, "WS2_32.LIB")
    #include <stdlib.h>

    void main() {
        // Initialize Winsock.
        WSADATA wsaData;
        int iResult = WSAStartup( MAKEWORD(2,2), &wsaData );
        if ( iResult != NO_ERROR )
            printf("Error at WSAStartup()\n");
        // Create a socket.
        SOCKET m_socket;
        m_socket = socket( AF_INET, SOCK_STREAM, IPPROTO_TCP );
        if ( m_socket == INVALID_SOCKET ) {
            printf( "Error at socket(): %ld\n", WSAGetLastError() );
            WSACleanup();
            return;
        }
        // Connect to a server.
        sockaddr_in clientService;
        clientService.sin_family = AF_INET;
        clientService.sin_addr.s_addr = inet_addr( "127.0.0.1" );
        clientService.sin_port = htons( 27015 );
        if ( connect( m_socket, (SOCKADDR*) &clientService, sizeof(clientService) ) == SOCKET_ERROR) {
            printf( "Failed to connect.\n" );
            WSACleanup();
            return;
        }
        // Send and receive data.
        int bytesSent;
        int bytesRecv = SOCKET_ERROR;
        char sendbuf[32] = "";
        char recvbuf[32] = "";
     

     
     FILE *stream;
     int RNumber;
     if( (stream = fopen( "test.txt", "r" )) == NULL ) // C4996
      // Note: _wfopen is deprecated; consider using _wfopen_s instead
      {
       printf("fopen failed!\n");
       return;
      }
        if( ( RNumber = fread( sendbuf, sizeof( char ), 25, stream )) == 0)
     {
      printf("fread 0 character!\n");
      return;
     }
       
     bytesSent = send( m_socket, sendbuf, strlen(sendbuf), 0 );
        printf( "Bytes Sent: %ld\n", bytesSent );
        while( bytesRecv == SOCKET_ERROR ) {
            bytesRecv = recv( m_socket, recvbuf, 32, 0 );
            if ( bytesRecv == 0 || bytesRecv == WSAECONNRESET ) {
                printf( "Connection Closed.\n");
                break;
            }
            if (bytesRecv < 0)
                return;
      printf("Recv chartaacter:%s\n", recvbuf );
            printf( "Bytes Recv: %ld\n", bytesRecv );
        }
        return;
    }
     


     

     

     

     

     

  • 虚假的测试繁荣--Zee(转载)

    2009-05-21 21:44:38

     

    转自:http://www.51testing.com/action/viewspace/itemid/129964.html

    转载请注明原文出处:

    原文请见:


    http://www.7dtest.com/bbs/thread-1952-1-1.html
    测试7刊-7点测试论坛出品-第六期

    有几个文章大概的题目如:
    软件测试行业缺口多少多少万、
    软件测试人员比博士还值钱、
    软件测试越老越吃香、
    软件测试是金饭碗、

    等等等等。

    以下是我的一些个人看法。

    1.        行业
    我们都知道媒体的报到都是因为一些利益驱动的,并不是为了良心和行业的良性发展,要是从工作的角度来说,我觉得他们很到位,但是少了一点,就是社会责任心。做为一个有良知的知识分子,我觉得应该说点事实,不要把一个本来挺好的行业最后糟蹋的不像样子。做为一个软件测试从业人员(我从一毕业就开始做软件测试),我觉得这些都不靠谱。
    在我的记忆中,跟测试同行聊天时,软件测试行业的缺口是一个所谓的牛人被媒体采访时问到的。但是这个牛人,自己也没有做过统计,于是乎,两眼一转,把心一横,在我不知道别人也不可能知道的心态下说出了这么一个数据:大概30万吧。实际上,这个数据没有经过任何公开的媒体调查(如果调查了后,就是这个数据,我觉得还有点借鉴意义)。结果就被一些写手们越扯越大。反正写错了,也没人打屁股,要写就要引人眼球,可劲的造吧。这种鼓吹的结果就是让一群人很盲目的进入了这个行业,结果发现根本不是那么一回事。于是经常看到有人问,我什么什么经历,转测试行不行呀?就有些人很不负责任的回答:只要努力,就行!我靠,也不想想,人家那么多年的其他行业的经验,为什么还要转测试呀?工资也不见得就高(这个问题稍后细说),也不见得轻松,上升空间也不见得有原来的行业多,干吗要鼓励人家换这个行业呀?(排除有些人骨子里就喜欢测试这个行业的。另:大部分人工作还是工作,并不是当成事业来做的,所以谈不上对哪个行业有非常深的兴趣)。
    所以在选择这个行业的时候,还是需要理智的思考的,曾经有一个朋友,工作大概四五年了,做过:网管、保安、保险推销等等的工作,技术基本没有积累。问我:我能不能转行做测试?我问了他一些基本的计算机知识和测试的基本知识,我说:你还是别转了,不如做点其他的事情。不过我也说了,我只是提个你不要转的建议,你要是非想转,我也可以告诉你要学什么。在很多情况下,我觉得更理性的思考才说出建议和决定比较合理,不要以为有了一份心就什么都有了,两码事。因为人的激情是有时间间隔的。
    测试人员的素质要求。可能是因为我进入了这个行业,老是有人在说这个行业的人需要什么样的技术和素质。大多数的都会提到一个字眼:浮躁。就是测试人员切忌浮躁。我晕,什么人不忌浮躁呀?这是对人的基本素质要求,而不是对测试行业的人的素质要求。可能有人说了,测试嘛,要细心,浮躁了就不能细心了。这种说法貌似合理了。但是,这绝不是测试人员的核心要求。极端一些说(因为极端的假设可以让问题更清晰),如果一个人只有细心,你是测试招聘人员,你会招吗?那这里就涉及到另一个问题了:就是要有技术。什么是技术呢?测试行业什么是技术呢?突然有这个问题似乎让人不知道怎么回答,有一种满肚子都是话突然之间倒不出来的感觉。于是,冷静一会,这种喜欢吹嘘的人就会摆出一堆话来:测试理论呀、测试方法呀、测试工具呀、测试流程呀等等等不都是技术吗?在我有限的知识体系里,个人觉得,这些都不是技术,只是测试人员应该有的常识。测试工具的使用只是测试人员应该掌握的技巧。

    2.        薪水
    薪水的诱惑。我看到过很多次说软件测试行业薪水如何如何高?XX出来不是八千就是五千的。还有人说,软件测试行业是IT中最高薪的行业,越老越值钱!我个人觉得软件测试行业绝对不是常青树。也不可能越老越值钱。现在做软件测试,找工作的人,一堆一堆的。好好看看这个市场,它不是缺少要做软件测试的人,而是缺少有经验的人。并且一般的经验,也不值什么钱。工作三四年(甚至更多)的人,5-6千的人,大有人在,而不是像有些广告上说的,这个行业进来就是万儿八千的。以为是找BUG是捡钱玩呀?我遇到的做测试的,工作十年左右的,也不过是在万元左右。人家这么多年都是白混的呀?在软件测试行业,从纯技术的角度来说:能拿到2万/月的人,很少很少。(请不要以某个个例来反驳,因为个例没有意义)。有些人挤破的头皮进外企。从大局来看(仅个人观点),外企在国内就没有真正把技术拿进来过(这里应该说大部分,不能一棍子全打了),所做的也无非是些边边角角的苦力活。所以外包才有市场,才会发展起来。几乎我认识的所有的测试行业的人都说外包没有技术含量,国内的外企难道不像外包吗?只是形式不同罢了。就拿中国的某些制造业来说,也有一部分属于这种状况,结果金融风暴来了,人家倒了,你也倒了。曾经有不止两个在软件业混了十几年的人跟我说:中国没有什么技术(我知道这句话有失偏颇,但它反应了一些现状)。再回到软件测试这个行业,首先,我认为刚毕业的大学生,不要指望一下子能爬多高。走的不稳总有一天摔倒。如果家里特有钱,像我一华为的同学跟我说的,那里有开着奔驰去上班的,一个月拿几千块钱的。人家那是自我实现追求。而我们大部分的人,还是老老实实的,想想这一生应该怎么过,才能买得起房子,买得起个二十万以下的车吧。软件测试从业人员,自己把自己一辈子能赚的钱都算算。你这一辈子的闲钱能达到十万吗?你敢乱花乱玩吗?你没有先消费后还贷吗?这是时尚,还是不得已而为之?是你的能力不足,还是这个行业已经限制了你的上限?就算是你到了级别,有多少人可以到副总?有多少人是技术总监?就算你是技术总监,又有多少公司的技术总监一年超过30W?我出来工作两三年之后,就有人说,我的工资涨的飞快。我个人在想,这些钱,还不够我的生活。因为我也要买房,买车,生儿育女,赡养老人。有没有想过这些事情,如果全压在你和你老婆(老公)身上的时候,多少的薪水够用的?有人也说了,有钱就过有钱人的生活,没钱就过没钱人的生活,反正过穷富不是一样过吗?一辈子很快就过去了。这种说法是无奈还是满足现状?说的时候心酸吗?看着自己的孩子和别人的孩子上的不一样的学校。玩的游戏没有人家玩的好,你什么感觉?就告诉自己,我的能力只能是这样了吗?选择一个行业,你就要知道,这个行业的薪水段在什么样的层次,就像一个同事跟我说的:一个片警拿一个包出去赌钱,里面都是几百万的人民币。你是不是遗憾自己选错了行呢?当然不能这样对比对吧。因为我们靠自己的能力,吃自己的饭。呵呵,这么对比一下就是要看这个文章的人想清楚,你想拿多少工资?这个行业能给你的只有这么多,你自己选择去吧。当然,也要看清楚的是,这个行业,比出去在大太阳下搬砖强多了。
    好吧,薪水暂时靠一段落。

    3.        技术
    技术,真实认真做软件测试的人应该有这样一种感觉。软件测试不容易做。它需要的知识太多了。如果仅玩数据库,只要把oracle搞的特别精通,我想一年工资二十万应该没有什么问题吧。但是软件测试行业是你要把好几种工具和语言都玩精通可能才值那么多钱。就拿性能测试来说吧(因为这一块是我一直做的,拿来打比方应该偏差不会太大),你只会性能测试工具就敢出去要万元/月以上的工资了吗?你敢要,谁愿意给呀?别以为自己可以是根葱了,其实还没发芽。我们都知道,在软件测试行业的JD一般都是:OS/network/DB/tools/applications /middleware、还有一些语言呀,脚本(脚本也是一种语言这里分开一下)呀,都包括的,就算不全包括,也要有一部分。你得懂呀?不懂全部,你得懂几个吧?你不懂,有人懂呀。那工作机会不就没了吗?怎么办呢?学吧。每天晚上搞到一两点,死劲的玩这些东西,大概找工作的时候,可以跟人侃了。我这个也会了那个也会了。但是呢,不能问深。因为学的广嘛。所以哪有时间细细的琢磨呢。所以问深了就晕了。人家一看,唉,这个人不求甚解,算了吧。也许很巧合,面试了一家公司,人家问的,也都被你忽悠上来了。总算找一工作。也是刷了好多人的。要是能把上面所说的每个东西,都玩了个精通,那出去找工作,问什么会什么,太牛B了。但是公司毛了,这样的人,我们能养得起吗?这种情况很少出现,我们就不去说它了。还要说软件测试行业。其实我们也知道,软件测试行业,在要求广泛的同时,也开始慢慢细化。越来越强调专向发展的人。所以,在进入这个行业的人,不要指望能把所有的公司JD都拿得下来,你只需要考虑是不是能满足其中一两种就可以了。并且仅这一两种也大概够你玩个十多二十年的。到那时,你已经不值钱了,因为还有一堆堆的年轻人在嗷嗷的叫着找这类的工作。国内工作到四十岁的技术人员,还有纯干技术的吗?(当然是有的,这里我说的是大部分情况下)我也有纯技术做了一二十年的同事,他自己也说他这种现象不正常。(这个和国家的福利待遇等都有关系,我这里不再展开说了。)

    4.        追逐

    追逐,如果从现在的大学生失业率来看的话,进入这个尚末成熟的软件测试行业,不见得是件坏事,因为乱世出英雄嘛。当然,在出英雄的前提下,就会有些怀才不遇的人很快的被糊里糊涂地砍倒在战场上。所以进入这个战场,就做好看清流弹的准备。不要报怨,认真的走好自己的路,不要和别人对比,因为不成熟的市场是没有什么可比性的。技术路线和泡沫市场的路线差距还是很大的。当然IT的技术路线和传统工业的技术路线差距也是很大的。我们基本上也算是产业工人的一部分,但是,我们并不是越老越值钱,如果不尽快在自己老到被人推倒在沙滩上之前赶紧找到自己的位置,相信在自己没有可利用的价值之后,很快就被淘汰。一个人被利用并不悲哀,悲哀的是没有可利用的价值。从比较职场的语言来说,我们之所以有工作,是因为老板们或者领导们认为我们还可用,想拿的工资更多,就让领导们觉得我们还有更多可用的地方。所以,尽量的去追逐那些在市场上看来有价值的知识,从而让自己的打工路,更平坦。(如果不想打工的话,那就追逐当老板应该有的知识。)不过,要注意这条路上,重点要知道自己追逐的是什么,而不是随大潮,看着别人玩什么自己也玩什么。很快那些大众型的知识都不值钱了(IT的更新也是很快的),所以要找准自己的位置。

    谨以此文,描述个人对测试行业的看法。如果打击到某些人或某类人,请见谅。

  • 最近和微软一哥们聊微软的测试,很有感触,记下来,和大家共同分享。(此文为转载)

    2009-05-21 01:37:50

    (此文为转载,出处查不到了)

    全文如下:

    开头语:

    作测试很久了,一直为一些问题所困扰,也一直对微软有一种顶礼膜拜的向往,终于有一天,近距离的接触了微软的测试,感觉不是以前想象中那么遥不可及,却又难以企及。于是把个人觉得微软值得借鉴的地方整理了一下,希望能对大家有所帮助。

     

    1.  测试流程

    首先说说测试流程,微软的测试流程也没什么新的东西,和大多数的测试流程一样。

    大致是先进行测试准备,然后是Testcase的编写,然后是白盒测试(不一定每个项目都有),然后是功能测试阶段,然后是验收测试,最终release

    如果看流程的话,和一般公司大同小异,没什么新花样。但是我觉得值得借鉴的是两点。

    第一,   微软的流程执行的非常认真。

    这点非常值得提倡,我们都知道,测试的最终质量决定于测试流程和测试人员素质,要想测试质量有保证,要么是流程很完善,要么你流程不行,但是个人能力超强。如果有一个很好的流程,就算执行的人稍微差点,最终的质量也不会差到哪里去。所以流程是很重要的。

    但是,看国内的公司欠缺的就是这个,要么是没有流程,要么流程是个花架子,没认真执行过。我想微软的测试人都是超级牛人,但是人家还是老老实实的忠实按照流程来走,我觉得这点非常好。(在IBM 也是这样,笔者以前在IBM作项目的时候,发现他们的文档写的特认真,流程特认真),所以说忠实的执行一个好的流程是成功的一大半。

    第二,   在整个流程中,微软非常强调测试尽早介入。微软在这方面是一致提倡的,按照我们国内IT业的恶习,一般都是软件主体差不多成型了,拉几个测试人员过来点点,其实这是非常不好的。微软的测试人员在项目一开始就和开发人员同步介入,在需求阶段就开始介入,进行需求评审。在开发人员开始编码的时候,测试人员就开始编写Test case,并开发一些测试工具,或者写一些配套的测试代码(不要奇怪,微软的测试人员都能写很好的代码)。微软的理念就是:预防bug比解决bug好,所以非常提倡测试尽早介入,把一部分bug消灭在需求阶段。

    2.  自动化流程

    说到自动化,大家可能以为我是说微软的自动化测试工具多牛,其实微软内部用到的自动化测试工具倒是不多,就算有也都是内部开发的,非常实用的,他们不会去用MI的工具。

            说微软的自动化程度高,主要是体现在流程方面,譬如说整个自动

        构建流程,在开发人       员代码check in之后,系统自动发邮件,邮

        件内容就是一个change list,包括代码更新list以及一个编译者添加的comment,其内容是该版本功能的变化或者修改掉的bug ID。整个测试过程中能用自动化的地方都尽可能采用自动化,尽可能减少人为失误,并且可

        以使人和机器并行工作。个人觉得,这点很值得我们国内的测试公司借鉴,能自动化的流程都自动化,减少一些不必要的沟通。

     

    3.  质量控制机制

    说到质量控制是个大问题,需要整个团队和流程提高素质。那么微软的质量控制可以借鉴的是什么呢?是他们的机制。在微软的测试流程当中,在开发的早期,项目中所有的问题都是Dev leaderPM商量说了算(当然也要参考需求方的意见),但是到后期,具体就是功能测试之后,项目的主动权都在测试这边,某个bug的要不要解决,或者项目进度控制都是测试leader说了算。这和国内的大多数软件公司是不一样的,在微软,测试人员要对最终的软件质量负责任,但是也有相应的权利来约束开发人员。当然,他们也肯定有一些bug是产生争议的,这个时候的仲裁机制就是PM,这个不是我们传统的PMProject manager),而是一种具有微软特色的PM(全称是Program manager)。这样,测试人员在对一些争议bug的处理上有相当的话语权。

     

    4.  测试用例及管理

    微软的测试用例倒没什么特别的,不过看过他们用例之后,还是觉得写的详细,认真,但是又不冗长拖沓,这个需要很高深的水平。另外,微软的测试用例管理用的是微软自己开发的用例管理工具。

    另外值得说明的是,微软的每个用例都进行了分级,并且功能所在的模块都标的很清楚。

     

    5.  效率

    在效率方面,微软的测试效率非常高!高的让人惊叹,我问一个在微软工作的哥们,“你们那边测试的最大特点是什么”,他说“最大特点是快!”,就是效率很高,具体就是在测试后期过程中测试和开发之间的反馈非常快,开发修改一定量的bug,提交一个新的版本。测试人员往往能在很快的时间内把测试结果反馈出来,一般是在1天之内就能把用例快速run一遍,这样就能减少某些后期才发现bug导致的项目delay。在国内很多项目的通病是,开发解决问题带进一个新问题,测试人员整个遍历一遍用例之后才能发现,这样来回反复就消耗了大量的时间。

    但微软是如何才能实现快速反馈呢?

    第一,   测试人员对程序的了解,微软的测试人员对程序内部结构都非常熟悉,修改某一个地方,可能引起什么问题,哪些用例需要重新测试,测试人员非常清楚,能快速的执行最可能出错的地方。如果某些模块不熟悉,那么他们会和开发人员在一起沟通这次修改可能引起的问题。

    第二,   工具!还是工具,在微软的测试中,测试人员用各种工具帮助测试,提高测试效率是占到很大的比重。

    第三,   时间意识。微软的测试人员有强烈的时间意识。

     

    6.  测试工具

    测试工具能很大程度上提高测试效率,这个作为测试人员都很清楚。当然测试工具在微软的测试中也应用非常广泛,但是请注意,微软并不是像我们国内的公司一样使用的都是LRQTP这类的录制回放工具,反而这种工具倒是用的不多,就跟微软不屑CMM一样,可能是不想屈尊自己IT老大的身份吧。

    但是微软的测试工具最大的特点是实用。他们用的测试工具都是确实能提高效率,确实能办事情的工具,都不是类似WRQTP的很大很系统的工具,而是比较小的,很灵活,实用的小工具(譬如:FiddlerDriphttpwatchIE DevToolBarPaintNotNetprocexp etc.)。甚至有一些测试工具是测试人员在开发人员协助下根据项目需要临时开发的,不过大多数工具都是微软内部已经共享出来的,在微软内部各种各样的小工具特别多。

    总体给我的感觉是,不是为了用测试工具而用,而是根据实际的需要,确实能提高效率而用到,在用的过程中确实也很大的提高了效率。

     

    7.  测试人员的专业素质

    微软测试给我印象最深刻的还有他们测试人员的专业水准,在测试过程中,测试人员在一些技术上并不逊色于开发人员,在一些bug的处理上,能提出很多合理的很有建设性的建议。

     

    8.  微软的白盒测试

    微软的白盒测试怎么执行呢?让我略微有点吃惊的是,微软的一半测试人员基本不做白盒测试,除非有些不能做黑盒的模块,另外也不是所有的产品都作白盒测试。

    微软的白盒测试一般还是由专门的白盒测试人员来做,但是开发人员要对测试人员的白盒测试代码进行Review,另外微软对开发人员的代码,效率也都有一套详细的考核机制,所以开发人员对自己的代码也是非常负责任的,都进行很认真的进行测试。

     

    9.  意识(时间,质量)

    另外微软的测试还有很好的一点就是意识,时间和质量的意识都是非常强。在控制时间成本上,意识非常强,这点非常值得我们国内同仁学习,另外,风险管理的机制和意识都是非常好。在微软,项目组的每个成员都被明确告知,如果这个项目每delay一天,就会损失多少个million的美元,所以整个项目组都有比较好的时间意识。

    另外,在微软,项目组人员的质量意识都是比较强的。怎么样更好服务用户,让用户体验更好,怎么样更好的改进,这种意识比较强。

     

    10. 微软的培训

    在微软内部,员工外训的机会比较少,大多都是内部互训,各人培训自己的强项,有比较好的互相分享的习惯。另外微软的内部有非常丰富的各种培训文档。以后我会上传上去和大家分享。

     

    11 测试数据记录

    微软的测试数据记录是非常全的,也都是系统自动的,每天都是由系统自动统计当天的bug情况,然后发送一个report到每个项目组成员的邮箱里。最后到测试总结的时候,这些测试数据将变得非常有用。

    编后感:在深入了解微软的测试之前,对微软这个IT业界巨无霸的测试感觉是顶礼膜拜,高不可攀,总觉得可能很神秘,用很牛的技术或者很高深的手段。深入了解之后,发现微软的测试也是和我们做一样的事情,只不过人家做的更认真,更细,更实用,更有效率。再回过头来看时,微软的测试给我留下印象最多的是,流程,效率,意识,工具,素质!也就是这几项,成为我们国内IT企业亟需跨越的。

  • 看看阿里巴巴牛P如何不断自我提升

    2009-05-20 23:22:55

     

    偶看到刊物上一些专业领域非常出类拔萃的技术人员的提升秘诀,冲动分享。版权归阿里巴巴。

    A 学习不分场合和时间,随时可以获取知识,比如网络、电视、书籍、同事、客户,甚至竞争对手。
    学习不能靠一时热情冲动,需要长期积累。平时的学习大多零碎、不系统,还需要整理、盘活现有知识

    B 在成功和失败中获取经验

    C 以个人兴趣为出发点,理论与实践相结合,并做到循序渐进

    D 在网上尝试引导别人解决问题,解决大量别人碰到的问题,让自己掌握的知识更加全面、深刻

    E 订阅大量RSS获取有价值的技术信息,写网志,认识技术圈子朋友,互通有无

    F 坚持和兴趣是关键。学习与自我提升是一个漫长的过程,经常长久在黑暗中徘徊,然后突然有阳光普

    照的一刻。将学习融入每天的工作与生活中,每一个项目都是很好的学习机会,都可以设法超越原先做

    事的定式,去学习并运用一些新的知识与方法。当学习感觉迷茫时,找同事交流讨论,常有豁然开朗的

    感觉。

    G 多思考问题,在工作中碰到的问题,去想想有无更好方法解决它,来提高自己

    H 多读,多观察,多思考

     

    面对棘手问题如何向老板汇报工作

     

    在日常工作当中,某一个难题面临几种选择技术方案,每一种方案都没有绝对的优势胜出,这个时候如何请示老板拍板?
       
       在这个情况下,单纯向老板诉苦或者让老板直接给答案都不是高明的作法。
           
       汇报之前,你多问自己几句,你真的做足功课了?你准备的材料与判断依据充分到足以让老板拍板的程度了?你充分考虑部门的接口系统、远期系统整合目标了?每一个方案的优势、劣势考试的维度覆盖全了?你有借助外脑思考了?
      
       最优方案可以转换成成本效益分析,综合权衡利弊得出的。有时候,某个场景下,该方案最优,但随实施推进,方案优劣可能颠覆。比如计划做PHP开发的系统二次开发,距离客户需求最贴近,但市场上PHP开发资源太缺乏了;再迂回确定用JAVA全新开发,近期成本高,但远期维护扩展性很好。

       不管多么艰难,老板肯定问你选择哪个,你给的答案应该是底气十足的。在交流时,切记思路不能被老板左右,同时不断理清自己的思路。

     

    近期面试测试应聘者的一些感想

    http://bbs.51testing.com/thread-107304-1-1.html

  • 微软软件测试技巧

    2009-05-20 23:17:54

    2.1        两点间直线最近,QA建立轨道让开发在直线间滑行
    2.2        测试最高境界:不需要测试
    2.3        预防缺陷成本<发现BUG;预防缺陷成本<事后追究责任成本
    2.4        测试驱动开发,让测试与开发同时结束
    2.5        BUG 分类深刻原因:经验模式转向量化数据、统计分析的科学模式,便于定义优先级、资源分配,穿插管理思想。
    2.6        执行用户体验 (UE ) 测试。UE设计能用一步完成绝不用2步。
    2.7        测试不局限于你看到的内容,把测试扎得很深、透。测试对象不局限于软件,文档也是测试对象
    2.8        对测试的软件施加酷刑
    2.9        白盒测试是很高难度的,用工具而非肉眼阅读
    2.10        Daily build与daily test结合才有意义,每个用例每日都运行,报告反映软件最新的全貌
    2.11        没人对QA 产出进行审核?
    2.12        如开发多次询问BUG重现步骤,说明内部质量管理是有问题的
    2.13        严格执行测试计划,排除测试随意性。但鼓励测试工程师创造性
    2.14        让测试数据说话,对用例和BUG统计了解项目发生了什么
    2.15        测试理论从实践中提炼,异于推理性理论。
    2.16        V模型包含妥协,其思想是在何时做某一个测试更合适。但每一个阶段都应该全部测试。应该打破V模型的局限
    2.17        文档记录下思路,和他人一起评审;补文档效益不显著。文档没有写好,更多反映态度问题。用最简单、直接的方式表达思路给他人。
    2.18        定格子明确测试范围,确认是否完备?有重复?接口测试按模块切分了么?
    2.19        测试资源不足时,思考现有人员是否有潜力?是否有效利用资源了?是否有其他方式可以解决?招聘后资源空余如何处理
    2.20        在时间和质量矛盾时,选择保证质量
    2.21        5天内专业团队发现0个BUG,达到ZBB阶段(Zero Bug Bounce
    2.22        Case 通过率:促使开发修复BUG;代码覆盖率:促使测试增加测试用例
    2.23        区分工程师能力之一:功能验证点
    2.24        衡量代码覆盖率的技巧:awk 在程序分支处加入printf(序号),运行检查遗漏的序号
    2.25        内部产品必须平滑过渡
    2.26        灰盒测试是一种妥协,一定要追求白盒测试;白盒测试本质用程序测试另外一种程序,编写白盒测试工具也是能力转换的方式。白盒测试工具与应用程序互验证。
    2.27        购买工具思考清楚想解决什么问题,用一个工具来解决,否则工具多反而效率下降。工具需可定制化
    2.28        自动化流程从创建开始,到环境恢复止。自动化测试主干流程容易重复,重视单元级的细致测试
    2.29        用自动化思维思考问题,抽样也是一种妥协
    2.30        定制控件,不要牺牲软件特性换取程序可测试性
    2.31        B 测试不是让用户找BUG,而是让用户判断是否满足功能需求、UI需求
    2.32        创造UE测试标准
    2.33        自动化编码原则
    用例间独立运行,不依赖其他
    用例结束RESET
    用例运行次数建执行无障碍

    2.34        1个人+ 1群机器运行,高效
    2.35        从入库开始,代码就接近可发布的ZBB
    2.36        手工测试为主,研发与测试比例2:1  ,最高不超4:1;自主研发测试工具为主的team,研发与测试比例1:1
    2.37        不单纯依据BUG数量衡量开发人员水平,否则带来无穷的争吵和问题
    2.38        不要轻易放过一个有测试专长的人才
    2.39        测试纪律不要定制太多太琐碎,应该保证充分严肃性
    2.40        开发部门与测试部门配合是否流畅,和2部门经理风格相关,在于形成共识
    2.41        规范无止境

     

    微软测试管理一些通用理念

    1.1        结果是刚性的,过程是柔性的
    1.2        熟视无睹的事情容易出问题,做事情回溯到本源
    1.3        所谓效率即一次把事情做对、做好。让适合的人做适合的事情,价值最大化
    1.4        把最好结果、最坏结果,理顺目标才做事情
    1.5        微软让人震撼的是全球经理提微小的BUG,非常严格的BUG 标准
    1.6        要赢得别人尊重,要一如既往专注、专业,需要自身付出努力和实力,用自己价值赢来。
    1.7        管理者要了解心理学,分配工作确定owner
    1.8        一部分人的产出物没有做好,浪费更多人的时间
    1.9        衡量团队成熟度指标:自管理度。经理花更多时间在运筹帷幄、新技术研究上
    1.10        管理者获取信息途径包括人、平台,避免数据失真。管理者必须有思想,减少层层汇报。
    1.11        人力成本隐性的,人力浪费更多是浪费机会成本
    1.12        搭建一个团队公平展现能力的平台,不要做无价值的工作。和组员讨论职业发展,有是非分明的处事方法,同时不要怕承认错误

     

    微软测试技术可借鉴的点

    1.1       测试驱动开发,尽早、不间断地进行软件测试。建立强大的支撑daily build和daily test的自动化测试体系。围绕BUG数据为中心建立缺陷管理平台、统计分析、项目管理平台。决策从经验模型转向科学模型,整个软件开发流程宏观、微观细节都用数据说话。透过数据管理者花精力在尚未做好的事情上
    1.2       建立制衡制度、文化,不让有问题的代码check in,保证代码库神圣。减少围绕BUG的各种成本。
    1.3       完善各种CheckList 或者模版(文档、用例)、开发测试工具(白盒…),让能力瞬间transfer 到团队,充分应用已有成员的成果,提升team Level。充分避免手工测试弊端(无知识传承、置信度低、相对持续在一个水平)
    1.4       自动化测试不仅仅是技术,更是思想,自动化测试不是找BUG的而是一种质量保证手段。自动化本质是引入一种痛苦解决另外一种痛苦。基础设施不足是问题根本。脚本是自动化的最低形式。框架充分re-use、封装复杂度,提高框架的适应能力。自动化测试应在单元级上细致验证。建立自动化的平方环境
    1.5       在每一个环节细致严格要求,比如BUG提交规范减少人为沟通。每一个QA把自己的事情一次作好、做专业
    1.6       发布标准: 95% case通过率以及85% 代码覆盖率,<5%不重要的case bug。
    1.7       强调文档价值 (能力转换形式,对管理的支撑)以及定义高质量文档的要求
    1.8       可靠性测试、可扩展性测试针对设计而言,尽早测试,否则即使结果不满意,成本也很高昂
    1.9       Work around和彻底解决问题间,选择后者。硬碰硬突破
    1.10  测试工程师业绩考核指标:增加check in前预防BUG、发现别模块的BUG、开发自动化工具等贡献度大的项比重

     

    阿里巴巴质量保证平台整合趋势

     

    当下阿里巴巴质量保证部门采用主要的平台、软件、工具有:


    1) 项目管理工具: IBM  rpm 。系统架构: jboss4.2 + oracle9 + redhat 3.8 。

    缺点:由于IBM SQL 加密以及数据库表结构未提供,经过几次系统调优,操作响应速度依然不尽如人意。
           目前所需要的部分报表是不满足的,需要导入到数据仓库平台分析。

      初步评估Microsoft share point。接触HP ppm(能够和quanlity center 、Microsoft project很好集成)。

       国内华为花费重点购买rpm以及昂贵的咨询费让IBM 一起提升软件开发规范度。

    2) 需求管理工具
       
       需求部门采用confluence。系统架构: linux。

       用例颗粒度尚未符合软件工程的Use case,细致程度待提升。

       目前部分测试报告、测试文档也放在confluence。

       confluence用 wiki风格。其版本管理能力、交流能力稍弱。comment具有类似回帖功能。

    3) 测试用例与缺陷管理

        采用quality center。 系统架构: jboss +IIS + sql server express+ windows 2003 server
        QA 经常使用的模块:测试用例分析与设计、缺陷管理、后台备份恢复等

        需求管理、dashboard报表系统未充分使用,另外有些团队测试实验室利用率稍低。
        由于web项目频繁变更,报表模板复用率偏低,故报表系统能力未充分发挥。
         
        主要缺点:每个全功能缺陷连接license在3-5万。

    4) 测试部门文档管理

        采用svn。系统架构: apache + redhat linux
         
        缺点:全文检索能力弱。可以结合google 本地搜索功能或者MS的搜索功能
       
    5) 内部技术论坛
       
       自主研发的论坛opentech。 系统架构: java + webx+ linux 。

       我个人认为还是相当不错的,功能齐全。有论坛、知识库,支持帖子搜索。且有高质量的文档。

       缺点:QA评价是有点阳春白雪  ,我看来缺点就是外部合作伙伴由于信任证书无法登录。

    6) 即时通信
      
       采用阿里巴巴自主研发的贸易通。系统架构:c++ + linux。
       平常各个测试组建立群,可以在群上迅速交流。

       缺点:新来的员工无法看到先行者的一些讨论、分享。

    7) 数据仓库平台
      
       MicroStrategy之上二次开发。后端Oracle。


    从上面看,信息分散到不同的平台中,为了进一步提升使用效能,整合平台工具需求呼之欲出。
    主线大致有几点:

    1) 项目管理->需求分析->测试分析与用例设计->BUG 管理->报表、统计分析,一个环状的闭环系统。
      
       由于平台采用多家产品,整合难度提高。仅仅从数据层面流动意义不大。

    希望上述多个环节能穿接起来,形成一个宏观层次提供报表、微观层次给测试工程师工作的平台

    2) 需求分析->测试分析与用例设计->BUG 管理->源代码,形成一个需求和源代码的映射关系,做到需求和代码的有效变更跟踪

      sina 采用开源工具做。

    3) 测试文档、交流、搜索功能一体化

       主要针对文档放在SVN,项目计划文档放Confluence,交流在贸易通上集散。
       
       希望能做到集文档、交流、全文检索功能于一身。这个过于个性化的需求,暂时没有找到开源工具解决。

       光针对全文检索需求,可以采用自主研发的isearch3.0或者开源lucense。带附件的帖子不能简单做搜索。

    4) 其他
       
       针对项目管理平台RPM,改善成性能更好 、数据纬度更丰富、数据流/接口清晰的平台

    ...

       每一个需求真正融汇贯通,实现成本相当不菲。

     

    阿里巴巴测试难题

     

    测试技术方面:

    (一) 功能测试

    1测试环境搭建时编译抛出错误,快速判断是否系代码问题  
    2测试中抛出500错误(或log文件中error),快速判断系代码or数据or外部接口问题
    3自动化测试脚本是否细化验证点为所有可验证内容(页面所有内容显示区域、数据库、搜索引擎、cache、本地cookies等)? 检查细化,但维护量非常大
    4(高优先级) 测试数据准备工具(数据库、搜索引擎、cache等持久化或临时数据)
    5个人pc机本地测试环境差异(操作系统状态、完整性,浏览器版本、完整性),引起问题的原因是软件的添加/卸载,浏览器插件安装/删除,补丁程序,系统设置与浏览器设置等等
    6 数据准备 如:不同类型账号生成,像生成10中供新单账号, 10个中供服务中账号等等,批量生成而不需要手工完成,否则效率慢了。
    7 搜索引擎支持多个站点,每个站点又有不同的数据应用,se.conf存在众多的配置项、分词器,测试的矩阵非常庞大,如何保证尽少资源获取最好测试效果
    8 抽样检查分词器的功能有遗漏,但分词器算法和外部已有的分词器算法不同,如何提高分词效果核对效率
    10 海量数据查询结果正确性验证

    (二) 性能测试
      1 生产环境硬件模拟
                    生产环境依赖于外部昂贵的设备,在测试环境开展性能测试如何模拟?比如有专用邮件服务器,图片服务器,CACHE服务器?
            2 数据模拟
                生产环境的数据量巨大,如何剪裁合适的数据集作为性能测试基准数据?
            3 用户行为模拟
                      虽时间变化日志系统分析的数据会很快过时,如何低成本跟进访问模式
              
      4 特殊场景下性能瓶颈定位与监控等等
          比如国际站凌晨2点突然LOAD 升高,原因未明
      5  容量规划的效果如何衡量
       

    (三) 质量管理平台
    1 没有缺陷报告平台,需要详细或自定义报表时无法给出   
                    如QC 的报表、需求管理2部分功能一直没有采用。
    2 项目管理、需求管理、缺陷管理多个系统入口, 并没有统一关联。另外代码与需求之间映射关系随着业务变更也难以一一映射
    3  现有的软件测试平台更适合传统的大型软件测试,能否、如何定制更适合快速上线的WEB系统?
          
    (四) 测试管理
    1 测试机器的使用权限(Linux、Windows)管理,做到近少互相干扰
    2 如何有效度量测试工程师的绩效?
    3 (高优先级) 如何更快找到合适的测试人才?
    4 (高优先级)如何提高开发、测试双方的满意度?
    5 (高优先级)如何提高估计测试时间的准确度?
      
    (五) 测试新技术的应用与推广  

    1  如何有效开展安全与漏洞测试
    如:sql注入,cookie安全机制,安全证书、加密等. 服务器与客户端的安全漏洞检测等
    2 白盒测试工具引入及白盒技术等
    如:单元测试工具Junit, parasoft的白盒测试工具使用与引入等。
    3 自动化测试在项目中是否需要介入,何时介入?(数据准备?回归测试?)
    4  如何在自动化覆盖率和验证点密度  与自动化成本间找到一个合理的平衡点


    测试策略与方法方面
    (一) 测试用例分析与设计
      1 冗余的测试用例的精简化问题
      2 (高优先级) 底层代码的修改如何测试,回归范围如何确定,测试策略如何确定?
    如 ejb, jboss改造的性能与功能测试
      3 如何使用冒烟测试对大型软件进行快速测试,用例的选择问题
      4 如何为复杂产品/大型测试项目选取测试策略? 如
    镜像站点测试
    异地数据同步测试
    重构项目测试  
      5 Apache Modul如何测试(功能测试与性能测试)如中文站最近发布的将Image server固定域名通过modul替换成动态域名?
      
      6 (高优先级)支持多浏览器(IE6/ie7/firefox...)/多OS软件如何测试? 支持国际化语言版本的软件如何测试?如国际站网站支持英文,繁体版,马来西亚语言。

         降低成本的测试方法有哪些?
        正交表测试方法满足我们的需求么?
      7 (高优先级)如何在时间、进度压力下,最优选取测试集合?回归测试的面积多大算合理?

      8(高优先级) 跨部门、跨公司的接口测试如何开展,以提高协调效率?
         如中文站和阿里软件贸易通状态接口,国际站和后台CRM 接口,

    (二) 测试执行

    1开发的代码中缺少足够的接口来支持自动化或者黑盒测试的问题
    2 反复测试引发的测试疲劳如何应对(个人、团队)?交叉测试什么时候引入合适?如何衡量交叉测试的绩效?

    (三) 测试标准
    1 如何定义测试“完成”,比如如何定义搜索引擎测试完成?
    2 如何提升对项目是否可以release的影响力
    3 (高优先级)如何清晰度量产品的测试质量
    按测试覆盖率?按BUG遗漏数?按已经发现BUG的曲线图?哪些标准度量最合适
    4 测试人员是否需要了解代码,了解代码需要到达何种程度?
    5 如何在没有单元测试代码情况下,度量代码测试覆盖率

     

    微软软件测试质量体系最佳实践课程

     

    MSUP的课程。看了很是心动:)

    陆宏杰的课程偶旁听过,给你展现很多MS的东东。有兴趣的朋友请

    祥见:www.msup.com.cn



    陆宏杰 曾任微软亚洲工程院部门经理
    微软资深专家顾问,曾任职于微软亚洲工程院,十余年的软件开发、软件测试和团队管理经验,曾主管过多个大型复杂项目的开发和测试工作,尤其在自动化测试技术和测试管理方面积累了大量的实际项目经验。对于各种测试方法的重点、难点和实施技巧有深入的研究,其主持开发和测试的项目多次获得微软全球最高技术奖项和工程奖项,并获得msup 2007年度top one金牌分享大师、msup 2007年度软件企业内训最佳好评讲师。

    课题
    简述
    Topic 1
    对软件测试的理解
    (1)软件测试的最高境界是什么
    (2)测试驱动开发模式
    (3)测试是需要额外增加项目时间
    还是加速开发进度?
    (4)通过测试提高开发有效代码率
    (5)软件测试的存在阶段
    (6)怎样实施不间断测试
    (7)缺陷分类对开发管理支撑作用
    (8)软件风险的概念
    (9)测试的充分性准则
    要做好测试,首先要有深刻的理解,对实践中最重要、最容易混淆或最容易出问题的地方结合实例阐述,讲解将测试融入开发进程的实战策略以及自动化测试的部署策略。

    Topic 2
    测试计划
    (1)测试计划的制定策略
    (2)测试计划和需求分析之间的联系
    与配合
    (3)如何科学评定工作量、所需人数
    和各方面设备
    (6)测试范围的界定
    (7)测试目标的界定和考评
    (8)项目风险评估
    (9)测试过程中的假定和局限
    (11)被测对象特性描述
    (12)具备可操作性的发布标准
    (13)对验证粒度的管理和要求
    (14)通用方法/工具的建立
    (15)所需拓扑逻辑的定义
    (16)各种测试工具的比较和选择标准
    (17)怎样提高测试效率
    (18)如何组织和管理需求文档、设计文档和测试文档
    分析文档的核心价值和在软件项目中的作用,为什么要写文档?不写行不行?要写哪些文档?准备文档对项目整体进度的影响是什么?

    这部分内容将分别从测试执行者和测试管理者的角度分别出发,讲解如何制定能覆盖到细节的测试计划,文档对项目的实用价值,对文档质量的评审流程,以及准备资源的依据,并最终评定每一个测试人员的测试执行情况。

    Topic 3
    测试用例
    设计
    (1)黑盒测试
    (2)白盒测试
    (3)等价类划分法
    (4)边界值分析法
    (5)因果图法如何提高测试技术复用程度
    在众多测试用例中,验证的深度和白盒测试是测试活动中比较突出的难点,大部分理论中的描述不具有可操作性。这部分内容会着重讲解如何进行深度验证和解决白盒测试的难点,使得白盒测试可以真正得以实施,同时,介绍提高测试效率及效果的技术复用策略。

    Topic 4
    测试度量体系建立
    (1)缺陷库的建立
    (2)用例库的建立
    (3)测试结果库的建立
    (4)自动化测试体系
    (5)高效的工作流程
    (6)数据统计和数据挖掘
    (7)缺陷追踪体系 科学的测试管理
    通过对测试度量体系的构建,深入理解如何工程化实施大规模深度测试。

    Topic 5
    自动化测试
    方法及技巧
    (1)对功能测试的控制
    (2)黑盒/白盒测试的部署技巧
    (3)安全性测试的难点和特点
    (4)Help、手册和文档的测试分工
    (5)全球化和本地化测试
    (6)可用性测试定义
    (7)可扩展性测试
    (8)Geo/Political/Legal的测试方法
    (9)Logging/ Message format Tracing/Counters( Diagnos ability)
    (10)Testability的评估
    (11)Test Hooks高级测试方法
    (12)基于场景的测试
    (13)可靠性/耐久性测试
    (14)集成测试
    (15)交互性测试
    (16)兼容性测试
    (17)UE测试
    (18)性能测试的方法和要点
    (19)Benchmark
    (20)压力测试
    (21)性能测试和压力测试的区别
    (22)压力测试的难点和技巧
    (23)对系统的压力测试
    (24)对界面的压力测试
    (25)使用工具进行性能测试和压力测试
    这一章是自动化测试的重要实战部分,将对每一种测试方法的重点、难点和实施技巧进行讲解,用一个真实的企业级软件项目作为案例,讲解如何在一个真实项目中逐一实施这些测试方法,其中绝大部分的测试方法都以自动化测试的技术和实现方法来讲解。当所有的测试方法都部署完成,讲解何如把这些独立的测试方法和测试活动整合成自动化测试体系。从而实现缺陷预防的持续改进。

    Topic 6
    自动化测试体系
    (1)自动化测试对Bug的控制力度
    (2)多种自动化测试工具的分析
    (3)自动化测试的运行部署策略
    (4)数据驱动的测试
    (5)核心功能的自动化测试标准
    (6)Pass Rate:测试活动的重要标准
    (7)代码覆盖率检查,对测试质量的审查
    (8)自动化测试的缺陷跟踪
    (9)GUI测试自动化的难点和解决方法
    (10)自动化测试的自动化
    (11)如何将多种自动化测试工具和技术部署为一个复杂完备的大型质量保证体系
    这部分内容是核心中的核心,它是建立在前面用例设计、测试计划和各种测试方法的基础上的,可以说前面的内容都是在为这一块打基础,对于自动化测试来说,光有技术和工具还不够,需要工程化的综合使用,使之成为一个体系,甚至需要实现自动化测试的自动化。

    Topic 7
    测试管理
    (1)如何着手组建和优化测试团队?
    (2)一个测试团队必须的3种人才
    (3)产品Bug和测试Bug
    (4)如何从每一个细节控制测试进度和项目进度
    (5)如何协调测试团队和其他团队的配合
    (6)周期性测试的活动安排
    (7)测试人员的考评标准
    (8)测试纪律的制定策略
    (9)质量文化
    (10)对工作项的时间限定
    (11)数据统计和数据挖掘
    (12)如何制定项目计划,包括开发计划和测试计划
    (13)合理的里程碑及里程碑之间的工作计划
    (14)长期计划、中期计划、短期计划
    (15)Guideline和CheckList
    (16)在项目进度要求很紧的情况下如何保证测试的质量和完备性
    (17)作为一个管理者必须控制的3件大事
    (18)保持项目的持续成长
    没有科学的测试管理就不可能建立完备的质量保证体系,这部分内容分享在测试管理中的有效经验,通过流程控制与过程改进优化测试效率,保证测试质量,加强测试对于需求分析和开发过程以及技术应用的配合,从而完整实现测试驱动软件开

    遴选合适岗位人才要领

     

    一 分析现有岗位人员技能特点,最好增加互补型人才

      假如现有的人才都属于通才型,那需要找到一个很有专长的人才,作为互补最合适。
    还有如果团队都是年轻人,加入一个经验丰富稳重一些的更好

    二 考察专业能力
     
      工程师考察专业能力相对容易一些,可以将自己经历过的项目提炼出一些有梯度的问题,判断应聘者

    属于需要人带 、独立做事情、带团队做事情、某个领域的专家中哪种类型

      专业能力最好能涵盖基础知识以及项目实践,把握好深度、广度。基础好的人,发展潜力、爆发力比

    较好

    三 考察学习能力

     了解碰到疑难问题的解决模式,以及对这个问题是否有提问的智慧。

    另外,可以将业余爱好与学习能力结合起来。还有询问经常去的一些网站,记得哪些比较深刻的技术细

    节。
     
      一般情况下,如果对某个比较难的技术问题把握得很到位,也可以侧面了解到学习能力高下。
      学习意愿可以从他最擅长的知识入手考察,一般意愿强的人,喜欢寻根究底,深刻理解背后的原理。
    反面而言,就是一根筋:)

    四 考察适应环境能力
     
     可以从几个方面看
    1 承受压力能力:互联网公司项目多\紧急,一般面临多项工作并行开展,同时节凑快。
    2  软技能:测试工作繁复琐碎,需要耐心、细致的特质;由于需要频繁和外部联系,良好的沟通技巧,

    有利于顺利开展工作。开放、共享的心态有助自我提升。
     
      还需要判断其缺点是否影响其业绩

    3  团队的融入性: 做事风格不能相差太多。认可结果为导向、客户第一等多项价值观

    五 职业素质
     
    1 比如跳槽是否过于频繁,能否有稳定性
    2 对自己是否有一个清晰的定位以及职业发展规划

     实际上,在挑选高级人才时碰到最大的问题有几个
    A) 比较接近的候选人偏少
    B)  把握不准到底适合这个岗位、流入市场的候选人到底有多少?这里有类似非常复杂的猴子捡玉米问


    C)  在软技能和潜力把握方面难度比较大

    欢迎大家探讨

    web软件测试碰到的难题

     

    最近在整理测试难题,以及打算在跨子公司讨论、分享的话题。呵呵,大致列举一些

    1 如何清晰度量产品的测试质量?

       按测试覆盖率?按BUG遗漏数?按已经发现BUG的曲线图?哪些标准度量最合适

    2 如何为复杂产品/大型测试项目选取测试策略? 如
     
    镜像站点测试
    异地数据同步测试
    重构项目测试

    3 支持多浏览器(IE6/ie7/firefox...)/多OS软件如何测试?

    降低成本的测试方法有哪些?

    正交表测试方法满足我们的需求么?

    4 支持国际化语言版本的软件如何测试?如国际站网站支持英文,繁体版,马来西亚语言。
    降低成本的测试方法有哪些?

    5 如何在时间、进度压力下,最优选取测试集合?
    回归测试的面积多大算合理?

    6 如何提高估计测试时间的准确度?

    7 跨部门、跨公司的接口测试如何开展,以提高协调效率?

    如中文站和阿里软件贸易通状态接口,国际站和后台CRM 接口,

    8 如何有效度量测试工程师的绩效?

    9 生产环境依赖于外部昂贵的设备,在测试环境开展性能测试如何模拟?

    比如专用邮件服务器,图片服务器?

    10 生产环境的数据量巨大,如何剪裁合适的数据集作为性能测试基准数据?

    11 如何更快找到合适的测试人才?

    12 如何提高开发、测试双方的满意度?

    13 如何在没有单元测试代码情况下,度量代码测试覆盖率

    14 现有的软件测试平台更适合传统的大型软件测试,能否、如何定制更适合快速上线的WEB系统?

    如QC 的报表、需求管理2部分功能一直没有采用。

    15 项目管理、需求管理、缺陷管理多个系统入口, 并没有统一关联。另外代码与需求之间映射关系随着业务变更也难以一一映射

    ...待续

     

    技术管理初体验

     

    在技术管理方面,偶是绝对的新手。

    不过就像很多事情一样 ,都有人无师自通的 J ,可惜偶不算这种。

    以下都是偶的一些浅显见解。

     

    技术管理和纯技术工作还是有很大的不同

    1)      技术管理需要经常REVIEW 成员的成果,REVIEW的工作量取决于REVIEW的粒度,太细会把握不住重点且工作量大,太粗无法看出门道。由于要REVIEW 组员成果,需要对组员的工作领域有比较深刻的把握,故技术管理需要杂家 纯技术则一门心思把自己的事情做好,并偶尔帮忙请教的同事解决问题,在自己的领域专注得比较深

    2)      技术管理的重点在于把握人,要鼓励组员积极发挥主观能动性,及时发现组员的思想情绪变化,也需要授权给与组员充分的信任但还是需要REVIEW成果;纯技术则重点在于管事,把颗粒很细的事情解决掉,当然也有培养接口人的任务。

    3)      技术管理的绩效考核从团队业绩出发,一华为跳槽过来的哥们说的: 团队PKI 比个人PKI 更难出彩; 纯技术工作更多把自己的活做好,并影响周围人积极向前

    4)      技术管理的工作经常被打断,思路也随之被打断,故在时间管理上提出更高要求;纯技术则干扰少一些 ,技术管理者需要帮纯技术的同事创造一个尽少被干扰的环境

    5)      在技能要求方面,作为一个上通下达的角色,技术管理在领悟能力、沟通、协调等 软技能方面提出很高的要求,另外在某些时刻需要根据直觉决断 ;纯技术则需要在技术细节方面把握很到位

     

    技术管理方面碰到的一些容易困惑的问题

    1)      技术管理碰到最大的问题是资源短缺,如何平衡各方的需求成为一个最棘手的问题

    2)      绩效考核,技术工作很难单纯用数字量化,如何甄别组员的优秀,需要有伯乐的眼光

    3)      一直保持良好的团队激情、氛围。基层的技术管理者手上有的 赏的权利很小,手段多为肯定、赞扬组员的工作,呵呵,有时候这些手段是不够 J

    4)      技术管理如何协调团队内外的关系。外部期望值一般都很高 ,作为技术管理者在满足外部需求时,需要权衡团队的承担能力

    5)      怎样的领导风格最适合团队? 太严格,容易压抑;太宽松,容易散漫;太武断,容易听不见他人意见,太犹豫容易错失时机

    6)      技术管理,自身还需要承担很多技术工作,比如确定技术研究方向、解决技术问题,技术和管理分配的时间比率为多少最合适?

    7)      …..

    说到底,面对诸多问题,有一个度量把握的问题,这个很需要艺术。 也是偶的努力方向。

     

     

     

     

     

  • 站点

    2009-04-03 16:40:45

     

    陈绍英的博客:

    http://blog.csdn.net/chenshaoying/category/304142.aspx?PageNumber=2

    在Controller中执行测试场景时,如果脚本需要在远程主机上执行,一定要通过VuGen的File菜单下 操作,把调用的DLL以及.h等文件添加到脚本中,只有这样执行场景时,Controller才会把Dll同步发送到远程主机上供本地脚本调用。

     

    三个VOA资料下载站点:

    http://www.tingclass.com/voa/list158_1.html

     

     

    http://www.unsv.com/voanews/specialenglish/scripts/

     

     

    http://www.52en.com/voa_se/index.asp?newsid=40

     

     

Open Toolbar