软件测试回顾---重点知识

软件测试重点知识回顾

8.1.1软件测试的目的是

  • 尽可能的发现程序中的错误
  • 并不是发现所有的错误
  • 并不是证明程序是错误的
  • 也不是为了调试程序

8.1.2白盒测试根据什么设置测试用例?黑盒测试根据什么设置测试用例?

  • 白盒测试根据内部逻辑来设计的
  • 黑盒测试根据的是软件的需求规格说明来设计测试用例

8.1.3为了提高测试效率应该?

  • 选择发现错误的可能性最大的数据作为测试数据
  • 并不是随机选择测试数据
  • 并不是取一切可能数据
  • 也不是编码完成之后指定软件的是计划

8.1.4使用白盒测试方法,确定测试数据应该根据x和指定的覆盖标准

  • 根据程序的内部逻辑
  • 并不是程序的复杂程度
  • 也不是使用说明书
  • 也不是程序的功能

8.1.5按照不同阶段的测试有哪些

  • 单元测试,集成测试,系统测试

8.1.6测试用例设计的基本原则

  • 测试用例能发现至今没有发现的错误
  • 测试用例应由测试数据输入和与之对应的预期输出结果这两部分组成
  • 在测试用例设计时,应当包含合理的输入条件和不合理的输入条件

8.1.7一个程序含有的路径数和xx有着直接的关系

  • 程序的复杂程度
  • 并不是程序的语句的条数
  • 程序的模块数
  • 程序指令执行时间

8.1.8动态黑盒测试

  • 测试的是软件在使用过程中的实际行为

8.1.9在自低向上测试中,要编写称为xxx的模块来测试正在测试的模块

  • 测试驱动模块

8.1.10软件测试中需要包含的内容

  • 测试预期输出
  • 没有测试资源和进度安排
  • 没有测试范围
  • 没有测试策略

8.1.11调试是什么

  • 调试是消除软件错误的过程
  • 不可重复

8.1.12在软件底层进行的测试称为?

  • 单元测试

8.1.13确定黑盒测试策略,优先选用的是

  • 等价类划分法
  • 注意不是边界值分析法

8.1.14不属于软件缺陷的是

  • 测试人员主观认为的不合理的地方
  • 软件缺陷是软件未达到产品规格说明数中标明的功能
  • 软件缺陷是出现了说明书中指明不会出现的错误
  • 软件缺陷是超出产品说明书指明的范围

8.1.15xxx把黑盒测试和白盒测试界限打乱了

  • 灰盒测试

补充资料:

8.1.16软件测试的核心是

  • 测试用例
  • 核心不是测试人员
  • 核心不是编程人员
  • 核心不是测试方法

8.1.17程序的三种基本控制结构

  • 顺序,条件和循环

8.1.18测试的基本流程

  • 开发人员将开发出来的产品交给测试部门
  • 测试人员使用某种测试方法测试产品并收集产品的缺陷
  • 与开发人员沟通并发现缺陷
  • 开发人员修复缺陷并送回到测试部门重新测试

8.1.19软件测试的目的

  • 尽可能发现并排除软件中潜藏的错误,并提高软件的可靠性

8.1.20软件测试报告中不包含的内容

  • 投资规模
  • 包含内容有项目背景、测试版本、结论和建议

8.1.21单元测试中模拟被测模块调用者的模块是

  • 驱动模块

8.1.22侧重于观察资源消耗尽情况下的软件表现的系统测试称为

进行压力测试的时候系统已经处于资源消耗尽的情况下持续运行的软件的表现

  • 压力测试

8.1.23用于必须参与的测试阶段是什么

  • 验收测试

8.1.24不属于单元测试的内容的是

  • 模块接口测试(集成测试)
  • 单元测试:局部数据结构测试,路径测试,用户界面测试

8.1.25划分白盒测试和黑盒测试依据的是

  • 是否能看到被测程序
  • 黑盒测试看不到源程序
  • 白盒测试可以看到被测的源程序

8.1.26单元测试中常用的方法

  • 白盒测试为主,辅以黑盒测试

8.1.27动态执行测试分为

  • 黑盒和白盒测试

8.1.28为什么要进行测试

  • 以最少的时间和人力,系统的找出软件中潜在的各种错误和缺陷
  • 实施测试收集到的测试结果数据为可靠性分析提供了依据
  • 不是为了开发团队的利益
  • 不是为了说明软件中的错误

8.1.29软件质量缺陷的原因

缺陷的原因要从系统本身上去找问题,而不是从用户的身上去找问题的所在

  • 缺乏或者没有进行有效的沟通
  • 软件复杂度
  • 编程错误
  • 用户操作错误不算是软件质量缺陷的问题,只能说明系统做的不好

8.1.30白盒测试方法

  • 语句覆盖
  • 分支覆盖
  • 逻辑覆盖
  • 循环测试

8.1.31属于静态分析的是

不运行程序而进行的检查

  • 代码规则检查
  • 程序结构分析
  • 程序复杂度分析

8.1.32测试设计阶段的任务

设计,肯定是和设计测试用例相关

  • 设计测试用例
  • 设计测试过程、脚本

8.1.33黑盒测试优点

  • 适用于各个阶段的测试
  • 从用户角度进行测试容器被理解和接收
  • 测试员和程序员可以由不同的人来担任

8.1.34白盒测试常用的设计测试用例的方法

  • 基本路径法
  • 语句覆盖
  • 条件覆盖

8.1.35软件测试目的

  • 尽可能的找出软件的缺陷

8.1.36Beta是验收测试的一种

8.1.37项目立项钱测试人员不需要提交任何材料

8.1.38单元测试能发现80%的软件缺陷

8.1.39代码评审是检查源代码是否达到模块设计的要求

8.1.40自底向上集成需要测试人员编写驱动程序

8.1.41验收测试是以最终用户为主的测试

8.1.42好的测试人员不能不屑的追求完美

  • 不能钻牛角尖

8.1.43软件测试工具不能代替软件测试员

8.1.44最重要的用户界面要素是软件符合现行标准和规范

8.1.45软件测试是有效的排除软件缺陷的手段

8.1.46产品说明书(需求文档)的变更应当受到控制

8.1.47不存在质量很高但是可靠性很差的产品

8.1.48静态白盒测试可以找出遗漏之处和问题

8.1.49单元测试能发现80%的软件缺陷

8.1.50软件测试的目的是尽可能多的找出软件缺陷

8.1.51单元测试可以发现大部分的软件缺陷

8.1.52自顶向上集成需要测试员编写驱动程序

8.1.53边界值是一个输入或者输出的值,处在等价类的边界上

  • 2
    点赞
  • 10
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

简单点了

谢谢大佬

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值