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