测试基础知识

找实习工作的过程中总结了下测试基础知识，编程能力重要，测试基础同样重要，希望对大家有帮助

软件测试方法：静态测试和动态测试

                    白盒测试和黑盒测试

                    传统测试与面向对象测试

软件测试过程：单元测试，集成测试，系统测试，验收测试

按测试类型：功能、性能、界面、易用性测试、兼容性测试、安全性测试、安装测试

（单元测试：在编码过程中，对每个小程序单元测试）

（集成测试：将单元集成在一起后，可称为组件）

回归测试、冒烟测试、随机测试

（冒烟测试：是指在对一个新版本进行系统大规模的测试之前，先验证一下软件的基本功能是否实现，是否具备可测性。专门针对某一项功能的测试---主干功能）

测试流程：编写测试计划，编写测试用例，搭建测试环境，，实施测试，测试评估，测试总结。

测试计划：就是在测试实施之前确定测试对象，并对测试对象进行资源，时间，风险，测试范围，预算等方面的综合分析。

测试计划的内容：简介，项目说明，范围，测试手段和策略，项目通过和失败的标准，暂停/重启测试的标准，测试任务分配，职责等等

测试用例三要素：测试步骤，输入数据，期望结果

测试用例内容：项目名称，测试环境，预置条件，用例编号，测试步骤，输入数据，预期结果。

测试数据是写好测试用例的关键？

测试用例内容，写好测试用例的关键

功能测试，性能测试

黑盒测试（也称为功能测试或数据驱动测试）

黑盒测试分为：等价类划分法，边界值分析法，因果图法，决策表法，正交实验法，场景法，错误推测法，常用控件测试（文本框，按钮，单选按钮，复选框）（要知道各种方法的实际应用场景）

黑盒测试在程序接口进行测试，只检查程序功能是否按规格说明书的规定正常用，也被称为用户测试。

         集成测试/系统测试/验收测试：黑盒测试

黑盒测试与软件的实现过程无关，在软件实现过程发生变化时，测试用例仍可使用

黑盒测试用例的设计可以和软件实现同时进行，这样能够压缩总的开发时间

等价类划分法：有效等价类，无效等价类（计算1-100之间的和，登录注册对密码位数的要求）

设计一个新用例，使它能够覆盖尽量多尚未覆盖的有效等价类，重复该步骤，直到所有有效等价类均被用例覆盖

设计一个新用例，使它仅覆盖一个尚未覆盖的无效等价类，重复该步骤，直到所有无效等价类均被用例覆盖

三角形测试用例

题目：输入三个数a、b、c分别作为三边的边长构成三角形。通过程序判定所构成的三角形是一般三角形、等腰三角形还是等边三角形时。用等价类划分方法为该程序设计测试用例。

在三角形计算中，要求三角形的三个边长：A B C。

1、 当三边不可能构成三角形时提示错误，可构成三角形时计算三角形周长。

2、若是等腰三角形打印“等腰三角形”， 若两个等腰的平方和等于第三边平方和，则打印“等腰直角三角形”。

3、若是等边三角形，则打印：“等边三角形”。

4、画出程序流程图并设计一个测试用例。

（三角形问题复杂之处在于输入与输出之间的关系比较复杂）

一、等价类划分法：大多数从输入域划分等价类，此处可从输出域划分等价类，且为最简单的方法。有五种可能的输出情况，一般三角形，等腰三角形，等腰直角三角形，等边三角形，非三角形

R1={<a,b,c>:边为a,b,c的等边三角形}

R2={<a,b,c>:边为a,b,c的等腰三角形}

R3={<a,b,c>:边为a,b,c的等腰直角三角形}

R4={<a,b,c>:边为a,b,c的一般三角形}

R5={<a,b,b>:a,b,c构不成三角形}

程序流图

二、边界值：由于三角形的边可是整数，也可是小数，无需对长度测试，无需边界值分析。

三、因果图法：三角形的三条边输入值的组合

         条件：

                            C1:A>0

                            C2:B>0

                            C3:C>0

                            C4:A+B>C

                            C5:A+C>B

                            C6:B+C>A

                            C7:A=B

                            C8:A=C

                            C9:B=C

                            C10:A^2+B^2=C^2

                            C11:A^2+C^2=B^2

                            C12:B^2+C^2=A^2

         动作：

                            E1：非三角形

                            E2：普通三角形

                            E3：等腰三角形

                            E4：等边三角形

                            E5：等腰直角三角形

         中间结果：

                            B10：边范围正确

                            B11：可构成三角形

                            B12：存在两边相等

                            B13：三边两两相等

                            B14：存在两边平方和等于另一边平方和

百度答案：https://wenku.baidu.com/view/2a601f1714791711cc791776.html

因果图

应用场景：输入条件过多时，输入与输出之间的关系，防遗漏

                   自动售货机，三角形的问题

命题

有一个处理单价为5角钱的饮料的自动售货机软件测试用例的设计。其规格说明如下：若投入5角钱或1元钱的硬币，押下〖橙汁〗或〖啤酒〗的按钮，则相应的饮料就送出来。若售货机没有零钱找，则一个显示〖零钱找完〗的红灯亮，这时在投入1元硬币并押下按钮后，饮料不送出来而且1元硬币也退出来；若有零钱找，则显示〖零钱找完〗的红灯灭，在送出饮料的同时退还5角硬币。

分析

根据该命题，我们可以分析出，自动售货机的业务中一共存在5个条件和5个结果，分别是：

条件：

1.售货机有零钱找

2.投入1元硬币

3.投入5角硬币

4.押下橙汁按钮

5.押下啤酒按钮

结果：

1.售货机〖零钱找完〗灯亮       当售货机中没有零钱的时候就有亮红灯

2.退还1元硬币               当投入1元，而且售货机中没有零钱可找的时候

3.退还5角硬币                      当投入1元，而且售货机中有零钱可找的时候

4.送出橙汁饮料

5.送出啤酒饮料

因果图－画条件和结果

因果图－画简单关系

在画完空白的条件和结果之后，我们可以将题目中最直接和简单的因果条件标出

1、条件“有零钱”和结果“红灯亮”是一个“非”的关系，当“有零钱”的时候，红灯是不亮的，而当售货机中“没有零钱”的时候，红灯必须要亮的。

2、条件“投1元”和条件“投5角”是一个“E”的关系，这两个动作不可能同时发生，即同时投入1元钱和5角钱（不能同时为真）；但是我们允许即“不投入1元钱”也“不投入5角钱”（可以同时为假）。

3、条件“选啤酒”和条件“选橙汁”是一个“E”的关系，这两个动作不可能同时发生，即同时“选择啤酒”和“选择橙汁”（不能同时为真）；但是我们允许即“不选择啤酒”也“不选择橙汁”（可以同时为假）。

4、条件“选啤酒”和条件“选橙汁”对于程序处理过程是等价的，即二者无论是价格还是系统的处理方法都是相同的，因此这两个条件可以合并为一个中间节点。而且这两个条件之间使用“或”的关系。

5、注意，条件“投1元”和条件“投5角”不是等价关系，表面上看，他们都是“钱”，好像差不多，但是对于程序的处理过程确实完全不同的，“投5角”后完全不用判断当前售货机中是否有零钱（因为题目中规定所有的商品都是5角钱），而“投1元”就不行了。

因果图－送出商品

现在我们从结果的角度考虑，要想“出啤酒”或者“出橙汁”，从现实买卖中分析必须要有什么先决条件呢？是的，就是“你的钱要付清”，而且你一定要选择了“啤酒”或者“橙汁”才行。而在上面的已有因果图中，我们无法找到“钱付清”的因素，因此这时候我们可以试着再加一个中间节点，就叫“钱付清”吧。

要想获得选中的商品，则条件“钱付清”和条件“选啤酒/选橙汁”必须要同时成立，因此是“与”的关系。

因果图－应该找零钱

根据题意，当投入1元钱，而且又选中了某一种商品的时候，系统是需要找零钱的。而现有条件和结果中并没有涉及到“应该找零钱”这种情况，因此我们还需要增加一个中间节点“应该找零钱”。

条件“投1元”和条件（中间节点）“选商品”与结果（中间）“应该找零钱”是“与”的关系，即这两个条件必须同时满足。

因果图－能够找零钱

上面已经确定了“投入1元钱”并且“选商品”，系统应该找给客户5角钱，那么接下来就要看当前售货机中是否有零钱可找了，庆幸的是，存在“有零钱”的条件；

现在系统“应该找零钱”给客户，而且恰恰又“有零钱”找给客户，那么就可以确定系统“能够找零钱”给客户了，所以这里我们又可以增加一个中间节点“能够找零钱”。

条件“有零钱”和条件（中间节点）“应该找零钱”与结果“能够找零钱”之间是“与”的关系。

因果图－1元钱付清

现在已经确定客户“投入1元钱”并且“选商品”后，系统“有零钱”可找，那么紧接着就可以找钱给客户了。

条件“能够找零钱”和结果“找5角”是“恒等”的关系；

条件“能够找零钱”和结果（中间节点）“钱付清”也是“恒等”的关系；

因果图－5角钱付清

考虑完投入1元钱后系统的处理情况，我们再来看投入5角钱后系统是如何处理的。因为售货机中的全部商品都是5角钱的，因此就不存在找零的问题了，只要客户“投入5角”并且按下相应的商品选择按钮就好了。

所以，条件“投5角”和结果（中间节点）“钱付清”直接是“恒等”的关系。

另外，条件“投5角”和条件（中间节点）“能够找零钱”都代表金额的计算已经结束，即“钱付清”，因此条件“投5角”和条件（中间节点）“能够找零钱”与结果（中间节点）“钱付清”之间是“或”的关系。

因果图－退还1元

我们考虑完了投入5角钱及投入1元钱并找零后，最后在考虑一下退还1元钱的情况。毫无疑问，当投入1元钱，并且选择了某种商品的时候，如果当前售货机中没有零钱可找，那么只能退还用户这1元钱了。

因此，条件“没零钱”和条件“应该找零钱”与结果“找1元”之间应该是“与”的关系，而且我们的条件中关于零钱是用了肯定的描述，即“有零钱”，要想表示没有零钱，直接使用一个“非”关就可以了。

判定表

去除无效用例

合并判定表

决策表法

因果图和决策表的区别：

没有太大区别，因果图法强调的是使用图形来分析被测对象的特点，重点在于图形分析四个字。尤其对于逻辑结构比较复杂的测试对象，先用因果图分析，再用判定表来总结因果图，最后写出测试用例，这样下来会很直观，思路会很清晰。当然对于比较简单的测试对象，有时也可以忽略因果图，直接使用判定表。说白了，就是分析的两个步骤，你可以省略第一个步骤，直接做第二步，这些都根据实际的测试情况来运用。

适用情况：输入输出较多，输入之间和输出之间相互制约的情况条件比较多

优点：能把复杂问题按各种情况列举出来，简明而易于理解，可避免遗漏

缺点：不能表达重复执行的动作，例：循环结构

应用：

NextDate函数需求：

NextDate函数输入为month(月份)、day(日期)和year(年)，输出为输入后一天的日期。例如，如果输入为：1964年8月16日，则输出为1964年8月17日。要求输入变量month、day和year都是整数值，并且满足以下条件：

Con1   1≤month≤12

Con2   1≤day≤31

Con3   1900≤year≤2050

答案

条件为：month，day，year

操作为：day加1；day复位为1；month加1；month复位为1；year加1

考虑规则个数：

1．  D1：day值在1-27之间（包含边界值）

2．  D2：day=28

3．  D3：day=29

4．  D4：day=30

5．  D5：day=31

6．  M1：month有30天

7．  M2：month有31天（12月除外）

8．  M3：month是12月

9．  M4：month是2月

1. Y1：year为闰年

11．Y2：year不是闰年

这里有三个条件，每个条件的取值分别为5,4,2，因此规则的个数应为5*4*2=40

正交实验法

         就是使用已经造好的表格，正交表来安排实验并进行数据分析的一种方法。（计算表格化，应用好）

应用：平台参数配置或兼容性测试

与因果图的区别：因果图是同类输入当中各元素不可同时发生，而对于不同类的输入之间，每次必须要产生一种情况，这样我们可以将需求中的各项输入分别来组合一遍。这样测试会非常充分，但不可避免的会产生非常庞大的组合数字。

9：最大构成用例数

                     4：最大分类数

                     3：各分类下的最大元素数

具体实例见PPT（网站的兼容性，PowerPoint打印功能不同选择的结果）

场景法：运用场景对系统的功能点和业务流程进行描述。

一般包含基本流和备用流，从一个流程开始，通过描述要经过的路径来确定过程，经过遍历所有的基本流和备用流来完成整个场景。场景主要包括四种：正常的用例场景，备选的用例场景，异常的用例场景，假定推测的场景。

实际应用：银行ATM

设计用例场景：每个经过用例的可能路径，可确定不同的用例场景，从基本流开始，将基本流与备选流结合起来，得到用例场景。

         场景1.基本流

         场景2.基本流 备选流1

         场景3.基本流 备选流1 备选流2

         场景4.基本流 备选流3

         场景5.基本流 备选流3 备选流1

         场景6.基本流 备选流3 备选流1 备选流2

         场景7.基本流 备选流3 备选流4

         场景8.基本流 备选流4

设计步骤：1.根据说明写出基本流与备选流

                     2.根据基本流和各项备选流生成不同用例场景

                     3.对每一个场景生成对应的测试用例

                     4.对所有生成的测试用例进行复审，去除多余的

                     5.对每一个测试用例确定测试数据值

白盒测试（也称为结构测试或逻辑驱动测试）

白盒测试需要完全了解程序结构和处理过程，他按照程序内部逻辑测试，检验程序中每条通路是否按预定要求正常工作，也被称为程序员测试

单元测试：白盒测试

针对被测单元内部是如何进行工作的测试，根据程序的控制结构设计测试用例

特点：主要检查程序的内部结构、逻辑、循环和路径

白盒测试可分为静态测试和动态测试

静态测试：代码走查，代码审查……

动态测试：边界值测试（防止数组越界，int类型的范围），逻辑驱动覆盖……

逻辑驱动覆盖

可分为：语句覆盖，判定（分支）覆盖，条件覆盖，判定-条件覆盖，条件组合覆盖

语句覆盖

语句覆盖：比较弱的测试标准。选择足够的测试用例，使程序中每一个语句至少被执行一次

判定覆盖：比“语句覆盖”稍强的测试标准，选择足够的测试用例，使程序中每个分支至少被执行一次

条件覆盖：较强的测试标准。选择足够的测试用例，使得判定中每个条件获得各种可能的取值。

判定条件覆盖：更强。选择足够的测试用例，使得每个条件获得各种可能的取值，每个判定取到各种肯能的结果

条件组合覆盖：更更强。选择足够的测试用例，使得判定条件中的每个组合都至少出现一次。

基本路径测试法

      步骤：

1. 根据源程序画出程序流程图和控制流图
2. 根据控制流图计算题目的圈复杂度
3. 找出控制流图中的各条独立路径
4. 根据各条独立路径，设计测试用例

程序的环路复杂度即圈复杂度V(G)（即该程序独立路径的条数）

                   V(G)=边-节点+2

                   V(G)=节点+1

                   V(G)=G中区域的数量

软件缺陷

满足以下5个规则之一，称为缺陷

1. 软件未实现产品说明书中要求实现的功能
2. 软件实现了产品说明书中未要求的功能
3. 软件出现了产品说明书中指明不该出现的错误
4. 软件未实现产品说明书中虽未明确提及但却应该实现的功能
5. 软件不易使用，难理解，运行缓慢或者最终用户认为不好

软件缺陷-严重性

Fatal：致命错误，造成系统或应用程序崩溃，死机，系统悬挂，或造成数据丢失，主要功能丢失等

Critical：严重错误，主要指功能或特性没有实现，主要功能部分丧失，次要功能完全丧失，或致命的错误声明

Major：主要错误，这样的错误虽然不影响系统的使用，但没有很好的实现功能，没达到预期效果。如提示信息不太准确，或用户界面差，操作时间长

Minor：一些小问题，对功能几乎没有影响，产品及属性仍可使用

Suggestion：一些友好建议

缺陷级别定义

A类bug：

         Blocker级-阻塞、倒闭：必须立即解决，根据情况可以要求项目组立即发布版本，导致开发或测试无法进行，或程序无法运行

         严重级：导致系统崩溃，数据丢失，严重系统资源泄漏等，关键功能缺失或错误

B类bug：

         关键级：功能缺失或错误，界面关键信息的错误

C类bug：

         次要级：界面非关键信息的错误

D类bug：

         易用级：使用不方便的问题

缺陷优先级用A-D或者1-4表示，A（1）表示最高级，D（4）表示最低级

最高优先级：立即修复，停止进一步测试

次高优先级：在产品发布之前必须修复

中等优先级：如果时间允许应该修复

最低优先级：可能会修复，但也可能不修复

一般情况：严重程度高的，优先级高

特殊情况：不成正比

严重情况与优先级无必然联系

缺陷生命周期：测试人员提交缺陷报告，开发人员处理缺陷报告，测试人员回归测试，关闭缺陷报告

单元测试（使用白盒测试法）

需求分析说明书——>概要设计说明书——>详细设计说明书——>源程序代码

系统测试            集成测试          集成测试            单元测试

先静态检查代码是否符合规范，再动态检查

单元测试针对每个程序的模块主要测试五个方面：

         模块接口，局部数据结构，边界条件，独立路径，错误处理

模块接口：对模块接口的测试，检查进出程序单元的数据流是否正确。需再其他测试前进行。

         测试重点：

                   调用所测模块时，输入参数与模块的形式参数的个数，顺序，属性上是否匹配

                   所测模块调用子模块时，它输入给子模块的参数与子模块中的形式参数在个数，顺序，属性上是否匹配

                   是否修改了只做输入用的形式参数

                   全局变量的定义在各模块中是否一致

注：主要关注单元中的输入和输出

局部数据结构

         测试模块内部的数据是否能保持完成性，包括内部数据的内容，形式，相互关系不发生错误。

         常见错误：

                   不正确或不一致的类型说明

                   错误的初始化或默认值

                   错误的变量名，如拼写错误或书写错误

                   上溢，下溢或者地址错误

         注：主要关注与被测单元内部相关的数据的类型

路径测试

     针对程序路径进行测试，尤为重要。主要关注由于计算错误，不正确的判定或不正常的控制流而导致的错误

常见问题：

     误解的或不正确的算数优先级，混合模式的运算，错误的初始化，精度不够精确，表达式的不正确符号表示，不正确的或不存在的循环终止，当遇到分支循环时不能退出，不适当的修改环境变量

主要关注：程序的逻辑分支问题

边界条件

     采用边界值分析法设计测试用例，重点关注程序边界处

注：主要针对程序中的边界问题

出错处理

     重点关注模块在工作中发生错误时，出错处理设施是否有效。

常见错误：对运行发生的错误描述难以理解

                     所报告的错误与实际遇到的错误不一致

                     出错后，在错误处理之前就引起系统的干预

                     例外条件的处理不正确

                     提供的错误信息不足，以至于无法找到错误的原因

注：主要针对程序中的错误提示

单元测试的执行过程

单元测试时，如果模块不是独立的程序，需要设置一些辅助测试模块

辅助测试模块类型：

         驱动模块：用来模拟被测模块的上一级模块，相当于被测模块的主程序，用来接收数据，将数据传给被测模块，启动被测模块，并打印出相关结果

          桩模块：用来模拟被测模块工作过程中调用的模块，他们一般只进行很少的数据处理

如何进行单元测试或白盒测试：

     直接使用mian函数调用测试代码

     借助测试工具执行测试代码

单元级测试工具：C++Test，JUnit，NUnit          

集成测试

测试内容：单元间的接口，及集成后的功能

重点关注：数据穿越接口是否丢失

                     一模块是否会破坏另一模块的接口

                     子功能组装是否达到所要求的主功能

          全局数据结构是否出问题

                     误差积累问题

黑盒+白盒=测试技术

非增量式+增量式=测试形式

非增量式测试：采用一步到位的方法来构造测试

优点：节省时间

缺点：一次集成模块较多时，容易出现混乱

         故障定位和纠正困难

         新旧故障混杂，难上加难

增量式测试：采用逐步集成方法实现测试

增量集成测试的三种方式：

自顶向下增量式测试：深度优先，广度优先

主控模块：即关键模块

主控模块特征：（至少具备其一）

     满足某些软件的主要需求

     在程序的模块结构中位于较高层次（高层控制模块）

     较复杂，较易发生错误

     有明确定义的性能要求

（在回归测试中也应集中测试关键模块的功能）

自顶向下集成测试过程：

     主控模块作为驱动模块，根据集成方式，下层桩模块一次一次被逐步替换为真正的模块

     在模块集成时必须进行单元测试

自顶向下集成测试方式：

     深度优先：首先集成在结构中的一个主控路径下的所有模块

                            主控路径选择任意

     广度优先：首先沿着水平方向，把每一层中所直接隶属于上一层的模块集成起来，直到底层。

自底向上增量式集成

混合增量式测试：自顶向下测试+自底向上测试

常见的两种混合增量式测试方法：

     衍变的自顶向下：首先对输入输出模块和引入新算法模块的测试

     自底向上-自顶向下：含读操作：自底向上，含写操作：自顶向下

非增量式测试：先分散再集中

         若在模块接口处存在错误，只在最后集成测试时一下子暴露，修改难度大

增量式测试：逐步集成和测试

         差错分散暴露，一些模块得到较多次的考验

不同集成方式方法的比较

自顶向下增量式测试：

     优点：自然的做到逐步求精，开始就能看到系统的框架，发现上层接口错误，不需要驱动模块

     缺点：需要提供桩模块，低层关键模块中发现错误较晚，在输入/输出模块接入系统以前，在桩模块中表示数据有些困难

自底向上增量式测试：

     优点：工程实践中常用的方法，可发现低层模块错误。由于驱动模块并模拟了所有要调用的参数，即使数据流并未构成有向非环状图，生成测试数据也无困难。

     缺点：直到最后一个模块被加进去之后才能看到整个程序（系统）的框架

系统测试（由黑盒测试工程师做）

将整个软件系统作为一个整体来测试，包括对功能，性能等，以及计算机硬件，某些支持软件，数据和人员等系统元素结合起来，在实际运行环境下对软件进行测试。

纸杯测试

功能测试：纸杯是盛水的，看是否能盛水，能不能盛热水，是否漏水，看容量是否符合需求规格说明书。（系统测试阶段主要是验证开发的程序是否满足了需求规格说明书的要求，所以此时应该对着需求规格说明书进行验证，看功能是否满足）        

界面测试：若纸杯是新浪委托生产的纸杯，那么最后界面上是钻石牙膏则不行

易用性：纸杯是否适合用户使用

性能测试：检查纸杯耐热程度等

兼容性：现在倒水，倒热水无问题，那么如果有倒可乐的需求，是否可以倒可乐

安全性：纸杯用料是否环保，绿色，不能包含有害物质，不可用废书废报纸生产纸杯

可移植性

其他……

手机测试：

        发烫不发烫，发烫后会产生什么有害物质吗。。。

常用工具软件测试：

         在Windows上，Linux上是否可使用

系统测试类型：功能测试，性能测试，界面测试，易用性测试，兼容性测试，安全测试，安装测试，文档测试，国际化/本地化测试

功能测试：主要是对产品的各个功能点进行验证。根据需求规格说明书和功能测试用例，逐项测试，以检查产品是否达到用户要求

系统阶段的功能测试主要是验证功能是否实现

         系统测试阶段设计测试用例的方式一般有：通过测试，失败测试，业务测试

                   通过测试：设计一批用例，根据我设计的测试用例，测试后是通过的

                   失败测试：设计一批用例，根据我设计的测试用例，测试后是是失败的

                   失败测试的四种输入类型：

                            输入非法数据、输入字符集、输入使缓冲区溢出的数据、输入默认值

                   业务测试：要保证重点去验证我的主要流程（例：下定单时，加购物车，付款等的流程）

安全性测试：检查系统对非法侵入的防范能力

         目的：检测系统时安全的，不受非法干扰。（测试者扮演试图攻击系统的角色）

         跨站点脚本攻击（简称XSS）

         SSL协议位于TCP/IP协议与各种应用层协议之间，为数据通讯提供安全支持

         可手工执行的测试：

                   输入的数据没有进行有效的控制和验证

                   用户名和密码

                   直接输入需要权限的网页地址可以访问

                   上传文件没有限制

                   不安全的存储

                   操作时间时效性

         借助工具进行的测试

                   不安全的对象引用，防止XSS攻击

                   注入式漏洞（SQL注入）

                   传输中与存储时密码没有加密，不安全的通信

                   目录遍历

                  XSS攻击：恶意攻击者往Web页面里插入恶意HTML代码，当用户浏览该页之时，嵌入其中Web里面的HTML代码会被执行，从而达到恶意用户的特殊目的。

Http请求为四步：

1.浏览器与服务器建立连接

2.浏览器向服务器发出请求

3.服务器对请求做出应答，发送给浏览器

4.数据传送完毕，关闭连接

其中重要的是第二步，发送信息中含有请求头、普通头、Http请求头、实体头、实体

而Http请求头中，包含有多种请求方法：如Get、post、Head、put、delete、connec、tracet等

重要的是get、post、head

Get：请求指定的页面信息，并返回实体主体

Head：只请求页面的首部

Post：从客户机向服务器传送数据，在要求服务器何CGI做进一步处理。主要用于发送Html文本中form的内容，让CGI程序处理

然后服务器返回状态，中间状态码表示了不同返回结果

1开头为消息响应类、2表示请求被成功处理，3表示请求被重定向，4表示客户请求有错，5表示服务器不能满足请求

具体可以参考Http协议分析

界面测试（UI testing）：第一印象，愉悦，向导，吸引，标准

第一印象：政府网站一般红色主题为背景，庄严的，儿童网一般比较可爱，政府网无法和儿童网界面交换

  吸引：好的一个产品好的一个界面，京东，当当，展现当前新的活动，通过活动吸引你

  向导：引导你在哪个位置，怎么去另一个界面

  设计产品时考虑大众的想法

  百度首页觉得不能出现中国移动，Google的logo

         思考范围

                   风格（主色调，背景），与诉求方保持一致

                   正确性（标志，文字，图片，弹出信息）

             一致性（单个页面，多个页面），在一个页面上改了一图片，在其他页面上的相应图片也改了

                   合理性，美观协调

易用性测试

         从软件的使用合理性和方便性等角度对软件系统进行检查，来发现软件不方便用户使用的地方（易理解，易学习，易操作，吸引性）

         饮水机：颜色指示热水和冷水（还要有文字指示），饮水机出水方式，

         推拉门：门打开的方式要符合人们日常生活习惯，最好在门上贴上开门方法

         手机指纹识别，指纹识别位置，手机屏幕尺寸，是否可单手拿持

         登录软件是否可以选择记住密码，方便登录

         百度有导航，分类，可以方便的选择自己想要的内容

         qq中有好友分组，搜索功能，方便寻找好友

         输入用户名，输入密码时两次密码不一致会立即提醒

易用性：安装易用性测试，功能易用性测试，界面易用性测试，辅助系统易用性测试

安装易用性测试：安装的自动化程度测试，安装选项的设置，安装过程中断的测试

功能易用性测试：

界面测试：控件测试：

兼容性测试：同一网站可在不同浏览器上方便的使用

                            Bugfree可以导出htm形式，Excel等

兼容性测试是指测试软件在特定的硬件平台上，不同的应用软件之间，不同的操作系统平台上，不同的网络等环境中是否能很好的运行的测试

兼容测试的作用：

         兼容性测试能进一步提高产品质量

         兼容性测试能是软件与尽可能多的其他软件“和平共处”，尽可能的达到平台无关性

         兼容性测试能尽可能的保证软件存在的价值，他是衡量一个软件质量的重要指标

         兼容性测试能使软件产品的市场更广阔

配置测试：指验证在不同的硬件配置和软件配置下，应用程序能否正常工作

目的：能保证软件在其相关的硬件上能够正常运行

核心：使用各种硬件来测试软件的运行情况

配置测试关注点：硬件兼容性测试，与整机兼容，与卡板及外部设备的兼容性

兼容性测试关注：向前兼容，向后兼容，不同版本间的兼容，标准和规范，数据共享兼容

向前兼容：指可以使用软件的未来版本（office2003还可以打开office2007）

向后兼容：指可以使用软件的以前版本（office2007还可以打开office2003）

不同版本之间的兼容：指要实现测试平台和应用软件多个版本之间能够正常工作

         用例选择原则：流行程度，类型，生产商，年限

         操作系统/平台兼容

         应用软件之间的兼容

         不同浏览器之间的兼容

         数据库兼容

         软硬件配合兼容

数据兼容性：指要在应用程序之间共享数据，他要求支持应遵守公开的标准，允许用户与其他软件无障碍的传输数据

性能测试 是通过自动化的测试工具，来模拟多种正常，峰值以及异常负载条件来对系统的各项性能指标进行测试

时间性能：软件的一个具体事务的响应时间

空间性能：软件运行时所消耗的系统资源

CPU利用率，内存占有率

性能测试分类：一般性能测试，可靠性能测试，负载预测试，压力测试，稳定性测试，大数据量测试，配置测试

一般性能测试：验证软件在正常环境和系统条件下重复使用时是否还能满足性能指标，如运行速度，响应时间，占有系统资源等，不施加任何压力。

C/S B/s

可靠性测试（稳定性测试）：从验证角度出发，检验系统的可靠性是否达到预期的目标，同时给出当前系统可能的可靠性增长情况。即连续运行被测系统，检查系统运行时的稳定程度（24*7方式）（只背一袋大米，去操场跑圈，看多久累到）

负载测试：通常让被测系统在其能忍受的压力的极限范围内连续运行，来测试系统的可靠性。

压力测试：持续不断的给被测系统增加压力，直到系统压垮位置，用来测试系统所能承受的最大压力（每天有十万用户同时访问京东，京东CPU达到80%临界值，之后继续增加用户，直到服务器被压垮）

回归测试

回归测试一直贯穿在实施过程中

对软件的新版本的测试时，对新版本进行重新测试，这时的测试不仅是验证被修复的软件缺陷是否被解决了，还要保证以前所有运行正常的功能依旧保持正常，而不受到这次修改的影响。

回归测试应关注两方面：1.在上一版本提交给开发的问题，开发说在新的版本已修复，要验证开发是否修复

  2.验证每一个版本里主要模块的功能是否未受到破坏

执行方式：人工测试+自动化

三种不同类型的测试用例：能够测试软件的所有功能的代表性测试用例

                                                        针对修改过的软件成分测试（最不可取）

                                                        专门针对可能会被修改而影响软件功能的附加测试

回归测试有时也被称为冒烟测试

冒烟测试：先验证主要功能是否实现

回归测试用力选择

回归测试基本过程：

1. 识别出软件中被修改的部分
2. 从原测试用例库T中，排除所有不再适用的测试用例，确定那些对新的软件版本依然有效的测试用例，其结果是建立一个新的测试用例库T0
3. 根据一定的策略从T0中选择测试用例，测试被修改的部分
4. 如果必要，生成新的测试用例集T1，用于测试T0无法充分测试的软件部分
5. 用T1执行修改后的软件

验收测试

验收测试是在系统测试之后，以用户测试为主，或有测试人员等质量保障人员共同参与的测试，是检验软件产品质量正式交给用户使用的最后一道工序

验收测试中以功能测试为主，与用户协商什么时候开展

步骤：编写测试计划，筛选测试用例，执行用例记录结果，分析测试结果，提交测试报告。

项目软件验收：通知用户方选派验收测试人员；测试部门准备相关文件供测试参考，如需求分析文档，设计说明，测试计划，用户手册，用户确认测试报告等；测试部门负责安装现场软件，建立周边环境，并通知测试现场所在单位的IT部门有关测试进行的时间及有何特殊要求

产品软件验收：

Alpha测试（内部测试）：软件开发公司组织内部人员模拟各类用户对即将面世的软件产品进行测试，试图发现错误。由用户，测试人员，开发人员等共同参与的内部测试。

Beta测试：内测之后的公测，即完全交给最终用户测试。软件开发公司组织各方面的典型用户在日常生活中实际使用Beta版本，并要求用户报告异常情况、提出批评意见。

验收测试技术：黑盒测试，易用性测试，静态测试

Web网站的特点

测试方法：功能测试，性能测试，可用性测试，兼容性测试，安全测试，界面测试

功能测试：链接测试，表单测试，Cookies测试，功能需求测试，数据库测试等等

性能测试：压力测试，负载测试，可靠性测试

（通过 Cookie 和 Session 技术来实现记录访问者的一些基本信息，Cookie 是由 Web 服务器保存在用户浏览器上的小文本文件，它包含有关用户的信息）、

兼容性测试：硬件测试，平台测试，数据测试，浏览器测试，分辨率测试

安全性测试：登录，超时限制，用户权限，日志文件，SQL注入，目录设置，XSS

链接测试内容：

                   超链接本身言简意赅，具有可读性

                   定期检查内部链接

                   设计出友好提示界面

                   （链接是否存在，是否有孤立的页面，页面是否存在）

链接测试阶段：必须在集成测试阶段，即整个web网站的所有页面开发完成之后

什么是导航？

                   导航描述了用户在一个页面的操作方式，在不同的用户接口控制之间，例如按钮，对话框，列表和窗口等，或在不同的连接页面之间

导航测试的内容：

         导航是否直观；

         Web系统的主要部分是否能通过主页访问

         Web系统是否需要站点地图、搜索引擎或其他的导航器帮助；

         测试web系统的页面结构

         导航条，菜单，链接是否一致

         各种提示是否准确，确保用户凭直觉就知道是否还有内容，内容在什么地方

         最好让用户参与导航测试，效果更好

错误示例：

1. 导航栏内容位跟随操作动态更新

1. 导航条目排列混乱

现象1：“退出登录”通常应排在导航栏最下端，放置位置不合适

现象2：列表相近的栏目应集中导航，方便操作。将岗位、用户和角色的导航条目排列混乱

导航测试要点：

方便快捷的访问用户需要的信息

无论在哪个位置都可以清楚地知道用户所处再web应用系统的位置

逻辑结构清晰，层次分明

容易返回上一状态或主页

测试基础知识（白盒测试，黑盒测试，测试用例，功能测试等等）