本文总用时3小时、将阐述自己对测试知识的理解，编写思路是本人自己所思所想所产出的。
另外送福利：
1、有朋友需要测试岗简历模板的(涵盖测试项目)，可以关注后私信我，送简历模板。
2、本人自己总结的测试岗位面试题50道，每道题结构清晰，思路明确。
加油~程序人生，年入20w不是梦。
目录
一、前言
二、测试理论
2.1测试的流程
2.2 评审概述
2.2.1评审的定义
2.2.2评审的目的
2.2.3评审的分类
2.3测试分类
2.3.1按照开发阶段划分
2.3.2按照测试技术划分
2.3.3按照软件特性划分
2.3.4其他划分
2.4 用例设计
2.4.1测试用例的定义
2.4.2测试用例需包含的内容
2.4.3测试用例在软件测试中的作用
2.4.4测试用例编写需注意
2.4.5举例设计测试用例
2.5 测试工具
2.5.1接口测试工具
2.5.2抓包工具
2.5.3性能测试工具
2.5.4自动化测试工具
2.6 BUG详解
2.6.1 提bug
2.6.2 bug管理工具
2.6.3 bug等级
2.6.4 bug优先级
2.7 回归测试
三、总结
一、前言
学习任何一项技能，只有深刻理解了其目的和意义，才能更加轻松的去学习，去举一反三，去自我引导、去自我思考、去自我解决。
软件测试的目的和意义：站在用户的角度上发现程序的错误，衡量软件的质量。并根据软件设计要求做出评估的过程。
从那几个方面入手评估：功能性、易用性、安全性、兼容性、稳定性等这几个方面
怎么去评估：这就需要我们积累测试知识，方便我们在不同的场景合理选择有效的测试方法来解决问题，详细内容请看测试理论。
二、测试理论 2.1测试的流程需求评审：开发人员、项目经理、产品经理开会后得出的软件测试需求结果
需求确定：测试人员对需求评审结果的确定
设计文档：确定好了之后输出设计文档，描述数怎么设计需求的
写测试用例：根据设计文档，转化成一条条测试用例,其中包括(前提、步骤、预期结果等)
执行测试用例：根据写的测试用例，按照测试步骤，检测是否达到预期结果
提交bug：没有达到预期结果的提交bug
开发修改：这一步不在测试人员能力范围内
回归测试：按照上述步骤再来几遍
提交测试报告：完全好了之后对本需求做一个验收
版本上线：等待软件上线
当我们知道了软件的测试流程之后，我们再逐个剖析每一个步骤里面的知识点，比如遇到什么用例用什么测试方法、怎么设计测试用例、bug定位、bug等级、回归方法等，一步步往下挖。
2.2 评审概述 2.2.1评审的定义2.2.2评审的目的在正式的会议上将软件项目的成果（包括各阶段的文档、产生的代码等）提交给用户、客户或有关部门人员对软件产品进行评价和批准。
2.2.3评审的分类设计出有效的测试用例，对软件的各个方面进行高效测试。
2.3测试分类 2.3.1按照开发阶段划分需求评审：《软件需求》《测试需求》
设计评审：《概要设计》《详细设计》
代码评审：《代码规范》
测试评审：《测试计划》《测试用例规范》《缺陷报告规范》
2.3.2按照测试技术划分单元测试：也叫接口测试，一般情况下单元测试开发人员在写完接口后会按照其写接口的逻辑测试一遍。但作为测试人员我们还要理解其目的在于检查每个程序单元能否正确实现详细设计说明中的模块功能、性能、接口和设计约束等要求，发现各模块内部可能存在的各种错误。
集成测试：也叫作组装测试。通常在单元测试的基础上，将所有的程序模块进行有序的、递增的测试。
确认测试：在模拟的环境下，验证软件的所有功能和性能及其他特性是否与用户的预期要求一致。
系统测试：系统测试是在真实的系统运行的环境下，检查完整的程序系统能否和系统（包括硬件、外设、网络和系统软件、支持平台等）正确配置、连接，并最终满足用户的所有需求
验收测试：是软件产品检验的最后一个环节。按照项目任务书或合同、供需双方约定的验收依据文档进行的对整个系统的测试与评审，决定是否接收或拒收系统
2.3.3按照软件特性划分黑盒测试：简单理解就是对其功能进行测试，不考虑内部逻辑结构，只看最后的功能结果。
白盒测试：相反白盒测试就是要考虑其内部的逻辑结构，对每一步的 *** 作进行测试并发现问题，例如增删改查的 *** 作测试，函数调用的测试等。
灰盒测试：介于白盒测试与黑盒测试之间的测试。灰盒测试关注输出对于输入的正确性；同时也关注内部表现，但这种关注不像白盒测试那样详细、完整。
2.3.4其他划分功能测试：很好理解，就是测试其软件的功能是否实现。
性能测试：交互速率、通信速率等是否到达一个标准
安全性测试：测试软件是否存在安全隐患，携带木马病毒等。比如黑客经常利用修改cookie信息来模拟用户登录系统，从而窃取信息等。
稳定性测试：这个也很好理解，就看这个软件如果一直用会不会存在比如闪退啊，打不开啊等情况。
兼容性测试：判断软件是否适用于指定系统，例如苹果、安卓、红帽啊等等。(少兼容少赚钱，因为现在系统很多，懂的都懂)
回归测试：是指对软件的新版本测试时，重复执行之前某一个重要版本的所有测试用例
冒烟测试：是指在对一个新版本进行系统大规模的测试之前，先验证一下软件的基本功能是否实现，是否具备可测性。也叫可测性测试。
随机测试：是指测试人员基于经验和直觉的测试，发现一些边缘性的错误。
猴子测试：乱点看会不会出现bug
不管按照什么测试方法去划分，其目的都是为了检测出bug，提高产品质量，只不过对于不同场景、不同时间段的测试我们选择的测试方法也不同，这就需要我们熟悉各种测试方法的理论，从而选择合适的方法，兵来将挡、水来土掩。
2.4 用例设计 2.4.1测试用例的定义2.4.2测试用例需包含的内容概念：设计一个情况，软件程序在这种情况下，必须能够正常运行并且达到程序所设计的预期结果
有效性：测试用例是测试人员测试过程中的重要参考依据。
可复用性：良好的测试用例具有重复使用的功能，使得测试过程事半功倍，提高测试效率
易组织性：即使是小的项目，也可能会有几千甚至更多的测试用例，测试用例可能在数月甚至几年的测试过 程中被创建和使用。
可评估性：从测试的项目管理角度来说，测试用例的通过率是检验代码质量的保证。
可管理性：测试用例也可以作为检验测试人员进度、工作量以及跟踪/管理测试人员的工作效率的标准。
2.4.3测试用例在软件测试中的作用标识符：由测试设计过程说明和测试程序说明引用的惟一标识符
测试项：描述被测试的详细特性、代码模块等，应该比测试设计说明中所列的特性更加具体。还要指出引用 的产品说明书或者测试用例所依据的其他设计文档。
输入说明：该说明列举执行测试用例的所有输入内容或者条件。
输出说明：描述进行测试用例预期的结果。
环境要求：是指执行测试用例必要的硬件、软件、测试工具、人员等。
特殊要求：描述执行测试必须的特殊要求。
用例之间的依赖性：如果一个测试用例依赖于其他用例，或者受其他用例的影响，就应该在此注明。
2.4.4测试用例编写需注意1、指导测试的实施
2、规划测试数据的准备
3、编写测试脚本的"设计规格说明书"
4、评估测试结果的度量基准
5、分析缺陷的标准
2.4.5举例设计测试用例1、不要设计“穷举测试用例”
2、在详细测试用例与有效测试时间中找到平衡点
3、好的测试用例应该多关注“反向测试问题”
4、测试用例库应该不断更新和维护
5、测试用例可以复用，但要注意数据有效性与环境变化
6、测试用例是设计出来的，不是写出来的
7、多去学习经验丰富的测试工程师所设计的测试用例
8、针对不同的需求类型和测试对象，灵活采用不同的测试用例设计方法
问题1：做加法器功能测试时，测试了1+1，1+2，1+3和1+4之后，还有必要测试l+5和1+6吗，能否放心地认为它们是正确的?
等价划分法：具有相同属性或方法的事务的集合 这个集合中某个个体所表现的特征与其他个性完全相同 对于某个测试对象的测试输入而言，某个个体能够被接受或被拒绝，则该个体所在集合中的任意个体都应该被接受或被拒绝
问题：货品价格 = 101 无效货品价格、货品价格 = 0 无效货品价格、货品价格 = -1 无效货品价格货品价格 = 100, 付款金额 = 101 无效付款、货品价格 = 100, 付款金额 = 99 无效付款、货品价格 = 100, 付款金额 = 100 不找零，请设计测试用例？
边界值分析法：如果输入条件规定了值的范围，则应取刚达到这个范围的边界的值，以及刚刚超越这个范围边界的值作为测试输入数据如果输入条件规定了值的个数，则用最大个数、最小个数、比最小个数少1、比最大个数多1的数作为测试数据
问题：在NextDate函数中，隐含规定了变量mouth和变量day的取值范围为1≤mouth≤12和1≤day≤31，并设定变量year的取值范围为1912≤year≤2050。
因果图法：因果图法是一种适合于描述对于多种输入条件组合的测试方法根据输入条件的组合、约束关系和输出条件的因果关系，分析输入条件的各种组合情况，从而设计测试用例的方法它适合于检查程序输入条件涉及的各种组合情况。
问题：校园一卡通自动充值，无需人工 *** 作，找到所有输入条件编号，找到所有输出条件编号，找出所有输入，输出的制约关系
判定表驱动法：判定表是分析和表达多逻辑条件下执行不同 *** 作的情况的工具。判定表也称决策表，是分析和表达逻辑条件下执行不同 *** 作的情况下的工具。它能够将复杂的问题按照各种可能的情况全部列举出来，简明并避免遗漏，设计出完成的测试用例集合。
插播一曲：聪明的朋友可能已经发现了，我编写的思路就是按照测试流程一步步解析的
2.5 测试工具 2.5.1接口测试工具2.5.2抓包工具1、Postman 用过一遍就会，懂的都懂(之前写的博客那个毕业项目也就是实现了postman的功能)
2、Jmter 一开始是用来做性能测试的，但发展了不久之后发现接口测试做的越来越成熟
3、Charles 可以理解为是一个HTTP代理服务器、反向代理服务器，如果对nginx有了解的也许用过这个东西。它允许一个开发者查看所有连接互联网的HTTP通信。
2.5.3性能测试工具1、Fiddler 是一款浏览器抓包工具，就是我们平时浏览网页时用的检查，里面包含了各种请求响应，http之间交互、会话层、网络层等各种信息。
2、Wireshark 是一个网络封包分析软件。Wireshark使用WinPCAP作为接口，直接与网卡进行数据报文交换。
2.5.4自动化测试工具1、LoadRunner 常用的就是LoadRunner，他是一种预测系统行为和性能的负载测试工具。适用于web端的性能测试，其特点就是能够生成大量的数据，从而考研软件的高并发性。并有很好监测、日志等功能。
2.6 BUG详解 2.6.1 提bug说到这个我就比较熟悉了
1、pytest python的集成测试框架，有兴趣的可以看我以前写的pytest入门(虽然写的不怎么好，但够用了)
2、gtest c++的集成测试框架，和pytest雷同，只是语法上和效果上有差别，未来也即将学习
3、RobotFramwork 其也是python的一个第三方测试工具，集成了python中很多的方法，可以对网页，移动APP进行自动化 *** 作。
4、selenium ui自动化测试框架，有兴趣的可以看我前面的博客，快速安装实现selenium自动化。
5、还有很多比如Appium、Robotium等就不介绍了。
这些自动化测试工具的目的都在于用脚本控制平台，从而实现测试用例的执行，达到预期测试效果，对python感兴趣的也可以找我交流学习哦。
2.6.2 bug管理工具1、首先要熟悉bug管理工具
2、其次准确的给bug定级
3、最后准确的记录bug信息
2.6.3 bug等级禅道：禅道是一款国产的优秀开源项目管理软件。拥有先进的管理思想，合理的软件架构，简洁实效的 *** 作，优雅的代码实现，灵活的扩展机制，强大而易用的api调用机制，多语言支持，多风格支持，搜索功能，统计功能。禅道项目管理软件的主要管理思想基于国际流行的敏捷项目管理方式——Scrum。禅道在遵循其管理方式基础上，又融入了国内研发现状的很多需求，比如bug管理，测试用例管理，发布管理，文档管理等。
JIRA：JIRA是Atlassian公司出品的项目与事务跟踪工具，被广泛应用于缺陷跟踪、客户服务、需求收集、流程审批、任务跟踪、项目跟踪和敏捷管理等工作领域。上万个团队选择JIRA对日常事务进行跟踪，并使团队始终获得最新信息。
2.6.4 bug优先级一级bug：（致命错误）
- 常规 *** 作引起的系统崩溃、死机、死循环报错，无法正常退出
- 功能设计与需求严重不符，基本模块缺失，测试流程无法进行
- 严重的数据计算错误
- 用户数据丢失或破坏
- 内存泄漏，系统无法登录
- 其他导致功能无法测试的问题
二级bug：（严重错误）
- 重要功能不能实现（例如：用户所要求的功能缺失，该有的页面未实现，逻辑不通，重要图表数据未开发，等）
- 错误的波及面广，影响到其他重要功能正常实现
- 非常规 *** 作导致的程序崩溃、死机、死循环 (非常规 *** 作：用户使用软件时不会进行的 *** 作）
- 系统中数据保存后数据库中显示错误
- 密码明文显示
- 页面无显示白屏，无数据
- 地图数据和图表数据不一致
三级bug：（一般错误）
不影响产品的运行、不会成为故障的起因、但对产品外观和下道工序影响较大的缺陷
- 次要功能不能正常实现
- *** 作界面错误（包括数据窗口内列名的定义，含义不一致）
例如：列名与列名下的内容不一致
- 查询错误、数据错误显示
- 简单的输入限制未放在前端进行控制；（格式显示，如登录和注册中的格式判断可由前端判断）
- 删除 *** 作未给出提示
- 边界条件错误或者未做限制
- 系统未做优化，数据页面加载慢， *** 作卡顿之类（性能层面问题）
- 兼容性问题（分辨率，系统版本等等）
四级bug：（界面问题）
程序在一些显示上不美观，不符合用户习惯，或者是一些文字的错误
- 界面不规范
- 辅助说明描述不清楚
- 提示窗口文字未采用行业术语
- 界面存在文字错误
- *** 作时未给用户提示
- 文字排列不整齐等一些小问题
五级bug：（建议性问题）
- 对于产品设计方面的意见和建议
- 对于产品界面优化方面的意见和建议
- 对于产品需要优化增强用户体验方面的意见和建议
2.7 回归测试P1： 即“马上解决”，优先级最高，应立即修复的问题，要求开发人员必须立即修改这条bug，一般是指该缺陷导致程序完全不能满足产品的需求，基本功能明显未实现或不可用，阻塞了测试流程与进度等。
P2：即“急需解决”，表示问题的修复很紧要，很急迫，关系到系统的主要功能模块能否正常使用，包括功能、数据，或者其他的一些比较着急的需求。
P3：即“高度重视”，表示有时间就要马上解决，主要是指系统实现的功能与预期结果要求较大，但不影响其他功能和主要的核心功能。
P4：即“正常处理”，按照个人计划处理就行，主要是指界面，交互和一些特别小的功能出错，但是可以跳过此类bug继续进行测试。
P5：即“低优先级”，一些可修改或不可修改，或者是还不确定能否修改成功的bug，不影响用户体验使用，不过修改了最好，一般如果要修改且时间来不及可以在后面的版本更新中再进行修改即可。
本块内容覆盖知识面比较多，下一期单独提出来讲解。
三、总结学习任何一项技能，只有深刻理解了其目的和意义，才能更加轻松的去学习，去举一反三，去自我引导、去自我思考、去自我解决。以上文章如有阐述有误的地方，还请指正，欢迎大家和我一起交流学习，创作实属不易，喜欢的点赞收藏关注咯。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）