可测试性需求

软件可测试性需求设计一、引言1、目的提高软件的可测试性，加快测试进度，提高测试效率。2、范围描述的范围主要是可测性设计的特征，考虑方向及设计方法。3、读者对象系统分析员、设计人员、开发人员。二、测试所需文档1、需求规格说明书2、概要设计说明书3、详细设计说明书4、系统功能清单5、系统运行环境搭建指导书6、系统操作指导书三、可测试性设计需求可测试性主要是指被测实体具有如下特征：可控制性、可分解性、稳定性、易理解性、可观察性，该特征的主要要表现是设立观察点、控制点、观察装置。需要注意的是可测性设计时必须要保证不能对软件系统的任何功能有影响，不能产生附加的活动或者附加的测试。1、可控制性设计需求1）全局变量的可控制性设计需求在外界使用适当的手段能够直接或间接控制该变量，包括获取、修改变量值等。可以将全局类型的变量进行分类并封装到一个个接口中操作。2）接口的可控制性设计需求各接口在外界使用适当的手段能够直接调用对该接口进行操作，这里所谓的适当的手段主要包括使用测试工具和增加额外代码。对于向外提供的接口的接洽处能够人为的对接，比如构造测试环境模拟接口对接，这里所指的开放接口主要是指相对于被测系统，即为被测系统外提供的接口。接口接洽处人为对接时各接口所要求的条件和所需的参数人为的能够轻易达到和提供。3）模块的可控制性设计需求对于每个相对独立的模块设计好所需要的驱动和桩都能单独设计用例进行测试对应的功能，在测试运行期间模块异常时能够将其隔离而不影响测试。4）业务流程的可控制性设计需求在测试环境满足的情况下能够控制任一单独业务流程，各业务流程具有流通性。5）场景的可测性设计需求将一场景所涉及到的业务和接口整合到一个统一的接口使其能够单独操作该场景。2、可分解性设计需求1）业务流程的可分解性设计需求对于复杂的业务流程需合理设定分解点，在测试时能够对其进行分解。2）场景的可测性设计需求对于复杂的场景需合理设定分解点，在测试时能够对其进行分解。3、稳定性设计需求测试模块发布合理，不能在后期追加的模块为前期所测模块引入新的不必要的测试活动。4、易理解性设计需求1）设计文档的易理解性设计参考标准内容描述主次要分清依赖关系描述明确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、软件可测试性需求设计 Vince2、高质量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、易理解性设计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）指标要求的“完整质量”概念，而传统的仅考虑软件设计和生产费用的产品费用则被“全寿命周期费用”的概念所替代。全寿命周期费用包括软件整个生命周期中从概念形成到报废处理全过程的费用。可测试性技术的应用可以极大地提高软件的“完整质量”，降低其全寿命周期费用。一方面，在软件设计阶段，可以对软件设计原型进行虚拟测试，验证设计方案，排除可能的设计缺陷；在生产阶段，可以对软件进行全面的测试，排除软件的潜在故障，从而降低使用过程中的故障率，提高其质量和可靠性；另一方面，可测试性技术可以缩短软件研制、试验和评价的周期，降低软件的研制费用，提高软件的可用性指标，减少软件的维护和保障费用，从而降低软件的全寿命周期费用。第一代可测试设计技术：特定目标可测试性设计第一代可测试性设计技术以外部测试和特定目标可测试性设计方法为基础。特定目标可测试性设计是指：针对特定功能和结构进行可测试性预计，判断其是否符合可测试性要求，若不满足，通过改善设计方案来提高其可测试性，直至满足要求。特定目标可测试性设计主要采用外部测试方法，测试向量的输入和测试响应的输出均通过被测设备的输入/输出端口进行操作，对被测对象内部节点的控制和观测则采用以在线（in-line）测试技术。其主要缺点如下：（1） 设计同系统的具体功能和结构紧密相关，对较复杂的系统进行设计的难度大、周期长；（2） 难以实现并行测试；（3） 需要专用测试接口和测试工具，成本高；（4） 随着系统的复杂，采用监控测试方法的适用范围日益减小。目前，特定目标可测试性设计已逐渐被其他的可测试性技术所代替。尽管如此，对于复杂程度较低的而言，特定目标可测试性设计方法仍然是一种不可或缺的方法。为可测性而设计发布时间: 2007-8-28 15:13 作者: 译者:陈能技 来源: 陈能技的质量感悟字体: 小 中 大 | 上一篇 下一篇 | 打印 | 我要投稿 | 推荐标签： 软件测试摘要 本文提供若干实用的建议，帮助项目组开发出可测性更强的软件产品。 本文对可测性（Testability）的定义为可见性和可控制性。可见性是我们能观察被测软件的状态、输出、资源利用和其它影响的程度；可控制性是我们能向被测软件输入或把它设置到某个特定状态的程度。 可见性基础 可见性的基本方面是能访问代码、设计文档和更改记录。这些是对大部分可测性进行改进的前提条件。 测试人员需要知道如何阅读代码，以及如何理解设计模型所采用的语言。在测试人员能提出测试接口、错误注入钩子或其它可测性特性之前，他们需要对系统设计有基本的理解。 可测性的改进需要测试人员和开发人员都使用共同的语言。 详细的输出 很多程序都有详细输出模式，这是可测性的很好的例子，它让人可以看到软件运转的细节。Unix的Mail程序就是其中一个例子： mail -vbretpettichord.comSubject: testability exampleSample text.Cc:bretpettichord.com. Connecting to mx.io.com. via relay. 220-deliverator.io.comESMTP Sendmail 8.9.3/8.9.3; Fri, 12 Jan 2001 15:34:36 -00 220 Welcome toIlluminati Online, Fnord! EHLO eris.io.com250-deliverator.io.com Hello IDENT:wazmoeris.io.com 199.170.88.11, pleased tu250-8BITMIME250-SIZE 5000000250-DSN250-ONEX250-ETRN250-XUSR250 HELP MAIL From: SIZE=67250 . Sender ok RCPT To: 250 . Recipient ok DATA354 Enter mail, end with “.” on a line by itself .250 PAA07752 Message accepted for deliverybretpettichord.com. Sent (PAA07752Message accepted for delivery) Closing connection to mx.io.com. QUIT221 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、