目录
前言
在自学的开始，我应该先对这一名词有所了解，在过去一年多的时间里，同样是作为测试岗位的工作者，虽然一直在兢兢业业工作，但是对于自己的认知其实并不清楚。作为应届生也是稀里糊涂的开始了自己的测试工作，最近因离职休息和学习也是有空闲的时间来进行自己这段时间一部分的学习记录，因为自己也只是一个超级菜鸡，之后尽量保持一定的更新频率，一是对所学技术和概念的温故知新，二是让自己保持一颗不断学习的心，不断去学习和提高，三也是通过记录流水账来满足自己喜欢码字的癖好。。。
有错误理解之处，希望大佬们不吝指出，谢谢！！
1.啥是软件测试？
很明显，要先知道这个概念，乃至于工作岗位要做什么，我们需要先知道什么是软件测试。
我在这一栏里，记录了我自己理解下软件的定义/软件的组成/软件产生过程/软件测试的定义/软件测试的目的。
1.1什么是软件？
那什么是软件呢？在看了很多的定义之后，我觉得都太过于系统官方，我在博客里按照自己的理解来发表看法。软件，简单来说就是控制计算机硬件工作的工具。
那软件是怎么样构成的呢？我查找了具体的软件组成定义，区分为系统软件和应用软件。系统软件是各类操作系统，如windows、Linux、UNIX等，还包括操作系统的补丁程序及硬件驱动程序，都是系统软件类。 应用软件可以细分的种类就更多了，如工具软件、游戏软件、管理软件等都属于应用软件类。我们日常说到的软件测试大部分还是只针对应用软件，所以我们去了解组成，只需要知道应用软件的组成即可。当然系统软件在不同情境下，我们也需要了解常用的操作系统去方便接手不同研发人员使用不同操作系统开发出来的应用软件任务。
1.2软件由什么组成？
因在这里只针对应用软件的组成分析，后续有记录到linux系统命令的学习时我会再进行相关的补充。（之后我提到的软件都默认以应用软件）
大部分软件组成可以简单由三者定义，页面客户端--代码服务器--数据库服务器（三者之间两两请求和应答）。当然也有存在比较特例的一些软件，例如嵌入式的软件，并非有熟悉的客户端，服务器，作为单片机的软件，本身是一个载体，例如常见的工业路由器/树莓派等，不过也能利用客户端和服务端这最基本的结构去进行理解，例如路由器我们在通信的领域中也能将自身终端设备作为客户端或者服务端，这又是涉及到传输层的知识了，后续我有具体记录也会再进行补充。
1.3软件产生过程复杂吗？
如果没有从事过软件测试工作的人，大家对于软件产生过程可能就是和我当时刚进入校园一样，以为是产品经理一顿输出研发人员一顿开发就完成了。事实上很大一部分流程也是这样，但是大部分没有接触过的可能会想的更简单，认为软件好坏就是由研发人员一个人完成的，更觉得研发人员技术的高低就决定了一个软件产品的质量好坏。
事实上，一个软件产生过程在现在的流程是比较系统和完善的。越大的公司可能会有更加完善的体系，我在这里仅是从自己的工作经历和查询到的部分资料上所来做的一个理解。
软件初步产生过程是由 客户/产品经理 所提出的需求做起始点出发，然后使用产品经理编写的需求文档（这个非常的重要，直接影响到后续一步步流程的跟进）和产品原型图（当然这个可能大公司会有对应的UI设计人员能够提交出简洁/友好/流畅/美观的界面设计），该需求文档会交由给研发人员，而研发人员就会着手开发，当开发完成后 会移交到测试部门，进行一系列的测试手段，公测内测通过之后进行部署上线，至此一款软件产生的过程就结束了（当然只针对发行，之后的维护或者定制之类的还会再进行“返厂”）
1.4讲了这么多，到底什么是软件测试？？？
没错，软件测试就是上述软件产生过程中的一环，由测试部门（当然研发也会有自测）进行测试去验证是否满足客户使用需求。
归纳成一句话就是，“使用技术手段验证软件是否满足使用需求”。 这里的需求就包括常见的功能需求和安全需求，若大型的软件项目必然也会涉及性能需求。
1.5测试软件的目的是什么？
在上述软件产生过程说了，在部署上线之前我们需要做到公测内测一系列测试通过。在我们做事情的时候，必然不会让我们顺心，我们想好好的让一款软件能够部署上线提供给客户使用，上线后如果客户遇到他们操作出来不想要的结果了怎么办？我们测试软件的目的就是为了尽量保证不遇到这样的情况发生！
有这么一句话希望大家和我自己永远记住，世界上没有完全没有bug（缺陷）的软件！
我们测试软件的核心目的，就是为了减少bug缺陷去保障软件的质量
2.软件测试分类
我们通过第一个模块已经大概对软件测试有了一个了解了吧，那么我们平常都是咋样来进行软件测试的呢？？？
一般我们谈到软件测试，都会讲到以下常听的七种测试类型。
2.1按测试阶段划分
我们先前知道的软件产生过程其实是一个软件项目运行的大的周期，那么我们如何去了解细化的测试周期阶段，从而知道有哪些测试分类。在这里我可以先说明，基本是由单元测试/集成测试/系统测试/验收测试组成的。
首先，我们知道软件是由研发开发出来的，那么必然有涉及到代码部分，那么科班出身的朋友们肯定知道研发的代码都是一块块的 一个个单元函数写出的，那么我们阶段测试的第一个测试方法就是单元测试。在这里也非常好去了解，按照程序源代码进行测试。例如常见的软件登录功能或者注册功能（微信qq都有用过吧，第一步是是不是就是登录），这个功能是一个独立的，我们需要验证这几十行代码是否都能够执行起来，可能有的分支/条件/路径并没有索引调用到。同样的，其他一个个实现功能的单元模块也是，比如淘宝购物车添加的部分也是由添加的那一部分功能代码去实现的，去对这一功能单元进行测试。
第二，我们上面说的通过一个个单元代码实现的每个功能，那么比喻为一块块积木，我们想把他们搭建起来，实现相互之间的依赖关系。那么我们就会让他们对每个单元模块之间进行接触和适配，这时候就有了阶段测试的第二个测试方法叫做集成测试（也被称为接口测试）。这是针对不同模块之间访问地址去进行测试的，例如上述比喻做搭积木就是把需要拼装的积木进行组装是否能够合并起来。
第三，在我们对软件的程序代码内部实现了每个部分能够各自运作切依赖部分能够请求互通响应之后，我们会对整个的软件进行阶段测试的第三个测试方法叫系统测试，这里是对整个软件进行测试，也是我们最常见的功能测试，不论公司大小基本上都得进行这样的系统测试（上述提到的两个阶段的测试比较高级 一般存在于中大型公司，复合他们测试质量前移的理念还能减少成本）
第四，前面三个阶段基本上以及测试完成了，这时候基本上可以说常规的一些bug都被排除了，但是记得我们说过的话，世界上没有完全没有bug的软件。我们仍然需要走最后一步，将软件去做阶段测试的第四个测试方法叫做验收测试。这个适用于大型的软件项目或者游戏类型的项目，对使用人群量有一定的要求，那么为了更好的保障软件质量不会出现一些细微的难发现的问题，我们需要对软件进行内测和公测，使用不同的人群去挖掘软件项目的缺陷。内测的理解很简单还是由公司内部的员工进行测试，可以是别的部门的同事或者负责别的项目的测试人员来进行验证；公测的理解方法也比较容易，比如说我们常见游戏公测（当然也有叫内测的），基本上是交给少量的客户来进行使用，那么通过提前的对客户使用情景来进行把控达到软件运行的稳定性才会有一个好的收益。
2.2按代码可见度划分（常见）
其实就是大家说的黑盒白盒灰盒测试。。。可能听起来很有b格，是比喻出来的，为个人更建议上述的按阶段测试划分的测试方法。
既然提到了，也简单说一下这三者的区别，其实跟标题一样显而易见。
黑盒测试，就相当于测试者把被测程序看成一个黑盒,不用关心程序的内部结构。因为官方的解释一直都比较系统官方。。所以我还是用自己的话来总结，其实就是源代码不可见，UI功能可见，那么主要也就是功能测试+系统测试，例如你输入信息进去之后能否给予你一个正确的反馈。当然你并不知道具体的代码和程序的逻辑，只能瞎摸索。
灰盒测试，就相当于测试者能看到部分程序，是基于对程序内部细节有限认知上的软件调试方法。测试者可能知道系统组件之间是如何互相作用的，但缺乏对内部程序功能和运作的详细了解这里看到的部分程序，其实就是能看到程序接口（每个代码的单元模块）的请求/参数/url方法，但是还是看不到具体的程序代码和逻辑。这里的灰盒测试，其实也就是能不能进行集成测试（接口测试）。
白盒测试，很显而易见了就是测试者能看到全部的代码，但是功能不可见。基本测试人员很少会去做白盒测试，除非涉及到测试开发的层级，这里的测试开发基本上也指的是开发人员，甚至于是高水平的开发人员，能够对代码进行review。但代码reivew的成本很高，基本上不会对此进行要求，更多的是开放源码，支持测试开发人员能够实现可集成的自动化开发，这一部分我也仍然在学习摸索当中，后续会继续补充相关部分的学习。
2.3其他的测试（补充）
这里稍微补充一下，除去上面常归纳出来的七种测试大类，还有比较值得关注的如性能测试，它是归属在专项测试里的并非属于功能测试，也是软件指标里经常需要去衡量考虑的。还有安全测试，也等同性能测试，都是需要被考虑的非功能测试的必测测试。
而最有逼格的自动化测试，其实显而易见只是为了提高效率，那么它算是非功能测试吗，很明显它归属于功能测试，自动化测试不论是采取工具自动节省效率还是利用代码的可操性，最终的载体都是在功能测试上进行重复操作，由工具或者代码代替了人为都手动点点点，所以要区分开来。自动化测试仍然是在功能测试的范畴。
3.质量模型
知道了软件测试里常谈的一些名词后，那么通过这些我们就能判断出软件的好坏了吗？？显然是不可以的。那么软件测试是怎么判断软件好坏的？
我根据一些资料里的软件质量模型和自己在工作里优先级较高的关注切入点，自己总结了五个重要的质量模型特性，但不限于5个仍然有3个在补充点之中。ps：功能性/性能/兼容性/易用性/安全性。
3.1功能性
这个不用多说，质量模型一定要先满足正向需求里的功能全部保证实现，由单一的功能性测试到业务类型的功能测试，都需要保证。
3.2性能
这个也是上述说过的非功能性的必测点，软件不仅只是前端客户端页面的体现，还会涉及到后端服务器的部分，那么性能很有必要，就对服务器的响应时间/错误率/吞吐量/资源占用率（硬件内存，cpu，磁盘，网络等）这些都是归属于性能测试。
3.3兼容性
软件中最常见的就是web软件，那么很显然web的载体浏览器就需要第一个被考虑到兼容性问题，有自己内核的浏览器最常见的就是谷歌/ie/微软edge/火狐（Firefox）/欧朋/苹果Safari，这些需要被考虑到，一般要在常见的版本里实验。提一嘴，360浏览器并非有内核，其实它就是谷歌+ie换皮肤。。。
还记得上面提到的软件是应用软件和系统软件吗，那么我们也需要对到不同的操作系统来进行兼容，不去区分大类的话，仅在win下我们也有常见的xp（现在少见了）/win10/win7/win8/win11（现在新电脑都预装），特别注意有的嵌入式的需要安装驱动的在新的操作系统下都需要进行驱动的手动安装。
上面针对的都是web形式的软件，如果是手机端的软件app其实也是一样的，我们会对手机进行兼容性的验证。如常见的分辨率/品牌/系统/网络/其他。具体可以参照APP流量平台 - 百度统计流量研究院来进行目前常用的手机品牌/机型/系统等
3.4易用性
前面有说过，在大公司里是有配备专门的ui设计师或者厉害的产品经理，是能做出好的产品原型图和设计的，那么除了功能上的使用契合度，我们易用性上也决定了一款软件产品的质量好坏。一般来说易用性需要满足例如注册信息的繁琐程度降低的简洁性，ui设计里的颜色色调是否对不同人群的友好，用户体验的流畅程度，每个菜单界面是否美观。（简洁/友好/流畅/美观）
3.5安全性
软件最容易忽视的就是安全问题，现在也有很多企业高薪聘请专门的安全工程师来保障自身的软件问题，而我们普通的软件测试也需要考虑一些数据上的保密，例如传输和存储过程中最容易出现的数据泄漏问题，我们是否对这些数据进行加密处理，而不是留下被人为手段容易达到明文抓走敏感数据的把柄。常见的例如登录数据，通过浏览器开发者插件就能够抓到对应的post请求，在请求体里能够看到账号密码未进行加密则是存在极大的安全隐患。
3.6可靠性
这个其实算是归属于质量模型里性能的部分，因为常见的可靠性也算是稳定性，比如程序未响应情况下的处理，还有程序卡顿和死机现象的反馈问题等，都归结于可靠性方面。因为这个可能更多考验研发的水平，测试人员也爱莫能助。。。
3.7移植性
这个一般是中大型公司才会考虑的问题，比如网站数据的迁移，或者出现的一些域名的更换啊等等需要变动到数据或者代码部分的，一般也是不怎么需要注意的。
3.8维护性
这个也是比较大型公司才需要考虑到的维护性和成本的问题，一般都是由研发内部进行考虑。如果存在版本较多的情况下，是否有公用的服务器存储代码或者保存数据以免遗失重要资料和文档。
4.测试流程的步骤
讲了这么多了，咋还是理论，我自己写的也快累了，到这五千字洋洋洒洒都是记着理论流水账。但是开始讲具体的测试流程，还是得谈理论，结合我自己的工作经历，来讨论测试流程有哪些步骤，以及会踩到的坑。
小小测试工程师，来完成测试项目的测试流程其实很简单的，只需要记住6步！（需求评审/计划编写/用例设计/用例执行/缺陷管理/测试报告）
4.1需求评审
测试流程里的第一步，也是比较至关重要的一步。首先我们需要确保各个部门需求理解的一致，是否有遗漏的地方。这个和产品的定义需求一样重要，事实上很多测试项目到后期较大的维护成本基本都是在这里出现了问题，没有在一开始就对一些细节的要求规划好，导致我们在测试过程中同样担当了产品经理的角色，在技术支持和开发之间两头跑，三个角色产生三个不一样的理解，最终仍然是以客户现场或者产品经理定义的需求标准为主。该部分尤其是针对工业化级别的项目，在大量发货出后，需要在软件产品在开发之前就做到详细的调研，而不是模糊的定义和模棱两可的标准，所以测试对产品提交的需求文档一定要足够仔细的让自己和各个部门同时理解到位，因此需求评审会议是十分重要的，能够避免后期不必要的维护。
btw提一嘴，测试流程最好与项目管理cmmi体系结合，这样能够更好的确保整个软件开发迭代周期是符合高效率的办公化结构。
4.2计划编写
这里的计划是整个测试项目的计划，包含了测试什么内容/谁来测试/测试项目的应用场景/测试的风险/风险的管控等一系列记录情况。在这里更是一份测试计划报告的整理输出，一般看各自公司是否有模版，一般可以于产品的需求文档/产品的说明书结合一起写。
4.3用例设计
这里设计测试用例，就是作为验证项目是否符合需求的操作文档，测试用例是什么呢？
测试用例我自己的理解有几种不同的定义方式：用户使用的案例/模拟不同用户使用的情景/是为测试项目去执行的文档，当然也是上面说的验证是否符合产品经理提出需求标准的操作文档。
4.4用例执行
这里很好理解，就是项目模版开发完成后开始执行用例文档，按部就班实施测试计划。有时候在执行测试计划的时候，可能也会再自行添加一些临时的业务流程补充测试。
这里涉及到的测试用例，会有用例的设计方法和一些缺陷管理的流程这在之后的 学习总结里我会继续补充出来。
4.5缺陷管理
这里的缺陷，就是在测试用例里执行后，最终结果没有达到或者不符合测试用例里写的预期结果。那么这样的缺陷就需要被提交去一个专门的被记录的地方（这个也在后面的地方会进行补充）。那么这里仅简要描述一下这个管理流程，即提交缺陷/回归缺陷/关闭缺陷，
最重要的就是提交缺陷和回归缺陷，因此处仅简要描述固不多对此进行笔墨。
4.6测试报告
这里的测试报告，更是输出最后的验证结果，多是以bug数量统计和分布记录的一种文档。一般最后输出的报告都是作为留档或者表示着一个项目的结束。不仅具有对项目体量化的参考意义，也是对一周期或者一阶段任务完成效率的审视。在web端的测试中，有不少方法能够使用封装好的库自动生成html格式的报告，例如newman是postman推出的一个node.js的库，不仅可以方便地运行和测试集合，还可用之构造接口自动化测试和持续集成；当然也能实现上述说的自动生成测试报告格式，一般使用npm install -g newman-reporter-htmlextra(不会告诉你这个extra后缀的报告生成的比较有逼格），不过这个安装方法前提是要有node.js，有了之后再安装npm-newman。
因为这里扯的太多了暂时先不继续流水账，之后也会有专门写接口测试部分的学习总结会设计到这一部分的内容。
5.测试用例模版
上面一直在对测试这个专业术语侃侃而谈，那落实到具体要测试的时候应该要做什么呢？我们在测试流程里提到了，也是测试人员必不可少的一环和需要熟练掌握的一个技能就是测试用例。那测试用例怎么写呢，我根据自己公司和网上其他一些的文档资料总结了一个简单的模版，包含了常见的测试用例8个要素点。（用例编号/用例标题/项目，模块/优先级/前置条件/测试步骤/测试数据/预期结果）当然在底下的详细解释里也会再补充参考别的部分内容，不仅限于上述提到。
这些要素一般在首行，我们会比内容设置大两号字体并且加粗处理，在审阅或者视图里将其冻结首行以达到下图的效果（btw这是接口测试的效果图，内容不一定一模一样，本质是一样的）。
5.1用例编号
首先我们写一份测试用例，一般都会在excel表格里进行操作，有的公司会在禅道这样的管理工具上面直接进行用例的添加（但是那样一条条的填写属实是有点痛苦）。在excel统计表下，我们用过都会知道一般用首列进行编号的顺序书写方便我们记录数据，同理我们用例也会有对应的编号。
以我自己公司所规定的用例编号，一般是由产品对需求文档里的需求编号进行扩写，一般组成部分都是新项目创建的日期开始，再配对上此条用例的类型，例如功能或者业务类型的用例就编写YW/xxxx这样的顺序编号。那么网上其他标准的格式也可以是：项目简称_模块_编号，这个都视各自公司规范而定。
5.2用例标题
这个也是比较常见的要素，通过标题能够知道要测的东西内容是什么。一般标题就是期望结果+测试点，例如常见的测试登录部分，就有登录成功（正确手机号）这样的标题例子。
5.3项目/模块
这个是方便我们在大几百几千条用例之中能够看到相关的模块信息，通过excel表格里的筛选就能只显示出我们所需要的那一测试模块或者单元里的具体用例里，隐藏其他不想看到的测试用例（在这里就能把Excel表单管理数据的优势发挥出来）。
5.4优先级
这个是用例里比较特殊的一块，我们一般规定优先级都是分为p0～p4，从高到低。一般优先级越高就越需要关注其测试结果，默认产品需求规格书里的标准功能都是p0必测通过级别，而p2或者p3一般是一些分支测试点 ，例如性能以及安全性测试的补充，也有不少测试用例是规定先前在质量模型之中的易用性占据p2和p3部分的优先级别，一般p4比较少会用到，有的公司也不会用到p4级别的用例。可能也是我还没有遇到足够细化的标准的公司。
5.5预置条件
如小标题所说，是一个测试前置的环境条件，这是非常重要的，例如在购物商城这样的web软件测试下，我们在对员工进行操作时，很明显需要满足登录成功这样的前置条件才有后面一系列的登入操作。
5.6测试步骤
这个也很显而易见了，就是这条用例所需要执行的步骤，还是拿登录模块距离，步骤一输入手机号/密码，步骤二点击登录，就是这样简单的两个步骤，换到复杂的模块里也是这样一步步去简化。
5.7测试数据
这个属于是部分用例特有的，有的用例可能不需要填写数据，但是像上面的登录模块就需要填写数据参数，而一些纯粹鼠标点击web界面的交互就不需要填写。
5.8预期结果
这个要素非常重要！首先我们需要区分开来它和测试结果的区别，它并不是测试结果，而是产品经理或者研发期望得到的一个结果，这个是我们脑子里想象的结果并非实际产生的结果！比如我们在正常的登录模块里，我们想的非常简单对的就是登录成功错误的返回用户名或密码错误，那么也存在不同的结果产生，比如说什么都没有返回。所以预期结果一般都是正向的结果！
5.9其他要素
刚刚提到的预期结果，那么基本上测试用例模版里也有存在测试结果，这里测试结果会有几个常见的参数标准例如PASS/FAIL/NA/POK等，具体填写要看和预期结果的差距或者说是研发是否有做该部分内容；还有一般会在后面添加例如备注的注意点要素，可复现的/可证明的测试结果验证图等，这些其他要素也是不同公司的要求标准。
6测试主流方向
流水账记了这么多，我们已经对整个软件测试流程有一定的了解了，或许还是有很多要知道的细节，但是仅针对软件测试这个词汇我们已经解析了很多。当然在大致知道了软件测试怎么样之后，相比我们还是得需要了解一下啊软件测试大体的一个方向，这也是为了我们之后自己想要从事的工作做一个眺望。
众所周知，所有的测试基本都是从功能测试做出发点开始。功能测试就是用来验证程序的功能是否满足需求，那么大家一直说的自动化测试又是怎么一回事呢，自动化测试其实也没有想象的多么智能智慧遥不可及，用简介的话语来概括自动化测试就是使用代码或者工具代替手工对软件项目进行测试验证。我觉得有这么一种方向就是在功能测试上深耕然后发展测试工程师个人能力达到功能自动化。
我们在上面的测试分类也谈到过，按阶段测试里划分出来的接口测试，那么它也是能降低测试成本/质量保障前移的一种测试类型，它在结合功能测试也可以说是阶段测试划分里面的系统测试，也能够很完善的测试完一个软件项目，那么它是否也能有自动化这样的节省人力的手段在里面呢，有！目前也被常讨论的持续化集成就是这样通过代码或者现场的工具来达到不断的对接口进行请求发送和自动响应。
最后，我们最容易被忽略掉的性能测试，这个在不同领域有着很大不一样的定义标准，目前我对性能测试的了解相对还较少，后续我会在性能测试的自主学习里添加自己的总结，这也是一种方向，由做的很完善的功能测试+性能测试组成的测试管理。
通过上述的三种组合（功能测试+接口测试/功能测试+性能测试/功能测试+web自动化）这样的几个方向，我想能够比较轻松的对自己想做的测试大方向有了一个模糊的定义，去招聘网站查找目前所需要的人才储备，大多数都是对这三者有一定的要求的。
7总结
其实写完这些东西，确实字数多且冗杂看起来不是那么的好，这也是我第一次写博客写的测试的总结，有很多待改进的部分，后续的改进点可能更多会贴一些思维导图以及好的资源网站跳转进行分享，总之写完第一篇博也是一个好的开始，提醒自己要不断学习充实自己的同时，也能记录所学分享一点点心得。
3727
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
