需求不明确/没有的情况下如何做测试

上一篇 / 下一篇 2009-01-13 20:58:12

摘要：本文针对需求不明确的情况下如何做测试，列举了3个步骤。这些步骤，都是实际经验的总结。利用这些步骤，可以在需求不明确，或是没有需求的情况下，进行必要的测试工作。但是，这些都是不规范的方法。需求不明确，或是根本没有需求，这本身就是一件不规范的事情，无论是开发人员，还是测试人员都无法在不规范的环境中，做规范的事情。但是工作要继续，不能因为某些障碍而停止。这时，请参考每一个步骤，尽可能地完成测试工作。
        关键字：需求；需求规格；测试需求；文档；猜测；沟通
        软件生命周期中，需求是整个周期的源头。良好的开端，是成功的一半。需求的重要性自然不言而喻。但是，在很多企业中，并没有对需求引起足够的重视。原因并不是PM们不知道需求的重要性，而是商业竞争中不得不裁剪某些看似不能获得很大利益的步骤。
        什么是需求？很多PM和开发人员都未必真正考虑过这个问题。IEEE对需求有以下两种定义的方式。
        1. 解决用户问题或达到用户目标需要具备的条件或能力
        2. 遵守合同、协议、规范或其他要求
        然后用规范的文档描述出来，就成了我们熟悉的SRS。
        我们常说的需求，其实并不是我们认为的SRS。SRS应该叫做需求规格说明书。那需求是什么呢？与需求规格有什么区别？
        需求：对要实现的功能的粗略描述
        需求规格：对需求的精确定义
        我们知道，在软件开发过程中，只有得知了需求的精确定义，才能开展工作。比如功能方面，编辑框能支持多少位字符。性能方面，时间和容量规定等。当然还包含其他非功能，性能方面的定义。
        除了以上所说的需求，对于测试人员，还必须有测试需求。这个环节，很少有企业会重视。测试需求分为2方面：
        需要测试哪些方面
        软件是否可测，需要增加哪些开发需求
        其中第一条，很多企业都列到了测试计划中，这也可以，没有规定一定要放到哪个文档里。但是对于第二条，可以说几乎没有多少企业去做。
        接下来，在没有明确需求，需求规格，测试需求的情况下，我们怎么去做测试呢？现在很多企业，其实就是在这种情况下做项目的。
        当测试人员接手一个项目后，第一件事情一定是想了解这个系统的功能，背景，架构。于是，马上就会想得到需求文档。但结果往往是失望的，根本没有文档，或者文档根本不具备参考价值。此时不必太失望，因为这种情况实在是太常见啦。这时，请试着从以下几个步骤着手。
        查阅文档：文档是最具权威的，也是记忆最长久的。有时，我们的项目可能是在原有产品的基础上，进行版本升级。这时，先去找找，有没有原有版本留下的需求，或者是用户手册等文档。从这些文档中，了解项目的背景，系统的基本功能。这对了解新项目是有很大好处的。并且，在产品升级的项目中，验证老版本的功能在新版本中是否正常，也是一个必要的工作。可以先参考老版本的相关文档，设计新版本中的用例。
        也有时，我们的项目是一个行业项目，比如金融项目。我们可以参考一些行业知识的书籍，文档。这对理解系统也有很大的好处。
        实在没有文档，那只好暂时跳过这一步骤了。
        在进入下一步骤之前，你可能得到了一些相关文档，也可能什么也没得到。无论如何，你可能对系统已经有了一些了解。这时，请记录下来，写成文档。无论是对自己，还是对别人，在以后都可能极有参考价值。试想一下，如果前人已经给你留下了这些文档，你是否可以轻松很多？还要注意及时更新你的文档。因为你对系统的理解，随时都在变化着，一定要保证你的文档和当前你对系统的理解是一致的。
        试着使用系统，根据经验和常识猜测：既然没有需求，那可以推测，该项目的管理一定是很糟糕的，对测试也不会投入很大的成本。因此，测试人员一般都是在编码完成后才进入项目。这时，应该已经可以看到成型的系统了。在没有需求的情况下，试着先“玩”一下系统吧。在这过程中，你应该对系统有可更深入的认识，在上一阶段中，你可能留下很多疑惑或是猜测，这时应该能排除一部分了。
        使用系统的同时，你应该具备行业知识。系统可能是针对某个专业领域设计的。例如一个期货交易系统。你没有基本的期货知识，比如什么是持仓，什么是平仓。那么你如何能真正理解这个系统呢？当你有了业务知识以后，你会进行更深入的思考，来全面测试系统。
        你还需要具备良好的软件知识。比如某些控件的特性。单选框只能单选，不能多选。日历控件是否可以手工输入非法格式等。这些都是应具备的意识。
        最后加上你的主观判断，你对系统的整体感觉怎么样？是否越用越厌烦，为什么厌烦。系统的反应速度是否可以容忍，细节处理是否圆滑，等等。
        在你认识系统的时候，可以使用一些方法，来帮助你更有效率地学习。比如可以画一些流程图。一图胜万语。同时，你也留下宝贵的文档。当然，这个步骤中，你也要随时注意保留和更新文档，以备后用。
        沟通：需求规格不一定非要以文档的形式表现出来。软件既然能做出来，那肯定是有需求的。而最清除需求的，一定是软件的直接制造者，开发人员。开发人员自己知道需求，但一般不会主动和测试人员沟通。因此，测试一定要主动和开发人员沟通。可以安排会议，让开发人员给测试人员介绍系统，并演示系统。让测试人员对系统有一个整体了解。然后测试人员能进行更细致的测试。在进行细致测试的时候，一定会有更多不明确的地方。这时就需要利用自己的行业知识，计算机知识等，猜测一部分。不需要每个细节都去询问开发人员。因为开发人员也有自己的工作，他们不希望花太多时间来给你解释。
        有些项目中，客户会直接参与到项目组来。这时，测试人员在权限允许的情况下，可以和客户进行沟通。客户那得来的需求，是最原始的需求。但是，客户未必有良好的表达能力来描述希望的功能，也未必有计算机知识，因此不能描述出一些隐式的需求。在被允许的情况下，测试人员可以和客户进行交流，不仅可以帮助客户正确描述出真实需求，测试人员也能详细了解需求。但是项目是要考虑成本的，客户的期望是无限制的。在客户提出需求以后，测试人员要先和PM或其他相关负责人协商后，才能将与客户交流得来的需求，作为测试的依据。同事，第一时间告知相关开发人员最新的信息，也记录成文档。这时，你就将非文档形式的需求，转换为文档形式了。至于文档的格式，不一定要按照标准SRS的格式。因为它本身就不是个规范的SRS。以任何容易理解的方式，组织你的文档。
        有时候，会根本找不到可以沟通的人。不要奇怪，确实就是有这种时候。比如：
        1. 测试一个开源软件
        2. 接到一个测试外包，但又没有得到相关文档，为了追求利益，还是接下了
        3. 软件项目组的部分人员已经联系不上等等
        这时候，一方面需要PM协调获取相关资料，联络相关人员。另一方面，测试人员也可组织头脑风暴，利用集体的智慧，共同探讨和猜测软件中的各个环节。也可以安排Bug Bash，让尽可能多的人员参与随机测试。一定会有人提出具有创造性的意见的。
        在进行以上步骤的时候，利用良好的工具，能让你事半功倍。我经常在使用的一个工具，就是Mindjet MindManager。这是一个很好的，帮助扩展思维的工具。它以分支的形式，来表现你的思维层次。你可以先列出个最基本的系统整体结构，然后逐步细化，增加分支。不要急于一次就将真个系统分析透彻，这是不可能的。你在进行以上步骤的时候，随时会细化这个结构。当项目结束后，看看这个结构图，简直可以当作SRS来参考了！

【51软件测试每周一问，整理】没有需求文档的时候如何来设计测试用例？（08-06-20）

这是根据51Testing软件测试网上“软件测试每周一问”问答整理而成，集大家之智慧！

【引题】测试用例应该是按照需求文档来开发，但是当项目没有需求文档时，该如何设计测试用例呢？

【题外话】大家在求职时参加的面试中会被问到各种各样的问题，有些问题的确是有确定的唯一的答案，而更多的问题是开放性的，面试着主要是你想了解求职人的自己的看法，而回答问题的方式也能看出个人看问题，思考的方式。本身，思考，就是一种方法学。

【正题】hjjlearning的回答是我比较满意的。Case by case的讨论问题，总是比较全面，而且可以引导大家更为全面的去思考，从而提高一个问题的广度。针对“没有需求文档”这样一个现象，我们去想解决问题时，需要花点时间去考虑造成这种现象的原因。针对不同的原因，也就是找对“病因”了，解决问题的方法也就有了。这就如中医看病，总是从表象的症状去寻其根究。就比如头通，表现出来的这一种症状，却有不同的原因，西医总是“头痛医头，脚痛医脚”，而中医主张从其根本去分析，痛其实是身体某处经络不通造成的，把相应的经络打通了，那痛的问题就会解决了，有时头痛可以通过按摩脚底的穴位，或是敲打胃经，胆经，等等。又扯远了，哈！

分析“没有需求文档”，分析其具体原因再针对性的解决：

1. 整个项目的开发人员和项目经理的意识不足，开发流程不规范，或是认识不到需求文档对于测试的举足之重。认为做过了市场可行性分析了，认为项目组的成员对于整个项目都有清楚，而且任务分配下去了，就没有必要写需求文档了。

针对这种情况，测试负责人应该坚持要求项目负责人派专人给出需求文档，否则就拒绝测试。这对于规范的软件开发项目来说应该是理所当然的事情，可是在中国（我不知道别的国家是怎么样子的），做事都讲究官大压死人。bingcha320说的好，上报'没有需求文档将无法进行测试用例设计'的事实给高层管理者(练口才的时候到了),引起他们的重视,让他们尽可能推动开发组或产品组完成需求文档，哈哈

2. 项目进度紧张，后期需求变动会比较大，来不及也不好写详细的需求文档，或是项目是从原有项目上进行升级，开发人员认为不要再进行

当项目经理把自己的难处说给你听，并给你一个“Sorry”的时候，那就要动用各方面的关系自己去搜集功能点啦。

简言之，不能瞎乱糊草的写测试用例。对自己的时间和精力负责，对整个项目负责，自己整一份feature check point list！

Zhuzx给出了比较详尽的条条框框的指导性的回答，（有经验有头脑的人就是厉害哈！我在其精彩回答后加了点自己的“挑刺”）

下面是我的一些看法，恳请各位同行批评指正：
1.根据客户的功能点整理测试需求追朔表：
一般的客户都要把要开发软件的功能点写成一个表格交给市场部，让市场部门转交研发部。所以客户的功能点是编写测试用例一个最最重要的依据。【其实这只是一个依据，客户列出的功能点，要转化为软件实现的功能点并能在开发人员和测试人员之间更好的沟通的话，还是需要一点处理的】

2.根据开发人员的Software Specification List整理我们的功能测试点：
一般来说，开发人员实现一个功能都要把该功能分成几个子模块来实现，所以Software Specification List也是我们参考的另一个比较重要的依据。【只做过黑盒测试，在做黑盒测试时，参考开发人员的design doc时，尽量避免被开发人员误导，因为有些在他们看来是要实现并验证的功能，在用户使用时其实只是一种情况，而有些在他们看来是一个问题时，实际上用户使用时会有不同的体验，测试人员不是为了验证代码的逻辑的正确，而是为了确保交付给用户使用时，软件的质量很高。当然了，这些开发文档在没有需求文档时是比较好的资料啦J】

3.开展项目跨部门讨论会：
可以抽出时间，叫市场部的项目负责人、产品经理、项目经理、软件开发经理和软件开发人员，分别讲讲他们对整个产品的认识和设计模式，对每个功能点的理解和认识，理顺思路，达成共识，测试人员负责记录，测试Leader负责整理汇总，形成测试的部分参考文档。

4.测试人员整理用例需求疑问递交项目组和客户代表回复：
测试人员根据项目讨论会后的理解，测试过程中可能碰到的问题（如：边界值、输入数据类型等等）和需求不明确的问题，整理用例需求疑问，让相关的模块负责人在“用例需求疑问”表格中回复，并给出详细解释和说明。

5.项目内部用例评审：
测试人员根据对项目的理解，编写测试用例要点，测试组内部评审修改后，可以召集项目组的成员，帮助Review一下，然后进行修改。经过多次修改和评审以后，测试用例要点可能会更加全面一些。

6.邮件和客户代表确认部分争议问题：
测试人员与开发人员、项目组成员，在需求问题上讨论有时候观点不一致，各说各有理，这种情况下最好把争议问题写成邮件，发给客户让客户来拍板，确定那种需求合理，到底如何做？抄送项目组的全体成员，方便大家都了解客户的意见。最后编写测试用例的时候，以客户的邮件内容为准。

7.项目Demo和部分已开发系统：
大部分的系统，由于没有需求，为了避免项目风险，开发方一般都要做成Demo，不断让客户确认后签字，不断展现新开发的功能，以达到吸引客户的目的。如果项目中有Demo，Demo也是参考标准。如果什么都没有，那已经开发的部分功能模块，要去随时让用户了解了解，并提出部分修改意见，也可以为我们熟悉系统提供部分依据。

8.参考同行业和竞争对手的类似产品：
假如说是做一个网上书店类似的网站，我们编写测试用例的时候，可以看看“当当网”，“China—pub”等等类似成熟相关的网站。很容易发现本公司产品的问题，无意识给产品添加了竞争力。对于竞争对手的了解一定不能够少。

9.交叉模块的测试，最容易被人忽略：
一般的产品，功能部分的交叉，即是说在A模块中设置了参数，在B模块和C模块中体现该参数的实际运用。比较难的如我们现在测试的“银行系统”中的交叉模块，还可能牵涉到不同的用户，3个以上的模块之间的调用。即是有了需求也很少写，同时也是需求编写的一个薄弱环节。这样的测试用例编写问题，一般初级测试工程师很难考虑全。对于有这种交叉功能的模块，必须要求项目组中的精兵强将，画出相关的调用关系图，表明调用关系，方便后面编写测试用例。

10.可以使用电话、MSN、Skype等网络聊天工具咨询部分需求：
我们做的产品，大多数的客户都在国外，测试经理也可以用这些网络聊天工具和客户确认部分需求疑问。不过要要事先越好时间，并注意异地的“时差”。