软件测试基础知识.docx
- 文档编号:24941879
- 上传时间:2023-06-03
- 格式:DOCX
- 页数:14
- 大小:19.77KB
软件测试基础知识.docx
《软件测试基础知识.docx》由会员分享,可在线阅读,更多相关《软件测试基础知识.docx(14页珍藏版)》请在冰豆网上搜索。
软件测试基础知识
一.测试基础:
1.瀑布模型软件生命周期分为哪些阶段
计划阶段
需求分析阶段
设计阶段
编码阶段
测试阶段
运行维护阶段
2.软件测试的预防目的,是预防什么
尽早返现、尽早解决,避免问题延后导致的问题扩大化
发现问题找出问题原因,并实施改进,从而避免同类问题的再次发生
3.软件测试的对象包括哪些
可执行的程序
开发这个程序的一切中间过程产品,包括需求文档、设计文档、源代码
该程序所在的运行环境
4.设计阶段要设计哪2个文档,中英文名分别叫什么?
概要设计,HLD
详细设计,LLD
5.软件研发团队中包括哪些角色?
项目经理
需求分析人员
设计人员
编码人员
测试人员
QA
配置管理人员
二.测试方法:
6.说一下白盒测试、黑盒测试、灰盒测试的区别
黑盒测试:
把测试对象看做一个黑盒子,不考虑内部逻辑,只依据外部规格要求,检查产品的实际规格是否符合要求的测试方法。
白盒测试:
把测试对象看做一个打开的盒子,利用设计的内部逻辑结构,对产品运行逻辑进行测试的方法。
灰盒测试:
是介于白盒测试与黑盒测试之间的,灰盒测试关注输出对于输入的正确性,同时也关注内部表现。
7.说一下白盒测试、黑盒测试各自的优缺点
黑盒测试优点:
1.符合使用者的视角,测试人员容易理解、容易执行
2.对测试人员技能要求不高,工作量相对较小
3.发现的问题都是和规格不一致的异常
黑盒测试缺点:
1.难于考虑到因设计引入的新的测试项,导致测试有遗漏
2.难于对复杂业务进行充分覆盖的测试
3.发现问题相对较难定位
白盒测试优点:
1.深入到最底层逻辑进行测试,能发现深层次问题
2.逻辑覆盖充分,可达到足够高的覆盖率
3.发现问题后定位解决问题成本低
白盒测试缺点:
1.测试技能要求高,测试工作量绝大
2.发现的不一定是规格上的缺陷
8.功能测试自动化适用的场合
回归次数多
质量要求高
版本迭代变化不大
9.静态测试和动态测试的区别
静态测试,无需运行被测试对象,而是直接观察,通常静态测试的对象是文档和源代码
动态测试,运行被测试产品,观察产品运行时的表现现象。
通常测试对象是可执行的程序。
10.对自动化能否取代手工测试这个问题,你是怎么理解的?
自动化测试无法取代手工测试。
因为:
1.自动化测试适用的场合比较少,而手工测试适合于大部分场合
2.自动化测试解决的不是测试的质量问题,而是测试的效率问题,单纯靠自动化测试无法发现产品突发性的问题
3.正常的测试过程中,手工测试居主,对没有修改的模块进行回归测试,才是自动化测试的主要适用场合
通过对大部分没有修改模块的自动化测试,可以大大节约人力,来投入到更需要手工测试的复杂或修改过的模块,通过更细致的手工测试来提高产品质量
三.测试过程:
11.软件测试过程一般划分为几个阶段?
每个阶段的测试重点是什么?
单元、集成、系统、验收
单元测试主要测试单元内部的数据结构、逻辑控制、异常处理等
集成测试主要测试模块之间的接口和接口数据传递关系,以及模块组合后的整体功能
系统测试主要测试整个系统相对于需求的符合度
验收测试主要测试产品是否达到用户可使用的状态
12.瀑布模型与双v模型的优缺点
瀑布模型有以下优点:
1)为项目提供了按阶段划分的检查点。
2)当前一阶段完成后,您只需要去关注后续阶段。
3)可在迭代模型中应用瀑布模型。
瀑布模型有以下缺点:
1)在项目各个阶段之间极少有反馈。
2)只有在项目生命周期的后期才能看到结果。
3)通过过多的强制完成日期和里程碑来跟踪各个项目阶段。
双V模型的优点:
1)将测试贯穿到整个软件的生命周期中,且除了代码要测试,需求、设计等都要测试。
2)测试更早的介入到软件开发中,能尽早的发现缺陷进行修复。
3)测试与开发独立起来,并与开发并行。
双V模型的缺点:
1)对有些项目,开发过程中根本没有文档产生,故W模型无法使用。
2)对于需求和设计的测试技术要求很高,实践起来很困难。
13.什么是回归测试?
你们公司是如何做回归测试的?
回归测试,即就是在软件生命周期中,只要软件发生了改变,就可能给该软件产产生问题;所以,每当软件发生变化时,我们就必须重新测试现有的功能,以便确定修改是否达到了预期的目的,检查修改是否破坏原有的正常功能。
回归测试可以发生在任何一个阶段,包括单元测试、集成测试和系统测试。
回归测试实施过程:
1、在测试策略制定阶段,制定回归测试策略
2、确定需要回归测试的版本
3、回归测试版本发布,按照回归测试策略执行回归测试
4、回归测试通过,关闭缺陷跟踪单(问题单)
5、回归测试不通过,缺陷跟踪单返回开发人员,开发人员重新修改问题,再次提交测试人员回归测试
14.回归测试的策略有哪些?
完全重复的回归测试策略
选择性重复的回归测试策略,包括了错误修改法、周边影响法、指标达成法
15.你们公司的测试流程是什么?
1)需求评审-需求定稿,测试人员理解需求
2)测试组长发布测试计划
3)测试人员进行测试方案的编写及评审
4)测试人员根据测试方案定稿进行测试类型选择、测试用例的编写和评审
5)测试人员根据测试用例进执行功能、性能、易用性、安装性、健壮性、恢复性等各类型的测试
6)发现问题提交缺陷,并审核缺陷
7)修复后,进行回归测试确认bug修复,关闭bug
8)编写测试报告及总结
9)提交过程文档到知识库。
四.测试覆盖率:
1、白盒测试的覆盖率有哪些?
如何计算的?
1)语句覆盖率:
所有的用例运行被测试程序后,执行到的语句所占总语句的比率
覆盖率=所有用例执行到的语句/总语句
2)判定覆盖率:
所有的用例运行被测试程序后,执行到的取真/取假分支总数所占总分支数的比率
覆盖率=(所有用例执行到的取真分支数+取假分支数)/总分支数
3)条件覆盖率:
所有的用例运行被测试程序后,执行到的条件取真值假值总数所占总条件取值的比率
覆盖率:
(所有用例执行到条件的取真值+取假值)/总条件取值数
4)判定-条件覆盖率:
所有的用例运行被测试程序后,执行到的条件取真假值总数与判定真假分支的总数所占总条件取值以及总的判定分支总数的比率
覆盖率:
(所有用例执行到条件的取值数+执行到分支数)/(总条件取值+总分支的取值)
5)条件组合覆盖率:
所有的用例运行被测试程序后,执行到的条件组合总数所占总条件组合的比率
所有用例执行到条件组合数/总条件组合数
6)路径覆盖率:
所有的用例运行被测试程序后,执行到的路径数所占总路径的比率
执行到路径数/总路径数
2、黑盒测试的覆盖率如何计算?
所有测试用例的测试点所占所有需求的测试点的比例,因此,必须将需求的大概的所有测试点分析出来
3、覆盖率越全面越好吗?
不是,覆盖率越高,测试设计及执行的成本会越高;因此只要重要的测试点覆盖到就满足覆盖率的要求了
4、常用的白盒测试设计技术
逻辑覆盖测试、基本路径测试、程序插装、循环覆盖测试
5、什么是基本路径测试?
一种常用的白盒测试用例设计方法,设计用例的步骤如下:
1)分析程序的控制流图
2)分析控制构造的环路复杂性
3)导出基本可执行路径集合
4)设计测试用例
5)保证程序的每一个可执行语句至少执行一次
五.用例写作:
测试用例应包含的主要项目?
答:
测试用例编号、测试项目测试标题、重要级别、预置条件、输入数据、操作步骤、预期输出
用例预置条件的作用?
答:
执行当前测试用例需要的前提条件,如果这些前提条件不满足,则后面的测试步骤无法进行或者无法得到预期结果。
前提条件必须是最近接近操作步骤的条件,不要离得太远了。
预期结果可能包含哪些内容?
答:
当前测试用例的预期输出结果,包括返回值的内容、界面的响应结果、输出结果的规则符合度等等
六.缺陷管理:
提交的缺陷开发不认可怎么办
首先和开发沟通,看是否能说服对方,或者被对方说服
如果双方达成不了共识,那么就可以上交给测试组长或者经理,由他去协调,如果项目组中有ccb组织,可以上ccb进行裁决
缺陷提单后的处理流程
简化版提单过程:
测试人员提单后直接交给开发人员确认是否是问题,如果是则进行修改,改好后交给测试人员在新版本上做回归测试。
回归测试通过则问题单关闭,不通过则返回开发人员重新修改(具体可以参照ppt上的流程图来讲解,如果觉得自己表达能力有限,怕说不清楚,可以用纸笔给面试官一边画一边讲)
缺陷单的主要内容
编号,测试环境,测试版本,缺陷描述,操作步骤,预期结果,实际结果,严重程度等
七.系统测试
请描述常见的系统测试类型有哪些?
功能测试、性能测试(负载测试、压力测试、并发测试、基准测试……)、异常测试、界面测试、易用性测试、安装测试、兼容性测试……
什么是异常测试?
异常测试,是检测系统对异常情况的处理。
异常测试覆盖硬件或软件异常时的处理。
测试方应通过人为制造错误情况测试系统对错误操作、错误报文的反应,检查程序中的屏幕或页面是否给出了清晰且充分的提示或约束;一旦出现错误情况,系统是否能正常报告,并检查系统的错误提示是否清晰且充分;测试系统是否处理了用户的异常操作,还是造成死机或处理错误。
只有通过异常测试的软件产品,才可以保证软件在正式上线后长时间的保持良好的运营状态,给最终用户以信心。
异常测试的结果也有助于为我们进一步的系统优化设计积累经验,设计和测试是一个相互反馈的过程。
八.单元测试
1)junit中有哪些注解,分别表示什么意思?
注解(Annotation)
@Test:
测试方法
@Ignore:
被忽略的测试方法
@Before:
每一个测试方法之前运行
@After:
每一个测试方法之后运行
@BeforeClass:
所有测试开始之前运行
@AfterClass:
所有测试结束之后运行
2)例举常用的断言5个
Assert.assertEquals
Assert.assertNotEquals
Assert.assertTrue
Assert.assertArrayEquals
Assert.assertNull
3)单元测试,集成测试,系统测试的区别
a)测试方法不同
单元测试属于白盒测试范畴
集成测试属于灰盒测试范畴
系统测试属于黑盒测试范畴
b)考察范围不同
单元测试主要测试单元内部的数据结构,逻辑控制,异常处理等
集成测试主要测试模块之间的接口和接口数据传递关系,以及模块组合后的整体功能
c)系统测试主要测试整个系统相对于需求的符合度
评估基准不同
单元测试的评估基准主要是逻辑覆盖率
集成测试的评估基准主要是接口覆盖率
系统测试的评估主要是测试用例对需求规格的覆盖率
4)什么是驱动单元和桩单元
驱动单元:
用来模拟被测试单元的上层单元,相当于被测函数的主程序
桩单元:
用来代替被测单元工作过程中调用的子单元
5)单元测试的策略有哪些,方法是什么?
分别有什么优缺点
a)孤立的测试策略
方法:
不考虑每个模块与其他模块之间的关系,为每个模块设计桩模块和驱动模块,每个模块进行独立的单元测试
优点:
最简单,最容易操作,可以达到高的结构覆盖率
缺点:
桩函数和驱动函数工作量很大,效率低
b)自顶向上的测试策略
方法:
不考虑每个模块与其他模块之间的关系,为每个模块设计桩模块和驱动模块,每个模块进行独立的单元测试
优点:
最简单,最容易操作,可以达到高的结构覆盖率
缺点:
桩函数和驱动函数工作量很大,效率低
c)自顶向下的测试策略
方法:
不考虑每个模块与其他模块之间的关系,为每个模块设计桩模块和驱动模块,每个模块进行独立的单元测试
优点:
最简单,最容易操作,可以达到高的结构覆盖率
缺点:
桩函数和驱动函数工作量很大,效率低
6)桩模块、驱动模块的概念。
驱动模块:
在大多数场合称为“主程序”,它接收测试数据并将这些数据传送到被测试模块,单元测试一个函数单元时,被测单元本身是不能独立运行的,需要为其传送数据,为此写驱动
驱动模块要完成以下事情:
1.接受测试输入
2.对输入进行判断
3.将输入传给被测单元,驱动被测单元执行
4.接受被测单元执行结果,并对结果进行判断
5.将判断结果作为用例执行结果输出测试报告
桩模块:
比如对函数A做单元测试时,被测的函数单元下还包括了一个函数B,为了更好的测试错误,定位错误,就要为函数B写桩,来模拟函数B的功能,保证其正确。
7)单元测试中关注的重点有哪些?
单元接口、出错处理、局部数据结构、独立路径、边界条件
8)junit在单元测试中的作用?
一个作用就是方便如果要测试一个方法的话除了junit就是main但是如果有很多个测试方法要测试的话你就需要频繁的更改main方法。
但是junit只要添加一个标记就可以了标记了你只需要在Outline窗口中右键你标记的方法选RunAs然后选择JUnitTest就可以测试了。
Junit中还可以使用@Test,@Before,@After,断言等,使测试更灵活。
WelcomeTo
Download!
!
!
欢迎您的下载,资料仅供参考!
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件 测试 基础知识