软件测试的目的和原则
目的：验证软件是否满足用户的需求
原则：以客户为中心，遵循软件测试的规范、流程、标准和要求
- 好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案。
- 成功的测试是发现了至今为止尚未发现的错误的测试。
- 测试并不仅仅是为了找出错误。通过分析错误产生的原因、阶段及错误发生的趋势。
- 帮助项目管理者了解当前软件开发过程中的缺陷，以便及时纠错、改进。
- 帮助测试人员设计出有针对性的测试方法，改善测试的效率和有效性。
- 让开发人员知道错误产生的重灾区，加强自测试，
- 让客户清楚我们专业的质量保证团队，可以向他们提交一份满意的答卷。。
- 没有发现错误的测试也是有价值的，完整的测试是评定软件质量的一种方法。
- 根据测试目的的不同，还有回归测试、压力测试、性能测试、安全测试等，分别为了检验修改或优化过程是否引发新的问题、软件所能达到处理能力和是否达到预期的处理能力等。
- 软件测试为了建立软件的信心。
- 从测试的目的出发，大概可以分为两类：为了验证程序能正常工作的测试；为了验证程序不能正常运行的测试
软件需求
**定义：
1.用户解决问题或达到目标所需条件或权能(Capability)。
2.系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能。
3.一种反映上面(1)或(2)所述条件或权能的文档说明。它包括功能性需求及非功能性需求，非功能性需求对设计和实现提出了限制，比如性能要求，质量标准，或者设计限制
大多数软件公司，会有两部分需求：
- 用户需求：用户想要软件实现的功能
- 软件需求：满足用户的期望或者合同规定的标准，规范，文档所需的条件和权限
Bug
软件功能和用户需求不一致
软件规格功能与软件说明书不符
描述Bug
-
发现问题的版本
开发人员需要知道出现问题的版本，才能够获取对应版本的代码来重现故障。并且版本的标识也有利于统计和分析每个版本的质量。 -
测试环境
环境分为硬件环境和软件环境，如果是web项目，需要描述浏览器版本，客户机操作系统等，如果是app项目，需要描述机型、分辨率、操作系统版本等。详细的环境描述有利于故障的定位。 -
错误步骤和测试数据
描述问题重现的最短步骤和测试的所有数据。 -
预期结果
要让开发人员指导怎么样才是正确的，尤其要以用户的角度来描述程序的行为是怎样的。如果是依据需求提出的故障，能写明需求的来源是最好的。
要相信：测试人员是最懂需求的。 -
错误日志
描述错误的现象。crash等可以上传log，UI问题可以有截图。 -
其他
某些公司会有一些其他的要求，例如故障的分类：功能故障，界面故障，兼容性故障等。有些有优先级的分类，严重影响测试需要开发人员优先修改的，可以设置优先级为高。 -
不要把多个bug放到一起
在无法确认是同一段代码造成的故障时，不要将bug放在一起提交。
Bug级别
-
崩溃：
系统运行阻断，严重影响开发人员和测试人员的工作，需要立即修复线上的bug，回退到一个稳定的版本 -
严重级别
系统可以运行，但不稳定，如果继续运行下去，可能产生严重后果，例如：直播画面失真 -
一般级别
系统可以稳定运行，但次要功能没有实现，影响用户体验 -
次要（建议性）级别
影响用户视觉体验（例如：界面文字提示，图像排版等）
Bug生命周期
New:新发现的Bug，未经评审决定是否指派给开发人员进行修改。
● Open：确认是Bug，并且认为需要进行修改，指派给相应的开发人员。
● Fixed:开发人员进行修改后标识成修改状态，有待测试人员的回归测试验证。
● Rejected：如果认为不是Bug，则拒绝修改。
● Delay:如果认为暂时不需要修改或暂时不能修改，则延后修改。
● Closed：修改状态的Bug经测试人员的回归测斌验证通过，则关闭Bug。
● Reopen：如果经验证Bug仍然存在，则需要重新打开Bug，开发人员重新修改。
无效的bug：open->closed open-rejected-closed
测试用例
定义：测试人员向被测试系统发起的一组集合，其中包括：
- 测试数据
- 测试平台
- 测试步骤
- 预期结果
软件开发的生命周期
软件开发的模型
瀑布模型：
优点：瀑布模型的每一个阶段都只执行一次，因此是线性顺序进行的软件开发模式，强调开发的阶段性； 强调早期计划及需求调查； 强调产品测试
缺点：依赖于早期进行的唯一一次需求调查，不能适应需求的变化，风险往
往迟至后期的测试阶段才显露，因而失去及早纠正的机会
螺旋模型
优点：强调严格的全过程风险管理。 强调各开发阶段的质量。 提供机会检讨项目是否有价值继续下去
缺点：引入非常严格的风险识别、风险分析和风险控制，这对风险管理的技能水平提出了很高的要求。这需要人员、资金和时间的投入
增量、迭代
特点：增量开发能显著降低项目风险，结合软件持续构建机制，构成了当今流行的软件工程最佳实践之一。增量开发模型，鼓励用户反馈，在每个达代过程中，促使开发小组以一种循环的、可预测的方式驱动产品的开发。因此，在这种开发模式下，每一次的迭代都意味着可能有需求的更改、构建出新的可执行软件版本，意味着测试需要频繁进行，测试人员需要与开发人员更加紧密地协作
定义：
- 增量通常和迭代混为一谈，但是其实两者是有区别的。增量是逐块建造的概念，例如画一幅人物画，我们可以先画人的头部，再画身体，再画手脚……
- 迭代是反复求精的概念，同样是画人物画，我们可以采用先画整体轮廓，再勾勒出基本雏形，再细化、着色
敏捷
敏捷开发有很多种方式，其中scrum是比较流行的一种
scrum里面的角色：
scrum由product owner(产品经理)、scrum master(项目经理)和team(研发团队)组成：
- 其中product owner负责整理user story(用户故事)，定义其商业价值，对其进行排序，制定发布计划，对产品负责。
- scrum master 负责召开各种会议，协调项目，为研发团队服务。
- 研发团队则由不同技能的成员组成，通过紧密协同，完成每一次迭代的目标，交付产品。
迭代开发
与瀑布不同，scrum将产品的开发分解为若干个小sprint(迭代)，其周期从1周到4周不等，但不会超过4周。参与的团队成员一般是5到9人。每期迭代要完成的user story是固定的。每次迭代会产生一定的交付
scrum的基本流程
- 产品负责人负责整理user story，形成左侧的product backlog
- 发布计划会议：product owner负责讲解user story，对其进行估算和排序，发布计划会议的产出就是制定出这一期迭代要完成的story列表，sprint backlog
- 迭代计划会议：项目团队对每一个story进行任务分解，分解的标准是完成该story的所有任务，每个任务都有明确的负责人，并完成工时的初估计
- 每日例会：每天scrum master召集站立会议，团队成员回答昨天做了什么今天计划做什么，有什么问题
- 演示会议：迭代结束之后，召开演示会议，相关人员都受邀参加，团队负责向大家展示本次迭代取得的成果。期间大家的反馈记录下来，由po整理，形成新的story
- 回顾会议：项目团队对本期迭代进行总结，发现不足，制定改进计划，下一次迭代继续改进，已达到持续改进的效果
软件测试的生命周期
- 需求分析：验证需求的正确性和合理性
- 测试计划：规划测试人员的数量，测试的时间，测试范围和测试目的
- 测试设计、开发：分析需求，设计测试用例
- 测试执行：记录Bug，执行测试用例
- 测试报告：测试范围，发现Bug，开发人员修改Bug，以及遗留的Bug，后续解决方案
软件测试的模型
软件测试的V模型
优点：开发的每个阶段与测试的每个阶段一一对应，是测试的依据
缺点：测试介入晚，导致前期的错误和风险发现晚，不适应需求变化的项目
W模型（双V模型）
优点：软件开发与测试同时进行，风险发现及时
缺点：不能适应需求变化，不适用敏捷开发
