如果你是软件测试员或是高级测试员,有志转向管理发展,从技术方面，那么需要加强以下内容，至少要做到几点：
　　1. 扎实的软件测试基本功，懂得测试计划的制作与编写(结合测试的项目,能以此来控制和确定测试所需人员,设备及时间)
　　2.要熟悉BUG跟踪工具及软件测试流程.(如: QC, Bugzilla, Mantis等)
　　3.要熟悉配置管理工具. (如: SVN，CVS, VSS等)
　　4.要熟悉自动化工具.(例如:QTP, Robot, RFT, Selenium等,能结合录制完的脚本编写代码)
　　5.要熟悉压力及性能测试工具.(例如: LoadRunner, webload, silkperformance等,能结合相关数据,分析出性能瓶颈)
　　6.要熟悉或精通一门语言. (例如: C#,Java,C++)
　　7.要熟悉数据库.(例如:Oracle, DB2, SQLServer, MySQL)
　　8.要熟悉至少一种主流操作系统. (例如: HP Unix,IBM AIX, Sun Solaris, Red HatLinux, SuSE Linux,Windows)
　　9. 必要的英文能力.
　　10.语言表达能力强,表达问题清晰明了.
　　11.沟通能力强,能和上级/开发经理很好的达成测试相关/BUG事宜.
　　12.学习技术的能力要强,能快速上手一个新的技术，这是做软件行业必须的.
　　13. 掌握管理技巧与团队建设，管理不是胡乱的管人.
　　14.乐于与人交流.
　　当然，现在的管理者，很多时候或者可以分为两类，一种是对业务和管理熟悉但不懂技术、另一种是对管理熟悉但不懂技术。
　　在软件这一行业，我认为做为一个管理者，非常有必要懂得技术，以技术做为基础，推进开展部门工作，可以更高效快捷，也可以在部门中更令下属信服，不懂技术的管理者往往得不到下属发自内心的信服（特别是在人才济济的大公司或知名企业），以上列出的技术均为软件测试行业通用型的测试技术，在不同的企业，因业务性质和业务特征的不同，对技术的要求也存在一定差异（当然，如果具备较强的学习能力，这些“个性化需求”其实算不上什么）。
　　懂技术的管理，才能走得更远！
本文转自：51Testing软件测试网

　　缺陷管理工具：
　　1. Bugzilla
　　2. Bugfree
　　3. TestDirector （Quality Center）
　　4. ClearQuest
　　5. JIRA
　　6. Mantis
　　7. Bugzero
　　8. BugTracker
　　9. URTracker
　　10.KisTracker
　　11.TestLink
　　12、JTrac
　　13、BugNet
　　14、BugOnline
　　15、eTraxis
　　一、Bugzilla（免费，跨平台）
　　Bugzilla是一个Bug追踪系统设计用来帮助你管理软件开发。
　　Bugzilla是一开源Bug Tracking System，是专门为Unix定制开发的。但是在windows平台下依然可以成功安装使用.
　　Testopia是一款和Bugzilla集成到一起的test case management系统.
　　它的强大功能表现在以下几个方面：
　　1. 强大的检索功能
　　2. 用户可配置的通过Email公布Bug变更
　　3. 历史变更记录
　　4. 通过跟踪和描述处理Bug
　　5. 附件管理
　　6. 完备的产品分类方案和细致的安全策略
　　7. 安全的审核机制
　　8. 强大的后端数据库支持
　　9. Web，Xml，Email和控制界面
　　10. 友好的网络用户界面
　　11. 丰富多样的配置设定
　　12. 版本间向下兼容
　　二、BugFree（免费）
　　BugFree是借鉴微软的研发流程和Bug管理理念，使用PHP+MySQL独立写出的一个Bug管理系统。简单实用、免费并且开放源代码(遵循GNU GPL)。
　　三、Quality Center（商业，前身Mercury TestDirector ，跨平台）
　　HP Quality Center; 提供了基于 Web 的系统，可在广泛的应用环境下自动执行软件质量测试和管理。仪表盘技术使您可以了解验证功能和将业务流程自动化，并确定生产中阻碍业务成果的瓶颈。HP Quality Center 使 IT 团队能够在开发流程完成前就参与应用程序测试。这样将缩短发布时间表，同时确保最高水平的质量。
　　企业级的软件质量解决方案。
　　四、IBM Rational ClearQuest （商业，跨平台）
　　IBM Rational ClearQuest 是一款强大的软件开发测试工具。集成并自动化软件及系统开发的业务过程。V7.0 提供增强的需求跟踪、构建跟踪、企业测试管理，及部署跟踪的功能。这提供了从开发到部署的完整的审计跟踪，并扩展了跨生命周期的可追溯性。软件增强了开发流程并使之自动化，同时还提高了软件生命周期的可理解性、可预测性和可控制性。
.......
本文转自51Testing软件测试网

　　1、项目进度
　　1.1测试执行阶段
　　写清楚当前是在冒烟阶段、功能测试执行阶段，还是回归测试阶段
　　写清楚当前阶段预计在什么时候结束（在可控的情况下，如果不可控或者不可预测，说明风险在哪里）
　　写清楚当前测试了哪个模块，还有哪些模块没有测试（一般都是先测试优先级高的模块）
　　写清楚下个星期的测试计划是什么
　　2、测试情况
　　2.1 再介绍一下本周的测试模块
　　2.2 写清楚当前模块的质量情况：open了多少bug，fix了多少，close了多少。bug的趋势是什么（后期应当收敛，在前期如果未收敛，解释未收敛的原因）
　　2.3 本周遇到的问题是什么（风险是什么）
　　3、贴图
　　3.1 相关图片，有需要解释的进行解释（如reopen的bug，高级别的bug）
更多测试相关精彩文章，请查阅51Testing软件测试网：http://www.51testing.com/html/22/n-865022.html

　　1.测试为质量而不只是数量：“这有1000个bug…很好！”测试员，请不要被数量震慑住。识别出最重要的缺陷和故障，帮助公司或者开发使bug更具有意义，这件事比仅仅为数量而测试要高出10倍的帮助。
　　2.学会考虑优先级：在第一条中，优先考虑测试什么是很重要的。在测试应用细节前，先测试应用程序的最关键部分，将有助于你第一时间找到最有价值的bug。当然，这也使得开发团队能够尽快地修复应用最核心的部分。
　　3.练习和改进书面交流能力：为了写出好的测试用例、bug报告等，优秀的测试员就必须具备极好的书面交流能力。这些测试文档是QA不可缺少的部分，必须详细和容易掌握的。
　　4.从自己或者其他人的错误中学习：每个人都会犯错，但是从其他人和自己所犯的错误中学习到东西，将有助于你成为更好的测试员。下一次你如何改进你的bug报告？下一个测试周期里，你又将如何更好得划分优先级？你又将如何更好得和开发团队交流呢？这些问题，你需要时时得问自己，问自己的测试人员。
　　5.做事客观、专业：每一次你执行测试，都得用一个全新的视角来看待。面对你所正在测试的软件，你需要摒弃偏见和过去的那些经验，并用开放式的思想来测试。那些想着“Oh，我知道这个软件”或者“我以前使用过”的测试员，很可能会忽视重要的bug。
　　6.不要被软件牵着走…打破陈规：探索软件，“打破测试”并提出改进意见。
　　7.提问一切事物：是否会按预期运作？是否会在所有设备上有效？是否每次都会在每个可用的用例下执行？为什么会造成这样的结果？是否可以变得更好？
　　8.考虑用户体验：记住，你的工作是在软件交付到用户手里前找到bug。用一个最终用户的心态加上你的技术技能，你将可能找到最优价值的bug。
　　9.增加bug报告的有效性：附上屏幕截图，提供细致的bug报告将给予那些需要理解bug并解决它的开发有效信息，尽可能用video来记录屏幕，附加到bug报告。Bug在哪里出现，时间、频率、在什么设备上、在什么操作系统上运行以及当时的情况。提供每个可能的细节/信息来方便其他相关人员理解这个问题。
　　10.充满工作热情！想在任何地方都出类拔萃，你就需要对你所在做的事充满热情。阅读，寻求新的培训机会，和你的测试人员交流分享，参加测试会议。
　　成为一名优秀的测试员，我确信还有许多需要做的。在评论部分分享你的观点吧。
本文转自：51Testing软件测试网

　　前言
　　公司的iOS测试机快达到苹果规定的100个上限了，而因为the new iPad新出，我们需要新的quota来测试新iPad，所以就仔细研究了一下苹果关于100个测试设备上限的规则。在这里分享给大家。规则的详细内容主要来自 苹果的官网文档。
　　规则
　　我总结出来的规则如下（附上原文以便对应）：
　　每一个开发者membership year,只能有100次增加设备的名额。如果你增加一个设备,之后又将该设备删除,并不会将用掉的名额恢复.
　　You can register up to 100 devices per year for development purposes. Any devices added, then later removed, still count towards your maximum number of registered devices per year.
　　在每一个开发者membership year开始的时候,Team Agent和Admin角色可以选择删掉一些设备来恢复资格, 也可以清空所有设备来恢复到最多100次设备的名额。这个操作在Team Agent和Admin在一次新的membership year开始后即可使用，在使用时，需要注意，先将需要删除的设备删掉，然后才能添加需要新增的设备。一旦开始增加新设备，删除设备以恢复名额的功能将不再可用。
　　At the start of a new membership year, Team Agents and Admins can remove devices and restore the available device count for their development team to 100 devices.
　　When Team Agents or Admins first sign in to the iOS Provisioning Portal at the start of a new membership year, they will be presented with the option to remove devices and restore the device count for those removed devices.
　　Important Note: At the start of your membership year, make sure to remove all devices you no longer use for development prior to adding any new devices.
　　在以后整个membership year中，删除设备不会增加新的名额。
　　Removing devices during your membership year will not open these slots to add new devices.
　　举例
　　直接看规则比较晦涩，举个例子：
　　假如第一年，你增加了70个设备，同时删除了10个设备，这个时候，虽然你的设备数是60，但是可用的增加测试机的名额却只有30个了。
　　到了第二年，你续费了开发者身份，在你第一次登陆进去后，你可以看到你的可用设备恢复成 100 – 60 = 40个了。这个时候，你可以选择删除一些设备，例如你又删除了20个设备，这样你的名额数变成60个。之后你增加了一个设备，因为你选择了增加新设备，苹果认为你已经放弃删除设备以恢复设备数的机会，这样，你的名额就固定成59个。以后删除设备都不会增加新名额了，直到你的下一个membership year开始时才又会有这样的机会来删除设备释放名额。
.....
本文转自：51Testing软件测试网

　　当你预期的那一天，也许是你害怕的那一天，终于来到了：从工程师的队伍里，你被提拔到了软件项目领导或者团队领导即项目经理的位置。
　　这也许就是你选择的职业道路，或许你不太情愿，将就尝试一下。无论在哪种情况下，你都可能缺少工程学科、人员管理以及领导能力的相关教育。这需要更多的领导能力和管理(它们不是一回事)，而不能象Dilbert（译注：著名IT漫画主角）那样简单地和老板对抗了。
　　当你考虑新的目标时，请考虑下面的活动计划列表。一次就抓住了每个亮点，这是不可能的。但是这份建议说明可以帮助你将注意力放在可以提高你和你的团队绩效的活动上。
　　一、建立优先级
　　作为项目经理，首先要做的、最重要的事是你需要有意识地建立优先级。当你仍陷于繁重的软件开发活动中时，你需要一套新的职责。过多的经理新手不能抗拒技术的吸引而陷于此类活动，这将导致项目组的其他人员想要获得经理的帮助时，却得不到帮助。
　　有成效的领导知道他们首要的任务是为其他组员提供服务。这些服务包括训练和指导、解决问题和冲突、提供资源、建立项目目标和优先级、提供适当的技术指引。
　　要使每个组员都能清楚的知道，你总是可以帮助他们。我发现将自己定位于为被我监督的人工作是非常有意义的，而不是相反的。在你所作的事情中，对于组员要求你帮助他们这件事，应该具有非屏蔽中断的优先级。
　　第二重要的，是使你的客户满意。作为一名经理，没有直接的能力使客户满意，因为你已不再是作为个人提供产品和服务完成这点。相反，你必须建立一种环境，准许你的组员最大程度上满足客户的需求。经理提供了强有力的方法，有效地提高客户的满意度。
　　第三重要的，是为你的项目工作。因为也许还有其他许多技术上的项目，或者其他经理的请求帮助，诸如为指导委员会工作。当这些和二个高级别的发生冲突时，都要准备推辞掉。很明显，使其他经理满意的事情是你最不重要的事情。
　　在一个有秩序的组织里，如果你在三个以上的重大环节上获得了成功，其他的经理都会很激动的。我们并不都能很幸运地工作在一个良好的环境里，但一定要对你任务单上排在最前面的工作任务努力尽到最大的责任。集中精力有效地、快乐地、尽可能地帮助你的组员，不要将精力放在使你上司满意的上面。
　　二、分析你的技能差距
　　除非你已经为新位置做好了准备，否则相对于你当前的领导能力和管理技能，你会感到一些差距。出色的技术背景或许是你被选为领导角色的一个因素，但是你要想干得出色，你需要更多的技能。针对别人的评论和项目，真实地列出你的长处和短处，然后减少差距。软件人员并不以令人满意的人际关系技能出名。你会希望增强处理人际关系的经验：解决冲突、说服以及灌输想法。你也不得不处理包括招聘、解雇、商谈计划表，以及在你的办公室里评论某人业绩使其伤心落泪等一些事务。
　　我发现从一堂倾听技能课开始我的管理职业是非常好的。当作为个体提议人，积极地将我们自己的技术议程提交小组时，我们经常对此感到非常惬意。有效的管理要求更多的合作和善于接受的人际关系方式。要花点时间学习如何(何时)巧妙地引导自己的自然判断。倾听技能课提供了一种交流机制，我已经发现在许多场合下都很有用。
　　接着，到讲台的另一侧，提高你的演讲能力。如果你真的不适应公开场合的讲话，学习戴尔.卡内基的课会有帮助的。你会发觉，通过这样的培训获得的经验，以及获得提高的交流能力，都可以帮助你更好地适应将来的工作。
　　作为项目领导，为了计划和跟踪项目， 以及当需要项目回退而采取修正措施时，你有责任调整其他人的工作。参加项目管理的培训课，阅读一些有关项目和风险管理的书籍和文章。参加项目管理学会，阅读其月刊--PM Network。SEI的软件能力成熟度模型对于软件项目计划和项目跟踪提供了很多有用的建议。建立优先级的能力、控制有效果的会议、清晰的交流，对于你，作为一名经理的绩效将会有实质上的影响。
......

 本文转自
               ╭═══════════════╮
                ║     51Testing软件测试网      ║   
  ╭══════┤                              ├══════╮
  ║            ║    http://www.51testing.com  ║            ║
  ║            ╰═══════════════╯            ║
  ║    ╭───────────────────────╮    ║
  ╰══┤       论坛域名：bbs.51testing.com            ├══╯
        ╰───────────────────────╯

　　在说去年兰亭第一次搞这种大型促销活动之前，有必要跟大家说一下国外几个非常重要的购物节：
　　感恩节（Thanksgiving Day）
　　感恩节是每年11月的第四个星期四，由美国创立，原意是为了感谢上天赐予的好收成，是美国国定假日中最地道、最美国式的节日，和我国的春节一样重要。感恩节购物已经成为了美国人的习俗，从感恩节到圣诞节这一个月，总销售额能占到全年的1/3，是各个商家传统的打折促销旺季。
　　黑色星期五（Black Friday）
　　黑色星期五是感恩节的第二天，也就是11月的最后一个星期五，这一天是美国人圣诞节前的大采购日。美国的商场都会推出大量的打折和优惠活动，以在年底进行最后一次大规模的促销。因为美国的商场一般以红笔记录赤字，以黑笔记录盈利，疯狂的抢购使得商场利润大增，因此被称作"黑色星期五"。
　　以前黑五促销主要以实体百货为主，据说是因为周五这天一大早，所有人都要摸着黑冲到商场排队买便宜货。随着网络电子商务的发展，越来越多的大促搬到了网上，大家足不出户就可抢购，也给了很多人海淘的机会。
　　网购星期一（Cyber Monday）
　　网购星期一是美国感恩节后的第一个星期一，大约从2000年开始，美国亚马逊、eBay等电商会在这一天推出大规模促销活动，成为“黑色星期五”的电商版本，就是真正的网购节。
　　大促那些事儿
　　去年9月份的时候兰亭搞了第一次大促销，前前后后持续了一个月，当然肯定也不是这三个节日，而是兰亭自己推的大促，据知情人透露这是在清库存，把积压的库存变现，让上市后第一个Q的财报漂亮点。记得当时是第一次搞这种促销活动，很多部门都牵涉进来了，采购，物流仓储，运营部门，品类管理部门，产品技术以及创始人等等。而跟我们关联度最高的莫过于促销页面开发测试及上线。当时大促是做四期，头三期是预热，最后一期才是促销商品的抢购。
　　如果要说产品复杂度，的确没有什么，最多就是要考虑到抢购时超卖情况以及开发一款网页游戏来抢Coupon（优惠券），另外增加了一种促销方式：秒杀，同时对于活动期内的秒杀商品需要在品类页，站内搜索页等等优先显示并打上秒杀图标，给用户以提示，除此之外，就是促销页面的开发，只不过当时最令大家头疼的就是分享到Facebook和Twitter等社交网站的功能，因为活动折扣价跟分享数和收藏数相关联，国内常受到第三方网络等影响，经常出现一些问题还需要排查到底是不是bug。而且做过互联网的都知道，只要涉及到页面样式和交互比较多的，就有比较大的工作量，很多样式的bug，兼容性的bug以及JS交互的bug。当然如果紧急上线肯定就需要做一些取舍，保证重要的功能没问题，其余的bug可以不予理睬，记得每一期发现二三十个bug，有一大半没有修复。
　　在我们拿到需求之后发现每一期的开发测试上线周期都只有两三天的时间，时间紧任务重，是摆在我们所有人面前的困难。为了保证大促的顺利进行，所有人都投入进来了，我们测试部门也对此做出了工作部署。把每一期功能或区块细分，同时把不同期的相同或相似的指派给2个人，这样每一期大概2～3个人参与，相同或相似的模块又不会没有backup，也不会造成同一个人连着做好几期的情况，后来证明这么部署是非常正确的。
　　当时大促的每一期都不轻松，基本都是要加班到凌晨2～3点，甚至好几天都是到了天亮才搞完，大家再回家休息，每一期其实都是不同的人参与，这样既能保证产品顺利发布，又能让加过班的同学第二天在家休息。记得当时有一次大家连着加班到第二天中午，我们早上去上班的时候还没有下班，接着把产品搞完上线，而晚上的时候也只是在公司办公桌趴了一会儿接着干活，相当辛苦，脸色也很憔悴。当时因为我正在学车，周末时的加班没有参加，平时我和其他两个人分工负责了每一期的上线，所以有时候也是要加班到很晚。当时有一期，公司其中一个创始人也跟着我们搞到凌晨12点，他在协调着几个大部门的工作，保证大促顺利开展。
　　在这之后不久，公司内刊的人邀请我写一篇大促的文章，说说我的所见所感，毕竟这是公司第一次搞大规模的促销，盛情难却，抽了个晚上写了一下，后来发表了，并且选了一张自认为拍的最帅的照片刊登上了。后来到了年底又才有了Black Friday和Cyber Monday同样持续差不多一个月的大促销。同样是耗费了不少的时间和人力，当时大家其实都非常想搞一个通用的模板在线进行编辑生成大促页面内容，不用再投入技术人员，但是项目紧资源少，平时都没有空来做这个，不知道在我离开之后现在是什么样子。而且我参与过的这两次大促给我印象最深刻的就是没有提前规划，很多东西到了正开发的时候还在改需求，并没有像阿里和京东那样差不多提前几个月就在规划逐步开展大促项目，有条不紊。来了京东，也算是经历过一次618了，我觉得很有必要以后跟大家分享下我经历过的618，不知道大家感不感兴趣？
　　版权声明：本文出自 zzzmmmkkk 的51Testing软件测试博客：http://www.51testing.com/html/65/n-864165.html
　　原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。

　　何为测试？测试就是检测，审查一个事务是否符合既定的标准。测试就像是空气和影子，如此亲密无间。曾听闻有人说“人人都是产品经理”。这话有些过了。今日我说——人人都是测试大牛，这却是实实在在。
　　不止以下场景你是否熟悉？
　　1）菜的时候看看蔬菜新鲜否？
　　2）找钱时候看看真假。
　　3）买衣服时看看款式默默料子。
　　4）甚至打英雄联盟时，记得插眼看看情况。
　　如此之类不胜枚举，其实测试天赋是天生的，只要人有欲有求，就有测试，只有有原则，有所谓的世界观，价值观，就有测试，因为你为人处事，不也拿实际情况和内心的标准做对比嘛？
　　我说，其实每个人都是被封印的测试大牛，测试工作，更容易无师自通。测试思维锻炼在于平常。厚积而薄发，迟早你会有功成名就的一天。不是吗？下面我们来看面试官总爱问的一道看似无理的问题“我身边有个桌子，你测试下吧”看似无从着手嘛？错，其实灵感就来源于生活。
　　1）一个桌子的本质就是放东西吧，测测其承重力。
　　2）或许他是一个家具，就测测其样子，形貌。
　　3）热的食物放在上面，就是个问题，何不测测其耐热能力，甚至是防火，放水等。
　　4）桌子旁边坐的是人，何不测测它的容量。
　　5）家里有孩子会不会磕到？测测其安全系数。
　　6）桌子的伴侣是椅子，何不测测它的百搭系数？
　　7）古语有个拍案而起，生气了喜欢敲桌子，何不测测其抗击打，甚至是抗磨损能力。
　　8）如果你用它打游戏，怎能不要求平稳能力？
　　诸如此类等等，等等……其实测试思维来源于生活的思考和积累，正如那句话，世界上不是缺少美，而是缺少发现美的眼睛，不用等着所谓的大牛去点化你，只要你够用心，善于总结思考，你就是大牛了。大道至简，最总要返璞归真，测试也不例外，不过是让一个产品的质量尽可能高。
　　在此我不妨啰嗦一句，有的不负责任的测试人员说，测试不能提高产品的质量，想要提高只能靠研发，和产品同学。我说大谬，那老板要你吃白饭嘛？所谓不以善小而不为，起码我们能保证用户看到尽可能高质量的产品，能对内提出合理的改进意见，只要言辞得当，相信大家也会乐意配合。天下兴亡匹夫有责，何况测试人员在质量问题上责无旁贷。哪怕你就当自己是个监军，你却真的明白监军的职责和任务嘛？
　　自豪的做个测试人员，因为我们是天纵英豪。意随心动，发觉自己的测试天赋。
　　版权声明：本文出自 qishaorain 的51Testing软件测试博客：http://www.51testing.com/html/58/n-864558.html
　　原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。

　　软件项目区别于其它项目的最显著的特征是其不可见性，它不像硬件购销、建筑工程，都是实实在在可见的东西。而软件项目在系统交付之前很长一段时间，客户是无法感知自己想要的系统究竟是什么样子。因此，需求管理就显得十分重要，据相关统计数据分析，软件项目90%以上失败的原因都在于没有重视需求或者需求管理方面做的不到位导致的。
　　需求管理作为软件项目管理的一个重要内容，贯穿项目实施的全生命周期。俗话说：万事开头难。需求作为软件开发的第一个环节，其重要性不言而喻。市面上关于需求管理的相关理论和书籍很多，但多数停留在理论层面，实操性不强。本文主要是根据我们以往项目的经验，进行一些需求管理方面的探讨。我们可以简单的将软件项目的需求管理分为需求获取、需求分析与验证、需求变更控制三个核心内容。
　　（一）需求获取
　　需求获取是软件项目需求管理的第一个过程，在这个过程中我们需要运用科学的方法以及相关的项目经验库辅助我们进行需求获取。需求获取的核心内容是通过调研掌握软件项目的实际需求，以便于指导整个项目的实施。需求获取的主要方法包括：用户访谈、问卷调查、现场观摩、头脑风暴等方法。在实际的项目操作过程中，相对比较明确的需求，我们可采用比较固定的需求获取方式，比如：问卷调查等。而对于相对比较模糊的需求或者说用户无法清晰表述自己需要的是什么的时候，我们可采用比较灵活的方式，例如：用户访谈、现场观摩等。
　　需求的类型主要包括：业务需求、用户需求和功能需求。在需求获取的过程中，无论采用哪种方法，我们都需要自顶向下或自下向上去了解用户真实的想法。业务需求的获取对象主要是客户的高层领导，我们都知道，项目的发起、实施、最终的成败很大程度上都取决于高层领导，我们需要对他们进行访谈，了解高层领导的公司战略、发展方向，更为重要的是获取他们对将要开发的软件系统的期望，以及希望该系统在解决现有业务问题，对公司整体战略的支撑方面的期望。帮助我们去更好地理解系统的宏观构想。在掌握了业务需求后，我们需要对中层管理人员进行调研，核心问题是搞清楚在宏观战略目标落地的这层，或者说指标细化并负责实施的中层他们对软件系统的期望以及实际要求，他们或希望此系统能够带来工作便利，或希望此系统能够做到精细化管理，如此等等。但他们都是具体的业务部门负责人，对自身的业务以及系统对业务的促进方面，有比较深刻的体会。最后，我们需要在掌握了业务需求、用户需求的基础之上，通过对IT管理部门、主要操作人员的需求调研或根据我们对需求的理解，细化出系统的功能需求，这个需求是最低层次的需求，也是一个层层落地的过程。
　　（二）需求分析与验证
　　在获取到软件项目需求后，接下来的工作就是对需求进行分析与验证，在项目的实际操作过程中，主要包括：需求分析建模、需求规格说明书编写和需求评审三个大的阶段。
　　需求分析建模主要是对已搜集到的信息进行提炼、分析和仔细审查，为最终用户所看到的系统建立一个概念模型，确保所有干系人都明白其含义，并能找出其中的错误、遗漏或不足。需求分析是软件项目需求管理的最重要一环。
　　在需求分析与建模过程中，对于用户需求不确定或用户无法清晰表述需求的，为了加快项目进度，我们往往采用原型法进行需求分析与建模，即根据我们的经验以及对用户基本需求的理解，用Axure等原型设计工具搭建一套原型系统。另外，我们还需要采用UML工具进行用例分析、用例描述等，并最终编写形成《软件需求规格说明书》。
　　需求验证或需求评审是衡量需求阶段产出成果的重要手段，在完成需求分析与建模后，项目相关干系人应组织召开需求评审会，邀请相关专家、外部相关单位等进行需求评审，就需求分析的结果《需求规格说明书》、原型系统等进行评审，并对评审结果进行签字确认，确保需求没有偏离用户要求，又略高于用户要求。
......
本文转自：51Testing软件测试网

　　文档需要全面，实时更新，并且易懂。我说的全面是指除了介绍程序的功能外还应该覆盖到代码中一些重要的地方。对很多人来说文档的重要性不言而喻，但很难保持它的及时性和准确性。糟糕的文档的后果通常会浪费更多的资源和时间。往往都是出于一些错误的原因而编写的文档。
　　要求文档的一些原因
　　有很多原因导致我们需要编写文档。团队经常会由于一些制度上的要求而编写文档，或者就是纯粹出于无知。下面是一些编写文档的错误的理由：
　　有人认为文档和项目的成败息息相关。
　　文档能够证明某些人的存在。
　　需求方除了文档也不知道要什么好
　　要你提供文档的人也就是求个安心，知道事情都OK了
　　工作流程提示说，你该创建文档了
　　文档都是过时的
　　软件文档的一个主要的问题就是它通常都不是最新的。代码的某个部分可能发生了改动，但是文档却体现不出这个情况。这句话适用于几乎所有的文档，影响最大的其实还是需求和测试用例。不管你多努力，文档的过期无可避免。
　　文档对谁有用？
　　取决于不同的受众，文档的类型和格式也会相应地有所不同。开发人员，测试人员，客户，主管，最终用户都是文档的最大的潜在用户。
　　开发人员
　　开发人员不应该依赖于文档，因为它们通常都是过时的。除此之外，没有什么文档能比代码本身更能提供详细以及最新的信息了。如果你想知道某个方法做了些什么，看下这个方法吧。不确定某个类是干嘛的？看一眼它。通常只有代码写的太差了才需要给它添加文档。
　　使用代码本身作为文档，这并不代表不需要其它的文档了。关键是要避免冗余。如果看一下代码就能获取到系统的详细信息，那么还可以有一些其它的文档来提供快速导读以及更高层面的一个概述的功能。代码本身的文档是回答不了这个系统是干嘛的或者这个系统用到了什么技术啊这种类型的问题。大多数情况下，对于开发人员而言，一个简单的README.md就足够他快速入门的了。像项目描述，环境配置，安装，构建及打包指令这些东西对项目的新成员来说非常有用。但那之后，代码就是你的圣经。产品代码提供了所有需要的详细信息，而测试代码则是作为产品代码的内在意图的一个描述。测试用例就是可执行的文档，而TDD（测试驱动开发）就是实现它的最常见的方式。
　　假设你用了某种持续集成的方式，如果测试-文档（这里测试就是文档，文档也是测试）中有一部分不对了，这个用例会执行失败，它将会很快得到修复。持续集成解决了测试-文档不正确的问题，不过它不能保证所有功能都是有文档的。由于这个原因（当然也有其它原因）测试-文档应当用TDD的方式来创建。如果在代码开发前，所有的功能都定义成测试用例，那么测试用例就能作为开发人员的一个完备的最新的文档了。
　　那团队的其它成员怎么办？测试人员，客户，主管，还有其它非码农呢，他们可能无法从产品和测试的代码中获取到所需要的信息。
.......
本文转自 51Testing软件测试网