51Testing软件测试网

 
 

常用链接

  • 我的随笔
  • 我的评论
  • 我参与的随笔

留言簿(3)

  • 给我留言
  • 查看公开留言
  • 查看私人留言

随笔档案

  • 2021年6月 (1)
  • 2021年3月 (1)
  • 2020年9月 (1)
  • 2020年3月 (1)
  • 2020年1月 (2)
  • 2019年12月 (3)
  • 2019年11月 (5)
  • 2019年10月 (1)
  • 2019年9月 (2)
  • 2019年8月 (14)
  • 2019年7月 (20)
  • 2019年6月 (15)
  • 2019年5月 (12)
  • 2019年4月 (19)
  • 2019年3月 (20)
  • 2019年2月 (9)
  • 2019年1月 (16)
  • 2018年12月 (17)
  • 2018年11月 (21)
  • 2018年10月 (16)
  • 2018年9月 (20)
  • 2018年8月 (22)
  • 2018年7月 (3)
  • 2018年6月 (1)
  • 2018年5月 (7)
  • 2018年4月 (1)
  • 2018年3月 (3)
  • 2018年2月 (6)
  • 2018年1月 (2)
  • 2017年9月 (8)
  • 2017年8月 (28)
  • 2017年7月 (3)
  • 2016年11月 (1)
  • 2016年6月 (1)
  • 2016年4月 (1)
  • 2016年2月 (2)
  • 2015年7月 (1)
  • 2015年5月 (1)
  • 2015年4月 (2)
  • 2015年3月 (1)
  • 2015年2月 (2)
  • 2015年1月 (6)
  • 2014年12月 (3)
  • 2014年11月 (3)
  • 2014年10月 (3)
  • 2014年9月 (2)
  • 2014年8月 (8)
  • 2014年7月 (16)
  • 2013年12月 (5)
  • 2013年11月 (1)
  • 2013年10月 (3)
  • 2013年9月 (2)
  • 2013年8月 (2)
  • 2013年7月 (3)
  • 2013年5月 (1)
  • 2013年4月 (2)
  • 2013年3月 (2)
  • 2013年2月 (3)
  • 2013年1月 (4)
  • 2012年12月 (4)
  • 2012年11月 (4)
  • 2012年10月 (3)
  • 2012年9月 (4)
  • 2012年8月 (3)
  • 2012年7月 (4)
  • 2012年6月 (2)
  • 2012年5月 (2)
  • 2012年4月 (1)
  • 2012年3月 (2)
  • 2012年2月 (2)
  • 2012年1月 (1)
  • 2011年12月 (3)
  • 2011年11月 (2)
  • 2011年10月 (1)
  • 2011年9月 (4)
  • 2011年8月 (3)
  • 2011年7月 (2)
  • 2011年6月 (4)
  • 2011年5月 (4)
  • 2011年4月 (2)
  • 2011年3月 (4)
  • 2011年2月 (4)
  • 2011年1月 (7)
  • 2010年12月 (7)
  • 2010年11月 (5)
  • 2010年10月 (4)
  • 2010年9月 (7)
  • 2010年8月 (7)
  • 2010年7月 (3)
  • 2010年6月 (3)
  • 2010年5月 (4)
  • 2010年4月 (4)
  • 2010年3月 (5)
  • 2010年2月 (3)
  • 2010年1月 (4)
  • 2009年12月 (3)
  • 2009年11月 (3)
  • 2009年10月 (1)
  • 2009年9月 (3)
  • 2009年8月 (2)
  • 2009年7月 (3)
  • 2009年6月 (1)
  • 2009年5月 (2)
  • 2009年4月 (4)
  • 2009年3月 (5)
  • 2009年1月 (1)
  • 2008年11月 (2)
  • 2008年7月 (5)
  • 2008年6月 (4)

文章分类

  • 行业资讯(45) (rss)
  • 软件业务知识(43) (rss)
  • 软件开发知识(33) (rss)
  • 软件测试工具(39) (rss)
  • 软件测试技术(157) (rss)
  • 软件测试管理(40) (rss)
  • 软件测试职业发展(57) (rss)

51testing软件测试网

搜索

  •  

最新评论

  • 1. re: 淘宝后台技术大揭秘,不看这篇你双十一要损失几个亿!
  • 关注官方公众号“Atstudy网校”,点击中间菜单栏“双11”,领取双十一技术内幕资料。
  • --51testing
  • 2. re: 软件测试流程的一点感悟
  • 提交缺陷时只需要描述现象即可,过多的分析可能会误导开发
  • --凡客诚品
  • 3. re: 软件测试流程的一点感悟
  • 阿达宿建德江阿斯顿
  • --凡客礼品卡
  • 4. re: 手机软件测试的经验总结
  • 很好啊~不错
  • --乐蜂网
  • 5. re: 手机软件测试的经验总结
  • 很好啊~
  • --罗莱家纺

阅读排行榜

  • 1. 软件测试流程的一点感悟(1091)
  • 2. 5年经验之谈:月薪3000到30000,测试工程师的变“行”记!(940)
  • 3. 测试自动化及软件测试工具的比较(858)
  • 4. 银行线上信贷系统如何做好接口测试?手把手教你接口工具Postman(825)
  • 5. 软件为什么要做异常测试?测试员必知的22个测试点总结!(807)

评论排行榜

  • 1. 软件测试流程的一点感悟(4)
  • 2. 软件测试的原则和经验 (4)
  • 3. 嵌入式软件测试技巧(2)
  • 4. 手机软件测试的经验总结 (2)
  • 5. 常用软件测试工具的分析与比较(1)

Powered by: 博客园
模板提供:沪江博客
IT博客 | 首页 | 发新随笔 | 发新文章 | 联系 | 聚合 | 管理

当个好的测试经理不容易,懂得这些很重要
 测试经理的工作:
  1、测试工作流程的搭建、完善;涉及部门的相关公司体制(例:绩效考核等);
  2、测试项目的裁决和资源分配,资源的分配,包括人力资源和一些软硬件资源;
  3、如果测试部门未进行测试人员的水平区分,或者测试部门人员比较少,那么测试经理自然也负责对部门内的培训工作;
  4、如果公司无单独的质量管理团队,那么相对测试经理需要做QA的角色。
  5、最后也是比较重要的一点,就是负责和各部门间的管理协调和沟通工作。
  中层经理人不论是作为一名执行者、还是一名领导者,都必须通过别人来完成任务。要做个“服众”的经理人,应该有意识地提高以下八项能力:
  1. 领悟能力
  做任何一件事以前,一定要先弄清楚上司希望你怎么做,然后以此为目标来把握做事的方向,这一点很重要,千万不要一知半解就开始埋头苦干,到头来力没少出、活没少干,但结果是事倍功半,甚至前功尽弃。要清楚悟透一件事,胜过草率做十件事,并且会事半功倍。
  2. 计划能力
  执行任何任务都要制定计划,把各项任务按照轻、重、缓、急列出计划表,一一分配部属来承担,自己看头看尾即可。把眼光放在部门未来的发展上,不断理清明天、后天、下周、下月,甚至明年的计划上。在计划的实施及检讨时,要预先掌握关键性问题,不能因琐碎的工作,而影响了应该做的重要工作。要清楚做好20%的重要工作,等于创造80%的业绩。
  3. 指挥能力
  无论计划如何周到,如果不能有效地加以执行,仍然无法产生预期的效果,为了使部属有共同的方向可以执行制定的计划,适当的指挥是有必要的。
  指挥部属,首先要考量工作分配,要检测部属与工作的对应关系,也要考虑指挥的方式,语气不好或是目标不明确,都是不好的指挥。而好的指挥可以激发部属的意愿,而且能够提升其责任感与使命感。要清楚指挥的最高艺术,是部属能够自我指挥。
  4. 控制能力
  控制就是追踪考核,确保目标达到、计划落实。虽然谈到控制会令人产生不舒服的感觉,然而企业的经营有其十分现实的一面,有些事情不及时加以控制,就会给企业造成直接与间接的损失。但是,控制若是操之过急或是控制力度不足,同样会产生反作用:控制过严使部属口服心不服,控制不力则可能现场的工作纪律也难以维持。要清楚最理想的控制,就是让部属通过目标管理方式实现自我控制。
  5. 协调能力
  任何工作,如能照上述所说的要求,制定完善的计划、再下达适当的命令、采取必要的控制,工作理应顺利完成,但事实上,主管的大部分时间都必须花在协调工作上。协调不仅包括内部上下级、部门与部门之间的共识协调,也包括与外部客户、关系单位、竞争对手之间的利益协调,任何一方协调不好都会影响执行计划的完成。要清楚最好的协调关系就是实现共赢。
  6. 授权能力
  任何人的能力都是有限的,作为高级经理人不能象业务员那样事事亲历亲为,而要明确自己的职责就是培养下属共同成长,给自己机会,更要为下属的成长创造机会。孤家寡人是成就不了事业的。部属是自己的一面镜子,也是延伸自己智力和能力的载体,要赋予下属责、权、利,下属才会有做事的责任感和成就感,要清楚一个部门的人琢磨事,肯定胜过自己一个脑袋琢磨事,这样下属得到了激励,你自己又可以放开手脚做重要的事,何乐而不为。切记成就下属,就是成就自己。
  7. 判断能力
  判断对于一个经理人来说非常重要,企业经营错综复杂,常常需要主管去了解事情的来龙去脉因果关系,从而找到问题的真正症结所在,并提出解决方案。这就要求洞察先机,未雨绸缪。要清楚这样才能化危机为转机,最后变成良机。
  8. 创新能力
  创新是衡量一个人、一个企业是否有核心竞争能力的重要标志,要提高执行力,除了要具备以上这些能力外,更重要的还要时时、事事都有强烈的创新意识,这就需要不断地学习,而这种学习与大学里那种单纯以掌握知识为主的学习是很不一祥的,它要求大家把工作的过程本身当作一个系统的学习过程,不断地从工作中发现问题、研究问题、解决问题。解决问题的过程,也就是向创新迈进的过程。因此,我们做任何一件事都可以认真想一想,有没有创新的方法使执行的力度更大、速度更快、效果更好。要清楚创新无极限,唯有创新,才能生存。
  领导力更需提升
  一个部门经理提高完成任务执行力的过程,其实也就是提高自身对部门员工领导力的过程。因为要提高执行部门的执行力,不是光靠经理一人所能完成的,而是要靠带领部门所有员工的共同努力才能完成的。
  说到底,对上提高执行力、对下就要提升领导力。
  那么,怎样才能提升领导力呢?除了提高以上八项能力之外,还有最重要的两点:
  1. 学会用老板眼光看企业。
  在老板看来,管理很简单,就是两件事:一是扩大业务范围,增加业务收人;另一件事就是降低管理成本,控制运作费用。其实这两件事,最终是一件事,收入减去成本,减去费用,就是利润。所以归根到底老板是看利润的,利润要从管理中来。
  2. 从被领导中学习领导。
  在领导人看来,领导也很简单,就是两件事:一是用人,内圈用德、外圈用才,用人所长、容人所短;二是激励,解人之难、记人之功,通过正面激励,引导下属往前跑,通过负面激励,推着下属往前走。要知道,任何领导都是从做下属开始的,谁都不可能一步登天当领导。在每个人的成长过程中,你会经历大大小小许多领导,只要你用心学习,不管是好领导、还是坏领导,你都可以从正反两方面学到经验和教训,这对你将来当好领导是十分珍贵的。
  软件测试管理常见问题及其回答
  1、测试负责人要进行严格的测试进度跟踪吗?
  很多时候,由于人力资源的不足,测试项目负责人都是在执行测试,这样就使整个项目缺乏控制,一些问题(例如:有些成员的缺陷质量不够合格;开发人员修改不及时,系统某些功能发生严重问题导致部分功能无法测试。)得不到解决,耽误了进度。所以测试负责任必须全程监控项目,尽可能多的掌握信息。通常,测试负责人需要完成下面这些内容的管理工作:
  测试用例执行情况;
  每个测试员提交的缺陷情况;
  测试中是否发生突发问题。
  2、 测试也有版本控制吗?
  这里的版本主要是指测试对象的版本控制,也就是指对开发部提交的产品进行版本控制。在开发小组版本管理不规范的情况下,测试小组进行版本控制十分重要,要保证测试对象是可以控制的。建议开发和测试双方进行明确的约定,可以各自指定专门的测试版本负责人,制定提交原则,对提交情况进行详细的记录,这样基本避免了版本失控导致的测试失误或无效。
  3、如何处理测试人员的流动问题?
  人员流动不仅仅是测试部门,这是IT行业的普遍现象。从管理者角度,主管需要多多和团队内成员进行沟通,建立一个融洽的团队环境,及时掌握情况,可以早些进行相应的调整。但是只有企业建立好的用人制度,给员工提高广阔的发展空间和好的培训学习机会,才能从根本上解决这一问题。
  加强项目管理,强化文档管理并保证文档的有效性,可以大大减少由于人员流失带来的损失。同时,测试部门要建立培训机制,使新到员工接受直接或者间接的培训,快速适应工作。
  4、为什么开发人员经常抱怨测试工程师提交的缺陷质量太差?
  我们经常听开发人员说:“这不是缺陷!”,“这个缺陷没有,因为我的系统上运行正常!”。测试工程师本身就是做质量工作的,提交的成果本身就应该质量高些,为什么还会有这种现象?
  提交的缺陷引起争议是一种正常的现象,例如测试人员描述不清楚就会引起争议。减少甚至避免这种现象的方法是交叉测试,交叉测试是提高测试质量的一个有效手段,当然交叉测试会增加一定的测试成本投入。在测试任务完成后,测试工程师之间互相验证彼此提交的缺陷,就会避免了缺陷描述不清、因运行环境而产生的缺陷等一系列问题,从而大大降低了回归测试以及交流的成本,因而这种投入也是值得的,实际开发人员在单元测试阶段也会进行交叉测试,来提高开发质量。
  另外,测试人员一定要按照规范描述测试中发现的缺陷,一个缺陷至少描述清楚概要描述、详细描述、重现步骤三方面的内容,缺陷管理参考第八章的内容。
  5、“让那些新手来做测试,反正他们也不会什么”正确吗?
  在实际项目开发中,我们常常看到有些单位忽视测试团队存在的意义,当要实施测试时,往往临时找几个程序员充当测试人员。也有些单位尽管认识到了组建测试团队的重要性,但在具体落实的时候往往安排一些毫无开发经验的行业新手去做测试工作,这常常导致测试效率低下,测试人员对测试工作索然无味。
  根据笔者的经验,测试团队应首先聘请一名资深的测试领域专家,他应具有极为丰富的同类项目软件测试经验,对软件开发过程中常见的缺陷或错误了然于胸;此外,他还具有较好的亲和力和人格魅力。其次,项目测试团队还具有很多具备一技之长的成员,如对某些自动化测试工具运用娴熟或能轻而易举地编写自动化测试脚本等。
  另外,测试团队还应聘请一些外部成员,如验证测试实施过程中,同行评审是最常使用的一种形式,这些同行专家就属于外部测试团队成员的范畴。至于测试团队里的测试新手,这部分人可以安排去从事交付验证或黑盒测试之类的
  6、测试同化现象是什么?
  同化现象是指随着时间的推移,开发人员会逐渐影响测试人员的思维和对缺陷的判断能力,尤其是针对同一产品,同一组开发人员和同一组测试人员共同配合了很长时间,很多本来是缺陷的问题,由于测试人员对软件“习惯成自然”的使用,会不被当成缺陷,尤其是在开发人员的解释和说服下。同化现象发生可能意味着“恶性循环”的开始:测试人员会帮着开发人员解释一个个缺陷的合理性,一轮有一轮的测试都不会发现问题。
  招聘新的人员,不同的测试项目组轮换去测试不同的产品,就可以避免。同时建议产品可以发布测试版,更多的人对其进行测试,就可以发现更多的问题。
  7、测试工程师如何避免定位效应?
  社会心理学家曾作过一个试验:在召集会议时先让人们自由选择位子,之后到室外休息片刻再进入室内入座,如此五至六次,发现大多数人都选择他们第一次坐过的位子。这种现象称为定位效应,说明人们习惯上凡是自己认定的,人们大都不想轻易改变它。
  定位效应在开发人员和测试人员身上都有体现。例如开发工程师针对某一自己写的功能,经常进行代码移植,这种复制的“功能”,由于上一次经过调试,在新的地方往往不会认真调试,这些代码往往会带来共享变量冲突等许多种类型的缺陷。
  定位效应体现在测试人员身上就是测试过的功能不再进行认真测试:在回归测试时,之前由于进行过认真的测试,往往会认为某些功能是可靠,只要验证一些以前发现的缺陷是否修改完成就可以了。这种现象在反复多次回归时表现的更加突出,因为回归测试中很多功能都会进行多次反复测试。众所周知,开发人员在修改缺陷时往往会引入新的缺陷,测试人员的疏于防范就会把这些缺陷带到用户这里。
  解决这种问题的方案一般有两个:
  (1)完整的执行测试用例:这种方法投入较大,但是在开发产品时最好在最后一次回归测试时测试的执行一次全部的测试用例。
  (2)交叉测试:测试人员交叉测试,就可以很大程度的避免定位效应。测试工程师在回归测试时互相交换任务,反复测试某一功能的机会大大减少,从而也就不会“主观的”人员某些功能没有缺陷。
  通常上面的两个方法都是结合使用的,既要进行交叉测试,又要全面执行测试用例,测试覆盖面要尽可能的广泛。
  8、测试人员忽然辞职怎么办?
  目前IT行业人员流动较大已经成为一种不争的事实,员工的辞职大多数都会给组织带来一定的影响,而这种影响基本是不可能避免的。在测试领域,员工忽然辞职也会带来很大的负面影响,尤其测试队伍规模较小时。面对这种情况,我们所能做的,就是如何最大限度的降低这种影响。
  根据作者的经验,主要有两种方法:第一种是在测试人员内部建立一个良好的学习环境,大家互相学习,这样某些特有技术不会被某一个人所掌握,而互相学习和提高自身,也是大多数成员愿意做的;第二种就是在组织中进行知识管理,把技术作为知识沉淀下来,这样新的员工在接手工作时容易上手,通过学习快速适应环境。
  此外,日常还要注意工作规范化,例如形成尽可能多的文档,都可以降低员工离职带来的损失。
  9、测试人员工作发生问题测试经理应该如何做?
  测试人员工作发生问题是测试经理经常要面对的问题,作为测试部门的领导,首先要做的是指出测试人员所犯的错误,使其尽快改正错误。
  唯一不能做的就是盯着下属的错误不放。总盯着下属的失误,是一个领导者的最大失误。英国行为学家波特说:当遭受许多批评时,下级往往只记住开头的一些,其余就不听了,因为他们忙于思索论据来反驳开头的批评。身为测试经理要根据测试人员的心理来进行指导,最大限度的调动每个人员的积极性来参加工作。
  10、不深入到具体测试工作时,测试经理如何考核员工?
  这种现象在测试规模较大的组织中很常见。测试经理应该尽可能的安排每周与每个成员在不被打扰的环境下进行谈话,这样可以尽早发现和解决很多问题。
  最为一个测试经理,主要工作之一就是定期的评定组织做了些什么并且是怎样做的。同时还要为员工做一个报告——关于充分了解测试人员正在做什么和怎样做的报告,以此来给测试人员做做工作成绩考核。这份报告要了解到每个人的动态。
  测试经理和每个员工重点是谈谈目前的工作,例如大家在工作中的问题或意见;是否需要帮助等。许多管理者经常抱怨没有时间在一周会见每一个员工来谈他们的工作。但是根据作者的经验,如果不能安排时间和员工进行每周的谈话,员工会来打扰测试经理的工作,因为员工很多问题还要要来找测试经理商议。
  同时对待员工要用他们能接受的方式,而不是我们自己可以接受的方式。“己之不予,勿施于人”,这条黄金法则可能会对许多生活中的纯粹的社交因素有效,但是并不是总对工作有用。有效率的管理者知道应该逐渐了解每一个员工需要怎样的对待方式。
  总之,只有尽可能多的和员工接触,才能更精确的进行考核。
  11、测试经理如何面对加班问题?
  大多数情况下,作者是不主张加班的。当员工每周工作超过40个小时的时候,他们开始在工作的时候关心自己的事。他们花钱,会给很久没有联系的人打电话,因为员工们一直都在工作。员工不能在太疲劳的状态下完成工作,这是因为他们在工作时不能关心自己,这种情况下通常效率很低。
  测试管理工作的重要任务之一就是要创造一个环境,让员工在工作时间内完成工作,同时还要鼓励他们每周不要超过40小时,甚至可以基于他们在40个小时能够完成的工作量给他们酬劳。通常情况下这样做能够提升创造力,从而会逐渐提高效率。
  测试工作本身的一个突出特点就是不断重复枯燥、冗长的测试,如果在疲劳状态下,很有可能精力不集中,略过一些重要的测试环节。而且有的时候测试需要编写测试驱动程序,这种情况更需要较好的状态来工作。
  12、测试管理者如何面对自己的错误?
  每个人都会犯错。我们可能会因为忘记开会而使客户发怒,承认自己犯错是一件尴尬的事情,尤其是管理人员认为对自己负责的项目小组承认犯错可能会失去尊严。如果我们不是经常犯错,承认错误的时候其实能够赢得尊敬。例如我们忘记一次会议,然后为此向同事或者客户道歉,其他的人会理解我们的。
  不管做了什么,不要否认或故意忽略自己的失误。故意忽略不会让错误消失,这只会让错误成长为怪物。
  13、为什么计划定期的培训?
  测试工作和开发工作一样,不但要面对日新月异的新技术,还要学习相关系统的领域知识。只有在不断的学习中,才能做好工作,跟上行业的发展。如果测试管理者没有基于不断的变化而培训员工,就会给组织带来一定的损失。日常培训可以是关于特定项目或者是技术,通常采用下面几种方法:
  (1)测试部门内自由交流方式的培训。这种培训的交流比较随意,可以在周五的例会上进行交流,也可以大家一起坐在茶馆里进行交流。方法可以采用“头脑风暴法”,让每个组员讨论一个特定的领域,这种交流方法特别对同时要做很多不同项目的小组比较有益处。当每个人做不同的项目,这会有助于每个人了解你小组所有的工程。
  (2)跨部门的互相学习。测试工作需要很多领域以及技术知识,这些知识单靠自学是远远不够的。和其它部门的同事进行交流是一个相当好的办法,大家在工作中可以在技术等各个方面互相得到提高。
  (3)外部培训。外部培训尽管投入较高,但也是值得的。这些专家一般在自己的领域非常精通,可以快速提高整个测试团队的水平。也可以通过测试小组介绍一些朋友来进行培训,这种方式可以降低成本。
  培训是构造学习型组织的基本条件,也是提高员工水平的重要方法。经常的定期培训,可以增强组织凝聚力,使员工更加愿意长期留在组织中发展。做为测试负责人,定期的进行培训是十分必要的。
  14、时间上不允许进行全部测试,测试负责人应该如何做?
  这个问题也许十分可笑,可是现实中我们的测试经理们却不得不面对这个问题。这里的全部测试不是指对软件进行遍历测试,而是指测试负责人制定的测试计划包含的全部测试内容。
  通常,不管是开发产品还是做具体的项目,都会发生耽误进度的情况。一旦整体进度不能向后延迟,项目相关人员习惯上的做法就是缩减测试时间。尤其在功能还没有开发完成的情况下,这种现象更为突出。
  担负着质量重任的测试经理,如何来解决这个问题呢?比较好的做法是按照下面的步骤逐步来完成和改进工作:
  (1)按照测试任务的轻重缓急,尽最大努力完成测试任务。在时间不足的情况下,我们应该对测试任务按照优先级来划分,重要紧急的任务先完成。这个时候的测试任务是一种辅助性工作,其目的就是尽最大努力来提高质量。因此,面对这种情况,测试负责人要做的就是带领测试小组充分利用所有资源来保证质量。
  (2)在实际工作中和开发人员共同配合,逐步改进工作。只有整个团队的软件开发能力提高了,才能从根源上解决问题。因此,测试负责人要带领团队和开发小组共同寻找适合自己的开发模式,从而使项目规划的更加合理,进而按照预定计划来开展测试工作。
  总之,在任何情况下,测试负责人都不应该抱怨。只有积极的面对问题,才能更好的解决问题。
  15、公司不重视测试,测试负责人如何开展测试工作?
  目前国内的软件公司不重视测试仍然是一种普遍现象。尽管很多公司在意识上已经开始重视测试,但是在具体工作中,往往由于追赶进度、节省资源等方面原因而忽略测试工作。在这种情况下,测试负责人仍要对软件质量负主要责任。在这种环境下,测试负责人应该如何开展工作呢?
  首先,要主动去配合开发人员完成工作。尤其是不能抱怨环境,在任何情况下抱怨是不能解决问题的,只能加重矛盾的激化。在此基础上,逐渐显出测试工作的重要性,然后再逐步健全测试体系。
  其次,用实际行动来证明测试工作的重要性。只有测试工作的业绩逐步表现出来,人们才会真正的注意到测试的重要性。因此,测试负责人从点滴开始做起,才能逐步做好测试工作。
  要想做好软件,把开发的软件产品形成商品,测试工作必须和开发一样重视。否则,质量不好的产品,很快会被市场淘汰的。现代的软件规模越来越大,测试工作也会越来越重要,因此测试负责人只要坚持做好工作,可发挥作用的空间会越来越大。
  最后要说的是,如果真的是在一个没有希望的团队里,测试负责人可以考虑辞职。辞职也是一个不错的选择,到新的环境去发挥自己的能力,要比长时间的怀着“郁闷”的心情去工作好的多。
  16、测试管理者需要是技术专家吗?
  测试管理者在测试项目中的主要任务是制定测试策略,管理测试计划的落实情况,并且还要为测试项目的进行创造良好的执行环境。同时还要调动员工的创造性,对员工的工作作出评估。这些工作不一定要求测试管理者达到专家的水平。
  但是在实际工作中,由于测试人员的短缺,测试管理者常常做为测试员来执行具体的测试任务。尤其在规模较小的测试团队,测试管理者的日常工作通常以具体的测试执行工作为主,这个时候更需要测试管理者有较好的背景知识。
  总体说来,技术方面的背景知识对测试管理者是十分有益的。例如:分配工作任务、做进度预算,以及一些具体的执行工作,都需要一定的背景知识。当然,做为一个测试管理者,没有必要精通所有的技术,那也是办不到的。测试管理者做到正确的帮助员工最好地完成工作,并且提供最好的完成工作的环境就可以了。
  如何成功管理一个团队?
  1、资源共享,真正意义上的团队合作
  团队工作的核心是协同合作,协同合作的重点在于资源共享,只有达到了真正的资源共享,这个团队才是真正意义上的团结合作的组织。
  资源共享举措:
  图书馆
  知识库管理系统,搜集整理各种知识
  项目产品事后分析报告,揭露存在的问题
  休假会
  定期过程审计,是技术交换的过程,是发现先进典型的过程,是学习的过程。
  产品质量信息公布
  通过学习交流实现资源共享
  不同部门不同场合的多种交流
  成功地将员工们的自身技能、智慧和头脑风暴纳入公司资源,使每一位团队成员都享受到了充分的资源支持,使他们可以没有后顾之忧地彼此切磋、彼此学习,从而获得不断提高,获得和提供友善帮助的机会。
  资源共享是成功释放团队成员潜能的良好机制。了解更多的信息,掌握更多的资源,实际上使得员工不得不或者说是主动承担起应负的,甚至更大的责任。
  正是团队资源共享的成功实践,它跨越了时间和空间的障碍,让每一位团队成员都可以随时随地的接触和管理自己与整个团队的资源,从而在团队成员之间构筑起资源共享的渠道,使整个团队的办公空间被无限扩大,使团队团结得更紧密。
  一位理智的团队成员会做到资源共享,这样可以让自己更清楚团队的实际情况,有利于认清团队工作的目标,从而促进自己工作的积极性,并开创出一片新气象。
  2、同一个目标
  共同的目标能够引导大家共同去追求,去努力,从而明确了企业目标是企业相成团队精神的核心动力。
  要想建立一个真正意义上的团队的共同目标,就必须使团队成员之间达成和谐的共识。团队中每一位成员都必须非常清楚团队要做什么,成品会是什么模样,基本的产品策略是什么,什么时候必须完成等。
  在任何项目的执行过程中,都会有一些“关键时刻”,要求团队成员在心理和情绪上必须凝聚对目标的共识,对共同的目标产生共鸣,对事情的优先级形成清楚的认识。惟有如此,团队才能团结共进,共创辉煌。
  3、沟通,上情下达,下情上达,双向而不拘形式
  在一个团队之内,沟通绝不是单向的,必须是一种双向互动的形式。因为,只有团队成员与团队高层之间保有无障碍的通话渠道,这个团队才是健全的,才能够真正地携手共进。
  如果一个团队的沟通和互动是正确的、健康而有效的,那么就能够使这一群人的力量完全结合,从而产生相加、相乘的效果,迅速推进团队工作。
  最迅速、最方便、最直接、最尊重人性的团队沟通方式,就是利用电子邮件系统。电子邮件系统为内部员工和上下级的交流提供了最大的方便,确保了相互间意见的及时交流,对消除相互间的隔阂十分有利,能够最大限度的统一整个团队的步调,共同前进。
  如果一个团队陷入沟通不良的困境时,应该采取不同以往的沟通方式进行改善。比如沟通效率过低,就应考虑设立针对沟通的部门;如沟通欠缺建设性,就应该反省团队内部教育是否滞后不前。
  一个成功的团队必须是充分沟通的团队。在上下级之间,如果只有命令,没有交流,必然导致领导者的独裁和团队成员积极性的丧失;在同事之间,如果彼此鼓励隔阂,也只能导致人际关系的僵硬和冷漠。
  糟糕的团队沟通就象宇宙的“黑洞”一样,会将团队成员的能量和热情吞噬殆尽。与之相反,顺畅的团队沟通则有如温暖人心的艳阳,为团队成员提供源源不断的能量,帮助他们高效地完成工作。
  4、敢于放权,善于授权
  充分授权不仅是让团队成员能够全力发挥才能,无所阻碍地工作,也是为他们清除各种不同的障碍,让他们以自己的力量达到某种成就的好方法。自主是充分授权的基石,让他们自主判断和实施计划,自由地思考和表达他们认为应该思考和表达的事情,自由地去冒险尝试,使他们不必怕受到额外的惩罚。
  充分授权是充分管理的结果,而不是忽视属下,让他们放任自流。当管理者对属下说“这是你的决定”时,他必须已经提供了完善的支持——训练、信息、资源——让属下能够作出正确的决定,这样才算充分授权。否则的话,让属下做决定等于弃他于不顾。
  在充分授权的环境中,不是无政府的混乱,而是用事实和才能领导一切,因而会放弃因为骄傲所造成的愚蠢,去除自我的狭隘心理,给整个团队创造一种和谐统一的合作气氛。
  精于授权,敢于担风险是管理者不能忘怀的素质。作为一个好的管理者,要学会放权,不能把权力一人独揽,要充分发挥下属的积极性,不然就会出现只有管理者忙忙碌碌,其他人却无所事事的局面,要学会大权独揽,小权分散,要学会抓大事,放小事,从而调动整个管理机构有机高效地运转。
  学会适当放权的最后一部是分清楚什么是可以控制的,什么是不可以控制的,聪明的领导者会发现,想控制下属如何运作项目,如何决定以及他们提什么样的建议是不可能的,因而领导者需要放弃对下属行为的控制,转而让他们以任务为核心,专心致力于自己承担的任务。这样才能更加恰当地把个人的力量转化为整个团队的力量。
  5、同等对待,就是抹杀杰出者的贡献
  我们最不可忽视的是团队高效率的培养、团队精神的形成,其基础是尊重个人的兴趣和成就,设置不同的岗位,选拔不同的人才,给予不同的待遇、培养和肯定,让每一个成员都拥有特长,都表现特长,并且这样的氛围越浓厚越好。
  世界因不同而丰富多彩,人类因差异而个性纷呈,区别对待表明了团队对个性的尊重。一个团队的组成并非是一些完全相同的个体,而是各有不同的个体组合在一起才能为团队带来各种不同的能力。也就是说团队需要的不是每个成员的共同点,恰恰相反,每个成员的不同点的集中才会使团队力量壮大。
  经典的团队,是每个成员都经过选拔组合,特别配备的,每个成员都做着与其他人不同的事情,最重要的是团队的管理者区别对待每一个成员,通过精心设计的相应的培训,使每一位成员的个性,特长能够不断的得到发展并发挥出来,这才识名副其实的团队。
  所谓的公平对待恰恰是极其不公平的,是对优秀人才的忽视,甚至会迫使优秀人才慢慢走向流失,趋于平庸化,因为他们没有得到应有的肯定而变得不再努力和突出。
  6、制定规则的人,就是第一个执行的人
  在一个团队中,各级管理者都起着至关重要的作用,所以,在任何一个团队中,每一级的负责人在提出工作要求、颁布管理规则的时候,要求每一个下属做到的,管理者自己必须首先要做到,每一个下属能做到的,管理者必须要做得更好。
  管理者以身作则的力量和作用,无论在任何时候都是不能丢弃的,一个人没有规则意识会被认为素质低,一个管理者没有规则意识也绝不是一个优秀的管理者。
  管理者决不能忽略自身对下属可能产生的影响,更需要知道自己会对下属产生深刻的影响,自己的乐观和悲观情绪会同样富有感染力,而且自己一举一动、一言一行的表现都会影响到周围所有人的情绪、语言和行为。管理者发出的信号是非常重要的。所以说,管理者的每一个决定和每一个行动都是对下属的一次绝好的培训机会.
  发号施令并不能帮助管理者实现自己的意图。真正的领导是通过以身作则来实现的,而不是简单的行政命令。无论管理者喜欢与否,他的做法都会成为组织其他成员的榜样。管理者对他们有着巨大的影响,他们事事都会从他的身上寻找原型。
  规则就是规则,确定下来的规则就要坚决执行。我们不缺乏规则,缺乏的是不折不扣的贯彻规则的决心和行动。
  管理者应该树立起“规则意识”。否则,规则就难以维持下去,只有真正做到这一点,并且把这些意识贯彻到团队的每一位成员的每一天的工作中去,才能够建设出一个成功的团队。
  7、授人以鱼与授人以渔
  一个团队的管理者,要做的不仅仅是帮助团队成员完成工作,更重要的是要教会团队成员如何独立完成工作。
  有时结果并不能反映出成功与失败,团队的成员们更注重的是一个过程,注重他们在这个过程中学会了什么,得到了什么、做出了什么。只有在工作过程中达到完美的配合和协作才是团队工作的真正意义所在。
  团队领导肩负着让队员得到学习和成长的重任。“授人以鱼”只是解决了他一时的低层次的需求,却不可能帮助他从根本上摆脱被动,他难免要等待外界的馈赠或者施舍;“授人以渔”则使成员有了求知的能力,这样才能在今后的工作中掌握主动权,作为一个平等、独立的团队成员立足于团队之中。
  帮助手下完成任务,不如教会手下如何去完成任务。
  团队合作需要学习,而学习更需要团队合作,如果一个团队中,为了发展而形成一种激烈竞争的局面,不但不会促进团队成员的大力学习,还会阻碍学习的进程,使成员之间互相明争暗斗而各自为政。这样就难以发展成一个学习型组织,要成为学习型组织,先决条件是必须有和谐的内部气愤,组织内的成员才能共享知识。
posted @ 2017-08-15 16:36 51testing 阅读(100) | 评论 (0) | 编辑 收藏
 
程序员:天天加班,但是加班费呢?

加班是大家老生常谈的话题了,国内互联网公司加班现象更是严重,而互联网公司中则要数程序猿加班最为厉害。很多人是在加班,但不代表很多人愿意加班,可能刚入职场的小白倒是干劲十足,成了工作狂,或者是热爱工作,又想证明自己的人生价值不断投身于事业中的人…

前几天,在社区看到一帖标题为:互联网公司加班没有加班费是普遍现象吗?为什么免费加班没人反抗呢?

提出这个疑问的程序猿认为就算是被生活压迫的流水线工人,没有加班费也不会去免费加班保住工作的,难道是程序猿的社会地位更低?只能为了一个饭碗去被迫接受免费加班吗?

于是,众猿们议论纷纷,好像在密谋什么大事。

◆有些人打算起来反抗,但…

@GreatMartial:

砸滴,想起义?

@lonenol:

肯定没人愿意加班,但是怎么反抗呢?

@ooppstef:

一个是不知道怎么反抗,离职到下一家加班的概率也大,BAT大部分团队都加班。另外,竞争大,很多时候自己也想提速做产品,加班也是自愿的。

@15015613:

根本原因是缺少反抗的组织者。一个人反抗,完全是找死。联合起来才有希望,想要联合起来便要有组织者、带头人,代表工人利益的工会跑哪去了?

@suilongfei:

别较真,不然大家都没饭吃。

◆有些人认为不加班,自然有人会替代掉你。

@veelog:

要么忍要么滚!不加班领导总喜欢给你挑毛病。

@codingadog:

你不愿意干的活,还有大把人没机会干。你再拼命不拼命,总有不要命的。中国是 14亿人而不是 1.4亿人。

@sagaxu:

如果 A流水线工资是 B流水线的 2到 10倍,B流水线的人会不会愿意免费加班换取 A流水线的一个职位?说到底还是供需决定的,互联网是少数既不需要拼爹又没有很高门槛的高薪行业。

@zartouch:

互联网是工作量大节奏快,要高薪就要承受大工作量。你加班只是因为你工作做不完而已,拿多少钱做多少事,这么简单的事情不用我再强调了吧?

于是这位程序猿先生又说,实际情况是工资更高的流水线企业加班更正规,私人小工厂反倒可能会有免费加班的情况;而工作量完不成是一方面,但是很多时候工期都不是有开发经验的人制定的,都是商务部门或者需求部门拍脑袋出来的,这个时候不能按期完成仅仅是自己的能力问题吗?但是互联网行业不同了,带头大哥BAT都在搞狼性和奋斗。还有的情况是,加班成了一种文化,没有什么事情要紧的时候也要在公司多坐一会上会网,不然到点没人走就自己走反而显得不正常。

然后,众猿们又开始吐槽。

◆有些人说大公司也加班,国企加班也没钱,怪领导?

@Lihz:

很多项目管理者并不懂得怎样衡量效率且对很多项目开发的把握并不大,大多数老板也不懂 IT的开发过程。这两点导致中层取悦或者说取信于老板的方式变成压迫底层加班,毕竟没有功劳也有苦劳嘛。

@ivanchou:

不少国企事业单位也没有加班费啊。

@sagaxu:

工资最高的一流公司的好部门,门槛也高啊。需要名校学历和能力过硬,不是靠加班堆时间能挤的进的。

@honmaple :

上周人事总监就说了,我们和阿里的差距就是阿里加班到 23:00,而我们只加班到 21:00。

◆有些人则是客观的吐槽派。

@EleanorKusosaki:

根据我对我司的JAVA的观察,我发现是这样的。他们一般都是单身租房,回去也没事干,不如在公司里面消磨一下时间,写写代码吃吃饭看看书,还能赚个晚饭补(当然长此以后就更加找不到对象了)。然后,不然就是家庭不圆满不想回家做家务…就熬到半夜再回去,不然就是做不完活。

@mytsing520:

你得证明确实是公司让你加班,而不是你主动加班。公司让你加班,按法律来说必须付给加班费;主动加班,事后公司认可的,也要付给加班费;如果纯粹是为了处理完问题而主动加班,法律不认可其加班事实。

@coderluan:

1.行业产出太难评价,不像流水线工人可以按件计费,所以加班就有钱,难免有人磨洋工,加班费就就不如绩效好操作。

2.这个行业其实人很多了,中国年轻人压力又大,很多人都是主动选择加班的工作的,毕竟工资肯定高一些,而就行业 1+1

End.

如果对软件测试感兴趣,想了解更多的软件测试知识,请大家关注“51Testing软件测试网”头条号。

相关热门文章

http://www.toutiao.com/i6426594521361940994/

http://www.toutiao.com/i6439201903241855490/

http://www.toutiao.com/i6439580855500276226/

http://www.toutiao.com/i6439919722615013889/

posted @ 2017-08-14 16:30 51testing 阅读(240) | 评论 (0) | 编辑 收藏
 
IT 岗位版《王者荣耀》,告诉我你是农药里的谁?

王者荣耀作为一款全民老幼皆宜的游戏

  讲真,咱们做IT的早已“中毒”已深

  今儿我们来把我们的程序员、测试、产品经理等

  代入到一个更加丧心病狂的游戏去

  

  没错

  就是“没事开个黑奶一口”的

  ▎王者农药 ▎

  为了搞这个特辑,我每天都在带薪打游戏,终于搞清楚了里面的角色定位等等...

  那么接下来就让我们进入

  ▎代入世界 ▎

  

  程序员 —— 刺客/李白

  

  刺客,属于高爆发、收割类英雄。此类英雄的特色是,前期发育,支援收割,后期切后排,秒脆皮英雄。

  而李白作为刺客型打野,依靠自身灵活的突进手段和高额的爆发伤害,他从上线以来就一直活跃在人们的视线中。

  这设定,简直就是各大牛逼【程序员】本人,研发前期需要蒙头搞代码(发育)和成熟,后期不断产出(支援收割),做出来的硬件软件都可以秒杀其他友(di)商(fang)。并且绝大多数程序员的颜值也担当得起【李白】的形象!

  市场商务 —— 战士/关羽

  

  战士职业有着最为庞大的队伍,定位非常灵活,可以根据战场形势走输出路线或防守路线,他们的抗压性极强,可以打拉锯战,顶在前排扛伤的同时打出高额的伤害。

  关羽在游戏中自身拥有超高的生存属性,皮糙肉厚的他拥有常人没有的抗击打能力,可以大量的伤害而屹立不倒。并且在超高防御的情况下,他的输出也会逐步上升,所以对于关羽来说越肉越强。

  作为公司团队派出与外界打拼磨合的【市场商务】通常也是冲在前方为队友们杀敌铺路,虽然路程遥远坎坷,却越战越勇,可谓是抗压性极强,常常与客户周旋打迂回拉锯战。

  CTO——坦克/项羽

  

  坦克,血厚防高,属于生存能力较强、输出能力一般的英雄。在团战中占据前排位置,抵挡掉较多的敌方输出伤害。

  正所谓一代补丁一代神,自吕布从神坛上跌落后,老司机项羽已成功登顶坦克排行榜。项羽的优点就在于能力均衡,能控能抗能救队友。

  这不就正是一家公司的【CTO】所拥有的技能么,首先能力均衡,能够可以解决技术方面大大小小的问题和Bug,并且一定是以团队为中心来活动和打仗,极力保护后方的所有技术人员,成为最强团控。

  设计——法师/妲己

  

  法师作为团队的主力输出英雄,一般站在坦克后面。法师的输出来自技能的法术伤害,普通攻击为物理伤害。法术攻击越高,技能伤害就越高。

  王昭君作为法师英雄的人气英雄,是一个拥有一身控制的英雄,而她最厉害的地方是团战,在团战中王昭君可以为队友提供控制,减速,不仅可以帮助队友击杀敌方,也能帮助队友安全撤退。

  公司的【设计师】非常符合“偶像歌手王昭君”的设定,不仅是因为设计师本身就是好看的,还因为他们绚丽的“法术”也给予了产品和团队有力又精致的包装,将其成为更能霸占市场的英雄。

  设计师版“甄姬”,觉得这台词搭配太棒了,(不要脸)

  

  测试 —— 辅助/蔡文姬

  

  在游戏中辅助是战斗中不可或缺的一环,辅助的职责一般而言是打保护,不断的控制敌方单位,辅助英雄在战斗中可以通过游走来为我方其他路的英雄建立优势。

  而自从S7大改之后,蔡文姬超越孙膑成为“打不死的移动血库”。奶量超足哪怕是坦克都能补足大半血量,大招还增加双抗300,让对手打到绝望!并且有着拥有提升队友属性的技能和回血增益技能。

  【测试工程师】在技术团队中也是不可缺少的角色,发现和分析问题,为产品和团队提供相应技术支持,确保产品质量指标。和“辅助奶妈”一样,有着很好的团队增益效果,为可以多方面协助队友作战与发育,从而取得最终的胜利。

  产品经理 —— 射手/后羿

  

  后羿作为射手,其技能射程远、伤害高,全图控制的大招更是让其成为敌人谈之色变的梦魔,在团战中依托坦克保护和自己走位下,灵活输出,合理运用大招控制,轻松消耗击杀敌人。

  作为对战中最主要的输出英雄,【产品经理】一样是一个团队产品输出重要的角色,因为产品经理要负责整个产品的成败,所以从研发到生产到销售,产品经理都需要参与。

  而由于后羿没有位移技能,所以,前期尽量和坦克一起去下路。产品经理也同样,在不断输出产品idea的同时必须和技术人员“捆绑”在一起,也协调好各种关系,包括研发、测试、市场、销售等部门的人,在保证品质的情况下如期的推出产品。

posted @ 2017-08-14 16:29 51testing 阅读(112) | 评论 (0) | 编辑 收藏
 
大数据分析铲屎官们的十大“猫奴症状”!你的“奴性”有多高?
null


大数据分析平台Daily View网络温度计,最近做了一项有关“猫奴特征”的调查,总结出“猫奴症”十个最常见的行为。

铲屎官们想知道自己的“奴性”有多高,或想了解你的猫奴症是否无可救药?可参考这十项指标,来,即刻开始十大倒数!


null


“这些猫毛不是我的”

第10位:衣服都是毛

猫奴病的初期病征便是衣服开始沾有猫毛,而沾毛情况在猫咪换毛的季节就更为严重。空气中飘浮着猫毛、一卷卷黏猫毛用的胶纸和吸尘机内一团团的成果,也是成为初级猫奴的最佳见证~


null


“铲屎的,你好像需要洗澡了”

第9位:闻猫的味道

刚养猫时会好奇猫咪不洗澡会臭吗?后来发觉原来它们会自行清洁,不但不臭,它们的肉球还会种香香的气味。一天不吸浑身难受!有人形容猫咪的肉球像是爆米花的味道,而在日本更将其气味做成护手膏等日用品,务求达到人猫味一致的境界!


null


出门带罐罐,为浪浪带来惊喜的一餐

第8位:随身带有罐罐

爱屋及乌的猫奴,身上总能变出一两个罐罐,方便在户外遇上流浪猫时,能赠它一餐温饱。你又是否早已熟识自家附近的浪浪们呢?


null


大大小小的纸箱比日日替你铲屎的奴才还要受宠

第7位:家中备有大小不一的纸箱

中级奴才会开始认识猫咪对纸箱的情结,不少猫奴也会用纸箱为主子做出各式各样的家具玩物,如大型猫城堡、 猫抓器或睡窝等。纸箱既便宜又深得主子喜爱,亦令不少猫奴的家也快要摇变成为废品回收场了......


null


打扫家居也只为了让主子住得舒适

第6位:变得很爱干净

猫咪爱洁净,不但对自身整洁有要求,对居住环境也一样。为了主子的健康,奴才会开始勤于打扫家居,每天准时早晚各铲屎一次,以确保能为主子提供整洁的生活环境和清新的如厕空间。


null


即使家中已有一大堆的猫玩具,你还是害怕主子发闷

第5位:猫咪用品一大堆

下班回家没带上一两件新的猫用品便太失职了。一年一度的宠物展,更是猫奴出血的大日子,左挑了几枝逗猫棒,右捧着一座新猫架,还有林林总总进贡用的猫咪零食……主子大满足,奴才最幸福~


null


装上猫网后,便不用害怕主子走到窗边了

第4位:打造适合猫咪的住家环境

资深的猫奴也是全能家居改造王:窗户装上猫网;在墙壁/门上钉出一条条猫走道,让主子畅通无阻地巡视全屋;将沙发搬到窗户旁,好让主子能舒舒服服地躺着晒太阳。到了这一步,你的猫奴指数已相当高了!


null


主子表示爪在你身,痛在我心呀!

第3位:手脚都是伤痕

手脚的伤痕从何来?主子主动来讨摸摸,若奴才摸太久或太短亦会被咬;主子心情不佳会被咬;主子肚饿时也会被咬。有时即使奴才刚好经过,主子也会不知何解地冲过来咬你,再光速地跑走。奴才望望手脚的伤痕,只能说一句:“这就是爱呀!”


null


“你们看看,我家猫咪多可爱。”

第2位:手机内全是猫咪照片、各种话题也离不开猫咪

末期的猫奴病, 手机会存有大量可爱的猫咪图片。屏幕壁纸、个人头像或朋友圈更新,全部也是家中主子大人的肖像。数个同事朋友闺蜜走在一起,又会禁不住向Ta们分享猫咪的近况或是自己的铲屎育猫心得,开展一场场完不了的讨论......

佯装猫叫的声音神似得快能骗过自己了

第1位:学猫叫逗猫玩

不论看到家中主子,还是街上的流浪猫,猫奴们也会情不自禁向它们“喵”起来,并会开始钻研不同的猫叫声。对于猫宝宝的矫柔叫声、主子日常的厌世叫声或老头猫咪的懒慵叫声,你也早已无师自通。去到这个境界,你的猫奴病算是病入膏肓,恭喜恭喜!

End.

如果对软件测试感兴趣,想了解更多的软件测试知识,请大家关注“51Testing软件测试网”头条号。

相关热门文章

http://www.toutiao.com/i6426594521361940994/

http://www.toutiao.com/i6439201903241855490/

http://www.toutiao.com/i6439580855500276226/

http://www.toutiao.com/i6439919722615013889/

posted @ 2017-08-10 17:07 51testing 阅读(104) | 评论 (0) | 编辑 收藏
 
事件响应计划成功九步
事件响应(IR)计划用于测试公司响应安全事件的能力。最终目标,是在缩减修复时间及成本的同时控制住情况,限制对公司造成的伤害。
  然而不幸的是,大多数IR计划都没能实现承诺。最近的调查显示,1/3的公司甚至都没有IR计划;而在有IR计划的公司中,IR计划往往十分简陋,仅有个基本框架,且甚少涉及除信息安全和IT团队以外的其他业务线。很多IR计划还基本未经测试和审查,因而在安全事件降临时往往达不到预期效果。
  想要切实可行的事件响应(IR)计划,不妨遵循以下九步。
  1. 处理业务问题并分配角色
  如上所述,有IR计划的公司太少。即便有个IR计划,最好的那些计划都可能会缺乏关键信息,或没纳入合适的人。
  事实上,IR文档往往“过时”且“笼统”,“遭遇危机时无法指导具体行动”。这意味着,应从基础开始实现计划,规划出正确的架构,并合理安排员工角色。
  首先,在开发过程早期,公司企业应将拥有并维护IR文档的人纳入进来。这有助于项目从专项IR计划转向常规业务实践。开发其他关键组件,比如事件分类系统(帮助攻击识别和修复)和数据分类框架,同样重要。
  最关键的是,这些计划真正吃透了公司业务,描清了特定员工应扮演的角色。有人建议,应让一名高管担负起在公司各部门实现该计划的责任,而且各部门的地理位置也不能忽视。
      IR计划必须贴合关键业务、公司文化、当前事件响应方式,及改变响应以适应未来发展的方式。
  ——普华永道网络安全业务负责人 斯洛纳·门克斯
  定义清晰的角色和责任是关键。确保人员都经过良好培训,可以有效履行这些角色职能和责任非常重要。
  2. 确认相关业务部门并让他们参与进来
  与大多数安全问题的根源一样,未经测试的脆弱IR计划,往往是因为仍旧以单独的IT和信息安全部门全权负责而失败。训练有素的IR计划需要业务部门间的合作,因为响应数据泄露或安全事件需要同等级的通信和业务协作。
  例如,零售商遭到入侵遗失了信用卡信息,便需要公共关系(PR)部门披露事件,需要Web开发人员找寻并修复软件缺陷,需要运营部门检查服务水平协议(SLA),需要市场部和客户支持部门。
      建立良好IR计划的最佳方式,是在制定过程中引入利益相关者,确保在公司范围内获得最大的认可。RACI表有助于责任分配。
  ——思科事件响应服务主管 肖恩·梅森
  于是,到底哪些人应该牵涉进来呢?除了常规的信息安全团队和其他支持性IT职能部门,一份各部门的细目清单应成为IR计划的一部分。高管层、关键业务团队、研发/业务持续性、情报团队、人力资源、法律、公共关系、执法、外部IR团队和厂商都是可以酌情纳入的。
  业务线必须参与到计划过程中。举个例子,尽管IT和法律可能是一致的,但业务功能拥有者或许不同意某项行动,或者可能看到其他需要被处理的负面影响。在业务层级拥有精准洞见,对规划一个有效且全面的IR计划特别重要。
  3. 确定KPI以衡量事件
  一个好的IR计划很可能是主观的,因而普遍不太清楚其有用程度——除非有明确的关键绩效指标(KPI)定义什么才是成功的构成因素。专家认为,这些KPI应既定性又定量。对于前者,可包含检测时间、事件报告(注意:2018年5月即将实行的GDPR规定了72小时报告窗口)、事件分类和调查。定量方面,KPI可包含误报数量、攻击本质(恶意软件还是非恶意软件)、识别出事件的安全工具等。
  IR人员不应该恐惧KPI数据。它们只是对管理的衡量。理解了它们的效用,你才能与高管无碍沟通。公司用KPI衡量绩效和响应时间,选择一套定义良好的KPI可使团队申请到更多资源,获得公司的更多支持。
  4. 测试,测试,再测试
  事件响应中一个最大的问题在于,尽管公司企业确实进行常规红队动作,对IR计划的压力测试却往往不足。IR计划压力测试应涉及到公司每一个人,最好还模拟出安全事件发生状态。但实际上,有人说,公司只是有时候知道该测试应该是什么样子的。
  执行这些测试可以保持IR计划不断更新,适应现代社会的需求,同时还特别有助于发现并修复业务线中的薄弱环节。最终,影响到安全预算的投入方向。
  认识到有很多公司仅仅创建但不测试IR计划很重要。测试有可能成为后勤噩梦,往往需要一整天,甚至很多天。IR计划测试最大的障碍,与高管的时间、协调和承诺有关。测试还需要高管商讨那些日常运营未必受影响而被认为不紧急的事项。
  5. 经常审查计划
  IR计划必须定期修订,尤其是在公司不断成长的情况下。IR计划须足够健壮,要能提供极好的操作框架,同时还需足够灵活,几乎可以处理所有面临的情况。灵活性与IR计划更新容易程度相关,应经常审查并更新计划。
  6. 定义事件
  与KPI紧密相关的,是事件定义——确定哪些是事件而哪些不是。这么做,可以找出哪些东西必须处理,而哪些可以无视,确保你的安全团队专心处理最严重的问题。
  比如说,攻击尝试是事件吗?或者攻击者成功侵入了才值得响应?一旦定义好,公司企业就可通过发现并记录影响到当前安全状态的威胁、风险和潜在失败,来执行事件威胁分析。
  美国国家标准与技术局(NIST)的事件拓扑学,将事件粗略分类为未授权访问、恶意代码、拒绝服务和不当使用,可将之作为一份有用的指南。
  7. 组建由IR分析师领导的团队
  事件响应团队分析安全问题与威胁情报报告,制定出公司的事件响应策略。事件响应团队的类型很多,可以是内部的、外部的,或者内外兼容的。
  有人认为,尽管该过程必须涉及各方利益相关者、IT团队内部及外部人士(包括主要调查人员和IT主管),该过程十分依赖有经验的渗透测试员和IR领导者,却依然是不争的事实。
  通常,团队包含各方面的技术人员,最重要的主管和网络取证人员。另外,好的团队往往配备有内存分析专家、恶意软件分析和威胁情报技术人员。
  但是,别忽视了渗透测试和捕猎团队,这样攻击和记录分析技能才有用武之地。对IR团队经理来说,能做到以上所有,且理解高管说话做事方式的老练IR分析师,才是最值得寻找并珍惜的人才。
  8. 实施正确的工具
  良好IR计划将围绕网络可见性、攻击者检测、恰当的警报、团队安全通信,以及与公司其他部门的良好沟通展开。好的威胁情报有助对攻击者活动的可见性与理解,良好沟通可使IR团队向公司其他部门解释安全事件以便推行修复。
  9. 建立沟通策略
  事件响应中任何时候都必不可少的就是沟通了,有一套通告第三方和内部团队的沟通策略尤其重要。而对外,司法部门和潜在事件修复提供者也应被通告,雇员则是内部沟通的首要对象。他们应该知道事件响应计划,接受响应流程培训,能够清楚了解自己的角色。
posted @ 2017-08-10 17:03 51testing 阅读(145) | 评论 (0) | 编辑 收藏
 
10款超好用的开源大数据分析工具
 考虑到现有技术解决方案的复杂性与多样化,企业往往很难找到适合自己的大数据收集与分析工具。然而,混乱的时局之下已经有多种方案脱颖而出,证明其能够帮助大家切实完成大数据分析类工作。下面我们将整理出一份包含十款工具的清单,从而有效压缩选择范畴。
  数据已经成为现代化企业中最为重要的宝贵资源。一切决策、策略或者方法都需要依托于对数据的分析方可实现。随着“大数据分析”逐步替代其上代版本,即“商务智能”,企业正面临着一个更加复杂、且商业情报规模更为庞大的新时代。
  考虑到现有技术解决方案的复杂性与多样化,企业往往很难找到适合自己的大数据收集与分析工具。然而,混乱的时局之下已经有多种方案脱颖而出,证明其能够帮助大家切实完成大数据分析类工作。下面我们将整理出一份包含十款工具的清单,从而有效压缩选择范畴。
  1. OpenRefine
  这是一款高人气数据分析工具,适用于各类与分析相关的任务。这意味着即使大家拥有多川不同数据类型及名称,这款工具亦能够利用其强大的聚类算法完成条目分组。在聚类完成后,分析即可开始。
  2.hadoop
  大数据与Hadoop可谓密不可分。这套软件库兼框架能够利用简单的编程模型将大规模数据集分发于计算机集群当中。其尤为擅长处理大规模数据并使其可用于本地设备当中。作为Hadoop的开发方,Apache亦在不断强化这款工具以提升其实际效果。
  3. Storm
  同样来自Apache的Storm是另一款伟大的实时计算系统,能够极大强化无限数据流的处理效果。其亦可用于执行多种其它与大数据相关的任务,具体包括分布式RPC、持续处理、在线机器学习以及实时分析等等。使用Storm的另一大优势在于,其整合了大量其它技术,从而进一步降低大数据处理的复杂性。
  4. Plotly
  这是一款数据可视化工具,可兼容JavaScript、MATLAB、Python以及R等语言。Plotly甚至能够帮助不具备代码编写技能或者时间的用户完成动态可视化处理。这款工具常由新一代数据科学家使用,因为其属于一款业务开发平台且能够快速完成大规模数据的理解与分析。
  5. Rapidminer
  作为另一款大数据处理必要工具,Rapidminer属于一套开源数据科学平台,且通过可视化编程机制发挥作用。其功能包括对模型进行修改、分析与创建,且能够快速将结果整合至业务流程当中。Rapidminer目前备受瞩目,且已经成为众多知名数据科学家心目中的可靠工具。
  6. Cassandra
  Apache Cassandra 是另一款值得关注的工具,因为其能够有效且高效地对大规模数据加以管理。它属于一套可扩展NoSQL数据库,能够监控多座数据中心内的数据并已经在Netflix及eBay等知名企业当中效力。
  7. Hadoop MapReduce
  这是一套软件框架,允许用户利用其编写出以可靠方式并发处理大规模数据的应用。MapReduce应用主要负责完成两项任务,即映射与规约,并由此提供多种数据处理结果。这款工具最初由谷歌公司开发完成。
  8. Bokeh
  这套可视化框架的主要目标在于提供精致且简洁的图形处理结果,用以强化大规模数据流的交互能力。其专门供Python语言使用。
  9. Wolfram Alpha
  这是一套搜索引擎,旨在帮助用户搜索其需要的计算素材或者其它内容。举例来说,如果大家输入“Facebook”,即可获得与Facebook相关的HTML元素结构、输入解释、Web托管信息、网络统计、子域、Alexa预估以及网页信息等大量内容。
  10. Neo4j
  其官方网站将这款工具称为图形数据库技术的下一场革命。这种说法在一定程度上并不夸张,因为此套数据库使用数据间的关系以操作并强化性能表现。Neo4j目前已经由众多企业用于利用数据关系实现智能应用,从而帮助自身保持市场竞争优势。
End.

如果对软件测试感兴趣,想了解更多的软件测试知识,请大家关注“51Testing软件测试网”头条号。

相关热门文章

http://www.toutiao.com/i6426594521361940994/

http://www.toutiao.com/i6439201903241855490/

http://www.toutiao.com/i6439580855500276226/

http://www.toutiao.com/i6439919722615013889/
posted @ 2017-08-09 16:17 51testing 阅读(185) | 评论 (0) | 编辑 收藏
 
程序员的福音,AI可以自动修复bug了!
 人工智能完全学会自己编程,可能说起来还有一种科幻感,但 AI 帮程序员找 bug 这件事,已经达到了不错的水平。
  北京大学、微软亚洲研究院和中国电子科技大学就一起尝试着让 AI 找 bug。微软亚洲研究院的 Lily Sun 在微软官方博客上介绍称,他们开发的精确状态系统(Accurate Condition System, ACS),能在人类不加干预的情况下自动修复软件系统中的 Bug。
  他们关于 ACS 的论文 Precise Condition Synthesis for Program Repair 发表在世界软件工程大会 ICSE 2017 上。
  ACS 会自动修复什么样的 bug 呢?Lily Sun 举了个例子:
  int lcm=Math.abs (mulAndCheck (a/gdc (a,b), b));
  return lcm;
  这是 Apache Math 中的一段代码,用来计算两个数的最小公倍数,并且引入了 Math.abs 来确保返回的值是正数。但是,这个程序有缺陷,有时候还是会返回负值。
  我们可以创建一个测试来找到其中的错误。测试的输入是a=Integer.MIN_VALUE、b=1,预期的输出是 throw ArithmeticException。
  把这个程序和相应的测试输入到 ACS 中,ACS 会自动生成第2、3 行的路径,修复程序缺陷:
  int lcm=Math.abs (mulAndCheck (a/gdc (a,b), b));
  + if (lcm == Integer.MIN_VALUE) {
  +  throw new ArithmeticException ();
  + }
  return lcm;
  让算法自己改 bug 这件事,从 2009 年开始就有研究,弗吉尼亚大学计算机系的 Westley Weimer、新墨西哥大学的 Stephanie Forrest 和卡耐基梅隆大学的 Claire Le Goues,就一起开发了 Genprog。
  而 ACS,在前人研究的基础上大幅提升了准确率。在 Defects4J 基准上的测试结果显示,ACS 生成的 23 个补丁中,有 18 个是正确的,准确率近 80%。
  ACS 准确率的提升主要得益于有更多的信息来源,特别是网上的大量代码。与以往的方法相比,ACS 有以下三种新的信息来源:
  一是用局部性原则信息对补丁中的变量进行排序;
  二是用自然语言分析技术来分析 Javadoc,然后用 Javadoc 中的信息来过滤不正确的补丁;
  三是通过对网上的开源程序进行统计分析,发现对变量进行操作的条件概率,进而生成正确的补丁。
posted @ 2017-08-08 16:50 51testing 阅读(177) | 评论 (0) | 编辑 收藏
 
通过20%的工作获得80%的性能改善jmeter实战
本文向您介绍如何通过最少的工作优化 WebSphere Application Server V6 以获得最大的性能改善。它侧重于使用 wsadmin 和 Jython 进行命令行优化,而不是使用 GUI 技术。通过应用一些根据经验获得的方法,能够通过最少的管理工作使 WebSphere Application Server 最佳地利用可用的硬件资源。这里描述的技术适用于任何性能优化问题——只有某些特定经验方法是特定于 WebSphere 的。
  引言
  如果您是这样一个人:启动并运行 WebSphere Application Server 后就忙着处理其他事情,而没有时间研究与性能优化相关的文档(请参阅参考资料)。那么,您来对地方了——本文旨在帮助您确定可能带给您 80% 性能改善的 20% 的性能更新。本文重点介绍 WebSphere Application Server base 产品——下一篇文章将介绍 WebSphere Application Server Network Deployment。
  应用程序基础设施中的优化带来的性能改善不能与修复编得很差的应用程序所获得的显著性能改善同日而语。 一些应用程序在其数据库查询中没有 where 子句;一些应用程序调用了 wait() forever;一些应用程序构建了死锁生成器;一些应用程序拥有庞大的 HTTPSession;一些应用程序执行了 select * 并试图将所有数据缓存到中间层中(有千兆的数据也那么干!)。本文将向您介绍一些很好的优化技巧,但只有应用程序本身可以带来真正显著的结果。是的,这意味着应用程序开发人员和服务器管理员必须定期相互沟通!
  性能测试环境
  找出薄弱环节
  您需要一个尽可能反映生产环境的测试环境。如果您使用的是几千兆的数据仓库,则测试系统可能需要小一些。但是性能和生产环境之间的任何差异都可能引起高开销的推断错误。大型企业没有任何理由宣称它们无法提供同等规模的性能测试服务器。小测试环境可能无法暴露某些方面(例如锁操作、日志记录、HTTPSessions、垃圾回收、连接池、CPU、内存、数据库、网络或应用程序)现有的问题。
  测试工具——找准方向
  创建实际测试工具是有效优化的关键步骤。如果您在测试服务器上施加的工作负载无法反映出站点中实际发生的情况,则您的优化将无法解决问题!有很多开放源代码的软件测试产品和商业软件测试产品(请参阅下面的参考资料)。您可以通过查看现有的服务器日志来了解实际测试场景。当引入新的应用程序时,这些历史记录对您是没有帮助的,所以必须有最好的设想。
  测试工具——打破极限
  优化旨在发现问题并修复它们。如果测试没有使服务器负载达到临界点,则有些问题将检测不到,所以要确保服务器的负载超过您预期的最高峰流量。这样做将使您获得测试工具定义中的误差幅度。优化最差情况下的负载,这样您在投入生产时就已经拥有更高负载下的性能值。于是,您将知道您的安全幅度有多大以及什么时候需要为非常流行的应用程序进行扩容。应用程序的创建者不应该开发测试工具,因为他们知道假定的边界条件,会有意避免创建超出这些边界的测试用例。生产工作负载可没有这么友善!
  一些测试提供的用户数是适度增长的,从而生成相当线性化的性能曲线图。但是实际的用户到达率往往是集群化且不规则的,所以在投入生产环境之前需要对这些条件进行测试。
  如果您的测试计算机上有其他用户,则他们必须知道您的测试计划——否则他们可能认为他们遭遇某种严重的问题,例如拒绝服务攻击。
  本文所使用的测试环境
  本文中的结果来自 IBM 培训计划,它使用 WebSphere Trade6 内部基准来训练学员在高压竞争环境下进行性能优化。该测试环境使用 Red Hat Enterprise Linux V3、WebSphere Application Server V6.0.1、DB2 V8.2 和 Apache JMeter。这些产品将安装在 VMWare V5.0 下。两台 IBM ThinkPad 便携式计算机使用以太网交叉电缆相连接。应用服务器运行在一台计算机上,而测试工具和数据库运行在另一台计算机上。
  为了简化性能优化环境和降低出现错误的可能性,您应该使用 shell 脚本来启动不同的组件。下面的清单 1 显示了一个名为 go_trade6 的示例脚本。该脚本从端到端启动基准,包括 WebSphere Application Server、DB2 服务器、JMeter 程序和用于监控 top 和 vmstat 的 xterm。
  清单 1. 启动测试环境所有组件的脚本
  xterm -exec top &xterm -exec vmstat 3 &su - -c db2start db2inst1#su - -c oninit informix startWASmozilla 
  &# start test harnesscd /root/trade6/jakarta-jmeter-2.0.2/bin/opt/IBMJava2-141/bin/java ApacheJMeter.jar -t tradebuysell.jmx 
  &# read wastecpu.c wastecpu & wastecpu & export PATH=$PATH:/opt/IBM/WebSphere/AppServer/bin
  环境卫生
  获得性能基准数
  在进行任何更改之前,获得性能基准数是很重要的,因为只有与基准进行比较才能确切说明系统变快还是变慢。在运行基准测试或其他性能测试时,必须谨慎地控制系统上的其他工作。例如,如果您的数据库用于事务处理和繁重的决策支持 (DSS) 查询,则可以确定非预定的 DSS 查询将牺牲您的事务性能。如果您在不知道 DSS 会有干扰时试图优化此环境,则将错误地得出结论:系统的性能“已优化,但不可预测”。实验示例的性能基准(使用 JMeter)如下面的图 1 所示。可以通过 Run 菜单下拉列表启动一项测试或清除先前的所有数据以进行下一次测试。
  图 1. 使用 JMeter 的性能基准:37 毫秒响应时间
  基准性能表明平均响应时间为 37.6 毫秒(请看 JMeter 帧的右下角)。您可以对不同的度量进行优化,例如吞吐量、中值响应时间、响应时间偏差或其他某种优化目标。首先确定优化目标,然后弄清楚如何优化系统才能实现此目标。
  如果工作负载很大而且系统优化不好,则需要花很长时间才能获得基准性能值。您可以使用小型测试工具来缩短一些早期测试的时间,还可以获得系统输出的详细信息。确保数千次点击的次秒级响应不会只是应用程序错误页面的详尽测试。JMeter 提供测试活动日志。您可以定义一个文件(例如 /tmp/jmeter.out)来包含 HTTP 请求响应活动的返回代码。
  在下面的下载部分,您将发现 JMeter 的两个不同的测试文件。一个是完全测试,另一个标为“Small”。Small 测试也启用了输出收集功能,以便您可以看到请求-响应的结果。在实验测试中,计算机是完全满负荷的——图 1 右下角的蓝色实框表示 100% 的 CPU 使用率。图形指示器和运行 top 命令的 xtermBoth 都指示 CPU 使用率的问题。查明什么占用了 CPU 时间需要费些周折。
  没有足够的 CPU 和内存,服务器(WebSphere Application Server 或其他任何服务器)将不能很好地运行。如果您在没有空闲 CPU 时或者在操作系统需要交换虚拟内存的地方试图优化服务器,则无法使其变得很快。下一部分将描述如何检测 CPU 或内存受限的系统以及如何修复它们。
  优化日志
  一些优化更改将使系统运行得更快,而一些将使之运行得更慢。记录您做了什么更改以及为什么这样更改将使优化过程更简单也更顺利。下面是一个非常简单的配置日志——格式不是很重要,只要您每次记录一些关键数据点即可。一个好的过程是将更改作为注释放在配置文件中。
  示例优化日志条目
  DateTime:_____________    Name:____________Parameter Changed_____________
  Why?_____________________How?________________
  New Performance___________millisecondsKeep____________ Remove_____________ How?_____
  CPU 使用率
  在进行任何优化前,系统必须有可用的 CPU 周期。任何在服务器上运行的不是很有用的程序都应该停止或禁用——包括在服务器上运行的漂亮屏幕保护程序!检测 CPU 受限的系统的最佳方式是运行 top 命令——它是 Linux/Unix 性能工具的“瑞士军刀”:
  图 2. top 命令
  在右上角,“idle”处于 0.0%,所以我们知道计算机已竭尽全力在运行。“COMMAND”栏中的进程列表显示占用最多 CPU 周期的两个程序称为 wastecpu。如果您阅读清单 2 中的注释,您会发现可以将 wastecpu 杀死。
  清单 2. wastecpu 源代码
  /* if you read this comment before you killed "wastecpu" you did good!Wastecpu is meant to simulate a
   "production application" and the purpose is to train people not to kill ANYTHING 
  without knowing what it does.*/#include <stdio.h>main()
  {int i;for (i=0;i<1;i=0){/* wow, what a useful program */i=0;}} /* end of main */
  在运行 top 命令时,要杀死这些模拟的 CPU 贪吃户,请按 K 键,top 将询问您要杀死什么进程。输入进程 id (PID)(在本例中为 2441),然后 top 将停止此程序。再次执行此操作来杀死第二个副本 PID 2442。要避免以后还要处理 wastecpu 程序,请在 go_trade6 脚本中将其注释掉。
  在一些生产环境中,发生问题时除了“抛弃硬件”外别无他法。有许多选择可以进行纵向和横向扩展。图 3 阐释了用于在实验环境中添加另一个处理器的配置。交叉电缆在学员小组(高度竞争的学员的一个重要特征)之间提供“气隙 (Air Gap)”安全性。
  图 3. 测试实验中两台 ThinkPad 的 Trade 6 配置
  内存使用率
  在有足够内存时,WebSphere Application Server 执行得最好。您可以通过 top 命令查看内存使用率。“交换”域应该为零——如果不是,则操作系统正在通过磁盘空间模拟有更多的 RAM 的情况,这当然是一个很慢的过程。使用 vmstat 命令可以更详细地检查内存情况。下面的图 4 中的 vmstat 输出表明系统不堪重负。“si”和“so”栏(swap-in 和 swap-out)与零相去甚远。此计算机需要更多的内存或者减少正在运行的程序。有关“si”和“so”的更多信息,请使用 man vmstat 获得。
  图 4. 内存不足的系统——“si”和“so”应该为零
  运行服务器或者使用 VMWare 教授实验的最好做法就是“升级”内存时不用打开计算机。只需关闭客户操作系统 (guest operating system),将设置更改为使用全部内存,然后启动虚拟机,如下面的图 5 所示。如果虚拟机需要比运行主机操作系统更多的内存,则程序运行仍然会很慢。如果有人能够发明一个系统,它可以模拟的内存比硬件中现有的内存更多,则这些程序将会执行得非常好!
  图 5. VMWare 工作站中的内存升级
  其他环境因素
  环境中有许多其他因素会影响性能,包括网络使用率、服务器上的其他程序、拒绝服务攻击以及电源线被绊断。请确保您的操作系统针对工作负载进行了优化。您需要修改 Linux 上的 sysctl、Solaris 上的 /etc/system,以及AIX 上的一组参数(请参阅下面的参考资料)。
  数据库管理员 (DBA) 能够对性能优化做出很大的贡献。除了调整数据库参数外,DBA 可以识别出编得不好的查询和死锁生成器,这种反馈对提高性能是很重要的。DBA 还有一些灵活的工具,例如 DB2 Health Center,它可以识别问题并生成脚本来修复这些问题。DB2 Performance Adviser 和 Index Adviser 也使 DB2 数据库优化变得更容易。要打开 DB2 Health Center,您可以从命令行输入 db2hc,或者单击 DB2 Command Center 中的 Health Center 图标。下面的图 6 显示了 DB2 Health Center 生成的一个警报,图 7 显示了它为更大的锁列表提供的一个建议:
  图 6. 正在运行的 Health Center:生成一个警报
  图 7. 正在运行的 Health Center:推荐解决方案
  应该捕获图 7 中建议的命令并将其放在一个脚本文件中。当凌晨两点试图恢复系统时是没有地方获得 GUI 的!所有的一切都需要放在脚本中。
  实现 Jython 经验优化方法
  现在我们开始优化 WebSphere Application Server。Wikipedia.org 将经验方法 定义为“进行近似计算或回调某个值,或者进行某种决策的易学易用的过程”。这是进行快速而质量不高的优化的“入场券”。为什么使用 Jython 呢?硬核管理员使用命令行而非 GUI 来执行重复的定义良好的任务。引用我们一位开发专家的话,“生命太短,不足以用 tcl 编程。”
  JVM 冗余垃圾回收 (GC)
  JVM 在堆中执行其工作的核心部分。对象不再使用时就是垃圾(技术术语是它们不再被引用)。对于任何家居,您可以通过看其垃圾来了解居住的是什么样的人!Verbose GC 有助于您确定您的内存堆是否太多或太大。
  清单 3. 优化冗余 GC
  #(c)copyright 2005# sample code - not supported# get help with this command in
   interactive mode: AdminConfig.help()server1=AdminConfig.getid('/Node:tux1Node01/Server:server1/')
  print server1jvm = AdminConfig.list('JavaVirtualMachine', server1)print ">>>>>  
   variable jvm is"print jvmprint ">>>>>   AdminConfig.show(jvm)"print AdminConfig.show(jvm)print "
  >>>>>   change jvm settings"AdminConfig.modify(jvm, [['verboseModeGarbageCollection','true' ]] )
  AdminConfig.save()   print ">>>>>   after save:"print AdminConfig.show(jvm)
  # on my system the output of verbose gc is in the file:#   
  /opt/IBM/WebSphere/AppServer/profiles/default/logs/server1/native_stderr1.log# 
  your milage may vary if you change the log locations## note 
  - when using jython you must use the string 'true', see below. ##wsadmin>
  AdminConfig.modify(jvm, [['verboseModeGarbageCollection', 0 ]] )#WASX7435W: Value 0 is converted
   to a boolean value of false.#''#wsadmin>AdminConfig.modify(jvm, [['verboseModeGarbageCollection', 1 ]] )
  #WASX7435W: Value 1 is converted to a boolean value of false.#''
  要使用以上脚本,请执行下列操作:
  将其放在一个文件中并起一个有用的名字,例如 verboseGC_on.jython。
  确保 wsadmin.sh(或者 wsadmin,对于 Windows┰谀拿盥肪吨小
  在命令提示符下运行 wsadmin.sh -lang jython -f verboseGC_on.jython。
  JVM 设置
  现在您已经配置了冗余 GC,您可以开始优化堆的大小。理想情况下 GC 周期应该:
  发生间隔大于 10 秒
  在 1 至 2 秒内完成
  下面的脚本将更改堆的大小。其目标是使堆足够大,大到 GC 间隔大于 10 秒;而又足够小,小到持续时间仅为 1 到 2 秒。对于每个新的 JVM 版本,GC 算法将会得到改进,所以此优化应该会随着时间的流逝越来越容易。
  清单 4. native_stderr1.log,其 GC 间隔 6893 毫秒,持续时间 456 毫秒
  <AF[14]; Allocation Failure. need 528 bytes, 6893 ms since last AF><AF[14]; managing allocation failure,
  action=1 (0/183731208) (1668600/1668600)>   <GC(14); freeing class sun.reflect.GeneratedMethodAccessor18(0x102391b8)> 
  <GC(14); freeing class sun.reflect.GeneratedFieldAccessor1(0x104e9f48)>..... lines deleted......  
   <GC(14); freeing class sun.reflect.GeneratedFieldAccessor19(0x10129030)>
  <GC(14); unloaded and freed 20 classes>   <GC(14); 
   GC cycle started Tue Dec 27 16;18;13 2005   <GC(14); freed 77240288 bytes, 42% free (78908888/185399808),
   in 436 ms>   <GC(14); mark; 396 ms, sweep; 40 ms, compact; 0 ms>
  <GC(14); refs; soft 52 (age > 6), weak 89, final 88, phantom 0><AF[14]; completed in 456 ms>
  清单 5. 将 JVM 堆增加到 512 MB - 1 GB
  #(c)copyright 2005# sample code - not
  supported#AdminConfig.help()server1=AdminConfig.getid('/Node:tux1Node01/Server:server1/')print
  server1jvm = AdminConfig.list('JavaVirtualMachine', server1)print ">>>>> 
  variable jvm is"print jvmprint ">>>>>   AdminConfig.show(jvm)"print AdminConfig.show(jvm)print ">>>>> 
  change jvm settings"AdminConfig.modify(jvm, [['initialHeapSize', 512 ],
  ['maximumHeapSize', 1024 ]])print ">>>>>   AdminConfig.show(jvm)"print AdminConfig.show(jvm)AdminConfig.save()
  连接池设置
  小型(4 个 CPU)数据库服务器的“最佳状态”是提供 100-200 个连接。WebSphere 作为数据库服务器前面的一个连接集线器。连接池的大小限制了开放多少数据库连接来受理传入的页面请求。
  清单 6 中的脚本将 Trade6 应用程序中使用的 JDBC 数据源的数据库连接池限制设置为 113。如果您的应用程序使用所有可用的连接,则大
  数连接都可能有一个需求未能满足。您可以通过阅读 javacore 来检测此未满足的需求,或者通过增加连接数并查看什么时候应用服务器停止请求更多的连接。如果连接数等于或大于 WebSphere 客户端用户数,则应该检查应用程序是否存在不严谨的代码。
  清单 6. 将 JDBC 连接池大小设置为 113
  #(c)copyright 2005# sample code - not supportedserver1=AdminConfig.getid('/Node:tux1Node01/Server:server1/')
  print server1jvm = AdminConfig.list('JavaVirtualMachine', server1)print "-->   variable jvm is"print jvmprint "-->  
  AdminConfig.show(jvm)"myds=AdminConfig.getid('/DataSource:TradeDataSource/')
  mydslist=AdminConfig.list('ConnectionPool',myds)print "-->
  before: "print AdminConfig.show(mydslist)AdminConfig.modify(myds, '[[connectionPool [[maxConnections 113]]]]')
  AdminConfig.save()#AdminConfig.modify(myds, '[[connectionPool [[minConnections 20]]]]')#AdminConfig.save()
  after: "mydslist=AdminConfig.list('ConnectionPool',myds)print AdminConfig.show(mydslist)#
  monitor connections at the database with the command# watch -d -n 5 "db2 list applications
  | wc -l"# or informix# watch -d -n 5 "onstat -g ses | wc -l"# this will include some irrelevant lines
  in count -- feel free to egrep them out
  启用 Servlet 缓存
  WebSphere Application Server 内置了两个性能工具以帮助改进配置。Performance Adviser 会友好地建议您优化 servlet 缓存,如果您同意,它将使性能得以改善。下面的图 8 显示了性能查看器的图形输出。要访问免费的 IBM 联机 Education Assistant(它提供了有关如何使用 PMI 工具的教程),请查阅下面的参考资料。
  清单 7. 启用 Servlet 缓存
  server1=AdminConfig.getid('/Node:tux1Node01/Server:server1/')print
  server1mywebcont=AdminConfig.list('WebContainer', server1)print AdminConfig.show(mywebcont)print
  "now modify settings"AdminConfig.modify(mywebcont,
  [['enableServletCaching', 'true']] )AdminConfig.save()print AdminConfig.show(mywebcont)
  图 8. 性能查看器
  线程池计数
  此脚本适度地增加线程池以保证 CPU 能够接受。一个 CPU 可以驱动 50 到 75 Java 线程。该脚本很重要,因为它必须发现与 Web 容器相关的线程池。一些简单的 Jython 代码发现正确的标识符,然后为活动线程分配新的最小和最大值:
  清单 8. 增加 WebContainer 的线程池大小
  server1=AdminConfig.getid('/Node:tux1Node01/Server:server1/')# show all thread pools# 
  print AdminConfig.list('ThreadPool', server1)# from all the ThreadPools take the 
  WebContainer# it will look something like this:#webpool='WebContainer(cells/tux1Node01Cell/nodes/tux1Node01#
  cont.../servers/server1|server.xml#ThreadPool_1113265230034)'## here is how to find the thread 
  pool with jython#tpList=AdminConfig.list('ThreadPool', server1).split(lineSeparator)
  # now loop and find WebContainer# the string.count() tests for a substring# for 
  production please add your own error handlingfor tp in tpList:  
   if tp.count('WebContainer') == 1:     
   tpWebContainer=tp## white space is significant in jython, so the un-indented line# ends the code blockprint
   tpWebContainerprint AdminConfig.show(tpWebContainer)# now that we have the identifier 
  to get to tpWebContainer # adjust the settings#AdminConfig.modify( tpWebContainer, [['maximumSize', 75 ]] )
  AdminConfig.save()AdminConfig.modify( tpWebContainer, [['minimumSize', 50 ]] )
  AdminConfig.save()print AdminConfig.show(tpWebContainer)
  高级优化思想:下一步优化什么
  有很多参数可以优化——一些可以使系统变得更快,一些则会使之变得更慢。要阅读优化佳作,请查阅下面的参考资料中的 SpecJAppServer2004 全面披露报告。
  有大量创建脚本的资源——相信您会同意使用脚本是最好的方法。在您通过一两次使用管理 GUI了解了可用的参数范围后,将会考虑转为使用脚本。有关脚本的更多信息,请参阅下面的参考资料。
  结束语
  本文描述了如何基于一些简单的经验来配置 WebSphere Application Server。同时让您通过访问下面的许多资源来获得关于性能优化的更多信息。
  在实验基准训练中,单一的最大改善是什么?优化应用程序!下面的图 9 显示了 Trade6 应用程序的配置页面。切换到直接的数据库访问和 JMS 是性能改善的最大单一贡献者。其他应用程序参数也提供了性能改善。该实验示例允许通过 Web 页面更改应用程序。您的应用程序也可以通过配置文件来获得类似的灵活性。
  图 9. Trade6 应用程序配置页面:单个 CPU、0.2 秒响应时间
  如果您达到或超越了性能目标,还应该做些什么呢?在下面的图 10 中,拥有 0.2 秒响应时间,看起来优化已经到头了。此时,您可以用更多的用户、更大的每用户事务数,或者更复杂的事务来增强测试工具。对于许多用户数超过计划的情况,详细的性能描述将使您了解配置平台的容纳范围有多大。
  您可能对如何羸得实验练习和如何从示例应用程序获得最佳性能感兴趣。设计该实验和撰写本文的目的不是为了赢得一场竞争,而是为提高 WebSphere Application Server 性能提供一个快速指导。如果我忽略了您最喜欢的优化参数,我将很乐意在以后的文章中将它包含进来——请将您的优化建议用脚本形式发送给我,我的邮箱是 lurie@us.ibm.com。我期待您反馈您觉得容易优化且优化后能获得很大性能改善的参数,并将代码示例发送给我们。
  图 10. 应用程序优化提供最大收获:在一个 CPU 上获得 0.2 秒响应时间!
posted @ 2017-08-08 16:50 51testing 阅读(110) | 评论 (0) | 编辑 收藏
 
写给一名软件测试工程师

你要为自己每一次的懦弱而忏悔:曾经不愿承认自己出生于农村,曾经不敢面对自己是一名外包员工,曾经一次次的不甘心自己只是一名测试工程师。

  不做失败者

  微软、IBM、Oracle、华为等等,这些公司选拔的测试工程师应该都是出类拔萃的人才。可惜不是你,说起你的大学,就想起郭敬明的《一梦三四年》。你开始想做测试是因为数次面试程序员被拒,但是却看见了“月薪8000不是梦”的广告。比起进入外企、国企、名企的同学,比起考上公务员的同学,比起做软件开发的同学,你在心里问自己“我是个失败者吗?”。我只能说你还没有成功,但是你已经开始挑战失败。

  一名测试工程师

  你有了正式的Title:“测试工程师”,我只能改编《双城记》里语句来形容“这是一个最美好的职业,这是一个最糟糕的职业。”

  你的脑子里充斥了各种词汇“白盒测试、自动化测试、测试工具”,可是开始测试任务以后才发现自己用的最多的测试工具就是缺陷管理工具,用到最多的测试技术就是点、点、点,测试组里最受重视的是懂业务的老员工,项目组里最低三下四的是测试。被开发说“这不是BUG,你操作有误,就是这样设计的”,被需求人员鄙视“怎么最基本的业务也不知道?”,测试经理找你谈话时委婉的说“在发现BUG的数量上你还需要努力”,马上就要发版本了,项目经理召集测试组开会“今天开始不要再关注界面的、易用性的、与核心业务无关紧要的BUG”…

  受了最多的委屈,拿着项目组里最低的工资,你都承受下来了,我佩服你。

  今天你再回头看看,肯定会微笑的领会当时的收获。高强度的手工测试培养了测试的Sense,BUG数量的压力激发了逆向发散的潜力,研究复杂的业务锻炼了测试思维。经过与开发、与需求的交锋,逐渐从逆来顺受转变为对抗。逐渐学着站在项目的角度思考测试,为什么要提前测试?为什么要首先关注核心业务?有些BUG为什么不应该提?

  最重要的是你加入了一个团队。当发现一个牛X的BUG,只有在给大家分享时才觉得无限光荣;当抱怨需求变更时,那么一帮人一起泄愤才最解气;当测试一个模块时,几个人一起抢BUG那才刺激。

  跳出去

  逐渐适应了环境,你就开始了几个阶段的胡思乱想:“我不要做手工测试了,我要做自动化测试”;“我不要做测试了,我要转开发”;“我不要做测试了,我要转管理”;“我不要在这个公司了,我要换更好的公司”。

  当你开始在组里照葫芦画瓢的录起来自动化测试脚本,你问自己“这就是自动化?”。你觉得用录制工具没有技术含量,就开始用开源工具、开始自己写测试框架,一遍遍调试,面对需求的变更整晚加班来特性化自动测试程序,你对自己说“写程序真繁琐”。你受够了技术工作,开始主动承担些带新人、任务分配、计划文档编写等工作,你和别人抱怨说“我怎么成了个打杂的了?”

  那么回过头来发现,认认真真投入项目中,仔细研究需求、认真的设计用例、严谨的来执行测试、适度的实现自动化、积极的分担别人的任务,只有这样才感觉最充实。当面对繁杂的需求文档,理清了思路画出了流程图;当看着自己设计密密麻麻的测试用例;当发现自己在原有框架上所作的特性化修改可以完美地运行;当看着自己负责的测试任务井井有条的进行着,自己辅导的新人积极向上的成长着;这一切的喜悦的感觉,都是全身心投入你目前的工作所换来的。

  学无先后

  你已经不再是二十岁出头,开始怀疑自己还能学会新的技术吗?不是说过了25岁就开始记忆衰退了吗?那你知不知道,随着年龄增长,阅历的丰富,理解和领悟能力会越来越强,虽然你比新人学得慢,但是在项目经验方面的优势却能帮助你有更深入的理解。知识是相通的,就比如当你研究明白了一门编程语言,那么再学习新的就会很快。测试也一样,测试工具、测试思想、测试流程都有很多种,不可能样样都会,深度的扩展是广度的前提。

  有人说程序员几天不学习新技术就跟不上时代了,那么测试工程师在工作中用到的技术却是稳定的。不断地重复类似的项目,不断地重复测试、修改测试脚本,你被惰性包围了吗?开始觉得不需要学习了吗?即使学习了新的技术和思想在项目中用不上又有什么用?

  学了一定要用,大多数时候领导为了规避风险,不会太支持你把新的技术或思想引入测试项目中。原来是传统迭代流程,你说要学习敏捷;原来是QTP,你说要换Selenium;原来是ST测试,你说要开展ET测试。你必须要私底下多做研究、多做实践、有较成熟的方案和技术。那么在真正有机会实施的时候,你才能够一展拳脚。实践----学习----实践,循环中不断进步。

  学习分享,在公司里,你开始学习了一门新技术,很新鲜,很有成就感,心里窃喜“看他们都不会”。这样下去有一天你会失落的发现,同事们开始对你的新技术不感兴趣,因为他们不理解,你提倡的技术思想因为无人认同而无法执行下去。与同行交流,你想炫耀一下刚学习来的“探索性测试”思想,她给你来一句“和自由测试有啥区别?我早就知道这个”,你想推广一下敏捷,她给你说“敏捷就是没有文档吗?好啊,终于不用写文档了。”你哭笑不得。

  这时才会发现,个人的发展和进步,需要团队的共同进步,需要行业的共同发展。这一切都来源每一个你这样的测试工程师的进步与分享。

posted @ 2017-08-07 17:08 51testing 阅读(216) | 评论 (0) | 编辑 收藏
 
愿你的大数据能有点柴米油盐的味道………
一直以来都有两个观点:
  1,当你不能够用生活中的例子来讲明白你所懂技术的时候,也许就是你自身对该技术理解深度不到位。
  2,牛人分两种,一种是把自己所会的技术讲的所有人都能听明白,而另一种就是讲的只有一小部分高手能听懂……..
  最近开始泡知乎论坛,买了一些Live开始学习。才发现自己对数据挖掘行业的认知浅薄,才知道自己该努力的方向。于是就有了今天的这篇文章:
  大数据是什么?它跟柴米油盐有什么样的关系?大数据跟数据科学家,数据挖掘,算法工程师又有什么关系?
  1,大数据是什么?
  实际上,最近一年。嚷嚷大数据的人很多,而这个词的热度也丝毫不减。而个人认为,大数据重要的是思维,是商业模式,而不是技术!大数据的这一思维能带给我们什么?不再是传统的拍脑袋做决定,而是依靠我们所拥有的数据跟行业经验,在这方面,行业经验非常重要。这也就是为什么互联网公司要想在传统行业做大数据分析必须要找到一个在这个行业经验很多的人的原因。
  记得一次中午吃饭,跟同事们就聊起了什么是大数据,什么是云计算的话题。实际很简单,我们吃饭的餐盘就是云,而我们食物就是大数据。而同事不是不知道云,他是不智道云跟我们有什么关系?它能带给我们什么?能给现在的工作提供哪些便利?
  云只是一个平台,重要的还是它的内容。我们用完餐,就会把餐盘放到收餐台上。而食物是我们所要吸收的,餐盘里不同的小格子可以放不同的食物,这些食物有些是大块,有些是小块,这些就相当于数据前期 的整理。专业点的说法就是数据清理,或者叫ETL。
  2,它跟柴米油盐有什么样的关系呢?
  要做好一道菜,或是做出一顿美食。缺少不了柴米油盐,就相当于有了数据,我们不仅要有烹饪的工具,而且还要有烹饪的技术。最近在看舌尖系列,就觉得中国人烹饪美食的技术不亚于现在IT的相关技术。只不过是我们都忽略了老祖宗的一些东西罢了……..
  当我们把食材准备好的时候,我们就需要开始烹饪了。这里就拿我的拿手菜(茄子烧肉)来举例子吧:茄子有很多的切法,可以切条,也可以切丁(就是那种小块)。而肉也是可以切成丝,也可以切成丁,同时也可以切成肉沫(这就是借助搅拌机了)。这些数据原始加工的过程,很大程度上决定了你最终分析出来的结果。有人的喜欢吃茄丁,有的人喜欢吃肉沫,有的人喜欢大块的肉…………而不同人的喜好决定了你的分析目标是什么?这也就是为什么数据挖掘里分析目标的关键性。
  当你有了分析目标之后,后边的油,盐,调料的多少就有了判断。而油是所有抄菜基上必须的一道步骤,这一步就相当于数据分析里的去缺失值,数据统计这一步。大体统计出数据的一个整体质量,有多少缺失值?中位数与平均数是否相等?是否符合正态分析?数据是呈现离散的,还是连续的?基本上都是在热锅的这一部分所要思考的。油热的好,葱姜蒜的香味就能出来,热不好,葱姜蒜有可能就糊锅了。后边抄菜的香味就出不来了。
  3,大数据跟数据科学家,数据挖掘,算法工程师又有什么关系?
  数据科学家:厨师长
  数据科学家这个概念,最早听到是在IBM的一次沙龙活动中听到的。当时我们小团队也稀里糊涂拿到了优胜奖,以为我们就可以是数据科学家了。现在想想,真的是too young,too native。科学家那有那么简单的事。而大数据就是一个跟柴米油盐的工种,离科学家还有很远的距离!
  当掌握了大数据思维之后,你也要跟实际的业务相关连。相当于你知道如何抄这个菜之后,食材的选择,新鲜程度如何这一方面你也需要掌握。同时你也要了解到当下这个菜的大体定价………..等等一系列的东西,有数据有关的,与数据无关的。你都要掌握你可以成为一个合格的数据科学家。否则,还是不要拿这个title出去忽悠人。
  数据挖掘:创作厨师
  至于数据挖掘,就你要你自创一个菜。刚开始学抄菜的时候,我们都是按照食谱一个一个的学着抄的。而到后期,当家人特别爱吃某两个菜的时候,你就要学会来调和这种菜的做法。比如,在做好鲫鱼豆腐汤的时候,是否要把冬瓜跟粉丝也放在一起。而当这样尝试之后,有的会成为一道更加美味的菜肴。而有的就不那以好吃了。
  从以上的角度来看,数据挖掘==自创菜,而数据分析==照菜谱抄菜。这样我们就能看出这两者的差别了。一个是有分析目标,一个是没有分析目标。数据挖掘有可能会为公司创造更大业绩,也有可能失败。就是因为你不知道你挖掘出来的目标是否符合公司的业务要求,或者说你挖掘出来的客户都很好,但在业务执行的时候就是会出很多问题。
  算法工程师:火候厨师
  实际上,算法工程师在大数据行业里是很重要的。经常见到的说法就是:代码工程师好招。而是一个好的算法工程师难遇。换在古代的说法就是:千军易得,名将难求!
  在大一点的饭店,你都会发现,客人在等餐的时间都会很长。而如何加快上餐速度。如何最快的烹饪好食物,并摆盘上菜。这一块是很有讲究的。而算法工程师,他们需要了解客户的业务,同时也要了解自己数据系统的性能。只有这两者相结合,才能更好的从业务角度来优化自己的数据架构。在这里,想起当时导师跟我讲的一个例子,中国人在写C的时候,爱用指针去调用内存,而在国外有些成熟的公司里都是用数组堆栈来直接调用。因为系统的延迟效应也是决定着你的最终成败。
  在IT行业分工越来越细的今天,算法工程师的价值越来越大,有可能一个公司。一个算法工程师就相当于10个代码人员的工作效果。这里提到的不是效率,而是效果。因为最终的业务落地需要有内在的算法支持,但更重要的是你的代码逻辑表达。
  好了,这次就先写到这吧!以后会坚持写的,希望能把抄菜大数据系列写完。最后,还是要感谢下公司,不定期的发菜(按照惯例,最后还是放上一道学会抄的菜),让我对各种菜谱开始了学习,在不能学习技术的同时,抄菜过程中也是对所学的知识进行深入思考。希望自己未来能抄得一手好菜,也能在大数据上精进一些,加油!
posted @ 2017-08-07 17:08 51testing 阅读(145) | 评论 (0) | 编辑 收藏
 
仅列出标题
共55页: First 25 26 27 28 29 30 31 32 33 Last