软件测试入门知识了解

一.概述

1.软件测试定义两面性

2.测试的生命周期

测试需求分析-->测试设计-->测试计划-->测试执行-->质量评估

3.软件测试过程:

 

 

需求评审和设计评审是验证软件产品的需求定义和设计实现,验证所定义的产品特性是否符合客户的期望、系统的设计是否合理、是否具有可测试性以及满足非功能质量特性的要求。这个阶段主要通过对需求文档、设计文档等阅读、讨论,从中发现软件需求工程和系统设计中所存在的问题 。 

单元测试的对象是程序系统中的最小单元---模块或组件上,在编码阶段进行,针对每个模块进行测试,主要通过白盒测试方法,从程序的内部结构出发设计测试用例,检查程序模块或组件的已实现的功能与定义的功能是否一致、以及编码中是否存在错误。多个模块可以平行地、对立地测试,通常要编写驱动模块和桩模块 单元测试一般由编程人员和测试人员共同完成。

集成测试,也称组装测试、联合测试、子系统测试,在单元测试的基础上,将模块按照设计要求组装起来同时进行测试,主要目标是发现与接口有关的模块之间问题 两种集成方式:一次性集成方式和增殖式集成方式。

功能测试一般须在完成集成测试后进行,而且是针对应用系统进行测试。功能测试是基于产品功能说明书,是在已知产品所应具有的功能,从用户角度来进行功能验证,以确认每个功能是否都能正常使用。

系统测试是将软件放在整个计算机环境下,包括软硬件平台、某些支持软件、数据和人员等,在实际运行环境下进行一系列的测试,包括恢复测试、安全测试、强度测试和性能测试等。

验收测试的目的是向未来的用户表明系统能够像预定要求那样工作,验证软件的功能和性能如同用户所合理期待的那样 。

安装测试是指按照软件产品安装手册或相应的文档,在一个和用户使用该产品完全一样的环境中或相当于用户使用环境中,进行一步一步的安装操作性的测试。

软件测试与开发关系:

二.需求和设计评审

1. 产品需求审查是软件开发重要环节之一,也是测试活动之一,即静态测试——需求验证。借助需求审查保证用户需求在市场/产品需求文档及其相关文档中得到准确、完整、无歧义的反映,并使各类开发人员在需求理解上达成一致。

2.测试需求:

测试目标取决于软件质量需求,而这种需求分为功能性需求和非功能性需求,功能性的需求相对容易确定,非功能性的测试需求难以确定。

  •  在制定测试计划之前,必须清楚测试需求
  •  明确测试需求的优先级
  •  测试需求分解得越细,对测试用例的设计质量越有帮助
  •  详细的测试需求还是衡量测试覆盖率的重要依据  
  • 测试需求是规划具体项目资源和时间的基础。

3.功能性测试需求

(1)功能性测试需求主要是根据产品规格说明书来检验被测试的系统是否满足软件各方面的功能的使用要求,包括用户界面的友好性。

  • 程序安装、启动正常,有相应的提示框、错误提示
  • 各项功能符合设计要求,正常运行并输出正确结果
  • 功能逻辑合理,并能处理各种异常操作
  • 能接受正确的数据输入,输出结果准确,格式清晰
  • 系统的各种状态按照业务流程而变化并保持稳定

支持各种应用环境,能配合硬件设备

(2)功能测试需求分析

了解需求范围-->明确目标用户-->分析功能步骤-->挖掘隐藏需求

  • 了解需求想要做什么,要完成哪些功能模块
  • 需求目标是谁?不同的用户角色,功能和权限是否一样?
  • 要完成功能,用户需要哪些步骤
  • 挖掘隐藏需求

4.用户界面及其显示要求

用户界面是和用户进行交互的窗口,其友好程度直接影响用户对于软件产品或软件服务的满意度。良好的用户体验,简单、方便和明了,让用户舒畅、愉悦

  • 通用框架、浮动窗口和文字等整体布局合理
  •  文字显示正常,且内容格式正确、美观。
  •  色彩协调,风格前后一致,  文字标记和超链接可以打开和跳转成功

5.非功能性需求

非功能性质量需求,包括系统性能、安全性、兼容性、扩充性,其测试需求会因不同的项目类型差异较大。

  • 客户端软件,如字处理软件、媒体播放软件等占用较少资源,在容错性、兼容性等方面要求高。
  • Web应用系统对性能、安全性等有很高要求 客户端/服务器应用系统。
  • 大型复杂企业级系统。

6.测试人员在需求评审中作用

需求评审归为静态测试范畴,包含了文档评审和技术评审双重内容,通常通过正式的评审会议来进行。而测试人员主要起着评审员的作用,检查需求定义是否合理和清楚。

  • 明确自己的角色和责任
  •  熟悉评审内容,为评审做好准备  
  • 针对问题阐述观点,而非针对个人
  •  从客户角度想问题,多问几个为什么
  •  在会前或会后提出自己建设性的意见
  •  对发现的问题跟踪到底
  •  针对需求文档等报告问题

7.设计审查

1)成功的产品开发和演化依赖于体系结构恰当的选择。软件设计一般可以分为体系结构设计和详细设计。测试人员参与设计评审保证需求能在设计中得到准确和完整的表示,也就是保证产品规格说明书的质量。

  •  系统架构的审查
  •  设计规格说明书的审查
  •  系统部署设计的审查
  •  多层次审查:high-level  low-level

2)系统架构设计的审查

系统架构设计的基本要求就是保证系统具有高性能、高可靠性、高安全性、高扩展性和可管理性 。系统架构设计评审就是保证这些特性在设计中得到充分考虑。

3)组件设计的审查

  • 功能和接口定义正  
  •  算法的有效性和优化
  •  合理的数据结构、数据流和控制流
  •  可测试性 等

4)系统部署设计的审查

系统部署设计的审查是基于软件服务的质量目标,用来审查软件部署的目标、策略是否合理,是否得到彻底的执行

  •  着重是否服从和遵守部署设计的技术规范
  •  逻辑设计的审查
  •  物理设计的审查
  •  可用性设计的审查  
  • 可伸缩型设计的验证
  •  安全性设计的验证

三.测试用例设计

1.测试用例(test case)是可以被独立执行的一个过程,这个过程是一个最小的测试实体,不能再被分解。测试用例也就是为了某个测试点而设计的测试操作过程序列、条件、期望结果及其相关数据的一个特定的集合。

2.测试用例的元素:

3.如何设计出高质量的测试用例

  • 客户需求导向的设计思路
  • 责任到人
  • 灵活的设计方法
  • 测试用例设计不能局限于输入数据 尽量避免含糊的、冗长的或复杂的测试用例
  • 尽量将具有相类似功能的测试用例抽象并归类

4.良好测试用例的特征

  • 可以最大程度地找出软件隐藏的缺陷
  • 可以最高效率的找出软件缺陷
  • 可以最大程度地满足测试覆盖要求
  • 既不过分复杂、也不能过分简单 使软件缺陷的表现可以清楚的判定
  • 测试用例包含期望的正确的结果
  • 待查的输出结果或文件必须尽量简单明了
  • 不包含重复的测试用例
  • 测试用例内容清晰、格式一致、分类组织

5.测试用例设计步骤

6.测试用例的创建

建立合适的、可扩展的测试用例框架,从而借助这个框

  • 72
    点赞
  • 510
    收藏
    觉得还不错? 一键收藏
  • 7
    评论
说明: 一、由于附件大小的限制,已将文件打成两个包发布(保证内容完整),请需要的朋友分开下载,谢谢合作。 二、请自行下载超星阅读器 简介:   我所见过的最好最经典的软件测试入门书,有一个别名叫“软件测试的本质”。书中没有讨论太多的软件测试理论,只包含了一部分常用的、基本的知识。从什么是软件测试、为什么要作软件测试开始,逐步引入基本的和高级的测试技术和方法,然后开始把读者引入实际工作中,讲述了一般的测试过程中要经历哪些阶段,要作哪些具体的工作,如何开展测试工作,如何找到缺陷并提交缺陷。甚至还包括了对测试人员的职业指导。建议所有的测试人员都读一读。 编辑推荐: 本书与同类书相比,具有一个显著的特点,就是浅显易懂。虽然整本书涉及的范围相当广泛,但是作者始终没有忘记,是读者的书,而不是他本人在自言自语。能够在如此庞杂的学科中流畅讲解、层层剖析,可见作者深厚的技术功底和对软件测试、软件工程的透彻理解。 目录 第一部分 软件测试综述 第1章 软件测试背景 第2章 软件开发过程 第3章 软件测试的实质 第二部分 测试基础 第4章 检查产品说明书 第5章 闭着眼睛测试软件 第6章 检查代码 第7章 带上X光眼镜检查软件 第三部分 运用测试技术 第8章 配置测试 第9章 兼容性测试 第10章 外国语言测试 第11章 易用性测试 第12章 测试文档 第四部分 加强测试 第14章 自动测试测试工具 第15章 臭由轰炸和Beat测试 第五部分 使用测试文档 第16章 计划测试工作 第17章 编写和跟踪测试案例 第18章 报告发现的问题 第19章 评价成效 第六部分 软件测试展望 第20章 软件质量评判 第21章 软件测试员职业指导 附录测验问题解答

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

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

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值