一 什么是软件测试
1.软件测试的概念
生活中的测试场景:冬天到了我想买一件羽绒服,买之前我要思考这些问题:鸭绒填充量,款式,尺码,价格,颜色...以上这些是购买需求,收到货后与以上需求对比,看这件羽绒服各个方面是否满足我的需求,这个过程也叫做测试。
软件测试的定义:软件测试是一个过程,测试人员针对软件各个方面来验证软件是否符合用户需求。
2.测试与研发的区别
①工作内容的不同:
开发人员:利用编程技能开发软件
测试人员:利用各种技能、测试工具找bug
②技术要求的区别:
开发人员:技能深度的要求
测试人员:技能广度的要求
③发展前景:
开发人员:初级开发工程师->中级开发工程师->高级开发工程师->架构师->CTO
测试人员:初级测试工程师->中级测试工程师->高级测试工程师->架构师->项目经理
3.测试人员应具备的素质
技能方面:编程能力,编写测试用例的能力
非技能方面:沟通能力,快速学习能力,团队合作能力,文字表达能力,抗压力,责任感,耐心细心...
4.软件测试与调试的区别
①目的
调试:发现缺陷并解决
测试:发现缺陷,验收缺陷
②人员
调试:开发人员来完成
测试:测试+开发人员
③阶段
调试:开发阶段完成
测试:贯穿软件的整个生命周期
④方法
调试:debug,打印日志
测试:黑盒测试、白盒测试、UI测试、接口测试、性能测试
二 什么是需求
1.需求的定义
满足用户期望或 规定文档所具有的条件,包含用户需求和软件需求。
用户需求:一句话。可以理解为甲方的需求,一般比较简略。
软件需求:一个文档。会详细描述开发人员必须实现的软件功能,开发人员和测试人员的直接依据。
2.测试人眼里的需求
需求是测试人员开展测试工作的依据。在设计测试用例的时候,具体步骤如下:搞清业务需求->软件功能需求点->测试需求点->测试用例
以“用户登录”为例子:
3.如何深入了解需求
参加需求评审会议,查阅文档(需求文档,技术文档),与项目经理沟通都可以更好的帮助测试人员理解需求。
三 测试用例
1.什么是测试用例
测试用例(Test Case)是为被测试系统提供的一组集合,包括测试环境,操作步骤,测试数据,预测结果。
在进行测试用例的时候,要考虑这几方面因素
测试用例=功能测试+界面测试+性能测试+安全测试+易用性测试+兼容性测试
2.测试用例的设计方法
❤️针对没有需求的案例
❤️针对有需求的案例
需求分析->需求有哪些功能->设计测试点->设计测试用例
❤️等价类
概念:根据需求将输入划分为若干个等价类,从等价类中拿出一个测试用例,如果这个测试用例通过,则所代表的等价类测试通过。
适用的需求:输入数据是无穷且有特点的。
有效等价类:根据需求来说是有效且有意义的数据构成的集合。
无效等价类:根据需求来说是无效且有无意义的数据构成的集合。
例子:
需求:超市买水果
有效等价类:苹果,火龙果,桃子
无效等价类:酸奶,毛巾,水杯
根据等价类划分测试用例步骤:
1.充分理解需求
2.分别划分有效等价类和无效等价类
3.分别细分有效等价类和无效等价类
4.分别对有效等价类和无效等价类进行组合
❤️边界值
概念:边界值分析法就是对等价类划分法的补充。,测试用例来自等价类的边界。设计测试用例的时候通常加上边界值和次边界值。
上点:边界上的点。
离点:边界左右的一个点。如果是闭区间,离点就算范围外的点;如果是开区间,离点就算范围内的点。
内点:边界内的点。
举例:
①【1,11】
上点:1,11
内点:6
离点:0,12
②(1,11】
上点:1,11
内点:6
离点:2,12
③(1,11)
上点:1,11
内点:6
离点:2,10
步骤:
1.充分理解需求
2.找到上点、内点、离点
3.根据上点、内点、离点设计测试用例
❤️判定表
概念:一种表达逻辑判断的工具
步骤:
1.确认输入条件和输出条件
2.找出输入和输出之间的关系
3.画判定表
4.根据判定表编写测试用例
适用场合:需要考虑输入之间的组合关系,不同组合关系对应的输出结果不同
例子:
需求:店铺活动,订单已提交,订单金额大于300或有红包,有优惠。
1.确认输入和输出条件
A B C
输入:金额大于300 有红包 订单已提交
1 2
输出:有优惠 无优惠
2.找出输入条件和输出条件之间的关系
AC 1
BC 1
ABC 1
A 2
B 2
C 2
AB 2
非ABC 2
3.画判定表
4.根据判定表来编写测试用例
1.金额大于300,无红包,订单已提交,有优惠
2.金额不大于300,有红包,订单已提交,有优惠
3.金额大于300,有红包,订单已提交,有优惠
4.金额大于300,无红包,订单没有提交,无优惠
5.金额不大于300,有红包,订单没有已提交,无优惠
6.金额不大于300,无红包,订单已提交,无优惠
7.金额大于300,有红包,订单没已提交,无优惠
8.金额不大于300,无红包,订单没有提交,无优惠
❤️正交排列
概念:能够使用最小的测试过程集合获得最大测试覆盖率,需要用到正交表。
适用场景:配置类软件、组合较多的情况
正交表特性:
1.每一列中不同数字出现的次数想等
2.任意两列数字的排列方式齐全且均衡
正交表表达式:L4(2³)
L:正交表
4:是试验次数(测试用例个数)
2:因素数 (输入的条件)
3:水平数 (输入的条件的可选项,不是输出条件)
步骤:
需求:用户注册信息,填写姓名,邮箱,密码,确认密码,验证码
1.找到因素数和水平数
因素数:姓名,邮箱,密码,确认密码,验证码
水平数:填写,不填写
2.使用allpairs工具生成正交表
3.根据正交表来编写测试用例
4.补充测试用例
❤️场景设计法
场景设计法:主要分为主事件流和多个次事件流
步骤:
1.找到主事件流
2.找到次事件流
3.将主次事件流串起来会形成场景,一个场景就是一个测试用例。
❤️错误猜测法
错误猜测法是对被测试软件设计的理解,过往经验以及个人直觉推测出软件可能存在的缺陷,比较依赖个人能力。
😶🌫️测试用例的作用
测试用例可以减少大量冗余测试,提高测试人员的工作效率,是建立自动化的基础。
四 测试分类
五 软件错误(BUG)
在规格说明书完全正确的前提下,程序的执行结构与用户预期结果不符的情况就是出现了BUG。
1.如何定义bug的级别
1.Blocker(崩溃):阻碍开发或测试工作;造成系统崩溃,导致数据库数据丢失等。
2.Critical(严重):如软件中数据保存后数据库中显示错误,用户所要求功能缺失。
3.Major(一般):功能菜单存在缺陷但不会影响系统稳定性。
4.Minor(次要):如错别字,界面格式不规范,页面显示重叠等。
注意:当出现崩溃级别的bug时,需要停止测试并打回。
2.bug的生命周期
bug状态转换图
New : 新发现的Bug,未经评审决定是否指派给开发人员修改。
Open : 确认是Bug,并认为需要修改,指派给开发人员。
Fixed : 开发人员修改后标识为修改状态,有待测试人员重新测试。
Rejected : 认为不是Bug,拒绝修改。
Delay : 认为不需要修改或暂时不能修改,延后修改,不是不修复。
Closed : 经测试Bug已被修复,关闭Bug。
Reopen : 经测试Bug仍存在,需要重新打开Bug。
六 软件的生命周期
软件的生命周期是指软件产品从设计到不再使用的时间,分为6个阶段:需求分析、计划、设计、编码、测试、运行维护
七 软件测试的生命周期
软件测试的生命周期:需求分析->测试计划->测试设计、开发->测试执行->测试评估
需求分析 :测试人员了解需求,对需求进行分解
测试阶段 :确定软件由谁测试以及测试周期、测试内容
设计阶段: 测试人员写测试用例,包括手工测试用例和自动化测试用例,编写测试工具
测试执行: 执行测试用例,在此过程中,测试人员记录、管理缺陷
测试评估: 测试完成后写测试报告
八 开发模型
1.瀑布模型(Waterfall Model)
适用的项目:小型项目
特点:线性顺序的开发模式
优点:每个阶段该做什么都非常清晰
缺点:风险在后期测试阶段才暴露,失去及时纠正的机会
2.螺旋模型(Spiral Model)
适用的项目:规模大,复杂度高,风险大的项目
特点:渐进式的开发模式
优点:具有严格的全过程风险管理,强调各开发阶段的质量。
缺点:人员、资金和时间的投入太高
3.增量、迭代
增量迭代是一种软件开发方法,通过分批次、逐步迭代的方式来开发和改进软件。在这个方法中,软件开发项目被分为较小可独立完成的增量,经历需求分析、设计、编码、测试等步骤。在完成一个增量后,根据用户反馈和需求变化,再决定下一个增量的开发内容。这样循环迭代,不断完善和扩展软件功能。
优点:快速交付,及时反馈,降低风险,减少问题积累。
增量和迭代是有区别的:
增量是逐块建造的概念,就像买了一块地,先从打地基一步一步开始盖。
迭代是反复求精的概念,就像直接买了毛坯房慢慢装修。
4.敏捷
特点:轻文档、轻流程、重目标、重产出
敏捷软件开发宣言:Manifesto for Agile Software Development
敏捷模型有很多种,其中scrum是比较为人所熟知的一种。
👀scrum
scrum里的角色:
产品经理(product owner):负责整理用户需求,定义其商业价值,制定发布计划,产品负责。
项目经理(scrum master):负责召开各种会议,协调项目,为研发团队服务。
研发团队(team):包括后端开发、前端开发、UI设计师、测试人员。各个成员紧密合作,完成目标迭代与产品交付。
流程:
1. 产品负责人整理好user story,形成产品待办事项。
2. 发布计划会议:产品经理负责讲解user story,制定出这一期迭代要完成的story列表和user story。
3. 迭代计划会议:团队对每一个story进行任务分解 。
4. 每日例会:每日项目经理召开大概10分钟的站立会议,团队成员进行复盘。
5. 演示会议:迭代会议以后,团队负责向大家展示本次迭代成果,大家将反馈记录并形成新的story。
6. 回顾会议:项目团队对本期迭代进行总结,制定改进计划。
九 测试模型
1.V模型
特点:垂直结构,每个开发阶段都有相应的测试阶段与之对应。
优点:明确标注了测试阶段和开发阶段之间的对应关系
缺点:测试人员介入太晚,发现问题时机太晚
2.W模型
特点:测试从需求阶段就介入
优点:测试人员能及早介入发现问题
缺点:缺乏灵活性,不适用于敏捷