电子文档交易市场
安卓APP | ios版本
电子文档交易市场
安卓APP | ios版本
换一换
首页 金锄头文库 > 资源分类 > DOCX文档下载
分享到微信 分享到微博 分享到QQ空间

软件功能测试设计指导

  • 资源ID:189764292       资源大小:33.04KB        全文页数:10页
  • 资源格式: DOCX        下载积分:10金贝
快捷下载 游客一键下载
账号登录下载
微信登录下载
三方登录下载: 微信开放平台登录   支付宝登录   QQ登录  
二维码
微信扫一扫登录
下载资源需要10金贝
邮箱/手机:
温馨提示:
快捷下载时,用户名和密码都是您填写的邮箱或者手机号,方便查询和重复下载(系统自动生成)。
如填写123,账号就是123,密码也是123。
支付方式: 支付宝    微信支付   
验证码:   换一换

 
账号:
密码:
验证码:   换一换
  忘记密码?
    
1、金锄头文库是“C2C”交易模式,即卖家上传的文档直接由买家下载,本站只是中间服务平台,本站所有文档下载所得的收益全部归上传人(卖家)所有,作为网络服务商,若您的权利被侵害请及时联系右侧客服;
2、如你看到网页展示的文档有jinchutou.com水印,是因预览和防盗链等技术需要对部份页面进行转换压缩成图而已,我们并不对上传的文档进行任何编辑或修改,文档下载后都不会有jinchutou.com水印标识,下载后原文更清晰;
3、所有的PPT和DOC文档都被视为“模板”,允许上传人保留章节、目录结构的情况下删减部份的内容;下载前须认真查看,确认无误后再购买;
4、文档大部份都是可以预览的,金锄头文库作为内容存储提供商,无法对各卖家所售文档的真实性、完整性、准确性以及专业性等问题提供审核和保证,请慎重购买;
5、文档的总页数、文档格式和文档大小以系统显示为准(内容中显示的页数不一定正确),网站客服只以系统显示的页数、文件格式、文档大小作为仲裁依据;
6、如果您还有什么不清楚的或需要我们协助,可以点击右侧栏的客服。
下载须知 | 常见问题汇总

软件功能测试设计指导

功能测试设计指导书 目 录功能测试设计指导书1第1章前言11.1概述11.2声明1第2章设计指导12.1三个故事12.1.1客户故事22.1.2测试故事22.1.3质量故事22.2设计指导32.2.1业务流程分析32.2.2测试因子分析32.2.3故障场景分析52.2.4总结7i 第1章 前言1.1 概述本指导书主要提供功能性测试相关的指导,基于用户(这里的用户包含外部最终用户以及系统用户,所有使用该特性的“人”都是用户,具体表现为人,程序,机器等)使用场景的角度给出功能性测试的要求。功能性测试不仅仅是客户业务功能(对客户直接可见的外部业务流程),还包含内部业务流程(对客户不直接可见,比如缓存刷盘,数据扫描,数据重建,数据同步等),以及操作维护方面的功能(安装、部署、配置、升级等)。非功能性的测试不包含在此文,请参考相关的指导。1.2 声明古人云:授人以鱼不如授人以渔,本指导书是“渔”非“鱼”,因此本文提供通用的功能性测试分析设计方法,该方法基于业界通用的比如等价类、边界值等工程方法基础之上的,提供了全面的完善的功能测试覆盖。第2章 设计指导2.1 三个故事作为一名测试人员,要将测试的活动以故事的形式表示现出来,能讲好如下的三个故事,分别是客户故事,测试故事和质量故事2.1.1 客户故事该特性客户用来运行什么业务?该特性给客户提供的关键业务能力是什么?客户在业务使用过程中会进行哪些业务操作以及对系统进行哪些维护性的操作?以上内容都是测试的关键输入,给客户提供的关键业务能力是测试通过的标准之一,客户的业务操作以及客户运行的业务就是测试的测试场景。客户故事是测试的入口与验收标准2.1.2 测试故事有了客户故事作为入口,那么下面就是如何开展测试的测试故事了,就是如何开展测试活动去验证客户故事呢,这就是知己知彼,所谓知彼就是业务流程分析;所谓知己就是测试技术方法分析,测试环境分析,测试工具分析等方面,最终形成测试用例。最核心的还是业务流程分析,因为这是客户业务操作在系统内部的具体实现,仅仅根据客户业务操作只能进行黑盒级别的验收测试,还有很多的异常场景我们是无法进行测试的,因此我们需要打开业务流程,找到保证业务操作成功和导致业务失败的因素,这些因素就是测试因子,对这些测试因子进行组合测试才能完整覆盖客户业务流。2.1.3 质量故事客户故事定义了测试场景和测试标准,测试故事定义了测试方法,那么如何评价测试标准是否达成呢,也就是特性的质量是否能满足客户的要求呢,这就是质量评估。2.2 设计指导第一个故事,一般从开发的设计规格文档中就可以提取出来,不需要特别的指导。第三个故事是在测试执行完成后进行的,会有另外的指导书进行指导。本指导书主要是指导第二个故事(测试故事)如何讲,这是整个测试质量的核心。特别说明:下文的业务是广义的概念,泛指系统内的各个功能实现逻辑,可以是从客户层面可见的完整的,也可以是其中的一个片段,也可以是系统内部客户不可见的功能片段(例如缓存刷盘,后台数据扫描,管理数据备份,日志搜集等等等等)2.2.1 业务流程分析业务流程是测试故事的开始,是客户业务场景在系统内部的实现。系统内部进行业务处理的单元是进程/服务(用户态/内核态),因此所谓的业务流程分析就是给出每个客户业务由哪些进程/服务来进行处理的?各个进程/服务处理的先后顺序是怎样的?每个进程/服务处理的输入和输出分别是什么?是否和第三方的系统进行交互?将以上分析清楚后,建议画出每个业务的业务流程图。2.2.2 测试因子分析在业务入口处的各种参数就是测试因子,业务入口可以是UI界面、API接口(内部的、外部的)、CLI命令行、SDK等,无论哪种方式,总是有一定的入口参数的,每个入口参数就是一个测试因子,入口参数的具体取值,通过边界值、等价类等测试工程方法获取,各种因子的正交组合就成了一个测试场景。例如S3接口上传对象来分析,上传对象的入参有用户信息,桶信息,对象信息,这几个都作为测试因子,下面来分析这些测试因子的取值,1) 用户信息就是用户名称,根据等价类规则,取值为系统存在的用户和系统中不存在的用户2) 桶信息就是桶的名称,根据等价类规则,取值为系统存在的桶和系统中不存在的桶3) 对象的信息:包含对象的名称,大小,本地文件路径,对象名称取值根据等价类分为有效的对象名称和无效的对象名称;对象大小(本地文件的大小)根据等价类与边界值,取值为最小值-1,最小值,最小值+1,最大值-1,最大值,最大值+1;本地文件路径根据等价类原则取值为存在的本地文件和不存在的本地文件经过以上分析,我们得到测试因子为:用户名称(有效,无效),桶名称(有效,无效),对象名称(有效,无效),对象大小(最小值-1-无效,最小值有效,最小值+1-有效,最大值-有效,最大值-有效,最大值+1-无效),本地文件路径(有效,无效)。如何进行测试因子正交组合呢?一般来说,系统内部对于各个测试因子的处理是有先后顺序的,因此对于对于测试因子中无效的取值遍历覆盖一遍,也就是说每个因子的每个无效取值(其他因子均为有效取值,不会产生阻碍)都作为一个测试场景,每个因子的有效值进行正交,每个正交值就是一个测试场景,我们可以得到如下的测试场景:无效用户+有效桶+有效对象有效用户+无效桶+有效对象有效用户+有效桶+无效对象名有效用户+有效桶+无效对象大小有效用户+有效桶+无效本地路径有效用户1+有效桶1+有效对象大小1+有效本地文件路径1+有效对象名1有效用户2+有效桶2+有效对象大小2+有效本地文件路径2+有效对象名2 。对于测试因子有效取值的正交,需要进行去重处理,去重的主要依据是因子之间的关联性(相互包含、限制约束,因果关系等),只有具备关联性性的因子才需要完全正交,不具备相关性的因子仅需要做一次正交即可(每个取值覆盖一次即可)。比如上面的这几个因子之间是没有关联关系的,因此只要保证每个因子的所有取值都覆盖一遍即可。其实也就是说上传一个30GB大小的对象到A用户还是B用户,对于系统功能测试来说是等价的,除非A用户单独对对象大小有要求,那此时用户和对象大小这两个因子之间其实是有关联关系的。上述分析方法,适用于所有的内外部入口,把系统流程打开了,其实就得到一个一个的业务处理入口(部分的,全流程的,内部的、外部的),把每个业务入口的输入来提取测试因子,然后进行测试因子的组合就得到了完整的正常功能测试集2.2.3 故障场景分析上一节的测试因子分析与组合最终得到了功能测试的正常流程,这仅仅只保证功能可用,那么在故障的情况下,功能的表现如何呢,这是本节要分析的内容。系统内部进行业务处理的最小单元是进程/服务,因此每个业务流程都要覆盖处理该业务的进程的故障。进程故障包含异常退出(单次退出,多次反复退出),进程挂死(单次,多次),进程进入X(Z/D/T/t等)状态,系统要有相应的故障检测、隔离、恢复机制来保证业务的连续性。此处除了考虑进程本身故障之外,还要考虑进程的载体(物理服务器,虚拟机,容器等)的故障也同样会造成进程无法处理业务,因此物理服务器/虚拟机/容器整体故障也是必须要覆盖的故障。进程的运行至少需要CPU和内存,那么CPU资源和内存资源故障也会导致进程无法正常处理业务。CPU资源故障包括CPU过载,CPU不足、CPU抢占;内存资源故障包含内存过载,内存不足,内存抢占,内存泄漏,内存越界,内存碎片等,后面三个故障是代码层面需要避免的问题,作为业务处理的观察点,可以不用直接模拟。CPU抢占和内存抢占不用直接模拟,是通过业务运行的方式进行触发的。进程/服务在业务处理的过程中如果要进行文件(配置文件,日志文件、数据文件、程序文件等)的读写与传输,这就涉及到文件操作相关的故障,首先是文件本身的故障:文件/目录不存在,文件损坏(无法打开等),文件内容错误,文件/目录权限错误;其次是文件的载体带来的故障,主要表现为文件系统只读,存储空间不足,文件系统损坏、存储介质故障等。有文件操作的时候以上故障是必须要测试的进程/服务在进行业务处理的过程中一般都需要时间基准,如果对时间有一定的依赖的话,时间的变化就会影响到业务处理。时间故障主要表现为时间跳变,包含向未来跳变,向过去跳变。时间跳变是业务流程中需要覆盖的故障场景,跳变值得大小一般是秒级,分钟级,小时级,天级等大部分情况下,一个业务流的完成往往是由多个进程/服务完成的,而往往这些不同的进程/服务是部署在不同的物理服务器上的,他们之间通过网络通信来进行协作完成业务处理过程,这就涉及到网络相关故障,主要包含物理上的网络中断、网络闪断、网络单通、网络丢包、网络错包、网络延时、网络降速、网络环路等故障。还包含业务层面的响应超时,无响应,消息错误/非法等故障。这些故障是业务异常必测场景。部分情况下,业务处理过程中会进行数据库的读写,这时候需要数据库的故障对业务处理的影响。数据库类的故障包括数据库连接失败,数据库连接超时,数据读写失败,数据库读写超时,数据库读写无响应,数据库节点故障等故障场景,这有数据库访问的情况下需要覆盖以上故障。还有些系统中,业务处理的过程中会与第三方的部件进行交互,常见的第三方部件例如用户认证系统(AD/LDAP)等。此时第三方系统的故障主要是:系统故障(不可访问),返回超时,无响应,返回消息错误/非法。无论那种故障,业务流程可以失败,但是本端进程/服务不能出现异常(崩溃退出,资源占用异常,业务处理错乱等)。2.2.4 总结功能性测试设计实现三部曲:业务流程分析,测试因子分析,故障场景分析。业务流程分析是基础,测试因子分析与组合得到了正常功能测试用例集,故障场景分析得到了异常功能测试用例集。进行异常功能测试的业务流量要选择测试因子分析中的全有效因子中的任一种即可。最终形成测试用例架构如下:1) 正常流程a) 参数异常:无效测试因子取值的组合b) 正常功能:有效测试因子取值的组合2) 异常场景a) 进程故障:b) 主机故障:c) 网络故障:d) 文件故障:e) 资源故障:f) 。

注意事项

本文(软件功能测试设计指导)为本站会员(添***)主动上传,金锄头文库仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。 若此文所含内容侵犯了您的版权或隐私,请立即阅读金锄头文库的“版权提示”【网址:https://www.jinchutou.com/h-59.html】,按提示上传提交保证函及证明材料,经审查核实后我们立即给予删除!

温馨提示:如果因为网速或其他原因下载失败请重新下载,重复下载不扣分。




关于金锄头网 - 版权申诉 - 免责声明 - 诚邀英才 - 联系我们
手机版 | 川公网安备 51140202000112号 | 经营许可证(蜀ICP备13022795号)
©2008-2016 by Sichuan Goldhoe Inc. All Rights Reserved.