3.14 测试用例编写方法以及实现规则+接口、性能测试术语

阳光穿透心脏的1/2处 2023-09-27 15:29 7阅读 0赞

**测试用例实现规则**

规则1：用例描述要求  
每个用例必需要有至少一条操作步骤和预期结果；  
操作步骤描述清晰。如：在什么页面，点击什么链接或按钮；页面入口、链接、按钮名称都要写清楚；  
**操作步骤中不要包含结果的检查；  
预期结果中只能包含结果，不能有步骤**；  
用例描述中**不允许出现假设性词汇，比如：假如，或许，可能等**；  
用例描述中**不允许出现二义性语句**。

规则2：用例名称要求  
用例名称以模块/页面/功能点去命名，命名格式：验证XXX是否正常；  
用例名称不允许出现重复、包含关系，或者仅有数字编号差异；  
用例名称简介易懂，不要包括具体操作步骤。

规则3：用例要素要求  
用例名称、所属模块、状态、责任人、用例等级、前置条件、步骤描述、预期结果为必填内容，不能为空，其他字段为选填内容。

规则4：用例等级要求  
由于User Story的优先级决定的是在一个版本中的开发优先级，用例的重要性参考的是模块对于系统功能的重要度，因此这里的重要性不以Use Story优先级为参考依据，这里当前所有功能测试用例等级默认都是P0。  
P0：核心功能测试用例（冒烟测试），确定此版本是否可测，该用例执行失败会导致多个重要功能无法运行；  
P1：高优先级测试用例，最常执行以保证整体功能稳定，包括基本功能测试以及重要的错误、边界测试（含UI部分、兼容性）；  
P2：中优先级测试用例，更全面地验证功能的各个方面，包括异常测试、中断、断网等；  
P3：低优先级测试用例，不常常被执行，比如性能、压力、兼容性等。

规则5：前置条件要求  
执行用例测试步骤前需要做的所有必备条件，原则上所有用例都有前置条件；  
前提条件包括测试执行入口、账号类型和权限、数据准备；  
不可将其他用例作为前置条件，但可以将其它用例执行结果作为前置条件。

规则6：步骤描述要求  
每一测试步骤对应一条预期结果；  
每一条预期结果与其对应的测试步骤的编号要求保持一致；  
一个结果有多个检查点时，确保检查点完整；  
一个界面展示可做一个单独用例；  
一个功能点可做一个单独用例；  
（若同一个功能中预期结果相同时，可以考虑不同步骤合并在同一个步骤描述中；查询条件相关测试点，可考虑以每个输入框为一个步骤，此步骤描述包括多种情况）  
不管以何种方式划分描述，用例及步骤必须覆盖所有的页面、功能点、以及业务场景。

规则7：预期结果要求  
结果含需要验证的所有结果输出，如页面检查、存储检查、消息检查等；  
结果涉及页面，需明确页面提示结果、数据变化；  
结果涉及存储：需明确关键值变化、数据库具体的表和关键字字段值变化；  
结果涉及消息：需明确关键查看内容；  
结果对应不同输入数据有差别时需分别对应描述清晰；  
结果要观察设备端响应是否正常。

规则8：测试数据要求  
测试数据可在测试用例规定的范围内做一定变化；  
需求涉及逻辑计算时，测试数据需要明确给出，编写形式为：\[字段名：字段值\]；  
对于页面输入数据，需要区分必填项。

**测试用例的常用功能点：**

输入数据设计  
边界值，边界值+1，边界值-1  
最大个数，最大个数+1，最小个数，最小个数-1  
空值、空表  
极限值  
0值，负数，非法字符  
日期、时间控制  
跨年度数据  
数据格式  
数据之间的关联性、逻辑性  
计算方式以及计算结果准确性，数字精度的取舍问题，汇总数据与分项数据累加的误差问题

常用的较验  
字段长度较验  
必输项校验  
重名校验  
字符类型较验  
标点符号检查  
中文字符处理

搜索（查询）设计  
空白搜索  
模糊搜索  
错误搜索  
精确搜索  
组合搜索  
重置搜索  
日期搜索要考虑起止时间比较、时间选择范围、起止日期同一天是否能查到当日数据（如：默认只选择日期时，起是日期+00:00:00，止是日期+23:59:59）  
部分列表测试时还要考虑搜索与分页、导出之前是否有影响。

按键处理  
浏览器前进后退  
常用快捷键检查  
回车键检查

默认值  
文本框  
单选框  
多选框  
下拉列表

界面检查  
只读项  
文字拼写  
字体  
页面跳转  
按钮功能

总结：设计用例中用例编写应严格根据需求规格说明书及测试需求功能分析点进行，要求覆盖全部需求功能点。

设计用例中测试用例设计条理清晰，描述正确。 用例名称：描述清楚该用例所要达到的测试目的。 用例必须清晰地描述此用例所需的前提条件。 测试用例编写要步骤明确，输入输出要素清晰，并且清晰无疑义。 测试用例结果的可判定性：即测试执行结果的正确性是可判定的，每一个测试用例都应有相应的期望结果且预期结果可以验证。

设计用例中测试用例的粒度必须合理，均匀覆盖测试需求，基本度是：验证一个功能点（同一页面没有任何操作，整体页面检查算一个功能点）一条用例，没有重复、冗余的测试用例。

**软件测试测试用例编写方法：**

1． 正确性测试  
输入用户实际数据以验证系统是满足需求相关文档的要求；测试用例中的测试点应首先保证要至少覆盖需求中的各项功能，并且正常。  
2．容错性（健壮性）测试  
程序能够接收正确数据输入并且产生正确（预期）的输出，输入非法数据（非法类型、不符合要求的数据、溢出数据等），程序应能给出提示并进行相应处理。把自己想象成一名对产品操作一点也不懂的客户，在进行任意操作。  
3．完整（安全）性测试  
对未经授权的人使用软件系统或数据的企图，系统能够控制的程度，程序的数据处理能够保持外部信息（或文件）的完整。  
4．接口间测试  
测试各个模块相互间的协调和通信情况，数据输入输出的一致性和正确性。  
5．数据库测试  
依据数据库设计规范对软件系统的数据库结构、数据表及其之间的数据调用关系进行测试。  
6．边界值分析法  
确定边界情况（刚好等于、稍小于和稍大于和刚刚大于等价类边界值），针对我们的系统在测试过程中主要输入一些合法数据/非法数据，主要在边界值附近选取。  
7．压力测试  
输入10条记录运行各个功能，输入30条记录运行，输入50条记录运行，进行测试。  
8．等价划分  
将所有可能的输入数据（有效的和无效的）划分成若干个等价类。  
9．错误推测  
主要是根据测试经验和直觉，参照以往的软件系统出现错误之处。  
10．效率  
完成预定的功能，系统的运行时间（主要是针对数据库而言）。  
11. 可理解（操作）性  
理解和使用该系统的难易程度（界面友好性）。  
12. 可移植性  
在不同操作系统及硬件配置情况下的运行性。  
13. 回归测试  
按照测试用例将所有的测试点测试完毕，测试中发现的问题开发人员。  
14. 比较测试  
将已经发版的类似产品或原有的老产品与测试的产品同时运行比较，或与已往的测试结果比较。

**接口测试文档术语定义：**

1，并发用户：绝对并发，相对并发  
2，点击率：用户提交数据数  
3，事物响应时间：3,5,10区间  
4，资源的利用率：内存，cpu，网路，I/o的利用率，input导包 output关闭流管道  
5，吞吐量：单位时间内的处理能力  
6，负载测试：性能指标来测瓶颈用户数  
7，压力测试：在指标达到瓶颈时系统还能不能继续运行  
8，绝对并发测试：线程同步，死锁的问题  
9，疲劳测试：可靠性测试，检查系统有没有内存的泄露，  
10，内存溢出：需要占用的内存超过系统的可用内存  
11，内存泄漏：内存无法被收回

**性能测试文档术语定义：**

请求响应时间：从客户端发起一个请求开始，到客户端接收到从服务器返回的响应，整个过程所耗费的时间。

事务响应时间：系统处理一个事务所耗费的时间，如转账。

吞吐量：单位时间内系统处理的客户端请求的数量，包含一次性能测试过程中网络上传输的数据量的总和与硬盘传输数据流的速度，传输数据为读出数据和写入数据的和。

吞吐率：单位时间内网络上传输的数据量。

并发：模拟大量用户进行同一的操作。

每秒点击数：负载测试期间每秒内vuser在服务器上的点击次数，通过点击次数可以估算出vuser的生成负载数。

负载测试：通过逐步增加系统负载，测试系统的性能变化。并最终确定在满足系统性能的情况下，系统最大能承受的负载量测试。

压力测试：不断给被测系统增加压力，直到系统被压垮为止，用来测试系统能承受的最大压力。

事务：从客户端发起一个或多个请求（这些请求组成一个完成的操作），到客户端接收到从服务器返回响应的过程。

集合点：模拟大量用户在同一时刻，对被测系统进行同一操作。

检查点：回放脚本期间搜索特定的文本来验证服务器响应的内容正确性。