测试与毛泽东思想精髓
        毛泽东思想的伟大之处，在于它是一个系统的方法论和世界观，是哲学层面的理论体系。而毛泽东哲学思想的精髓在于理论与实践相结合，我们今天的市场经济就是引进西方的商业模式和中国的具体国情相结合的产物。而且不管是军事战役还是商战竞争，从哲学层面上，毛泽东军事思想肯定具有现实的指导意义。毛泽东思想根本不是宣传部门的政治口号，而实际上它是现在企业管理的利器。重新提倡毛泽东思想，不是文革中的"造神运动"的复辟，而是希望毛泽东的一些思想精髓能成为我们测试人的有力高效武器。
       连英国权威杂志《经济学人》都做撰文讨论，毛泽东思想是中国的无价之宝，随着中国在世界和平崛起，开始被西方世界认识。知识无国界，西方人很清楚！我们做为中国人，对于先辈的优秀文化遗产，更不要妄自菲薄。我觉得有责任把毛泽东思想与我们的测试工作关联起来，用毛泽东思想给我们测试工程师们补补课，从中吸收有利于我们测试工作的思想。

夺取全国胜利，只是万里长征走完了第一步
按测试用例完成了功能测试，只是测试走完的第一步。

发展体育运动，增强人民体质
      测试人员在忙碌后，要适当休息一下，自学一些产品相关的开发知识。例如：如果你的产品是基于VXWORKS平台实现的，则可以看一本介绍VXWORKS开发入门的相关的书。如果是基于LINUX实现的IP包过滤，则可以看看LINUX OS的代码结构，大致的数据结构，了解一些IP包转发的代码实现规律，修炼内功。

凡是反动的东西，你不打它就不倒
凡是有缺陷的产品，你不测试它，它就永远有BUG

妇女能顶半边天
  测试不是女同事的专属地，男女思维有别，测试最好能男女各顶半边天，

节约闹革命
无论测试设计还是执行时，都要充分利用测试时间和测试设备资源。节约闹测试。

阶级斗争要年年讲，月月讲，天天讲
重视测试要年年讲，月月讲，天天讲。不要只是2-3个星期的搞运动，过后大家又一滩死水。

救死护伤，实行革命的人道主义
  测试人员互相帮助，共同进步，一起提高产品质量的同时一起提高测试水平的修炼。

军民团结如一人，试看天下谁能敌
测试和开发团结如一人，一起实现天下无敌的高质量产品。

没有文化的军队是愚蠢的军队，愚蠢的军队是不能战胜敌人的
测试人员若由能力差的人组成，则这样的测试团队很难得到开发人员的重视，也很难得到公司的重视和投入，更谈不上士气的提升，专业水平的提高。

枪杆子里面出政权
  测试人员别空喊，公司不重视测试，开发不尊重测试。先拿出自己的所有本领，尽可能早的，多的找出重要的BUG，并帮助开发人员快速的定位BUG。用你的输出和业绩让开发人员从业绩和能力上尊重你，正如同我当年一个人负责测试的桢中继QOS的模块，该模块的开发人员同时维护3个功能模块，在经过我一段时间的折磨后，某日他主动对我说：我目前最放心的就是桢中继QOS的模块。往往开发人员修改的严重BUG越多，他们反而更放心，更钦佩相应的测试人员。

人定胜天
   坚定信念，BUG还会有的。别先太多归咎客观条件。

为什么人的问题，是一个根本的问题，原则的问题
  人，只有测试者的才智才是真正的强大的测试力量。依赖测试工具，基本不可能保证产品质量的完美。
曾有一个案例： 深圳S公司的某款产品常在实际应用中出现一些无法在实验室测试时发现的BUG。在经过2款业内顶尖的测试仪器测试后，只发现了一个严重BUG。该S公司后将这款设备交由一家专业的测试公司进行系统测试时，却在4天的时间内找到了4个严重BUG，让S公司不得不佩服这家专业的测试公司。而这家专业的测试公司，靠的不是所谓业内领先的测试仪器，而是主要依靠3-4名有着累计20多年测试经验的优秀测试工程师花了近半年的时间用人的大脑设计出的一个个高效的测试策略和测试方法达到这样的效果。
    所以，只有人民才是创造世界历史的动力。

人是要有一点精神的
测试人员至少需要一点信念，坚信BUG一定还有。

什么叫工作，工作就是斗争。我们是为着解决困难去工作、去斗争的 
   测试就是找BUG，以BUG输出为业绩。如果测试仅听开发人员说已不可能测出BUG，就不再测试的话，也就不需要专业的测试人员。

实践出真知
   所有的测试策略和测试方法的实际效果一定要靠实际动手实施论证后，才能知道是否真正有效。

世界上怕就怕“认真”二字，共产党就最讲认真
  很多BUG稍纵即失，如果测试人员不和开发人员较真，得到100%的确认，不要轻易放过任何一个测试人员自己主观怀疑的问题疑点。

贪污和浪费，是极大的犯罪
  漏测是犯罪，过度测试同样是犯罪。过度测试会浪费掉开发人员宝贵的时间，会让所有人忽视掉其他或许更重要更需要深入测试的地方。

我们不但善于破坏一个旧世界，我们还将善于建设一个新世界
  测试人员不但要善于找BUG，还要加强定位BUG重现的能力。找BUG是艺术，需要的是创造性，定位BUG则是科学，需要严谨的逻辑推理能力。所以，我爱说：好的测试人员一半是工程师一半是艺术家，是严谨与创造性共存于一身的人。

我们的干部，无论职位高低，都是人民的勤务员
      这段话针对我们初级的测试管理者，通常是一些工作年限较短，人生阅历较少的小组长，leader这类管理者。做了测试管理者不是当官了，你是领导而不是官。何为领导，拆开了说就是：带领大家奔向成功，指导大家克服困难，取得一步步的前进。我认为：做为团队领导应该鼓励远多于批评，毕竟测试干久了，是容易让人感到气馁的工作（bug越来越难找了），更需要做领导的，像关心自己家人一样关心自己的组员，组员成功了，才是团队的成功。
      当然，实际中由于诸多原因，很多组长,leader在还未完全具备领导素质的情况下，就因为早几个月熟悉项目，就被委任为了带头人。结果，很多自己做人都还不够成熟的人，在所谓的领导岗位上一次次的无意间伤害了组员的积极性，加速了团队成员的离职，让公司承担着各种招聘成本和项目风险。
     可能有些基层的测试朋友看到上面这段关于组长的话，心里觉得舒服了，替你出气了。请不要误解。关于组长与组员，团队的关系，我还有如下观点：就如同一对新婚夫妻，在年轻时因为自己的不成熟，因为自己缺乏足够的婚姻生活经验，很容易互相抱怨，埋怨而吵架。但如果双方能坚持互相理解，互相包容，互相扶持。总有一天，大家都能修炼成熟了，吵架，埋怨就会越来越少了，大家也就和谐了。因此，当我们基层的测试人若遇到很年轻不够成熟的管理者时，应该多一份理解，多一份包容。帮助他也是在为自己。这里我谈一个亲身的经历：在我早期的一个测试项目中，我的leader只比我早进入项目1年。有一次，在一个项目中由于销售的压力，我们在时间，人力，资源都很紧张的情况下，在离最终目标日期还有4－5天的时候，我们的leader看着目前项目的进度，顶不住来自其他部门的压力了，变得脾气开始有些急躁了，并直接表现在与我们的谈话和工作要求上。基本上小组的每个人都感受到了组长脾气的变化。在午餐时，我特意坐到了leader的对面，和他简单讲了一段话“越是在困难和越是在危险的时候，做为千军万马的带头人越要镇定，泰然自若。如果领军人表现出了恐慌，急躁，慌乱，肯定下面的部队也会恐慌，急躁，慌乱。更不利于大家一起齐心度过难关”。下午，我的leader悄悄给我发了封email，表示很感谢我中午给他的建议。最后这个项目依靠我们这个高效的团队利用周末的加班还是按时完成了交付。

无限风光在险峰
  越当我们发现不了BUG的时候，越是挑战自我，突破自我的时候来了。
  测试是一个没有止境做到100％完美的的工作。

虚心使人进步，骄傲使人落后
       即使你是找BUG数最多的测试人员，也要向身边的每一个测试人员学习他们的经验。毕竟每个人都有自己独特的思想和思路。 而测试生存和发展的根基就是发散的思维和不断增加的新测试方法。

星星之火，可以燎原
       对于测试新人而言，最难的是找到第一个bug，第一个严重bug。因为对测试新人而言，很可能第一次执行测试的时候，从事的是回归测试或一个已长期测试过的产品，测试目标本身能容易被找到的bug就比较少了。再加之测试新人所依赖的测试用例，也早已发现了用例能发现的所有bug了。所以，等于说新人一开始就直接遇到一个大的挑战。因此，新人第一次开始测试时，如果在前3天，甚至第一周没找到bug，也请不要灰心。回家去，坚定信念，发挥自己的创造性，去发现一些老员工没有用过的方法，至少先要乱想10个新的测试情景，来一一尝试，试图找到一个bug，哪怕是一个拼写bug。只要有了第一个bug就如同销售人员开了第一单，就你就可以星星之火，可以燎原了。

愚公移山，改造中国
     测试人员，不要指望1周时间就找到所有的严重BUG也不要期望一个测试人员或一种测试方案就可以保证整个产品的质量，饭要一口一口的吃，山要一点一点的移。一个产品的稳定，需要多人，多个版本，多个测试阶段，多种测试方案，一个一个的BUG积累起来，才能最大化的保证产品的高品质。

政策和策略是党的生命
   测试策略是一个测试项目成功与否的生命

真正的铜墙铁壁是什么，是群众，是千百万真心实意地拥护革命的群众
   测试部门真正的铜墙铁壁是从事各类测试相关工作的人，而且是有着真心实意地拥护公司的价值观和使命的人。并不是所谓的流程，仪器，工具。

自己动手，丰衣足食  自力更生，奋发图强
      产品的质量稳定要靠自己公司的测试人员的主动能动性，智慧和潜能的挖掘，高昂的士气来保证和提高。切不迷信靠几台测试仪器，几次技术培训，一些外部流程就能保证质量的提升。关键还是发挥和挖掘自身的潜力。

自动化测试的理解误区澄清：

1：是不是所有测试用例都可以自动化。

——不是所有的测试用例和测试步骤都可以转化为自动化测试。

在自动化测试投入较多的行业领先企业其自动化测试率有的能达到80％左右，但仍有20％左右的测试用例需要手工来进行测试。在国外通常从开发第一版测试用例时，就同步进行自动化测试脚本的开发，所以自动化测试率普遍比中国的企业高。

2：自动化测试找不到bug。

——自动化测试不直接找bug，而是通过解放有经验的测试工程师的生产力，让其从重复的回归测试中解放出来。从事新测试方法和测试手段的研究，通过自动化测试解放出的生产力来间接找到更多更深层次的新bug，将产品质量再提高一个档次。

3：自动化测试一定会马上大量减少测试人员数量。

——自动化测试不会大量减少测试人员数量。因为开展自动化测试初期需要投入一定的人力进行自动化测试脚本开发，并逐渐将自动化测试脚本用于日常的测试中，逐步减少手工测试人员从事重复劳动的时间和人数。为了缩短自动化测试脚本的开发时间，可考虑将自动化测试脚本的开发工作借助外包的力量来早日实现大规模的自动化测试。

4：自动化测试能代替手工测试。

——自动化测试不适合新功能测试，适合对软件质量稳定且经常需要被测试的模块进行投入开发。

5：只有性能测试才需要自动化。

——自动化测试不光进行性能测试，更被大量应用于功能测试验证，在国外超过半数的自动化测试脚本都是用于功能验证测试。

通常自动化回归测试较手工回归测试有如下优势：

   1：大大缩短回归测试项目的时间，在减少了人力投入的同时，更能保证研发  项目能按时市场发布。甚至能缩短研发周期，提前发布产品。

   2：在同样的产品研发时间内，能对产品进行更全面的多次测试，将新引入的问题尽可能的在产品发布前挖掘出来。

   3：能保障回归测试的质量。因为每次自动化回归测试都是保持同一个标准的步骤，环境和测试方法。所以测试结果具有一致性。

   4：让更有经验的测试工程师从回归测试中解放出来，专注于新的测试方法的研究，来发现更多产品深层次的问题。

   5：减少测试工程师人数，降低研发成本。因为实施自动化回归测试后，厂商就不用像以前一样保留一定的人力来专职进行回归测试。

   6：能避免测试人力和时间的紧张，而降低了回归测试的质量要求，导致引入了新问题而未被发现。

   7：没有在手工回归测试中因为测试工作的重复性和测试工程师对已测过功能的过于自信，而导致测试覆盖面不全，新引入问题没被发现的人为隐患。

   8：避免了部分工程师非主观的疏忽大意，没有发现新引入的问题。

   。。。。。。。。。

本文全部版权归原文作者董杰全部所有，且第一次发布是在51testing，如果其他朋友或机构要转载请先得到原文作者董杰的书面允许，否则将诉诸法律。

如下观点，只代表我个人观点，如有偏差，还望各位同行提出相应观点和意见。
如果网友看过我以前写过的文章，就能理解我如是如何理解定义测试的。

谁是测试团队中的核心技术人员

我个人认为对于公司测试团队中最重要的人是设计优秀测试策略和设计优秀ROI(ROI: 投入产出比)测试方案的测试工程师，当然自动化测试脚本开发工程师和测试工具开发者对于测试部也是非常重要和不可或缺的。

      为什么我认为测试部最重要的人是测试策略和测试用例的设计者？

       首先从相关人才的来源来分析：

自动化测试开发工程师：可以由只毕业3－4个月或才进入项目1－2个月的工程师就能从事。测试工具开发：甚至不需要对测试了解多少也能从事。而设计测试策略和好的测试方案设计者则需要至少2－3年的相关业务黑盒测试经验的工程师，才有可能做好。

       其次从相关人才发挥的作用分析：

测试策略的制定就好似公司的市场部要制定大的市场战略。例如：这个测试方案的定位是什么？这轮测试的目的是什么？有多少资源可以进行测试？应集中资源先对哪些重要又紧急的功能进行测试？如何区分重要或紧急的功能？如何安排紧急而不重要的功能与重要而不紧急功能的测试顺序？等等。。。。。。
测试方案的设计：就好似公司的销售部针对每个具体的客户制定具体的销售计划和销售方案。例如：对于这个case我们的目标期望是什么？如何达到这个目标？是否还有更好的方法来达到这个目标？如何利用现有的有限资源取得最大化的结果？这个case的ROI是否高效？而测试工具的开发和自动化测试脚本的开发则类似于公司中的研发部，提供必须的高效武器与公司市场部，销售部一起攻城拔寨。

如何成为一个合格优秀的测试策略的设计者呢。我的观点是：
1：一切测试策略的目的是什么？是为了满足公司市场销售策略。因此我们应该设法保证测试策略既能按期完成研发计划，又能不影响销售的产品质量。
2：将有限的资源先用到紧急又重要的测试任务中，再评估其他任务的优先级。但一定要以市场销售计划为依据。一个脱离市场销售的测试策略是一个误国误民的策略。
3： 测试策略不是测试计划。我的看法是：以市场销售计划为依据，先制定测试策略，再按任务的优先级和资源情况来制定测试计划。现在常有不少朋友误认为测试计划就是测试策略，测试策略就是schedule，这种观点我个人并不认同。
4： 测试策略不是一个人设计出来的。它一定是先听取了市场人员的意见和要求，再结合研发的要求得出的一个平衡取舍的产物。
5： 好的测试策略设计者是一个以公司利益为第一位，而不只局限在测试部门利益的员工。办公事政治玩多了，设计的测试策略有可能就是一个对公司利益有害的策略。
6：一定要最大化的接近客户的真实应用来定义重要的模块功能，而不简单依据模块的复杂度来定义。
7： 能知己知彼。对自己的测试资源有多少，要有准确清晰的认识才能知道量体裁衣。而不要打肿脸撑胖子，最后实施时，却完成不了测试策略。

      接下来，如何成为一个合格优秀的测试用例设计者。我的观点是：
好的测试用例至少要满足如下要求：（这里只讨论功能测试用例的要求）
1： 粒度一定要细，对功能需求中的每个小点，每个数据都要覆盖到。并尽量多的想到更多的测试方法来对被测试项进行拷打。
2： 测试方法不能过度测试。大家容易想到测试不充分对公司有害，但往往会忘记过度测试对公司也是有害的，这点在我的测试经历中感受非常深刻。例如： 因为你的过度测试，浪费了你的有效测试时间，这个时间原本是可以拿来发现更多真正有意义对销售有影响的bug。因为你的过度测试发现的bug，开发人员有时必须为这些意义不大的bug花时间来修改，浪费了修改其他更有意义bug的时间，影响了项目的进度，影响了产品的销售计划。说不定公司甚至因为你的几个过度测试，延迟了1个月推出产品，导致公司在这1个月中损失1亿的订单。而这些都是真正有可能发生的。所以，要避免在不漏测的前提，走向另一个极端－过度测试。
3： 你的测试用例是否容易转化为自动化测试。如果你在进行测试用例设计时，根本没有把将来进行自动化测试的开发做为一个考虑因素。那么，你的测试用例永远只能用手工进行回归测试，将大大浪费公司的资源并影响产品发布时间。如果回归测试的手工执行是你自己来做的话，那么以后你的苦日子可就长了。
4： 测试用例应该考虑执行时资源和时间的安排。例如：千万不要出现有的test case执行完一遍只需要1小时，有的test case执行完一遍却需要20个小时。为了便于测试管理和计划安排，应设法让测试用例未来执行的时间保持在一个参考值左右。假设一个标准test case的执行时间为4小时，那么设计的test case应尽量保持在3－5小时内。这样非常容易量化并管理测试用例执行者的工作，更有利于测试计划的安排，测试策略的制定，研发计划的按时执行。
5：理想状态下，最好你的测试用例也要有好的易读性。例如：test case的执行者拿到你的case后能在半小时或1个小时左右就能读懂并执行。否则，如果执行者还需要4－5个小时才能读懂或不能完全读懂你的测试方法和测试步骤。那公司将会为这样的测试用例付出非常大的成本代价，甚至会影响测试计划的执行和产品的研发计划。

总结：对于部分迷茫的测试工程师，如果你希望在测试领域发展而不是在代码开发领域发展，就不要误认为只有代码才是高手，只有代码才是好的测试工程师。要做一个对公司有最大价值的测试工程师，就应该尽量往成为 一个好的测试策略设计者和测试用例设计者成长和发展，但这一切工作又很依赖一个很基础的因素——工作的责任心，只有把公司的大局发展放入自己的心中，才能真正做好工作的取舍，设计出有价值的测试策略和测试用例。

这个问题是几位网友发email问我的。在此谈谈我的一家之谈。如有偏差，还望各位同行提出相应的观点和意见。
按我经历和看到的测试，测试通常分为如下几个阶段：
代码走读，白盒测试，灰盒测试，功能测试，系统测试。
代码走读通常是由开发人员互相评审执行。（可以提前发现很多代码中的问题）
白盒测试通常借助一些白盒测试工具来执行，还是由开发人员来执行。（我个人认为ROI并不高）
灰盒测试通常是针对一些关键的底层代码，如driver，或公用度高的代码来进行。通过写一些测试C程序来测试覆盖被测代码。这个工作可以由开发人员完成，也可以由测试人员完成。但同样不需要测试人员看代码，前提是一定要有非常详细的被测模块的功能定义。
功能测试和系统测试都由测试人员完成。自然是黑盒测试，不需要代码。
以我的经验来看，是否发现bug，与读code没有任何关系。反而我认为读代码，会降低测试人员的效率。
为什么？测试人员读代码，我认为有如下几个坏处：
1） 会让测试人员进入黑匣，反而看不到这个匣子的形状和大小。并不利于测试人员设计好的测试方案。
2） 浪费测试人员的有效工作时间。既然读代码的目的是为了更好的设计测试用例，那么就应该多思考如何设计好测试用例。看代码并不是唯一的方法。我的经验是：公司对被测模块的功能定义文档的详细程度将对测试用例开发起到非常好的作用。同时应多向开发人员询问一些问题，如：哪些模块开发人员觉得实现时很复杂，或开发人员自己认为哪些地方更容易出错。
3）测试人员自身并不擅长代码部分，读代码效率也不会高。
这些年工作经验和职业经验告诉我一个道理：无论我们做什么，在公司一定要注意ROI就是投入产出比。你要先考虑公司的投入产出比，再考虑自己的投入产出比。对于中国的企业，普遍处于追赶型企业，项目紧，资源少。
需要在质量和投入上做一个平衡，有时减少一些ROI低的测试流程对公司反而是一件好事。
我个人的观点和建议是：在产品正式交给测试部之前，开发人员一定要先互相进行code review，有资源的情况下，最好能对一些很底层的驱动进行API测试，这样会大大降低傻瓜bug的出现，保护好测试人员的时间，提高测试工程师的效率。
在测试部这端，应把精力多集中在功能测试和系统测试中，多花时间思考好的test stratagem and test case. 在进行测试策略和测试用例设计前，一定要多争取向公司申请详细完整的功能需求文档，设计文档（不需要实现文档）。在进行测试策略和测试用例设计的过程中，一定要多请几位公司技术服务部的系统工程师，听听他们从用户真实使用的角度提供的测试意见，SE的意见会大大提高测试的有效性，提高测试工程师的效率。
对于一个功能，我认为需要有如下类型的测试用例：
1： 功能测试 2：组合测试 3：室外应用测试 4：性能测试 5：压力测试。期间几种测试也可以互相组合。那么对于测试人员如何提高设计测试策略和测试用例的能力呢？
  第一牢记ROI。第二丰富的测试经验。第三时刻考虑以市场导向。
  第四自己对功能需求的真正把握。第五系统实现技术了解的多少。
关于测试用例的设计，我以后会再开一个专题来谈谈我的一家之言。
现在给junior测试者一些建议：
   1：对功能需求要非常熟练，一定不能对功能需求有任何一点误解或是不清晰的地方。其次，必须对功能定义中的数据流也要了然于心。
   2：尽量多了解与所测功能有关的其他功能的应用，可以大大扩展你进行创造性设计时的素材。
   3：多向开发者要一些不涉及代码的设计文档，这样你可以知道哪些地方在实现的时候复杂度高，容易出错。那你就进行重点攻击。
   4：多学习本公司产品实现的主要技术。例如：我在通信厂商，自然一切代码都是依托vxworks来实现的。所以，我在进行了3个月的测试后，自己从公司借了一本vxworks基本技术介绍的书来看。搞清楚了开发人员常常会用到的数据结构：如循环链表，mbuf, 知道了什么情况下读指针会跑到写指针前面导致data access的发生等等。 古人云：知己知彼，百战百胜。也就是这个道理。如果测试者对产品实现的主要技术有一定广度的了解，那么你设计的测试用例就会更有穿透力。
   5:  勤奋。在完成规定的测试后，自己多想想那里还可以再提高，再完善的。对自己潜力的挖掘，一定会大大提供你思维的发散性的，丰富自己的测试方法。

发布时间: 2007-7-17 11:06    作者: 董杰    来源: 51Testing投稿1.    开场白
　　首先，作为一个一直在网络和电信设备测试领域工作了几年的老油条，我想把我这几年的工作经历以及在我身边看到的故事与大家分享。希望能帮助一些刚进入测试的朋友能更好的从学生角色转换为一个职业人，少一些刚毕业时的迷茫。
　　我在大学时代学的是计算机，在毕业前对网络的认识也就是学校开设的两门课计算机网络以及计算机网络与通信课程，让我印象最深的是学了一大堆与高数有关的数学公式，例如什么香农公式这类。毕业前连IP子网都算不清，也就大概知道TCP,UDP的区别。我更多的时间和精力都放在了程序的开发上,曾用Delphi独立开发了一个全省系统的MIS系统，用Linux+Gcc+Gdb＋UDP开发了一个模拟QQ原理的即时聊天软件。