• 空间首页
• 空间管理
• 51Testing软件测试网
• 站点论坛
• 添加我的日志

我的最新日志

• robot安装及破解时提示cannot connect to license server 解决方案

  2008-1-10

  robot下载地址：http://bbs.51testing.com/viewthr ... p;extra=&page=1
  
  Robot安装、破解说明：
  

  Robot-TestManager Performance Testing Manual.doc
  

  
  
  按照该文档破解License Server，在执行步骤5时提示：
  cannot connect to license server -15，10：10061(winsock:connection refused)，多次执行Start或者Stop按钮问题仍无法解决，于是又搜索到如下解决方法：
  
  1、点击”开始”—>”运行”，输入”cmd”，在弹出的Dos界面中输入Ipconfig/all，如下图，找到网卡的虚拟地址。
  
  
  
  2、右键单击“我的电脑”，选择“属性”，在弹出的属性页面框中选择“硬件”项，点击“设备管理器”。
  
  3、在弹出的“设备管理器”窗体中，选择“网络适配器”—>网卡。
  
  4、右键点击相应的网卡，选择“属性”，在弹出的页面中选择“高级”—>“Network Address”，填入相应的值，如“00F0F4E41793”，如下图：
  
  
  
  5、重装License，破解！OK
  该方法来源：http://www.cnblogs.com/3echo/archive/2007/09/12/890783.html
  
  该方法在步骤4时又遇到问题，“高级”选项找不到“Network Address”，于是只好在注册表里进行修改了
  
  Win 2K/XP下修改网卡MAC地址的方法:

  
  1.先找到下面这个注册表项
  [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000]
  在它下面有0000、0001、0002……，找到里面有个字符串描述项DriverDesc记录的是你的网卡描述，那就是它了。
  这里假设它是0000。

  
  2.在[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000]
  里添加一个字符串项NetworkAddress，原来可能就有了，不过为空，如果没有就加一个吧。现在将它赋值，
  如果你的网卡是11-22-33-44-55-66，那么就像下面这样填写。
  "NetworkAddress"="112233445566"

  
  3.然后再到下面这个注册表项
  [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000\Ndi\params]
  在里面添加一个项，并添加相应的内容。
  [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000\Ndi\params\NetworkAddress]
  "default"="112233445566"
  "paramdesc"="MAC Address"

  
  4.接下来，重启就行了。

  
  该方法来源：http://blog.sina.com.cn/s/blog_567592bd010007vp.html
  
  

  查看(676) 评论(0)

• Cookie测试工具小汇(转)

  2007-12-30

  文章发表时间:2007-08-28

  现在很多网站都用到Cookies，特别是用户的登陆以及购物网站的购物车。 Cookies 通常用来存储用户信息和用户在某应用系统的操作，当一个用户使用Cookies 访问了某一个应用系统时，Web 服务器将发送关于用户的信息，把该信息以Cookies 的形式存储在客户端计算机上，这可用来创建动态和自定义页面或者存储登陆等信息。
  如果Web 应用系统使用了Cookies ，就必须检查Cookies 是否能正常工作。测试的内容包括Cookies是否起作用，存储的内容是否正确，是否按预定的时间进行保存，刷新对Cookies 有什么影响等。

  http://ccc.atmos.colostate.edu/~hail/howto/faq/coo...

  如果到\Local Settings\Temporary Internet Files文件夹下查看每个Cookies文件是一件很麻烦的事情，这个时候就需要有工具来帮助我们。

  1、Cookie Editor

  http://www.proxoft.com/CookieEditor.asp

  Cookie Editor is an application that helps you manage cookies set by Internet Explorer, Netscape or Mozilla Browsers.

  Cookie Editor allows you to maintain the level of your privacy by allowing you to see, edit or delete any unwanted cookies. It searches your drives for all IE cookies then displays them is easy grid-like format. You can examine content of any cookie or delete it.

  For advanced users, you can also edit the contents of cookies. So, for example, if you want to change your zip code for 'movies.yahoo.com', or move up the expiration date of a given cookie, you could do so without even opening your browser!

  比较大的特点是可以显示出IE，Netscape和Firefox的Cookie；因为Netscape和Firefox的Cookie不是存储在Temporary Internet Files文件夹下的，而是在Application Data文件夹下的对应文件夹里。

  

  2、IECookiesView

  http://www.nirsoft.net/utils/iecookies.html

  一个可以帮你搜寻并显示出你计算机中所有的Cookies档案的数据，包括是哪一个网站写入Cookies的，内容有什么，写入的时间日期及此Cookies的有效期限..等等资料。你是否常常怀疑一些网站写入Cookies内容到你的计算机中是否会对你造成隐私的侵犯！使用软件来看看这些Cookies的内容都是些什么呢！如此你就不会再担心怀疑了。此软件只对IE浏览器的Cookies有效。

  

  3、Cookies Manager

  http://home.nordnet.fr/~pmdevigne/CookiesManager_e...

  Cookies Manager helps you to select which cookies you want to keep and which cookies you want to delete.

  

  4、My Cookie

  My Cookie是一款可以实时查看、修改IE内 Cookied的软件。并且可以设置 Cookie值的生命周期。

   

  文章来源:http://www.cnblogs.com/oscarxie/archive/2007/08/28/872610.html

  查看(52) 评论(0)

• TestDirector更改字体大小操作步骤 (转)

  2007-12-29

  首先下载一个比原有系统字体大的控件TDClientUI80.xco，然后在执行如下操作。

  服务器端：
  第一步到以下路径
  C:\Inetpub\TDBIN\Install
  找到TDClientUI80.xco覆盖此文件

  第二步到以下路径
  C:\Inetpub\TDBIN
  找到setup_a.ini打开找到以下内容，把CheckSize=3197104改为 CheckSize=3197992
  [File_2]
  Register=Y
  URLName=%URL%/Install/tdclientui80.xco
  ShortName=tdclientui80.ocx
  Descrīption=User Interface
  ProgID=tdclientui80.TdFrameX
  Version=8.0.0.2931
  Main=Y
  param_TDsrvURL=%URL%
  param_RegisteredPages=Requirements,{e6e61bac-8859-4d1d-b8d9-cf50bc63a31a}!Test Plan,{3980dd43-7f99-4585-9e8b-9cb29920bd8e}!Test Lab,{99ea8527-6a6a-40fe-a67c-82cf763902d0}!Defects,{61c669c7-eddd-4277-bf5e-64807cb8dcef}
  param_RegisteredTools=Document Generator,{9037655e-bdd5-4883-86fa-ecea50b2a9cc}!Product Information,{4603f45c-0353-451e-9571-e4dbb6351f84}
  param_RegisteredLinks=Site Administrator,%URL%/SiteAdmin.htm!Add-Ins Page,%URL%/Addins.html!Mercury Interactive on the Web,http://www.mercuryinteractive.com!About TestDirector,%URL%/Help/About.htm
  param_RegisteredHelp=Online Help,%URL%/Help/OnlineHelp/TDHelp.htm!Books Online,%URL%/Help/Books/onlinedoc.htm!What's New,%URL%/Help/OnlineHelp/tdhelp.htm?context=w&topic=7000!Support Information,%URL%/Help/Support/supportcustomer_support.htm!Technical Support Online,http://support.mercuryinteractive.com!Mercury Interactive on the Web,http://www.mercuryinteractive.com!About TestDirector,%URL%/Help/About.htm
  param_RegisteredWorkflow={26728871-5c6a-4a91-a2b4-400b80626c19}
  param_Parameters=StartPage=start_a.htm
  CheckSize=3197992

  客户端：
  找到以下路径
  C:\Program Files\Common Files\Mercury Interactive\TD2000_80
  把tdclientui80.ocx文件删除。

  文章来源:http://hrbtester.blog.sohu.com/38741640.html

  
  

  查看(147) 评论(0)

• 测试过程中对浏览器的设置问题(转)

  2007-12-29

  
  
  1.jpg
  图1：Internet临时文件的设置
  
  
  2.jpg
  图2：“高级”选项的设置           
  说明：在“高级”选项中，对测试起重要作用的是“禁止脚步调试”（不选择，即前面不要有勾）和“显示每个脚本错误的通知”（选择它，即前面要出现勾）。            
  这些设置对重现有关脚本错误的Bug起着重要的作用。根据这些脚本错误的通知，开发人员可以快速发现代码中的错误，并及时修复它。
  
  文章来源:http://hi.baidu.com/ruanjiancesh ... df73f8ae513357.html

  查看(322) 评论(1)

• 软件测试过程中应该注意的要点(转)

  2007-12-29

  软件测试是比较辛苦的事情，但又不是没有章法的，你一旦掌握了一定的技巧之后，将对你有事半功倍的效果。
  
  1.边界测试，测试用户输入框中的数值的最大数和最小数，以及为空时的情况。
  
  2.非法测试，例如在输入数字的地方输入字母。
  
  3.跟踪测试，跟踪一条数据的流程,保证数据的正确性。
  
  4.在开始测试时应保证数据的正确性，然后在从系统中找出各种BUG。
  
  5.接口测试，程序往往在接口的地方很容易发生错误，要在此模块测试勿掉以轻心。
  
  6.代码重用测试，在开发过程中有些模块功能几乎相同，程序员在重用代码时可能忘记在原有代码上修改或修改不全面，而造成的错误。
  
  7.突发事件测试，服务器上可能发生意外情况的测试。
  
  8.外界环境测试，有些系统在开发时依赖于另外一个系统,当另外一个系统发生错误时, 这个系统所受到的影响的情况。
  
  9.缺陷验证：在程序员刚修复Bug之后的地方,一定要在次验证、测试，往往程序员只修复报告出来的缺陷而不去考虑别的功能在修改时可能会重新造成错误。
  
  10.做好BUG管理工作，认真做好测试记录，在做完一天的测试记录之后,第二天再根据第一天的测试记录重复测试你会发现有未修正的错误。
  
  11.错字、错词测试，如果在系统中有用词不当的地方，我想这是不应该的。
  
  12.系统兼容测试，例如有些程序在IE6能运行正常，到IE5下不能运行。有些程序在WIN2000下能运行，而到WIN98却不能运行。像一些很特别的用户去使用系统，你很有可能发现BUG。
  
  13.用户的易用性测试，往往用户的需求是不断的变化的，而其中一部份变化的原因，是由用户操作上不方便引起的。
  
      软件测试是软件开发中的重中之重，没有一点可以马虎，在项目管理过程，强调的是每个过程的每一个环节都要进行测试，保证系统在每个阶段可以控制。因为软件测试中考虑的问题基本上是项目管理中考虑的问题，相反，在项目管理中考虑的一些问题也应该是在软件测试的时候有所体现，体现的内容就是软件测试的一些侧重点，具体说，软件测试是事务性的，而项目管理是策略性，一些策略性的东西必须在一些事务性的事务上来实现。所以说从事软件开发的相关工作是一件很辛苦的事，只有在工作中多总结，才能找到符合自己的方式方法，才能在工作中事半功倍。
  
  文章来源:http://hrbtester.blog.sohu.com/22361211.html

  查看(437) 评论(3)

• Web测试中书写Test Case时要考虑的检查点

  2007-12-29

  通常书写Test Case时需要考虑的检查点
  
  对于屏幕显示来说包括：
  检查显示的布局；
  检查域和按钮的顺序；
  检查域的尺寸；
  检查字体的大小和风格；
  检查文本的含义；
  检查拼写错误；
  检查屏蔽域；
  检查只读域；
  检查图片；
  检查按钮的状态；
  检查按钮的尺寸；
  检查按钮的图标和名字；
  检查是否有重复的图标；
  检查指针是否在第一个可输入域；
  检查TAB键的次序；
  
  对于域来说包括：
  检查可编辑性；
  检查域间的移动；
  检查分界条件；
  检查有效分界符；
  检查无效分界符；
  检查连续多个有效分界符；
  检查仅一个分界符输入；
  检查多余空格的截取；
  检查只读域和屏蔽域在TAB时的状态；
  
  对于数字域来说包括：
  检查正数值；
  检查负数值；
  检查零值；
  检查小数点；
  检查特殊字符加数字；
  检查字母加数字；
  检查ASCII值；
  检查重复值；
  检查空值；
  
  
  对于字符域来说包括：
  检查仅有字母；
  检查仅有数字；
  检查字母数字；
  检查允许的特殊字符；
  检查禁止的特殊字符；
  检查包含特殊字符的字母数字；
  检查ASCII值；
  
  对于字母域来说包括：
  检查字母；
  检查数字值；
  检查字母数字值；
  检查特殊字符；
  检查ASCII值；
  
  对于时间域来说包括：
  检查字符?和/；
  检查其他特殊字符；
  检查字母数字值；
  检查正确的格式；
  检查错误的格式；
  检查错误的日期数字；
  检查正确的日期数字；
  检查日历表；
  
  对于错误信息和警告信息来说：
  检查错误信息和警告信息的含义；
  检查错误信息和警告信息的一致性；
  检查确定位置的错误信息；
  检查错误信息后的光标位置；
  检查所有异常对应的错误信息；
  检查错误信息的格式；
  
  对于普通的检查来说：
  检查文本域和字符域输入是否左对齐；
  检查数字域输入是否右对齐；
  检查标签的切换；
  检查重复的名字；
  检查可删除的表格；
  检查表格的多选；
  检查过滤器的逻辑性；
  检查多个过滤器的逻辑性；
  检查重复的序列号；
  检查显示切换；
  检查快捷键；
  检查工具栏提示；
  检查日期域是否居中；
  检查选择项的高显；
  检查选择符；
  检查显示窗口的风格统一性；
  
  
  对于按键的功能包括：
  New button：
  检查包含next和cancel按键的子窗口的显示；
  检查子窗口显示的内容；
  Add button：
  检查包含save和cancel按键的子窗口的显示；
  Edit button：
  检查在未选择项目情况下点击后的警告信息；
  检查包update和cancel按键的子窗口的显示；
  检查选择的项目是否显示在制定的位置；
  Copy button：
  检查在未选择项目情况下点击后的警告信息；
  检查点击后的确认信息；
  检查插入后的复制数据；
  Delete button：
  检查在未选择项目情况下点击后的警告信息；
  检查点击后的确认信息；
  检查删除后的数据；
  Run button：
  检测运行时的参数窗口；
  检查执行结果；
  检查未选择项目情况下点击后的警告信息；
  Back button：
  检查是否回到上一屏幕；
  Next button：
  检查是否显示下一屏幕；
  Finish button：
  检查数据是否进入数据库；
  检查完成屏幕的显示；
  Cancel button：
  检查确认信息；
  检查是否有其他键执行同样功能；
  检测是否能能够正确处理；
  
  文章来源:http://hi.baidu.com/ruanjiancesh ... 8313cad0c86a67.html
  
  [ 本帖最后由 linwenyan 于 2007-12-29 01:38 编辑 ]

  查看(1143) 评论(6)

• web压力测试的几个关键点(转)

  2007-12-29

  设计压力应用
  
      设计试图对 Web 服务进行压力测试的压力测试系统时，要让它们以某种特定的方式运行代码。这些风格超越了功能验证，目的是要弄清楚被测试的 Web 服务是不是不仅能做我们认为它能做的事，而且在被施加了某些高强度压力的情况下仍然继续正常运行。压力测试必须对 Web 服务应用四个基本条件。许多已建立的压力系统应用了这些条件。有效的压力测试系统将应用以下这些关键条件：
  
  重复（Repetition）： 或许最明显的且最容易理解的压力条件就是测试的重复。换句话说，测试的重复就是一遍又一遍地执行某个操作或功能，比如重复调用一个 Web 服务。功能验证测试可以用来被弄清楚一个操作能否正常执行。而压力测试将确定一个操作能否正常执行，并且能否继续在每次执行时都正常。这对于推断一个产品 是否适用于某种生产情况至关重要。客户通常会重复使用产品，因此压力测试应该在客户之前发现代码错误。许多最简单的压力系统只实现这一个条件，但简单地扩 展功能验证测试来多次重复并不能构成一个有效的压力测试。当与下面的一些原则结合起来使用时，重复就可以发现许多隐蔽的代码错误。
  
  
  并发（Concurrency）： 并发是同时执行多个操作的行为。换句话说，就是在同一时间执行多个测试，例如在同一个服务器上同时调用许多 Web 服务。这个原则不一定适用于所有的产品（比如无状态服务），但是多数软件都具有某个并发行为或多线程行为元素，这一点只能通过执行多个代码示例才能测出 来。功能测试或单元测试几乎不会与任何并发设计结合。压力系统必须超越功能测试，要同时遍历多条代码路径。至于怎么做到这一点取决于具体的产品。例如，一个 Web 服务压力测试需要一次模拟多个客户机。Web 服务（或者任何多线程代码）通常会访问多个线程实例间的一些共享数据。因额外方面的编程而增加的复杂性通常意味着代码会具有许多因并发引起的错误。由于引 入并发性意味着一个线程中的代码有可能被其他线程中的代码中断，所以错误只在一个指令集以特定的顺序（例如以特定的定时条件）执行时才会被发现。把这个原 则与重复原则结合在一起，您可以应用许多代码路径 和定时条件。
  
  
  量级（Magnitude）： 压力系统应该应用于产品的另一个条件考虑到了每个操作中的负载量。压力测试可以重复执行一个操作，但是操作自身也要尽量给产品增加负担。例如，一个 Web 服务允许客户机输入一条消息，您可以通过模拟输入超长消息的客户机来使这个单独的操作进行高强度的使用。换句话说就是，您增加了这个操作的量级。这个量级 总是特定于应用的，但是可以通过查找产品的可被用户计量和修改的值来确定它 — 例如，数据的大小、延迟的长度、资金数量的转移、输入速度以及输入的变化等等。单独的高强度操作自身可能发现不了代码错误（或者仅能发现功能上的缺陷）， 但与其他压力原则结合在一起时，您将可以增加发现问题的机会。
  
  
  随机变化： 最后一点，任何压力系统都多多少少具有一些随机性。如果您随机使用前面的压力原则中介绍的无数变化形式，您就能够在每次测试运行时应用许多不同的代码路径。下面是几个关于怎样在测试生 命周期内改变测试的示例。使用重复时，在重新启动或重新连接服务之前，您可以改变重复操作间的时间间隔、重复的次数，或者也可以改变被重复的 Web 服务的顺序。使用并发，您可以改变一起执行的 Web 服务、同一时间运行的 Web 服务数目，或者也可以改变关于是运行许多不同的服务还是运行许多同样的实例的决定。量级或许是最容易更改的 — 每次重复测试时都可以更改应用程序中出现的变量（例如，发送各种大小的消息或数字输入值）。如果测试完全随机的话，因为很难一致地重现压力下的错误，所以 一些系统使用基于一个固定随机种子的随机变化。这样，用同一个种子，重现错误的机会就会更大。
  
  
      一个压力测试通常会结合上述的所有原则，并且在允许的范围内尽可能长时间地运行。测试被允许的执行时间越长，就可以遍历越多的代码路径，并且发现的错误也越多。当然，一旦找到错误就必须 诊断并修复它。由于一个代码错误可以在压力测试运行多日以后自己显示出来，所以系统必须保证当出现错误时所有可用的调试信息都被生成 — 否则可能就必须花费同样多的时间来重现这个错误。
  
  文章来源:http://hi.baidu.com/ruanjiancesh ... b77e0734fa4167.html

  查看(1267) 评论(6)

• 针对代码类测试的要点总结 (转)

  2007-12-27

  代码测试
  静态测试
  （1）同一程序内的代码书写是否为同一风格
  （2）代码布局是否合理、美观
  （3）程序中函数、子程序块分界是否明显
  （4）注释是否符合既定格式
  （5）注释是否正确反映代码的功能
  （6）变量定义是否正确（长度、类型、存储类型）
  （7）是否引用了未初始化变量
  （8）数组和字符串的下标是否为整数
  （9）数组和字符串的下标是否在范围内（不“越界”）
  （10）进行数组的检索及其它操作中，是否会出现“漏掉一个这种情况”
  （11）是否在应该使用常量的地方使用了变量（例：数组范围检查）
  （12）是否为变量赋予不同类型的值
  （13）（12）的情况下，赋值是否符合数据类型的转换规则
  （14）变量的命名是否相似
  （15）是否存在声明过，但从未引用或者只引用过一次的变量
  （16）在特定模块中所有的变量是否都显式声明过
  （17）非（16）的情况下，是否可以理解为该变量具有更高的共享级别
  （18）是否为引用的指针分配内存
  （19）数据结构在函数和子程序中的引用是否明确定义了其结构
  （20）计算中是否使用了不同数据类型的变量
  （21）计算中是否使用了不同的数据类型相同但长度不同的变量
  （22）赋值的目的变量是否小于赋值表达式的值
  （23）数值计算是否会出现溢出（向上）的情况
  （24）数值计算是否会出现溢出（向下）的情况
  （25）除数是否可能为零
  （26）某些计算是否会丢失计算精度
  （27）变量的值是否超过有意义的值
  （28）计算式的求值的顺序是否容易让人感到混乱
  （29）比较是否正确
  （30）是否存在分数和浮点数的比较
  （31）如果（30），精度问题是否会影响比较
  （32）每一个逻辑表达式是否都得到了正确表达
  （33）逻辑表达式的操作数是否均为逻辑值
  （34）程序中的Begin…End和Do…While等语句中，End是否对应
  （35）程序、模块、子程序和循环是否能够终止
  （36）是否存在永不执行的循环
  （37）是否存在多循环一次或少循环一次的情况
  （38）循环变量是否在循环内被错误地修改
  （39）多分支选择中，索引变量是否能超过可能的分支数
  （40）如果（39）,该情况是否能够得到正确处理
  （41）子程序接受的参数类型、大小、次序是否和调用模块相匹配
  （42）全局变量定义和用法在各个模块中是否一致
  （43）是否修改了只作为输入用的参数
  （44）常量是否被做为形式参数进行传递
  
  动态测试
  （1）测试数据是否具有一定的代表性
  （2）测试数据是否包含测试所用的各个等价类（边界条件、次边界条件、空白、无效）
  （3）是否可能从客户那边得到测试数据
  （4）非（3）的情况下，所用的测试数据是否具有实际的意义
  （5）是否每一组测试数据都得到了执行
  （6）每一组测试数据的测试结果是否与预期结果一致
  （7）文件的属性是否正确
  （8）打开文件语句是否正确
  （9）输入/输出语句是否与格式说明书所记述的一致
  （10）缓冲区大小与记录长度是否匹配
  （11）使用文件前是否已打开了文件
  （12）文件结束条件是否存在
  （13）产生输入/输出错误时，系统是否进行检测并处理
  （14）输出信息中是否存在文字书写错误和语法错误
  （15）控件尺寸是否大小适宜
  （16）控件颜色是否符合规约
  （17）控件布局是否合理、美观
  （18）控件TAB顺序是否从左到右，从上到下
  （19）数字输入框是否接受数字输入
  （20）（19）的情况下、数字是否按既定格式显示
  （21）数字输入框是否拒绝字符串和“非法”数字的输入
  （22）组合框是否的能够进行下拉选择
  （23）组合框是否能够进行下拉多项选择
  （24）对于可添加数据组合框，添加数据后数据是否能够得到正确显示和进行选择
  （25）列表框是否能够进行选择
  （26）多项列表框是否能够进行多数据项选择
  （27）日期输入框是否接受正确的日期输入
  （28）日期输入框是否拒绝错误的日期输入
  （29）日期输入框在日期输入后是否按既定的日期格式显示日期
  （30）单选组内是否有且只有一个单选钮可选
  （31）如果单选组内无单选钮可选，这种情况是否允许存在
  （32）复选框组内是否允许多个复选框（包括全部可选）可选
  （33）如果复选框组内无复选框可选，这种情况是否允许存在
  （34）文本框及某些控件拒绝输入和选择时显示区域是否变灰或按既定规约处理
  （35）密码输入框是否按掩码的方式显示
  （36） Cancel之类的按钮按下后，控件中的数据是否清空复原或按既定规约处理
  （37） Submit之类的按钮按下后，数据是否得到提交或按既定规约处理
  （38）异常信息表述是否正确
  （39）软件是否按预期方式处理错误
  （40）文件或外设不存在的情况下是否存在相应的错误处理
  （41）软件是否严格的遵循外设的读写格式
  （42）画面文字（全、半角、格式、拼写）是否正确
  （43）产生的文件和数据表的格式是否正确
  （44）产生的文件和数据表的计算结果是否正确
  （45）打印的报表是否符合既定的格式
  （46）错误日志的表述是否正确
  （47）错误日志的格式是否正确
  
  文章来源:http://hrbtester.blog.sohu.com/53931752.html
  
  [ 本帖最后由 linwenyan 于 2007-12-26 21:13 编辑 ]

  查看(49) 评论(1)

• 恰当选择软件测试自动化方案(转)

  2007-12-27

  随着测试流程的不断规范以及软件测试技术的进一步细化，软件测试自动化已经日益成为一支不可忽视的力量。能否借助于这支外在力量以及如何借助于这支力量来规范企业测试流程、提高特定测试活动的效率，正是本 期所要讨论的话题。
  
  目前，软件测试自动化的研究领域主要集中在软件测试流程的自动化管理以及动态测试的自动化（如单元测试、功能测试以及性能测试方面）。在这两个领域，与手工测试相比，测试自动化的优势是明显的。首先自动化测试可以提高测试效率，使测试人员更加专注于新的测试模块的建立和开发，从而提高测试覆盖率; 其次，自动化测试更便于测试资产的数字化管理，使得测试资产在整个测试生命周期内可以得到复用，这个特点在功能测试和回归测试中尤其具有意义; 此外，测试流程自动化管理可以使机构的测试活动开展更加过程化，这很符合CMMI过程改进的思想。根据Oppenheimer Funds的调查，在2001年前后的3年中，全球范围内由于采用了测试自动化手段所实现的投资回报率高达1500％。
  
  
  方案选型六大原则
  然而存在优势是否就一定意味着选择自动化测试方案都能为企业带来效益回报呢？也不尽然，任何一种产品化的测试自动化工具，都可能存在与某具体项目不甚贴切的地方。再加上，在企业内部通常存在许多不同种类的应用平台，应用开发技术也不尽相同，甚至在一个应用中可能就跨越了多种平台; 或同一应用的不同版本之间存在技术差异。所以选择软件测试自动化方案必须深刻理解这一选择可能带来的变动、来自诸多方面的风险和成本开销。
  
  以下笔者给出企业用户进行软件测试自动化方案选型的参考性原则，这些原则是从笔者实际工作中凝练而成的，它包括以下六个方面的建议:
  
  选择尽可能少的自动化产品覆盖尽可能多的平台，以降低产品投资和团队的学习成本;
  测试流程管理自动化通常应该优先考虑，以满足为企业测试团队提供流程管理支持的需求;
  在投资有限的情况下，性能测试自动化产品将优先于功能测试自动化被考虑;
  在考虑产品性价比的同时，应充分关注产品的支持服务和售后服务的完善性;
  尽量选择趋于主流的产品，以便通过行业间交流甚至网络等方式获得更为广泛的经验和支持;
  应对测试自动化方案的可扩展性提出要求，以满足企业不断发展的技术和业务需求。
  实战模拟
  
  以下笔者结合一个典型的企业客户，剖析其适用的软件测试自动化方案选型过程。
  
  1．公司背景介绍
  
  A公司是一家大型保险公司，拥有近20个城市的分公司，并在其中5个城市建立了IT支持中心。平均每年的上线应用数量在20个左右（新业务系统和原有业务系统的主要版本发布）。目前A公司的专职测试团队人数不足30人，而且测试团队的测试人员技能参差不齐，目前测试只是作为项目上线前的一道工序而已。在测试团队内部也几乎没有自动化的手段，主要依靠手工测试。由于已上线应用系统的问题，开发团队必须分出一部分资源去维护和修复上线应用，而同时测试团队的测试成果和效率却无法和这些应用质量挂钩，也更无从谈起对软件质量的控制。所以，A公司决定在软件质量和测试方面进行投入，他们考虑以下几方面:
  
  引进软件测试流程管理的自动化，提高软件测试过程的管理水平，使软件测试和软件开发一样可被评估、被衡量。
  实现性能测试自动化，所有应用上线之前必须有应用性能风险评估报告和相关部门的确认
  逐步实现功能测试的自动化，在目前人员配置的情况下，把部分手工测试变成自动化测试，提高测试可信度，降低人为错误。
  通过软件测试自动化，管理软件测试中的案例、缺陷、报告等资产，进一步提升软件测试的效率并建立测试基础库。
  在规划中，将来的2～3年内使所有的应用系统上线都必须有数字化的测试数据作为依据。
  2．公司应用系统的情况
  
  由于保险公司的业务种类繁多，同时在经过了几十年的经营后，公司内的应用系统从早期的终端方式到现代的J2EE和.NET等应有尽有，鱼龙混杂。IT部门已经建立的3年规划，即在未来的3年时间内将所有终端和C/S方式的应用转换成B/S架构，但当前仍然需要对这些旧应用系统进行维护，以保证业务的顺利进行。对于开发部门来说，目前新应用开发基本上已经以B/S架构为主，主要是基于J2EE架构的Web HTTP应用和部分Window.NET Form的应用。
  
  3．公司软件测试现状
  
  企业机构在做测试自动化选型时一定要考虑清楚企业内部哪些部分可以实施自动化、哪些部分暂不实施自动化、哪些部分仅在某几个项目做自动化试点。切忌匆忙上马或盲目否定，缺乏实事求是的理性思考。
  
  测试部门目前仅负责系统测试和对用户验证测试进行管理，对于之前的单元测试和集成测试主要由开发团队中划分出的一部分临时测试人员完成。由于缺乏监测手段，测试部门也无法收集和确定集成测试和单元测试的完成情况，在整个软件测试过程中，业务需求是由开发部门通过Rational RequisitePro进行管理，但测试需求目前尚没有提出要求，测试案例主要通过在公司公用的文件服务器中的目录管理方式管理，对测试中缺陷流程等管理主要依靠邮件的流转进行处理。目前90％以上的测试是通过Excel和Word等测试案例文档来完成，测试人员对软件测试自动化的认识仅停留在“记录＋回放”的认识上。
  
  4．可供选择的方案
  
  方案A: A公司可以采用美科利（Mercury）公司产品为主的软件测试自动化方案。
  
  依照原先的邮件流转过程配置TestDirector缺陷管理流程，为每个保险业务的开发小组和测试团队分配相应的用户许可证，取消原有邮件方式。
  部署Mercury Quick Test Professional，以便完成应用程序相关功能测试。
  部署Mercury Load-Runner。从测试团队中分化出专职的性能测试自动化工程师和小组，和业务部门协调，建立A公司应用系统上线性能指标，通过LoadRunner给出测试指标。
  建议A公司成立专门的质量控制部门，对TestDirector中的数据定期进行分析，建立相关质量模型，以便于企业量化管理和过程改进。
  方案B: A公司也可以采用IBM Rational产品为主的软件测试自动化方案。
  
  采用Rational Test manager来进行整个测试流程的管理，为相关开发和测试小组成员分配相应权限，改变以前通过邮件以及Word、Excel文档管理测试的工作方式。
  部署Rational Robot，用它来完成功能相关的测试工作以及新版本发布时的冒烟测试。此外，Rational Robot也能较好地完成性能相关测试。统一的操作方式降低了工具的学习周期和培训带来的大笔开销。
  部署Rational Purify plus，使测试工作前移到开发阶段。由于Purify plus能较好地支持白盒测试，编程人员在编码阶段引入的错误能尽早被检测到，这大幅降低了后期测试的开销。
  建议A公司成立专门的质量控制部门，对Test manager中的数据定期进行分析，建立相关质量模型，以便于企业量化管理和过程改进。
  方案C: A公司也可以采用开源软件为主的软件测试自动化方案。
  
  采用Bugzilla来进行Bug跟踪管理，采用Bugzilla Test Runner进行测试用例管理，采用CVS进行测试资源的配置管理。
  采用MaxQ和WebInject对B/S结构的应用系统进行功能测试。
  采用DBMonster、Open－STA、LoadSim进行性能相关测试。
  可采用Xunit架构的开源工具对不同语言的程序单元进行单元测试。
  建议A公司成立专门的开源软件维护小组，以解决可能会碰到的工具维护工作。
  建议A公司成立专门的质量控制部门，对Bugzilla、Test Runner、CVS中的数据定期进行分析，建立相关质量模型，以便于企业量化管理和过程改进。
  5． 方案评价
  
  由于不同客户在组织架构、员工素质以及流程管理水平等方面的不同，我们很难用一个实例、一两句话来说明不同解决方案的适用性。在上面的例子中，笔者给出了3种可行的方案，具体选择哪一个，需要仔细权衡。这里笔者给出一般性的意见，对于不想受制于某个测试自动化厂家的企业，开源绝对是一个理想的选择。此外，它不需要支付成本，工具的源代码可以随意修改，因而具有较好的灵活性。但开源工具的弊端也是明显的: 缺乏使用培训和技术支持，工具的用户界面一般也较为粗糙。而对于那些比较看重培训和售后支持的企业，笔者建议选择IBM Rational或Mercury或其他厂家的产品。这样虽然需要支付一部分费用，但省去了工具维护所需要的大量工作。至于具体选择哪个厂家的产品为好，笔者尚无结论性意见。相信读者朋友都有一些见仁见智的看法，不妨来信交流。
  
  实施中的注意事项
  
  首先，一个企业实施测试自动化，绝对不是拍脑袋说干就能干好的，它不仅涉及测试工作本身流程上、组织结构上的调整与改进，甚至也包括需求、设计、开发、维护及配置管理等其他方面的配合。如果对这些必要的因素没有考虑周全的话，必然在实施过程中处处碰壁，既定的实施方案也无法开展。其次，尽管自动化测试可以降低人工测试的工作量，但并不能完全取代手工测试。100％的自动化测试只是一个理想目标，根据笔者的经验，即便一些如SAP、Oracle ERP等测试库规划十分完善的套件，其测试自动化率也不会超过70％。所以一味追求测试自动化只会给企业带来运作成本的急剧上升。再次，实施测试自动化需要企业有相对规模的投入，对企业运作来说，投入回报率将是决定是否实施软件测试自动化的最终指挥棒，笔者建议企业在决定实施软件测试自动化之前，必须要做量化的投资回报分析。此外，实施软件测试自动化并不意味着必须采购强大的自动化软件测试工具或自动化管理平台，毕竟软件质量的保证不是依靠产品或技术，更多的因素在于高素质的人员和合理有效的流程。
  
  文章来源:http://www.uml.org.cn/Test/200712202.asp

  查看(43) 评论(1)

• 11种方法检测软件可靠性(转)

  2007-12-27

  软件的安全可靠性是衡量软件好坏的一个重要标准，安全性指与防止对程序及数据的非授权的故意或意外访问的能力有关的软件属性，可靠性指与在规定的一段时间和条件下，软件能维持其性能水平能力有关的一组属性。具体我
  们可以从以下几个方面来判断：
  
  1.用户权限限制。软件是否按功能模块划分用户权限，权限划分是否合理，考察超级用户对各个用户的权限管理是否合理，包括修改用户的登录资料等。
  
  2.用户和密码封闭性。软件对用户名和密码有无校验，有无保护措施，尤其对密码有无屏蔽功能。
  
  3.系统对用户错误登录的次数限制。软件对用户错误登录有无次数限制，一般做法是连续三次登录失败就退出系统。
  
  4.留痕功能。软件是否提供操作日志，比如某用户登录的时间，查询、修改或删除的动作以及离开的时间等。
  
  5.屏蔽用户操作错误。考察对用户常见的误操作的提示和屏蔽情况，例如可否有效避免日期的录入错误或写入无效的日期。
  
  6.错误提示的准确性。当用户操作错误或软件发生错误时，能否有准确清晰的提示，使用户知道造成错误的原因。例如当用户未输入完有效信息时存盘，系统应当给出关于未输入项的提示。
  
  7.错误是否导致系统异常退出。考察软件运行的稳定性，当软件发生一般错误或严重错误时，软件是否会自动退出。
  
  8.数据备份与恢复手段。主要针对有数据存储需要的软件，有的软件依靠数据库操作系统本身的备份与恢复机制，这需要用户具备一定的操作知识；好的软件会提供备份与恢复的操作，不需要用户直接对数据库系统进行操作。
  
  9.输入数据有效性检查。当用户输入的数据有错时，软件应能判断数据的有效性，避免无效数据的生成。
  
  10.异常情况的影响。在程序运行过程中进行掉电等试验，考查数据和系统的受影响程度；若受损，是否提供补救工具，补救的情况如何。
  
  11.网络故障对系统的影响。当网络中断连接时，是否会造成数据的丢失。
  
  以上一些方面是中国软件评测中心在大量的软件测试实践中提炼出来的比较有共性的项目，对于不同类型的软件，在安全可靠性方面还有更多的评测指标，并且依据实际情况侧重点有所不同。
  
  文章来源:http://www.uml.org.cn/Test/200712141.asp

  查看(52) 评论(1)