可测试性需求Word格式.docx
- 文档编号:19970437
- 上传时间:2023-01-13
- 格式:DOCX
- 页数:30
- 大小:45.12KB
可测试性需求Word格式.docx
《可测试性需求Word格式.docx》由会员分享,可在线阅读,更多相关《可测试性需求Word格式.docx(30页珍藏版)》请在冰豆网上搜索。
对于复杂的业务流程需合理设定分解点,在测试时能够对其进行分解。
2)场景的可测性设计需求
对于复杂的场景需合理设定分解点,在测试时能够对其进行分解。
3、稳定性设计需求
测试模块发布合理,不能在后期追加的模块为前期所测模块引入新的不必要的测试活动。
4、易理解性设计需求
1)设计文档的易理解性
设计参考标准
容描述主次要分清
依赖关系描述明确
2)接口的易理解性
接口功能明确
参数有意义
3)业务的易理解性
4)场景的易理解性
5、可观察性设计需求
1)业务执行状态和过程可观察性设计需求
2)异常情况可观察性设计需求
6、测试驱动和桩的设置
为单个测试接口、测试业务、测试场景预留测试驱动和桩的接入点。
7、适合增量式开发的可测性设计
在增量式开发过程中必须优先考虑测试桩和测试驱动实现的难易程度和真实性。
8、可查询设计
对系统级别的全局变量或者状态设置查询接口;
某一业务或场景调用接口设置接口路径查询。
9、自愈合功能
在某一场景中局部出现故障时设置多路选择或者其他干涉进行跳转执行使其具有正常逻辑功能。
10、输出结果
对于任何一项操作都要能产生预期的输出,不管是正确的还是错误的甚至是异常的。
测试结果的表现形式可以是数据、现象等,不管是以什么方式表现,都要有依可寻,在设计文档中要有说明。
对于测试结果易于判断,具有可分析性、可获得性。
在设置的各个控制点或观察点的结果易于查询、修改等。
11、提供统一的操作执行面板
操作面板元素主要由输入和输出元素组成,如所执行的操作和对应的输出,但由于被测系统可能是一个比较复杂的系统,由多个可以独立的模块组成,涉及到的操作和输出比较多,各操作之间的关联也比较复杂。
在设计时统一的做一个操作面板,该操作面板成为一个可以执行整个被测系统操作的独立模块,一种是以命令的形式执行操作,直接以printf语句的形式输出查看,另一种是以GUI的形式,输入(执行的操作)输出均在界面上执行和体现,这样比较直观。
特别对于执行某一场景时要跟踪该场景的关键过程和执行后的输出参数,给出一系列可以分析的数据,该场景可以以执行过程分阶段监控,将监控围的数据输出以供测试人员分析。
[讨论]需求的可测试性
需求需求
敏捷模式中强调UserStory的可测试性。
我觉得在传统模式中,强调需求的可测试性也有非常大的好处。
1.用户需求以文字性描述居多,如果需求有测试通过标准,那么开发和测试人员都可以有一个容易遵循的规则。
2.需求有通过标准,说明开发测试以及需求分析人员都达成了共识,减少工作中的分歧。
3.既然要研究测试通过标准,那么自然就要求QA从需求分析阶段就开始工作。
我想这是所有QA都期盼的结果。
4.如果团队无法设计出需求的通过标准,那可能是需求不够明确或者团队缺乏相关的知识。
总之,大家可以在开发前就可以知道这个需求多半是无法完整实现的。
应该还有其他的好处,大家可以来讨论一下。
软件可测试性设计
发布时间:
2009-8-0617:
27作者:
Vince来源:
文斯测试技术研究中心
字体:
小中大|上一篇下一篇|打印|我要投稿|推荐标签:
软件测试技术
一、概述
随着软件行业的迅猛发展,软件测试也逐渐受到越来越多的软件公司所重视,然而开发出来的软件直接就可以拿出来做测试吗?
根据近几年来的实践证明,在设计软件时事先没有对软件的可测试性进行周密设计和部署的软件在测试时总是很难于进行,直到测试无法进行下去为止。
被测软件在编码时需要考虑给测试和后期的产品维护提供必要的手段和接口支持,即要求软件具有可测试性。
基于可测试性的目标考虑,良好的架构设计,完备的接口,使得软件测试更加高效和可行,同时产品维护也更加便利。
本文描述的围:
可测试性定义、可测试性特征、可测试性设计。
读者对象:
系统分析和设计人员、开发人员、测试人员。
参考文献:
1、《软件可测试性需求设计》Vince
2、《高质量C++/C编程指南》林锐
3、《软件工程思想》林锐
二、软件可测试性定义
2.1可测试性定义
软件的可测试性是指在一定的时间和成本前提下,进行测试设计、测试执行以此来发现软件的问题,以及发现故障并隔离、定位其故障的能力特性。
简单的说,软件的可测试性就是一个计算机程序能够被测试的容易程度。
一般来说可测试性很好的软件必然是一个强聚、弱耦合、接口明确、意图明晰的软件,而不具可测试性的软件往往具有过强的耦合和混乱的逻辑。
2.2可测试性特征
1、可操作性:
“运行得越好,被测试的效率越高。
”
1)系统的错误很少;
2)没有阻碍测试执行的错误;
3)产品在功能阶段的演化(允许同时的开发和测试)。
2、可观察性:
“你所看见的就是你所测试的。
1)每个输入有唯一的输出;
2)系统状态和变量可见,或在运行中可查询;
3)过去的系统状态和变量可见,或在运行中可查询(例如:
事务日志);
4)所有影响输出的因素都可见;
5)容易识别错误输出;
6)通过自测机制自动侦测部错误;
7)自动报告部错误;
8)可获取源代码。
3、可控制性:
“对软件的控制越好,测试越能够被自动执行与优化。
1)所有可能的输出都产生于某种输入组合;
2)通过某种输入组合,所有的代码都可能被执行;
3)测试工程师可直接控制软件和硬件的状态及变量;
4)输入和输出格式保持一致且有结构;
5)能够便利地对测试进行说明、自动化和再生;
6)接口和模块易控制;
7)业务流程和场景易控制。
4、可分解性:
“通过控制测试围,能够更快地分解问题,执行更灵巧的再测试。
1)软件系统由独立模块构成;
2)能够独立测试各软件模块;
3)业务流程和场景易分解。
5、简单性:
“需要测试的容越少,测试的速度越快。
1)功能简单性(例如:
特性集是满足需求所需的最小集合);
2)结构简单性(例如:
将体系结构模块化以限制错误的繁殖);
3)代码简单性(例如:
采用代码标准为检查和维护提供方便)。
6、稳定性:
“改变越少,对测试的破坏越小。
1)软件的变化是不经常的;
2)软件的变化是可控制的;
3)软件的变化不影响已有的测试;
4)软件失效后能得到良好恢复和隔离。
7、易理解性:
“得到的信息越多,进行的测试越灵巧。
1)设计能够被很好地理解并遵循行业规;
2)部、外部和共享构件之间的依赖性能够被很好地理解;
3)设计的改变被通知;
4)可随时获取技术文档;
5)技术文档组织合理;
6)技术文档明确详细;
7)技术文档精确性稳定;
8)相关环境配置说明与操作指导。
三、软件可测试性设计
3.1可测试性设计
软件的可测试性特征主要表现是设立观察点、控制点、观察装置、驱动装置、隔离装置。
需要注意的是可测试性设计时必须要保证不能对软件系统的任何功能有影响,不能产生附加的活动或者附加的测试,采取合适的设计模式对软件进行设计。
1、坚持测试驱动设计(测试先行)的方法。
优先编写测试代码,这是标准的XP方法。
不是说应该一次性编写全部测试代码后,再一次性全部实现。
先写验收测试,再写单元测试,编写一些测试代码,实现它们,再编写一些测试代码,再实现它们等等是个更好的办法。
设计以这种方式得以进展;
在实现阶段捕捉错误并在下一组测试中改正它,以这种方式编写测试也更少会使人畏缩。
2、尽量做到每个操作对应一个函数,使函数小型化。
使用小型函数说明和重载带缺省参数的函数将使在测试中调用这些函数变的愉快的多。
否则,在测试这些函数时将不得不构造额外参数,如果参数很大,那么将很快导致代码膨胀。
更糟的是,它会诱使你编写比在其它情况下更少的测试。
3、数据的显示与控制分离
把代码移到GUI视图的外面。
然后各种GUI动作就能成了模型上的简单方法调用。
这样,对GUI测试者来说,通过方法调用测试功能比间接地测试功能容易的多。
另一个好处是它使修改程序功能而不影响视图变的更容易。
4、可控制性设计
1)全局变量的可控制性设计
I.在外界使用适当的手段能够直接或间接控制该变量,包括获取、修改变量值等;
II.可以将全局类型的变量进行分类并封装到一个个接口中操作。
2)接口的可控制性设计
对于向外提供的接口的接洽处能够人为的对接,比如构造测试环境模拟接口对接,这里所指的开放接口主要是指相对于整个被测系统,即为被测系统以外提供的接口。
3)模块的可控制性设计
4)业务流程的可控制性设计
5)场景的可测试性设计
5、可分解性设计
1)业务流程的可分解性设计
2)场景的可分解性设计
6、稳定性设计
7、易理解性设计
I.设计参考标准
II.容描述主次要分清
III.依赖关系描述明确
I.接口功能明确
II.参数有意义
8、可观察性设计
1)业务执行状态和过程可观察性设计
2)异常情况可观察性设计
9、测试驱动和桩的设置
10、适合增量式开发的可测试性设计
11、可查询设计
1)对系统级别的全局变量或者状态设置查询接口;
2)某一业务或场景调用接口设置接口路径查询
12、自愈合功能
在某一场景中的局部出现故障时设置多路选择或者其他干涉进行跳转执行气候的具有正常逻辑的功能。
13、输出结果
14、提供统一的操作执行面板
操作面板元素主要由输入和输出元素组成,如所执行的操作和对应的输出,但可能被测系统是一个比较复杂的系统,由多个可以独立的模块组成,涉及到的操作和输出比较多,各操作之间的关联也比较复杂。
在设计时统一的做一个操作面板,该操作面板成为一个可以操作整个被测系统的独立模块,一种是以命令的形式执行操作,直接以printf语句的形式输出查看,另一种是以GUI的形式,输入(执行的操作)输出均在界面上执行和体现,这样比较直观。
如下图所示:
3.2可测试性编码
1、注释需要详尽。
特别对于接口,要描述清楚功能、实现及参数;
2、使用模块化方法,编码低耦合、高聚;
3、为集成测试与系统联调准备调测开关及相应打印函数,并且要有详细的说明;
4、为单元测试选择恰当的测试点,并仔细构造测试代码、测试用例,同时给出明确的注释说明。
测试代码部分应作为(模块中的)一个子模块,以方便测试代码在模块中的安装与拆卸(通过调测开关);
5、使用断言来发现软件问题,提高代码可测试性;
6、用断言来检查程序正常运行时不应发生但在调测时有可能发生的非法情况;
7、为测试自动化工具提供所需要的特定“钩子(hook)”;
8、对于每个功能,提供访问、修改“状态”变量的接口,包括提供查询、修改上层软件、软硬件接口、底层硬件状态的接口及打印;
9、提供查询系统状态的接口。
比如存使用、程序使用进程数等;
10、对于测试因为环境等因素而可能无法测试的功能,提供接口模拟软件实现该功能的过程;
11、对于修改功能,提供修改功能参数单位的接口,以便于进行如软件性能等的测试;
12、出错及异常处理保存记录,记录具有详细的属性,并且格式统一、意义明确;
13、在程序异常时,除了保留日志,还需要提供观察、恢复的外部方法;
14、对全局变量、特殊结构,提供查询的方法。
3.3可测试性调试与定位
1、对于程序中所涉及到的变量尽可能的在调试过程中可以查询及修改;
2、在整个软件系统执行过程中为每个关键业务或相对独立的业务设定一个调试点,便于系统集成和问题围的定位;
3、在设定好的调试点处对处理的业务输出数据和全局数据进行可视化输出,便于测试结果的分析。
3.4测试所需文档
可测试性的具体体现
(一)
2009-2-1713:
49作者:
阿七整理来源:
51Testing博客
软件测试功能测试
一.功能测试
1.安装测试:
1)安装过程中对于缺省安装目录及任意指定的安装目录,是否都能正确安装;
2)若是选择安装,查看能否实现其相应的功能;
3)在所有能中途退出安装的位置退出安装程序后,验证此程序并未安装成功(没有程序组及程序项产生);
4)软件安装后,对其它已经安装的软件是否有影响;
5)裸机安装后,各功能点是否可用;
6)安装前,安装程序是否判断可用磁盘空间大小,如果不能满足安装空间要求,安装程序能否继续;
7)安装过程中查看声明、版本信息、公司名称、LOGO等是否符合标准;
8)安装过程中界面显示与提示语言是否准确、友好;
9)重复安装时系统是否有提示、是否可以覆盖安装、是否可以升级安装、是否允许多版本共存;
10)是否有注册码或硬件加密狗,在没有它们(或错误)存在的情况下能否顺利安装。
2.配置测试
1)是否可以按照用户手册的说明,运行于多种操作系统(Windows各版本、Unix、Linux等);
2)按系统最低要求进行软件的安装配置,查看能否正常实现各种功能;
3)数据源等信息配置不正确时能否给出提示信息;
4)是否可以按照用户手册的说明,支持多种数据库。
3.卸载测试
1)卸载后注册表中的注册信息及相关的程序安装目录是否能完全删除掉;
2)卸载过程中完全删除共享文件后,看其它程序能否正常运行;
3)卸载后,是否对其它已经安装的软件有影响;
4)系统卸载后用户建立文档是否保留;
5)软件卸载画面上的软件名称及版本信息是否正确;
6)在所有能中途退出卸载的位置是否能正确退出;
7)卸载过程中界面显示与提示语言是否准确、友好;
8)卸载后安装此系统能否打开原来保存的文件,并一切运行正常;
9)卸载程序如果要求重新启动机器,在重启动之间是否给用户提示以保存现有的己运行的程序的资料;
10)是否可以选择组件进行卸载;
11)卸载过程中,对意外情况的处理(掉电等)。
12)在卸载过程中,是否有终止或者结束按钮。
4.运行与关闭测试
1)运行时是否与其它应用程序有冲突(存冲突);
2)是否可以同时运行多个程序;
3)任务栏有无程序运行提示;
4)若有未保存的数据,关闭系统时是否有提示;
5)后台服务程序在点击关闭按钮时是否有确认提示;
6)运行时是否过份占用系统资源、退出时能否完成释放占用的系统资源。
5.服务程序的测试:
1)系统是否限制服务器程序启动的数量,如不限制,同一围启动多个服务是否对系统有影响;
2)服务程序能否长时间正常运行;
3)外界异常后,服务程序的自动恢复能力(服务器掉电、网络中断后恢复、数据库异常后恢复…);
4)在点击关闭按钮时是否有确认提示;
5)应用程序与其他程序是否兼容(能否避免存冲突)。
6.系统管理(参数设置)
1)参数设置后,能否正确的进行应用;
2)设置错误参数,系统的容错能力;
3)修改参数,对与之相关模块的影响;
4)系统是否有默认的参数,A有:
默认的参数是否起到作用;
B没有:
不设置,系统能否运行或者给出提示。
7.用户、权限管理
1)赋予一个人员相应的权限后,在界面上看此人员是否具有此权限,并以此人员身份登陆,验证权限设置是否正确(能否超出所给予的权限);
2)删除或修改已经登陆系统并正在进行操作的人员的权限,程序能否正确处理;
3)重新注册系统变更登陆身份后再登录,看程序是否能正确执行,具有权限是否正确;
4)在有工作组或角色管理的情况下,删除包含用户的工作组或角色,程序能否正确处理;
5)不同权限用户登录同一个系统,权限围是否正确;
6)覆盖系统所有权限设定;
7)能否添加信息为空的用户(其中包括空用户名及空口令、空用户名非空口令、非空用户名及空口令);
8)能否添加长用户名及长口令,如果允许,新用户能否正确登录;
9)系统是否允许删除系统管理员这一特殊用户或修改系统管理员口令,删除或修改后系统的实际情况;
10)登录用户能否修改自己的权限;
11)添加用户(有标识或编号):
标识相同,用户名不同;
标识相同,用户名相同;
标识不同,用户名相同;
标识不同,用户名不同;
12)登录用户能否修改本人(或其他人)的信息,删除本人(或其他人);
13)修改用户的信息(包括权限,口令,基本信息等),对其他模块的影响;
14)修改用户信息:
修改后的用户信息和已经存在的用户信息相同;
修改后的用户信息和已经存在的用户信息不同;
15)不给用户授权,是否允许登录;
15)改某些设置时,是否会影响具有上级权限及相同权限人员的设置;
16)系统管理员修改了某些数据,以其他人员身份登录时数据是否改变;
17)用户能否同时属于多个组,各个组的权限能否交叉;
18)删除后重新添加的用户是否具有以前的权限;
更改用户各项属性(包括权限)看对权限是否有影响。
8.系统登录测试
1)使用合法用户登录系统;
2)用户名、口令错误或漏填时能否登陆;
3)系统是否容许多次非法登陆,是否有次数限制;
4)使用已登录账号登录系统系统能否正确处理;
5)使用禁用登陆系统能否正确处理;
6)删除或修改后的用户用原用户登录;
7)不输入用户名和口令,重复点“确定”和“取消”按钮,是否允许登录。
9.注销
1)注销为原模块、新模块系统能否正确处理;
2)中止注销能否返回原模块、原用户;
3)注销为原用户、新用户系统能否正确处理;
4)使用错误的、口令或无权限、被禁用进行注销。
10.修改口令
1)正常情况;
2)输入错误的原口令或新口令与确认口令不一致系统能否正确处理;
3)修改口令后,用原口令是否能登录(同时验证新口令是否有效);
4)是否能修改其它用户的口令。
11.右键功能
1)右键菜单中的功能是否与菜单(或工具栏)中对应的功能一致;
2)右键菜单中的功能能否正确实现;
3)同一菜单下的热键是否相同。
12.记录列表
1)增加重复记录、空白记录,系统能否正确处理;
2)修改后不保存(有保存按钮),系统能否正确处理;
3)删除或修改正在使用信息,系统能否正确处理;
4)删除级联记录的上游或下游记录,系统能否正确处理;
5)删除记录时是否有提示;
6)记录中包含的缺省系统信息能否删除和修改;
7)记录列表能否及时反应记录的变化;
8)记录变化之后系统相关信息能否及时更新;
13.统计、查询
1)对非法的时间围系统能否正确处理;
2)统计查询语句包含多个与或非条件时,系统能否正确处理;
3)条件逻辑混乱,
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 测试 需求