功能测试心得多篇文章

1、接触功能测试已经有三年之久，对功能测试也有自己的一些感触和心得，下面就说说功能测试那点事。一、从测试前期工作开始谈起当接到一个新项目时，首先需要做的就是了解该项目的测试内容，测试范围，项目周期以及项目目前 的进度。根据对项目的了解，综合测试资源，制定出项目的测试计划和测试策略。当项目开发的已经比较 完整，可以直接进行系统测试，基本上采取常规测试，系统测试和回归测试进行交替。有些项目，只完成 部分模块的开发时，则适合加入集成测试。如果项目时间比较紧张，而资源条件又允许的条件下，也可以 进行敏捷测试。根据项目各自的特点，采取最佳的测试策略。二、关于模块划分和用例编写关于weJ测试，大家也都知道，有

2、些功能是基于页面的。当功能和页面相互融合的时候，对于模块的 划分就不是那么容易了。如果按页面进行划分，比较容易进行任务的分配，操作起来也比较容易控制。但 是，每个页面上会出现重复的或类似的功能，出现问题后，容易产生冗余和重复的bug。如果按照功能去 划分，可能需要在每个页面上进行重复操作，并且对于web页面的测试，功能也不是很好区分，不是很明 显，并且比较散，可能一个操作会对多个页面产生影响。我的经验是，一般情况下，页面划分优先级高于 功能模块划分。当然，具体情况还要具体分析。关于用例如何编写，我想大部分的测试工程师都会比较了解，什么等价类划分，边界值分析法，因果 图法，等等，大家只管去网上查

3、吧，介绍的有很多。只要有用例的标题，操作步骤，期望结果，基本上都 是可用的。三、测试过程当用例编写完成，项目组进行了用例评审后就可以直接进入测试执行阶段了。（对于如何进行用例评 审，曾经尝试过两种方法，一种是每条逐个评价，一种是只评价用例框架。前者耗时太多，后者细节不够， 总是无法找到最佳的方式。不知各位看官是否有这方面的经验。）在这个阶段，曾经做过一个关于交叉测 试的实验。项目中，有测试工程师A编写完的用例，分配给B来执行，或者，在项目接近收尾的阶段，让 团队人员进行互相补充的交叉测试。发现，后者的结果比前者要好。因为前者是将交叉测试放在项目比较 靠前的阶段进行，一般情况下，工程师会严格按照

4、测试用例进行测试，很难有时间去挖掘深层次的缺陷。 而后者是将交叉测试安排到项目比较靠后的阶段进行，此时，大部分的缺陷已经被挖掘出，可能在进行测 试时，有助于思维的发散。四、测试风险评估在测试整体完成后，需要测试负责人对该项目进行总结，编写测试报告，其中必须要做的功课就是进 行风险评估。测试环境和线上的正式环境还是存在不少差异，有些模块在测试环境下可能无法进行完善的 测试，比如数据迁移的问题，比如第三方接口的不稳定。对于测试覆盖不到的地方，尽量在此列出，提醒 相关人员的注意，将上线后可能出现问题的风险降到最低点。对于功能测试的流程以及每个阶段如何开展，网上的资料已经很多很多，就不细说了，上面几点

5、是在 工作中，觉得值得注意的几点，希望大家可以共同探讨。第一篇文章总结：测试用例执行时实行交叉测试方法，A设计的测试用例给B完成，B设计的给A完成， 一般是在项目后期进行效果比较好第一篇文章测试用例是测试执行的关键，它直接指导如何测试。测试用例的产生源于测试需求，所以在此之前需要把 测试需求做好。根据测试需求的分类，在系统功能方面，我把它分成三个集合：界面功能，通用功能，业 务功能。任何一个页面的元素都可以分解成这三个集合中的子集或元素。根据这三个集合的特点选择不同 的测试用例设计方式。具体的设计可以参考不同的用例模板，对于界面功能，选择简单的模版，甚至列表 都可以，因为它们的元素一般都比较独

6、立。通用功能指在很多系统中都会出现的一些常规功能，比如：“上 一页”，“返回”，“返回主界面”等，它们有页面的动态变化。在数据库里的反映，就是最多只涉及单个表格 的改动，并不引起表与表之间的连锁反应。它所使用的用例模式可采用现在常用的描述法表示。不过对具 体系统中的某些功能点还需要具体再考虑。测试用例设计的重点就是业务功能。对于一个熟练的测试人员来说，界面和通用功能的检查，用例已 在他们的心中，并不需要文档指导。业务功能是一个系统的核心，它往往也代表了一个管理软件的价值。 业务功能的测试用例模版，我现在比较支持场景法。对主业务流的设计采取全路径的检测，因为他们的节 点不是特别多，其它的不再累述

7、。除了对系统正确业务流执行的设计外，还有其它一些设计方法，根据测 试人员的不同特点，他们的设计也会有所不同。业务功能的设计在我看来是最能反映出测试设计人员的专 业水平。因为它不但需要好的测试技术还需要好的系统相关行业知识。这种用例分类的想法，是为公共用例库的建立策化。为了方便测试文档管理，培养新人，特别是将熟 练的测试人员从重复繁重的文档工作中脱离出来，重点放在如何检查系统上。这种分离是有必要的。此外 还有一个特别操作集，源于某些测试人员的非常规操作，范围超出三个集合，但错误对系统的影响很大。 这个集合比较小，可以单独管理，用于对系统稳定性的考察。我有时候觉得系统就跟人一样，没有完美的人，也没

8、有完美的系统，我们只是努力做得更好。第二篇文章总结：业务测试是功能测试中的重点，比较支持场景法第二篇文章万科项目的功能测试已经接近尾声，作为常规项目，与产品化项目存在一定差异，从测试来说，对常规项 目与产品化项目所提缺陷的尺度与侧重点也应该是存在差异的，在这一点上，我对自己在万科项目中表现 的并不满意。首先，并未理解常规项目与产品化项目的区别，往往以产品化项目的尺度来要求万科项目在一些方面 做出改进。其次，测试过程中没有所谓的侧重点，基本上是广撒网的形式。那么，作为测试应该如何应对常规项目与产品化项目的差异，并做好功能测试呢？常规项目由于是由客户提需求，那么从业务层面上讲，测试人员的业务经验应

9、该是服从于客户的业务需求的， 不能作为评判功能是否合理的依据或标准（冻结的业务需求是唯一的标准）。常规项目的测试侧重点则应 该放在客户真实的业务场景上，要明白客户如何使用我们的软件，使用软件的哪个功能解决什么样的问题， 我们的软件是否真的能很好地为客户解决这些问题？个人认为常规项目的功能测试安排两轮为好。第一轮，以主流用户（即客户）的角度测试功能的正确性，在这一轮中，需明确列出客户使用软件的 各个业务场景，测试点覆盖所有的业务场景。理论上来说，这一轮发现的问题将会主要集中在跨模块的业 务场景中，所以需重点关注跨模块的业务场景。这一轮中发现的问题一般都是功能上的，严重级和优先级 都很高，开发和测

10、试需要尽快修复和验证，以保证第二轮功能测试的展开。第一轮的测试效果很大程度上 依赖于测试人员对客户需求、真实业务场景的理解和掌握，所以测试人员如何更好地掌握客户的需求和业 务场景很关键。第二轮，以专家用户（即测试人员）的角度对软件的健壮性及容错性进行验证，在这一环节中的侧重 点是对异常情况的考虑，例如功能并发、不符合条件的输入、边界值等等。第二轮测试最好能够安排交叉 测试，测试人员重点测试自己负责的模块，对其他模块的关注度可适当降低（在工作量上体现），这样的 交叉测试的好处是能很轻易地覆盖由于不同人看问题的聚焦点不同而带来的测试盲点。产品化项目个人认为产品化项目对测试来说有着更高的要求，因为对

11、产品化项目来说，面向的客户并不是固定的， 因此就不会有非常明确的业务场景，也不像常规项目那样，有任何不明确的地方可以直接找一线确认，然 后按照客户提的需求实现即可。所以对测试来说，在功能的合理性方面也是需要增加关注度的，这样，对 测试也就会有更高的要求，对业务的熟悉，对公司管理理念的理解，这些都将直接影响到测试的深度。个人认为，产品化项目功能测试流程基本可以参照常规项目的两轮测试，而根据其差异，需增加关注 点、调整测试尺度。在第一轮中，需要增加对功能合理性的考虑，加强对各种异常的业务场景的验证，思考功能的实现是 否遵守先进的管理理念，这些看似并不属于测试的范畴，但个人恰恰认为正是这些对产品的完

12、善和个人能 力的提升有着很积极的意义。在第二轮中，与常规项目相比，测试应该提高对产品的要求。真正让客户觉得产品是否专业的，往往 是细节。大胆的制定严格的尺度，面对吹毛求疵、鸡蛋里面挑骨头的评价必须hold住！关于产品化项目，说句题外话，卖产品的同时也是在卖你的管理理念，先进的管理理念才能真正成就 客户并得到客户的认可，也在不知不觉中提升了客户对我们产品的满意度。功能测试国别差异之我见发布时间：2011-9-23 14:19作者：Sean Liu来源：51Testing软件测试网采编字体：小中大|上一篇下一篇|打印|我要投稿|推荐标签：软件测试功能测试作为黑盒测试的一个重要阶段，功能测试毋庸置疑

13、是不可缺失的。功能测试的相关话题很多，无论是 测试的形式，例如手动测试和自动化测试，还是测试方法，例如数据驱动和关键字驱动，都有大量的研究 文章。我这篇博文里却打算从国别不同的角度来讨论一下功能测试的差异，原创文章可能有一些谬误的地 方，请读者指摘。日式循规蹈矩日本人给世界其他民族的印象是做事认真严谨，对待问题一丝不苟，犯了错误按严重程度该下跪的下 跪，该剖腹的剖腹。他们的这种一贯行事方式也带到了软件行业，而软件行业的摩尔定律，技术的日新月 异，代码、框架的多变，都似乎与他们的性格格格不入。日本制造的东西一向以坚固耐用著称，给我映像 最深的一个细节是，在日本工作的时候，发现他们的垃圾袋居然都坚

14、固无比，用来逛超市买东西拎重物也是屡用不坏。然而，对于遵从摩尔定律的计算机行业来说，投入大量的精力来尽可能的发现bug以及解决 问题是否很值，这真的是有待商榷的问题。但，话虽如此，日企采用的测试用例的设计方法还是非常值得我们学习的，这其中又首先要提一下要 因分析法（网上有些说法把鱼骨图等同于要因分析法，我并不赞同此说，后面会有详述）。要因分析法的精髓在于，以产品的某一特性为因子，以这个特性的不同表现（根据等价类划分、边界 值分析等方法）为状态，一一列举后，采用二维组合的方式来确定测试用例。下面我举一个简单的例子“我打算从南京去北京”来说明。因子。交通方式天气情沿出发时辰一状态氐飞机*晴点白天/

15、状态2二火军*雨#夜晚二?状态3汽车e争表1这即是一张简单的要因表，值得注意的是，因子和状态的确定是必须规定范围的，而这个范围在这个 例子中则为“正常人的思考”范围。譬如说，“交通方式”我没有写“步行”，因为这不符合常人从南京去北京的 思考方式，当然有人为了挑战吉尼斯纪录，这里非要采用步行方式从南京前往北京，那么状态里添加这项 显然是可以的。此外，因子和状态的另一个隐性的确定方针为详细度，这个度如何把握，我们可以从下表来理解:因子砂飞机火车/汽车F天气情沅出发时叵状态0南方航空动车* :;豪华卧铺晴点白天/ 状态2“东方航空口高斑.普通卧铺口夜晚中.状态p特此争状态心普快弟表2表2将表1的“交

16、通方式”进一步细化，此时状态的选择将进一步增多。如果要求详细度更加提高，例如因子为“动车”，那么可以加上状态为“一等座”和“二等座”，这种组合很灵活，取决于我所需的详细级别。要因确定之后，便是组合，以表1所列要因为例，二维组合有下列共18种：飞机-晴-白天，飞机-雨-白天，飞机-雪-白天，飞机-晴-夜晚，飞机-雨-夜晚，飞机-雪-夜晚火车-晴-白天，火车-雨-白天，火车-雪-白天，火车-晴-夜晚，火车-雨-夜晚，火车-雪-夜晚汽车-晴-白天，汽车-雨-白天，汽车-雪-白天，汽车-晴-夜晚，汽车-雨-夜晚，汽车-雪-夜晚对于表2来说，二维组合则有2*4*2*3*2=96种，貌似有点多，当然你想分

17、析的越详细，那么组合数量 自然会相应的增加。回到表1得出的18种用例，假如我的通过条件是从南京到北京的时间越短越好，在实际的外界环境 下（例如晴天，预期花费有限额），这18个用例中，就会出现有的测试通过，有的测试失败的情况了。在 不同的实际外界环境下，测试通过的情况还会发生变化（例如下雪天，飞机会发生班次延误）。要因分析法的好处在于“事无巨细，滴水不漏”，坏处在于过程“繁琐冗长，枯燥乏味”。即使如此细致的要因 分析，依然存在一定的用例遗漏的风险，这个风险来自于对因子和状态潜在的考虑不周。随着详细级别要 求或者系统复杂度的提高，使用要因分析法组合出详尽的测试方案则成为了QA的一种折磨，每一个QA

18、 遇到复杂的测试对象，都将成为酷刑下折翼的天使，欲哭无泪的在心中默默呐喊“坑爹啊”（因此要对要因 法做一定程度的改良，如何改良，后文将详述）。前文伏笔“要因分析法不是鱼骨分析法”，鱼骨分析法的另一个更加正式的书面称呼是“根本原因分析法” （日本管理大师石川馨先生发展出来的，故又名石川图）。根本原因分析法同样有着折磨常人的地方（题 外话：为什么日本人使用的方法总是那么坑爹？），它要求分析者们集中精力寻求发生问题的任何一种可 能性（头脑风暴），将这些可能性绘制在鱼骨图上，再寻求所有可能性的根源，其本质上不是一种用于设 计测试方案的方法（仅仅用于追溯问题，例如发现bug后追溯引起bug的根源）。关于

19、根本原因分析法的 讨论，由于和本文的重点有偏离，因此不做进一步描述，题外话就此打住。欧美式头脑风暴众所周知，欧美企业的风格是强调人性和自由，对于测试来说，自然不可能采纳日式那种条条框框的 做法。测试方案设计的基本方法和准则，例如边界值分析、等价类划分、因果图等，被QA们牢牢的记在 心中，功能测试方案设计时，根据需求分析或用户手册，众人在一起集中进行头脑风暴，此时包括RD也 将参与进来，对于测试合理或者不合理的地方提出建议。因此，方案设计的时候，更强调的是经验和阅历 以及对需求的关注程度。测试方案设计是有偏重的，对于一些重要的feature强烈关注，用例也将根据feature 的重要性而详略有别

20、。头脑风暴式的测试用例设计的辅助工具往往以思维导图为主，还是以“我打算从南京去北京”为例，其 中一种思维导图设计如下：交通玉机东航大车:东航&初 1南航交虹具高铁火车动车特怏飞机南航交谖：具虫车思维导图的灵活性很高，因此设计出的导图每次都会有所不同，跟随着与会者偏重点的不同而产生不同的 设计方案。好比欧洲的菜肴大多以整块烹制为主，而中国人的菜肴则基本上都是切碎的。这是因为受限于传统使 用的餐具。而测试方案的设计方法也同样受到西方和东方文化差异的影响，例如Agile首先在欧美出现并 迅速得到推广和应用，而Agile绝对不会首先出现于日本。对于头脑风暴式的测试方案设计，这颇有Agile 的风格，项

21、目参与者进行充分的思想交流，QA们将每一个闪现于头脑的想法都记录在案，同时根据别的 QA和RD的建议来不断地修正或弥补方案，直到完成设计。这种设计方法的好处是拥有很好的灵活性，且可以避免精力被耗费到旁枝末节上。用例可以是很多步 骤组合起来的（表现为思维导图的层次较多），通过一个用例测到多个feature，这在进行具体的自动化测试代码编写时可以节省大量劳动力。由于交流足够充分，某些不易被想到的测试用例也可以被挖掘出来（好 比绘制清晰的思维导图）。然而，这种方法的缺点也是显而易见的，某些测试用例有可能在头脑风暴中被 忽视或遗忘，且受限于人的思维的不严密性，未设计在案的测试用例，往往也没有人会关注到

22、为什么这些 测试用例不用测”这个问题。欧美与日式的比较其实从上述的两个篇章，我已经阐述了二者之间的差异。日式苦行僧般的要因分析法，几乎可以遍历 穷举所有可能的组合方式（除非因子有遗漏），设计完毕后，到了具体测试实施阶段，无论是手动测试还 是自动化测试，对于QA来说，都是一个比拼耐力的考验，测试用例数动辄过千，大量的测试用例之间甚 至只有细微的差别。QA将完全体验不到创作的乐趣，转而成为一名不折不扣的体力劳动者。一个测试对 象的测试周期也被大大拉长，所需的人月数也很多。完成这些繁琐的工作之后，测试对象将趋于完美，细 微的bug也将被找出并修正。此时不排除测试对象可能已经是一个落后的甚至被淘汰的产

23、品了。当然，这 对于用户忠诚度极高的日本人来说，这不算什么问题，他们不厌其烦的强调产品品质，但是对于这颗星球 上的其他民族来说，大多宁可忍受一些小bug，也不愿使用一个过期的技术落后的产品。对于欧美式的测试设计，显然比较契合当前的飞速发展的计算机业，但产品中留下的bug数量往往也 会比日式测试法多的多。这尤其表现在产品的一些局部的、次要的功能上，这些功能往往将成为bug集中 营。两者融合的思考欧美与日本，两者采用的方法各有长处。一者的缺点往往恰是另一者的长处。那么该如何从两者中取 长补短，去粗取精以至互相融合呢？这也是我在工作中一直不断思考的一个问题。我认为有一种可行的解决方案可以按照如下的做

24、法进行：1、列出要因表，因子和状态的列举方式可以采用思维导图进行2、根据deadline来划分测试的详略程度，制订测试计划3、头脑风暴，将要因表的二维组合放在参与者的头脑中进行4、在列举测试用例的同时，对不测的用例也要追究一下不测的原因5、归纳测试用例之间的共性，对于差别较小的测试用例，要考虑如何整合到一起，对于可以串行的用 例，要考虑是否可以合并为一个多步骤的用例通过以上5个步骤，我想既可以避免要因分析法的要因组合阶段带来的让人抓狂的繁琐和用例数量过 多的缺陷，又可以避免头脑风暴带来的某些用例的考虑不周。是否还有其他更好的取长补短的方法呢？这个问题将依然萦绕在我的日常测试工作中，吾将上下求索

25、， 并期待您对本文的看法能够给予我茅塞顿开的启迪。第五篇文章今天boss问我们对于公司当前功能测试是否有完善意见，突然觉得这个话题离我们很近，却总来没深入总 结过。还好要求明天上交报告，先在此做些总结，到时候拼装下给boss.接触测试三年了，从测试工程师到测试组长兼sepg，然后跳槽继续测试工程师。一路下来都在跟需求 跟业务打交道。做好测试首先要做好需求、理解业务，这个不用多说了，相信很多人都总结过。当然也听 到过一些言论“换单位了，那业务不是没用了”，换单位后，业务没用这是必然的，我也是从易制毒换到当 前的税务，但有一点都是跟政府行业，其实我们要做的是摸索和总结如何快速获取和掌握新业务，内容

26、不 同，但方法是可以通用的。对于需求处理，就我接触的有以下三种情况。A、有需求说明，无设计文档。B、有需求分析文档，快完成时临时补充设计文档。C、有需求分析文档和设计文档。A这种情况一般分工不是很明确的小团队都会出现，需求来源为客户或者区域客服（特点是太简单了 没经过提取，或者太自我了，很难实现），这时候在不规范的过程也会弄一次需求讨论。这个时候测试务 必要做到这点争取参加需求讨论会议，不用发言，只要听就可以。因为这里没有写文档的习惯，很多 测试标准、需求处理细点都会在口头上体现，你得眼疾手快，参加会议很好的一点就是测试过程中，碰到 不一致的地方，可以有足够的重语气让开发修改，因为你有证据，而

27、不用去问开发这点是不是要改，如何 实现。B这种情况其实是最头痛的，在时间紧和维护项目中经常出现。软件需求功能在界面上都实现了，但 开发只是考虑实现需求，却没有把需求与当前业务（其他模块的逻辑），后台数据处理（例如某个字段更 新）这些弄好。因为功能测试时，测试人员大都会跑流程或者数据库测试，这时候模糊无标准的问题就来 了，头痛。另外一些开发人员就会以功能实现，进入测试、或者边设计边改，测试就大工作量了。这个时 候测试有这些可以扭转一些局面一一版本验收流程、开发人员给测试人员培训。版本验收：像前面提出的， 设计不全面等，很容易导致只完成需求，破坏了原有功能或流程功能，在拿到版本后，进行初步的重要流

28、 程验收，可以减少很多测试工作量。开发人员讲解培训：这个很好的解决了由于没设计文档导致的测试不 了解内部，被动，另外也是给开发压力，逼他们做单元和集成自测，从中测试也可以提问，不要觉得这是 浪费时间，好处你试了才知道。我很坏，呵呵。C这种情况一般实行Cmmi3之后的企业都很规范。这里我讲下自己的几个方法，更好的理解需求：模 块间逻辑图、数据流向图、需求用例矩阵。模块间逻辑图：其实就usecase图、流程图，只要能让自己摸 清楚模块间的业务联系即可，为自己的业务测试用例做准备。数据流向图：目的是搞清楚，该某块功能涉 及哪些表、存储过程，数据表见关系如何，其实有点像数据库模型的小型版，很多问题在界

29、面上实现了， 但后台sql处理却有错误。例矩阵这个主要是对覆盖率进行校验，其实就是一个execl，针对某个需求点有 哪些用例。这些文档我稍后上转。另外在阅读需求时，多写一些为什么（例如：文档上写着某输入框有默 认值，那你注明下：默认值可以修改吗？）或许你们觉得让测试参加会议，让开发讲解这些有点难，但记住一点：做测试的一定要“主动”。在做功能测试过程中，经常会碰到其他的问题。例如：对于web，所用控件的ie兼容性，标签值显示 格式、长度，提示信息风格、内容，按钮大小，名称等这些，当前项目和开发人员都习惯最后处理。更多 时候测试跟开发还不能达成一致，维护时还有“这是以前开发人员弄的，当前不予修改这

30、些。” 一些通用的 界面要求可以定个标准并维护，这个初步难的话，在项目测试计划里能注明下，并达成统一。这样避免项 目后期，开发人员改动，测试人员由于对工作负责又得全部测试一遍，减少工作量。功能测试，先抓主干，在测分支这是恒定的原则。但如何完善功能测试这个值得讨论，测试前如何分 析需求，编写用例，测试通过准则。测试中确定测试版本，选择用例，测试优先级。项目后期的测试分析， 用例优化等等。第六篇文章本文是InfoQ中文站特邀编辑滕振宇采访了微软亚太研发集团服务器与开发工具事业部的部门经理 Ramesh Rajagopal的作品。在采访中，Ramesh从项目管理、需求管理以及技术架构控制等方面分享了

31、 他所带领Visual Studio软件生命周期管理工具团队使用敏捷方式组织管理大规模软件团队方面的经验。注：本文是依据邮件采访整理而成，为保持现场感，文中使用第一人称指代微软亚太研发集团服务器 与开发工具事业部。微软Office产品组最早引入了功能小组模型，并采用这个模式开发、发布了几个Office版本。之后， 微软其它部门也开始采用，包括Windows部门和开发工具事业部门（后者负责开发Visual Studio系列产 品）。这些部门都拥有数千名工程师，我们需要在具有数百万行代码的代码库上工作，并且多次成功发布 了这些产品，可以说，功能小组模型在项目管理、需求管理、以及技术及构架控制等方面

32、有着很好的扩展 性。首先简单介绍一下我们是如何进行产品计划。进入产品开发前，高层管理团队要确定新版本将带来的 商机（Business Opportunity）。（注意：为了能够确定这些商机，高层管理团队会从在整个部门收集数据 和征询反馈意见。）然后，起草对应这些商机的高层目标。这些目标会被分解为多个用户价值主张（U ser Value Propositions,可以将它们看作是Agile术语中的“epic故事）。接下来它们又会被细分为用户体验（User Experience,可以将他们理解为Agile术语中的“主题，Themes）。功能小组于是会定义实现这些 用户体验的用户故事。实现这一整套用

33、户体验也就是实现了用户价值主张，从而达到商业目标（BusinessObjectives）o我们会为每个产品的发布设计一个计划里程碑（通常情况下一个里程碑需要12个星期）。在这个阶段， 产品负责人会为这个产品发布制定一组要达到的商业目标和目的。接下来每个下属团队（它们是整个产品， 如Visual Studio,开发的一部分）要创建出符合一个或多个商业目标的产品待开发事项（Product Backlog）。下面让我们来看一个具体的例子。对于微软开发工具部门而言，我们的使命是：“让每一个使用微软工 具和平台的软件项目获得成功”。我们每个产品以及其中所包含的功能都是围绕这个使命来开发的。例如， 早期的

34、Visual Studio主要是集中在核心的开发活动上，如：编码、编译和调试。后来我们意识到软件项目 要成功，需要提供对整个开发周期的支持。这直接导致了 Team Foundation Server和Visual Studio ALM（Application Lifecycle Management，软件应用生命周期管理）工具的产生，以支持项目管理、构架、设 计和测试等开发活动。Visual Studio 2010的一个商业目标是：“使软件开发团队采用正确的方法来编写软件”。从这个高层主 题可以创建出几个价值主张。其中一个主张就是：“使软件开发团队通过构架和模型工具来管理软件的复杂 性”。它还

35、可以再进一步细分为：“使软件开发团队能够理解和分析已有的代码”、“使软件开发团队能够验证 它们的代码是否符合指定的构架设计”、“使软件开发团队能够理解他们所在的领域和需求，并设计出期望 的构架”等主题。这些主题分配给各个功能小组。在设计计划里程碑最后阶段，功能小组和产品负责人（负 责某一特定的价值主张）相互协作一起定义出产品待开发事项。它包含了一组划分好优先级的用户故事， 期间会充分听取团队成员的意见和反馈，并最终与产品负责人进行确认。这实质上就是产品的发布计划， 并用它来进行跟踪和管理产品的开发。产品待开发事项中的用户故事也是以工作项的形式保存在TFS上的（TFS 2010的MSF Agile Template定义了用户故事工作项类型）。每个产品待开发事项可能会覆盖多个价值主张，而关于同一个价值主张的主题也