测试的覆盖种类
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 ┃
┠──────┼───────────────────────────┨
┃前置条件 │操作员登录营销管理系统 ┃
┠──────┼───────────────────────────┨
┃测试方法 │等价类划分（对应还有“错误猜测法”、“边界值分析”等） ┃
┠──────┼───────────────────────────┨
┃输入数据 │用户名：51testing 性别：男金额：10元描述：aaaaaaa ┃
┠──────┼───────────────────────────┨
┃执行步骤 │①.进入【营销下发】页面； ┃
┃ │②.点击『增加』按钮； ┃
┃ │③.输入相应数据； ┃
┃ │④.点击『确定』按钮； ┃
┃ │⑤.在后台数据库()输入查询语句验证： ┃
┃ │ 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、 对于每个测试项目测试的测试用例不是一成不变的，随着测试经验的积累或在测试其他项目发现有测试不充分的测试点时，可以不断的补充完善测试项目的测试用例。
阅读(665) | 评论(0) | 转发(0) |
