引言：
软件测试在软件生命周期中占据重要的地位，软件测试慢慢的独立发展成为一个行业，并且在迅猛发展。
一、 软件缺陷与软件故障案例
二、 软件缺陷的定义
对于软件缺陷的精确定义，通常有下列描述：
软件缺陷从哪来？第一大原因就是软件产品规格说明书，很多情况下，说明书没有写，或写的不够全面，经常更改，或者开发小组没有很好的沟通，造成对说明书理解的不一致。第二大原因是软件设计，没有做设计或设计不好，经常变动等和产品规格说明书一样的问题，第三个原因才是编写代码和其它原因；前两个原因至少占了 80%以上。如图1-1所示
图1-1 软件缺陷产生的原因分布
通过大量的测试理论研究及测试实践经验的积累，典型的软件缺陷产生的原因被归纳为以下几种类型：
(1) 需求解释有错误；
(2) 用户需求定义错误；
(3) 需求记录错误；
(4) 设计说明有误；
(5) 编码说明有误；
(6) 程序代码有误；
(7) 数据输入有误；
(8) 测试错误；
(9) 问题修改不正确；
(10) 不正确的结果是由于其他的缺陷而产生。
缺陷发现的越早，则修复这个缺陷的代价就越小，在需求、设计、编码、测试、发布等不同的阶段，发现缺陷后修复的代价都会比在前一个阶段修复的代价提高10倍（参见图1-2）。
引言：
软件测试是保证软件质量的一种手段，那么，什么叫软件测试？
狭义：测试的定义：“程序测试是为了发现错误而执行程序的过程”。这个定义，被业界所认可，经常被引用。
广义：为了更早地发现问题，所以将测试延伸到需求评审、设计审查活动中去，也就是将“软件质量保证”的部分活动归为测试活动。实际上，在软件开发实际操作中，常常将软件测试和质量保证——这两种努力（efforts）合并起来。延伸后的软件测试，被认为是一种软件测试的广义概念。
软件测试的定义：软件测试是贯穿整个软件开发生命周期、对软件产品（包括阶段性产品）进行验证和确认的活动过程，其目的是尽快尽早地发现在软件产品中所存在的各种问题——与用户需求、预先定义的不一致性。
现状：初期、不成熟、浮躁
公司越来越注重，开发与测试比例越来越接近
越来越紧缺-跳槽，待遇
毕业生、想转行
导致浮躁、但真正静下心来学习的不多
基础知识不扎实：知道基本方法但不深入理解
专业技术不够精通：写着精通某某工具，实际上只会皮毛
没有建立器相对完整的测试体系概念：对自己的工作职责理解不到位
在中国必然会经过一个不成熟的阶段，但最终会趋于平静，平稳的发展阶段。
1、参与需求讨论，制订测试计划，确保测试能顺利执行并完成。 2、负责项目的功能性测试、用户体验测试、兼容性测试以及性能测试 3、负责测试用例的编写；编写测试报告和对测试结果分析， 4、与开发人员、产品经理沟通和协作，推动整个项目的顺利进行； 5、负责软件开发团队项目进度管理工作，6.熟悉Linux常用命令，熟悉常用数据库，熟练使用基本的SQL语句； 7.熟练使用Loadrunner，Jmeter等至少一种性能测试工具
成本：项目的开销，人工成本，工具成本，设备成本，错误成本（BUG）
进度：时间，计划
质量：软件对顾客需求的满意程度，一个低质量的软件，即使生产成本很低，进度控制良好，顾客也难以接受。
程序测试包括程序逻辑功能，界面，性能，易用性，兼容性，安装等测试，当然文档测试也算，排版，字体大小，也算程序测试的内容
测试环境=硬件+软件+网络
硬件环境：笔记本,台式机，服务器
软件环境：不同的操作系统windows10 windows8 windows7 Linux Mac ，
不同浏览器firefox chrom
网络:局域网还是互联网
|
需求评审 |
测试计划制定 |
测试计划执行 |
发布与测试报告总结
|
|
1从用户体验角度提供设计建议 2从开发经验角度，分析设计是否存在风险，是否能够实现 3 联合其他模块分析，设计是否存在漏洞，逻辑功能存在缺陷
|
1测试用例设计 2测试用例评审，和测试时间估计 3测试资源申请
|
1用例执行 2 Bug修复验证和推动版本进度 3性能监控，压力测试，兼容测试
|
1版本发布和线上质量监控，用户反馈实时响应 2测试用例更新整合，测试计划评估 3提供版本最终测试报告，包括用例覆盖率，bug数据分析等
|
|
全程跟进需求变更，与产品无缝沟通，在测试阶段有需求变更要第一时间了解改动范围，如果影响版本的质量要说明风险，评估需求是否必须更改以及是否影响版本发布上线的时间线
|
规划测试项目需要的功能开发和自动化开发人员比例，规划整个测试流程需要的时间，要预留处理紧急事件的缓冲
|
执行 协调测试资源，部署测试环境，督促开发和产品提供一切需要的测试工具，测试数据等，推动版本进度，每日进行bug review（bug复盘），标识出bug解决的优先级和提交测试的时间点，每日提供当日产品质量报告
|
报告 项目发布上线后，对整个版本的bug进行数据分析，总结出用例的覆盖率，对于没有覆盖到用例的bug，转化成用例，同时测试人员之间进行分享，针对新接触的测试方法测试工具和有价值的bug进行经验总结
|
黑盒测试(Black Box -Test)指的是把被测试的软件看做一个黑盒子，我们不去关心盒子里边的结构是什么样子，只关心软件的输入数据和输出结果
有人把黑盒测试比作中医，通过“望闻问切”来判断是否有问题。
“望”：观察软件的行为是否正常。
“闻”：检查输出的结果是否正确。
“问”：输入各种信息，结合“望”，“闻”来观察软件的响应。
“切”：像中医一样给软件“把把脉”，敲击一下软件的某些“关节”
白盒测试(White Box Testing),指的是把盒子盖打开，去研究里边源代码和程序结构。
静态测试，是指不实际运行被测试软件，而只是静态的检查程序代码、界面或者文档中可能存在的错误的过程。
动态测试:是指实际运行被测程序，输入相应的测试数据，检查实际输出结果和预期结果是否相符的过程。
是黑盒测试的一部分，它检查实际软件的功能是否符合用户的需求。
功能测试可以细分逻辑功能测试，界面测试，易用性测试，安装测试和兼容性测试。
逻辑功能测试:测试应用是否符合逻辑，比如应该先注册账号之后，才能进行登录,登录之后才能看我的购物车
界面测试:窗口大小，按钮大小，点击按钮弹出什么样的提示框，是否有滚动条，下拉菜单是否有展示内容...
易用性测试:从软件使用的合理性和方便性等角度对软件系统进行检查,比如，软件窗口长宽比例是否合适，颜色色彩是否赏心悦目，字体大小是否合适
安装测试:
兼容性测试:硬件兼容性测试和软件兼容性测试
硬件兼容性:比如一款软件在pc机，笔记本,主机上是否兼容
软件兼容性测试:比如一款软件在windows8和windows10上是否兼容
时间性能:软件的一个具体事务的响应时间。比如点击一个登陆按钮，到登录成功(失败)的反应时间，浏览器非常常见，ANR（Application not responding 应用程序无响应）
空间性能:软件运行时所消耗的系统资源，比如对内存和cpu的消耗
一般性能测试:软件正常运行，不向其施加任何压力的测试
稳定性测试:也叫可靠性测试，是指连续运行被测系统，检查系统运行时的稳定成都。
负载测试:让被测系统在其能够忍受的压力范围之内连续运行，来测试系统的稳定性。（测试载重）
压力测试:持续不断的给被测试的系统增加压力，直到被测试的系统压垮为止，用来测试系统所承受的最大压力。（测试强度）
是指对软件的新版本进行测试时，重复执行上一个版本测试时的用例，比如在1.0版本中，有一个bug，到了2.0版本中,再重新测试1.0中这个bug
指对一个软件进行系统大规模的测试之前，先验证一下软件的基本功能是否实现，是否具备可测性。
测试小组在正式测试一个新版本之前，先指派一两个测试人员测试一下软件的主要功能，如果没有实现，则打回开发组重新开发，这样做可以节省大量的时间成本和人力成本。
是指测试中所有的输入数据都是随机生成的，其目的是模拟用户的真实操作，并发现一些边缘性的错误。
单元测试（unit testing），是指对软件中的最小可测试单元进行检查和验证。对于单元测试中单元的含义，一般来说，要根据实际情况去判定其具体含义，如C语言中单元指一个函数，Java里单元指一个类，图形化的软件中可以指一个窗口或一个菜单等。
总的来说，单元就是人为规定的最小的被测功能模块。
单元测试当一段代码完成之后，是由白盒测试工程师或者开发人员自行测试，比如java中执行单元测试叫做junit测试。
目前大部分公司单元测试由开发人员简单编译和调试一下自己的程序，没有相应的单元测试计划。
单元测试方式:先静态地观察代码是否符合规范，然后动态地运行一下代码,检查运行的结果。
集成测试是单元测试的下一个阶段，是指将通过测试单元模块组装成系统或者子系统，再进行测试，重点测试不同模块的接口部分。
l 在把各个模块连接起来的时候，穿越各个模块的接口的数据时候会丢失
l 一个模块的功能是否会对另一个模块的功能产生不利的影响
l 各个子功能组装完成后，能否达到预期的父功能
l 全局数据结构是否有问题
l 单个模块产生的误差累计起来是否会放大
例如：模块接口测试
l 应对通过所测模块的数据流进行测试
l 调用所测模块时的输入参数与模块的形式参数的个数、属性和顺序是否匹配
l 所测模块调用子模块时，输入子模块的参数与子模块的形式参数在个数、属性和顺序上是否匹配。
l 输出给标准函数的参数的个数、属性和顺序是否正确
集成测试完成之后，就是系统测试和验收测试。
系统测试:指的是将整个软件系统看做一个1个整体进行测试，包括对功能、性能，以及软件所运行的软硬件环境进行测试。
系统测试由黑盒测试人员在整个系统集成完毕后进行测试，前期主要测试系统的功能是否满足需求，后期主要测试系统运行的性能是否满足需求，以及系统在不同的软硬件环境的兼容性等。
验收测试：以用户为主的测试，软件开发人员和质量保证人员参加，
测试一个带广告图案的花纸杯
能否装水，
除了装水， 能否装其他液体。比如可乐，酒精
能装多少ML的水
杯子是否有刻度表
杯子能否泡茶，跑咖啡
杯子是否能放冰箱，做冰块
杯子的材质是什么（玻璃，塑料,黄金做的）
外观好不好看。
什么颜色
杯子的形状是怎么样的。
杯子的图案是否合理
能否装100度的开水 (泡茶)
能否装0度冰水
装满水，放几天后，是否会漏水
杯子内壁上的涂料是否容易脱落。
杯子上的颜色是否容易褪色或者脱落
风吹是否会倒，摔一次是否会摔坏，摔多次是否会摔坏
制作杯子的材料，是否有毒
放微波炉里转的时候，是否会熔化。
从桌子上掉到水泥地上是否会摔碎。
杯子是否容易长细菌
杯子内壁上的材料，是否会溶解到水中
装进不同液体，是否会有化学反应。
杯子是否容易烫手
杯子是否好端，好拿
杯子的水是否容易喝到
杯子是否有防滑措施
是否能接受杯子的广告内容与图案
|
1.应当把“尽早和不断地测试”作为开发者的座右铭。 |
|
2.设计测试用例时，应该考虑到合法的输入和不合法的输入，以及各种边界条件，特殊情况下要制造极端状态和意外状态，比如网络异常中断、电源断电等情况。 |
|
3.一定要注意测试中的错误集中发生现象，这和程序员的编程水平和习惯有很大的关系。 |
|
4.对测试错误结果一定要有一个确认的过程。一般有A测试出来的错误，一定要有一个B来确认，严重的错误可以召开评审会进行讨论和分析。 |
|
5.制定严格的测试计划，并把测试时间安排得尽量宽松，不要希望在极短的时间内完成一个高水平的测试。 |
|
6.回归测试的关联性一定要引起充分的注意，修改一个错误而引起更多错误出现的现象并不少见。 |
|
7.妥善保存一切测试过程文档，意义是不言而喻的，测试的重现性往往要靠测试文档。 |
线性模型：最常见的“瀑布模型”，基础框架，但缺点在于“集成之日就是爆炸之日”。（立项分析-需求分析-设计-编码-测试-维护）很多企业使用后使用迭代进行修改。
渐进式模型：最常见的“螺旋模型”，（需求分析-风险分析-设计、编码-测试、评审），迭代开发和增量开发模式。
注意：每一次迭代原型出来后，测试人员都需要从原型界面，系统主要功能，性能等方面对原型进行评审。
软件生命周期 同任何事物一样，一个软件产品或软件系统也要经历孕育、诞生、成长、成熟、衰亡等阶段，一般称为软件生命周期（软件生存周期）[1] 。软件生命周期模型是指人们为开发更好的软件而归纳总结的软件生命周期的典型实践参考。
许多产品都是使用“边做边改”模型来开发的。在这种模型中，既没有规格说明，也没有经过设计，软件随着客户的需要一次又一次地不断被修改。
在这个模型中，开发人员拿到项目立即根据需求编写程序，调试通过后生成软件的第一个版本。在提供给用户使用后，如果程序出现错误，或者用户提出新的要求，开发人员重新修改代码，直到用户满意为止。
这是一种类似作坊的开发方式，对编写几百行的小程序来说还不错，但这种方法对任何规模的开发来说都是不能令人满意的，其主要问题在于：
（1） 缺少规划和设计环节，软件的结构随着不断的修改越来越糟，导致无法继续修改；
（2） 忽略需求环节，给软件开发带来很大的风险；
（3） 没有考虑测试和程序的可维护性，也没有任何文档，软件的维护十分困难。
瀑布模型是最早出现的软件开发模型，在软件工程中占有重要的地位，它提供了软件开发的基本框架。其过程是从上一项活动接收该项活动的工作对象作为输入，利用这一输入实施该项活动应完成的内容给出该项活动的工作成果，并作为输出传给下一项活动。同时评审该项活动的实施，若确认，则继续下一项活动；否则返回前面，甚至更前面的活动。对于经常变化的项目而言，瀑布模型毫无价值。
瀑布型简单地说就是按照需求、设计、编码、测试、软件维护这个基本的顺序来研发软件，前面一个步骤不完成，后面的步骤不能开始，否则问题会滚到下个阶段，带来更多的问题
优点：
1) 为项目提供了按阶段划分的检查点
2) 当前一阶段完成后，只需要去关注后续阶段。
缺点：
1）各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量。
2）由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发风险。
3）通过过多的强制完成日期和里程碑来跟踪各个项目阶段。
4）瀑布模型的突出缺点是不适应用户需求的变化。
原型化模型的第一步是建造一个快速原型，实现客户或未来的用户与系统的交互，经过和用户针对原型的讨论和交流，弄清需求以便真正把握用户需要的软件产品是什么样子的。充分了解后，再在原型基础上开发出用户满意的产品。
如图所示：原型严格来说不算一种软件生命周期模型，它只是一种获取需求的方法，在实际工作中该方法是相当重要的方法。
模型要点：瀑布和原型模型相结合，强调版本升级。
该模式的特点是一次性地获取全部的需求，然后做出分版本实现各需求的计划，每个版本只实现一部分需求，通过多个版本逐步实现全部需求，而每个版本可以认为是一个“小瀑布”。
该模型的好处是可以尽快让系统上线，让客户先使用部分功能，尽早实现系统的价值。
该模型比较能符合实际的情况，我们往往也是通过多个版本来逐步实现全部需求，但需求是不可能在一开始就完全确定的，实际情况是往往只能确定80%，而后期通过各版本我们还会获取更多的新需求以及需求调整。将此模型稍微调整后，可以适用于大部分的实际项目。
增量模型也是原型化开发方法。如图所示
螺旋模型是一个演化软件过程模型，将原型实现的迭代特征与线性顺序（瀑布）模型中控制的和系统化的方面结合起来。使得软件的增量版本的快速开发成为可能。在螺旋模型中，软件开发是一系列的增量发布。螺旋模型的整个开发过程如图所示。
图中的螺旋线代表随着时间推进的工作进展；开发过程具有周期性重复的螺旋线形状。4个象限分别标志每个周期所划分的4 个阶段：制定计划、风险分析、实施工程和客户评估。螺旋模型要点：统一了瀑布模型与原型模型，与增量模型相似，更强调风险分析。
1.软件分多个版本开发，每个版本就是一次螺旋。
2.每个版本按照这样的顺序进行：
1）确定软件目标，选取定实施方案，弄清项目开发的限制条件；（图中左上象限）
2）分析所选取方案，考虑如何识别和消除风险；（图中右上象限）
3）实施软件开发；（图中右下象限）
4）评价开发工作，提出修正建议，调整计划。（图中右下象限、左下象限）
3.需求不是一次获取和实现的，通过多个螺旋来完善。
4.计划也不是一次成型的，每次螺旋都需要调整。
优点：
1）设计上很灵活，可以在项目的各个阶段进行变更；
2）以小的分段来构建大型系统，使成本计算变得简单容易；(国企项目)
3）客户始终参与每个阶段的开发，保证了项目不偏离正确方向以及项目的可控性；
4）随着项目推进，客户始终掌握项目的最新信息 , 从而能够和管理层有效地交互；
5）客户认可这种公司内部的开发方式带来的良好的沟通和高质量的产品。
缺点：
螺旋模型强调风险分析，但要求许多客户接受和相信这种分析，并做出相关反应是不容易的。
因此，这种模型往往适应于内部的大规模软件开发。该模型建设周期长，而软件技术发展比较快，所以经常出现软件开发完毕后，和当前的技术水平有了较大的差距，无法满足当前用户需求。
V 模型的左边下降的是开发过程各阶段，与此相对应的是右边上升的部分，即各测试过程的各个阶段。
V 模型的优点在于它非常明确地标明了测试过程中存在的不同级别，并且清楚地描述了这些测试阶段和开发各阶段的对应关系。
V模型的缺陷及解决思路
V模型仅仅把测试过程作为在需求分析、系统设计及编码之后的一个阶段，忽视了测试对需求分析,系统设计的验证，需求的满足情况一直到后期的验收测试才被验证。
解决的思路是，当一个软件开发的时候，研发人员和测试人员需要同时工作，测试在软件做需求分析的同时就会有测试用例的跟踪，这样，可以尽快找出程序错误和需求偏离，从而更高效的提高程序质量，最大可能的减少成本，同时满足用户的实际软件需求。
相对于V模型，W模型更科学。W模型是V模型的发展，强调的是测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、功能和设计同样要测试。测试与开发是同步进行的，从而有利于尽早地发现问题。
https://zhidao.baidu.com/question/8152959.html
软件测试工具是通过一些工具能够使软件的一些简单问题直观的显示，使测试人员更好的找出软件错误所在。
软件测试工具分为自动化软件测试工具和测试管理(禅道)工具。
软件测试工具存在的价值是为了提高测试效率，用软件来代替一些人工输入。
测试管理工具是为了复用测试用例，提高软件测试的价值。
一个好的软件测试工具和测试管理工具结合起来使用将会使软件测试效率大大的提高。
Bug管理工具： 禅道 Jira（付费）,Trac,gitlab
自动化 python+ selenium ，python+ appnium （ui自动化） pytest,unites,Junit (测试用例 单元测试) innerHtml （发送测试报告） request +python+allure 接口自动化
性能测试工具 jmeter ,Loadrunner、
抓包工具 Fiddler charles (弱网测试的)
接口工具 postman ，jmeter
录制脚本 bodyboy jmeter
云测 腾讯云 模拟不同的移动端或者是web浏览器
命令 Linux adb monkey
数据库 myql,oracle,redis
语言 python,java,c,c++
Winrunner 最主要的功能是自动重复执行某一固定的测试过程，它以脚本的形式记录下手工测试的一系列操作，在环境相同的情况下重放，检查其在相同的环境中有无异常的现象或与预期结果不符的地方。可以减少由于人为因素造成结果错误，同时也可以节省测试人员大量测试时间和精力来做别的事情。功能模块主要包括：GUI map、检查点、TSL 脚本编程、批量测试、数据驱动等几部分
商业化-挣钱 性能测试工具 响应时间，CPU，内存，吞吐量....
LoadRunner® 是一种预测系统行为和性能的工业标准级负载测试工具。通过以模拟上千万用户实施并发负载及实时性能监测的方式来确认和查找问题，LoadRunner 能够对整个企业架构进行测试。通过使LoadRunner ，企业能最大限度地缩短测试时间，优化性能和加速应用系统的发布周期。LoadRunner 是一种适用于各种体系架构的自动负载测试工具，它能预测系统行为并优化系统性能。LoadRunner 的测试对象是整个企业的系统，它通过模拟实际用户的操作行为和实行实时性能监测，来帮助您更快的查找和发现问题。此外，还能支持广范的协议和技术，为您的特殊环境提供特殊的解决方案
QTP是一个B/S系统的自动化功能测试的利器,软件程序测试工具。Mercury的自动化功能测试软件QuickTest Professional ，可以覆盖绝大多数的软件开发技术，简单高效，并具备测试用例可重用的特点。Mercury QuickTest Pro 是一款先进的自动化测试解决方案，用于创建功能和回归测试。它自动捕获、验证和重放用户的交互行为。 Mercury QuickTest Pro为每一个重要软件应用和环境提供功能和回归测试自动化的行业最佳解决方案。
测试管理工具
基于WEB的测试管理工具，他能够让你系统地控制整个测试过程，并创建整个测试工作流的框架和基础，使整个测试管理过程变得更为简单和有组织。他能够帮助你维护一个测试工程数据库，并且能够覆盖你的应用程序功能性的各个方面。T并且还为你提供了直观和有效的方式来计划和执行测试集、收集测试结果并分析数据。还专门提供了一个完善的缺陷跟踪系统。并可以同Mercury公司的测试工具、第三方或者自主开发的测试工具、需求和配置管理工具、建模工具的整合功能。你可以通过他进行需求定义、测试计划、测试执行和缺陷跟踪，即整个测试过程的各个阶段
自动化测试工具 支持java python的脚本 python
自动化--写好脚本，运行脚本，自己执行，自己出测试报告，自己发送到测试和开发邮箱
80%bug 手动测试出来
Selenium是为正在蓬勃发展的web应用开发的一套完整的测试系统。Selenium测试直接运行在浏览器中，就像真正的用户在操作一样。它的主要功能包括：测试与浏览器的兼容性——测试你的应用程序看是否能够很好得工作在不同浏览器和操作系统之上。测试系统功能——创建衰退测试检验软件功能和用户需求。支持自动录制动作和自动生成。Selenium的核心Selenium Core基于JsUnit，完全由JavaScript编写，因此可运行于任何支持JavaScript的浏览器上，包括IE、Mozilla Firefox、Chrome、Safari等
自动化测试工具，android和ios软件 手机App app
Appium是一个开源、跨平台的，适用于原生或混合移动应用(hybrid mobile apps)的自动化测试平台。Appium使用WebDriver（JSON wire protocol）驱动安卓和iOS移动应用.Appium的设计哲学是不要为了移动端的自动化测试而重新发明轮子，重新写一套惊天动地的api，也就是说webdriver协议里的api已经够好了，拿来改进一下就可以了另外Appium可以把server放在任意机器上，哪怕是云服务器都可以，所以Appium和WebDriver天生适合做云测试。
开源，免费，简单，易操作。 开源组织，支持脚本录制，支持抓包测试，支持测试移动端软件
压力和负载测试
接口测试是测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。测试的重点是要检查数据的交换，传递和控制管理过程，以及系统间的相互逻辑依赖关系等。
接口测试的目的是测试接口，尤其是那些与系统相关联的外部接口，测试的重点是要检查数据的交换，传递和控制管理过程，还包括处理的次数。外部接口测试一般是作为系统测试来看待的。
接口自动化
接口上传参数的正确性，和服务器返回值的正确性，容错性验证(滴滴)，以及安全性检测。
包是指数据包.目的是分析包的内容与相关协议,然后衡量是否符合当初的设计或排除故障.
在被测接口并没有明确的接口文档给出时，我们需要借助抓包工具来帮助测试，利用抓包工具我们几乎可以获得接口文档中能给你的一切
Charles，fiddler 抓包工具
抓浏览器，抓手机APP请求
原文：https://www.cnblogs.com/tutubuguai/p/13602804.html