1、第2章测试用例设计2.1 测试用例设计原则2.2 测试用例设计方法2.3 测试用例设计步骤2.4 测试用例分级2.5 测试用例编写要素与模版2.6 测试用例设计误区2.7 单元测试2.8 单元测试案例分析与实践1 测试用例（Test Case）是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。2 测试用例构成了设计和制定测试过程的基础，是测试工作的指导，是软件测试质量稳定的根本保障。（1）测试的“深度”与测试用例的数量成比例。（2）测试的覆盖度是以确定、实施和/或执行的测试用例的数量为依据的。（3）测试工作量与测试用例的数量成比例。（4
2、）测试设计和开发的类型以及所需的资源主要都受控于测试用例。3测试用例设计很重要！2.1测试用例设计原则测试用例设计一般遵循以下原则：1.正确性 输入用户实际数据以验证系统是否满足需求规格说明书的要求；测试用例中的测试点应首先保证要至少覆盖需求规格说明书中的各项功能，并且正常。42.1测试用例设计原则2.全面性 覆盖所有的需求功能项；设计的用例除对测试点本身的测试外，还需考虑用户实际使用的情况、与其他部分关联使用的情况、非正常情况(不合理、非法、越界以及极限输入数据)操作和环境设置等。52.1测试用例设计原则3.连贯性 用例组织有调理、主次，尤其体现在业务测试用例上；用例执行粒度尽量保持每个用例
3、有个测点，不能同时覆盖很多功能点，否则执行起来牵连太大，所以每个用例间保持连贯性很重要。62.1测试用例设计原则4.可判定性 测试执行结果的正确性是可判定的，每一个测试用例都有相应的期望结果。72.1测试用例设计原则5.可操作性 测试用例中要写清楚测试的操作步骤，以及不同的操作步骤相对应的测试结果。82.2测试用例设计方法基于白盒技术的测试用例设计：白盒测试是结构测试，所以被测对象基本上是源程序，以程序的内部逻辑为基础设计测试用例。基于黑盒技术的测试用例设计。92.2.1等价类划分法定义：等价类划分法是把所有可能的输入数据，即程序的输入域划分成若干部分（子集），然后从每一个子集中选取少数具有代
4、表性的数据来设计测试用例。102.2.1等价类划分法地位：该方法是一种重要的、常用的基于黑盒技术的测试用例设计方法。112.2.1等价类划分法划分等价类：等价类是指某个输入域的子集合。等价类划分可有两种不同的情况：有效等价类和无效等价类。利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能。无效等价类指对程序的规格说明是不合理的或无意义的输入数据所构成的集合。122.2.1等价类划分法划分等价类的标准：测试完备合理、避免冗余；划分等价类重要的是：集合的划分，划分为互不相交的一组子集，而子集的并是整个集合；同一类中标识（选择）一个测试用例，同一等价类中，往往处理相同，相同处理映射到相同
5、的执行路径。132.2.1等价类划分法划分等价类的方法：（1）在输入条件规定了取值范围或值的个数的情况下，则可以确立一个有效等价类和两个无效等价类。例如：输入值是范围0100的学生成绩142.2.1等价类划分法划分等价类的方法：（2）在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下，可确立一个有效等价类和一个无效等价类 例如：输入值必须是负数 152.2.1等价类划分法划分等价类的方法：（3）在输入条件是一个布尔量的情况下，可确定两个有效等价类和一个无效等价类。例如：输入值是“是否为党员”162.2.1等价类划分法划分等价类的方法：（4）在规定了输入数据的一组值（假定n个），并
6、且程序要对每一个输入值分别处理的情况下，可确立n个有效等价类和一个无效等价类。例如：输入条件说明学历可为：专科、本科、硕士、博士四种之一172.2.1等价类划分法划分等价类的方法：（5）在规定了输入数据必须遵守的规则的情况下，可确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）。例如：输入密码必须是6位由字母和数字组成的有效序列182.2.1等价类划分法划分等价类的方法：（6）在确知已划分的等价类中各元素在程序处理中的方式不同的情况下，则应再将该等价类进一步的划分为更小的等价类。例如：考虑一下if嵌套192.2.1等价类划分法根据等价类设计测试用例：按以下三个原则设计测试用
7、例：（1）为每一个等价类规定一个唯一的编号；（2）设计一个新的测试用例，使其尽可能多地覆盖尚未被覆盖地有效等价类，重复这一步，直到所有的有效等价类都被覆盖为止；（3）设计一个新的测试用例，使其仅覆盖一个尚未被覆盖的无效等价类，重复这一步，直到所有的无效等价类都被覆盖为止。202.2.1等价类划分法实战演习：【例2-1】设有一个档案管理系统，要求用户输入以年月表示的日期。假设日期限定在1990年1月2049年12月，并规定日期由6位数字字符组成，前4位表示年，后2位表示月。现用等价类划分法设计测试用例，来测试程序的日期检查功能。212.2.1等价类划分法22表2-1“日期检查功能”的测试用例等价
8、类2.2.1等价类划分法23表2-2 设计的测试用例结果2.2.1等价类划分法补充例题：某程序规定：输入三个整数a、b、c分别作为三边的边长构成三角形。通过程序判定所构成的三角形的类型，当此三角形为一半三角形、等腰三角形及等边三角形时，分别计算用等价类划分法为该程序进行测试用例设计。242.2.1等价类划分法分析：分析问题中给出的隐含的对输入条件的要求：（1）整数（2）三个数（3）非零数（4）正数（5）两边之和大于第三边（6）等腰（7）等边如果a、b、c满足（1）（4），则输出为下列情况之一1）如果不满足（5），则程序输出为“非三角形”；2）如果满足（7），则程序输出为“等边三角形”；3）如果
9、满足（6），则程序输出为“等腰三角形”；4）如果三边都不相等，则程序输出为“一边三角形”。252.2.2边界值分析法定义：边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。262.2.2边界值分析法意义：大量的测试实践经验表明，边界值是最容易出现问题的地方，也是测试的重点。使用边界值分析方法设计测试用例时一般与等价类划分结合起来，边界值分析法是对等价类划分法的补充。根据测试人员的经验发现，边界值分析法拥有最强最强的发现程序错误的能力。272.2.2边界值分析法对边界值设计测试用例，应遵循以下几条原则 （1）如果输入条件规定了值的范围，则应取刚达到这个范围的边界的值，以及刚刚超越这
10、个范围边界的值作为测试输入数据。例如，如果程序的规格说明中规定：重量在10公斤至50公斤范围内的邮件，其邮费计算公式为。282.2.2边界值分析法对边界值设计测试用例，应遵循以下几条原则 （2）如果输入条件规定了值的个数，则用最大个数、最小个数、比最小个数少1、比最大个数多1的数作为测试数据。比 如，一 个 输 入 文 件 应 包 括 1255个 记 录292.2.2边界值分析法对边界值设计测试用例，应遵循以下几条原则 （3）对每个输出条件分别按照以上原则或确定输出值的边界情况。如，一个学生成绩管理系统规定，只能查询95-98级大学生的各科成绩。由于输出值的边界不与输入值的边界相对应，所以要检
11、查输出值的边界不一定可能，要产生超出输出值之外的结果也不一定能做到，但必要时还需试一试。302.2.2边界值分析法对边界值设计测试用例，应遵循以下几条原则 （4）如果程序的规格说明给出的输入或输出域是个有序集合（如顺序文件、线性表、链表等），则应选取集合的第一个元素和最后一个元素作为测试用例。312.2.2边界值分析法对边界值设计测试用例，应遵循以下几条原则 （5）如果程序中使用了一个内部数据结构，则应当选择这个内部数据结构边界上的值作为测试用例。（6）分析规格说明，找出其他可能的边界条件。322.2.2边界值分析法常见的一些边界值（1）对16-bit 的整数而言 32767 和-32768
12、是边界（2）屏幕上光标在最左上、最右下位置（3）报表的第一行和最后一行（4）数组元素的第一个和最后一个（5）循环的第 0 次、第 1 次和倒数第 2 次、最后一次332.2.2边界值分析法常见的一些边界值【例2-2】测试计算平方根的函数 -输入：实数 -输出：实数 -规格说明：当输入一个0或比0大的数的时候，返回其正平方根；当输入一个小于0的数时，显示错误信息平方根非法-输入值小于0并返回0；库函数Print-Line可以用来输出错误信息。342.2.2边界值分析法常见的一些边界值【例2-2】测试计算平方根的函数 （1）等价类划分：输入=0 （2）等价划分测试用例有两个：输入4 输入-1035
13、2.2.2边界值分析法常见的一些边界值【例2-2】测试计算平方根的函数（3）边界值分析 输入 最小负实数 输入 绝对值很小的负数 输入 0 输入 绝对值很小的正数 输入 最大正实数362.2.2边界值分析法边界值分析法具体操作（1）边界值分析法利用输入变量的最小值(min)、略大于最小值(min+)、输入值域内的任意值(nom)、略小于最大值(max-)和最大值(max）来设计测试用例。372.2.2边界值分析法边界值分析法具体操作（2）基于可靠性理论中称为“单故障”的假设，即有两个或两个以上故障同时出现而导致软件失效的情况很少，也就是说，软件失效基本上是由单故障引起的。因此，在边界值分析法中
14、获取测试用例的方法是：每次保留程序中的一个变量，让其余的变量取正常值，被保留的变量依次取min、min+、nom、max-、max。对程序中的每个变量重复。382.2.2边界值分析法实战演习：【例2-3】三角形问题的边界值分析测试用例。要求边长 是 整 数 且 取 范 围 值 设 值 为 1,100。392.2.2边界值分析法40 表 2-5 三角形的边界值分析测试用例健壮性测试（补充）健壮性测试是作为边界值分析的一个简单的扩充，它除了对变量的5个边界值分析取值外，还需要增加一个略大于最大值(max+)以及略小于最小值(min-)的取值，检查超过极限值时系统的情况。因此，对于有n个变量的函数采
15、用健壮性测试需要6n+1个测试用例。412.2.2边界值分析法【例2-4】NextDate函数的边界值分析测试用例（健壮性测试）分析：在NextDate函数中，隐含规定了变量month和变量day的取值范围为1month12和1day31，并设定变量year的取值范围为1912year2050。422.2.2边界值分析法432.2.2边界值分析法测试用例用例monthdayyear预期期输出出Test1Test2Test3Test4Test5Test6Test766666661515151515151519111912191319752049205020511911.6.161912.6.16
16、1913.6.161975.6.162049.6.162050.6.162051.6.16Test8Test9Test10Test11Test12Test13666666-112303132200120012001200120012001day超出1312001.6.22001.6.32001.7.1输入日期超界day超出131Test14Test15Test16Test17Test18Test19-112111213151515151515200120012001200120012001Mouth超出1122001.1.162001.2.162001.11.162001.12.16Mouth
17、超出1122.2.3因果图法为何需要因果图？等价类划分或边界值分析法只考虑了不同的输入和不同的输出之间的关系。但是如果是各个输入条件之间有很复杂的组合，这两种设计方法都很难用一个系统的方法进行描述，设计测试用例只能依靠测试人员主观的猜测或者分析，具有很大的盲目性。442.2.3因果图法什么是因果图？因果图是一种形式化的语言（以图的形式表现），它不仅描述了原因和结果之间的关系，也描述了各个原因之间、各个结果之间复杂关系的组合。在这里，因因就就是是程程序序的的输输入入条条件件，而果果则则是是程程序序的的输输出出。正确的使用因果图可以对很复杂的功能逻辑进行分析，设计出高效而简洁的测试用例。452.2
18、.3因果图法6种因果逻辑：恒等：如果原因为真，那么结果必定为真462.2.3因果图法6种因果逻辑：与：只有2个原因都为真，那么结果为真，可扩展为多个原因472.2.3因果图法6种因果逻辑：或：2个原因中有一个为真时，结果就为真，可扩展为多个原因482.2.3因果图法6种因果逻辑：非：只 有 原 因 为 假，结 果 才 为 真492.2.3因果图法6种因果逻辑：与非：先与后非502.2.3因果图法6种因果逻辑：或非：先或后非512.2.3因果图法原因之间的约束关系（4种）：排他性约束（异）：各个原因之间不能同时为真，但可以同时为假。例如：小明同学不可能同时属于A班和B班，但可能既不是A班的，也不
19、是B班的，而是C班的522.2.3因果图法原因之间的约束关系（4种）：包含性约束（或）：各个原因中总有一个为真。即可以同时为真，但不可以同时为假。例：支付宝买家付款时，有个输入条件（既原因）是余额支付、网银支付，买家可以选择单独余额支付或者单独网银支付，也可以同时选择余额支付和网银支付2种方式。但是不可以选择不支付。532.2.3因果图法原因之间的约束关系（4种）：必要性约束（要求）：当原因a为真时，原因b必须同时为真；但是原因b为真时，原因a既可以为真，也可以为假。举数字证书的例子：现有的业务规则下，如果申请了数字证书（原因a），那么该用户必然通过了支付宝认证（原因b）。反之，如果用户通过了
20、支付宝认证，那么不一定申请了数字证书（a）。542.2.3因果图法原因之间的约束关系（4种）：唯一性约束：有且只有原因a和原因b中的一个为真。非此即彼，不存在第三种情况。举例来说，人的性别不是男，就是女，不会存在既不是男也不是女的人。552.2.3因果图法结果之间的约束关系（1种）：掩码标记（结果约束）：如果结果b为真，那么结果a一定为假，如果结果b为假，则结果a的状态不定。还拿支付宝来举例子，先给出两个结果：安全控件运行正常（a），无法输入登陆密码（b）。如果无法输入登陆密码，那么可以判断是安全控件没有正常运行，反过来，如果可以输入登陆密码，则不能确定安全控件一定工作正常，有可能是用了Fir
21、eFox浏览器访问Alipay的。562.2.3因果图法使用因果图设计测试用例的步骤：（1）分析需求（2）确定原因和结果（3）确定逻辑关系（4）确定约束关系（5）把因果图转换为决策表（6）根据原因给出结果（7）设计测试用例572.2.3因果图法实战演练：【例2-5】某软件需求说明书：某段文本中，第一列字符必须是A或B，第二列字符必须是一个数字，在此情况下进行文件的修改。但如果第一列字符不正确，则给出信息L；如果第二列字符不是数字，则给出信息M。582.2.3因果图法实战演练：确定原因和结果：592.2.3因果图法实战演练：确定因果逻辑关系：602.2.3因果图法实战演练：确定因果逻辑关系：（原
22、因C1可以再细分）612.2.3因果图法实战演练：确定约束关系：（完整的因果图）622.2.3因果图法实战演练：根据因果图画决策表：632.2.3因果图法实战演练：根据原因分析结果：642.2.3因果图法实战演练：设计测试用例：652.2.3因果图法例：一胖妞减肥，第一条件必须是每餐只能吃一个苹果或者一块牛肉，第二个条件必须每天锻炼1个小时，在此情况下则可以每天减肥1斤。但如果第一个条件不满足，则出现经常晕倒情况；如果第二个条件不满足，则只能减1两肉。662.2.3因果图法 因果图适用于检查程序输入条件的各种组合情况。利用因果图设计测试用例需要考虑输入条件与输出结果之间的因果关系，而这些因果关
23、系很难从需求规格说明书中直接得出，一般软件系统的因果关系非常的复杂，所以利用因果图设计用例费事、费力。（可直接给出判定表）672.2.3因果图法练习：有一个处理单价为5角钱的饮料自动售货机，软件测试用例的设计规格说明如下：若投入5角钱或1元钱的硬币，压下橙汁或啤酒的按钮，则相应的饮料就送出来；若售货机没有零钱找，则一个显示零钱找完的红灯亮，这时在投入1元硬币并压下按钮后，饮料不送出来而且1元硬币也退出来；若有零钱找，则显示零钱找完的红灯灭，在送出饮料的同时退还5角硬币。68NextDate函数测试用例分析：该函数隐含规定了变量month和day及year的取值范围分别为：month1,12da
24、y1,31year1912,2050692.2.3因果图法2.2.3因果图法练习：如企业的人力资源管理系统，该系统中有一模块为计算员工的年终风险金。根据需求描述：该企业有两种类型的员工：年薪制员工及非年薪制员工。对于年薪制员工，如有严重过失则要扣除年终风险金的4%；对于一般过失，扣年终风险金的2%；而对非年薪制的员工，如有严重过失，则扣除月薪8%；一般过失扣除月薪的4%。702.2.4场景法什么是场景法？现在的软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。这种在软件设计方面的思想也可以引入到软件测试中，可以比较生动地描绘出事件
25、触发时的情景，有利于测试设计者设计测试用例，同时使测试用例更容易理解和执行。712.2.4场景法场景法基础知识：通过运用场景来对系统的功能点或业务流程的描述，从而提高测试效果。场景法一般包含基本流和备用流，基本流只有1条，是一个完整的业务流程，初始节点位于系统初始状态，终止节点位于系统终止状态。备选流有1条或多条，只是业务流程的执行片段，需要和基本流共同构成场景，初始节点位于基本流或其它备选流，终止节点位于基本流或系统其它终止状态。722.2.4场景法场景法基础知识：732.2.4场景法场景法基础知识：每个经过用例的可能路径，可以确定不同的用例场景。场景1 基本流场景2 基本流备选流1 场景3
26、 基本流备选流1备选流2 场景4 基本流备选流3 场景5 基本流备选流3备选流1 场景6 基本流备选流3备选流1 备选流2 场景7 基本流备选流4 场景8基本流备选流3 备选流4 742.2.4场景法场景法基础知识：当备选流的数量众多时，场景的构建实际上等同于业务执行路径的构建，备选流越多，则执行路径越多，与程序执行路径类似，将导致场景爆炸。752.2.4场景法场景法基础知识：如何选取典型场景进行测试，以满足测试的完备性和无冗余性要求，基本原则如下：1.最少场景数等于基本流与备选流的总数。2.有且唯一有一个场景仅包含基本流。3.对应某个备选流，至少应有一个场景覆盖备选流，且在该场景中避免覆盖其
27、它的备选流。762.2.4场景法场景法的基本设计步骤：1.根据说明，描述出程序的基本流及各项备选流2.根据基本流和各项备选流生成不同的场景3.对每一个场景生成相应的测试用例4.对生成的所有测试用例重新复审，去掉多余的测试用例，测试用例确定后，对每一个测试用例确定测试数据值。772.2.4场景法场景法实战演练：例：以ATM机取款功能为例，进行测试用例的设计782.2.4场景法第一步：确定基本流和备选流79基本流(1)ATM处于就绪状态(2)插入银行卡(3)卡校验(4)输入密码(5)密码校验(6)选择“提款”(7)输入金额(8)取款校验(9)出钞(10)凭条打印选择(11)打印交易凭条(12)退卡
28、(13)用例结束ATM回到就绪状态备选流1银行卡无效备选流2密码错误（还有机会）备选流3密码错误（没有机会）备选流4ATM没有现金备选流5ATM内现金不足备选流6账面金额不足备选流7达到每日最大的提款金额备选流x退出2.2.4场景法场景法实战演练：第二步：根据基本流和备选流来确定场景 80场景基本流备选流场景1成功提款基本流场景2银行卡无效基本流备选流1场景3密码错误（还有机会）基本流备选流2场景4密码错误（没有机会）基本流备选流3场景5ATM没有现金基本流备选流4场景6ATM内现金不足基本流备选流5场景7账面金额不足基本流备选流6场景8达到每日最大的提款金额基本流备选流72.2.4场景法场景
29、法实战演练：第三步：设计用例 81测试用例ID场景/条件银行卡密码输入（选择）的金额账面金额ATM内金额日已取金额预期结果CW1场景1：成功提款VVVVVV成功提款CW2V(VALID,有效的）I(无效)n/a(不适用)2.2.4场景法场景法实战演练：第四步：来设计数据，把数据填入用例表中 822.3测试用例设计步骤（1）测试需求分析（2）测试用例设计（3）测试用例评审（4）测试用例完善832.4测试用例分级 从未有足够的时间做所有我们需要做的事情，这是在软件项目，尤其在测试中的一个普遍的话题。在测试执行过程中通常需要组织和安排测试用例来在有限的时间尽可能地实现测试目标。Ross Collar
30、d在“Use Case Testing”一文中说：“测试用例的前10%到15%可以发现75%到90%的重要缺陷”。测试用例的优先级划分将帮助确定找出了这前10%到15%的测试用例。842.4测试用例分级 为用例划分为不同的执行级别，可以为在每轮的版本执行中抽取用例提供共同的参考依据，但具体不同的产品，在测试过程中可以根据版本当前的具体情况进行安排是否进行测试。852.4测试用例分级 1.Level1 基本（1）该类用例涉及系统基本功能，1级用例的数量应受到控制。（2）划分依据：该用例执行的失败会导致多处重要功能无法运行的，如：表单维护中的增加功能、最平常的业务使用等。可以认为是发生概率较高的而
31、经常这样使用的一些功能用例。（3）该级别的测试用例在每一轮版本测试中都必须执行。862.4测试用例分级2.Level2 重要（1）2级测试用例涉及系统的重要功能。2级用例数量较多。（2）划分依据：主要包括一些功能交互相关、各种应用场景、使用频率较高的正常功能测试用例。（3）在非回归的系统测试版本中基本上都需要进行验证，以保证系统所有的重要功能都能够正常实现。在测试过程中可以根据版 本 当 前 的 具 体 情 况 进 行 安 排 是 否 进 行 测 试。872.4测试用例分级3.Level3 一般（1）3级测试用例涉及系统的一半功能，3级用例数量也较多。（2）划分依据：使用频率较低于2级用例。例
32、如：数值或数组的边界情况、特殊字符、字符串超长、与外部件交互消息失败、消息超时、事物完整性测试、可靠性测试等等。（3）在非回归的系统测试版本中不一定都进行验证，而且在系统测试的中后期并不一定需要每个版本都进行测试。882.4测试用例分级4.Level4 生僻（1）该级别用例一般非常少。（2）划分依据：该用例对应较生僻的预置条件和数据设置。虽然某些测试用例发现过较严重的错误，但是那些用例的处罚条件非常特殊，仍然应该被植入4级用例中。如界面规范化的测试也可归入4级用例。在实际使用中使用频率非常低、对用户可有可无的功能。（3）在版本测试中有某些正常原因（包括：环境、人力、时间等）经过测试经理同意可以
33、不进行测试。892.4测试用例分级测试用例分级的其它方法（1）小版本确认测试（Build Verification Tests(BVTs)Level1 基本（2）高（Highs）Level2 重要（3）中（Mediums）Level3 一般（4）低（Lows）Level4 生僻902.5测试用例编写要素与模版怎样为测试用例分配优先级 需要以下三步：第一步：（1）把所有功能性验证的测试标注为高级；（2）把所有错误和边界值或确认测试标注为中级；（3）把所有非功能性的测试（例如性能和可用性）标注为低级。912.5测试用例编写要素与模版怎样为测试用例分配优先级第二步：（1）把功能性验证测试分为两组：重
34、要和不是十分重要；将“不是十分重要”的功能性验证测试降级为中级 （2）把错误和边界测试分成两组：重要和不是十分重要，将“重要”的错误和边界测试升级为高级；（3）把非功能性测试分成两组：重要和不是十分重要，把“重要”的非功能性测试升级为中级。922.5测试用例编写要素与模版怎样为测试用例分配优先级第三步：将高优先级别的测试用例分成两组：严重和重要的，将“严重”的高优先级的测试用例升级为BVT优先级。最后，经过调整后一般测试用例中BVT级（1级）占10-15%，高级（2级）占20-30%,中级（3级）占40-60%，低级（4级）占低为10-15%。932.5测试用例编写要素与模版 一般来说，编写测
35、试用例所涉及的内容或者要素以及样式均大同小异，一般都包含主题、前置条件、执行步骤、期望结果等。测试用例可以用数据库、Word、Excel、xml等格式进行存储和管理。942.6测试用例设计误区 （1）能发现到目前为止没有发现的缺陷的用例是好的用例。（2）测试用例应该详细记录所有的操作信息，使一个没有接触过系统的人员也能进行测试。（3）测试用例设计是一劳永逸的事情。（4）测试用例不应该包含实际的数据。（5）测试用例中不需要明显的验证手段。95测试用例编写实战演练 某公司开发了一种聊天工具允许内部员工用公司特定邮箱和密码登陆,该聊天软件可以提供内部员工之间的日常打字聊天,语音聊天需求,一个用户可以
36、同时与多个用户分别聊天和语音,也可以在一个聊天窗口里面与多人一同聊天和语音,一个人能同时与30个人分别聊天,一个聊天窗口允许的最大人数为50人,但该工具不允许使用外部邮箱登陆,即使是内部用户邮箱密码也不能在外部网络登陆。96测试用例编写实战演练 作业：以一个B/S结构的软件的登录功能点为被测对象，假设用户使用的浏览器为IE6.0 SP4。功能描述如下：1.用户在地址栏输入相应地址，要求显示登录界面；2.输入用户名和密码登录系统，系统自动进行校验，并给出相应提示信息（假设能登录进系统的一组用户名为：user，密码为123456）；3.如果用户名或者密码任一信息未输入，登录系统会给出相应提示信息；
37、4.连续3次未通过验证时，自动关闭IE。972.7单元测试什么是单元测试?写了个类，要给别人用，会不会有bug？怎么办？测试一下。用main方法测试好不好？不好！不能一起运行！大多数情况下需要人为的观察输出确定是否正确 80个类难道需要写80个main方法？992.7单元测试 单元测试（unit testing），是指对软件中的最小可测试单元进行检查和验证。对于单元测试中单元的含义，一般来说，要根据实际情况去判定其具体含义，如C语言中单元指一个函数，Java里单元指一个类，图形化的软件中可以指一个窗口或一个菜单等。总的来说，单元就是人为规定的最小的被测功能模块。1002.7单元测试 单元测试地
38、位：101 上图是一个典型瀑布式软件开发流程，那么各项软件测试工作是在项目开发流程中循序渐进的进行的。2.7单元测试为什么要进行单元测试？重用测试，应付将来的实现的变化。以后基于我现在这个类写出来的其他代码，会更加有正确性。提高士气，明确知道我的东西是没问题的。成本：开发，测试，部署，维护。哪个阶段花的钱最多？维护。！最终提高软件的质量。1022.7单元测试单元测试的目标？确保各单元模块被正确地编码是单元测试的主要目标，但是单元测试的目标不仅测试代码的功能性功能性，还需确保代码在结构上结构上可靠且健全，并且能够在所有条件下正确响应。1032.7单元测试单元测试的依据？单元测试是对软件基本组成单
39、元进行测试。主要依据是：软件详细说明书软件详细说明书。1042.7单元测试单元测试的目标？（1）信息能否正确地流入和流出单元。（2）在单元工作过程中，其内部数据能否保持其完整性，包括内部数据的形式、内容及相互关系不发生错误，也包括全局变量在单元中的处理和影响。（3）在为限制数据加工而设置的边界处，能否正确工作。（4）单元的运行能否做到满足特定的逻辑覆盖。（5）单元中发生了错误，其中的出错处理措施是否有效。1052.7单元测试单元测试的任务？（1）模块接口测试。（2）局部数据结构测试。（3）路径测试。（4）边界条件测试。（5）错误处理测试。（6）代码书写规范1062.7单元测试谁来执行单元测试？
40、单元测试也是程序员的一项基本职责，程序员必须对自己所编写的代码保持认真负责的态度，这是也程序员的基本职业素质之一。同时单元测试能力也是程序员单元测试能力也是程序员的一项基本能力的一项基本能力，能力的高低直接影响到程序员的工作效率与软件的质量。1072.7单元测试根据是否执行程序可以将单元测试分为两类：单元静态测试单元动态测试1082.7单元测试单元静态测试 静态测试指不运行被测程序不运行被测程序本身而寻找程序代码中可能存在的错误或评估程序代码的过程，仅通过分析或检查源程序的方法、结构、过程、接口等来检查程序的正确性。1092.7单元测试 静态测试主要包括代码检查、静态分析两种途径。它可以由人工
41、进行，充分发挥人的逻辑思维优势，也可以借助软件工具自动进行。1102.7单元测试静态测试包括：代码检查：主要检查代码的设计是否一致、代码是否遵循标准性和可读性、代码的逻辑表达是否正确，以及代码结构是否合理等。静态分析：一种计算机辅助的静态分析方法，主要对程序进行控制流分析、数据流分析、接口分析和表达式分析等。程序设计语言不同，静态分析工具也不同。1112.7单元测试代码检查：代码检查包括桌面检查、代码审查、代码走查和技术评审四种情况。应根据项目的实际情况来决定采取哪种静态测试形式。1122.7单元测试桌面检查：是由程序员自己检查自己编写的程序。程序员在程序通过编译之后，进行单元测试设计之前，对
42、源程序代码进行分析，检验，并补充相关的文档，目的是发现程序中的错误。1132.7单元测试代码审查：是由若干程序员和测试人员共同组成一个会审小组，通过阅读、讲解、讨论和模拟运行的方式，对程序进行静态分析的过程。1142.7单元测试代码走查：与代码审查不同，不是简单地读程序和对照错误检查表进行检查，而是让与会者充当计算机。让测试用例沿程序的逻辑运行一遍，随时记录程序的踪迹，供分析和讨论用。1152.7单元测试技术评审：是指开发组、测试组和相关人员(QA、产品经理等)联合进行，也是采用讲解、提问并使用编码模板进行的查找错误的活动。一般也有正式的计划、流程和结果报告。1162.7单元测试什么样的情况下
43、需要执行静态分析？静态程序分析往往作为一个多人参与的项目中代码审查过程的一个阶段，因此编写完一部分代码之后就可以进行静态分析，分析过程不需要执行整个程序，这有助于在项目早期发现以下问题：变量声明了但未使用、变量类型不匹配、变量在使用前未定义、不可达代码、死循环、数组越界、内存泄漏等。1172.7单元测试单元静态分析工具静态程序分析工具PC-Lint是一款针对C/C+语言、windows平台的静态分析工具，FlexeLint是针对其他平台的PC-Lint版本。由于PC-Lint/FlexeLint是商业的程序分析工具，不便于大家对其进行学习和使用，因而下面我将介绍一个针对C语言的开源程序静态分析
44、工具splint。1182.7单元测试单元静态分析工具splint使用举例：1192.7单元测试单元静态分析工具splint使用举例：1202.7单元测试静态分析在项目编码过程中所处的位置1212.7单元测试静态分析的意义？静态分析工具在代码通过编译之后再对代码进行分析。我们会问：静态分析工具与编译器相比，所做的工作有什么不同？静态分析工具相比编译器，对代码进行了更加严格的检查，像数组越界访问、内存泄漏、使用不当的类型转换等问题，都可以通过静态分析工具检查出来，我们甚至可以在分析工具的分析标准里定义代码的编写规范，在检测到不符合编写规范的代码时抛出告警，这些功能都是编译器没有的。1222.7单
45、元测试什么是单元动态测试？单元动态测试就是通过选择适当的测试用例并实际运行选择适当的测试用例并实际运行所测程序，然后比较实际运行结果和预期结果进而找出错误的方法。动态测试有结构测试和功能测试。在结构测试中，常采用语句测试、分支测试或路径测试。1232.7单元测试单元动态测试工具工作原理：使所测试程序有控制地运行，并且自动地监视、记录、统计程序的运行情况。典型的方法是在所测试程序中插入检测各语句的执行次数、各分支点、各路径的探针（“插桩”），以便统计各种覆盖情况。1242.7单元测试单元动态测试工具使用：目前，最流行的单元测试工具是xUnit系列框架，常用测测试 工 具 根 据 语 言 不 同 分 为 Junit(Java)、CppUnit(C+)、Dunit(Delphi)、Nunit(.net)、PhpUnit(Php)等。下面以Junit为例简单介绍单元动态测试工具的使用。125
