测试理论

1.1 软件的分类

1.1.1 软件的定义

一系列按照特定顺序组织的计算机数据和指令的集合。
软件 = 数据 + 指令 + 文档
问题：常见软件有哪些？

1.1.2 根据应用场景分类

工具类软件、游戏型软件、媒体型软件、电商型软件等

1.1.3 根据软件架构分类

单机版软件、分布式软件

1. 单机版软件：office、红警等
2. 分布式软件：
   C/S架构软件：客户端需安装专门软件，如QQ 微信等
   B/S架构软件：客户端为浏览器 ，如百度、hao123等

1.2 软件测试的定义与原则

1.2.1 为什么需要软件测试

• 事故：阿丽亚娜5号火箭爆炸，造成重大经济损失。

• 原因：程序中试图将64位浮点数转换成16位整数时发生溢出-----缺少错误程序对数据溢出进行管理

• 事故：拼多多2019年用户可以领取100元无门槛券。
• 原因：程序中试图将64位浮点数转换成16位整数时发生溢出-----缺少错误程序对数据溢出进行管理

1.2.2 软件测试的定义

通过人工或自动化的方式来验证软件的实际结果与用户需求是否一致的过程

1.2.3 软件测试的原则

• 原则一：测试显示软件存在缺陷
  测试只能证明软件中存在缺陷，但并不能证明软件中不存在缺陷。软件测试是为了降低存在缺陷的可能性，即便是没有找到缺陷，也不能证明软件是完美的。
• 原则二：穷尽测试是不可能的
  现在软件的规模越来越大，复杂度越来越高，想做到完全性的测试是不可能的。在测试阶段，测试人员可以根据风险和优先级来进行集中和高强度的测试，从而保证软件的质量。
• 原则三：测试尽早介入
  为什么测试要尽早介入呢，简单的说就是保证软件质量，降低风险和成本。测试人员一般在需求阶段就开始介入，使缺陷在需求或设计阶段就被发现，缺陷发现越早，修复的成本就越小。
• 原则四：缺陷集群性（2/8原则）
  缺陷集群性表明小部分模块包含大部分的缺陷。软件测试中存在Pareto原则：80%的缺陷发现在20%的模块中。
  一个功能模块发现的缺陷越高，那存在的未被发现的缺陷也越高，故发现的缺陷与未发现的缺陷成正比。
• 原则五：杀虫剂悖论
  反复使用相同的杀虫剂会导致害虫对杀虫剂产生免疫而无法杀死害虫。软件测试也一样。如果一直使用相同的测试方法或手段，可能无法发现新的bug。
  为了解决这个问题，测试用例应当定期修订和评审，增加新的或不同的测试用例帮助发现更多的缺陷。
  测试人员不能一直依赖于现有的测试技术，而要不断的提升测试方法以提高测试效率。
• 原则六：测试活动依赖于测试内容
  根据业务的不同，软件测试内部也分为不同的行业，比如游戏行业、电商行业、金融行业。不同的行业，测试活动的开展都有所不同，比如测试技术、测试工具的选择，测试流程都不尽相同，所以软件测试的活动开展依赖于所测试的内容。
• 原则七：没有错误是好是谬论
  有可能99%没有bug的软件也是不能使用的。如果对错误的需求进行了彻底的测试，这种情况就发生了。软件测试不仅是找出缺陷，同时也需要确认软件是否满足需求。如果开发出来的产品不满足用户的需求，即便找到和修复了缺陷也作用不大。
• 原则八：程序员应避免检查自己的程序
• 原则九：严格执行测试计划，排除测试的随意性
• 原则十：应当对每一个测试结果做全面的检查
• 原则十一：妥善保存测试计划、测试用例、出错统计和最终分析报告，为维护提供方便
• 原则十二：设计测试用例时，应当包括合理的输入数据和不合理的输入数据
• 原则十三：测试用例应由测试数据和与之对应的预期输出结果这两部分组成

1.3 开发与测试模型的介绍

1.3.1 开发模型

1. 瀑布模型：

• 引入：做饭最终不能返回
• 定义：将软件生命周期的各项活动规定为按固定顺序而连接的若干阶段工作，形如瀑布流水，最终得到软件产品的项目。

• 优点：
  为项目提供了按阶段划分的检查点
  当前一阶段完成后，只需要去关注后续阶段。
• 缺点：
  各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量。
  由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发风险。
  通过过多的强制完成日期和里程碑来跟踪各个项目阶段。
  瀑布模型的突出缺点是不适应用户需求的变化。

2. 快速原型模型：在需求分析阶段对软件的需求进行初步而非完全的分析和定义，用户与开发者在过程中加强反馈，快速设计开发出软件系统可以运行的模型；
3. 增量模型：把待开发的软件系统模块化，第1个增量往往是产品的核心，将每个模块作为一个增量组件，从而分批次地分析、设计、编码和测试这些增量组件；
4. 敏捷开发：先选择产品，再进行开会、对产品计划，然后对任务进行分工，分工后开始按照计划执行，然后就做出了新的功能模块，然后再进行演示、回顾，最后再领取新的任务，依次循环。

1.3.2 测试模型

V模型：
V 模型的左边下降的是开发过程各阶段，与此相对应的是右边上升的部分，即各测试过程的各个阶段。
V 模型的优点在于它非常明确地标明了测试过程中存在的不同级别，并且清楚地描述了这些测试阶段和开发各阶段的对应关系。

W模型：
相对于V模型，W模型更科学。W模型是V模型的发展，强调的是测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、功能和设计同样要测试。测试与开发是同步进行的，从而有利于尽早地发现问题。

1.4 软件测试的流程

阶段名	工作内容	产出物
测试准备阶段	项目立项、需求分析、需求评审	需求文档、产品PRD
测试计划阶段	编写测试计划、计划评审	测试计划
测试设计阶段	提取测试点、编写测试用例、用例评审	测试用例
测试执行阶段	冒烟测试、执行测试用例、提bug、回归测试	缺陷报告
测试完成阶段	验收测试、编写测试报告、项目上线	测试报告

1.5 软件测试的分类

1.5.1 按技术划分

黑盒测试、白盒测试、灰盒测试

• 黑盒测试(Black Box -Test)：把被测试的软件看做一个黑盒子，我们不去关心盒子里边的结构是什么样子，只关心软件的输入数据和输出结果
  有人把黑盒测试比作中医，通过“望闻问切”来判断是否有问题。
  “望”：观察软件的行为是否正常。
  “闻”：检查输出的结果是否正确。
  “问”：输入各种信息，结合“望”，“闻”来观察软件的响应。
  “切”：像中医一样给软件“把把脉”，敲击一下软件的某些“关节”
• 白盒测试：是一种按照程序内部逻辑结构和编码结构设计测试数据并完成测试的测试方法
• 灰盒测试：一种基于程序运行时的外部表现同时又结合程序内部结构来设计测试数据的测试方法
  

1.5.2 按阶段划分

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

• 单元测试：对一个模块、一个函数或者一个类来进行正确性检验的测试方法
• 集成测试：单元测试后，将单独的模块按照设计要求组装成为子系统或系统，作为整体进行测试的测试方法
• 系统测试：集成测试后，将硬件、软件看作一个整体,对系统的功能及性能的总体测试
• 验收测试：系统测试后以用户测试为主，或有测试人员共同参与检验软件质量的测试方法

测试名称	测试对象	测试依据	人员	测试方法
单元测试	最小模块，如函数，类等	《详细设计》	白盒测试工程师或开发人员	白盒测试方法
集成测试	最小模块组成的子系统或系统	《概要设计》	白盒测试工程师或开发人员	黑盒测试与白盒测试相结合
系统测试	整个系统	《产品需求》	黑盒测试工程师	黑盒测试方法
验收测试	整个系统	《产品需求》，验收标准	主要是用户，还有可能是测试工程师	黑盒测试方法

1.5.3 按内容划分

功能测试、性能测试、兼容性测试

1.5.3.1 功能测试：

• 界面测试、冒烟测试、回归测试、业务逻辑测试、易用性测试
• 功能测试：根据产品操作描述和需求文档，测试一个产品的特性和可操作行为是否满足用户需求的测试方法
• 界面测试：测试用户界面的功能模块的布局是否符合客户使用习惯，界面操作便捷性、导航简单易懂性的测试
• 冒烟测试：验证系统的核心功能是否能够正常运行的测试方法
• 回归测试：指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误的测试方法
• 业务逻辑测试：在基本的功能点都已合格的基础上，准备多种测试数据，来驱动各种约束条件下业务流程，确定最终输出的结果是否符合预期的测试
• 易用性测试：指用户使用软件时是否感觉方便的测试

1.5.3.2 性能测试：

• 性能测试：通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行校验的测试方法
• 压力测试：通过逐步增加系统负载，测试系统性能的变化，并确定在什么条件下系统性能处于失效状态
• 负载测试：通过逐步增加系统负载，测试系统性能的变化，在满足性能指标的情况下，系统所能承受的最大负载量的测试
• 并发测试：是一个负载测试和压力测试的过程，即逐渐增加并发用户数负载直到系统的瓶颈，通过分析资源监控指标等来确定系统并发性能

1.5.3.3 兼容性测试：

1. app
   （1）Android/IOS版本
   （2）厂商
   （3）型号
   （4）分辨率
   （5）屏幕：全屏、水滴屏、刘海屏、曲面屏、折叠屏、双面屏
2. web——浏览器
   （1）Trident内核：IE、360（兼容模式）、搜狗（兼容模式）
   （2）Gecko内核：Firefox
   （3）Blink内核：Chrome、360（极速模式）、搜狗（极速模式）
   （4）WebKit内核：Apple Safari

1.5.4 按其他划分

• 冒烟测试、随机测试、安全性测试、探索性测试、回归测试、Alpha测试、Beta测试
• 随机测试：随机测试主要是根据测试者的经验无需测试用例对软件进行功能和性能抽查的测试方法
• 安全性测试：通过不同的测试方法，检验程序、网络、数据库安全性的测试方法
• 探索性测试：碰到问题时能随机应变，强调测试人员的主观能动性明确整体的测试计划的测试方法
• Alpha测试：俗称内测，α测试。内部环境下的测试；开发人员或测试人员在现场
• Beta测试：俗称外测、公测，β测试。生产环境下的测试；开发人员和测试人员都不在现场

1.6 软件开发生态系统

软件开发生态系统目前最流行最常见的有App、微信小程序、公众号、前端和后台。

1.6.1 App

App即应用程序，Application的缩写，主要指安装在智能手机上的软件，完善原始系统的不足与个性 化。使手机完善其功能，为用户提供更丰富的使用体验的主要手段。手机软件的运行需要有相应的手机 系统，目前主要的手机系统:

• 苹果公司的iOS
• 谷歌公司的Android(安卓)系统。 APP比如:微信，QQ，知乎......需要你下载的软件都是APP。
• 华为的鸿蒙系统

1.6.2 微信小程序

• 微信小程序，小程序的一种，英文名Wechat Mini Program，是一种不需要下载安装即可使用的应用，
• 它实现了应用“触手可及”的梦想，用户扫一扫或搜一下即可打开应用。
• 全面开放申请后，主体类型为企业、政府、媒体、其他组织或个人的开发者，均可申请注册小程序。微信小程序、微信订阅号、微信服务号、微信企业号是并行的体系。
• 微信小程序是一种不用下载就能使用的应用，也是一项创新，经过将近两年的发展，已经构造了新的微 信小程序开发环境和开发者生态。微信小程序也是这么多年来中国IT行业里一个真正能够影响到普通程 序员的创新成果，已经有超过150万的开发者加入到了微信小程序的开发，与我们一起共同发力推动微 信小程序的发展，微信小程序应用数量超过了一百万，覆盖200多个细分的行业，日活用户达到两个 亿，微信小程序还在许多城市实现了支持地铁、公交服务。微信小程序发展带来更多的就业机会，2017年小程序带动就业104万人，社会效应不断提升。
• 2017年1月9日，张小龙（微信之父）在2017微信公开课Pro上发布的微信小程序正式上线。
• 2018年2月，微信官方发布公告称:已对涉及假货高仿、色情低俗和违规“现金贷”等超过2000个微信小 程序，进行永久封禁处理。
• 2019年8月9日，微信向开发者发布新能力公测与更新公告，微信PC版新版本中，支持打开聊天中分享 的微信小程序。

1.6.3 前端

• 前端是什么??
  前端，也称web前端。对于网站来说，通常是指网站的前台部分，包括网站的表现层和结构层(通 俗点就是用户可以看到的部分)。 总结一下，浏览器、APP、应用程序的界面展现和用户交互就是前端

• 前端能干什么??
  前端工程师，别称web前端开发攻城狮，是在2005年由淘宝发明出来的称呼。前端工程师通过前端 技术完成界面设计(听说大公司分工较明细，这部分交给设计师),界面制作，用户交互，网站维 护、网站优化等等。
  通俗点讲，可以设计、制作网页，给网页加上各种各样的特效和功能。

• 前端需要学会哪些技术?
  基础:html+css+javascript,html5+css3 进阶:各种框架，如Bootstrap,jquery,react,vue,angular等等 其他:http,一门后端语言，网站优化等等

1.6.4 后端

• 后端开发即“服务器端”开发，主要涉及软件系统“后端”的东西。比如，用于托管网站和 App 数据的服务器、放置在后端服务器与浏览器及 App 之间的中间件，它们都属于后端。
• 简单地说，那些你在屏幕上看不到但又被用来为前端提供支持的东西就是后端。网站和移动 App 的后端 网站的后端涉及搭建服务器、保存和获取数据，以及用于连接前端的接口。如果说前端开发者关心的是 网站外观，那么后端开发者关心的是如何通过代码、API 和数据库集成来提升网站的速度、性能和响应 性。与前端类似，移动 App 的后端与网站后端是一样的。为移动 App 搭建后端有这些选择:云平台 (AWS、Firebase)、自己的服务器或 MBaaS(移动后端即服务，Mobile Backend as a Service)。 后端开发使用 Ruby 、 Apache 、 Nginx 、 PHP 、 MySQL 、 MongoDB 等技术。后面我们会更多地介 绍这些开发技术。

1.7 公司组织架构

1.7.1 整体公司组织架构图

4.4.2项目成员组成

• 项目经理
• 产品经理
• UI设计师
• 技术总监
• 开发工程师 (web前端，Android，iOS，后端)
• 测试工程师

1.8 工作日常

1.8.1 程序员日常工作

• 对项目经理负责，负责软件项目的详细设计、编码和内部测试的组织实施，对程序员小型软件项目兼 任系统分析工作，完成分配项目的实施和技术支持工作。
• 协助项目经理和相关人员同客户进行沟通，保持良好的客户关系。
• 参与需求调研、项目可行性分析、技术可行性分析和需求分析。
• 熟悉并熟练掌握交付软件部开发的软件项目的相关软件技术。
• 负责向项目经理及时反馈软件开发中的情况，并根据实际情况提出改进建议。
• 参与软件开发和维护过程中重大技术问题的解决，参与软件首次安装调试、数据割接、用户培训和项 目推广。
• 负责相关技术文档的拟订。
• 负责对业务领域内的技术发展动态。

1.8.2 周期性报告

• 日报:每日晨会或者站立会需要
• 周报:本周工作内容总结和下周工作内容计划
• 月报:本月总结和下月计划