认识、概念、基础、用例
- 一、认识
-
- 1. 什么是软件测试/li>
- 2. 软件测试和研发的区别/li>
- 3. 一个优秀的测试人员需要具备什么素质/li>
- 二、概念
-
- 1. 什么是需求/li>
- 2. 什么是BUG/li>
- 3. 什么是测试用例/li>
- 4. 开发的五个模型
- 5. 测试的两个模型
- 三、基础
-
- 1. 软件测试的生命周期/li>
- 2. 如何描述一个BUG/li>
- 3. BUG的级别
- 4. BUG的生命周期
- 5. 如果因为一个BUG和发开人员发生冲突了怎么办/li>
- 四、用例
-
- 1. 等价类
- 2. 边界值
- 3. 因果图
- 4. 正交设计法
- 5. 场景法
- 6. 错误猜测法
一、认识
1. 什么是软件测试/h2>
2. 软件测试和研发的区别/h2>
- 目的不同:软件测试是检查软件的质量(以需求为标准) 软件调试是开发人员为了检查程序是否实现了他(开发人员)想让程序实现的功能
- 人员不同:软件测试:黑盒测试工程师,白盒测试工程师,开发人员(单元测试或者白盒测试);软件调试:开发人员
- 阶段不同:软件调试,只在开发阶段;软件测试,贯穿了整个开发的生命周期
- 难易程度,技能要求;开发广度小,专业度高;测试广度大,专业度低
- 目的不同:软件测试是检查软件的质量(以需求为标准) 软件调试是开发人员为了检查程序是否实现了他(开发人员)想让程序实现的功能
- 人员不同:软件测试:黑盒测试工程师,白盒测试工程师,开发人员(单元测试或者白盒测试);软件调试:开发人员
- 阶段不同:软件调试,只在开发阶段;软件测试,贯穿了整个开发的生命周期
- 难易程度,技能要求;开发广度小,专业度高;测试广度大,专业度低
测试左移:需求前调研阶段和需求阶段,测试人员参加
测试右移:产品上线后,系统监控,日志记录和分享
3. 一个优秀的测试人员需要具备什么素质/h2>
二、概念
1. 什么是需求/h2>
- 用户需求:用户想要软件实现功能 BOSS/实际用户(反馈和要求)/公司的业务人员(针对公司内部系统)非常简单,没有实现的细节
- 软件的需求:用户需求的具体细化,是用户需求具体的实现细节,开发人员要根据软件需求进行软件开发
2. 什么是BUG/h2>
- 当软件需求规格(软件需求)存在并且合理,如果软件功能和软件需求规格不相符合,我们就说软件错误(BUG)
- 当软件需求规格不存在的时候,用户需求存在并且合理,软件功能和用户需求不相符,就是软件错误(bug)
3. 什么是测试用例/h2>
4. 开发的五个模型
- 优点,强调软件质量,每一次迭代进行严格的风险分析,提供讨论项目是否有必要进行下去的机会;
- 缺点,引入风险管理,会投入大量人力物力
- 适用的项目:前期需求不是很明确,并且有风险,项目比较庞大的系统开发
-
迭代、增量模型
一个系统的四个功能,ABCD四模块,两周完成
迭代模型:第一周开发人员完成ABCD四个模块的基础功能,第二周,在基础功能之上进行细化和完善
增量模型:第一周,完成AB模块,第二周,完成CD模块
-
敏捷开发模型
- 优点:,左边的每一个阶段是右边每一个测试阶段的依据
- 缺点:测试介入晚,会失去前期错误及时纠正的机会
- 当软件需求规格(软件需求)存在并且合理,如果软件功能和软件需求规格不相符合,我们就说软件错误(BUG)
- 当软件需求规格不存在的时候,用户需求存在并且合理,软件功能和用户需求不相符,就是软件错误(bug)
3. 什么是测试用例/h2>
4. 开发的五个模型
- 优点,强调软件质量,每一次迭代进行严格的风险分析,提供讨论项目是否有必要进行下去的机会;
- 缺点,引入风险管理,会投入大量人力物力
- 适用的项目:前期需求不是很明确,并且有风险,项目比较庞大的系统开发
-
迭代、增量模型
一个系统的四个功能,ABCD四模块,两周完成
迭代模型:第一周开发人员完成ABCD四个模块的基础功能,第二周,在基础功能之上进行细化和完善
增量模型:第一周,完成AB模块,第二周,完成CD模块
-
敏捷开发模型
- 优点:,左边的每一个阶段是右边每一个测试阶段的依据
- 缺点:测试介入晚,会失去前期错误及时纠正的机会
迭代、增量模型
一个系统的四个功能,ABCD四模块,两周完成
迭代模型:第一周开发人员完成ABCD四个模块的基础功能,第二周,在基础功能之上进行细化和完善
增量模型:第一周,完成AB模块,第二周,完成CD模块
敏捷开发模型
5. 如果因为一个BUG和发开人员发生冲突了怎么办/h2>
(1)先检查自身,看BUG的描述是否清楚
(2)从用户的角度去劝说开发人员
(3)BUG定级要有理有据
(4)不断提高自己的业务水平和技术水平
(5)可以和产品经理商量开BUG评审,讨论这个BUG有没有修改的必要以及他的解决方案
四、用例
根据需求写测试用例,首先要保证需求的,要先验证需求;,把大需求细化成小需求,根据每一个小需求提炼出功能点,根据每一个功能点发散的考虑它的测试用例,去写测试用例(用具体的设计测试用例的方法)
1. 等价类
- ,把输入分成若干个等价类,每一个等价类当中选一个测试用例进行测试,如果这个测试用例测试通过,我们就是这个测试用例代表的等价类测试通过
2. 边界值
- ,设计测试用例的时候会把等价类和边界值结合在一起进行测试用例的设计
3. 因果图
(1)先检查自身,看BUG的描述是否清楚
(2)从用户的角度去劝说开发人员
(3)BUG定级要有理有据
(4)不断提高自己的业务水平和技术水平
(5)可以和产品经理商量开BUG评审,讨论这个BUG有没有修改的必要以及他的解决方案
根据需求写测试用例,首先要保证需求的,要先验证需求;,把大需求细化成小需求,根据每一个小需求提炼出功能点,根据每一个功能点发散的考虑它的测试用例,去写测试用例(用具体的设计测试用例的方法)
因果图:一个逻辑图,恒等,与,或,非
如何用因果图法设计测试用例/p>
①找出所有的输入和输出
②确定不同的输入组合和输出之间的关系
③用因果图来表示输入和输出之间的关系
④根据因果图画判定表
⑤根据判定表写测试用例
4. 正交设计法
根据正交性,在所有的实验组合中找到最优的组合进行测试,通过对这些最优组合的解来分析验证整个实验整体的结果。
经济、高效
因素:输入
水平:输入的取值
列:因素数(C),输入的个数
水平数:每一个因素的取值的最大个数(T)
行:L = (水平数-1)*因素数+1
正交表的性质:
①每一列中各数据出现的次数一样多
②不同的两列不同的数据组合出现的次数一样多
根据正交表设计法设计测试用例的步骤:
①确定因数(输入)②确定每一个因素的水平③找出因素数和水平数④根据因素数和水平数确定正交表的行和列⑤根据正交表的性质去填充正交表里的数据⑥根据正交表的每一行设计测试用例⑦补充正交表里面没有的,但是你认为可能的测试用例
5. 场景法
把各个孤立的功能点按照一定的策略组合起来,形成一个应用场景
总结:找出场景当中的每一个功能点,根据每一个功能点的正常和异常的情况去设计测试用例
6. 错误猜测法
根据测试人员的知识、经验去推断可能会出现问题的功能模块,有针对性的去设计测试用例
补充的设计测试用例的方法,测试人员可以用其他设计测试用例的方法设计需求的测试用例,用错误猜测法作为一种补充的方式
声明:本站部分文章及图片源自用户投稿,如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢!