测试用例设计

目　录 1. 引言 1 1.1. 背景 1 1.2. 参考资料 1 1.3. 假定和约束 1 1.4. 用户的特点 1 2. 功能需求 1 2.1. 系统范围 1 2.2. 系统体系结构（二层架构的系统可剪裁本小节） 1 2.3. 系统总体流程 2 2.4. 需求分析 2 2.4.1. XXXXXXX(功能需求名称) 2 2.4.1.1. 功能描述 2 2.4.1.2. 业务建模 2 2.4.1.3. 用例描述 3 2.4.1.4. 用户界面 5 2.4.2. XXXXXXX(功能需求名称) 5 3. 非功能需求 5 3.1. 性能要求 5 3.1.1. 精度 5 3.1.2. 时间特性要求 6 3.1.3. 输人输出要求 6 3.2. 数据管理能力要求 6 3.3. 安全保密性要求 6 3.4. 灵活性要求 6 3.5. 其他专门要求 6 4. 运行环境规定 6 4.1. 设备 6 4.2. 支持软件 7 4.3. 接口 7 4.4. 控制 7 5. 需求跟踪 7 6. 签批单 7 1. 引言 1.1. 背景 说明： a．待开发的软件系统的名称； b．本项目的任务提出者、开发者、用户及实现该软件的计算中心或计算机网络； C．该软件系统同其他系统或其他机构的基本的相互来往关系。 1.2. 参考资料 列出本说明书中引用和参考的资料，如： a．本项目的经核准的 计划任务书 或合同

本章介绍UML建模元素 1： Stereotype-也被称为类型、构造型 UML里的元素扩展，简单来说其功能就是在已有的类型上添加一些标记，类似于打个戳，从而生成新的东西。 简单的说加一句话来更加清楚准确描述这个类。 2： Actor（主角、参与者）-是在系统之外与系统交互的某人或某事物，在建模过程中处于核心地位。 参与者和系统之间有一个明确的边界，参与者只能存在于边界之外，边界之内的所有人和事物都不是参与者。 人或物都可以时参与者； 3：如何确定参与者-一定是启动业务的主角 4：业务主角和业务工人 业务主角（business actor）是参与者的一个版型，用于定义业务的主角，不依赖计算机系统。业务主角是与业务系统有着交互的人和事物，用来确定业务范围。 业务范围：项目所涉及的所有客户业务的客观存在；系统范围：软件将要实现对应业务的系统功能。 业务工人被动参与业务 5：参与者和干系人 干系人-是与要建设的这个系统有利益相关的一切人和事 参与者就是干系人代表，对系统提出要求来获得他所代表的涉众的利益。 用户（user），指的是系统的使用者，是参与者的代表，一个用户可以代理多个参与者。 角色（role），指的是参与者的职责，一个角色代表了系统中的一类职责。 6:用例：一种把现实世界的需求捕获下来的方法。用例定义了一组用例实例，其中每个实例都是系统所执行的一系列操作

本人主要做一个知识的归类与记录，如是转载类文章，居首都会备注原链接，尊重原创者，谢谢！ 此文转载原链接：https://www.cnblogs.com/bianfengjie/p/9210311.html 一、前言 功能测试是测试工程师的基础功，很多人功能测试还做不好，就想去做性能测试、自动化测试。很多人对功能测试的理解就是点点点，如何自己不用心去悟，去研究，那么你的职业生涯也就停留在点点点上了。在这里，我把我对功能测试的理解写下来。 二、功能测试所需要掌握的技能 2.1 熟练使用SQL 1、常用的 sql 语句一定会写。比如说增删改查之类。 2、了解数据库的事务、会编写存储过程、熟练常用的系统函数。 3、了解并可以进行数据库的备份、迁移、还原、镜像等操作 4、对 sql 语句进行调优，并对可以对运行的语句监控查看性能 5、了解数据库集群等操作。 2.2 Linux Linux是测试人员的基础功，不需要掌握太难或者很不常见的Linux命令，正常能做到查看日志，定位问题就可以了。 1、基本命令 常用的Linux基本命令，面试经常会问的，或者给出一种场景，问你用什么命令。 具体请看：https://www.cnblogs.com/bianfengjie/p/9213180.html 2、查看日志 初级测试人员在工作时经常遇到，发现bug，开发不承认或者不愿意解决的情况

在我们的测试工作中，对于某个APP的测试其实有很多东西都是类似的可以抽象出来的，所以针对APP的测试过程和重点关注内容，做以下梳理和总结。 　　 一、首先是测试资源确认及准备 　 　1.1 　　产品需求文档、产品原型图、接口说明文档以及设计说明文档等应齐全； 　 　1.2 　　 测试设备及工具的准备：IOS和andriod不同版本的真机，以及相关测试工具的准备。 　　 二、 测试用例 的设计与评审 　　（1）根据产品需求文档、产品原型图等文档，设计客户端的一般功能测试用例； 　　（2）测试用例评审、修改与完善，评审通过后着手进入正式测试阶段。 　 　三、UI测试 　　（1）确保手头的原型图与效果图为当前最新版本，符合产品经理及用户要求； 　　（2）测试过程中一切以效果图为准，若有用户体验方面的建议，可以先以邮件的形式与产品经理确认，确认通过后，可以正式向开发提出用户体验方面的问题； 　　（3）由于测试环境中的数据为模拟数据，测试时必须预先考虑到正式环境中可能出现的数据类型。 　　 四、功能测试 　　（1）功能测试时主要依据编写的功能测试用例进行软件功能的遍历； 　　（2）涉及的测试主要包括基本功能测试，安装、卸载、运行测试，异常处理（包括网络突然断开或者网速过慢、机器内存不足等异常情况的处理）测试。 　 　五、中断测试 　　（1）软件运行过程中接电话、收短信、锁屏、闹铃、充电

一、前置知识点： 1、了解软件相关概念； 2、有一定的软件测试基础； 3、了解测试流程； 4、了解测试生命周期 二、熟悉常用术语： 黑盒测试、灰盒测试、白盒测试（功能划分）； 功能测试、性能测试、安全测试（职业划分）; 兼容性测试 、易用性测试、 UI元素测试（易用点划分）; 三、测试用例是什么？ 答：测试用例（Test Case）是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个 程序 路径或核实是否满足某个特定需求。 测试用例是测试工作的核心、是一组在测试时输入输出的标准、是软件需求的具体对照。 四、测试用例有什么作用？ 1、检验软件是否满足客户需求； （1、通过编写测试用例，可以把产品文档的内容逐一进行测试防止遗漏；2、也可以能更好的知道软件的各个功能及作用；3、及时消除需求文档中的歧义及错误的地方，以便可以及时纠正，避免后期的不必要的麻烦与损失） 2、体现一个测试人员的工作量； （通过编写测试用例，按照自己每天的工作量，可以推测出完成该测试任务需要多久，以便可以合理划分时间，以及汇报该测试任务所需时间，以便进行团队及领导的后续安排） 3、展现测试用例的设计思路； （通过编写测试用例，可以理清思路，设计出合适的测试计划，对产品有一个更好的认识与把握） 五、测试员用例包含那些内容？ 用例编号、用例名称、测试背景、前置条件、优先级、重要级、测试数据、测试步骤

4. 测试设计技术 2015-06-24 目录 4.1 测试开发过程 4.1.1 测试用例生命周期 4.1.2 测试用例的质量评估 4.1.3 测试用例的组织 4.2 测试设计技术的种类 4.6 选择测试技术 4.1 测试开发过程 [1] 返回 4.1.1 测试用例生命周期 测试条件标识：简单的说，就是确定测试什么？需求文档中的需求条目，我们可以认为是测试条件！ 测试用例设计：说明如何来识别测试什么(用白盒设计技术还是黑盒设计技术)？即如何详细识别需求中的测试条件！ 测试用例实现：得到的是详细的测试用例步骤！ 测试用例执行：是通过运行测试用例（自动或手动）来对系统进行测试！ 测试用例管理：是如何来组织、跟踪和维护测试用例过程！ 4.1.2 测试用例的质量评估 测试用例与系统需求（测试条件）之间进行关联，保证需求的可追溯性；测试用例包含明确的测试输出预期结果； 确定测试覆盖率 需求变更对测试设计和测试执行的影响 测试用例在发现缺陷方面的有效性； 4.1.3 测试用例的组织 按照软件功能模块组织； 按照测试用例的测试类型组织； 按照测试用例的优先级组织； 4.2 测试设计技术的种类 [1][2] 返回 基于规格说明的测试技术（黑盒测试技术）具有以下共同特点： 使用正式或非正式的模型来描述需要解决的问题、软件或其组件等； 根据这些模型，可以系统地导出测试用例。 基于结构的技术

1.目的 　　测试用例评审流程规范主要为开展测试用例评审工作提供指引，规范测试用例评审管理工作。 2.测试用例评审流程内容 　　2.1.前提：测试人员编写完一个完整的功能模块的测试用例或已完成所有测试用例的编写； 2.2.流程输入：A.测试用例； B.需求规格说明； 2.3.流程输出：A.问题记录清单； B.测试用例评审报告； 2.4.参与评审人员：项目经理、测试负责人、测试人员、需求分析人员、架构设计人员、开发人员； 2.5.评审方式： 　　　　1）召开评审会议。与会者在测试用例编写人员讲解之后给出意见或建议，同时记录下评审会议记录； 　　　　2）通过邮件、及时通讯工具与相关人员沟通。 　　　　　　无论采用哪种方式，都应该在评审之前事先把需要评审的测试用例相关文档以邮件的形式发给参与评审的相关人员，同时在邮件中提醒参与评审的相关人员在评审前查阅一遍评审内容，并记录相关问题，以便在评审会议上提出，以节省沟通成本。 　　2.6评审用例检查清单： 　　　　1）测试用例是否按照公司定义的模板进行编写的； 　　　　2）测试用例的本身的描述是否清晰，是否存在二义性； 　　　　3）测试用例内容是否正确，是否与需求目标相一致； 　　　　4）测试用例的期望结果是否确定、唯一的； 　　　　5）操作步骤应与描述是否相一致； 　　　　6）测试用例是否覆盖了所有的需求； 　　　　7）测试设计是否存在冗余性

在我们的测试工作中，对于某个APP的测试其实有很多东西都是类似的可以抽象出来的，所以针对APP的测试过程和重点关注内容，做以下梳理和总结。 　　 一、首先是测试资源确认及准备 　 　1.1 　　产品需求文档、产品原型图、接口说明文档以及设计说明文档等应齐全； 　 　1.2 　　 测试设备及工具的准备：IOS和andriod不同版本的真机，以及相关测试工具的准备。 　　 二、 测试用例 的设计与评审 　　（1）根据产品需求文档、产品原型图等文档，设计客户端的一般功能测试用例； 　　（2）测试用例评审、修改与完善，评审通过后着手进入正式测试阶段。 　 　三、UI测试 　　（1）确保手头的原型图与效果图为当前最新版本，符合产品经理及用户要求； 　　（2）测试过程中一切以效果图为准，若有用户体验方面的建议，可以先以邮件的形式与产品经理确认，确认通过后，可以正式向开发提出用户体验方面的问题； 　　（3）由于测试环境中的数据为模拟数据，测试时必须预先考虑到正式环境中可能出现的数据类型。 　　 四、功能测试 　　（1）功能测试时主要依据编写的功能测试用例进行软件功能的遍历； 　　（2）涉及的测试主要包括基本功能测试，安装、卸载、运行测试，异常处理（包括网络突然断开或者网速过慢、机器内存不足等异常情况的处理）测试。 　 　五、中断测试 　　（1）软件运行过程中接电话、收短信、锁屏、闹铃、充电

转载 测试用例评审 首先要清楚内部评审的定义，是测试组内部的评审，还是项目组内部的评审。评审的定义不同，内容也不会相同。 一.评审分类： 测试组内部评审 测试组内部的评审，应该着重于： 测试用例本身的描述是否清晰，是否存在二义性； 是否考虑到测试用例的执行效率，往往测试用例中步骤不断重复执行，验证点却不同，而且测试设计的冗余性，都造成了效率的低下； 是否针对需求跟踪矩阵，覆盖了所有的软件需求； 是否完全遵守了软件需求的规定。这并不一定的，因为即使再严格的评审，也会出现错误，应具体情况具体对待。 项目组内部评审 如果是项目组内部的评审，也就需要评审委员会来做了，角度不同，评审的标准也不同。比如： 收集客户需求的人员注重你的业务逻辑是否正确； 分析软件需求规格的人注重你的用例是否跟规格要求一致； 开发负责人会注重你的用例中对程序的要求是否合理。 二.测试用例评审步骤 测试用例的评审能够使用例的结构更清晰，覆盖的用户场景更全面；对于测试工程师来说也是一个快速提高用例设计能力的过程。 1.需要评审的原因 测试用例是软件测试的准则，但它并不是一经编制完成就成为准则。由于用例开发人员的设计经验和对需求理解的深度各不相同，所以用例的质量难免会有不同程度的差异。 2.进行评审的时机 第一，是在用例的初步设计完成之后进行评审； 第二是在整个详细用例全部完成之后进行二次评审。如果项目时间比较紧张

五、测试 1.单元测试 　　 单元测试的方式是黑盒测试，即通过每个环节的输入输出情况进行测试。程序由四个类组成，对应生成四个测试类，使用Junit5对其中的主要方法进行测试。测试的大致思路是预先设计较为简单的数独用例，生成新的对象，运行方法，并将阶段性的结果与预先计算的结果相比较。 　　 有些方法具有返回值，便于设计测试类，例如对 Main::isNumber()进行测试： //Main::isNumber public static boolean isNumber(String str){ String reg = "^[0-9]+?$"; return str.matches(reg); }//MainTest::testIsNumber @Test final void testIsNumber() { Assert.assertEquals(true, Main.isNumber("100")); Assert.assertEquals(true, Main.isNumber("10a")); Assert.assertEquals(true, Main.isNumber("4.5")); } 　　 对于更多没有返回值的方法，采取验证阶段结果的方法，预测方法执行后对象属性的变化并加以验证。例如对SudokuGenerator::creatFirstBlock()方法的测试