软件测试就是为了验证软件是否符合用户的需求
1.测试与调试的区别
①目的不同 测试的任务是发现程序中的缺陷； 调试的任务是定位并解决程序中的问题。 ②参与角色不同 测试主要是由测试人员和开发人员来执行，黑盒测试主要由测试人员完成、单元/集成测试主要是由开发人员执行。调试由开发人员完成。 ③执行的阶段不同 测试贯穿整个软件开发生命周期，调试一般在开发阶段。
软件测试与研发的区别
①难易程度 ：开发广度小，专业度高。测试广度大，专业度低 ②薪水 ：中小企业总体比研发低，自动化等专业测试领域和研发基本无差距。大厂研发测试基本无差别 ③发展前景 ：自动化测试、安全测试等领域发展前景和研发基本一致。 ④繁忙程度： 一般比研发轻松，但敏捷模式下差距不大，产品发布前压力比较大 ⑤技能要求 ：测试要求更广泛：业务能力，设计和架构分析能力，测试手段和工具使用，用户模型分析和理 解，编程能力
目的：验证软件有没有问题 原则：以客户为中心，遵循软件测试的规范，流程，标准和要求
满足用户的期望或规定的文档（合同、规范、标准）所需要的的条件和权限 包括用户需求和软件需求 ●软件需求从用户需求转化而来 ●用户需求转换为软件需求的核心是沟通
1.正式文档存在且合理，软件的功能和文档不相符，叫做软件缺陷 2.不存在文档时，用户的需求存在且合理，程序没有满足用户的需求称之为软件缺陷（BUG）
向被测试系统发起的一组操作集合，包含测试环境、测试数据，操作步骤，预期结果，标题、功能米快、前提条件、重要性。
需求分析，计划、设计、编码、测试、运行维护
1.瀑布模型
优点： 强调开发的阶段性； 强调早期计划及需求调查； 强调产品测试。 缺点： 前期的缺陷到后期才有可能比发现，不能适应需求的变化 适用场景：需求比较稳定的项目
2.螺旋模型
优点：强调风险的把握
缺点：风险各项要求较高，对人员，资金，时间的投入较大
适用场景：前期需求不明显，风险大，项目庞大的需求
3.增量模型，迭代模型 场景：一个系统，开发A B C D四个业务模块，两周时间
增量模型：第一周：完成A B模块； 第二周：完成C D模块 迭代模型：第一周：完成四个模块的基础功能； 第二周：补充完成复杂的业务功能
4.敏捷开发模型 ①价值观
个体与交互重于过程和工具 可用的软件重于完备的文档 客户协作重于合同谈判 响应变化重于遵循计划
②scrum（敏捷开发方法）
scrum将产品的开发分解为若干个小sprint(迭代)，其周期从1周到4周不等，但不会超过4周。参与的团队成员一般是5到9人。每期迭代要完成的user story是固定的。每次迭代会产生一定的交付
③角色
PO（产品经理）：product owner负责整理user story(用户故事)，定义其商业价值，对其进行排序，制定发布计划，对产品负责。 SM（项目经理）：scrum master负责召开各种会议，协调项目，为研发团队服务。 ST（研发团队) :scrum Team由不同技能的成员组成，通过紧密协同，完成每一次迭代的目标，交付产品。
④流程
<1> 产品负责人负责整理user story，形成左侧的product backlog。 <2>发布计划会议：product owner负责讲解userstory，对其进行估算和排序，发布计划会议的产出就是制定出 这一期迭代要完成的story列表，sprint backlog。 <3>迭代计划会议：项目团队对每一个story进行任务分解，分解的标准是完成该story的所有任务，每个任务都有 明确的负责人，并完成工时的初估计。 <4>每日例会：每天scrum master召集站立会议，团队成员回答昨天做了什么今天计划做什么，有什么问题。 <5> 演示会议：迭代结束之后，召开演示会议，相关人员都受邀参加，团队负责向大家展示本次迭代取得的成果。期间大家的反馈记录下来，由po整理，形成新的story。 <6>回顾会议：项目团队对本期迭代进行总结，发现不足，制定改进计划，下一次迭代继续改进，已达到持续改 进的效果
⑤敏捷中的测试
特点：轻文档，轻流程、重目标，重产出，拥抱变化 削弱测试用力的作用，进行探索性测试（思维导图）
①V模型
优点：后期测试的每一个阶段对应前期开发的阶段，有明确的依据 缺点：测试在编码之后，导致缺陷的风险在后期才会被发现
②W模型
特点;测试的对象不仅仅是程序，还有需求设计等 优点：有利于项目前期的问题及时发现，避免造成后期开发完成才发现前期的问题 缺点：阶段性较强，不适用于敏捷开发
需求分析→测试计划→ 测试设计、测试开发→ 测试执行→ 测试评估
<1>版本号、测试环境、操作步骤、预期结果、实际结果
<2>BUG级别：崩溃、严重、一般、次要 1、Blocker（崩溃）： 阻碍开发或测试工作的问题；造成系统崩溃、死机、死循环，导致数据库数据丢失，与数据库连接错误，主要功能 丧失，基本模块缺失等问题。如：代码错误、死循环、数据库发生死锁、重要的一级菜单功能不能使用等（该问题 在测试中较少出现，一旦出现应立即中止当前版本测试）。 2、Critical（严重）： 系统主要功能部分丧失、数据库保存调用错误、用户数据丢失，一级功能菜单不能使用但是不影响其他功能的测 试。功能设计与需求严重不符，模块无法启动或调用，程序重启、自动退出，关联程序间调用冲突，安全问题、稳 定性等。如：软件中数据保存后数据库中显示错误，用户所要求的功能缺失，程序接口错误，数值计算统计错误等 （该等级问题出现在不影响其他功能测试的情况下可以继续该版本测试）。 3、Major（一般）： 功能没有完全实现但是不影响使用，功能菜单存在缺陷但不会影响系统稳定性。如：操作时间长、查询时间长、格 式错误、边界条件错误，删除没有确认框、数据库表中字段过多等(该问题实际测试中存在最多） 4、Minor（次要）： 界面、性能缺陷，建议类问题，不影响操作功能的执行，可以优化性能的方案等。如：错别字、界面格式不规范， 页面显示重叠、不该显示的要隐藏，描述不清楚，提示语丢失，文字排列不整齐，光标位置不正确，用户体验感受 不好，可以优化性能的方案等（此类问题在测试初期较多，优先程度较低；在测试后期出现较少，应及时处理）
<3>BUG生命周期 ● New:新发现的Bug，未经评审决定是否指派给开发人员进行修改。 ● Open：确认是Bug，并且认为需要进行修改，指派给相应的开发人员。 ● Fixed:开发人员进行修改后标识成修改状态，有待测试人员的回归测试验证。 ● Rejected：如果认为不是Bug，则拒绝修改。 ● Delay:如果认为暂时不需要修改或暂时不能修改，则延后修改。 ● Closed：修改状态的Bug经测试人员的回归测斌验证通过，则关闭Bug。 ● Reopen：如果经验证Bug仍然存在，则需要重新打开Bug，开发人员重新修改。 无效的bug：open->closed open-rejected-closed
①检查BUG描述是否清楚 ②站在用户的角度说服开发人员 ③BUG定级要有理有据 ④不断提升自己的技能水平 ⑤评审BUG
