下面的这个清单是我和一些行业的熟人，在众多大的科技公司里工作后，一起收集汇总出来的一些特征。我们的工作经历多样而广泛，从财富50强企业到硅谷创业公司，从全新到代码库到30年的老古董。
　　下面的这些特征，不仅是对我们，我想对广大的软件开发者也都代表了一个非常理想的工作环境。虽然很多的公司会认为清单上的这些做法是不可能接受的，但如果争取向这种理想的情况靠近，我们相信很多的程序员，包括我自己，都会希望为你工作。
　　· 向开源社区捐赠力量
　　· 允许程序员用自己的电脑开发。
　　无法做到这一点通常意味着一个过度耦合的开发环境…
　　· 不需要依赖具有专利的通信协议
　　你们的Microsoft Exchange server无法支持 Linux 或 OS X 吗?
　　你们的文档需要使用 Microsoft Office 或 Pages for Mac 吗?
　　· 允许程序员去选择无薪休假
　　一年中指定的那几天有薪假期真的很有价值吗？
　　· 具有一个条理整洁的代码库
　　考虑转换成一种面向服务的架构，会对你有帮助 ;)
　　· 优先分配时间来重构/偿还技术债务或其它不能直接产生经济效益的事情
　　如果有技术债务，应该在文档上记录，并尽可能的消除。
　　· 不使用一个“自己定制的框架”或不正确的实现的开源框架
　　用Stack Overflow应该能够解决大部分的代码相关的问题。
　　· 不是一个“市场驱动型”公司
　　· 不武断的设定最后期限
　　“周二前我们必须做出这个功能，届时我们要群发邮件通知！”
　　· 抛弃Minimum Viable Product
......
本文转自：51Testing软件测试网

　　每次新版本要出货时, 常常被询问是否测试结束了? 质量是否有信心? 你依据的标准是甚么?
　　我想很多人都会觉得很难回答这个问题. 基本上, 可以根据以下五种状况, 来决定是否测试可以结束.
　　1. 老板说了算
　　基本上, 老板是无敌的. 他说甚么时候就是甚么时候. 我想大家不会, 也不敢不同意. XD
　　2. 团队有共识要停止
　　如果团队讨论完后, 决定要何时停止测试, 这样也是可以结束
　　3. 当代价太高
　　如果要找到下一个 bug 的代价, 会超过这个 bug 所带来的损失, 那确实没有必要再测下去, 是可以即刻结束
　　4. 如果 bug 被发现的比例下降到预期的目标
　　有时候你会观察每一段时间内找到多少 bug, 如果你发现它一直在下降, 并且低于你所定的目标, 这时候你就可以出货. 像是低于5 个 bugs/per day, 并且这些 bugs 都不是严重的 bugs
　　5. 如果已经达到预期的测试涵盖率目标
　　如何你会度量你的测试个案, 已经涵盖了多少东西, 便可以知道你的测试范围够不够. 像是 90 % line coverage, 75% branch coverage 等等. 当达到设定的目标, 自然你也可以说测试可以结束了.
　　目前看起来只有后面两个, 比较有数据来参考, 前面三个比较是自由心证. 事实上, 这些都是心安的说法. 因为只要给妳时间和资源, 其实都还是可以找到 bugs的.
　　因为, < 1 bugs/per day 或是 100% line/branch coverage, 其实都没有保证甚么. 最多只是账面上给你信心. 出货后被抓到问题, QA 还是等着被骂没有做好. 不公平, 但是是事实. XD
本文转自：51Testing软件测试网 http://www.51testing.com/html/46/n-863746.html

　　好的单元测试用例中发现的问题揭露了设计和代码上的缺点。
　　最近这段时间，对单元测试的介绍急剧地增多。而在上世纪90年代和2000年早期，这一习惯似乎十分无力。通常就是这样，人们采用一项新的技术，回溯当年，各机构们也在从结构化设计方法转向以对象为中心的设计方法，他们将所有的焦点放在至关重要的权利上，同时丢弃看起来不能与新愿景整齐地融合的例行做法。因此单元测试就被忽略了。
　　但是，很少但是要说我们从过去的10年中学到了什么，那就是我们学到了单元测试是一个非常重要的学科。测试帮助我们更好地来写代码，形成回归基础使得重构和让添加成为特色更简单。有人讨论单元测试的一个十分细微的影响。处在单元层面的可测性和好的设计之间似乎有着某种极为紧密的联系。几乎是公认的说法，难测的代码必有设计问题。当你修复了设计上的问题时，测试就变得简单了。
　　让我们来看一个例子。


　　在图1中，我们有一个类，这个类看起来设计不错。有一个公共方法，evaluate()，它是用户与类接触的点。它将其工作传给一系列私有方法。很明显，这样的一个类没有任何错误，RuleEvaluator做了我们想让它做的工作。现在，我们应当怎样为这个类写单元测试用例呢？我们应当能够举例来说明，用多个变量来调用evaluate()方法然后检查结果。但是假如我们想测试getNextToken()方法呢？

      ......
　查看全文请点击下载：http://www.51testing.com/html/42/n-863942.html
　　这个例子也许会惹恼你。你可以认为无需重用getNextToken()或者hasMoreTokens()方法中的代码，将他们拉进其类中是无意义的，因为这无意义地增加了类的数量。但是作这个动作的确让代码更有模块化的概念。我们可以在将来的某个点重用RuleTokenizer方法。至少，现在很清晰，我们应当在标记功能代码的哪些地方做改变。我们的代码相关性更加少，改变其中一个而不影响另一个更容易。
　　如果这是可测性不高是设计差的一个信号的唯一例子的话，这只会被认为是侥幸，但实际不是这样。通常来说，单元测试的痛是有地方出错了的表示。有时这种痛很明显。举例来说，如果你必须创建很多对象才能得到你想测的那一个对象，这常常是过度耦合的一个表现。其他的情况更微妙。我们来仔细观察一些例子。
      ......
　查看全文请点击下载：http://www.51testing.com/html/42/n-863942.html
　　本文收录于《51测试天地》电子杂志第三十四期。

　　版权声明：本文出自51Testing软件测试网电子杂志——《51测试天地》第三十四期。51Testing软件测试网及相关内容提供者拥有51testing.com内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像，否则将追究法律责任。

　　很多软件测试从业者用到的黑盒测试用例设计方法大多是等价类划分法、边界值分析法、判定表法、因果图法和正交试验法等，其实还有一种方法不得不提到，那就是错误猜测法，这对资深测试人员尤为重要。因为随着在产品测试的实践中对产品的了解和测试经验的丰富，使用错误猜测法设计的测试用例往往非常有效，可以作为测试设计的一种补充手段。并且积累的经验越丰富，方法使用效率越高。那么到底什么是错误猜测法呢，下面我们将通过定义和实际测试案例来加深对错误猜测法的认识。
　　首先，我们先来看看错误猜测法的定义：有经验的测试人员往往可以根据自己的工作经验和直觉推测出程序可能存在的错误，从而有针对性的进行测试。它的要素共有三点，分别为：经验、知识、直觉。关于如何使用的问题，我们提炼出两点：
　　1 . 列举出程序中所有可能有的错误和容易发生错误的特殊情况；
　　2 . 根据他们选择测试用例。
　　我们知道经验是错误猜测法的一个重要要素，也就说带有主观性，那么这就决定了错误猜测法的优缺点，首先我们来看优点：
　　1 . 充分发挥人的直觉和经验
　　2 . 集思广益
　　3 . 方便使用
　　4 . 快速容易切入
　　对应的缺点有：
　　1 . 难以知道测试的覆盖率
　　2 . 可能丢失大量未知的区域
　　3 . 带有主观性且难以复制

      ......
　查看全文请点击下载：http://www.51testing.com/html/42/n-863942.html
　　实例：测试**学院的课程搜索输入框
　　既然是用错误猜测法，那么我们首先列出可能导致搜索结果出错的情况，如下：
　　1 . 单个空格，多个空格
　　2 . 字符串前面有空格
　　3 . 字符串后面有空格
　　4 . 转义符 "\n"
　　5. Null
　　6. 特殊字符
　　7 . 通配符 *
　　8.空串，很长的字符串

      ......
　查看全文请点击下载：http://www.51testing.com/html/42/n-863942.html
　　本文收录于《51测试天地》电子杂志第三十四期。

　　版权声明：本文出自51Testing软件测试网电子杂志——《51测试天地》第三十四期。51Testing软件测试网及相关内容提供者拥有51testing.com内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像，否则将追究法律责任。

　　一次面试一个品学兼优的女孩子，刚从51testing学习完毕，来我们单位面试，由于我本人对于统计学比较有兴趣，所以就问了她一个统计学的方法，什么叫做正交测试。
　　她的回答非常流利，而且说这是51Testing老师所教。但是我却说了她说得并不完全正确，我一时也没有说清楚为什么不正确，也许这就是直觉！ 面试完之后，我立即翻书找出答案，等再去找她的时候她已经离开了。于是我心里一直都忐忑不安，总感觉如果这样结束面试是非常没有礼貌，也没有价值的。
　　下午的时候，我鼓起勇气向51Testing老师询问了她的QQ，然后很顺利的加了QQ，并把我的结论告诉了她，她也认同之后，我这才放下了心。
　　虽然最终，我们单位并没有录用她，但是我还是觉得她很优秀，就和面试过的许多优秀的女孩子一样，我感觉她们都是思维敏捷，品行端正，品性善良的，我的做法也应该是正确的，我希望她能找到一个适合她的好工作！那我想这是当然的啦！
　　女孩所说的是---正交表中任意2列都是全排列。我翻书后发现，虽然任意2列的数值覆盖到了全排列的所有可能情况，但是在某些正交表中（不是所有的）会出现重复的情况，所以说不可以说成为任意2列是全排列。
　　那应该怎么描述这个正交表的特性呢？
     ......
　 查看全文请点击下载：http://www.51testing.com/html/42/n-863942.html
　　我由此总结一下正交表的特性：
　　1：表中任何一列不同的数字出现的次数相等，如果任何两列没有重复的数对，那么表中任何一列不同的数字出现的次数都是此正交表的水平数，如果任何两列有重复的数对，重复一次，则任何一列不同的数字出现的次数就为水平数的两倍，以此类推。
　　2：表中任何2列中，每种数对出现的次数相等。如果(1,2)有2对，那么(2,3)也有2对，以此类推。
　　3：表中任何2列中，去除重复的数对，则这2列的数对其实是有放回的全排列。
　　以下是无放回的全排列和有放回的全排列之间的区别：
　　对于 表
　　取任意2列无放回的全排列-显然这不是正交表，因为对于这2列，无放回的全排列是不可能出现（1，1），（2，2），（3，3）的：
　　实验个数是水平数*（水平数-1），此例就是3*2=6。
    ......
　  查看全文请点击下载：http://www.51testing.com/html/42/n-863942.html
　　本文收录于《51测试天地》电子杂志第三十四期。
　　版权声明：本文出自51Testing软件测试网电子杂志——《51测试天地》第三十四期。51Testing软件测试网及相关内容提供者拥有51testing.com内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像，否则将追究法律责任。

　　一 大学篇
　　09年踏入测试行业一转眼至今已5年有余，回想这一路走来感慨良多，初次接触测试应该是读大二的时候在计算机杂志上面看到的一篇文章，测试人才的缺失在中国很严重，当初也没有想到自己会踏入这个行业，那时候的自己对未来的路充满迷茫，毕业也意味着失业，现在想想当初读读书时候的自己是多么的放纵，课余时间基本都是和同学们一起玩游戏：80后应该很熟悉的《传奇》、《传奇私服》、《天龙八部》，大家在在游戏中尽情驰骋，大杀四方，在娱乐的同时与同学间的感情增进不少，哈哈，在游戏中唯一的收获：团队精神力量的强大。
　　二 培训篇
　　临近毕业季，有培训机构来学校招生，什么机构就保密了，以免广告之嫌，当时承诺培训之后可以介绍工作，还有证书发放，带着对未来的迷茫和恐惧，刚开始参加了研发的培训，随着一两天的学习后，发现自己不是做研发的料，用古语云：朽木不可雕也。于是乎听说有测试的培训，于是乎便和最好的哥们跳到了测试（大学里面都是成群结队的，关系很铁），就此走上了一条不归路，当时开课也就10来个人，授课的老师是一个公司的测试总监，从最基础的学起，测试的基本理论，在学习过程中很多次有放弃的念头，读完大学还需要参加培训，读大学有什么用呢？多次会想到这些，在哥们的劝说下，坚持了下来。在历经8个多月的理论培训后便进入培训讲师所在的公司进行实习。
　　三 实习篇
　　对于即将毕业的学生来说，有实习的机会是很不错的（参加培训时还在学校，只是课程比较少了），当然实习是无薪的，想着能够实战心里无比激动，心里嘀咕：学的知识终于发挥用处了。公司安排了一个测试带领我们，当遇到问题时可以向他请教，哎，从那时候起实习生就处于放养的状态了，公司很少管理我们，有种自生自灭的味道，那段时间的实习了解到了公司内部的测试大概流程，熟悉了测试工具的使用，测试用例的编写，测试环境的搭建，数据库方面的实际操作经验，虽然没有做成一项完整的工作，但是这一段时间的学习未以后找工作提供了一些优势，实习期短短的2个月便结束了，培训机构答应的落实工作也杳无音讯了。从那时起也正式告别学生身份，踏入社会，去历经江湖险恶，体验人生百态了。
　　未完待续...
原帖地址：http://www.51testing.com/html/29/n-863929.html
版权声明：本文出自51Testing软件测试网电子杂志——《51测试天地》第三十四期文章投稿。51Testing软件测试网及相关内容提供者拥有51testing.com内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像，否则将追究法律责任。

　　一 大学篇
　　09年踏入测试行业一转眼至今已5年有余，回想这一路走来感慨良多，初次接触测试应该是读大二的时候在计算机杂志上面看到的一篇文章，测试人才的缺失在中国很严重，当初也没有想到自己会踏入这个行业，那时候的自己对未来的路充满迷茫，毕业也意味着失业，现在想想当初读读书时候的自己是多么的放纵，课余时间基本都是和同学们一起玩游戏：80后应该很熟悉的《传奇》、《传奇私服》、《天龙八部》，大家在在游戏中尽情驰骋，大杀四方，在娱乐的同时与同学间的感情增进不少，哈哈，在游戏中唯一的收获：团队精神力量的强大。
　　二 培训篇
　　临近毕业季，有培训机构来学校招生，什么机构就保密了，以免广告之嫌，当时承诺培训之后可以介绍工作，还有证书发放，带着对未来的迷茫和恐惧，刚开始参加了研发的培训，随着一两天的学习后，发现自己不是做研发的料，用古语云：朽木不可雕也。于是乎听说有测试的培训，于是乎便和最好的哥们跳到了测试（大学里面都是成群结队的，关系很铁），就此走上了一条不归路，当时开课也就10来个人，授课的老师是一个公司的测试总监，从最基础的学起，测试的基本理论，在学习过程中很多次有放弃的念头，读完大学还需要参加培训，读大学有什么用呢？多次会想到这些，在哥们的劝说下，坚持了下来。在历经8个多月的理论培训后便进入培训讲师所在的公司进行实习。
　　三 实习篇
　　对于即将毕业的学生来说，有实习的机会是很不错的（参加培训时还在学校，只是课程比较少了），当然实习是无薪的，想着能够实战心里无比激动，心里嘀咕：学的知识终于发挥用处了。公司安排了一个测试带领我们，当遇到问题时可以向他请教，哎，从那时候起实习生就处于放养的状态了，公司很少管理我们，有种自生自灭的味道，那段时间的实习了解到了公司内部的测试大概流程，熟悉了测试工具的使用，测试用例的编写，测试环境的搭建，数据库方面的实际操作经验，虽然没有做成一项完整的工作，但是这一段时间的学习未以后找工作提供了一些优势，实习期短短的2个月便结束了，培训机构答应的落实工作也杳无音讯了。从那时起也正式告别学生身份，踏入社会，去历经江湖险恶，体验人生百态了。
　　未完待续...
原帖地址：http://www.51testing.com/html/29/n-863929.html
版权声明：本文出自51Testing软件测试网电子杂志——《51测试天地》第三十四期文章投稿。51Testing软件测试网及相关内容提供者拥有51testing.com内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像，否则将追究法律责任。

　　最近刚结束三个项目，三个项目测试期间发生了很多的故事。
　　成员介绍：组长W，成员L，成员Z。
　　成员背景：组长W刚到公司任职，以前的老员工。成员L熟悉项目A，成员Z熟悉项目C。
　　组长目的：锻炼组员L具备组长的管理能力，锻炼组员Z具备组长的管理能力。
　　任务分工：成员L负责项目A的测试，成员Z负责项目C的测试，组长W负责项目B的测试。
　　项目进度介绍：项目A刚开始提交部分模块待测试。项目B边设计边编码阶段。项目C集成测试再有一周就结束了。原先的项目C的测试组长此刻离职，原先的项目A的测试组长均此刻离职，此时组长W必须保证项目A测试任务的前提下，监管项目C，因为负责测试的成员Z，成员L均没有管理经验。原本4个人的项目，因为原来2位组长的离职，造成组长W接任需要有适应过程，该过程大概2~3周。
　　整个项目C，组长W参与的较少，只关心关键的测试进度，里程碑，具体事宜均交给成员Z处理。进度很顺利，按期完成测试任务。但是项目经理多次反馈成员Z，测试粗心大意，经确认验收测试和组长W的测试反馈，项目C较简单，项目经理走查代码认真，Bug较少属于正常现象。
　　项目A因为在前期只有成员L参与，碰到问题不知道如何处理，多次依赖测试组长W解决，导致组长W无法正常参与项目B的测试。最终组长W放弃项目B的同时测试，选择带领成员L测试，并在测试期间，逐渐引导成员L如何解决问题。由于前期测试任务安排的失误，造成组长W，测试成员L多次加班赶工测试的情况。项目A软件编码期间，由于开发人员的出差，造成项目中停，最终导致项目延期2周。该问题在后期测试项目B埋下了风险。因为项目A原本比项目B前结束4周，现在只提前2周，项目B无测试资源安排。
　　项目A在测试期间，将开发组长出差到工程前线，项目经理也出差到工程前线，一度将项目A陷入无人管理的阶段，只有1个普通的开发人员修改缺陷，碰到需要讨论的问题时无法解决，影响项目进度。测试后期整理数据库安装包，打包程序时，开发组长均不参与，只是分配任务给没有经验的普通开发人员，造成简单的问题多次修改未果的情况，开发组长在这个时候不仅没有帮助，反而只是让普通的开发人员自行解决，该过程造成延期3天的工作量。测试后期数据库安装包的验证和程序的验证，组长W均有意让测试成员L参与，本项目测试成员L学会了，碰到问题解决的思路，编写测试报告，验证发布的程序，数据库安装包等。
　　项目B由于测试组长W多次帮助项目A，导致项目B的测试进度很慢，在项目C结项的同时，项目A在7天后也结项。组长W将测试成员Z，测试成员L先后均参与项目B的测试。此时离项目B的结项还有2周。3个人参与测试1周时，由于项目B在工程试点的反馈，需要对需求，设计，编码返工，造成延期4天的工作量，测试组长W反馈测试需要延期4天才能结项，项目经理接受延期的申请，向公司的上级领导申请项目B的延期。经多次延期，商定项目延期6天结项。在系统测试刚开始时，由于开发人员的不配合，造成搭建测试环境很困难，同时测试组长W让测试成员Z负责环境的搭建，但是发现测试成员Z对于环境搭建，安装包的校验很混乱，测试成员Z花费很久的时间才把环境搭建起来。对于刚搭建起来的环境，根据测试组长会议上及时反馈的安装包问题，经过项目经理，产品经理的讨论，原来的数据库安装包需要重做，程序也要调整，此刻又造成2天的工作量延期。由于测试组长W的提前安排和测试组成员的加班赶工，已经编写大部分的用户手册。后期出现的问题，因为及时反馈和项目经理的主动咨询，均得到有效的处理。
　　3个项目是结束了，但是测试这边存在的问题与项目组的不合理安排，以及突发的需求变更，计划变更，外加与开发人员的沟通问题和配合问题，冲突到一起，造成测试过程中很不顺利，多次修改，多次返工。测试人员测试的很累，开发人员编码的也很累，加上开发人员沟通期间的不合作，造成很严重的负面情绪。
　　真的希望下次这些项目申请变更时，测试负责人应该多反思是否影响测试资源，测试负责人应培训测试成员基本的管理能力。否则，测试人员很累，测试负责人更累。在沟通的问题上，我们不应只发牢骚说开发人员的沟通能力弱，我们应该思考测试人员的沟通方式是否应该改变，对于不善沟通的人员，减少文字沟通，多口头交流。在项目的任务制定上，项目组负有很重大的责任，内部太缺少沟通讨论，均口头的小讨论解决问题，问题的结果无书面正式通知，均通过转述给测试人员，对此，测试人员意见很大。需求，设计上，负责开发的人员不负责任，测试人员碰到的问题，不能解决是，不是反馈给领导，均是拒绝方式回复测试人员，导致测试人员对开发人员的工作态度，人品大打折扣。
　　版权声明：本文出自 guofei318 的51Testing软件测试博客：http://www.51testing.com/html/17/n-863617.html
　　原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。

　　游戏测试，具体到游戏研发测试，一切都是为了游戏研发服务。
　　游戏测试，在游戏研发中属于辅助部门，辅助美术、技术、策划三大研发部门开展研发工作，辅助运营、商务部门开展运营推广工作。
　　游戏测试要怎样做才能更好地辅助研发？辅助运营？
　　目前游戏测试的大环境并不好，大环境中的游戏测试主要以黑盒功能测试为主，工作目标以尽量多的寻找bug，尽量少的遗漏bug为主；另外有少量的自动化、性能、压力测试工作，比较少见的白盒、测试开发工作。
　　大环境中测试员普遍存在的问题：不受重视、产品出bug测试背黑锅、无穷无尽的加班、待遇低、没有上升空间、等等。
　　这一切的根源都在于：测试的贡献只是找bug，对团队的贡献明显相对技术、美术、策划等主力部门较小。
　　测试员为了提升自己的待遇，传统的技术路线不外乎向性能、自动化、白盒等方向发展，但由于游戏测试本身的特性，作为娱乐级产品对产品软件方面的质量要求并不高，而更需要可玩性方面的品质，再加上游戏研发领域技术门槛的持续降低，硬件成本的降低，以至于性能、自动化、白盒等方向对游戏研发的实质贡献并没有想象中那样大，因此并无法改善游戏测试的贡献较小的问题。
　　我们现在走在一条与大环境不太一样的游戏测试路线上，至少目前来看，这条路上游戏测试可以得到从领导层到项目组各级同事的重视、没有背黑锅现象、可控的加班、与研发等平衡的待遇、可见的上升空间。而所有这一切，全部来自于游戏测试对游戏研发、游戏运营的实质贡献。
　　首先，我们的工作目标是：通过发现bug、分析bug、分析人的行为、发现团队的问题、帮助团队解决问题，从而促进团队进化，提高团队整体研发能力。这样一来，发现更多的bug，遗漏更少的bug，自然成为测试工作的副产品，而无需作为主要追求目标。
　　这样的目标设定，从根本上解决了测试团队贡献不足的问题，从而改变了测试的地位，解决了传统游戏测试的各种尴尬。
　　在我们的测试工作中，测试工作可以分解为两大部分：一部分是黑盒功能测试、一部分是团队进化部分。
　　黑盒功能测试部分：
　　黑盒功能测试，bug生命周期管理，反馈产品的质量信息
　　我们更看重的是第二部分工作内容--团队进化：
　　通过对黑盒功能测试发现的bug进行分析、对项目团队中其他成员行为进行观察，发现团队研发工作中存在的问题，找到解决问题的方法，持续不断的提升团队的研发能力。
　　因此，相对于传统的游戏测试，我们更看重：
　　1：bug的深层分析能力
　　2：改进团队工作方法的能力
　　3：跨部门的沟通能力
转自：http://www.51testing.com/html/28/n-863628.html

　　从事软件行业已经快五年了，最近换了份工作，入职新公司已经快一个星期了，这几天一直在培训公司业务，周围同事也经常告诫我一定要懂业务。业务，似乎一下子从来没有这么重要过?程序员其实最不喜欢的就是熟悉业务，文档很多，业务名词枯燥无味，甚至不能为程序员的职业生涯积累多少有用的东西，因为换个行业这些知识几乎都没有用了，远不如学习些新技术、框架等等有用。那我们程序员为什么要学习业务呢?业务知道是不是不重要呢?其实不是不重要，是非常重要。业务的重要性从以下几个方面来体现：
　　1.理解业务有助于程序开发人员更新准确有效的开发出符合用户要求的功能。
　　软件里每个功能都有它一定的作用，要么是达到某种业务需要的手段，要么是能够帮助用户简化一些重复性的工作。特别是前者，能理解用户的根本需求，按照用户的要求开发某个功能，必须站在用户的角度看问题，才能完成开发任务。当然，这是程序员的本职工作。优秀的程序员，可能会根据用户的要求，结合自己在这个行业，举一反三，开发出让用户拍大腿功能，触到用户的痛处，这才是程序员的最高追求。当然，只学技术，不学业务，也可能成为一个很牛的人，但再牛也没有意义，毕竟软件是给人用的。
　　2.业务是一个企业的生命线，是灵魂。
　　为什么这么说呢?我曾经工作过两个公司。第一家公司主要是做公安行业的，98年创立，至今三十人左右，年营收刚刚过千万。而同一时期创立的腾讯等公司已是我们仰望的国内巨头，而百度、阿里当时还不知道在哪。为何有这么大的差距?可能有其它的原因在里面，但我觉得最根本的原因，就是因为这个企业没有灵魂 ——业务。大部分的业务需求都是用户提出的，需求定下来以后开发为一个项目。过两年政策一变(当然也和公安这个业务和government的原因)，再改变需求开发为下一个项目。从没想过这个行业需要软件的原因，以及想通过软件想到达到一个什么样的目的，没有产品的概念，没有帮助客户和客户共嬴的意识。
　　3.懂业务才能做出好的产品。
　　我觉得一个优秀的软件企业不单单是做出一个好的软件，而是让的客户使用上自己的产品后，帮助用户更快更好的产生经济效益，或者达成某些管理目标。
......
原文链接：http://www.51testing.com/html/80/n-863380.html