一、什么是软件？
软件 == 程序 + 文件
二、什么是软件测试？
1，使用人工或自动的手段来运行或测量软件系统的过程，检验是否满足规定，预期；
2，利用方法对软件的质量或者使用性进行判断和评估的过程；
三、软件测试工程师的工作内容
- 初级 ：寻找bug ，复现bug，定义bug级别，跟踪bug；
- 确认范围 - 定测试方法 - 制定计划-- 测试案例/代码 -测试文档 -测试报告；
- 中级：（知识广度）扎实的测试理论；搭建环境，常用linux命令，xshell 脚本编程，常用sql，接口测试，性能测试，selenium自动化（web）,adb 查看日志，appium
- 高级：（知识深度+ 管理方面经验）项目架构（微服务，区块链，大数据，算法）
全栈之路：测试理论基础 → 常用测试工具 → linux命令 → 数据库sql基础 - 自动化 - 性能
四、常见的软件生命周期模型
| 模型 | 优点 | 缺点 |
| 瀑布模型 | 计划周密（分工明确），按部就班； | 单一流程不可逆转； |
| 敏捷开发 | 快响应，计划变化大，拥抱变化，灵活性高； | （前提要有一个展示性的产品原型）限制开发者创新，不适合大型项目 |
| 大爆炸模型 | 无需计划，简单模型，所需资源很少，易于管理，灵活的开发人员 | 高风险和不确定性，质量无法把握，不适合大型项目 |
| 螺旋模型 | 减少了过多测试，测试不足（产品故障多）所带来的风险 | 风险驱动的；计划变化同时考虑，需要人员多，容易延期；只适合内部开发的大规模软件项目 |
五，软件测试对象：
测试对象是贯穿整个测试过程的:
-
- 软件需求说明
- 软件概要设计
-
- 软件详细设计
- 软件运行环境
-
- 可运行程序
六， 五大要素和两个目标：
要素： 质量、人员、资源、 流程、技术
目标： 测试覆盖率，测试效率
七，软件测试所遵循的原则：
- 测试显示缺陷的存在，但不能证明系统不存在缺陷；
- 穷尽测试是不可能的，应设定及时终止的条件；
- 测试应该尽早进行；
- 缺陷具备群集特性；
- 测试的杀虫剂悖论；（根本原因就是测试人员对测试软件过于熟悉，形成思维定势）
- 测试的二八原则（80%的时间花在20%的重点功能上）；
- 测试活动依赖于测试背景；
八，软件测试阶段：
按测试阶段来分类：单元测试、集成测试、系统测试、验收测试
九、软件开发的几个阶段：
1.项目启动阶段：了解客户需求、配置相关资源
2.项目设计阶段：明确客户需求，确立软件开发、测试的方法
3.项目执行阶段：开发与测试阶段
4.项目竣工阶段：软件的上市、后期维护与技术支持
十、什么是测试用例
????????测试用例是描述输入实际值和预期输出行为或者结果的文档，他同时也标识了测试过程结果与约束。
十一、测试用例几大要素
标识符，测试内容，输入条件，预期结果，测试环境信息，与其他测试用例的依赖关系，
测试用例需要被开发、审阅、使用、维护和保存。
十二，软件测试方法分类
1）白盒、黑盒、灰盒
2）单元测试、集成测试、系统测试、验收测试、回归测试、Alpha 测试、Beta 测试
3）静态测试和动态测试
十三，测试用例设计方法
黑盒测试法：（等价类划分法、边界值、因果图、判定表、错误推测、正交、业务）
白盒(静态测试法，动态测试法（语句覆盖法、判定覆盖、条件覆盖、组合覆盖、路径覆盖）)
补充：
- 等价类划分法 --输入条件和输出条件的等价划分 ; 字符，数字时间，类型
- 边界值分析法 --大于，等于，小于（用这种方法设计出的测试用例发现程序错误的能力最强。）
- 错误推断法 --异常场景（经验）
- 因果图法 --适合于检查程序输入条件的各种组合情况。
- 正交试验分析法 --每个案例只有一个测试点 （参数配置类的软件）
- 状态迁移图法
- 流程分析法 （基础流和分支流）逻辑覆盖程度
如果程序的功能说明中含有输入条件的组合情况，则一开始就可选用因果图法和判定表驱动法。
功能图法也是很好的测试用例设计方法，我们可以通过不同时期条件的有效性设计不同的测试数据。? 对于业务流清晰的系统，可以利用场景法贯穿整个测试案例过程，在案例中综合使用各种测试方法。
十四，怎么保证测试案例覆盖业务功能？
1，首页测试需求覆盖：保证所有需求都已经设计用例；
2，多维度考虑-根据测试特性覆盖：保证所有不同类型已覆盖（功能、易用性、兼容性、弱网、安全性、性能、）；
3，业务场景的覆盖（业务层、接口层等）
4，编写测试用例前，检查相关需求、设计文档是否有问题（功能描述不清，设计逻辑缺陷），如有问题找相关设计或者开发问清楚。
然后整理成需要覆盖的功能列表或者思维导图，功能列表包含新增和修改功能点，性能需求也要列出来（因为要整理对应的性能测试用例），
同时还需要对既有功能进行一个梳理，检查是否会与其他功能有交互，整理出影响点。
把功能列表发给组员，并找时间进行会议评审，主要对功能等进行查漏补缺。
5，最后才行进测试用例编写，注意编写规范。
6，编写完毕后，把测试用例发给组员，开会进行评审，主要对检查点、用例规范进行查漏补缺。
7、执行测试用例过程中，发现用例不完善或者错误，需对测试用例进行及时的修改与调优
8、测试完毕后对漏测的bug进行测试用例补充。
9、统计分析， 要将测试需求、测试用例以及发现的bug关联起来，便于管理和跟踪，同时也便于查看覆盖率。
10、测试人员定期反思成长，积累经验。
十五，性能指标 (多快好省)
并发；延时、响应时间；稳定性（长时间运行）；资源使用率； 思考时间；
十六，测试模型
V模型
流程
需求分析—>概要设计—>详细设计—>软件编码—>单元测试—>集成测试—>系统测试—>验收测试
局限性
- 仅仅将测试放在后半段，忽视了测试对需求的分析和验证
- 违背了测试需要尽早进行的原则
W模型
X模型
H模型
