一、测试方法:
功能测试
| 黑盒测试或数据驱动测试,不考虑内部结构及代码,从产品界面、架构出发。输入数据在预期结果和实际结果之间进行评测,进而提出更加使产品达到用户使用的要求。 |
性能测试 | 产品满足需求提及的性能级别和承受压力的能力。负载、压力、并发 |
安全性测试 | 应用程序级别安全性和系统级别安全性。 安全性测试应用:防SQL漏洞扫描;防XSS、防钓鱼;get、post、cookie、session |
兼容性测试 | 浏览器、分辨率、数据库、操作系统、手机APP。 主流内核不同的浏览器:IE、Firefox、Chrome、Safaris、opera 分辨率兼容测试:1、需要一个虚拟机,将之分辨率设为1024x600; 2、怎么测试? 1)需要一个虚拟机,将之分辨率设为1024x600; |
可靠性测试 | 指与在规定的一段时间和条件下,软件能维持其性能水平能力有关的一组属性。 用户权限控制、用户和密码封闭性、系统对用户错误登录的次数限制、留痕功能、屏蔽用户操作错误、错误提示准确性、错误是否导致系统异常退出、数据备份与恢复说手段、输入数据有效性检查、异常情况的影响、网络故障对系统的影响。 |
易用性测试 | 用户使用软件是感觉的方便度 |
安装\卸载测试 | 确保软件在正常情况下和异常情况的不同条件下安装/卸载 |
二、测试需求
- 测试需求应全部覆盖已定义的业务流程,以及功能和非功能方面的需求。
- 测试需求项必须是可核实的;应指明满足需求的正常的前置条件以及不满足需求时的出错条件;不涉及具体的测试数据。
- 测试需求是衡量测试覆盖率的重要指标,同时是开发测试用例的依据。
- 测试需求分析过程:需求采集(需求规格说明书)—>测试需求分析(测试要点、功能交互、质量特性、测试类型)—>测试需求评审。
- 需求采集的提取方法:通过列表的形式对软件开发需求进行梳理,形成原始需求列表,列表的内容包括需求标识、原始测试需求描述;将每一条软件需求对应的开发文档及章节号作为软件需求标识;使用软件需求的简述作为原始需求描述。
三、测试计划
- 测试计划包括测试项目的背景、目标、范围、方式、资源、进度安排、测试组织、以及与测试有关的风险。
- 5W原则:why、what、where、who。
- 测试结束条件:需求覆盖率、用例执行率、缺陷遗留率。达到预期质量的目标。
- 确定测试对象优先级,确定测试实现的先后顺序;把注意力集中到最关键、最有意义和优先级最高的测试对象上。
四、测试用例设计
用例设计技术:等价类划分方法,边界值分析方法,错误推测法,因果图法,判定表驱动分析方法,场景法。
-
等价类划分:
(1)把所有可能的输入数据,即程序的输入域划分成若干部分(子集),然后从每一个子集中选取少数具有代表性的数据作为测试用例.该方法是一种重要的,常用的黑盒测试用例设计方法.
(2)分为有效等价类和无效等价类,
(3)划分等价类标准:完备测试、避免冗余
(4)划分等价类的方法:
- 在输入条件规定了取值范围或值的个数的情况下,则可以确立一个有效等价类和两个无效等价类。
- 在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下,可确立一个有效等价类和一个无效等价类。
- 在输入条件是一个布尔量的情况下,可确定一个有效等价类和一个无效等价类。
- 在规定了输入数据的一组值(假定n个),并且程序要对每一个输入值分别处理的情况下,可确立n个有效等价类和一个无效等价类。
- 在规定了输入数据必须遵守的规则的情况下,可确立一个有效等价类(符合规则)和若干个无效等价类(从不同角度违反规则)。
- 在确知已划分的等价类中各元素在程序处理中的方式不同的情况下,则应再将该等价类进一步的划分为更小的等价类
2.边界值分析法
(1)选择测试用例原则:
- 如果输入条件规定了值的范围,则应取刚达到这个范围的边界的值,以及刚刚超越这个范围边界的值作为测试输入数据。
- 如果输入条件规定了值的个数,则用最大个数,最小个数,比最小个数少一,比最大个数多一的数作为测试数据。
- 根据规格说明的每一个输出条件,分别使用以上两个规则
- 如果程序的规格说明给出的输入域或输出域是有序集合,则应选取集合的第一个元素和最后一个元素作为测试用例。
3.错误推测法:
基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例。
4.因果图法:
(1)因果图方法最终生成的是判定表。它适合于检查程序输入条件的各种组合情况。利用因果图生成测试用例的基本步骤:
- 分析软件规格说明描述中, 哪些是原因(即输入条件或输入条件的等价类),哪些是结果(即输出条件), 并给每个原因和结果赋予一个标识符。
- 分析软件规格说明描述中的语义.找出原因与结果之间, 原因与原因之间对应的关系. 根据这些关系,画出因果图。
- 由于语法或环境限制, 有些原因与原因之间,原因与结果之间的组合情况不可能出现. 为表明这些特殊情况, 在因果图上用一些记号表明约束或限制条件。
- 把因果图转换为判定表。
- 把判定表的每一列拿出来作为依据,设计测试用例。
(2)因果图方法是一个非常有效的黑盒测试方法,它能够生成没有重复性的且发现错误能力强的测试用例,而且对输入、输出同时进行了分析。
(3)从因果图生成的测试用例(局部,组合关系下的)包括了所有输入数据的取TRUE与取FALSE的情况,构成的测试用例数目达到最少,且测试用例数目随输入数据数目的增加而线性地增加。
(4)如果哪个开发项目在设计阶段就采用了判定表,也就不必再画因果图,而是可以直接利用判定表设计测试用例了。
5.判定表驱动测试方法:
判定表是分析和表达多逻辑条件下执行不同操作的工具。
(1)判定表通常由四个部分组成:
- 条件桩(Condition Stub):列出了问题的所有条件,通常认为列出得条件的次序无关紧要。
- 动作桩(Action Stub):列出了问题规定可能采取的操作,这些操作的排列顺序没有约束。
- 条件项(Condition Entry):列出针对它左列条件的取值,在所有可能情况下的真假值。
- 动作项(Action Entry):列出在条件项的各种取值情况下应该采取的动作。
(2)规则及规则合并:
规则:任何一个条件组合的特定取值及其相应要执行的操作称为规则。在判定表中贯穿条件项和动作项的一列就是一条规则。显然,判定表中列出多少组条件取值,也就有多少条规则,既条件项和动作项有多少列。
化简:就是规则合并有两条或多条规则具有相同的动作,并且其条件项之间存在着极为相似的关系。
(3)判定表的建立步骤:
- 确定规则的个数.假如有n个条件。每个条件有两个取值(0,1),故有2n种规则。
- 列出所有的条件桩和动作桩。
- 填入条件项。
- 填入动作项。等到初始判定表。
- 简化.合并相似规则(相同动作)。
6.场景法(流程分析法):
(1)场景法也叫流程分析法,是将软件系统的某个流程看成路径,用路径分析的方法来设计测试用例。根据流程的顺序依次进行组合,使得流程的各个分支都能走到。
(2)场景法设计步骤:
- 根据说明,描述出程序的基本流及各项备选流
- 根据基本流和各项备选流生成不同的场景
- 对每一个场景生成相应的测试用例
- 对生成的所有测试用例重新复审,去掉多余的测试用例,测试用例确定后,对每一个测试用例确定测试数据值
五、测试方法的选择:
- 首先进行等价类划分,包括输入条件和输出条件的等价划分,将无限测试变成有限测试,这是减少工作量和提高测试效率最有效方法。
- 在任何情况下都必须使用边界值分析方法。经验表明用这种方法设计出测试用例发现程序错误的能力最强。
- 用错误推测法再追加一些测试用例。
- 对照程序逻辑,检查已设计出的测试用例的逻辑覆盖程度。如果没有达到 要求的覆盖标准,应当再补充足够的测试用例。
- 对于业务流清晰的系统,可以利用场景法贯穿整个测试案例过程,在案例中综合使用各种测试方法。