软件分为：
1、软件分为：系统软件和应用软件（测试对象）
系统软件: 系统软件是生成、准备和执行其他程序所需的一组文件和程序。如操作系统、Windows、数据库SQL server、
驱动程序、Java语言系统编译环境
应用软件：计算机用户为了解决某些具体问题而购买的、开发或研制的各种程序或软件包。eg：APP、QQ、vx
1.1、应用软件
C/S：client-server：就是我们一定要安装一个客户端你才能使用的软件
缺点：每次更新都需要更新服务端和客户端，比如说大超市收银系统每次更新每台电脑都必须重装客户端，特别是有分店的
情况，人力物力财力都很大
B/S:browser-server：只需要一个浏览器，就可以访问服务的
优点：只需要更新服务器，不需要更新浏览器，用户主动性比较高，比如:天猫、淘宝
2、软件测试的定义：
1983年，IEEE就提出的软件工程的标准术语，定义：使用人工和自动的手段来运行和测试某个系统的 过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别。
2.1、我们为什么要做软件测试，它的目的在于：
1)软件测试为了发现程序（软件)存在的代码或业务逻辑错误
2)软件测试为了检验产品是否符合用户需求
3)软件测试为了提高用户体验
3、软件测试的分类
3.1、按软件测试的技术划分
白盒测试、黑盒测试、灰盒测试（介于黑盒和白盒之间）-->代码逻辑实现、输入输出、接口测试API
白盒测试：基于软件内部设计和程序实现的测试方法（代码层面）。不仅仅关注输入与输出的结果正确性，同时还关注程序是
如何处理的
黑盒测试：就是把所有的功能和逻辑接口都放在一个盒子里面，但是看不到里面的逻辑与走向的，你只能通过盒子的外表进行
测试。黑盒测试是指在测试过程中只关注输入和输出，如果输入一个测试数据，输出的结果是正确的，
我们就认为这个功能是正确的，也叫数据驱动测试。
3.2、按测试对象是否运行划分
动态测试、静态测试（文档检查、代码走查）
3.3、按不同的测试手段划分
手工测试、自动化测试（jmeter/代码走查Python）
3.4、按测试包含的内容划分
功能测试、界面测试、安全测试、兼容性测试、易用性测试、性能测试等
功能测试：测试软件的功能是否符合需求。通常采用黑盒测试方法，一般由测试人员独立执行。
界面测试：简称UI测试，测试用户界面布局是否合理，整体风格是否一致，界面文字是否正确，命名是否统一，页面是否美
观，文字、图片组合是否完美等。
安全性测试：测试该系统防止非法入侵能力。
兼容性测试：测试该软件与其他软件硬件的兼容能力。
易用性测试：测试软件是否易用，主观性比较强，一般要根据很多用户的测试反馈信息，才能评价易用性（参考市面上同类型
的比较成熟的产品、界面、习惯性操作、操作易用简单）
3.5、按测试执行阶段划分
单元测试、集成测试、系统测试、验收测试（正式验收、Alpha测试、Beta测试）
单元测试：主要是测试程序代码，为的是确保各单元模块被正确的编译，比如有具体到模块的测试，也有具体到类、
函数、方法的测试等。（主要用到白盒测试，一般是开发自主测试）
集成测试：单元测试之后，将各单元组合成完整的体系，测试软件单元之间的接口是否正确、数据能否正常传递，（比如
说登录和充值这两个功能是否能够连通：主要用灰盒测试，开发或者测试做）
系统测试：把软件系统搭建起来，按照需求规格说明书说明中所要求，测试软件其性能功能等是否和用户需求相符合，在
系统中运行是否存在漏洞等（根据测试用例，进行完整的系统测试，由测试人员独立完成）
验收测试：主要是用户在拿到软件的时候，在使用现场，会根据前边提到的需求以及规格说明书说明来做相应的测试，
以确定软件达到符合效果的（用户对软甲进行验收（正式验收+alpha+beta测试））
Alpha测试：一种前期的用户测试，软件产品刚研发出来前期，公司内部组织员工及部分真实用户，模拟实际操作环境（环
境测试）下进行验收测试（内测）。测试和开发在场。
Beta测试：一种后期用户测试，此时系统已经通过内部测试，大部分错误已经改正，即将正式发行，在一个或多个真实环境下
发布版本，真实用户进行测试（公测），测试和开发不在场。
3.6、其他测试
冒烟测试、回归测试、探索性测试/自由测试（测试思维）
冒烟测试：冒烟测试的对象是每一个新编译的需要正式测试的软件版本，目的是确认软件基本功能能正常操作，进行后续的正
式测试工作。
回归测试：指错误被修正后或软件功能、环境发生改变后进行（开发修改）的重新测试，确认修改部分不会对其他功能造成影
响。
4、软件的生命周期
软件生命周期是软件开始研制到最终废弃不用所经历的每一个阶段。
4.1、瀑布型生命周期模型
在1970年人类整理了第一个软件生命周期，即瀑布型生命周周期模型也叫瀑布模型。规定了它们自上而下、相互衔接的固定次序，如同瀑布流水、逐级下落，具有顺序性和依赖性。每个阶段规定文档并需进行评审。
问题定义及规划-->需求分析-->设计-->编码-->测试-->运行维护
问题定义及规划 ：主要确定软件开发目的及其可行性，制定项目总体开发计划；
需求分析（产品）：在确定软件开发可行的情况下，对软件需要实现的各个功能进行详细的分析，明确客户的需求，输出需求
规格说明书+原型图，提交评审。召开需求评审会议（开发测试运维UI配置管理人员等在场）
设 计（开 发） ：把需求分析得到的结果转换为软件结构和数据结构，形成系统框架。
概要设计：主要是框架的实现，指搭建架构、表述各个模块功能、模块接口连接和数据传递的实现等多项事务。
详细设计：对概要设计中表述的各个模块进行深入分析等，其中需要包含数据库设计说明。
编码（开发）：按照详细设计好的模块功能表，编程人员编写出计算机可以运行的程序代码。
测试：在软件设计完成后要经过严密的测试，以发现软件在整个设计过程中存在的问题加以纠正，测试的方法主要有白盒测试
跟黑盒测试。建立详细的测试计划并严格按照计划进行。
a.单元测试
b.集成测试
c.系统测试
d.验收测试
运行维护：软件维护是软件生命周期中持续时间最长的阶段，在软件开发完成并投入使用后，由于多方面的原因。软件不能继
续适应用户的需求，要延续软件使用寿命，就必须对软件进行维护。软件维护主要包括纠错性维护和改进性维护两
个方面。
4.2、V模型
RAD[Rap Applicationb Development,快速应用开发]模型是软件开发过程中的一个重要模型，由于其模型构图形似字母V，所以又叫软件开发的V模型，它通过开发和测试同时进行的方式来缩短开发周期，提高开发效率。
用户需求 <-- 验收测试
需求分析 <-- 系统测试 系统测试用例根据需求说明书编写出来的
概要设计 <-- 集成测试 集成测试用例根据概要设计中模块功能及接口等实现方法编写出来的
详细设计 <-- 单元测试 单元测试的测试用例是和详细设计一起出现的，在研发人员做详细设计的时候，
编码和实现 相应的测试人员也就把测试用例写出来了。
4.3、敏捷开发模型
从1990年代开始逐渐引起广泛的关注，是一种以人为核心、、迭代、循序渐进的开发方法，强调以人为本、专注于交付对客户有价值的软件，是一个用于开发和维持复杂产品过程的框架，就是把一个大项目分为多个相互联系，但也可以独立运行的小项目，并分别完成，在此过程中软件一直处于使用状态。（类似于微信、社交类软件：20个功能花1年时间，第一个迭代版本：选取优先级最高的几个功能，花3个月的时间，第二个迭代版本花3个月时间这样子.....）
5、 软件测试工作流程
需求分析 ----> 需求规格说明书
需求评审（产品需求人员、开发人员、测试人员、配置管理人员）
完成开发计划后
召开会议，确定 开发编写开发计划 测试编写测试计划
项目开发周期安排
概要设计、详细设计 编写测试用例
编写代码并自测 用例评审（提前发布评审通知，产品需求人员、开发人员、测试人员、配置管理人员）
提交测试 部署测试环境（硬件软件环境提前准备好，运维、开发、测试）
冒烟、正式测试
提交bug并跟踪
（经过2-4轮测试，达到发布要求） 测试通过 ---> 测试报告
发布上线
5.1、软件测试的基本流程
测试需求分许阶段：参与需求评审会议。阅读需求，理解需求，主要是对业务的学习，分析需求点。
测 试 计 划 阶 段：主要任务是编写测试计划，参考软件需求规格说明书、项目整体计划、内容包括测试范围（来自需求
文档）进度的安排，人力物力的安排，人力物力的分配，整体测试策略的制定，和风险的评估与规措
施有一个制定，一般有测试负责人编写（其他人也可能会参与相关的评审工作）。
测试设计阶段：主要任务是编写测试用例，会参考需求规格说明书（原型图）概要设计、详细设计等文档，有不明确的也会
及时和开发和产品经理沟通。用例编写完成后会进行评审。
测试执行阶段：首先搭建测试环境，执行预测（冒烟），以判定当前版本可测与否，如果预测通过，进入正式测试，遇到问题
提交bug到缺陷平台，并且对bug进行跟踪，直到被测试软件达到测试需求要求，没有重大bug，测试结束
（完善测试用例）
测试评估阶段：出测试报告，对整个测试的过程和版本质量做一个详细的评估，确认是否可以上线。
6、测试需求分析
测试需求是什么？
a、测试需求主要解决‘测什么’的问题，一般来自需求规格说明书中原始需求
b、测试需求应全部覆盖已定义的业务流程，以及功能和非功能方面的需求
6.1、案例：
运行条件：用户未注册
输入：访问网站-->点击注册
主流程
a、点击注册按钮
b、用户输入手机号码，图片验证码、密码、勾选同意协议，点击下一步、
规则约束
业务处理流程：c、图片验证码为4位字母或数字字母组合
d、短信验证码为4位数字、有效期位60s
e、密码长度8-16位、数字、字母、符号至少包含两种
其他流程
f、支持首页跳转
g、支持投标页面跳转
a、弹框显示“欢迎加入蜂群”
b、选择加入蜂群，输入蜂群名称，点击确定，加入蜂群申请成功
输出：c、选择系统自动分配，直接加入系统分配的蜂群
d、注册成功
6.2、测试点思路步骤：（正常+异常）
1）、正常功能：是否可以正常提交
2）、单个输入项验证（正常+异常）
规则：按顺序从上到下，对每一个输入项进行验证
a、数据长度、数据类型验证，必填项验证、重复
b、限制约束验证
c、隐形需求、充分熟悉产品业务/背景，挖掘隐形需求
3）功能交互验证
模块之间传递的信息和数据，对存在功能交互的功能选项
4）非功能性测试：
界面、易用性、兼容性、安全性、性能压力等
7、测试用例方法
7.1、等价类划分法
等价类划分法是一种典型的、重要的黑盒测试方法，是指某个输入域的子集合中。在该子集合中，所有的输入数据对于揭露软件中的错误都是等效的。
等价类划分有：有效等价类和无效等价类。
eg：微信红包
按数据划分：有效0.01-200（中小数位数不超过2位），无效 < 0.01或者 > 200 或者 0.01-200中的小数位数
超过两位数；
按数据类型组成划分：
有效：数字； 无效：非数字；
按是否为空划分：
有效：不为空；无效：为空。
7.1.1 等价类划分法用例设计原则:
1)划分有效及无效等价类，为每一个等价类规定一个唯一的编号
2)设计一个新的测试用例（数据），使其尽可能多的覆盖尚未覆盖的有效等价类，重复这一步，直到所有的有效等价类都
被覆盖为止；
3)设计一个新的测试用例（数据），使其仅覆盖一个尚未被覆盖的无效等价类，重复这一步骤，直到所有的无效等价类都
被覆盖为止。
7.2、边界值分析法
边界值分析法是对等价类划分法的一个补充，边界值一般都是从等价类的边缘值去寻找。边界值分析法的基本思想：
正好等于、刚刚大于、刚刚小于边界的值作为测试数据；
注意：0是一个特殊值，我们在考虑边界值的时候同时也要考虑这个特殊值，负数
7.2.1 边界值的作用
人们从长期的测试工作经验得知，大量的错误是发生在输入或者输出范围的边界上，而不是在输入范围内部，因此针对
各种边界情况设计测试用例，可以查出更
多错误。
7.2.2、等价类划分法/边界值分析法常见的运用场景
a、输入条件规定的取值范围或值的个数的情况（类似最小 < x < 最大、最小 < x、最大 > x）；比如用户名长度红包
金额数值输入范围
b、在输入条件是true和false两种状态的情况下，比如勾选、开关设置
c、在下拉列表包含多个选项的情况，比如城市下拉选项（第一个、最后一个、中间一个）+常用选项
d、在规定了输入数据必须遵守的规则的情况下，可确立一个有效等价类（符合规则）和若干个无效等价类（从不同
角度违反规则 ）
以上除了等价类之外同时会涉及边界值的分析，边界值还包括：
a、报表数据的第一行、最后一行、中间一行；
b、屏幕上光标在最左上、最右下位置
8、场景法
场景法就是通过场景描述的业务流程（业务逻辑），也包括代码实现逻辑，设计用例来遍历场景（路径），验证软件
系统功能的正确性。
8.1、如何使用场景法
a、画出流程图（需求中的业务流程图）
矩形：表示步骤（操作、输入、输出结果）
菱形：判断（Y/N）
箭头：数据流向
b、场景全部进行用例覆盖
【注意：场景法的重点是测试流程，因此每个流程一个用例验证即可，流程测试没有问题并不能说明系统功能没有问题了，还需要针对单步的功能进行测试，只有单个的功能点和流程测试才算充分的测试】
9、错误推测法（白话：反推法）
基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性的设计测试用例的方法；
它的要素：经验、直觉、知识；
10、软件测试用例编写
什么是测试用例：
测试用例是为项目需求而编制的一组测试输入,执行条件以及预期结果，以便测试某个程序是否满足客户需求，（每一个测试点的数据和步骤设计）
测试用例的重要性：
10.1、测试用例是软件测试的核心
软件测试的重要性是毋庸置疑的，测试用例是测试工作的指导，是软件测试质量稳定的根本保障。影响软件测试的因素很多，
