第一阶段基础知识

一、测试理论

1.如何理解软件测试？

软件测试就是用人工或自动化对软件进行测试，目的是找到预期结果与实际结果的差异，他的核心是通过最少人力，物力，财力来找出软件中的与预期结果不符的地方，去让开发进行修复，从而降低商业风险

2.软件测试的原则

1.不存在只能证明软件存在问题，不能说不存在问题

2.不能进行穷举测试，应该进行分类测试

3.测试工作应当尽早介入测试

4.软件存在集群现象又叫“二八法则”，就是80%的BUG出现在20%的模块里面

5.测试依赖于环境：操作系统、浏览器

        操作系统：分为两个系统

        手机系统例如：安卓，iOS，

        电脑系统例如：Windows，mac，linux

        浏览器：火狐，谷歌或者IE，开发的程序是需要兼容这个3个主流的浏览器

6.杀虫剂现象：当一个测试人员进行固定不变的测试流程就会形成思维固化，容易漏测，解决方法可以进行交换测试。

3.测试项目分为两类

B/S架构：

B/S架构的全名是Browser/Server，通过浏览器访问的就属于B/S架构的

C/S架构：

C/S架构的全名是Cilent/Serever,通过客服端访问的就属于C/S架构的

4.软件开发模型

软件生命周期：每个软件都有一个生命周期

模型类别

瀑布模型，快速原型模型，螺旋模型

软件测试模式

所谓软件测试模型，就是前辈们总结的测试经验。

作用

通过经验总结得到测试模型，旨在提高软件开发测试过程中的效率和效果。

第一种模型：V模型

V模型 在前面瀑布模型的基础上，对测试的工作进行了更细致的划分

补充

V模型最早是由 Paul Rook 在20世纪80年代后期提出的，由英国国家算计机中心文献中发布。

V模型其实是瀑布模型的变种，他反应了测试活动与分析和设计的关系。

V模型标明了测试过程中本身存在不同阶段，从左到右，描述了开发过程和测试过程间的阶段对应关系。

优缺点

优点：V模型既包含了底层测试又包含了高层测试

缺点： 依赖于需求分析。不适应需求变化往往会在后期显露风险，失去尽早纠错的机会，

如果没有及时发问题，到最后测试阶段才发现则需要推倒重来。一般只适用于大型的或者复杂的项目上，比如银行 、保险、建筑。

总结

组成部分

用户需求==>需求分析==>概要设计==>详细设计==>编码==>单元测试==>集成测试==>系统测试==>验收测试

优点： 只需关注当前阶段、文档驱动、线性模型。

缺点：不响应需求变化，不灵活。

第二种模型：W模型

W模型也称为双V模型

这种模型，测试伴随着整个开发周期，并且测试的对象不仅仅是程序，需求设计同样要测试。

W模型是为了解决V模型中存在的问题，也就实现了测试前移。

双V模型，蓝色代表开发 绿色代表测试

双V模型中 开发V当中右边的三个：集成、实施、交付

集成：就是指多个程序员完成自己部分的代码后，需要将代码合并到一起，这个过程就叫做集成

实施：将开发好的程序部署到服务器上

交付：验货、交给自己或用户来使用

在测试V中也多了三个，W是为了实现测试的前移，因为多的四个在左侧：验收测试设计、系统测试设计、集成测试 设计、单元测试设计

验收测试设计：也就是当有了需求文档以后，会对需求文档进行测试，这肯定是静态测试

也就是，通过验收测试设计、系统测试设计、集成测试设计、单元测试设计，可以对前面的每个环节都进行测试 ，测试伴随了软件开发的全过程

W模型的优缺点

优点

1.强调测试伴随着整个开发周期，而且测试的对象不仅仅是程序，还包括需求和设计

2.更早的介入测试，能尽早的发现缺陷

缺点

因为是站在更高的角度看问题，所以对于测试技术要求高，实践起来比较困难

5.软件质量模型

软件质量模型分为6类

功能性：检查业务功能是否满足需求

可靠性：容错能力 （出现错误后恢复正常的时间或所需要的能力）

易用性：看得懂，会使用

效率：性能（响应时间，占用的资源等）

维护性：为后续的功能开发与维护提供便利

移植性：软件需要能够在不用的环境（软件环境，硬件环境）下都能正常工作

6.软件测试分类

按阶段分类：

单元测试，集成测试，系统测试，验收测试，

其中验收测试有3个测试版本：α：内侧版本，β：公测版本，γ：预正式版

按是否查看代码分

黑盒:看不到源码，直接对软件进行测试

白盒：可以看到所有源码，针对源码和软件一起测试

灰盒：可以以看到一部分源码，结合软件进行测试

按是否自动化划分

人工：针对软件进行纯人工测试

自动化：借助自动化工具进行测试

按照是否运行划分

静态：就是不实际运行被测软件，而只是静态地检查程序代码、界面或文档中可能存在的错误的过程。

动态：指的是实际运行被测程序，输入相应的测试数据，检查实际输出结果和预期结果是否相符的过程，所以判断一个测试属于动态测试还是静态的，唯一的标准就是看是否运行程序。

其他

回归：测试人员进行测试出BUG，提交给开发人员进行修复，开发人员修复完成后再次进行测试。

冒烟：针对于软件最基本的程序进行测试

随机：针对于软件重要功能进行测试

探索：

7.用例设计编写格式说明
用例编号：项目模块编号

用例标题：预期结果（测试点）

模块/项目：所属项目或模块

优先级：表示用例重要程度P0~P4（P0最高）

前置条件：要执行此条用例，有那先前置条件

测试步骤：描述操作步骤

测试数据：操作的数据，没有可以不写

预期结果：期望达到的结果

测试用例的作用
1.防止漏测

2.实施测试标准

3.便于理清测试思路，确保测试没有遗漏

4.便于测试工作量评估

5.便于提前准备测试数据

6.便于把控测试的工作进度

7.便于进行回归测试

8.便于测试工作的组织，提高测试效率，降低工作交接成本

等价类划分
概念：在所有测试数据中，具有某种共同特征的数据集合划分

分类：

有效等价类：满足需要的数据集合

无效等价类：不满足需要的数据集合

步骤：

1.明确需求

2.确定有效和无效等价类

（无效等价类可以从一下几点来考虑

1.从需求中找，找不满足的数据

2.根据数据的类型

3.根据数据的长度

4.是否为空，空在表格中表示为（/）

5.是否重复（用户ID、用户名或手机号等）

8.缺陷类型

BUG不等同于缺陷，但BUG是缺陷的的一部分

软件缺陷

定义：软件在使用过程中存在的任何问题都叫软件的缺陷，缺陷不等同于bug，

缺陷的存在会导致软件产品在某种程度上不能满足用户的需求，只要你的软件不符合用户的看法，那你的软件就是有缺陷

缺陷的判定标准
软件未实现需求（规格）说明书中明确要求的功能--少功能

软件出现了需求（规格）说明书中指明不应该出现的错误--功能错误

软件出现的功能超出需求（规格）说明书指明的范围--多功能

软件未实现需求（规格）说明书中虽未明确指明但应该实现的要求--隐形功能错误

软件难以理解，不易使用，运行缓慢，用户体验不好--不易使用

缺陷产生的原因
需求：需求描述不易理解，有歧义错误等

设计：设计文档存在错误或缺陷

编码：代码出现错误

运行：软硬件系统本身故障导致软件缺陷

软件缺陷的核心内容
缺陷的标题：描述缺陷的核心问题

缺陷的预期结果：希望得到的结果

缺陷的预置条件：缺陷产生的前提

缺陷的实际结果：实际得到的结果

缺陷的复现步骤：复现缺陷的过程

缺陷的必要附件：图片日志等信息&