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