什么是软件测试
- 软件测试它就是一个过程
- 测试就是对软件的全方位进行全面的校验.
- 通过测试技术验证软件是不是符合用户的信息.
测试和开发的区别
在工作上的区别:
开发人员通过编程技能来开发和实现这个软件.
测试人员通过测试技能来验证软件是否符合用户需求.
在技术上的要求:
开发人员更加注重深度,而测试人员更加注重广度.
🔥测试和调试的区别
目的: 调试是发现问题和解决问题, 测试是发现问题和验证问题.
人员: 调试是开发人员来完成, 测试是测试 + 开发人员来完成(有一些白盒测试是开发人员完成的).
阶段: 调试是在开发阶段, 测试贯穿整个软件的生命周期(在需求阶段就开始了).
方法: 调试通过Debug,打印日志等. 测试通过白盒测试, 黑盒测试, 接口测试, 自动化测试等.
🔥测试人员需要具备的素质
非技术: 学习能力, 合作能力, 沟通能力, 抗压力, 文字表达能力
技术: 编程能力, 编写测试用例能力.
需求
什么是需求
需求分为两种,一种为用户需求,另一种为软件需求或者功能需求.
用户需求: 就是甲方提出的要求或者终端用户使用时需要实现的效果.
软件需求: 详细描述了开发人员必须要实现的软件功能.
为什么要有需求
需求是开发的标准,也是测试人员编写测试代码的依据.
如何深入理解需求
多参加各种会议,会议中会对产品进行剖析,深入了解产品的细节.
多阅读相关文档,(技术文档, 需求文档, bug库)
测试用例的概念
测试用例就是为了测试向被测试的系统提供的一组集合.里面包含了 测试环境, 操作步骤, 测试数据, 预期结果.测试用例是测试人员测试的依据.也可以减少测试工作的冗余度. 测试用例还是实行自动化的依据.
🔥🔥🔥bug的概念
bug就是程序没有实现用户合理的预期功能的要求.
如何描述一个bug
**1、发现问题的版本 **
开发人员需要知道出现问题的版本，才能够获取对应版本的代码来重现故障。并且版本的标识也有利于
统计和分析每个版本的质量。
2、问题出现的环境 **
环境分为硬件环境和软件环境，如果是web项目，需要描述浏览器版本，客户机操作系统等，如果是
app项目，需要描述机型、分辨率、操作系统版本等。详细的环境描述有利于故障的定位。
3、错误重现的步骤 **
描述问题重现的最短 步骤。
**4、预期行为的描述 **
要让开发人员指导怎么样才是正确的，尤其要以用户的角度来描述程序的行为是怎样的。如果是依据需
求提出的故障，能写明需求的来源是最好的。
要相信：测试人员是最懂需求的。
**5、错误行为的描述 **
描述错误的现象。crash等可以上传log，UI问题可以有截图。
6、其他
某些公司会有一些其他的要求，例如故障的分类：功能故障，界面故障，兼容性故障等。有些有优先级
的分类，严重影响测试需要开发人员优先修改的，可以设置优先级为高。
bug的级别
Blocker（崩溃）Critical（严重）Major（一般）Minor（次要）
bug的生命周期
● New:新发现的Bug，未经评审决定是否指派给开发人员进行修改。
● Open：确认是Bug，并且认为需要进行修改，指派给相应的开发人员。
● Fixed:开发人员进行修改后标识成修改状态，有待测试人员的回归测试验证。
● Rejected：如果认为不是Bug，则拒绝修改。
● Delay:如果认为暂时不需要修改或暂时不能修改，则延后修改。
● Closed：修改状态的Bug经测试人员的回归测斌验证通过，则关闭Bug。
● Reopen：如果经验证Bug仍然存在，则需要重新打开Bug，开发人员重新修改。
无效的bug：open->closed open-rejected-closed
软件的生命周期
需求分析, 计划, 设计, 编码, 测试, 运行维护.
常见模型
瀑布模型
start -> 需求分析 -> 计划 -> 设计 -> 编码 -> 测试 -> end
特点: 是线性的.
优点: 每个阶段干什么都非常的明确
缺点: 发现的问题太晚,会导致人力, 时间资源的浪费.
适用: 比较小的项目.
螺旋模型
特点: 软件进行到每一个阶段都会进行风险分析.
优点: 风险分析可以避免一些问题暴露在线上.
缺点: 风险分析失败会导致问题直接暴露在线上.
适用: 适用与大型的,多风险的项目.
增量与迭代模型的区别
增量是逐快建造,迭代是精益求精. 就向画画: 增量是先画头再画身子,最后画腿. 而迭代是先画整体轮廓再细化.
敏捷
个体与交互重于过程和工具
可用的软件重于完备的文档
客户协作重于合同谈判
响应变化重于遵循计划
在每对比对中，后者并非全无价值，但我们更看重前者。
scrum
角色: scrum由产品经理, 项目经理, 研发团队(前端开发, 后端开发, 测试, 设计)
工作流程:
产品负责人负责整理user story，形成左侧的product backlog。
发布计划会议：product owner负责讲解user story，对其进行估算和排序，发布计划会议的产出
就是制定出这一期迭代要完成的story列表，sprint backlog。
迭代计划会议：项目团队对每一个story进行任务分解，分解的标准是完成该story的所有任务，每
个任务都有明确的负责人，并完成工时的初估计。
每日例会：每天scrum master召集站立会议，团队成员回答昨天做了什么今天计划做什么，有什
么问题。
演示会议：迭代结束之后，召开演示会议，相关人员都受邀参加，团队负责向大家展示本次迭代取
得的成果。期间大家的反馈记录下来，由po整理，形成新的story。
回顾会议：项目团队对本期迭代进行总结，发现不足，制定改进计划，下一次迭代继续改进，已达
到持续改进的效果。
V模型
特点是左边是开发,右边是测试,测试被分为许多类型.
缺点是介入需求太晚了.
W模型
W模型特点：测试的对象不仅是程序，需求、设计等同样要测试，测试与开发是同步进行的
W模型优点：**有利于尽早地全面的发现问题。**例如，需求分析完成后，测试人员就应该参与到对需
求的验证和确认活动中，以尽早地找出缺陷所在。同时，对需求的测试也有利于及时了解项目难度
和测试风险，及早制定应对措施，显著减少总体测试时间，加快项目进度。
W模型缺点：**测试和开发活动也保持着一种线性的前后关系. **上一阶段完全结束，才可正式开始下一个阶段工作。无法支持敏捷开发模式。并不能拥抱变化,不适用于敏捷.
🔥🔥🔥软件测试的生命周期
需求分析 -> 测试计划 -> 测试设计, 测试开发 -> 测试执行 -> 测试评估
如何开始第一次测试
刚进入公司的准备工作:
1、阅读所有项目有关的文档，包括：需求文档、设计文档、用户手册
2、尽可能参加各种项目会议，了解项目的背景、人员组成、尽可能的了解需求和业务。特别针对业务
专业性较强的项目，例如银行业务，需要了解各种业务知识，如高低柜、一二三类账户等、存款、贷款
等。
3、熟悉项目所使用的测试管理工具、配置管理工具，获取对应的地址和登录方式
4、阅读已有的测试方案和测试案例
5、阅读旧有的bug库，了解系统功能。尤其重要的是和现有的测试团队保持一致的故障定级原则
6、了解公司的规范要求，特别是用例编写规范、用例执行规范、bug提交规范、测试工具工具使用规
范等
当第一次测试来临时,我们需要和组长确定:
1、测试的计划是什么？
2、测试的内容是什么？test case有多少？安排了几天执行？有没有自由测试的时间？
3、我要测试的内容开发人员是谁？需求人员是谁？
4、分配给我的测试内容是否需要特殊的测试资源？资源是否满足需要？
在我们确认了以上内容之后，就可以开始测试的执行了
🔥🔥🔥当与开发产生争执时的解决办法
测试经常会遇到这些问题:
这不是bug
这个bug的级别太高了
bug影响不大，暂不修改
当遇到这些问题时,解决方式:
1、先检查自身，是否bug描述不清楚
2、站在用户角度考虑问题 应该让开发人员了解到Bug对用户可能造成的困扰 ，这样才能促使开发人员
更加积极地、高质量地修改Bug。在争执时，可以问一句：如果你是用户，你可以接受么？
**3、BUG定级要有理有据 **
BUG定级时，不仅要参考BUG级别，还要考虑BUG是否会影响到流程，往往用户的BUG级别和我们的
是有区别的，需站在用户的角度定考虑定位级别
4、提高自身的技术和业务水平. 不光要提出问题, 最好也能提出解决方案
5、开发人员不接受时，不要争吵
6、发起三方讨论会
