软件测试入门

入门

一，测试理论

测试方法：比如 黑盒测试、白盒测试、自动化测试

测试类型：功能测试、性能测试、兼容性测试、压力测试等

测试流程：
1.需求分析
2.编写测试用例
3.评审测试用例
4.搭建测试环境
5.等待开发提交测试包
6.部署测试包
7.冒烟测试(对软件主体基本功能进行基本测试)
8.执行测试用例
9.BUG跟踪处理(提交及回归BUG)
10.N轮之后符合需求
11.测试结束.

测试用例怎么写：等价类、边界值、因果图等
测试常识：测试是无穷无尽的

二，测试工具

抓包工具fiddler，接口工具postman，自动化工具和性能工具jmeter

三，http知识

软件的数据如何传输，前后端如何交互

四，数据库知识

CRUD

五，Linux服务器

六，测试内容

1，接口测试
每个接口可能有多个输入参数，每个参数有 “典型值”、“边界值”、“异常值”之分，根据接口的定义，可以推断某种输入应当产生什么样的输出。输出包括函数的返回值和输出参数。 同时要观察是否有程序语句从来没有被执行过，特别留意函数体内的错误处理程序块。
2，路径测试
路径测试就是测试程序的流程路径，想遍历全部路径几乎是不可能的，不测试或者胡乱找几条路径测试却又不行，输入与对应的输出之间的路径是唯一的。由于接口测试时的输入要有代表性的，因此相应的路径也具有代表性，制定的路径测试检查表应该包括：数据类型、变量值、逻辑判断、循环、内存管理、文件I/O、错误处理。
3，功能测试
功能测试的基本方法是构造一些合理输入（在需求范围之内），检查输出是否与期望相同。有两种比较好的测试方法：等价划分法和边界值分析法，等价划分是指把输入空间划分为几个“等价区间”，在每个“等价区间”中只需要测试一个典型值就可以了；边界值测试法是对等价划分法的补充。除了典型值外还要用边界值作为测试用例。
4，健壮性测试
健壮性是指在异常情况下，软件能正常运行的能力。它有两层含义：(1)容错能力，容错性测试通常构造一些不合理的输入来引诱软件出错；(2)恢复能力，恢复测试重点考察系统能否重新运行、有无重要的数据丢失、是否毁坏了其它相关的软件硬件。
5，性能测试
性能测试即测试软件处理事务的速度，一是为了检验性能是否符合需求，二是为了得到某些性能数据供人们参考，有时人们关心测试的“绝对值” ，有时关心测试的“相对值” 。
6，用户界面测试
绝大多数软件拥有图形用户界面，图形用户界面的测试重点是正确性、易用性和视觉效果，在评价易用性和视觉效果时，主观性非常强，应当考虑多个人的观点。
7，信息安全测试
信息安全性是指防止系统被非法入侵的能力，既属于技术问题又属于管理问题。主要有如下步骤：(1)为非法入侵设立目标、(2)邀请一些人扮演黑客，让他们想尽办法入侵系统，实现“目标”(3)如果有人成功了，请他详述入侵的过程。
8，压力测试
压力测试也叫负荷测试，即获取系统能正常运行的极限状态。 主要任务是：构造正确的输入，使劲折腾系统却让它刚好不瘫痪。 压力测试的一个变种是敏感测试，敏感测试目的是发现什么样的输入可能会引发不稳定现象。
9，可靠性测试
可靠性是指在一定的环境下、给定的时间内、系统不发生故障的概率。软件可靠性测试可能会花费很长时间。 比较实用的办法是，让用户使用该系统，记录每一次发生故障的时刻。计算出相邻故障的时间间隔，注意要去掉非工作时间。然后统计出不发生故障的“最小时间间隔”、“最大时间间隔”和“平均时间间隔”。
10，安装/卸载测试
目前市面上有非常流行的、专门制作安装/卸载程序的一些工具，如Install Shelled。主要的测试工作是：(1)至少在标准配置和最低配置两种环境下测试；(2)如果有安装界面，应当尝试各种选项，如选择“全部”、“部分”、“升级”等。

七，软件测试步骤

测试的按照以下步骤进行：

1，模块测试(单元测试)
模块测试主要发现的往往是编码和详细设计的错误，目的是保证每个模块作为一个单元能正确运行；
2，子系统测试
子系统测试把经过单元测试的模块放在一起形成一个子系统来测试，着重测试模块的接口。
3，系统测试
把经过测试的子系统装配成一个完整的系统来测试，发现的往往是软件设计中的错误，也可能发现需求说明中的错误。不论是子系统测试还是系统测试，都兼有检测和组装两重含义，通常也称为集成测试。
4，验收测试(确认测试)
验收测试是在用户积极参与下进行的，而且可能主要使用实际数据(系统将来要处理的信息)把软件系统作为单一的实体进行测试进行测试，它发现的往往是系统需求说明书中的错误
平行运行
同时运行新开发出来的系统和将被它取代的旧系统，然后比较新旧两个系统的处理结果。平行运行可以在准生产环境中运行新系统而又不冒风险，同时用户能有一段熟悉新系统的时间，用户可以趁这段时间验证用户指南和使用手册之类的文档。以准生产模式对新系统进行全负荷测试，可以用测试结果验证性能指标。

八，项目及测试报告

github：
https://github.com/wangsen111111/Testing-personal-blog

一，软件测试的介绍和分类

(1)软件测试是什么？

(2)软件测试的分类

按方法分类

黑盒测试（不透明的盒子）：只检查输入和输出即可→外部暴露出来的功能能够实现，不关注原理
白盒测试（透明的盒子）：通过检查内部的结构看对不对（对内部逻辑结构进行测试，通过逻辑的覆盖率来判断测试是否有效）→直接看代码写的对不对
灰盒测试（半透明的盒子）：介于黑盒与白盒之间（或结合两者）

按方向分类

功能测试：测试功能 能不能做
性能测试：测试性能（高并发 承载量）功能能做多好
压力测试：逐渐增加模拟用户数量，发现瓶颈（发现软件的性能瓶颈）
负载测试：持续保持高强度的工作能维持多长时间
举重：压力测试：可以举多重
负载测试：可以举多久 一般为：峰值的80%~90%
并发测试：同时做一件事会不会出错
安全测试：测试安全 防止黑客攻击

按阶段分类

单元测试：针对代码块（方法、函数、类）

集成测试：把代码块连接起来（接口）

系统测试：功能、性能、安全、兼容性、易用性、稳定性、UI……

兼容性（WEB-浏览器 APP-andriod-iOS）
     同一个网站在不同浏览器上是否能使用
易用性（用户体验）

稳定性（可归于性能测试）
   7*24一直使用这个软件，看会不会崩溃
UI（界面-好不好看，设计图比对）

验收测试：系统测试通过之后

按对象分类

按状态分类

(3)其他

冒烟测试：测试前的测试→是否具备可测试性

回归测试：测试发现很多bug，告诉开发发现很多问题，让开发去改，开发修改完后，检查提交给开发的bug有没有修改完成

α测试：内测

β测试：公测

(4)互联网公司的研发团队结构

二，软件的研发模型和测试流程

(1)研发管理模型

1，瀑布流

从上往下，步骤与步骤之间是相互独立的。

好处：上下级分明，必须要完成第一步才能完成第二步。

缺点：不变通

2，V字型

左边是开发的工作，右边是测试的工作
好处：测试和开发的工作有了一一对应的关系
缺点：还是从上往下

3，W字型(双V字型)

左边的V是开发做的事，右边的V是测试做的事
两个V一一对照
效率比较高
测试和开发工作同步

这三者都需要测试

4，敏捷模型

特点：
高效的工作、及时的沟通、日报、白板、站立会、集中办公
日报：每天写一个工作日报
白板：工作进度，及每天工作任务
站立会：

(2)测试流程

1，需求分析阶段

产品原型：

学习业务流程：(金融、银行……)
拿到产品原型后，看它每一个功能实现
提取功能点：
从大到小把它的功能写出来
模块（以产品原型举例）：首页、发现、下载、我的；首页又可以划分：推荐、课程、路径、实战……
找到最小的功能，列出来（树状结构）：
例子：

编写需求分析说明书

转换为文档
··没有需求怎么办
参考市面上已经成熟的同类型的产品的实现

2，测试设计阶段（文档阶段）

测试计划 测试方案 测试策略

5W1H分析法：

测试计划： 5W1H：what where when who why how


一个完整的测试计划模板：
https://blog.csdn.net/weixin_43664254/article/details/89239052

测试用例

测试方法用来设计测试用例

1，等价类 找出有代表性的值

通过少量的数据代表大量的数据
-无效等价类（找不是有效值中的） 如：0 200.01
-有效等价类（找出有效值中的有代表性的数据）
如： 0.01 0.02 200
199.99 99.99（0.01，＞0.01的数，200，＜200的数，中间值）

2，边界值

比如微信红包→￥0.01-200
伪代码：

3，场景法(用户)

测试用例模板

重要级：在有限的时间里挑出重要级高的先测试

测试用例练习

3，测试执行阶段

回归测试：检查已经知道的BUG是否被修改

4，测试总结阶段

(3)BUG的管理

1，BUG的管理平台/系统/工具

禅道：
https://demo.zentao.net/bug-browse-3.html
禅道提BUG

附件：佐证确实有个BUG 截图等

2，BUG的六要素

回归测试：
版本1→版本2：迭代
会在版本2上做回归测试（在版本2上去检查在版本1上发现的问题有没有被解决）

3，BUG的生命周期

在解决BUG之后，如果回归测试还存在，就激活BUG。
如果开发认为不是BUG，就讨论。
BUG彻底解决了就关闭

4， BUG的状态

(4)版本迭代

-随着时间/测试次数多推进，会发布很多版本，其中的版本号是不断叠加的

-增量测试
   只测试已知的有变化的功能（但是该回归的还要回归）
-全量测试
   测试软件的所有功能（增加了功能之后要把所有功能都测试一遍）

(5)评审（检查测试用例）

同行评审
小组评审
部门评审
项目评审
第三方评审
邮件评审

(6)测试应用

1，测试应用

2，软件结构区别：(一个需要安装，一个不需要安装）

(7)测试应用测试报告的编写

三，测试用例的编写

(1)前置知识点及常用术语

软件的相关概念

-软件：数据、程序、文档的结合
-测试时操作数据，程序是测试的主体，文档是工作时的可视化（测试用例是文档的一部分）

软件测试基础

-软件测试是以满足需求为目的保证软件质量的一系列的手段。

测试流程

-需求分析→计划指定→用例编写与执行→对测试结果的分析报告

测试生命周期

-测试计划→测试设计→*测试开发（测试用例的编写属于测试开发）→测试执行→测试评估

常用术语

按软件测试的手段划分

    黑盒：把软件比做黑色的盒子，不知道盒子里面的内部结构，只能通过外面暴露出来的接口、功能进行测试

    灰盒：把软件比做半透明的盒子，可以看到内部少量的东西，可以通过外面暴露的功能和盒子内部的数据进行对比，得出测试结论。

e.g.测试订单生成的功能
可以通过软件上生成的订单和数据库里的数据进行对比，验证是否一致。
    白盒：把软件看成一个透明的盒子，通过观察内部的结构直接推敲出软件是否符合需求（三者中计数难度最高的）

按软件测试方向划分

    功能：验证软件是否符合用户提出的表面需求

    性能：测试一个软件的工作效率

    安全：测试软件是否能够保护用户的信息

按测试点划分

    兼容性：测试软件在不同平台上的表现

    易用性：测试软件是否友好，满足用户的使用习惯

    UI元素：检查界面的布局是否一致、美观

(2)测试用例

测试用例是什么

（在测试时按照测试用例的描述进行操作的，规范每一步都输入输出，对照判断是否满足需求。通过测试用例和需求的一一对照，确定测试是否能够覆盖需求，是否有遗漏）

    -测试工作的核心

    -一组在测试时输入输出的标准

    -软件需求的具体对照

测试用例有什么作用

  -检验软件是否满足客户需求（测试用例是以需求为基础生成的）

    -体现一个测试人员的工作量

    -展现测试用例的设计思路

测试用例包含哪些内容

 -用例编号

       每一个编号都是唯一的，可以用简单的数字来编写，也可以带上是做什么的，e.g.xxxx_001。

    -用例名称

       用例的名字，设计要求。要求用最少的字去描述，言简意赅。

    -测试背景

       测试用例是属于哪一个项目的，用例是测什么的

    -前置条件

       执行这条测试之前应该满足什么条件，e.g.测试登录要求账号密码是注册了的

    -优先级

       优先级和重要级没有绝对的关系，e.g.周末计划出去玩，出去玩的优先级最高，突然公司要求加班（重要级）

    -重要级

    -测试数据

       在测试时输入的数据，e.g.登录功能，账号密码就是登录数据。

       有些测试用例是不需要用键盘输入值的，也是有测试数据的，只是没有明确写出来（鼠标的操作也属于数据）

    -测试步骤

    -预期结果

       每一步操作对应的现象，e.g.输入正确的账号密码，预期结果就是登录成功

    -实际结果

       在执行测试的时候出现的实际的状况，e.g.输入正确的账号密码，登录失败/成功/网络异常（满足需求或者功能有问题）

    -备注

       特殊情况

(3)测试用例编写流程

需求分析：客户需要的东西和对那个东西的要求

 -业务需求：关注系统是否满足业务（购物？银行？）。

       -用户需求：关注系统是否满足用户习惯。

       -功能需求：关注系统是否满足功能要求。

       如果没有需求怎么办

       -参考市面上已经上线的同类产品

       如果需求模糊怎么办

       -收集整理已有需求

       -和产品经理逐条确认

       -参考同类型产品的实现情况

提取测试点

什么是测试点

   -测试点即通过需求分析后对得出的需要进行测试的具体内容

   测试点对测试用例的设计有什么好处

   -快速：根据测试点快速设计测试用例。

   -覆盖：测试点可以完全覆盖需求。

   -方法：在擦拭点上可以快速应用测试方法

   -细节：展现出需求的细节

慕课网前端 测试点提取：登录功能 搜索功能 下载APP功能

(4)测试用例编写

测试用例编写注意

   -根据项目的实际情况设计测试用例表格

   -用例格式不是固定的，不要生搬硬套

   -根据具体情况编写

1，测试用例编写方法

-等价类划分法

       如何选择适当的数据子集。来代表整个数据集。

       通过降低测试的数目去实现“合理的”覆盖，覆盖了更多的可能数据，以发现更多的软件缺陷。

       (一种典型的黑盒测试的方法)将所有可能输入的数据划分为若干个等价类，从每个部分中选出最具有代表性的数据，作为测试用例，进行合理的分类。

       等价类分为有效等价类和无效等价类→测试用例具有完整性和代表性。

       -有效等价类：合理的有意义的数据，检验程序是否满足规格说明

       -无效等价类：对于软件规格来说是不合理的、没有意义的输入数据的集合

  -边界值分析法

           使用边界值分析方法设计测试用例时，一般与等价类花饭结合起来，但它不是从一个等价类中任选一个例子作为代表，而是将测试边界情况作为重要目标，选取正好等于、刚刚大于或刚刚小于边界值的测试数据。（边界值可以作为等价类的补充。）

  -场景法

           通过运用场景来对系统的功能点或业务流程的描述，从而提高测试效果。

           场景法一般包含基本流和备用流，从一个流程开始，通过描述经过的路径来确定的过程，经过遍历所有的基本流和备用流来完成整个场景。

2，设计测试用例表格

根据测试点编写测试用例表格
点击注册按钮显示注册对话框 对输入的邮箱验证是否可用

3，测试用例评审

→简单的来讲。评审就是对测试用例进行检查。

   →评审包括同行评审、小组评审、部门评审、三方评审（开发、测试、客户）等

   →不同的评审类型会有不同的角色参与

评审的意义在哪里
通过评审可以发现测试用例的不足
方便测试人员改进用例
达到在测试是提高测试质量的目的

评审的流程

4，测试用例管理

为什么需要管理用例
测试用例数量巨大
测试用例会随着需求变更
测试用例需要补充完善

如何管理用例
原始的excel管理方式
专业的项目管理系统

禅道：https://demo.zentao.net/testcase-browse-3.html

四，自动化测试

自动化测试或测试自动化是一种软件测试技术，它使用自动化测试工具来执行测试用例套件。相反，手工测试是由坐在计算机前的人员仔细执行测试步骤来执行的。

自动化测试软件还可以将测试数据输入被测系统，比较预期结果和实际结果，并生成详细的测试报告。软件测试自动化需要大量的金钱和资源投资。

连续的开发周期将需要重复执行相同的测试套件。使用测试自动化工具，可以记录该测试套件并根据需要重复执行。一旦测试套件自动化，就无需人工干预。这提高了测试自动化的投资回报率。自动化的目标是减少手动运行的测试用例的次数，而不是完全消除手动测试。

五， 接口测试

首先是接口测试，http学习后就可以学习接口知识啦，使用postman进行接口测试。
接口测试就是校验这个接口返回参数和状态是否正确，接口测试前期需要做如下准备工作：

a.开发人员提供服务接口（接口路径、头文件、请求数据格式等）;

b. 给出测试数据。以登录为例：需要各种组合的用户名和密码;

c.根据前两步可以选着postman、RESTClient、Fiddler、Charles任意一款工具模拟请求。当请求成功发送并返回时！

d.根据模拟的的设计请求格式，选则相应的测试工具。目前主流的接口测试主要有：Jmeter、Locust、以及自己编写的一些的脚本。对于刚入门的个人推荐学习Jmeter，Jmeter既可以做接口测试，还可以基于接口做并发测试、压测、负载测试，不过性能和稳定性没有loadrunner好。

写脚本的项目目录一般包括：库文件lib、测试数据文件data、测试用例文件、测试报告、日志文件和主程序。

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

手机组装流水线按照图纸将各个电子元件组装焊接为各个模块组件（如喇叭，听筒，麦克，FPC，按键板，摄像头，LCD等），再将各个模块组件组装成一部完整的手机。

如果一起顺利，在给手机安装系统后就可以正常使用了。但是很不幸，大多数情况下的手机是无法使用的，那么就需要将已经组装好的手机重新拆机，逐个模块排查问题，在每个模块排查中需要对每个电子元件进行检测，通过花费大量的时间和精力才能定位到问题原因。

那么在后续的生产中，如何才能避免这种问题的发生呢？

你可能立即就会想到，为什么不在组装焊接前，就先测试每个要用到的电子元器件呢？这样你就可以先排除有问题的元器件，最大程度地防止组装完成后逐级排查问题的事情发生。

实践也证明，这的确是一个行之有效的好办法。

如果把手机的生产、测试和软件的开发、测试进行类比，你可以发现：
电子元器件就像是软件中的单元，通常是函数或者类，对单个元器件的测试就像是软件测试中的单元测试；
组装完成的功能模块组件如喇叭，听筒，麦克，FPC，按键板，摄像头，LCD等就像是软件中的模块，对功能模块组件的测试就像是软件中的集成测试；
手机全部组装并安装系统就像是软件完成了预发布版本，手机全部组装并安装系统完成后的开机测试就像是软件中的系统测试；

单元测试

单元测试是指，对软件中的最小可测试单元在与程序其他部分相隔离的情况下进行检查和验证的工作，这里的最小可测试单元通常是指函数或者类。

单元测试和编码属于软件过程的同一个阶段，它应用人工测试和计算机测试这样两种不同类型的测试方法对模块进行集中检测。单元测试主要使用白盒测试技术，对多个模块的测试可以并行地进行。

人工测试的方法由审查小组进行，其主要使用白盒测试技术进行代码审查，审查的重点是模块接口、局部数据结构、重要的执行通路、出错处理通路和边界条件，一般来说可以查出30%～70%的逻辑设计错误和编码错误，这可以减少系统验证的总工作量。

审查小组一般由一名审查组长，带领程序的设计人员、编码人员和测试人员共同进行。

计算机测试的方法必须为每个单元测试开发驱动程序和(或)存根程序，驱动程序是一个“主程序”，它接收测试数据，传送给被测试的模块，并且输出有关的结果。

存根程序代替被测试的模块所调用的模块。它使用被它代替的模块的接口，可能做最少量的数据操作，输出对入口的检验或操作结果，并且把控制归还给调用它的模块。
单元测试的代码结构一般包含三部分：分别是准备、调用与断言
准备：准备部分的⽬的是准备好调⽤所需要的外部环境，如数据，Stub（桩代码），Mock，临时变量，调⽤请求，环境背景变量等等。
调用：调⽤部分则是实际调⽤需要测试⽅法，即函数或者流程本身。
断言：断⾔部分判断调⽤部分的返回结果是否符合预期。
每个单元测试都应该能清晰地分出这三部分，当然有时调⽤断⾔两部分合在⼀起也是⽐较常见的

驱动程序 桩程序 Mock

驱动程序：驱动程序（Driver）也称作驱动模块，用以模拟被测模块的上级模块，能够调用被测模块。在测试过程中，驱动模块接收测试数据，调用被测模块并把相关的数据传送给被测模块。

简单说就是你负责测试的模块没有main()方法入口，所以需要写一个带main的方法来调用你的模块或方法。这个就是驱动测试
桩程序：桩程序（Stub），也称桩模块，用以模拟被测模块工作过程中所调用的下层模块，即被测模块本身调用的其他关联函数。桩模块由被测模块调用，它们一般只进行很少的数据处理。

桩是指用来代替关联代码或者未实现的代码，为了让测试对象可以正常的执行，其实一般会硬编码一些输入和输出，保证被测模块能够正常运行
Mock：Mock除了保证Stub的功能之外，还可深入的模拟对象之间的交互方式，如：调用了几次、在某种情况下是否会抛出异常以及提供数据断言

集成测试

集成测试是测试和组装软件的系统化技术，主要目标是发现与接口有关的问题。

由模块组装成程序时有两种方法：

1,非渐增式测试方法
先分别测试每个模块，再把所有模块按设计要求放在一起结合成所要的程序。非渐增式测试一下子把所有模块放在一起，并把庞大的程序作为一个整体来测试，测试者面对的情况十分复杂，在庞大的程序中想要诊断定位一个错误是非常困难的，改正错误更是极端困难，而且一旦改正一个错误之后，马上又会遇到新的错误。
2,渐增式测试方法
把下一个要测试的模块同已经测试好的那些模块结合起来进行测试，测试完以后再把下一个应该测试的模块结合进来测试，每次增加一个模块，实际上同时完成单元测试和集成测试。把程序划分成小段来构造和测试，在这个过程中比较容易定位和改正错误；
渐增方式也有两种集成策略：自顶向下集成和自底向上集成

自顶向下集成

自顶向下的集成测试就是按照系统层次结构图，以主程序模块为中心，自上而下按照深度优先或者广度优先策略，对各个模块一边组装一边进行测试。
优点：较早地验证了主要控制和判断点；按深度优先可以首先实现和验证一个完整的软件功能；功能较早证实，带来信心；只需一个驱动，减少驱动器开发的费用；支持故障隔离。
缺点：柱的开发量大；底层验证被推迟；底层组件测试不充分。
适应于产品控制结构比较清晰和稳定；高层接口变化较小；底层接口未定义或经常可能被修改；产口控制组件具有较大的技术风险，需要尽早被验证；希望尽早能看到产品的系统功能行为。

自底向上集成

自底向上集成是从系统层次结构图的底层模块开始进行组装和集成测试的方式。对于某一个层次的特定模块，因为它的子模块（包括子模块的所有下属模块）已经组装并测试完成，所以不再需要桩模块。在测试过程中，如果想要从子模块得到信息可以通过直接运行子模块得到。也就是说，在集成测试的过程中只需要开发相应的驱动模块就可以了。
优点：对底层组件行为较早验证；工作起初可以并行集成，比自顶向下效率高；减少了桩的工作量；支持故障隔离。
缺点：驱动的开发工作量大；对高层的验证被推迟，设计上的错误不能被及时发现。
适应于底层接口比较稳定；高层接口变化比较频繁；底层组件较早被完成。

系统测试

系统测试是将已经继承好的软件系统，作为计算机系统的一个元素，与计算机硬件、某些支持软件、数据和人员等其他系统元素结合在一起，在实际运行环境下，对计算机系统进行一系列的集成测试和确认测试。

系统测试的目标是：通过与系统的需求规格说明进行比较，检查软件是否存在与系统规格说明不符合或与之矛盾的地方，从而验证软件系统的功能和性能等满足规格说明所制定的要求。

系统测试分析

用户层：围绕用户界面的规范性、友好性、可操作性、系统对用户的支持，以及数据的安全性等方面展开。另外，用户层的测试通常还应注意可维护性测试和安全性测试。
应用层：主要是针对产品工程应用或行业应用的测试。从应用软件系统的角度出发，模拟实际应用环境，对系统的兼容性、可靠性等进行测试。针对整个系统的应用层测试，包含并发性能测试、负载测试、压力测试、强度测试、破坏性测试。
功能层：检测系统是否已经实现需求规格说明中定义的功能，以及系统功能之间是否存在类似共享资源访问冲突的情况。
子系统层：针对产品内部结构性能的测试。
协议/指标层：针对系统所支持的协议，进行协议一致性测试和协议互通测试。

系统测试的方法：

1，功能测试：功能测试属于黑盒测试，是系统测试中最基本的测试。功能测试主要根据产品的需求规格说明和测试需求列表，验证产品是否符合需求规格说明。
2，协议一致性测试：主要用于分布式系统。在分布式系统中，很多功能的实现是通过多台计算机相互协作来完成的，这要求计算机之间能相互交换信息，所以需要制定一些规则（协议）。对协议进行测试，通常包括：协议一致性测试、协议性能测试、协议互操作性测试、协议健壮性测试。
3，性能测试：主要用于实时系统和嵌入式系统，性能测试是指测试软件在集成系统中的运行性能，目标是量度系统的性能和预先定义的目标有多大差距。一种典型的性能测试是压力测试，当系统同时接收极大数量的用户和用户请求时，需要测量系统的应对能力。性能测试要有工具的支持，在某种情况下，测试人员必须自己开发专门的接口工具。
4，压力测试：又称强度测试，是在各种超负荷的情况下观察系统的运行情况的测试。
5，容量测试：在系统正常运行的范围内测试并确定系统能够处理的数据容量。容量测试是面向数据的，主要目的就是检测系统可以处理目标内确定的数据容量。
6，安全性测试：安全性测试就是要验证系统的保护机制是否抵御入侵者的攻击。保护测试是安全性测试中一种常见的测试，主要用于测试系统的信息保护机制。评价安全机制的性能与安全功能本身一样重要，其中安全性的性能主要包括：有效性、生存性、精确性、反应时间、吞吐量。
7，失效恢复测试：验证系统从软件或者硬件失效中恢复的能力。失效恢复测试采用各种人为干预方式使软件出错，造成人为的系统失效，进而检测系统的恢复能力。如果恢复需要人为干预，则应考虑平均修复时间是否在限定的范围内。
8，备份测试：备份测试是失效恢复测试的补充，目的是验证系统在软件或者硬件失效的实践中备份其数据的能力。
9，GUI测试：GUI测试与用户友好性测试和可操作性测试有重复，但GUI测试更关注对图形界面的测试。GUI测试分为两个部分，一方面是界面实现与界面设计的情况要符合；另一方面是要确认界面能够正确处理事件。GUI测试设计测试用例一般要从以下4方面考虑：
（1）划分界面元素，并根据界面的复杂性进行分层。通常把界面划分为三个层次，第一层是界面原子层；第二层是界面组合元素层；第三层是一个完整的窗口。
（2）在不同的界面层次确定不同的测试策略。
（3）进行测试数据分析，提取测试用例。
（4）使用自动化测试工具进行脚本化工作。
10，健壮性测试：又称容错测试，用于测试系统在出故障时，是否能够自动恢复或者忽略故障继续运行。健壮性测试的一般方法是软件故障插入测试，在软件故障插入测试中，需要关注三个方面：目标系统、故障类型和插入故障的方法。
11，兼容性测试：检验被测的应用系统对其他系统的兼容性。
12，易用性测试：与可操作性类似。检测用户在理解和使用系统方面是否方便。易用性测试是面向用户的系统测试，包括对被测系统的系统功能、系统发布、帮助文本和过程等的测试。最好在开发阶段就开始进行。
13，安装测试：验证成功安装系统的能力。
14，文档测试：主要是针对系统提交给用户的文档进行验证。文档测试的目标是验证用户文档的正确性并保证操作手册的过程能正常工作。
15，在线帮助测试：用于检验系统的实时在线帮助的可操作性和准确性。
16，数据转换测试：目标是验证已存在数据的转换并载入一个新的数据库是否有效。

七， 确认测试

概述

确认测试也称为验收测试，它的目标是验证软件的有效性（即软件的功能和性能是否符合用户预期）。

需求分析阶段产生的软件需求规格说明书，准确地描述了用户对软件的合理预期，因此是软件有效性的标准，也是进行确认测试的基础。

确认测试的范围和软件配置复查

确认测试必须有用户积极参与，或者以用户为主进行，使用用户界面输入测试数据并且分析评价测试的输出结果，在验收之前通常要由开发单位对用户进行培训，一般来说确认测试分为Alpha和Beta测试。

确认测试的一个重要内容是复查软件配置。复查的目的是保证软件配置的所有成分都齐全，质量符合要求，文档与程序完全一致，具有完成软件维护所必须的细节。

Alpha和Beta测试

Alpha测试就是由开发者“指导”用户在开发环境下进行的测试。Alpha测试是在受控的环境中进行的。
Alpha测试是用户在开发环境下进行的测试，也可以是产品供应商内部的用户在模拟实际操作环境下进行的测试。软件在一个自然设置状态下使用，开发者坐在用户旁边，随时记下错误情况和使用中的问题。这是在受控制环境下进行的测试。

Beta测试就是由软件的最终用户们在一个或多个实际生产环境下进行的测试。开发者通常不在Beta测试的现场，因此，Beta测试是软件在开发者不能控制的环境中的“真实”应用。
Beta测试是由多个用户在一个或多个用户的实际使用环境下进行的测试。通常是在不受控制的环境下进行的测试，开发者通常不在现场。用户记录在测试过程中遇到的一切问题（真实的或想象的），并且定期把这些问题报告给开发者。

八， 软件测试方法

软件测试方法主要分为黑盒测试和白盒测试：(测试思路)

1，黑盒测试(功能测试)
把程序看作一个黑盒子，完全不考虑程序的内部结构和处理过程，而是在程序接口进行的测试；
2，白盒测试(结构测试)
把程序看成装在一个透明的盒子里，测试者完全知道程序的结构和处理算法，按照程序内部的逻辑测试程序，检测程序中的主要执行通路是否都能按预定要求正确工作。

九， 设计测试用例

一，测试用例
设计测试用例时一般从以下几个方面进行分析：
1,UI(界面测试) 2,功能测试 3,性能测试(压力测试) 4,接口自动化 5,安全 6,兼容性
(1),UI(界面测试)
通过用户界面 (UI) 测试来核实用户与软件的交互
测试用户界面的功能模块的布局是否合理、整体风格是否一致
(2)功能测试
功能测试就是对产品的各功能进行验证，根据功能测试用例，逐项测试，检查产品是否达到用户要求的功能。
(3)性能测试(压力测试)
性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试
通过负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接受的性能点，来获得系统能提供的最大服务级别的测试。
(4)接口自动化

(5)安全

系统安全性：
1，软件漏洞，设计上的缺陷或程序问题;
2，数据库的安全性，这也是系统安全性的核心。
黑盒测试：不具备代码走读的能力，根据需求文档来进行编写case用例，测试需求
白盒测试：具备代码走读的能力，能根据需求文档来复查研发写的代码逻辑
(6)兼容性
软件兼容性测试是指检查软件之间能否正确地进行交互和共享信息 测试软件之间能否协作
软件兼容性测试工作的目标是保证软件按照用户期望的方式进行交互。