盖种测试
1.语句覆盖：语句覆盖是几个测试用例的设计，通过测试程序运行。使每一个可以运行的语句至少运行一次。
2.判定覆盖（也叫分支覆盖）：设计若干个測试用例。运行所測程序，使程序中每一个推断的取真分支和取假分支至少运行一次。
3.条件覆盖：设计足够的測试用例，运行所測程序。使程序中每一个推断的每一个条件的每一个可能取值至少运行一次。
4.判定——条件覆盖：设计足够的測试用例，运行所測程序，使程序中每一个推断的每一个条件的每一个可能取值至少运行一次。而且每一个可能的推断结果也至少运行一次。
5.条件组合測试：设计足够的測试用例，运行所測程序，使程序中每一个推断的全部条件取值组合至少运行一次。
6.路径測试：设计足够的測试用例，运行所測程序。要覆盖程序中全部可能的路径。
用例的设计方案基本的有以下几种：条件測试，基本路径測试，循环測试。通过上面的方法能够实现測试用例对程序的逻辑覆盖。和路径覆盖。
測试的目的是检查程序的行为是否符合设计规格。程序的行为就是某种输入时会产生什么输出，因此，一个典型的測试用例完毕下面工作：设定输入数据、执行程序、验证输出是否符合预期。
函数的输入数据一般包含：
A、參数；
B、成员变量。仅仅考虑函数须要读取的成员变量；
C、全局变量，仅仅考虑函数须要读取的全局变量；
以上三项。当涉及到复杂数据类型时。仅仅考虑函数须要读取的域。比如，一个结构对象。有十个域。而函数仅仅读取当中一个域。则不必考虑其它九个域。
D、其它数据。如函数须要读取文件或数据库中的数据，则要先在文件或数据库中设置好这些数据。
显然。全部可能输入都进行測试。既不可能也无意义，我们应该用一定的规则选择有代表性的数据作为输入。输入可分为三大类：正常输入，边界输入。非法输入，每大类还可再分为若干小类，划分小类的根据是：同一小类中每一个数据都具有等价的測试效果。也就是说。小类中取任取一个数据作为输入，假设測试通过，能够肯定同小类的其它输入也能够測试通过。这就是寻常说的“等价类法”。
正常输入
比如字符串的Trim函数，功能是将字符串前后的空格去除。那么正常的输入能够有四类：
前面有空格；
后面有空格；
前后均有空格；
前后均无空格。
边界输入
上例中空字符串能够看作是边界输入。
再如一个表示年龄的參数，它的有效范围是0-100。那么边界输入有两个：0和100。
非正常输入
垃圾数据或使代码不能完毕正常功能的数据。如一个文件操作的函数，非正常输入有这么几类：
文件不存在。
文件夹不存在。
文件正在被其它程序打开；
权限错误。
预期输出
一个完整的測试用例应该有预期输出。预期输出就是程序执行后的预期结果。通常表如今对某些数据的改动，即预期输出要自己主动推断程序所改写的数据的结果值是否符合预期。
程序可能改动的数据包含：
A、返回值；
B、输出參数；
C、成员变量，仅仅考虑函数所改写的成员变量；
D、全局变量。仅仅考虑函数所改写的全局变量；
以上四项，当涉及到复杂数据类型时，仅仅考虑函数所改写的域，比如，一个结构对象，有十个域，而函数仅仅改写了当中一个域。则不必考虑其它九个域。
E、其它数据，如函数改写文件或数据库中的数据。也是一种输出，只是通常难于自己主动推断是否符合预期，可用人工查看来取代。
Test Case Template
┃用例编号 │ BOSS_ FS_ MARKETING_NEW_01P ┃
┠──────┼───────────────────────────┨
┃測试优先级 │高（还有“较高、中、较低、低”几个等级） ┃
┠──────┼───────────────────────────┨
┃用例摘要 │新增营销记录 ┃
┠──────┼───────────────────────────┨
┃測试类型 │功能性測试（相应还有“安全性測试”等） ┃
┠──────┼───────────────────────────┨
┃用例类型 │基本事件（相应还有“备选事件”、“异常事件”） ┃
┠──────┼───────────────────────────┨
┃用例设计者 │songfun ┃
┠──────┼───────────────────────────┨
┃设计日期 │2005-04-25 ┃
┠──────┼───────────────────────────┨
┃相应需求编号│REQ_ MARKETING_NEW_01 ┃
┠──────┼───────────────────────────┨
┃相应UI │Marketing.htm ┃
┠──────┼───────────────────────────┨
┃相应UC │UC_ MARKETING_NEW_01 ┃
┠──────┼───────────────────────────┨
┃版本 │Build v0.1 ┃
┠──────┼───────────────────────────┨
┃相应开发者│Frank ┃
┠──────┼───────────────────────────┨
┃前置条件 │操作员登录营销管理系统 ┃
┠──────┼───────────────────────────┨
┃測试方法 │等价类划分（相应还有“错误推測法”、“边界值分析”等） ┃
┠──────┼───────────────────────────┨
┃输入数据 │username：51testing 性别：男金额：10元描写叙述：aaaaaaa ┃
┠──────┼───────────────────────────┨
┃运行步骤 │①.进入【营销下发】页面。 ┃
┃ │②.点击『添加』button。 ┃
┃ │③.输入相应数据； ┃
┃ │④.点击『确定』button； ┃
┃ │⑤.在后台数据库(test/test@testDB)输入查询语句验证： ┃
┃ │ select * from MarketingTab where ID='1001' ┃
┃ │ ┃
┠──────┼───────────────────────────┨
┃预期输出 │㈠.运行步骤④后，页面弹出加入成功提示信息框； ┃
┃ │㈡.运行步骤⑤后查询数据库，记录确实加入成功且数据无误 ┃
┃ │ ┃
┠──────┼───────────────────────────┨
┃实际结果 │符合预期 ┃
┠──────┼───────────────────────────┨
┃測试日期 │2005-05-01 ┃
┠──────┼───────────────────────────┨
┃结论 │ ┃
┗━━━━━━┷━━━━━━━━━━━━━━━━━━━━━━━━━━━┛
測试用例要包含欲測试的功能、应输入的数据和预期的输出结果。
測试数据应该选用少量、高效的測试数据进行尽可能完备的測试；基本目标是：设计一组发现某个错误或某类错误的測试数据。測试用例应覆盖方面：
1、 正确性測试：输入用户实际数据以验证系统是满足需求规格说明书的要求；測试用 例中的測试点应首先保证要至少覆盖需求规格说明书中的各项功能，而且正常。
2、 容错性（健壮性）測试：程序可以接收正确数据输入而且产生正确（预期）的输出， 输入非法数据（非法类型、不符合要求的数据、溢出数据等）。程序应能给出提示
并进行对应处理。把自己想象成一名对产品操作一点也不懂的客户。在进行随意操作。
3、 完整（安全）性測试：对未经授权的人使用软件系统或数据的企图，系统可以控制的程度，程序的数据处理可以保持外部信息（数据库或文件）的完整。
4、 接口间測试：測试各个模块相互间的协调和通信情况。数据输入输出的一致性和正确性。
5、 数据库測试：根据数据库设计规范对软件系统的数据库结构、数据表及其之间的数据调用关系进行測试。
6、 边界值分析法：确定边界情况（刚好等于、稍小于和稍大于和刚刚大于等价类边界值），针对我们的系统在測试过程中主要输入一些合法数据/非法数据，主要在边界值附近选取。
7、 压力測试：输入10条记录执行各个功能，输入30条记录执行，输入50条记录运行。。。
进行測试。
8、等价划分：将全部可能的输入数据（有效的和无效的）划分成若干个等价类。
9、错误猜測：主要是依据測试经验和直觉，參照以往的软件系统出现错误之处。
10、效率：完毕预定的功能，系统的执行时间（主要是针对数据库而言）。
11、可理解（操作）性：理解和使用该系统的难易程度（界面友好性）。
12、可移植性：在不同操作系统及硬件配置情况下的执行性。
13、回归測试：依照測试用例将全部的測试点測试完成。測试中发现的问题开发者 已经解决，进行下一轮的測试。
14、比較測试：将已经发版的相似产品或原有的老产品与測试的产品同一时候执行比較。或与已往的測试结果比較
说明：针对不同的測试类型和測试阶段，測试用例编写的側重点有所不同。
1、 当中第1、2、6、8、9、13项为模块（组件、控件）測试、组合（集成）測试、系统測试都涉及并重点測试的方面。
2、 单元（模块）測试（组件、控件）測试：重点測试第5项。
3、 组合（集成）測试：重点进行接口间数据输入及逻辑的測试，即第4项。
4、 系统測试：重点測试第3、7、10、11、12、14项。
5、 当中压力測试和可移植性測试假设是公司的系列产品，能够选用当中有代表性的产品进行一次代表性測试就可以。
6、 GMPS基础測试用例设计完毕后，其它的測试项目仅仅编写设计与之不同部分的測试用例。
7、 对于每一个測试项目測试的測试用例不是一成不变的，随着測试经验的积累或在測试其它项目发现有測试不充分的測试点时。能够不断的补充完好測试项目的測试用例。
。
 A. GukiZ and Contest 水题)
