测试用例

[+] 目的 范围 术语解释 测试用例原则 1 系统性 2 连贯性 3 全面性 4 正确性 5 符合正常业务惯例 6 仿真性 7 可操作性 测试用例主要元素 测试用例编写规范 1 常规的测试用例 2 初始化的测试用例 3 边界的测试用例 4 空值的测试用例 5 格式错误的测试用例 6 溢出的测试用例 7 关联的测试用例 8 唯一值的测试用例 9 权限不足的测试用例 10 角色权限的测试用例 测试用例编写细则 1 测试用例命名规则 2 测试用例编号规则 测试用例编写方法 1 测试用例编写准备 2 测试用例编写方法 1 目的 统一 用例编写的规范，为测试设计人员提供测试用例编写的指导，提高编写的测试用例的可读性，可执行性、合理性。为测试执行人员更好执行测试，提高测试效率，最终提高公司整个产品的质量。 测试 2 范围 适用于集成 测试 用例和 用例的编写，现在编写用例的辅助工具为 系统测试 TestDirector 8.0。 3 术语解释 集成测试： 集成测试是在软件系统集成过程中所进行的测试，其主要目的是检查软件单位之间的接口是否正确。 系统测试 ： 系统测试是对已经集成好的软件系统进行彻底的测试，以验证软件系统的正确性和性能等满足其规约所指定的要求，检查软件的行为和输出是否正确并非一项简单的任务，它被称为测试的 “先知者问题 ”。 4 测试用例原则 4.1 系统性 1.

测试与调试（负责人：孙媛媛） 　一、功能检查 　　1 、功能是否齐全，例如：增加、删除、修改 　　2 、功能是否多余 　　3 、功能是否可以合并 　　4 、功能是否可以再细分 　　5 、软件流程与实际业务流程是否一致 　　6 、软件流程能否顺利完成 　　7 、各个操作之间的逻辑关系是否清晰 　　8 、各个流程数据传递是否正确 　　9 、模块功能是否与需求分析及概要设计相符 　　二、面向用户的考虑 　　1 、操作方便性，如：按键次数是否最少 　　2 、易用性，面对用户的操作是否简单易学 　　3 、智能化考虑 　　4 、提示信息是否模糊不清或有误导作用 　　5 、要求用户进行的操作是否多余，能否由系统替代 　　6 、能否记忆操作的初始环境，无需用户每次都进行初始化设置 　　7 、是否不经确认就对系统或数据进行重大修改 　　8 、能否及时反映或显示用户操作结果 　　9 、操作是否符合用户习惯，比如：热键 　　10 、各种选项的可用及禁用是否及时合理 　　11 、某些相似的操作能否做成通用模块 　　软件数据处理测试用例模板 　　一、输入数据 　　1 、边界值 　　2 、大于边界值 　　3 、小于边界值 　　4 、最大个数 　　5 、最大个数加 1 　　6 、最小个数 　　7 、最小个数减 1 　　8 、空值、空表 　　9 、极限值 　　10 、 0 值 　　11 、负数 　　12

测试 用例 要包括欲测试的功能、应输入的数据和预期的输出结果。测试数据应该选用少量、高效的测试数据进行尽可能完备的测试；基本目标是：设计一组发现某个错误或某类错误的测试数据，测试用例应覆盖方面： 1、 正确性测试：输入用户实际数据以验证系统是满足需求规格说明书的要求；测试用 例中的测试点应首先保证要至少覆盖需求规格说明书中的各项功能，并且正常。 2、 容错性（健壮性）测试：程序能够接收正确数据输入并且产生正确（预期）的输出， 输入非法数据（非法类型、不符合要求的数据、溢出数据等），程序应能给出提示 并进行相应处理。把自己想象成一名对产品操作一点也不懂的客户，在进行任意操作。 3、 完整（安全）性测试：对未经授权的人使用软件系统或数据的企图，系统能够控制的程度，程序的数据处理能够保持外部信息（ 数据库 或文件）的完整。 4、 接口间测试：测试各个模块相互间的协调和通信情况，数据输入输出的一致性和正确性。 5、 数据库测试：依据数据库设计规范对软件系统的数据库结构、数据表及其之间的数据调用关系进行测试。 6、 边界值分析法：确定边界情况（刚好等于、稍小于和稍大于和刚刚大于等价类边界值），针对我们的系统在测试过程中主要输入一些合法数据/非法数据，主要在边界值附近选取。 7、 压力测试：输入10条记录运行各个功能，输入30条记录运行，输入50条记录运行。。。进行测试。 8、等价划分

输入格式： 每个输入包含 1 个测试用例，即一个以科学计数法表示的实数 A。该数字的存储长度不超过 9999 字节，且其指数的绝对值不超过 9999。 输出格式： 对每个测试用例，在一行中按普通数字表示法输出 A，并保证所有有效位都被保留，包括末尾的 0。 输入样例 1： +1.23400E-03 输出样例 1： 0.00123400 输入样例 2： 1.2E+10 输出样例 2： 12000000000 # include <iostream> # include <string> using namespace std ; int main ( ) { string s ; int len0 = 0 ; cin >> s ; for ( int i = 0 ; i < s . length ( ) ; i ++ ) if ( s [ i ] == 'E' ) { for ( int j = i + 2 ; j < s . length ( ) ; j ++ ) len0 = len0 * 10 + ( s [ j ] - '0' ) ; if ( s [ 0 ] == '-' ) cout << '-' ; if ( len0 == 0 ) { for ( int j = 1 ; j < i ; j ++ ) cout << s [ j ] ; } else if ( s [

测试数据设计方法一： 构造测试数据时，需要看数据的来源，数据的来源一般来讲有三个个，一个是根据被测系统需求的分析，针对正常业务，异常情况，边界情况等来构建完整的数据，又称为“造”数据。 这不仅仅包括最基本的基础数据，比如：用户、权限、配置、原数据等，还包括上面提到的业务数据。对于比较小型的系统来说可行度高，对于大型的系统来说可能较为复杂。 测试数据设计方法二： 第二种方式就是利用现有系统，这适合已有类似系统，测试是针对升级或者增加功能的产品化的系统。这种情况把已经在生产环境中运行的数据导出。在此基础上再进行数据的整理、 加工为测试数据。 测试数据设计方法三： 还有一种方式就是将现有非电子化的业务数据录入到系统中，在验证业务的同时也完成了测试数据的积累。即边测试边积累数据。但是这种情况积累的数据往往有一定局限性，因为 已、经发生的业务数据基本是正确的、一致的，而且可能缺少某些特定业务的数据（不常发生的业务）。这样就需要根据对测试需求的分析，追加新的测试数据，以便能完整覆盖业务 类型。 测试数据应用： 1，不该为空的数据是否有校验； 2，该有默认值的数据默认值是否正确； 3，引用其它功能生成的数据，是否会实时刷新； 4，页面关闭或系统重启后，数据的初始化设置等 5，数据的长度、类型控制是否合理，比如身份证号，实际业务中会有字母，且会出现在最后 一位 对应方法： 等价类、边界值、场景法

回归测试(Regreesion Testing) 目的: 验证缺陷得到了正确的修复,同时对系统的变更,没有影响以前的功能 策略: 　　1) 完全重复测试 　　重新执行所有在前期测试阶段建立的测试用例,来确认问题修改的正确性和修改的扩散局部影响性 　　2) 选择性重复测试 　　即有选择地,重新执行部分在前期测试阶段建立的测试用例,来测试被修改的程序 　　　　a) 覆盖修改法 　　　　即针对被修改的部分,选取或重新构造测试用例验证没有错误再次发生的用例选择方法 　　　　b)周边影响法 　　　　该方法不但包含覆盖修改法确定的测试用例,还需要分析修改的扩散影响,对哪些收到修改间接影响的部分选择测试用例验证它没有受到不良影响,该方法比覆盖修改法更充分一点. 　　　　c)指标达成法 　　　　这是一种类似于单元测试的方法,在重新执行测试前,先确定一个要达成的指标,如修改的部分代码,100%的覆盖,与修改有关的接口 60%的覆盖等,基于这种要求选择一个最小的测试用例集合 流程: 　(适用于单元测试,集成测试,系统测试) 　　　1)在测试策略指定阶段,制定回归测试策略 　　　2)确定需要回归测试的版本 　　　3)回归测试版本发布,按回归测试策略执行回归测试 　　　4)回归测试通过,关闭缺陷跟踪单(问题单 　　　5)回归测试不通过,缺陷跟踪单返回开发人员,开发人员重新修改问题,再次提交测试人员回归测试

为什么需要测试用例 测试的目的是在有限的资源下，尽可能多的找出系统的缺陷。这就要求在测试中，尽可能完全的走完系统的所有流程，保证所有的分支都经过测试。 而测试过程是由人来执行的，不可能避免的会遗漏一些应该测试内容，这样就很容易出现测试不全面的问题。再者，现有的软件开发大多都是迭代式进行的，需要对同一个功能反复测试多遍。很有可能第一轮测试得比较全面，当进行第二轮的时候，可能也会遗漏某些点。这种情况下，测试过程是由人控制的，具有盲目性，是不可控制的。 而测试用例就是把软件测试行为做一个科学化的组织和归纳，用来指导测试行为。 一般需求入基线后，测试人员开始介入项目，对需求进行分析，并根据自己对需求的理解设计出详细的测试用例。这样在测试执行时，按照设计好的过程去执行，避免由于人为的原因使测试不全面。 在设计测试用例的过程中，测试人员也可以根据自己的理解，对需求提出不同的看法，或者发现需求中某些功能描述得不够详细或者有歧义，提早发现问题，降低项目风险。 测试用例设计的方法分类 从测试方法上可以分为黑盒测试、白盒测试、灰盒测试。 1.1. 黑盒测试 程序的内部逻辑实现对测试人员是透明的。测试人员只需要根据需求文档来决定程序应该做什么事情，会产生什么样的结果。测试人员对需求中的每个点进行覆盖测试。目前流行的黑盒测试设计方法有： Ø 等价类划分 Ø 边界值分析 Ø 因果图法 Ø 场景法 1.2.

为什么么需要因果图 在黑盒测试中，等价类划分或边界值分析法只考虑了不同的输入和不同的输出之间的关系。但是如果是各个输入条件之间有很复杂的组合，这二种设计方法都很难用一个系统的方法进行描述，设计测试用例只能依靠测试人员主观的猜测或者分析，具有很大的盲目性。 让我们先来看一个简单的例子。 假设某个软件需求文档中有这样的说明： 第一列字符必须是A或B，第二列字符必须是一个数字，在此情况下进行文件的修改。但如果第一列字符不正确，则给出信息L；如果第二列字符不是数字，则给出信息M。 先用等价类来分析，第一列会有三个输入：A、B、非(A B)的字符。第二列字符有二个输入：数字、非数字（为了简便起见，有关数字再细化的问题不做讨论）。这是一个根据理论进行分析的过程。但是做完了这一步，并不能得出输出。也就是说如何分析第一列和第二列的关系，没有明确的理论指导。实际操作过程中，各个测试人员可能会设计出不同的测试用例。 这个例子还仅仅是一个2个输入条件之间有关系，如果到更复杂的应用中，可能会更多。如果没有一种方法指导我们的思想，测试用例就会很不全面。 而因果图正好弥补了上述缺点。我们先来看一下什么叫因果图。因果图是一种形式化的语言（以图的形式表现），它不仅描述了原因和结果之间的关系，也描述了各个原因之间、各个结果之间复杂关系的组合。在这里，因就是程序的输入条件，而果则是程序的输出

输入选择框 输入框 验证输入框之前的标题是否正确 验证输入与输出是否信息一致 未输入任何信息，当输入框里面有提示信息时，查看提示信息是否合理 字段长度校验(边界值) 验证输入状态：当处于某种状态下，输入框是否处于可写或非可写状态。例如，系统自动给予的编号等栏位作为唯一标识，当再次处于编辑状态下，输入框栏位应处于不可写状态，如果可写对其编辑的话，可能会造成数据重复引起冲突等 验证对特殊字符输入的处理： a.输入域如对某些字符禁止输入时，是否有限制 b.中文、英文、空格，数字，字符，下划线、单引号 等所有特殊字符的组合 c.所有特殊字符测试（!~@#$^&*()_+{}|:“<>?/.,;‘[]=-`￥……（）–：《》？、。，；’【】、=-•） 验证二代身份证号： a.长度不等于18位的数字串，是否提示错误 b.特殊字符X在最后一位，是否校验通过 c.特殊字符X在前面17位中任意一位，是否提示错误 d.带字母（非X）、特殊字符、空格、汉字，是否提示错误 e.特殊的18位数字串，如‘00…00’,‘11…11’，是否提示错误 验证多行文本输入的处理： a.是否允许回车换行 b.保存后再显示能够保持输入时的格式 c.仅输入回车换行，检查能否正确保存；若能，查看保存结果。若不能，查看是否有正确提示 d.仅输入空格，检查能否正确保存；若能，查看保存结果。若不能，查看是否有正确提示

前言 之前我们的用例数据都是配置在Http 请求中，每次需要增加，修改用例都需要打开 jmeter 重新编辑，当用例越来越多的时候，用例维护起来就越来越麻烦，有没有好的方法来解决这种情况呢？我们可以将用例的数据存放在 csv 文件中，然后通过 csv 文件配置来读取用例中的数据，执行测试。 一：设置测试用例，创建用例数据文件：testcase.csv 用例名称变量含义 ： ${caseSeq}:用例编号 ${apiType}:api 类型 ${apiSeq} ：api 版本号 ${apiName}：api 名称 ${priority}:优先级 ${url}:api 路径 ${methods}:请求方法 ${parameter}: 请求参数 ${expectValue}:期望值，用于断言 二：新建一个线程组，命名为：数据驱动，添加http 请求默认值，配置好IP地址和端口号 三：添加逻辑控制器-循环控制器。 循环控制器的作用可以控制整个用例循环执行的次数。默认值是1根据用例数量可以修改为8 四：在循环控制器节点下创建 CSV数据 文件设置，具体配置内容如下: 五：添加逻辑控制器——如果（if） 控制器，if 控制器的作用为根据不同条件执行不同的用例，例如这里根据不同的接口请求类型，分别添加GET和POST两个控制器。 （1） GET 设置的条件语句为 ："${methods}"==