我的E家

目录历史经典人物的向上管理学1、达到预期2、超出主管自己达不到3、补位典型战国时代，秦国宰相范雎的封地汝南遭韩国侵占，秦昭襄王问范雎：“臣相失去自己的封地，会不会很难过？”范雎回答：“臣并不难过。”昭襄王又问：“为什么不难过呢？”范雎回话，说他原本是一介小民，本无封地，如今失去封土，就等于恢复原来的样子，为何要忧伤难过呢？昭襄王觉得范雎的话不合情理，就向将军蒙骜说：“我只要有一个城池被敌人围困，就寝食难安，可是应侯范雎失去自己的封地，却说他毫不难过，这是什么道理？”蒙骜说：“不妨让我去查一下实情吧！”于是蒙

精神打压，不断的否定和打压(让你无条件服从、变相裁员 +企图让你自己走人)不会以工作的角度去看待问题，而是会上升到态度、人品、能力等方面对员工进行批判：“你的能力太低了，连最简单的任务都完不成。”“你做的事情和外包有什么区别”“这个方案不行，重新改”、“你的效率太低了，看看别人”等等，以此来降低员工的自尊，经过一番“调教”之后，最后获得员工的无条件服从。比如“你这个脑子长着干嘛的？这么简单的事都干不好？”、“你到底还想不想干？不想干滚蛋，真是没用！”、“拿着公司的钱是让你来做事的，不是让你来玩的！”打着“看

这个事，你来主R吧希望每个人都能够独挡一面其实我对你是有点失望的我认为这个价值不大你的横向价值输出有哪些你的影响力怎么体现你做和别人做有什么区别？业界是怎么做的感觉你这个和某某很像，为什么要重复造轮子你的实现路径是什么相比上个Q这个Q哪些指标上升了，哪些下降了你这个策略底层逻辑是什么？顶层设计在哪？最终交付价值是什么？过程的抓手在哪里？如何保证结果的闭环？你比别人的亮点在哪里？优势在哪里？你的思考和沉淀在哪里？你有形成自己的方法论吗？换别人来是否会不一样？这件事儿的价值在哪儿？量化一下给我我早就和你说过以你

目录问题1：究竟是不是要做一个技术型的测开人员或测开团队？问题2：技术选型时可以从哪些方面入手？问题3：应该是何种态度看待当前团队/公司已有的工具平台？问题1：究竟是不是要做一个技术型的测开人员或测开团队？答案： 个人以为是的如下是依据：依据1：国内各个互联网大厂小厂的工作内容要求，对于代码开发能力是刚需(外包除外)；依据2：国内各个互联网大厂，各个职级晋升均有技术要求和技术影响力；依据3：很多效率问题、测试难点痛点问题，必须通过技术手段才能解决；依据4：重复的手

目录一、2种团队的特点二、深处在低效能团队怎么办三、写在最后一、2种团队的特点2种团队的典型特点：1）高效能研发团队(包括开发、测试、产品、业务等等人员)：(思维严谨) 研发质量过硬、事前事中独当一面、不抱怨，事后遇事handle，不是shirk。2）低效能研发团队(包括开发、测试、产品、业务等等人员)：研发质量呵呵、事前事中缺专业果敢，事后遇事shirk、shirk、shirk。 当然了，团队合作中，一次中大型项目合作后，其实很容易分辨出当...

摘要测试人员和开发人员之间的关系常常很紧张。 各方对另一方应该知道和做的事情有一定程度的期望，而对另一组必须工作的约束，条件和要求知之甚少。 但这不必是这种方式。 做出一些更具体和有用的反馈的努力可以大大改善态度。内容大家都知道猫和狗不相处。我对此的较不科学的解释之一是，这都是关于不良沟通的。当狗摇尾巴时，它说：“一切都很酷；让我们一起玩。”但是就猫而言，狗说的是：“当心！我真的很生气...

前言           工作3年+技术人员、测试人员在入职第一天，除了寻常的熟悉公司文化、团队人员、安装工具等等外，还需要了解什么，才能尽快上手新的工作呢？由于有丰富的工作经验，也接触了不同的团队、公司，那么除了所有公司共同的或者类似的工具、人员、流程外，这里梳理了一份需要尽快熟悉起来的清单。有了这份清单，相信能更快熟悉并上手业务了。入职第一天，应该做什么-(一)找领导沟通     ...

有慧眼识人的伯乐          只有善于做认识决策和不善于做人事决策的人，前一种人的成果使用时间换来的，后一种人，事后才会后悔不休         举例：为了人事决策问题郑重其事，例如是否聘用一个处理危机的人员，其他人评价对齐啧啧称道，能把问题解决的尽善尽美，还能冷静预判并防止危机的发生，过去业绩辉煌；         斯隆的反问： 这些被处理的天衣无缝的危机是怎么发生的？  ...

引言                之前写过候选人必知必看，这篇与之对应，从面试官角度，记录一些自己的心得体会。无论谁，处在什么位置上，可能都会有作为面试官的经验。               这里，不想就面试官需要具备的硬性能力(专业、沟通、知识面广度...)做强调。本文想就如何尽量避免在面试不通过情况下给候选人以预约的感受。一、面试官的沉没成本和收获             面...

引言                无论谁，处在什么位置上，都会有作为候选人，去面试的经验。但反观下来，面试者、候选人在每一轮1个小时左右的交流中，都会有不同层面的感受。当然，这个感受，一半和具体的面试结果/顺畅度有关，例如，面试中问答很流畅，结果符合双方预期，那么这个时候双方都是相对比较愉悦的心态，当然这是人之常情了。但是，如果双方聊下来发现不能达到互相满意的程度，情况往往会让双方都比较失望...

一、质量保证的核心目标 这个话题在实际的项目或团队中很少有明确的约定或口径，实际经验而言，可以归于一条：线上故障的减少。这个经验得来的目标实际是一个非常宽泛的目标了，通过团队成员的多方努力，这个目标仍然是“若即若离”。 站在不同人员的角度，对测试目标会有共同的期望：故障的减少 & 人效的提升 & 迭代周期的缩短。但对测试结...

 1、QA需要的优秀品质       1.会写，能写测试代码、测试工具       2.推动项目顺利进行       3.扎实的测试能力       4.沟通协调能力好       5.喜欢学习新事物2、采取措施对QA人员的"犯错"补救测试人员是软件的守护者，是保证软件质量的最后一道防线最后一道关卡，测试人员“犯错”，有相关的补充措施补救；3、测试与用户行为...

前言          最近项目中涉及了大量的前端页面类测试，如小程序、H5等多个B、C端的测试，故而想把一些心得记录下来，仅供大家参考。这里仅仅对前端测试中涉及的需求层面的问题做简单剖析，希望借此来抛砖引玉。前端测试的困境        回顾从刚刚入门测试到现在，进行了大量B/C端的页面类测试，包括：机票类页面、促销类页面、视频类页面、招聘类页面、广告运营类等等。测试范围包括：功能、...

一、出色的产品经理特质出色的产品经理从哪里来： 公司里面，只不过在其他岗位上。 优秀的特质：1、对产品的热情让应聘者谈谈喜欢的产品及原因，不同领域的产品和讨厌的产品2、用户立场目标用户的经验，喜欢，价值观，知觉能力，忍受程度，技术理解个人理解： 这里的用户立场，其实技术人员，特别是测试人员也是十分需要的，这也反过来印证了出色的产品经理可能在其他岗位上。3、职业操守一...

一、测试策略制定的出发点 测试策略可谓是质量保证的核心，关乎测试的深度和广度、效率提升、风险控制、质量运营等等方面。如何设计出符合业务需求，质量需求的测试策略，最能体现测试人员的功力了。设计测试策略可以从以下方面考虑深入下去：业务需求 真实的用户数据 技术实现方案 自身经验ps:考虑测试的内容和方式时, 都应当以高产出投入比为最终目标,最大化地利用现有资源排除...

前言            记得第一次是被一位后台开发人员问到了这个问题：想入门测试，应该看哪些书？当时推荐了好些技术类书籍，最后一想，只推荐开发书籍似乎缺了点什么，后来就又推荐了诸如《测试之美》之类的测试书籍。不知道那位开发同事到底有没有真正理解力推开发书籍的目的，不过从这个问题本身也可以反推出来：哪怕是和测试人员接触最为密切的开发人员，也不完全清楚测试究竟是什么。           ...

目录什么是团队团队协作的作用团队协作的五种障碍一、丧失信任二、惧怕冲突三、缺乏承诺四、逃避责任五、忽略结果克服团队协作的五种障碍一、建立信任二、掌握冲突三、兑现承诺四、增强责任感五、关注结果总结参考什么是团队        一少部分人(3~12个)有着同样的目标，为实现它们而负有同样的责任，并且当目标实现后会分享同样的奖赏...

目录业界/团队内部普遍已经有的共识业界几种评估不同时期bug修复代价的方法一、修复的时间二、修复时测试的次数三、修复花费的费用四、修复对上线的风险bug暴露的方法探讨总结业界/团队内部普遍已经有的共识bug的预防/避免 优先于 bug的发现； BUG越早发现的越好 bug给之后上线带来不同程度的风险 bug尽可能扼杀在上线之前，不然上线后很可能带来线上...

目录前言TL是什么一、带了一群人1、个人要专业2、团队管理二、干一些事情三、达成目标总结前言 TL，是 team leader 的简称，是一个团队的主心骨了。若干年以来，遇到了大大小小不同风格的直属TL，自己也有意无意的会指导后来的新同学。但，总的来说，无论是直接给自己指导，还是间接地影响自己的行为做事方法，还是直接的晋升、加薪、绩效等方面，T...

目录一、单元测试目标何为单元测试为何要进行单元测试如何进行单测-消除外部依赖二、难以测试说明设计不佳为何要关心设计开发人员需要遵守的各种原则测试人员需要遵守的原则关于作者Viktor FarcicAlex Garcia一、单元测试这本书上，看到对单元...

目录翻译内容QA Is Not The Enemy(QA不是敌人)Know What You Are Being Tested On 知道你在测试什么​Test Your Own Stuff First首先测试你自己的东西Avoid The Bug/Fix Cycle避免缺陷/修复周期Help With Automation 帮助实现自动化What About Th...

                                            背景            最近接触到一个客户端的业务，若干次大版本跟进下来，整个版本上线时间大致是这样的：一个夜黑风高的晚上，抬眼望去，四周其他团队已经走光了，看手机已经半夜近12点了，大家还在修修补补的做bug验证，主流程回归... 这样基本到了夜里一两点了，版本正式对外发布，于是可以验证主流程后，...

问题的背景             无论是日常工作中对流程落地的追踪，还是晋升答辩时，评审们经常喜欢反复追问的问题，大意就是：流程中某个环节落地不好怎么办？这里举一个实际的例子： 项目提测流程中有一个环节，测试人员在类似bugfree的平台上，写一些主流程方面的测试用例，让开发人员在提测前，需要执行这些测试用例，并且全部通过后，才能提测。这本来是一个极其常见的提测流程，但执行中为了防止开发人员...

                               目录 1~关键对话的含义2~关键对话的目标3~处在关键对话场景下的心理状态4~好公司和差公司的区别5~ 关键对话的重要性6~跟踪表现良好的人行为7~专注于真正想要的结果8~ 谈话禁忌9~决策的四种方式 自勉1~关键对话的含义两个或更多人参与讨论，条件：1）事关重大ps: 个...

前言             之前写深入bug产生原因分析(一)，这里主要从实际的项目bug中，总结出了实际bug的根源的几个方面。这些问题的解决不但没有对最终交付的产品有所裨益，反而耽误了不少测试时间。现在就简要做下梳理，并汇总自己在处理这些问题时的一些经验。             无效bug： 是针对有效bug来说的。无效bug是指需要花时间修复，但修复后又不会给即将交付的产品带来用...

                          目录前言一、开发人员发现bug是一种什么心情二、QA发现bug是一种什么心情三、产品经理遇到线上bug后的心情四、经验前言           无论你在团队中属于什么角色(开发、产品、测试等)，可能都需要换位思考，从其他角色的角度，来看待问题、思考和决策。由于发现bug是项目中十分常见的，这里就发现bug时的心情做...

一、测试团队的弊病 1、片面强调流程           流程能解决一部分问题，不能解决所有问题，还是应该找到根本的解决方案。目前越来越多的项目组，在业务比较成熟了以后，为了“减少”/"规避"上线后的故障，采用增加流程审批的方案：各种修改的审批各种review的增加小到一行代码的改动，大到一两个月的项目，统统走相同的流程。结果造成流程也就变成了所谓的流程，大项目不能通过其控...

一、测试背景       《微软的软件测试之道》建议从两因素组合测试开始，逐渐提高组合维度，直至6因素组合测试，因为有研究表明6因素组合测试可以发现绝大多数的程序缺陷。但是，随着组合维度的提高，测试用例数呈爆炸式增长。假设有N个因素，每个因素均有M个因子，所有的测试用例数=M的N次方。        举一个实际的例子，曾经测试过一个业务筛选类接口，总共涉及50+个因素的筛选，每个因素的值有...

《微信背后的产品观》一、微信回顾成为移动互联网的新入口产品经理：1）了解人性(人是懒惰的，懒惰恰恰导致发明；人是跟风的，追逐时尚；人没有耐心，没有耐心看你的说明书；人不爱学习-马桶阅读理论：不要给用户超过马桶上看不完的内容；)2）了解群体心理(用户是乌合之众；群体智商低于个体智商；互联网产品的用户是群体，非个体；重视屌丝用户)3）产品经理，建造系统并制定规则，让群体在体统中演化4）伟大的产品应该满

一、员工每天都比平常水平好一点点二、领导力 所谓“领导力”，不是“在员工面前摆谱”的能力，更不是给员工添堵的能力。恰恰相反，它是一种“服务员工”的能力，或者再说得明白点儿，是一种“让员工感到舒坦”的能力。 为了做到这一点，他们在员工面前绝不会表现得高高在上、不可一世。他们总是对员工给予最大限度的尊重，他们总是想方设法地成为员工的理解者、知心人与协助者。因此，在员工面前，他们总是能够展现出一种极为强

要点要点元素 描述 职位匹配度 职能要求匹配就好，并不需要超过岗位level多少； 并不是超出越多越好： 性价比问题 团队的整体水平 能否与团队的人员合作，能起到什么作用； 管理的难度 代码能力 常见的算法实现即可，不需要特别复杂的算法(毕竟不是招算法牛人) 代码实现上进一步考察： 实现效率，异常处理； 测试思路； ...

做事思维偶尔为之的事情，需要可行解；常常要做的事情，需要尽可能最优解/长远性的解类似的思考方式：对自己短期可以快速有大收获的事情——马上行动；对自己长期有大量收获的事情——制定阶段性计划；对自己收获不大，但必须要做的事情——寻找可行的方案；对自己有收获，且未来存在很多类似的事情时——寻找解决该类问题的方案/方法论将事情区分优先级紧急且重要的事情；紧急

参考：https://news.cnblogs.com/n/534978/一周内的能量波动图

一、前序曾经写过QA的软实力和硬实力的blog:QA的软实力和硬实力。作为一名测试人员，软实力和硬实力都是必不可少的。最近通过几个项目的“锤炼”，对QA的职责和工作思考重心有了几点理解。二、QA的三重境界第一境界：看山是山-“拼命”寻找bug此境界属于QA的入门级。刚刚入门QA时，往往以为寻找的bug越多，则自己的“能力越强”。甚至，不少公司，对QA的一项评定就是一段时间内寻找bu

一、居安思危的意识最近看到一篇有关技术人员中年危机的文章http://blog.youkuaiyun.com/csdnnews/article/details/78280033，个人感觉，三百六十行里，各有各的“危机感”，只是危机感的年龄段和程度不同。而面对“危机感”的出路，可能就是要有居安思危的意识，时刻为某种危机做准备，才能立于不败之地。二、不同阶段的危机感阶段一：(1~3年)初出茅庐的愣头青

企业治理中的个人英雄主义一、企业家在企业管理的过程中有这样两种风格：1）他们比较强势，外在表现就是精力旺盛，一个人能够处理掉企业发展中的所有问题，对企业有着强大的把控能力2）他们崇尚无为而治，把事情多数交给职业经理人去干，自己则到世界各地的名山大湖去游览，优哉游哉二、个人英雄主义在企业运营中的阶段性个人英雄主义在企业经营过程中是需要分阶段的：1）在企业初创期必须集权，推崇个

测试人员的特质测试人员拿了工资就是要告诉你他们所了解的一切事实，甚至有时候他们会直白得说你的小宝宝很丑，还给出一些列论据。测试人员的关键特质：好奇心(想弄清楚事物是怎么运行的)喜欢动手实验(想知道不同场景究竟发生什么)胆子大（不怕破坏东西，不怕据理力争）善于学习(工作性质要求)ps:办公室政治不擅长不容易相信任何人(别人总是告诉他们模块x不需要测试，或代码y“没

参考http://coolshell.cn/articles/17583.html感悟-积累阶段提升自己学习能力和解决难题的能力方法：把时间挤出来努力学习基础知识，多掌握一些技术（很多技术在思路上是相通的），然后才能有机会改变自己目前的状况工作5-7年，你需要拥有：高效的学习能力。这意味着——基础知识扎实、触类旁通

KISS原则即keep it simple, stupid。 直译：保持简单，让傻瓜都懂。ps : 突然想起了利郎男装的广告语，觉得用到kiss原则上，也很贴切：简约不简单。取舍之间张显智慧。多则惑，少则明。把简单的事复杂化是容易的，但把复杂的事情简单化，则是最困难的。对产品设计和体验的Kiss对于一个产品需求，随着需要的不断增加，实现的功能那是越来越多，功能全对产品来说是必要的。

小而精的工程师团队参考：http://vdisk.weibo.com/s/gN-sQ/1351485199创始人：工程师团队成员：个体能力强，每个人都是leader工作方式：剔除无创新工作自由时间：20%环境氛围：不断反思，相互学习个人理解： 每个人都是leader，不断从中反思，学习，进步，充满热情，每天有不同的精彩。团队成员选拔1)