什么是软件测试
验证软件是否满足用户的需求（不是以软件测试人员的主观去判断软件的质量的，软件测试是有标准的）
软件测试与软件调试的区别
- 人员不同：软件测试人员有黑盒测试工程师、白盒测试工程师、开发人员；软件调试有开发人员
- 目的不同：软件测试是检查软件的质量；软件调试是程序员为了检查程序是否实现了他（开发人员）想让程序实现的功能
- 阶段不同：软件测试贯穿了整个软件开发的整个过程；软件调试只在开发阶段
一个测试人员所具备哪些素质
- 对软件测试这个岗位感兴趣
- 具备测试相关知识，有一定编程能力，掌握几门语言
- 有团队协作精神、责任感和一定的承受压力能力
概念
什么是需求
- 用户需求：用户想要软件实现的功能，非常简单，没有实现细节
- 软件需求：用户需求的具体细化，是用户需求具体的实现细节，开发人员根据软件需求进行开发
什么是BUG
当且仅当规格说明（用户需求）是存在并且正确的，程序与规格说明之间的不匹配称为软件错误（BUG）
什么是测试用例
是为了实施测试而向被测试的系统提供的一组集合，这组集合包含：测试环境、操作步骤、测试数据、预期结果等要素
开发模型
- 瀑布模型
每个阶段都只执行一次，因此是线性顺序进行的软件开发模式
**优点：**各个阶段比较独立，看中需求分析和软件测试
**缺点：**无法适应需求的变化，测试到编码结束后才介入，导致前期的缺陷无法及时发现，无法及时修正
- 螺旋模型
一般在软件开发初期阶段需求不是很明确时，并且有风险，项目比较庞大的开发
**优点：**强调软件的质量，每一次迭代进行严格的风险分析，评估讨论项目是否有必要进行下去的机会
**缺点：**引入风险管理，投入成本会增加
- 迭代、增量模型
一个系统的四个功能：A模块、B模块、C模块和D模块，四周完成
迭代模型：第一周开发人员完成A、B、C和D四个模块的基础功能，第二周，开发人员在基础功能之上进行细化完善。抗风险能力更强
增量模型：第一周完成A、B模块。第二周完成C、D模块
- 敏捷模型
轻文档、轻流程、重质量、重目标，可以适应需求的变化
敏捷模型中的scrum
开发周期为1-4周，人员为10人以内
scrum角色：
- PO-产品经理（product owner）负责整理客户需求成 user story
- SM-项目经理（scrum master）负责保证整个敏捷流程的顺利实施
- ST-研发团队（scrum Team） 目标是交付一个高质量的可用软件
scrum流程
- 发布计划会议
- 迭代计划会议
- 开发过程中，每日站会
- 产品演示评估会
- 回顾会议
敏捷模型中的测试
- 轻文档
- 快速迭代
软件测试模型
-
软件测试V模型
优点：左边开发的每一个阶段和右边测试的每一个阶段一一对应，是右边测试每一个阶段的一句
缺点：测试在编码完成才介入，前期的错误和风险到后期才能发现，失去及时纠正的机 -
软件测试W模型
优点：测试阶段和开发阶段在两个独立的V模型里面，测试介入比较早，在项目初期就介入，前期风险可以及时被发现
缺点：W模型每一个阶段仍然是一个串行的过程，不能适应需求变化的项目，所以无法应用到敏捷开发
软件测试的生命周期（软件测试的流程）
需求分析——>测试计划——>测试设计、测试开发——>测试执行——>测试评估
- 需求分析阶段：分析需求，细化需求，验证需求的正确性和合理性
- 计划阶段：根据需求编写测试计划/测试方案；规划测试人员数量，规划时间，测试范围，测试目的
- 设计/开发阶段：分析需求，从细化到的需求中提炼功能点，设计测试用例
- 测试执行：执行测试用例，记录BUG
- 测试报告：测试的范围，有多少测试用例，执行了多少，余留多少测试用例用例，发现了多少BUG，修改并验证了多少BUG，遗留BUG以及解决方案
如何描述一个BUG
（1）出现问题的版本号：获取对应版本的代码，并且版本的标识也有利于统计和分析每个版本的质量
（2）出现问题的环境：环境分为软件环境和硬件环境；如果是web项目，需要描述浏览器的版本号，客户机操作系统等，如果是APP项目，需要描述机型、分辨率、操作系统版本等。详细的环境描述有利于故障的定位
（3）测试步骤和测试数据
（4）实际结果
（5）预期结果
如何定义BUG的级别
- Blocker（崩溃）：阻碍开发或测试的问题；造成系统崩溃、死机、死循环、导致数据库数据丢失，与数据库连接错误，主要功能丧失，基本模块缺失等问题。如代码的错误、死循环、数据库发生死锁、重要一级菜单功能不能使用等
- Critical（严重）：系统主要功能部分丧失、数据库保存调用错误、用户数据丢失，一级功能菜单不能使用但是不影响其他功能的测试。功能设计与需求不符，模块无法启动或调用，程序重启、自动退出，关联程序间冲突，安全问题、稳定性等。如：软件中数据保存后数据库中显示错误，用户锁要求的功能缺失，程序接口错误，数值计算统计错误等（该等级的问题出现在不影响其他功能测试的情况下可以继续该版本的测试）
- Major（一般）：功能没有完全实现但是不影响使用，功能菜单存在缺陷但不会影响系统稳定性。如：操作时间长、查询时间长、格式错误、边界条件错误、删除没有确认框、数据库表中字段过多等（该问题实际测试中存在最多）
- Minor（次要）：界面、性能缺陷、建议类问题，不影响操作功能的执行，可以优化性能的方案。如：错别字错误、界面格式不规范，页面显示重叠、不该显示的要隐藏等