什么是等价类测试，用定义简单明了的回答

等价类划分测试的办法是把程序的输入域划分成若干部分（子集），然后从每个部分中选取少数代表性数据作为测试用例。每一类的代表性数据在测试中的作用等价于这一类中的其他值。该方法是一种重要的，常用的黑盒测试用例设计方法。

扩展资料：

划分等价类的原则：

1、在输入条件规定了取值范围或值的个数的情况下，则可以确立一个有效等价类和两个无效等价类。 

2、在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下，可确立一个有效等价类和一个无效等价类。

3、在输入条件是一个布尔量的情况下，可确定一个有效等价类和一个无效等价类。

4、在规定了输入数据的一组值（假定n个），并且程序要对每一个输入值分别处理的情况下，可确立n个有效等价类和一个无效等价类。 

5、在规定了输入数据必须遵守的规则的情况下，可确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）。 

6、在确知已划分的等价类中各元素在程序处理中的方式不同的情况下，则应再将该等价类进一步的划分为更小的等价类。

等价类划分是一种典型的黑盒测试方法。 等价类划分是指分步骤把海量（无限）的测试用例集减得很小，但过程同样有效。 也就是说，选取足够小测试用例，发现更多软件缺陷。

等价类划分有两种不同情况：有效等价类和无效等价类。

有效等价类：

是指对于程序的需求规格说明来说是合理的，有意义的输入数据构成的集合。

利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能（确认过程） 。

无效等价类 （与有效等价类的定义恰巧相反）

是指对于程序的需求规格说明来说是不合理的，无意义的输入数据构成的集合。

利用无效等价类可检验程序对于无效数据的异常处理能力（检验过程） 。

根据测试用例的完整性可以划分：

下面使用二分法来说明测试用例的完整性：

健壮是指要考虑无效值。强是指要考虑组合情况，使用笛卡尔积算出测试用例个数。

使用下面例子分别说明它们区别：

根据上面信息划分等价类：

使用最少测试用例覆盖每个有效等价类。在上面例子弱一般等价类的用例如下：

强一般等价类是基于多缺陷假设，强一般等价类的测试用例是要覆盖每个有效等价类取值的笛卡尔积。即在有效等价类取值的所有组合。组合个数是2 1 1=2。

在弱一般等价类的基础上，增加取值为无效值的情况。对于无效输入，测试用例将拥有一个无效值，并保持其余的值是有效的。

在强一般等价类的基础上，增加取值为无效值的情况。也是运用笛卡尔积思路得出测试用例。测试用例个数有：（2+3）（1+5） （1+3）=5 6 4 = 120（个），用例数量太多，就不意义列出来了。

上面从四个不同方面来思考怎样设计测试用例，我们需要选取如何测试用例，发现更多缺陷呢？正如我们在开头提到：

等价类使用方法说明如下：

根据以上说明，弱健壮等价类是符合以上要求。在使用等价类划分法设计测试用例的的重点在于 划分有效等价类和无效等价类粗细的粒度 。粒度越粗，设计测试用例越少，粒度越细，设计测试用例越多。相对来说，粒度越细能发现更多问题。

      测试设计是将概括的测试目标转化为具体的测试条件和测试用例的一系列活动。

①评审测试依据（需求，系统架构、设计和接口说明）。

②评估测试依据和测试对象的可靠性。

③通过对测试项、规格说明、测试对象行为和结构的分析，识别测试条件并确定优先级。

④设计测试用例，并确定优先级

⑤确定测试条件和测试用例所需要的必要的测试数据。

①依据在测试策略或测试计划中确定的测试技术。

②通过对测试依据和测试目标的分析，可以确定需要测试的内容，获得测试条件。

       测试用例是通过使用在测试计划中确定的测试技术，对于已确定的测试条件进行逐步推敲，精炼而设计出来的重点说明如何具体 *** 作产生何种结果的文档。（指引我们测试的文档）

      测试用例应该具有可重复性、可验证性和需求可追踪性。

①前提条件，如项目或局部测试环境的需求，及其交付计划。

②测试步骤。

③测试数据。

④预期结果。

①测试两个参数的值相加后的结果是否正确

②期中：输入的数值在-99到99之间，大于99或小于-99的输入应该被拒绝，并显示错误信息。

根据测试需求，我们开始测试：

①分别给第一个参数和第二个参数输入表中的值，得到的测试加过如表所示：

②如果我们对第一个参数的值分别取从-99到99的199个数，第二个参数的值分别取从-99到99的199个数，我们不可能对两位数相加的所有情况进行穷举测试。

③如果不能进行穷举测试，我们将面临以下的问题：

         在测试了1+1，1+2,1+（-1）和1+（-2）之后，还是否有必要测试1+3,1+4呢？

        如果不对加法计算器程序进行穷举测试，是否放心的认为所有的参数组合都是正确的呢

对于以上两个问题，我们可以采用等价类划分法来进行解决。

①等价类划分的办法就是把程序的输入域划分成若干部分。

②从每个部分中选取少数代表性数据当做测试用例。

③每一类的代表性数据在测试中的作用等价于这一类中的其他值。

④也就是说，如果某一类中的一个例子发现了错误，这一等价类中的其他例子也能发现同样的错误。

⑤繁殖，如果某一类中的例子没有发现错误，则这一等价类中的其他例子也不会发现错误。

①如果输入条件规定了取值范围或值的个数，则可确定一个有效等价类和两个无效等价类。

②如果一个输入条件说明了一个“必须成立”的情况，则可划分一个有效等价类和一个无效等价类。

③如果输入条件规定了输入数据的一组可能的值，而且程序使用不同的方式处理每一种值，则可为每一种值划分一个有效等价类，并划分一个无效等价类。

④如果我们确定，已划分的某等价类中的各元素（例子）在程序中的处理方式是不同的，则应据此将此等价类进一步划分成更小的等价类。

⑤在确定了等价类之后，建立等价类表，列出所有划分出的等价类。

①明确测试对象，非测试对象保证正确。

②为每个等价类规定一个唯一的编号。

③设计一个测试用例，使其尽可能多的覆盖尚未覆盖的有效等价类。重复这一步，最后使得所有有效等价类均被测试用例所覆盖。

④设计一个新的测试用例，使其只覆盖一个无效等价类。重复这一步使所有的无效等价类均被覆盖。

例子是前面的加法计算机

①一个有效数据等价类，两个无效数据等价类。

有效数据等价类就是：由那些对程序的规格说明有意义的、合理的输入数据所构成的集合。

无效数据等价类就是：那些对程序的规格说明不合理的或无意义的输入数据所构成的集合。

       在实际工作中，我们通常在确立了等价类以后，把程序中所有的等价类建立等价类表，一遍在编写测试用例的时候有所依据。

①为等价类表中的每一个等价类分配一个唯一的编号。

②设计一个新的测试用例，使他能够尽量覆盖尚未未覆盖的有效等价类。

③重复这一步骤，从而使所有有效等价类均被测试用例所覆盖。

④与上述类似，设计一个新的测试用例，使它只覆盖一个无效等价类。

⑤重复这一步骤，从而使所有无效等价类均被测试用例所覆盖。

①在测试“-99≤数值99”的这个等价类区间的时候，我们会发现如10+40，-20+30和-30+（-30）这类的正数相加，正数负数相加，负数相加也是不同的等价区间。因此我们可以使用更多的等价类划分。

②根据以上等价类划分的加过，得出下表的等价类表：

根据上面划分的4个等价类，我们至少需要有5个测试用例：

①测试相同的内容。

②如果等价类中的一个测试能够获取一个缺陷，那么选择该等价类中的其他测试也能获取该缺陷。

③如果等价类中的一个测试不能获取缺陷，那么选择该等价类中的其他测试也不能获取缺陷。

④如果正确的花粉都能加了，可以大大降低测试用例的数量，测试会准确有效。

⑤如果错误的将两个不同的等价类当作一个等价类，那就会遗漏一种测试情况。

⑥相反的，把同一个等价类看作了两个不同的等价类，那么测试就会是冗余的。

①不但要考虑有效等价类，也要考虑无效等价类。

②仔细划分，审查划分。

③过于粗略可能会漏掉软件缺陷。

⑤组织评审。

①余额宝体现到yhk增加新规则：快速到账（2小时）日限额1W元。

②超过1W元只能选择普通到账。

③按照等价类划分方法设计测试用例。

①设计用例：

②细致分析需求，日限额1W,所以要区分两个场景：

       边界值分析法是一种补充等价划分的测试用例设计技术，它不是选择等价类的任意元素，而是选择等价类便捷的测试用例。

       实践证明，在设计测试用例时，对边界附近的处理必给予足够的重视，为检验便捷附近的处理专门设计测试用例，常常去的良好的测试效果。

      边界值分析法不仅重视输入条件边界，而且也从输出域导出测试用例。

        如果输入条件规定了取值范围，应以该范围的边界内及刚刚超范围的边界外的值作为测试用例。

eg1:以a和b为边界，测试用例应当包含a和b以及略大于a和略小于b的值。

eg2:根据以上计算器的例子，根据边界值分析的方法来看看如何对边界值进行测试：

        由于允许输入的额数值在-99到99之间，所以我们可以把-99和99看做两个边界值。我们测试的时候可以去临近边界值的数值和边界值本身作为输入：

eg3:余额宝体现到一囊卡增加新规则：快速到账（2小时）日限额1W元：

       等价类划分法和边界值分析方法都是着重考虑输入条件而不考虑输入条件的个各种组合、输入条件之间的相互制约关系。

       如果在测试时必须考虑输入条件的各种组合，则可能的组合数目将是天文数字；因此必须考虑采用一种适合于描述多种条件的组合、产生多个相应动作的测试方法，这就需要利用因果图（逻辑模型）。

       因果图法基于这样的思想：一些程序的功能可以用决策表的形式来表示，并根据输入条件的组合情况规定相应的 *** 作；因此，可以考虑为决策表中的每一列设计一个测试用例，以便测试程序早输入条件的某种组合下的输出是否正确。

      概括的说，因果图方法就是从程序规格说明书的描述中找出因（输入条件）和果（输出结果或程序状态的改变）。将因果图转换为判定表，为决策表中的每一列设计一个测试用例。这种方法考虑到了输入情况的各种组合以及各个输入情况之间的相互制约关系。

      判定表（Decision Table）是分析和表达多逻辑条件下执行不同 *** 作的工具。是编写程序的辅助工具，可以把复杂的逻辑关系和多种条件组合的情况表达得及具体又明确。

判定表通常由四个部分组成：

①条件桩（Condition  Stub）:列出了问题的所有条件，通常认为列出的条件的次序无关紧要。

②动作桩（Action Stub）：列出了问题规定可能采取的 *** 作，这些 *** 作的排列顺序没有约束。

③条件项（Confition  Entry）:列出针对它左列条件的取值，在所有可能情况下的真假值。

④动作项（Action  Entry ）:列出在条件项的各种取值取值情况下应该采取的动作。

①分析软件规格说明中哪些是原因（即输入条件或输出条件的等价类），哪些是结果（即输出条件），并给每个原因和结果赋予一个标识符。

②分析软件规格说明中语义的内容，找出原因与结果之间、原因与原因之间的对应关系，根据这些关系画出因果图。

③由于语法或环境的限制，有些原因和原因之间、原因和结果之间的组合情况不可能出现。为表名这些特定的情况，在因果图上使用一些记号表名约束或限制条件。

④把因果图转换为判定表。

⑤根据判定表中的每一列设计测试用例。

eg:使用因果图+判定表设计测试用例测试两位数计算器。

①输入1：                                                                ②输入2：

条件1：0≤X≤99                                                      条件1：0≤X≤99    

条件2：-99≤X<0                                                    条件2：-99≤X<0

条件3：X<-99                                                        条件3：X<-99

条件4：X>99                                                         条件4：X>99

输出：

正确计算

错误提示

输入1：

     1、2、3、4互斥

输入2：

    1、2、3、4互斥

输出：

输出结果正确和错误互斥

得到的测试用例：

       正交实验设计法（Orthogonal experimental design）,是从大量的试验点中挑选出适量的、有代表性的点，应用依据伽罗卡瓦理论导出的“正交表”，合理的安排试验的一种科学的试验设计方法。

1、提取功能说明，构造因子—状态表

2、加权筛选，生成因素分析表

       计算个因子和状态的权值，删去一部分权值较小，即重要性比较小的因子或状态，使最后生成的测试用例集缩减到允许的范围。

3、利用正交表构造测试数据集

  ① 如果每个因子的状态树是不统一的，几乎不可能出现均匀的情况，必须首先用逻辑命令来组织个因子的状态，作出布尔图。

②根据布尔图得到相应结束的正交表。

③依照因果图上根节点到叶子节点的顺序逐步替换正交表上的中间节点，得到最终的正交表。

4、利用正交表每行数据构造测试用例

正交表：

正交表的表示形式：Ln（t^c）其中：L为正交表的代号，n为行数（试验行数），t为水平数，c为列数（因素数）。

eg：L4（2^3），它表示需做四次实验，最多可观察3个因素，每个因素均为2水平：

1：正确

2：错误

eg：一个正交表中也可以割裂的水平数不相等，我们称它为混合型正交表，如L8(2^4 4^1）：

根据正交表的数据结构可以看出吧，正交表是一个n行c列的表，其中第j行由数码1,2，tj组成，这些数码均各出现n/t次。

第二列的数码个数为2，t=2，即由1、组成，各数码均出现2次。

1、Technical Support (supportsaacom)

http://supportsascom/techsup/technote/ts723_Designstxt

2、查DrGenichiTaguchi设计的正交表，

http://wwwyorkacuk/depts/maths/tables/orthogonalhtm

3、数理统计、试验设计等方面的书及附录中

    关注点：因素数和对应的水平数组组成的矩阵

eg：测试支付宝web网站，该网站点有大量的服务器和 *** 作系统。并且有许多具有各种插件的浏览器需要考虑：

WEB浏览器：IE11、chrome、FireFox

插件：无、Flash、支付宝插件

应用服务器：IIS、Apache、Jetty

*** 作系统：Windows2000、Windows NT、Linux

1、提取系统功能说明中的因子

①WEB浏览器        

②插件

③应用服务器

④ *** 作系统

2、分析个因子的状态

①插件：1=None、2=Flash、3=FireFox

②WEB浏览器：1=IE11、2=Chrome、3=FireFox

③应用服务器：1=IIS、2=Apache、3=Jetty

④ *** 作系统：1=Windows2000、2=Windows NT、3=Linux

3、选择正交表

正交表水平数为3，因素数为4。选择L9（3^4）

4、将因子、状态映射到上面正交表中

       现在的软件几乎都是用事件出发来控制流程的。事件触发时的情景形成了场景，而同一事件不同的触发顺序和处理结果就形成了事件流。

       这种在软件设计方面的思想可以引入到软件测试中，可以生动的描绘出时间触发时的情景，有利于设计测试用例，同时使测试用例更容易理解和执行。

       经过用例的每条路径都用基本流和备选流来表示，之黑线表示基本流，是经过用例的最简单的路径。

       备选流用不同的色彩表示，一个备选流可能从基本流开始，在某个特定条件下执行，然后重新加入基本流中（如备选流1和3）；

      也可能起源于另一个备选流（如备选流2），或者终止用例而不在重新加入到某个流（如备选流2和4）。

       每个经过用例的可能路径，可以确定不同的用例场景。从基本流开始，再将基本流和备选流结合起来，可以确定以下用例场景：

场景1：基本流

场景2：基本流 备选流1

场景3：基本流 备选流1 备选流2

场景4：基本流 备选流3

场景5：基本流 备选流3 备选流1

场景6：基本流 备选流3 备选流1 备选流2

场景7：基本流 备选流4

场景8：基本流 从、备选流3  备选流4

①根据说明，描述出程序的基本流及各项备选流。

②根据基本流和各项备选流生成不同的场景。

③对每一个场景生成相应的测试用例。

④对生成的所有测试用例重新复审，去掉多余的测试用例，测试用例确定后，对每一个测试用例确定测试数据值。

eg：在淘宝的购物过程：

       用户登录到网站后，进行商品的选择，当选好自己心仪的商品后进行购买，这时把所需商品放进购物车，等进行结账的时候，用户需要登录自己注册的账号，登录成功后，进行结账并生成订单，整个购物过程结束。

①通过以上的描述，从中确定哪些是基本流，哪些是备选流：

②根据基本流和备选流来确定场景：

1、测试用例项划分

       测试用例划分的经典方法就是瀑布模型，从上到下，逐渐细分，大模块包括小模块，小模块包括更小的模块。

      要从更多的角度切入系统，把系统切分成一块一块的，来进行测试，从而确保测试大项的完整性。

2、切面设计

       功能点切面：最常见的切面，通常认为页面上的一个按钮就是一个功能点。根据功能的复杂程度，按每个功能进行用例的撰写。

      隐含切面：完整业务流程的测试；从需求、业务角度进行编写。

3、功能点用例设计

①任何情况下都必须使用边界值分析方法，经验表明用这种方法设计出测试用例发现程序错误的能力最强。

②必要时用等价类划分方法不从以希望测试用例。

③如果程序的功能说明中含有输入条件的组合情况，则一开始就可选用因果图法。

④如果程序业务复杂度比较高，则使用使用场景法补充一部分测试用例。

eg:共享单车充值

1、边界值考虑充值金额：0元，1元，负数，非金额参数，多位小数（小数后3位）,yhk限额。

2、由于充值时可以选择不同的银行支付渠道，所以针对支付宝、微信、通联、银联、银行直连等渠道分别设计测试用例。

3、考虑异常场景，如充值失败、yhk余额不足、银行返回超时等。

4、如果场景中还包含更复杂的业务场景，如满减、满赠、增加抽奖次数等，还需要结合场景法进行测试。

常见的开发模型：

V模型、瀑布模型、敏捷开发模型、W模型

软件生命周期：

1、问题的定义及规划

2、需求分析

3、软件设计（明确怎么做！）

4、软件编码

5、软件测试

6、运行维护

测试生命周期：

单元测试：一般是开发完成时

集成测试：单元测试之后，单元之间接口是否正确，数据是否正常传递。比如说注册和充值两个功能是否能够连通。

系统测试：根据测试用例，进行完整的系统测试

验收测试：用户对软件进行验收

软件测试阶段：

单元、集成、系统、验收（正式验收、Alpha测试，Beta测试）

软测方法：

白盒测试、黑盒测试、灰盒测试

软测类型：

功能、界面、安全、兼容性、易用性、性能、压力、负载、恢复测试等

其他测试分类：冒烟测试、回归测试、探索性测试

常用的开发的模型：V模型

软件测试的分类

什么是黑盒测试？

黑盒测试也称功能测试，它是通过测试来检测每个功能是否都能正常使用。不考虑内部结构，在程序接口进行测试。

Alpha、Beta测试的区别？

Alpha测试：前期的用户测试，公司内部在模拟实际 *** 作环境下进行的一种验收测试。

Beta测试：后期的用户测试，此时已经通过内部测试，即将真实发布，是软件的在一个或者多个用户的实际使用环境下进行的测试

冒烟测试和回归测试区别？

冒烟测试：在新版本出来的时候，将软件的全部功能过一遍，功能可以正常进行不会影响测试进度，这个版本就可以真正测试了

回归测试：对以前版本中发现的bug在新的版本中验证是否存在且是否引发新的bug

1、边界值：

选取等于、刚刚大于、刚刚小于边界的值作为测试数据

基本思想是在最小值、略高于最小值、正常值、略低于最大值和最大值等处取值

2、等价类划分：

等价类划分就是把程序的输入域划分成若干部分，然后从每部分选取少量的具有代表性的数据作为测试用例。

无效等价类：不合理的、无意义的输入数据结婚，验证程序处理意外数据的能力

有效等价类：有意义的输入数据的集合，检验程序是否实现了规格说明总的功能和性能

等价类划分方法：按区间划分、数值划分、数值集合划分、限制条件和规则划分

3、错误推算法：

进行错误的 *** 作，验证程序是否对出错的场景和情况有些应对能力，来选择测试用例数据

4、因果法/判定表法：

将判定表的每一列作为依据，设计测试用例。检查输入条件的各种组合情况

5、场景法：

通过描述的业务流程，设计用例来列出不同业务场景，作为测试用例的测试数据

基本流：主要是功能的正常 *** 作流程

分支流：需要程序做非法判断处理的

测试用例方法的选择（划重点）

1、进行等价类划分，主要是输入条件的划分，这是提高测试效率最有效的方法

在任何情况下都必须使用边界值分析法，这种方法设计出测试用例发现程序错误的能力最强

2、用错误推测法追加测试用例

3、如果程序说明中含有输入组合情况，则一开始就用判定表法（判定表法很少用到）

4、如果还没有达到覆盖标准，应当再补充足够的测试用例（场景法）

1、列出需求文档中的可测试性的原始需求

2、对每一条需求进行细化分解，形成可测试的测试点

3、针对测试点确定执行适合的测试类型

4、建立测试需求分析矩阵，对测试需求进行管理

软件测试需求的 重点 是“ 测什么 ”。

测试需求分析的目的：获取测试点，根据测试点编写用例

按钮指示灯：按压上下按钮指示灯是否亮

电梯门开关：按压上下按钮电梯门在当前楼层是否能打开

按向上按钮：电梯是否关门且向上面楼层方向走

按向下按钮：电梯是否关门且向下面楼层方向走

当电梯门没有关上：按开电梯门按钮，门是否开

当电梯门没有关上：按关闭电梯门按钮，门是否关闭

电梯内：按各个楼层，对应的指示灯是否亮

电梯内报警装置：报警装置是否正常

电梯内通话设备：按通话按钮能否接通外界

电梯内灯光：电梯内灯光是否亮，是否有无损坏

电梯内通风：是否通风

按各个楼层按钮：是否到当前楼层停止并开门

当超过最高重量：电梯是否报警打开电梯门，直到小于最高承重

电梯当前楼层是否和电梯内显示屏楼层一直

显示屏内是否有当前楼层，当前向上或者向下箭头，且与当前 *** 作一致

电梯门超过规定时间未关门是否会有报警提示

上下按钮是否控制一个电梯或者两个电梯的开关门，如果控制两个电梯，按向上或者向下按钮，另一个电梯是否受控制

电梯是否分单双层？

在单层电梯情况下，按双层电梯，对应双层电梯数字是否亮，是否会到这一层

在双层电梯情况下，按单层电梯，对应单层电梯数字是否亮，是否会到这一层

电梯限层：按超过限层的电梯层数，数字是否亮，是否会到这一层

双击某楼层：是否会取消这个楼层且楼层灯灭

假如我在9楼，有人先按12楼，有人后按1楼，此时电梯是否先上12楼，再下1楼？

电梯感应：有人或者物体在门中间卡着，门是否会关闭，是否会有警铃提示？

电梯到达指定楼层是否有声音提示？

电梯是否刷卡：刷卡的电梯，如果没有刷卡是否能选楼层

维修开关：电梯内是否有维修开关

测试用例：指导性执行测试，帮助证明软件功能或发现软件缺陷的一种说明。每一个测试点的数据设计和步骤设计。

测试用例的重要性：

（1）、便于测试计划的实施

            一般主要适用于集成测试、系统测试、回归测试。根据用例知道自己的进度

（2）、规划测试数据的准备

            比如测注册，要提前准备好手机号、身份z号、不重复的用户名，邮箱等

（3）、编写测试脚本的根本

            自动测试的中心任务是编写测试脚本。测试脚本就是以测试用例为基础。

（4）、评估测试结果的基准

            通过测试用例的覆盖性和错误率，可以判断测试的结果，是否能发布

（5）、分析缺陷标准

 收集缺陷，对比测试用例。分析是漏测还是缺陷复现。反应了测试的不完善，应立即补充相应的测试用例

测试标题如何写：测试点，对测试点进行细化分解。比如：输入正确用户名、密码，能否正常登陆。

测试用例编写格式注意：

（1）、测试标题一定要描述测试点（验证什么写什么），简洁明了，不存在重复

（2）、测试步骤要有指导性的意义，涉及测试数据输入最好包含具体的测试数据

（3）、预期结果是唯一的，不能出现“发送成功或失败”

如何编写测试用例？

用例包含：用例编号、功能模块、用例标题、前提条件、 *** 作步骤、期望结果（含判断标准）、实际结果、备注

编写方式：按照功能+业务逻辑

（1）、首先保证单个功能是正常的

（2）、然后功能联合起来的业务逻辑是对的

比如：登录、充值、提现功能都是好的。业务逻辑，就是把所有的功能联合起来走一遍，看是否是好的

用例覆盖：包含正面和反面的用例

（1）、正面用例：根据功能模块划分，针对要测试的功能模块，所有正常输入数据的测试用例都写出来

（2）、反面用例：例如登录失败等，输入非法数据，违反唯一约束等等