基本介绍
一，软件测试定义
通过手工或者工具对“被测对象”进行测试操作，从而验证实际结果与预期结果之间是否存在差异。
（打一巴掌还一口，差异就是bug简称缺陷）
二，软件测试的作用
1，通过测试工作可以发现并修复软件当中存在的缺陷，从而提高用户对产品的使用信心。
2，测试可以记录软件运行过程中产生的一些数据，从而为决策提供数据支持。（12306购票，同一时间访问量没有考虑到，测试过程中设定1亿用户到10亿用户，公共网络某一时段）
3，测试可以降低同类型产品开发遇到问题的风险（让别人先去看看，自己再去，实验品，同类型：qq-微信）
三，测试原则
所谓的测试原则指的就是我们在执行测试工作时必须要遵守得一些原则
1，测试证明软件存在缺陷（无论做多少只能证明当前软件是有缺陷的）
2，不能执行穷尽测试（没有办法把所有情况都罗列出来，所以任何的测试工作都与结束的时候），（从现在到死都测不完，进公司一年就测一个功能点，测得的很全，肯定不要你）
3，缺陷存在群集现象（28理论，核心=20%，非核心=80%）
（qq功能常用的核心功能很小的一部分20%， 其他功能80%都不是核心功能，核心功能抢占市场，要集中所有的人力物力财力测核心功能，100人测20%，1人测80%。 那种测出问题的机率大？ 100双眼睛盯着一个人发现的多。 会发现更多的缺陷=缺陷群集）
在实际工作中我们会集中测试20%的核心功能，所以这个部分发现缺陷的几率就会高于80%。因此我们就会遇到缺陷都集中在20%功能模块里的现象
4，某些测试需要依赖特殊的环境（南北方温度不同，手机电池低温下未做测试）
5，测试应尽早介入：为了更多的发现和更好的解决软件中的缺陷，我们追求测试工作尽早的展开
（发现bug 开发人员要改 改完保证没有问题不行 你说没问题就没问题啊，必须在测试，关联测试，牵一发而动全身）
6，杀虫剂现象：同样的一个测试用例不能重复的执行多次，因为软件会对她产生免疫（产生抗体，）
（我告诉你2.3 3.7不等于6 你会怎么做呢？想尽一切办法去做改成好用的，所以再测试的时候就不能在用同样的数据，所以开发人员讨厌测试人员）
7，不存在缺陷谬论
（我的软件没问题？谬论，指鼻子骂他。）
测试对象介绍
对于当前的测试行业来说我们最经常测试的主体就是软件（主体功能），但是需要我们明白的是一个软件也不仅仅只有功能需要测试。我们可以将软件分为三个部分组成：
功能集合 使用说明书 配置数据
配置数据：默认提供给客户的也要是对的（冰箱）
地图软件，淘宝打开有东西吧 默认数据 为了让客户快速的看到网站默认的东西
手机买回来会自带的软件都属于配置数据
对于一款软件来说从无到有需要一个过程，我们把可以将这个过程分为不同阶段，然后每个阶段都会有相应的测试
1，需求分析阶段：各种需求规格说明书
（用户有可能怎样用，用户按照他的操作会得到一个什么样的结果，写出来 测试人员拿到这个说明书进行设计，不要觉得这个连软件都没有要怎么测呢，字错了都算测试，不是所有的功能都能实现，不可行的需求，测试阶段提出建议，半年之内从地球到火星，可能吗？）
2，软件架构设计：API接口文档（接口测试）
设计的概念：房屋构造
Cto：首席技术执行官，不需要做底层代码编写，站在一定的高度，把整个公司的框架搭起来，要实现多少个功能，每个功能有多少个模块，每个模块又有多少个小的模块，画好了出一套文档，程序员拿到了做开发工作
接口文档 接口测试
3，编码时间阶段：源代码（白盒测试，黑盒测试）
a，确定想法做什么 b，怎么做，c，动手做
这一阶段我们测试对象是源代码（如果测试人员也会代码，那就是两个程序员，成本太高，）
如果可以的话就可以给客户用了
4，系统功能使用（测试阶段）：这一阶段测试对象是软件功能主体，当前行业做的最多的一种测试
相当于让测试人员充当客户，对功能主体进行验证，OK了，拿到市面上给客户用
总结：不要认为测试的对象就是软件，这是狭义的错误的，
软件本身有三个部分组成：
1，软件有一堆的功能指令，（关闭，最小化）功能说明书，使用人员要培训
2，默认的配置数据（拿到客户面前给客户看的时候第一次展示的内容，是对的）
3，一款软件从没有到有需要很多阶段，作为测试人员每个阶段都有要测的东西（测试需求文档，测试api文档，测试源代码，测试主体功能）
测试级别
软件的开发都会依据相应的开发模型，则测试级别指的就是在这个模型当中我们认为定义的开发步骤。其中对于测试来说我们最常见的一种级别分类如下：
1，单元测试（UT unit test）：在软件测试中单元指的就是组成软件最小的底层代码结构，一般就是类，函数，组件（当下的软件测试行业，不会可以要求测试人员对源代码进行测试，谁开发谁测试）
小区的单元，小模块进行测试
就是对底层的源代码进行测试，组成构成当前源代码最小的部分，
常见的有三种类型：类，函数，组件(不明白代码没事，找到集合，最小的组成部分)
不管界面多漂亮 ，只管底层的代码对不对，逻辑结果对比不对
2，集成测试（IT system ingertation test）：
将不同的多个单元模块组合在一起，然后验证它们之间沟通的“桥梁”是否能正常工作（换成人话：接口测试 ）
单元是最小部件，集成就时组合在一起，
例一：小汽车，雨刷，挡风玻璃。组合三米长的雨刷和挡风玻璃在一起不行了。
例二：两人没结婚前没事，一结婚在一起天天吵架
3，系统测试(ST system test)：这是当前行业做的最多的一种测试，有测试人员充当用户然后对软件的功能主体进行测试
4，验收测试：
核心：为了让用户为这个软件进行买单（不是为了挑毛病，）
例子：我是包工头，在外边几经周折接了一个小工程，前期需要投钱进去比如100万，把楼盖出来了，然后找让我盖楼的（托关系才接到的活）人来验收，看看我盖的怎么样，当我让他验收时是希望她找到毛病还是不希望。肯定是不希望。我不可能自己花了100万然后跟他说你给我挑挑毛病吧，那不是我有毛病吗
（1）α测试---内测（公司内部，测试开发在一起）
（2）β测试---公测（提问题，反馈，邮箱反馈，奖励）
（3）UAT（user acceptance test）测试---由客户派出本公司业务精通人员来使用该软件，从而对功能进行测试
客户花钱买软件，客户觉得你们懂技术但不一定懂我们的业务，所以客户要站在自己的业务需求角度，派出本公司业务精通人员来对软件进行使用测试（场景）
系统测试分类
1，功能测试：验证当前的软件主体功能是否可用
你告诉我好用不行 我得验证
2，兼容性测试：验证当前软件在不同的环境下是否还可以使用
Windouw /Linux，浏览器，客户端：（pad，电视，手机，电脑）
3，安全测试：验证软件是否只是能授权用户提供功能使用
银行卡，密码保护，次数限定
4，性能测试：
相对于当前软件消耗的资源，它的产出能力
性能：高大上。
例子：我作为一个人在这里需要扯着嗓子吼着给你们讲课，你可以有这么两个选项，
第一个：你让我一天吃三顿饭，我能给你吼一天，
第二种：你让我一天吃两顿饭，让我给你吼两天
对比一下，哪一个效率更高一些？第二种效率高一些，人还是我这个人，
总结：1234打游戏升级一样，对于刚入行 就做功能测试，是立身之本，然后做兼容，做安全，最后一步做性能测试。
常见的系统测试方法
一，按测试对象进行分类
1，白盒测试：这种测试的主体就是软件的底层代码，不会在意外在的界面是否ok，只要求底层功能实现，同时逻辑正确。
问你会不会，你可以说了解（不会就是了解哈~~）html，python，数据库等都了解了就会了
虽然现在可能都不会用哈，慢慢学哈
2，黑盒测试：这种测试就是指测试软件外在主体功能是否可用。
看不到里面只能看外在（登录，关闭，测试只能看到的，底层代码看不到）
3，灰盒测试：介于二者之间（接口测试）
先保证功能可用，在保证模块没问题。
4，上述三种方法当中的“盒”指的就是被测对象
二，按测试对象是否执行分类
1.静态测试：指的就是测试不执行
不给我软件，我怎么测啊？测文档啊，对着文档看网页界面
2.动态测试：将软件运行在真实的使用环境中进行测试
给我个小汽车，没问题，上路上跑两圈就测试了
三，按测试手段进行分类
1，手工测试：由测试人员手动的对被测对象进行验证，优点就是可以灵活地改变测试操作环境。
手机买回来就是拍拍照片打打电话测一测，但就是有的人喜欢在油锅里煮一煮，在冰箱里冻一冻，没问题，有人来操作的时候很灵活就可以改变，但工具不行------自动化
2，自动化测试：所谓自动化主要有两种
一种是自己写测试脚本，
估计现在很多同学心里想的是老师你快教我写脚本吧~~刚学完Java着急写点东西。
测试的脚本不是程序开发，不需要把所有的逻辑都搞定，这里你会发现测试的脚本无非就是调用接口，传值就可以了，这就是一个脚本了。
当然了如果你有能力可以自己写开发一套框架出来，去基于自己公司产品的流程测试框架出来，这也是脚本，但这个不是随随便便一个人就能做的，毕竟开发一款软件不是一个人就能做的，所以不用有挫败感，不用说你们写不出来，我也写不出来，这样心里是不是有安慰了
一种就是通过第三方的工具对被测对象进行测试。
第三方工具收费，所以如果可以自己写脚本 ，所以很多公司不做自动化测试。
优点就是可以高效率的去执行一些人工无法实现的操作
例子：12306，其中构建一个场景，我想测一下在同一时间，能同时容纳多少人去同时操作这个网站。登录功能，不是你一个人登陆吧，你怎么知道全国有多少人跟你一块去点登陆呢。
手工去测：那现在让你操作你最多能点多少用户登陆在电脑上，6个浏览器，都打开，最多十几个用户。但是这种测试无意义，淘宝12306如果连是个用户都扛不住，那就不用测了
用工具测试：帮你很容易的批量生成你想要数量的用户，做到人工无法完成的事情。
各有各的好处
软件质量
描述当前软件是否好用，在当前的软件行业里我们所采用的一套标准是基于iso组织制定的。需要我们记忆的就是软件质量的六大特性：
有点绕，其实就是这样一件事情，在行业里专门用于衡量软件质量好坏的一套标准，iso国际标准化组织出一套全世界都遵守的标准，只要达到这个标准，这款软件就是好的。
1.功能性：软件需要满足用户显示或者隐式的功能。
例子：淘宝 输入手机 结果显示出手机的相关信息
隐式：比如默认的排序，我只想简单的得到手机信息，，但是隐式信息会提供客户的体验
2.易用性：软件易于学习和上手使用
王者荣耀：为什么火？容易学习，操作简单，左边有个转盘右边有按键，
吸引用户：追求向上的心态，想着在圈子里排位靠前一些，所以就一直玩
3.可靠性：指的就是软件必须实现需求当中指明的具体功能
之你答应我这个软件中又是个功能，那么我使用时就得有这十个，有八个不靠谱。
4.效率性：类似于软件的性能。
下载：迅雷，百度网盘，旋风。同样网络环境下谁快谁效率高
5.可维护性：
要求软件具有将某个功能能修复之后继续使用的能力。
家里买了电视机，给了遥控器，有一天遥控器坏了，修好了，那么电视机可以继续使用。
6.可移植性：
当前软件可以从一个平台移植到另一个平台上去使用的能力。
总结：【功能靠用，功能可“移”】
例子:比如面试时，你往后端提了一个bug，但是后台开发人员说这不是bug。那么你要问 在什么情况下（软件环境使用情况下）不是bug。比如：6 2=8，开发说功能实现了，没问题不是bug，测试人员说，6 2结果8对话框弹出来后点完确定按钮，结束后框里的值没恢复到默认值。
从什么角度说服呢？从用户体验说太高大上。应该从软件质量标准中有个易用性来说
如果用户点完确定按钮数值1，2的值没有回复默认的话，用户会迷惑，刚才我有计算这个结果吗，他会觉得想要再次点击【求和】按钮，所以从用户的角度来讲他不易于用户的使用。所以至于怎么说得委婉动听就是随便了。这都是以后常见的与开发沟通的常见问题，而且也证明了测试的思想。
软件测试流程
1，需求分析
（1）理清楚我们需要设计的点是什么。
知道自己要测什么
（2）需求的来源：需求规格说明书(功能说明书)，API文档，竞品分析（同类产品他们有的功能我们有，他们不犯的错我么们也不能犯），个人经验
我怎么知道这个软件到底要测什么？依据需求的来源写出测试点。去哪找
2，设计用例/测试用例
（1）什么是用例？用例就是用户为了测试软件的某个功能而执行的操作过程
（2）设计用例是有方法的（等价类，边界值，判定表……）
3，评审用例:对当前的用例进行添加或者删除
4，配置环境
（1）环境：指的就是当前被测对象运行所需要的执行环境，作为测试人员需要具备配环境的能力
不会的话，百度，男问女，女问男，要培养自己的这种能力。定心丸：【一般情况下都会使用一键安装的集成环境】.
（2）环境分类：操作系统 服务器软件 数据库 软件底层代码的执行环境（.html能打开证明有这种环境，.jsp文件打不开证明没有安装所需要的环境（java））
数据库只负责用不负责优化，会一个就都差不多
5，执行用例
拿着设计好的去执行
（1）一般在执行用例之前我们会做一个冒烟测试 。这种测试的核心就是快速的对当前软件的核心功能或者主体执行流程进行验证。如果冒烟测试阶段有问题，则可以将此版本会退给开发。
电商类的网站：什么是最核心的功能？ 购物。会把最核心的功能快速的走一遍。
冒烟测试：烟冒完了很快就没了，
（2）如果冒烟测试通过那么才会开展全面的测试。
6，回归测试及缺陷跟踪
（1）比如在测试中找到了一个问题，告诉开发，开发说修复完了。能信吗？
回归测试指的就是当我们将某个缺陷提交给开发之后，由他们进行修复，修复完成之后需要测试人员再次对其进行测试【回归测试】
（2）缺陷跟踪：指的就是当测试人员发现某个缺陷之后需要一直对其进行状态的跟踪
7，输出测试报告
将当前的测试过程中产生的数据进行可视化的输出。方便其他人去查看。
假如今天身体不舒服去医院检查，检查一圈，回来医生告诉我回家等死吧，心里肯定不愿意，总得告诉我为什么，给我点依据吧~~~
8，测试结束
可能让你崩溃，测试都结束了，还算一个步骤吗？算！
应为现在很多产品都有很多版本，需要更写迭代，所以要把当前版本所产生的东西归档，
将整个测试过程中产生的一些文档进行整理归档，方便后续版本使用
软件架构
所谓的软件架构我们可以理解为是用来指导我们软件开发的一种思想。目前来说最常见的二中架构模式就是B/S C/S
B---browser 浏览器
C---client 客户端
S---server 服务器
生活中哪种是？
两种架构的比较
1.标准：相对于CS架构来说 BS架构的两端都是在使用现成的成熟产品。所以BS会显示的标准一些。
浏览器种类很多 但是固定的就那么几种，淘宝是不会自己开发浏览器的，qq微信等需要自己开发界面
2.效率：相对于bs架构来说cs中的客户端可以分担一些数据的处理，因此执行效率会高一些
打开淘宝界面时，你考虑这些数据是怎么来的吗，左侧的导航需要我们自己整理出来吗？不需要，都是淘宝服务器端处理的，你所看到的都是浏览器解析后呈现出来的。客户端只负责展示，服务器端做的。今天浏览器一关 ，明天再打开就没了。Cs架构不同，如果把网断了，在连上，东西还在
3. 安全：BS架构中的数据传输都是以HTTP协议进行的输出，而http协议又是明文输出，可以被抓包，所以相对于cs架构来说bs就显得不那么安全（相对来说，不是绝对的）
找个浏览器，打开看一下，别有用心的人
4.升级：假如淘宝要改版了，做什么能看到改版后的内容。刷新一下浏览器就行。怎么更新王者荣耀，下载升级
BS架构只需要在服务器端将数据进行更新，前台只需要刷新页面就可以完成升级，而CS架构当中必须要将两端都进行更新。
5.开发成本：相对于BS架构来说，CS当中的客户端需要自己开发，所以相对来说成本会高一些。
软件开发过程模型
1.瀑布模型：
是线性模型的一种，代码完成后有足够的时间测试。
强调早期计划：如果早期得第一步需求分析阶段做的到位，后期不会再有需求变更
改良：每个阶段都可以融入小的迭代，没问题了在进行下一阶段
2.快速原型模型
3.螺旋模型
测试模型
随着测试过程的管理和发展，测试人员通过大量的实践，从而总结出了不少测试模型，常见的V模型，W模型，H模型等。这些模型与开发紧密结合，对测试活动进行了抽象，成为了测试过程管理的重要参考依据
1.V模型
2.W模型
在需求和设计阶段也添加了测试工作
3.H模型
软件测试分类
黑盒测试：
又称数据驱动测试，完全不考虑内部机构和特性，只注重软件的功能需求（不管代码）
一，功能测试
1.逻辑功能测试
2.界面测试
3.易用性测试
4.安装测试
5.兼容性测试
二，性能测试
1.时间性能
2.空间性能
3.一般性能
4.稳定性测试
5.负载测试
6.压力测试
白盒测试：
把盒子打开研究里面的程序结构和源代码
静态测试/动态测试
随机测试：
针对重要功能新增加功能，以前发生过重大bug的模块进行二次测试，也叫探索测试，他可以结合回归测试来使用。
很有价值的一篇理论文章，对初级测试人员帮助极大。
,
