测试用例设计

前言： 怎么设计自动化测试用例？是不是所有的手动用例都适合转成自动化测试用例？ 设计自动化测试用例需考虑的方面： 1、并不是所有的手工用例都要转为自动化测试用例。 考虑到脚本开发的成本，不要选择流程太复杂的用例。如果有必要，可以考虑把流程拆分成多个用例来实现脚本。 2、选择的用例最好可以构建成场景。 例如，一个功能模块，分多个用例，多个用例使用同一个场景。 3、选择的用例可以带有目的性。 例如，这部分是用例做冒烟测试，那部分用例是做回归测试等，当然，会存在重叠的关系。如果当前用例不能满足需求，那么唯有修改用例来适应脚本和需求。 选取的用例可以是主体流程，这部分适用于冒烟测试。 4、选取的用例可以是你认为是重复执行，很烦琐的部分。 例如，字段验证、提示信息验证这类，这部分适用于回归测试。 5、自动化测试也可以用来做配置检查、数据库检查。这些可能超越了手工用例，但也算用例拓展的一部分，项目负责人可以有选择地增加。 6、平时在手工测试时，如果需要构造一些复杂的数据或重复一些简单的机械式动作，则告诉自动化脚本，让它来帮你，或许你的效率会因此而得到提高。 在编写自动化测试用例过程中应该遵守以下几点原则： 1、一个用例为一个完整的场景，从用户登录系统到最终退出并关闭浏览器。 2、一个用例只验证一个功能点，不要试图在用户登录系统后把所有的功能都验证一遍。 3、尽量少的编写逆向逻辑用例

摘要：1. 登陆、添加、删除、查询模块是我们经常遇到的，这些模块的测试点该如何考虑 　1. 登陆、添加、删除、查询模块是我们经常遇到的，这些模块的测试点该如何考虑 　　1)登陆 　　① 用户名和密码都符合要求(格式上的要求) 　　② 用户名和密码都不符合要求(格式上的要求) 　　③ 用户名符合要求，密码不符合要求(格式上的要求) 　　④ 密码符合要求，用户名不符合要求(格式上的要求) 　　⑤ 用户名或密码为空 　　⑥ 数据库中不存在的用户名，不存在的密码 　　⑦ 数据库中存在的用户名，错误的密码 　　⑧ 数据库中不存在的用户名，存在的密码 　　⑨ 输入的数据前存在空格 　　⑩ 输入正确的用户名密码以后按[enter]是否能登陆 　　2) 添加 　　① 要添加的数据项均合理，检查数据库中是否添加了相应的数据 　　② 留出一个必填数据为空 　　③ 按照边界值等价类设计测试用例的原则设计其他输入项的测试用例 　　④ 不符合要求的地方要有错误提示 　　⑤ 是否支持table键 　　⑥ 按enter是否能保存 　　⑦ 若提示不能保存，也要察看数据库里是否多了一条数据 　　3) 删除 　　① 删除一个数据库中存在的数据，然后查看数据库中是否删除 　　② 删除一个数据库中并不存在的数据，看书否有错误提示，并且数据库中没有数据被删除 　　③ 输入一个格式错误的数据，看是否有错误提示

　　自动化测试用例的编写是实现项目自动化的核心，合理的用例设计是保证自动化效益和实用性的关键，也直接决定了自动化脚本是否具备可扩展和可维护性。由此，本篇文章主要为大家介绍了测试用例编写的规范和注意事项。 　 　一、自动化测试用例选择 　　自动化测试主要应用于基础功能的验证和回归，对于在项目迭代过程中不断修改的功能来说，手工测试的效率是大大高于自动化测试的。因此，我们在进行自动化之前，要挑选基础功能来进行自动化。在这个过程中，我们可以从手工测试用例中进行挑选，也可以专门为自动化编写一套用例。 　　在自动化初期，建议从手工测试用例中进行挑选。一方面手工测试用例的覆盖度最为全面，可以保证测试的全面性；另一方面，也会提高测试效率。我们挑选用例的原则是：清晰、简单、基础、改动小的功能。 　　 二、自动化测试用例编写 　　挑选完合适的用例之后，就是通过代码编写自动化用例的过程。这个过程主要包括数据预置、用例编写和用例后置三个步骤。 　 　1、数据预置 　　在进行用例编写之前，我们需要准备一些数据，保证用例能够真正的执行起来。比如，我们在测试一个网页登录功能，我们需要系统的URL参数、需要一个可以登录的用户名和密码；我们需要测试删除文件的功能，就需要提前上传一个文件，这个文件可以提前预置，也可以在执行删除操作之前，执行一个上传操作；通过哪种方式预置数据，需要根据项目的实际情况选择

1 、问：你在测试中发现了一个bug ，但是开发经理认为这不是一个bug ，你应该怎样解决？ 首先，将问题提交到缺陷管理库里面进行备案。 然后，要获取判断的依据和标准： 根据需求说明书、产品说明、设计文档等，确认实际结果是否与计划有不一致的地方，提供缺陷是否确认的直接依据； 如果没有文档依据，可以根据类似软件的一般特性来说明是否存在不一致的地方，来确认是否是缺陷； 根据用户的一般使用习惯，来确认是否是缺陷； 与设计人员、开发人员和客户代表等相关人员探讨，确认是否是缺陷； 合理的论述，向测试经理说明自己的判断的理由，注意客观、严谨，不参杂个人情绪。 等待测试经理做出最终决定，如果仍然存在争议，可以通过公司政策所提供的渠道，向上级反映，并有上级做出决定。 2 、问：给你一个网站，你如何测试？ 首先，查找需求说明、网站设计等相关文档，分析测试需求。 制定测试计划，确定测试范围和测试策略，一般包括以下几个部分：功能性测试；界面测试；性能测试；数据库测试；安全性测试；兼容性测试 设计测试用例： 功能性测试 可以包括，但不限于以下几个方面： 链接测试。链接是否正确跳转，是否存在空页面和无效页面，是否有不正确的出错信息返回。 提交功能的测试。 多媒体元素是否可以正确加载和显示。 多语言支持是否能够正确显示选择的语言等。 界面测试 可以包括但不限于一下几个方面： 页面是否风格统一，美观

基础题（65分） 1、什么是需求？需求有哪些来源？（3分） 答：需求的分类：直接需求（用户直接需求告知要求）和间接需求（行业需求要求）；需求的定义：准确的描述用户需求； 来源：行业、用户、团队、运营、客服、自己（调研反馈、数据分析、竞品分析）；数据分析：产品功能使用情况，如行业报告、产品后台数据等挖掘用户需求；调研反馈：通过市场调研或用户调研等方式挖掘用户真实需求；竞品分析：确立竞品分析的目的，然后分析竞品的功能和内容都有什么，通过与竞品的对比得出自身产品的需求； 直白点说：01：来源客户要求；02行业要求；03公司内部分析的需求； 2、为什么说需求需要测试，如何测试？（4分） 答：需求是标准，贯穿整个项目，是项目中最重要的标准，必须经过多方面（技术、角色：用户、产品、测试、开发）测试，才能合理安排项目进度和技术分析设计，确保需求符合用户要求和课实现。 测试方法：01评审，参加人员（用户、产品、测试、开发）；02场景和技术模拟，确保可实现；03行业调研； 3、单元测试的定义？测试意义是什么？（3分） 答：指对软件中的最小可测试单元进行检查和验证。对于单元测试中单元的含义，一般来说，要根据实际情况去判定其具体含义，如C语言中单元指一个函数，Java里单元指一个类，图形化的软件中可以指一个窗口或一个菜单等。总的来说，单元就是人为规定的最小的被测功能模块

功能测试的一些心得 　　 一、前言 　　 功能测试 是测试工程师的基础功，很多人功能测试还做不好，就想去做 性能测试 、 自动化测试 。很多人对功能测试的理解就是点点点，如何自己不用心去悟，去研究，那么你的职业生涯也就停留在点点点上了。在这里，我把我对功能测试的理解写下来。 　　 二、功能测试所需要掌握的技能 　　2.1 熟练使用 SQL 　　1、常用的 sql 语句一定会写。比如说增删改查之类。 　　2、了解 数据库 的事务、会编写存储过程、熟练常用的系统函数。 　　3、了解并可以进行数据库的备份、迁移、还原、镜像等操作 　　4、对 sql 语句进行调优，并对可以对运行的语句监控查看性能 　　5、了解数据库集群等操作。 　　2.2 Linux 　　Linux是测试人员的基础功，不需要掌握太难或者很不常见的Linux命令，正常能做到查看日志，定位问题就可以了。 　　1、基本命令 　　常用的Linux基本命令，面试经常会问的，或者给出一种场景，问你用什么命令。 　　2、查看日志 　　初级测试人员在工作时经常遇到，发现 bug ，开发不承认或者不愿意解决的情况，测试人员怎么摆脱这样的问题呢？ 　　那就是根据发现的bug根据日志级别，来查看日志，定位问题。 　　那这里首先要说一下日志级别了。 　　首先记住这一点：日志级别越高，输出的信息越少 。 　　具体的日志级别分为四级： 　　info

1. 正确的测试流程 需求分析阶段，tester就应该被involve，这样可以最早的发现问题，避免问题 需求确定后，开始pre-study，这个时候需要明确测试环境，测试需要的人力物力，人力需要考虑请假离职等原因，物力需要考虑第三方交付时间，节假日，综上得出deliver time 然后确定需求之后，开始做grooming，来分析测试点，需要从功能性能，兼容性，易用性，探索性等方面来设计测试点 编写测试用例，根据grooming的结果来编写测试用例 测试用例review，review测试用例，保证测试用例的质量与覆盖性 开始测试 提供测试报告 2. 测试的时候需要注意的一些点 需要记录自己的测试版本以及条件 测试的时候需要follow文档，以便于顺带验证文档的正确性 测试的时候可以先进行冒烟测试来看pipe，在第三方测试的时候这个尤其重要，也可以让第三方提供测试报告 测试的时候bug要以单子的形式记录，这样时间久了可以追溯 测试报告中需要写明测试结果，测试步骤，bug应该提供复现步骤，以及出现频率 3. 测试方法 来源： https://www.cnblogs.com/emmaduan/p/11597668.html

　　在软件测试过程中，一个成熟的团队一般都有自己的公共测试用例库。公共测试用例库即可复用的测试用例库。今天我们就讨论一下如何开发有效的可复用测试用例，并学会如何使用和管理。 一、可复用测试用例的开发 　　测试用例是为了验证最小功能点的一组输入、输出及操作序列的集合。可复用测试用例是指“为了复用目的而设计的测试用例”。复用的意义在于通过可复用测试用例验证功能相同或相近的模块，加快测试用例的设计进度、减少测试人员的负担；也可以帮助产品在设计类似功能时的需求细节补充；还可以与开发人员达成协议，后期在开发类似功能的时候，可以事先有一个既有的标准，提高开发效率和代码质量；　 　　 1.可复用维度分析 　　为高效使用可复用测试用例，测试用例的复用性可从三个维度分析： 　　 　　1）时间角度：使用以前软件版本的测试用例作为新版本测试用例的基础，可作为软件维护和回归测试时复用。 　　2）通用角度：以某平台或硬件为基础的软件，测试其平台特性的测试用例可以复用。如B/S结构网络应用产品，针对该网络结构数据传输安全的测试用例基本都可以复用。 　　3）应用角度：以某特定领域模型为基础构建的测试用例，在同一领域不同应用系统种的测试过程中可以复用。 　　 2.可复用测试用例质量特性 　　为构建高质量的可复用测试用例，需要规定可复用测试用例的本质特征，即对其质量特性进行分析

一、什么是配置文件？ 配置文件示例　　 [mysql] default-character-set = utf8 [mysqld] port = 3306 basedir = c:\mysql-5.7.25-winx64\mysql-5.7.25-winx64 daradir = c:\mysql-5.7.25-winx64\mysql-5.7.25-winx64\data max_connections = 200 character-set-server = utf8 default-storage-engine = INNODB explicit_defaults_for_timestamp = true 为什么要做配置文件？ 　　所有的代码和配置都变成模块化可配置化，这样就提高了代码的复用性，不用每次都去修改代码内部。 场景举例 　　 1、多处地方需要使用同一个参数，这时候最好是配置化，这样改一处就可以了 　　 2、如果是经常变化的变量，我们也可以做这个配置。---> 与参数化要区分开来 python中常见的配置文件格式 　　　.ini、.conf、.cfg结尾的文件 配置对象 section option 二、ConfigParser模块 掌握一些比较基础的用法：跟file文件一样，要先打开才能进行读取操作 实例化ConfigParse对象：cf =

前言 单元测试是软件开发中必不可少的一环，但是在平常开发中往往因为项目周期紧，工作量大而被选择忽略，这样往往导致软件问题层出不穷。线上出现的不少问题其实在有单元测试的情况下就可以及时发现和处理，因此培养自己在日常开发中写单元测试的能力是很有必要的。无论是对自己的编码能力的提高，还是项目质量的提升，都是大有好处，本文将介绍 Java 单元测试框架 JUnit 5 的基础认识和使用来编写单元测试，希望同样对你有所帮助。 本文所涉及所有代码片段均在下面仓库中，感兴趣的小伙伴欢迎参考学习： https://github.com/wrcj12138aaa/junit5-actions 版本支持： JDK 8 JUnit 5.5.2 Lomok 1.18.8 认识 JUnit 5 要说什么是 JUnit 5，首先就得聊下 Java 单元测试框架 JUnit，它与另一个框架 TestNG 占据了 Java领域里单元测试框架的主要市场，其中 JUnit 有着较长的发展历史和不断演进的丰富功能，备受大多数 Java 开发者的青睐。 而说到 JUnit 的历史，JUnit 起源于 1997年，最初版本是由两位编程大师 Kent Beck 和 Erich Gamma 的一次飞机之旅上完成的，由于当时 Java 测试过程中缺乏成熟的工具，两人在飞机上就合作设计实现了 JUnit 雏形，旨在成为更好用的