软件工程模型

　　谈起测试学，不得不讨论一下软件工程模型，因为测试学与软件工程学的发展依依相关，相辅相成。另外对于比较先进的测试理念，测试工程师应该贯穿于软件工程的整体过程之中。

　　瀑布模型

　　这个模型大概是现在最经典的软件工程模型，业务建模-〉系统分析-〉概要设计-〉详细设计-〉编码-〉测试-〉部署。

　　但是这个模型存在着比较严重的问题：

　　1、不可反复，不适应与需求变更处理：由于瀑布模型从业务建模到部署一脉相承，不可以回复。现代软件项目中需求变更是无处不存在的：唯一不变的就是需求变更。而运用这种模型，只要项目需求发生变化，就要打翻重新进行系统分析，概要设计，详细设计…

　　2、用户很难在项目初期了解项目状态：由于用户在项目初期很难提出自己的需求，他们有时候也不知道该做些啥？而利用瀑布模型只有到编码结束，用户才可以看到正 正他们所需要的产品，而初期这些产品往往是他们所了解不全的，需要补充的，客户往往在这个时期推翻他们的需求，要求另立需求，这样往往给客户方，需求方带来比较麻烦的结果。

　　迭代模型和螺旋模型：

　　这两个模型往往在概念上区别不明显，许多书上将这两个模型混为一谈。其实这两个模型的思想本质上是一致的。他将客户的需求按照用户的重要等级和模块自身的等级，从最基础的进行分析，设计，编码，测试，然后再进入下一轮迭代。这样用户可以在每一轮结束就可以看到产品的一些雏形，进行需求变更和下一轮的建议，由于初期开发工作比较少，用户又可以在产品初期提出相对可观的下一轮的需求，所以这样的模型往往利于现在软件公司产品的开发，著名的RUP工具每一项都遵循迭代的思想。

　　测试模型

　　V模型

　　² 单元测试相对于编码进行，这一步往往由测试人员来执行；

　　² 集成测试相对于详细设计，他将模块由上到下，由下到上进行逐步的集成。以测试模块与模块，类与类之间的关联性；

　　² 系统测试是相对于总体设计而言的，测试人员站在用户的角度对系统进行全面的测试工作；

　　² 接收测试是用户对产品进行测试，一般分为Alpha测试和Beta测试。Alpha测试一般由公司内部的非技术人员或非参与人员对产品进行的测试；Beta测试往往是指定客户对公司进行测试，是系统推出市场之前，测试阶段推出的第二个版本。

　　V模型可以运用于瀑布模型和迭代模型

　　X模型

　　X模型是将软件系统分为罗干模块，对每个模块进行单元，集成以及系统测试，然后统一对模块进行集成测试，这种测试方法目前软件行业处于淘汰趋势。

　　前置模型

　　图示中所列出的是面向对象的前置模型，其他编成方法的前置模型大小意，就是将测试贯穿于软件开发的全部过程。在需求，设计和编码阶段对产生的工件进行复审，提出自己的建议和意见。对于前置软件测试法，bug在软件前期就可以发现从而降低软件开发成本。

　　不利用前置方法的bug曲线。

　　利用前置方法的bug曲线,bug在开始之前就能够被发现。

　　软件测试方法

　　白盒 黑盒 

　　动态 就是利用KDE的调试功能逐步调试程序，进行测试 就是普通所说的通过人工或者自动方法进行测试 

　　静态 即test review 就是对需求，设计工件进行审核 

　　软件测试步骤

　　² 测试计划

　　² 书写测试用例

　　² 开发测试代码

　　² 开展测试工作（往往需要进行几次轮测包括测试和复测，每次对于测试中的bug，要求开发人员给与明确答复修改完毕，非法bug以及下一版中解决）

　　² 评估测试

　　软件测试类型

　　1.数据和数据库完整性测试

　　在项目名称中，数据库和数据库进程应作为一个子系统来进行测试。在测试这些子系统时，不应将测试对象的用户界面用作数据的接口。对于数据库管理系统 (DBMS)，还需要进行深入的研究，以确定可以支持以下测试的工具和技术。

　　2.功能测试

　　对测试对象的功能测试应侧重于所有可直接追踪到用例或业务功能和业务规则的测试需求。这种测试的目标是核实数据的接受、处理和检索是否正确，以及业务规则的实施是否恰当。此类测试基于黑盒技术，该技术通过图形用户界面 (GUI) 与应用程序进行交互，并对交互的输出或结果进行分析，以此来核实应用程序及其内部进程。以下为各种应用程序列出了推荐使用的测试概要：

　　3.UI测试

　　用户界面 (UI) 测试用于核实用户与软件之间的交互。UI 测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。另外，UI测试还可确保UI 中的对象按照预期的方式运行，并符合公司或行业的标准。包括用户友好性，人性化测试。

　　4.性能测试

　　4.1负载测试：

　　负载测试是一种性能测试。 在这种测试中，将使测试对象承担不同的工作量，以评测和评估测试对象在不同工作量条件下的性能行为，以及持续正常运行的能力。负载测试的目标是确定并确保 系统在超出最大预期工作量的情况下仍能正常运行。此外，负载测试还要评估性能特征，例如，响应时间、事务处理速率和其他与时间相关的方面。

　　4.2强度测试

　　是一种性能测试，实施和执行此类测试的目的是找出因资源不足或资源争用而导致的错误。如果内存或磁盘空间不足，测试对象就可能会表现出一些在正常条件下并不明显的缺陷。而其他缺陷则可能由于争用共享资源（如数据库锁或网络带宽）而造成的。强度测试还可用于确定测试对象能够处理的最大工作量。

　　4.3容量测试

　　容量测试使测试对象处理大量的数据，以确定是否达到了将使软件发生故障的极限。容量测试还将确定测试对象在给定时间内能够持续处理的最大负载或工作量。例 如，如果测试对象正在为生成一份报表而处理一组数据库记录，那么容量测试就会使用一个大型的测试数据库，检验该软件是否正常运行并生成了正确的报表。

　　4.4基准测试

　　与已知系统的比较

　　4.5竞争测试

　　软件竞争使用各种资源（数据纪录，内存等）