这里就测试用例在功能测试上的设计方向，大略的谈谈我自己的一些浅见。

测试用例是测试执行的关键，它直接指导如何测试。测试用例的产生源于测试需求，所以在此之前需要把测试需求做好。根据测试需求的分类，在系统功能方面，我把它分成三个集合：界面功能，通用功能，业务功能。任何一个页面的元素都可以分解成这三个集合中的子集或元素。根据这三个集合的特点选择不同的测试用例设计方式。具体的设计可以参考不同的用例模板，对于界面功能，选择简单的模版，甚至列表都可以，因为它们的元素一般都比较独立。通用功能指在很多系统中都会出现的一些常规功能，比如：“上一页”，“返回”，“返回主界面”等，它们有页面的动态变化。在数据库里的反映，就是最多只涉及单个表格的改动，并不引起表与表之间的连锁反应。它所使用的用例模式可采用现在常用的描述法表示。不过对具体系统中的某些功能点还需要具体再考虑。

测试用例设计的重点就是业务功能。对于一个熟练的测试人员来说，界面和通用功能的检查，用例已在他们的心中，并不需要文档指导。业务功能是一个系统的核心，它往往也代表了一个管理软件的价值。业务功能的测试用例模版，我现在比较支持场景法。对主业务流的设计采取全路径的检测，因为他们的节点不是特别多，其它的不再累述。除了对系统正确业务流执行的设计外，还有其它一些设计方法，根据测试人员的不同特点，他们的设计也会有所不同。业务功能的设计在我看来是最能反映出测试设计人员的专业水平。因为它不但需要好的测试技术还需要好的系统相关行业知识。

这种用例分类的想法，是为公共用例库的建立策化。为了方便测试文档管理，培养新人，特别是将熟练的测试人员从重复繁重的文档工作中脱离出来，重点放在如何检查系统上。这种分离是有必要的。此外还有一个特别操作集，源于某些测试人员的非常规操作，范围超出三个集合，但错误对系统的影响很大。这个集合比较小，可以单独管理，用于对系统稳定性的考察。

我有时候觉得系统就跟人一样，没有完美的人，也没有完美的系统，我们只是努力做得更好。

软件测试的内容很多，就功能方面来说有界面，数据，流程，权限等。对于一般的管理软件来说，流程的测试是一个重点。如何对流程进行测试，是用例设计人员考虑的重心。下面就流程测试设计谈谈我自己的一些看法。

流程用例设计第一是要考虑流程的完备性。先要整理出要测试流程的节点和关系。确定节点和关系有几种方法，可以从流程图中得到，也可以从系统用例中得到，或者需求说明中整理出来，如果不幸这些都没有，你也可以自己找出来。如何寻找，请参见我的文章《没有文档如何测试》。

    掌握资料后，首先，确定要测试流程的重点。在一个系统中，一个大流程有时会包含几个小流程，也有可能会出现流程相交的情况。这里的重点是指对于确定的一个独立的流程而言，它有一个明确的起点和一个明确的终点，它的分支点可能会接入其他流程，但我们只把那些当成接口考虑。

一个流程在通常情况下，有两个方面的内容：一是流程节点的移动，即功能的实现，主要与角色相关。二是节点间数据的流动，主要检查数据的完整性与正确性。对于以角色为重点的流程，第一个方面是重点；对于以业务实现为主要的流程，第二个方面是重点。下面分别进行阐述和举例说明。

测试流程的功能实现，第一步是确定节点，这些节点的特征就是要有一个独立的业务意义，其包含的业务数据也是不可再分的。常见的这类典型的流程就是公文流转。公文流转在很多办公软件中都会遇到。从新建公文开始，到公文传递审阅，到最后审阅完成。这种流程看起来很简单，实际上在程序设计实现的时候，仍会出现一些问题，其中包括流程设计的合理性。

设计测试用例的时候，分没有权限的测试和权限测试两种。没有权限的测试主要检查流程在实现方面的功能问题，往往是一个角色走到底。它的节点最大数和最小数往往已经定义。主要检查节点和节点之间的实现，如数据传递是否正确，流程是否会回退。这里重点要提到的是，不间断的，一气呵成的业务转移与退出再进入系统继续业务是有所不同的，这主要取决于程序在实现业务流程时才用的方式，是保存在缓存中还是及时读写。对于可以自定义流程的程序来说，则要考虑跨标准节点的一些流程定义和一些非业务常规的流程定义。这部分测试用例的设计，不但要检查流程的正确性，还要考虑是否存在其他可能在系统设计之外的暗含的流程。比如某些流程需要文件导入导出，但却没有对这些文件做出判断。

当加入权限进行测试的时候，首先测试用户实际使用的角色处理，保证需求的正确性。然后再设计自定义角色的处理，这部分往往内容很多，且不太可能进行完全测试。重点是将主要节点进行角色检查，设置最小权限和最大权限的组合，以检查是否会出现数据丢失，跨流程或角色越权的情况。如果考虑角色和流程定义的双重组合，如果没有工具软件支持，其工作量是难以想象的。当然我们仍然可以从其中只选择20%的用例实现设计，可以找出超过80%的流程权限的问题。其关键就是结合程序实现的方式，即进行灰盒用例设计。

使用灰盒用例设计的好处也体现在以数据为主的业务流程实现上。测试这样的业务流，往往是测试多个相关算法。它的测试重点在数据的选择上，有两类数据取值要考虑，一种是业务数据，一种是系统数据。业务数据的取值，主要考虑正确业务数据，边界业务数据和错误的业务数据；同时结合算法本身的特点还要考虑0，1，2，9，浮点数，最大值，最小值，小数位等的情况。考虑内存和中心处理器的能力，还要进行大数据量的测试，这时要结合测试工具进行设计。我曾遇到一个关于浮点数取值的问题，按照一般小数的算法，结果是0.01，但在算法实现时，机器中是0.009999….，按业务规定小数位后三位全部舍掉，入另一个帐。这种偏差的累计是很惊人的。除此外，还要考虑数据与数据之间的影响。有些算法在单独检查时没有错误，但当附加条件取值时（往往是特殊值），就会影响整个结果。

相信做测试的大部分朋友都有同感，在很多时候，我们都要面临没有文档或文档混乱，残缺的系统进行测试，而这时往往距离系统提交的时间只有几周了。那么，这时我们应该如何确定测试需求呢？先放下心中的愤懑，让我们讨论一下。

   对一个系统而言，就算是你对它一无所知，仍然可以对界面和普通功能点进行测试，比如添加，删除等。但这对一个系统而言是远远不够的，是否实现它预期的需求才是测试工作的重心。如果不是因为时间的限制和这个系统的提交不需要你负责，你要坚持你自己的意见，而不是听从所谓的功能基本都实现了。  

    首先，去发现需求。这时你要把自己想象成一个侦探。所测试的这个系统现在它要满足什么需求，并以此建立这个时间的测试需求版本。实际上，系统的开发也许已经经过了几个版本了，每个版本都有实现的需求，有些很重要，有些次之。现在，你是要尽可能的全部找出它们。

第一步：收集数据。

    1、阅读文档。如果你手头还是有一些文档，不管它的版本是多么老或者残缺不全都比没有要好，它总会给你提供一些需求的线索。也可从用户手中得到的一些用户文档或发行的媒体文件。一般用户在系统设计之初都会给当时的调研人员留下一些纸制或电子类的文档以表述他们的系统需求期望。如果你的项目经理已经遗失了这些资料，用户那里一般也有备份。但你需要一种婉转的方式去询问，以免给用户造成系统是否不能正常完成的印象。这些可以帮你对这个系统总体来说应该要满足那些重要的功能提供资料。

    2、检查系统的体系结构。找一些对这个系统体系结构比较了解的人解释给你，并告诉你为什么系统是这样的体系结构。我们常常能从定义系统能力的最高层的限制中发现一些薄弱的连接。如果你本身就有一些系统体系结构方面的知识，这方面的工作应该不是很困难。

    3、执行程序。检查程序的执行，在每一个页面中检查功能是否能够全部实现，在此可以找出它是否存在一个上一个结点和下一个结点。做上记录。然后根据页面的标题和节点之间的逻辑推理，可以大致判断出有几个业务流，它们涉及哪些相关节点。哪些页面之间存在数据联系。

    4、询问开发者。这是一个比较头痛的问题，如果开发人员正忙于赶工期，他们对你的轻视可能导致你的询问很难有所成效。所以，你要尽量的提问得仔细，问题最好用是这样或不是这样回答，以免因为他们不想对你解释太多而敷衍你。所以，你要尽可能的做好前面的工作，而不是依赖于开发人员。首先，你需要在项目经理那里得到开发人员所做的模块清单。哪些模块被几个开发人员同时操作，找出现在的负责人。然后，整理出自己所知道的模块信息，与开发人员交流。如果你对这件事感到委屈，那么至少有两个方面你需要加强，一是学会善于沟通，与开发人员相处融洽。二是努力学习，获得足够的知识与开发人员平等交谈。

    5、询问项目经理

   项目经理是一个能给你提供自己最大帮助的人，因为这个测试可能往往就是他要求的。你在那里尽可能的去找出有关系统的信息和资料。如果他不配合你，那么这个系统可能存在着某些巨大的问题导致也许根本无法交付。所以你需要花更多的时间来做工作。

   当你找到这些需求资料时，你应该没有责备过任何一个人，因为在那个时候，他们做了他们的工作，你不能去要求人们以前应该做什么。现在你拥有的优势超过了项目中的其他人，你不需要被他们的假定迷惑。你可以更客观的去看待这个系统，并且比较它和设计的初衷有什么不同。

第二部，将资料转化为系统需求。

    现在你有一些经过整理的材料，可以将它们转变为需求了。每个一个功能在不同的人那里可能有不同的说法。当你浓缩它们并定义它们这些说明的价值将变得非常清晰。我们想确定每一个说明的本质。这说明是否相关角色，特性或功能？

    首先确定你能够安排的工作时间，根据时间按主要和次要安排需求。然后可按以下步骤来整理：

    1、确定系统拥有多少角色（业务），他们负责什么样的工作，在系统中体现在那些模块中。然后画出这些角色的用例，或者他们涉及的业务。一般来说，系统很少有角色会全程做完一个业务流程。你可以先把每一个角色所做的每一个功能点列出来，然后再将它们放到一个完整的业务流中去。或者先画出整个的业务流，然后再分配给角色。最后你能得到一个完整的图，它包含整个系统所有业务流程，并且有哪些角色在某个节点上能够做哪些操作（拥有哪些权限）都非常的了然，这将是你测试的重点。

    2、确定系统管理员的工作内容，系统管理员一般对系统进行初始设置，角色定义，业务流定义等重要操作。

    3、确定系统的数据流动，包括系统的内部模块间数据流动（可结合系统角色图）和系统间的数据流动接口，在这些地方一般都比较容易出问题。

    4、确定公共部分需要测试的需求。系统中有一些部分为很多角色所共同拥有并且不涉及业务流程。将这部分内容整理，一般来说这些内容只会涉及界面和普通功能的测试，如定义系统界面风格。

    5、确定系统的使用情况。系统有多少用户，稳定运行要求至少多少时间，什么时候会出现系统使用高峰期，高峰期的特点。系统对未来几年内的用户和数据增长是否提供足够的可扩展空间。

    6、系统的安全确定。系统运行的环境要求什么样的安全级别，有什么具体要求。如：访客是否能访问到只有用户才能访问的功能；一个角色是否越权访问他不能访问的角色。系统是否存在没有指向的链接页面作为后门（这个比较难）。等等。

    7、使用该系统的用户可能的硬，软件环境，比如机器类型，操作系统，常用软件等。

    8、其他系统要求确定的需求。

    做完这些工作后，你可以开始设计你的测试用例了。也许仍然存在你不知道的情况，但你可以确定它没有表现在系统的可视范围内。