测试基本概念

简介: 一、软件质量保证和软件测试的区别软件质量保证(Software Quality Assurance):SQA介入于整个软件开发过程——监督和改进过程,确认达成的标准和过程被正确的遵循,保证问题被发现和解决。

一、软件质量保证和软件测试的区别

软件质量保证(Software Quality Assurance):SQA介入于整个软件开发过程——监督和
改进过程,确认达成的标准和过程被正确的遵循,保证问题被发现和解决。它以预防
为主。
软件测试(Software Testing):软件测试是在一定控制的条件下,围绕一个系统或应用
的操作并且评价其结果(一个最简单的例子:如果用户使用硬件A,在应用接口B上做
了操作C,那么结果D应当出现),控制的条件应当包括正常和异常的条件。测试企图
使事情变得很糟糕,从而来检测出一些应当发生而没有发生,或者不应当发生而发生
的事情。测试以检测为主。
*关于如何安排QA和测试的任务时,不同的组织变化是很大的。有时它们可以有一个
组或个人来负责,共同的是一个项目组混合了测试人员和开发人员,并且他们一起紧
密的工作,而QA过程有项目经理来监督。所有这些是同组织的大小和商业结构有关
的。

 二、软件中存在错误的来源

1、缺乏或者没有进行沟通,如对于一些我们应用程序中应当或者不应当实现的细节问
题。
2、软件复杂度——在当今的软件开发中,对于一些没有经验的人来说,软件复杂性
可能是难以理解的。图形化界面,客户/服务器和分布式的应用,数据通信,大规模的
关系数据库,应用程序的规模等指数般的增加了软件的复杂度。面向对象技术也有可
能增加软件复杂度,除非能够被很好的工程化。
3、编程错误——任何一个编程人员都可能产生错误。
4、不断变更的需求——用户可能不知道变更的影响,或者知道影响却还是需要进行
变更,这些会引起重新设计,工程的重新安排,对其它项目的影响,已完成的工作可
能不得不重做或推翻,硬件需求可能也会受到影响。如果存在许多小的变更或者任何
大的改动,由于项目中不同部分间可知和不可知的依赖关系,这样就会产生问题,跟
踪变更的复杂性也可能引入错误。项目开发人员的积极性也会受到打击。在一些快速
变化的商业环境下,不断变更的需求可能是一种残酷的事实。在这种情况下,管理人
员必须了解结果的风险,QA工程师和测试工程师必须适应和计划进行大规模的测试来
防止不可避免的BUG出现无法控制的局面。
5、时间的压力——软件项目的时间安排是最难的,通常是需要很多猜测的工作。当最
后期限来临的时候,错误也就伴随发生了。
6、人员的自大——我们经常会发现人们普遍喜欢说:
 “没问题”
 “很简单”
 “我可以在几小时内解决那个问题”
 “修改那些老代码应当是很简单的”
 而不是说:
 “那会增加很多复杂性,可能会导致很多错误”
 “如果我们要做那个的话,我们将无能为力”
 “我无法估计可能要多长时间,除非我能进一步进行观察和研究”
 “我们无法搞清楚那些混乱的代码到底在做什么事情”
 如果存在太多的“没问题”的话,问题也就产生了。
 7、缺乏文档的代码——维护和修改很差的代码或缺乏文档的代码是很困难的。最终
结果将导致BUG的出现。
 8、软件开发工具——视图工具,类库,编译器,脚本工具等等通常会把它们自身的
BUG 引入到你的项目中。

三、测试分类

1、黑盒测试——不是基于内部代码和设计的知识,而是基于需求和功能。
 2、白盒测试——基于应用程序的内部逻辑的知识,通过语句,分支,路径和条件的
覆盖率。
 3、单元测试——测试中的最小单位,测试特殊的功能或代码模块。由于需要对内部
代码和设计的详细知识,该测试一般由开发者完成而不是由测试人员完成。该测试的
容易程度同代码设计的好坏直接相关。
 4、增量型的集成测试——随着新功能的增加,不断的对应用程序进行测试。在程序
的所有部分完成之前,需要一个应用程序的各个部分之间能够相对独立的进行工作。
这类型测试可以有开发者或测试者完成
 5、集成测试——测试应用程序结合的部分来确定它们的功能结合到一起是正确的。
在这里‘部分’的概念可能是代码模块,独立的应用程序,在网络上的客户端和服务
器断程序等等。这类型测试典型的是于客户/服务器和分布式系统相关。
 6、功能测试——是一种黑盒测试,同应用程序的功能需求紧密相关。这类型测试应
当有测试人员来完成。这并不意味着开发人员在发布版本之前就不需要检查他们的代
码。
 7、端到端测试——同系统测试类似,包括模拟现实世界对一个完整的应用环境进行
测试。例如同数据库进行交互、使用网络通信,或者其他的软件、硬件和系统进行交
互。
 8、理智测试——这是一种典型的原始测试,其目的是要确定一个新的软件版本在一
些主要的测试努力下表现的足够好并且可以接受。例如:如果一个新软件每五分钟当
机一次,使系统执行速度极其缓慢,或者破坏系统数据,那么该软件就处于不够‘理
智’状态,必须保证在当前状态下进行进一步测试。
 9、回归测试——在软件或环境被修改后进行的再测试。可能很难确定我们需要进行
多少的再测试,尤其接近到开发过程的末期。自动测试工具可能会有很大的帮助。
10、可接受性测试——基于最终用户的规格进行的最后测试。或者基于最终用户在一
定的时间范围内的测试。
11、负荷测试——在高负荷条件下进行的测试。
12、压力测试——该术语通常同负荷测试和性能测试是可交换的。也可用于描述这样
一些测试
 如:在不正常的负荷状态下,过分的重复某些动作或输入情况下进行的系统功能测试
13、性能测试——该术语通常同负荷测试和压力测试是可交换的。理想的性能测试是
定义在需求文档或QA测试计划中的。
14、安装和反安装测试——测试完全、部分或升级的安装/反安装过程
15、恢复测试——测试当出现崩溃,硬件错误或其他灾难性问题时,系统的表现情况
16、安全性测试——测试系统对于内部和外部非法入侵、故意损坏时的表现情况。可
能需要复杂的测试技术。
17、兼容性测试——测试系统在不同的平台/硬件/操作系统/网络上的表现情况。
18、ALPHA测试——在开发进行结束的时候进行的测试。针对测试的结果可能还会进
行一些小的设计更改。这类测试典型的是由用户进行的,而不是由开发者或测试人员
进行的。
19、BETA测试——在开发和测试已经全部结束后,并且在最终版本发布之前进行的
测试。这类测试典型的是由用户进行的,而不是由开发者或测试人员进行的。

 

四、开发和执行软件测试需要哪些步骤

1、获取需求、功能设计、详细设计规格和其它必须文档
2、获取预算和时间安排需求
3、确定项目相关人员和他们的责任,汇报需求,必须的标准和过程(如版本过
程、变更过程等)
4、确认应用高风险的部分,设定优先级,确定测试的范围和限制
5、确定测试的方法——单元测试、集成测试、功能测试、负荷测试、可用性测
试等
6、确定环境需求(软件/硬件/通信等)
7、确定测试用具环境(记录/回放工具、覆盖率分析器、测试跟踪、问题跟踪等
等)
8、确定测试输入需求
9、确定任务,任务责任和相应的工作量
10、设定时间安排估计、时间表、里程碑等
11、确定输入的等价类、边界值分析、错误类
12、准备测试计划文档和需要的评审
13、写测试用例
14、对测试用例进行必须的评审
15、准备测试环境和测试用具,获取需要的用户手册/参考文档/配置指导/安装
指导,建立跟踪过程,日志和存档过程,获取测试数据
16、获取和安装软件版本
17、执行测试
18、评价和汇报测试结果
19、跟踪问题和修改
20、如果需要进行再测试
21、在整个生命周期内维护和修改测试计划、测试用例、测试环境和测试用具

五、什么是测试计划

测试计划是描述软件测试努力的目标、范围、方法和焦点的文档。准备测试计
划的过程是完整考虑软件产品可接受评价努力的一个有用的方法。完整的文档
将有助于测试组之外的人理解为什么要进行软件正确性检测,并且如何进行检
测。测试计划应当足够完整但也不应当太详尽,以致在测试组之外没有人会读
它。下面是一些可能会包含在测试计划中的一些内容,依赖于特定的项目:
1、标题
2、确定软件的版本号
3、修订文档历史,包括作者、日期和批示
4、目录表
5、文档的目的和适合的读者群
6、测试的目的
7、软件产品概述
8、相关文档列表,例如:需求、设计文档、其他测试计划等
9、相关的标准或合法需求
10、可跟踪性需求
11、相关的命名规范和标识符规范
12、整个软件项目组织和人员/联系信息/责任
13、测试组织和人员/联系信息/责任
14、假设和依赖关系
15、项目风险信息
16、测试优先级和焦点
17、测试范围和限制
19、测试提纲——对测试过程的一个分解,通过测试类型、特点、功能性、过
程、系统、模块等
20、测试环境设置和配置问题
21、数据库设置需求
22、概述系统日志/错误日志/其他性能,有助于描述和汇报问题的屏幕捕获工具
等
23、有助于测试者跟踪问题根源的具体软硬件工具的论述
24、测试自动化的可能性和概述
25、使用的测试工具,包括版本、补丁等
26、使用的项目测试度量
27、报告需求和测试可传递性
28、软件入口和出口准则
29、初始的理性测试阶段和标准
30、测试终止和重新开始的标准
31、人员安排
32、测试地点
33、用到的测试外的组织,他们的目的、责任、可传递性、联系人和协作问题
34、相关的财产、分类、安全性和许可证问题
35、公开的一些问题
36、附录——词汇表、缩略语等

 六、什么是测试用例

1、一个测试用例就是一个文档,描述输入、动作、或者时间和一个期望的结果,其目
的是确定应用程序的某个特性是否正常的工作。一个测试用例应当有完整的信息,
如:测试用例ID号,测试用例名字,测试用例的目的,测试条件、输入数据需求、步
骤和期望结果。
2、注意开发测试用例的过程有助于在应用的需求和设计中发现问题。这主要是由于是
需要完整的考虑应用的整个操作。正因为这样,需要在开发的早期准备测试用例。

七、制定测试计划应该考虑哪些因素

应明确的在测试计划中确立好"测试管理机制"的关键事件,如:
1>.汇报机制确定好用周报制度还是日报制度,日报的反馈速度快,定位解决问
题快,但信息处理工作量大;
2>.例会制度,每周举行一次例会,根据实际情况,考虑测试计划的调整或滚动;
3>.实施怎样的实验室管理制度,以做到责任明确;
4>.在日报中的工作汇报:不仅是发现的问题,还应包括在测试时新创造的测试
点,这些测试点应该补充到测试计划中作为一个测试项
5>.人员情绪如何调整,在测试周期过长时,影响测试效率的一个重要因素是测
试人员的情绪,一个人反复测试一个模块,总是会出现厌倦情绪的。具体怎么调整?
是一个有待讨论的问题。
应明确的在测试计划中确立"数据"的管理和分析体系和办法,如:
专人对提交的过程文档,周报报告中的数据予以整理和管理,以便后期在系统测
试评审时作为数据来分析。
 现在往往是在系统测试结束后才来收集数据,可能会造成数据的不同程度失真或滞
后。收集的数据可以按不同种类来划分。这可以依赖我们系统CHECKLIST。有一种工
具叫 SRES (软件可靠性专家系统) 还是很有用的,我们可以按照它的输入数据来收
集。
应明确的在测试计划中确立"风险估计"的引入,如:
制定测试计划时,就应该考虑好对系统测试工作量的估计,测试成本的估计,版本
市场定位的估计等等,并且必要时可根据实际情况进行裁剪或补充

 

目录
相关文章
|
1月前
|
Java 测试技术 Maven
JAVA单元测试概念与实战
单元测试是软件开发中的一个测试方法,用于验证软件代码中最小的、独立的单元是否按照预期工作。在Java中,这通常指的是单个的方法或者一个类的个别功能。单元测试的目的是隔离代码的每个部分,并确保各个部分是正确的。
65 4
|
1月前
|
jenkins 测试技术 持续交付
软件测试:基础概念
软件测试:基础概念
68 0
|
1月前
|
测试技术 UED
软件测试/测试开发|软件测试基础概念
软件测试/测试开发|软件测试基础概念
35 0
|
19天前
|
测试技术
深入探索软件测试:从基本概念到先进方法
【5月更文挑战第30天】 在这篇文章中,我们将深入研究软件测试的各个方面。我们将从基本的软件测试概念开始,然后探讨一些先进的测试方法和工具。我们的目标是为读者提供一个全面的软件测试概览,帮助他们更好地理解这个领域。
|
20天前
|
测试技术
软件测试概念与基础
软件测试概念与基础
|
21天前
|
测试技术 网络安全
精简总结:一文说明软件测试基础概念(二)
本文讲述了软件测试人员应具备的素质,包括技能和非技能方面。技能涵盖测试用例设计、编程、快速学习新技术以及业务学习能力。
22 0
|
21天前
|
SQL 架构师 安全
精简总结:一文说明软件测试基础概念(一)
该内容是关于软件测试的介绍,包括软件测试的基础概念、特点、与开发的区别,以及与调试的差异。文中提到了测试是为了验证软件是否满足用户需求,确保软件质量,并举例说明了日常生活中测试的存在。还讨论了软件测试的不可穷尽性,并列举了软件测试与开发在内容、技能和职业发展路径上的不同。此外,提到了《软件测试的艺术》这本书作为学习资源。内容中包含了两张图片,分别展示了相关概念。
28 0
|
27天前
|
敏捷开发 Web App开发 测试技术
【软件测试】概念篇 -- 详解(下)
【软件测试】概念篇 -- 详解(下)
|
27天前
|
安全 测试技术 程序员
【软件测试】概念篇 -- 详解(上)
【软件测试】概念篇 -- 详解(上)
|
1月前
|
测试技术 开发者
【专栏】测试驱动开发(TDD)和行为驱动开发(BDD)的核心概念与实践
【4月更文挑战第27天】本文探讨了测试驱动开发(TDD)和行为驱动开发(BDD)的核心概念与实践。TDD强调先写测试用例,通过测试推动设计,确保代码质量与可维护性。BDD侧重软件行为和业务价值,提倡使用通用语言描述行为,减少沟通障碍。选择TDD或BDD取决于项目复杂性、团队技能和业务需求。理解两者差异有助于团队做出合适的选择,发挥测试的最大价值。