软件测试流程2.docx
《软件测试流程2.docx》由会员分享，可在线阅读，更多相关《软件测试流程2.docx（19页珍藏版）》请在冰豆网上搜索。
软件测试流程2
软件测试流程
1.软件测试流程
1.1.软件测试整体流程
首先看一下软件生命周期。
软件开发全部过程、活动和任务的结构框架,是从可行性研究到需求分析,软件设计,编码,测试,软件发布维护的过程。
如下图所示:
在学习软件测试整体流程的过程中,我们要明确这样几个问题:
测试计划的前期是否需要需求调研?
测试具体分几个阶段,每个阶段执行的依据是什么?
每个阶段的作用是什么?
每个阶段都需要生成哪些文档,这些文档对整个测试工作和产品的质量保障起到哪些作用?
测试工作的各个阶段:
软件测试工作必须要通过计划测试、设计测试、执行测试、评估测试几个阶段来完成。
计划测试阶段需要整理测试需求、制定测试计划;
设计测试阶段要设计测试用例和测试过程,要保证测试用例完全覆盖测试需求;要根据测试用例实现具体的自动化脚本或者手工的操作步骤;
执行测试阶段则通过自动化测试工具或人手工来执行那些自动化脚本或手工的操作步骤;
评估阶段则要对软件的质量和测试工作自身的质量做出一个客观的评价。
软件测试的整体流程具体如下图所示:
需求阶段:
设计编码阶段:
集成、系统、验收阶段:
开发生命周期中的验证活动:
软件测试流程,集成、系统、验收如下图所示:
1.2.单元测试
目标:
检验程序最小单元有无错误（类、文件、窗口、函数、菜单、报表或一个存储过程）
◆接口、数据结构、边界、覆盖、逻辑
检验单元编码与设计十分吻合
依据:
详细设计,编码
方法:
白盒测试
测试执行人:
开发工程师
进入条件:
代码无错误地通过编译或汇编。
测试内容:
（1）模块接口:
对被测模块,信息是否能正确地流入和流出。
（2）局部数据结构:
模块的工作过程中,其内部的数据能否保持其完整性。
（3）边界条件-----在边界上模块是否能正常工作。
（4）覆盖条件------模块的运行是否达到了规定的逻辑覆盖。
（5）出错处理-----检查模块的错误处理设施是否有效。
具体要求:
（1）在进行单元测试之前,由项目负责人决定是否进行静态分析。
（2）单元测试的主要形式是结构测试。
（3）单元测试的测试计划应该根据被测单元的性质而制订:
如对系统控制单元应主要采用结构测试;对复杂的计算单元应主要采用算法分析测试用例;对界面单元就应该测试各种选项的组合。
（4）语句覆盖率应达到100%。
（5）分支覆盖率应达到85%。
（6）单元测试由开发部负责开展。
单元测试执行:
在进行单元测试时,需设置若干辅助测试模块。
辅助模块有两种:
一种是驱动模块（Driver）,用以模拟被测试模块的上级模块。
另一种是桩模块（Stub）,用以模拟被测模块工作过程中所调用的模块。
驱动模块和桩模块都是“替身”模块,而不是软件产品的真正组成的部分。
下图显示了一般的单元测试环境。
单元测试一般由开发设计人员本身完成。
一般由开发组在组长的监督下进行,由编写该单元的开发设计者设计所需的测试用例和测试数据,来测试该单元并修改缺陷。
开发组组长负责保证使用合适的测试技术,在合理的质量控制和监督下执行充分的测试。
1.3.集成测试
将经过单元测试的模块按设计要求组装起来,组合成所规定的软件系统的过程称为“集成”。
目标:
检验组成系统的模块接口有无错误
代码实现的系统设计与需求定义是否吻合
时机:
主要的单元测试完成后,经常与单元测试同步进行
方法:
黑盒测试,白盒测试
责任:
开发工程师、测试工程师
集成测试重点:
1、各个模块连接起来后,穿过模块接口的数据是否会丢失,是否能够按期望值传递给另外一个模块;
2、各个模块连接起来后,需要判断是否仍然存在单元测试时所没发现的资源竞争问题;
3、分别通过单元测试的子功能模块集成到一起能否实现所期望的父功能;
4、兼容性,检查引入一个模块后,是否对其他与之相关的模块产生负面影响;
5、全局数据结构是否正确,是否被不正常的修改;
6、集成后,每个模块的误差是否会累计扩大,是否会达到了不可接受的程度。
集成测试方式:
将模块连接起来组成一个可运行的系统,有两种方法;非渐增式测试和渐增式测试。
（1）非渐增式测试（Non-incrementaltesting）
当每个模块都进行单元测试后,按照软件结构要求把所有模块连接起来织成一个完整的程序,对全程序进行测试。
这种测试方法叫非渐增式测试。
例如,有一块系统结构,如图（a）所示,其单元测试和集成顺序如图（b）所示。
模块d1、d2、d3、d4、d5是对各个模块做单元测试时建立的驱动模块,s1、s2、s3、s4、s5是为单元测试而建立的桩模块。
这种一次性集成方式将所测模块连接起来进行测试,但是一次试运行成功地可能性并不大。
其结果如果存在错误,不易找到原因,查错和改错都会遇到困难。
（2）渐增式集成方式
逐次将未曾测试的模块和已测试的模块（或子系统）结合成程序包,然后将这些模块集成为较大系统,在集成的过程中边连接边测试,以发现连接过程中产生的问题。
最后逐步集成为要求的软件系统。
根据集成的过程又可以分为
自顶向下集成
自底向上集成
三明治”集成法
●自顶向下的集成方式
这种集成方式是将模块按系统的程序结构,沿控制层次自顶向下进行集成。
步骤:
（1）以主模块为所测模块兼驱动模块,所有直属于主模块的下属模块全部用桩模块进行模拟测试。
（2）采用深度优先或宽度优先的策略,用实际模块替换相应桩模块,再用桩代替它们的直接下属模块,与已测试的模块或子系统集成为新的子系统。
如下图
（3）进行回归测试（即重新执行以前做过的全部测试或部分测试）,排除集成过程中引起错误的可能。
（4）判断是否所有的模块都已集成到系统中,是则结束测试,否则转到
（2）去执行。
●自底向上的集成方式
这种集成的方式是从程序模块结构的最底层的模块开始集成和测试。
因为模块是自底向上进行集成,对于一个给定的模块,它的子模块（包括子模块的所有下属模块）已经集成并测试完成,所以不再需要桩模块。
自底向上集成的步骤如下:
（1）由驱动模块控制最底层模块的并行测试,也可以把最底层模块组合成实现某一特定软件功能的簇,由驱动模块控制它进行测试。
（2）用实际模块代替驱动模块,与它已测试的直属子模块集成为子系统。
（3）为子系统配备驱动模块,进行新的测试。
（4）判断是否已集成到达主模块,是否结束测试,否则执行
（2）。
下图说明自底向上集成和测试的顺序:
1.4.系统测试
目标:
检验组成整个系统的代码、以及系统的软硬件配合有无错误
代码实现的系统与用户需求是否吻合
检验系统的文档等各种是否完整、有效
模拟验收测试的要求,检查系统是否符合用户的验收标准
时机:
多数集成测试完成后
方法:
黑盒测试
责任:
测试工程师
1.5.验收测试
目标:
使客户验收签字
系统是否符合事先约定的验收标准
时机:
系统测试完成后,在项目组看来开发和测试工作已经全部完成,可以交付使用
方法:
黑盒测试
责任:
产品经理或其他高级经理
开发工程师
测试工程师
用户
1.6.α测试与β测试（beta测试）
α测试是由用户在开发环境下进行的测试,也可以是开发机构内部的用户在模拟实际操作环境下进行的测试。
α测试可以在软件编码结束时开始,或在模块（子系统）测试完成后开始,也可在确认测试过程中软件达到一定的稳定和可靠程度之后再开始。
α测试需要开发人员参与。
β测试是由软件用户在实际使用环境下进行的测试。
这些用户通常是与公司签定了一定合同的外部用户,用户在使用该产品时愿意返回有关错误信息给开发者。
β测试时,开发人员不在测试现场。
只有当α测试达到一定可靠程度时,才能开始β测试。
β测试通常由主持产品发行的人员来管理。
α测试和β测试区别
⏹α测试——尽量模拟用户的使用环境
β测试——真实用户的使用环境
⏹α测试——开发方测试
β测试——最终用户测试
问题:
Beta测试属于验收测试吗
答:
是!
✓所谓验收测试（acceptancetest）是在产品发布之前所进行的软件测试活动,它是技术测试的最后一个阶段,通过了验收测试,产品就会进入发布阶段.
✓α、β测试事实上,软件开发人员不可能完全预见用户实际使用程序的情况。
例如,用户可能错误的理解命令,或提供一些奇怪的数据组合,亦可能对设计者自认明了的输出
信息迷惑不解,等等。
因此,软件是否真正满足最终用户的要求,应由用户进行一系列
“验收测试”。
验收测试既可以是非正式的测试,也可以有计划、有系统的测试。
测试过程总结,如下图所示:
2.常用测试技术
首先看一下软件测试的分类:
●按测试阶段分类
✓单元测试、集成测试、系统测试、验收测试
●按测试策略分类
✓黑盒/白盒测试、动态/静态测试、手工/自动测试
●按测试技术方法分类
✓功能测试、性能测试、压力测试、易用性测试、安装测试、容错性测试、兼容性测试、安全性测试
●黑盒测试/白盒测试
---从要不要看代码来区分
●动态测试/静态测试
--从要不要运行软件来区分
而常用的测试技术如下图所示:
2.1.功能测试
功能测试:
✓使用测试应用系统的功能需求的黑盒测试方法。
✓这类测试应由测试员做,这并不意味着程序员在发布前不必检查他们的代码能否工作。
✓运行系统,查看其功能是否正常实现,是否满足需求。
对于需求没有涵盖,但功能实现上不合理的地方（从用户角度考虑）与项目经理沟通,进行系统完善。
功能测试参考:
✓参考《需求分析》、《规格说明书》、《测试计划》、《测试用例》等文档
✓多与开发人员、用户及其他项目相关人员沟通
功能测试的控件操作,如下图所示:
控件中文本框测试:
从输入数据的内容,长度,类型,格式等几个方面来考虑。
文本框如下图所示:
控件中按钮测试:
✓按钮功能是否实现
✓提示信息是否正确
✓对于不符合业务背景的输入数据是否有相应的处理
按钮如下图所示:
控件中单选框测试:
✓单选按钮是否同时只能选中一个
✓各单选按钮功能是否能正确完成
✓是否有默认被选中的选项
单选框如下图所示:
控件中updown+文本框测试:
✓上下箭头的控制
✓边界值的测试
✓默认值的测试
✓非法输入字符的测试
如下图所示:
控件中组合列表框测试:
✓条目内容的检查
✓条目功能的是否实现
✓列表框中是否能输入数据
控件中复选框测试:
✓多个复选框可以同时选中。
✓多个复选框可以被部分选中。
✓多个复选框可以都不被选中。
例如,即不选轮廓,也不选阴影字体
✓逐一执行每个复选框的功能。
✓每个复选框都可能有三种状态:
选中、未选中和部分选中。
控件中列表框测试:
✓条目内容正确。
✓逐一执行列表框中每个条目的功能。
✓列表框内容多要使用滚动条。
✓列表框允许多选时,要分别检查按Shift选中条目、按Ctrl选中条目和直接用鼠标选中多项条目。
列表框如下图所示:
控件中滚动条测试:
✓滚动条是否能拖动
✓滚动条拖动时屏幕刷新情况
✓滚动条拖动时显示信息的显示
✓滚动条的上下按钮是否可用如下图所示:
控件组合操作:
即各种控件的组合使用:
✓控件间的相互作用
✓Tab键的顺序
✓热键的使用
✓回车键和ESC键的使用
✓控件组合后功能的实现
如下图所示:
对登录操作测试
如下图所示:
✓输入正确的用户名和密码,点“确定”,用户可以正确登录
✓输入不正确的用户名,正确的密码,点“确定”。
系统提示错误。
✓输入正确的用户名,不正确的密码,点“确定”。
系统提示错误。
✓输入不正确的用户名,不正确的密码,点“确定”。
系统提示错误。
✓输入三次错误的登录信息,自动退出。
✓输入允许的最大长度为20个字符的用户名和最大长度为20个字符的密码,可以正确登录
✓输入超过允许的最大长度的用户名和最大长度的密码。
系统提示错误。
✓进入登录界面,接受默认值,什么都不输入,直接按确定
✓输入特殊字符。
例如,输入正确用户名,按Backspace或Delete键删除用户名,再次输入用户名;或者输入ASCII表中的不可显示的字符如NUL,LF等。
✓点“取消”,退出程序。
✓入正确的用户名或密码,点“取消”退出程序后,再次进入登录界面直接按确定。
检查程序的默认值是否改变
✓密码显示为*,不能显示为输入的具体字母或数字
✓Tab键的顺序为用户、密码、确定、取消
文件操作打开文件测试:
✓打开在任意位置的文件
✓以各种方式打开文件
✓打开任意格式的文件
✓打开文件对话框中的各按钮
如下图所示:
文件操作保存文件测试:
✓在任意位置保存文件
✓以各种方式保存文件
✓保存任意格式的文件
✓保存文件对话框中的各按钮
如下图所示:
文件操作保存文件测试:
✓正常关闭文件,系统提供确认信息。
✓通过菜单或窗口按钮关闭。
✓非正常关闭。
文件操作打印文件测试:
✓本地打印和网络打印是否能完成
✓打印界面的各属性的设置
✓打印界面的各按钮功能是否能实现如下图所示:
编辑操作测试:
✓查找、搜寻中考虑输入的内容和长度
✓替换中考虑输入的内容和长度
✓编辑操作窗体的功能测试
如下图所示:
插入操作测试:
复制操作测试:
鼠标测试:
如何进行测试:
✓左右键操作是否能完成
✓单击、双击、三击是否能完成
✓拖放、滚轮等功能是否能完成
✓移动、点击的速度
如下图所示:
2.2.界面测试
窗体需要测试:
✓窗体大小
✓移动窗体
✓缩放窗体
✓显示分辨率
✓状态栏
✓工具栏
✓错误信息
✓父窗口
✓子窗口
如下图所示:
控件界面测试案例:
控件界面测试检查列表:
菜单界面测试:
菜单界面测试检查清单,如下图所示:
特殊属性检查清单,如下图所示:
界面设计总体原则:
✓界面的长宽比例
✓按钮的大小
✓背景的搭配
✓颜色的搭配
测试技术小结:
●测试用例设计的目的是导出可能发现错误的测试集
●测试case设计的技术主要是白盒和黑盒
●白盒测试注重程序的结构,是小规模的低层测试
●黑盒测试注重需求的实现,是大规模的高层测试
●还有大量的特定软件系统的测试方法,需要专门的测试技术和指南
●测试永无止境,设计测试case最终目的是为了尽量多的发现问题,在产品发布前解决文档测试技术小结:
文档测试审查单:
术语:
用户是否理解;是否需要定义;是否标准、前后一致
标题:
是否合适,是否和实际产品一致
内容:
功能描述正确、清晰
逐步执行:
确保所有信息真实正确和实际产品功能一致;检查搜索的正确性;检查网站URL能否正确链接
图表和拷屏:
图表准确;拷屏版本一致;图表标题正确
示例:
对文档中示例要载入并使用,保证其可以正确执行
错别字:
无错别字,标点符号正确
排版:
排版正确,风格一致
设计易用性测试用例:
实例分析:
优秀界面的特点:
●符合标准和规范●直观性
●一致性
●灵活性
●舒适性
●正确性
●实用性
3.软件测试策略
我们无法为软件做穷举测试,存在着组合爆炸的情况。
软件测试中的“杀虫剂”现象。
我们无法修复所有发现的错误。
黑盒测试
●黑盒测试是对需求的所有输入条件进行测试
●黑盒测试发现的错误类型
✓功能不对或遗漏
✓界面错误
✓数据结构或外部数据库访问错误
✓性能错误
✓初始化和终止错误
黑盒测试关注点:
●功能:
✓如何测试功能的有效性
✓何种类型的输入会产生好的测试用例
✓系统是否对特定的输入值敏感
●数值:
✓如何分隔数据类的边界
✓系统能够承受何种数据率和数据量
✓特定类型的数据组合会对系统产生何种影响
●界面
●性能
●其他
白盒测试:
●白盒测试发现的错误类型:
✓语法错误
✓编译错误
✓Memoryleak
✓Performanceproblem
✓逻辑问题
✓判定条件问题
✓编程规范
●测试技术
✓基本路径
✓控制结构
基本路径测试,如下图所示:
优缺点比较,如下图所示:
静态测试与动态测试:
静态测试（Statictesting）:
不实际运行被测试的程序
✓测试对象:
•软件文档（用户类,开发类）
•源代码（逻辑错误,代码标准/规范/风格）
✓分类:
•代码走查（walkthrough）
•代码审查（Inspection）
•技术评审（Review）
动态测试（DynamicTesting）:
通过执行软件的手段来测试软件
静态测试技术:
代码走查（walkthrough）
✓开发组内部进行的,采用讲解、讨论和模拟运行的方式进行的查找错误的活动代码审查（Inspection）
✓开发组内部进行的,采用讲解、提问并使用Checklist方式进行的查找错误的活动。
一般有正式的计划、流程和结果报告
技术评审（Review）
✓开发组、测试组和相关人员（QA、产品经理等）联合进行的,采用讲解、提问并使用Checklist方式进行的查找错误的活动。
一般有正式的计划、流程和结果报告
黑盒测试与白盒测试:
白盒测试（WhiteBoxTesting）
✓又称结构测试,逻辑驱动测试或基于程序的测试
✓深入到代码一级的测试,使用这种技术发现问题最早,效果也是最好的。
但效率很低。
✓这一阶段测试以软件开发人员为主,在JAVA平台使用Xunit系列工具进行测试,Xunit测试工具是类一级的测试工具对每一个类和该类的方法进行测试。
黑盒测试（BlackBoxTesting）
✓又称功能测试,数据驱动测试或基于规格说明书的测试
✓黑盒测试主要还是功能部分。
主要是覆盖全部的功能,结合兼容、性能测试等方面进行,根据软件需求、设计文档,模拟客户场景随系统进行的测试。
手工测试与自动测试:
手工测试和自动测试
✓手工测试:
测试人员手动执行软件进行测试
✓自动测试:
利用测试工具和测试脚本来进行测试
自动化测试与手工测试的关系
✓自动化测试是对手工测试的一种补充
✓自动化测试不可能完全代替手工测试
✓手工测试和自动化测试一个都不能少,关键是在合适的地方使用合适的测试手段
✓自动化测试是软件测试发展的一个趋势
自动测试的优势:
●自动化测试对程序的回归测试更方便。
可以极大提高测试效率,缩短回归测试时间。
●可以运行更多更繁琐的测试。
自动化的一个明显的好处是可以在较少的时间内运行更多的测试。
●可以执行一些手工测试困难或不可能进行的测试。
●更好地利用资源。
将繁琐的任务自动化。
●可以提高准确性和测试人员的积极性,将测试技术人员解脱出来投入更多精力设计更好的测试用
例。
将可自动测试的测试自动化后,可以让测试人员专注于手工测试部分,提高手工测试的效率。
●测试具有一致性和可重复性。
●测试的复用性。
●增加软件信任度。
自动测试的缺陷:
✓手工测试比自动测试发现的缺陷更多（85%:
15%）
✓工具本身不具有想象力
✓不能处理意外事件:
如网络中断
✓前期的购置工具、培训成本较高
✓不能取代手工测试;
✓测试自动化不能提高有效性
测试自动化可能会制约软件开发。
由于自动测试比手动测试更脆弱,所以维护会受到限制,从而制约软件的开发.
测试分类如下图所示:
如下图所示:
升级会员 