零基础的人如何快速学习软件测试？（成都软件测试技术该如何入门？）
零基础的人如何快速学习软件测试？
自学的话建议从读书开始。 基础软件测试的入门很简单。 《软件测试的艺术》等书会帮助你。 最好的方法是读书学习一部分后，试着找相关的工作。 记住要强调细心和耐心。
一边工作一边成长是最快的学习方法。
成都软件测试技术该如何入门？
试图从零开始软件测试，但说难也不是很容易。 成都千锋从以下几个方向和大家分享~
1 .工作
众所周知，学东西真正快速的方法是一边学习一边做。 以前做过功能测试，如果想做自动化测试的话，当然会在公司内部找。 如果公司里有那样的团体，能转过去就OK了。
但如果你为力，别人不想要你，接下来就用第二种方法。
2 .在线教育视频
现在互联网越来越发达了。 要找到什么，只有你想不到。 没有你找不到的东西。
我记得刚开始软件测试的时候，有问题在网上找。 那个时候软件测试的数据很少，短短几年，现在有很多测试教程。 如果你想学习什么技术，你可以在网上找到。 那样的话，会给我们提供很多机会。
但是，选择太多也不好。 容易引起浮躁的现象，学习的心不稳定，容易停留在基础阶段。
3 .培训
成都千锋教育独家开设了全栈软件测试工程师课程。 首期教育总监有测试阶段课程——总监王老师、软测试行业首屈一指的教育总监，10年从业经验。 课程上线后，有很多企业的定制需求，按照目前企业招聘需求，首批40多名软件测试工程师将参与企业的现场招聘。 配备全能软件测试工程师，贯穿900小时的课程，由浅入深。
与其他只强调保证学生顺利就业的机构不同，千锋成都软件测试培训是业内少见的一门在保障学生高薪就业的基础上，打好未来5-10年职业发展基础的课程。
转软件测试需要学习什么？
用这样的词找工作一般是测试开发，现在很多公司在招人，工资也不错。
测试时，被划分的部门应该在刀具效率组，平时不仅要做测试工作，还要进行简单的刀具开发、自动化的接口测试等，以提高测试效率。
所以说要学习，一定要掌握基础性的测试理论。 另外，最好是使用自动化相关的、数据库、一些工具，如果需要Java的话，也可以Java w
软件测试都是培训的吗？
软件测试不一定是培养出来的训诫的。
因为大学里也有专门的软件测试专业，而且专业对口的学生毕业后可以从事互联网行业中的测试工作。 另外，也有中途跳槽的人。 开发一般转移到测试岗位上。 我觉得考试的岗位更有前途，所以改变测试不需要训练。
软件测试需要掌握哪些知识？
一、软件生命周期( SDLC、Systems Development Life Cycle、SDLC ) )。
软件规划和可行性研究(问题定义、可行性研究)； 需求分析； 软件设计(概要设计、详细设计)； 编码； 软件测试； 运用和维护
生存周期的划分
各阶段的任务相互尽量独立，同一阶段的各任务性质尽量相同，从而降低各阶段任务的复杂度，简化不同阶段之间的联系，有利于软件开发过程的组织管理。
生存周期基线
功能基线( functional baseline )
功能基线是指在系统分析和软件定义阶段结束时，在经过正式审查和批准的系统设计规格书中对软件生命周期开发系统的规格说明； 或对项目委托单位和项目承包单位双方签字同意的协议书或合同规定的开发软件系统的规格说明，或下级申请经上级同意或直接上级下达的项目任务书规定的开发软件辅助 功能基线是第一个授权的功能配置标识符。
分配基线( allocated baseline )
分配基线是在软件要求分析阶段结束时经过正式审查和批准的软件要求的规格说明。 基线分配是第一个批准的分配配置id。
产品基线( product baseline ) )
产品基线是指在软件组装和系统测试阶段结束时，经过正式审查并批准的、所开发软件产品的所有配置项目的规格说明。 产品基线是第一个批准的产品配置id。
SDLC的六个阶段
定义和计划
这个阶段由软件开发者和需求者共同讨论，主要确定软件的开发目标及其可行性。
需求分析
在判断软件开发可行的情况下，详细分析软件要实现的各功能。 需求分析阶段是一个重要阶段，如果这个阶段进展顺利，可以为整个软件开发项目的成功奠定良好的基础。 不变的只有变化本身。 “”，同样，需求在软件开发的过程中也在不断变化和深入，因此为了保护整个项目的顺利进行，必须制定需求变更计划。
软件设计
本阶段主要根据需求分析的结果设计整个软件系统，包括系统框架设计、数据库设计等。 软件设计一般分为总体设计和详细设计。 优秀的软件设计软件程序的编制为良好的基础。
程序代码
此阶段是将软件设计的结果转换为计算机可执行的程序代码。 在程序编码中必须制定统一的、遵循标准的编写规范。 保证程序的可读性、维护性，提高程序的执行效率。
软件测试
软件设计完成后，必须经过严密的测试，发现并纠正整个软件设计过程中存在的问题。 整个测试过程分为单元测试、装配测试及系统测试三个阶段进行。 测试的方法主要有白盒测试和黑盒测试两种。 在测试过程中需要制定详细的测试计划，并严格按照测试计划进行操作，以减少测试的随意性。
执行维护
软件维护是软件生命周期中最长的时间。 软件开发完成并投入使用后，由于多方面的原因，软件不能继续满足用户的要求。 为了延长软件的寿命，软件需要维护。 软件生命周期维护既包括错误纠正性维护，也包括改进性维护。
周期模型
典型的几种生命周期模型包括瀑布模型、快速原型模型和迭代模型
二.软件生命周期(瀑布模型)中软件测试的对应关系
三.软件测试过程
步骤1 :分析要进行测试的产品/项目，确定测试策略，制定测试计划。 这个计划审查批准后进入第二步。 在开始测试工作之前一定要确定正确的测试策略和指导方针，这些是后期工作开展的基础。 只有把这次的测试目标和要求分析清楚，才能决定测试资源的投入。
步骤2 :设计测试用例。 测试用例的设计根据测试要求和测试策略进行。 进度压力较低时，应进行详细设计；进度、成本压力较大时，应保证测试用例涵盖重要测试要求。 用例获得批准后，请转至步骤3。
步骤3 :如果满足“入门指南”( EntryCriteria )，则运行测试。 测试的执行主要是建立测试环境，运行测试用例。 运行测试时，进行进度管理、项目协调等工作。
步骤4 :提出缺陷。 这里进行缺陷的审查和验证等工作。
步骤5 :消除软件缺陷。 通常，开发经理必须审查缺陷并进行缺陷分配。 程序员修正自己负责的缺陷。 程序员修改完成后，进入回归测试阶段。 如果满足“完成条件”( ExitCriteria )，测试将成功完成。
步骤6 :编写测试报告。 分析测试，总结这次的经验教训，在下一个工作中修改。
软件测试过程管理主要包括软件测试是一个什么样的过程，如何评估软件测试过程，如何进行配置管理和测试风险分析以及测试成本的管理。
四、软件测试过程(对应于第三条) ) ) ) ) ) )。
1、制定测试计划
2、编辑测试用例
3、运行测试用例
4、、发现并提交错误
5、开发组修复bug
6、返回已修复的错误
7、修复完毕的错误关闭状态，未正确修复的错误重新激活
五.测试用例
测试用例( Test Case )是为特定目标创建的一组测试输入、执行条件和预期结果，用于测试程序路径或验证是否满足特定需求。
测试用例的元素包括版本号、模块名、用例号、用例名、用例级别、预配置条件、验证过程、预期结果(包括判断标准)、测试结果、测试时间、测试器等。 (其中核心要素是预设条件、验证步骤、预期结果)
测试用例的设计方法:等价类划分、边界值分析、错误估计法、因果图法、场景设计法
一个好的测试用例必须满足以下要求。 测试用例必须完成对要求的完全覆盖(即使用案例和要求的双向可追溯性)。 测试用例必须是可执行的； 测试用例结果的唯一性测试用例必须简洁
六、缺陷报告(错误的提交) )。
有效的缺陷报告元素通常包括标题、前提条件、测试环境、操作步骤、实际结果、预期结果、发生频率、优先级、严重级别和附件(通常为图像格式)。
此外，还有测试人员、开发负责人等其他信息。
标题:简明扼要，毫不含糊
优先级4级软件修复的紧急程度
1–即时解决:缺陷会导致系统几乎无法运行，或严重妨碍测试的运行(需要立即修复) )。
2–高优先级:缺陷严重，影响了测试(必须当天或次日及时解决) )。
3–正常:常见错误
4–低优先级:页面文本框对齐等，可以在开发有时间的时候处理
严重级别severity(4级)缺陷故障对用户使用系统的影响
1–致命:主流程不通，系统丧失功能，用户数据被破坏，系统崩溃，死机
2–严重的:影响过程比较严重的，如系统的主要功能部分未实现
3—-一般:系统的次要功能没有完全实现，但不影响用户的正常使用
一般来说，缺陷越严重，优先级越高，但也有例外:
1 )从用户的角度来看，缺陷并不严重，但可能影响测试的运行(高优先级、低重要性) )。
2 )虽然有些缺陷比较严重，但由于技术的限制，暂时无法纠正。 优先顺序下降
附件
文字有时很难明确说明缺陷，但在这种情况下，使用图像(用刷子表示问题)会很直观
如何有效地报告缺陷？
单一准确性:每份报告只针对一个缺陷。 如果存在多个缺陷，则可能只修改一个开发，而不修改其他开发，从而延长缺陷的生命周期
可再现:不能忽略或省略如果某个操作步骤，特别是重要的操作，讲解不清楚，就会有rd ( researchanddevelopmentengineer )来沟通如何操作，浪费大家的时间
完全统一:完整的说明信息
简短扼要:使用关键词
特定条件:存在只在特定环境中存在的问题
七.测试报告
测试报告是指将测试过程和结果记录下来，分析发现的问题和缺陷，为纠正软件存在的质量问题提供依据，同时为软件的验收和交付奠定基础。
详细的测试报告包含足够的信息，包括产品质量和测试流程的评估。 测试报告基于测试期间的数据收集和最终测试结果的分析。
报告的主体框架如下。
1、首页
·报告名称(软件名称版本号客户端类型( android、iphone、后台管理等)测试范围(单元、集成、系统、模块等)测试报告) )
·报告委托人、报告负责人、报告日期等
·版本变更的历史
密级
2、引言
2.1创建目的
本测试报告的具体编写目的是说明预期的读者范围。
2.2项目背景
简要说明项目的目标和目的。 必要时包括简史，这部分不需要脑力劳动，直接从需求或招标文件中复制即可。
2.3系统概述
如果设计说明书中有这一部分，就照抄。 请注意，所需的框架图和网络拓扑图会引起注意。
2.4术语和缩写
列举设计本系统/项目的专业术语和缩略语约定。 关于技术相关的名词和多义词，为了不产生歧义，必须明确记载。
2.5参考资料
3、测试概述
测试摘要说明。 包括测试声明、测试范围、测试目的等，主要是测试情况概述。 (其他测试经理和质量员工的关注部分)
3.1测试方法(和工具) )。
简单介绍测试中采用的方法(和工具)。
3.2测试范围
介绍这次测试的软件功能
3.3测试环境和配置
简要说明测试环境及其构成。
4、测试结果和缺陷分析
这是整个测试报告中最令人兴奋的部分，这部分主要是对各种数据进行汇总测量，测量包括测试过程的测量和能力评估、软件产品的质量测量和产品评估。 对于不需要流程测量或相对较小的项目，例如检查时向用户提交的测试报告、小项目的测试报告等，可以省略流程的测量部分。 采用CMM/ISO或其他工程标准流程时，应提供测试报告，提供流程改进建议和参考。 主要用于公司内部测试改进和缺陷预防机制。 必须列出进程度量。
4.1测试运行情况和记录
描述测试资源的消耗情况，记录实际数据。 (测试，项目目的经理关注部分)
4.1.1测试组织
可以列出简单的测试组架构图
4.1.2测试时间
最好给出测试的跨度和工作量，并区分文档和测试活动的时间。 数据可用于流程度量。
4.1.3测试版
4.2展望分析
4.2.1需求覆盖
需求覆盖率是指被测试的需求/功能与需求规格书中记载的所有需求/功能的比率，通常必须达到100%的目标。
4.2.2测试盖
需求/功能(或编号)用例数运行总数未运行/遗漏测试分析及原因
测试覆盖率计算执行数/用例总数×100%
. 3缺陷统计和分析
由于缺陷统计主要涉及被测系统的质量，这一部分将成为开发商、质量工作者重点关注的部分。
4.3.1缺陷总结
被测系统测试回归测试合计
合计
按重要性分类
严重的，一般微小的
按缺陷类型
用户界面完整性功能算法界面文档用户界面等
按功能分布
一功能二功能三功能四功能五功能六功能七
为了直观地看到，希望呈现有缺陷的饼图和条形图。 谚语说，图标能迅速为读者提供信息，尤其是各级管理员没有时间逐篇阅读文章。
4.3.2缺陷分析
本部分综合分析上述缺陷和其他收集的数据
缺陷的综合分析
缺陷发现效率=缺陷总数/测试执行用时
能给具体人员下达平均指标
用例质量=缺陷总数/测试用例总数×100%
缺陷密度=缺陷总数/功能点总数
缺陷密度可以得到系统各功能或各需求的缺陷分布情况，开发者基于此分析可以得到该部分功能/需求缺陷最多，今后开发时关注，测试经验表明，测试缺陷越多的部分隐藏的缺陷也越多
4.3.3残留缺陷和未解决问题
残留缺陷
评估:对这些问题的看法，也就是说如果这些问题被传播出来会产生什么影响
五、测试结论和建议
5.1测试结论
1 .测试运行是否充分(可以增加对安全性、可靠性、可维护性和功能性的描述) )。
2 .测试风险的控制措施和效果
3 .测试目标是否实现
4 .测试是否通过
5 .能否进入下一阶段的项目目标
5.2建议
1 .说明系统有问题，说明测试中发现的软件缺陷和不足，以及对软件实施和运行的影响
2 .潜在缺陷和后续工作
3 .缺陷修正和对产品设计的建议
4 .关于改进流程的建议
6、附录
·缺陷列表
·缺陷等级定义标准
·测试合格标准
八.测试战略
战略，百计所谓“战略”，就是为了实现某个目标，首先根据可能出现的问题预先制定一些应对方案，然后在实现目标的过程中，根据形势的发展变化制定新的方案，或者根据形势的发展变化选择应对方案。
软件测试的目标是验证软件的功能，找出问题所在，评估软件质量是否符合要求。 软件测试策略必须围绕这样的目标来考虑和制定。 测试策略描述测试项目和测试任务的关系。 用于说明测量什么、如何测量、如何调整测试资源和测试时间等。 他的目的和作用是指导测试工程师测试工作的总方向和侧重点。 测试策略是否合理有效地制定，对测试项目的进度有很大的影响。
测试策略分为几个模块。
1 .测试安排、发布计划
此模块用于枚举测试项目本身的重要里程碑。 每个里程碑都需要明确的结束时间。 这个时间指导下一次测试。 如果没有足够的测试计划，则可以在下一个测试范围内选择优先级较高的特性来运行测试，以最大限度地保证产品质量。
2 .测试范围(按优先顺序)
本部分分为In Scope和Out Of Scope。 本节应说明哪些产品模块在测试范围内，以及在此阶段的测试中不考虑哪些产品模块。 对于测试范围内的模块，需要确定优先顺序，以应对缺乏适当测试时间的情况。 对于不在测试范围内的模块，必须指明原因。 (为什么在本测试阶段不考虑测试)。
3 .测试资源
测试资源是测试战略中重要的一环，分为人才和工具两部分。 人事主要说明参加测试的人。 当然，很多角色，如何可以包括专业的测试人员、客户、产品经理等。 工具主要是指可能使用其他软件(可能需要许可证)
4 .测试环境
测试环境主要包括推荐的环境解决方案、操作系统要求、硬件和软件要求。
5 .测试方法
测试方法的罗列主要是为了说明要对测试项目进行何种类型的测试，需要功能测试，非功能测试是可选的。 测试方法的选择主要根据软件应达到的质量特性来决定。 的6个质量特性为:功能性、可靠性、易用性、高效性、易用性、可维护性、可移植性
6 .用例设计方法
用例设计的一般方法是等价类的划分、边界值、因果关系图、判定表、场景等。 我想说的是，为了提高用例的有效性和验证点的覆盖度，在设计用例时需要软件所具备的以27个质量子特性为出发点的功能性(适应性、正确性、互操作性、安全机密性、功能合规性) 可靠性(成熟性、容错性、易恢复性、可靠性合规性)； 使用起来很方便性(易操作、易理解、易学的习性、吸引性、易用依从性)； 效率(时间特性、资源特性、效率合规性)； 维护性(易分析、易修改、稳定性、易测试、维护性依从性)； 可移植性(适应性、易安装性、易更换性、共存性、可移植性合规性) ) ) ) )。
7 .文档管理
对于完整的产品来说，文档是重要的一环。 通常包括安装、文档升级、用户指南等。 文档不仅仅是一个文件，向客户公开还需要经过全面的测试。 不良的文档很可能会误导用户，使他们对测试项目失去信心(虽然客户很少看到文档……: )
8 .风险管理
风险管理模块应列举目前已知的不确定性因素。 这些因素可能来自技术、资源或其他方面。
9 .提交软件包验证
这部分有一定的特殊性，并不适用于所有的产品。 这一部分主要是测试项目安装包的验证。
九、测试计划(与测试战略差异不明显) )
十、测试计划(与测试战略差异不明显) )
十一.操作系统命令、数据库命令
熟悉window和linux系统的基本操作命令。 由于客户端基本上使用的是window，所以大多数服务器都使用linux。 至少要掌握这两个操作系统中的内容。 新建、搜索、修改、删除、压缩和解压缩文件； 安装、卸载软件； 程序的启动、停止。
关于数据库，很多人都说我是个测试。 我只关心业务。 为什么需要理解数据库的操作？ 业务的本质是对数据库中存储的数据进行操作。 数据是业务的基础，往往不仅仅关注页面显示的变化，而是通过数据库验证数据是否符合业务结果的期望。 因此，测试人员至少要掌握sql server、mysql、Oracle等主要数据的添加、删除、变更操作命令。 面试中也一般会问这些种类
十二.用户界面自动化
现在，自动化测试已经成为测试人员提高工资所需的技能之一。 这里，我推荐一些我知道的UI自动化方案。 网页自动化Python selenuim。 移动端自动化( ios android ) Python appium。 还有很多其他方案，但我没有接触过，也没有理解过，所以都不会胡说八道。 实现UI自动化需要知道的知识是html、css和javascript。
十三.接口测试(手动自动化) )
同样，也是提高工资的技能包。 这里使用过两个方案。 一个是手动进行接口测试。 我推荐一位发言人。 适合在对数较少的接口上进行测试，例如集成其他系统时的技术验证。 多界面分批行驶测试我接触的是ant jmeter工具，jmeter可以批量运行接口，并在每个请求中添加检查点。 ant是Java的文件包集成工具，用于控制对jmeter的调用并以html格式生成结果报告，以便于查看结果
十四.性能测试
同样，提高工资的技能包。 性能测试通过使用自动化的测试工具模拟各种正常、峰值和异常的负载条件来测试系统的性能指标。 负荷测试和压力测试都是性能测试，可以两者结合进行。 负载测试的目标是确定不同工作负载下的系统性能，并测试负载逐渐增加时系统性能指标的变化。 压力测试是通过识别系统瓶颈或不可接受的性能点来获得系统所能提供的最大服务级别的测试。
在实际工作中，我们经常测试bs和cs这两种软件，这两种性能指标一般都需要什么？
Bs结构程序一般关注的一般指标如下(以下)
W:平均每秒响应次数=总请求时间/秒数；
* avgtimetolastbyteperterstion ( ms tes ) :有人用每秒业务脚本重复次数的平均值来混淆两者；
* Successful Rounds :成功的请求；
*失败的请求:
* Successful Hits :成功的点击次数；
*失败的点击次数；
* Hits Per Second每秒的点击次数；
* Successful Hits Per Second每秒成功的点击次数；
*每秒失败的点击次数；
* Attempted Connections :尝试链接数；
CS结构程序重视数据库的测试指标，因为一般的软件后台通常是数据库
* User 0 Connections :用户连接数，即与数据库的连接数；
* Number of deadlocks :数据库死锁；
* Buffer Cache hit :数据库Cach——这是回避。
冒风险，声明如果出现这个问题，开发需要负责。 ——这是转移。
我默默地认为这个风险影响不大，只是让自己知道。 之后，在查明问题之后，处理——是自留。
我提出了这个可能出现的问题，让产品完善需求，提前处理开发。 避免测试后出现此错误。 ——这是控件。
我觉得以上就是我应该拥有的测试人员的知识体系。 其实渗透测试、单体测试、安全测试等，有很多我没有接触过的东西。 接触越多，感觉自己能做的越少，学习。