测试的基本流程详解

测试

1.什么是软件测试？
软件测试

2.测试是对软件测试的度量，
软件测试是否满足用户的需求
软件测试是按照一定的评判标准（需求）来进行的活动。
2.软件测试和软件开发的区别？
软件开发：用程序开发得方式把用户的需求实现成一个一个软件（APP,web网站，小程序。。。。）角色：程序开发人员
软件测试：测试人员进行测试查看是否满足需求
测试和调试得区别：
1.软件测试和软件调试得区别：----
软件调试在软件开发过程中进行得
目的：
软件测试是查看软件是否满足用户得需求；
软件调试是开发人员检查程序是否实现了他想要程序实现的功能；
角色：
软件测试：软件测试工程师，白盒测试工程师，开发人员（白盒测试：单元测试）

单元测试：对一个模块的进行测试
Java Junit
软件调试：开发人员
阶段不同：
软件测试：贯穿到了整个软件开发的生命周期

概念篇：
1.什么是需求？
满足用户的期望和正式规定的合同，标准，文档所需要的条件和权限；
用户的需求 软件的需求
软件需求是用户需求转换而来的

软件形成的过程：从无到有----产品经理：

BUG：
2.什么是BUG？
当我们的规格说明存在，并且合理，如果软件功能和需求规格不符合，说明是软件错误

当规格说明不存在，如果用户的需求存在并且合理，如果功能和用户需求不匹配，说明是软件错误

3.什么是测试用例？–向被测试系统发起的一组集合，
也包括测试平台，测试环境，测试数据，测试步骤，预期结果，测试功能模块，前置条件，重要性等

为什么测试工程师需要写测试用例？
评估测试的功能的覆盖率；不会进行大量的冗余操作；重复使用。

测试正常流程：
1.输入正确的用户名和密码，正常登录，直接进入首页
2.输入用户名不存在，密码存在，登陆失败
3，用户名存在，密码错误
测试用例：
测试水杯

4.软件开发的五个模型和软件测试的两个模型
软件开发的生命周期：需求—分析/计划—设计-开发–测试–运行维护
1.软件开发的模型：
瀑布模型：适应于需求稳定的项目，项目前期的问题或错误后期测试的时候才能发现，会失去修正错误的最佳时机。
前期的问题后期才能发现

螺旋模型：适用于前期项目比较庞大，需求不明确，风险比较大的项目，有利于项目风险的控制。
3.迭代模型：
4.增量模型

5.敏捷开发模型：敏捷开发拥抱变化

scrum流程

1.发布计划会议：产品经理对user story进行排版，讲 解，整理出这一期迭代需要完成的user story
2.迭代计划会议：进行任务划分，完成的确切时间
3.开发过程，每日站会：三件事
4.演示会议：向客户演示成果，期间提出的问题，由产 品经理继续整理成user
5.回顾会议：总结，改进敏捷流程
角色：PO 产品经理 SM项目经理 ST研发团队
敏捷开发：
轻文档，轻流程，重目标，重产出；
测试人员在敏捷开发过程中怎么去完成测试任务？—
测试人员得核心任务不变，找BUG；不仅会找BUG，要知道BUG产生得原因，解决方案
6.两大测试模型
1.软件测试V模型
特点：左边的阶段和右边的测试阶段一一对应，并且是右边每一个测试阶段的依据
缺点：项目前期的风险和错误到后期测试阶段才发现，会失去问题及时纠正的机会；

2.软件测试W模型
特点：测试在项目一开始就介入（需求阶段介入） ，有利于前期风险的及时发现
缺点：不能用于敏捷开发，不适用与需求变化

PO：product owner 产品经理 客户得代表方，用户需求转化为一个user story
SM:项目经理
ST：研发团队，交付一个高质量可用得软件

基础篇：

1.软件测试的生命周期----（软件测试的流程？）
-----需求分析----测试计划（范围、时间、人员、工具）—测试设计/开发（测试用例）----测试执行（执行测试用例，补充测试用例）——测试评估（（覆盖范围。测试了哪些功能，哪些没有测试）BUG的情况的统计）测试报告

2.如何描述一个BUG？重点
1.测试版本–当前测试的系统所在的代码版本
2.测试环境–系统所在的环境（1.网页web系统（Chrome Firefox IE edge-浏览器的版本号。（2.APP(ios Android 系统的版本号 机型））
3.测试步骤–引起BUG的操作步骤
4.测试数据—引起BUG的输入信息，或者数据
5.测试的实际结果—预期结果
6.其它，错误截图，错误日志等附件

4.BUG的级别—
崩溃：系统无法运行，死机
严重：系统还可以运行，但是不稳定，如果继续运行， 会产生严重得后果
一般：系统可以稳定得运行，但是一些一般功能没有实 现，实现得有问题，不影响用户使用
次要：建议性得BUG，界面得问题
对于BUG得级别，每个公司得标准不一样，可能 更细致

5.BUG得生命周期：
new（新建）——open（确认）
BUG得管理系统 jira tapd 禅道
6.如果测试人员因为一个BUG和开发人员产生争执怎么办?
.重要：不能争吵 镇定
1.检查一下自身，看BUG是否描述清楚，
2.站在用户得角度 去说服开发人员
3.BUG的定级要合理。——按照公司的测试BUG定级规范，要有理有据
4.要不断的提高自己的业务水平和技术水平
5.可以和产品经理，开发人员，测试人员开“三方会议”讨论BUG的严重程度，影响程度，以及最终解决方案

用例篇
1.基于需求的设计测试用例：
1.验证需求的正确性和合理性
2.细分需求，多细致的需求就设计多细致的测试用例
从细分的需求里边，根据每一个功能点设计完 整的测试用例
（1）如果用户没有收到激活邮件，进入登陆页面输入电子邮件和密码，重新发送。
如果用户收到邮件，在登录页面输入电子邮件和密码，不会重新发送，并且提示激活。
2.。。24小时之内，点击激活邮件，提示，链接失败，需要重新发送激活邮件
24小时之内点击激活邮件，已激活系统，超过24小时
之后，再次点击？——链接失败，系统已激活

1.等价类、
当输入很多，没有办法穷举，把输入（特殊情况下考虑输出）划分成若干个等价类，从每一个等价类中选一个测试用例，如果这个测试用例通过，那么就说这个测试用例代表的等价类测试通过。
有效等价类：对于输入有意义的数据规格，称为有效等 价类-----激活邮件的例子
无效等价类：

例子
等价类的划分（边界值）：>2;-5~2之间；<-5
等价类的边界是否需要专门测试？因为边界往往最容易出错
2.边界值法：针对输入输出的边界进行测试的方法。
3.因果图法
当我们的输入有多种，不同的输入组合对应的不同的输出，可以使用因果图法；
因果图：恒等 与 或 非
恒等：
如何根据因果图设计测试用例？
1.分析需求，找出所有的输入和输出
2.找出所有输入和输出之间的关系
3.因果图
4.根据因果图判定表
5.根据判定表设计测试用例

测试用例：
1.输入：订单提交/订单不提交 金额大于300/金额小于300 有红包/没有红包
输出：有优惠/无优惠
2.找关系：订单已提交，金额大于300，有红包，则有优惠。

3.画因果图

4.画判定表

5.写测试用例