测试用例

有朋友问我关于测试流程的问题，并说自己公司总是出现线上bug，应该怎样解决。现在我对这些做了一些总结，希望对大家有所帮助。 现在需求变更频繁，测试计划几乎没有 一：测试流程（根据公司实际情况） 需求评审--->测试编写用例，开发编写代码--->测试用例评审--->开发提测--->进行测试，提bug--->产品验收--->上线 1.需求评审的之前一定要过一遍需求（需求评审的邮件里面有需求文档）；在进行需求评审时，提出自己的疑问点。 2.评审完后，进行测试用例的编写，对于需求不明确的点，跟需求人员确认（这一步很重要：评审需求时一般大题上没有问题就可以了，但是编写测试用例时会更加关注细节） 3.跟开发，产品进行用例评审（这一步也很重要，同一个需求，每个人的理解都不一致，可能开发和测试理解的完全不是一个。避免到了测试这一步才发现开发做的完全不正确） 4.根据测试用例进行测试，并对用例进行补充（这一步是真正进行测试时，开发出来的可能比预期的要多，比如一些初始化配置） 5.对测试出来的问题进行管理（即提bug：缺陷管理工具有很多，一般每个公司大同小异） 6.产品人员验收（这一步也很重要，否则到了上线后发现开发出来的不是想要的，或者中间流程有错误用不了，就尴尬了） 二：一些现状 1.测试最后知道需求 认为测试不重要，开发提测后，才告诉测试有这个功能，然后开发说怎样测试，测试就怎样测试 ---

第一阶段学习总结报告 曾经心怀澎拜，曾经满怀激情，曾经翘首等待这为期四个月的实训终于拉开帷幕。2015年的这个暑假对于我来说是最幸运而同时有特别重要的一个暑假，因为我非常幸运的来到了济宁惠普软件人才实训基地进行为期四个月的实训学习。第一天来到惠普我变被浓厚的企业文化深深的吸引，作为一家跨国公司，她有强大的包容性和多元性。实训期间采取公司制的这一策略让我们真正融入到公司的文化中，时刻以惠普员工的高标准来严格要求自己，磨练自己。 我学习的专业是软件测试，虽然在大学也开过“软件工程”这门课，但对测试这门行业的了解基本为零。通过几天几位导师和班主任和蔼可亲的指导以及全心全意的关怀，我对测试行情以及职业要求和发展等都有了较深入的了解。几天的测试基础的学习也是我越来越喜欢测试了，也更加坚定了我的选择。 众所周知，做测试职业工具是必不可少的，在学习了一些理论知识后，我们的美女导师徐老师就带领我们学习了第一个开源测试工具——testLink。第一次接触这个工具的时候我是丈二的和尚摸不着头脑，简直一头雾水，什么都不知道，课上跟着老师的思路做了一遍，虽然能做出来但是完全不明白做每一步的原因是什么。课下老师给了我们一个安装压缩包，让我们自己搭建环境，我不管是在网上百度也好找同学给帮忙也好几次都安装失败。软件XAMPP里的Ahache和Mysql总是启动不了，最后通过问老师才知道电脑的80端口被占用

itest 入选 2019 年度最受欢迎开源中国软件 开源工具的发展,离不开你我的支持,需要您投上宝贵的一票 去投票 itest 简介 ： 查看简介 itest 开源敏捷测试管理，testOps 践行者。可按测试包分配测试用例执行，也可建测试迭代(含任务，测试包，BUG)来组织测试工作，也有测试环境管理，还有很常用的测试度量；对于发版频繁，需求常变，itest还可导出用例，线下修改、执行，新增后再导入（同步）到线上；且可根据测试策略来设置测试流程，并可实时调整；在测试看板中，能查看迭代报告，测试包执行情况，测试任务进展，也可以在看板上直接执行用包用例。 在线体验1 http://120.78.0.137:8080/demo 在线体验2 https://itest.work/demo/ v4.2.1下载地址 ： itest下载 在4.2.0 发布1周天后，因3个重要(用户强烈要求)更新 V4.2.1 紧接着发布， 根据用户反馈（用户的持续反馈是我们更新动力！），共增加了9个更新：其中有1个重要功能增强, 以及8个BUG 修复(其中两个重要BUG )。如，,有用户反馈，他在分用例到用例包时,要分配个把小时。支持从其他用例包已分配的用例中，拷贝分配关系到当前用例包中 来，当同样的用例，需要在不同的平台上执行时，就不用重复分配用例了，省时省力，另外4.2.0安装包，少打了一个文件

1、超继承 　　重写测试用例类的init方法，如下所示。 import requests import unittest class XiaoheiCases(unittest.TestCase): def __init__(self,methodName,url,data,cookies=None): super(XiaoheiCases,self).__init__(methodName) self.url = url self.data = data self.cookies = cookies 2、ddt模块 ''' ddt结合unittest来进行数据处理的第三方库，很强大 安装pip install ddt ddt需要和unittest或pytest结合使用 ''' from ddt import ddt,data,unpack import unittest test_print = [1,3] test_b = [[1,2,3],[4,5,6]] @ddt #装饰测试类 class TestMath(unittest.TestCase): @data(test_print) #装饰测试函数，通过这种方式传参，如果通过*test_data传参，则有几个参数，执行几次测试用例 def test_print(self,item): print('item:{0}'

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

测试计划 项目 测试人员 需求推演 时间 编写测试 用例时间 用例内评与 评审时间 测试时间 计划上线时间 提测时间 备注 素拓十期 陶海燕 10/27 10/21晚上 报告模板 对于在测试之前写了测试用例的项目，统一按照模板一来写测试报告；对于测试前没来得及写测试用例的项目，测试报告的格式请参考模板二。 模板一： 【 XXX 项目】测试报告（写了测试用例的项目参照该模板） 需求范围 ： JCQD-XXX 测试周期 ： 2016/9/8-2016/9/12 测试人员 ： 测试环境 ： 测试结果： 用例总数 已测 未测 PASS FAIL Blocked 测试详情： （有必要说明的事项都可写在该栏里） 1. 测试过程中发现几个 bug ，已修复并验证通过几个 bug 。 问题单号： JCQD-XXX ； JCQD-XXX ； ... 2.Blocked 的问题单号有 JCQD-XXX 等。并写清楚该部分问题如何解决。例如，经与产品经理确认，该功能放到下期需求。（也就是说，需求变更的部分归到 blocked 一类） 测试结论 ： XXX 测试总结与建议 ： XXX 测试用例 ：测试用例见附件（一定要把测试用例以附件的形式加到测试报告里） 模板二： 【 XXX 项目】测试报告（未写测试用例的项目参照该模板，具体填写方法可参照麒伊的邮件小白卡一期测试报告） 需求范围 ： JCQD-XXX

unittest的属性： 该文以思维导图的形式描述unittest的重要属性。 其中前四个是unittest最核心的三个属性。 testcase：测试用例； testsuite：测试套件，多个测试用例组成一个测试套件； test runner：执行测试用例，该类中的run()方法会执行testsuite/testcase中的run()方法。测试的结果会保存在testresult中。 还有一个很重要的就是fixture，看着是挺陌生的，其实就是一个测试用例执行之前环境的准备和执行之后环境的销毁。 三、实例： 首先准备一些待测方法，functions.py： def fun_div(x): return x/2 def fun_add(x): return x+2 def fun_minus(x): return x-2 def fun_multi(x): return x*2 接下来写一些测试用例来测这些方法，test.py import unittest from functions import fun_add,fun_minus,fun_multi,fun_div class TestFun(unittest.TestCase): times = 0 @classmethod def setUpClass(cls): print('setUpclass') def setUp

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