一、软件的分类
1.软件的定义
一系列按照特定顺序组织的计算机数据和指令的集合。
软件 = 数据 + 指令 + 文档
2.根据应用场景分类
工具类软件、游戏型软件、媒体型软件、电商型软件等
3.根据软件架构分类----单机版软件、分布式软件
（1）单机版软件：例如红警、office、纸牌、相机等
（2）分布式软件：
C/S架构软件：客户端需要安装专门软件，例如QQ、微信等
B/S架构软件：客户端为浏览器，例如百度、hao123、FireFox等
二、软件测试
1.软件测试的定义
通过人工或自动化方式来验证软件实际结果与用户需求是否一致的过程。
2.软件测试的原则
原则一：测试显示软件存在缺陷
测试只能证明软件中存在缺陷，但并不能证明软件中不存在缺陷。软件测试是为了降低存在缺陷的可能性，即便是没有找到缺陷，也不能证明软件是完美的。
原则二：穷尽测试是不可能的
现在软件的规模越来越大，复杂度越来越高，想做到完全性的测试是不可能的。在测试阶段，测试人员可以根据风险和优先级来进行集中和高强度的测试，从而保证软件的质量。
原则三：要尽早介入测试
为什么测试要尽早介入呢，简单的说就是保证软件质量，降低风险和成本。测试人员一般在需求阶段就开始介入，使缺陷在需求或设计阶段就被发现，缺陷发现越早，修复的成本就越小。
原则四：缺陷集群性（2/8原则）
缺陷集群性表明小部分模块包含大部分的缺陷。软件测试中存在Pareto原则：80%的缺陷发现在20%的模块中。一个功能模块发现的缺陷越高，那存在的未被发现的缺陷也越高，故发现的缺陷与未发现的缺陷成正比。
原则五：杀虫剂悖论
反复使用相同的杀虫剂会导致害虫对杀虫剂产生免疫而无法杀死害虫。软件测试也一样。如果一直使用相同的测试方法或手段，可能无法发现新的bug。
为了解决这个问题，测试用例应当定期修订和评审，增加新的或不同的测试用例帮助发现更多的缺陷。
测试人员不能一直依赖于现有的测试技术，而要不断的提升测试方法以提高测试效率。
原则六：测试活动依赖于测试内容
根据业务的不同，软件测试内部也分为不同的行业，比如游戏行业、电商行业、金融行业。不同的行业，测试活动的开展都有所不同，比如测试技术、测试工具的选择，测试流程都不尽相同，所以软件测试的活动开展依赖于所测试的内容。
原则七：没有错误是好是谬论
有可能99%没有bug的软件也是不能使用的。如果对错误的需求进行了彻底的测试，这种情况就发生了。软件测试不仅是找出缺陷，同时也需要确认软件是否满足需求。如果开发出来的产品不满足用户的需求，即便找到和修复了缺陷也作用不大。
原则八：程序员应避免检查自己的程序
原则九：严格执行测试计划，排除测试的随意性
原则十：应当对每一个测试结果做全面的检查
原则十一：妥善保存测试计划、测试用例、出错统计和最终分析报告，为维护提供方便
原则十二：设计测试用例时，应当包括合理的输入数据和不合理的输入数据
原则十三：测试用例应由测试数据和与之对应的预期输出结果这两部分组成
三、开发与测试模型
1.开发模型
瀑布模型：
特点：1）是线性模型的一种，每一个阶段只执行一次
2）文档驱动
优点：开发的各个阶段比较清晰，当前阶段完成之后，只需关注后续阶段
缺点：1）不响应需求的变化
2）风险往往延至后期才显露，失去及早纠正的机会
快速原型模型：在开发真实系统之前，构造一个原型，在该原型的基础上，逐渐完成整个系统的开发工作
特点：1）快速的构建软件的原型
2）支持用户参与
优点：克服瀑布模型的缺点，减少由于软件需求不明确带来的项目风险开发。
缺点：不适合大型系统的开发（适合开发小型的、灵活性高的系统）。
生命周期：如下图
增量模型：把待开发的软件系统模块化，第1个增量往往是产品的核心，将每个模块作为一个增量组件，从而分批次地分析、设计、编码和测试这些增量组件。
敏捷开发：先选择产品，再进行开会、对产品计划，然后对任务进行分工，分工后开始按照计划执行，然后就做出了新的功能模块，然后再进行演示、回顾，最后再领取新的任务，依次循环。
2.测试模型
2.1 V模型
V模型介绍：
1）V模型是最具有代表意义的测试模型，最早是由Paul Rook在20世纪80年代后期提出，由英国国家计算机中心文献中发布，旨在改进软件开发的效率和效果。
2）V模型本身是软件开发中瀑布模型的变种，它反映了测试活动与分析设计的关系
3）V模型标明了测试过程中本身存在的不同阶段，从左到右，描述了开发过程和测试过程间的阶段对应关系。
优点：测试V模型既包含了底层测试又包含了高层测试。
缺点：当需求变更时将会导致返工量非常大，模型灵活性比较低。
V模型示意图：
2.2 W模型
W模型介绍：
测试伴随着整个软件开发周期，并且测试的对象不仅仅是程序，需求和设计同样要测试。
优点：
1）强调测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，还包括需求和设计。
2）更早的介入测试，能尽早的发现缺陷进行修复。
缺点：对于测试技术要求高，实践起来困难。
W模型示意图：
四、软件测试的流程
- 需求分析与评审—>保证需求正确与准确、PM(产品经理)、RD(开发人员)、QA(测试人员)理解无误
- 测试计划与测试方案—>明确测试范围、目标、人员、环境，评估工作量，做人员与进度的安排
- 测试用例设计—>根据等价类划分法、边界值法、判定表法 用例设计
- 测试用例评审—>测试用例覆盖是否全面、测试用例编写是否清晰易读
- 执行测试用例—>先做冒烟测试，在执行系统测试
- 缺陷提交与追踪—>提交bug到缺陷平台，追踪bug，对bug做回归测试
- 生成测试报告—> 参与测试报告，把自己的测试过程写上去
五、软件测试的分类
1.按技术划分：
黑盒测试：又称数据驱动测试，完全不考虑程序内部结构和内部特性，注重于测试软件的功能需求，只关心软件的输入数据和输出数据。
白盒测试：指的是把盒子打开，去研究里面的源代码和程序结构，进行测试。
灰盒测试：基于程序运行时的外部表现同时又结合程序内部结构来设计测试数据的测试方法
2.按阶段划分：
单元测试：又称模块测试。对软件的组成单位进行测试，其目的是检验软件基本组成单位的正确性。
集成测试：单元测试后，将单独的模块按照设计要求组装成为子系统或系统，作为整体进行测试的测试方法。
系统测试：集成测试后，将软件系统看成是一个系统的测试。包括对功能、性能以及软件所运行的软硬件环境进行测试。
验收测试：系统测试后以用户测试为主，或有测试人员共同参与检验软件质量的测试方法。
单元、集成、系统、验收测试比较
3.按内容划分：
3.1 功能测试
界面测试：测试用户界面的功能模块的布局是否符合客户使用习惯，界面操作便捷性、导航简单易懂性的测试。
业务逻辑测试：在基本的功能点都已合格的基础上，准备多种测试数据，来驱动各种约束条件下业务流程，确定最终输出的结果是否符合预期的测试。
易用性测试：指用户使用软件时是否感觉方便的测试
3.2 性能测试
压力测试：压力测试是在高并发情况下，持续一段时间，测试系统的稳定性和容错能力。
通常要进行软件压力测试的资源包括内部内存、CPU、磁盘空间和网络带宽。
负载测试：通过自动化工具来持续对系统增加负载，发现系统的性能问题，查看系统是否达到要求的性能指标。在测试中找出各种bug，例如：内存管理bug，内存泄露bug，缓冲器溢出bug等。
并发测试：是一个负载测试和压力测试的过程，即逐渐增加并发用户数负载直到系统的瓶颈，通过分析资源监控指标等来确定系统并发性能
3.3 兼容性测试
app
Android/IOS版本、厂商、型号、分辨率、
屏幕：全屏、水滴屏、刘海屏、曲面屏、折叠屏、双面屏
web
浏览器：四类，根据浏览器内核（78）
4.按其他划分：
冒烟测试：验证系统的核心功能是否能够正常运行的测试方法。
回归测试：指修改了旧的代码之后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。
随机测试：是根据测试说明书执行用例测试的重要补充手段，是保证测试覆盖完整性的有效方式和过程。 随机测试主要是对被测软件的一些重要功能进行复测，也包括测试那些当前的测试用例没有覆盖到的部分。
安全性测试：通过不同的测试方法，检验程序、网络、数据库安全性的测试方法。
探索性测试：碰到问题时能随机应变，强调测试人员的主观能动性明确整体的测试计划的测试方法。
Alpha测试：俗称内测，α测试。内部环境下的测试；开发人员或测试人员在现场。
Beta测试：俗称外测、公测，β测试。生产环境下的测试；开发人员和测试人员都不在现场。