偶看新闻适合下雨天听的中文歌:软件测试基本理论
来源：百度文库 编辑：偶看新闻 时间：2024/04/28 11:23:23
软件测试基本理论 2007-10-20 16:52
分类：求职就业 字号： 大大 中中 小小 软件工程模型
谈起测试学，不得不讨论一下软件工程模型，因为测试学与软件工程学的发展依依相关，相辅相成。另外对于比较先进的测试理念，测试工程师应该贯穿于软件工程的整体过程之中。 瀑布模型
这个模型大概是现在最经典的软件工程模型，业务建模-〉系统分析-〉概要设计-〉详细设计-〉编码-〉测试-〉部署。
但是这个模型存在着比较严重的问题： 1，不可反复，不适应与需求变更处理：由于瀑布模型从业务建模到部署一脉相承，不可以回复。现代软件项目中需求变更是无处不存在的：唯一不变的就是需求变更。而运用这种模型，只要项目需求发生变化，就要打翻重新进行系统分析，概要设计，详细设计… 2，用户很难在项目初期了解项目状态：由于用户在项目初期很难提出自己的需求，他们有时候也不知道该做些啥？而利用瀑布模型只有到编码结束，用户才可以看到正正他们所需要的产品，而初期这些产品往往是他们所了解不全的，需要补充的，客户往往在这个时期推翻他们的需求，要求另立需求，这样往往给客户方，需求方带来比较麻烦的结果。 迭代模型和螺旋模型：
这两个模型往往在概念上区别不明显，许多书上将这两个模型混为一谈。其实这两个模型的思想本质上是一致的。他将客户的需求按照用户的重要等级和模块自身的等级，从最基础的进行分析，设计，编码，测试，然后再进入下一轮迭代。这样用户可以在每一轮结束就可以看到产品的一些雏形，进行需求变更和下一轮的建议，由于初期开发工作比较少，用户又可以在产品初期提出相对可观的下一轮的需求，所以这样的模型往往利于现在软件公司产品的开发，著名的RUP工具每一项都遵循迭代的思想。 测试模型 V模型
单元测试--编码
集成测试--详细设计
系统测试--总体设计
接收测试--产品 单元测试相对于编码进行，这一步往往由测试人员来执行；
集成测试相对于详细设计，他将模块由上到下，由下到上进行逐步的集成。以测试模块与模块，类与类之间的关联性；
系统测试是相对于总体设计而言的，测试人员站在用户的角度对系统进行全面的测试工作；
接收测试是用户对产品进行测试，一般分为Alpha测试和Beta测试。Alpha测试一般由公司内部的非技术人员或非参与人员对产品进行的测试；Beta测试往往是指定客户对公司进行测试，是系统推出市场之前，测试阶段推出的第二个版本。 V模型可以运用于瀑布模型和迭代模型
X模型
X模型是将软件系统分为若干模块，对每个模块进行单元，集成以及系统测试，然后统一对模块进行集成测试，这种测试方法目前软件行业处于淘汰趋势。 前置模型
图示中所列出的是面向对象的前置模型，其他编成方法的前置模型大小意，就是将测试贯穿于软件开发的全部过程。在需求，设计和编码阶段对产生的工件进行复审，提出自己的建议和意见。对于前置软件测试法，bug在软件前期就可以发现从而降低软件开发成本。 不利用前置方法的bug曲线。
利用前置方法的bug曲线,bug在开始之前就能够被发现。
软件测试方法 白盒 黑盒
动态 就是利用KDE的调试功能逐步调试程序，进行测试 就是普通所说的通过人工或者自动方法进行测试
静态 即test review 就是对需求，设计工件进行审核 软件测试步骤
测试计划
书写测试用例
开发测试代码
开展测试工作（往往需要进行几次轮测包括测试和复测，每次对于测试中的bug，要求开发人员给与明确答复修改完毕，非法bug以及下一版中解决） 2 评估测试
软件测试类型 1.数据和数据库完整性测试
在项目名称中，数据库和数据库进程应作为一个子系统来进行测试。在测试这些子系统时，不应将测试对象的用户界面用作数据的接口。对于数据库管理系统 (DBMS)，还需要进行深入的研究，以确定可以支持以下测试的工具和技术。 2.功能测试
对测试对象的功能测试应侧重于所有可直接追踪到用例或业务功能和业务规则的测试需求。这种测试的目标是核实数据的接受、处理和检索是否正确，以及业务规则的实施是否恰当。此类测试基于黑盒技术，该技术通过图形用户界面 (GUI) 与应用程序进行交互，并对交互的输出或结果进行分析，以此来核实应用程序及其内部进程。以下为各种应用程序列出了推荐使用的测试概要： 3.UI测试
用户界面 (UI) 测试用于核实用户与软件之间的交互。UI 测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。另外，UI 测试还可确保 UI 中的对象按照预期的方式运行，并符合公司或行业的标准。包括用户友好性，人性化测试。 4.性能测试
4.1负载测试：
负载测试是一种性能测试。在这种测试中，将使测试对象承担不同的工作量，以评测和评估测试对象在不同工作量条件下的性能行为，以及持续正常运行的能力。负载测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。此外，负载测试还要评估性能特征，例如，响应时间、事务处理速率和其他与时间相关的方面。 4.2强度测试
是一种性能测试，实施和执行此类测试的目的是找出因资源不足或资源争用而导致的错误。如果内存或磁盘空间不足，测试对象就可能会表现出一些在正常条件下并不明显的缺陷。而其他缺陷则可能由于争用共享资源（如数据库锁或网络带宽）而造成的。强度测试还可用于确定测试对象能够处理的最大工作量。 4.3容量测试
容量测试使测试对象处理大量的数据，以确定是否达到了将使软件发生故障的极限。容量测试还将确定测试对象在给定时间内能够持续处理的最大负载或工作量。例如，如果测试对象正在为生成一份报表而处理一组数据库记录，那么容量测试就会使用一个大型的测试数据库，检验该软件是否正常运行并生成了正确的报表。 4.4基准测试
与已知系统的比较 4.5竞争测试
软件竞争使用各种资源（数据纪录，内存等） 5. 安全性和访问控制测试
安全性和访问控制测试侧重于安全性的两个关键方面：
应用程序级别的安全性，包括对数据或业务功能的访问
系统级别的安全性，包括对系统的登录或远程访问。
应用程序级别的安全性可确保：在预期的安全性情况下，主角只能访问特定的功能或用例，或者只能访问有限的数据。例如，可能会允许所有人输入数据，创建新账户，但只有管理员才能删除这些数据或账户。如果具有数据级别的安全性，测试就可确保“用户类型一” 能够看到所有客户消息（包括财务数据），而“用户二”只能看见同一客户的统计数据。
系统级别的安全性可确保只有具备系统访问权限的用户才能访问应用程序，而且只能通过相应的网关来访问。 6.故障转移和恢复测试
可确保测试对象能成功完成故障转移，并能从导致意外数据损失或数据完整性破坏的各种硬件、软件或网络故障中恢复。
故障转移测试可确保：对于必须持续运行的系统，一旦发生故障，备用系统就将不失时机地“顶替”发生故障的系统，以避免丢失任何数据或事务。 恢复测试是一种对抗性的测试过程。在这种测试中，将把应用程序或系统置于极端的条件下（或者是模拟的极端条件下），以产生故障（例如设备输入/输出 (I/O) 故障或无效的数据库指针和关健字）。然后调用恢复进程并监测和检查应用程序和系统，核实应用程序或系统和数据已得到了正确的恢复。 7.配置测试
配置测试核实测试对象在不同的软件和硬件配置中的运行情况。在大多数生产环境中，客户机工作站、网络连接和数据库服务器的具体硬件规格会有所不同。客户机工作站可能会安装不同的软件例如，应用程序、驱动程序等而且在任何时候，都可能运行许多不同的软件组合，从而占用不同的资源。（如浏览器版本。OS版本等） 8.安装测试
安装测试有两个目的。第一个目的是确保该软件在正常情况和异常情况的不同条件下: 例如，进行首次安装、升级、完整的或自定义的安装_都能进行安装。异常情况包括磁盘空间不足、缺少目录创建权限等。第二个目的是核实软件在安装后可立即正常运行。这通常是指运行大量为功能测试制定的测试。 9.本地化测试
又称本地化测试，是指为各个地方开发产品的测试，如英文版，中文版等等，包括程序是否能够正常运行，界面是否符合当地习俗，快捷键是否正常起作用等等，特别测试在A语言环境下运行B语言软件（比如在英文win98下试图运行中文版的程序），出现现象是否正常。 10.文字测试
测试文字是否拼写正确，是否易懂，不存在二义性，没有语法错误；文字与内容是否由出入等等，包括图片文字 11.分辨率测试
测试在不同分辨率下，界面的美观程度,分为800*600，1024*768，1152*864，1280*768，1280*1024，1200*1600大小字体下测试 12发布测试
主要在产品发布前对一些附带产品，比如说明书，广告稿等进行测试 12.1说明书测试
主要为语言检查，功能检查，图片检查
语言检查：检查说明书语言是否正确，用词是否易于理解；
功能检查：功能是否描述完全，或者描述了并没有的功能等；
图片检查:：检查图片是否正确 12.2宣传材料测试
主要测试产品中的附带的宣传材料中的语言，描述功能，图片 12.3帮助文件测试
帮助文件是否正确，易懂，是否人性化 12.4广告用语 产品出公司前的广告材料文字，功能，图片，人性化的检查 软件测试曲线 大家都知道软件的bug是不可能为零的，它一般随着时间的推移bug数逼近于零，用一个曲线图表示： 这里横坐标是时间，纵坐标是还没有发现的bugs数。项目开始之前bug为无穷大，随着时间的推移，bug趋于零但是不会等于零。 由于bug不会等于零，难道产品就不发布了吗？还有一种bug可以确定产品发布时间。 横坐标为时间，纵坐标是已经发现的bugs数，当这个曲线趋于平稳，也就是说它的斜率趋于零的时候，这个产品就可以发布了。 软件的杀虫剂现象 由于测试人员的思路不尽相同，每个人测试的侧重点不同，由于都按照测试用例进行测试，但是测试用例一般仅描述系统的一些基本测试项，不会将所有的测试用例方方面面都写到，有时还需要测试人员的经验和素质。所以A测试某个产品用了七个工作日，第一天到第四天报出许多bug,但从第五天开始几乎报不出啥 bug了。七天后换了B,B一下子又测试出一堆bug,不能说A的水平差，只能说，该产品已经对A产生了抗药性，这就是测试学中的杀虫剂现象。用图表示： 所以在测试中每次轮流测试最好安排不同的测试人员进行不同模块测试工作，以避免杀虫剂现象产生。
分类：求职就业 字号： 大大 中中 小小 软件工程模型
谈起测试学，不得不讨论一下软件工程模型，因为测试学与软件工程学的发展依依相关，相辅相成。另外对于比较先进的测试理念，测试工程师应该贯穿于软件工程的整体过程之中。 瀑布模型
这个模型大概是现在最经典的软件工程模型，业务建模-〉系统分析-〉概要设计-〉详细设计-〉编码-〉测试-〉部署。
但是这个模型存在着比较严重的问题： 1，不可反复，不适应与需求变更处理：由于瀑布模型从业务建模到部署一脉相承，不可以回复。现代软件项目中需求变更是无处不存在的：唯一不变的就是需求变更。而运用这种模型，只要项目需求发生变化，就要打翻重新进行系统分析，概要设计，详细设计… 2，用户很难在项目初期了解项目状态：由于用户在项目初期很难提出自己的需求，他们有时候也不知道该做些啥？而利用瀑布模型只有到编码结束，用户才可以看到正正他们所需要的产品，而初期这些产品往往是他们所了解不全的，需要补充的，客户往往在这个时期推翻他们的需求，要求另立需求，这样往往给客户方，需求方带来比较麻烦的结果。 迭代模型和螺旋模型：
这两个模型往往在概念上区别不明显，许多书上将这两个模型混为一谈。其实这两个模型的思想本质上是一致的。他将客户的需求按照用户的重要等级和模块自身的等级，从最基础的进行分析，设计，编码，测试，然后再进入下一轮迭代。这样用户可以在每一轮结束就可以看到产品的一些雏形，进行需求变更和下一轮的建议，由于初期开发工作比较少，用户又可以在产品初期提出相对可观的下一轮的需求，所以这样的模型往往利于现在软件公司产品的开发，著名的RUP工具每一项都遵循迭代的思想。 测试模型 V模型
单元测试--编码
集成测试--详细设计
系统测试--总体设计
接收测试--产品 单元测试相对于编码进行，这一步往往由测试人员来执行；
集成测试相对于详细设计，他将模块由上到下，由下到上进行逐步的集成。以测试模块与模块，类与类之间的关联性；
系统测试是相对于总体设计而言的，测试人员站在用户的角度对系统进行全面的测试工作；
接收测试是用户对产品进行测试，一般分为Alpha测试和Beta测试。Alpha测试一般由公司内部的非技术人员或非参与人员对产品进行的测试；Beta测试往往是指定客户对公司进行测试，是系统推出市场之前，测试阶段推出的第二个版本。 V模型可以运用于瀑布模型和迭代模型
X模型
X模型是将软件系统分为若干模块，对每个模块进行单元，集成以及系统测试，然后统一对模块进行集成测试，这种测试方法目前软件行业处于淘汰趋势。 前置模型
图示中所列出的是面向对象的前置模型，其他编成方法的前置模型大小意，就是将测试贯穿于软件开发的全部过程。在需求，设计和编码阶段对产生的工件进行复审，提出自己的建议和意见。对于前置软件测试法，bug在软件前期就可以发现从而降低软件开发成本。 不利用前置方法的bug曲线。
利用前置方法的bug曲线,bug在开始之前就能够被发现。
软件测试方法 白盒 黑盒
动态 就是利用KDE的调试功能逐步调试程序，进行测试 就是普通所说的通过人工或者自动方法进行测试
静态 即test review 就是对需求，设计工件进行审核 软件测试步骤
测试计划
书写测试用例
开发测试代码
开展测试工作（往往需要进行几次轮测包括测试和复测，每次对于测试中的bug，要求开发人员给与明确答复修改完毕，非法bug以及下一版中解决） 2 评估测试
软件测试类型 1.数据和数据库完整性测试
在项目名称中，数据库和数据库进程应作为一个子系统来进行测试。在测试这些子系统时，不应将测试对象的用户界面用作数据的接口。对于数据库管理系统 (DBMS)，还需要进行深入的研究，以确定可以支持以下测试的工具和技术。 2.功能测试
对测试对象的功能测试应侧重于所有可直接追踪到用例或业务功能和业务规则的测试需求。这种测试的目标是核实数据的接受、处理和检索是否正确，以及业务规则的实施是否恰当。此类测试基于黑盒技术，该技术通过图形用户界面 (GUI) 与应用程序进行交互，并对交互的输出或结果进行分析，以此来核实应用程序及其内部进程。以下为各种应用程序列出了推荐使用的测试概要： 3.UI测试
用户界面 (UI) 测试用于核实用户与软件之间的交互。UI 测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。另外，UI 测试还可确保 UI 中的对象按照预期的方式运行，并符合公司或行业的标准。包括用户友好性，人性化测试。 4.性能测试
4.1负载测试：
负载测试是一种性能测试。在这种测试中，将使测试对象承担不同的工作量，以评测和评估测试对象在不同工作量条件下的性能行为，以及持续正常运行的能力。负载测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。此外，负载测试还要评估性能特征，例如，响应时间、事务处理速率和其他与时间相关的方面。 4.2强度测试
是一种性能测试，实施和执行此类测试的目的是找出因资源不足或资源争用而导致的错误。如果内存或磁盘空间不足，测试对象就可能会表现出一些在正常条件下并不明显的缺陷。而其他缺陷则可能由于争用共享资源（如数据库锁或网络带宽）而造成的。强度测试还可用于确定测试对象能够处理的最大工作量。 4.3容量测试
容量测试使测试对象处理大量的数据，以确定是否达到了将使软件发生故障的极限。容量测试还将确定测试对象在给定时间内能够持续处理的最大负载或工作量。例如，如果测试对象正在为生成一份报表而处理一组数据库记录，那么容量测试就会使用一个大型的测试数据库，检验该软件是否正常运行并生成了正确的报表。 4.4基准测试
与已知系统的比较 4.5竞争测试
软件竞争使用各种资源（数据纪录，内存等） 5. 安全性和访问控制测试
安全性和访问控制测试侧重于安全性的两个关键方面：
应用程序级别的安全性，包括对数据或业务功能的访问
系统级别的安全性，包括对系统的登录或远程访问。
应用程序级别的安全性可确保：在预期的安全性情况下，主角只能访问特定的功能或用例，或者只能访问有限的数据。例如，可能会允许所有人输入数据，创建新账户，但只有管理员才能删除这些数据或账户。如果具有数据级别的安全性，测试就可确保“用户类型一” 能够看到所有客户消息（包括财务数据），而“用户二”只能看见同一客户的统计数据。
系统级别的安全性可确保只有具备系统访问权限的用户才能访问应用程序，而且只能通过相应的网关来访问。 6.故障转移和恢复测试
可确保测试对象能成功完成故障转移，并能从导致意外数据损失或数据完整性破坏的各种硬件、软件或网络故障中恢复。
故障转移测试可确保：对于必须持续运行的系统，一旦发生故障，备用系统就将不失时机地“顶替”发生故障的系统，以避免丢失任何数据或事务。 恢复测试是一种对抗性的测试过程。在这种测试中，将把应用程序或系统置于极端的条件下（或者是模拟的极端条件下），以产生故障（例如设备输入/输出 (I/O) 故障或无效的数据库指针和关健字）。然后调用恢复进程并监测和检查应用程序和系统，核实应用程序或系统和数据已得到了正确的恢复。 7.配置测试
配置测试核实测试对象在不同的软件和硬件配置中的运行情况。在大多数生产环境中，客户机工作站、网络连接和数据库服务器的具体硬件规格会有所不同。客户机工作站可能会安装不同的软件例如，应用程序、驱动程序等而且在任何时候，都可能运行许多不同的软件组合，从而占用不同的资源。（如浏览器版本。OS版本等） 8.安装测试
安装测试有两个目的。第一个目的是确保该软件在正常情况和异常情况的不同条件下: 例如，进行首次安装、升级、完整的或自定义的安装_都能进行安装。异常情况包括磁盘空间不足、缺少目录创建权限等。第二个目的是核实软件在安装后可立即正常运行。这通常是指运行大量为功能测试制定的测试。 9.本地化测试
又称本地化测试，是指为各个地方开发产品的测试，如英文版，中文版等等，包括程序是否能够正常运行，界面是否符合当地习俗，快捷键是否正常起作用等等，特别测试在A语言环境下运行B语言软件（比如在英文win98下试图运行中文版的程序），出现现象是否正常。 10.文字测试
测试文字是否拼写正确，是否易懂，不存在二义性，没有语法错误；文字与内容是否由出入等等，包括图片文字 11.分辨率测试
测试在不同分辨率下，界面的美观程度,分为800*600，1024*768，1152*864，1280*768，1280*1024，1200*1600大小字体下测试 12发布测试
主要在产品发布前对一些附带产品，比如说明书，广告稿等进行测试 12.1说明书测试
主要为语言检查，功能检查，图片检查
语言检查：检查说明书语言是否正确，用词是否易于理解；
功能检查：功能是否描述完全，或者描述了并没有的功能等；
图片检查:：检查图片是否正确 12.2宣传材料测试
主要测试产品中的附带的宣传材料中的语言，描述功能，图片 12.3帮助文件测试
帮助文件是否正确，易懂，是否人性化 12.4广告用语 产品出公司前的广告材料文字，功能，图片，人性化的检查 软件测试曲线 大家都知道软件的bug是不可能为零的，它一般随着时间的推移bug数逼近于零，用一个曲线图表示： 这里横坐标是时间，纵坐标是还没有发现的bugs数。项目开始之前bug为无穷大，随着时间的推移，bug趋于零但是不会等于零。 由于bug不会等于零，难道产品就不发布了吗？还有一种bug可以确定产品发布时间。 横坐标为时间，纵坐标是已经发现的bugs数，当这个曲线趋于平稳，也就是说它的斜率趋于零的时候，这个产品就可以发布了。 软件的杀虫剂现象 由于测试人员的思路不尽相同，每个人测试的侧重点不同，由于都按照测试用例进行测试，但是测试用例一般仅描述系统的一些基本测试项，不会将所有的测试用例方方面面都写到，有时还需要测试人员的经验和素质。所以A测试某个产品用了七个工作日，第一天到第四天报出许多bug,但从第五天开始几乎报不出啥 bug了。七天后换了B,B一下子又测试出一堆bug,不能说A的水平差，只能说，该产品已经对A产生了抗药性，这就是测试学中的杀虫剂现象。用图表示： 所以在测试中每次轮流测试最好安排不同的测试人员进行不同模块测试工作，以避免杀虫剂现象产生。