点击上方蓝字关注我们！ | 导语 使用YAML文件描述测试用例，自动化生成测试用例，并提供网页访问的能力；同时对测试用例数据进行多维度的统计，提供丰富的测试用例管理和查看视图，更好的保障客户端迭代质量。 背景 “开发负责质量”是研发效能提升的重要一环，有利于推动更合理的架构设计，形成研发上的闭环，让做自动化、做单元测试的成本足够低。 在研发效能提升的大背景下，开发也要开始着手编写测试用例。我们先来看下测试用例是什么： 测试用例是从测试角度对需求各个功能点的详细文字描述，包括执行步骤、预期结果等，用于指
此时这个开始设计系统测试用例，无法编写很具体细节的用例，但是我们可以思考编写简略测试用例的要点。
测试用例（Test Case）是为特定的目的而设计的一组测试输入、执行条件和预期结果的文档。它的作用其实就是为了测试是否满足某个特定需求。测试用例是指导测试工作进行的依据。
“二麻子，听说前几天你的文章《测试用例设计的两个基本方法》被人转发到微信群后，引起了一波激烈的讨论？”
上回，我们聊到了测试策略，也提到了测试策略的重要性。很多人说测试策略现在会包含在测试设计阶段，落地到测试用例中，也没什么问题，因为这都是解决问题的过程方法，不是核心目标。提到测试用例，这个作为测试入门级的问题，现在很多人对它也是看法颇多。
主要分享测试的学习资源，帮助快速了解测试行业，帮助想转行、进阶、小白成长为高级测试工程师。
最近王豆豆又恢复了以前的勤快了，这已经是一周内的第三篇，值得夸奖（自夸下），王豆豆一直很佛系的运营这个公众号，也许并不能说是运营，只是觉得有一个地方能写字挺好，刚好写的字能给一部分人带来帮助，每次收到小伙伴的反馈真的特别高兴，正因为这些感觉王豆豆会一直写下去，以后的文章类型可能不限于测试技术，也可能对某些产品的测评或是对某本书的思考，年纪越大越想拓展自己的思维。
从业测试行业多年，至今编写测试用例不下少数，总体对自己编写测试用例不是很满意，百度检索与同事切磋学习总结以下内容分享给大家：
不知从何时起测试过程中，写得最多的文档就是测试用例，有时连测试报告都免了，毕竟测试任务真的很紧，时间都拿熟悉执行测试了，哪里有时间写测试文档啊，再说我们也不爱写这些文档啊，哈哈。。。
众所周知，测试用例就是用来评估软件系统是否满足了一系列的商业需求而存在的。那么，如果使用了不好的或者是冗余的测试用例无疑就浪费的宝贵的工期，也浪费了公司的成本。所以，好的测试用例应该既能完美的评估商业需求并能达到最小成本消耗。
测试用例是一个传统而又基础的话题，对于新手来说如何写一个全面的测试用例是走出小白的第一步，随着技术和时代的进步，传统的冗余测试用例已经逐渐跟不上时代，不写测试用例没事做，写了测试用例也跟不上需求的变化还浪费时间，那么怎么办呢？
测试点是测试者在测试时需要关注的地方。虽然我们在分析测试点时，会使用各种测试方法，但这些方法在思路和操作上都是不同的，一些方法得到的测试点要细一些、具体一些，一些方法得到的测试点粗一些、泛一些是非常正常的。另外，谁也不能保证这些测试点之间不会重复或是相互包含。如果我们的测试就是按照这样一份粗细不一、深浅不明、关系不清的说明书来进行的，又怎么不会陷入既冗余又不足的困境中呢？
（1）有限的时间内测试，保证用户经常使用（使用频率比较高，主要的，核心的功能）功能的质量。 （2）如果有限的时间所有的功能不能完全测完，可以和产品经理开发商量，把没有通过测试的，有风险的功能把用户的入口，屏蔽掉（让用户无法使用），产生错误风险就会降低。 （3）本次测试，测试报告写清楚，这次上线，哪些功能测试了，哪些功能没有测试，上线风险分析清楚。
作为一名开发人员，你可能会发现周围的开发并不太喜欢写测试用例，甚至有些同学根本不写测试用例，认为写测试用例完全是浪费时间，或者是测试用例只是测试的事情。
背景 这篇是自用文章，不过为了方便更多读者，适当介绍一下背景。 笔者最近换了新工作，可能是跟下属不熟悉的关系，昨天在会议上要求他们在用例中说清楚测试点。这句话引起了下属的一些情绪。我觉得这个问题有必要拿出来说一说，而且讨论这个问题的时候很容易从A变成B，这需要管理者警惕。 昨天讨论的问题，归结起来有三点： 为什么测试用例标题中要把测试点描述清楚？ 为什么写测试用例？ 测试用例应该写成什么样的粒度？ 这几个问题，测试新手大都能说出个一二三来，不过据我了解，很多测试工作很多年的同行，在工作中仍会对此产生困惑。
httprunner 分层主要是分三层：api、testcase、testsuites 前面讲分层的时候讲到api单独封装每个接口，testcase可以有多个测试步骤，调用api层的接口是写测试用例，用例的步骤是有序的。 testsuites 这一层是测试用例的集合，把测试用例放到一个测试套件去执行，用例执行应该是无序的，有依赖的场景在testcase这一层测试用例里面就已经按步骤写好了。
今天的这篇文章继续接着昨天的文章《软件测试新人问题回复（一）》开始解答剩下的问题：
简单来说，无论函数如何实现，单测可以保证我们始终能得到预期的结果。 最近半年我们在提升我们项目的代码单测覆盖率，来提前发现代码中的问题。单元测试可以有效的提前发现问题，也可以很好的实现测试左移。
如果希望可以进一步提高某个阶段测试工作的效率，还可以考虑应用“设计测试过程”的方法。这里所说的测试过程，指的是我们在执行测试时所设定的执行测试用例的先后顺序。之所以这样做，是因为可以充分的利用不同功能之间的耦合性，尽量通过一次操作来检查尽量多的内容，从而降低已完成工作的无效性或低效性，最终提高某个阶段的整体工作效率。不过，这项工作同样要求操作者必须对被测的系统所涉及的所有业务以及这些业务之间的关系都非常熟悉才行。
不同阶段的测试用例的用例编号有不同的规则： （1）系统测试用例：产品编号-ST-系统测试项名-系统测试子项名-XXX （2）集成测试用例：产品编号-IT-系统测试项名-系统测试子项名-XXX （3）单元测试用例：产品编号-UT-系统测试项名-系统测试子项名-XXX **其中产品编号也叫项目标识，每个公司都有若干不同的项目或者产品，如何来区分它们呢？这就需要有产品编号了，每个公司都有自己的一套定义产品编号的规则，并且每个现有产品的编号已经制定好了，直接拿过来用就可以了。 **产品编号后的ST、IT、UT分别对应系统测试阶段、集成测试阶段、单元测试阶段。实际工作中有些公司会将产品编号以及测试阶段省略。 **测试阶段后面就是测试项目名了，对应的是较大较系统的测试点。 **测试项目名后面就是测试子项目名，有些测试是没有子项目名的，只有当测试项力度比较大的时候才会有成都市子项 （比如说：我们要测试用户能否成功登录这个功能，那我们就可以分为很多个子项，qq登录、邮箱登录等等）。 **测试子项名后面就是具体的用例编号了，可以是数字：01、001、002等等。
最近几天，连续有几个同学在微信中问我类似的问题「我拿到一个 XXX 需求，应该如何开始写测试用例呢？」
断言成功代表用例成功，断言失败代表用例失败。存结果，是因为如果这个用例失败了，还想看下接口当中到底给你返回的数据是什么，失败在哪里。
上一篇文章和大家介绍了测试的基础知识，用例设计方法我们讲到了5种。那么在设计用例时该如何应用用例设计方法、设计出覆盖率高的测试用例呢？今天，船长以登录测试为例，给大家深度剖析一下测试用例设计方法。也欢迎大家留言交流。
对测试用例的简单描述。用概括的语言描述该测试用例的测试点。每个测试用例的标题不能够重复，因为每个测试用例的测试点事不一样的。
诸如此类的疑问很多，今天我们先来聊聊“如何编写用例”的问题。编写用例是我们测试人员日常工作中最主要也是最频繁的工作，我们可以从书上或者网上查到很多这方面的资料，很遗憾的是，很难用一篇文章能把这个问题讲得全面而清晰。这也跟企业中面临的情况复杂多变有关，本文希望抛砖引玉，欢迎大家在文章下方留言。
“好的”测试用例一定是一个完备的集合，它能够覆盖所有等价类以及各种边界值，而跟能否发现缺陷无关
其实很多人测试人er都知道测试用例的重要性，它不仅会锻炼我们的测试思维，还可以对项目有个整体的把握，假如有新人来了，通过看测试用例也能熟悉不少，也省去一些我们教的时间。
测试用例是对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。
本节主要内容 - 测试用例的基本要素 - 测试用例的设计方法 - 测试用例的有效性 - 测试用例的粒度和评价
Selenium是一个基于浏览器的自动化工具，她提供了一种跨平台、跨浏览器的端到端的web自动化解决方案。Selenium主要包括三部分：Selenium IDE、Selenium WebDriver 和Selenium Grid：
所有测试用例编写的前提，是测试人员足够熟悉业务需求，过分追求设计方法，而忽略了业务本身的诉求，有点本末倒置。测试人员要如何快速熟悉需求呢？主要有以下几个方向。
平台注册地址http://47.108.155.10/register.html 没有账号，先注册自己的账号，注册后自动登录
pytest是个测试框架。冒烟（保证主流程通的）+回归（正常用例/异常用例，尽可能覆盖全面一些）。
一、通用测试用例八要素 1、用例编号； 2、测试项目； 3、测试标题； 4、重要级别； 5、预置条件； 6、测试输入； 7、操作步骤； 8、预期输出
有一些小伙伴一直想改变pytest用例的执行顺序，实际上我们在用例设计原则上用例就不要有依赖顺序。 pytest默认执行用例是先根据项目下的文件夹名称按ascii码去收集的，module里面的用例是从上往下执行的. pytest_collection_modifyitems 这个钩子函数顾名思义就是改变用例的执行顺序。
单元测试 & mocha 简述 1. 单元测试 单元测试（unit testing），是指对软件中的最小可测试单元进行检查和验证 这个最小测试单元，可以是一个函数，可以是一个类，可以是一个对象，也可以
首先我们从最开始接触的文档开始，那就是测需求文档;需求审查主要是我们对需求文档的理解，并熟透整个系统的每个功能和流程，对后期所有的测试建立思路，后续的工作基本依照需求进行操作，所以需求审查是一个很重要的一步。
Selenium是一个基于浏览器的自动化测试工具，它提供了一种跨平台、跨浏览器的端到端的web自动化解决方案。Selenium主要包括三部分：Selenium IDE、Selenium WebDriver 和Selenium Grid。
httprunner 2.x版本最大的改进就是分层机制了，1.x的版本是线性设计的，每个用例都是独立的。 一个用例里面涉及到流程性的，我们测试修改个人信息是否修改成功，在yaml文件里面需写3个步骤：登录-修改个人信息-查询个人信息。 这样3个测试步骤，每个测试步骤写的test下。但是下个测试用例，重新写个yaml文件也需要遇到登录的话，这样登录的步骤就会重复去写，所以维护起来不方便。 httprunner 2.x版本开始引入分层机制，可以定义公共的方法，在用例里面直接引入步骤，这样登录方法我们只需写一次
Tech 导读 本文将对测试驱动开发（TDD）进行探讨，主要阐述了TDD基本概念理解、TDD常见误区、TDD技术选型等，并提供了贫血模型三层架构和DDD下的TDD实战案例。
我认为，一个“好的”自动化测试项目，需要从“时间”、“人力”、“收益”这三个方面出发，做好“取舍”。
如何进行用例设计，如何让设计好的用例覆盖全面，将代码存在的问题在上线前更早发现是每一个测试工程师必备的技能。那么如何达到这些指标呢？如何将用例设计既快又全面呢？今天小编就告诉大家常用设计用例的方法，以及每个方法的适用范围，便于大家更快的选择出最优的方法。
测试用例（Test Case）是为了实施测试而向被测试的系统提供的一组集合，这组集合包含：测试环境、操作步骤、测试数据、预期结果等要素 。
前边的随笔主要介绍的requests模块的有关知识个内容，接下来看一下python的单元测试框架unittest。熟悉 或者了解java 的小伙伴应该都清楚常见的单元测试框架 Junit 和 TestNG，这个招聘的需求上也是经常见到的。python 里面也有单元
这个最小测试单元，可以是一个函数，可以是一个类，可以是一个对象，也可以是一个组件，一个插件
前言：在功能测试中测试人员使用的测试用例设计方法大多都是黑盒用例设计方法，黑盒用例设计方法有其中又以等价类划分法、边界值分析法为使用最多的方法，同时等价类和边界值也是最简单的，但这二个方法根据自身的属性，如果测试人员稍有不留意就会造成数据的遗漏，今天就主要分析一下测试人员是如何使用这二种方法的。 1 如何编写测试用例 测试人员应该怎样编写一份高质量的测试用例？ 1.测试用例设计方法 等价类划分法 边界值分析法 因果图 决策表 正交试验 场景法 状态迁移 错误推测法 2.测试用例的组成元素 用例编号 用例标
如何对用例进行编写、设计一直都是测试人员的必修课，每个人都有自己编写用例的习惯和方法，下面我会给你推荐一套优秀的测试用例设计方法，用于面试及实际工作中均可让你脱颖而出。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
即时通信 IM
实时音视频
