测试宝典之需求至上个人整理汇总转自51testing.docx
《测试宝典之需求至上个人整理汇总转自51testing.docx》由会员分享，可在线阅读，更多相关《测试宝典之需求至上个人整理汇总转自51testing.docx（24页珍藏版）》请在冰豆网上搜索。
测试宝典之需求至上个人整理汇总转自51testing
测试宝典之需求至上
（转自51testing）
如何做好需求分析及变更管理
业务员与客户进行的沟通，撰写需求分析报告是项目展开的基础。
项目是以客户的需求为中心，而不是为技术而迁就需求。
本章包括以下内容：
一.让客户畅所欲言，罗列出所有的需求
二.透过现象分析潜在的需求
三.利用自然的语言描述项目模型
四.利用示意图和图表将用户的需求表现出来。
五.什么人要看需求分析报告？
六.建立需求变更日志，制作新版本的需求分析报告。
七.本阶段重点工作角色
八.总结
一：
让客户畅所欲言，罗列出所有的需求
让用户将所有的想法尽可能的阐述清楚，并把所有的要求罗列出来，不要遗漏。
这时候不应该害怕“勾引”起客户的潜在需求而增加设计开发的工作量，从而被今后客户无止境的变更拖入泥潭，直接明白地跟客户把问题和要求一条条地列出来，把条理、归纳、分析先都扔到一边去，将用户最原始、最完整的要求准确地记录下来就完成了第一步的工作。
很明显，假如客户的需求做的都不完整，随时可能会产生意想之外的变更，甚至这个变更会破坏已经做的模型及结构，那么这个项目从开始就注定了会失败；比如站点所有的功能都实现了，本地测试起来也没有什么问题了，但是你却不知道客户的系统是要承受每天100万独立IP的访问，而你原来想当然的以为了不起就是1万独立IP访问的访问流量，稍微有经验的开发人员都会明白这样的设计是个灾难，无论是应用服务器、数据库还是程序全部要重新开发！
二：
透过现象分析潜在的需求
很多情况下客户并非专业人士，在他们滔滔不绝的描述中不能指望他们帮助我们整理出重点和技术难关，这需要我们去为客户进行分析、归纳和整理，尤其是客户谈的不多却又是技术上实现难度和强度很高的地方特别值得注意。
客户往往对需求的概念是非常模糊的，大多时候给出的需求都是笼统而且尺度难以控制的，这就要求业务人员在倾听了客户的详细说明以后，帮助客户进行整理和分析，同时预测客户在开发过程中变更及今后应用中可能进行修改升级的潜在需求。
比如在为客户设计办公自动化系统的时候，也许就要为客户预留将来与他们的业务单位进行交互的通道；在设计邮件系统的时候要考虑可能会需要广告管理服务器；设计网络电子商店时今后增加库存产品进销存统计分析等等；限于时间财力的考虑，客户通常能够接受分阶段实施的开发过程，在需求分析时，提早为客户设想到今后的需求变更除了使项目开发更加顺利以外，也为今后业务的进一步深入打下了更好的基础。
笔者曾负责一个大型新闻网站的设计，当客户拿着将近五十页厚的一本设计要求报告时，我发现有四十页的内容对程序开发来说都是重复的，而在其中一页的角落却画了个“搜索其他网站相关新闻”的按钮，并且没有做任何说明，仅仅这10个字所完成的工作量完全顶的上其他整整四十页重复赘述所做的工作，客户完全不知道这个要求引发的问题实际就是一个搜索引擎的开发，通过协商，客人同意了修改成站内搜索的引擎。
三：
利用自然的语言描述项目模型
在业务员与客户进行沟通和调查时撰写的需求分析，尽可能用自然的语言进行描述，虽然客户的水平和资历有所不同，但是最自然的描述能够使项目开发的各个成员都能清楚地理解需求含义，不至于在理解上产生偏差。
对客户而言，这样的模型描述最接近真实，容易参与修订，并能以此为测试和验收的依据。
请比较以下两份关于需求的描述，
“用户在访问首页的时候可以在点击'客户通道'按钮，弹出填写'用户名'和'密码'的窗口，输入正确后在新窗口打开客户通道的首页，在该页显示所有可操作的功能的导航条和最新的导读新闻链接列表”
“站点分为公开和加密两种状态，通过身份验证机制使特有的用户可以访问到加密信息，并提供不同于普通用户的功能。
”
前段描述我们就很容易想象的出来设计完成的网站是什么样子，而后一段的描述可能会做出无数不同的版本，造成对需求理解的歧意。
四：
利用示意图和图表将用户的需求表现出来。
需求分析无论文字上怎么样表述都还是抽象的，对客户而言理解毕竟是困难的，将基本确定的需求制作出示意图是最直观有效的。
制作示意图可以有很多种方式，用PowerPoint或Visio制作流程示意，用Html文档制作界面示意都是可行的，最简单利用画图和Word表格方式也完全可以，关键是利用示意图将客户的需求和即将开始设计的系统体现起来，在进行系统分析和程序开发之前，双方对今后要完成的产品就能够有直观的认识，换言之，就是在产品还没有真正进入开发阶段的时候，双方就对工作的结果达成统一的意见，这将大大地减轻需求变更所带来的困扰，同时客户更容易地参与到项目的开发过程，保证项目往正确的方向进行。
在RUP中有这样的描述：
“利用电影、卡通、图片、表格和动画片等制作示意图开始，告诉我们用户是谁，要发生什么事情，如何发生。
以用户友好的方式帮助收集并改进用户需求。
鼓励更有创造性、更加创新的设计解决方案。
鼓励团队复审，并避免所有人都不希望出现的特征。
确保以可理解、直观的方式实施特征。
使访谈过程变得轻松，避免出现访谈没有结果的现象。
简单地说，制作示意图就是使用工具向用户（主角）说明（有时是动画演示）系统如何适应组织的需要，并表明系统将如何运转。
协调员将初始示意板展示给小组，小组成员提供意见。
之后，在举办研讨班期间，示意板也进行”实时“演进。
所以，您需要一种可以轻松更改示意板的画图工具。
为了避免分散注意力，一般最好使用简单的工具，比如图表、白板或PowerPoint。
”
五：
什么人要看需求分析报告
项目经理、系统分析员、开发经理、交互设计师、测试人员、文档人员包括客户代表都应该看需求分析，并进行共同的讨论，达成一致的意见。
我们经常会遇到业务人员辛辛苦苦谈下来的项目，对开发人员来说却是难以实现的，而技术人员设计的产品却常常得不到客户的认可，甚至发生纠纷，因此参与项目开发的人员都应该对这份需求有统一清晰的认识，并根据自己的工作对需求提出意见，通过与客户的沟通修订，最终确定项目实现的目标。
例如：
项目经理通过需求分析才能组建所需要的团队包括配置工作环境，制定开发周期。
开发周期的限制和功能上的要求可能会影响到程序员采用什么样的语言和工具进行编写；
操作用户的技能水平将影响到交互设计师进行前台设计时做到什么样的精度；
界面设计人员根据项目的性质和定位确定表现方式。
测试人员了解测试环境和条件后才能对项目质量进行跟踪和检测；
通过下表，我们可以看的出不同角色根据需求的变更所进行的工作流程：
六：
建立需求变更日志，制作新版本的需求分析报告
尽管我们费了许多功夫在需求分析进行了最大可能的努力，但几乎可以肯定的是，这份需求分析在开发过程中一定会发生变化，也许是出自客户的遗漏，也可能是在开发过程中被激发出来的，这种变更有时是如此的频繁和琐碎，以至于往往不能将变更及时反馈到项目的各个角色中，那么做好需求变更日志就显得非常重要。
在需求分析后面附上变更日志，并将修改后的需求分析制作成新版本，保留每次更改过的版本，而不是覆盖，这样就比较容易地跟踪到需求变更过程中所带来的工作调整。
在新版本的需求分析中，将变更多部分用特殊方式表明出来，并在日志中记录变更多重的明细。
关于需求分析和变更管理可以参照下图示意：
七：
本阶段重点工作角色
在需求分析和变更管理的过程中，工作量最大的角色为客户代表、业务员和项目经理。
客户代表提出需求，业务员帮助整理和分析，项目经理对整个项目进行评估。
在实际工作中，很多项目失败的起因都和需求分析有关。
客户代表和业务员通常并非从事技术开发的专业人员，在讨论需求的时候往往对项目的技术难度、工作量、时间进度把握不准确，这时候需要项目经理或技术人员进行参谋。
为了降低项目的风险，提高工作效率，有必要设计规范的需求管理计划书，帮助客户代表和业务员更好的完成任务。
以下提供一份需求管理计划的模板可作为参考：
八：
总结
根据笔者的经验，要尽快做好需求分析掌握以下要点，也许能事半功倍：
仔细聆听，罗列客户的所有要求；
将需求进行分析，确认可操作的系统模型；
利用最自然的语言将系统进行描述，使每个开发人员不会产生歧意；
迅速确定网站的用户角色；
比如访客、会员、重要客户、前台管理员、网站管理员、业务员等；
分析确定每个角色的权限及可操作的功能；
比如会员可以查看特别信息、修改个人信息、退出登陆等；
前台管理员能够登录管理系统，能够发布编辑修改信息，能够审查会员资格等；
网站管理员可以更改栏目、修改网站界面等；
制作流程图和示意图将需求表现出来；
让客户参与到示意图的设计中，及时正确的反应出需求变更。
制作需求变更日志，保留升级版本，通过版本控制进行需求管理；
通过需求《管理计划书》使每个参与人员看到共同的努力目标
需求管理：
需求的结构
在各类方法论和标准中，都大量提到了需求如何开发/描述/跟踪等内容，唯独关于需求结构的描述甚少，本文尝试比较几种需求结构的优劣及应用环境，供读者使用。
万事都不是绝对的，切勿生搬硬套。
用户需求-产品需求型
--------------------------------------------------------------------------------
这个是做CMMI的企业最熟悉的，因为RD过程域里边正好有着两样东西。
这种表述方式适合“产品-项目型”项目，也就是说企业整体上有一个成型的产品，并通过定制这个产品来销售给特定的客户。
简介：
用户需求就是用户需要用我们的软件来做什么，常常包含很多非软件功能的描述，比如（银行软件）“在开户时，用户凭身份证，身份证复印件，开户申请单（签字确认）可开户。
”看似很简单，却有几个问题：
复印件是一张纸，还是想用联机的摄像头拍摄一个？
（航空安检就是这样的）开户申请单，是一张纸还是指屏幕上的一个表单？
如果是表单，应该打印出来签字吧？
产品需求就解答上面的问题的：
这个（些）客户需求需要我们产品具体做什么呢？
几个明显地是应该选择这种需求结构的判定条件：
1.几乎每次销售都需要二次开发才能完成
2.几乎每个客户都是大客户（因此才值得做二次开发）
3.我能把客户分类并描述他们的业务特点，以及为什么购买我的产品
使用这种需求结构应该注意的地方：
1.要善于让多个用户需求复用一个产品需求
2.要善于从多个重复的用户需求中提炼并产品化产品需求
常见问题：
1.这种方法没有颗粒度的概念，需要自己把握
2.这种方法没有条目化的概念，很多企业理解为只要编写《用户需求说明书》《产品需求说明书》即可
更详细的内部结构：
1.客户需求和产品需求可能各自还包含若干个层次
成功要诀：
1.正确处理对不同级别的需求，典型地（不要生搬硬套）：
若一个需求仅来自于单个客户，应“轻视”之，只保留简单文档并进行简单测试，但要记录“有人要了这个需求”以便复用或提炼
若一个需求被提炼为产品需求，应建立基本的需求和设计文档及适当的测试手段。
若一个需求被列入产品核心模块（如工作流/信息流/组织结构等可复用内容），则应该建立健全的文档供5～10年内查阅，并确保自动化测试（每日冒烟测试和版本发布测试）
文件-操作型
--------------------------------------------------------------------------------
即基于功能点分析进行组织，特别适合于需要招标-报价的项目。
简介：
所谓文件，就是一组用户可以理解的逻辑数据，比如在“会议管理系统”中，会议/会议室/参加人都是文件。
在OA/MIS等数据库系统众所，一个文件一般对应若干个物理表。
所谓操作，就是围绕某个文件展开的操作，比如会议的计划/通知/召开/总结/上传附件等；会议室的增加/修改/预订等；参加人的增加/删除/通知/统计等。
操作必须是“基本过程”，也就是说包含了所有分支/异常等，以最终操作者达成操作意图为终点。
文件和操作对应若干功能点及造价，文件15（外部）或35点（内部），操作4～5点不等，每点对应1.5人天左右大约1000多元成本。
此方法比较新，已有配套的培训教程，包括如何利用功能来计算工作量/成本/工期，并有配套免费工具。
以下产品与之匹配：
当需要向甲方竞标和报价的时候，用次方法可以迅速准确地计算价格，且双方均可理解。
几个明显地是应该选择这种需求结构的判定条件：
1.政府行业
2.需要向甲方报价
3.这个系统是一个以数据和操作的数量为主要因素决定产品规模进而影响报价的（比如类似OA）
使用这种需求结构应该注意的地方：
1.文件和操作的概念是有判定标准的，不要望文生义
常见问题：
1.这种表达方式适合表达要做什么，但无法表达“做到什么程度”
更详细的内部结构：
1.客户需求和产品需求可能各自还包含若干个层次
成功要诀：
1.此方法的目的在于向客户确认是否“有必要做”成这个样子，每个功能的增加将带来造价的增加。
如果用别的方法描述需求，客户总是希望做得更全更好，但这个方法可以避免。
场景-故事型
--------------------------------------------------------------------------------
敏捷中非常推崇的方法，但多数敏捷方法只提到了故事，而较少谈及场景。
即使不使用敏捷，也可以使用这种方法。
简介：
故事只有一句话，但却很好地表达了几个重要内容，比如（银行软件）“三次密码错误锁定”这个功能会写成“作为用户，我希望在取款时尝试密码第三次错误后锁定账号，以防止有人恶意尝试我的帐号密码。
”角色-操作-目标是故事中最重要的三个要素。
很多传统的需求描述方法文字冗长，却未能覆盖这三个要点。
场景呢，则是某种应用环境，围绕场景可以发生若干故事。
比如“取款”就是一种场景，包括了密码正确正常取款/密码可以重试两次/三次密码锁定等若干故事。
以下产品与之匹配：
有一定的创意，很希望通过创意生成故事，进而增进产品的功能。
几个明显地是应该选择这种需求结构的判定条件：
1.产品的吸引力不在于功能多少（否则应该用上面的文件-操作型），而是实现到何种程度（故事中的“目标”）
2.针对一种场景，可以想象很多故事以增进产品价值（简直是无穷的，因此需要排列优先级）
使用这种需求结构应该注意的地方：
1.故事必须是一个能/也必须整体交付的功能，这是故事的一个天然颗粒度把握方法。
常见问题：
1.故事写得不好。
问题很多，买本书看看：
用户故事与敏捷方法http：
//www.china-
更详细的内部结构：
1.很多场景各自还包含若干个层次
成功要诀：
1.一定要面向用户价值描述用户故事，否则经常无法达到预期效果。
比如一款杀毒软件，每次安装其他软件时，需要多次修改注册表和硬盘，因此弹出的拦截界面很多；尽管可以选择“相同操作不再提醒”，但仍然弹出。
因为用户理解的“相同操作”（同一个软件的安装过程中）和程序员理解的“相同操作”（同一个注册表项的修改）不同。
用例型
UML的方法。
没好好学过UML，所以也不太清楚。
只记得非常重要的一句话：
只描述那些对客户有价值的用例，登录/修改密码/XXX都别写（潘家宇说的）。
从这一点上看，UML的组织方法是面向开发团队的。
想想也是，别看都是图形化的，UML可真不是写给客户看的，包括UC图。
而且UC图下面马上接上的是Sequence等技术图，如果一个UC下面没有或者不必要画那些技术图，这个UC也就可以消失了。
如何进行测试需求分析
测试需求分析流程
测试需求分析要点
要素分析
1、界面元素是否满足自定义的质量标准或行业通行标准或常用使用标准等
2、公司部门制定的Web元素描述规范
数据分析
1、输入域的数据
2、已显数据的来源
3、数据的输出
4、数据关联
流程分析
1、常用的或规定的业务流程
2、各业务流程分支的遍历
3、明确规定不可使用的业务流程
4、没有明确规定但是应该不可以执行的业务流程
功能交互分析
1、结合数据分析，流程分析，但是侧重点是功能实现。
2、操作入口明确、合理
“操作入口”，指的是产品内部不同模块之间的转接元素，例如在Web产品中，按钮控件、输入框、文字链等都属于操作入口；“明确”指的是入口的视觉感是清晰的、可识别的；“合理”是指入口的出现是符合用户操作逻辑的，适时的。
3、实现功能的步骤简洁明确
“实现功能的步骤”指的是系统界面上实现业务功能的实际操作步骤，例如：
注册用户时，输入优惠代码，点击“应用”按钮，再点击“提交”。
“简洁明确”是指步骤符合实际业务逻辑并足够简洁，并且不会产生步骤上的混乱。
4、交互执行的结果正确完整
按系统操作步骤执行交互响应后的界面结果或其他功能的前置条件。
用户场景分析
1、现在的软件几乎都是由事件触发来控制流程的，事件触发时的情景便形成了场景，而统一事件不同的触发顺序和处理结果就行成了事件流。
2、模拟实际业务中形成某一事件的场景，转变成系统中该事件触发时的情景。
从而检验该场景的正确性。
质量模型分析
1、度量需求定义的指标
1）每条用户需求的定义都正确反映了用户的要求
2）在第一层基础上的完整性和一致性要求，即用户的所有要求都有定义且不能相互矛盾
2、一套结构化的根据指标对需求定义进行度量的方法
过程方法分析
1、组织结构关系分析
2、业务流程展开模型
3、任务需求分析矩阵
测试需求分析资料收集
最近开始研究测试需求分析，得到曹老师指点一、二，在雪大嫂、导演等众多测友的大力支持下演绎了如下理论和心得：
一、测试需求分析定义：
测试需求提供一个测试应用程序所必须的详细的描述。
一个测试需求是：
有利于开发和测试
帮助定义测试对象和测试范围
设置明确的团队目标
发现需求中不完善和不足地方，进行完善以节省时间和投入
便于需求基线化和跟踪业务需求变更
一条有用的测试需求总是：
惟一的
精确的
有边界的
可测试的
举例：
系统主要事务的响应时间满足系统要求，为不符合要求的测试需求；
测试需求：
在1G内存和1.73兆主频的计算机上在25个并发用户执行插入、更新和删除操作时端到端的响应时间在3秒时间内。
系统功能测试需求分类
1、业务功能测试需求
2、可靠性测试需求
3、安全性测试需求
4、易用性测试需求
5、可移植性测试需求
6、可维护性测试需求
上面对于测试需求的分类是依据软件质量模型而定的，对于效率我们放在性能测试需求中，而其他5种特性都应归入功能测试范畴。
在这里，我们把安全性单独提出来，目的是强调安全性测试的重要性。
尤其对于金融行业系统，其安全性是至关重要的。
二、提取测试需求
测试工作的依据首先是业务需求规格说明书，所以应该首先提取测试需求，把需求从业务需求中提取出来，再把业务需求分解为测试需求，每个业务需求对应一个或多个测试需求。
在分析测试需求和设计测试用例时，以需求规格说明书为依据，以业务功能为中心，以质量模型中的各子特性为出发点，同时深刻理解业务规则和隐式需求，通过与客户深入沟通，明确测试范围和质量目标，达到测试分析和设计全面、无遗漏。
什么是隐式需求呢？
从质量保证的定义：
产品或服务满足显示或隐含需求能力的功能和特性总和。
所以在提取测试需求时，除了关注显式提出的业务需求外，我们也应该关注隐式的需求。
这些隐式需求包括：
1、用户隐式的需求。
例如：
行业规则、业务规则、原来系统已经实现约定俗成的操作或功能等。
这些需求设计人员往往认为研发团队会知道这些规则，所以没有在需求中显示描述。
这些地方由于没有明确约定，又缺少沟通，往往成为最容易出现缺陷的地方，不容忽视。
2、计算机领域的规范或习惯。
这些方面是很难写到业务需求中的，业务需求往往是文字描述，很难准确描述系统展示界面，例如，如果某个输入我有限个元素，则应该用列表框或选择框控件实现，而用编辑框实现则要在输入中做很多判断，不断增加编程工作量，也增加测试工作量，同时给用户带来不便。
3、客户认为我们应该理解或在需求中遗漏的需求。
例如，认为我们理解金融行业的会计规则，但是如果不在测试需求明确说明，则由于测试工程师没有金融行业会计方面的测试经验而忘记测试。
4、业务需求编写人员受计算机技术的能力。
不知道性能指标如何描述或描述不准确。
需要测试团队协助科技人员和业务人员把描述不准确、正确或隐含的性能指标需求显示描述清晰。
通过多个项目上线后的问题反馈来看，原因主要是：
1、对实际业务中可能发生的情况或者说场景考虑不足。
例如：
已经到了交易闭市时间，例如5点整闭市，而在柜面在接近5点时发送了一个请求操作，服务器接收到该请求后，把这个操作请求发送到其他系统（交易所系统）请求进行处理，而这个过程中，已经到5点整（实际生产系统中，各服务器系统的时间并非完全同步），而此时服务器已经关闭了交易，造成无法接收请求处理的操作结果，而此时在交易所系统已经做了记录操作成功，但由于银行服务器没有接收到返回，造成产生了单边交易。
2、用户违反操作规则或业务规则操作。
虽然在测试中测试人员会考虑很多异常操作和违反业务规则的情况，但往往在测试阶段由于各种各样的原因没有进行测试（例如：
缺少测试设备，在测试中没有使用POS机，而通过软件界面输入到系统与通过POS机设备输入可能存在差。
）违反规则的例子：
更换银行卡问题。
某客户在北京分行开户，后在上海办理了一个新的银行卡，用户要把交易帐户关联的交易帐户转到上海卡上，在交易中出现问题，而系统需求中说明只能是在本分行管辖区域内更换银行卡，而不能跨地域更换。
3、意识上的问题或沟通不足导致的问题。
有时，我们测试人员会认为某些事情应该是这样，应该已经处理了，应该是客户成熟的东西等等，实际上并不是这样。
在测试中，柜面和网银上输入借记卡卡号为11位，而实际上网银输入应该为18位。
测试中，客户提供我们的卡号也都是从核心系统中搜索到的，也都是11位。
实际上借记卡应该有18位，前面6位为银行固定号码，最后一位为检验位，中间11位才是银行卡号。
举一个意识问题导致的缺陷，对于银行网银上的密码加密，因为客户的网银早就有系统在运营，而被测试系统部署已经运营的网银中，测试人员往往认为网银密码加密这些应该是客户使用的是成熟的算法，不用再测试。
测试实际上不是这样。
测试需求的表示
测试需求可以保存在任何文档中，但是我们在项目中往往是通过测试管理工具进行管理，这样便于进行跟踪管理。
下面我们本文结合目前最流行的测试管理工具HPQualityCenter（后面简称QC）工具进行讲解。
（下略）
升级会员 