下载掌阅APP，畅读海量书库
立即打开
测试的目的应该是验证需求，Bug（预期结果与实际结果之间的差别，即缺陷）是这个过程中的产品而非目标。测试人员应该像工兵一样，在大部队（客户）预期前进的方向上探雷、扫雷，而不需要去关心那些根本没有人会去碰的地雷。衡量一个测试人员应该去衡量他测试了多少需求（测试工作量）。许多测试团队在需求不清晰的情况下，就进行测试，这简直是事倍功半。往往到最后还要返工重来。所以对于测试工程师来说，测试需求是永远放在第一位的。
1.1 从需求的含混性说到软件测试的目的
小白 大鸟啊，我郁闷得很啊。
大鸟 咋啦？
小白 我们公司参与了一个大项目。当时市场人员把项目签下来的时候，项目组是欢天喜地。项目做了一年多，到了交付的时候，用户却很不满意，当初说好的需求，好多都变了卦。
用户是上帝，最关键的是如果收不到后面的钱，那就算白干了。公司要求项目组加班加点进行修改。我们测试部门也不得不一遍一遍地做着重复劳动，搞得大家是怨声载道。做市场的和做开发的相互指责，然后，大家又一起骂客户刻薄。公司里面弥漫着灰心丧气的气氛。
大鸟 你们是怎么和客户谈需求的？
小白 市场人员先谈单，估计人家需要做什么。然后，我们这边派一个搞技术的人员过去了解需求，拿一些对方的表格和笔记回来。
大鸟 你们去询问需求，然后做了一个文档。你们头脑里的东西，跟客户要的东西，其实是不一样的。但是，大家都认为这样白纸黑字，基本上是一样的。但这里面其实是有差异的。这种差异，有时影响不大，但有时，是致命的。毕竟，文档不是最终的实物。客户永远认为，他是把需求给你讲清楚了的，如果你做不到，不是他的责任。而且，你要记住一点， 用户只有在见到或使用过实物的时候，他才知道他其实要的是什么东西 。否则，如果研发人员没搞清需求就闷头做事，迟早项目会变成“包工队的故事”。
场景漫画：包工队的故事
甲 ：说一个包工队接一好活儿，盖一个 70 多米高的大烟囱！
乙 ：还真不错！
甲 ：起早贪黑把活干完了，人家来一验收，死活不给工钱，还叮当五四被打了一顿！
乙 ：为啥啊，质量不行？
甲 ：把图纸拿倒了，人家让挖口井！
小白 “ 用户只有在见到或使用过实物的时候，他才知道他其实要的是什么东西 。”这句话，我严重同意。可是，要按你的说法，那用户和我们之间，就永远不可能存在真正意义上的沟通！那不成了虚无主义了吗？”
大鸟 如果你不了解客户的业务需求，或者不真正熟悉其行业规则的时候，你需要更严谨的方式来询问和确定需求。否则，那些落在纸上的文字和文字之间，埋藏着数也数不完的陷阱。需求阶段过于匆忙，就会出问题。比如说，客户忙，随便给你找一个表格，到最后就是无尽的麻烦。
小白 客户不都是这样吗？有何问题呢？
大鸟 客户没有问题，而是去问的人要格外小心了。他要搞清楚客户的背景、立场——客户关注自己想要的结果，但不同人关注的东西不同。有些客户希望不要给他们增加过多的工作任务，越傻瓜越省事越好；有些用户关心新系统的性能是否可靠，速度够不够快；而系统管理员，关心的技术和安全。总之，每个人都各怀心事。需求是多种多样的，所以对于用户所提出来的需求都要仔细记录，认真掂量。
小白 如何掂量？
大鸟 多问自己几个问题。
（1）这是谁的问题？谁是顾客？谁必须被取悦？（Who的问题）
（2）他们的问题是什么？来自于哪些方面？基于什么？有什么特殊性？（What和Why的问题）
（3）哪些问题是一定要解决的？哪些可以不解决？哪些用户根本不在乎？（Scope的问题）
（4）哪些问题是比较简单的？哪些是比较复杂的？简单的要不要合并？复杂的如何分解？（拆分和合并的问题）
很多人去做需求，以为拿着本子记下来就好了。其实，很多时候，都没那么简单。觉得简单，是因为很多人认为从技术上设计这类的软件，简直是小菜一碟。但是，他没有想到的是，很多问题只是冰山一角，有些问题暗流汹涌，有些问题前后矛盾，有些问题不可实现。用户需求暗藏着一个个陷阱和地雷。
场景：两个圆的故事
甲用铅笔在纸上画了两个圈。问乙：“你说，这是啥？”
乙说：“两个圆。”
甲摇摇头：“是两个鸡蛋。”
乙觉得甲很无聊，不耐烦地说：“好吧，就算两个鸡蛋。”
甲摇摇头：“不是，这不是鸡蛋，这是两个乒乓球。”
乙不知甲在暗示什么，他在听。
甲说：“我看到的东西，和你看到的东西，不一样。但是，在纸上，画的是同样的两个圈。”
小白 你上面所说的这些东西，不是市场人员或者需求分析人员应该考虑的问题吗？和测试Team有什么关系呢？
大鸟 那我问你，你现在做软件测试，测试的目的是什么？
小白 让我想想。软件测试的目的是尽可能发现并改正被测试软件中的 Bug（缺陷），提高软件的可靠性。
大鸟 这个定义听起来很正确，但用它来指导测试会带来很多问题。比如有的公司，用发现的Bug的数量来衡量测试人员的业绩，其结果如何呢？其一，有一些不够敬业的测试人员会找出一些无关痛痒的Bug来充数，结果许多时间会被浪费在这些无关痛痒的Bug上；其二，测试人员会花很大力气设计一些复杂的测试用力去发现一些迄今尚未发现的缺陷，而不关心这些缺陷在实际用户的使用过程当中是否会发生，从而浪费了大量的宝贵时间。究其根源，就是因为对测试目的的这种错误理解造成的。为什么这么说呢？因为软件里Bug的数量是无法估计的，所以如果测试的目的是为了找 Bug，那么测试工作将变成一项无法完成也无法衡量进度而且部分无效的工作（因为有些 Bug 在实际的运行过程当中根本不会发生）。
小白 唔……那你看这样说对不对：测试的目的就是为了保证软件质量？
大鸟 这个定义也是看似正确，但实际上，混淆了测试和质量保证工作的边界。软件质量要素有很多，包括可理解性（Understandability）、简洁性（Conciseness）、可移植性（Portability）、一致性（Consistency）、可维护性（Maintainability）、可测量性（Testability）、易用性（Usability）、结构（Structure）、效率（Efficiency）、安全性（Security）等，所以，软件质量保证和测试的关注点其实是不同的。假如说，你保证了软件安全性的高质量，但是用户压根就不关心安全性，那你不是白测吗？
小白 那么测试的目的应该是什么呢？
大鸟 IEEE 对软件测试的定义是：“使用人工或自动手段来运行或测定某个系统的过程，其目的在于检验它是否满足规定的需求或是弄清预期结果与实际结果之间的差别。”所以，简言之，测试的目的应该是验证需求，Bug（预期结果与实际结果之间的差别，即缺陷）是这个过程中的产品而非目标。测试人员应该像工兵一样，在大部队（客户）预期前进的方向上探雷、扫雷，而不需要去关心那些根本没有人会去碰的地雷。衡量一个测试人员应该去衡量他/她测试了多少需求（测试工作量）。我看到许多测试团队在需求不清晰的情况下，就进行测试，这简直是事倍功半。往往到最后还要返工重来。所以对于我们 QA（测试工程师）来说，测试需求是永远放在第一位的。
小白 我一直以为程序完成后了，才开始软件测试。
大鸟 我一直反对软件测试仅存在于程序完成之后。如果只将程序设计阶段后的阶段称之为软件测试的话，需求阶段和设计阶段的缺陷产生的放大效应会加大。这非常不利于保证软件质量。需求缺陷、设计缺陷也是软件缺陷，记住“软件缺陷具有生育能力”。软件测试应该跨越整个软件开发流程。需求测试和设计测试也可以算作软件测试的一种。软件测试应该是一个泛型概念，涵盖整个软件生命周期，这样才能确保周期中的每个阶段经得起考验。
1.2 需求的定义与分类
小白 我明白了，正因为测试的目的是为了验证需求，所以测试部门就该和研发、市场、技术等支持部门通力合作，搞清楚需求到底是什么？大鸟，到底需求的定义是什么呢？
大鸟 我认为需求是这样的：需求是指明了必须实现什么的规格说明。它描述了系统的行为、特性或属性，以及在开发过程中对系统的约束。 用户（提出）的需求是用户个人认为在对自身目标的解决方案中，自己不能或者不愿完成的部分。
因为不愿且不能，所以用户的目标可能是含混的、模糊的。好多产品只是有一个潜在的客户群，产品做出来后用户才有反馈。
小白 如何减少需求含混性？
大鸟 当我们发现存在比较大的歧义时，自己通过交流的方式来降低这种歧义。开始的时候，我们会有一个初步的文档。但是在合同签下来后，会有一个相对时间较长的需求的再确认过程，我们会和客户一起来走一个流程。然后，我们会把大家商业需求的结果，转换成最终的设计，用PPT把用户故事（包括操作界面和业务流程）都模拟出来，让客户有身临其境的感觉。在正式开工以前，给客户汇报。到此为止，我们并不做任何真正的编码工作。
小白 这样做，还是很花时间，效果如何呢？
大鸟 相对于搞错了需求，重新开发，这是最合算的了。很多人都不愿意这样做，最后人都跑光了。知道项目经理最痛苦的事情是什么吗？项目没完人跑光了（你知道项目经理最最痛苦的事情又是什么吗？人在，项目不让你做了！这种事情，也有不少啊）。
小白 那么，如何获得、采集需求？
大鸟 搞清楚用户需求是一个长期不断地获取和澄清的过程。对项目不同阶段所要求的需求粒度（需求分解细化的程度）也各不相同。在项目初始的立项阶段，需求采集的主体是市场人员，市场人员从客户那里得到一些直接的或者潜在的需求，这些需求或为全新的，或为对现有产品的改进期望。市场人员得到此类需求后，及时做初步分析，并书面反馈给PM（项目经理）。这时市场人员是需求的主要来源，但并不是唯一的来源，技术支持人员、中间商、潜在客户群都会给出贡献。我们把立项阶段得到的需求叫业务需求。
小白 业务需求？
大鸟 业务需求反映的是企业/组织对软件系统的 高层次目标。 业务需求确定后会得到一个叫做 业务愿景 的东西，其实就是项目成功后会是个什么样子，并在涉众范围内达成一致。而业务需求的确定对之后的用户需求和软件需求起了限定作用，业务需求就是需求过程的宪法，任何需求不得与之相违背。比如说：研发一台电视机，为用户提供看电视的服务。请注意，是服务，是以外部的眼光，全局性地看这一需要实现的东西。
小白 高层次目标？
大鸟 对，就是高层次的。咱们中国有一个成语“纲举目张”，纲是鱼网上的总绳，比喻事物的主干部分；目是指网眼，比喻事物的从属部分。纲举目张是指抓住事物的关键，就可以带动其他环节。在这里面，业务需求就是那个纲，指用户需求的大方向、大框架，它的输出结果就是MRD，即市场需求书（Market Requirement Document），或者有的公司称其为商业需求书。
小白 懂了，那然后呢？
大鸟 然后我们要在业务需求的基础上进行用户访谈、调查，对用户使用的场景进行整理，从而建立用户角度的需求。用户需求必须能够体现软件系统将给用户带来的业务价值，或用户要求系统必须能完成的任务，即用户能使用系统来做些什么。比如说，为了让用户能够看到电视节目，需要做到：接受电视信号、显示到屏幕、可以换台等。这些内容都是为业务需求服务的，也是为了能够看到电视节目所必不可少的，即用户需求是业务需求的深入和细化。在这个阶段，我们需要将MRD中笼统的“概念化”需求转化为可实现的“专业化”细则，将MRD中的内容进行指标化和技术化。此外我们还要挖掘出其中的隐性需求，以便后续引导用户的兴趣和投资点。
此阶段的输出结果是PRD，即产品需求文档（Product Requirement Document），着重在论述“ 要做什么 ”的问题。此文档重点体现产品的功能和各项指标的说明，分别是功能要求、开发要求、兼容性要求、性能要求、扩展要求、产品文档要求、产品外观要求、产品发布要求、产品支持和培训要求、产品其他要求等。其中，在功能要求当中，应该重视主要Feature（特性）的重点描述。