qileilove

blog已经转移至github,大家请访问 http://qaseven.github.io/

B/S架构测试环境搭建_Teradata篇(Win32系统)

 前言:Teradata数据库在数据仓库领域的优势还是相当的巴适,测试需要,而且该数据库好多SQL都是自备,很强大,有这方面兴趣的朋友可以一起研究。

  一、创建数据库:

  (1)Teradata安装好之后,最好安装一个Assitant,不过没有这个也没什么,纯手工SQL也能写。如果不是第一次使用环境,先开启Windows的服务,然后在开始菜单的Teradata的选项中选择“Teradata multiTool”选项,将两个后台服务PDE和DBS启动。具体启动界面如下:

图1 启动PDE和DBS

  (2)正常启动后台服务完成后,需要在文件hosts中配置步骤(3)需要的创建数据库的信息,配置文件在Teradata安装完成之后放在C:\WINDOWS\system32\driver\etc下面,名称为hosts,修改最后一行的设置,设置成启动Teradate的ip和对应的数据库信息,如在本机启动了Teradata的服务,同时我想创建一个gusl的数据库,那么在此行应设置成127.0.0.1 guslcop1。

  (3)在开始菜单的Teradata选项中选择“Database Setup”用来创建数据库和用户。弹出如图2的窗口,输入数据库的名称gusl和对应的Super user的用户名和密码,同时创建一个管理用户,密码设置什么的都在这。

图2 创建数据库图形页面方式

  (4)确定后Teradata会在控制台打印对应的创建信息,正确无误后该数据库就可以正常使用了,如果出错,可以查看对应的信息纠正(刚开始搞很容易出错,不过熟练了就好多了)。

 (5)使用BTEQ登陆,这个具体的安装和配置网上一堆,很实用的Teradata的工具。不过建议装个BTEQ的windows版的,这个能复制建表语句,直接的BTEQ不能(很悲剧)。使用Super user和刚才新建的用户登录。在BTEQ弹出输入“Enter your Logon or BTEQ command”时输入.logon database_name/user_name(注意前面的点必须要),提示输入密码,完成登录。如图3

图3 测试创建完成的数据的登录

  (6)登陆完成后需要创建对应的用户同时给对应的用户授权,具体的命令和图解如下:

  创建用户命令: create user "gusl" from DBC as password=gusl,account='$DBC',permanent=3000000,fallback;

  Teradata的命令不全是以点(.)开始,但是一定是以分号结尾。上传的是我第一次留下来的截图,上面还有当时的犯错记录。


图4 创建用户

 (7)用户创建成功后给用户授权,同理SQL的grant命令,和Oracle的有一点区别。

  grant select,delete,insert,update on database to user。(授予某一个用户在某一个数据库中的权限)。

图5 给用户授权

  用户创建完成之后我们可以尝试着使用该用户登录数据库,看是否能正常登陆。

图6 新创建的用户登录系统

  PS:补充创建创建数据库的SQL,正常登陆后即可。在Teradata中数据库就是少了密码的用户,这一点很独特,或者你认为他是对应的Schema也行,看你怎么理解了。

  create database database_name from mib as permanent=3000000,spool=4000000,account = '$mib',fallback ;

  数据库环境搭建就告一段落,我是按照我从事测试行业接触知识的先后顺序将对应的内容分享,有点偏技术了,毕竟这些都是数据库的基本操作,掌握了可以为我们的测试工作更好的开展





posted @ 2011-11-23 10:25 顺其自然EVO 阅读(864) | 评论 (0)编辑 收藏

[分享]解读软件外包

 1、对大学生谈软件外包的原因

  中国软件外包行业这几年成为发展最为迅速的行业之一,无论你是在校的大学生,还是即将毕业的同学,都有必要了解这个行业。如果你是软件相关专业的同学,或者毕业后准备从事软件行业,那么更应该关注软件外包这个行业。

  尽管网上已经有很多关于软件外包的信息,但是这些信息很多都是媒体记者的报道,他们只是从旁观者的角度看待软件外包,缺乏一定的深度和实践感受。还有一些来自非软件外包的人士,基于他们主观的理解和推测,认为软件外包是很低级的工作,为软件外包工作泼冷水,影响了对软件外包工作的正确认识,造成了软件外包的“中国式误会”。

  大学生接受了系统的高等教育,具有牢固的知识基础,而且具有极强的可塑性和学习能力,是未来软件外包行业的主力军。但是,他们参加软件外包实际项目的机会和经验毕竟很少,对于软件外包有很多模糊的认识。由于教材的更新需要更长的周期,高校教师如果没有丰富的外包企业经验,很难把软件外包的实际知识传授给学生,因此,外包企业从业人员有必要向这些高校学生交流一些软件外包企业的实际情况。

  那么什么是软件外包?软件为什么要外包?中国软件外包的现状如何?将来做软件外包是否有前途?这些问题可能很多同学不是很清楚,如果今后打算进入这个行业,则从现在开始就需要先了解这些问题的答案。

  笔者具有多年的软件外包公司工作经验,对于软件外包行业一直积极关注,并且积极与国内外同行交流,对软件外包有些自己的体会,借此机会与个位同学进行交流。

  2、软件外包介绍

  软件外包就是软件开发商(简称“发包方”)将软件开发的一部分或者全部,发给别的软件公司(简称“接包方”)去完成。

  我们通常说的中国外包公司很多都是“接包方”,主要从日本和欧美等国承接软件外包项目的技术工作。现在软件行业比较发达的美国、欧洲和日本是最大的“发包方”市场。

  由于软件外包是软件全球性生产方式,所以存在很多关于外包的英文术语。外包的英文单词是“Outsourcing”。站在“发包方”的角度,把“接包方”成为“Vendor(外包服务商)”。站在“接包方”角度,把“发包方”成为“Client(客户)”

  软件外包与其他外包其实没有本质区别,就是双方合作把一个很复杂的、较大的软件项目分工合作,共同做好。其实在其他行业,外包已经实施了很长时间,例如汽车行业,生产汽车的公司(比如一汽集团)他们先设计好汽车的结构,完成主要部件的生产,把很多零件外包给很多厂家加工,然后采用完成整个车辆的安装和制造。

  现在人们很关注软件外包,就是因为外包在软件行业应用的时间还很短,而且软件生产存在很多不可见因素,软件外包的优势和好处,还没有被普遍了解和感受。

  总结一句话,软件外包就是软件生产的分工和合作,主要目标就是生产出好的软件。

  3、软件外包的理由

  同学们可能都听说了,现在印度和中国做软件外包“火得不得了”,越来越多的欧美大型软件公司都把软件外包给印度和中国。为什么会出现这种现象呢?

  要回答这个问题,不能简单的从发包方或者接包方一个方面寻找答案。因为“一个巴掌拍不响”,要实现软件外包,必须双方都有需求、有能力、愿合作才行。而且不能把目光只盯在中国一个国家,还需要从全球软件行业的整体来看待和理解。

  为什么软件外包能发展的这么快呢?主要原因在于通过软件外包,发包方和接包方都获得了可观的利益,非常具有现实意义。说得更简单一点,就是双方都获得了好处,大家是互相合作的伙伴。

  作为发包方,可以获得下列好处:

  ● 降低软件项目成本
  ● 提高软件质量
  ● 缩短软件开发周期

  怎么理解软件外包能较低软件项目成本呢?

  大家可能听说过,美国的软件技术人员的工资比中国同等水平的人员要高5到10倍,所以不少美国的软件开发公司都把软件开发和测试的工作,发到中国的软件外包公司来作,可以大幅度的降低成本。对于中国的软件外包公司,他们从国外客户承接外包项目,可以获得很稳定也很好的项目价格,所以很乐意做软件外包服务商(Vendor)。

 说到通过软件外包提高软件质量,可能很多人不理解。举个例子就明白了。

  美国微软(Microsoft)公司是全球最大的软件公司,现在正在开发的Windows Vista新操作系统,需要同时发布多个语言的本地化软件,例如英语、简体中文、繁体中文、日语、韩语、德语、法语、阿拉伯语等。这些语言的本地化版本的翻译、编译、测试,如果全部在微软公司内部完成,那么微软需要招聘大量的精通每种语言和软件技术的工程师,否则语言质量肯定不能保证。如果把这些工作外包给专业的软件本地化外包公司,软件本地化是这些外包公司的强项,所以可以显著的提高软件质量。

  软件外包能缩短软件开发周期的道理很容易理解,如果很复杂的软件开发工作都在一个公司内部完成,那么可能耗费1年甚至几年的时间。例如,如果Microsoft Windows Vista的软件需求分析、框架设计、详细设计、软件编码、软件测试、软件多语言本地化等工作都在Microsoft公司内部实现,那么微软可能需要招聘很多的内部员工,动用很多的项目经理管理这些人员,对这些人员进行技术、语言和流程培训,花费的时间肯定比外包更长。这样的软件即使开发出来了,等到能够发布这些技术可能过时了,其他竞争对手的相似产品肯定已经早已占领了市场。

  现在是网络信息时代,时间就是金钱,速度就是效益,“快鱼吃慢鱼”,实现抢先推出新产品,谁就可能占领更多的市场份额。

  4、做软件外包的前途是啥?

  俗话说:“男怕入错行”,如果你进入了一个没有前途的行业,即使你的能力再高,你的发展空间也很有限。对于,刚刚毕业的大学生,第一份工作非常重要,甚至会影响一生的职业生涯。

  软件外包是全球软件行业新兴的行业,是经济全球化和软件产业全球分工的产物。大家知道全球化已经深入到我们生活的每个方面,我国的改革开放就是顺应了时代潮流。

  对于中国而言,软件外包的发展更是如火如荼,属于典型的IT“朝阳行业”。每年的增长速度都在50%以上,特别对于中国的软件外包公司,他们每年的业务都是100%的速度增长,发展势头不可阻挡。

  从事软件外包工作的好处之一是可以在短期内获得职业提升的机会。现在中国软件外包行业如果具有5年以上的工作经验,就可以成为外包的有经验专才了。很多大学生进入软件外包公司工作2到3年,如果学习能力和交流能力好,可以成为项目经理或者部门经理。

  从事软件外包工作的好处之二是可以学习和培养国际化思维方式和工作方式。前面已经谈到,软件外包是全球合作的工作方式。做软件外包工作,有机会学习先进的软件设计和测试方法,学会管理大型的、多个团队协作的软件项目,要和多个国家和地区的技术人员和管理人员进行英语或者日语交流。这样可以提高语言表达能力,团队交流能力,遵守科学的生产流程,成为熟悉国际市场和技术的职业人士,对于将来的职业发展大有帮助。

  而如果毕业后到一个小的软件公司工作,由于中国的小软件公司很多都是10多个或者几十个人的手工作坊式公司,企业内部缺乏完善的流程,管理混乱,粗放式经营,依靠个别高手的能力,这样的环境很不容易学习到关键技术,而且还会养成随意的、不善交流的独立自我的工作习惯。这种习惯一旦养成对于今后的职业发展是大为不利的。

  因此,大学毕业生投身做软件外包,就是进入了一个发展前途十分可观的“朝阳行业”,通过自身的不断努力,有希望在短期内,成为熟悉国际化行业规则的技术和管理人才,成为职场上非常有竞争力的软件专家。

  5、外包公司是怎么工作的?

  进入软件外包企业后,为了尽快适应新环境,完成日常工作,需要了解软件外包公司是如何安排工作的。

  从外包的内容看,现在大多数中国软件外包公司从事两种内容的工作,第一是软件设计和编码的外包(即开发外包),第二类是软件测试外包。

  从工作的地点看,软件外包公司的员工的工作形式分为两种,第一是被派遣到发包方(客户)的公司进行工作,这种形式称为“On-site外包”。第二式在软件外包公司内部工作,称为“In-house外包”。

  如果同学们到人才招聘网站看看外包公司的招聘广告,经常能看见赴微软,赴IBM从事软件开发或测试的招聘职位。这种形式就是“On-site外包”。举个例子,软件外包公司A招聘了从事软件外包测试的同学小李到微软亚洲工程院从事微软的软件测试,虽然小李在微软的公司工作,但是他隶属于A公司,工作上受到A公司和微软公司的领导,A公司每个月按照A公司的工资标准给小李发工资。一般来说,“On-site外包”的工程师的技术水平要求的更高些。

  在笔者看来,“On-site外包”工作方式只是软件外包的初级形式,如果软件外包的服务模式成熟之后,越来越多的外包将以“In-house外包”的形式实现。下面介绍“In-house外包”的工作方式。

  所有的软件外包公司都是以“项目”的形式,组建项目团队开展外包工作。一个“项目”就是一个有着明确的任务,明确的开始和结束时间,以及明确的质量要求的工作。项目团队就是为了完成一个项目组建的有不同角色的多个人的小组,一般安排一个项目经理,一个或几个组长,多个工程师。

项目经理主要制定项目计划、资源安排、内部交流和外包的客户交流。组长为每个工程师分结和安排具体的任务,跟踪项目进度,解决技术问题。工程师根据组长分配的任务按照进度和质量完成每天的工作,并且报告进展和遇到的问题。

  项目经理负责周期性的向“客户”报告项目进展情况,同时把客户反应的问题和来自客户的最新文件和要求等传达给项目组。

  通常项目经理和组长都是由具有管理和技术经验的员工担任,对于刚刚加入软件外包公司的大学生来说,绝大多数都是从工程师的职位做起的,先经过外包公司的内部培训,然后进入项目组实习,转正之后称为工程师,负责具体的开发或测试工作。

  顺便说说,不少优秀的大学生,专业技术非常好,学习能力由特别强,善于思考和总结,也善于与其他人交流和合作,这样的学生很快就可以在项目团队中脱颖而出,经过一年或者两年可以从普通工程师晋升到测试组长甚至项目经理。我的不少同事就是这样过来的,这是因为软件外包发展得非常快,客户发来的软件外包项目越来越多,项目团队越来越多,每个项目都需要项目经理,所以从事软件外包具有很大的职业发展空间。

  现在总结一下软件外包公司的工作方式:

  ● “On-site外包”或者“In-house外包”方式
  ● 按照项目团队的方式工作
  ● 刚进入外包公司的大学生绝大多数要从工程师做起

  6、有哪些好的外包公司?

  对于正在找工作的同学来说,都希望到一个规模较大的公司工作,一般来说,大公司比较规范,待遇也较高,倒闭的风险小。对于软件外包公司来说也是这样子。

  同学们可以猜猜看,全球著名的高端软件外包公司有哪些?据媒体报道,比较公认的全球高端外包公司分别是IBM,HP和EDS,前两家同学们肯定耳熟能详,有些同学可能怀疑IBM,HP能算是软件外包公司吗?它们算不算外包公司不是我说的,反正做软件外包多年的老外都这么人为,人家可是全球知名的外包专家,可不是信口胡说的呀。

  有的同学经常问我,国内有哪些规模较大的外包公司?哪个外包公司最好?我一般都回答不好。为什么呢?因为每个人看问题的角度不同。比如,什么是“规模较大”?是按照正是员工的人数比较呢还是按照每年的总收入确定?什么样的外包公司是“好公司”?给员工发的工资搞就是好公司吗?给员工提供专业的技术培训,而且具有很大的职业发展空间的是否就是“好公司”呢?

  因此,在你问这些问题前,先要搞清楚你心目的好公司应该具有什么样的特征。

  我还是从国内外包公司的普遍特征来给出这个问题的一些参考信息。

  前面已经提到,我国软件外包公司属于新兴的行业,真正从事软件外包的员工如果人数超过1000人在中国就可以算是比较大的外包公司了。据了解国内最大人数的外包公司现在不超过3000人(这里需要说明一点,有些公司一开始是做系统集成的,最近才开始做软件外包业务,虽然他们的全体员工超过5000人,但是真正做软件外包的还不超过3000人)。所以同印度的某些大的软件外包公司项目,我国的软件外包公司规模普遍弱小。印度的软件外包公司超过10000人的很多,有些超过了5万人。所以有些国内的软件外包的朋友,把中国软件外包公司比作“蚂蚁”,把印度外包公司比作“大象”。

  如果同学们打算做软件外包,肯定要问哪个省市的软件外包公司最多?我要告诉大家的是,中国的软件外包在各个省市的发展很不平衡。大连、北京、上海、深圳、苏州、西安等发展的相对快些。其他各个地方今年开始从政府到企业都开始提出要发展软件外包了。

  关于国内软件公司的规模,同学们可以参考我国政府权威部门发布的“中国软件欧美出口工程”试点企业名单。这些公司都具有一定的规模和实力,有些记者把这些公司比喻成“中国外包的国家队”,言外之意其他的外包公司只能算是“地方武装”了。 。

  大连的软件外包发展的最为快速,特别是对日外包做的最为成功,因为大连的政府支持,地理位置靠日本很近,可以找到很多掌握日语的软件技术人员。北京和上海的软件外包发展的时间更长,这两个直辖市凭借经济和政治的影响,吸引了大量的国外客户,人才资源很丰富,所以外包做的很早,很多欧美的大型软件公司都在这两个城市成立的研发中心。

  说到外包公司,很多人首先想到的是中国本土的外包公司,其实出了本土外包公司,国外外包公司在中国的分公司也不可忽视。这些国外外包公司有的进入中国较早,有的最近一两年才在中国落户。他们凭借国外市场的良好客户关系,全球的专业品牌,先进的外包管理技术,丰富的外包经验,加上国际化的工作环境,良好的薪资待遇,吸引着很多大学生前去应聘。

  最后给同学们一点建议,大家在找工作的时候与要单纯追求规模大的外包公司,中小规模的外包公司有可能发展速度更快,有可能提供很大的职业发展空间。关键是通过各种方式综合了解软件外包公司的发展前景、工作环境和个人发展空间,可以通过打听在外包公司工作的同学、朋友、亲戚、老乡,也可以上网看看外界对这家公司的报道和评论。

 7、软件外包公司需要什么样的人?

  刚毕业的同学如果没有考研或出国留学,都有过找工作应聘的经历,不少同学都感觉找到合适的工作单位不是一件容易的事情。有些同学虽然得到了软件外包公司的应聘机会,但是面试后就没有消息了。

  而一些软件外包公司的招聘人员却为找不到合适的人员而苦恼,只好发动一切可以调动的因素,解决企业人才困乏的问题。所以有人把这种现象归纳为:“高校有人没事干,企业有事没人干”。

  这种现象的本质是大部分高校毕业生的综合素质达不到软件外包企业的用人要求。那么软件外包公司需要什么样的人呢?为了能够进入软件外包企业,在校学生应该如何学习和学习什么呢?

  说的简单一点,企业需要的是能马上融入外包项目团队,独立承担实际外包项目任务的人。所以很多企业在招聘启事中都有“x年软件外包相关工作经验”等的硬性指标,而这些都是在校学生欠缺的地方。

  现在一些外包公司都提供兼职岗位(Freelancer),这是在校学生(尤其是即将毕业的学生)参与社会实践的好机会,应该抓住这些实习机会,积累工作经验。另外,如果在这些企业实习期间表现优秀,毕业后有机会成为公司的正式员工。

  软件外包企业对待大学毕业生更看重学生的学习能力。刚毕业的大学生就像一块好的毛坯钢材,材质优良,如果这些学生有较好的主动学习能力,进入企业后经过几个外包项目的实践,积极思考,善于总结,成长很快。企业不欢迎凡事不经过大脑思考,大小问题都要向主管求助的“懒汉”员工。

  企业需要具有职业精神的员工。职业精神包括很多方面的内容,包括对工作的热情投入,积极与团队成员交流,具有合作精神,以企业利益为重。而不欢迎喜欢与企业讨价还价,抱怨企业提供的发展空间不够大的学生。

  由于软件外包服务行业是为客户提供服务的行业,很多外包项目的具体任务一般比较琐碎、枯燥,例如按照客户提供的软件框架进行编码,按照客户提供的测试用例执行软件测试。对于刚刚毕业的学生他们都需要从这些很基础的技术岗位做起,这是对他们职业精神和做事风格的考验。

  软件外包服务的很多工作就像生产流水线上的公司在拧螺丝钉,需要遵守严格的生产流程和一丝不苟的严谨精神。把这些基本工作做好了,才能取得企业的管理人员的信任,才有机会承担更复杂更大责任的工作。

  一些刚毕业的学生经常心高气傲,很鄙视这些繁琐枯燥的工作,感叹埋没他们的才华,这是没有摆正工作心态的表现。外包公司非常欢迎愿意做看似琐碎的工作同时有能力做好的同学。其实做好这些看似琐碎的工作,当好拧螺丝的工人,就是不简单,他的未来就会不平凡。道理很简单:基础打好了,万丈高楼平地起。

  总结起来,外包企业需要具有一定的外包工作经验,主动学习能力强,团队合作精神好,愿意从琐碎的技术工作做起,而且有能力做好“小事”的人。

  海尔公司总裁张瑞敏有句名言说得非常好,对于准备到软件外包公司工作的同学非常有启发,他说:“把一件简单的事做好就是不简单,把每一件平凡的事做好就是不平凡”。

  8、哪些人不适合做软件外包技术人员?

  大千世界,无限精彩。作为软件行业的新领域,软件外包吸引着越来越多的人投入这个行业。每个行业都有行业的行规和准则,并不是任何人都适合从事软件外包行业的。

  哪些人不适合从事软件外包呢?由于本文的读者针对即将毕业的大学生,也适用于准备加入软件外包公司的新人,所以我们可以把问题缩小范围:哪些人不适合做软件外包服务的技术人员?

  回答什么人不能做软件外包,也就是哪些人做不好软件外包,需要先了解软件外包服务行业的工作性质和对人的综合要求。软件外包是为客户提供专业技术服务的行业,而且现在的软件外包企业的客户大都来自国外,客户对外包公司人员要求比较严格。另外,外包公司的工作非常具体和琐碎,需要一丝不苟。

  软件外包行业的这些特点,决定了以下三种类型的人不适合做软件外包的技术人员:

  第一种人是外语不过关的人。

  语言是交流工具。如果客户是欧美客户,英语交流是必不可少的。如果客户是日本公司,对日语要必须熟悉。作为初级的外包技术人员,需要阅读和写作大量的文档和邮件,这些都需要良好的英语能力。很多英语不过关的人员不容易通过外包公司的笔试。对英语的要求,需要达到熟练阅读英文文档,写作专业的测试缺陷报告和日常邮件写作的程度。

  外包公司强调英语的重要性,这是做好工作的基础,因此,请在学校里、公司里利用一切条件自觉学习英语,养成习惯,从阅读理解学习。把英语阅读和写作养成一个习惯,终生受益。

 第二种人是痴迷于钻研软件高深技术的人。

  软件外包服务的很多工作都是非常琐碎的,看上去没有多少高深新技术的事务性工作。例如,对日软件外包的项目,客户已经编制好了程序框架,需要变成人员根据他们的规范编写代码和每天工作进度日志。不少外包编程人员抱怨客户限定的过于严格,没有足够的自我创造的空间。对于软件外包测试人员,最常见的工作就是执行客户编写好的测试用例,报告软件缺陷,很少有机会从软件项目的全局高度制定测试计划,确定测试方案和策略,安排资源和进度。

  如果你对软件编程的各种新技术无限热爱,习惯于一个人无拘无束的从事软件产品的开发,最好不要去软件外包公司,否则很难发挥你的聪明才智。这样的人更适合自己创业开发独立的软件产品,或者到中国中小型软件公司当软件开发工程师。

  第三种人是大事做不来,小事不愿做的人。

  正如前面说过的,很多软件外包工作非常具体和琐碎,需要非常好的做事态度,满足客户各种合理的和不合理的要求。有些同学到软件外包公司工作不久就感到失望了,抱怨工作枯燥,看不到前途。这些都是刚参加不久的人容易产生的错误认识。

  在任何软件外包公司,如果个人的工作能力非常突出,很容易被领导赏识和提升,因为软件外包发展太快了,对人才的需求非常强烈。但是如果不从具体的琐碎的小事做起,并且把小事做好,怎么能证明你可以把大事做好呢。

  任何公司之所以能够生存、发展、壮大,必尤其成功之处,不要觉得你必老板高明很多。比较聪明的同学会放平心态,从学徒学起,把每一件工作都做好了,自己的长处得到发挥,对自己的前途发展大有帮助。

  总结起来,不善于外与交流的,痴迷于钻研软件高新技术,不能踏踏实实工作的人,不适合到软件外包公司从事软件技术工作。

  9、如何通过软件外包公司的面试?

  如何通过软件外包公司的面试?这是很多同学都很关注的问题。面试成功来自于应聘者自身的综合实力和运气。为了提高面试成功率,请按照以下几个方面进行准备。

  (1)制作有吸引力的求职简历

  外包公司的招聘专员每天都会收到几十封甚至上百封求职简历,如果你的简历很平淡,可能很快从招聘专员的眼下溜走,失去了面试的机会。

  什么是有吸引力的简历? 简单地说就是让看到你简历的招聘专员相信你就是他们正在寻找的最合适的人。因此,你的简历要简明扼要,列举出符合他们要求的条件和相应的客观证据。要明白求职简历目的就是获得面试的机会,否则你的水平再高,也不可能进入招聘专员的“法眼”。

  如何写出具有吸引力的简历,现在很多资料都比较详细,但是最重要的一点是实事求是,反对夸张和吹嘘。把你的技能和经验按照招聘职位的要求进行内容和形式的组织即可。

  (2)准备面试

  ● 了解要去面试的公司,可以浏览公司的网站,媒体报道,同学和朋友的介绍。
  ● 了解公司的行业,规模,现状和发展概况。
  ● 技术准备,准备应聘职位要求的技能
  ● 模拟面试场景(包括英语自我介绍和书面答题)
  ● 准备自我介绍、各种证书、笔试和面试解答问题
  ● 计划乘车路线和穿着打扮等外表形象

  (3)参加面试

  ● 准时
  ● 诚实
  ● 积极
  ● 友好
  ● 不必不亢
  ● 注意细节
  ● 沉着冷静
  ● 避免争论
  ● 小心“陷阱”
  ● 充分发扬长处
  ● 展示个人综合能力









posted @ 2011-11-23 10:22 顺其自然EVO 阅读(681) | 评论 (1)编辑 收藏

软件测试管理给我的三大启示

软件测试管理给我的三大启示

 1、软件测试团队组成应该是技术背景的人员为基础

  现在大部分的国内软件公司测试人员基本对于编程的了解非常的浅显,像专业性很强的软件产品可能更多的是业务人员组成的测试团队,比如我目前的ERP产品测试团队大部分人以往都是从事财务、供应链和生产制造的从业经验,他们在业务流程以及行业知识上较为丰富,但对于软件开发基本都没有概念。专业的公司例如google,微软等他们的测试人员都是由开发人员转入的,测试人员甚至能力强于开发,因为开发不会测试,但测试会开发。业务人员主导的团队和技术人员主导的团队截然不同,从思维还是方法上都有较大的差异。业务主导的测试会从业务的角度去验证产品,但他们可能选择的是“最笨”的办法去一遍又一遍去验证业务流程,当业务流程有成千上万或者网状业务流的时候就傻眼了,因为你永远不可能完成所有的业务验证。技术主导的测试就不一样了,技术人员的天性决定了,他们从测试的第一步开始就想着如何能够使用最为简单,更为聪明的方式去验证业务流程,他们甚至会绞尽脑汁的去设计测试脚本,通过最高效的技术手段去使用最为聪明的方式来全面验证业务流程,因为他们有良好的技术。很多深层的缺陷从黑盒的角度可能是永远无法发现的,但对于技术测试人员来说可能就是轻而易举的事情。测试团队的构成应该更加合理,技术测试和业务测试的结合是非常必要的,这也是目前国内软件公司最为欠缺的,这也是为什么现在测试在国内无法得到足够的尊重的重要原因,因为缺乏技术含量!

  2、开发人员对于产品质量的保证是核心关键

  当我们的测试人员每天随随便便就能轻松发现数十上百的缺陷,并甚至以此为优秀测试人员评价标准的时候,google的测试人员却在为每天能发现2个缺陷而高兴,甚至为了这2个缺陷还要编写大量的测试脚本和测试模型。因为他们在前段编码环节就已经做到了良好的质量控制,对于测试已经是精益求精的。现在国内的很多软件公司开发人员管的就是开发,好一点的公司可能会要求一些单元测试,但要求的深度缺乏衡量的标准。老师问了我,我们公司编码的效率,我说人均200行/天,他非常的惊诧,因为他们公司的编码效率是40行/天。因为他们每天除了编码,还要做好多质量保证的事情,首先开发人员要对需要编码的功能做设计分析,思路清晰后才开始编码,编码完成后要花将近一半的时间去做单元测试,来保证编码的质量。所以到了测试环节,每天就只能发现零星的几个bug。这个太让我吃惊了。对于我们经常会以任务紧,没时间等客观因素压缩设计和单元测试的时间,短期的效率换取的是长期的痛苦,甚至是用牺牲品牌的价值而换取的。

  3、自动化测试要做前后端分离的测试,UI的自动化测试不可取

  听到这个其实对我是一种打击,因为我们风风火火的自动化目前较多还是基于UI的测试,确实由于业务的复杂度以及更新的频度对于我们自动化的测试冲击非常大,用例更新维护的成本甚至超过了自动化测试本身带来的价值。对于功能、界面频繁变动的产品不太适合大量使用UI自动化测试。但产品的现状又不可能为了自动化测试的需求而进行大幅的更改。这个问题还在冥思苦想中。自动化测试4年了,从无到有,取得了突破性的进展,但目前却是一个转折点,如果最大化体现自动化测试的价值任重道远。从UI自动化到底层自动化突破是扭转自动化测试的关键。

  突然好想去微软、谷歌、甲骨文、IBM这样的卓越企业,想去接受高成熟度的IT公司的洗礼。相信能从他们那里学到很多很多。唉,可惜只怪自己英文太烂!进这样的跨国企业没什么机会。

posted @ 2011-11-22 17:21 顺其自然EVO 阅读(222) | 评论 (0)编辑 收藏

敏捷测试理论以及实践(7)

 5、传统测试阶段

  当开发完成了所有的功能点,测试那个时候也差不多完成了这些功能点的测试,我们就会有一个阶段性的最终版给客户评估,让客户看看需要的功能是不是都已经可以了,如果觉得没什么问题,一般情况下就不进行功能添加与更改了。(当然,真的要更改我们还是会欢迎的,不过一般客户也知道,频繁的更改不能保证产品的质量,所以到最后他们一般有不紧急的更改也会要求放在下一个版本里的)

  到目前为止,真正意义上的敏捷测试阶段其实已经完成了,要开始进入一些传统的测试了,比如系统测试性能测试,压力测试等。这些就会用到之前说的DevTest里管理的测试用例,通过这些测试用例,我们会生成测试任务,然后通过手工和自动的方式,把这些任务完成,当然,可能要进行几轮,第一轮测试最仔细,覆盖面最大,所以时间也最长,第二轮主要是对开发修Bug的确认以及可能影响到的功能的测试,最后还有一轮验收测试,主要对基本的功能进行测试,确保不会出现明显的问题。

  这些测试都完成以后,差不多产品也就可以发布了,当然能不能发布,领导们还是会有一个会议研究通过的,不过也就是通过 DevTrack 和 DevTest 来导出一些报表看看测试情况来了解产品质量。

  以上差不多就是我们公司现在的一个流程,从严格意义上来说,不是完全的敏捷测试,只是算一部分,但是如果从以前的瀑布来看看,已经算很敏捷了。而且,从现在这个流程分析,如果把那些传统意义上的测试继续敏捷化,我们觉得对产品的质量没法保证,所以基本上,目前这个模式,可以算是我们公司特色的敏捷测试了,之后应该不太会有大的更改了。

  接下来我再总结一下我们公司的模式,以及补充一些之前没提到的,因为之前写得太急,有时候很难想得太全。

  我们公司测试模式按照顺序主要有以下这么几步组成:

  1)需求阶段测试研究设计方案是否符合要求

  2)开发编码期间完成测试用例

  3)开发完成一个功能的编码,测试就需要开始测试,并且确保能在一个迭代周期中完成测试,并且确认严重Bug的修复

  4)所有迭代周期完成后,开始进入集成测试,系统测试,验收测试以及压力测试,性能测试

  差不多测试需要参与的工作就是这几步了,下面就是有一些细节点讨论一下,我会以问答形式来介绍:

  (1)问:发现了很多Bug,测试人员怎么知道哪些Bug要马上修,哪些可以推迟修呢?

  答:首先,我们会规定什么样子的Bug需要什么样的优先级,比如报错优先级就会比较高,每个测试人员都有这么一个文档让他们来判断这个 Bug 是什么级别。其次,我们会有专门的人员对这些Bug进行二次过滤,由他们来觉得这个Bug是否需要在这个迭代周期中进行修复,这种专门的人员的能力需要很高,因为他们需要能了解这个Bug的重要性以及这个Bug修复起来所需人力物力是否能在这个迭代中解决,所以一般这个角色会有测试主管或者项目经理来承担。

  (2)问:整个测试期间,就专职的测试人员参与测试就行了吗?

  答:不是的,首先开发肯定需要进行单元测试;然后设计人员和项目经理也要参与测试,因为只有他们最清楚这个功能设计的初衷,才能真正知道现在做完的是不是真的符合当初的初衷;再次,客户也会参与测试,因为产品说到底最终是给客户使用的,他们当然想拿到一个他们满意的产品,所以我们会定期给客户版本,让他们对做好的功能点进行简单的试用,让他们来看看产品是否符合他们的需要,这样就是最直接的用户体验了,发现的问题也是最真实的。 
(3)问:测试过程中是否需要开会?

  答:需要,测试人员也会有每日立会,跟开发差不多,也是介绍,昨天做了什么,今天要做什么,之前碰到什么问题。会议效果很好,首先让大家知道其他人在测啥,然后如果有问题的话,大家一起讨论就可以共同进步。另外测试也需要有反思会,看看这一轮发生的问题,为什么有些Bug没有找到之类的。

  (4)问:敏捷是否需要特别的测试技术?

  答:不需要,敏捷只是一种思想,有一些价值观,它不会教你用什么方法去测试一个产品,只会教你以怎么样的一种态度去做测试,以怎么样的时间安排去开展测试。

  (5)问:敏捷是否还是需要回归测试?

  答:需要,回归测试仍然属于一个比较重要的环节,不管是敏捷还是传统的测试,只是由于敏捷测试中对时间的要求越来越高,使得本来需要大量时间的回归测试越来越难实施,所以目前的趋势是尽可能把回归测试用自动化测试来实现。对于我们公司而言,这也是一个方向,有些部分也在开始,但是由于产品逻辑比较复杂,很多功能有自动化测试实现会比较麻烦,所以现在我们的回归测试有相当一部分还是人工的方式,当然最终必然是会大部分采用自动化测试的。

  (6)问:对于重复的Bug,怎么去处理?

  答:其实我也咨询过不少公司,很多公司是不允许重复提交Bug的,所以提交之前需要先去确认是否其他人提交过,我相信这个确认过程应该会花费不少时间,不过对于开发而言应该会减少时间,因为不会出现重复的Bug;当然也有一些公司允许重复提交的Bug,原因也很简单,觉得对于Bug而言,只要是必须修的,发现了就得提,别人提过当然最好,但是就怕别人没提过,你却认为提过就不提了,最后客户发现就惨了。所谓“宁可错杀一千,不可放过一个”就是这个道理了,呵呵。我们公司是允许提重复Bug的,当然是在不知道有其他人提过的前提的,你如果已经知道别人提过了,当然就不能再去提了。

  敏捷测试差不多就讲到这里了,也许有人清楚有人迷惑,水平有限,也没法讲得太好,望见谅。如有问题,可以私聊。谢谢大家一直看完!

  (全文完)

posted @ 2011-11-22 17:20 顺其自然EVO 阅读(167) | 评论 (0)编辑 收藏

软件项目管理实践之如何实施质量控制?

  质量控制包括对项目管理过程绩效和项目可交付成果的质量控制。质量控制主要通过文档评审、技术评审、代码走查和测试检查实现。

  一、技术评审

  技术评审包括技术文档评审、技术实现评审和代码走查。

  1、文档评审

  实施过程前期产生的需求规格说明书、系统设计说明书、测试用例等文档是后期编码、测试的主要依据和输入,这些文档的质量直接决定了软件系统的好坏、系统返工的多寡以及客户满意度。因而对这些文档的评审尤为重要,评审的目的在于在交付给下游开发或测试时及早发现问题,修正错误,以免问题和错误在系统中的蔓。

  文档评审采用同行评审会议的方式进行,由项目经理组织,开发相关文档参与的角色包括其他子系统的系统分析员、质量控制部相关人员、其他兄弟部门有类似经验的系统分析员等;测试相关文档则由项目经理、测试经理、系统分析员和其他测试人员参与。评审过程中,主要从以下几方面考察文档的质量:

  ● 可读性。主要从文档是否符合公司模板规范、逻辑结构层次是否清晰明确、文字表达是否无歧义等方面判断;

  ● 完整性。主要从文档是否完全满足要求,是否已覆盖所有的功能点等方面判断;

  ● 一致性。主要判断文档表述是否前后不一、是否有矛盾等;

  ● 技术可行性。主要判断目前的技术框架是否支持,是否有类似的经验,是否有技术风险等。

  2、技术实现评审

  技术实现评审包括项目技术框架选型评审、具体某个模块的技术实现方法评审。技术框架的评审目的是为了在进入大规模编码开发前确认选择何种技术框架、判断现有的技术框架是否满足项目功能和性能需求、框架是否足够稳定以及可能存在的风险等;具体某个模块的技术实现方式评审目的是为了保证选择的实现方式目前来说是最优的、可以推广到其他模块使用的。技术评审通过评审会议的方式进行,参与的人员包括项目经理、系统分析员、开发人员、公司内部相关技术的专家、有同类项目经验的实施人员、质量控制人员等。

  3、代码走查

  代码走查主要是对软件代码进行复审,主要以高级程序员复审代码或同级别的程序员交叉检查的形式进行。代码走查的目的是通过抽查,保证代码的编写和注释符合编码规范,编码逻辑符合系统设计要求,减少测试返工以及因测试返工引起的来回沟通、回归测试等问题,降低管理成本,提高开发效率。

  二、测试检查

  测试检查是由测试人员根据测试用例对软件产品进行功能测试以及使用压力测试工具对系统进行压力测试。测试检查的目的是确保交付给客户执行验收测试前软件产品经内部严格测试,检查系统是否满足用户需求和符合实际应用环境的需要,从而增强客户对项目成功的信心。

  我们定义了五个测试检查过程,包括单元测试、集成测试、系统测试、客户验收测试以及确认缺陷已正确修复的回归测试。

  单元测试由开发人员自行负责,测试通过标准由系统分析员制定,测试团队核准,确保开发人员在提交代码前在本地已经过测试,主流程可以跑通,可以进入集成测试阶段。主要目的是通过自查自纠减少返工以及降低后续测试阶段中开发人员与测试人员之间的来回沟通成本。

  集成测试由系统分析员负责,通过集成开发人员提交的代码,利用Ant等自动化工具发布到测试环境。系统分析员选取典型的测试用例对软件产品进行测试,确保业务模块在操作过程中没有出现重大的业务逻辑错误以及页面方面的低级错误,可以提交到测试团队进行进一步的深入测试。测试过程如出现问题,进一步分析产生原因和影响分析后提交到JIRA系统中交由开发人员处理,同时在JIRA系统上进行缺陷跟踪。

  系统测试由测试团队负责,依照经过评审的测试用例对已发布可用于测试的软件产品进行全面的功能性测试,确保系统满足功能需求。测试过程中,发现的问题连同问题出现时的系统截图一并提交到JIRA系统中,由系统分析员分析后转由开发人员实施缺陷修复,同样的,在JIRA系统中进行缺陷跟踪。

  客户验收测试由客户需求负责人负责,测试团队配合完成。测试的过程也是对客户系统操作培训的过程,必要时,由系统分析员给客户演示和解释。客户需求负责人往往是业务骨干,精通业务规则,熟悉业务流程和操作,可以对系统进行更深入的功能测试,发现隐藏较深的缺陷或者因为考虑不周引致的设计缺陷。

  回归测试由测试团队负责,根据JIRA系统上的缺陷修复状态,对已包含缺陷修复的版本进行验证测试。测试过程不单是对缺陷修复进行验证,同时对因修复缺陷影响到的其他模块进行回归测试,确保缺陷被正确修复的同时不影响原有模块以及不引入新的缺陷。由于回归测试的工作量很大,我们使用QTP工具,通过录制测试脚本,使回归测试可以自动化执行,减轻测试团队的负担,提高工作效率。

  每周的测试情况以测试周报的形式体现,周报内容包括测试范围、测试过程中遇到的问题以及解决方法等。另外,周报还报告了缺陷的统计信息,包括缺陷总数(其中:本周新增的缺陷)、已关闭的缺陷总数(其中:本周关闭的缺陷)、已处理但未关闭的缺陷总数、正在处理的缺陷总数以及未处理的缺陷总数。通过这些信息基本上可以看出软件系统的缺陷趋势,从而为后续的决策提供量化支持。

  测试发现的缺陷我们使用JIRA系统进行跟踪和监控。测试人员在系统上提bug,由相应的系统分析员负责对缺陷进行原因分析和影响分析,必要时与程序员一起确认问题产生的原因和可能影响的模块,分析后转交由相应的开发人员进行修改,缺陷修复并经单元测试后发布到测试环境交由测试人员进行验证测试并关闭此问题,最后由客户进行验收测试后并确定发布版本和发布时间后予以发布。在这个流程中,测试人员验证测试时需要对该缺陷涉及的本模块其他功能和其他模块进行一轮回归测试,确保已修复的缺陷不再重复产生,其他功能不受影响。

  另外,为了确保已发现的缺陷不再重复出现,对于频繁出现的,如界面显示的是代码而非中文、缺乏信息提示、没有进行逻辑检查、后台计算结果有误等缺陷进行进一步的分析,找出是因为系统设计文档的缺陷、人为疏忽还是没有按照设计文档设计或其他原因所导致,从而制定相应的改进措施。

posted @ 2011-11-22 17:16 顺其自然EVO 阅读(457) | 评论 (0)编辑 收藏

初探团队基于session的探索性测试

如果你是一名测试人员,那么不管你对探索性测试的了解是多是少,我肯定你一定用过探索性测试的方法。想想看,你是否曾经这样测试过?不仅仅按照测试案例或者脚本上写什么,就完全使用那一套相同的数据、一模一样的流程,而是根据你执行时的所见,临时有所想和所动,进行一定程度的自由发挥?我想你肯定有过,这就是探索性测试,它将你的测试与纯基于脚本的测试(script. based testing)区分开来。而这种自由发挥,因为是有大致方向和范围的,所以也与完全盲目乱点的猴子测试(monkey testing)不同。

  换言之,因为你是人,所以你比猴子和机器人都聪明,你懂得在学习中不断完善自己,而不是漫无目的或者按图索骥。因为你是测试人员,所以探索性测试是你必备的职业技能。而如果不经过一定的理论指导和系统实践,我想凭着那点探索的本能,你还不足以成为一名高效的测试人员。如果想快速提高探索测试的技能,我认为最好的方法是和你测试组的伙伴一起来实践和提高,而不是一个人练习。如果你所在的团队还没有过这方面的实践,那么你可以从本文当中了解到我们团队中基于session的探索性测试的实践和感悟。

  为什么我们选择基于session的探索性测试?

  基于session的探索性测试在2000年由James Bach和Jonathan Bach兄弟俩创建。这里的Session其实就是一段指定的时间,比如从8:30到10:00的一个半小时。探索性测试可以不基于session。至少在读完J Whitter的“探索性测试”一书后我完全没有觉得session是探索性测试中的一个关键词。但是查阅探索性测试资料,你会发现实践中的探索性测试很多都是基于session展开的。我们实践了以下三个基于session的探索性测试的要点,并感受到了它的益处。

  1、因为session,更专注

  因为每个session都有确定的开始和结束时间,一般长度为一小时、一个半小时或者两小时,所以在这有限的且不算太长的时间里,测试人员会更专注,从而效率更高。

  我清楚地记得,有一天下午我们小组(4个测试人员)计划了两个各一个半小时的session。第一个session结束,当我们做debrief(下面会介绍debrief)的时候,有两个人明确提出下面即将开始的新的session能否改成一个小时,因为过去的一个半小时太累了,“大脑都要缺氧了!”当然,刚收获了近40个缺陷和近30个疑问的这个session,无疑大家都是很辛苦的。但是,从另一个方面,我们也看到,平时如果没有session,大家的专注程度是否还可以提高一点呢?对我而言,虽然感到这次和我平时个人做探索性测试的专注程度类似,但在一个集体做探索性测试的氛围下,似乎也更有时间的紧迫感了。我想这就象自己在家做模拟卷和在学校里和同学一起模拟考一样,总有那么点不同的压力。

  2、因为charter,强迫思考

  在一个既定的方向或者说章程(Charter)上一定要发现缺陷,这其实是强迫你思考和挑战自己的思维局限。

  我喜欢看钓鱼比赛的节目,也感到它和测试的相通之处很有意思。例如,钓鱼的挑战在于:如何在你已经非常熟悉、觉得无鱼可钓的水域找到鱼;如何在一个你不熟悉的水域,快速钓到大鱼;如果你可以自由选择,你将换到哪个水域(因为根据经验你猜想那里可能有大家伙)?精明的垂钓者不单有专业的钓竿(测试辅助工具),对天气、水域(软件工作环境)和鱼生活习性(被测系统的功能)的了解,还要有一些很重要的临场判断(根据前面几条鱼的大小和难易程度判断今天在这个地方钓上大家伙的概率,以决定下一步是继续在这里守株待兔还是马上转移)和一点点的运气。关于运气,我觉得测试中也一定是有的,但是我更相信机遇或者运气是比较垂青有准备的头脑的。所以,我总是愿意花时间去多测测,花心思去少测测。

  想想测试中,我们是否也面临和钓鱼类似的挑战?如何在你已经测试了一段时间,觉得比较稳定的功能上找到新的缺陷?如何在你不熟悉的模块,快速找到缺陷?如果一种方法找不到缺陷,接下来该换种什么样的思路?

  突破自己思维的局限,我们团队中每个人都在实践多种不同的方法。比如,探索性测试一书中的各种方法(遍历法、强迫症法、取消法、超模法。。。),自创或者借鉴的各种测试的常用方法(web测试要点、安全测试常用方法。。。)以及Test Explorer工具的小提示等等。

  当我们设定所有测试人员都采用同一种方法来测试的时候,报出的不同的缺陷往往非常令人印象深刻。我们也在一起分享、总结、积极寻找测试某个软件的最管用的探索性测试方法是哪一两个。强迫自我突破,学习他人突破,三个臭皮匠顶个诸葛亮!

  3、因为汇报(debrief),团队力量胜于个人

  我个人觉得,个人的探索性测试和团队的探索性测试在流程上最大的差别就是汇报(debrief)。这是一个session结束后的短暂讨论环节。我们采用的是Jon Bach提出的PROOF模式。PROOF即Past, Results, Obstacles, Outlook, Feelings的首字母缩写。按照这个形式,我们会逐个分享过去这个session自己完成的工作、得到的结果、碰到的困难、接下来需要进行的工作(可以作为下一个session的目标)、自己的感觉。在这个环节里,我们会对一些公共的问题或者大的障碍进行一些沟通,但不会太长时间讨论,而主要是让团队成员知晓一些我们认为重要的信息。这里,我们经常能够发现共鸣或者别人轻易就解释了我们的疑惑。如果我们做的charter是同一性质的,如易用性,那么我们会在每个人都以PROOF模式做简要汇报后,按照session报告中缺陷和问题的记录,快速过一遍每个缺陷和问题。这对于我们能够及时学习和借鉴别人的测试思路,马上运用到自己接下来的测试过程有一定的帮助。我感到:通过debrief环节的及时沟通和互相学习,我们将探索测试的精髓也扩展到了我们的团队学习和实践中,即在一个很短的周期内,学习和执行是融为一体的,而不是顺序的、隔离的。

用ET测试自己的模块和别人的模块

  1、测试自己的模块

  当用探索性测试方法测试自己的模块时,在功能方面能更为有效地发现缺陷,尤其是那些复杂功能。另外,我们觉得有些探索性测试的方法应该被本模块负责的测试人员优先采用而保证其质量,不应该由别的测试人员来尝试。比如,确保所有按钮都可以工作,所有报错信息都正常显示,所有字段最大长度检查都通过等。因为如果一个别的测试人员随机地去检查字段长度,而结果是被测的正好没问题,漏测的地方正好有问题,这就可能给团队一个错误的信息。这种情况属于基于脚本的测试没有到位。或者别的测试人员逐个检查每个字段长度而发现全部都没有问题,最后才知道这是因为已经被本模块测试人员测试过并且缺陷被修复过了,这就是一种资源的浪费。

  2、测试别人的模块

  (1)为什么要测试别人的模块?

  有人也许会问:“如果每个测试人员都可以熟练有效地运用探索性测试方法来测试自己的模块,那为什么要互相交换,去测试别人的模块呢?”这是个很好的问题。带着这个疑问,我们尝试了测试别人的模块,并发现了以下的必要性和好处。

  ● 避免自己难以发现的问题被遗漏

  人无完人,测试人员也不例外。每个人每次测试中的盲点并不都能被自己及时发现。而换个人,这样的问题容易很快被发现。对于团队来说,这是一种高效的做法。

  ● 利于知识传递和储备

  测试别人的模块,利于及时深入了解被测对象的详细复杂逻辑。当你被要求去探索性测试一个不熟悉的复杂功能时,如果事先不做一些功课,相信你甚至都很难订出一个自己觉得合理的charter。硬着头皮上的后果是在一个明明有大贝壳的沙滩,花了时间却只捡到一些零零碎碎的小贝壳。这对组织是危险的,对自己也是令人沮丧的。

  ● 有很多好的问题(issue)被提出,或者再次被提出

  不难理解,因为视角不同,交换测试的时候会有很多好的问题被提出。再次被提出是指原来测试的人员也有类似的感觉,但不那么强烈;或者曾被诸如“用户不会这么做或者这样想”而遭到过开发人员的拒绝。这种问题一旦被再次提出,往往就更具有说服力,值得旧话重提。

  (2)测试别人的模块时如何选择charter?

  经过实践,我们发现利用探索性测试测试别人的模块时,在易用性、用户界面显示、模块交互、类似功能的一致性等方面能够高效地发现有价值的缺陷。

  (3)测试别人的模块时应避免的情况

  为了避免资源的浪费,我建议在测试别人的模块的时候先告知原来负责测试这个模块的人员你接下来的session里测试的范围和方向。尽量不要去测试那些已经做过大量测试的非主要功能,而主要功能则可以运用以前没有运用过的探索性方法再深入测试。比如,原来的测试人员在主要功能的数据多样性方面已经进行过大量测试,而按照操作顺序这种探索性测试方法相对运用得比较少,这就将是你的更好的方向。

  另外,测试时报告的缺陷数量固然重要,但我们的目标不是报告更多的缺陷,而是报告更多有商业价值的缺陷,所以应该避免在一些很边缘的或者细小的地方报很多类似的缺陷,同一类型的小缺陷算一个缺陷就够了。

  (4)如何看待别人在你的模块报告的缺陷?

  正如在你的一亩三分地上,当你自己已经觉得收割完毕,而看到别人仍然收获颇丰的时候,除了不敢相信,我很难想像你会有更开心的第一反应。而我觉得人与人的差别往往在于第二反应,在于不敢相信之后你会做什么。当别人在你的模块报告较多的缺陷时,大多数人会仔细看一下,确认到底是什么问题,接着以“了解了”结束。有一部分人会想“如果也给我一个同样charter的session,我能报出这个缺陷么?为什么?”还有人会去汇总背后的原因,分享这些心得,以后测试的时候能提醒自己和团队朝这些方面改进。

  经过初步尝试团队的基于session的探索性测试,我感到了其与个人的基于session的探索性测试的互为补充之处,也实践了如debrief这样的团队实践。下一步,我们将对测试的结果进行分析,持续探索利用探索性测试提高测试有效性和效率的有效方法。

posted @ 2011-11-22 17:08 顺其自然EVO 阅读(235) | 评论 (0)编辑 收藏

步步学LINQ to SQL:使用LINQ检索数据

 该系列教程描述了如何采用手动的方式映射你的对象类到数据表(而不是使用象SqlMetal这样的自动化工具)以便能够支持数据表之间的M:M关系和使用实体类的数据绑定。即使你选择使用了自动生成类的工具,理解这一实现过程可以让你更加方便地对你的应用程序加以扩展。

  第一篇:步步学LINQ to SQL:将类映射到数据库

  一旦你将数据库表映射到对应的类对象上并在DataContext中申明了到数据库的映射关系,你就可以不需要使用一行数据库代码(SQL语句)访问数据了。

  通过一个简单的示例BookCatalog(强类型的DataContext)来说明,你可以通过使用在Authors,Books和 Categories中定义的集合从数据库中访问book,author和category。

  例如,要查找书的类别,你所要做的就是循还bookCatalog.Books对象并且LINQ会自动地查找数据库(通过映射关系)并填充你使用的集合---使用Book类为要查找的每本书创建一个实例:

BookCatalog bookCatalog = new BookCatalog( );
foreach( Book book in bookCatalog.Books){
string title = book.Title;
decimal price = book.Price;
}

  你也可以使用LINQ来过滤这些结果集,因为大多数时候,你并不要一次返回所有的书或者基于性能方面的考虑也不会这么做。

  LINQ提供了一套完整的类似于SQL语法的语言,该语言已经被集成到了.NET语言(C#,Visual Basic)。对该语法的描述超出了本文的范围,下面我们一起看两个例子以了解它们是如何使用的。

  因为BookCatalog返回一个集合对象,我们使用的查询语法将会查找这些对象(意味着你将直接使用对象名以及它们包涵的字段或属性而不是数据表的字段)。因此,例如,如果你仅仅想查找价格低于$30的书籍,你可以使用一个LINQ where从句,该从句可以仅仅只从bookCatalog.Books集合对象上查找价格低于$30的书:

IEnumerable cheapBooks = from book in bookCatalog.Books
where book.Price.CompareTo( 30m ) < 0
select book;

  LINQ的延期执行意味着对books集合的检索不会即时从数据库取得直到实际需要时才进行(例如,使用一个foreach循还),因此我们可以保持应用的过滤条件,然后限制查询的数据以确保读取数据的效率。

  例如,你以后可以使用LINQ提供的orderby语法来定义上面的结果集将数据按书的标题进行排序。

IEnumerable sortedBooks = from book in cheapBooks
orderby book.Title
select book;

  现在,如果你在执行了LINQ查询链之后通过sortedBooks执行循还,仅仅只会执行一次数据库查询。其结果仍然会返回价格低于$30并且按照书的标题排序的所有书。

BookCatalog bookCatalog = new BookCatalog( );
IEnumerable cheapBooks = from book in bookCatalog.Books
where book.Price.CompareTo( 30m ) < 0
select book;
IEnumerable sortedBooks = from book in cheapBooks
orderby book.Title
select book;
foreach( Book book in sortedBooks ) { ... }

  现在我们一起看看如何映射对象之间的关系以便你能够操作这些对象(例如book.Author.Name)。

posted @ 2011-11-22 16:37 顺其自然EVO 阅读(253) | 评论 (0)编辑 收藏

以小见大、由浅入深-谈如何面试Javascript工程师

 面试Javascript工程师难吗?Javascript工程师的水平参差不齐,如何评定他们技术水平的高低?如何确定Javascript工程师适合承担哪方面的任务?我在腾讯时的面试经验是,通过不同纬度的结构化问题、由浅入深的进行考查。

  基础

  如何判断一个对象是方法?这个问题简单有简单的答案,复杂有复杂的答案,但可能都不是最好的答案。

  页面加载和渲染的过程:简单一点只考查JS、CSS、IMG的加载顺序和过程,复杂一些则涉及内核间的差异以及并发处理。对于这个问题是否理解是写出高效率代码和结构的必须。

  冒泡与捕获:它们的定义,它们的区别,如何阻止冒泡?基础知识,经典题目。但是不是每个人都能完整全面的回答出这个问题,面试者需要对DOM tree有自己的理解。

  闭包:闭包是一个很好的面试题目,能够很好的考查出不同水平的面试者。了解什么是闭包、如何使用闭包、闭包的原理、闭包的真正原理,只有对JS的作用域链、垃圾回收机制有深入了解的工程师才能正确无误的完整回答这个问题。

Scope Chain是了解Closure原理的关键

  工具库

  jQuery:考查编程习惯和经验。jQuery作为现在使用最为广泛而且最简单的JS库,能够很好的测出使用者的开发经验和JS水平。一个有着真正开发经验的工程师,应当能正确的写出各种类型的选择器,回答为什么用bind来进行事件绑定、mouseover和mouseenter的区别。如果这些考不倒他,别急,live方法的实现原理、ready方法的实现机制这两个问题足以考查出他对DOM、浏览器差异的认识。

  extJS、YUI、Prototype:这些工具库或框架都有各自的特点,可以采用像上面类似的问题从浅入深进行了解。

  实际问题

  解决实际问题考查的是你把知识融会贯通的能力、解决问题的能力、理解能力以及学习能力,这对综合素质的考查是一种很好的方式。第一次面对一个问题,面试者是否能迅速给出思路、由过程推导出结果,能否在一些提示下一步步得到最终的完整答案,这都是很好的考察点。

  Autopager:自动翻页功能是一个由浅入深考查面试者能力的好例子。对滚动条事件的了解,pageHeight、windowHeight、scrollY的区别和关系是两个关键点,而最后对于事件的clearTimeout优雅处理是隐藏的考查点。

 Lazyloader:许多人见过图片延迟加载的产品,但是他们是否有了解过背后的实现原理?从功能抽象到具体实现,onresize的考虑、延迟触发的考虑,这道题目有一定难度,和上面的例子也有一定相似之处。

  经过了前三个方面的了解,你应该已经对这个面试者的基本水平有了一个大致的判断。下面的步骤可以让你了解这个人能够承担什么样的工作,他的发展潜力多大。

  项目

  通过之前的项目经历可以认识他的Team work能力、解决问题的能力,在项目中的角色和承担的责任也可以反衬他的个人能力。

  如果他没有做过跨浏览器开发,那么这种需要长期积累的任务就不适合分派给他来解决;如果他曾经有浏览器插件的开发经历,那么浏览器App的工作也许能够利用他的现有经验;如果他用过jQuery Mobile、sencha touch或者XUI,那么他可能适合开发移动Web App。作为管理者高明的地方在于,把合适的人用在合适的地方。

  技术视野

  具有技术视野的人一般具有很大的发展潜力,他们未来不会仅仅只是一个普通的工程师,而有可能会成长为技术专家或者技术管理者。

  在HTML5方面应当对新的语义标签、Canvas、Webworker、Drag & Drop有所经验或者了解;在CSS3方面,应当或多或少尝试过Radius、Gradient、Transform。当然,如果能够了解Mask,甚至能够知道Flexible Box的使用方法和原理,那么这个人对盒子模型的理解和对新知识的学习能力可以得到很好的体现。

  JS开发工程师是最容易的职位,也是最难的职位。新的技术和框架层出不穷、浏览器版本日新月异、越来越多API的出现,好的JS开发工程师需要随时学习和更新许多知识,包括后台(Webworker、Websocket、Node.js)、UI(Canvas、Transparent)、动画(Transform、Transition、Animation)等方面。面试者是否有自我更新意识,他的技术视野多高决定了他能够涵盖的范围多大,他的未来发展潜力多大。

HTML5已经战胜移动Flash,前途无量

  如果能够把以上所有问题清楚、顺利的回答完整,我相信他的表达能力、沟通能力应该是相当优秀的,同时值得欣喜的是,我们又找到了一位优秀的同伴。

posted @ 2011-11-22 15:50 顺其自然EVO 阅读(190) | 评论 (0)编辑 收藏

挨踢项目求生法则-战略篇

挨踢项目求生法则-战略篇

  摘要:

  知道什么是挨踢项目吧?什么!不知道?那IT项目知道了吧?为了不让客户踢、不让老板踢、项目组成员之间不互相踢,俺为大家分享一些减少被踢机会的心得体会。就算不能让项目成功,也至少不会死得那么惨吧!我将分战略篇、团队建设篇、需求篇、设计篇、编码篇、测试篇、实施篇和计划篇为你分享。

  什么叫挨踢项目?

  IT项目,特别是软件开发项目,都属于“挨踢”项目的范畴。挨踢项目的几大特点:

  1、需求不确定。
  2、技术不确定。
  3、工期限死。
  4、预算限死

  两大不确定和两大限死,你想不“挨踢”都难!

  指挥战争可能是最复杂的项目管理

  做挨踢项目可能比较杯具,但最复杂、难度最高、代价最大的项目管理可能是战争的管理了。战争靠什么取胜呢?如果你是这场战争其中一方的统帅,你会如何指挥这样战争呢?你可能会说:你不是在扯淡吗?说挨踢项目管理,怎么跑到战争去了?让我们先看看战争的战略管理,然后再回到项目的战略管理吧。

  白起的故事

  白起你不会没有听说过吧?就是那个杀死几十万赵国俘虏的杀人狂魔。但我说的不是他杀俘虏的事情,而是白起被称为战神,一生没有打过败仗,他是如何做到的?因为他只选择打战略上能打赢的仗!

  当时只有赵国有实力和秦国一战,双方几十万大军对峙在长平一带。秦军统帅是白起,赵军统帅是廉颇。白起对于此战的战略上的判断是这样的:两国实力、军力相当,如果全力出战,秦国能胜,但只能是惨胜,这样的后果只能是削弱了自己,反而让其他战国有机可乘。秦国的优势在于全国上下一心,特别是秦王和大臣们众志成城。而赵国虽然军力不错,但赵国内部权力斗争厉害,各派只为自己利益不顾国家利益。因此白起定下的战争策略是:对外称病不能担当统帅,隐藏自己做统帅的事实,以拖待变,寻找有利战机再出击。另一方面,秦国使出反间计,成功让赵国更换主帅,换了那个很出名的只会“纸上谈兵”的赵括。

  赵括上任后,全军出击,结果中了白起埋伏,白起利用地形,用基本相等的数量的士兵困住了几十万赵军,不与之决战,消耗赵军的粮草,最后赵军被迫投降。后面就是白起杀死几十万降兵的事情了。白起成功地用比较少的代价,给赵国带来致命的打击。

  白起杀死几十万降兵后,立马建议秦王马上挥军灭掉赵国。秦王认为此时出击必会促使六国合纵,这样秦国会招架不住;但白起认为,刚杀掉几十万降兵,其他五国还在震惊之中,没有这么快缓过气来,一时无法合纵,此时正是灭掉赵国的好时机!但秦王坚持自己的想法,白起只有退兵。后来秦王后悔了,想让白起率军灭掉赵国。这时白起认为:其他五国已经缓过气来了,此时攻击赵国,六国必会合纵。但秦王一意孤行,白起托病不统军,秦王另找人统帅,结果六国果然合纵,出现了“信陵君盗取帅印”促使魏国出兵的著名历史事件,秦军大败。秦王再次要求白起统帅,认为只要白起统帅必能获胜,但白起仍然推辞,最后秦王恼羞成怒,杀了白起。

  白起在战略上的判断是相当准确的,可惜他的老板和他想法不一样,白起拒绝执行战略上注定失败的决策,虽然避免了自己打败仗,但得罪了老板,下场凄惨啊!咱们这些做项目的,如果遇到一个战略上有问题的项目,你是做还是不做呢?

  庞涓的故事

  说起庞涓,大家可能马上想到的是他如何害孙膑,然后孙膑又如何设计杀之报复。其实庞涓是一个战略上判断正确的人,只是被迫执行了战略上有问题的决策。

  庞涓是魏国的大将,他对魏王建议的国策是:先西进灭掉秦国,解除后顾之忧后再图其他。秦国当时并不强大,多年与魏国争夺河西河东,“三十年河西三十年河东”的故事就是这样来的。但魏王认为:秦国很穷,但秦人很彪悍,灭掉秦国代价太大,没啥好处。魏王最想做的事情是灭掉赵国和韩国,所谓的“三晋合一”,魏、赵、韩原本同属晋国,后来他们将之瓜分掉。庞涓认为:灭掉赵国、韩国是不可行的,因为附近的战国,特别是齐国不会让魏国成功的,其他战国必会出兵。但魏王执意要先灭赵国,然后是韩国,让庞涓统帅。庞涓只能坚决执行老板的决策,率军猛攻赵国,就快攻克邯郸之时,齐国突然出兵突袭魏国的大梁,这就是“围魏救赵”的故事。庞涓只能回师救大梁,途中遇到伏击,损失惨重,但还不至于战死。

  魏王仍然不甘心,再次要庞涓统帅灭韩国,故事再次上演,这次是“围魏救韩”。庞涓再次回师,孙膑上演了“逐日减灶”的典故,让庞涓判断失误,率大军进入死地,被齐军伏击致死。

  庞涓同样在战略上的判断是基本正确的,但他的老板想法不是这样,庞涓作为老板的手下,他选择了坚决执行老板的决策,但仍然得不到好下场!

  遇到一个战略上有问题的项目,你不做会死,做也会死,怎么办呢?、


  认识软件项目的战略管理和战术管理

  上面两个故事,希望我能大概说清楚什么是战略。项目的战略大概就是指:能决定项目成败的宏观因素,如:甲乙双方在这个项目上的商业利益、双方领导的特点、项目的预算、目标、工期等,还有就是你所带领的团队是否有能力有条件完成这个项目等。

  战略上有赢的可能,加上好的战术,项目才有机会成功。

  战略上没赢的可能,无论用什么好的战术,项目都逃不过失败。

  战略上有赢的大好条件,但你的战术很差,项目也会失败,你浪费了一个大好的项目!

  希望我们能尽量选择战略上有机会赢的项目,万一运气不好,挑上了一个战略上没机会赢的项目,那么就要想办法不要死得那么惨。

  下面的法则供你参考。

  法则1:从战略高度出发

  客户为什么要做这个项目?我们公司为什么承接这个项目?

  合同的金额是多少?我们公司对这个项目的预算是多少?项目工期有多长?

  你的项目团队有什么人?每个人的水平和潜力怎样?

  有没有其他影响项目成功的重大风险?

  以上问题应该尽早搞清楚,通常来说可以在公司的高层领导那里得到很多重要信息,但如果你无法接触高层,或者高层不鸟你,你用尽所有办法都难以获取以上的重要信息,那么你基本上可以判断:这个项目死定!

  最怕遇到一些让你自己解决所有问题的领导,这些只能是无水平、不负责任的领导!除了合同金额一些涉及公司机密的内容可能不方便透露外,其他信息是必须让项目经理知道的,而且有些事情是需要高层出马帮助项目组去搞定的。

  遇到高层不鸟你的情况,法则1-4都没啥作用,你可以直接看法则5。

  法则2:尽量提高你在客户面前的地位

  通常情况下,我们需要门当户对地和客户接触,高层VS高层,基层VS基层。如果你是一位小小程序员,想和客户高层说话,这是大忌!

  很不幸的是,项目经理能经常接触的客户中的最高领导,只能是对方的业务骨干,最多是部门经理,而项目经理以下的项目成员,身份更加是低微了。

  为了让项目组将来的工作更加主动,要做好项目组成员的“包装”,例如让项目经理挂上副总、总监之类的头衔,尽量让项目成员的身份放大和提高。第一次和客户接触时,就要包装好你的高大形象。例如项目启动会上,以比较高的形象来展示项目组各成员。


法则3:让客户的高层重视项目

  越是高层的客户,越抓得住项目的目标,越是基层的客户,越容易陷入细节,甚至提出很多匪夷所思的要求。如果客户的高层能向下属明确本项目的目标和范围,那么客户的中层基层就比较容易搞定了。

  法则2做得好,就很有机会让项目经理可以直接接触到客户的高层,项目经理在掌握了项目的战略的情况下,了解了客户大致想法的情况下,就比较容易驱动客户高层做事情了。如果项目经理不好接触客户的高层,那么就要动用法则4,让你的高层去找客户的高层。

  法则4:驱动你的高层做事情

  项目中很多重大问题,方向性的问题,其实是需要我们的高层去做的。例如让我们的高层与客户高层明确项目的目标与范围,推动客户配合需求调研工作,推动上线试运行,推动验收等。项目中出现重大问题,会影响项目成功时,都应该第一时间将问题反馈给我们的高层,让高层去处理或给出建议。

  我不觉得你能解决所有问题才叫厉害,在项目组的层面确实有些问题是无法解决的,这些问题如果不及时让高层知道并让高层支援你,问题将会变得更加严重。

  如果你的高层是那种什么事情都让你自己搞定的话,那么本法则不适用,看“法则5:输少当赢!”

  法则5:输少当赢!

  如果是项目战略上判断觉得无赢的可能,但你的高层领导认为可以赢,执意要求你执行他的决策,那么本法则可能会让你不会死得那么惨。

  做一个战略上不可能赢的项目是很痛苦的,最佳选择是不做这个项目,但通常你没得选,你只能硬头皮上。你应该庆幸,不是让你做战争的统帅,你不会象白起或者庞涓那样会死得很惨,你最多是辞职不干!

  万一赢头皮要做这样的项目,只能是“输少当赢”了。向你的高层随时报告进展,遇到什么问题全部抛给他,美名其曰:向您请教应该如何处理!遇到与领导有某些分歧,你可以适当地争论一下,然后假装被你的领导说服,你还要装作很受教的样子。你只能在很有限的空间内,尽量降低这个项目的损失,尽量降低你将来需要承受后果的严重程度。将一些问题及时抛给高层,或许会有机会帮助高层重新思考自己的想法,逐步修正他对这个项目的战略判断,这样的话会慢慢变得对你有利。

  采用法则5时,是不得已的选择。如果想不做这个项目,恐怕只能选择辞职;为生活,只能暂时忍一忍,接手这个烫手山芋吧。

  关键是心态要好,尽自己力就OK了,对得起自己,也对得起这个项目。挨领导的批可能是不可避免的了,当他唱歌吧!

posted @ 2011-11-21 16:17 顺其自然EVO 阅读(133) | 评论 (0)编辑 收藏

性能测试计划VS测试实践

 许多人说,面向过程的工作是成功的关键。虽然我非常赞成这个说法,但我总是纳闷为什么人们对于性能测试的7个要点并没有特别关注,而这7个要点能左右性能测试项目的成败。

  当一个测试人员被分配到性能测试项目组,项目经理会让他/她做的第一件事就是着手准备测试计划。但在测试计划的准备阶段,测试经理及其属下在准备文档时通常会掉以轻心,文档的大部分内容要么是从以前的项目中复制过来的,要么是从网上找来的任意模板;对测试计划中提到的需求说明不予任何关注就直接转移到下一阶段了。不可否认的是:作为公司流程标准中的必须项,测试计划通常只流于形式;因此它从来没有真正用于连接项目的执行。

  我想说的是,用来准备测试计划的时间是整个项目实施期间非常有价值的部分。但不幸的是,所有这些多半都只是在理论上说说,很少用于实践。因此测试人员通常不会把测试活动和测试计划紧密的结合到一起,因为每个测试计划的实施都会受与此过程相关的费用影响,而且他们认为测试计划会延缓测试活动。

  这无疑是一件坏事,但即使你否定了这个项目计划阶段—若测试工程师在项目执行阶段认真遵循性能测试的7个要点,我觉得我们还是能在最后看到希望。

  7个要点:

  1、知道SLA指的是什么。


SLA 服务等级协议

定义

  SLA:Service-Level Agreement的缩写,意思是服务等级协议。
  服务等级协议是关于网络服务供应商和客户间的一份合同,其中定义了服务类型、服务质量和客户付款等术语。
  SLA: SoftWare License Agreement的缩写,意思也可为软件许可协议,像著名的GPL,BSD等均为典型代表.
  SLA: Second Language Acquisition的缩写,意思是第二语言习得。

项目

  典型的SLA 包括以下项目:
  分配给客户的最小带宽;
  客户带宽极限;
  能同时服务的客户数目;
  在可能影响用户行为的网络变化之前的通知安排;
  拨入访问可用性;
  运用统计学;
  服务供应商支持的最小网络利用性能,如99.9%有效工作时间或每天最多为1分钟的停机时间。
  各类客户的流量优先权;
  客户技术支持和服务;
  惩罚规定,为服务供应商不能满足 SLA 需求所指定。

要求

  按照 SLA 要求,服务供应商采用多种技术和解决方案去监控和管理网络性能及流量,以满足 SLP 中的相关需求,并产生对应的客户结果报告。
  另一方面,客户本身也提出了自己的技术及解决方案去监控邻居的流量和服务,以确保提供他们答应的传送服务项目。
  SLA概念已被大量企业所采纳,作为公司 IT 部门的内部服务。大型企业的 IT 部门都规范了一套服务等级协议,以衡量、确认他们的客户(企业其他部门的用户)服务,有时也与外部网络供应商提供的服务进行比较。

编辑本段服务水平协议

定义

  SLA 服务水平协议(简称:SLA,全称:service level agreement)是在一定开销下为保障服务的性能和可靠性,服务提供商与用户间定义的一种双方认可的协定。通常这个开销是驱动提供服务质量的主要因素。

内容

  一个完整的SLA同时也是一个合法的文档,包括所涉及的当事人、协定条款(包含应用程序和支持的服务)、违约的处罚、费用和仲裁机构、政策、修改条款、报告形式和双方的义务等。同样服务提供商可以对用户在工作负荷和资源使用方面进行规定。

保障

  传统上,SLA包含了对服务有效性的保障,譬如对故障解决时间、服务超时等的保证。但是随着更多的商业应用在Internet的广泛开展,越来越需要SLA对性能(如响应时间)作出保障。这种需要将会随着越来越多的商业在Internet 的开展而重要起来。实际上,SLA的保障是以一系列的服务水平目标(SLO)的形式定义的。服务水平目标是一个或多个有限定的服务组件的测量的组合。一个SLO被实现是指那些有限定的组件的测量值在限定范围里。SLO有所谓的操作时段,在这个时间范围内,SLO必须被实现。但是由于Internet的统计特性,不可能任何时候都能实现这些保障。因此SLA一般都有实现时间段和实现比例。实现比例被定义为SLA必须实现的时间与实现时段的比值。例如:在工作负荷<100 transaction/s前提下,早上8点到下午5点服务响应时间<85ms,服务有效率>95%,在一个月内的总体实现比例 <97%。

  2、了解真实用户的使用模式。

  3、知道如何加载服务器。

  4、知道负荷服务器的最大负荷量。

  5、明白自动化测试需要包含哪些类型。

  6、了解你的测试工具以最大化其功能。

  7、了解你的测试环境。

  你只要在脑海中牢牢记住这些要点是专业范畴内的一部分。你既不需要把这些归档,也不用把它们交付客户,你只需要实践。因为最后,客户既不会想知道你的负载测试计划有多好或多坏,也不会因你遵循的标准不同而生气,相反,客户在意的是你提交的结果的准确度和这些统计资料对改善应用程序的性能有多大帮助。相信我,深入了解这些要点的每个方面并认真执行,对得到负载测试的真实结果肯定会有所帮助。

posted @ 2011-11-21 16:09 顺其自然EVO 阅读(197) | 评论 (0)编辑 收藏

仅列出标题
共394页: First 上一页 360 361 362 363 364 365 366 367 368 下一页 Last 
<2024年11月>
272829303112
3456789
10111213141516
17181920212223
24252627282930
1234567

导航

统计

常用链接

留言簿(55)

随笔分类

随笔档案

文章分类

文章档案

搜索

最新评论

阅读排行榜

评论排行榜