北京软件测试培训
达内北京亚运村中心

010-62126400

北京软件测试培训 > 疑难解答 >大神解读:软件测试常用方法和和工具详解

大神解读:软件测试常用方法和和工具详解

  • 时间:2019-02-27 14:53
  • 发布:北京软件测试培训
  • 来源:疑难解答

选择和使用测试方法和工具

  • 按照测试需求用途(或测试技巧)选择
  • 在软件开发生命周期和软件测试流程中适当地选择
  • 按照测试人员实际技能选择
  • 选择可提供的和可执行的

测试方法

类别及技巧 目标 使用方法 举例 适合场景
压力测试 模拟出实际用户环境 产生测试数据;测试组模拟用户处理被创建的数据 确定是否分配了足够的磁盘空间;通讯的容量是否足够;测试系统过载的情况 关于容量的信息不确定
性能测试 确定系统达到了希望达到的性能水平 使用软件和硬件的监视器;使用模拟的监控模型,对关心的性能指标进行监控;创建一个小程序; 计算通信的时间;单位时间处理的信息量; 程序开发的早期
恢复测试 当在进行安装或组装操作过程中,文件丢失时或发生意外后系统有能力重新进行操作 程序的安装,运行方式,工具的使用和关键技术经过足够的评估;系统开发完毕后,介绍一下发生失败后的处理过程 人为的使一个系统在安装或者组装过程中产生错误 当操作的连续性是个重点的时候
操作测试 确定操作文档已经完整 作为计算机正常操作的一部分来执行测试 操作的介绍被文档化,操作者被培训 预先将程序进行产品化。操作性是系统的一个重要指标
复合性测试(与过程的复合性) 校验程序的开发是否依照已定义的标准,流程和操作方式进行的。 将文档/程序同标准相比较,比较有效的方法是检查过程 代码互查(一行一行) 依赖于管理的需要
安全性测试 安全性的缺陷很难被发现;大多数的情况下组织能够防止一般性的破坏者。 对安全性的需求进行评审;分析与安全性有关的处理流程;转包给专业的人员; 定义了被保护的资源,权限进行了控制,日志文件和审查追踪是可用的。 当被保护的资源对于组织具有重要的价值
需求测试 用户的需求可以被实现 创建测试用例和功能检查列表 建立测试矩阵去证实系统需求均被文档化 每一个应用程序都要进行需求测试
回归测试 程序修改后,确保功能的正确性 重新测试应用程序中没有改变的部分 重新执行以前的测试用例 当新的程序有可能影响老的功能
错误处理测试 所有可能的错误条件均经过了验证 一组有经验的人员预测在那里会出现问题 建立一个错误处理的列表 贯穿整个开发生命周期
支持手册测试 检验操作过程被完整地文档化了 对过程有足够的介绍;可以协助用户正常使用 系统在一定的条件下产生一个提示,用户被告知如何采取必要的操作。 最佳时机是在安装测试的时候,但是应该在开发全过程中。
系统兼容测试 检验当使用适当的参数和数据时,需要的信息可以在两个系统中正确的交换 文件和数据被用来在多系统之间传递。 典型的由一个系统到另一个系统的数据交换程序。 两个应用程序之间的参数有可能发生变化
控制性测试 验证数据交换时有足够的审计追踪能力 关键数据或者有价值的数据 从负面来看程序,是否确保了会出错的条件都被保护了。 系统测试的一部分
并行测试 新版本和老版本同时运行,用以确保新版本的程序运行正确。 需要对两个系统输入相同的数据来运行 运行新旧两个工资支付系统 不确定新系统的的运行情况

测试工具

阶段 测试工具 备注
需求 检查表、实况调查与验证、流程图、需求模型、错误推测、风险列表、打分表、走查(讲解开发思路)、......
设计 因果图、检查表、实况调查与验证、正确性数据、评审、错误推测、执行规范、流程图、设计模型、风险列表、打分表、测试用例、走查(讲解开发思路)、......
编码 边界值分析、因果图、检查表、实况调查与验证、编译分析、基础复杂度、控制流分析、覆盖测试对照表、数据流分析、错误推测、流程图、映射图、代码互查、完成特征、测试用例、跟踪、走查(讲解开发思路)、......
测试 确认测试标准、边界值分析、检查表、实况调查与验证、基础复杂度、控制流分析、覆盖测试对照表、数据字典、功能性测试、灾难性测试、错误推测、全面测试、测试仪器、并行模拟、代码互查、系统日志、测试用例的产生及执行、程序及工具、容量测试、......
安装 确认测试标准、检查表、实况调查与验证、错误推测、全面测试、测试仪器、并行操作、代码互查、系统日志、程序及工具、......
维护 检查表、代码比较、实况调查与验证、灾难性测试、错误推测、测试仪器、综合测试工具、代码互查、系统控制审计评审、系统日志、测试用例的产生及执行、跟踪、程序及工具、......

UT - IT - ST

测试过程 单元测试(UT) 接口测试(IT) 系统测试(ST)
定义 是对软件基本组成单元(软件设计的最小单位)进行正确性检测,如函数或一个类的方法。 通常所说的接口联调,是单元测试的逻辑扩展。在单元测试的基础上,将所有模块按照HLD要求组装成为子系统或系统,验证模块间的接口是否正确的。 将已经集成好的软件系统,作为整个基于计算机系统的一个元素,与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结合在一起,在实际运行环境下,对计算机系统进行一系列的组装测试和确认测试。
测试依据 源程序本身,包括代码和注释;详细设计(LLD,Low Level Design) 单元测试的模块;概要设计(HLD,High Level Design) 软件需求规格说明(SRS,Software Requirement Specification)
测试目的 与LLD是否符合 与HLD是否符合 与SRS是否符合
测试方法 属于白盒测试范畴 属于灰盒测试范畴 属于黑盒测试范畴
考察范围 主要测试单元内部的数据结构、逻辑控制、异常处理等 主要测试模块之间的接口和接口数据传递关系,以及模块组合后的整体功能 主要测试整个系统相对于需求的符合度
评估基准 逻辑覆盖率 接口覆盖率 测试用例对需求规格的覆盖率
评估基准的方法 TDD,测试驱动开发 每个接口被覆盖的程度;每个接口的等价类、边界值被覆盖的程度 等价类两两组合;边界值分析;业务流程法;状态迁移法;错误猜测法;输出域覆盖
被测对象 一个或一组函数 子系统、模块间接口 完整的软件系统及系统交互的软硬件平台
测试时机 编码之后,代码已经通过编译之后 在单元测试之后 集成测试之后
测试人员 开发人员或白盒测试工程师 函数间/模块内集成是开发人员;模块间集成是白盒测试员;子系统间集成是黑盒测试员; 黑盒测试工程师
测试通过标准 单元测试用例的执行率为100%,通过率为95%;语句的覆盖率达100%;分支的覆盖率达85% 各个单元模块结合到一起能够协同配合,正常运行;测试用例的执行率为100%,通过率为95% 系统功能、性能等满足需求规格说明书中的要求;测试用例的执行率为100%,通过率为95%
测试策略 控制流测试、数据流测试、排错测试、分域测试等 大爆炸、自顶向下测试、自底向上测试、三明治 功能测试、性能测试、随机测试等


本期软件测试学习分享到这里就结束了,下期将为大家带来更多软件测试相关知识!


上一篇:测试用例在测试过程中的价值体现在哪些方面
下一篇:软件测试阶段详细问题汇总及心得体会

马上预约七天免费体验课

姓名:

电话:

关于软件测试方法的详细总结

初学者必须了解的测试基本概念

关于软件测试分类的概念解读

这些软件测试类型你知道几个

  • 关注微信公众号

    回复关键字:视频资料

    免费领取 达内课程视频学习资料

  • 视频学习QQ群

    添加QQ群:1143617948

    免费领取达内课程视频学习资料

Copyright © 2018 Tedu.cn All Rights Reserved 京ICP备08000853号-56 京公网安备 11010802029508号 达内时代科技集团有限公司 版权所有

选择城市和中心
江西省

贵州省

广西省

海南省