如何解决软件测试的近忧和远虑[2] 软件测试
其中，黑盒测试中常用的等价类划分方法是先把程序的输入域划分成若干区间，然后从每个区间中选取少数代表性数据当作测试用例(由于数量太大，穷举测试一般情况下不可能实现)。在使用等价类划分方法时，通常会涉及到两种等价类：有效等价类和无效等价类。顾名思义，有效等价类就是对程序的规格说明是有意义的合理的输入数据集; 无效等价类就是对程序规格说明书不合理或无效的输入数据集。我们在设计测试用例时，要兼顾这两种情况。同时要注意一个测试用例只能覆盖一个无效等价类。这样便于错误定位，防止一个错误表征掩盖了另一个错误。例如，程序的规格说明中规定了“……每类科技图书10至50册，……”，若一个测试用例为“小说5册”，在测试中很可能只检测出书的类型错误(小说不是科技类图书)，而忽略了书的册数错误(5不在10至50之间)。
[NextPage]
黑盒测试中另一个常用的测试用例设计方法是边界值分析，它是一种补充等价类划分的测试用例设计技术，它选择一组测试用例检查边界值是否符合相应规格说明。因为输入域的边界比中间更加容易发生错误，所以引进了边界值分析方法往往能发现更多的软件缺陷和错误。
而不管黑盒测试多么全面，它都可能忽略类似于逻辑性错误、潜在破坏性执行流程、冗余程序代码乃至于简单打字错误等，而白盒测试则可以进一步发现它们，查找出代码层次的错误和缺陷。白盒测试用例设计包括的门类也相当繁多，这里限于篇幅不再赘述。
做好软件测试件管理，消除“远虑”
测试件泛指一切手工测试和自动测试活动中必须受控或值得纳入测试团队知识库的所有输入和输出数据，包含团队自主开发的测试自动化工具。如何有效地管理好测试件，是影响测试团队效率与整体水平的重要因素之一。在待测项目规模小、功能点少的情况下，测试工作或许能正常进行。但如果测试团队要同时测试多个项目，各项目规模都相对较大，涉及的测试人员较多时，测试工作的效率可能会大为降低。除此之外，测试件管理对于团队的整体水平提高亦具有不可估量的长远意义，将有代表的测试用例、测试方案等积累起来，可避免团队长时间在一个较低水平上徘徊。
在表2所示测试件中，除了测试用例自动化管理、测试缺陷(报告)跟踪管理已经有较好的自动化管理工具外，其他测试件目前尚未发现有对应的专用管理工具，笔者建议采用配置管理工具(如CVS)。(由于测试缺陷跟踪管理在上期已有详细的论述，这部分内容本文从略)
测试用例管理系统
测试用例设计人员需要了解目前已经设计了哪些模块或部件的测试用例，还需要完成哪些设计工作，而测试执行人员需要被明确地告知今天要测试什么，需要执行多少个测试用例。基于这些需求，人们开发了测试用例管理系统，其目的是为了对项目的测试用例的设计、执行及执行结果进行统一管理，提高测试活动的效率。
测试用例管理系统市面上有很多(如微创测试用例管理系统等)。典型的工作流程如下：设置基本参数→登录系统→选择项目→新增模块节点→新增需求→新增测试用例→审核测试用例→新增测试组→新增测试计划→执行测试→测试结果查看→统计分析。该流程涉及到的角色包括测试组长、测试设计人员、测试执行人员、系统管理员、测试评审员等。其中，测试设计人员拥有写入测试用例的权限，测试执行人员负责测试用例的执行，二者是测试用例管理系统的主体。
配置管理
除测试用例、测试缺陷报告之外的测试件均可以使用配置管理的方式进行管理。这里有两个可选择的配置管理方式。一是将测试件的逻辑集合(称为测试件组)作为配置项保存在配置库中。每个测试件组有自己的版本信息，而组成测试件组的各个测试件没有自己的版本信息。测试人员可以根据需要随时从配置库中取出任何版本的测试件组(包含已修改的和未修改的测试件)。由于其操作简单，且出现版本错误的可能性较小，所以适用于配置管理体系不成熟的情况。
另一种方式是把单个的测试件作为配置项，每个测试件有自己的版本信息。这种方式需要在测试件组或多个测试件组上进行基线化。通过基线化操作，方便测试人员能取出对应于不同版本系统的所有测试件。这种方式如果使用不当，可能导致使用的测试件版本错误，所以其适用于有较完善的配置管理体系的情况。
不管采用哪种方式，都要注意控制测试件的更新，但要避免两个或更多的人同时试图修改同一配置项。关于测试件的存放，需要注意的是，必须规定好各测试件在配置库中的物理位置。
文章来源于领测软件测试网 https://www.ltesting.net/