软件测试第一阶段：web前端技术基础-8- 软件测试中的理论和概念

一丶测试的目的和原则

软件测试的目的

• 测试的目的就是为了找到软件或者网站等其中存在的问题（bug，用户体验感不好，界面丑陋，功能是否全面等）
• 通过测试可以提前找到软件中存在的问题，可以降低商业风险（减少不必要的支出，省钱）

软件测试的定义

• 软件测试就是用人工或者自动化对软件系统进行测试，通过测试找到 预期结果和实际结果的差异
• 预期结果：在测试之前我们就知道的结果，希望出现的结果
• 实际结果：测试之后得到的实际结果

软件测试的基本原则

1）所有软件只能证明存在问题，不能证明不存在

• 辩证
• 所有的软件都是有问题的，只是在于这些问题你是否发现了而已

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

• 穷举：将所有的可能出现的问题都测试一遍
• 分类测试：
  • 可以被正常搜索的：也就是可以正常显示的那些，   比如：在淘宝中搜索男装
  • 不能被正常搜索的：也就是那些不该出现，不该被显示的对象      比如：在淘宝中搜索违禁品
  • 特殊情况：：比如在淘宝中搜索时输入空格 或者什么都不输入

3）测试工作应该尽早介入，可以降低成本

及早发现问题，及早解决

4）缺陷聚集原则，二八原则

• 一个项目中80%的缺陷会集中出现在20%的功能模块中
• 越是有问题的地方，往往会出现更多的其他问题
• 出现这个现象的缘由：
  • 负责这个模块的程序员技术水平一般
  • 模块功能复杂

5）测试依赖环境

• 程序的架构：b/s  c/s
  • B/S架构：Broswer/Server          通过浏览器访问服务
  • C/S架构：Client/Server              通过客户端程序访问服务
• 测试B/S架构准备三款浏览器：谷歌，火狐，ie（苹果，欧鹏，qq）
• 测试C/S架构准备：
  • pc：win7，8，10        mac，linux
  • 手机：安卓，苹果，鸿蒙

Broswer：浏览器           Server：服务端        Client：客户端  

6）杀虫剂现象

• 测试人员在经过一段时间后进入自己固有的思维意识，很难在测试出其他的bug（漏洞），这个时候可以进行交叉测试（测试人员交换测试）

7）不存在缺陷谬论

• 同第一条重复的

二丶 软件开发模型

简介 ：

• 软件的生命周期：软件开发模型

软件测试与软件的开发模式有着紧密的联系，作为一名测试人员，应该充分理解软件的开发模式，以便 找准自己在其中的位置，从而发挥自身的价值

在软件开发的几十年实践中，人们总结了很多软件开发模型用来描述和表示一个复杂的开发过程，软件 开发有三种模式：

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

三种模型：

瀑布模型：

 

第一个阶段：项目立项阶段 

1. 调研：

• 首先对项目进行可行性的研究，通过可行性的研究可以判断这个项目是否挣钱
•  调研完成后会得到一个可行性调研报告
• 这个工作是由项目负责人来完成

    2.需求分析：

• 调研判断项目没问题以后，就可以进行需求分析
• 最终会得到一个需求规格说明书，规格书中仅仅是 需求的大体说明
• 这个工作是由项目经理完成

第二个阶段：项目开发阶段

1.概要设计：

• 就是将需求规格书中的内容落地
• 概要设计完成后，会得到一个概要设计文档
• 概要设计文档中会将整个项目分成若干个功能模块，而且会明确说明每个模块中的功能
• 这个是由经验丰富的前端和的后端程序员完成的

2.详细设计：

• 在详细设计中，明确指定了模块具体实现的细节
• 最终会得到一个详细的设计文档
• 整个工作是由一线程序员来完成的

3.编码：

• 其实就是程序员写代码
• 最终得到的是代码
• 这个是由程序员完成的

4.软件测试：

• 测试软件是否可以正常运行，是否达到了预期的功能，效果
• 最终得到的是测试报告
• 这个是由测试工程是来完成的

第三个阶段：项目运维阶段

• 上线用户才能访问

瀑布模型的特点

• 是以文档驱动，后面所有的工作都是基于前面的文档的内容
•  每个阶段执行一次，而且是线性依次进行的
• 开发模式中，瀑布模型是非常重要的一种

瀑布模型的优点

• 各个阶段非常清晰
• 每个人只需要关注自己的阶段

瀑布模型的缺点

• 下面的阶段是依赖上面阶段的分析结果，一旦上面出现问题  那么下面全部都错了  一步错步步错
• 整个流程过分依赖需求分析结果，这种模式不能适应变化频繁的项目
• 这种模式适用于传统项目和行业：银行、保险、建筑

快速原型模型

• 一个项目在很短时间能上线，就有一个版本上线，这个版本往往功能不全，而且有bug
• 在后续的版本中陆续修复bug，并添加完善功能

 特点：

• 快速上线
• 支持用户参与

优点：

• 克服了瀑布模型中的缺点，减少中间环境，可以及早发现问题并进行修复

缺点：

• 仅仅适合中小型项目，不适合大型项目

螺旋模型

三， 软件测试模型

简介：

• 测试模型：所谓的模型就是这个行业的人总结出来的测试经验

第一种：V模型

• 这种模型其实就是在前面瀑布模型的基础上进行测试的
• 这种模型其实也就是是瀑布模型的变种
• 根据测试阶段不同，测试也同样分成四个不同的阶段

 V型的流程

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

优点：

• 整个过程比较清晰，既包含底层测试    又包含对高层进行测试

缺点：

• 这个本质还是瀑布模型 ，因此也就具有瀑布模型的缺点

第二种：W（双V）模型

• 这种模式主要是为了解决V型模型存在的问题，解决思路就是测试前移

 W型比V型多的部分

• 集成：每个程序员将自己负责的功能模块合并到一起
• 实施：将 开发好的软件安装到客户的服务器上
• 交付：教给用户如何使用软件

静态和动态测试

• W模型中，对各种的文档进行测试，都是静态测试
• 对程序进行测试，就是动态测试

W模型中的流程

• 开发V：用户需求=>需求分析=>概要设计=>详细设计=>编码=>集成=>实施=>交付
• 测试V：验收测试设计=>系统测试设计=>集成测试设计=>单元测试设计=>单元测试=>集成测试=> 系统测试=>验收测试

优点：

• 测试工作前移，可以今早发现存在的问题

缺点：

• 对技术和管理能力要求较高

四，软件质量模型、

• 质量体系：ISO 9126

六大特性：

• 功能性
• 可靠性
• 易用性
• 效率
• 维护性
• 可移植性

五，软件测试分类

第一种分类方法：按照阶段分类

• 单元测试
  • 模块：程序的最小单位就是模块，比如用户登录模块、购物车模块等这都是一个单独的模块
  • 单元测试就是检测这个模块是否满足测试用例的要求，仅仅是测试一个单独的模块是否能 正常运行
• 集成测试
  • 集成测试又称为 组装测试
  • 在单元测试完成以后，就是表示每个单独的模块已经正常
  • 集成测试，就是将多个模块组合起来进行测试
• 系统测试
  • 在集成测试完成以后，才能进行系统测试
  • 系统测试就是将软件作为一个整体来测试，测试的依据是软件需求说明书【就是检查软件是否 达到了当初想要的样子】
• 验收测试
  • 主要是检查软件是否满足客户的要求，对软件做最后的测试
  • 验收测试分为几个小类
    • α测试（Alpha）：阿尔法测试的软件版本  内测版本，软件bug较多，一般不让用户直接 使用，而是公司内部交流使用
    • β测试（Beta）：贝塔测试就是软件的公测版本，目的就是让更多的用户通过使用软件 来发现更多的问题
    • γ测试（Gamma）：伽马测试就是软件的正式候选版，这个版本和用户最后使用的正式 版几乎完全一致

第二种分类方法：按是否查看源码进行分类

• 白盒测试

  • 不去执行程序，而是去直接读取程序的代码

• 黑盒测试
  • 又称之为数据驱动测试
  • 这种测试就是直接使用软件，完全不考虑程序内部结构和代码
  • 例如：输入账号、密码，一点就能登录成功，就表示测试通过
• 灰盒测试
  • 既要去读程序的代码，也要去执行程序
  • 也就是既要做黑盒的工作，也要做白盒的工作

第三种分类方法：按照是否运行程序划分

• 静态测试
• 动态测试

第四种分类方法：是否自动运行

• 人工测试：所有的测试工作是由测试人员手动点击完成的测试
• 自动化测试：通过python开发自动化工具，用工具完成的测试工作

第五种分类方法；其他分类

• 冒烟测试
  • 测试软件基础功能是否正常
• 回归测试
  • 在测试工作种，一旦发现了bug，需要将这个bug提交给开发，开发修复完成后，需要重新进行测试
• 随机测试
  • 虽然叫做随机测试，但是  不是真的随机
  • 这里的随机其实就是重复测试，包括测试之前的测试用例种中没有涵盖的部分
• 探索测试
  • 这个测试不是必要的 就是可以修改 即使不修改也怎么不影响软件的使用

六，软件缺陷

• 缺陷不等于bug   但缺陷中包含着bug
• bug仅仅只是缺陷中的很小的一个部分而已
• 什么是缺陷：只要让测试人员认为不合理的，那么这个就是缺陷

1，软件缺陷判定标准

• 软件未能达到软件需求规格书中的要求 
  • 比如开发一个计算器要求有+ - x /   而只有+  -
• 软件的功能超出规格书中的要求
  • 开发一个计算器要求有+ - x /    里边不光有+ - x / 还有**
• 软件出现了规格书中明确指定不能出错的地方
• 软件出现了规格书中未明确指定，但是不应该出现的错误

2，软件缺陷产生的原因（缺陷只能减少 但不能完全避免，完全没有）

• 对于需求文档等文件的 解释、理解 错误【需求说明会】
• 设计文档本身有错误
• 程序代码错误
• 硬件和软件系统有错

3，软件缺陷的类型

• 功能错误：软件没有达到需求文档的功能要求，或者功能异常
• 界面错误：软件功能正常，但是界面不好看或者未达到软件规格说明书中的要求
• 兼容性错误：软件和系统中的其他的程序冲突，导致软件无法运行
• 易用性错误：软件用起来不好用
• 改进建议：改了更好，不改也不影响使用