-
测试需求的来源
2007-04-05 13:52:44
测试需求的主要来源是系统需求说明书（或者叫软件规格说明书等），有了系统需求说明书基本就能画出系统的样子，测试需求报告主要是系统角度上来提供需要测试哪些要点，主要提供功能性的需求。性能上的需求还需要结合从详细设计和数据库设计上面获得。系统的具体内容都应从需求说明书和系统设计书上能够获得。如果没有系统的前期完整文档，或者因为需求变更没有做好，遗憾的是这种情况并不少见，那么我们只能从已存在的系统中提取了。有相关项目经验的测试人员一般可以找出大部分的需求，而没有经验的测试人员几乎无从下手。我们在另一片文章《没有文档如何确定需求》一文中会给出一些意见。
系统需求说明书是按照系统，子系统，模块、功能、子功能、数据的形式来编写的。比如一般的企业管理系统都包括前端的子系统和后台的管理系统，前端的子系统一般由业务人员操作，后台管理子系统一般由系统管理员或高级用户操作。在文档中我们提取系统基本功能点后需要测试需求点进一步分割下去。基本功能点的粒度一般以一个子功能点为宜。以检测向数据库中添加新数据的功能来举例吧（不考虑空间和并行的情况），可以分为添加0条数据，添加1条数据，添加n条数据。添加0条数据是指进入添加功能界面，然后不添加数据直接退出；添加一条数据就是向数据库里执行一次添加操作，然后退出；添加n条数据是连续向数据库中添加数据。添加0条数据对数据库而言视为不能再扩充的用例。但添加一条数据和添加n条数据是可以扩充。比如日期输入域可以测试的内容包括：标准数据，特殊数据，边界数据，非法数据。标准数据是指在输入最不可能出错的数据的情况下，该功能是否可以使用，如果在我们选择最正确的数据的情况下系统无法使用，我们就认为此功能根本不可使用，下边的测试就可以不进行了。特殊数据的测试是对系统来说是需要特别提出的数据，比如日期型数据，有闰年，闰月的问题。边界数据只一个数据集合的边界如：所有月的第一天，所有月的最后一天，第一个月，最后一个月。非法数据就是所有不符合系统定义和设计的数据，它包括集合之外的数据和格式不对的数据。首先是正确性测试，对页面进行正常操作的测试然后对单个数据域测试之后还需要对输入域进行组合测试，如果全部写成用例，对于数据输入项很多的页面来说，测试工作量很大，这时可以结合详细设计书采用一些简化用例的方式（比如正交法），保留特殊项的必要检查，主要是与其它表中有数据读取，改写的项以及某些需要特别注意的项比如日期，金额等。不过，如果有自动化测试工具就可以设计几乎全部的用例，调试好脚本，晚上让机器执行。
如果开发人员都是熟练的开发人员（有三年相关项目的开发，并且开发的系统被专门测试过），测试的在界面和通用功能点上的耗费会比较小，这方面的需求粒度可以比较大一些。如果开发团队都是1-2年的开发人员且没有和测试配合过，界面和通用功能点也必须认真全面测试，粒度要设计得很小。测试和开发的磨合不是一件容易的事。如果有充足的时间，我们当然不用在意那么多，但实际上我们的时间很紧张。
测试需求最好还要考虑软件应用单位的人员使用软件的情况，这一点比较难，但对于一些行业软件来说，总有一些行业习惯，比如：在做完某个业务功能后，业务人员需要再手工填一些表，这就要考虑键盘和鼠标乱动的情况；甚至要考虑突然断电，对刚进行操作的影响，因为有些业务人员需要频繁的穿梭于各个工作台。如果需求上没有考虑这些问题，一个好的测试人员也应该考虑到。还有用户使用的其它软件，如果有一部分用户习惯使用WPS，如果只考虑到OFFICE接口，到了用户那里会出现意想不到的麻烦，因为有些机子装不了OFFICE。
-
没有文档如何确定测试需求
2007-04-05 13:52:44
相信做测试的大部分朋友都有同感，在很多时候，我们都要面临没有文档或文档混乱，残缺的系统进行测试，而这时往往距离系统提交的时间只有几周了。那么，这时我们应该如何确定测试需求呢？先放下心中的愤懑，让我们讨论一下。
对一个系统而言，就算是你对它一无所知，仍然可以对界面和普通功能点进行测试，比如添加，删除等。但这对一个系统而言是远远不够的，是否实现它预期的需求才是测试工作的重心。如果不是因为时间的限制和这个系统的提交不需要你负责，你要坚持你自己的意见，而不是听从所谓的功能基本都实现了。
首先，去发现需求。这时你要把自己想象成一个侦探。所测试的这个系统现在它要满足什么需求，并以此建立这个时间的测试需求版本。实际上，系统的开发也许已经经过了几个版本了，每个版本都有实现的需求，有些很重要，有些次之。现在，你是要尽可能的全部找出它们。
第一步：收集数据。
1、阅读文档。如果你手头还是有一些文档，不管它的版本是多么老或者残缺不全都比没有要好，它总会给你提供一些需求的线索。也可从用户手中得到的一些用户文档或发行的媒体文件。一般用户在系统设计之初都会给当时的调研人员留下一些纸制或电子类的文档以表述他们的系统需求期望。如果你的项目经理已经遗失了这些资料，用户那里一般也有备份。但你需要一种婉转的方式去询问，以免给用户造成系统是否不能正常完成的印象。这些可以帮你对这个系统总体来说应该要满足那些重要的功能提供资料。
2、检查系统的体系结构。找一些对这个系统体系结构比较了解的人解释给你，并告诉你为什么系统是这样的体系结构。我们常常能从定义系统能力的最高层的限制中发现一些薄弱的连接。如果你本身就有一些系统体系结构方面的知识，这方面的工作应该不是很困难。
3、执行程序。检查程序的执行，在每一个页面中检查功能是否能够全部实现，在此可以找出它是否存在一个上一个结点和下一个结点。做上记录。然后根据页面的标题和节点之间的逻辑推理，可以大致判断出有几个业务流，它们涉及哪些相关节点。哪些页面之间存在数据联系。
4、询问开发者。这是一个比较头痛的问题，如果开发人员正忙于赶工期，他们对你的轻视可能导致你的询问很难有所成效。所以，你要尽量的提问得仔细，问题最好用是这样或不是这样回答，以免因为他们不想对你解释太多而敷衍你。所以，你要尽可能的做好前面的工作，而不是依赖于开发人员。首先，你需要在项目经理那里得到开发人员所做的模块清单。哪些模块被几个开发人员同时操作，找出现在的负责人。然后，整理出自己所知道的模块信息，与开发人员交流。如果你对这件事感到委屈，那么至少有两个方面你需要加强，一是学会善于沟通，与开发人员相处融洽。二是努力学习，获得足够的知识与开发人员平等交谈。
5、询问项目经理
项目经理是一个能给你提供自己最大帮助的人，因为这个测试可能往往就是他要求的。你在那里尽可能的去找出有关系统的信息和资料。如果他不配合你，那么这个系统可能存在着某些巨大的问题导致也许根本无法交付。所以你需要花更多的时间来做工作。
当你找到这些需求资料时，你应该没有责备过任何一个人，因为在那个时候，他们做了他们的工作，你不能去要求人们以前应该做什么。现在你拥有的优势超过了项目中的其他人，你不需要被他们的假定迷惑。你可以更客观的去看待这个系统，并且比较它和设计的初衷有什么不同。
第二部，将资料转化为系统需求。
现在你有一些经过整理的材料，可以将它们转变为需求了。每个一个功能在不同的人那里可能有不同的说法。当你浓缩它们并定义它们这些说明的价值将变得非常清晰。我们想确定每一个说明的本质。这说明是否相关角色，特性或功能？
首先确定你能够安排的工作时间，根据时间按主要和次要安排需求。然后可按以下步骤来整理：
1、确定系统拥有多少角色（业务），他们负责什么样的工作，在系统中体现在那些模块中。然后画出这些角色的用例，或者他们涉及的业务。一般来说，系统很少有角色会全程做完一个业务流程。你可以先把每一个角色所做的每一个功能点列出来，然后再将它们放到一个完整的业务流中去。或者先画出整个的业务流，然后再分配给角色。最后你能得到一个完整的图，它包含整个系统所有业务流程，并且有哪些角色在某个节点上能够做哪些操作（拥有哪些权限）都非常的了然，这将是你测试的重点。
2、确定系统管理员的工作内容，系统管理员一般对系统进行初始设置，角色定义，业务流定义等重要操作。
3、确定系统的数据流动，包括系统的内部模块间数据流动（可结合系统角色图）和系统间的数据流动接口，在这些地方一般都比较容易出问题。
4、确定公共部分需要测试的需求。系统中有一些部分为很多角色所共同拥有并且不涉及业务流程。将这部分内容整理，一般来说这些内容只会涉及界面和普通功能的测试，如定义系统界面风格。
5、确定系统的使用情况。系统有多少用户，稳定运行要求至少多少时间，什么时候会出现系统使用高峰期，高峰期的特点。系统对未来几年内的用户和数据增长是否提供足够的可扩展空间。
6、系统的安全确定。系统运行的环境要求什么样的安全级别，有什么具体要求。如：访客是否能访问到只有用户才能访问的功能；一个角色是否越权访问他不能访问的角色。系统是否存在没有指向的链接页面作为后门（这个比较难）。等等。
7、使用该系统的用户可能的硬，软件环境，比如机器类型，操作系统，常用软件等。
8、其他系统要求确定的需求。
做完这些工作后，你可以开始设计你的测试用例了。也许仍然存在你不知道的情况，但你可以确定它没有表现在系统的可视范围内。
