小木虫 --- 500万硕博科研人员喜爱的学术科研平台
软件工程:需求分析的20条法则作者: 收集于网络
　　对商业用户来说，他们后面是成百上千个供应商，前面是成千上万个消费顾客。怎样利用软件管理错综复杂的供应商和消费顾客，如何做好精细到一个小小调料包的进、销、调、存的商品流通工作，这些都是商业企业需要信息管理系统的理由。软件开发的意义也就在于此。而弄清商业用户如此复杂需求的真面目，正是软件开发成功的关键所在。&　　经理：“我们要建立一套完整的商业管理软件系统，包括商品的进、销、调、存管理，是总部-门店的连锁经营模式。通过通信手段门店自动订货，供应商自动结算，卖场通过扫条码实现销售，管理人员能够随时查询门店商品销售和库存情况。另外，我们也得为政府部门提供关于商品营运的报告。”&　　分析员：“我已经明白这个项目的大体结构框架，这非常重要，但在制定计划之前，我们必须收集一些需求。”&　　经理觉得奇怪：“我不是刚告诉你我的需求了吗？”&　　分析员：“实际上，您只说明了整个项目的概念和目标。这些高层次的业务需求不足以提供开发的内容和时间。我需要与实际将要使用系统的业务人员进行讨论，然后才能真正明白达到业务目标所需功能和用户要求，了解清楚后，才可以发现哪些是现有组件即可实现的，哪些是需要开发的，这样可节省很多时间。”&　　经理：“业务人员都在招商。他们非常忙，没有时间与你们详细讨论各种细节。你能不能说明一下你们现有的系统？”&　　分析员尽量解释从用户处收集需求的合理性：“如果我们只是凭空猜想用户的要求，结果不会令人满意。我们只是软件开发人员，而不是采购专家、营运专家或是财务专家，我们并不真正明白您这个企业内部运营需要做些什么。我曾经尝试过，未真正明白这些问题就开始编码，结果没有人对产品满意。”&　　经理坚持道：“行了，行了，我们没有那么多的时间。让我来告诉您我们的需求。实际上我也很忙。请马上开始开发，并随时将你们的进展情况告诉我。”&风险躲在需求的迷雾之后&　　以上我们看到的是某客户项目经理与系统开发小组的分析人员讨论业务需求。在项目开发中，所有的项目风险承担者都对需求分析阶段备感兴趣。这里所指的风险承担者包括客户方面的项目负责人和用户，开发方面的需求分析人员和项目管理者。这部分工作做得到位，能开发出很优秀的软件产品，同时也会令客户满意。若处理不好，则会导致误解、挫折、障碍以及潜在的质量和业务价值上的威胁。因此可见——需求分析奠定了软件工程和项目管理的基础。&拨开需求分析的迷雾&　　像这样的对话经常出现在软件开发的过程中。客户项目经理的需求对分析人员来讲，像“雾里看花”般模糊并令开发者感到困惑。那么，我们就拨开雾影，分析一下需求的具体内容：&　　·业务需求——反映了组织机构或客户对系统、产品高层次的目标要求，通常在项目定义与范围文档中予以说明。&　　·用户需求——描述了用户使用产品必须要完成的任务，这在使用实例或方案脚本中予以说明。&　　·功能需求——定义了开发人员必须实现的软件功能，使用户利用系统能够完成他们的任务，从而满足了业务需求。&　　·非功能性的需求——描述了系统展现给用户的行为和执行的操作等，它包括产品必须遵从的标准、规范和约束，操作界面的具体细节和构造上的限制。&　　·需求分析报告——报告所说明的功能需求充分描述了软件系统所应具有的外部行为。“需求分析报告”在开发、测试、质量保证、项目管理以及相关项目功能中起着重要作用。&
　　前面提到的客户项目经理通常阐明产品的高层次概念和主要业务内容，为后继工作建立了一个指导性的框架。其他任何说明都应遵循“业务需求”的规定，然而“业务需求”并不能为开发人员提供开发所需的许多细节说明。&　　下一层次需求——用户需求，必须从使用产品的用户处收集。因此，这些用户构成了另一种软件客户，他们清楚要使用该产品完成什么任务和一些非功能性的特性需求。例如：程序的易用性、健壮性和可靠性，而这些特性将会使用户很好地接受具有该特点的软件产品。&　　经理层有时试图代替实际用户说话，但通常他们无法准确说明“用户需求”。用户需求来自产品的真正使用者，必须让实际用户参与到收集需求的过程中。如果不这样做，产品很可能会因缺乏足够的信息而遗留不少隐患。&　　在实际需求分析过程中，以上两种客户可能都觉得没有时间与需求分析人员讨论，有时客户还希望分析人员无须讨论和编写需求说明就能说出用户的需求。除非遇到的需求极为简单；否则不能这样做。如果您的组织希望软件成功，那么必须要花上数天时间来消除需求中模糊不清的地方和一些使开发者感到困惑的方面。&　　优秀的软件产品建立在优秀的需求基础之上，而优秀的需求源于客户与开发人员之间有效的交流和合作。只有双方参与者都明白自己需要什么、成功的合作需要什么时，才能建立起一种良好的合作关系。&　　由于项目的压力与日俱增，所有项目风险承担者有着一个共同目标，那就是大家都想开发出一个既能实现商业价值又能满足用户要求，还能使开发者感到满足的优秀软件产品。&客户的需求观&　　客户与开发人员交流需要好的方法。下面建议20条法则，客户和开发人员可以通过评审以下内容并达成共识。如果遇到分歧，将通过协商达成对各自义务的相互理解，以便减少以后的磨擦（如一方要求而另一方不愿意或不能够满足要求）。&1、 分析人员要使用符合客户语言习惯的表达&　　需求讨论集中于业务需求和任务，因此要使用术语。客户应将有关术语（例如：采价、印花商品等采购术语）教给分析人员，而客户不一定要懂得计算机行业的术语。&2、分析人员要了解客户的业务及目标&　　只有分析人员更好地了解客户的业务，才能使产品更好地满足需要。这将有助于开发人员设计出真正满足客户需要并达到期望的优秀软件。为帮助开发和分析人员，客户可以考虑邀请他们观察自己的工作流程。如果是切换新系统，那么开发和分析人员应使用一下目前的旧系统，有利于他们明白目前系统是怎样工作的，其流程情况以及可供改进之处。s&3、 分析人员必须编写软件需求报告&　　分析人员应将从客户那里获得的所有信息进行整理，以区分业务需求及规范、功能需求、质量目标、解决方法和其他信息。通过这些分析，客户就能得到一份“需求分析报告”，此份报告使开发人员和客户之间针对要开发的产品内容达成协议。报告应以一种客户认为易于翻阅和理解的方式组织编写。客户要评审此报告，以确保报告内容准确完整地表达其需求。一份高质量的“需求分析报告”有助于开发人员开发出真正需要的产品。&4、 要求得到需求工作结果的解释说明&　　分析人员可能采用了多种图表作为文字性“需求分析报告”的补充说明，因为工作图表能很清晰地描述出系统行为的某些方面，所以报告中各种图表有着极高的价值；虽然它们不太难于理解，但是客户可能对此并不熟悉，因此客户可以要求分析人员解释说明每个图表的作用、符号的意义和需求开发工作的结果，以及怎样检查图表有无错误及不一致等。&
5、 开发人员要尊重客户的意见&　　如果用户与开发人员之间不能相互理解，那关于需求的讨论将会有障碍。共同合作能使大家“兼听则明”。参与需求开发过程的客户有权要求开发人员尊重他们并珍惜他们为项目成功所付出的时间，同样，客户也应对开发人员为项目成功这一共同目标所做出的努力表示尊重。&6、 开发人员要对需求及产品实施提出建议和解决方案&　　通常客户所说的“需求”已经是一种实际可行的实施方案，分析人员应尽力从这些解决方法中了解真正的业务需求，同时还应找出已有系统与当前业务不符之处，以确保产品不会无效或低效；在彻底弄清业务领域内的事情后，分析人员就能提出相当好的改进方法，有经验且有创造力的分析人员还能提出增加一些用户没有发现的很有价值的系统特性。&7、 描述产品使用特性&　　客户可以要求分析人员在实现功能需求的同时还注意软件的易用性，因为这些易用特性或质量属性能使客户更准确、高效地完成任务。例如：客户有时要求产品要“界面友好”或“健壮”或“高效率”，但对于开发人员来讲，太主观了并无实用价值。正确的做法是，分析人员通过询问和调查了解客户所要的“友好、健壮、高效所包含的具体特性，具体分析哪些特性对哪些特性有负面影响，在性能代价和所提出解决方案的预期利益之间做出权衡，以确保做出合理的取舍。&8、 允许重用已有的软件组件&　　需求通常有一定灵活性，分析人员可能发现已有的某个软件组件与客户描述的需求很相符，在这种情况下，分析人员应提供一些修改需求的选择以便开发人员能够降低新系统的开发成本和节省时间，而不必严格按原有的需求说明开发。所以说，如果想在产品中使用一些已有的商业常用组件，而它们并不完全适合您所需的特性，这时一定程度上的需求灵活性就显得极为重要了。&9、 要求对变更的代价提供真实可靠的评估&　　有时，人们面临更好、也更昂贵的方案时，会做出不同的选择。而这时，对需求变更的影响进行评估从而对业务决策提供帮助，是十分必要的。所以，客户有权利要求开发人员通过分析给出一个真实可信的评估，包括影响、成本和得失等。开发人员不能由于不想实施变更而随意夸大评估成本。&10、 获得满足客户功能和质量要求的系统&　　每个人都希望项目成功，但这不仅要求客户要清晰地告知开发人员关于系统“做什么”所需的所有信息，而且还要求开发人员能通过交流了解清楚取舍与限制，一定要明确说明您的假设和潜在的期望，否则，开发人员开发出的产品很可能无法让您满意。&11、 给分析人员讲解您的业务&　　分析人员要依靠客户讲解业务概念及术语，但客户不能指望分析人员会成为该领域的专家，而只能让他们明白您的问题和目标；不要期望分析人员能把握客户业务的细微潜在之处，他们可能不知道那些对于客户来说理所当然的“常识”。&12、 抽出时间清楚地说明并完善需求&　　客户很忙，但无论如何客户有必要抽出时间参与“头脑高峰会议”的讨论，接受采访或其他获取需求的活动。有些分析人员可能先明白了您的观点，而过后发现还需要您的讲解，这时请耐心对待一些需求和需求的精化工作过程中的反复，因为它是人们交流中很自然的现象，何况这对软件产品的成功极为重要。&
13、 准确而详细地说明需求&　　编写一份清晰、准确的需求文档是很困难的。由于处理细节问题不但烦人而且耗时，因此很容易留下模糊不清的需求。但是在开发过程中，必须解决这种模糊性和不准确性，而客户恰恰是为解决这些问题作出决定的最佳人选，否则，就只好靠开发人员去正确猜测了。&　　在需求分析中暂时加上“待定”标志是个方法。用该标志可指明哪些是需要进一步讨论、分析或增加信息的地方，有时也可能因为某个特殊需求难以解决或没有人愿意处理它而标注上“待定”。客户要尽量将每项需求的内容都阐述清楚，以便分析人员能准确地将它们写进“软件需求报告”中去。如果客户一时不能准确表达，通常就要求用原型技术，通过原型开发，客户可以同开发人员一起反复修改，不断完善需求定义。&14、 及时作出决定&　　分析人员会要求客户作出一些选择和决定，这些决定包括来自多个用户提出的处理方法或在质量特性冲突和信息准确度中选择折衷方案等。有权作出决定的客户必须积极地对待这一切，尽快做处理，做决定，因为开发人员通常只有等客户做出决定才能行动，而这种等待会延误项目的进展。&15、 尊重开发人员的需求可行性及成本评估&　　所有的软件功能都有其成本。客户所希望的某些产品特性可能在技术上行不通，或者实现它要付出极高的代价，而某些需求试图达到在操作环境中不可能达到的性能，或试图得到一些根本得不到的数据。开发人员会对此作出负面的评价，客户应该尊重他们的意见。&16、 划分需求的优先级&　　绝大多数项目没有足够的时间或资源实现功能性的每个细节。决定哪些特性是必要的，哪些是重要的，是需求开发的主要部分，这只能由客户负责设定需求优先级，因为开发者不可能按照客户的观点决定需求优先级；开发人员将为您确定优先级提供有关每个需求的花费和风险的信息。&　　在时间和资源限制下，关于所需特性能否完成或完成多少应尊重开发人员的意见。尽管没有人愿意看到自己所希望的需求在项目中未被实现，但毕竟是要面对现实，业务决策有时不得不依据优先级来缩小项目范围或延长工期，或增加资源，或在质量上寻找折衷。&17、 评审需求文档和原型&　　客户评审需求文档，是给分析人员带来反馈信息的一个机会。如果客户认为编写的“需求分析报告”不够准确，就有必要尽早告知分析人员并为改进提供建议。&　　更好的办法是先为产品开发一个原型。这样客户就能提供更有价值的反馈信息给开发人员，使他们更好地理解您的需求；原型并非是一个实际应用产品，但开发人员能将其转化、扩充成功能齐全的系统。&18、 需求变更要立即联系&　　不断的需求变更，会给在预定计划内完成的质量产品带来严重的不利影响。变更是不可避免的，但在开发周期中，变更越在晚期出现，其影响越大；变更不仅会导致代价极高的返工，而且工期将被延误，特别是在大体结构已完成后又需要增加新特性时。所以，一旦客户发现需要变更需求时，请立即通知分析人员。&19、 遵照开发小组处理需求变更的过程&　　为将变更带来的负面影响减少到最低限度，所有参与者必须遵照项目变更控制过程。这要求不放弃所有提出的变更，对每项要求的变更进行分析、综合考虑，最后做出合适的决策，以确定应将哪些变更引入项目中。&
20、 尊重开发人员采用的需求分析过程&　　软件开发中最具挑战性的莫过于收集需求并确定其正确性，分析人员采用的方法有其合理性。也许客户认为收集需求的过程不太划算，但请相信花在需求开发上的时间是非常有价值的；如果您理解并支持分析人员为收集、编写需求文档和确保其质量所采用的技术，那么整个过程将会更为顺利。&“需求确认”意味着什么&　　在“需求分析报告”上签字确认，通常被认为是客户同意需求分析的标志行为，然而实际操作中，客户往往把“签字”看作是毫无意义的事情。“他们要我在需求文档的最后一行下面签名，于是我就签了，否则这些开发人员不开始编码。”&　　这种态度将带来麻烦，譬如客户想更改需求或对产品不满时就会说：“不错，我是在需求分析报告上签了字，但我并没有时间去读完所有的内容，我是相信你们的，是你们非让我签字的。”&　　同样问题也会发生在仅把“签字确认”看作是完成任务的分析人员身上，一旦有需求变更出现，他便指着“需求分析报告”说：“您已经在需求上签字了，所以这些就是我们所开发的，如果您想要别的什么，您应早些告诉我们。”&　　这两种态度都是不对的。因为不可能在项目的早期就了解所有的需求，而且毫无疑问地需求将会出现变更，在“需求分析报告”上签字确认是终止需求分析过程的正确方法，所以我们必须明白签字意味着什么。&　　对“需求分析报告”的签名是建立在一个需求协议的基线上，因此我们对签名应该这样理解：“我同意这份需求文档表述了我们对项目软件需求的了解，进一步的变更可在此基线上通过项目定义的变更过程来进行。我知道变更可能会使我们重新协商成本、资源和项目阶段任务等事宜。”对需求分析达成一定的共识会使双方易于忍受将来的摩擦，这些摩擦来源于项目的改进和需求的误差或市场和业务的新要求等。&　　需求确认将迷雾拨散，显现需求的真面目，给初步的需求开发工作画上了双方都明确的句号，并有助于形成一个持续良好的客户与开发人员的关系，为项目的成功奠定了坚实的基础。
本栏目更多导读：作为一名软件测试工程师，需要具备哪些能力？
按投票排序
通用技能上：1.基本计算机知识（操作系统，数据库，通讯协议原理，熟悉至少一门编程语言）2.基本软件测试知识（各种测试理论，测试方法论，测试用例编写，缺陷界定标准，软件质量评估）3.简单项目管理知识产品、系统认知：1.熟悉所测产品功能，能够将产品文档内描述的UC转化成TC，这个最最基本2.熟悉所测产品的一些隐藏需求或者功能（业务上的进阶能力）打个比方，支付公司上一种新的支付渠道，熟悉业务的测试人员应当可以预见到这次升级可能会对前段界面、系统账务、各类报表等各个模块造成影响，从而一并纳入测试范畴。要知道，很多时候，即便是接入这些渠道的产品经理，也不一定会在Prd或者UC中对这些可见影响项一一列出，这需要经验和责任心。性格上：1.有牛皮糖属性的为佳，越“不要脸”越好测试工程师，在很多公司，和研发是有业务上对立属性的（虽然从宏观角度上来说，都是为了提高软件质量服务）。测试工程师提交的BUG越多，意味着研发工程师工作质量越差，需要返工的工作量也越大，甚至会影响绩效，所以测试工程师有时候很容易得罪研发部门。一个可以相对坚持原则（比如3级BUG以上一定要改），又能拉下脸和不愉快的研发工程师保持较好关系的测试工程师，会对项目质量起到很关键作用。说到底，又能做事（发现BUG并督促修改），又会做人（该进的不让，该退的绝对给面子，最大化消除部门间矛盾）的测试工程师，是十分难得的。2.有异想天开属性的为佳这个只可意会，不好言传的。在我带过的团队里，的确有那种奇葩……经常会用令人匪夷所思的方式找出BUG，这是天赋。3.会“偷懒”的为佳这里的偷懒不是指上班发微博聊天混日子，而是能够利用已知资源对枯燥乏味的测试工作进行优化的同学。说个实例：我以前公司曾经上过一个“授信”项目，做过金融类项目的同学大家都知道。授信项目的测试用例真可以说是相当变态，随着账期、滞纳金率、手续费率、利息率、本金、还款情况的不同，可以衍生出无比多的用例，同时每个用例进行编写时，都要仔细根据规则计算预期结果的资金状况，非常费力。咱部门一个小伙子，头一天晚上拿了PRD，第二天晚上就利用Excel写了一个固定某些账期下不同情况下的各项资金计算工具(有一些小BUG，无伤大雅)……大大减少了兄弟们按计算器的工作时间。这种“懒”员工，你是领导你喜欢不？事情没完，在实际测试的过程中，我们发现一旦研发修改了BUG，会引发其他用例的大崩溃（这类项目真悲剧，牵一发动全身），每次版本升级我们都不得不进行全面的回归测试。太坑爹了，这不是要命么？聪明的测试同事们又想偷懒了，他们在数据库端写了一个数据匹配工具，每次新跑用例就拿正确的（已保存）数据文件自动去比对新产生的文件，自动返回比对结果。兄弟们再也不用每次回归都一行行打SQL去查数据了，棒极了。在研发修改BUG之余，他们自己写了一套存储过程，可以实现数据的自动回归和增量备份，再也不用每次把所有数据擦光从第一个交易日跑起了，棒极了！说了那么多，其实就一句话：干一行，爱一行。
触类旁通。你不是产品，但你知道产品是怎么工作的；你不是运营，但你知道用户关心什么；你不是开发，但你知道开发同事怎么工作；你不是设计，但你有你对交互逻辑的理解；你不是销售和编辑，但你熟悉产品业务。常识知识。常识好的人产品逻辑好（概述）。沟通能力。基本地，把一个问题表述清楚。能说服开发把bug改掉，不改掉的得要求明确回复原因。维护测试工作的尊严，坚决抵制欺负测试人员的行为。计算机知识。和你目前工作最相关的知识，你最应该先掌握。心态好。测试有时候比较枯燥，重复性强。遇上一茬新来的开发同学，你会感到测试工作回到很久以前了。综和各种情况，说明测试需要好心态。
一、知己识人
所谓知己就是清楚的认识自己，什么才是对自己最重要的。就测试这个职业来讲，我认为自己得到什么，学到什么才是最重要的。很多人看到这里可能觉得是正确，这种大道理谁都知道。但是平时呢大部分往往，嗯，保证产品 质量，保证公司企业的质量。但是有多少测试做的事情是真正自己想做的，又有多少做的事情是对自己有意义的。可能工作本身带来不了很多的学习点或者兴趣点，但是我们不能被忙碌的工作，频繁的项目，坑爹的老板所迷惑，因为我们是测试，我们是一个需要提升自我修养，提升自我知识面才能够更上一层境界 的职业。所以笔者自己是时不时的会问自己到底学到了什么，自己需要的是什么。
所谓识人，这里所说的识人不是说怎么识别好人坏人，而是如何去面试一个测试，如何给一个测试去定一个要求。为什么笔者会提到这点，就如上面所说的，现在很多人进入了测试的圈子。笔者自身是一个做移动互联网的测试，同样也经历过了上海，北京，杭州等地在各个不同阶段的面试。感觉到了不仅仅应聘测试的IT们迷茫，企业 本身对于测试的定位也很迷茫。面试就是第一个能够看出来的地方。个人觉得测试这个职业很奇特，因为除了学历，技术还和这个人的各个方面素质有着紧要的关系。当然这里我不想多的举例子，我只想给各个面试官以及企业 一点建议，筛选海量的简历的确可以靠曾经的工作经验，可以靠学历。但是希望在面试过程中能够从“态度”“开拓性思维”“为什么要做测试”三方面去做检查，如果发现有欠缺能够在入职之后进行相应的培训补足，这样的话，我相信对于广大测试人和企业来讲都是会看到好处。同样的会加速推动测试行业的发展。
二、找到测试的意义
这里其实就和知己很像，我相信这次chinatest的讲师也好，我碰见的各位同仁也好，每个人在企业中都分别扮演着自己的角色。我相信我们大家的角色绝对不会只是定位在找bug。但是我也同样的看到很多测试人没有找到测试的意义，很多上层或者老板觉得测试就是为了保证质量，呸！他们只会觉得测试是为了找到bug的，无论嘴上说的多好听，很多人最后还是会用数据来定你的KPI。但是，我们不能因为如此迷茫了自己，迷失了做测试的意义，不能 最终 为了测试而去测试。测试的意义在于从各个角度，各个维度去保证 产品的质量。这句话是废话，也是空话。但是为什么我想这里提醒大家找到测试的 意义呢，是因为只有测试人找到了测试的意义（可能是提升自己的管理 能力，提升自身的技术能力 ，分析能力等），那么才不会在各种困难，各种挫折面前迷失了自己，才不会为了测试而测试，最终得不偿失。
当你在执行测试用例的时候，意义在学习别人写用例的思路，学习设计方法，不在重复劳动上面。
当你在编写测试用例的时候，意义在于怎么能够更好的分析需求，分析需求，写出有意义的有限的用例，不在为了完成任务，写上成千上万条用例。
当你面对找缺陷这个常见的任务的时候，意义在于学习研究各种方法，各种技术找到质量高的缺陷，分析总结，不在为了去完成缺陷数量而去找。
当你作为一个测试管理者的时候，意义在于你要学习管理，你要引导测试人，你要体谅沟通 。不在写好用例之后简单的让他们去执行。
当你面对一个周期很短，测试又很少的项目的时候，意义在于你要学会评估风险，合理使用好各种方法应对，从而积累，不在用自己的生命换取产品所谓的质量
当你觉得做测试没有意义的时候，意义在测试为你带来了什么，测试让你学到了什么，不在你是不是想跳槽或者转行
三、心理素质
笔者为什么将这条放在那么前面呢，这里不得不提到，笔者在仅仅只有两年工作测试经验的时候就已经亲身经历过了身边的测试由于心理问题而最终选择绝路的事情。能从心理上真正了解测试的只有测试，这点我深信不疑。任何一个测试最先面对的心理压力就是重复性的劳动。测试人是愿意去做？是否愿意去寻求这重复劳动中的真谛？这其实是任何一个测试都应该迈过的一个坎儿。 而在之后的测试生涯中，依然会碰见很多心理的考验，自己对于质量心里没有底、或者由于产品发布问题 遭到了老板的职责、或者和开发以及其他人闹不开心、或者找不到缺陷时期的郁闷、达到了测试瓶颈时候的困惑等。测试也是人，每个人都有自己的背景以及性格，这些时间一长，往往对于测试来讲，就是考验心理素质的时候，你是否还 看得清自己的路，是否还知道自己做测试的初衷，会不会对于自己做测试去质疑等等。测试这个职业无非是心理活动波动最大的，心理上的暗示和缓解对于测试是最大的一个帮助。笔者第一本读的有关心理学的书籍是《梦的解析》，之后陆续看了佛洛依德的若干部著作。对于心理学上很有兴趣，强烈推荐各位测试同仁有空读一两本心理学有关的书籍，相信你得到的帮助绝对不只是心理上的。 四、 主观能动
很多人说测试行业中很多都是性格内向的人，很多需要细心的女性 。这点我不否认，但是只是和测试本身没有非常直接的关系。但是无论男女，无论性格，作为测试必须要学会的是主观能动。笔者在本文一开始就提到测试行业原本历史就短，并且 国内外的文化，技术差距很大。我自己是一个做手机移动端的测试（如果有人要交流相关技术，我很乐意一起讨论），在移动互联网的测试国内的积累更加的少。我举个实际的例子，在安卓的自动化测试框架中有一个框架叫做robotium，我无意识中的加了国内很多讨论群，同时也订阅了robotium gmail的一个讨论组。一个月过去了，国内的群很多都沉默，但是那个gamil的组却已经有了七百多封的讨论邮件。这里其实总结来讲，国内外的教育，文化从我们小时候开始与国外就是不同的一个理念，造成了国内很多人的主观能动性相对来讲比较差。但如果你选择了测试，那么必须大大提升你的主观能动性。如果你想做好测试，得到更多的信息，得到更多的技术，那么你必须主动去网上查找资料，主动的找人进行沟通，主动的进行实践，那么一切才会有改变。否则我相信做不了多久就会唉声载道。
同时，这里的主动 不单单是单方面的吸收，还有主动进行分享。每个人都是普通人，没有一场战斗，革命是靠一个获胜的。一个人的能力有限 ，当大家把自己所知的东西都主动分享出来，那么才能够产生更大的财富 。一切才能够进步。
五、乐观精神（阿Q精神）
首先澄清一点，笔者在除了测试以外的方面并非一个乐观的人，所以还修炼不到火候。乐观对于测试绝对不可少。你往往面临着一个复杂的功能性产品，往往会被误解，往往会被很多人在心里看不起、会因为找不到缺陷而心情不好等等 ，等等。乐观会让你精神拥有强壮的体魄和内心，否则你会无法继续在这条道路上走下去。可能最后打败你的是你自己，说服你的是你自己。这份精神难能可贵，当你面对各种各样的突发事件，面对各种 困难 的时候，不妨乐观一下，调整好心态去在能力范围内做好，会有意想不到的收获。
六、 沟通能力
说到这里，如果你已经具备了测试的最基本的素质的时候，那么你绝对，绝对会觉得测试绝对不是测试唯一的工作，在一个公司，项目中测试不是你一个人的战斗。最先的一点，避无可避，也是历史上战斗最悠久的一个对手：开发。可能再好的朋友也会和你争论的面红耳赤。当你要确认缺陷的时候，你可能会遭到各方面的质疑；当你明确需求的时候，你可能需要和你的项目产品经理甚至客户进行沟通；当你要管理团队或改进测试流程的时候，那么你可能需要和相关的所有人进行沟通协调。沟通是一门技术，这句话放在测试身上再好不过了。我们往往扮演着各种各样的角色，曾经有人甚至告诉我，我除了做测试，还做全职的售前售后。很多测试在为提升效率而烦恼，当你解决了沟通问题的 时候，那么效率上升的比例可能是几何倍数增长的。同时，你的人际关系也会越来越好，这样会让你做管理，做协调，甚至做结构上的改变变得那么轻而易举。
沟通能力其中比较重要的就是描述，当一个测试人员描述一个事情都描述不清楚的时候，绝对不是一个好的测试人员。测试人天生需要汇报提交缺陷，而清楚的描述这些缺陷如何发现，现象怎么样是一项基础技能。描述问题另外一面就是倾听问题。用怎么样的心态描述问题，又用 怎么样的态度去倾听别人所说的。决定了沟通最后的效果。
七、分析能力
我们慢慢的从一些软性条件上说到了硬性的条件上了。好的分析能力带给测试的会是另外一片天地。分析能力其中包括了：如何去发现问题，如何去分析问题，如何去解决问题，如何去总结问题。这里的问题不是指测试中的缺陷。可能是一种模型的运用，可能是一种测试技术，也可能是一种人际关系等等。曾经在google全球code jam竞赛中获取第一的中国选手告知我“万事不懂问google”，同样的我相信，很多人会觉得为什么有的问题我就查不到，别人就查得到。如何灵活运用搜索引擎真的是一门学问。好的分析能够让你找到问题出在什么地方，然后找到切入点进行相对应的改进以及修改。面对产品，能知道风险最多的地方在哪里；面对技术，能够搜寻出最终的可行性方案；面对团队，能够对症下药，而不会无从下手。分析来说，实在有太多地方可以说，我这里就不一一说明了。
八、条理性
任何事情都有轻重缓急，在《高效人士7个习惯》以及ChinaTest中柴阿峰提到的基于风险的测试中都提到了这点。作为测试，很可能你会有很多事情排着队。可能是烦人的客户，可能是不停在变得需求，可能是新 测试技术的探索，可能是自己私人的事情等等。当项目时间，测试人员数量，产品风险，个人私事这样几个维度一起向你攻击的时候，那么你只有 通过分析，然后有条理的归类到7个习惯中提到的四象限中。对于测试，缺陷有优先级，工作有优先级，杂事有优先级，什么都要有优先级。包括朱少民老师提到的传统脚本测试和目前正热的探索性，敏捷测试的和谐并存。这也是需要有条理性 的针对公司，项目的情况具体安排，并非传统不好，并非敏捷探索就一定好。不管黑猫白猫，抓到老鼠的就是好猫，不是吗？
这点毋庸置疑。测试必须要有责任感。当然不是说让测试承担一切的责任。而是对于自己所做的一切进行负责，对自己负责。测试是一个企业把关的角色。可能对于一些人来讲只是一份工作，但是就企业来讲，无论他们怎么看待测试，他们依然将产品的质量的好坏直接挂钩到了测试身上。测试行业遍布各个行业，如果你只是在做移动互联网内的一个交互娱乐应用的话，可能责任还没有体现出来。但是还有很大一部分的人一直工作在银行、铁路、航空、医疗等领域，这些测试必须负责，他们关系到老百姓的生命安全。就如同《测试之美 》中曾经提到，作者在几年前做的是医疗行业的测试，几年后自己母亲生病，维持着母亲生命的正是自己曾经测试过的医疗器械。只有当这个时候，自己的安心来自于自己的负责。所以我希望各个行业的测试们负起一份责任
正因为测试行业需要发展，测试技术需要进步，所以更加需要测试人去勇敢的钻研，尝试，实践、创新。很多测试人碍于自己只是一个打工的人，而不敢站在更高的角度看待 问题；碍于自己内心的恐惧，而看不起自己，觉得自己不是做技术，或者不是能够解决眼前问题的人、又或者碍于自己性格内向，而从而停止了沟通前进的步伐。我曾经一直这样和我的员工说”很多事情你不敢去做，很多事情你不知道怎么去做，但是不要忘记，你不做总有人会去做。他们做了所以他们变得有名有财富有知识。而你，还是你“。就比如笔者，这次勇敢的做了决定去参加了ChinaTest。为什么说勇敢呢，因为笔者也仅仅工作两年，最终成为了 ChinaTest第一个 报名参加的人，也是第一个自费参加大会的人。我相信这也是一份测试应该有的勇气。
前面大家提到了很多能力，我觉得有些是作为一个工程师通用的要求，那么什么是测试工程师特别需要的能力或者品质呢？我就说自己感触最深的三点：责任心 - 作为一个把关者，身在其位就要做好本分，不轻易放过任何一个问题，更不能为了让测试通过而胡乱修改和删除测试用例或者测试数据。独立思考 - 深入理解产品，有自己对软件行为正确与否的判断能力，该坚持意见的时候能够坚持住。灵活 - 能意识到在资源有限的情况下需要权衡和折中，大家都是为同一个目标奋斗，不要让自己的固执成为项目或者产品的绊脚石。
批判性思考
要做一名优秀的测试工程师需要掌的知识广而多。至少要具备如下几方面的能力：1、必须掌握测试方面的理论知识。这点很重要，是首要基础。2、具备编写程序的能力。不会写代码，发现了bug无法找到问题的根源也无法调试。3、懂得网络方面的基础知识。这个主要是安全测试做准备。4、必须掌握数据库方面的知识。这个是必须要掌握的。5、懂一些底层的方面的知识。6、心要静、细心耐心、责任心。心静不下来无法对bug展开发向思维及拓展想像。7、测试工具不仅会用而且要精通。功能自动化测试和性能测试必须要掌握一个工具。8、具备写作能力和表达能力。写作能力主要用于写test case或提交bug ,表达清楚开发人员或执行用例的人一看就懂。
和任何一个职业一样，测试工程师也分很多方向，自动化、数据库、白盒等等，我想题主暂时只是想找一份看上去还可以的测试工作。思考学习能力默认你已经有了，以下列一些条条框框的技能吧，起码在求职网站上能够有更多HR找上你。会一门编程语言，会到什么程度，能写自动化脚本，光凭这个就能找一个待遇还不错的自动化工程师的职位。什么？你不信，君不见华为外包中，会编码的测试简直是百里挑一。什么？那开发转测试岂不是很容易拿到高工资，是的，但是能不能做好测试不仅仅是会编程而已。会SQL，除非那种报表类型的测试，会普通增删改查，知道4种join的区别就可以了，君不见数据库是单独的一门学问，我们只是做测试的，不是做DBA。会通信协议，HTTP是必须的，看行业脑补，做电信的SMPP/MM7/MDSP，做即时通信的SIP/XMPP，会到什么程度，有个RFC在手边能够读懂报文。会性能，这个比较宽泛，要学的太多，前端调优，中间件调优，函数调优，数据库调优每个都够吃一壶的。测试用例、测试方案要会写，常用的测试设计方法要知道，Linux命令要会敲，安全性和易用性要了解。以上基本找个软件测试工程师的职位已经不成问题了
其他的大家都谈过了;理解能力,对产品的功能和复杂的业务逻辑一定要有一个相对正确的认识!并且要站在开发人员和用户两个角度来看待测试的产品,要站在几种不动的层面去思考问题!动手能力,想像力,探险精神,敢于尝试!不过前提是考虑过尝试行为过后有可能产生的风险是可控制范围内的..我有的同事经常会在遇到一个自己不会的问题时,就不停的问下一步呢?再下一步呢?选哪一个啊?我通常都是不等他们第二次开口说"下一步呢?"就接下来该怎么办怎么办都一步一步的告诉他了!有时候我很忙,他们等着急了催促的语气问接下怎么做时...我都会说,你自己去想,然后再试一下,你放心,你绝对不会把机器,服务器硬件给搞坏的!最坏的结果就是还原数据库.最多就是重装服务器!他们为什么不愿意试一下?不是因为他们不敢,怕出现什么搞不定的问题,而是他们遇到一个问题时,根本就没有想过要思考,只想找别人帮忙,这样的问题别人帮他们解决100次,他们就算是把解决问题的步骤都记下来了,也是知其然不知其所以然!进公司半年一年了,每天接触同一个产品,让他去搭建一套新的测试环境,他连几个服务器之间的关系和为什么都不知道?不知道也不去问其他人,不是培训不到位,而是最起码的理解和学习能力,只知道要弄懂肯定会很麻烦!长期在展示层面用常规操作去测试功能,却不去思考这些功能究竟是干什么的!都是怎么来的!平时用的QC,只会写用例,和提交新bug,改bug状态.其他的功能包括设置都不会,对bug的级别和状态统计的功能都要问下一步呢?这不就是告诉别人你都工作这么久了第一次在QC上用统计查询!靠着拉低团队整体效率来掩盖自己的负效率,顶着testcenter的头衔,抱着侥幸的心态得过且过,这样的不靠谱人员都去应聘测试!哪一个是正确的操作,万一选错了.出现的结果是什么.想想为什么会这样.别连对产品的业务认知都懵懂情况下,出现的结果只是自己主观上感觉不对,就愣说这是个bug!一个步骤对应一个结果,只要不报错,就必然有得到这个结果的逻辑!说那是个bug,只能说明你根本不知道那个业务逻辑!看到我用QTP跑脚本冒烟一个模块业务功能,就感叹好方便啊好快啊,我们能不能都用这个呢?这种带着让我也跟你一样的轻松涵义低级询问,对于一个真正的测试人员根本无力吐槽!一个只需要拿鼠标点点功能按钮键盘敲几个字,这都嫌麻烦的人哪里懂,经历了几次测试版本才成型的自动化测试脚本,反正他们在意的是怎么自己运气这么不好,总是刚刚一拿起手机玩几分钟就被路过的领导看到了!是运气不好呢?还是频率太高呢?
要细心，有责任心；技术关要过，基本的软件要学会使用；涉及到业务方面的还要掌握业务知识；工作要系统化流程化；描述问题要清晰明了；要有良好的沟通能力；
首先心态：平和，耐心，细心；再而业务常识：领域知识扩展，做份内的事，学份内份外的东西最后谈技术：要有绝对的精通项即对于领域知识须广，对于专业技术须精
我们尽量把测试工程师职位说的非常专业和技术，好让大家以为测试工程师职位的门槛很高。
理论确实很重要。。理论--&实践--&理论--&总结--&实践--&理论--&实践==实用的技术
既会做事又会做人，情商高一点。
除了测试的基本技能外，要多了解心理学和社会学等学科。
热爱你的工作, 热爱你的同事, 热爱你测试的东西
小姐的身子（研发）丫鬟的命（测试）
懂理论，会技术，会工具，练项目，会编程以后发展会更好
会用软件，超级强大的业务知识。
对我来说，测试就是找茬，而且有些茬可以找，有些茬找了就是矫情，——找茬的艺术。}