软件测试-基本概念
1.什么是软件测试
测试指的是对我们生产出来的产品特性进行一些校验，例如对传感器、手机等的测试，而软件测试是对我们开发出的软件进行校验是否存在问题，测试软件特性是否符合用户需求。
2.软件测试的基本概念
软件测试的基本概念包括需求、测试用例、bug。
2.1什么是需求
分为两大类，分别是用户需求和软件需求。
用户需求：由用户提出的需求，比如用户要求制作一个点餐小程序等。该需求一般比较简略。自研产品的话，一般由产品经理提出需求。
例如：用户对点餐小程序提出需求
软件需求/功能需求：将用户需求转化为软件需求，详细描述开发人员需要实现的功能。
注意：用户需求不等于软件需求。用户需求不一定合理、需要对用户需求进行提取和分析。
软件需求是我们测试人员进行测试工作的基本依据，而用户需求不能。
2.2什么是测试用例
测试人员在执行测试前需要编写测试用例，测试用例的质量与产品的质量具有很大的关联关系，一份好的测试用例可以降低软件在线上环境出现问题的概率。但是任何测试样例都不能不能保证是完美的。
例如：对搜索框编写测试用例。
测试用例主要解决两个问题：测试什么、怎么进行测试。
测试用例的要素：测试环境、测试步骤、测试数据、预期结果等要素。
2.3什么是bug
bug的由来：格蕾丝·赫柏1945年9月9日，格蕾丝使用的Mark Ⅱ出现故障，导致工作无法进行。经过了近一天的检查，格蕾丝找到了故障的原因：继电器中有一只死掉的蛾子。蛾子被夹了出来。后来，”bug” (小虫) 和”debug” (除虫) 这两个本来普普通通的词汇成了计算机领域中特指莫明其妙的“错误”和“排除错误”的专用词汇而流传至今，而格蕾丝·赫柏也因此成了第一个发现“bug”的人。
软件缺陷的概念和界定：
当且仅当存在规格说明且正确时，程序与规格说明之间不匹配就是错误的，可以提出bug。
例如：登录页面，规格说明要求昵称为4-12个字符，而测试时发现2个字符也能注册成功，可以认定为bug。
当规格说明没有提到的功能，判断标准以用户体验为准，当程序没有实现用户合理预期的功能，也可以认为是软件错误，可以提出bug。
例如：选择框供选项的元素非常多，几十甚至几百个，影响用户体验，也能提出bug。
3.开发模型
开发模型：可以理解为开发流程/项目推进流程。软件从没有到上线的过程（软件的生命周期）。
软件的生命周期：需求分析->计划->设计->编码->测试->运行维护
需求分析：对用户需求进行分析、市场分析、技术分析。
计划：什么时候开始动工，什么时候结束，不同模块需要的时间等。
设计：将软件需求进行拆分，每个模块有谁来管理，设计哪些接口，采用哪些技术，使用什么框架等待。
编码：由开发人员参考需求文档和技术文档来进行编码。
执行测试：测试人员参考测试案例执行测试。
运行维护：
- 修复性维护，对项目中未发现的文件进行修复。
- 完善性维护：对功能进行完善，增强功能或预防维护。
3.1瀑布开发模型
瀑布模型是其他模型的基础框架，一个阶段结束才能开始下一个阶段，线性顺序进行的软件开发模式，
缺点：
- 很多风险往往后期的测试阶段才被发现。失去尽早纠正的机会（没有充分的了解客户需求，导致在开发阶段花费了大量时间和资源开发了一个不符合用户实际要求的程序，导致需要更多的时间来修复问题）
- 测试在后期开展，需要足够的时间来测试，否则容易造成测试不充分，软件问题直接暴露给客户。
- 运行的产品很迟才能被看到，不能够很好的迎接变化（变化需要消耗更多的时间和资源）。
使用场景：需求固定的小型项目
3.2螺旋模型
采用渐进式的开发模型，在瀑布模型的基础上添加了风险分析，然后生成新的原型。增加了风险分析阶段，团队需要耗费更多的时间和资金。
适用场景：初期阶段需求不确定，变化概率大的大型项目。
计划：制定一个详细的项目计划，包括项目目标、时间表等等。
风险分析：对潜在的风险进行评估、识别和管理，可能包含技术风险、需求风险等等。可以制定相应的风险应对策略。
原型阶段：根据计划阶段确定的需求和目标，构建一个可交互的软件原型，能够展示系统关键功能以及交互流程。通过原型，尽早的发现潜在的设计问题，验证技术可行性。
产品实施阶段：开发团队将原型转为实际的软件产品，并进行全面的测试。保证软件的质量。
3.3增量模型和迭代模型
增量模型：将项目进行模块化，使其每一个功能都能够独立开发和上线。
迭代模型：先完成功能的基础版本，在经历一次次的迭代优化，直到功能完善。
3.4敏捷模型
软件开发敏捷宣言特点：
- 强调人与人之间的沟通
- 轻文档
- 重视目标
- 重视产出
敏捷开发有很多种方式scrum是比较流行的一种。
scrum中的角色：
- 产品经理：负责整理用户需求，定义其商业价值等等
- 项目经理：负责召开各种会议，协调项目进度。
- 研发团队：紧密配合、完成每一次迭代交付产品。
迭代开发：scrum将产品的开发分解成若干个小的迭代，周期不等，一般不超过四周，每周要完成的需求是固定的。每一次迭代产生一定的交付。
scrum的基本流程：
- 需求发布会议：确定本次迭代要实现的需求。
- 迭代计划会议：将需求拆分成一个个任务，明确每个任务对应的负责人等等。
- 每日会议：回答三个问题，昨天做了什么？今天要做什么？遇到了什么问题。
- 演示会议：一次迭代结束后，展示完成的工作。
- 回顾会议：讨论并反思本次迭代中的优点和不足，以及需要改进的地方。
4.测试模型
软件测试的什么周期：需求分析->测试任务->测试设计于开发>-执行测试->测试评估
4.1V模型
明确了测试有不同类型，而且每个类型和前期的开发工作相对应。
缺陷：测试后置
4.2W模型
测试从最开始就介入，有利于尽早的发现问题。但是开发和测试虽然是同步的，但是仍然存在着前后的线性关系。
不支持敏捷模型。
