测试用例设计

一、简介 　　在开始接口测试之前，我们想一下，接口测试的流程是什么？说到这里，有些人就会产生好奇和疑问，心里mmp：接口测试要什么流程哈？？？不就是参考接口文档，直接利用接口测试工具（例如jmeter和postman）测试。。。其实，如果一个project中，只是几个接口，你完全可以做临时的接口测试，但project可不止几个接口，少则几十条接口，多则成百上千接口。另外，如果你公司的这个项目，第一次做接口测试。而且古人说过：“无规矩不成方圆。”所以哈，我们还是有必要严格遵守接口测试的流程。 二、接口测试的流程 　　接口测试属于功能测试，接口测试的流程类似于以往的功能测试。接口测试的流程如下： 测试尽早找开发拿接口文档（需求文档）； 根据接口文档编写测试用例（用例编写可按照以往规则写，比如等价类划分，边界值，场景法等设计方法）； 执行测试，查看不同的参数请求，接口返回的数据是否达到预期 三、为什么要写用例 理清思路，避免漏测和重复测； 提高测试效率； 跟进测试进度； 更好的发现问题，记录问题，复现问题； 跟进重复性工作； 告诉领导：我做过； 接口测试流程中的一个产物（测试用例） 　　上面7点，有用例，自己心中有数，不用一个测试点重复测好多次，也避免漏测。 四、接口用例设计 　　 　　主要从四个方面来设计接口用例： 功能，业务逻辑，异常，安全 　　 功能： 　　1）功能是否正常； 　

1.软件测试基础 软件测试工程师：查找错误和缺陷，然后要求开发人员进行修改，保证软件质量。 漏洞（360安全漏洞）：硬件，软件，协议的具体实现或系统安全策略存在缺陷，从而可以使攻击者在未授权的情况下破坏系统。 千年虫问题：年份存2年，超过百年会出现bug。1900→2000 开发和测试的比例：4:1→10:1 手工测试、功能自动化测试、性能自动化测试、白盒测试 1-3-5年规划：手工测试工程师，功能自动化测试工程师，性能测试工程师 需要的技术：计算机操作系统，软件开发技术、软件测试技术、自动化工具 1.1 Windows操作系统及网络基础 　　熟悉windows操作系统和计算机基础知识，能够搭建软件测试环境，熟悉网络协议。 什么是软件：软件=程序+文档 什么是软件缺陷： 软件未出现说明书要求的功能 软件出现了说明书指明不应该出现的错误　 软件出现了说明书未提到的功能 软件未实现说明书虽未明确提及但应该实现的功能 软件难以理解，不易使用，运行缓慢或者从测试员角度看，最终用户会认为不好。　 什么是软件测试：在现有软件中寻找缺陷的过程 软件测试的历史：defect（缺陷），bug(臭虫)，debug（调试） 计算机层次：计算机硬件，操作系统，应用软件　 裸机包含软件：BIOS(Basic input/output system 基本输入输出系统) 常见操作系统：Windows

一 手工测试用例与自动化测试用例的对比 二自动化测试用例的实现 =========================================================================== 手工/自动化测试用例对比： 自动化测试用例注重点： 1.不是所有的手工用例都要转换成自动化测试用例 2.考虑到脚本开发成本，需要和人工测试用例成本做对比 3.最好是通过场景来设计测试用例，可抽出page模块，执行case，便于开发和维护 ========================================================================== 自动化测试用例的实现： PO设计模式回顾： 1.与web自动化的PO设计模式无太大差别 2.PO设计模式的优点：减少代码重复性、提高测试用例的可读性、提高测试用例的可维护性 回顾unittest框架： 1.unittest框架是python自带的单元测试框架 2.setUp方法用于测试用例执行前的初始化工作 3.tearDown方法用于释放驱动 4.在用例中使用断言方法判断用例是否执行成功 5.unittest.main方法，用于执行单元测试模块脚本 6.框架入口main.py文件中写入discover方法用于执行所有的测试用例脚本 导入unittest，测试类继承unittest

1.测试用例的流程设计 1.1 打开浏览器 1.2 提供url地址 1.3 查找元素 1.4 输入内容(可选) 1.5 查看结果 1.6 输出结果 2.测试用例的模块化 把各种测试模块都形成方法 3.测试用例的数据分离 把需要用到的参数统计一下,然后形成一个文档用于保存当前的数据,把数据字典话 4.使用excel管理用户数据 pip install xlrd # 读取 pip install xlwt # 写入 使用excel来保存数据字典 5.保存测试结果到excel中 除了Excel，也可以保存成HTML，PDF，看需求吧 6.测试用例模板参考 7.用例模板参考 总体信息 用例初始化 001用例 002用例 003用例 来源： https://www.cnblogs.com/sundawei7/p/11959199.html

一、unittest框架简介 　　unittest设计时主要用于单元测试，但其他功能强大，也可以用于其他的自动化测试（GUI、接口）。 二、unittest框架的四个核心 　　1. testcase：测试用例 　　2. testsuite：测试套件 　　3. testfixture：用于配置或者删除环境，提供setUp()启动和tearDown()释放的方法，定义了特殊的运行方式 　　4. testrunner：提供run()方法，运行测试集，可以生成测试报告 三、unittest框架常用的类 　　1.TestCase　　2.main　　3.TestSuite　　4.skip　　5.TestResult　　6.TestLoader 四、unittest框架的实现过程 　　1. 通过继承的方式（unittest.TestCase）获取父类方法，构建测试用例 　　2. 构建测试用例遵循标准：必须以test开头 　　3. 通过testfixture初始化运行时所需要的变量。setUp获取，tearDown回收 　　4. 定义测试类。unittest.main()，另外一种通过testsuite的方式指定运行某一些测试用例。unittest.TsetSuite()得到测试集对象。通过addTest()或者是addTests() 　 5. 运行测试集 来源： https://www

1、进行需求收集及分析 搜索关键字：导流平台 同类产品体验及熟悉 搞清楚，业务流、数据流、用户焦点 2、初步熟悉原型 初步熟悉、遍历原型， 初步进行测试需求分析 3、聆听及和权威的人进行沟通 测试人员的通病就是弱技术，导致不敢或者没有底气和技术人员、架构师、设计师等进行沟通 而往往这种对话是很重要的，由于是遇到盲点时，前提是自己真的得提前做好了功课 4、识别项目中需要提前设计的技术点 测试到一定阶段可自动化的业务流，提前进行知识的准备及储备 需要进行性能测试的点 5、测试用例设计 这是最重要的一项，必须是在前面扎实的工作之前，才会觉得写测试用例如行云流水，在这个阶段一定要注意用例的可执行性， 一定要避免To write is one thing,to test is another thing 的情况 除了项目内的用例，由于是门户类平台，一定要注意共同及潜在测试用例的挖掘。 6、说专业的话 通过对项目从开始到测试用例完成的过程，一定要至少让自己成为半个专家吧 7、邮件汇报进度 邮件汇报工作，分主次、分轻重缓急、反应进度、反应风险 8、流程管理贯穿始终 依托于禅道，对事项进行管理和跟进 设计测试的框架及模板文档 来源： https://www.cnblogs.com/jpr-ok/p/11958382.html

近两周我的面试非常多，大概一天一个。我是二面面试官，一面是技术面，有一定的难度。按道理来说二面的通过率应该比较高才对，不过最近的二面通过率可能不到50%，一面的通过率一般比较稳定保持在30%以下，所以两面全过的概率大概只有15%左右，可能更低。 那么二面的通过率为什么那么低呢？我想举几个例子就可以说明了。 二面我一般都会问一道用例设计题，大概是给你一袋盐，或者给你一件衣服，写出一些测试用例。 我的心理预期是15个可执行的用例。 有的候选人是这么回答的。 假如是一袋盐，那么要看看装盐的袋子是不是会漏？ 这时候我一般会反问，那应该是要漏还是不要漏？很多候选人这时候会愣住，可能完全意识不到我为什么会这么问。 我这么问是因为我有个怪癖，那就是我希望测试用例都是可以执行的。可以执行的意思是，你要告诉我你究竟是希望袋子漏还是不漏。如果你希望袋子是不漏的，那么袋子漏的时候测试用例就是不通过的，反之也成立。如果你告诉我看看袋子漏不漏，那么因为我是很笨的，我不知道如何去执行这个用例，因为我不知道袋子究竟是需要漏呢还是不能漏。 与之类似的，在测试衣服的时候，有的候选人会回答要看衣服的尺码是不是合适。那么我会反问，对于L号，衣服多长是合适，多长又是不合适呢？这是因为合适不合适是没有执行标准的，对于一个身高不高的人——比如1米49家穷人丑的我——来说，L号是不合适的，太长了。而对于身材匀称的其他人来说

Android 提供了一系列强大的测试工具，它针对 Android 的环境，扩展了业内标准的 JUnit 测试框架。尽管你可以使用 JUnit 测试 Android 工程，但 Android 工具允许你为应用程序的各个方面进行更为复杂的测试，包括单元层面及框架层面。 Android 测试环境的主要特征有： 可以访问 Android 系统对象。 Instrumentation 框架可以控制和测试应用程序。 Android 系统常用对象的模拟版本。 运行单个 test 或 test suite 的工具，带或不带 Instrumentation 。 支持以 Eclipse 的 ADT 插件和命令行方式管理 Test 和 Test 工程。 这篇文章是对 Android 测试环境和测试方法的简要介绍，并假设你已经拥有一定的 Android 应用程序编程及 JUnit 测试的经验。 概要 Android 测试环境的核心是一个 Instrumentation 框架，在这个框架下，你的测试应用程序可以精确控制应用程序。使用 Instrumentation ，你可以在主程序启动之前，创建模拟的系统对象，如 Context ；控制应用程序的多个生命周期；发送 UI 事件给应用程序；在执行期间检查程序状态。 Instrumentation 框架 通过将主程序和测试程序运行在同一个进程来实现这些功能。

什么是测试覆盖率 首先，该如何评审自己写的测试用例是否满足测试要求？是否存在漏洞与缺陷？ 这就要引入一个测试覆盖率的概念了。 测试覆盖率 覆盖率是用来度量测试完整性的手段，是测试效果衡量的标准，是测试技术有效性的度量： 覆盖率 = （至少被执行一次的项目(item)数） / （项目的总数） 项目是指：语句、判定、分支、函数等等。 覆盖率按照测试方法一般可分为三大类： 白盒覆盖率：语句、判定、条件、路径等等； 灰盒覆盖率：接口相关； 黑盒覆盖率：功能、性能测试； 另外还包括面向对象覆盖率等。 注意，测试用例设计不能一味的追求覆盖率，因为测试成本随覆盖率的增加而增加，要在覆盖率和成本之间有所取舍。 白盒覆盖率 白盒覆盖率中使用的最常见的就是逻辑覆盖率（Logical Coverage），也称为代码覆盖率（Code Coverage）、或者称为结构化覆盖率（Structural Coverage）。 逻辑覆盖率包括： 语句覆盖； 判定覆盖； 条件覆盖； 判定条件覆盖； 条件组合覆盖； 路径覆盖； 语句覆盖 语句覆盖（Statement Coverage）的含义是，在测试时运行被测程序后，程序中被执行到的可执行语句的比率： 语句覆盖率 = （至少被执行一次的语句数量） / （可执行的语句总数） 现在我们祭出在测试覆盖率篇中都会使用的一张图。 这个一个函数的流程图，需要传入三个参数

判定表法 概念： 分析和表达多种输入条件下系统执行不同动作的工具，它可以把复杂的逻辑关系和多种条件组合的情况表达得既具体又明确 判定表法设计用例的步骤 ： 列出所有的条件桩和动作桩 填入条件桩、条件项 填入动作桩、动作项 化简，合并相似规则 将每条规则转化为用例 优缺点分析： 优点：能把复杂的问题按各种可能的情况一一列举出来，简明而易于理解，也可避免遗漏 缺点： 系统庞大时，列条件桩是体力活； 合并存在漏测的风险。一个显然易见的原因是，虽然某个输入条件在输出接口上是无关的，但是在软件设计上，内部针对这个条件走了不同的程序分支 适用范围：多个输入判断条件存在逻辑关系，且不分先后的情况。 实例演习 1、如果【觉得疲倦】并且对书的内容【感兴趣】，同时书中的内容让你【糊涂】的话，回到本章重读 2、如果【觉得疲倦】并且对书的内容【感兴趣】，同时书中的内容【不让你糊涂】，继续读下去 3、【不觉得疲倦】并且对书的内容【感兴趣】，但是书中的内容让你【糊涂】的话，回到本章重读 4、如果【觉得疲倦】并且对书中的内容【不感兴趣】，同时书中的内容不让你糊涂，请停止阅读，休息 5、如果【觉得疲倦】并且对书的内容【不感兴趣】，并且书中的内容让你糊涂，请停止阅读，休息 6、【不疲倦】，对书的内容【感兴趣】，书中的内容不糊涂，继续读下去 7、【不疲倦】，【不感兴趣】，书中内容糊涂，跳到下一章去读 8、【不疲倦】，