loneba的专栏

C:\Users\Administrator.ZHANGHAO-PC>python -m robot.testdoc C:\Python27_bak\Scripts\test testdoc.html生成的文件如下：

CSDN：请您谈谈什么是敏捷测试？何勉：我们讲敏捷测试是指在敏捷开发模式下测试活动的规划、测试流程的组织、测试技术的实施，测试用例的管理以及测试人员的发展。敏捷开发模式给测试带来了挑战，也带来潜在的机遇，如何应对这些挑战并实现潜在的机遇是敏捷测试要回答的问题。我们把敏捷测试看成敏捷实施不可分割的部分，有效的敏捷测试会让敏捷实施更加顺畅、持久，并且带来对业务可见的真实价值。CSDN：敏捷

大公司做自动化测试一般都会有一个大的框架。就好比一般大公司规章制度比较全，你只要按照规章制度去做就可以了。自动化测试框架也是如此，一般测试人员只要在现有框架编写自动化测试脚本就可以了。         这样的好处，节省了时间和精力，便于复用，对测试人员的要求也就降低了。不好的地方，如果框架设计的不好，灵活性可能会差些。        自动化测试框架都包含什么内容呢？        主程

：“测试用例预演”。且慢试图在头脑中搜索你对这种方法的印象，因为这是我自创的名词（申明：如果很不幸你通过其他途径确实听到或是见过这种描述，请一定告知本人，本人会慎重考虑，至少到目前为止，我还能有把握地说这是我首先命名和以正式文档描述的一种方法）。之所以把这种算不上十分复杂的方法写下来，是因为本人在实际的工作中发现该方法确实能起到比较大的作用，而且更重要的是，那种高手过招的感觉，很希望能和更多有高手

设计好测试用例对测试执行和测试管理都大有裨益。对测试执行的好处不言而喻，拿着一个好的测试用例，即便是一个测试菜鸟做测试执行也能保证用例对应功能得到覆盖。对测试管理而言，也非常有帮助，测试用例设计架构清晰，就能保证测试计划制定、测试任务分配能够更加准确。对自动化测试实施更加有好处。如果测试用例设计不清晰，不同的人按照同样的用例设计出的自动化测试脚本差异就会比较大。       有些项目的测试用例

测试数据和测试脚本分离TC发流相关参数、

说到测试用例的设计，我想每个有过测试经历的测试工程师都会认为很简单，不就是：按需求或概要设计，得到软件功能划分图，然后据此按每个功能，采用等价类划分、临界值、因果图等方法来设计用例就行了。　　但事实上撇开测试数据的设计不谈，仅就测试项来说，我们发现，对同一个项目，有经验的测试人员，在写用例或测试时总会有更多的测试考虑点，从而发现更多的问题；而有些测试人员测试用例的撰写却只有那么三板斧，表面看好

局部变量局部变量在过程执行完毕返回时自动销毁，结束其生命周期。所以过程内定义的变量，在过程外无法访问。例如，下面例子中定义了过程add，调用过程add后，无法访问变量c，因为c是局部变量。% proc add {a b} {set c [expr $a+$b]}% add 3 47% set ccan't read "c": no such variable全局

ExpectExpect is a Tcl extension designed for scripting applications. It's similar to the scripting languages used in telecommunications packages, but much more general. By default, Expect is built o

http://insertyou.iteye.com/blog/1108146#************************************************ # Construct MAC address## @PARAMS# rawMac --- raw MAC address, integer## @RETURN# the MAC addre

TCL安装目录 D:\Tcl 的目录2016-04-03  18:24              .2016-04-03  18:24              ..2016-03-28  22:19              bin2016-03-28  22:20              demos2016-04-03  18:24           254

自定义库fun.py和RF脚本testsuite1.robot在同一路径下fun.py的内容如下# coding=utf-8def test_a_b(a,b): if a>b: flag = False print flag return flag else: flag = Tr...

1、无返回值参考：直接在Setup或Teardown配置。关键字可以传参数，想执行2个以上的关键字时，Run Keywords | [keyword1 | arg1 | arg2…] | AND | [keyword2 | arg1 | arg2…]…配置实例执行结果如下图2、有返回值参考：直接是不能取得返回值的，不过可以把 setup里这个 关键字 封装一下，在封装关键词里用...

关键字 打印字符关键字 打印字符，可变参数@{arg}，打印出可变参数的值调用调用举了2个例子，第2行入参为列表@{varlist}；第3行入参为元素值。 调用结果如下

Should Match Regexp是RF BuildIn关键字，入参为string, pattern, msg=None, values=True；前2个参数为必选，后2个参数为可选参数。实现基于Python re模块。说明（1）\是转义字符（2）匹配字符串可包含特殊字符，但在字符串中午特殊含义，只是文本意思。（3）匹配模式不是全字符匹配。若需要全字符匹配，在匹配模

Many keywords, such as Evaluate, Run Keyword If and Should Be True, accept an expression that is evaluated in Python. These expressions are evaluated using Python's eval function so that all Python bu

转自：http://blog.csdn.net/divfor/article/details/45532887无论test或者keyword能否pass，均有Teardown收拾残局，真是个好东西。只是当前的设计有些尴尬：只能写一个keyword，只能执行预先写好的。实际情况中往往需要在Teardown执行多个关键字，且不期望是预先静态写成而是根据测试用例的中间执行结果而定（比如login

Windows PowerShell版权所有 (C) 2009 Microsoft Corporation。保留所有权利。PS C:\Users\Administrator.ZHANGHAO-PC> D:PS D:\> pythonPython 2.7.12 (v2.7.12:d33e0cf91556, Jun 27 2016, 15:24:40) [MSC v.1500

Windows PowerShell版权所有 (C) 2009 Microsoft Corporation。保留所有权利。PS D:\> pythonPython 2.7.12 (v2.7.12:d33e0cf91556, Jun 27 2016, 15:24:40) [MSC v.1500 64 bit (AMD64)] on win32Type "help", "cop

错误分析1、第一次调用失败是设置路径不对，我在本地创建的文件夹为service（路径D:\Tcl\lib\service\stax），staxgs上介绍的安装文件夹是services，就差1个s导致找不到，低级失误！后续一定要仔细核对。Microsoft Windows [版本 6.1.7601]版权所有 (c) 2009 Microsoft Corporation。保留所有权利。

前言： 使用脚本语言来设计自动化测试开发框架，是很多大型ＩＴ企业在进行自动化测试中所采用的方法，一个好的自动化测试框架，可以大幅度提高测试人员自动化脚本开发的效率，可以提高自动化脚本开发的并行性和可靠性。自动化测试框架设计的好与坏，直接关系到整个公司的测试水平，也关系到公司产品的发布周期和发布质量。那么在设计一个自动化测试框架的时候，会面临哪些问题？对这些问题，有什么解决方法，每一种解决方

做好软件测试自动化，首先要有好的软件测试用例，这是自动测试开发的依据。现在大的公司一般都有一个自动化测框架，具体测试用例的自动化脚本都是在这个框架基础之上去写。这样就降低了对普通测试人员的代码水平要求，也更容易在测试团队之间开展自动化测试。自动化测试框架 测试用例导入、测试结果导出、GUI界面管理。测试脚本的复用 面向对象技术（抽象成类，继承，多态性）、函数（要对被测对象做下抽象，把一些常

Being a systems administrator today isn’t easy. However, the open source community continues to makes it easier. Take, for example, Tcl. Tcl is an open source scripting interface included in the Cisco

做测试不学习自动化测试的话，感觉职业前景堪忧。特别只是做些产品的系统测试，随着测试时间的增长，相比新人对产品的业务知识理解深入些，对产品的应用及综合分析能力增强了些。 但是随之再往技术上发展，感觉瓶颈很大。      开始学习自动化测试知识。刚开始感觉自动化只是学习一些脚本语言。了解了一些之后，不是这么简单。大公司的自动化一般都是有一个大的平台，平台的代码相对边更新小些。还包括具体对应某个测试

创建加载程序库创建库文件（TCL文件）--可以放在任何地方创建tclIndex文件(自动创建)--auto_mkindex  库文件路径 *.tcl  -->生成tclIndex文件将tclIndex文件所在目录加入全局变量auto_path中 C:\>set TCLLIBPATH="库文件所在目录" 注：库文件所在路径 --区分大小写 创建程序包创建程序库文件pa

When to stop testing 的5个基础标准：（Lee Copeland "A Practitioner's Guide to Software Test Design"）1。 是否达到原先定义的覆盖标准。        比如原先定义测试95％的功能条目，测试100％的需求条目，只对接口类做集成测试等等。达到标准了就停。2。 所发现的缺陷 （bug或者功能不足等等）

TCL脚本语言基础介绍Tcl简介（一）：Tcl 语法Tcl 语法Tcl是一种很通用的脚本语言，它几乎在所有的平台上都可以释运行，其强大的功能和简单精妙的语法会使你感到由衷的喜悦，这片文章对 Tcl有很好的描述和说明。如果你看起来很吃力，那是因为 Tcl与一般的语言有一些不同之处，刚开始可能有一些不理解，但很快就会掌握的。请坚持一下,我能坚持写完，你至少也应该坚持读一遍吧

为什么我们招不到合适的测试人员？为什么测试人员在面试的时候总是失败？具体原因如下：70%：能力与经验不符！比如：6年测试经验的简历，实际能力只有2年；或者说两年的测试经验重复了六年！80%：基础技术不扎实！包括操作系统原理、数据库原理、软件架构、网络、基础的编程知识等都停留在学校的概念上。100%：测试设计理论不好或没有！50%：学习意愿不强、主动性不强！50%：Test Sense（

今天看到一篇关于华为测试团队的培养模式的文章， 感觉还不错，所以就copy过来了： 软件设计能力：测试并非劣于研发，包括：架构、设计、对需求理解、甚至在商务的层面，测试软件设计思维能帮助一个产品少走弯路。 原理分析提升：测试不仅仅只是发现缺陷，包括：定位缺陷、给研发指导意见等，提升整体团队的技术能力。 测试思维模式：通过根因分析反

Tcl简介（二）：Tcl 内建命令Tcl 内建命令Built-in commands 内建的命令Tcl提供了下面描述的内建函数。... 表示参数不定append varName value append varName value value value ... 将那一大堆value附加到varName后面。如果变量不存在，会新建一个。例子：set i "aaa

做测试，特别是做通信产品的系统测试，重复劳动比较多，很容易产生倦怠。特别是这个产品成熟后，偶尔增加些新功能，所学知识有限。测试一段时间后，主要是对一些通信、网络相关协议有了一定了解，有些还谈不上深入。如果好学可以学习下相关协议、标准，能够深入理解下。另一方面，对系统原理的理解，但是这方面的学习，最多只能深入到功能模块，再往下就要设计代码，学习时间和能力很难得到保证。几年测试，测试过程中真正

upvar  --引用；用于函数传参array    set    arrayName   list      设置数组arrayName的元素的值。 list 的形式和array   get的返回值的list形式一样。如果arrayName不存在，那么生成arrayName。array   names    arrayName   ?pattern?     这个命令返回数组arra

自动化的最终目的是 一系列计划的测试 对应一系列测试需求 测试的核心不是测试脚本，而是测试数据。着就是为什么有如此多的宣传，数据驱动自动化测试作为自动化实现框架。前提是数据应该驱动测试，且使用测试应用程序的特点。测试脚本只是一个工具。只有在测试数据设计完好的前提下，自动化测试才能高效。    自动化测试框架的目的是减少测试脚本的维护成本。传统的录制/回放（capture/pla

(1)空字符也算任何字符，也就是说一个点可以表示有一个字符，也可以表示没有字符% regexp . ""0% regexp . " "1% regexp . a1% regexp . @1% regexp . #1% regexp . 11% regexp {(a|b)+} "aaa" match1% set matchaaa

TCL解释器对（1）双引号（" "）中的各种分隔符不作处理，但是对于换行符（\n）及$和[ ]两种置换符会照常处理。                       （2）花括号（{ }）对各种特殊字符都不会做特殊处理，跟普通字符一样处理。实例（1）换行符% set x "\na\nb"ab% set x {\na\nb}\na\nb（2）$符% set y "

负载测试 负载测试是通过逐步增加系统负载，测试系统性能的变化，并最终确定在满足性能指标的情况下，系统所能承受的最大负载量的测试。压力测试压力测试是通过逐步增加系统负载，测试系统性能的变化，并最终确定在什么负载条件下系统性能处于失效状态，并依此来获得系统能提供的最大服务级别的测试。通俗地讲，压力测试是为了发现在什么条件下系统的性能会变得不可接受。压力测试是一种特定类型的负载测试。例如

把Tcl库代码放入包(package)中是一个复杂的过程。Tcl 8.x名字空间(namespace)令人困惑。把这两个东西放一起，你很可能搬起石头砸自己的脚。更糟的是，未来使用这些包的用户比包的作者更容易“中枪”。       标准的Tcl发布有很多的文档介绍namespace和package命令如何工作，但是很少有关于如何干净、有效的使用名字空间和包的介绍资料。在网上搜索，也未找到任何怎么

#a 的3、4之间有3个空格% set a "1 a 3   4 5aaa xx11 22 3"1 a 3   4 5aaa xx11 22 3#把a用空格分开% split $a1 a 3 {} {} 4 5 aaa xx11 22 3% set num [lindex [split $a] 2]3% set num [lindex [split $a]

% set text "Some arbitrary text which might include \$ or {"Some arbitrary text which might include $ or {% regexp -inline -all -- {\S+} $textSome arbitrary text which might include {$} or \{%

做了3年系统测试，有点找不到方向。相比入门时，现在对系统的内部构造和功能原理有了一定的理解。但是由于不懂代码，无法进行更深层次的学习。从最初的照着测试用例进行简单的测试执行，对测试功能点有了更深的理解，对这些功能的实际应用有了一定的认知。熟悉了一些测试工具的使用。       单纯想往技术上发展的话，只能从对系统涉及协议、标准的更深层次的学习入手了。而公司在测试设计这块做的不太好，许多用例都是