测试用例优先级划分
从未有足够的时间做所有我们需要做的事情，这是在软件项目，尤其在测试中的一个普遍的话题。在可用的有限时间内，如何知道你的测试工作做的最好？当应用程序发布时，总会有些遗漏的缺陷没有被发现。对于测试而言，目标是通过改进产品质量使风险减到最小，这可以通过建造一套具体的测试用例来将应用程序按照它的速度完成等方法实现。
IEEE Standard 610 (1990) 中定义测试用例为：
1. 为一个特定目标而开发一组测试输入，执行条件和的期望结果，例如测试某个程序路径或核实是否满足某个特定的需求。
2.指定输入，预期结果和一组测试项的执行条件的文档(IEEE Std 829-1983)。
当然，你将发现在项目的生命周期里的每一个应用程序的版本上执行你全部的测试用例是很困难的。但是你将如何知道哪个测试用例必须在每一个版本中执行，什么应该被执行，同时如果你有时间的话，什么又可以被执行？
给你的测试用例划分优先级别
你的应用程序不需要十全十美，但它必须迎合你目标用户的需求和期望。为了了解你项目的期望，你需要确定什么是应用程序中最重要的，目标和风险又是什么。
Sue Bartlett在“How to Find the Level of Quality Your Sponsor Wants”一文中详细的讨论了这个问题，她在文中注解到：“当我们在详细的计划，设计或编码之前沟通质量目标时，我们有一个更好的机会来避免在最后时刻的质量不匹配，那意味着迎合计划，弥补花费并且赢利将有一个更好的成功的机会。”
为了测试计划的目的，在项目版本的进度下，测试执行过程中组织和安排你的测试用例将帮助达到这些目标。作为这种组织的一部分，我们要考虑每一个测试用例的优先级别。根据优先级别分组测试用例将帮助你决定不同类型的版本需要什么样的测试用例，因此计算需要的时间。如果你只有有限的时间，你可以查看什么是最合适。
Ross Collard在"Use Case Testing"一文中说：“测试用例的前10%到15%可以发现75%到90%的重要缺陷”。
测试用例的优先级划分将帮助确定找出了这前10%到15%的测试用例。
如何划分测试用例的优先级别
你曾查看过多少次你的测试用例并且能够很容易的挑选出最重要的一个小的子集？这个答案可能是不经常，停止思考“所有的测试用例都是同等重要”这个问题是非常困难的。当设计测
试用例时，分配优先级别是不容易的，并且在项目期间里用例的优先级不一定是静止的。然而，我们可以通过构造一个划分优先级别流程的例子来开始处理划分测试用例优先级别的第一步。让我们假设你刚刚根据功能说明书，用例和其他一些关于应用程序的目标行为和能力的信息源完成了设计测试用例。现在是时候来为每个测试用例分配一个优先级别了。
测试用例的优先级别
首先，你必须确定什么是你优先级别的类型和其暗示着什么。就我们的目的来说，我们将用一个假设开始，那就是我们可能发现的缺陷的严重程度和那些相应测试用例的优先级别之间是平行的。
1 –小版本确认测试（Build Verification Tests (BVTs)：也叫做“冒烟测试”，一组你想先运行的以确定这个给出的小版本是否可以测试的测试用例。如果你不能访问每一个功能区域或执行其他测试用例依赖的基本操作，那么在执行这个优先的测试用例之前，试图做其他任何的测试都是没有意义的，因为他们大多数肯定要失败。
2 –高（Highs）：最常执行以保证功能性是稳定的，目标的行为和能力可以正常的工作，和重要的错误和边界被测试的测试用例的集合。
3 –中（Mediums）：这是使给出的功能区域或功能变得更详细，检查功能的多数方面包括边界，错误和配置测试的测试用例
4 –低（Lows）：这是通常最少被执行的测试用例。但这并不意味着这些测试都不重要，只是说他们在项目的生命期间里不是常常被运行，例如GUI，错误信息，可用性，压力和性能测试。
我们将测试用例分成4类：BVTs，高，中和低。现在的问题是将测试用例分到不同的优先级别里。毕竟，优先级别将指出哪些测试用例被认为是需要更频繁的执行的，哪些又不是。
怎样着手分配优先级别
1) 随意地分配：
基于如果你没有足够的时间测试却又至少要保证所有的产品需求已经被确认可以在设想的良好状况下象它们被期望的那样工作的想法，前面这3 步将让你任意的分组测试用例，如果你也停下来思考每个测试用例的测试的内容，它们都将变的很重要。因此只需要：
I)把你所有功能性验证（或基本路径（Happy Path））的测试标注为高优先级别
II)把你所有错误和边界值或确认测试标注为中优先级别
III)把你所有非功能性的测试（例如性能和可用性）标注为低优先级别.
2) 提升和降级：
并非所有的功能性测试都一样的重要，并且和边界和非功能性测试一样的重要。思考一下测试的重要性及相对于其他同等优先级别的测试，你想要检查这个功能的频率－考虑质量目标和你项目的需求。
I)把功能性验证测试分为两组：重要和不是十分重要。
II)将“不是十分重要”的能性验证测试降级为中优先级别
III)把错误和边界测试分成两组：重要和不是十分重要
IV)将“重要”的错误和边界测试升级为高优先级别
V)把非功能性测试分成两组：重要和不是十分重要
VI)把“重要”的非功能性测试升级为中优先级别
VII)针对每组高，中和低优先级别的测试用例，重复划分和升级/降级流程直到你达到一个点，可以在不同优先级别之间移动的测试用例的数量到最小。
3) 识别小版本验证测试用例（Build Verification Tests）：
现在，为了确保小版本是可以测试的并准备好给小组其他成员开始测试，哪些测试用例是必须在每个小版本中都检查呢？
I)将好优先级别的测试用例分成两组：严重和重要的
II)将“严重”的高优先级的测试用例升级为BVT优先级
注意：不要先识别BVT测试用例！BVT只是高优先级别测试用例的精选，它们已经被确定为对系统和测试是非常重要的。
在这个流程的最后，就是要检查优先级别的百分比分布情况是：BVT为10-15%，高为
20-30%,，中为40-60%，低为10-15% 。
在升级和降级测试用例时，需要考虑的方面是用户将要求这个功能或功能性的频率是怎样。同样的，对于用户日常的或月尾的活动而言，这种行为的严重性是如何。Robyn Brilliant在测试进度报告中提供了一个清单，你可以在考虑降级或升级测试用例的时候使用
使用从一到五的一个刻度，从最严重到最少的严重程度，量化可靠性风险如下：
I)这个功能的失败将影响用户。
II)这个功能的失败将给公司造成重大的影响
III)这个功能的失败将引起一个潜在的延期给客户
IV)这个功能的失败对公司将有较小的影响
V)这个功能的失败没有任何影响
这个和其相似的刻度可以帮助你达到你测试用例优先级别划分的最后一步。
总结
这是一个简化的划分测试用例优先级别过程的例子。然而，在快速组织测试用例和安排测试进度和工作量，及制订项目计划时需要完成哪些测试用例等方面，它可以给你很多帮助。
记住，你怎样给你的测试任务划分优先级和如何执行测试用例将取决于你在你的项目周期的位置。当你朝发布前进并通过调查和观察确定危险和缺陷出现的地方时，你可能会重新给你的测试用例划分优先级别。向上为每个阶段建立你的测试目标并保证他们在你的测试用例的优先级别上被反映，当它在解释并执行你的计划时，将使你的生活变得容易得多。
最后，拥有划分了优先级别的测试用例也为你潜在的，待定的自动化项目给出了一个好的起点。比如，自动化BVT中的测试用例，度量收益，改进测试自动化，自动化高优先级的测试用例等方面。
编号： 密级： XXX大数据平台 性能测试方案 [V1-2.0] 拟制人： 审核人： 批准人： [2016年06月08日]
文件变更记录 *A - 增加M - 修订D - 删除 修改人摘要审核人备注版本号日期变更类型 （A*M*D） V2.0 2016-06-08 A 新建性能测试方案
目录 目录................................................................................................................................................................... I 1 引言 (1) 1.1编写目的 (1) 1.2测试目标 (1) 1.3读者对象 (1) 1.4 术语定义 (1) 2 环境搭建 (1) 2.1 测试硬件环境 (1) 2.2 软件环境 (2) 3 测试范围 (2) 3.1 测试功能点 (2) 3.2 测试类型 (2) 3.3性能需求 (3) 3.4准备工作 (3) 3.5 测试流程 (3) 4.业务模型 (4) 4.1 基准测试 (4) 4.1.1 Hadoop/ Spark读取算法的基准测试 (4) 4.1.2 Hadoop/ Spark写入算法的基准测试 (5) 4.1.3 Hadoop/ Spark导入算法的基准测试 (6) 4.1.4 Hadoop/ Spark导出算法的基准测试 (7) 4.2 负载测试 (8) 4.2.1 Hadoop/ Spark并行读取/写入算法的负载测试 (8) 4.2.2 Hadoop/ Spark并行导入/导出算法的负载测试 (9) 4.3 稳定性测试 (10) 4.3.1 Hadoop/ Spark并行读取/写入/导入/导出算法，7*24小时稳定性测试 (10) 5 测试交付项 (12) 6 测试执行准则 (12) 6.1 测试启动 (12) 6.2 测试执行 (12) 6.3 测试完成 (13) 7 角色和职责 (13) 8 时间及任务安排 (13) 9 风险和应急 (14) 9.1影响方案的潜在风险 (14) 9.2应急措施 (14)
测试用例编写之等价类划分法 一、概念 等价类划分法指把所有可能的输入数据，即程序的输入域分成若干个部分(子集)后，从每个子集中选取少数具有代表性的数据作为测试用例的方法。是一种重要且常用的黑盒测试的测试用例设计方法。 二、等价类划分 等价类可分为两种情况：有效等价类与无效等价类。有效等价类是指：对程序的规格说明是有意义的、合理的输入数据所构成的集合；无效等价类意义与之相反。 三、确定等价类的规则 如何确定等价类，这是使用等价类划分方法的一个重要问题。等价类的划分在很大程度上是试探性的，一般规则如下： 1）如果输入条件规定了取值的范围或取值的个数（[0，99]），则可确定一个有效等价类和两个无效等价类（<0 ；[0，99]；>99）； 2）如果一个输入条件说明了一个“必须成立的”情况（如变量名必须以字母开头），则可划分一个有效等价类（以字母开头）和一个无效等价类（不以字母开头）； 3）如果输入条件规定了输入数据的一组可能的值，而且程序是用不同的方式处理每一种值，则可为每一种值划分一个有效等价类，并划分一个无效等价类； 4）如果某个输入条件规定了一个输入值得离合(即离散值)，且程序对不同的输入值做不同的处理，那么每个允许的值确定为一个有效等价类，另外还有一个无效等价类。（任意一个不允许输入的值、）例：优、良、中、差，则此时有4个有效等价类和1个无效等价类(非优、良、中、差的值就为无效) 5）如果某个输入条件规定输入数据是整型，那么可以确定3个有效等价类（正整数、零、负整数）和一个无效等价类（非整数）。 6）如果某个输入条件规定处理的对象是表格，那么可确定一个有效等价类(表有1项或多项)和一个无效等价类(空表)。 7）如果能够确知，已划分的某等价类中的各元素在程序中的处理方式是不同的，则应据此将此等价类进一步划分成更小的等价类。 四、建立步骤 根据已列出的等价类表，按以下步骤确定测试用例： 1) 为每个等价类规定一个唯一的编号； 2) 设计一个测试用例，使其尽可能多地覆盖尚未覆盖的有效等价类，重复这一步，最后使得所有的有效等价类都被测试用例所覆盖；
测试用例优先级划分 从未有足够的时间做所有我们需要做的事情，这是在软件项目，尤其在测试中的一个普遍的话题。在可用的有限时间内，如何知道你的测试工作做的最好？当应用程序发布时，总会有些遗漏的缺陷没有被发现。对于测试而言，目标是通过改进产品质量使风险减到最小，这可以通过建造一套具体的测试用例来将应用程序按照它的速度完 成等方法实现。 IEEE Standard 610 (1990) 中定义测试用例为： 1. 为一个特定目标而开发一组测试输入，执行条件和的期望结果，例如测试某个程序路径或核实是否满足某个特定的需求。 2.指定输入，预期结果和一组测试项的执行条件的文档(IEEE Std 829-1983)。 当然，你将发现在项目的生命周期里的每一个应用程序的版本上执行你全部的测试用例是很困难的。但是你将如何知道哪个测试用例必须在每一个版本中执行，什么应该被执行，同时如果你有时间的话，什么又可以被执行？ 给你的测试用例划分优先级别 你的应用程序不需要十全十美，但它必须迎合你目标用户的需求和期望。为了了解你项目的期望，你需要确定什么是应用程序中最重要的，目标和风险又是什么。
Sue Bartlett在“How to Find the Level of Quality Your Sponsor Wants”一文中详细的讨论了这个问题，她在文中注解到：“当我们在详细的计划，设计或编码之前沟通质量目标时，我们有一个更好的机会来避免在最后时刻的质量不匹配，那意味着迎合计划，弥补花费并且赢利将有一个更好的成功的机会。” 为了测试计划的目的，在项目版本的进度下，测试执行过程中组织和安排你的测试用例将帮助达到这些目标。作为这种组织的一部分，我们要考虑每一个测试用例的优先级别。根据优先级别分组测试用例将帮助你决定不同类型的版本需要什么样的测试用例，因此计算需要的时间。如果你只有有限的时间，你可以查看什么是最合适。 Ross Collard在"Use Case Testing"一文中说：“测试用例的前10%到15%可以发现75%到90%的重要缺陷”。 测试用例的优先级划分将帮助确定找出了这前10%到15%的测试用例。 如何划分测试用例的优先级别 你曾查看过多少次你的测试用例并且能够很容易的挑选出最重要的一个小的子集？这个答案可能是不经常，停止思考“所有的测试用例都是同等重要”这个问题是非常困难的。当设计测试用例时，分配优先级别是不容易的，并且在项目期间里用例的优先级不一定是静止的。然而，我们可以通过构造一个划分优先级别流程的例子来开始处理划分测试用例优先级别的第一步。让我们假设你刚刚根据功能说明书，用例和其他一些关于应用程序的目标行为和能力的信息源完
三角形测试用例 题目：输入三个数a、b、c分别作为三边的边长构成三角形。通过程序判定所构成的三角形是一般三角形、等腰三角形还是等边三角形时。用等价类划分方法为该程序设计测试用例。 在三角形计算中，要求三角形的三个边长：A B C。 1、当三边不可能构成三角形时提示错误，可构成三角形时计算三角形周长。 2、若是等腰三角形打印“等腰三角形”，若两个等腰的平方和等于第三边平方和，则打印“等腰直角三角形”。 3、若是等边三角形，则打印：“等边三角形”。 4、画出程序流程图并设计一个测试用例。 分析一下： 1、构成三角形的条件：任意两边之和大于第三边； 2、构成等腰三角形的条件：任意两边相等； 3、构成等腰直角三角形的条件：任意两边相等，而且两条边的平方和等于第三边的平方和； 4、构成等边三角形的条件：三条边都相等。 那么用什么样的设计方法进行测试用例的设计呢？ 一、等价类划分：三角形三条边A、B、C的数据类型不同 二、边界值分析：由于三角形的边长可以是正整数或正小数，所以就不对长度进行测试，那么边界值分析就不用了 三、因果图法：三角形的三条边数据输入组合 我们看一下三角形的流程图： 注：改正一个小错误，在判断是否是等腰直角三角形中 A的平方=B的平方+C的平方。由于画图时，网络速度问题，导致真或假的值没有标注。 三角形等价类列表 判定类型有效等价类 无效等价类
一般三角形 ((a>0) Λ(b>0) Λ(c>0))Λ (a<=0 V b<=0 V c<=0) Λ (((a+b)>c) V ((a+c)>b) V ((b+c)>a)) (1) (((a+b)<=c) V ((a+c)<=b) V ((b+c)<=a)) (2) 等腰三角形 (1) Λ (a=b V a=c V b=c)(3) (2) V (a!=b Λ b!=c Λ a!=c) (4) 等边三角形 (1) Λ (a=b=c ) (5) (2) V (a!=b!=c)(6) 根据上表组成的测试用例： 三角形等价类测试用例 ID 输入数据覆盖测试用例输出结果 a b c 1 3 4 5 (1) 一般三角形 2 0 4 5 (2) 非(一般)三角形 3 3 0 5 (2) 4 3 4 0 (2) 5 1 4 5 (2) 6 3 8 5 (2) 7 3 2 1 (2) 8 3 3 5 (3) 等腰三角形 9 3 4 3 10 3 4 4 #include
性能测试用例主要分为预期目标用户测试，用户并发测试，疲劳强度与大数据量测试，网络性能测试，服务器性能测试五大部分，具体编写测试用例时要根据实际情况进行裁减，在项目应用中遵守低成本，策略为中心，裁减，完善模型，具体化等原则；一、WEB 全面性能测试模型 Web 性能测试模型提出的主要依据是：一种类型的性能测试可以在某些条件下转化成为另外一种类型的性能测试，这些类型的性能测试的实施是有着相似之处的； 1. 预期指标的性能测试 系统在需求分析和设计阶段都会提出一些性能指标，完成这些指标的相关的测试是性能测试的首要工作之一，这些指标主要诸于“系统可以支持并发用户200个；”系统响应时间不得超过20秒等，对这种预先承诺的性能要求，需要首先进行测试验证； 2. 独立业务性能测试 独立业务实际是指一些核心业务模块对应的业务，这些模块通常具有功能比较复杂，使用比较频繁，属于核心业务等特点。 用户并发测试是核心业务模块的重点测试内容，并发的主要内容是指模拟一定数量的用户同时使用某一核心的相同或者不同的功能，并且持续一段时间。对相同的功能进行并发测试分为两种类型，一类是在同一时刻进行完全一样的操作。另外一类是在同一时刻使用完全一样的功能。 3. 组合业务性能测试 通常不会所有的用户只使用一个或者几个核心业务模块，一个应用系统的每个功能模块都可能被使用到；所以WEB性能测试既要模拟多用户的相同操作，又要模拟多用户的不同操作；组合业务性能测试是最接近用户实际使用情况的测试，也是性能测试的核心内容。通常按照用户的实际使用人数比例来模拟各个模版的组合并发情况；组合性能测试是最能反映用户使用情况的测试往往和服务器性能测试结合起来，在通过工具模拟用户操作的同时，还通过测试工具的监控功能采集服务器的计数器信息进而全面分析系统瓶颈。 用户并发测试是组合业务性能测试的核心内容。组合并发的突出特点是根据用户使用系统的情况分成不同的用户组进行并发，每组的用户比例要根据实际情况来匹配； 4. 疲劳强度性能测试 疲劳强度测试是指在系统稳定运行的情况下，以一定的负载压力来长时间运行系统的测试，其主要目的是确定系统长时间处理较大业务量时的性能，通过疲劳强度测试基本可以判定系统运行一段时间后是否稳定； 5. 大数据量性能测试 一种是针对某些系统存储，传输，统计查询等业务进行大数据量时的性能测试，主要针对某些特殊的核心业务或者日常比较常用的组合业务的测试； 第二种是极限状态下的数据测试，主要是指系统数据量达到一定程度时，通过性能测试来评估系统的响应情况，测试的对象也是某些核心业务或者常用的组合业务。 第三种大数据量测试结合了前面两种的测试，两种测试同时运行产生较大数据量的系统性能测试；大数据量测试通常在投产环境下进行，并独立出来和疲劳强度测试放在一起，在整个性能测试的后期进行；大数据量的测试可以理解为特定条件下的核心业务或者组合业务测试； 6. 网络性能测试 主要是为了准确展示带宽，延迟，负载和端口的变化是如何影响用户的响应时间的，在实际的软件项目中 主要是测试应用系统的用户数目与网络带宽的关系。网络测试的任务通常由系统集成人员完成； 7. 服务器（操作系统，WEB服务器，数据库服务器）性能测试 初级服务器性能测试主要是指在业务系统工作或者进行前面其他种类性能测试的时候，监控服务器的一些计数器信息，通过这些计数器对服务器进行综合性能分析，为调优或提高系
分析题目中给出和隐含的对输入条件的要求： （1）整数 （2）三个数 （3）非零数 （4）正数 （5）两边之和大于第三边 （6）等腰 （7）等边 如果 a 、 b 、 c 满足条件（ 1 ） ~ （ 4 ），则输出下列四种情况之一： 1)如果不满足条件（5），则程序输出为 " 非三角形 " 。 2)如果三条边相等即满足条件（7），则程序输出为 " 等边三角形 " 。 3)如果只有两条边相等、即满足条件（6），则程序输出为 " 等腰三角形 " 。 4)如果三条边都不相等，则程序输出为 " 一般三角形 " 。 列出等价类表并编号 覆盖有效等价类的测试用例： a b c 覆盖等价类号码 3 4 5 （1）--（7） 4 4 5 （1）--（7），（8） 4 5 5 （1）--（7），（9） 5 4 5 （1）--（7），（10） 4 4 4 （1）--（7），（11） 覆盖无效等价类的测试用例： 2. 设有一个档案管理系统，要求用户输入以年月表示的日期。假设日期限定在1990 年1月~2049年12月，并规定日期由6位数字字符组成，前4位表示年，后2位表示月。现用等价类划分法设计测试用例，来测试程序的"日期检查功能 "。（不考虑2月的问题） 1)划分等价类并编号,下表等价类划分的结果
2)设计测试用例，以便覆盖所有的有效等价类在表中列出了3个有效等价类，编号分 别为①、⑤、⑧，设计的测试用例如下： 测试数据期望结果覆盖的有效等价类 200211 输入有效①、⑤、⑧ 3)为每一个无效等价类设计一个测试用例，设计结果如下： 测试数据期望结果覆盖的无效等价类 95June 无效输入② 20036 无效输入③ 2001006 无效输入④ 198912 无效输入⑥ 200401 无效输入⑦ 200100 无效输入⑨ 200113 无效输入⑩ 3.NextDate 函数包含三个变量：month 、 day 和 year ，函数的输出为输入日期 后一天的日期。例如，输入为 2006年3月 7日，则函数的输出为 2006年3月8日。 要求输入变量 month 、 day 和 year 均为整数值，并且满足下列条件： ①1≤month≤12 ②1≤day≤31 ③1920≤year≤2050 1)有效等价类为： M1＝{月份：1≤月份≤12} D1＝{日期：1≤日期≤31} Y1＝{年：1812≤年≤2012} 2)若条件① ~ ③中任何一个条件失效，则 NextDate 函数都会产生一个输出，指明相 应的变量超出取值范围，比如 "month 的值不在 1-12 范围当中 " 。显然还存在着大量的 year 、 month 、 day 的无效组合， NextDate 函数将这些组合作统一的输出： " 无效输入日期 " 。其无效等价类为： M2＝{月份：月份<1} M3＝{月份：月份>12} D2＝{日期：日期<1} D3＝{日期：日期>31} Y2＝{年：年<1812} Y3＝{年：年>2012} 弱一般等价类测试用例 月份日期年预期输出 6 15 1912 1912年6月16 日 强一般等价类测试用例同弱一般等价类测试用例
Hadoop大数据平台测试报告及成功案例
目录 1技术规范书应答书 ................................. 错误！未定义书签。2技术方案建议 ......................................... 错误！未定义书签。3测试及验收 ............................................. 错误！未定义书签。4项目实施与管理 ..................................... 错误！未定义书签。5人员资质与管理 ..................................... 错误！未定义书签。6技术支持及保修 ..................................... 错误！未定义书签。7附录 ......................................................... 错误！未定义书签。
1.1 大数据平台测试报告 1.1.1某银行Cloudera CDH 性能测试测试 某银行现有HODS在支撑行内业务方面已经遇到瓶颈。希望通过搭建基于Hadoop 的历史数据平台(新HODS)，以提升平台运行效率及数据覆盖面，支撑未来大数据应用，满足未来业务发展需求。本次POC测试的主要目的是验证Hadoop商业发行版(EDH) 是否可以满足某银行HODS应用特点，主要考察点包括： ?验证产品本身的易用性、可扩展性，主要涉及集群的部署、运维、监控、升级等； ?验证产品对安全性的支持，包括认证、授权、审计三大方面； ?验证产品对资源分配的控制与调度； ?验证Hadoop基本功能，包括可靠性、稳定性、故障恢复等； ?验证Hadoop子系统(包括HDFS、HBase、Hive、Impala等) 的性能、使用模式、设计思想、迁移代价等。 1.1.1.1基础设施描述 1.1.1.1.1硬件配置 硬件配置分为两类：管理节点(master node) 与计算节点(worker node)。 管理节点配置(2) CPU Intel? Xeon? E5-2650 v3 2.3GHz,25M Cache,9.60GT/s QPI,Turbo,HT,10C/20T (105W) Max Mem 2133MHz (40 vcore) 内存16GB RDIMM, 2133MT/s, Dual Rank, x4 Data Width (128GB) 网络Intel X520 DP 10Gb DA/SFP+ Server Adapter, with SR Optics
三角形问题的等价类测试用例 四种可能出现的输出：非三角形、不等边三角形、等腰三角形和等边三角形 可以使用这些输出标识如下所示的输出（值域）等价类： R1={〈a，b，c〉：有三条边a、b和c的等边三角形} R2={〈a，b，c〉：有三条边a、b和c的等腰三角形} R3={〈a，b，c〉：有三条边a、b和c的不等边三角形} R4={〈a，b，c〉：三条边a、b和c不构成三角形} 四个弱一般等价类测试用例是： 测试用例 a b c 预期输出 WN1 5 5 5 等边三角形 WN2 2 2 3 等腰三角形 WN3 3 4 5 不等边三角形 WN4 4 1 2 非三角形 由于变量a、b和c没有有效区间，则强一般等价类测试用例与弱一般等价类测试用例相同。 考虑a、b和c的无效值产生的以下额外弱健壮等价类测试用例： 测试用例 a b c 预期输出 WR1 -1 5 5 a取值不在所允许的取值值域内 WR2 5 -1 5 b取值不在所允许的取值值域内 WR3 5 5 -1 c取值不在所允许的取值值域内 WR4 201 5 5 a取值不在所允许的取值值域内 WR5 5 201 5 b取值不在所允许的取值值域内 WR6 5 5 201 c取值不在所允许的取值值域内以下是额外强健壮性等价类测试用例三维立方的一个“角”： 测试用例 a b c 预期输出 SR1 -1 5 5 a取值不在所允许的取值值域内 SR2 5 -1 5 b取值不在所允许的取值值域内 SR3 5 5 -1 c取值不在所允许的取值值域内 SR4 -1 -1 5 a、b取值不在所允许的取值值域内 SR5 5 -1 -1 b、c取值不在所允许的取值值域内 SR6 -1 5 -1 a、c取值不在所允许的取值值域内 SR7 -1 -1 -1 a、b、c取值不在所允许的取值值域内
测试用例实例 （含：功能测试用例、性能测试用例、兼容性测试用例） 目录 一、功能测试用例................................................................................. - 2 - 二、性能测试......................................................................................... - 9 - 2.1预期性能测试用例.................................................................... - 9 - 2.2 用户并发测试用例................................................................. - 10 - 2.3 大数据量测试用例................................................................. - 10 - 2.4 疲劳强度测试用例................................................................. - 11 - 2.5 负载测试测试用例................................................................. - 11 - 三、兼容性测试................................................................................... - 11 - 用例编号TestCase_LinkWorks_WorkEvaluate 项目名称LinkWorks 模块名称WorkEvaluate模块 项目承担部门研发中心-质量管理部 用例作者 完成日期2005-5-27 本文档使用部门质量管理部 评审负责人 审核日期 批准日期 注：本文档由测试组提交，审核由测试组负责人签字，由项目负责人批准。 历史版本： 版本/状态作者参与者起止日期备注 V1.1
如何对大数据软件产品进行测试 前言 本文仅考虑大数据产品的系统以及验收阶段的测试，而不考虑单元及集成阶段的测试，我认为大数据产品在单元及集成阶段的测试应该与普通产品的测试没有多大区别。 案例 本文以该案例作为讨论对象：小x网是专门从事儿童用品的网上超市，随着大数据的 普及，小x网决定在网站内推出一个新功能：即根据某人的历史购物情况以及购买同类产 品人的购物情况，对单一用户进行定向产品推荐。这个功能的实现无疑需要用到大数据的 技术，但是作为一门黑盒测试工程师，我们无需了解开发人员是如何用什么技术实现的， 而我们只需要考虑的问题是：对这个客户推荐的产品是否合理。比如这个用户家里有个男孩，经常在小象网上买一些男孩类的产品，而你推荐的产品而是一条裙子，这显而易见是 不合适的。 对产品刚下线时的测试： 这个时候我们需要基于场景简单的设计一些测试用例，进行测试，比如： 1.顾客王斌曾经为他的宝宝购买十个汽车模型玩具，其他产品从来没有购买过。现在 添加一条新的汽车模型玩具产品，测试是否可以推荐给了顾客王斌； 2.顾客李湘在大象网上曾经购买了一条连衣裙给她的宝贝女儿，而购买这条连衣裙的 其他4名顾客还给他们家公主购买了芭比娃娃玩具。当顾客李湘再次登录大象网，看看我们是否给李湘推荐了芭比娃娃玩具。 3.然后我们可以逐步增加难度，比如顾客李悦在大象网上为她公主购买衣服，玩具， 幼儿食品三类产品；顾客张蕾和顾客李悦在网上购买的产品类型差不多。检查系统能否把 张蕾和李悦归为一类人群，即把张蕾购买的一些产品介绍给李悦；而把李悦购买的一些产 品介绍给张蕾。 4.最后我们逐步增加用户以及产品的数量来，设计更加复杂的测试用例，在这里希望 大家自己考虑。 5.当产品的数量与客户的数量达到一定的数量级别，我们可以把系统放在正式环境下 进行测试（当然需要用到云），用户数据来自于正式的用户环境，但是这时在页面上的接 口不要放开，在正式环境下来进行测试，这个时候我们可能会发现一些软件缺陷。 6.当我们通过以上5步，认为产品可以正式上线了，通过网页上打开这个功能。给用 户提供一个使用该功能的反馈渠道，用户在实际使用过程中使用会遇到一写问题，通过反 馈渠道反馈给我们，我们客户以及时修复。 对升级产品进行测试： 大数据产品往往有两种部署场景： 1）处理出来的数据放在本地，而云端仅仅用来计算，存储log等信息； 2）所有处理都在云端进行处理，处理出来的数据也放在云端 首先让我们来看看情形1）如何来进行测试和版本更新。
等价类划分 商品之间的等价交换 1、价值规律的基本内容 ①商品生产要遵循商品的价值量由社会必要劳动时间决定——商品的价值量 由生产商品的社会必要劳动时间决定。 ②商品交换要遵循等价交换原则——以价值量为基础，实行等价交换。 2、价值规律表现形式：价格受供求关系影响围绕价值上下波动。 ①价值规律的表现形式也称价值规律的实现形式和发生作用的形式。 ②等价交换是商品交换的一个重要原则。“等价”是指交换双方商品的价值都 要相等，即各自商品所消耗的社会必要劳动时间相等。货币出现以后，商品的价格却由货币来衡量，表现为价格。等价交换也就是要求商品的价格应该与价值相符合，因为价格由价值决定。 ③在现实生活中，价格与价值经常不一致，这是由商品的供求关系的变化引 起的，使价格上涨或下跌；反过来，价格的上涨或下跌也会影响供求关系，使供求趋于平衡，从而使价格接近价值。 ④由于价格与供求之间存在着相互制约的关系，这样就会产生以下情况： 第一：价格的上涨和下跌，都不会距离价值太远，它总是围绕价值上下波动。 第二：从一个较长时间来看，从全社会来看，商品的平均价格还是与它的价值相一致。 ⑤价格围绕价值上下波动表明：社会必要劳动时间决定价值量这一内容，始 终作为一种趋势，作为一个规律在贯彻着。所以，价值规律的表现形式不仅不违背规律，反而正是价值规律的表现形式，而且是唯一的表现形式。价值规律基本内容和表现形式是一致的，价格围绕价值上下波动就是价值规律基本内容的外在表现，价格和价值相符的本质，在实际交换中只能通过价格围绕价值波动这种形式才能实现。价格最终还是由价值决定。 等价类划分 等价类划分法是一种典型的、重要的黑盒测试方法，它将程序所有可能的输入数据（有效的和无效的）划分成若干个等价类。然后从每个部分中选取具有代表性的数据当做测试用例进行合理的分类，测试用例由有效等价类和无效等价类的代表组成，从而保证测试用例具有完整性和代表性。利用这一方法设计测试用例可以不考虑程序的内部结构，以需求规格说明书为依据，选择适当的典型子集，认真分析和推敲说明书的各项需求，特别是功能需求，尽可能多地发现错误。等价类划分法是一种系统性的确定要输入的测试条件的方法。由于等价类是在需求规格说明书的基础上进
测试用例设计方法 1等价类划分 1.1 理论知识 等价类划分是一种典型的黑盒测试方法。这一方法完全不考虑程序的内部结构，只依据程序的规格说明来设计测试用例。 等价类是指某个输入域的子集合。在该子集合中，各个输入数据对于揭示程序中的错误都是等效的。 等价类合理地假设：某个等价类的代表值，与该等价类的其他值，对于测试来说是等价的。 因此，可以把全部的输入数据划分成若干的等价类，在每一个等价类中取一个数据来进行测试。这样就能以较少的具有代表性的数据进行测试，而取得较好的测试效果。 等价类划分是把所有可能的输入数据,即程序的输入域划分成若干部分（子集）,然后从每一个子集中选取少数具有代表性的数据作为测试用例.该方法是一种重要的,常用的黑盒测试用例设计方法. 1) 分类： 划分等价类: 等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:有效等价类和无效等价类. 有效等价类:是指对于程序的规格说明来说是合理的,有意义的输入数据构成的集合.利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能. 无效等价类:与有效等价类的定义恰巧相反. 设计测试用例时,要同时考虑这两种等价类.因为,软件不仅要能接收合理的数据,也要能经受意外的考验.这样的测试才能确保软件具有更高的可靠性. 2）划分等价类的方法: 下面给出六条确定等价类的原则： ①在输入条件规定了取值范围或值的个数的情况下,则可以确立一个有效等价类和两个无效等价类. ②在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下,可确立一个有效
如何设计和执行测试用 例 Pleasure Group Office【T985AB-B866SYT-B182C-BS682T-STT18】
如何设计和执行测试用例测试需求收集完毕后，开始测试设计。 测试用例是什么测试用例就是一个文档，描述输入、动作、或者时间和一个期望的结果，其目的是确定应用程序的某个特性是否正常的工作。设计测试用例需要考虑以下问题： 测试用例的基本格式： 软件测试用例的基本要素包括测试用例编号、测试标题、重要级别、测试输入、操作步骤、预期结果，下面逐一介绍。 用例编号：测试用例的编号有一定的规则，比如系统测试用例的编号这样定义规则： PROJECT1-ST-001 ，命名规则是项目名称+测试阶段类型(系统测试阶段)+编号。定义测试用例编号，便于查找测试用例，便于测试用例的跟踪。 测试标题：对测试用例的描述，测试用例标题应该清楚表达测试用例的用途。比如“测试用户登录时输入错误密码时，软件的响应情况”。 重要级别：定义测试用例的优先级别，可以笼统的分为“高”和“低”两个级别。一般来说，如果软件需求的优先级为“高”，那么针对该需求的测试用例优先级也为“高” ;反之亦然， 测试输入：提供测试执行中的各种输入条件。根据需求中的输入条件，确定测试用例的输入。测试用例的输入对软件需求当中的输入有很大的依赖性，如果软件需求中没有很好的定义需求的输入，那么测试用例设计中会遇到很大的障碍。
操作步骤：提供测试执行过程的步骤。对于复杂的测试用例，测试用例的输入需要分为几个步骤完成，这部分内容在操作步骤中详细列出。 预期结果：提供测试执行的预期结果，预期结果应该根据软件需求中的输出得出。如果在实际测试过程中，得到的实际测试结果与预期结果不符，那么测试不通过;反之则测试通过。 软件测试用例的设计主要从上述 6 个域考虑，结合相应的软件需求文档，在掌握一定测试用例设计方法的基础上，可以设计出比较全面、合理的测试用例。具体的测试用例设计方法可以参见相关的测试书籍，白盒测试方法和黑盒测试方法在绝大多数的软件测试书籍中都有详细的介绍。 一般来说，每个软件公司的项目可以分为固定的几大类。可以按业务类型划分，比如 ERP 软件、产品数据管理软件、通信软件、地理信息系统软件等等;可以按软件结构来划分，比如 B/S 架构的软件、 C/S 架构的软件、嵌入式软件等等。参考同类别软件的测试用例，会有很大的借鉴意义。如果，公司中有同类别的软件系统，千万别忘记把相关的测试用例拿来参考。如果，系统非常接近，甚至经过对测试用例简单修改就可以应用到当前被测试的软件。“拿来主义”可以极大的开阔测试用例设计思路，也可以节省大量的测试用例设计时间。 加强测试用例的评审： 测试用例设计完毕后，最好能够增加评审过程。 同行评审是 CMM3 级的一个 KPA ，如果因为公司没有通过 CMM3 级，就不开展同行评审是不恰当的。测试用例应该由产品相关的软件测试人员和软件开发人员评审，提交评审意见，然后根据评审意见更新测试用
用例编号XXX-XXX-XXXX 项目名称XXXX 模块名称XXXX模块 项目承担部门XXXX部 用例作者 完成日期2014-12-24 本文档使用部门XXXX部 评审负责人 审核日期 批准日期 注：本文档由测试组提交，审核由测试组负责人签字，由项目负责人批准。历史版本：
一、功能测试用例 此功能测试用例对测试对象的功能测试应侧重于所有可直接追踪到用例或业务功能和业务规则的测试需求。这种测试的目标是核实数据的接受、处理和检索是否正确，以及业务规则的实施是否恰当。主要测试技术方法为用户通过GUI（图形用户界面）与应用程序交互，对交互的输出或接受进行分析，以此来核实需求功能与实现功能是否一致。
二、性能测试 性能测试是一种对响应时间、事务处理速率和其他与时间相关的需求进行测试和评估。性能测试的目标是核实性能需求是否都已满足。可以分为以下几种进方式来组织进行测试。1.1.预期性能测试用例 通常系统在设计前会提出一些性能指标，这些指标是性能测试要完成的首要工作，针对每个指标都要统写多个测试用例来验证是否达到要求，根据测试结果来改进系统的性能。预期性
能指标通常以单用户为主。 1.2.用户并发测试用例 用户并发测试是性能测试最主要的部分，主要是通过增加用户数量来加重系统负担，以检验测试对象能接收的最大用户数来确定功能是否达到要求。
1.3.大数据量测试用例 大数据量测试是测试对象处理大量的数据，以确定是否达到了将使软件发生故障的极限。大数据量测试还将确定测试对象在给定时间内能够持续处理的最大负载或工作量。 1.4.疲劳强度测试用例 强度测试也是性能测试是的一种，实施和执行此类测试的目的是找出因资源不足或资源争用而导致的错误。如果内存或磁盘空间不足，测试对象就可能会表现出一些在正常条件下并不明显的缺陷。而其他缺陷则可能由于争用共享资源（如数据库锁或网络带宽）而造成的。强
等价类划分法实例
1.某程序规定："输入三个整数 a 、 b 、 c 分别作为三边的边长构成三角形。通过程序 判定所构成的三角形的类型，当此三角形为一般三角形、等腰三角形及等边三角形时，分别作计算… "。用等价类划分方法为该程序进行测试用例设计。（三角形问题 的复杂之处在于输入与输出之间的关系比较复杂。） 分析题目中给出和隐含的对输入条件的要求： （1）整数（2）三个数（3）非零数（4）正数 （5）两边之和大于第三边（6）等腰（7）等边 如果 a 、 b 、 c 满足条件（ 1 ） ~ （ 4 ），则输出下列四种情况之一： 1)如果不满足条件（5），则程序输出为 " 非三角形 " 。 2)如果三条边相等即满足条件（7），则程序输出为 " 等边三角形 " 。 3)如果只有两条边相等、即满足条件（6），则程序输出为 " 等腰三角形 " 。 4)如果三条边都不相等，则程序输出为 " 一般三角形 " 。 列出等价类表并编号
覆盖有效等价类的测试用例： a b c 覆盖等价类号码 3 4 5 （1）--（7） 4 4 5 （1）--（7），（8）
4 5 5 （1）--（7），（9） 5 4 5 （1）--（7），（10） 4 4 4 （1）--（7），（11） 覆盖无效等价类的测试用例： 2.设有一个档案管理系统，要求用户输入以年月表示的日期。假设日期限定在1990年 1月~2049年12月，并规定日期由6位数字字符组成，前4位表示年，后2位表示月。现用等价类划分法设计测试用例，来测试程序的"日期检查功能"。（不考虑2月的问题） 1)划分等价类并编号,下表等价类划分的结果 输入等价类有效等价类无效等价类
大数据应用案例分析
在如今这个大数据的时代里，人人都希望能够借助大数据的力量：电商希望能够借助大数据进一步获悉用户的消费需求，实现更为精准的营销;网络安全从业者希望通过大数据更早洞悉恶意攻击者的意图，实现主动、超前的安全防护;而骇客们也在利用大数据，更加详尽的挖掘出被攻击目标信息，降低攻击发起的难度。 大数据应用最为典型的案例是国外某著名零售商，通过对用户购买物品等数据的分析，向该用户——一位少女寄送了婴儿床和衣服的优惠券，而少女的家人在此前对少女怀孕的事情一无所知。大数据的威力正在逐步显现，银行、保险公司、医院、零售商等等诸多企业都愈发动力十足的开始搜集整理自己用户的各类数据资料。但与之相比极度落后的数据安全防护措施，却让骇客们乐了：如此重要的数据不仅可以轻松偷盗，而且还是整理好的，凭借这些数据骇客能够发起更具“真实性”的欺诈攻击。好在安全防御者们也开始发现利用大数据抵抗各类恶意攻击的方法了。 扰动安全的大数据 2014年IDC在“未来全球安全行业的展望报告”中指出，预计到2020年信息安全市场规模将达到500亿美元。与此同时，安全威胁的不断变化、IT交付模式的多样性、复杂性以及数据量的剧增，针对信息安全的传统以控制为中心的方法将站不住脚。预计到2020年，60%的企业信息化安全预算将会分配到以大数据分析为基础的快速检测和响应的产品上。 瀚思(HanSight)联合创始人董昕认为，借助大数据技术网络安全即将开启“上帝之眼”模式。“你不能保护你所不知道的”已经成为安全圈的一句名言，即使部署再多的安全防御设备仍然会产生“不为人知”的信息，在各种不同设备产生的海量日志中发现安全事件的蛛丝马迹非常困难。而大数据技术能将不同设备产生的海量日志进行集中存储，通过数据格式的统一规整、自动归并、关联分析、机器学习等方法，自动发现威胁和异常行为，让安全分析更简单。同时通过丰富的可视化技术，将威胁及异常行为可视化呈现出来，让安全看得见。 爱加密CEO高磊提出，基于大数据技术能够从海量数据中分析已经发生的安全问题、病毒样本、攻击策略等，对于安全问题的分析能够以宏观角度和微
练习题：万年历查询软件，要求用户输入以年月日表示的日期，然后系统会换算出该日期的农历表示法及相关黄历信息。假设日期限定在1900年1月1日~2049年12月31日，并规定日期由8位数字字符组成，前4位表示年，中间2位表示月，最后2位表示日期。其中4、6、9、11月只有30天，平年的2月份只有28天，闰年的2月份有29天。 （备注：为简化处理，本题在进行用例设计时，不必考虑对平年、闰年的判断）
一、先用等价类划分法设计测试用例，来测试程序的"日期检查功能"。1）划分等价类并编号,下表等价类划分的结果 2）设计测试用例覆盖所有的有效等价类，设计的测试用例如下： 3）为每一个无效等价类设计一个测试用例，设计结果如下：
4）测试用例举例： 5）存在的问题： 1、在对2月、大月、小月的无效日期进行用例选择时，日期没有取到边界上，如果程序忘记了对2月份的日期进行特殊判断，而是粗略写成所有的日期都必须小于等于28，那么用例9、用例10并不能发现错误。 2、在对大月、小月进行用例选择时，按照等价类的思想，从集合{1、 3、5、7、8、10、 12}和{4、6、9、11}中任意挑选了中间数据，感觉令人不够放心。 6）解决办法： 二、结合边界值方法进行用例设计。 首先还是利用等价类的方法进行用例设计，然后看看哪些边界值已经被覆盖到
了，最后再针对没有被覆盖的边界值补充测试用例。 设计测试用例覆盖等价类和边界值
可以再补充1月31日、11月30日的测试用例，因为1月是大月的第一个月，11月是小月的最后一个月，也可以算是边界值。 设计测试用例覆盖无效等价类：
软件测试基础：测试用例设计 测试需求收集完毕后，开始测试设计。测试用例是什么？测试用例就是一个文档，描述输入、动作、或者时间和一个期望的结果，其目的是确定应用程序的某个特性是否正常的工作。设计测试用例需要考虑以下问题： 测试用例的基本格式 软件测试用例的基本要素包括测试用例编号、测试标题、重要级别、测试输入、操作步骤、预期结果，下面逐一介绍。 用例编号：测试用例的编号有一定的规则，比如系统测试用例的编号这样定义规则： PROJECT1-ST-001 ，命名规则是项目名称＋测试阶段类型（系统测试阶段）＋编号。定义测试用例编号，便于查找测试用例，便于测试用例的跟踪。 测试标题：对测试用例的描述，测试用例标题应该清楚表达测试用例的用途。比如“ 测试用户登录时输入错误密码时，软件的响应情况” 。 重要级别：定义测试用例的优先级别，可以笼统的分为“ 高” 和“ 低” 两个级别。一般来说，如果软件需求的优先级为“ 高” ，那么针对该需求的测试用例优先级也为“ 高” ；反之亦然， 测试输入：提供测试执行中的各种输入条件。根据需求中的输入条件，确定测试用例的输入。测试用例的输入对软件需求当中的输入有很大的依赖性，如果软件需求中没有很好的定义需求的输入，那么测试用例设计中会遇到很大的障碍。 操作步骤：提供测试执行过程的步骤。对于复杂的测试用例，测试用例的输入需要分为几个步骤完成，这部分内容在操作步骤中详细列出。 预期结果：提供测试执行的预期结果，预期结果应该根据软件需求中的输出得出。如果在实际测试过程中，得到的实际测试结果与预期结果不符，那么测试不通过；反之则测试通过。 软件测试用例的设计主要从上述 6 个域考虑，结合相应的软件需求文档，在掌握一定测试用例设计方法的基础上，可以设计出比较全面、合理的测试用例。具体的测试用例设计方法可以参见相关的测试书籍，白盒测试方法和黑盒测试方法在绝大多数的软件测试书籍中都有详细的介绍，这里不作赘述。 重用同类型项目的测试用例 如果我看得远，那是因为我站在巨人的肩上－－牛顿。 一般来说，每个软件公司的项目可以分为固定的几大类。可以按业务类型划分，比如 ERP 软件、产品数据管理软件、通信软件、地理信息系统软件等等；可以按软件结构来划分，比如 B/S 架构的软件、 C/S 架构的软件、嵌入式软件等等。
等价类划分 等价类划分法是一种典型的、重要的黑盒测试方法，它将程序所有可能的输入数据（有效的和无效的）划分成若干个等价类。然后从每个部分中选取具有代表性的数据当做测试用例进行合理的分类，测试用例由有效等价类和无效等价类的代表组成，从而保证测试用例具有完整性和代表性。利用这一方法设计测试用例可以不考虑程序的内部结构，以需求规格说明书为依据，选择适当的典型子集，认真分析和推敲说明书的各项需求，特别是功能需求，尽可能多地发现错误。 由于等价类是在需求规格说明书的基础上进行划分的，并且等价类划分不仅可以用来确定测试用例中的数据的输入输出的精确取值范围，也可以用来准备中间值、状态和与时间相关的数据以及接口参数等，所以等价类可以用在系统测试、集成测试和组件测试中，在有明确的条件和限制的情况下，利用等价类划分技术可以设计出完备的测试用例。这种方法可以减少设计一些不必要的测试用例，因为这种测试用例一般使用相同的等价类数据，从而使测试对象得到同样的反映行为。对于等价类我们从以下几个方面讨论它的划分方法。 有效等价类划分 有效等价类指对于程序规格说明来说，是合理的、有意义的输入数据构成的集合。利用有效等价类可以检验程序是否实现了规格说明预先规定的功能和性能。有效等价类可以是一个，也可以是多个，根据系统的输入域划分若干部分，然后从每个部分中选取少数有代表性数据当做数据测试的测试用例，等价类是输入域的集合。 无效等价类划分 无效等价类和有效等价类相反，无效等价类是指对于软件规格说明而言，没有意义的、不合理的输入数据集合。利用无效等价类，可以找出程序异常说明情况，检查程序的功能和性能的实现是否有不符合规格说明要求的地方。 等价类划分的方法有 按区间划分。 按数值划分。 按数值集合划分。 按限制条件或规划划分。 按处理方式划分。 等价类划分的原则如下：