前几年测试刚刚火起来的时候，要求确实比较低，所以不少人都看中了这个行业，随之而生的各种测试培训班也成功地帮助不少人转行到了测试。可是经过这两年的检测，发现了培训班出来的人员能力有限，慢慢的就提高了要求。说实话，培训班就是快餐生产方式，他可以帮你从其他行业快速来转到测试这个行业来，只个领路人，给你展示一下测试都是怎么做的，需要哪方面的技术 ，可是如同读一本书，你只看书本就以为读懂了或是掌握了书的内容，那是很可笑的。

在我工作当中也遇到了不少从培训班出来的同学，整体来说他们有如下的共同点：

1，计算机基础知识比较差，不少计算机的正常操作都是他们的障碍。

2，不能清醒地认识自己，在培班班跟着老师写了一些儿程序，以为自己就会了，其实只是模仿而且，完全没有自己的思路，还自我感觉良好。

3，缺乏学习能力，证明自己的方法错误。有不少同学知识自己的能力差，为了表现自己就花大时间来做需求，可是就不出成绩，没有找到学习的方向。

4，由于能力有限，不能好好地表达问题。由于自己的能力有限，不能很好地定位问题，与其他人合作的时候表达不清，造成项目延迟，相关人员都要加班。

其实不管你是怎么进行测试这个行业的，有的是走培训班，有的是自己找工作的，这都不重要，重要的是你能为公司带来什么？你在工作中有没有成长？现实社会是很残酷的，如果你不成长，不学习，早晚会淘汰你的。下面我就从个人角度出来，来说一说非计算机专业的测试之路应该如何走才会轻松些儿：

1，理清思路，明确方向。

不管你以前是从事什么行业的，既然你选择了要做测试，就一定看中了测试的特点。无论是工作相对轻松，还是工资稍好一些儿，那就要为了这个目标而去努力，天下没有白吃的午餐，只做日常的工作是很能提升的，要有针对性的提升自己。首先我们要有这个理念，然后才能有明确的行动。

　2，认清自我，切忌盲目。

测试行业是入门容易，想走远比较难。而我们自己也要反思一下，自己会什么技术，听说过或是在培训班学习的东西，扪心自问，你真的会了吗？现在的培训班为了工作需要一般都会讲手工测试，测试工具的使用，自动化相关的测试，压力测试，服务器的搭建与使用，内容是不错的，但是短短的两三个月你真能都学会吗？任何一项测试都要花费上几年来不断完善的，学会和会用是两码事。

3，低调做人，有计划地成长

在你的技术能力有限的情况下，面试的时候就不要骄傲了，凡是自我感觉良好，目空一切；而没有真才实学的，根本不可能面试成功的。低调一下，态度良好，就有可能获得工作的机会。不管你以前学会什么，在工作的时候一定要踏实。可以理一下，按下面的顺序有计划地提升自己：

· 掌握计算机基础知识，操作系统的日常使用，windows or linux;文档办工之类的软件使用，千万不能因为这些儿知识影响了你的工作。

· 工作方法，与人交流的能力等软技能，不要小看这些儿，它们比技术更重要。说话听不懂，表意不清，生活习惯不好等都会影响你的工作。

· 常用测试软件的使用。软件只是工具，你不可能掌握所有工作的使用，但是你也不可能不会使用，如果工作需要有快速学习的能力。

· 基本语言的学习，如python，java，shell等。如果你有能力和兴趣，还是要学习一下的，不用太深，但也不能不会。

· 开源框架的学习，如webdriver，appium还有其他的一些儿框架，会使用这些解决工作中遇到的问题。

· 时常与公司的大牛交流学习，本来这个行业就是需要不断学习，跟着牛人学习比自己摸索学习的要快的多。

　4，要有危机感，防止温水煮青蛙

很多情况下我们通过自己的努力找到了一份工作，然后在工作中就按公司的要求来不断完成自己的任务。不过这远远不够，平时的工作只是你的本职工作，保质保量地完成是必须的。不过还要时刻想着提升一下自己，不然几年后你就会发现，只会公司的相关业务，使用公司的平台和工具，离开了这些你还有什么呢？公司不会管你以前做过什么工作，只会看中你以前的工作能为公司带来什么。明白了这一点儿，你就应该明白要做什么了。

最后社会和公司是不相信苦劳的，如果你不能很好地完成工作，影响了项目进度；或是其他人与你合作的时候严重受影响，大家就会给上级反馈情况。当你做到了你部门的人员都不愿意与你合作，提起你来就直摇头的时候，你就离离开公司不远了。就我们公司而言，外包人员三个月不符合要求，就随时可以换掉你；正式员工在试用期不合格，直接走人的。

如果有任何疑问，欢迎添加qq群测试入门到大神 755431660 共同学习~

对于软件测试人员来说，不需要你多么熟练使用Linux所有命令，也不需要你对Linux系统完全了解，你只需要学会一些常用的基本命令，这些命令足够支撑你去查看日志，定位bug，修改文件，搭建环境就完全OK了。对于Linux系统底层的实现不需要了解，甚至对于绝大多数的命令都不需要知道。

我们是如何在我们的工作中使用Linux呢？

相信很多人都知道，之所以我们会用到Linux，是因为我们的产品将Linux系统作为我们的服务器使用，当我们去测试产品时需要在Linux上部署产品，若产品某个功能出现错误，我们需要去排查出错的原因，出于这二个目的，我们就需要掌握一定的Linux命令。

​

01

第一个作用：搭建环境

根据每个公司的情况，软件测试人员需要自己在Linux系统上部署测试环境，也有公司是开发人员帮忙在Linux服务器上部署，不需要测试人员自己部署，而现在大部分开始做自动化部署了，就更不需要软件测试人员手工部署，直接在Jenkins上自动部署就完成了，然后打开web界面，新部署上的去的代码就生效了。

现在的部署就这个简单了，基本不用手工了，那如果用手工部署需要用到哪些命令？

王豆豆就列一些在部署时需要用的命令：

基本在部署环境时，主要就会用到这些命令，可能还有其他的，根据实际使用情况。

02

第二个作用：查看日志

对软件测试人员来说，查看日志恐怕是软件测试人员运用Linux系统最多的功能。

查看日志主要是用于定位bug，或者查看程序执行情况（什么时候调用哪个服务，什么时候在哪个表中写数据，什么时候发起请求等都可以在日志中查询到）。

在查看日志时经常用到的一些命令：

1.查看日志文件的命令

（1）vi

vi/vim 原本是指修改文件，同时可以使用vi 日志文件名，打开日志文件

（2）less

less命令是王豆豆查看日志最常用的命令。

用法：less 日志文件名 --分页显示文件的内容

经常使用这个命令是因为在查看过程中可以根据实际情况翻页和查找，非常的方便。

空格或f 向下翻页

enter键 换行 

q或Q 退出

pgup/pgdn 向上/向下一页一页切换

方向键 向上/向下一行一行切换

查找指定字符串：

先输入/，然后在/后面输入要查找的指定字符串，回车

--》显示的一个指定字符串是从当前位置查找到的第一个，可以按“n”继续向下查找其它的。

（3）cat

查看文件内容比较少的文件，经常用cat命令。

（4）tail

tail命令的意义是显示文件最后的几行，默认显示十行。

王豆豆经常使用的却是另一种场景：

当执行出错时，我们一般都会查看日志，但如果日志过多，查找很麻烦，这时王豆豆一般会使用tail命令动态显示日志。

tail -400f XX.log -->动态就是显示日志文件新增的内容

2.搜索文件内容

（1）在文件里面搜索

在文件里面搜索，先用less命令查看文件，然后输入指定字符串进行查找。

（2）文件外面搜索

在文件外面搜索特定的字符串，可以用grep命令查找

=》 grep 'ERROR' test.log

查找test.log文件中包含'ERROR'的行，并且显示出来

=》 grep 'ERROR' test.log | wc -l

返回test.log文件中包含'ERROR'行的数目

根据查看日志定位到软件出错时的日志，通过分析日志来解决bug，当然这有可能也定位不出bug， 查看日志是定位bug的手段之一。

03

第三个作用：修改文件

修改文件一般是指修改配置文件，我们只需要掌握简单的几个命令就能学会如何修改文件。

1.进入文件

vi 命令前面有讲过这个命令是找开文件，在我们需要修改文件时，就需要使用vi/vim其意为在vim编辑器中打开文件，达到可以编辑文件的目的。

vi 命令除了可以修改文件 ，还可以作为新增文件的命令。

=》vi 不存在的文件名 ---》表示新增一个文件，并编辑

=》vi 存在的文件名 ---》表示可以修改该文件

2.修改文件

vim编辑器有三种模式：

1.一般模式

使用vi命令进入的那个模式就是一般模式

2.命令模式

在一般模式下输入：或/ 即进入了命令模式

3.编辑模式

在一般模式下按I,i,A,a,O,o,R 即进入了编辑模式

在编辑模式下会提示INSERT REPLACE字样

从命令模式或者编辑模式切换到一般模式，按ESC

通过vi命令找开文件，初始状态为一般模式，如果要修改文件，需要切换到编辑模式。

在一般模式时通过按I,i,A,a,O,o,R 都可以进入到编辑模式，使用哪一个都可以，唯一的区别就是插入的光标所在位置不同，王豆豆一般使用i/I，然后通过移动光标到达目标位置进行修改，所以不用记那么多，记住一个就好，是不是很聪明？

修改的操作就和我们编辑doc文件大致差不多，其他复杂的命令能记住就记住，记不住也不影响我们修改文件，唯一的区别是修改的效率快慢。

3.保存文件

修改文件之后，需要保存修改的内容，这样才算修改成功。

根据上面的使用场景来看是不是觉得掌握Linux命令非常的简单，真正需要你记的也不是很多，能记住常用的命令就完全足够我们使用了，其他的命令就随着我们在实际使用时再查再记，也是OK的。

如果有任何疑问，欢迎添加qq群测试入门大神 755431660 共同学习~
​​

无论我去过多少家公司，工作到最后都会变糟。在我工作过的技术公司里面，早晚都会出现一些问题，这些问题要么需要做出管理方面的改变，要么需要对现有的管理风格迅速做出极端改变。但通常这些需要的改变都不会发生，然后我开始换地方，希望能遇到更好的管理。

   作为独立贡献者，我已经在大中小规模都有的好几家技术公司当过web后端软件工程师。我想通过本文卑微的努力把我所见到的事情、问题出在哪里、以及可能的解决方案是什么说清楚。我写这个是为了梳理自己的思路，同时也希望有人能从这些故事当中找到熟悉的东西，并且了解到并不是只有他自己才体会到这些。在某些情况下，这些看起来似乎是开发者的问题，但是开发者是在管理层创造的环境下工作的，所以我也把它们列进来了。

   如果你很忙的话，我已经把要点标出来了。不过，知道这些要点是什么意思会更好一些。

1、计划

　没有路线图，或者路线图很虚

  对成功应该是什么样没有想法或者想法很少的话，你是永远也无法实现的。项目的想法模糊会导致写出来的代码也含糊，运行“晚”（没有路线图的话你怎么知道呢？），以及各种沮丧。

  解决方案：制订路线图。

   路线图不以现实为基础（没有找工程师/利益攸关者进行估计，过程中没有检查点）

  管理层决定了一系列他们想要的事情，并且决定这个季度就要完成。但如果没有来自执行那些工作的人提供输入的话，那些设想可能就是空中楼阁。没有检查点去了解事情的进展情况的话，项目就会完成得很迟，往往太迟了以至于要重新确定范围，希望能完成点有意义的事情。

  解决方案：强迫那些负责做事的分解时间表，并且要合理化。让他们暂停写代码（很多开发者认为只有写代码才算生产力），先做完这个。对于好的、周密的估计要激励。

  路线图制订得太迟（在开发期间）

  先做项目，上路后才制订路线图。突然才意识到正在做的项目毫无意义。时间和精力还有士气都没了。

  解决方案：在开始工作前花时间制订路线图。你不需要预测每一种可能的未来，但是当你了解形势时就更容易把握好方向不至于撞车。

  路线图的极端改变不是因为环境变化，而是因为短视或者原先的计划缺乏周密性。

  某一天商业团队一觉醒来决定另一个项目的优先级应该更高，因为这样才可能有高速发展的走势，只是他们一开始没有事先花时间确定好事情的优先级。几个月的努力变成白费功夫，而这其实是完全可以避免的。

解决方案：认真对待路线图。好好确定优先级。除非商业方面发生了极端的变化，路线制订好就要坚定走下去。犹豫不决造成的损失比坏决定还要糟糕。致力于你说自己要做的项目。那是可以衡量的生产力。如果你对上一个优先级感到后悔的话，下个季度别再犯同样的错误了。

2、所有权

项目缺乏直接负责人

  项目是建立了，也分配给团队了。也许某人下达跟踪要完成工作的工单。一些人想起来的时候就去处理这些工单。经理偶尔会在邮件里面问问进展情况。开发者都是各自回答问题。结果表明该项目严重滞后，而且很多工作都没做好。

  解决方案：选定1个人，其工作是确保项目取得进展。这个人有权力跟经理去谈，如果必要的话可以申请更多的资源，但到头来回答关于进展情况并且推动事情发展的都是这个人。

  某个大项目只有一位工程师孤军作战

  每个人都忙着做项目。一个人有点空闲，然后被分配去做一个重要的项目。并行主义万岁对吧？错。这位工程师试图知道事情是怎么做的，但是得到的帮助寥寥，因为别人都很忙。没人审核她的工作。他们问什么地方耽误了她也回答了，但是没人对答案感到满意。她请求帮助但是被告知没有人有空。

  解决方案：除非你是在初创企业，已经快没钱，再过几周就要死掉，否则的话一个项目至少要分配2个人，理想的话3个最好。他们会提出问题的可能性要高得多，因为相互之间可以讨论工作，一起推进事情前进。而引入第三个人可以在设计决策和代码审核方面打破僵局。

  代码评审缺乏责任担当，不够彻底，指责代码作者

  来了一个pull请求。你很忙，这个人可能知道他们在做什么，只需要同意就可以继续你的事情了。轻而易举的同意谁不喜欢呢，对吧？再想想。看都没看只能说明你是个懒人。而且你还给别人开了先例，行啊，我以后也可以不审核代码了。当别人写的代码出问题时人家会说你不是看过了吗？代码是你批准的，负责也有你一份。

  解决方案：认真对待代码评审。如果你没有时间，把它分配给别人，或者问问pull的请求者是不是能够等久一点因为自己还没时间。我向你保证，你会对自己的所谓感到高兴的。

技术债务

  没有采取合适行动让旧系统退役，重写及/或撤除现有遗留系统

  到了一定时候，某个遗留的单一程序规模达到了像利维坦巨兽那样的地步，而且给web带来的灾难之严重已经到了妨碍开发的地步。现有的资深开发者处理相关事情的时候都有困难，新的开发者更是骂骂咧咧了好几个月才稍微提高了一点效率，奇怪的崩溃潜伏着，导致你的客户时不时会出现莫名的问题。但管理层总是优先考虑产品，并没有意识到技术债务拖累了他们非常渴望的产品功能研发。

  解决方案：企业必须赋予技术债务足够的优先级。遗留系统中最臭名远扬的问题必须优先处理。重写的工作必须按照规模大小依次处理。这会给将后的功能开发带来时间红利，连开发者的幸福感和寿命都会增加。大家常说开发者离开的不是自己的工作，而是他们的老板，但我认为很多时候，开发者离开的也是他们的代码库。

　开发没有必要写的系统

  “你有没有听说过那门很酷的新语言？我用周末的时间学了，现在想看看用到生产过程里面会怎么样。我听说挺棒的。”然后，一个用新语言开发的新系统做出来了，结果发现它做的东西跟某个现成的开源库非常类似，只是针对了比较特殊的用例，而且支持的开发者比较少。这个项目迟早都会延误，开发者离开了那家公司，可是在这个系统上已经浪费了很多大可不必的时间，但其实这些本来可以用在对业务很关键的工作上的。

  解决方案：这个问题比较棘手。需要有一位老练的经理知道什么对这种项目亮红灯，转而采用现成的解决方案，以及什么时候开绿灯。你当然不希望打压好的开发者，但是你也不想浪费时间精力。最好是让那位开发者写一份详细的建议书说清楚实现细节，然后进行详细的审查。也就是说，这是招到经验欠缺的经理可能会遇到的陷阱之一。

  把错全都归咎到遗留系统上面

  差点忘记，遗留系统。人人都喜欢喷原有代码，指责往往已经不在那里的开发者，因为对方无法还击。情况变得这么糟糕一定是因为那帮人太烂了，但我们比他们好。当然我们不会去修改原来的东西，我们的额外修改是必要，但我们比他们好，真的，我们保证。在别人的东西基础上增加修改要容易多了，它会让你琢磨为什么要有原来的东西。这会创造出一种抱怨没完没了的有毒环境，最终受害的将是代码质量和团队和谐。

  解决方案：尽管对原有的确质量不高的系统没完没了的抱怨可能会很有吸引力，但是请记住，正是因为原先的代码才让公司走到了现在，而那些有疑问的涉及决定也许是几次变更、商业决策以及紧急灾难共同造成的结果，这在任何快速成长的企业里面都是很常见的事情。某个东西很糟糕？做出具体计划改进它。要行动而不是抱怨，哪怕你的举措是慢慢削弱旧系统。你后面的人（可能也是你自己）会对此感激不尽的。

3、设计

  如果你在绕开系统弱点上面用的代码量多过利用其优点的代码量的话，就是坏设计

  有人有一个很棒的新设计，他们想实现这个设计，因为它比原来的那个好多了，原来的设计太糟糕。只是这么做会需要到处修补一下，但这完全是可以接受的，因为整体上新设计更好。直到后来才发现需要的修补的地方太多了，但是你已经全力以赴，没法走回头路了。

  解决方案：重新开始。沉没成本谬论是真的。你已经犯了一个错误，没关系，你可以吸取教训然后做出更好的。不要无奈地接受混乱。

  如果致力于这一代码库的大多数人都遇到了同样的问题，并且这些问题采用不同的架构时可以避免的话，就属于糟糕设计

  你会注意到同一段代码被拷贝粘贴到系统的每一个被牵涉到的地方。你问某人为什么，他们解释说“哦，那是因为这个系统因为某个原因预计要做这个，其实这不是真的，但听起来不错，所以大家只好跟着做。”你不知道为什么他们要这么做，但你很忙，所以就把这段代码粘贴进去然后继续自己的事情了。

  解决方案：我说的话听起来会很痛苦，但是，还是重构吧。重构整个东西，把那些拷贝粘贴都去掉。付出会有回报的。

4、编码

  随意编码。没有测试，或者测试糟糕。没有处理极端情况，而主要是编写基本逻辑（happy-path）代码

  “这里是初创企业，我们没有时间做这个，晚点再处理。这是可以接受的，”这些年来很多开发者都这么说，每个人都为最后的混乱局面贡献了自己的力量。未经测试就上线代码，产品出问题晚点再修复，哪怕写测试也只是测基本逻辑，或者甚至连这个都不做。

  解决方案：管理层可以强制要求测试的覆盖面，不过其实这并不是代码库测试是否到位的好的衡量手段。有效的办法是让周密的人对这些代码进行评审，让那些代码评审只是做表面文章的走人。不幸的是，不幸的是，当你招进来的工程师缺乏经验或者不够尽责的时候就会出现这种情况，所以招人的时候要擦亮眼睛。

　5、会议

  没有日程，或者日程不明确，没有可衡量的输出

  你查看日程发现自己有个叫做“系统讨论会”要参加，但是要干什么并没有描述，只知道邀请了10个人，要进行1个小时。身为好员工的你出席了，但是绝大部分时间内都是默不作声，只有其中的2个人在那里漫谈，到会议最后的时候，组织者拍拍那两个人的后背中断了同名的谈话，并且威胁着要再举行一次会议。大家的时间被白白浪费掉了，一点收获都没有。

  解决方案：在全公司范围强制执行一项政策，要求所有会议都要有日程，有可衡量的输出，只让必须参加的人出席，而且要有备忘录，看看会议的结果是否达到预期。一旦目标达成或者时间到马上结束会议。任何违背这些原则的会议，要么允许大家走人，要么允许将来不再出席。这样就会迫使大家做出改变。

  可以邮件或者私聊解决的会议

  你参加了一个会议，会议有可衡量的输出（耶！），但这只是一个只需简单回答是与否的问题，通过邮件或者私聊完全就可以解决。

  解决方案：是的，就用邮件或者私聊。用好你的常识，以及合适的媒介。

  该参加的人不参加不该参加的人却参加的会议

  你参加了一个有10个人出席但是主要设计师缺席的会议。大家都举手说了点东西，但到最后，所有的东西都被负责的人拒绝了。那天晚些时候，因为某些原因你出息了一个有工程负责人参加的会议，为的是审查了一下底层代码决策的事情，可是他在不了解背景的情况下对东西吹毛求疵，浪费了大家的时间（也包括他自己的）。

  解决方案：邀请每一个人参加会议都要有个好的理由。如果你想不出好理由，那就别邀请那个人。如果某件事情的主要决策者应该参与，那就邀请他。最重要的是，不要把可来可不来的人加进来。如果某个人是可选的话，那就不要邀请。就这么简单。这是一场公司会议，不是技术研讨会。

  为了开会而开会（站立会议，你究竟想从中得到什么？）

  你在参加每天的站立会议？大家讨论的都是你没有想法或者不在意的事情。你分享的东西可能跟他们也毫无关系。跟你有关系少数人你早就在会下交流过了，然后你报告说你们已经在私下交流过了，而且还会继续在会下跟他们讲。等一下，为什么我们还要站在这里呢？

  解决方案：如果你绝对必须知道其他人在做什么，把它写成文字以聊天或者邮件形式进行。但你会说：“哦，但是没人会看。”对。那是因为没人在意。可是你以为大声说出来他们就会在意了吗？作为这种日常仪式的结果你现在就会做得更好了吗？未必。不要再浪费别人的时间了，把焦点放在结果上面。要消灭一切无用的会议，尤其是那些重复性的、主要是出于惯例进行的会议。

  开会太早或者太晚。注意力广度很低，愤怒情绪高涨。你不会从这些会议中收获好结果的。

  现在是下午6点，有人还在开会。你的手紧紧握住了当天的第三杯咖啡并且祈祷这次会议要么有个好结果要么很快就会结束。很可惜，一件事情都没有通过。第二天早上你意识到有人已经安排了早上8:30的会议。你握住手里当天的第一杯还没喝完一半的咖啡希望有个好结果。有人问了你一个yes/no的问题，然后会议结束了。没开玩笑吧？

  解决方案：认真点。很多时候我们考虑事情都忽略了人的因素了。不要把会议安排得太早或者太晚，要安排在核心时间段。如果会议很重要，就需要马上进行。否则的话，没有什么事情是不可以等1天或者几个钟头的。那样的话，大家会更愿意出席，更愿意参与，你也更有可能得到想要的结果。

　6、流程

不评估当前情况就盲目遵守流程

  冲刺！谁不喜欢冲刺呢？我们行动敏捷。你什么意思敏捷可不是名词。我给它大写，必须这样。不管怎样，让我们大概一周左右都要冲刺一下，让大家弄清楚自己都在做什么。我怎么知道这么做有效？因为我们每周都要开始新的冲刺啊。什么？结果怎么衡量？我们创建并完成了很多工单。你还想要什么？

  解决方案：流程是个好东西。流程指导工作，引导得到路线图（你当然要有！）上想要的结果。然而，无法衡量你是否离目标更近或者是否实现了目标的流程要么是不必要的、要么是错误的、浪费时间的，或者以上都是。永远都要评估你的流程，看看它能给你带来什么，又会让你失去什么，并且确保前者永远比后者更多。

  民主过度导致优柔寡断

  每个人的意见都很重要。因为我们不是专制的，对吧？我们听听工程部门所有人的意见。等一下，有两个人不同意，这可不好。其中一位工程师虽然跟项目没有关系，但是他很有经验啊！我们还是搞定他再继续吧。别管期限了，我们需要把事情做对！正确才是最重要的。

  解决方案：企业不是政府，这里不应该民主。又快又好的决定可以拯救公司，决策慢的话无论好坏都会毁掉一家公司。如果你让某人负责这个项目，他们就有最后的话语权，他们会迅速做出决定。争端可以在更加私下的场合解决，不用把整个工程部门都牵扯进来。关注你的人，这样可以让结果最大化。让他们每个人都有话语权的话，你就会毫无理由地陷入僵局。

  过分微观管理，经理不去关心更大的局面，IC沮丧，糟糕的工作出现

经理是管人的人，他跟你在一个战壕上。在不知道是什么原因导致你做出这个决定的情况下，他问你这行代码为什么不换种写法。你用了一个小时的时间才跟他解释清楚，最后他就说了一句“哦”然后同意你了。与此同时，路线图已经延误而且跑偏了，工程师愤怒了，但是该解决这些真正的问题的时候经理却不见了。

  解决方案：要相信人。如果你无法信任他们，那就开除对方。微观管理是任何组织的丧钟，会阻止任何团队扩大。如果经理不去处理真正高层的决策，一行代码是起不到作用的，因为当房子都已经着火的时候你却在跟木匠争吵新椅子的问题。要站得高一点，用鸟瞰的视角来做出好的决策，即便底层会出现一些低效的事情，但大船仍然朝着正确的方向航行。

越级管理

   你在做某件事情，你的老板问你情况怎样，于是你提供了一个更新。然后你的老板的老板又问，你给出同样的回答只是没说那么详细。然后他的老板问，你就说“不错。”然后一位跟你的团队毫无关系的经历又来问，你开始猜测发生了什么事。你决定写一封全公司范围的报告，说清楚进展情况，这浪费了你的时间，因为你要向那些不应该有其他考虑的经理解释清楚事情。

  解决方案：就像过去说的那样，企业不是一般社会。层级的存在不是为了压制下级，而是为了保持秩序和效率。如果3级经理定期询问非直接下属项目的进展情况，这就是微观管理或者管理层级太多的迹象。这些问题的解决方案也很明显。

缺乏有用的检查点

  项目结束时我们会知道。我们以工单完结数来汇报项目状态。当然，尚未完结的工单数是会随时间转移而变化，但那只是粗略的估计，对吧？直到根据安排需要2周的事情最后拖到了6个月完成。

  解决方案：增加检查点。“这些那些应该要在第二周结束时完成。”如果检查点任务未达标，必须进行重新评估， 可能还要给项目多分配资源如果其优先级比较高的话。否则的话，你的项目范围和时间就会不断膨胀，超出你的控制。

  工程师陷入困境的时候不去拉他们一把

  每个人都知道Jacike在做住这个长期项目，而且已经做了一段时间了。你经常会想了解他的进展情况。管理层似乎并不关心他是否延误，因为嘿，你知道的，这个项目很困难。时间过去了，没人介入进去。他时不时会请求帮忙，但被告知大家都很忙。项目就这么一直搁置下去了。

  解决方案：管理层应该对项目状态有一定的了解。如果某件事情明显拖得太久了的话，那么到了一定时候，管理层介入找出缺失了什么信息，或者是否需要加人等是完全适合的。这不是微观管理，这是管理的核心部分，但害怕微观管理的经理往往赋予的自由度太高了，根本就没有起到管理的责任。是，当然这种权衡是有点像走钢丝线，但这是好的管理的标志。

   注：从下面内容开始我就只列表了，因为实在抽不出时间展开讲了，但希望列出的东西能够不言自明。如果确实很重要并且时间允许的话，我会展开说一下。

　7、沟通

   过度沟通。出于所谓的透明性，事无巨细都邮件给一大群人。收件箱堆满了信，大家就会有意识地过滤掉，导致对此漠不关心。

   沟通不足。你要进行大改很可能会有影响到其他团队，但是却没有通知对方。

　8、评估

  经理没有让直接下属来评估

  对如何改进的描述很含糊，经常说那个人从来都没有超过期待这样的话来打压别人工资，但是又从来没有明确这是什么意思

  奖励所谓的“灭火队员”，也就是那些对糟糕的代码部署做出迅速响应的人，而不是那些设计和编码都很仔细，设法避免问题出现的人

  没有清晰的发展路径

　9、宣传

  “公司是个大家庭。”不，不是，如果是的话，很多公司都像虐待孩子的父母，只有孩子不断付出，而父母却一直都只有期望和惩罚。

  “利用社交媒体来传播公司的文章。”这往好里说顶多算是不够诚实。希望利用大家的个人关系来推销公司就是不拿工作和个人生活当两回事了。这是手伸过头的表现。如果员工喜欢公司所为的话，他们自己会传播的。

　10、面试

  流程与目标不一致：面试的目标是要找到那份工作跟公司和团队都很搭的合适人选。

  工程师负担过重，经常要进行面试，跟工作一样频繁。

  强调雇佣更多的人，而没有把焦点放在留住现有人才上（如果你的工程师感觉没有被公司好好对待的话，他们又会如何介绍你的公司给别人呢？）。

11、酒精

  常规活动也提供酒精饮料。喝酒带来的纯粹是压力，不好的健康习惯，不良的工作环境。

  宣扬喝酒文化，把它正常化

　12、歧视

  种族主义、性别歧视、LGBT歧视、年龄歧视。虽然这方面的培训很多，但是出现了一些微妙的歧视形式。

  多元化水平很低

13、员工福祉

  工作过度、紧张过度或者忽视劳累的明显迹象，美其名曰“勤奋的员工”。

  忽略了员工也是人。无视人际关系问题、健康问题等。

转载：http://www.51testing.com/html/62/n-3725162.html

　　自动化测试可以快速自动完成大量测试用例，节约巨大的人工测试成本；同时它需要拥有专业开发技能的人才能完成开发，且需要大量时间进行维护（在需求经常变化的情况下），所以大部分具有很好开发技能的人员不是很愿意编写自动化用例。但由于软件规模的高速增长，人力资源的逐步稀缺，自动化测试已是势在必行。

　　对于自动化测试首先需要保证其功能是对客户有价值的和正确可用的。而这一切的基础就是用例要能测试客户的需求，期望，最好能让客户参与到测试用例的开发过程中来或让客户评审测试用例，因此出现了ATDD、BDD等各种理论方法来支撑这一行为。现有很多自动化测试工具可支持ATDD、BDD等，比如Cucumber1、RobotFramework2、SpecFlow3、JBehave4、Fitness5、Concordion6等。其中Cucumber和RobotFramework是最流行的两个框架，但许多人在第一次选择测试框架时因缺乏实践经验而困惑，所以今天为大家分享这两款框架在几个项目上的经验及对比，方便大家在以后的项目上能正确地选择这两款测试框架。

　　首先看一下这两款工具的简单对比。

　　二、案例

　　Cucumber案例1：某社交网络系统

　　项目时间：4年前

　　项目背景：系统的主要功能是帮助用户能通过一个手机应用同时与Facebook，Twitter，Flickr等社交网络更新信息，并能一次性把自己更新的信息同步到这些社交网络。其中它有一个服务器端，用于和各个社交网络通信，一个Web应用和一个手机应用提供给最终客户使用。它的技术栈主要是JavaSpring，Android，iOS，MySQL等。

　　被测系统构架图：

　　由于这个项目是中国团队和法国团队一起合作开发，当时法国团队的架构师提出选用Cucumber作为自动化测试框架来测试这个系统，项目需要支持多国语言，且需要同时做服务器和手机端的功能测试，甚至在一个测试场景中既包含服务器测试部分，又含手机端测试部分，而使用基于Cucumber的测试系统很好的满足了我们的需求，其中手机端的功能测试用的是Calabash8。Calabash是一个手机功能测试系统，它使用Cucumber将Android的测试框架Robotium9和iOS的测试框架Frank10封装了起来，使得Cucumber的Step可以调用Robotium和Frank进行测试。这样就可以实现一个测试场景里面既包含手机端测试，又包含服务器端测试，比如：

　　I"submit"updateto"Facebook"with"Iamhappytoday"on"Android"

　　I"get"updateon"Facebook”with"Iamhappytoday"on"Server"

　　实现方式是在Calabash中使用Ruby实现一层胶水代码，和服务器测试功能测试代码连结起来，并根据不同的Step调用不同的测试驱动层代码从而实现同一个测试用例同时包含服务器端和手机端测试。虽然这样的测试用例不会很多，但它却有效的表达了端到端的系统集成测试，让测试集合更加丰满。

　　如果重新选择测试工具，我还是会选择Cucumber和Calabash，主要原因是它们可以方便的统一做手机和服务器的功能测试。虽然RobotFramework配合Selenium也能实现类似的功能，但是需要使用RobotFramework对Selenium重新进行封装，没有Calabash方便易用。

　　Cucumber案例2：某大型养老保险系统

　　项目时间：2年前

　　项目背景，主要功能是提供一个Web系统让用户可以购买养老保险，管理养老保险账户里面的资金等业务。主要的技术栈JavaSpring,JSP,AngularJS,OracleDB等。

　　被测系统构架图：

　　基于安全和开发成本原因，比如重用已有的服务器和容器环境，重用开发资源，所以公司绝大部分项目只用Java语言进行后台服务器端开发，导致公司大部分人员只熟悉Java语言，因此测试框架选择了CucumberJava版11。

　　如果重新选择工具，由于技术栈和成本的原因，我仍然会选择CucumberJava版，不会考虑RobotFramework。因为对于这种JavaSpring商业应用项目，我不想引入一个Jython去加深项目的技术栈，只要能充分利用当前团队已有的技术栈就可以了，并且还更容易说服开发人员帮忙实现和维护自动化测试，从而促使整个团队都能对自动化测试负责。

　　RobotFramework案例1：某AC项目

　　项目时间：3年前

　　项目背景：该项目是WIFI系统的AC（AccessController接入控制器）部分，包含WIFI接入的认证、计费等功能。它也提供了配置界面，包括Web和命令行两种。AP（AccessPoint接入点）是与该系统交互的外部系统。通常来说AP会有很多个，放置在不同的空间区域，提供WIFI接入服务，AP和AC之间使用有线链路连接。

　　被测系统构架图：

　　该系统作为一个嵌入式设备，从用户的角度来看主要包括两部分功能。第一部分是操作管理员在命令行或者Web界面上进行功能配置，第二部分是AP与系统进行交互，完成网络接入等功能。

　　明确了被测对象和场景后，就需要寻找相应的测试库来完成这些用户（即包括人，也包AP）与系统之间的交互。对于Web来说，有成熟的Selenium可以使用，Selenium提供了多种语言的API，从这个角度来看RobotFramework和Cucumber都可以选择。对于命令行操作而言，可以选用RoboFramework的SSH库来完成，当然在这一点上其他的语言也有相应的类库。要想完成上述这个系统的测试，还需要完成报文的收发及编解码工作，Python的类库Scapy12能够很好地完成这部分工作，只需要在此之上做少量定制化开发，并将其封装成为RobotFramework关键字即可。经过上面的分析可以看到，使用基于Python的RobotFramework能够很好地处理报文相关的逻辑，加上团队在Python上有比较好的技术储备，因此RobotFramework成了最终的选择。

　　如果重新选择，我还是会选择RobotFramework，原因是其他平台上找不到类似Scapy这样好用的测试库。

　　RobotFramework案例2：某移动广告管理平台

　　项目时间：1年前

　　项目背景：该项目是一个Web系统，用于广告投放、查询、显示等功能。

　　测试思路是做端到端的测试，覆盖从广告投放、广告查询及广告显示等一系列功能。其中涉及到的测试库主要是Selenium，这点上与案例1类似。不同之处在于这个项目中参与自动化用例编写的主要是从不编写代码的测试人员，而RobotFramework有一个专用的用例编写环境—RIDE，其中用例编辑窗口如下图：

　　虽然它只是简单地把使用TAB符号隔开的一系列纯文本变成了可视的表格，但对于这些测试人员来说，他们以前工作的平台就是Excel中，所以很容易切换过来。再加上它提供的一些高亮、抽取关键字等特性，使得测试人员可以比较专注于测试用例的设计、编写和优化，而不用关心格式等细节问题。

　　在RIDE中导入相关测试库之后，可以通过F5快捷键查看所有关键字的文档，如下图所示：

　　下载测试工具，欢迎前往51Testing软件测试网。（http://www.51testing.com）

End.

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

是时候告别Junit了！

一、 青出于蓝而胜于蓝

TestNG是一款脱胎于JUnit和NUnit的测试框架，借鉴了后者的设计思想，在此基础上又引入了新的功能，比如分组测试、依赖测试、多线程测试等。

TestNG除了支持单元测试外，还可以用来做集成测试、功能测试、端到端测试等等，而junit只是用来单元测试。

二、 TestNG优于JUnit的设计详解

1.分组测试

分组测试可以很方便让你去指定你需要测试的某一批次的测试用例，我们可以使用@Test注解里的groups属性为某个测试方法指定一个或多个group，示例代码如下

public class TestExample {

@Test(groups = "group1")

public void test1(){

Assert.assertEquals(1+1,2);

}

@Test(groups = "group1")

public void test2(){

Assert.assertEquals(1+2,3);

}

@Test(groups = "group2")

public void test3(){

Assert.assertEquals(1+3,4);

}

}

另外我们还需要建立一个testng.xml文件，去指定要运行的分组测试。

<!DOCTYPE suite SYSTEM "http://beust.com/testng/testng-1.0.dtd" >

<suite name="My test suite">

<test name="testing">

<groups>

<run>

<include name="group1"/>

</run>

</groups>

<classes>

<class name="com.example.Boot.test.TestExample" />

</classes>

</test>

</suite>

2.参数化测试

所谓参数化测试就是为测试用例提供参数数据，示例如下：

@Test(dataProvider = "data")

public void hello(String name){

Assert.assertEquals(name,"world");

}

@DataProvider(name = "data")

public Object[][] data(){

return new Object[][]{{"world"}};

}

3.依赖测试

当两个测试用例之间存在依赖关系，TestNG支持你使用注解l指定依赖关系。

@Test

public void insert(){

System.out.println("insert data");

}

@Test(dependsOnMethods = "insert")

public void query(){

System.out.println("query data");

}

上面的代码，如果query方法依赖的insert方法执行失败了，则query方法则将被跳过。如果insert失败了，还想要执行query方法的话，则可以在@Test中添加

alwaysRun = true的属性

需要说明的是这个用法不能用于单元测试，单元测试要求用例之间是隔离的，这也是为什么JUnit没有提供这个功能的原因。在集成测试等场景中需要的话则可以使用。

4.多线程测试

并发测试一直是测试的难点，TestNG提供了一套多线程执行测试用例的的方案，给并发测试带来了很大的方便。

@Test(threadPoolSize = 5,invocationCount = 30,timeOut = 100)

public void multiThreadTest(){

Long id = Thread.currentThread().getId();

System.out.println("thread id: " + id);

}

threadPoolSize 指线程数量，invocationCount表示测试用例调用的次数，timeOut表示超时阀值

5.按优先级顺序测试

@Test 提供了一个很有用的priority属性来指定测试用例执行的优先级，数值越低，优先级越高。这个在测试流程的时候很有用！

public class PriorityTest {

@Test(priority = 1)

public void priority1(){

System.out.println("登录");

}

@Test(priority = 2)

public void priority2(){

System.out.println("首页");

}

@Test(priority = 0)

public void priority0(){

System.out.println("注册");

}

}

6.更丰富的注解

三、拥抱TestNG

从上面的介绍可以看到，TestNG相比JUnit提供了更全面的功能，更适用于互联网环境下的各个测试场景。而JUnit的定位仅仅是单元测试！ 因此建议TestNG 作为 Java 项目的主要单元测试框架！
End.

51Testing：人气最旺的软件测试技术门户，提供软件测试社区交流、软件测试博客、人才服务、测试沙龙、测试杂志、测试资料下载等全方位信息服务，是国内最专业的软件测试就业培训、企业服务供应商。

　　那么对于Web应用来说，该测试哪些方面，该如何测试呢？来看看作者 Abhimanyu Ghoshal给出的这些建议。
　　一、首先应该测试什么？
　　当测试Web应用的时候，首先要明确你的应用要用来做什么，比如帮助用户编辑照片、发送票据、联系朋友或跟踪社交媒介等。你通常需要着眼于这四大领域：
　　1.  功能性测试
　　几乎所有的用户都期望自己所使用的Web应用功能准确、迅速、一致。这就意味着开发者必须精益求精，帮助用户实现某种形式上的结果。下面是一些需要全面测试的常见的功能元素：
　　表单：无论是反馈调查、创建任务计划，还是订阅新闻，都需要用到表单。你需要检查提交操作是否正常，是否能够提交连接并提交到你的数据中，所有字段是否能够接收输入的内容。
　　文件操作和计算：这其中涉及图像和文档的上传、编辑、计算功能和正确的输出值。首先，要确保你能想象得到会有多少用户会使用你的应用，并尽可能地针对他们进行调节。另外，要考虑一下如何使你的App更有效地计算并显示出结果，给用户提供一个更加流畅的用户体验。
　　搜索：如果你的应用允许用户搜索内容、文档或文件，那么就要保证你的搜索引擎能够索引这些信息，并定期更新，以便能够让用户实现快速查找，并根据查找条件快速显示相关结果。
　　媒体播放组件：测试音频、视频、动画和互动媒体播放组件（如游戏和图形工具）的时候，这些组件应该像预期的功能效果一样，在加载和运行的时候不能影响（暂停或减缓）其他应用的运行。
　　脚本和类库：确保你的脚本（比如图像显示或Ajax页面加载）在各种浏览器之间是相互兼容的，因为不同的用户可能会使用不同的浏览器访问你的应用，同时你可以测量不同浏览器的加载时间来进行性能优化。如果你的脚本只能和某些浏览器相互兼容，那么就要确保应用中的其他组件有更好的性能，这样所有的用户就能得到最好的应用体验。
　　最后，就是要全面检查其他组件的功能，包括提示系统、用户配置文件和管理仪表板等。

更多内容请关注51testing软件测试网...

开发或者测试互联网产品的过程中，同学们一定遇到过connection timed out和socket read timed out两种和网络相关的异常。今天我们并不分析引起这些异常的原因，也不谈发生异常以后的解决办法，我们来说说如何制造这类异常，从而模拟对应的异常场景。
　　了解tcp协议就知道connection即建立连接的过程，其实和socket read即传输数据的过程并没有太大的差别，两者都是请求应答模式，而只是前者的请求数据量很小而已。要使两者超时，我们可以采用相同的方法即限制网络传输的带宽来达到目的。
　　Tc即traffic control就是这样一款能够限制网络流量的工具。Tc中主要的概念包括类class和过滤器filter。
　　我们可以用class把网络设备的带宽划分成不同的区间
　　tc class add dev $DEV parent 1: classid 1:11 htb rate 90mbps ceil 100mbps
　　tc class add dev $DEV parent 1: classid 1:12 htb rate 90bps ceil 100bps
　　如上，11这个class对应的带宽为90到100mbps，12这个class对应的带宽只有90到100bps。划分好了class，我们就可以用filter把符合特定条件的数据包归入不同的class中
　　tc filter add dev $DEV protocol ip parent 1:0 prio 1 u32 match ip sport $PORT 0xffff match ip dst $IP flowid 1:12
　　如上就把源端口是$PORT，目的地址是$IP的数据包归入12这个class中了，这样就把符合该条件的数据流量限制到了90到100bps。在正在运行的系统中开启上述tc限制，即把特定数据流限制到一个极小值，我们就能模拟出connection timed out异常了。关于tc更详细的教程可以参考1、2。
　　那么socket read timed out异常又该如何模拟呢，我们怎么才能区分建立连接和数据传输这两个过程，tc工具还能满足我们的需求吗？在寻找问题答案的过程中，另一个linux内核组件iptables进入了我们的视野。
　　Iptables是linux系统中常用的防火墙组件，功能十分强大，网上有十分丰富的资料。由于其能够识别数据包中的syn、ack等标志位，故能把建立连接和后续的数据传输过程区分开来。
　　iptables -A INPUT -p tcp --src $IP --dport $PORT ! --syn -j DROP
　　如上，在目的机器上加入该条iptables规则，可以实现将未设置syn标志位的数据包丢弃的功能，这样连接能够建立完成但后续的数据传输将无响应。
　　另外，Iptables具有一种连接跟踪机制，即能够记录连接的状态。这些状态分别是NEW、ESTABLISHED、RELATED和INVALID。我们可以利用该特性实现相同的效果。
　　iptables -A INPUT -p tcp -m state --state ESTABLISHED -s $IP --dport $PORT -j DROP
　　如上，在目的机器上加入该条iptables规则，当匹配了ip和端口，并且数据包所对应的连接状态是ESTABLISHED时将其丢弃。
　　至此read timed out异常也能轻松模拟了。Tc和Iptables是linux网络模块中强有力的工具，除了能够利用它们开发功能，也能够在网络异常测试中发挥关键的作用。

51Testing软件测试论坛圣诞活动期待您的参与~ipadmini 惠普平板 京东购物卡等你来抢！

　　1.测试脚本组织上不太了解应用在实际项目中怎样的组织编写方式，如何定义action、事务，检查点一般使用在什么情况下，是用文字、图还是函数，是否有规范的要求。

　　先简单解答一下什么是Action 什么是事务：

　　Action :是一组事务或是一个独立的事务，一个Action可能和服务器有多次交互，完成活动目的

　　Transaction:在Loadrunner 中定义是用来度量服务器相应VU的请求相应时间。

　　检查点：在每次事务提交后，服务器端都会返回响应信息，要通过对相应信息的检查来确认每次事务请求处理结果是否正确。具体采用什么样的检查方法，根据实际情况来确定，返回的是文字就验证文字，返回图片验证图片，返回数字验证数字。

　　2.测试场景中哪些监控器是常用的监控器，监控器中的监控指标也不太清楚常用的监控指标有哪些。

　　监控指标分为系统监控，应用监控，事务监控

　　事务监控：必须要监控的是事务平均相应时间，每秒处理事务数，事务成功率，事务失败率等

　　系统监控：分为CPU使用率，内存使用率，磁盘IO，网络IO 等具体指标说明见

　　应用监控：JVM，web服务器，apache IIS，数据库 oracle ，informix，中间件tuxedo weblogic等等

　　每种应用的架构不一样监控的指标也不一样，如tuxedo 使用MQ技术那么监控要看其消息对列大小变化，队列越长说明处理能力下降。

　　具体指标代表什么意思可以去网上查资料。上次发的文档里有一篇文章《Computer Performance Monitoring》是专门介绍监控指标的可以参考。

　　3.测试场景中如何使用IP Spoofer，什么情况下使用。

　　在一些系统中为防止网络攻击，对请求IP地址进行限制，当多个并发时候会拒绝请求。在这种情况下通过Loadrunner IP欺骗技术，构造数据包时候修改来源IP地址欺骗服务端IP过滤功能。

　　4.测试场景在项目中一般是否定义服务水平协议(SLA),在什么情况下需要使用SLA。与基于目标的场景有什么区别。

　　SLA是针对事务级别做阀值设置，设置数据在结果分析时有效

　　目标场景的设置是对控制台有效，影响测试执行。

　　5.测试分析中没有如何分析的思路，一般对哪些图表进行怎样的分析能够分析出问题。建议将‘Load Test(loadrunner).ppt’中的‘应用Loadrunner测试心得’进行培训。

　　这个可以安排时间组织讨论。

　　6.LR11中在录制脚本过程中没有录制下thinktime，而且没有找到在哪里设置录制时记录thinktime的地方。

　　11没找到设置位置，这个问题保留吧。如实在需要直接手工插入think时间。

　　7.在使用ip 欺骗时候如何判断vu用户使用的虚拟ip  

          更多精彩文章请上51Testing软件测试网查看

阅读全文

        下面介绍一下我使用Loadrunner测试时的一些心得、经验与教训。

一、性能测试步骤
        使用LoadRunner进行性能测试的步骤：测试计划-》设计测试用例-》录制测试脚本-》执行测试-》分析测试结果，这个测试步骤和常规的测试过程很类似。

测试计划

•分析应用系统

•定义性能测试目标（确定需求对应的度量指标）

•计划LoadRunner执行过程

阅读全文

        在购买工具，工具可用之后，可能由于测试人员对新工具或工具的替换，甚至对自动化测试的不了解，测试工具的升级，工具对公司产品需要大规模定制等原因，测试经理往往应该考虑如何通过培训可以让大家最快的熟悉并能掌握使用工具。

阅读全文

        于是这些日子抽空学着用QTP来建立wap网站的自动化脚本，可惜由于自己对QTP本身就不熟悉，所以一路磕磕碰碰，好在同事们都给予了大力的帮助，尤其是天彤，总算我也让QTP小小的run了一把。为了不让大家在同样的地方“摔跤”，也为了将天彤的“秘诀”发扬光大，整理心得如下：

        1.目前QTP支持在firefox运行脚本，但是录制仍然需要借助IE。而IE并不支持对wap的浏览，因此无法直接使用QTP创建对象库。并且尝试使用Opera进行录制时发现同样获取不到对象。接触过QTP的人应该都知道，对象是脚本的基础，所以这个时候需要我们做一次有意义的转换。首先我们在Opera中打开需要录制对象的页面，然后将页面保存为.htm后缀的文件，再使用IE打开这个保存的文件，最后就可以使用QTP的管理对象工具获取到这个页面上的任意一个你想关注的对象。

阅读全文