行业资料软件可测试性需求

行业资料软件可测试性需求 软件可测试性需求设计 来源:考试吧(Exam8.com) 2009-8-7 【考试吧:中国教育培训第一门户】 模拟考场 视频课程 百度推广 一、引言 1、目的 提高软件的可测试性，加快测试进度，提高测试效率。 2、范围 描述的范围主要是可测性设计的特征，考虑方向及设计方法。 3、读者对象 系统分析员、设计人员、开发人员。 二、测试所需文档 1、需求规格说明书 2、概要设计说明书 3、详细设计说明书 4、系统功能清单 5、系统运行环境搭建指导书 6、系统操作指导书 三、可测试性设计需求 可测试性主要是指被测实体具有如下特征:可控制性、可分解性、稳定性、易理解性、可观察性，该特征的主要要表现是设立观察点、控制点、观察装置。需要注意的是可测性设计时必须要保证不能对软件系统的任何功能有影响，不能产生附加的活动或者附加的测试。 1、可控制性设计需求 1)全局变量的可控制性设计需求 在外界使用适当的手段能够直接或间接控制该变量，包括获取、修改变量值等。可以将 全局类型的变量进行分类并封装到一个个接口中操作。 2)接口的可控制性设计需求 各接口在外界使用适当的手段能够直接调用对该接口进行操作，这里所谓的适当的手段主要包括使用测试工具和增加额外代码。对于向外提供的接口的接洽处能够人为的对接，比如构造测试环境模拟接口对接，这里所指的开放接口主要是指相对于被测系统，即为被测系统外提供的接口。接口接洽处人为对接时各接口所要求的条件和所需的参数人为的能够轻易达到和提供。 3)模块的可控制性设计需求 对于每个相对独立的模块设计好所需要的驱动和桩都能单独设计用例进行测试对应的功能，在测试运行期间模块异常时能够将其隔离而不影响测试。 4)业务流程的可控制性设计需求 在测试环境满足的情况下能够控制任一单独业务流程，各业务流程具有流通性。 5)场景的可测性设计需求 将一场景所涉及到的业务和接口整合到一个统一的接口使其能够单独操作该场景。 2、可分解性设计需求 1)业务流程的可分解性设计需求 对于复杂的业务流程需合理设定分解点，在测试时能够对其进行分解。 2)场景的可测性设计需求 对于复杂的场景需合理设定分解点，在测试时能够对其进行分解。 3、稳定性设计需求 测试模块发布合理，不能在后期追加的模块为前期所测模块引入新的不必要的测试活动。 4、易理解性设计需求 1)设计文档的易理解性 设计参考 标准 excel标准偏差excel标准偏差函数exl标准差函数国标检验抽样标准表免费下载红头文件格式标准下载 内容描述主次要分清 依赖关系描述明确 2)接口的易理解性 接口功能明确 参数有意义 3)业务的易理解性 4)场景的易理解性 5、可观察性设计需求 1)业务执行状态和过程可观察性设计需求 2)异常情况可观察性设计需求 6、测试驱动和桩的设置 为单个测试接口、测试业务、测试场景预留测试驱动和桩的接入点。 7、适合增量式开发的可测性设计 在增量式开发过程中必须优先考虑测试桩和测试驱动实现的难易程度和真实性。 8、可查询设计 对系统级别的全局变量或者状态设置查询接口; 某一业务或场景调用接口设置接口路径查询。 9、自愈合功能 在某一场景中局部出现故障时设置多路选择或者其他干涉进行跳转执行使其具有正常逻辑功能。 10、输出结果 对于任何一项操作都要能产生预期的输出，不管是正确的还是错误的甚至是异常的。测试结果的表现形式可以是数据、现象等，不管是以什么方式表现，都要有依可寻，在设计文档中要有说明。对于测试结果易于判断，具有可分析性、可获得性。在设置的各个控制点或观察点的结果易于查询、修改等。 11、提供统一的操作执行面板 操作面板元素主要由输入和输出元素组成，如所执行的操作和对应的输出，但由于被测系统可能是一个比较复杂的系统，由多个可以独立的模块组成，涉及到的操作和输出比较多，各操作之间的关联也比较复杂。在设计时统一的做一个操作面板，该操作面板成为一个可以执行整个被测系统操作的独立模块，一种是以命令的形式执行操作，直接以printf语句的形式输出查看，另一种是以GUI的形式，输入(执行的操作)输出均在界面上执行和体现，这样比较直观。 特别对于执行某一场景时要跟踪该场景的关键过程和执行后的输出参数，给出一系列可以分析的数据，该场景可以以执行过程分阶段监控，将监控范围内的数据输出以供测试人员分析。 [讨论],,,,,需求的可测试性 需求需求 敏捷模式中强调User,,,,,Story的可测试性。我觉得在传统模式中，强调需求的可测试性也有非常大的好处。 1.,,,,,用户需求以文字性描述居多，如果需求有测试通过标准，那么开发和测试人员都可以有一个容易遵循的规则。 2.,,,,,需求有通过标准，说明开发测试以及需求分析人员都达成了共识，减少工作中的分歧。 3.,,,,,既然要研究测试通过标准，那么自然就要求QA从需求分析阶段就开始工作。我想这是所有QA都期盼的结果。 4.,,,,,如果团队无法设计出需求的通过标准，那可能是需求不够明确或者团队缺乏相关的知识。总之，大家可以在开发前就可以知道这个需求多半是无法完整实现的。 应该还有其他的好处，大家可以来讨论一下。,,,,, 软件可测试性设计 发布时间:,,,,,2009-8-06,,,,,17: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)设计的改变被 通知 关于发布提成方案的通知关于xx通知关于成立公司筹建组的通知关于红头文件的使用公开通知关于计发全勤奖的通知 ; 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、易理解性设计 1)设计文档的易理解性 I.,,,,,设计参考标准 II.,,,,,内容描述主次要分清 III.,,,,,依赖关系描述明确 2)接口的易理解性 I.,,,,,接口功能明确 II.,,,,,参数有意义 3)业务的易理解性 4)场景的易理解性 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,,,,,测试所需文档 1、需求规格说明书 2、概要设计说明书 3、详细设计说明书 4、系统功能清单 5、系统运行环境搭建指导书 6、系统操作指导书 可测试性的具体体现(一) 发布时间:,,,,,2009-2-17,,,,,13: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),,,,,条件逻辑混乱，系统能否正确处理; 4),,,,,多表查询统计及单表查询统计功能是否正确实现; 5),,,,,分类查询、精确查询、无条件查询、组合查询能否完整列出满足条件的记录; 6),,,,,能否按系统默认的条件进行查询; 7),,,,,当统计时间段为当日、跨日、跨月、跨季、跨年度时，统计查询结果是否正确; 8),,,,,当某些操作被别人取消后，设置条件段为取消前、取消后、包含取消操作的一段时间; 9),,,,,以不同的权限登录时，统计、查询是否正确; 10),,,,,在查询或统计大数据量时，系统是否允许终止操作; 11),,,,,查询、统计按钮是否允许双击或更多的点击，系统做何反映; 12),,,,,查询出的数据是否允许修改。 可测试性的具体体现(二) 发布时间:,,,,,2009-2-17,,,,,13:52,,,,,,,,,,,,,,,,,,,,作者:,,,,,阿七整理,,,,,,,,,,,,,,,,,,,,来源:,,,,,51Testing博客 字体:,,,,,,,,,,小,,,,,,,,,,中,,,,,,,,,,大,,,,,,,,,,|,,,,,上一篇,,,,,下一篇,,,,,|,,,,,打印,,,,,,,,,,|,,,,,我要投稿,,,,,,,,,,|,,,,,推荐 标签:,,,,,软件测试,,,,,功能测试 14.,,,,,文件操作 a、保存 1),,,,,文件是否能够正确保存在在缺省位置或指定位置(本地、网络); 2),,,,,系统能否正确处理长文件名、特殊字符文件名保存; 3),,,,,文件能否保存为其它扩展名; 4),,,,,如应用程序对文件名区分大小写，当这些文件在导出到介质中时，系统能否正确处理; 5),,,,,介质空间已满时，系统是否给出提示。 b、打开 1),,,,,打开文件是否正确显示上一次保存的内容; 2),,,,,系统能否正确处理非系统默认扩展名的文件; 3),,,,,文件能否被其他程序正确打开; 4),,,,,打开对话框中，是否有默认扩展名的文件类型; 5),,,,,打开对话框时，是否有默认的路径。 c、打印输出 1),,,,,是否按所设置的格式打印; 2),,,,,是否有打印预览，能否设置打印字体，打印效果是否合乎客户要求; 3),,,,,打印预览的内容是否正确，内容是否能够进行拖拽操作，是否影响实际的打印; 4),,,,,安装或不安装打印功能模块，对其它模块是否有影响; 5),,,,,打印机未安装系统有无提示; 6),,,,,打印中途能否进行正常的打印中断，是否可以选择打印的内容。 7),,,,,能否进行本地或网络打印。 d、导入、导出功能 1),,,,,导入的文件格式非要求时，系统如何处理; 2),,,,,导入、导出的有效文件能否完整正确地显示并被使用; 3),,,,,导出后的文件是否允许修改，如果允许，导入后能否使用;如不允许，系统有何限制; 4),,,,,导入，导出是否可以选择路径; 5),,,,,在客户端和服务器端进行导入，导出; 6),,,,,在客户端和客户端之间进行导入，导出; 7),,,,,在本地进行导入，导出; 8),,,,,不同文件格式的导入，导出。 e、检入与检出 1),,,,,单文件、多文件检入与检出; 2),,,,,能否多次检入与检出; 3),,,,,文件检出后其它人能对其做何操作。 15.,,,,,界面上对象的功能(文本框，下拉框，按钮，热键等等) a、工具条 1),,,,,工具条能否正常显示/隐藏; 2),,,,,工具条按钮在不可用时是否置灰，例如在不置灰情况下，重复点击工具条上的按钮，看系统是否能够正常进行操作; 3),,,,,可移动工具条在窗口中间位置其形状是否正确; 4),,,,,工具条船坞状与非船坞状时其上按钮是否相同; 5),,,,,工具栏上工具按钮功能是否能正常实现; 6),,,,,工具按钮显示是否正确、友好、醒目易懂; 7),,,,,工具栏上的工具按钮是否有鼠标悬停提示; 8),,,,,工具栏上的工具按钮是否可以任意定制。 b、下拉列表 1),,,,,列表记录的每一行是否显示完整; 2),,,,,列表记录不能在一页中显示时，是否有纵向滚动栏; 3),,,,,列表滚动栏上滑块能否自由滑动，对应内容显示是否正确; 4),,,,,列表中内容能否自动排序。 c、窗口 1),,,,,打开的窗口不确认关掉，能否再调其它窗口，且连续开窗口系统能否正确处理; 2),,,,,窗口尺寸变化时窗口中控件能否自适应; 3),,,,,MDI中，子窗口的平铺、重叠、排列图标功能是否正确; 4),,,,,窗口的标题、图标是否和菜单命令、按钮一致; 5),,,,,子窗口和主窗口的属性是否正确; 6),,,,,窗口中的上下左右滚动条是否能达到预览全部界面的效果。 d、文本框 1),,,,,对输入域的必添项处理是否正确; 2),,,,,输入域是否有长度限制; 3),,,,,输入域如对某些字符禁止输入时，限制是否成功; 4),,,,,中文、英文、空格，数字，字符，下划线、单引号,,,,,等所有特殊字符的组合; 5),,,,,口令域 ?,,,,,口令为空格或包含空格、特殊字符(所有特殊字符的测试)时系统能否正常处理; ?,,,,,口令位数是否有限制; ?,,,,,口令与帐号相同，系统是否有提示; ?,,,,,口令为字典单词系统能否正确处理; 特殊的对系统安全性要求较高应该注意: ?,,,,,口令应有最少位数限制; ?,,,,,口令应为数值、大小写字母、特殊字符的组合; ?,,,,,口令禁止设为空，不能和要被修改的口令一致; ?,,,,,口令区分大小写; 6),,,,,时间域 ?,,,,,年度超过4位; ?,,,,,月份输入0或大于12; ?,,,,,日期输入0或大于当前月份的天数; ?,,,,,年度，月份，日期输入负数; ?,,,,,时间输入大于或小于边缘值的数据; ?,,,,,进行字符及汉字的输入，看程序能否正确处理; ?,,,,,系统中所涉及时间是否取服务器时间; ?,,,,,有范围的输入域，开始时间大于、小于、等于结束时间，系统能否正确处理; ?,,,,,时间范围同当前时间的关系是否正确; ?,,,,,是否包含缺省时间且缺省时间意义是否正确; ?,,,,,系统对闰年，闰月的处理; ?,,,,,对不同的时间格式(yyyy-dd-mm,yy-dd-mm,yyyy/dd/mm,yy/dd/mm等)是否允许输入; ?,,,,,输入的时间在与之有关的模块中是否能正确的起到作用及对其他模块的影响; ?,,,,,对时间点的测试。 7),,,,,货币域 ?,,,,,输入负值、零、特大数、小数系统能否正确处理; ?,,,,,系统对小数点后数位的控制是否正确; ?,,,,,系统能否正确处理数值计算; ?,,,,,输入非数值型数据(包括特殊字符)，系统能否正确处理; ?,,,,,系统能处理货币的种类。 8),,,,,身份证(18或15位): 身份证中输入非法的年月日信息(包括超界数字及字符，汉字)，程序能否进行检验并正确处理; 由身份证号码计算年龄，系统对出生年份末两位数是00的身份证号码能否正常处理; 在年龄和身份证均作为用户信息输入时，是否具有关联; 在身份证的输入中，是否允许输入字符”x”。 9),,,,,电话号码 ?,,,,,输入特殊的电话号码，如119，110，800等看程序是否能正确处理; ?,,,,,验证,，(，),,,,,*,,,,,#,,,,,是否有真正含义; ?,,,,,电话号码长度是否有限制; ?,,,,,电话号码是否允许输入汉字，英文。 10),,,,,关于时间的其它操作 ?,,,,,时间的跨月份、年度操作; ?,,,,,12小时、24小时制的操作; ?,,,,,客户机与服务器时间不同的操作(包括客户机与服务器两地时差不同); 11),,,,,数据字段一致性 不同窗口中同一类数据输入域的数据接口是否一致(如添加用户及用户登录窗口对用户标识和口令的长度是否一致)。 e、图表曲线 首先，在一定的时间段观察曲线走势，如果有类似的软件可对比的话可以进行对比大体趋势，然后，再找关键点，对比关键点的数据。测试中，需要找到曲线的计算公式，找关键点进行计算。(进行对比是必要的，第一，可以节省一些不必要的工作量;第二，也有可能是编码人员所用的公式本身就有问题，而你所有测试所做的计算都是徒劳了。) f、列表 1),,,,,列表记录不能在一页中显示时，是否有纵向滚动栏;记录长度超过列表宽度时，是否有横向滚动栏; 2),,,,,列表滚动栏上滑块能否自由滑动，滑块滑动时，对应内容显示是否正确; 3),,,,,列表内容是否可直接输入; 4),,,,,列表中每列数据能否按升序、降序排列; 16.,,,,,备份与恢复 1),,,,,备份T日的数据，进行操作，然后恢复，查看恢复的数据是否正确; 2),,,,,备份到不同介质上，并考虑介质空间已满的情况; 3),,,,,用系统提供的恢复功能进行恢复: ?,,,,,用数据库进行恢复; ?,,,,,在备份和恢复还没有结束的时候，终止(掉电，网络不通等)备份和恢复; ?,,,,,有操作的时候，进行备份和恢复; ?,,,,,没有任何操作的时候，进行备份，恢复; ?,,,,,部分备份，全部备份，部分恢复，全部恢复有选择的备份和恢复; 4),,,,,进行备份，恢复操作是否有权限限制,,,,,A,,,,,有:,,,,,分别用有权限的用户和没有权限的用户进行操作,,,,,B,,,,,没有:单个用户进行备份，恢复;多个用户同时进行备份和恢复。 17(系统日志的处理 1),,,,,系统能否正确记录日志信息; 2),,,,,系统是否有清空日志的功能; 3),,,,,系统是否有导出日志的功能; 4),,,,,当日志数据超过容量时，系统如何处理。 二(性能测试 具体用例不好设计，下面列出了一些有性能要求的测试点: 1),,,,,查询 2),,,,,保存 3),,,,,统计 4),,,,,刷新 5),,,,,显示 6),,,,,传输 7),,,,,响应 8),,,,,下载 打开网络上其它介质上的文件时，可制造网络拥挤情况下的文件打开操作。主要测试点，集中在几个点上。一是数据量小的时候主要的查询统计刷新等功能点;二是数据量积累到一定程度时的查询统计刷新时间，这里的一定程度是根据实际的项目和客户需求来定的。 三(极限压力测试 1),,,,,接收大数据量的数据文件时间; 2),,,,,大数据恢复时间; 3),,,,,大数据导入导出时间; 4),,,,,大批量录入数据时间; 5),,,,,大数据量的计算时间; 6),,,,,多客户机同时进行某一个提交操作; 7),,,,,采用测试工具软件; 8),,,,,编写测试脚本程序; 9),,,,,大数据量的查询统计时间。 四.,,,,,容错测试 1),,,,,通过断开网线的强制性停止数据传输以及重新将网线接上，查看提示信息及对系统的影响; 2),,,,,系统断电，恢复后查看对系统的影响程度; 3),,,,,死机后，看程序如何处理; 4),,,,,服务器DOWN掉，客户端程序如何处理。 五(并发测试 1),,,,,登录的并发操作:多人同时登录系统，使用不同或相同账号; 2),,,,,提交的并发操作:多人同时提交相同的工作项、不同的工作项; 3),,,,,对数据库操作的并发操作:多人同时从数据库中读出(或向数据库导入),,,,,相同文件、不同文件。 ************************ 附:一些容易出错的地方 ************************ 一.,,,,,有关新建和修改 1.,,,,,创建或修改的内容为已经存在的内容，系统是否有提示; 2.,,,,,修改正在使用的数据。 二.,,,,,删除 1.,,,,,应有确认提示; 2.,,,,,若删除的内容在文件或数据库中，应作实际校验; 3.,,,,,删除正在使用的数据; 4.,,,,,考虑删除数据的相关数据是否同时被删除; 5.,,,,,重新使用已删除的数据。 三(关于提示信息的验证 有些操作系统会给出成功(有时没有成功提示)或失败的提示，一定要验证提示的正确性(尤其是一些重要操作，如修改口令)，即用其它方法检查所作的操作是否真正成功或失败。 四(关于考虑硬盘空间已满的情况 1.,,,,,数据存储和备份; 2.,,,,,生成文件; 3.,,,,,拷贝文件 五(关于修改系统时间 对于和时间有关的业务，测试时考虑修改系统时间对系统的影响。 六(对于响应速度慢的按钮进行连续点击;或中途取消，再继续… 七(凡是支持并发过程的功能，一定要做并发测试(手工进行或利用工具); 八(打印功能(能否正确打印，打印效果与预览是否一致) 九(系统初始化 1),,,,,如果系统安装后需要进行初始化，初始化过程是否正确; 2),,,,,如果系统安装后不需要进行初始化，安装后的默认设置是否正确、适当。 十(版权声明是否符合标准，如果有公司的logo，图标是否正确(最容易测试的地方，也是最容易被忽略的地方) 十一(如果捆绑硬件，如果可能的话，在测试我们的软件产品前要对硬件的性能、稳定性进行严格测试。(包括大数据量的传输入等) 十二(备份与恢复 1),,,,,备份与恢复过程本身的正确性; 2),,,,,备份内容的正确性(通过事先准备的测试数据在恢复后验证); 3),,,,,备份与恢复过程中对异常情况的处理(掉电、网络不通等); 4),,,,,在原始机上的恢复; 5),,,,,在非原始机上的恢复; 6),,,,,在裸机(只有操作系统和必要的数据库或第三方产品)上的恢复; 7),,,,,在一台机器上进行若干次的备份与恢复; 8),,,,,如果是支持多数据库的软件，备份与恢复是容易出错的地方。 需要严格把握的错误类别: 在整个测试过程中对每条问题都制定有错误归类，现按照问题的严重程度，把问题主要分为四类: A:严重影响系统运行:导致系统出现不可预料的严重错误的问题，例如:运行过程中出现页面或页面无法显示、死机等; B:影响系统运行:系统中重要的功能出现运行错误，例如:导致用户必须重新登录的问题，导致个别用户不可用的问题; C:不影响系统运行但必须修改:系统中基本的操作或功能没有实现或实现有误的问题，以及不符合常规的操作界面的问题; D:所提建议:不影响系统运行，对系统的可用性等提示的建议性的问题。 可测试性的内涵和设计 发布时间:,,,,,2009-6-04,,,,,13:35,,,,,,,,,,,,,,,,,,,,作者:,,,,,未知,,,,,,,,,,,,,,,,,,,,来源:,,,,,网络转载 字体:,,,,,,,,,,小,,,,,,,,,,中,,,,,,,,,,大,,,,,,,,,,|,,,,,上一篇,,,,,下一篇,,,,,|,,,,,打印,,,,,,,,,,|,,,,,我要投稿,,,,,,,,,,|,,,,,推荐标签:,,,,,软件测试技术,,,,,可测试性 1.可测试性描述了测试信息获取的难易程度 可测试性包括两方面的含义:一方面，便于对软件的内部状态进行控制，即所谓的可控性;另一方面，能够对软件的内部状态进行观测，即可观测性。实际上，可控性和可观测性所描述的就是对软件进行测试时信息获取的难易程度。传统的“黑箱”功能测试方法的根本缺陷就在于它难以获取有效表征被测对象内部状态的信息。 2.可测试性是软件本身的一种设计特性 同可靠性(reliability,,,,,)一样，可测试性也是软件本身所固有的一种设计特性。软件的可测试性并不是可测试性设计所赋予的，软件一旦设计生产出，本身就具备了一定的可测试性。正如可靠性可以通过MTBF等可靠性指标度量一样，可测试性也可以通过可控性、可观测性指标来度量。要改善软件的可测试性指标，必须在软件设计阶段就进行良好的可测试性设计。 3.可测试性技术的最终目标是提高软件的质量和可靠性，降低全寿命周期费用 降低软件的费用，追求软件的高质量是工业界的永恒主题。目前，单纯合格与否的传统质量标准已转变为综合了性能指标、可靠性及可用性(availability)指标要求的“完整质量”概念，而传统的仅考虑软件设计和生产费用的产品费用则被“全寿命周期费用”的概念所替代。全寿命周期费用包括软件整个生命周期中从概念形成到报废处理全过程的费用。 可测试性技术的应用可以极大地提高软件的“完整质量”，降低其全寿命周期费用。一方面，在软件设计阶段，可以对软件设计原型进行虚拟测试，验证设计 方案 气瓶 现场处置方案 .pdf气瓶 现场处置方案 .doc见习基地管理方案.doc关于群访事件的化解方案建筑工地扬尘治理专项方案下载 ，排除可能的设计缺陷;在生产阶段，可以对软件进行全面的测试，排除软件的潜在故障，从而降低使用过程中的故障率，提高其质量和可靠性;另一方面，可测试性技术可以缩短软件研制、试验和评价的周期，降低软件的研制费用，提高软件的可用性指标，减少软件的维护和保障费用，从而降低软件的全寿命周期费用。 第一代可测试设计技术:特定目标可测试性设计 第一代可测试性设计技术以外部测试和特定目标可测试性设计方法为基础。特定目标可测试性设计是指:针对特定功能和结构进行可测试性预计，判断其是否符合可测试性要求，若不满足，通过改善设计方案来提高其可测试性，直至满足要求。特定目标可测试性设计主要采用外部测试方法，测试向量的输入和测试响应的输出均通过被测设备的输入/输出端口进行操作，对被测对象内部节点的控制和观测则采用以在线(in-line)测试技术。其主要缺点如下: (1),,,,,设计同系统的具体功能和结构紧密相关，对较复杂的系统进行设计的难度大、周期长; (2),,,,,难以实现并行测试; (3),,,,,需要专用测试接口和测试工具，成本高; (4),,,,,随着系统的复杂，采用监控测试方法的适用范围日益减小。 目前，特定目标可测试性设计已逐渐被其他的可测试性技术所代替。尽管如此，对于复杂程度较低的而言，特定目标可测试性设计方法仍然是一种不可或缺的方法。 为可测性而设计 发布时间:,,,,,2007-8-28,,,,,15:13,,,,,,,,,,,,,,,,,,,,作者:,,,,,译者:陈能技,,,,,,,,,,,,,,,,,,,,来源:,,,,,陈能技的质量感悟 字体:,,,,,,,,,,小,,,,,,,,,,中,,,,,,,,,,大,,,,,,,,,,|,,,,,上一篇,,,,,下一篇,,,,,|,,,,,打印,,,,,,,,,,|,,,,,我要投稿,,,,,,,,,,|,,,,,推荐 标签:,,,,,软件测试 摘要 ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,本文提供若干实用的建议，帮助项目组开发出可测性更强的软件产品。 ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,本文对可测性(Testability)的定义为可见性和可控制性。可见性是我们能观察被测软件的状态、输出、资源利用和其它影响的程度;可控制性是我们能向被测软件输入或把它设置到某个特定状态的程度。 ,,,,, 可见性基础 ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,可见性的基本方面是能访问代码、设计文档和更改记录。这些是对大部分可测性进行改进的前提条件。 ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,测试人员需要知道如何阅读代码，以及如何理解设计模型所采用的语言。在测试人员能提出测试接口、错误注入钩子或其它可测性特性之前，他们需要对系统设计有基本的理解。 ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,可测性的改进需要测试人员和开发人员都使用共同的语言。 ,,,,, 详细的输出 ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,很多程序都有详细输出模式，这是可测性的很好的例子，它让人可以看到软件运转的细节。Unix的Mail程序就是其中一个例子: ,,,,, mail,,,,,-vbret@pettichord.com Subject:,,,,,testability,,,,,example Sample,,,,,text. . Cc: bret@pettichord.com...,,,,,Connecting,,,,,to,,,,,mx.io.com.,,,,,via,,,,,relay...,,,,,220-deliverat or.io.com ESMTP,,,,,Sendmail,,,,,8.9.3/8.9.3;,,,,,Fri,,,,,,12,,,,,Jan,,,,,2001,,,,,15:34:36,,,,,-00,,,,,220,,,, ,Welcome,,,,,to Illuminati,,,,,Online,,,,,,Fnord! >>>,,,,,EHLO,,,,,eris.io.com 250-deliverator.io.com,,,,,Hello,,,,,IDENT:wazmo@eris.io.com,,,,,[199.170.88.11],,,,,,pleas ed,,,,,tu 250-8BITMIME 250-SIZE,,,,,5000000 250-DSN 250-ONEX 250-ETRN 250-XUSR 250,,,,,HELP >>>,,,,,MAIL,,,,,From:,,,,,,,,,,SIZE=67 250,,,,,...,,,,,Sender,,,,,ok >>>,,,,,RCPT,,,,,To:,,,,, 250,,,,,...,,,,,Recipient,,,,,ok >>>,,,,,DATA 354,,,,,Enter,,,,,mail,,,,,,end,,,,,with,,,,,“.”,,,,,on,,,,,a,,,,,line,,,,,by,,,,,itself >>>,,,,,. 250,,,,,PAA07752,,,,,Message,,,,,accepted,,,,,for,,,,,deliverybret@pettichord.com...,,,,,Sen t,,,,,(PAA07752 Message,,,,,accepted,,,,,for,,,,,delivery),,,,,Closing,,,,,connection,,,,,to,,,,,mx.io.com. >>>,,,,,QUIT 221,,,,,deliverator.io.com,,,,,closing,,,,,connection ,,,,, ,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,这些详细的输出信息可以帮助测试人员了解客户端和服务器端之 间的通讯过程，从而帮助设计出测试用例来测试服务器的错误处理能力。同时这些信息可以 帮助暴露问题出现的地方。 ,,,,, 日志 ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,详细的输出信息是记录软件事件的其中一种技术。日志可以帮助测试人员更容易理解软件的运转情况。也可以帮助发现一些容易忽略的bug。当bug出现，日志可以帮助定位到错误的代码和帮助调试。 ,,,,, 诊断、监视和错误注入 ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,断言是一种普遍的诊断。断言是使程序对处理的输入的假设更加清晰明确的额外代码行。当断言被违反了(假设不成立)，错误或异常就自动出现。所以断言被违反就意味着bug。 ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,如果没有断言，你可能不会注意到bug已经发生，因为内部数据可能已经被破坏，但是只有当进一步的测试访问到这些数据时才出错。断言也可以帮助定位错误出现的代码位置。 ,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,查找内存泄漏问题的有效的方法是监视内存使用。有很多工具可以做到这点。如果能监视内部内存设置会使测试更容易。例如在Netscape输入“about:config”能把所有设置输出。对于于配置问题的追踪会有很大帮助，尤其是某些问题只是在特定的机器才会出现。 ,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,有时候测试人员需要访问内部数据。“测试点”可以让测试人员在系统的某个点检查数据或插入数据。这种方法对于数据流应用程序特别有用。 错误注入特性可以帮助测试错误处理代码。有很多环境错误是很难让它出现，特别是以可预见、可重复的方式出现的。例如:磁盘满、坏介质、断网等。错误注入技术就是加入钩子用于注入这些错误并触发软件的错误处理代码。 ,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,另外一种错误注入的方法是使用工具HEAT或Holodeck，它们扮演的是程序和操作系统之间的中介者角色。由于它所处的位置，所以它可以控制操作系统给程序提供的各种服务，包括内存、磁盘空间、网络等，从而触发各种环境问题，看程序的处理能力如何。 ,,,,, 测试接口 ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,手工测试比较容易使用GUI接口。自动化测试则使用编程接口容易些。 ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,Excel的早期版本包含一个测试接口。因为数学计算的准确性是一个关键的需求，所以能用自动化的方式频繁地运行测试变得非常重要。后来Excel的测试接 口公开给用户，我们现在都可以通过VB来访问。 ,,,,, 用户接口可测性 ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,GUI自动化测试工具面临的一个普遍问题是个性化控件。个性化控件是指那些不被GUI测试工具所识别的控件。 ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,评估和确保软件产品在指定的GUI测试工具下的可测性的过程如下: 1、,,,,,尽早测试GUI测试工具和开发工具的兼容性 2、,,,,,定义用户界面元素的命名标准 3、,,,,,查找个性化控件。如果有，计划提供可测性支持 A、确保工具可以用名称、类型和位置识别控件对象 B、确保控件使用的名字是唯一的。否则如果多个窗体或控件使用相同的标识可能导致工具识别不出来 C、确保工具可以检查控件的内容。能访问文本框的文本。能确认某个check,,,,,box是否选中 D、确保工具可以控制控件。能点按钮。能选择需要的菜单项 ,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,通常需要反复试验才能找到操作个性化控件的方法和技巧，例如: 1、,,,,,键盘操作 2、,,,,,初始化控件 3、,,,,,鼠标事件 4、,,,,,字符识别 5、,,,,,Clipboard访问 6、,,,,,外部访问 ,,,,, 结论:可测性选择 ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,自动化需要可测性。 ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,成功的自动化需要关注可测性。 ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,编程接口比用户接口提供更高效率的自动化测试支持。 ,,,,, 结论:让可测性发生 ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,测试人员必须认识到可测性需要他们清楚了解软件设计，评审现有的设计文档和阅读代码。 ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,测试人员通常因为害怕他们的请求会被拒绝而不愿意要求可测性。但是通常会发现，请求的可测性实际上已经在某些地方存在或者由于其他原因已经计划要做。 构件可测试性挑战 发布时间:,,,,,2007-4-14,,,,,11:47,,,,,,,,,,,,,,,,,,,,作者:,,,,,上海软件构件化服务中,,,,,,,,,,,,,,,,,,,,来源:,,,,,软件世 界 字体:,,,,,,,,,,小,,,,,,,,,,中,,,,,,,,,,大,,,,,,,,,,|,,,,,上一篇,,,,,下一篇,,,,,|,,,,,打印,,,,,,,,,,|,,,,,我要投稿,,,,, 构件的可测试性是设计和测试软件程序及构件的重要概念之一。运用具有良好的可测试性的程序和构件来构建软件，可以简化测试操作、减少测试开销、提高软件质量。 James,,,,,Bach曾指出，有一些程序特性可以用于可测试的软件，包括可操作性、可观察性、可控制性、易理解性等等。Jeffrey,,,,,M.Voas和Keith,,,,,W.,,,,,Miller将软件可测试性看成是可靠性的三个难题之一。他们指出软件可测试性分析对于检测和评估一个使用经验主义(empirical)分析方法的软件测试是很有用的。 然而，在构件工程、基于构件的软件开发中，开发者对构件的可测试性仍然存在一些疑惑。什么是构件的可测试性,它的相关要素是什么,怎样检查、测量或评价软件构件的可测试 性,怎样设计和开发可测试的构件来达到良好的可测试性, 构件可测试性是什么, 在构件工程中，有几种不同的构件可测试性的观点，包括构件可观察性(observability)、构件可跟踪性(traceability)、构件可控制性(controllability)和构件易理解性(understandability)。 构件可观察性和可跟踪性 根据Roy,,,,,S.,,,,,Freedman的观点，软件可观察性是指根据一个程序的操作行为、输入参数及输出结果，来察看观察这个程序的简单程度。这也暗指了设计和定义一个构件的接口(例如输入、输出接口)将会影响到它的可观察性。可以使用Roy,,,,,S.,,,,,Freedman提出的方法来检测一个构件的接口，相对于它的输入，来评价观察它的操作和输出的简单程度。应用到构件工程中，构件可跟踪性是另一个影响构件可观察性的要素。 软件构件的可跟踪性是指跟踪构件属性和构件行为的嵌入能力的范围。它有两方面:行为跟踪(behavior,,,,,traceability)和跟踪可控制性(trace,,,,,controllability)。行为跟踪指构件跟踪它的内部和外部行为的便利的程度。现实世界中，构件工程可以通过在软件中增加一个程序跟踪机制来检查和监视软件构件的内部和外部行为。 共计有六种类型的构件跟踪，它们是操作、性能、错误、状态、GUI事件和通讯跟踪。可以使用不同的方法将跟踪可控制性添加到软件构件中。为了支持嵌入功能的访问，必须在构件中定义一个标准跟踪接口。构件跟踪接口的标准化和跟踪格式对一个基于构件的程序建立系统化的跟踪解决方法很重要。 构件可控制性 一个程序(或构件)的可控制性是一个重要的特性，它表明了控制一个程序(或构件)的输入/输出、操作和行为的简单程度。构件开发者从三个方面察看软件构件的“可控制性”:行为控制，特性定制和安装布置。第一个方面与构件的行为和输出结果(相应于操作和输入数据)的能力有关，第二个方面指支持构件内部特性的定制和配置的嵌入能力，最后一个方面是指构件安装和配置的控制能力。 构件可理解性 构件可理解性依赖于构件信息提供的多少以及它们表述的好坏。构件文档的表述是第一要素。 构件可理解性的第二要素是构件程序资源表述，包括构件源代码及其支持元素，例如安装代码和测试驱动等。 最后一个要素是构件质量信息的表述，包括构件验收的测试计划和测试套件，构件测试度量和质量报告。 虽然看上去构件供应商隐藏了详细的测试信息和问题信息也挺合理的，但是用户还是希望在不久的将来他们能够提供构件的质量信息、验收的测试计划，甚至是测试套件。 测试软件构件的挑战 在构件工程范例中，主要目标之一是产生可复用的软件构件作为软件产品。第三方工程师根 据用户给出的需求，使用构件作为构建软件系统的部件。所以，程序的可测试性很大程度上依赖于相关构件及其集成的可测试性。构建软件构件的测试要考虑如下几点: 怎样复用构件测试, 考虑软件构件的演化，必须注意构件测试的可复用性。复用构件测试的关键是开发一些系统化方法和工具，来建立可复用的构件测试套件，管理和存储各种测试自愿，包括测试案例、测试数据和测试脚本。对于工程师来说，使用ad-hoc方法，用相同的测试套件技术来处理与当前软件不同的软件构件(例如，第三方构件)很难。在构件验收测试和构件集成中，这个问题就会影响构件测试的复用。 解决这个问题有两个可选择的方法。第一是为构件建立新的plug-in-and-test的测试套件技术;另一个方法是在构件内部建立测试，也就是嵌入式测试。第一种方法是在构件外部的测试套件中建立和维护构件测试，第二个方法是在构件内部建立构件测试。显然，如果一个友好的测试操作接口可行的话，这种方法简化了构件测试，减少了用户方的构件测试开销。要执行嵌入式构件测试，我们需要其他功能工具来执行测试、测试报告和测试结果检查。所以，需要标准化测试访问接口，来支持构件、测试套件和嵌入式测试的交互。 如何构建可测试的构件, 一个理想的可测试软件构件不仅是可配置可执行的，而且在标准化构件测试工具的支持下也是可测试的。与普通构件不同的是，可测试构件有以下一些特性: 可测试构件一定可跟踪;可测试构件一定有一些很好定义的测试工具的嵌入接口;具有嵌入式测试的可测试构件必须使用标准化机制; 关于可测试构件的设计有三个问题。第一个问题是对可测试构件，怎样设计和定义通用架构和测试接口，第二个问题是怎样用系统化方法产生可测试构件，最后一个问题是为了支持测试和可测试构件，怎样控制和最小化程序的费用和资源。 如何构建构件测试驱动和存根, 在设计应用中，工程师基于给定的需求和设计说明书，使用ad-hoc方法来开发特定模块或特定产品的测试驱动和存根。这种方法的主要缺点是产生的测试驱动和存根只对特定的项目(或产品)有用。 很明显，传统方法会导致在构件测试驱动和存根构建上的更高的开销。 显然，需要新的系统的方法来为不同的构建和各种定制服务构建测试驱动和存根。这其中的关键就是为构件产生可复用的、可配置的(或可定制的)、可管理的测试驱动和存根。 构件测试驱动必须是基于脚本的程序，只使用它的黑盒功能。这有两组，第一组包括特定功能测试驱动，每一个都使用了一个构件的特定产生功能(或操作);第二组包括特定情形的测试驱动，每一个都使用了一个构件黑盒操作(或功能)的特定顺序。 在构建构件框架时需要构件测试存根。每一个测试存根模拟构件的一个黑盒功能和/或行为。有两种方法产生测试存根。第一种是基于模型的;第二种方法是操作化的基于脚本的。然而，怎样用系统化的方法产生这些特定功能的测试存根是一大挑战。 总体而言，一个程序测试执行环境包括几个支持功能:测试检索、测试执行、测试结果检查 和测试报告。显然，一个构件的测试环境必须包括这些类似的功能。 怎样提高代码的可测试性 发布时间:,,,,,2007-11-12,,,,,14:11,,,,,,,,,,,,,,,,,,,,作者:,,,,,未知,,,,,,,,,,,,,,,,,,,,来源:,,,,,网络转载 字体:,,,,,,,,,,小,,,,,,,,,,中,,,,,,,,,,大,,,,,,,,,,|,,,,,上一篇,,,,,下一篇,,,,,|,,,,,打印,,,,,,,,,,|,,,,,我要投稿,,,,,,,,,,|,,,,,推荐 标签:,,,,,软件测试 现在越来越多的开发组织在程序开发中使用单元测试的方式，甚至有些外包工程要求开发者交货的时候提供完整的单元测试代码。单元测试不仅仅是在编码的时候需要考虑，在程序设计的时候就应该充分考虑测试的需要，要设计和编写出“可测试”的代码。 为什么一些代码难以测试 在进行单元测试的时候，会发现程序中某些部分很难进行自动测试，比如耦合程度比较高的类、用户界面、数据库、Servlets和EJB类、等等。本文主要说明程序中这些“难以测试”的部分应该采用什么样的方式去测试。是什么因素使得这些代码难以测试呢,首先是不知道测什么，其次是一些代码之间互相依赖严重，在测试环境中要建立起这些类的实例都很难。 应该测什么 我们首先假设某些部分是不会有问题的:假设Swing或者MFC的底层类是没问题的;假设Oracle、Sql,,,,,Server等等数据库的操作是没问题的。我们需要做的就是把我们自己写的代码部分和这些代码从物理上尽量的分离开，这样一来我们写的代码就可以测试了。至于Servlets这样的程序，可以使用HttpUnit或者使用一段程序调用其中的业务代码进行测试。 测试高耦合的类 我们看一下下面的程序: 程序中有一个CoffeeMaker类，我们想使用CoffeeMakerTest类对其进行测试。CoffeeMaker类工作的时候需要调用Warmer类和Boiler类，假设这两个类很难在测试环境中创建出来，这样的情况应该怎么进行测试呢,对于高耦合的类，事实上总是可以通过某种编程方法减少类之间的耦合。请看下面的例子: 在左边的图中，A和B紧密的耦合在一起。为了减弱这种耦合，在右侧的图中，在程序中引入了IB接口，类A只要了解IB接口就可以工作了。实际运行环境中可以使用B类实现IB接口进行实际的工作，测试环境下，可以实现一个虚拟的IB就口，就可以方面的对A进行测试了。 测试的时候情况如上图，真实运行情况下，IB的实现类是B。在测试的时候类B很难创建实例，因此在测试程序中创建BStub类的实例。BStub是专门为了测试而创建的，ATest类控制他的输入和输出。 如果简化上面的情况，可以更进一步:测试类本身就是IB接口的一个实现，这样就不用写一个新的类了，如下: 使用上面介绍的方式，减少类之间的耦合，下面就是Coffee,,,,,Maker的程序经过改进的情况，类之间的耦合程度大大下降，便于测试了。 类似上面介绍的Stub类的方法在单元测试中有很广泛的应用。这种方法要求在设计时充分考虑类之间的联系，类与类之间的关系要基于接口，而不是基于实现。这样的方式也会为程序带来最大的灵活性。 一般说来，下列模块都应该通过接口的方式进行调用: 1:硬件; 2:数据库; 3:还没有完成的类。 测试用户界面 测试用户界面是一个在设计的时候就应该考虑的问题(又强调了一遍，要在设计的时候考虑)。对用户界面进行单元测试，要求程序具有较好的层次性，用户界面和其背后的业务逻辑要是分离的。也就是说:用户界面只是薄薄的一层，并且用户界面和业务逻辑之间的耦合程度很小，模块间联系较为松散。这样的实现进行单元测试就很容易了。后台的业务逻辑可以独立进行测试，前台的界面可以写一个假的后台接口的实现进行测试。基本上所有的东西都是可以进行自动测试的。当然在实际上没有必要测试的这么具体，测试过多细节要花很多成本，并且随着需求的细微变更(比如某个控件位置的改变)都要修改测试程序也是不实际的。 程序设计一般遵循层次原则，一般说来，上层的程序可以调用下层的程序，同层之间也可能存在互相的调用。具体到UI的设计，如下所示:UI和下面各个层次之间的调用是单方向的，UI调用业务代码得到返回值，业务代码只能通过消息、事件和抛出错误等方式与UI发生联系，不能够在业务代码中直接调用UI，否则业务代码将不可测试。 一般说来，程序应该尽力减少UI和UI模块之间的互相调用，比如，窗口之间的迁移逻辑不应该写在窗体的代码中;业务代码之间的互相调用则是比较常见的，比如一个公司的管理系统，财务模块调用人员管理模块的接口，这是很正常的结构。层次之间原则上坚持单向调用。如果存在层次之间的双向调用，程序中的层次划分基本上就名存实亡了。 很多JSP开发者很熟悉STRUTS框架，这是MVC的一种实现。使用这个框架，可以使JSP页面成为程序的一种单纯的数据表示，不用进行任何业务功能。JSP画面之间的迁移、JSP对底层业务代码的调用都不是在UI层次上进行的。微软为应用程序的界面设计也创建了这样一种技术，叫做User,,,,,Interface,,,,,Process,,,,,(UIP),,,,,Application,,,,,Block。根据这样的技术，UI实际上简化为一个薄薄的层，UI之间的迁移、UI对后台层次的调用是在UIP层次上(User,,,,,Interface,,,,,Process)实现的。类似STRUTS的struts.config，程序也使用一个配置文件反映用户界面之间的迁移关系。有兴趣的朋友可以自己去MSDN看看。