不用 如果你创建所有类文件都在同一个包里，那么就直接写个test类，在test类中 直接使用你之前所创建类的就可以了，
前提是你的test类和其他的类在同一级目录中，不需要继承，也不需要接口的。
直接调用
比如你写了个类文件A.java
又写了个测试类test.java，且A和test在同一级目录
那么在test.java中直接使用就行
比如
test.java{
public static void main(args[]){
A a;
}
}
2. 我编写了个c++程序,如何编写测试程序,测试程序有哪些具体的要求你好！测试程序负责给编写好的程序提供样本数据，自动收集运行结果，并根据结果作出反馈。
测试程序可以单独写，也可以做为模块整合在源程序中。像我们熟知的debug语句，就是测试的最简单例子。
在没有“断电查看”这一功能之前，为了监测程序每步执行后变量的结果，往往加入一些输出关键变量的语句。例如以下程序：#incldue 通常会显示-89******00(0xcccccccc).一般这样的语句还会出现在对指针进行操作之后，用debug语句输出指针所指向内存的内容等。这只是测试程序的一个功能。 正如前面提到的，测试程序应该提供数据以检测程序的健壮性和安全性，以及用海量数据对执行效率进行检验等。测试数据的选择有以下几个要点，分别检测程序的不同特性：@ 尽可能包括输入集合内所有可能出现的元素，观察程序能否给出正确结果。 （Authenticity） 比如：有一个程序输入给定迷宫平面图，要测试出最短路径长度。那么输入的迷宫应该包括各种可能：有通路的和没有通路的，有死胡同的和没有的，有回路的（避免搜索时出现死循环），出口在左上角，右上角的等，都要考虑进去。 程序应该对每种情况都做出正确的反应。@ 注意测试极端情况以及临界情况。 （Security） 这是为了检测程序的健壮性，用户不可避免地会做出不合法的举动，程序需要有足够的防护强度来应对这些意外。 比如：如果编写了一个简易的计算器，那么一定要检查除数为0的情况；一个程序的功能是将一片文档的内容链接到另一个文档内，那么一定要检查自己链接自己的情况；等等。 @ 注意输入数据的规模以及随机性。（Efficiency） 衡量程序效率的标准应该考虑大规模数据下的表现。 数据需要有足够的随机性以避免意外情况。 比如：比较几种不同排序算法的效率时，选用的数据应该是随机顺序的。 在顺序数据的情况下：冒泡算法显然比快排还快，但这是偶然情况。@ 如果有可能，还可以检测程序的通用性及扩展性（Versatility & Compatibility） 好的程序应该易于扩展，可利用价值高。 大多数软件都在不停的打补丁，而不是推倒重写。 测试程序一般无法直接检测这两种特性。 然而，测试中出现的错误有时可以帮助我们提升程序的质量。 我曾经写过一个类似于美图秀秀的图像处理程序，C++写的，相当粗糙。 输入还要用命令行控制。当时我用各种图片进行了测试，包括纯色的，有明显背景色调的，以及完全混乱的噪声点。 前面的图片表现都很好，但处理最后一张图片时程序抛出了异常——经过检验发现，我的处理程序是基于24位图片写的，而最后一张图片是32位的。类似的情况还有32位系统和64位系统下程序运行的问题等，在此就不赘述了。 要编写测试程序，一般分为两个模块：数据生成和结果检测。测试程序的第一部分将生成的数据写入一个文件，让程序读取文件并运行后，再将结果写入另一个文件，之后由测试程序的第二部分比对输出文件和标准答案。 对于检测健壮性的测试程序，只需有第一部分即可，待检测程序在处理数据时如果发生异常，就根据结果作相应的修改。测试效率的程序，可以在待检程序内加入计时模块。 具体写法如下：#include 我一直在想，作为测试人员应该用脑袋去测试，也就是说应该在工作中不断的总结经验，把自己的发现应用到测试中去，这样你才能有真正的提高，你所具备的理论和能力才有竞争力。 回到测试用例中来，我觉得做好以下三点就是一个好的用例。 第一：依据分明 众所周知，一个项目首先立项，然后经过一系列的动作到了需求分析，昨晚需求分析后，测试就可以做测试需求，然后就可以写测试用例了。所以写测试用例的依据就是需求。这么说太笼统，举一个例子。一个系统经过前期的需求分析，详细设计，模块设计等一系列的动作，最后生成了详细的需求说明和详细设计文档等等，在这些文档中，已经很详细的描述了所有的需求点和功能点，也有较详细的技术说明，接下来的工作就是怎么把这些功能点和需求点变成测试点，这就需要做好测试需求分析和测试方案工作，生成一个个可测试的测试点。这也是需求必须可测的一个体现。 假设经过上一步工作，分析出这个系统有5个模块，50个大的功能点，500个具体需求点，最后生成了5000个测试点。那么 ok，我们就要写5000个测试用例。还是那句话，一个测试用例只能对应一个测试点，测试点和用例是1对1的关系；一个需求点可以对应多个用例，需求点和用例是1对多的关系。这样做的目的在统计中讲。 第二：目的明确 用例都有个测试目的，这就是要目的明确，并且也只能有一个目的。前面无论多少步骤，都是为了找到这个目的途径。功能从大到小有层次的划分，我们做测试用例也是有层次的，不然你怎么定义用例的优先级呢？等到测试最小的功能点是，支持这个功能点的其他上层功能点，我们都默认正确就可以了，这就是我们的预期，所以在测试步骤中不用对上层的功能专门考虑测试数据，只把他当成一个正确的找到目前的功能点的途径就行。换句话说，你要测试的功能点需要点10个连接才能找到，那么前9个连接我们再以前就应该设计了用例，在第10个连接中默认他们正确就ok，这个用例的前9步，只是告诉你如何找到第10步。就是这样。 第三：便于统计 测试用例对整个测试过程的质量控制和评估有很重要的意义。 一，可以做测试需求覆盖分析。这样如果一个用例写几个测试点，那么就无法完成需求覆盖分析工作，至少是不符合规则的。 你还可以通过模块划分，来分析哪个模块存在的问题较多，还有可能存在更多的问题（应为程序员不同，能力就不同，缺陷喜欢扎堆分布，这个大家都知道），存在问题较多的模块需要做进一步的测试或者下一次作为测试重点。如果你统计的数据不准确，会误导结果的。 三，做缺陷分析。用例失败了，就生成一个缺陷。 写好一个软件的测试用例62616964757a686964616fe78988e69d8331333337613764的建议有： 1、测试用例名称，也叫测试用例标题，一定要写得简洁、明了，需要用概括的语言描述该用例的出发点和关注点，使得测试人员第一眼看到测试用例名称就能够明白测试用例的目的。用例名称中一般要求不能存在假设性的语句，并且原则上每个用例的名称不能重复。 2、预置条件要明确，包括测试环境、测试数据、测试场景。因为许多BUG只有在特定的环境、特定的场景下才可以重现。没有正确的前提条件，就无法进行后面的测试步骤或无法得到预期的结果。 3、测试步骤描述要简单、清晰，并且要清楚每一个步骤的描述，比如：第一步，输入用户姓名；第二步，输入登录密码；第三步，用户点击登录。步骤写的明确时就利于提高用例的可操作性。 4、用例的预期结果要完整而且清晰，并且要将各个输出的结果写出来，包括：返回值的内容、数据库相关字段的记录、界面的响应结果、输出结果的规则符合度、日志的检查和对其它业务影响的检查。 5、测试用例级别要划分清楚，这样在测试执行时有主次之分。 6、测试用例的划分也要单一，一个测试用例只检查功能点的一种情况。一个用例检查的情况太多，会导致用例的目的不明确。而且这样组织用例，有利于需求覆盖率的统计。一个功能点我们测试了哪些情况，以及哪些功能点我们在重点测试，一目了然。 测试用例设计和执行是测试工作的核心，也是工作量最大的任务之一。 测试用例（Test Case）目前没有经典的定义。比较通常的说法是：指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。 测试用例编写准备 1 从配置管理员处申请软件配置：《需求规格说明书》和《设计说明书》； 2 根据需求规格说明书和设计说明书，详细理解用户的真正需求，并且对软件所实现的功能已经准确理解，然后着手制订测试用例。 测试用例制定的原则 1测试用例要包括欲测试的功能、应输入的数据和预期的输出结果。 2测试数据应该选用少量、高效的测试数据进行尽可能完备的测试。 用例覆盖 1正确性测试：输入用户实际数据以验证系统是满足需求规格说明书的要求；测试用 例中的测试点应首先保证要至少覆盖需求规格说明书中的各项功能，并且正常。 2容错性（健壮性）测试：程序能够接收正确数据输入并且产生正确（预期）的输出， 输入非法数据（非法类型、不符合要求的数据、溢出数据等），程序应能给出提示 并进行相应处理。把自己想象成一名对产品操作一点也不懂的客户，在进行任意操作。 3完整（安全）性测试：对未经授权的人使用软件系统或数据的企图，系统能够控制的程度，程序的数据处理能够保持外部信息（数据库或文件）的完整。 4接口间测试：测试各个模块相互间的协调和通信情况，数据输入输出的一致性和正确性。 5压力测试：输入10条记录运行各个功能，输入30条记录运行，输入50条记录进行测试。 6性能：完成预定的功能，系统的运行时间（主要是针对数据库而言）。 7可理解（操作）性：理解和使用该系统的难易程度（界面友好性）。 8可移植性：在不同操作系统及硬件配置情况下的运行性。 测试方法 1边界值分析法：确定边界情况（刚好等于、稍小于和稍大于和刚刚大于等价类边界值），针对我们的系统在测试过程中主要输入一些合法数据/非法数据，主要在边界值附近选取。 2等价划分：将所有可能的输入数据（有效的和无效的）划分成若干个等价类。 3错误推测：主要是根据测试经验和直觉，参照以往的软件系统出现错误之处。 测试用例的填写 1一个软件系统或项目共用一套完整的测试用例，整个系统测试过程测试完毕，将实际测试结果填写到测试用例中，操作步骤应尽可能的详细，测试结论是指最终的测试结果（结论为：通过或不通过）。 如何编写测试计划呢？测试计划要包括以下四个要点：1、待测试的内容；2、编写测试用例的时间；3、执行测试用例的时间；4、执行回归测试的时间。以上四点，待测试的内容可以需求分析中取得，需求分析中的测试要点就是要测试的内容，而其它3点就不是很容易确定了。因为我们可以从软件的开发进度中获得开始时间，但很难确定测试的结束的时间。下面有一个预估的办法，是大多数测试工程师的经验所得，我们拿到评审后的需求分析可以用下面的方法预估。 1、计算需求分析的页数，得出测试用例的页数，需求分许页数：测试用例页数 ≈ 1:1 2、由测试用例页数计算编写系统测试用例时间：编写系统测试用例时间 ≈ 系统测试用例页数*1小时 3、计算执行测试用例时间：编写测试用例用时：执行系统测试用时 ≈ 1:2 4、计算回归测试包含的时间：系统测试用时：回归测试用时≈ 2:1 以上的方法可能根据测试人员对项目熟悉程度和测试经验的不同而有所差别，大家可以根据自己的经验做出调整。计算出测试用例、执行测试和回归测试的时间后，根据软件项目的开发进度就可以编写出一个软件测试的时间表了。 不过从目前国内软件公司的现状来说，测试时间一般都不够，所以我们只能延长我们的工作时间，提高我们的工作效率。程序员说他们处于最底层，用户说要改什么，他们就要实现什么，没人关心他们的工作难度和工作时间。（发点牢骚，大家就当没看见，呵呵） 需要明确个问题，有没有有需求或者设计文档没？1，有的话按照文档写，将文档中的功能点摘录出来，按照功能点去写测试用例；2，没有文档，按照软件功能去写--那你们应该属于了解和学习阶段了：先了解软件功能，然后将软件的功能模块进行划分，梳理出来一个个功能点；这样有了功能点就可以进行测试用例编写了：1，测试用例的要包括操作步骤：怎么操作--把你的操作过程描述下来； 期望结果--软件设计的结果是什么--这个来自设计和平时的体验； 实际结果--在测试过程中按照步骤执行下来之后看到的结果；2，编写测试用例时将功能点进行划分，需要确认该功能点有几个测点，基本上做到一个测点一个case;3，测试用例要划分优先级和重要级别：软件功能主流程上的功能是重要级别最高的，而优先级一半配合开发过程和功能完善来确定：基本的要优先级最高，边角的可以优先级最低；LZ如果是个新手，建议将软件划分成小块，一个个的消化，其实测试最容易入门的方式就是将你作为使用者，这就是用例的来源。 希望能对你有帮助。 三、编制测试用例 着重介绍一些编制测试用例的具体做法。 1、测试用例文档 编写测试用例文档应有文档模板，须符合内部的规范要求。测试用例文档将受制于测试用例管理软件的约束。 软件产品或软件开发项目的测试用例一般以该产品的软件模块或子系统为单位，形成一个测试用例文档，但并不是绝对的。 测试用例文档由简介和测试用例两部分组成。 简介部分编制了测试目的、测试范围、定义术语、参考文档、概述等。测试用例部分逐一列示各测试用例。 每个具体测试用例都将包括下列详细信息：用例编号、用例名称、测试等级、入口准则、验证步骤、期望结果（含判断标准）、出口准则、注释等。以上内容涵盖了测试用例的基本元素：测试索引，测试环境，测试输入，测试操作，预期结果，评价标准。 2、测试用例的设置 我们早期的测试用例是按功能设置用例。后来引进了路径分析法，按路径设置用例。 目前演变为按功能、路径混合模式设置用例。 按功能测试是最简捷的，按用例规约遍历测试每一功能。 对于复杂操作的程序模块，其各功能的实施是相互影响、紧密相关、环环相扣的，可以演变出数量繁多的变化。没有严密的逻辑分析，产生遗漏是在所难免。 路径分析是一个很好的方法，其最大的优点是在于可以避免漏测试。 但路径分析法也有局限性。 在一个非常简单字典维护模块就存在十余条路径。一个复杂的模块会有几十到上百条路径是不足为奇的。 笔者以为这是路径分析比较合适的使用规模。若一个子系统有十余个或更多的模块，这些模块相互有关联。 再采用路径分析法，其路径数量成几何级增长，达5位数或更多，就无法使用了。那么子系统模块间的测试路径或测试用例还是要靠传统方法来解决。 这是按功能、路径混合模式设置用例的由来。 返回《软件测试术语及名词解释》。 呵呵，我刚写的一篇文章~专门讨论测试需求~~摘抄一些吧~1. 基本概念软件测试需求是根据测试目标而确定的被测软件的测试属性。 测试属性就是软件测试人员结合软件测试意图和被测软件本身的特点分析得到的测试对象、范围和内容等要素。其中软件测试意图指测试人员根据被测软件或系统的实际使用情况或者工作环境，考察被测软件功能性、可靠性、安全性、易用性等方面能力的想法。 软件测试类型是软件测试意图的具体表现。通过对测试模式的总结，并且从软件质量属性的角度进行分类，形成软件测试类型。 根据被测试对象的不同，软件测试可以分成不同的级别如单元测试、部件测试、配置项测试、系统测试等。软件系统测试需求则是软件测试需求在系统测试级别中的具体应用。 同理，软件系统测试类型也是软件测试类型在系统测试级别中的实例应用。在软件需求规格说明文档中，开发人员对各个软件需求点进行了描述，因此我们用{软件需求}表示依据软件需求点形成的矩阵，用符号 表示。 2.软件系统测试需求与软件需求的关系软件系统测试需求和软件需求的相同之处在于两者分析的对象都是软件系统，并且都是对其需求的描述。理想状态下，软件系统测试需求与软件需求应该是相同的，均是以用户需求为依据，对其进行全面阐述。 但是由于软件工程化水平的发展情况，以及实际操作过程中由于软件开发人员和软件测试人员从不同的角度分析和理解用户的需求，造成软件系统测试需求和软件需求现实上的差异。在实际操作过程中，软件需求主要是描述软件该实现什么样的功能或者该达到什么样的性能等用户的需求[2]。 软件需求与用户的需要有着十分紧密的关系，软件需求是本着实现用户需要的思想开展的，以满足用户需要为前提的。因此软件需求就是描述软件要做什么。 而软件系统测试需求又是从另外一个角度分析软件的。软件测试需求主要描述软件是否做了应该做的，同时没有做不该做的，也就是说从用户实际使用的角度出发，考察软件是否实现了用户的需求，同时考察软件对非用户需求的处理情况。 软件系统测试需求就是在系统测试这个测试级别上以软件需求为基础分析出的测试需求，它是进行软件系统测试活动的基础。欢迎讨论~~。
