软件测试题目
1.常见的线性化模型及非线性化模型有哪些
线性化模型:瀑布模型、V模型
非线性化模型:螺旋模型、快速原型、X模型
2.画出V模型
用户需求 验收测试
需求分析 系统测试
概要设计 集成测试
详细设计 单元测试
编码
3.最早引入探索性测试的是什么模型?引入风险管理的是什么模型
最早引入探索性测试:X模型
引入风险管理:螺旋模型
4.你们公司有使用过敏捷开发模式吗?具体如何做的?
- 目标制定,目标对齐
- 产品规划
- 组织产品待办列表
- 需求梳理
- 迭代规划
- 迭代开发
- 开回顾会议
5.软件测试流程:6大活动
需求分析-->测试计划-->测试方案--->测试用例-->测试执行-->测试报告
6.软件测试的范围和对象
程序、文档、数据
7.软件测试7原则
- 所有测试应该追溯到用户需求
- 应当把尽早测试和不断测试作为软件测试的座右铭
- 完全测试是不可能的,测试需要终止
- 软件测试无法发现潜在缺陷
- 充分注意集群现象
- 避免程序员检查自己的程序
- 避免测试的随意性
8.你面试这个工作的优势
综合素质:
- 细心、耐心、责任心、自信心
- 沟通能力
- 团队协作能力
- 发现问题的敏锐程度以及观察能力
- 逻辑思维能力以及发散性思维能力
- 有丰富的软件测试经验
专业素质:
- 熟悉软件研发流程以及测试流程知识
- 熟悉软件测试理论知识
- 掌握测试工具、管理工具、自动化工具、集成工具。性能工具。安全工具....
- 掌握计算机相关知识、数据库、操作系统、网络基础、开发语言
9.软检测试的5大风险
进度风险、人员风险、质量风险、成本风险、变更风险
10.软件测试按阶段、是否运行程序、技术,分别如何划分
按阶段分:单元测试、集成测试、系统测试、验收测试
按是否运行程序分:静态测试、动态测试
按技术分:黑盒测试、白盒测试、灰盒测试
11.系统测试的范围(16大点)
功能测试、性能测试、压力测试、容量测试、安全测试、可用性测试、GUI测试、安装测试、异常测试、配置测试、备份测试、健壮性测试、文档测试、在线帮助测试、网络测试、稳定性测试
12.非正式验收测试的分为:阿尔法测试、贝塔测试;区别
α测试:
- 由公司内部人员测试
- 遇到bug可以控制
- 使用的是测试环境
- 发现问题能及时修复
β测试:
- 由典型用户测试
- 遇到bug不可控制
- 使用的是现网环境,又称线上环境、公网环境、生产环境
- 遇到问题需要统一收集然后集中修复
13.冒烟测试具体如何做的
在正式测试之前抽取项目中基本流程用例(大概10%左右),全部执行通过,如果冒烟测试不通过、项目直接打回。冒烟测试之前需要安装测试环境、测试时间半天至一天。
14.回归测试如何做的
执行上个版本的测试用例、查看bug是否修复、或者修复bug是否引入新的问题。
集合测试又分为
联合测试、组装测试
15.需求分析的特征
- 不许是可核实的
- 必须指出正确条件和错误条件
- 不包含具体数据
16.需求分析的方法
罗列测试要点、注重功能交互、对比质量特效、遍历测试类型
17.上传、下载、支付如何测试
上传:
下载:
18.测试计划谁写,写多长时间
编写人:测试经理或测试组长
时间:2-3天
19.测试计划的内容
项目概述、目的和范围、测试的通过准则、读者和对象、测试参考资料、测试策略、硬件环境、软件环境、启动条件、结束条件、测试周期、人力投入、任务分配以及进度安排、测试风险
20.什么时候开始测试,什么结束测试
开始
- 测试用例编写完成,并通过评审
- 开发编码完成,并通过自测
- 开发提交了转测试申请单以及相关配置
- 测试环境搭建完毕,冒烟测试通过
结束
- 测试任务全部完成,人力投入充分
- 需求覆盖率一般达到100%,测试用例通过率一般达到100%
- 缺陷密度达到预定标准
- 预定标准:高验收标准:3-5个,一般验收标准:6-10个
- 缺陷密度计算方式:缺陷密度=bug总数/总代码量,代码量单位:KLOC,千行
- bug缺陷呈现正态分布或者收敛状态
- 需求规格说明书中所有功能全部正确实现
- 交付件齐全,系统测试通过
21.缺陷密度的计算公式
缺陷密度=bug总数/总代码量,代码量单位:KLOC,千行
22.测试用例的组成
功能模块、标题、优先级、预置条件、操作步骤、预期结果
23.为什么要有测试用例的优先级,依据什么来设置优先级
目的:为了测试时间不充分的情况下,按照优先级比例抽取主要功能模块进行执行
根据重要性和使用评率来确定用例的优先级,两高的高,两低得低,一高一低得中
24.黑盒测试用例设计的方法有哪些?
等价类划分法、边界值分析法、错误推测法、场景法
25.这些方法使用的策略
- 对于业务流程清晰的系统,可以采用场景法贯穿整个测试流程(主要用于冒烟测试和回归测试)
- 进行等价类划分,将无限的测试变为有限
- 集合边界值分析法进行补充
- 然后使用错误推测法追加一些异常的测试用例
26.等价类划分的标准
- 完备测试:将集合划分成不相交的一组子集,而子集的并集是整个集合
- 避免冗余:子集之间不相交
27.来一题,具体设计测试用例数据
28.弱覆盖如何覆盖:(-25,28】;-25,28,-24,29
上点有效,离点无效,上点无效,离点有效
上点:取值范围的端点,不用关注端点的取值到底是有效还是无效
离点 :取值范围的端点左右两边的值
29.测试用例执行结果的状态:单词要会写
- new(未执行)
- pass(通过)
- fail(失败)
- block(阻塞)
- investigate(观察中)
30.提交缺陷开发不认可咋办
- 首先进行自我检查,依据需求确定缺陷是否有问题
- 确定是问题,拿出依据与开发人员有理有据的沟通
- 沟通无效,告知测试经理,将问题提交给CCB进行裁决是否是问题
31.是否所有缺陷都需要修复,为什么
并非所有的缺陷都需要修复
-
修复风险太大,不值得修复
-
没有足够的时间进行修复,并且遗留bug不会影响版本发布新功能
32.执行过程中你发现的bug过多咋办
- 冒烟测试进行不充分,不彻底
- 发现bug越多的模块,残留的缺陷也越多,同时说明开发编码质量太差,会影响测试的质量和效率
- 我们需要将版本打回,要求开发人员自测,自测通过后再提交代码
33.偶现bug如何处理
- 在本季上多次尝试该问题,若能出现则截图保留证据
- 若本机上不能重现,在其他电脑上尝试是否能出现
- 在其他电脑上无法重现,但问题比较严重,找开发人员进行协助定位
- 对于难以重现的问题,需要将问题单挂起,看后续版本是否存在,后续版本如果不存在,则关闭
34.bug单的组成:
缺陷标题、缺陷状态、缺陷级别、缺陷优先级、测试版本、测试阶段、缺陷类型、重现步骤(缺陷描述)、实际结果、预期结果、缺陷所属模块、提交人、附件
35.bug单的流转状态
rejected(非问题)---------------------
|-----reopen--| |
| | |
new ---------open----------fixed------------closed
| |
| |
pending----------
- 测试发现问题,使用bug管理系统提单至开发人员,bug状态为new(新建)
- 开发打开bug单,确认问题是否存在,bug状态为open(打开)
- 开发确认是bug,将bug修复完成后,bug状态为fixed(修复)
- 开发给出依据确认不是bug,bug状态为rejected(拒绝)
- 测试回归bug,验证通过,bug状态为closed(关闭)
- 测试同意开发给出不是bug依据,关闭问题单,bug状态为closed(关闭)
- 开发确认测试提交问题是bug,延迟解决,bug状态为pending(挂起)
- 测试回归bug,验证不通过,bug状态为reopen(重现打开)
36.缺陷的级别,每种级别的含义,每种级别的缺陷举2个例子
- 致命:程序主要功能缺失、闪退、崩溃、报5XX。
- 严重:次要功能没有实现,引发部分功能无法使用。如:无法删除商品,无法新增商品
- 一般:基本功能实现,但边界值错误,或者某些重要功能异常错误
- 轻微:界面排版错误,系统操作不方便,但可以使用
37.BVT,SIT,UAT,中文含义
BVT:冒烟测试
SIT:系统集成测试
UAT:用户验收测试
38.bug单的附件有哪些?
截图、视频、抓包、日志文件
39.测试报告的附件有哪些?
测试用例、bug清单、bug遗留清单
40.常见的测试设计文档有哪些?
需求分析、测试方案、测试用例
41.提单的5C原则,可以中文
- correct(准确):问题单中每个部分描述准确,不会引发误会
- clear(清晰):问题单中每个组成部分描述信息,易于理解
- concise(简洁):只包含必不可少的信息,不包含任何多余信息
- complete(完整):包含重现该问题的完整步骤
- consistent(一致):按照一致的格式书写全部的问题单
42.缺陷的生命周期
提交、确认、分配、修改、验证、关闭
43.提单工具:
禅道(zentao)、bugfree,TAPD,Jira,QC,DTS
44.测试报告的组成
项目背景、测试目的、测试范围、测试策略、测试环境、测试工具、人员组成、人力投入、和工作量的数据统计、用例数、缺陷数、遗留问题、测试风险
45.软件测试过程
- 产品经理进行需求调研,搜索用户需求、整理出一份文档:需求规格说明书
- 产品经理组织开发和测试,召开需求讲解会议,会议结束后,开发和测试均得到需求规格说明书
- 开发和测试深入了解需求文档,提出对需求文档有疑问的地方
- 产品经理召开会议给测试和开发澄清需求
- 软件测试工程师对自己负责的模块进行需求分析,完成后组织测试内部人员和开发人员进行评审
- 评审后根据评审意见修改需求分析文档,测试经理开始编写测试计划、安排后期测试过程中人力投入和各阶段时间安排
- 测试计划评审通过后,软件测试工程师开始编写测试用例,完成后进行评审
- 开发编码完成后,,从svn上获取安装包,搭建测试环境
- 软件测试工程师开始执行冒烟测试,通过后,进行正式的测试执行,如果不通过版本打回
- 正式测试分三轮,达到测试结束条件后,终止测试
- 测试经理开始编写测试报告,测试报告评审通过后,软件提交预发布流程,审核通过后,开始安排上线时间
- 上线对主功能进行测试,成功上线后,开始进行下一轮迭代