软件测试理论

软件测试的作用

1.通过测试工作可以发现并修复软件当中存在的缺陷，从而提高用户对产品的使用信心。

2.测试可以记录软件运行过程中产生的一些数据，从而为决策提供数据支持。

3.测试可以降低同类型产品开发遇到问题的风险

测试原则

指的就是执行测试工作时必须遵守的一些原则

1.测试证明软件存在缺陷：无论执行任何测试操作都只能证明当前软件存在缺陷

2.不能执行穷尽测试：某一些功能无法将所有测试情况都罗列出来，所以任何测试都有结束的时间

3.缺陷存在群集现象：对于软件功能来说，核心功能占20%，非核心是80%。在实际工作中，我们会集中测试20%的核心功能，所以这个部分发现缺陷的几率就会高于80%，因此我们就会遇到缺陷都集中在20%功能模块里的现象

4.某些测试需要依赖特殊的环境

5.测试应尽早介入:为了更多的发现和更好的解决软件中的缺陷，我们追求测试工作尽早的开展

6.杀虫剂现象：同样的一个测试用例不能重复执行多次，因为软件会对它产生免疫

7.不存在缺陷谬论：任何软件不可能是完美的。

测试对象介绍

对于当前的测试行业来说我们最经常测试的主体就是 软件（主体功能），但需要我们明白一个软件也不仅仅只有功能需要测试

我们可以将软件分为三个部分：功能集合+使用说明书+配置数据

对于一款软件来说从无到有需要不同的过程，我们可以将这个过程分为不同的阶段，然后每个阶段都会相应有测试对象

1.需求分析阶段：各种需求规格说明书。

2.软件架构设计：API接口文档（接口测试）

3.编码实现阶段：源代码（白盒测试、单元测试）

4.系统功能使用：软件功能主体（当前行业做的最多的一种测试：功能测试）

测试级别

软件的开发都会依据相应的开发模型，则测试级别指的就在这个模型当中我们人为定义的开发步骤。其中对于测试来说我们最常见的一些级别分类如下：

1.单元测试【UT unit test】：在软件测试中单元指的就是组成软件最小的底层代码结构，一般就是类、函数、组件（当下的软件测试行业，不会刻意要求测试人员对源代码进行测试）。

2.集成测试【IT  system ingertaion test】：将多个单元模块组合在一起，然后验证它们之间沟通的“桥梁”是否能正常工作（接口测试）

3.系统测试【ST system test】：这是当前行业做的最多的一种测试，由测试人员充当用户对软件的功能主体进行测试。

4.验收测试：（1）α测试---内测

                     （2）β测试---公测

                     （3）UAT（user acceptance test）测试---第三方客户派出业务精通的人员来使用该软件，从而对功能进行测试。

                     （4）验收测试的核心就是让用户 为当前软件“买单”

系统测试分类

1.功能测试：验证当前的软件主体功能是否可用。

2.兼容测试：验证当前软件在不同的环境下是否还可以使用。

3.安全测试：验证软件是否只是能授权用户提供功能使用。

4.性能测试：相对于当前软件消耗的资源 它的产出能力

常见的系统测试方法

一、按测试对象进行分类

1.白盒测试：这种测试的主体就是软件的底层代码，不会在意 外在的界面是否OK，只要求底层功能实现，同时逻辑正确。

2.黑盒测试：这种测试就是指测试软件外在 主体功能是否可用。

3.灰盒测试：介于二者之间（接口测试）

上述三种方法当中的“盒”指的就是被测对象

二、按测试对象是否执行分类

1.静态测试：指的就是测试不执行(审查源代码,技术要求较高)。

2.动态测试：将软件运行在真实的使用环境中进行测试。

三、按测试手段进行分类

1.手工测试：由测试人员手动的对被测对象进行验证，优点就是可用灵活的改变测试操作及环境。

2.自动化测试：所谓自动化主要有两种形式，一种是自己写测试脚本，另外一种就是通过第三方的工具对被测对象进行测试。

优点：高效率的去执行一些人工无法实现的操作。

软件质量

描述当前软件是否好用，在当前的软件行业里我们所采用的一套标准是基于ISO组织制定的。需要我们记忆的就是软件质量的六大特性：

1.功能性：软件需要满足用户显示与隐式的功能。

2.易用性：软件易于学习、便于上手使用。

3.可靠性：指的就是软件必须实现需求当中指明的具体功能。

4.效率性：类似于软件的性能。

5.可维护性：要求软件具有将某个功能修复之后继续使用的能力。

6.可移植性：从当前软件可以从一个平台移植到另一个平台上去使用的能力。

【功能靠用、效率可“移”】

软件测试流程

需求分析---设计用例---评审用例---配置环境---执行用例---回归测试及缺陷跟踪---输出测试报告(测试结果)---测试结束

1.需求分析

        （1）当前阶段的核心目的：梳理清楚需要设计的点是什么

        （2）需求的来源：需求规格说明书、API文档、竞品分析（同类产品）、个人经验

2.设计用例

        （1）用例就是用户为了测试软件的某个功能而执行的操作过程。

        （2）设计用例是有方法的（等价类、边界值、判定表、场景法、因果图）

3.评审用例

        对当前用例进行添加或者删除。

4.配置环境

        （1）环境：指的就是当前被测对象运行所需要的执行环境。作为测试人员需要具备配置环境的能力。【一般情况下都会使用一键安装的集成环境】

        （2）环境分类：操作系统+服务器软件+数据库+软件底层代码的执行环境

5.执行用例

        （1）一般在执行用例之前，会先做一个冒烟测试。冒烟测试的核心就是快速的对当前软件的核心功能或者主体功能执行流程验证。如果冒烟测试阶段有问题，则可以将此版本回退给开发。

        （2）如果冒烟测试通过，则才会开展全面的测试。

6.回归测试及缺陷跟踪

        （1）回归测试指的就是当我们将某个缺陷提交给开发之后，由它们进行修复，修复完成之后需要测试人员再次对其进行测试【回归测试】

        （2）缺陷跟踪：指的就是当测试人员发现某个缺陷之后需要一直对其进行状态的跟踪

7.输出测试报告

        将当前的测试过程中产生的数据进行可视化输出。方便其它人查看。

8.测试结束

        将整个测试过程中产生的文档进行整理归档，方便后续版本使用。

常见的软件架构

所谓软件架构可以理解为是用来知道软件开发的一种思想。目前来说最常见的两种架构模式

B/S架构、C/S架构

        B---browser  浏览器

        C---clent       客户端

        S---server     服务端

两种架构模式的比较

1.标准：相对于CS架构来说BS架构的两端都是在使用现成的成熟产品，所以BS会显示的标准一些

2.效率：相对于BS架构来说CS架构中的客户端可以分担一些数据的处理，因此执行的效率会高一些。

3.安全：BS架构当中的数据传输都是以http协议进行的传输，而http协议又是明文传输。可以被抓包，所有相对于cs架构来说BS就显的不那么安全【相对的】

4.升级：BS架构只需要在服务器端将数据进行更新，前台只需要刷新页面就可以完成升级。而CS架构当中必须要将两端都进行更新。

5：开发成本：相对于BS架构来说CS架构当中的客户端需要自己开发，所以成本相对来说会高一些。

浏览器基本介绍

1.浏览器是什么

        浏览器本质就是一款软件，安装在操作系统之上。一般给用户提供浏览网页的服务。

        目前来说我们会人为的将所有浏览器总结出一个所谓的五大生产厂商。

        【对于浏览器最核心的技术就是内核】

2.五大浏览器生产厂商

           IE              微软        trident

        Chrome       谷歌        blink

        Firefox         火狐        gecko

        safaril          苹果         webit

        Opera          欧朋        presto【现在已经放弃自己的技术，向chrome靠其】

常见的图片类型

1.jpg（jpeg）：一种可以高度保留图片色彩信息的图片格式。常见于 web端

2.png：此类型的图片透明可以实现透明

3.GIF：图片所占体积小，可以实现动图

4.psd：它是一种分层的图片。