2022年测试用例标准 .pdf

测试用例标准1、前言统一测试用例编写的规范，为测试设计人员提供测试用例编写的指导，提高编写的测试用例的可读性，可执行性、合理性。为测试执行人员更好执行测试，提高测试效率，最终提高公司整个产品的质量2、范围本文档适合测试人员内部使用，适合于任何产品和项目。3、测试用例编写原则3.1 系统性对于系统业务流程要能够完整说明整个系统的业务需求、系统由几个子系统组成以及它们之间的关系；对于模块业务流程要能够说明清楚子系统内部功能、重要功能点以及它们之间的关系；3.2 连贯性对于系统业务流程来说，各个子系统之间是如何连接在一起，如果需要接口，各个子系统之间是否有正确的接口；如果是依靠页面链接，页面链接是否正确；对于模块业务流程来说，同级模块以及上下级模块是如何构成一个子系统，其内部功能接口是否连贯3.3 相关性考虑各个产品之间的相关性，当某个产品某个页面的字段发生增删改时，其它产品是否有相应变化，和后台数据库之间是否匹配当某个产品增加某个功能时，其它相关产品是否有相应措施3.4 全面性应尽可能覆盖程序的各种路径应尽可能覆盖系统的各个业务应考虑存在跨年、跨月的数据大量数据并发测试的准备系统中各功能、业务的异常情况3.5 正确性输入用户实际数据以验证系统是否满足需求规格说明书的需求。测试用例中的测试点应保证至少覆盖需求规格说明书中的各项功能。3.6 符合正常业务惯例测试数据应符合用户实际工作业务流程兼顾各种业务变化的可能要符合当前业务行业法律，法规。3.7 仿真性名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 1 页，共 5 页 - - - - - - - - - 人名、地名、电话号码等应具有模拟功能，符合一般的命名惯例。3.8 容错性（健壮性）程序能够接收正确数据输入并且产生正确（预期）的输出，输入非法数据（非法类型、不符合要求的数据、溢出数据等） ，程序应能给出提示并进行相应处理。4、测试用例设计方法4.1 等价类划分法将所有可能的输入数据（有效的和无效的）划分成若干个等价类。4.2 边界值分析法指对输入的边界条件进行分析，设计出针对边界值的测试用例。4.3 因果图法就是利用图解法分析软件输入( 原因) 和输出条件 ( 结果) 之间的关系，以设计测试用例的方法。因果图法适合于检查程序输入条件的多种情况的组合，并最终生成判定表，来获得对应的测试用例。4.4 功能图法功能图是描述程序状态变化、转移的过程，因为软件运行或操作的过程可以看作是其状态不断发生变化的过程。测试用例的设计就是如何覆盖所有软件表现出来的状态，即在满足输入/ 输出的一组条件下，软件运行是一系列有次序的、受控制的状态变化过程。4.5 错误推测法推测法主要依赖经验、 直觉来作出简单的判断甚至是猜测，给出可能存在缺陷的条件、 场景等，在找到缺陷后，设计出相应的测试用例。4.6 正交实验设计方法主要步骤是：对软件需求规格说明中的功能要求进行划分( 层层分解与展开 ) ，分解成具体的、相对独立的基本功能。根据基本功能的质量需求，找出影响其功能实现的操作对象和外部因素，每个因素的取值可以看作水平，多个取值就存在多个水平。确定待测试软件中所有因素及其权值，这是测试用例设计的关键，确保全面、准确。权值是依据各因素的影响范围、发生的频率和质量的需求来确定的。加权筛选，生成因素分析表。利用正交表构造测试数据集，正交表的每一行，就是一条测试用例。考虑交互作用不可忽略的处理因素和不可混杂的原则，有交互作用的组合优先安排。利用正交实验设计方法设计测试用例，可控制生成的测试用例数量，覆盖率高且测试效率高。4.7 接口间测试测试各个模块相互间的协调和通信情况，数据输入输出的一致性和正确性。4.8 数据库测试依据数据库设计规范对软件系统的数据库结构、数据表及其之间的数据调用关系进行测试。4.9 可理解（操作）性理解和使用该系统的难易程度（界面友好性）。名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 2 页，共 5 页 - - - - - - - - - 4.10 可移植性在不同操作系统及硬件配置情况下的运行性。5、测试用例编写规范5.1 测试用例命名规范以功能模块和业务流程进行命名5.2 测试用例编号规则用例编号规则：测试模块名称的第一个字母进行命名（大写）-功能编号，若测试模块名称比较长时，可进行简写一般简拼不超过5 个字母：如：测试模块为“调试程序” ，功能编号为“ TSRJ” ；测试模块为“华电云通报表管理软件” ，功能编号为“ BBGL ”功能编号规则直接以001、002、003. 调试程序下温控调试模块下的某个用例编号为“WKTS-001”5.3 测试用例文档书写内容1、被测试对象的介绍2、测试范围与目的3、测试环境与测试辅助工具的描述4、功能测试用例主要元素前置条件（可选）：系统权限配置或前、后台配置描述（所有进行操作的前提条件）。操作步骤： 测试的操作步骤描述用例描述： 功能点描述。测试数据： 前期数据准备。期望结果： 描述输入数据后程序应该输出的结果。实际结果： 描述本条用例的实际测试情况，并判断实际测试结果与预期结果的差别。Bug编号： 需要进流程的对应事物流程的编号。优先级： 为用例划分为不同的执行级别备注： 测试过程中遇到的问题等情况说明。6、测试用例级别划分Level1 ：该类用例涉及系统基本功能，1 级用例的数量应受到控制划分依据：该用例执行的失败会导致多出重要功能无法运行的，如：表单维护中的增加功能、 最平常的业务使用等。可以认为是发生概率较高的而经常这样使用的一些功能用例。该级别的测试用例在每一轮版本测试中都必须执行Level2 ：2 级测试用例涉及系统的重要功能。2 级用例数量较多。划分依据：主要包括一些功能交互相关、各种应用场景、使用频率较高的正常功能名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 3 页，共 5 页 - - - - - - - - - 测试用例在非回归的系统测试版本中基本上都需要进行验证，以保证系统所有的重要功能都能够正常实现。 在测试过程中可以根据版本当前的具体情况进行安排是够进行测试。Level3 ：3 级测试用例涉及系统的一半功能，3 级用例数量也较多。划分依据：使用频率较低于2 级用例。例如：数值或数组的便捷情况、特殊字符、字符串超长、与外部件交互消息失败、消息超时、事物完整性测试、可靠性测试等等。在非回归的系统测试版本中不一定都进行验证，而且在系统测试的中后期并不一定需要每个版本都进行测试Level4 ：如果没有可以不适用该级别该级别用例一半非常少。划分依据： 该用例对应较生僻的预置条件和数据设置。虽然某些测试用例发现过较严重的错误，但是那些用例的处罚条件非常特殊，仍然应该被植入4 级用例中。如界面规范化的测试也可归入4 级用例。在实际使用中使用频率非常低、对用户可有可无的功能。在版本测试中有某些正常原因（包括：环境、人力、时间、硬件设备等）经过项目经理和测试负责人同意可以不进行测试。7、编写用例注意事项7.1 功能检查功能是否齐全，例如：增加、删除、修改，查询条件是否合理，用户使用是否方便功能是否多余功能是否可以合并功能是否可以再细分软件流程与实际业务流程是否一致软件流程能否顺利完成各个操作之间的逻辑关系是否清晰各个流程数据传递是否正确模块功能是否与需求分析及概要设计相符批量增加、批量修改，增加、修改等录入比较频繁的界面或录入数据量较多的界面，是否支持全键盘或全鼠标操作，并且使用通用的键实现数据字段的有序切换7.2 面向用户的考虑操作方便性，如：按键次数是否最少，并不以开发实现技术限制为限制，而是以用户使用方便性和应用软件约定和通常的快捷键来实现提出合理建议易用性，面对用户的操作是否简单易学智能化考虑提示信息是否模糊不清或有误导作用。 错误信息是否有用户语言风格的出错后续处理建议提示要求用户进行的操作是否多余，能否由系统替代。 系统升级后， 用户能否不做任何操作自动进行所有升级的数据、环境等准备工作，包括删除缓存等动作能否记忆操作的初始环境，无需用户每次都进行初始化设置是否不经确认就对系统或数据进行重大修改能否及时反映或显示用户操作结果操作是否符合用户习惯，比如：热键各种选项的可用及禁用是否及时合理名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 4 页，共 5 页 - - - - - - - - - 某些相似的操作能否做成通用模块7.3 软件流程测试反流程操作反逻辑操作重复操作反业务流程操作违反流程的打乱流程的不按操作手册的乱操作8、附件缺陷等级划分标准测试用例模板名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 5 页，共 5 页 - - - - - - - - -