-
界面设计与测试规则
2007-06-07 14:30:40
界面是软件与用户交互的最直接的层，界面的好坏决定用户对软件的第一印象。而且设计良好的界面能够引导用户自己完成相应的操作，起到向导的作用。同时界面如同人的面孔，具有吸引用户的直接优势。设计合理的界面能给用户带来轻松愉悦的感受和成功的感觉，相反由于界面设计的失败，让用户有挫败感，再实用强大的功能都可能在用户的畏惧与放弃中付诸东流。目前界面的设计引起软件设计人员的重视的程度还远远不够，直到最近网页制作的兴起，才受到专家的青睐。
目前流行的界面风格有三种基本方式：多窗体、单窗体以及资源管理器风格，无论那种风格，以下规则是应该被重视的。1：易用性：
按钮名称应该易懂，用词准确，屏弃摸棱两可的字眼，要与同一界面上的其他按钮易于区分，能望文知意最好。理想的情况是用户不用查阅帮助就能知道该界面的功能并进行相关的正确操作。
易用性细则：
1):完成相同或相近功能的按钮用Frame框起来，常用按钮要支持快捷方式。
2):完成同一功能或任务的元素放在集中位置，减少鼠标移动的距离。
3):按功能将界面划分局域块，用Frame框括起来,并要有功能说明或标题。
4):界面要支持键盘自动浏览按钮功能，即按Tab键的自动切换功能。
5):界面上首先应输入的和重要信息的控件在Tab顺序中应当靠前,位置也应放在窗口上较醒目的位置。
6):同一界面上的控件数最好不要超过10个，多于10个时可以考虑使用分页界面显示。
7):分页界面要支持在页面间的快捷切换，常用组合快捷键Ctrl+Tab
8):默认按钮要支持Enter及选操作，即按Enter后自动执行默认按钮对应操作。
9):可写控件检测到非法输入后应给出说明并能自动获得焦点。
10):Tab键的顺序与控件排列顺序要一致，目前流行总体从上到下，同时行间从左到右的方式。
11):复选框和选项框按选择几率的高底而先后排列。
12):复选框和选项框要有默认选项，并支持Tab选择。
13):选项数相同时多用选项框而不用下拉列表框。
14):界面空间较小时使用下拉框而不用选项框。
15):选项数较少时使用选项框，相反使用下拉列表框。
16):专业性强的软件要使用相关的专业术语，通用性界面则提倡使用通用性词眼。
2： 规范性：
通常界面设计都按Windows界面的规范来设计，即包含“菜单条、工具栏、工具厢、状态栏、滚动条、右键快捷菜单”的标准格式，可以说：界面遵循规范化的程度越高，则易用性相应的就越好。小型软件一般不提供工具箱。
规范性细则：
1):常用菜单要有命令快捷方式。
2):完成相同或相近功能的菜单用横线隔开放在同一位置。
3):菜单前的图标能直观的代表要完成的操作。
4):菜单深度一般要求最多控制在三层以内。
5):工具栏要求可以根据用户的要求自己选择定制。
6):相同或相近功能的工具栏放在一起。
7):工具栏中的每一个按钮要有及时提示信息。
8):一条工具栏的长度最长不能超出屏幕宽度。
9):工具栏的图标能直观的代表要完成的操作。
10):系统常用的工具栏设置默认放置位置。
11):工具栏太多时可以考虑使用工具箱。
12):工具箱要具有可增减性，由用户自己根据需求定制。
13):工具箱的默认总宽度不要超过屏幕宽度的1/5。
14):状态条要能显示用户切实需要的信息，常用的有：
目前的操作、系统状态、用户位置、用户信息、提示信息、错误信息等，
如果某一操作需要的时间较长，还应该显示进度条和进程提示。
15):滚动条的长度要根据显示信息的长度或宽度能及时变换，以利于用户了解显示信息的位置和百分比。
16):状态条的高度以放置5号字为宜，滚动条的宽度比状态条的略窄。
17):菜单和工具栏要有清楚的界限;菜单要求凸出显示，这样在移走工具栏时仍有立体感。
18):菜单和状态条中通常使用5号字体。工具栏一般比菜单要宽，但不要宽的太多，否则看起来很不协调。
19):右键快捷菜单采用与菜单相同的准则。
3：帮助设施：
系统应该提供详尽而可靠的帮助文档，在用户使用产生迷惑时可以自己寻求解决方法。
帮助设施细则：
1):帮助文档中的性能介绍与说明要与系统性能配套一致。(我们的系统帮助文档都是系统的祖先时期的说明，让人困惑)。
2):打包新系统时，对作了修改的地方在帮助文档中要做相应的修改。
3):操作时要提供及时调用系统帮助的功能。常用F1。
4):在界面上调用帮助时应该能够及时定位到与该操作相对的帮助位置。也就是说帮助要有即时针对性。
5):最好提供目前流行的联机帮助格式或HTML帮助格式。
6):用户可以用关键词在帮助索引中搜索所要的帮助，当然也应该提供帮助主题词。
7):如果没有提供书面的帮助文档的话，最好有打印帮助的功能。
8):在帮助中应该提供我们的技术支持方式，一旦用户难以自己解决可以方便的寻求新的帮助方式。
4：合理性：
屏幕对角线相交的位置是用户直视的地方，正上方四分之一处为易吸引用户注意力的位置，在放置窗体时要注意利用这两个位置。
合理性细则：
1):父窗体或主窗体的中心位置应该在对角线焦点附近。
2):子窗体位置应该在主窗体的左上角或正中。
3):多个子窗体弹出时应该依次向右下方偏移，以显示窗体出标题为宜。
4):重要的命令按钮与使用较频繁的按钮要放在界面上注目的位置。(默认界面应该只显示目标用户最常使用的功能，至于不常用到的高级功能，可以“隐藏”起来，比如说，放到菜单里，不要都做成按钮摆到界面上。果真需要需要这些高级功能的话，用户自然会到菜单里去找的。 )
5):错误使用容易引起界面退出或关闭的按钮不应该放在易点位置。横排开头或最后与竖排最后为易点位置。
6):与正在进行的操作无关的按钮应该加以屏蔽(Windows中用灰色显示，没法使用该按钮)。
7):对可能造成数据无法恢复的操作必须提供确认信息,给用户放弃选择的机会。
8):非法的输入或操作应有足够的提示说明。
9):对运行过程中出现问题而引起错误的地方要有提示，让用户明白错误出处，避免形成无限期的等待。
10):提示、警告、或错误说明应该清楚、明了、恰当。
5：美观与协调性：
界面应该大小适合美学观点，感觉协调舒适，能在有效的范围内吸引用户的注意力。美观与协调性细则：
1):长宽接近黄金点比例，切忌长宽比例失调、或宽度超过长度。
2):布局要合理,不宜过于密集，也不能过于空旷，合理的利用空间。
3):按钮大小基本相近，忌用太长的名称，免得占用过多的界面位置。
4):按钮的大小要与界面的大小和空间要协调。
5):避免空旷的界面上放置很大的按钮。
6):放置完控件后界面不应有很大的空缺位置。
7):字体的大小要与界面的大小比例协调, 通常使用的字体中宋体9-12较为美观，很少使用超过12号的字体。
8):前景与背景色搭配合理协调，反差不宜太大，最好少用深色，如大红、大绿等。蓝色文字以白色背景容易识别，而在红色背景则不易分辨，原因是红色和蓝色没有足够反差，而蓝色和白色反差很大。除非特殊场合，杜绝使用对比强烈，让人产生憎恶感的颜色。常用色考虑使用Windows界面色调。
9):整个界面色彩尽量少的使用类别不同的颜色。统一色调，针对软件类型以及用户工作环境选择恰当色调:如：安全软件，根据工业标准，可以选取黄色，绿色体现环保，蓝色表现时尚、紫色表现浪漫等等，淡色可以使人舒适，暗色做背景使人不觉得累等
10):如果使用其他颜色，主色要柔和，具有亲和力与磁力，坚决杜绝刺目的颜色。
11):大型系统常用的主色有"#E1E1E1"、"#EFEFEF"、"#C0C0C0"等。
12):界面风格要保持一致，字的大小、颜色、字体要相同，除非是需要艺术处理或有特殊要求的地方。
13):如果窗体支持最小化和最大化或放大时，窗体上的控件也要随着窗体而缩放；切忌只放大窗体而忽略控件的缩放。
14):对于含有按钮的界面一般不应该支持缩放，即右上角只有关闭功能。
15):通常父窗体支持缩放时，子窗体没有必要缩放。
16):如果能给用户提供自定义界面风格则更好，由用户自己选择颜色、字体等。
6：菜单位置：
菜单是界面上最重要的元素，菜单位置按照按功能来组织。
菜单位置细则：
1):菜单通常采用“常用--主要--次要--工具--帮助”的位置排列，符合流行的Windows风格。
2):常用的有“文件”、“编辑”，“查看”等，几乎每个系统都有这些选项，当然要根据不同的系统有所取舍。
3):下拉菜单要根据菜单选项的含义进行分组，并切按照一定的规则进行排列，用横线隔开。
4):一组菜单的使用有先后要求或有向导作用时，应该按先后次序排列。
5):没有顺序要求的菜单项按使用频率和重要性排列，常用的放在开头， 不常用的靠后放置；重要的放在开头，次要的放在后边。
6):如果菜单选项较多，应该采用加长菜单的长度而减少深度的原则排列。
7):菜单深度一般要求最多控制在三层以内。
8):对常用的菜单要有快捷命令方式，组合原则见8。
9):对与进行的操作无关的菜单要用屏蔽的方式加以处理，如果采用动态加载方式����即只有需要的菜单才显示����最好。
10):菜单前的图标不宜太大，与字高保持一直最好。
11):主菜单的宽度要接近，字数不应多于四个，每个菜单的字数能相同最好。
12):主菜单数目不应太多，最好为单排布置。
7：独特性：
如果一味的遵循业界的界面标准，则会丧失自己的个性.在框架符合以上规范的情况下，设计具有自己独特风格的界面尤为重要。尤其在商业软件流通中有着很好的迁移默化的广告效用。独特性细则：
1):安装界面上应有单位介绍或产品介绍，并有自己的图标。
2):主界面，最好是大多数界面上要有公司图标。
3):登录界面上要有本产品的标志，同时包含公司图标。
4):帮助菜单的“关于”中应有版权和产品信息。
5):公司的系列产品要保持一直的界面风格，如背景色、字体、菜单排列方式、图标、安装过程、按钮用语等应该大体一致。
8：快捷方式的组合
在菜单及按钮中使用快捷键可以让喜欢使用键盘的用户操作得更快一些。在西文Windows及其应用软件中快捷键的使用大多是一致的。
菜单中：
1):面向事务的组合有:
Ctrl-D 删除
Ctrl-F 寻找
Ctrl-H 替换
Ctrl-I 插入
Ctrl-N 新建
Ctrl-S 保存
Ctrl-O 打开
2):列表:
Ctrl-R 刷新
Ctrl-G 定位
Ctrl-Tab 下一分页窗口或反序浏览同一页面控件
3):编辑:
Ctrl-A 全选
Ctrl-C 拷贝
Ctrl-V 粘贴
Ctrl-X 剪切
Ctrl-Z 撤消操作
Ctrl-Y 恢复操作
4):文件操作:
Ctrl-P 打印
Ctrl-W 关闭
5):系统菜单
Alt-A 文件
Alt-E 编辑
Alt-T 工具
Alt-W 窗口
Alt-H 帮助
6):MS Windows保留键:
Ctrl-Esc 任务列表
Ctrl-F4 关闭窗口
Alt-F4 结束当前程序
Alt-Tab 切换当前程序
Enter 缺省按钮/确认操作
Esc 取消按钮/取消操作
Shift-F1 上下文相关帮助按钮中：
可以根据系统需要而调节，以下只是常用的组合。
Alt-Y 确定(是)
Alt-C 取消
Alt-N 否
Alt-D 删除
Alt-Q 退出
Alt-A 添加
Alt-E 编辑
Alt-B 浏览
Alt-R 读
Alt-W 写
这些快捷键也可以作为开发中文应用软件的标准,但亦可使用汉语拼音的开头字母（不推荐）。
9:安全性考虑：
在界面上通过下列方式来控制出错几率，会大大减少系统因用户人为的错误引起的破坏。开发者应当尽量周全地考虑到各种可能发生的问题,使出错的可能降至最小。
如应用出现保护性错误而退出系统,这种错误最容易使用户对软件失去信心。因为这意味着用户要中断思路,并费时费力地重新登录,而且已进行的操作也会因没有存盘而全部丢失。
安全性细则：
1):最重要的是排除可能会使应用非正常中止的错误。
2):应当注意尽可能避免用户无意录入无效的数据。
3):采用相关控件限制用户输入值的种类。
4):当用户作出选择的可能性只有两个时,可以采用单选框。
5):当选择的可能再多一些时,可以采用复选框,每一种选择都是有效的,用户不可能输入任何一种无效的选择。
6):当选项特别多时，可以采用列表框，下拉式列表框。
7):在一个应用系统中,开发者应当避免用户作出未经授权或没有意义的操作。
8):对可能引起致命错误或系统出错的输入字符或动作要加限制或屏蔽。
9):对可能发生严重后果的操作要有补救措施。通过补救措施用户可以回到原来的正确状态。
10):对一些特殊符号的输入、与系统使用的符号相冲突的字符等进行判断并阻止用户输入该字符。
11):对错误操作最好支持可逆性处理，如取消系列操作。
12):在输入有效性字符之前应该阻止用户进行只有输入之后才可进行的操作。
13):对可能造成等待时间较长的操作应该提供取消功能。
14):特殊字符常有；;’”><,｀‘：“［”｛、\|｝］+=)-(_*&&^%$#@!,.。?/还有空格。（此外，还要注意全角和半角符号的区别）
15):与系统采用的保留字符冲突的要加以限制。
16):在读入用户所输入的信息时，根据需要选择是否去掉前后空格。
17):有些读入数据库的字段不支持中间有空格，但用户切实需要输入中间空格，这时要在程序中加以处理。
10:多窗口的应用与系统资源：
设计良好的软件不仅要有完备的功能，而且要尽可能的占用最底限度的资源。
应用细则：
1):在多窗口系统中，有些界面要求必须保持在最顶层，避免用户在打开多个窗口时，不停的切换甚至最小化其他窗口来显示该窗口。
2):显示多个窗口时，窗口的名称是否被适当地表示？
3):活动窗口是否被适当地加亮？
4):如果使用多任务，是否所有的窗口被实时更新？
5):在主界面载入完毕后自动卸出内存，让出所占用的WINDOWS系统资源。
6):关闭所有窗体，系统退出后要释放所占的所有系统资源 ，除非是需要后台运行的系统。
4):尽量防止对系统的独占使用。美丽的事物常常会让人无法抗拒。这就是为什么产品出色的外观设计对于电脑、汽车、日用品、家具、食品、服装等等几乎所有商品的销售与推广，都有着举足轻重的作用的原因。
同样的道理，对于软件公司来说，软件产品就是他们的商品，而软件界面就是他们产品的外观，界面的美观与否，直接关系到了软件产品的营销成败。
我们可以清楚地看到，微软公司对软件界面设计的重视。请回想一下您在第一次见到win2000时的情景，与nt4.0相比是否惊叹他界面的美观性与易用性？而您如果使用过xp系统，则会被其令人神奇的感官概念而震惊折服！金山公司的金山词霸就是国内软件成功的例子了，从金山词霸3.0到金山词霸2001 的变化堪称经典。著名的网页动画制作软件flash从3.0到4.0，仅仅修改了图标和窗体，立即大为增色…
现今世界上成功的软件公司都非常重视软件界面的美化设计工作，因为他们深刻地知道，在激烈的市场竞争中，仅仅有强大的功能是远远不够的，不足以战胜强劲的对手。我们可以相象一下，您在挑选手机的时候，如果有两款手机，性能相同，而第一款比第二款要美观很多，那么您将选择哪一款呢？当然是美观的那一款了。试想，您的客户，也会拿您和您竞争对手的软件做这样的比较的。
现在的软件企业都知道，广告和市场推销活动对市场营销的作用是多么的重要，并不遗余力地打广告、做活动、做推广。但我们知道，这些活动的最终目的，是为了让用户购买并使用软件产品，而用户最终使用的也是您的产品，那么为什么不在软件界面的美观性上多下些工夫呢？在诸如家用电器、汽车、电脑等成熟的市场中，用非常精美的广告去推广一种功能强大却丑陋无比的产品，是一种笑话。然而，这样的笑话在软件行业里却屡见不鲜。这也是像中国足球一样，中国软件业与国外相比较存在的一个很大的差距。
作者： lwfwind
Link URL: http://www.cnblogs.com/tester2test/archive/2006/07/15/451597.html -
QTP知识点滴积累
2007-06-07 14:30:40
1. dos命令的执行
Dim oShell
Set oShell = CreateObject ("WSCript.shell")
oShell.run "cmd /K CD C:\ & Dir"
Set oShell = Nothing
2.使用可选步骤
OptionalStep.Browser("browser_name").Page("page_name").Link("link_name")默认可选步骤
默认情况下，QuickTest 将打开下列对话框的步骤视为可选：
3. 处理运行错误对话框标题栏
自动完成文件下载Internet ExplorerNetscape输入网络密码错误安全警报安全信息安全警告所需的用户名和密码
- 停止 - 停止运行会话。
如果 QuickTest 配置为在运行后显示测试结果，则会显示测试结果。 - 重试 - QuickTest 尝试再次执行该步骤。
如果该步骤成功，则运行会继续。 - 跳过 - QuickTest 跳过引发错误的步骤，然后从下一步骤继续运行。
- 调试 - QuickTest 暂停运行以便对测试或组件进行调试。
可以执行本章描述的任何调试操作。在调试之后，可以从测试或组件停止的那一步开始继续运行会话，也可以使用单步命令来控制运行会话的其余部分。 - 帮助 - 对于显示的错误消息，打开 QuickTest 故障排除帮助。在查看“帮助”主题之后，可以在错误消息框中选择另一个按钮。
- 详细信息 - 将消息框扩展为显示其他有关错误的信息。
4.
下列语句指示 QuickTest 等待打开“航班表”对话框时最多等待 20 秒。blnDone=Window("Flight Reservation").Dialog("Flights Table").Exist
counter=1
While Not blnDone
Wait (2)
blnDone=Window("Flight Reservation").Dialog("Flights Table").Exist
counter=counter+1
If counter=10 then
blnDone=True
End if
Wend
5. ExecuteFile "c:\test.vbs"
6. msgbox Environment.Value("home")
7.请教不将测试结果记录到日志的语句。
对于已知是错误的验证点，在测试报告中能否记录通过，或者根本不记录呢？Reporter.Filter = NewMode
The mode can be one of the following values:
Mode
Description0 or
rfEnableAll Default. All reported events are displayed in the Test Results.
1 or rfEnableErrorsAndWarnings Only event with a warning or fail status are displayed in the Test Results.
2 or
rfEnableErrorsOnly Only events with a fail status are displayed in the Test Results.
3 or
rfDisableAll No events are displayed in the Test Results.
8.库中不需要有对象存在也可执行：
Dim aaa,bbb
aaa="Login"
bbb="OK"
Dialog("Title:="&aaa).Activate
Dialog("Title:="&aaa).WinButton("text:="&bbb).Click
9.setting的应用举例
If Setting.Exists("Tester Name") Then
Setting.Remove ( "Tester Name")
End IfSetting.Add "Tester Name", "Mark Train"
Setting("Tester Name") ="hello"
MsgBox Setting("Tester Name")
10.qtp 关键字头＋空格（技巧）
Link URL: http://www.cnblogs.com/tester2test/archive/2006/07/20/455425.html - 停止 - 停止运行会话。
-
测试用例的有效维护
2007-06-07 14:30:40
转载软件测试和质量专栏
开发一个软件产品，会发布多个版本，伴随着测试用例（Test case）的不断维护, 使测试用例不断完善并与产品功能、特性(features)的变化保持一致，所以测试用例是和产品版本相关联的。特别是对提供软件服务的软件产品，多个版本常常共存，为客户提供服务，这时多个版本的测试用例也是并存的，所以在新建、修改、删除测试用例时要十分小心，并有相应的规则。根据产品特性和test case一致性，分下面几种情况分别处理：
1. 产品特性没变，只是根据Late Discovery Bug 或 Remedy Ticket 来完善 test case，只有这时候可以修改Test case, 也就意味着当前修改的test case，对目前和以前的版本都有效。
2. 原有产品特性发生了变化，不是new feature, 而是enhanced features（功能增强）, 这时候原有的 test case 只对先前版本（如version 1.0、2.0) 有效，而对新的版本（如 version 3.0)无效，这时绝不能修改 test case ，只能增加新的 test case，这一点很重要。原有的 test case 依然对原有版本有效（如version 1.0、2.0)。
3. 原有功能取消了，这时只要在新版本上使之对应的test case置为inactive（无效）。
4. 完全新增加的特性，大家比较清楚，增加对应的、新的测试用例。
这样，新旧版本的相同测试用例得到一致的维护，测试用例数也不会成几、十几倍的增加，可以真正保证 test case 的完整性、有效性！
Link URL: http://www.cnblogs.com/tester2test/archive/2006/07/22/457484.html -
LR内存的使用
2007-06-07 14:30:40
Operating system
Win2000 Advanced Server sp3
Windows XP sp1
WindowsNT 4 SP
Protocol
Process (MB)
Thread (MB)
Process (MB)
Thread (MB)
Process (MB)
Thread (MB)
SAPGUI Ram
26
6.2
26
6.2
26
6.2
Swap
26
6.7
26
6.7
26
6.7
C Ram
3
0.27
3
0.28
3.6
0.29
Swap
2.7
0.27
2.5
0.27
2.2
0.26
CITRIX Ram
15.4
8.8
15.4
8.8
15.4
8.8
CITRIX Ram
15.4
8.8
15.4
8.8
15.4
8.8
Swap
12.5
8.4
12.5
8.4
12.5
8.4
COM/DCOM Ram
7
0.4
5.8
0.4
5.8
0.4
Swap
3.5
0.3
3.2
0.3
2.9
0.3
CTLIB Ram
4
N/A
4
N/A
4
N/A
Swap
3.5
N/A
3.5
N/A
3.5
N/A
DBLIB Ram
4
N/A
4
N/A
4
N/A
Swap
3.5
N/A
3.5
N/A
3.5
N/A
DB2 Ram
7
0.8
6.9
0.5
7.2
0.96
Swap
5.2
0.97
5
0.95
4.8
0.8
DNS Ram
3.4
0.3
3.3
0.3
3.9
0.3
Swap
2.9
0.3
2.7
0.3
2.4
0.3
FTP ? Ram
3.1
0.26
3.1
0.25
3.6
0.28
Swap
2.7
0.25
3.1
0.25
2.4
0.25
INFORMIX Ram
5.1
N/A
5.1
N/A
5.1
N/A
Swap
2.6
N/A
2.7
N/A
2.6
N/A
IMAP ? Ram
3.4
0.3
3.4
0.3
4
0.3
Swap
2.8
0.3
3
0.3
2.5
0.27
JAVA General Ram
10.5
0.6
10.5
0.6
10.5
0.6
Swap
12.7
0.6
12.7
0.6
12.7
0.6
MAPI Ram
4.2
0.3
4.8
0.31
5
0.33
Link URL: http://www.cnblogs.com/tester2test/archive/2006/08/14/476590.html -
我写的一个性能测试方面的讲稿
2007-06-07 14:30:40
-
每日构造与冒烟测试[转载]
2007-06-07 14:30:40
每日构造与冒烟测试 作者：Steve McConnell 如果你想创建一个只包含一个源程序文件的简单程序，那么你只需要编译、连接那一个文件就可以了。如果是一个团队项目组，有着许多甚至上千个源程序文件，那么要创建一个可执行程序的过程就变得更复杂、更耗时。你必须用各种各样的组件将程序逐步建立起来。
在微软或其它一些软件公司中惯例是：每日构造并做“冒烟测试”。每天都对已完成的源程序进行编译，然后连接组合成可执行的程序，并做“冒烟测试”，以简单的检查该执行程序在运行时是否会“冒烟”。
带来的好处
虽然这是一个非常简单的过程，但却有非常重要的意义：
1、能最小化集成风险
项目组可能遇到的一个很大的风险是，项目组成员根据不同的系统功能各自开发不同的代码，但是当这些代码集成为一个系统的时候，也许系统完成不了预期的功能。这种风险的发生取决于项目中的这种不兼容性多久才被发现，由于程序界面已经发生了变化，或者系统的主要部分已经被重新设计和重新实现了，相应的排错工作将非常困难和耗时。极端情况下，集成的错误可能回导致项目被取消掉。每日构造和冒烟测试可以使这种集成错误变得非常小，而且便于解决，防止了很多集成问题的产生。
2、能减小产品低质量的风险
这种风险是和集成不成功、集成出错相关联的。每天对集成的代码做一些少量的冒烟测试，即可杜绝项目中那些基本的质量问题。通过这种方式，使系统达到一种周知的良好状态，维护这样的系统可以防止系统逐步恶化到耗费大量时间排查质量问题的地步。
3、能简单化错误诊断
当系统每天都进行build和测试时，系统任何一天发生的错误都能够变得十分精细，便于排查。比如在17日系统还运行正常，18日就出错了，那么只需要检查这两次build之间的代码变化就可以了。
4、能极大鼓舞项目组的士气
看到产品的不断成长，能够极大的鼓舞项目组的士气，有时甚至不管这个产品到底用来做什么。开发人员可能会为系统显示了一个矩形而感到激动。通过每日构造，产品每天进步一点,保证项目士气的持续高涨。
进行每日构造和冒烟测试
虽然说这是一个简单枯燥的活，每天进行build，每天进行测试，但也有着一些值得注意的细节：
1、每天坚持
每日构造，最重要的就是“每日”。如Jim McCarthy所说，把每日构造看作是项目的“心跳”，没有“心跳”的话，项目也就死了(Dynamics of Software Development, Microsoft Press, 1995)。Michael Cusumano and Richard W. Selby描述了另外一种隐含的比喻，把每日构造比作项目的“同步脉冲”(Microsoft Secrets, The Free Press, 1995)。 不同开发人员写的代码在他们的“脉冲”之间肯定都会存在“同步”的差异，但是必须有这样一个“同步脉冲”，使得这些代码能够组合为一个整体。当项目组坚持每天把这些不同的“脉冲”组合到一起的时候，开发人员脱离整体的情况就会得到极大程度的杜绝。
有些项目组把这一过程简化为“每周build一次”。这样带来的问题是，某一次build失败后，可能要回溯好几周才能找到原因。如果这种情况发生的话，已经得不到经常build带来的好处了。
2、严格检查每一次build
要保证每一次build的成功，就必须保证build后的结果（也可称为build）是可以正常运行的，如果build不可运行，那么本次build被认为是不成功的，同时应该将修复此次build的工作提高到项目组最高级别来处理。
对于如何衡量一个build，每一个项目组都会定义一些自己的标准，这些标准需要设定一个严格的质量级别来处理那些特别严重的缺陷，同时也需要具有一定的伸缩性来忽略掉那些微不足道的缺陷，一些不适当的关心也许会使整个过程举步为艰。
一个好的build起码应该具备以下条件：
●能够成功编译所有的文件、库，以及其它相关组件；
●能够成功链接所有的文件、库，以及其它相关组件；
●不能存在任何使得系统无法运行或者运行出错的高级别故障；
●当然，必须通过冒烟测试
3、每天进行冒烟测试
冒烟测试应该是对整个系统流程从输入到输出的完整测试。测试不必是面面俱到的，但是应该能够发现系统中较大的问题。冒烟测试应该是足够充分的，通过了冒烟测试的build就可以认为是经过充分测试、足够稳定的。
不进行冒烟测试的build是没有太大价值的。冒烟测试就像一个哨兵，在阻止着产品质量恶化和集成问题的产生，不进行冒烟测试，每日构造可能会变成浪费时间的练习。
冒烟测试必须随着系统的扩充而扩充。最初，冒烟测试可能是非常简单的，比如验证系统是否会打印“Hello World”，随着系统功能的扩充，冒烟测试需要越来越充分。最初的冒烟测试也许只需要几秒钟来执行，逐渐地，测试可能会花费30分钟，1小时，甚至更长。
4、建立一个专门的build小组
在很多项目组，维护每日构造，并更新冒烟测试用例，会耗费一个人工作的大部分时间。因此在一些大的项目中，这项工作独立成不止一个人来完成的全职工作。比如在 Windows NT 3.0的研发中，就有一个由四个全职人员组成的专门的build小组(Pascal Zachary, Showstopper!, The Free Press, 1994)。
5、为build增加修订，如果这样做有意义的话
一般开发人员不会每天都经常向系统中快速的增加实际的代码，通常是每隔几天，他们在开发好完成某个功能的一套代码以后，然后集成到整个系统中。
6、规定一些导致build失败的惩罚措施
很多执行每日构造的项目组都会规定一些惩罚措施，来惩罚那些导致build失败的行为。从最开始，项目组成员就清楚的知道，build的正常执行是项目组的头等大事。一个失败的build是项目组的意外，无法成为项目组工作的准则。必须坚持：导致build失败的同事，必须停下手中的工作，首先来解决build失败的问题。如果一个项目组的build经常失败的话，久而久之的，再来谈build的正确性就没有意义了。
有种轻松的惩罚措施，能够突出解决问题的优先性。Some groups give out lollipops to each "sucker" who breaks the build. This developer then has to tape the sucker to his office door until he fixes the problem. 有些项目组会惩罚犯错的同事戴上山羊角，或者向一个项目基金捐献5块钱。
有些项目组对此的惩罚就有点残酷了。微软的开发人员，在一些知名度很高、很重要的产品如Windows NT，Windows 95，Excel等产品后期研发中，被要求随时带着寻呼机，如果你的代码导致build失败的话，即使是凌晨3点钟，也会要求你立即来处理这个问题。
7、即使在压力下也需坚持每日构造和冒烟测试
当项目进度的压力越来越大时，维护每日构造的工作看起来有些浪费时间，但是恰恰相反。在压力之下，开发人员丢掉一些平时的规定，会采用一些设计和实现的捷径，这在平时压力较小的环境下一般时不会用的。代码的review和单元测试也可能会比平时粗心一些，这些代码的状态变化也会比平时快很多。
为防止这种情况的出现，每日构造会坚持相关的规定，让压力下的项目保持在正轨上。代码仍然每天在不断变化，但是构造过程使得这种变化每天都可控。
谁能够从每日构造这种过程中得到好处呢？一些开发人员会抗议说，由于他们的项目太大，每天进行build是没有实际意义的。但是为什么现在最复杂的软件项目组却能够成功的执行每日构造的制度呢？本文首发时，Windows NT包括了560万行代码、分布在4万个源程序文件中，项目组仍然可以坚持每日构造。
Link URL: http://www.cnblogs.com/tester2test/archive/2006/10/27/541975.html -
关于内存泄漏检测问题，和大家一起分享
2007-06-07 14:30:40
-
极度郁闷的测试老兵(作者：guoyong）
2007-05-29 11:24:22
原帖出处：http://bbs.51testing.com/thread-64359-1-1.html
极度郁闷的测试老兵
我一个测试老兵。6年测试工作经验。5年性能测试经验。3年自动化测试经验。2年测试部管理经验。
因公司拖欠两个月薪水，无奈开始找工作。
可能是自己开的薪水高8K-12K，暂时还没有找到工作（总计：7个工作日）。
因为全家只靠我一个人的薪水，现在公司不发薪水就快要没米下锅了。心理极度压抑。
他妈的老子不怕！大不了从5K重新来过！（感谢51Testing给我一个说出心理话的空间）
经过一个月的疯狂面试，（面了２０家公司）
最后总算找到工作了，虽然薪水不高，但也算知足了。面了这么多公司真是受打击啊，最后都在怀疑自己的能力是不是真的不行。
下面是一些公司的面试过程。
JS 笔试，面谈，还当场写了一个单元测试代码。最后没有消息，可能是要求的薪水太高，他们给不出。
XS 笔试，面谈，这是一家测试培训的公司，当时面试时一个LR高手问如何测试图片验证码，我告诉他可以屏弊或用万能码，最后他告诉我可以使用测试插件需要自己用代码实现。胡说八道自己也没试过就不要乱说，这种人教学生真是害了学生。最后双方都不满意。
HFKY 笔试，测试部面试，开发部面试，人事经理面试，最后没有消息。这个是自己的英语不过关。无话可说
KLX 面谈，随便问了几个问题，问薪水要求。最后告诉我最多5K。我无语
ZH 笔试，全英文试题与测试一点关系也没有，人家就是要求英语。自己能力不行没得谈了。
YD 笔试，机试，面试 最后毫无消息了。莫名其妙的公司。该公司的办公环境非常压抑，房间里黑乎乎的。
ZW 笔试 面试 最后等消息。最后就没消息了。
DL 笔试，这个公司搞笑笔试的题目居然是国外的IQ测试题，全英文，就是把网页打印下来，我回家自己试试只答对了30%。最后毫无消息。该公司没有安全感，就在居民楼中办公。
YC 笔试 面试 这个是通过了，考虑到是外包公司把他给拒了。
GH 笔试 测试技术面试 部门经理面试 HR面试 最后告诉我学历不符。没办法人家公司有规定啊。（我大学没毕业，没有学历）
DZ 电话面试 笔试 面试 这个是最郁闷的，我与面试官没法交流，他不知道我在说什么，我也不知道他在问什么。最后直接告诉我不合适。
HWL 这个更搞笑，到了公司一看原来公司一个员工也没有，大家随便聊了聊，告诉只能给5K,没办法公司在创业。对这种不公司实在是没兴趣。
JD 笔试 技术面试 部门经理面试 人事面试 最后告诉我学历不符。真他妈生气，学历不符你早说啊，害得我陪你玩了一天。
ZM 笔试 总经理面试 这个爽快，试用期5K 6天工作日。直接拒了。
MY 笔试 然后直接告诉我不相符。我也没问为什么，直接回家了。
XYL 直接面谈 然后告诉我等通知。最后是没消息。一家外包公司，我也没兴趣。
这个时候人已经快要崩溃了，压力都让我有想吐的感觉（真实的感觉）
YT 这个面试状态最差，一直心情烦燥，笔试居然有20页的题目，随便答了答，然后是面试一下子来了4个人，大家在友好的气氛中聊了40分钟，最后一个经理夸奖到你还是很聪明的。最后告诉我等通知。
XL 笔试 测试经理面试 部门经理面试 人力专员面试 人力总监面试 CEO面试 最后终于通过了。行了这家吧，双方都比较满意。
如果最后一家在不成功，估计我都要去睡天桥了。在一次面试回来的路上，走在天桥底下，看到一个流浪汉睡在那里，当时真想同他说“哥们能不能让在你这躺一会”
经过这些面试也认识到自己的不足，没有学历，英语不行。在这两个方面自己还要大力补充。
感谢楼下的兄弟对供的机会。在这里说一声谢谢！
祝所有做测试的兄弟姐妹2007年一切顺利！
Link URL: http://www.cnblogs.com/tester2test/archive/2007/05/29/763627.html -
[论坛] 数据库操作的样例脚本
2007-05-17 07:59:46
-
[论坛] 我做的一个小工具定时执行批处理或者可执行文件（可批量执行）
2007-05-17 07:58:10
我做的一个小工具定时执行批处理或者可执行文件（可批量执行）
AutoRunBat.exe
(2006-07-04 16:15:28, Size: 184 kB, Downloads: 161) -
[论坛] 我写的两个小工具（bug记录工具）
2007-05-17 07:57:45
我写的两个小工具（bug记录工具）
bugsetup.rar
(2005-06-10 11:02:09, Size: 731 kB, Downloads: 367) -
[论坛] 提供一个可以批量生成数据的工具给大家
2007-05-17 07:57:15
提供一个可以批量生成数据的工具给大家
Thelp.exe
(2007-04-04 10:24:45, Size: 167 kB, Downloads: 53) -
[论坛] 把我收集的性能资料做成一个程序给大家，方便大家写测试总结使用
2007-05-17 07:55:25
把我收集的性能资料做成一个程序给大家，方便大家写测试总结使用
performance.exe
(2005-12-05 09:23:14, Size: 329 kB, Downloads: 379) -
[论坛] 把我的性能测试讲稿奉献给大家
2007-05-17 07:53:19
把我的性能测试讲稿奉献给大家
[ 本帖最后由 fish_yy 于 2007-4-12 20:07 编辑 ]
xncssj.pdf
(2007-04-12 20:07:52, Size: 259 kB, Downloads: 219) -
五一期间各大公司加班口号(转）
2007-04-29 15:51:13
-
我用delphi写的一个很小的bug管理工具
2007-04-24 12:12:26
我用delphi写的一个很小的bug管理工具，希望对大家有点帮助（很早以前写的了）
Bug管理小工具下载
Link URL: http://www.cnblogs.com/tester2test/archive/2006/05/12/398434.html -
不成熟的测试工具
2007-04-24 12:12:26
在编写这个工具前没有用过winrunner，工具主要是模仿鼠标键盘事件，可以编写脚本，针对不同的如菜单，按钮，文本输入都有相应的规则，后台有一个access数据库，可以针对数据库中的数据结合脚本测试，点击“i”信息图标，可以写脚本，详细请参见说明书，安装程序中有！
Link URL: http://www.cnblogs.com/tester2test/archive/2006/05/12/398453.html -
提供软件测试、软件开发相关服务
2007-04-24 12:12:26
服务内容
提供软件开发、软件测试理论知识的咨询、培训、指导、实施；
提供开发工具、测试工具的使用培训、指导、实施；
提供软件性能、压力测试方案的制定、实施、分析等服务；
承接软件开发、软件测试项目；
服务内容介绍
软件开发、软件测试理论知识的咨询、培训、指导、实施
青扬软件咨询服务为企业提供软件工程关于软件生存周期（需求分析、可行性分析、概要设计、详细设计、编码、软件测试、软件发行、软件维护等各个阶段的理论）、软件开发模型（瀑布模型、快速原型等模型）、测试（单元测试、集成测试、系统测试、性能测试、压力测试以及测试计划、测试设计、测试用例的编写等）、测试模型等理论知识的咨询、培训、指导和实施以及对相应结果的分析与系统的改良。
开发工具、测试工具的使用培训、指导、实施
青扬软件咨询服务为企业提供主流开发工具（Java、Delphi、Jsp、C#等），自动化测试工具（Winrunner、QuickTest、Loadrunner、TestDirector、Bugzailla、Jmeter、Badboy等）以及测试数据的自动生成技术的使用指导、培训、以及相应的编码规范、操作技巧等。
软件性能、压力测试方案的制定、实施、分析等服务
目前随着国内软件企业的蓬勃发展，对软件系统的性能、压力和稳定性的要求越来越高，青扬软件咨询服务为企业提供软件性能、压力测试方案的制定、测试用例编写、测试数据生成运用Loadrunner、Jmeter等进行性能和压力的测试，对软件测试结果进行分析，提供软件的改良意见等。
承接软件开发、软件测试项目
青扬软件咨询服务为企业或者个人提供软件项目的定制以及为企业提供软件项目的承接服务。
联系方式
Mail：win_soft@163.com Msn：win_soft@163.com
Link URL: http://www.cnblogs.com/tester2test/archive/2006/05/18/403034.html -
自动化测试在企业中的实施
2007-04-24 12:12:26
自动化测试在企业中的实施文章出处：不详 作者：钱亦嵘 发布时间：2005-10-19【摘要】本文从为什么要引入自动化测试出发，深入探讨了企业实施自动化测试的流程。
【关键词】自动化测试自动化测试工具
- 前言
51testing上许多期杂志都有涉及到自动化测试专题的文章,其中既有谈到自动化测试技术解决方案的文章,也有教大家如何使用自动化测试技术的文章,看了以后都使我受益非浅。
大家知道，在国内测试行业属于一个新兴行业，与国外测试行业相比，国内也只是近几年才开始重视软件测试的。之所以被关注，原因也许是多方面的，但我想最根本一点就是中国软件要发展。
中国软件这几年发展迅速，很大部分原因是借鉴了国外优秀企业的经验技术，从无到有，学习了国外企业的一整套做事的规范，的确是一种快速成长方法。当然软件测试也应该如此，从不重视到重视，更应该多学习一下如何制定测试流程，缺陷管理以及测试用例设计等优秀理念。在此笔者只想针对自动化测试在企业中的实施谈些个人意见，希望能和大家分享。
当然，自动化测试作为一项新技术，一开始往往会被一些人认为是“无所不能”的，以为一旦有了它就可以解决软件所有的质量问题。难道自动化测试就是传说中所谓的“银弹”吗？结果当然是否定的。假如在实施前没有好好的调查、做好预期准备工作就盲目开展，一旦进入推广实施阶段，往往最终会弄得无法收场的结果。下面让我们先来解决一个问题。
- 为什么要引入自动化测试
首先，按照笔者的观点，用自动化工具进行测试只不过是测试活动中的一种。真正要在工作中派上用场，也是因为测试工作有了人的参与，而使用工具的目的也只不过是用来减少部分手工测试，将更多人力资源投入到更有价值的工作中，决不能轻重不分。
其次，既然要跟上国际潮流，那么自动化测试技术就是将来大部分测试工程师需要必备的一项技能。这也是笔者为什么要写这篇文章的出发点，希望能帮助大家推动自动化测试在企业中的实施。当然首先要保证一点，要实施自动化测试的企业必须符合具备开展自动化测试的一些先决条件。
笔者就有这样的感受，在企业中，如果想把自动化测试技术应用到工作生产中，没有持之以恒的恒心，坚忍不拔的决心，高度的自信心，是不可能完成这个工作的。那么怎样的时机是有利于开展自动化测试的？实施过程中该注意什么？采用什么策略去避免不必要的损失，提高大家对新技术的兴趣是很有讲究的。下面笔者将一一做出解答。
- 企业实施自动化流程
1）至关重要的是公司的高层必须认同成立测试部门是很重要的，不是浪费公司的资源；这一点，其实很早就应该达成共识，因为像Microsoft这样的公司也说过“大多数人认为我们是一个软件开发公司，其实我们是一家软件测试公司”的话，从中可以看出测试是非常重要的。然而考虑到公司的长远发展，自动化测试将是今后的一个发展方向。由此看来，自动化测试是有必要深入开展的。
2）在公司大规模使用前，必须要有专人针对不同的自动化测试，去评估究竟该使用哪种测试工具比较好。自动化测试工具又分单元测试工具、功能自动化工具和性能自动化工具，其中又分开源的和商业工具。究竟哪种工具更适合自己公司平台的测试，还需要有专业人员进行评估。
第一、比如说公司是采用Java技术还是.NET技术开发产品的。大多数商用工具都会根据现今最流行的开发平台提供一种自动化测试的解决方案。做测试工具比较专业的有Mercury，Segue，IBM Rational，Compuware，Empirix这几家公司，根据不同测试又有相应的测试工具。
第二、如果考虑到商业软件比较昂贵，还可以考虑一下开源的测试工具。这些工具往往具有小巧，灵活多变，免费的特性，还有个好处就是它的开源。现在全世界范围已经有越来越多的人投入到开源项目中去。已经比较出名的有Apache的Jmeter，Jtest，OpenStar等等。就连全球最大的IT公司IBM现在也把目光聚焦到了这块，由IBM出资1000多万的开源项目Eclipse，在过去也许是唯一一个能和JBuilder开发环境相媲美的开源的开发环境了。但现在在此平台上有了TPTP，但我们同样可以在Eclipse上做我们的功能和性能测试
第三、也许以上工具都无法满足测试的特殊需求，那最好的方法就是自行开发测试工具；这主要集中在嵌入式系统方面。比如手机与手机之间需要做到即时、无误的发送短消息，而一般常用的工具是没有办法做到这方面测试的，那就只能考虑公司内部自己开发测试工具了。
第四、还有就是在选用工具方面，还要充分考虑到工具的可集成性、可扩展性以及平台兼容性。因为实际工作中，我们常常需要把测试流程，需求管理，缺陷管理，配置管理结合的更紧密，通过工具去统一管理。这些都是在选用工具时要考虑到的因素。
3）在全面实施之前，根据以往的经验，笔者建议最好选出几个人进行小规模的实验。这样做的好处一来可以以小见大，从几个人的反映看出自动化测试的雏形；二来可以总结不足之处，在后期的开展中尽量避免；三来，可以把实施所见的成效推广开来，为后期工作的开展做好铺垫。
笔者在企业里就有类似的经历，一个项目已经上线，以后每次发布一个补丁之前，测试人员都需要通过执行一些SIT(System Integration TestCase)测试用例来覆盖整个系统的大部分模块。而执行一遍这样的用例，至少需要花费六个测试人员一天的时间。后来在这个项目内进行了自动化测试的实验，根据SIT的测试用例转换成自动化脚本。运行一个用例脚本只需要十五分钟，而每次也只需要一个测试人员把所有脚本运行一遍就可以了，其他人就可以从中解放出来做其他工作了。像这样比较成功的例子，一定要在后期工作开展时加以宣传，要认大家认识到自动化好处，这样大家才会有积极性去学。
4）有了上面的经验，接下来该在整个部门进行自动化测试的推广了。当然适当给从业人员进行工具的使用技能以及一些相关知识培训还是有必要的。因为在工作中常常发现由于测试工程师掌握知识的差距，每个人对工具上手操作有快有慢。为了尽量给大家造成好的影响，能够更好的开展这项工作，使其能更快的应用到日常工作中去，减轻部分繁琐的重复性劳动，对测试工程师进行培训还是必不可少的。
5）正如软件生命周期有需求分析阶段一样，在录制自动化脚本之前也需要收集需求,这些需求主要是用于后期录制脚本的选取。这些需求可以根据需求人员做的需求文档，也可以选择测试人员的测试用例来转化成脚本，还可以让需求分析人员推荐几个常用的，相对简单的流程转化成脚本。总之一句话，需求就好比源头，从源头抓起才能开发出高质量的脚本。
6）做了前面一系列准备工作，已经有了一个好的开始。接下来就要求大家进行一次头脑风暴，对刚收集来的需求进行分析，设计出一个好的实现方案。这里我想强调两点：
第一、工具只能帮助测试人员去更好的进行测试，至于怎样使用才能提高工作效率，还是需要测试人员在实施前期进行更多的思考，比如思考如何把一个好的设计转化成我们后期的自动化脚本等。因为脚本是不会创造性的发现本身没有涉及到的缺陷，就好比许多测试人员编写测试用例，如果你没有把你要测试的功能点写入测试用例中，根据测试用例执行人员是不会考虑到这一点的。因此设计一个全面，详细的设计方案显得尤其重要。
第二、出于程序可复用的角度考虑，按照怎样的划分粒度，如何把脚本进行好的规划也很重要。例如：将一些使用率高的模块录制成共享脚本，使用者只需要通过一些参数进行使用，无须考虑到内部的具体实现机制。这样还可以大大减少大家的重复劳动量。
7）对工具有了一定认识以后，就到了上手操练阶段。俗话说：“拳不离手，曲不离口”。由于前期投入大量精力、人力、物力，现在正是出成果的时候。但在开发脚本之前，笔者还有几点想着重申明一下：
第一、开发脚本必须遵循一些规范化，就类似于程序员编程规范一样。我们的测试脚本就好比是我们测试人员的程序，同样要形成一个编写规范。因为养成这样的好习惯，是为了能方便维护脚本，避免增加后期的维护量和方便使用者使用；
第二、保证开发的脚本回放没有问题的基础上，适当增加出错处理来增强脚本；
第三、后期还可以在脚本中加入检查点，这样做的好处可以把原来需要人工去校验的地方让脚本去做；
第四、在脚本中增加数据驱动方法，使脚本能覆盖更多的分支路径，进一步提高脚本的集成度。因为前面已经说过了，脚本是不会执行那些没有被编写进去的功能点的，所以说后期测试人员一旦发现这个地方有必要让脚本来代替手工进行执行，就可以不断的增强我们的自动化脚本。
8）最后，切记任何工作的开展并非一朝一夕，新技术的开展将需要投入大量人力物力，而自动化测试就是我们测试工程师必须要坚持的一个长期的发展方向。为了不至于做事只做表面，建议每个测试团队中都必须要有专人去负责推动自动化工作的开展。还必须有专人负责维护脚本，规范脚本，甚至可以引入配置管理工具来统一管理脚本和把经验文档化。只有这样我们的测试财富才会从中不断积累，只有这样自动化测试才能走得更远。
以上总结了几点，都是笔者在企业中推行自动化测试的一些心得体会。最后希望能够有更多人从自动化测试中获得快乐，从繁琐的手工测试中解脱出来。
Link URL: http://www.cnblogs.com/tester2test/archive/2006/05/22/406008.html -
我写的qtp部分培训资料
2007-04-24 12:12:26
标题搜索
我的存档
数据统计
- 访问量: 272241
- 日志数: 689
- 建立时间: 2006-12-05
- 更新时间: 2009-04-15
