1.1 软件的分类

1.1.1 软件的定义

        一系列按照特定顺序组织的计算机数据和指令的集合。

        软件 = 数据 + 指令

1.1.2 根据应用场景分类

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

1.1.3 根据软件架构分类

        单机版软件、分布式软件

            单机版软件：office、红警等

            分布式软件：

                    C/S架构软件：客户端需安装专门软件，如QQ 微信等

                    B/S架构软件：客户端为浏览器 ，如百度、hao123等

1.2 软件测试的定义与原则

1.2.1 软件测试的定义

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

1.2.2 软件测试的原则

原则一：测试显示软件存在缺陷

测试只能证明软件中存在缺陷，但并不能证明软件中不存在缺陷。软件测试是为了降低存在缺陷的可能性，即便是没有找到缺陷，也不能证明软件是完美的。

原则二：穷尽测试是不可能的

现在软件的规模越来越大，复杂度越来越高，想做到完全性的测试是不可能的。在测试阶段，测试人员可以根据风险和优先级来进行集中和高强度的测试，从而保证软件的质量。

原则三：测试尽早介入

为什么测试要尽早介入呢，简单的说就是保证软件质量，降低风险和成本。测试人员一般在需求阶段就开始介入，使缺陷在需求或设计阶段就被发现，缺陷发现越早，修复的成本就越小。

原则四：缺陷集群性（2/8原则）

缺陷集群性表明小部分模块包含大部分的缺陷。软件测试中存在Pareto原则：80%的缺陷发现在20%的模块中。

一个功能模块发现的缺陷越高，那存在的未被发现的缺陷也越高，故发现的缺陷与未发现的缺陷成正比。

原则五：杀虫剂悖论

反复使用相同的杀虫剂会导致害虫对杀虫剂产生免疫而无法杀死害虫。软件测试也一样。如果一直使用相同的测试方法或手段，可能无法发现新的bug。

为了解决这个问题，测试用例应当定期修订和评审，增加新的或不同的测试用例帮助发现更多的缺陷。

测试人员不能一直依赖于现有的测试技术，而要不断的提升测试方法以提高测试效率。

原则六：测试活动依赖于测试内容

根据业务的不同，软件测试内部也分为不同的行业，比如游戏行业、电商行业、金融行业。不同的行业，测试活动的开展都有所不同，比如测试技术、测试工具的选择，测试流程都不尽相同，所以软件测试的活动开展依赖于所测试的内容。

原则七：没有错误是好是谬论

有可能99%没有bug的软件也是不能使用的。如果对错误的需求进行了彻底的测试，这种情况就发生了。软件测试不仅是找出缺陷，同时也需要确认软件是否满足需求。如果开发出来的产品不满足用户的需求，即便找到和修复了缺陷也作用不大。

1.3 测试模型的介绍

1.3.1 测试模型

    V模型

       W模型

1.4 软件测试的流程

        阶段名                                              工作内容                                                           产出物

   测试准备阶段                        项目立项、需求分析、需求评审                                需求文档、产品PRD

   测试计划阶段                        编写测试计划、计划评审                                                    测试计划 

   测试设计阶段                        提取测试点、编写测试用例、用例评审                              测试用例

   测试执行阶段                        冒烟测试、执行测试用例、提bug、回归测试                     缺陷报告

   测试完成阶段                         验收测试、编写测试报告、项目上线                                 测试报告

项目立项后，我们先提前介入进入测试准备阶段，进行需求分析、评审，产品经理总结出需求文档和产品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 兼容性测试

    app：

        Android/IOS版本

        厂商

        型号

        分辨率

        屏幕：全屏、水滴屏、刘海屏、曲面屏、折叠屏、双面屏

    web：

        浏览器：四类，根据浏览器内核（78）