测试的几个原则

1. 应当把“尽早地和不断地进行软件测试”作为软件开发者的座右铭。
2. 测试用例应由测试输入数据和对应的预期输出结果这两部分组成。
3. 程序员应避免检查自己的程序。
4. 在设计测试用例时，应包括合理的输入条件和不合理的输入条件。
软件测试的原则
5. 充分注意测试中的群集现象。
经验表明，测试后程序中残存的错误数目与该程序中已发现的错误数目成正比。
6. 严格执行测试计划，排除测试的随意性。
7. 应当对每一个测试结果做全面检查。
8. 妥善保存测试计划，测试用例，出错统计和最终分析报告，为维护提供方便。

关于bug

测试的原则---Good Enough

　　对于相对复杂的产品或系统来说，zero-bug是一种理想，good-enough是我们的原则。

　　Good-enough原则就是一种权衡投入/产出比的原则：不充分的测试是不负责任的；过分的测试是一种资源的浪费，同样也是一种不负责任的表现。我们的操作困难在于：如何界定什么样的测试是不充分的，什么样的测试是过分的。目前状况唯一可用的答案是：制定最低测试通过标准和测试内容，然后具体问题具体分析。

测试的规律----木桶原理和80-20原则

（1）木桶原理

　　在软件产品生产方面就是全面质量管理(TQM)的概念。产品质量的关键因素是分析、设计和实现，测试应该是融于其中的补充检查手段，其他管理、支持、甚至文化因素也会影响最终产品的质量。应该说，测试是提高产品质量的必要条件，也是提高产品质量最直接、最快捷的手段，但决不是一种根本手段。反过来说，如果将提高产品质量的砝码全部押在测试上，那将是一个恐怖而漫长的灾难。

（2）Bug的80-20原则。

　　实践证明。80%的bug往往隐含在20%的软件区域。所以一旦在某处发现了bug，多找找周围。这也是有经验的测试员的一种方式。

   一般情况下，在分析、设计、实现阶段的复审和测试工作能够发现和避免80%的Bug，而系统测试又能找出其余Bug中的80%，最后的5%的Bug可能只有在用户的大范围、长时间使用后才会曝露出来。因为测试只能够保证尽可能多地发现错误，无法保证能够发现所有的错误。

其实也不是局限于电子产品，只不过电子产品这个问题突出一些。

现在很流行的趋势，电子产品一般只要你买得起的，大家一般都不会选择去买国货。尽管广告天天在打，可是很多消费者并不认可。原因何在？产品的质量有问题，产品的售后也不好。这说明了什么，生产开发这些产品的人有问题，质检的人也没有起到很好的作用。恶性循环的结果是这个厂家失去了市场和受众的信赖。

还是拿手机来说，同样的价位，国产的手机肯定销量远远小于nokia，为什么，因为几乎所有的人都认可nokia的质量，却无法给国产手机以同等的信赖。也说明了这个道理。

一个企业赖以生存的是信誉，是产品的质量。所以你如果去过车间，都会看到很大的一个条幅，上面写着“质量是企业立足之本”。这句话没有错，但是在实际上，中国人的中庸哲学和理论却无法，至少在很多时候，没有保证真的把这句话落到实处。为什么？成本。一文钱瘪倒英雄汉，更何况你为了某个产品需要花大价钱开请高手？

我没做过nokia手机的测试，我曾经做过3年左右的日系手机的软件测试。他们的手机品质不错。我们使用的对比机就是nokia的手机。企业的目标就是同样的问题，nokia不出现的，我们的手机出现了，就是问题。当然如果nokia也出现了，值得提交的问题也要提交。

我很感恩那段日子，虽然每天都处在“辐射”的阴影里，我在那段日子里学了很多。学到至少日本企业的那种严格的管理和缜密的思维以及规范化的流程。

这在后面的参加的国内，国际项目中是没有遇到过的。“一叶知秋”，做习惯国内项目的人很少有人能去做日本项目，原因是觉得他们“跟变态似的没事找事”。但是我要说的是，没有严谨或者说过于严苛的工作习惯，出来的东西到底自己有多少把握？安全性如何？易用性如何？性能如何？

举个简单的例子，我在日企做手机测试提交的bug分为五个等级。每一个bug的提交都要自己的初步分析，精简操作步骤，横向纵向对比（不同的硬件操作确认排除硬件问题，不同版本的软件操作确认出现问题的那个版本，不同类型但是有一定关联的相关程序或者格式文件的操作缩小范围），log文件的提交等一系列的过程。当然还需要找到依据，做任何事情都要有根据，发行bug也不例外。没有根据的只限于手机死机，重启这样的问题。然后才能够进行提交。提交之后的处理也是慎之又慎。会有专人来进行这些问题的后续retest把关，并且把处理的结果及时与测试部负责人进行沟通，便于测试人员进行及时的retest。程序员和测试员只有确认的义务，没有处置的权利。一旦发行错了bug或者本来没有修复的给确认成了TestOK，会受到很严厉的处罚。

在项目进行结尾的时候，对所有的问题和所有的项目都要进行一一排查。

严谨而有序的工作流程造就了高质量的产品。付出和获得始终是成正比的。

国内项目倒是鲜少遇见这样的事，导致我一开始去做的时候还不习惯。总有人抱怨我，你发一个bug整那么多对比信息干嘛？倒是让我哑口无言。很多事情没有根据。我们在测试的时候，开发人员在随时的进行更改，经常发生我们测试过的东西一转眼就被改掉了不得不重新测试的问题。

做国内项目很苦。因为很多的开发人员很随意。他们对自己很看重，觉得自己是太阳，测试人员是为他们服务的。他们为了赶进度，只能随时改，而你测试的，也就只能随着他们的步骤去做。测试人员提交了bug，他们给你面子才会很快的处理，处理完了基本上也不会告诉你。我当时的感觉就是，恍然大悟。我终于明白了国内的产品为什么PK不过外国的。或许说这话有人会有意见。所以我声明，我希望我只是看到了最灰暗的一角。其他的都是好的：）

同事说，国内项目很多都是这样的。然后我发现，浸泡在这样环境中的他们，做事情也是很随意。或许这就是近墨者黑的另一种体现。

一个很好的思维，一个很好的习惯造就一套很好的流程，一个很好的可控的严谨的流程可以缔造一个高质量产品的生命。

为了我们的国货，国内的软件开发流程还有很长的路要走。中国的劳动力成本在上升，中国的劳动力已经不是优势。而我们是不是也该好好想想，如何和国外那些同行们在质量上PK，取得一席之地？

我只想说，做开发的，全局来考虑一下，做测试的，把好自己的门，有责任心的去面对你测试出来的东西，不要管别人怎么看。因为，你是最后一道关。。

***不过说实话，做对日项目，严苛的管理制度是一种很沉重的折磨，虽然受益良多，但是不想再去做。hoho。。

编外：

不是说买国货就是爱国，不买国货就是不爱国，虽然总有人在争论这个东西。也不是说爱国非要说国货的好，关起门来，我们要想的是如何从心理真正的认同，甚至是世界认同我们的质量。这需要所有人的努力。诚然，世界都充满了“Made in China”，也并不能说明，中国的质量如何好，因为中国是世界工厂，廉价的劳动力吸引了太多人来中国投资办厂。如今，中国的劳动力优势渐渐失去了，中国的未来靠什么取胜？质量！只有质量提高了，才能真正的做到全世界使用中国的东西是因为质量好而不仅仅是便宜。

这个问题

我记得我在感悟软件测试这个帖子里面说过，只是不明确

诚然，我也不是大家，说的话也没有权威性，只是说明一下自己的感悟。

测试需要懂编程知识。但是不是所有的测试都会用到编程知识。

要是你想要做自动化测试，编脚本是基本的能力，所以你要会脚本语言以及协议
一个不懂得脚本语言的人，是不够资格去做自动化测试的。因为你除了简简单单的录制脚本之外，需要设置的东西很多。需要你用脚本语言进行控制。

msn测试中国里经常有人问，为什么他录制的lr跑不了？很多原因在于脚本控制有问题。比如，对于web里面随机弹出的某个窗口的控制。你在录制的时候可能没有，但是回放的时候出现了。那你的脚本自然就跑不下去了。解决这样的问题，怎么能缺了脚本语言的基本功？

还有，为什么我录制了，看不到脚本？很多的时候是因为协议选择错误。要了解其中的原因，自然也是需要了解一些协议方面的知识了。

要是你要做白盒测试，一定要知道白盒测试的几种基本方法。因为方法决定了你要会的东西。

静态白盒测试，需要做的任务是检查设计和代码，主要就是静态的检查，审查和走查；动态白盒测试主要是让程序运行起来，然后进行相关代码的检查。主要手段有数据覆盖，代码覆盖（条件覆盖，分支覆盖）等。

理解了这些，就不难知道，要想做白盒测试，懂得测试的程序，至少保证能看懂和能改，能够进行代码注入是应该具备的能力。自然，根据不同的项目要求，需要具备的编程能力就不同。

黑盒测试，很多人说，这是最没有前途的测试种类。我不这样认为。黑盒测试，对于测试员的要求，业务的理解，客户需求的理解绝对要高于一切。也就是说，用户需要什么，你的关注点就在那里。比如说，手机测试，你就要保证等到用户拿到这个手机的时候，使用的时候，是满意的。不能有任何的问题，至少是让用户无法容忍的问题出现。奔着这个目标，自然就知道自己该关注的问题是什么。至于你测试的这个程序是用什么语言编写的，有哪些实现的方法，并不重要。重要是这个东西，能用，好用，易用，安全，可靠，然后用户满意。

此外，还有对于测试全局的把握，不能做好手头的那一块就完事了。这是和开发人员最大的区别。你必须从更高的角度来看待问题。了解更多，发现更多。比如说你测试A模块，但是发现了B模块的问题，发不发这个bug在其次，你一定要让负责B模块的人知道哪里出现了什么问题。你不是在抢他们的生意，也绝对不可以视而不见。因为你的这一个“忽略不计”，可能会给这个产品带来隐患，导致这个厂家以后会蒙受巨大的打击。你也必须对得起在你身后，付了钱的，等着使用的用户们。因为你在为他们将要使用的产品负责。

至于测试工具，数据库，我觉得脑袋聪明一点，学习能力好一点的，这些东西，会一种顺手的就可以了。剩下的，都是工具嘛，用到了在学其实才是学习最快的方式。

最后还是自己写过的那些话：

软件测试从立项到出厂，也是一条长长的流水线，我们都是关注其中某一段的人。虽然说软件测试全程关注，但是也少有人少有项目组从头到尾都在参与。一般会有不同的人不同的项目组参与不同的阶段。在某一段，某一个领域，你成为资深的专家已经够让你学习一辈子。这样理解的角度来看，其实如何一种有这种全程质量思想，认为软件质量高于一切的人，都可以胜任这份工作，区别就是你发展的空间有多大而已。

如果我说，我就想做一辈子黑盒测试，那么我一点编程也不会，但是懂很多的业务，比如银行的软件，通信的软件，sap等，我熟悉所有的流程和业务体系。也可以啊。你会编程，会数据库。但是你不懂业务，我们一起去应征，我敢说，除非他们需要白盒测试，否则他们会要我不要你。。因为很简单，客户是上帝，我诠释的很好。而你未必可以。

不过，要是以上你都会，就可以成为“武林高手”了。不过，目前的江湖缺少秘籍，不知道要你学多久

推荐给：刚刚入门的新人

推荐语：这是一篇关于测试员角色定位的文章，希望可以给刚入门的人，入门不就感到有些迷茫的人一些启示。

其实我们从小学，到大学，学到的哲理，格言不下亿万句，在人生的某个时刻能真正对你有用的那一句才算真的有用。这篇文章，当初也给了我极大的启发。特推荐至此。

声明：来自testage的《测试员》第一期（节选）

   很多刚进入门的同仁开始慢慢对做测试流露出迷茫的眼神，问其原因，很简单，做测试学不到东西，整天就鼠标点点，键盘敲敲，很难学到真正的东西。

听了之后不由得露出理解的笑容，想当年我也是从这样的境遇走过来的。刚进入公司的时候就让做测试，经历了同样的鼠标点点，键盘敲敲的经历。然而正是这样的一些成长经历让我在平淡中明白了很多道理，并且慢慢从因为工作而做测试转化为因为兴趣爱好而继续做测试工作。

    做测试不仅仅是表面看到的这种敲敲点点现象的延续，还有更深层次的内涵，只

是我们很多人还没到达这个境界而已，所以看起来很枯燥。

    刚开始做测试的朋友很多都在做黑盒测试，而黑盒测试往往对代码编写能力要求不是很高，这样给刚入门的人就造成了一个测试人员不需要太多知识的误解。

    然而，做测试往往需要很广泛的知识。不仅仅只是专业上的，而且要了解很多开发人员不了解的东西，在一个系统里面开发人员可以只了解客户需求，而我们的测试人员需要了解整个全局的东西。呵呵，感觉有点统筹全局的成就感。不过有时候相对于开发人员来说也的确是这样的。开发人员可以不用太多了解用户的需求，而我们却需要能够准确捕获用户的观点，对很多细节需要非常注意。

    往往很多人在初入测试行业的时候非常热衷于测试工具的学习以及使用，其实这并不是一个很系统的认知。知识的学习也是分阶段的。测试这两个字很表面来看很简单，只是给程序挑错误，找出bug 来，但是在整个软件开发过程中我们该如何把测试跟开发结合起来有效地进行都需要经过实践来证明。而这些不是工具所能完成的。我们对整个测试流程方面的东西需要了解得很多很多，而工具只是需要了解的其中一部分而且是比较小的一部分知识而已。

    你所了解的不仅仅只是测试的表面，你需要了解测试的流程，你需要了解如何用一个好的测试计划来规划我们的测试时间、测试范围（有些公司把测试范围的设计归纳在测试需求里面，但是很多公司都是在测试计划里面），需要了解如何用一个好的测试用例来覆盖整个测试范围之内的测试实施。了解如何保证所测试出来的bug 是开发人员的问题而不是因为自己了解不够导致出现的问题。Bug 分析报告之内如何总结问题都是我们需要注意到的知识。对自己的测试时间也需要进行详细规划，尽量多地考虑进去各种可能。这样才可以尽量减少相关的风险。

其实这些问题真的在哪个论坛里都有，不过奇怪的也是，每次面试都会遇到，无论是自己面试还是给别人面试。。

PS:声明一下，这里的问题基本都不是原创的，答案呢，在软件测试“百家争鸣，百花齐放”的时代也是丰富多彩的。但是道理都差不多。仅作为参考，呵呵~~

什么是“软件测试”？

1。出自(IEEE, 1986; IEEE, 1990).

Software testing is the process of analyzing a software item to detect the differences between existing and required conditions (that is, bugs) and to evaluate the features ofthe software item

就是一个通过分析软件和需求之前差异，发现bug,对软件的功能进行评价的过程。

2。软件测试就是在受控制的条件下对系统或应用程序进行操作并评价操作的结果。

3。软件测试是为了发现错误而执行程序的过程。

这一种也是大多数文档和书籍进行的定义，其实和第一个定义没有什么区别。

什么是“测试案例”?

测试案例是一份文档，它描述了一个输入、反应、或者是与其相应的预期的响应，以便来判断应用软件的工作是否正常。测试案例应当包括测试标识、测试案例的名称、目标、测试条件/设置、输入数据要求、步骤、以及预期的结果。

如果时间不够，无法进行充分的测试怎么办?

使用风险分析，确定测试的重点。

由于很少有机会对一个应用软件进行所有可能的测试 (包括所有可能的事件组合、所有的相关性、或者一切可能出错的东西)，对大多数软件开发项目来说，利用风险分析是适当的。这需要判断技能、常识、感觉和经验。如果有正当理由，也可采用正式的方法。需要考虑下列因素：

ü  对于该项目的用途而言，哪种功能最重要?

ü  哪种功能对用户最明显?

ü  哪种功能对安全影响最大?

ü  哪种功能对用户最有用?

ü  对客户来说，该应用软件的哪个部分最重要?

ü  在开发过程中，该应用软件的哪个部分可以最先测试?

ü 哪一部分代码最复杂，容易导致出现错误?

ü 哪一部分的应用程序是在急迫或在惊恐的情况下开发出来的?

ü 哪一部分程序与过去项目中引起问题的部分相类似/有关?

ü 哪一部分程序与过去项目中需要大量维护的部分相类似/有关?

ü 需求和设计的那些部分不清楚或不容易读?

ü 开发人员认为在应用软件中哪些部分是高风险的?

ü 哪些问题能造成最差的发行?

ü 哪些问题最能引起用户抱怨?

ü 哪些测试可以容易地覆盖多种功能?

ü 哪些测试在覆盖高风险部分的测试时使用时间最少?

如果需求一直在变化怎么办?

这是一个常见的令人头疼的问题。

ü如果可能，尽早与承担该项目风险的人接触，以便了解需求会怎样改变，从而可以尽早地改变测试计划和策略。

ü 如果在对应用程序进行初始设计时多考虑一些适应性，那么以后在发生需求的改变时，就不需要再为改变做很多事情了。

ü 好的代码注释和好的文档有助于开发人员作出相应的改变。

ü只要有可能，就应使用快速原型 (rapid prototyping)，以帮助用户确认他们的需求，从而减少变更。

ü在项目的时间表中应当留出余量，以应付可能出现的变更。

ü尽量把新的需求纳入应用软件的“下一版”，而把原始需求作为“第一版”。

ü通过谈判，把易于实现的新的变更列入项目，而把难于实现的新需求列入该应用软件的以后的版本。

ü要确保让客户和管理人员了解变更对进度表的影响、所带来的风险、以及因变更所引起的大量资金消耗。

ü在应付改变时，应在为建立自动测试而作的努力和重新进行测试所做的努力之间取得平衡。

ü在设计自动测试剧本时，试图使其有一些灵活性。

ü在对应用软件进行自动测试时，要把注意力集中在看来不大会改变的部分。

ü对变更进行适当的风险分析，以减少回归测试的要求。

ü在设计测试案例时要有一定的灵活性。做到这一点并不容易，所以要降低测试案例的详细程度，或者只建立高级的通用型的测试计划。

ü 少注意详细的测试计划和测试案例，要把重点放在专门的测试 (ad hoc testing) 上。

很可恨，不会有游泳。据说在游泳的时候，尽量把自己放松，沉下去的人才能浮上来。

大学的时候有这样一首歌谣，大一的时候，知道你不知道，大二的不知道你不知道，大三的时候不知道你知道，大四的时候，知道你知道

其实也算是人生的一段缩略箴言，可以让人在某些时刻想起它感慨良多。。

很喜欢的一部由苏友朋，贾静雯等主演的《倚天屠龙记》，俊男靓女的组合让我耳目一新。很多东西也是让我感触颇深。记得关于有一场张三丰临阵教授太极剑法给张无忌的。。。张无忌刚开始全都记住了，后来忘记了一小半，又过一会儿忘记了一大半，最后全都忘记了。。然后赢得了胜利。片中的张无忌是个武学奇才，又有机遇，总有令人想象不到的机遇。

但是那一段我印象很深，也总在以后的工作中时时想起。虽然不知道为什么会在全部忘记的情况下才能挥洒自如，也不知道何时自己在软件测试这个领域也能有如此的造诣。

时间回首4年前，自己刚刚踏入软件测试这一行，真的是什么都不知道。在实际的工作中，点点滴滴从头学起，也才发现，很多东西原来如此妙不可言。

很多人都说，测试这个东西没有技术含量。说这话的人更多的是有些开发经验的，但是却做不成开发，“不得不转入“测试队伍里来的人。那个时候也曾迷茫过，特别是朝朝暮暮面对着同样的流程，同样的步骤，总是在不停的重复的同样的工作的时候。。

后来，越来越多的人在随声附和那个声音，测试没有前途，测试没有技术含量，尤其是黑盒测试，到大街上随便抓一人来，一个礼拜的学习，准可以干测试。。

我开始思索，我是不是真地走错了路？是不是真得如此没有前景。

感谢这个时代，让我可以在网络上找到很多我需要的资料。然后我发现，不是没有技术含量，而是因为我不懂，我们的不懂，我们陷入了误区，盲区，才会永远在那个巴掌大的地方挣扎着。。

于是我开始学习，利用工作之余的时间进行学习，然后我发现，很多的思维都在悄悄改变，很多的方法与之前不同，我开始知道，自己原来是如此的适合这个行业。

随后的日子里，我的收获开始让更多的人受益，我开始对管理和测试的流程提出自己的见解而且颇有成效，我开始根据实际的工作情况，对项目组进行培训，让我们大家共同成长。

然后我发现了，我知道得越多，不知道得越多。。

我开始烦躁，开始不知道该怎么办？

那一天，偶尔看到了一篇人生哲理，以学习游泳作为比喻，沉下去，浮上来。恍然大悟。

是的，只有沉下去，踏踏实实，才能浮上来，越走越宽。。

于是，我在众人的不解与迷茫中辞掉了之前的testing leader的工作，不舍得挥别了我亲手带出来的子弟兵，来到了另外一个公司，从一个测试员开始，踏踏实实，重新做起。

这里有着丰富的资源，我可以学到更多

这里有着众多的机会，我可以体验更多

这里有着众多活的资源，我可以成长更多

我相信，我的努力不会白费

我的明天，一定会更加明朗。。

这篇文章，现在写，似乎有些晚了。毕竟，算算日子，离开之前的岗位，已经3个多月了。

2007年的6月27日，我正式的离开了工作了3年的公司，也将永远的告别了曾经让自己为之奋斗过的岗位--手机软件测试。

2004年，大学毕业之后，我和千千万万个毕业的学子，带着希翼和迷茫，在如潮的毕业生专场寻觅过，在人才市场穿梭过，在路边的报摊因为购买招聘报纸驻足过。。

最终，没能以这样的方式找到合适的工作。而是因为一个巧合，巧遇一位贵人，把我，领到了手机测试的大军中。

我开始在自己完全不懂得世界里寻找自己的方向。

工作上，我学会了什么叫做MT call, MO call,什么叫做MIDlet,什么叫做JAR, Mainfest..终于，经过一个又一个项目，我成熟了，飘洋过海出国差，也在别人的瞩目中拿到奖状，手把手带出自己的子弟兵，也带着自己的队伍冲刺拼杀。。。时间走过了3个春秋，我已经蜕变，不再迷茫，不再青涩。我知道自己面对的是什么，知道自己该寻找的又是什么

最终，在这样的季节，我选择了离开，准备了储备了三年，我学到了自己能学到的一切，我离开了。带着留恋，也带着遗憾，遗憾我的青春不容许我再浪费我的光阴于这不该再驻足的地方。。

新的地方，截然不同的东西，新的地方，截然不同的挑战。但是，激情依旧在，我深信，我的明天，依然灿烂~~

记得高中的时候，曾经有位高高帅帅的学长，在我们学习最为艰苦的时候，前来探班

现在已经不记得他的名字和长相，只记得他说了一句话。

“如果你的世界只有碗口那么大，你不懂也只有碗口那么多；如果你的世界变成了圆盘那么大，你不懂的也会变多。。”当时有些似懂非懂，此刻倒是明白了很多。

软件测试，04年，带着一份新奇，一份感悟，一份兴趣，我加入了这个行业，至此已经将近四载岁月。

最初的一无所知，懵懵懂懂；后来的略有所知，似懂非懂。。我对这个行业的理解也在这跌跌撞撞中不断的加深。

软件测试，据说某些测试培训学校说，不需要会编程，不需要外语很强，不需要。。只要3-6个月强化培训，便可成为软件测试“精英”，月薪8000.。

我不知道为什么会有人会相信。但是我明白，诱惑的力量。我更加知道，这是不可能的。

有句话说的很不错，适用于任何行业：你的价值与你的可替代率成反比。比比皆是的软件测试培训学校，出来的人有几个人说，我无可替代？那么，既然别人随时都可以替代你，我为什么要给你那么多的钱？很容易理解的道理，确实让很多人迷茫。。

软件测试，测试的理论，测试的经验，测试的思想，测试的工具以及必要的计算机知识都是测试员不可或缺的东西。

理论，如今是百花齐放，不亚于春秋战国的百家思想，只是国内的权威的比较少。空理论的比较多。很多“著作”翻翻看看，都差不多。这也算一大悲哀。

经验，需要实践来积累，理论和实践相结合，这是我们学到的知识。但是理论应用于多变的实践，往往会有不一样的效果，如何去甄别？如何去看待？这需要时间，需要积累。不能被同一块石头绊倒。

思想，某种程度来说，这属于天赋的一部分，就如有些人善于理，有些人喜好文，没有理由。软件测试也是一样，没有测试的思想，对它只有功利的想象，没有真心的投入和理解。。。。。。无论如何，你都捅不破那层窗户纸。测试实践中，遇到的瓶颈会特别多，然后，你会放弃，也意识到，自己对这个行业，其实真的没有兴趣。到头来，不过是浪费了时间和精力，还有宝贵的青春。

工具，某种程度上讲，工具是个死东西，熟能生巧。区别于项目的需求不同，策略不同。所以我觉得某种程度上讲，招聘信息上写，精通XX工具，其实有些可笑的。因为昨天不代表今天，今天不代表明天。潜力和人品才是最重要的考核标准。

计算机知识，很多人问我，测试需要会编程吗？很多网站上也会纷飞着这个帖子，加上很多人“一千人眼中一千个哈姆雷特的解释”。我也只能说，看你自己的选择。

软件测试从立项到出厂，也是一条长长的流水线，我们都是关注其中某一段的人。虽然说软件测试全程关注，但是也少有人少有项目组从头到尾都在参与。一般会有不同的人不同的项目组参与不同的阶段。在某一段，某一个领域，你成为资深的专家已经够让你学习一辈子。这样理解的角度来看，其实如何一种有这种全程质量思想，认为软件质量高于一切的人，都可以胜任这份工作，区别就是你发展的空间有多大而已。

无论怎样，软件测试的目前还是这样一个状态，很多良莠不齐的人在参与，很多的风险在暴露；很多人在讲它如何重要，很多人在软件风险的切实体会中知道真的要去培养专业的队伍。。

我还在学习，在实践，也在观察。希望看到有一天，软件测试也有明媚的春光。

这个行业，这个行业中的我们，都是艺术以及创造艺术的人。

做国内测试项目的若干感悟

谈到这个话题，就会想起若干年前，柏杨先生的一篇让国人为之痛骂的《丑陋的中国人》

我觉得，一个国家一个民族的个性真的可以体现在各个方面。

比如：我做的测试项目，从对日测试到欧美测试，就感触颇深。

日本人的等级森严，阶级尊卑的传统体现在他的工作中就是非常严格而规范的流程。项目中的每一个参与者都有其确定的身份，也就有其确定的权限和责任。

符合项目制定的规范，严格按照既定的逻辑和标准去做事，成为日本项目的一大特点。

在工作中，你发现了一个问题，你会明确的知道应该向谁汇报而不能越级。一旦出现问题，会进行责任的层层追究，考勤，考核都有严格的流程。。

而相对而言，非常崇尚自由和个性化的欧美项目，就会有着相对宽松的氛围。在工作中，你发现了一个问题，你 可以有更加宽泛的范围去选择汇报和询问的对象。只要能保质保量的完成工作的内容，没有人在乎你是提前来了半个小时还是早走了15分钟。。

国内项目，我觉得就是比较尴尬的一个现象。一方面，归根于中国几千年来的封建等级制度，有一种层层汇报的制度。但是每个组成部分却不能像日本项目一样界限分明，于是当问题出现的时候，不知道找谁。似乎是对日本规范的一种抵制，国内大多项目不喜欢制定严格的规范和流程。表面是充斥着各种的自由和个性，但是却缺乏后期很好的维护。以至于在破烂不堪的表面，残存着若干或大或小的问题。

做国内项目，只有2个词的感受：上火~

我也衷心的希望，这只是个案。。

对日项目的时候：

项目开始2个月前，我们会有项目启动会议。会得到项目的TTSJ等需求文档，客户与开发之间协商的可开发，不可开发的最终成果文档。我们会了解这个项目的总体流程。

项目开始一个半月之前，我们会得到项目的系统详细设计和概要设计文档。大家利用这些文档进行测试系统的熟悉，测试点的划分，测试case的抽取，设计，测试case的评审。并且开发方会定期将系统设计变更的文档予以公布，供我们进行备案，以及对测试点的修改（一般来说，成型的测试case很少进行改动，而是会进行notes添加，在后续测试中才会针对notes和设计文档对测试case进行修订）

项目开使之后，会维持部分模块的稳定性，比如当前测试A模块的时候，A是绝对不允许开发人员在测试中进行修改，而是在既定的测试完成之后，开发才可以进行修改，并且提出修改文档，回馈测试方，声明修改了哪些部分，供测试人员进行retest

测试人员发行bug之后，相关的开发人员会进行修改，修改的记录和测试员后续测试的记录会追加在bug表上。在测试员进行retest确认关闭后，开发的负责人要给予该bug关闭的原因。项目结束后，这些原因也会成为软件质量的评价因素之一。

软件项目完成后，项目组需要书写评价报告，包括软件的质量总体评价，负责测试的模块中出现问题的几率，原因分析等。

国内项目：

至少我参与过的国内项目，测试员会在实际测试开始2周内参加测试，这期间包括了对系统的熟悉，测试式样的设计。而且一般的测试项目，因为项目实际开发与需求的脱节性，加上开发人员时间的紧迫性以及没有形成良好的文档约束性。测试人员基本在项目开始的时候是拿不到设计文档，包括详细设计和概要设计文档。能得到的只是很久之前的或者无效或者部分有效的一份比较模糊的需求文档。。

我不太清楚，这里面的原因到底在哪里，但是我清楚的知道，这样的需求文档，能到导致的问题是：测试人员需要跟开发以及需求人员去核实一些重要信息。这在很大程度上取决于测试人员的主观能动性和测试的经验，而且由于对测试系统的熟悉程度不够，也很难做到没有遗漏。。。直接导致的后果就是测试的效果下降，测试出来的产品留有或多或少对后期有影响的bug。

bug这一块，国内项目往往开发和测试出现重迭，也就是说，我刚刚测试过的模块，可能转瞬就被改过了，导致测试量的浪费。不得不进行无规则的重复的测试。

而且国内的开发人员很少会有这样一个习惯，对bug进行针对性的定位和反馈。在他们看来，自己的开发模块都忙不过来，能抽出时间来进行修改已经是给了测试人员天大的面子，哪里有时间进行反馈，有什么必要？殊不知，这样的想法在很大程度上造成了测试管理的滞后，导致系统整体的质量受到影响。

说到这里，都似乎忘记了自己写这篇文字的初衷。

虽然，我们大家都说，全面质量管理，都说，测试和开发都是软件生命周期中不可或缺的重要一环，但是到目前为止，至少在国内，很多的企业，重视的依然是开发，对于测试，特别是独立的第三方测试，依然是不重要的补充。依然是开发后期才能参与进来的。

没有人不重视食物的质量，因为攸关人命，一种不合格的罐头可能会导致成百上千人的中毒以及死亡。所以食品企业的质管员责任重大。他们监督着流水线上的每一个环节。没有人不重视建筑的质量，尽管在当今，由于利益的驱动，这份责任在被淡化，进而出现大桥坍塌，住宅小区裂缝等质量问题，关乎民生。。而在软件这个领域，虽然人们说了很多年，软件质量，软件质量，但是对于软件测试的重视程度依然还在低水平徘徊。开发的没有高超的技能，做不了开发了，就以为一定能做好测试，一个个培训机构，几个月就要“培养出”月薪8000的“测试精英”。。我倒是想问，测试，软件测试，到底在你们这些人眼中，意味着什么？没有测试的灵魂，没有测试的信念，只为了追风，只为了薪水而进入测试行业的人，到底会给我们的测试行业，带来什么？？

******************************************************************************

这篇文章本来写在csdn，感谢51test的兄弟把它转载到了这里，并且成为精华。

于是努力找回密码，再次开始我的51test生涯：）