网站建设比较好的多少钱,自助网站,网页以新窗口方式打开怎么做,一个网站要怎么做的一、单元测试的概念
单元测试#xff08;Unit Testing#xff09;是对软件基本组成单元进行的测试#xff0c;如函数#xff08;function或procedure#xff09;或一个类的方法#xff08;method#xff09;。当然这里的基本单元不仅仅指的是一个函数或者方法#xff…一、单元测试的概念
单元测试Unit Testing是对软件基本组成单元进行的测试如函数function或procedure或一个类的方法method。当然这里的基本单元不仅仅指的是一个函数或者方法有可能对应多个程序文件中的一组函数。
单元也具有一些基本的属性。比如明确的功能、规格定义明确的与其他部分的接口定义等可清晰地与同一程序的其他单元化分开来。 二、单元测试的目的
单元测试的目的在于发现各模块内部可能存在的各种错误主要是基于白盒测试。也就是说在单元测试过程中用的最多的是白盒测试方法也可能会有灰盒或者黑盒。单元测试和白盒测试是不同的划分不存在包含关系。
在单元测试阶段对应的文档是详细设计文档LLD对应的代码就是单元代码因此单元测试的目的主要有3点
1、验证代码是与设计相符合的
2、发现设计和需求中存在的错误
3、发现在编码过程中引入的错误。 三、单元的常见错误
单元的常见错误一般出现在以下五个方面因此这五个方面是单元测试应该关注的重点。
1、单元接口。
2、局部数据结构。
3、独立路径。
4、出错处理。
5、边界条件。 四、如何进行单元测试
在单元测试时由于单元本身不是一个独立的程序一个完整的可运行的软件系统并没有构成所以需要设置一些辅助测试单元辅助测试单元有两种一种是驱动单元另外一种是桩单元。
1、驱动单元Driver:用来模拟被测单元的上层单元相当于被测函数的主函数如main函数。所以驱动单元主要完成以下4个步骤
1接受测试数据包含测试用例输入和预期输出
2把测试用例输入传送给被测单元驱动被测单元测试
3将被测单元的实际输出和预期输出进行比较得到测试结果
4将测试结果输出到指定位置。
2、桩单元Stub用来代替被测单元工作过程中调用的子单元。
桩单元模拟的单元可能是自定义函数这些自定义函数可能尚未编写完成为了测试被测单元需要构造桩单元来代替它们可能存在错误会影响测试结果所以需要构造正确无误的桩单元来达到隔离的目的。
驱动单元和桩单元都是额外的开销虽然在单元测试的时候必须写但是并不需要作为最终的产品提供给客户。 五、单元测试策略
一般的单元执行策略有三种孤立的单元测试策略Isolation Unit Testing自顶向下的单元测试策略Top Down Unit Testing和自底向上的单元测试策略Bottom Up Unit Testing。需要注意的是在集成测试中也有自顶向下和自底向上的测试策略但是测试对象不同。
1、孤立的单元测试策略Isolation Unit Testing
方法不考虑每个模块与其它模块之间的关系为每个模块设计桩模块和驱动模块每个模块进行独立的单元测试。 优点这个方法比较简单最容易操作可以达到很高的结构覆盖率可以并行开展该方法是纯粹的单元测试。 缺点桩函数和驱动函数工作量很大效率低。
2、自顶向下的单元测试策略Top Down Unit Testing
方法先对最顶层的单元进行测试把顶层所调用的单元做成桩模块其次对第二层进行测试使用上面已经测试过的单元做驱动模块以此类推直到测试完所有模块。 优点可以节省驱动函数的开发工作效率高。 缺点随着被测单元一个一个被加入测试过程将变得越来越复杂并且开发和维护的成本将增加。
3、自底向上的单元测试策略Bottom Up Unit Testing
方法先对最底层的模块进行单元测试将模拟调用该模块的模块设置为驱动模块然后再对上面一层做单元测试用下面已经测试好的模块做桩模块以此类推直到测试完所有模块。 优点可以节省桩函数的开发工作量测试效率较高。 缺点不是纯粹的单元测试底层函数的测试质量对上层函数的测试将产生很大影响。 六、系统测试的概念
系统测试System Testing的定义将已经集成好的软件系统作为整个基于计算机系统的一个元素与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结合在一起在实际运行使用的环境下对计算机系统进行一系列的组装测试和确认测试。
系统测试的对象软硬件集合在一起的系统集成后的产品不应是独立的软件与硬件环境。不仅仅包括需测试的软件还要包含软件所依赖的硬件、外设甚至包括某些数据、某些支持软件的系统等。
目的通过与系统的需求定义做比较发现软件与系统定义不符合或与之矛盾的地方以验证软件的功能和性能等满足其规约所指定的要求。
常见的系统分类
纯软件QQ.................
软件和硬件手机PSP空调电梯
软件硬件和维护人员大型系统 七、系统测试的环境
真实环境直接将整个系统和其交联的物理设备真实的建立链接进行测试
优点可以发现某些只能在真实环境下出现的问题
缺点构建这样一个环境需要高昂的费用它的测试运行也需要高昂的费用
仿真环境它能够逼真的模拟被测试软件运行所需的真实物理环境的输入与输出并且能够组织被测软件的输入来驱动被测软件运行同时接收被测软件的输出结果。
优点仿真环境和真实环境的软件依赖是一样的并且它能够保证测试的可重复性、完整性、可扩展性
Example 1某系统环境搭建的要求
硬件环境
CPU主频2GHZ以上4核及以上
内存4GB及以上
硬盘可用空间10G以上
软件环境
平台要求Windows XP/2003标准版Apache2.2.XMysql5.0及以上版本
目录权限目录/Attachment/Cache及文件需要写的权限
推荐平台推荐使用XAMPP作为安装介质
选用测试工具应考虑的因素
1.测试工具与被测软件系统的匹配程度
2.测试工具提供的主要功能和辅助机制
3.测试工具的服务和技术支持
4.测试工具的价格
测试数据
特点
1.数据可以以消息、事物、记录、文件等形式存在
2.数据来源很多
3.真实数据最好但在很多情况下不易或者不能得到
来源
1.产品数据
2.手工构造数据
3.生成数据一般由工具设备构造
4.捕获数据少用与捕获数据源有关允许手工修改
5.随机数据系统测试少用它易于获得不够真实性能测试常用
产品数据
1.最具真实性
2.不能覆盖所需所有场景
3.数据敏感很难保证正确性
4.随时间变化
5.可能数据量太大从而降低测试执行速度
手工构造数据
1.费时间、枯燥
2.如果对系统的功能缺乏了解数据不真实
3.有时是获得特定测试用例所需独特数据的唯一手段
生成数据
1.一般由工具或设备构造
2.数据取决于工具的完善程度和测试人员的关于如何构造数据的规格说明
捕获数据
1.与捕获数据源无关
2.允许手工修改
随机数据
1.易于获得不够真实
2.对强度或负载测试是非常有用的 八、系统测试的类型
常见的测试类型
功能测试配置测试、恢复性测试、备份测试
性能测试压力测试、稳定性测试、容量测试
GUI测试可用性测试
兼容性测试
安全性测试网络测试
安装性测试
文档测试
功能测试
概念根据SRS和 需求列表验证产品的功能实现是否符合产品的需求规格
目标:
1.是否有不正确或者遗漏了的功能做错或少做
2.功能实现是否满足用户需求和系统设计的隐藏需求
3.能否正确的接受输入能否正确的输出结果
功能测试步骤
1.对每个明确的功能需求进行标号
2.对每个隐含的功能需求进行标号
3.对可能出现的功能异常进行分类分析并且标号
4.把功能划分为关键功能和非关键功能
5.对每个功能进行测试分析分析其是否可测如何测试可能的输入、输出
6.脚本化和自动化
性能测试
概念用来测试软件在集成系统中的运行性能
目标: 度量系统各项指标确认系统有无各种性能瓶颈
特点混合白盒测试和黑盒测试的方法
性能测试考虑的两个方面:
1.验证系统实现的性能是否与性能需求完全一致
2.检测系统实现的具体性能到底怎样
常用方法探针测试驱动
常用工具Loadrunner,WebLoad,SilkPerformer
GUI测试
概念针对软件系统界面进行的测试
目标1.测试界面实现与界面设计的吻合情况 2.确认界面处理的正确性
关注点界面层与功能接口层上GUI系统分为三个层次界面层、界面与功能的接口层、功能层
常用工具QTPQARun
兼容性测试
概念考虑被测试软件在其他软件例如操作系统或硬件设备下的运行情况。
目标1.与辅助软件的结合情况操作系统其他应用程序测试软件监控软件浏览器等 2.与硬件设计的结合情况由于兼容性测试对硬件要求较多一般无特殊要求都只会针对软件要求做测试。
安全性测试
概念验证集成在系统内的保护机制是否能够在实际中保护系统不受非法的侵入用来保护数据本身的完整性和保密性。广义的还包括物理安全和业务安全。
范围主要从几个方面考虑系统登录用户管理防火墙系统数据WEB安全数据库安全内部通讯系统防毒测试等。
保护测试是安全测试中的一种常见的测试主要用于测试系统的信息保护机制
安装性测试
概念主要依据软件的测试特征列表、软件安装、配置文档、设计安装过程的测试用例发现软件在安装过程中的错误。
目标找出软件安装的错误安装手册的错误。
安装测试前所要做的检查工作
1.安装文档是否齐全
2.安装软件的程序文件是否齐全
3.被测试的安装文件是否齐全
4.软件的文件格式是否与安装指导中的要求的文件格式相符
常用自动化安装测试软件Total Uninstall:它能够监视软件安装的所有过程记录下它对系统所做的任何改变FileRiver:可以自动监视和准确记录下多个文件夹中的文件以及子文件的细微变化。
文档测试
概念主要针对软件需求说明书安装手册配置指南等文档测试内容主要是编写规范内容正确性无歧义性完整性。
目标验证用户文档是正确的并且保证操作手册的过程能够正确工作。 九、系统测试的过程
测试阶段的划分
系统测试计划阶段完成系统测试计划规划和步骤
系统测试设计阶段完成系统测试方案
系统测试实现阶段完成系统测试用例系统测试规程系统测试预测试冒烟测试项
系统测试执行阶段执行系统测试预测试系统测试用例开展回归测试校验已修复的问题提交系统预测试报告系统测试报告缺陷报告
过程软件需求分析、设计概要、系统测试执行 系统测试中的角色及职责
开发代表解决资源需求对系统测试结果进行监督
QA系统测试过程质量保证参与相关评审对过程进行审计
配置管理组对系统测试文档及测试代码等相关配置进行配置管理
软件开发组
1.系统测试计划阶段提供软件开发计划SDP参与系统测试计划的评审
2.系统测试设计和实现阶段提供SRS需求分析测试建议响应系统测试需求参与软件系统测试方案的评审
3.系统测试执行阶段跟踪解决软件测试项目组的缺陷问题报告单参与系统测试报告的评审
软件测试组
1.系统测试计划阶段制定系统测试计划并组织评审
2.系统测试设计和实现阶段制定软件测试方案并组织评审按照软件系统测试方案实现测试用例测试代码和测试工具等设计编写测试规程
3.系统测试执行阶段执行系统测试反馈并跟踪缺陷问题报告单完成系统测试报告并组织评审输出测试案例、总结等经验文档
系统分析组
1.提出系统测试需求
2.进行测试需求跟踪
3.进行软件系统可测性分析确定系统测试的对象、范围和方法
系统测试计划的要点
1.明确系统测试的被测对象
2.完成系统测试的需求跟踪
3.明确系统的通过或失败标准
4.系统测试的挂起标准及恢复的必要条件
5.明确系统测试工作任务分配
6.系统测试结束后应交付的工作产品
系统测试设计的要点
1.测试环境和测试数据的准备
2.测试工具的开发/场景设计
3.系统测试用例设计
4.测试策略的选择如测试几轮
系统测试方案和系统测试计划的区别
系统测试计划对系统测试全过程的组织、资源、原则等进行规定和约束并制定系统测试全过程各个阶段的任务以及时间进度安排并提出对各项任务的评估、风险分析和管理需求。
系统测试方案描述系统需要测试的特性测试的方法测试环境的规划测试工具的设计和选择测试用例的设计方法测试代码的设计方案。设计测试方法的细节文档
注案需要在系统测试计划的指导下进行系统测试计划提出做什么而系统测试方案明确提出“如何做”
系统测试执行概述
1.按一定的系统测试计划依据系统测试用例完成测试的各项操作任务
2.根据系统测试方案搭建系统测试环境是系统测试执行的一个重要步骤测试环境时候与否会严重影响测试结果的真实性和正确性
3.系统测试执行阶段应完成环境准备、测试操作、测试记录、测试报告
4.执行的时间安排在集成测试执行完成之后进行系统测试的执行
系统测试预测试
目的验证软件系统基本功能或预测主要的系统功能以确保其后的系统测试执行能够顺利进行。
时间安排系统预测试应在开发项目组提出软件版本转系统测试申请后进行主要是完成转系统测试评审需要输入的《软件系统与测试报告》。
人员安排执行验证软件基本功能活动的主体可以是软件开发项目组也可以是软件测试项目组或联合的组织。
转系统测试评审
1.评审责任的主体为软件项目测试组需要完成软件转系统测试评审表
2.软件版本转系统测试通过后才能启动执行系统测试过程
3.启动执行系统测试过程后系统预测试相关的软件版本测试代码文档环境等均应在配置管理中基线化
系统测试报告写作和评审
1.依据系统测试计划的测试通过准责结束系统测试后撰写系统测试报告
2.系统测试报告需要通过评审责任人为软件测试项目组由软件开发项目组配置管理小组和QA参与
3.评审不通过系统测试报告退回。在评审不符合项和问题解决后再提交评审申请或重新启动系统测试过程
4.评审通过后系统测试相关文档、代码、工具等均需跟随软件代码开发文档一起完成配置基线化系统测试过程结束
系统测试日报的写作目的
1.测试人员总结每天的测试工作便于了解自己的测试进度和测试情况用以调整下一天的工作计划
2.测试人员对被测对象每天给出评估结果用以调整后续工作的测试策略
3.测试人员向测试经理反映测试中的困难保证测试的顺利进行
4.测试经理通过测试日报了解每个工作人员的测试进度把握测试的整体进度发现进度上的风险及时调整计划
5.测试经理通过测试日报了解各模块缺陷发展的趋势判断测试是否可以退出
6.开发经理可以通过软件测试日报了解当前软件的质量情况并可以调整缺陷修改的人力资源、
7.如果软件有多个测试组并行测试测试日报可以提供彼此测试交流的手段
系统测试步骤
需求分析 - 计划、方案 - 用例设计 - 环境搭建 - 执行 - 测试报告
需求分类 1. 项目需求用户自己提需求 2产品需求产品人员进行调查撰写
基线第一种说法软件版本相对稳定 第二种说法文档经过多次评审修改之后封存起来任何人需求修改都要提出申请。 十、集成测试概念
1.集成测试也叫组装测试、联合测试、子系统测试或部件测试。
2.集成测试是在单元测试的基础上将所有模块按照概要设计要求如根据结构图组装成为子系统或系统进行集成测试。 十一、集成测试的目的
1.找出模块接口以及整体体系结构上的问题 2.确保各组件组合在一起后能够按照既定意图协作运行并确保增量的行为正确 3.集成测试属于灰盒测试 1)验证接口是否与设计相符合 2)发现设计和需求中存在的错误。 十二、集成测试关注的重点
一些模块虽可以单独正常工作但不能保证连接起来也能正常工作程序在某些局部反映不出来的问题在全局上就很有可能暴露出来影响功能的实现。
因此集成测试应当考虑一下两个问题
1.模块间的接口需要考虑的有两点
1)在把各个模块连接起来的时候穿越模块接口的数据是否会丢失 2)全局数据结构是否有问题会不会被异常修改。
2.集成后的功能需要考虑三点
1)各个子功能组合起来能否达到预期要求的父功能 2)一个模块的功能是否会对另一个模块的功能产生不利的影响 3)单个模块的误差积累起来是否会放大从而达到不可接受的程度。 十三、集成测试的层次
一个产品的开发过程包括了一个分层的设计和逐步细化的过程从最初的产品到最小的单元可以划分为产品——子系统——硬件子系统、软件子系统——软件模块——软件程序——单元。
一般单元测试针对最小的单元结构系统测试对应于产品级而当中的所有各层测试都需要通过集成测试来完成由于集成的力度不同因此将集成测试划分为3个级别
1.模块内集成测试单元测试完成后 2.子系统内集成测试即模块间集成测试 3.子系统间集成测试 十四、集成测试策略
集成测试策略是在测试对象分析的基础上描述软件模块集成组装的方式、方法分类如下
1.大爆炸集成Big Bang Integration
是属于非增值式集成Non-Incremental Integration的一种方法也叫一次性组装或整体拼装。该集成把所有系统组件一次性集合到被测系统中不考虑组件之间的相互依赖性或者可能存在的风险。应用一个系统范围内的测试包来证明系统最低限度的可操作性。 1)方法(策略)
a.在这种集成方式中首先对每个模块分别进行单元测试
b.然后再把所有单元组装在一起进行测试
c.最后得到要求的软件系统 2)目的
在最短时间内把系统组装出来并且通过最少的测试来验证整个系统 3)优点
a.在有利的情况下大爆炸集成可以迅速完成集成测试并且只要极少数的驱动和桩模块设计如果需要的话;
b.它需要的测试用例也是很少的;
c.该方法比较简单
d.多个测试人员可以并行工作对人力物力资源利用率较高。 4)缺点
a.这种一次性组装方式试图在辅助模块的协助下在模块单元测试的基础上将所测模块连接起来进行测试但是由于程序中不可避免地存在模块间接口、全局数据结构等方面的问题所以一次试运行成功的可能性并不很大;
b.在发现错误的时候其问题定位和修改都比较困难;
c.即使被测系统能够被一次性集成但还是会有很多接口错误很容易的躲过测试而进入到系统范围测试内。 5)适用范围
a.维护型项目或功能增强型项目其以前的产品已经很稳定并且新增的项目只有少数几个组件被增加和修改
b.被测系统比较小并且它的每个组件都经过了充分的单元测试
c.产品使用了严格的净室软件工程过程并且每个开发阶段的质量和单元测试质量都非常高。 2.自顶向下的集成策略Top-Down Integration
采用了和设计一样的顺序对系统进行测试在第一时间内对系统的控制接口进行了验证。 1)方法策略
a. 以主模块为所测模块兼驱动模块所有直属于主模块的下属模块全部用桩模块替换对主模块进行测试
b.采用深度优先Depth-First或者宽度优先Breath-First的策略用实际模块替换相应桩模块再用桩替代它们的直接下属模块与已测试的模块或子系统组装成新的子系统
c.进行回归测试排除组装过程中引起的错误的可能
d.判断所有的模块是否都已组装到系统中?如果是则结束测试否则转到b步骤去执行。 2目的
从顶层控制开始采用同设计顺序一样的思路对被测系统进行测试以验证系统的接口稳定性。 3优点
a.自顶向下的增殖方式在测试过程中较早的验证了主要的控制和判断点;
b.功能可行性较早得到证实还能够给开发者和用户带来成功的信心;
c.最多只需要一个驱动模块减少了驱动器开发的费用
d.由于和设计顺序的一致性可以和设计并行进行如果目标环境可能存在改变该方法可以灵活的适应
e.支持故障隔离。 4缺点
a.桩的开发和维护是本策略的最大成本随着桩数目增加成本急剧上升;
b.底层组件中一个无法预计的需求可能会导致许多顶层组件的修改这破坏了部分先前构造的测试包;
c.底层组件行为的验证被推迟
d.随着底层模块的不断增加整个系统越来越复杂。 5适用范围
适用于大部分采用结构化编程方法的软件产品且产品的结构相对比较简单对于具有以下属性的产品可以优先考虑该策略
a.产品控制结构比较清晰和稳定
b.产品的高层接口变化比较小
c.产品底层接口未定义或经常可能被修改
d.产品控制模块具有较大的技术风险需要尽早被验证
e.希望尽早可以看到产品的系统功能行为
f.在极端编程Extreme Program中使用探索式开发风格时其集成策略可以采用自顶向下。
3.自底向上的集成策略Bottom-Up Integration
是从程序模块结构的最底层的模块开始组装和测试因为模块是自底向上进行组装对于一个给定层次的模块它的子模块包括子模块下属所有模块已经组装并测试完成所有不在需要桩模块。在模块的测试过程中需要从子模块得到的信息可以通过直接运行子模块得到。
4.三明治集成Sandwich Integration
也称为混合式集成集合了自顶向下和自底向上两种策略的优点它将系统划分为3层中间一层为目标层测试的时候对目标层上面的一层使用自顶向下的集成策略对目标层下面的一层使用自底向上的集成策略最后测试在目标层会合。
5.基干集成Backbone Integration
在很多系统中尤其是嵌入式系统一般划分为两个部分内和部分基干部分和外围应用部分这两部分经常被不同的项目组并行开发该策略首先要识别应用的控制组件部分基干部分和应用子系统部分然后进行测试。
结合自顶向下自底向上和大爆炸集成的元素验证紧密耦合的子系统之间的互操作性。
6.分层集成Layers Integration
分层集成是针对分层模型使用的一种策略。
通过增量式集成的方法验证一个具有层次体系结构的应用系统的稳定性和可互操作性。
7.基于功能的集成Function-Based Integration
是从功能角度出发按照功能的关键程度对模块的集成顺序进行组织。
采用增值的方法尽早的验证系统关键功能。
8.基于进度的集成Schedule-Based Integration
考虑了项目的进度压力兼顾进度和质量在两者之间寻找均衡点进行测试该集成的最基本策略是把最早可获得的代码拿来立即进行集成必要的时候开发桩模块和驱动模块在最大程度上保持与开发的并行性从而缩短了项目集成的时间。
9.基于风险的集成Risk-Based Integration
是基于假设系统风险最高的模块间的集成往往是错误集中的地方因此尽早的验证这些接口有助于加速系统的稳定。所以该集成需在第一时间内验证高危模块间的接口保证系统的稳定性。
10.基于事件消息的集成Event/Message-Based Integration
针对基于状态机的系统工作原理是基于状态变迁内部模块间的接口主要通过消息来完成因此该集成是从验证消息路径的正确性角度出发渐增式的把系统集成到一起从而验证系统的稳定性。
11.基于使用的集成Use-Based Integration
针对面向对象的系统从分析类之间的依赖关系出发通过从最小依赖关系的类开始集成逐步扩大最后集成到整个系统通过该集成方法可以验证类之间接口的正确性。
12.分布式集成Distributed Services Integration
针对可以有许多并发运行、没有专门控制轨迹的组件、以及没有专门服务器层的分布式系统。
验证松散耦合的同级组件之间交互的稳定性。
13.客户/服务器的集成Client/Server Integration
对于和单独的服务器组件进行松散耦合的客户端组件可以使用客户/服务器集成来完成。
验证客户和服务器之间交互的稳定性。
14.高频集成High-frequency Integration
快速迭代式开发和增量式开发可能会导致系统功能的遗漏和冲突该集成主要是为了避免以上问题同时控制可能出现的基线偏差。
