一、功能图测试方法基于什么进行用例设计?
1. 等价类划分 常见的软件测试面试题划分等价类: 等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:有效等价类和无效等价类. 2. 边界值分析法 边界值分析方法是对等价类划分方法的补充。测试工作经验告诉我,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例,可以查出更多的错误. 使用边界值分析方法设计测试用例,首先应确定边界情况.通常输入和输出等价类的边界,就是应着重测试的边界情况.应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据. 3. 错误推测法 基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法. 错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例. 例如, 在单元测试时曾列出的许多在模块中常见的错误. 以前产品测试中曾经发现的错误等, 这些就是经验的总结。还有, 输入数据和输出数据为0的情况。输入表格为空格或输入表格只有一行. 这些都是容易发生错误的情况。可选择这些情况下的例子作为测试用例. 4. 因果图方法 前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条件之间的联系, 相互组合等. 考虑输入条件之间的相互组合,可能会产生一些新的情况. 但要检查输入条件的组合不是一件容易的事情, 即使把所有输入条件划分成等价类,他们之间的组合情况也相当多. 因此必须考虑采用一种适合于描述对于多种条件的组合,相应产生多个动作的形式来考虑设计测试用例. 这就需要利用因果图(逻辑模型). 因果图方法最终生成的就是判定表. 它适合于检查程序输入条件的各种组合情况. 5. 正交表分析法 有时候,可能因为大量的参数的组合而引起测试用例数量上的激增,同时,这些测试用例并没有明显的优先级上的差距,而测试人员又无法完成这么多数量的测试,就可以通过正交表来进行缩减一些用例,从而达到尽量少的用例覆盖尽量大的范围的可能性。 6. 场景分析方法 指根据用户场景来模拟用户的操作步骤,这个比较类似因果图,但是可能执行的深度和可行性更好。 白盒测试用例设计的关键是以较少的用例覆盖尽可能多的内部程序逻辑结果 黑盒法用例设计的关键同样也是以较少的用例覆盖模块输出和输入接口。不可能做到完全测试,以最少的用例在合理的时间内发现最多的问题 详细的描述一个测试活动完整的过程。1. 项目经理通过和客户的交流,完成需求文档,由开发人员和测试人员共同完成需求文档的评审,评审的内容包括:需求描述不清楚的地方和可能有明显冲突或者无法实现的功
二、如何根据需求设计测试用例?
? 从拿到需求文档不要立马开始着手写测试用例,需要仔细推敲整理需求,画出系统级、模块内流程图,并找出各种测试点,等对需求进行了头脑风暴般的整理之后,此时已对测试系统的功能很清楚了,再着手开始写测试用例。
那么编写测试用例的总体思路是什么呢?通过半年的测试用例编写经验,总结如下,如有不妥之处需改进。
1、整理分析需求文档 仔细将需求文档文档阅读一遍,记录不明白的地方及关键测试点,简单画出总体流程图。
然后再来一遍,仔细分析各个模块的功能,画出模块内流程图,找出所有功能,并列出主要测试点 2、编写用例 按照不同的业务规则可将测试用例分为四部分:场景用例、系统用例、功能用例 场景用例:按照用户的实际操作与业务逻辑设计用例,不必涉及很复杂的操作或逻辑,把用户最常用的、正常的操作流程作为一个场景设计测试用例。
系统用例:是用户场景的细化,包含正常场景、分支场景和异常场景,是两个或多个有关联的功能组合而成的场景。
功能用例:用于验证各功能点的业务规则,包括界面元素和各功能的业务规则验证。
主要针对单个功能点。
第一步:场景用例(关键字:模拟用户实际操作) 根据画出的模块内流程图,描述用户的主要业务目标,包含完整的系统级场景和模拟用户实际操作的不同场景,几个功能点的组合也算是用户场景。
第二步:系统各角色的系统用例 结合画出的模块内流程图,将系统划分多个角色,再将每个角色分解为多个任务,每个任务就是一个系统用例。
系统用例分别正常流程、异常流程,分支流程,以场景的形式描述。
第三步:功能用例 描述单点功能的逻辑规则及页面元素,分层描述逻辑规则,对逻辑规则细化可直接作为用例的操作步骤描述。
编写用例的过程中也有一些迷茫: 问题1:场景法用什么方式描述比较清楚,并且后期需求改动了易维护? 问题2:测试用例与测试数据的关系是什么呢?如何将两者区分开来? 3、报表类功能模块如何编写测试用例? 报表类的模块基本没有业务流,不适用场景法。
其实报表类模块主要验证能否依据查询条件正确查询显示数据,并保证数据的正确性。
三、软件测试中性能测试用例如何设计,求写好的用例?
好的测试用例标准:
质量属性:
l 正确性:确保测试标题描述部分的内容正确性。
l 经济性:只为确定需要的目的设计相应的测试步骤。
l 可重复性:自我一致性,即不管谁执行此用例,结果一样。
l 适应性:既能适应短期需要,又能考虑长远需要。
l 可追踪性:用例能追踪到一个具体的需求。
l 自我清理性:单个用例不会影响整个测试环境,即用例执行完了可以恢复原有的测试环境。
l 结构化和可测试性
l 含有规范的测试标题和编号。
l 含有一个确定的测试某一个特定需求的目的。
l 含有关于测试方法的描述。
l 指定条件信息-环境、数据、预置的条件测试、安全入口等。
l 含有操作步骤和预期结果。
l 陈述任何辅助证据,例如截图报告并确保这些东西妥善保存。
l 确保测试环境的干净(即用例不会影响整个环境)。
描述时使用主动语气结构。
l 操作步骤不要超过 15 步。
l 确保单个用例测试执行时用时不超过 20 分钟。
l 自动化脚本用例添加必要的注释,比如目的、输入和期望结果。
l 如果可能,建议提供可选择性的预置条件测试。
l 用例之间的先后顺序是否跟业务流程一致,即用例在业务流程中的彼此顺序关系是否合理。 配置管理:
l 采用命名和编号规范归档。
l 保存为特定的格式,文件类型。
l 用例版本是否与当前被测试软件版本一致(对应)。
l 包含用例需要的相应测试对象,如特定数据库。
l 存档阅读。
l 存档时按角色控制访问方式
l 当网络备份时存档。
l 离线归档。
这是我在优就业学习时总结的,希望对你有用
四、使用黑盒测试设计测试用例的方法有哪些?
黑盒测试用例设计方法包括等价类划分法、边界值分析法、错误推测法、因果图法、判定表驱动法、正交试验设计法、功能图法等。
五、传统软件测试和游戏测试在设计测试用例上的区别?
游戏测试在跑用例这一块与软件测试是一样的,但是在易用性测试这一块就需要有大量玩游戏的经验,需要站在玩家的角度来分析设计目的的合理性,其次在游戏中玩家的目的是变化的,软件的用户需求却是相对稳定的,所以游戏测试更需要多变通多角度的来看待问题
六、黑盒测试是根据软件的什么来设计测试用例?
黑盒测试是根据软件输入输出关系来设计测试用例的,参数是输入,实际输出与预期输出进行对比。
七、什么是测试用例和测试规程,设计一个测试用例应当从哪几方面考虑?
软件测试流程指的就是测试计划、测试设计、测试执行、测试总结这几个阶段。但如果面试中有人问你:你们公司的测试流程是什么时。你要回答:在项目启动后,从系统需求分析阶段,测试人员就介入项目着手测试需求分析,编写测试计划、设计测试方案和测试用例;然后搭建测试环境,准备测试数据;当系统通过集成测试后,测试团队首先进行版本验证测试,然后进行多轮迭代系统测试;一般经过三代迭代测试后,95%的用例通过测试,没有明显致命和严重的bug就结束系统测试;最后由测试负责人进行测试评估总结。
八、测试工程师都是怎么写测试用例的?
写测试用例是测试最基本的技能,但是如何写出条理清晰,简单明了的测试用例呢?
1、测试用例的基本要素:
功能
功能项
测试目的
前提条件
测试要点
预期结果
2、整体了解业务,进行大致分类
根据大的功能来分类,一般是根据某个功能的整个流程分类,若某个功能流程中,某个功能项内容内容很多,可单独分为一个功能,测试点尽量避免重复。
3、测试点注意操作联动影响,即操作某功能考虑当前页面联动,其他页面联动,及其他设备联动
4、考虑异常情况:断线重连、前台运行,后台运行,杀掉进程、覆盖安装……
5、考虑兼容性:机型、系统版本,屏幕大小、网络
九、测试算例是什么?
是指软件测试过程中的测试用例,相当于用来测试的方法,测试功能或者系统是否有bug
十、什么是测试用例?
测试用例(Test Case)是将软件测试的行为活动做一个科学化的组织归纳,目的是能够将软件测试的行为转化成可管理的模式;同时测试用例也是将测试具体量化的方法之一,不同类别的软件,测试用例是不同的。不同于诸如系统、工具、控制、游戏软件,管理软件的用户需求更加不同的趋势。
要使最终用户对软件感到满意,最有力的举措就是对最终用户的期望加以明确阐述,以便对这些期望进行核实并确认其有效性。测试用例反映了要核实的需求。然而,核实这些需求可能通过不同的方式并由不同的测试员来实施。例如,执行软件以便验证它的功能和性能,这项操作可能由某个测试员采用自动测试技术来实现;计算机系统的关机步骤可通过手工测试和观察来完成;不过,市场占有率和销售数据(以及产品需求),只能通过评测产品和竞争销售数据来完成。
既然可能无法(或不必负责)核实所有的需求,那么是否能为测试挑选最适合或最关键的需求则关系到项目的成败。选中要核实的需求将是对成本、风险和对该需求进行核实的必要性这三者权衡考虑的结果。
我们公司于上使用日事清来进行编辑测试用例,同时执行测试用例,并取得不错的成效。日事清是专业的企业管理软件,可自动生成工作总结,进行日程计划、团队协作。
也可以算个人,也可以算企业,以为既可以管理个人的个人日程也可以管理整个团队里面的日程。
- 相关评论
- 我要评论
-