文章目录
一、什么是软件测试
1.什么是软件测试
- 软件测试就是找BUG,发现缺陷
- 软件测试只是一个样本测试,具有不可穷尽性。
软件测试就是验证软件产品特性是否满足用户的需求。
在早期,更多的是将软件测试看做对软件产品的"检验" ,检查软件的每个功能是否正常运行正常
- 验证软件功能执行的正确性,可以是否能正常工作。
- 测试的活动是以测试人员"预期的结果(需求定义)"为依据,看是否符合需求
测试:就是保障软件的质量
2.软件测试和调试的区别
调试:开发自己调试,确保程序做了程序员想做的事,发现问题,解决问题。在开发阶段进行。
测试:测试和开发一起执行。确保程序解决了它要解决的问题,来发现问题。测试伴随软件的整个生命周期
测试人员需要的素养
技能:
1.测试用例设计的能力
2.编程能力(编写测试工具、自动化测试用例)
3.技术快速学习的能力、业务快速学习能力
非技能
1.沟通合作能力
2.文字表达能力(写测试用例、编写测试文档、BUG)
3.抗压能力
4.责任感
二、软件测试概念
1.需求
1.需求的定义
-
用户需求:甲方提出来的需求,或者用户要完成的任务
-
软件需求:功能需求,详细描述需要实现的软件功能
软件需求是产品经理写的
软件需求是测试人员进行测试的基本依据
用户需求就是一句话,软件需求是一个文档(详细描述用户需求应该如何实现)
2.测试人员眼中的需求
-
需求是测试人员开展软件测试工作的依据
-
业务需求--->软件功能需求点--->测试需求点--->测试用例
- 从软件功能需求出发,无遗漏的识别出测试需求。直接关系到用例的测试覆盖率
- 对于每个测试需求点,需要具体设计测试用例
- 测试工程师在需求分析和设计阶段开始介入
2.测试用例
Test Case
1.测试用例概念
- 测试用例是一组集合,包含测试环境、测试数据、预期结果、操作步骤
例子:测试环境:windows+Chrome +本地
测试数据:用户名字符串、密码字符串
操作步骤:输入用户名、输入密码、点击登录按钮
测试预期:登录成功
- 测试用例可以提高测试人员的工作效率,降低工作的重复性
- 测试用例是建立自动化的基础
3.BUG 软件错误
- 当且仅当规格说明书(软件需求)是存在的并且正确。程序与规格说明之间的不匹配(预期结果!=执行结果)才是错误
- 当程序没有实现最终用户合理预期的功能要求时,就是软件错误。
4、开发模型和测试模型
1.软件的生命周期
- 需求分析:分析需求是否合理、需求是否完整
- 计划 : 谁开发、谁测试、开发多久、测试多久...
- 设计 : 设计应该如何实现功能
- 编码 :进行具体的代码编写
- 测试 : 对代码功能进行测试,出具测试报告后才能上线
- 运营维护 :如果线上有问题,测试人员需要协助开发定位、解决问题
2.开发模型
1.瀑布模型
- 需求分析产出:需求文档
- 设计环节产出:技术文档(涉及到哪些接口,库表,mq, 定时任务...)、UI视觉搞
特点:线性的
优点:强调开发的阶段性,每个阶段做什么,产出什么非常清晰
缺点:风险往往会推迟到后期测试阶段才会显露,失去及早纠正的机会
适应的项目:小型的项目
2.螺旋模型
优点:每个阶段都会进行风险分析,避免发生一些线上问题
缺点:风险分析可能会分析错,需要大量人力财力时间的投入
适应项目:比较大的项目、风险比较多的项目
3.增量、迭代
增量:逐块建造的概念,做完一个模块,再做下一个模块
迭代:反复求精,先整体,再细节 (就像素描,先画一个轮廓,再画手、画脸)
4.敏捷
敏捷宣言
- 拥抱变化、请流程、重交付、轻文档、重交互
个体与交互重于过程和工具(个体之间面对面沟通)
可用的软件重于完备的文档 (开发文档、需求文档)
客户协作重于合同谈判
响应变化重于遵循计划
在每对比对中,后者并非全无价值,但我们更看重前者。
scrume开发模式
三大角色
product owner(产品经理)
scrum master(项目经理)
team(研发团队):后端开发、前端开发、UI设计师、测试
流程
1.产品经理收集用户需求
2.项目经理将需求进行优先级的划分、计划项目什么时候开始和结束、由谁来做
3.每日站会,汇报昨天的工作。如果没有完成,遇到了什么问题、今天计划要做什么。
4.演示。
3.测试模型
1.V模型
特点:左边是开发、右边是测试、类似于瀑布模型
优点:测试被划分成很多类型
缺点:测试介入太晚,问题发现的时间太晚
2.W模型(双V模型)
特点:开发一个V 、测试一个V
优点:测试人员尽早的介入
缺点:测试人员和开发人员在一定程度上仍是串行的。并且不能拥抱变化、不能适应于敏捷
三、软件测试基础
1.软件测试的生周期
- 需求分析->测试计划->测试设计、测试开发->测试执行->测试评估
需求分析:需求是否完整、需求是否正确
测试计划:确定由谁测试、什么时候开始测试、结束测试
测试设计:写测试用例(手工测试用例、自动化测试用例)、编写测试工具
测试执行:执行测试用例
测试评估:测试人员产生测试报告
2.描述一个BUG
1.发现问题的版本
2.出现问题的环境
3.错误重现的步骤
4.预期行为的描述
5.错误行为的描述
6.其他。比如BUG复现的前置条件、BUG给谁、BUG的优先级
1.BUG的优先级
- 根据bug的影响程度进行划分
1.Blocker(崩溃):阻碍开发、测试工作的问题,系统崩溃、死机、数据库数据丢失、主要功能丧失...
2.Critical(严重):只要功能部分丧失、数据库保存调用错误、用户数据丢失
3.Major(一般):功能没有完全实现,但是不影响使用、如操作时间长、数据库表中字段过多。
4.Minor(次要):优化、建议类、不影响功能的使用。如错别字
强调:如果发现崩溃级别的bug,就需要停止测试,测试打回
2.BUG的生命周期
-
New:新发现的Bug,未经评审决定是否指派给开发人员进行修改。
-
Open:确认是Bug,并且认为需要进行修改,指派给相应的开发人员。
-
Fixed:开发人员进行修改后标识成修改状态,有待测试人员的回归测试验证。
-
Rejected:如果认为不是Bug,则拒绝修改。
-
Delay:如果认为暂时不需要修改或暂时不能修改,则延后修改。
-
Closed:修改状态的Bug经测试人员的回归测斌验证通过,则关闭Bug。
-
Reopen:如果经验证Bug仍然存在,则需要重新打开Bug,开发人员重新修改。
无效的bug:open->closed open-rejected-closed
3.如何发现bug
1.测试的二八定律:80%的故障集中于20%的模块
2.开发的二八定律:80%的故障集中于20%的开发人员
3.进行逆向思维和发散性思维
4.不局限于用例和需求文档
5.尽早介入项目
4.如何进行测试
1.充分理解需求
文档(产品文档+技术文档)
项目功能问题问产品。模块底层如何实现问开发
参加会议
2.确定测试计划
3.执行测试
bug在开发修复之后,一定要进行验收
4.项目上线 +维护