测试需求的来源

   测试需求的主要来源是系统需求说明书（或者叫软件规格说明书等），有了系统需求说明书基本就能画出系统的样子，测试需求报告主要是系统角度上来提供需要测试哪些要点，主要提供功能性的需求。性能上的需求还需要结合从详细设计和数据库设计上面获得。系统的具体内容都应从需求说明书和系统设计书上能够获得。如果没有系统的前期完整文档，或者因为需求变更没有做好，遗憾的是这种情况并不少见，那么我们只能从已存在的系统中提取了。有相关项目经验的测试人员一般可以找出大部分的需求，而没有经验的测试人员几乎无从下手。我们在另一片文章《没有文档如何确定需求》一文中会给出一些意见。

   系统需求说明书是按照系统，子系统，模块、功能、子功能、数据的形式来编写的。比如一般的企业管理系统都包括前端的子系统和后台的管理系统，前端的子系统一般由业务人员操作，后台管理子系统一般由系统管理员或高级用户操作。在文档中我们提取系统基本功能点后需要测试需求点进一步分割下去。基本功能点的粒度一般以一个子功能点为宜。以检测向数据库中添加新数据的功能来举例吧（不考虑空间和并行的情况），可以分为添加0条数据，添加1条数据，添加n条数据。添加0条数据是指进入添加功能界面，然后不添加数据直接退出；添加一条数据就是向数据库里执行一次添加操作，然后退出；添加n条数据是连续向数据库中添加数据。添加0条数据对数据库而言视为不能再扩充的用例。但添加一条数据和添加n条数据是可以扩充。比如日期输入域可以测试的内容包括：标准数据，特殊数据，边界数据，非法数据。标准数据是指在输入最不可能出错的数据的情况下，该功能是否可以使用，如果在我们选择最正确的数据的情况下系统无法使用，我们就认为此功能根本不可使用，下边的测试就可以不进行了。特殊数据的测试是对系统来说是需要特别提出的数据，比如日期型数据，有闰年，闰月的问题。边界数据只一个数据集合的边界如：所有月的第一天，所有月的最后一天，第一个月，最后一个月。非法数据就是所有不符合系统定义和设计的数据，它包括集合之外的数据和格式不对的数据。首先是正确性测试，对页面进行正常操作的测试然后对单个数据域测试之后还需要对输入域进行组合测试，如果全部写成用例，对于数据输入项很多的页面来说，测试工作量很大，这时可以结合详细设计书采用一些简化用例的方式（比如正交法），保留特殊项的必要检查，主要是与其它表中有数据读取，改写的项以及某些需要特别注意的项比如日期，金额等。不过，如果有自动化测试工具就可以设计几乎全部的用例，调试好脚本，晚上让机器执行。

   如果开发人员都是熟练的开发人员（有三年相关项目的开发，并且开发的系统被专门测试过），测试的在界面和通用功能点上的耗费会比较小，这方面的需求粒度可以比较大一些。如果开发团队都是1-2年的开发人员且没有和测试配合过，界面和通用功能点也必须认真全面测试，粒度要设计得很小。测试和开发的磨合不是一件容易的事。如果有充足的时间，我们当然不用在意那么多，但实际上我们的时间很紧张。

   测试需求最好还要考虑软件应用单位的人员使用软件的情况，这一点比较难，但对于一些行业软件来说，总有一些行业习惯，比如：在做完某个业务功能后，业务人员需要再手工填一些表，这就要考虑键盘和鼠标乱动的情况；甚至要考虑突然断电，对刚进行操作的影响，因为有些业务人员需要频繁的穿梭于各个工作台。如果需求上没有考虑这些问题，一个好的测试人员也应该考虑到。还有用户使用的其它软件，如果有一部分用户习惯使用WPS，如果只考虑到OFFICE接口，到了用户那里会出现意想不到的麻烦，因为有些机子装不了OFFICE。