测试用例

软件构造学习笔记-2

旧巷老猫 提交于 2020-03-04 20:11:04
本周课程把第六章测试的内容提前讲了一部分,主要为实验1服务,讲了有关测试的概念、作用和基本方法。 有关测试 1.好的测试:能发现错误,不冗余,具有最佳特性,复杂度适中。 2.测试种类:分为单元测试、集成测试、系统测试。 图1-测试的种类 3.测试需要有正确的态度:测试时要让程序尽快出错,因为只有发现了错误才有改正错误的机会。把错误改正后,代码质量才能得到提升。 测试用例 1.测试用例是输入+执行条件+期望结果。测试用例的开发是有其特定目的的,一般来说是测试程序某一部分的正确性或性能。 2.测试流程 : 写测试用例->组织测试用例(一般在和src同级的文件夹test中)->执行测试用例->获取状态和报告->根据报告修改并重新测试直到测试通过 测试优先编程/测试驱动开发(TDD) 1.在写源代码之前先写测试,尽早而经常地经常测试,而不是把测试留到最后。最后测试通常会降低效率,因为总体测试之前没有对代码的任何部分进行测试,每一处都有可能出错。 2.步骤:写规范(即指定输入和输出的关系)->写规范的测试用例->写代码->执行测试 3.规范也有可能是有漏洞的。写测试可以发现规范中的错误或者不完整,及时修正有利于程序的开发。 图2-规范的书写 使用JUnit进行自动化单元测试 1.JUnit是一个Java语言的单元测试框架。Junit 测试也是程序员测试,即所谓的白盒测试

Robot Framework变量的使用技巧

て烟熏妆下的殇ゞ 提交于 2020-03-04 15:26:15
1、变量的使用 变量可以在命令行中设置,个别变量设置使用--variable (-v)选项,变量文件的选择使用--variablefile (-V)选项。 通过命令行设置的变量是全局变量,对其所有执行的用例都有效。它们将覆盖变量表格中的同名变量或是 通过变量文件引入到测试数据中的同名变量。 设置单个变量的语法是--variable name:value, “name”是不使用${}的变量名称, “value”则是其赋予的值。 可以多次使用该选项设置多个变量。仅有标量变量可以使用该语法且只能赋值字符串。许多特殊字符在命 令行中很难表示,但可以使用转义字符转义它们,使用—escape 选项。 --variable EXAMPLE:value --variable HOST:localhost:7272 --variable USER:robot --variable ESCAPED:Qquotes_and_spacesQ --escape quot:Q --escape space:_ 在命令行中使用变量文件的基本语法是--variablefile path/to/variables.py 使用 Set Test Variable 创建的变量,可以在该测试用例范围内的任何位置有效。例如,你在一个用户关键字 中创建了变量,它将在测试用例级别有效及当前测试中的所有其他用户自定义关键字中有效

Robot Framework使用技巧之内部变量

瘦欲@ 提交于 2020-03-04 12:08:10
【转载】 1、变量的使用 变量可以在命令行中设置,个别变量设置使用--variable (-v)选项,变量文件的选择使用--variablefile (-V)选项。 通过命令行设置的变量是全局变量,对其所有执行的用例都有效。它们将覆盖变量表格中的同名变量或是 通过变量文件引入到测试数据中的同名变量。 设置单个变量的语法是--variable name:value, “name”是不使用${}的变量名称, “value”则是其赋予的值。 可以多次使用该选项设置多个变量。仅有标量变量可以使用该语法且只能赋值字符串。许多特殊字符在命 令行中很难表示,但可以使用转义字符转义它们,使用—escape 选项。 --variable EXAMPLE:value --variable HOST:localhost:7272 --variable USER:robot --variable ESCAPED:Qquotes_and_spacesQ --escape quot:Q --escape space:_ 在命令行中使用变量文件的基本语法是--variablefile path/to/variables.py 使用 Set Test Variable 创建的变量,可以在该测试用例范围内的任何位置有效。例如,你在一个用户关键字 中创建了变量

Robot Framework使用技巧

亡梦爱人 提交于 2020-03-04 12:05:49
1、变量的使用 变量可以在命令行中设置,个别变量设置使用--variable (-v)选项,变量文件的选择使用--variablefile (-V)选项。 通过命令行设置的变量是全局变量,对其所有执行的用例都有效。它们将覆盖变量表格中的同名变量或是 通过变量文件引入到测试数据中的同名变量。 设置单个变量的语法是--variable name:value, “name”是不使用${}的变量名称, “value”则是其赋予的值。 可以多次使用该选项设置多个变量。仅有标量变量可以使用该语法且只能赋值字符串。许多特殊字符在命 令行中很难表示,但可以使用转义字符转义它们,使用—escape 选项。 --variable EXAMPLE:value --variable HOST:localhost:7272 --variable USER:robot --variable ESCAPED:Qquotes_and_spacesQ --escape quot:Q --escape space:_ 在命令行中使用变量文件的基本语法是--variablefile path/to/variables.py 使用 Set Test Variable 创建的变量,可以在该测试用例范围内的任何位置有效。例如,你在一个用户关键字 中创建了变量,它将在测试用例级别有效及当前测试中的所有其他用户自定义关键字中有效

时序扩展的UML状态图的测试用例生成研究

别来无恙 提交于 2020-03-04 08:24:26
一、基本信息 标题:时序扩展的UML状态图的测试用例生成研究 时间:2014 出版源:西南大学 领域分类:时序扩展;UML状态图;测试用例;需求规格说明;模型 二、研究背景 问题定义:时序扩展的UML状态图的测试用例生成研究 难点:了解透彻相关的理论基础;知晓充分性准则、UML状态图的时序扩展; 相关工作:学习软件测试基础理论,了解UML及其建模技术;看懂UML状态图; 三、创新方法 1.理论基础和建模技术相结合,发挥了充分性准则的作用; 四、实验 实验1:相关理论基础 要探究的问题:软件测试基础理论;基于模型的测试用例生成简介;UML状态图。 结论:作为检测和控制软件质量的重要手段,软件测试伴随着软件从设计到完成开发的整个生命周期。一个科学的合理的软件开发过程,软件测试与软件的设计和幵发是同步进行的。 模型可以理解为对要处理的系统或者问题,在某些角度或者某些特定层次上进行 的抽象化的描述,使其更加简单,方便人们理解其本质。采用合理的手段对软件进行建模 ,可以使软件的开发者更好地把握 软件的开发需求。将模型的思想应用与测试用例生成过程中, 就是将软件测试的活动进行模型的抽象化。 状态图是一种可以对系统动态行为建模的图形,用于描述系统类对象的生命周期中所有的状态 ,以及当特定事件发生时所引起的类对象状态的转移,可反映系统根据不同事件的发生导致类实体发生状态转移的状况

1.3 测试用例管理工具

纵然是瞬间 提交于 2020-03-04 03:05:46
1. word,excel:总体来说excel比word效果更好,看起来条理清晰,根据测试进度做标记也比较方便。缺点是不容易维护,要做好了比较花时间,特别是遇到业务性很强的复杂系统或者遇到多人协作的时候。 2. xmind、freeMind等:思维导图也可以写用例,可以用来结构化管理思维发散,头绪繁多的问题。一般只列出检查的要点和测试过程中需要注意的地方,具体的操作步骤和测试数据不需要写出来。比较适合做探索性测试。缺点跟excel差不多,多人协作方面是短板。不过最近出了在线编辑xmind的工具,一定程度上能解决这个问题。 3. viso等:啥?viso也可以写用例?当然了,只要能够表达出自己的测试思路,能够覆盖足够的测试点和测试场景,用什么只是工具选择的问题。用viso等画图工具主要侧重与系统流程方面,需要列出系统执行流程以及关键节点(比如判定条件等),测试的时候根据图做测试。顺便说一句,黑盒测试也可以使用路径覆盖、判定条件覆盖等测试方法了。 4.IBM clear quest: 缺陷及变更管理工具。它对软件缺陷或功能特性等任务记录提供跟踪管理。提供了查询定制和多种图表报表。每次查询都可以定制,以实现不同管理流程的要求。 5.TestPad:这个工具的座右铭是“花更多时间测试”。这个工具的主要概念是——checklists。在你的测试计划可以有一系列的checklists(测试)

测试笔记:测试基础

纵然是瞬间 提交于 2020-03-04 00:05:24
windows基础 软件定义 计算机=硬件加软件 软件=程序(program)+文档(document) 软件测试的对象:程序和文档都要测试 软件开发阶段划分 阶段一:需求分析阶段(由需求分析人员完成;产出物:《需求规格说明书》) 阶段二:设计阶段(由系统架构师/分析师完成;产出物:《概要设计说明书》和《详细设计说明书》) 阶段三:编码阶段(由开发人员完成/程序员完成;产出物:程序/代码) 不同的开发阶段引入的bug比例如何? 需求分析阶段引入的bug最多(大概占bug总数的55%左右) 其次是设计阶段(大概占缺陷总数的25%左右) 最少的是编码阶段(大概占缺陷总数的15%左右) 还有5%左右的缺陷是由系统兼容性或者配置原因造成的。 需求分析阶段引入的bug最多,其次是设计阶段,引入bug阶段最少的是编码阶段 因此:1)在测试中不能只测程序,文档也必须测 2)测试工作应尽早介入,并且贯穿整个开发周期始终(尽早测试原则,不断测试原则) 什么是软件缺陷 1.软件的缺陷–defect,bug 2.软件缺陷的定义:1)需求要求的功能没有实现 2)实现了需求没有的功能(画蛇添足) 3)软件出现了指明不应出现的错误 4)需求虽未明确指明,但是应该实现的功能没有实现 eg:法规; 说明:需求不是完美的,有可能有遗漏,但是测试人员应该专业,发现bug就要提交,即使需求中没有提及 5)软件不易使用

华为测试一面+二面颤抖面经

China☆狼群 提交于 2020-03-03 23:43:09
1.自我介绍 2.介绍下你实习主要负责的项目情况?你是如何测试的? 3.如果某个查询结果为空,如何排查问题? 3.bug如何跟踪? 4.web测试会不会关注页面响应?举例? 5.如何理解测试? 6.测试流程? 7.有没有写过测试设计?用例? 8.测试设计方法有哪些? 9.用excel写个登陆功能的用例? 10.说下你写的sql注入要怎么做?想测什么? 1.自我介绍 2.实习的项目介绍,有哪些模块? 3.熟悉的语言是?写个代码:有效ip 4.了解ipv6的ip格式吗? 5.聊聊做的笔试题吧? 6.说下osi七层模型?数据链路层做了什么? 7.知道二三层传输吗? 8.说下tcp三次握手 9.网络编程socket知道吗? 10.sql语句的执行顺序? 11.聊下对测试的理解? 12.有没有bug没测出来被用户提出来的? 13.有没有接触到性能和安全方面的测试? 14.医院真实数据你们拿不到,那么像比较大的患者数据你们如何进行测试呢? 15.说下用例设计思路:atm机 16.用例情况很多,组合很多时怎么处理?如何保证最少的用例覆盖最多的测试点? 17.因果图和正交法具体怎么使用? 18.谈谈你对自动化测试的理解? 来源: CSDN 作者: Apollo- 链接: https://blog.csdn.net/qq_39091292/article/details/104631277

软件测试的基本知识点

烈酒焚心 提交于 2020-03-03 05:33:02
软件测试的基本知识点 软件的分类 C/S与B/S架构 软件测试的定义 软件测试的目的 软件测试的分类 软件生命周期 生命周期模型 1.瀑布型生命周期模型 2.V模型 3.敏捷开发模型 软件测试的基本流程 测试设计用例设计方法 等价类划分法 边界值分析法 场景法 错误推测法 测试用例的编写与评审 软件的分类 软件分为两大类:系统软件、应用软件。 软件测试的对象是:程序、数据、文档。(主要为程序) C/S与B/S架构 C/S :就是我们一定要安装安装一个客户端才能够使用的软件。 缺点:每次更新都要更新服务端和客户端。 B/S :只需一个浏览器就可以访问服务。 优点:只需更新服务器不需要更新浏览器,用户主动性比较高。 软件测试的定义 使用人工和自动的手段来运行或测试某个系统的过程,其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别。 软件测试的目的 1.软件测试是为了发现程序存在的代码或业务逻辑错误 2.软件测试是为了检验产品是否符合客户的需求 3.软件测试是为了提高用户的体验 软件测试的分类 按测试技术划分:白盒测试、黑盒测试、灰盒测试 对象是否运行划分:动态测试、静态测试 按不同测试手段划分:手工测试、自动化测试 按测试包含的内容划分:功能测试、界面测试、安全测试、兼容性测试、易用性测试、性能测试 其他测试:冒烟测试、回归测试、探索性测试/自由测试 冒烟测试–>主干

软件测试英语词汇

萝らか妹 提交于 2020-03-03 02:49:34
软件测试英语专业词汇 NLV:Nation Language Version 本地化版本 FVT:Functional Verification Testing 功能验证测试 TVT:Translation Verification Testing 翻译验证测试 SVT:System Verification Testing 系统验证测试 fault--故障 在软件中一个错误的表现。 feasible path--可达路径 可以通过一组输入值和条件执行到的一条路径。 feature testing--特性测试 参考功能测试(Functional Testing) FMEA--失效模型效果分析(Failure Modes and Effects Analysis) 可靠性分析中的一种方法,用于在基本组件级别上确认对系统性能有重大影响的失效 FMECA--失效模型效果关键性分析(Failure Modes and Effects Criticality Analysis) FMEA的一个扩展,它分析了失效结果的严重性。 FTA--故障树分析(Fault Tree Analysis) 引起一个不需要事件产生的条件和因素的确认和分析,通常是严重影响系统性能、经济性、安全性或其它需要特性。 functional decomposition--功能分解 参考模块分解(modular