本人刚才开始做软件测试,想在这个行业有所成长,希望各们前辈多多指点!

发布新日志

  • 过来看看

    2008-10-29 09:10:45

        最近比较忙,家时也不能上网了,都二个多月没上来看看了,朋友们都好吧!

  • 转"手机短信测试"

    2008-08-22 19:56:24


    系统测试方法分为:功能测试,一致性测试,性能测试,压力测试,容量测试,安全性测试,恢复性测试,备份测试,GUI测试,健壮性测试,兼容性测试,可用性测试,可安装性测试,文档测试,在线帮助测试以及数据转换测试等。
          从手机软件系统测试的角度分为:功能模块测试,交叉事件测试,压力测试,容量性能测试,性能测试和用户手册测试等。
         由于笔者执行手机软件测试工作中,短消息和电话测试的较多,下面就以短消息为例来阐述,手机软件测试的一般方法和测试的要求,来供大家参考。
    一.短消息[SMS]的基本功能测试
    1、短消息的基本功能:是指短消息的编辑,删除,保存,收发,显示,以及各种按钮等功能的正常实现。
    2、测试要求和执行:一般根据测试案例或软件本身的流程就可以完成短消息的基本功能测试。     
    二.短消息的交叉事件测试
    1、交叉测试:又叫事件或冲突测试,是指一个功能正在执行过程中,同时另外一个事件或操作对该过程进行干扰的测试。例如通话过程中接收到短信或来响闹。应该以执行干扰的冲突事件不会导致手机死机或花屏等严重的问题出现为Pass的标准。
    2、测试要求和执行:干扰要恰到好处,准确,否则很难发掘出深层次的软件缺陷。
    三.短消息的压力性能测试
    1、压力测试:又叫边界值容错测试或极限负载测试,即测试过程中,已经达到某一软件功能的最大容量,边界值或最大的承载极限,仍然对其进行相关操作。例如连续进行短信的接收和发送,超过收件箱和PIM卡所能存储的最大的条数,仍然进行短消息的接收或发送,以检测软件在超常态条件下的表现,来评估用户能否接受。
    2、测试要求和执行:可以考虑进行自动化测试
    四.短消息的容量性能测试
    1、容量测试:又叫满记忆体测试,包括手机的用户可用内存和SIM/PIM卡的所有空间被完全使用的测试。此时再对可编辑的模块进行和存储空间有关的任何操作测试,如果软件的极限容量状态下处理不好,有可能导致死机或严重的花屏等问题的出现。
    2、测试要求和执行:可以考虑进行自动充满记忆体测试,要对不同品牌和不同容量大小的SIM/PIM卡进行测试
    五. 短消息的兼容性能测试
    兼容性测试:也就是不同品牌手机,不同网络,不同品牌和不同容量大小的SIM/PIM卡之间的互相兼容的测试,以短消息为例:中国电信的小灵通接收到从中国移动或中国联通GSM发来的短消息,接收,显示和回复功能是否正常等;

  • QTP

    2008-08-19 22:00:05

    一:如何破解qtp9.5版本

    获取镜像文件 T6510-15059.iso ,使用虚拟光驱打开。

    打开虚拟光驱下\QuickTest\CHS目录中inst.bat文件安装,如果提示有文件未安装,选\QuickTest\CHS\prerequisites下对应文件安装后继续使用inst.bat文件安装QTP9.5。

    安装成功后打开help-about QuickTest Professional-选中所有,查看license。如果已经破解,应该为Unlimited。

    如果没有被破解,建立2个文件夹,使得目录如下C:\Program Files\Common Files\Mercury Interactive\License Manager。使用qtp8.2的破解文件mgn-mqt82.exe,运行后在License Manager文件夹下面出现lservrc文件,使用写字板打开,拷出截至#在内的第一行字符,贴到9.5中做为license。

    二:qtp8.2版本中文教程

    QTP8.2中文版Tutorial.chm

    下载地址:http://bbs.51testing.com/viewthread.php?tid=44976

    三:相关视频网站

    qtp,lr等相关视频:http://www.3atesting.com/mv/

  • QTP自动化测试流程(转)

    2008-08-05 14:17:19

     

  • 51Testing丛书连载:(十二) QTP自动化测试实践

    2008-07-30 21:36:05

     

            另外一种自动化的功能测试工具是基于浏览器和DOM对象模型开发的,例如Selenium、Watir等,这些测试工具直接访问Web浏览器,利用脚本语言操纵浏览器和Web页面中包含的DOM对象,从而达到模拟用户控制浏览导航、页面元素的操纵等效果,并且直接获取DOM对象的属性,从而获得Web页面元素的各种属性,通过这些属性可判断测试步骤的结果是否正确。图3.3所示的是可作为插件嵌入到Mozilla Firefox浏览器中的Selenium IDE的测试界面。

    软件测试
    图3.3  Selenium IDE的测试界面

            HTML DOM(Document Object Model)是一个HTML文档的编程接口,它定义了HTML的标准对象集合,并且定义了标准的访问和操纵HTML对象的方式。HTML DOM接口让测试人员可以访问和操纵HTML文档的内容。图3.4所示的界面是使用了一个名为“IE DOM Inspector”的工具查看到的Web页面中的DOM对象。

    软件测试 
    图3.4  IE DOM Inspector的界面

            如果熟悉和了解DOM的原理,那么完全可以自己动手编写一个基于浏览器和DOM的Web页面自动化测试工具,例如,下面的C#代码就是一个简单的例子:

    using System;
    using System.Collections.Generic;
    using System.ComponentModel;
    using System.Data;
    using System.Drawing;
    using System.Text;
    using System.Windows.Forms;
    using System.Diagnostics;
    using System.Threading;
    // 引用Microsoft.mshtml的HTML接口
    using mshtml;
    // 引用IE对象
    using SHDocVw;

    namespace WebAutomatedTest1
    {
        public partial class Form1 : Form
        {
            static AutoResetEvent documentComplete = new AutoResetEvent(false);
            public Form1()
            {
                InitializeComponent();
            }
            private void button1_Click(object sender, EventArgs e)
            {
                InternetExplorer ie = null;
                // 启动IE的进程
                Process p = Process.Start("iexplore.exe", "about:blank");
                // 等待一段时间,让IE启动
                Thread.Sleep(3000);
                if (p == null)
                {
                    MessageBox.Show("不能启动IE!");
                    return;
                }
                SHDocVw.ShellWindows allBrowsers = new SHDocVw.ShellWindows();
                // 附加到IE进程
                int i = 0;
                while (i < allBrowsers.Count && ie == null)
                {
                    InternetExplorer browser = (InternetExplorer)allBrowsers.Item(i);
                    if (browser.HWND == (int)p.MainWindowHandle)
                        ie = browser;
                    ++i;
                }
                if (ie == null)
                {
                    MessageBox.Show("不能附加到IE!");
                    return;
                }
                ie.DocumentComplete += new DWebBrowserEvents2_DocumentCompleteEventHandler(ie_DocumentComplete);
                object nil = new object();
                 ie.Navigate("http://127.0.0.1:9462/WebUT/default.aspx",ref nil,ref nil,ref nil,ref nil);
                documentComplete.WaitOne();
                HTMLDocument Doc = (HTMLDocument)ie.Document;
                 HTMLInputElement textBox = (HTMLInputElement)Doc.getElementById("TextBox1");
                textBox.value = "123";
                 HTMLInputElement button = (HTMLInputElement)Doc.getElementById("Button1");
                button.click();
                // 验证,如果Label1的值等于123,则表示测试通过
                 HTMLSpanElement label = (HTMLSpanElement)Doc.getElementById("Label1");
                if (label.innerText == "123")
                {
                    MessageBox.Show("测试通过!");
                }
                else
                {
                    MessageBox.Show("测试不通过!");
                }
            }
            private static void ie_DocumentComplete(object pDisp, ref object URL)
            {
                documentComplete.Set();
            }
        }
    }



    连载  连载  载三  连载四  连载  连载六  连载七  连载八  连载九  连载十  连载十一

    本文选自:《51Testing软件测试作品系列》之二的 QTP自动化测试实践》,本站经电子工业出版社和作者的授权,近期将进行部分章节的连载,敬请期待!

    版权声明:51Testing软件测试网及相关内容提供者拥有51testing.com内容的全部版权,未经明确的书面许可,任何人或单位不得对本网站内容复制、转载或进行镜像。51testing软件测试网欢迎与业内同行进行有益的合作和交流,如果有任何有关内容方面的合作事宜,请联系我们。


  • 51Testing丛书连载:(十一) QTP自动化测试实践

    2008-07-30 21:35:07

            测试工具的优势在于可部分地替代人工的测试过程,能重复不断地执行,能精确判断数值和字符对象。自动化测试工具把测试用例用自动的方式执行,例如,自动地产生数据,自动地打开应用程序,自动地查找控件,自动地输入数据,自动地操作控件,自动地收集测试结果,自动地与预期结果进行比较等。
            自动化功能测试工具可基于GUI层面进行测试,也可基于代码层面进行测试。只要实现了自动化执行测试用例,自动化地检查测试数据的测试工具,替代人工进行测试步骤的执行,从而验证应用程序是否满足了特定功能的测试工具,都可以称为自动化功能测试工具。
    3.3.1  基于代码层面的功能自动化测试工具
            基于代码层面的功能自动化测试工具主要是一些单元测试工具,例如JUnit、NUnit、MSTest等,这些工具直接访问被测试的应用程序的代码,对其中的类和函数进行调用,输入各种测试数据,检查函数的返回值,通过比较返回值与期待的值是否一致来判断测试是否通过。图3.2所示的是Visual Studio.NET 2005中的单元测试管理界面。
     

    图3.2  Visual Studio.NET 2005中的单元测试管理界面
            这种类型的工具主要实现了测试代码框架产生的自动化,例如,下面代码是Visual Studio.NET 2005中的单元测试框架MSTest为某个类的方法自动产生的单元测试代码框架:
    // 以下代码由 Microsoft Visual Studio 2005 生成。
    // 测试所有者应该检查每个测试的有效性。
    using Microsoft.VisualStudio.TestTools.UnitTesting;
    using System;
    using System.Text;
    using System.Collections.Generic;
    using AUT;
    namespace TestProject1
    {
        /// <summary>
        ///这是 AUT.Form1 的测试类,旨在包含所有 AUT.Form1 单元测试
        ///</summary>
        [TestClass()]
        public class Form1Test
        {
            private TestContext testContextInstance;
            /// <summary>
            ///获取或设置测试上下文,上下文提供有关当前测试运行及其功能的信息。
            ///</summary>
            public TestContext TestContext
            {
                get
                {
                    return testContextInstance;
                }
                set
                {
                    testContextInstance = value;
                }
            }

            #region 附加测试属性
            //
            //编写测试时,可使用以下附加属性:
            //
            //使用 ClassInitialize 在运行类中的第一个测试前先运行代码
            //
            //[ClassInitialize()]
            //public static void MyClassInitialize(TestContext testContext)
            //{
            //}
            //
            //使用 ClassCleanup 在运行完类中的所有测试后再运行代码
            //
            //[ClassCleanup()]
            //public static void MyClassCleanup()
            //{
            //}
            //
            //使用 TestInitialize 在运行每个测试前先运行代码
            //
            //[TestInitialize()]
            //public void MyTestInitialize()
            //{
            //}
            //
            //使用 TestCleanup 在运行完每个测试后运行代码
            //
            //[TestCleanup()]
            //public void MyTestCleanup()
            //{
            //}
            //
            #endregion

            /// <summary>
            ///Add (int, int) 的测试
            ///</summary>
            [DeploymentItem("AUT.exe")]
            [TestMethod()]
            public void AddTest()
            {
                Form1 target = new Form1();
                TestProject1.AUT_Form1Accessor accessor =
    new TestProject1.AUT_Form1Accessor(target);
                int i = 0; // TODO: 初始化为适当的值
                int j = 0; // TODO: 初始化为适当的值
                int expected = 0;
                int actual;
                actual = accessor.Add(i, j);
                Assert.AreEqual(expected, actual, "AUT.Form1.Add 未返回所需的值。");
                Assert.Inconclusive("验证此测试方法的正确性。");
            }
        }
    }
            在代码框架的背后,单元测试框架负责查找和调用被测试的类和方法,通过代码反射机制可以访问到被测试代码中的所有方法和属性。另外,单元测试框架会提供一系列的Assert类,使用这些Assert类可以简化测试结果检查、判断的工具。
            提示:在执行单元测试时,单元测试框架负责加载包含测试类的程序集文件,通过查找里面的测试类和测试方法标识来加载测试方法,例如,上面代码中的“[TestMethod()]”就是用于标识其中的测试方法。

    连载  连载  载三  连载四  连载  连载六  连载七  连载八  连载九  连载十  连载十二

    本文选自:《51Testing软件测试作品系列》之二的 QTP自动化测试实践》,本站经电子工业出版社和作者的授权,近期将进行部分章节的连载,敬请期待!

    版权声明:51Testing软件测试网及相关内容提供者拥有51testing.com内容的全部版权,未经明确的书面许可,任何人或单位不得对本网站内容复制、转载或进行镜像。51testing软件测试网欢迎与业内同行进行有益的合作和交流,如果有任何有关内容方面的合作事宜,请联系我们。



    TAG: QTP 自动化测试
  • 51Testing丛书连载:(十) QTP自动化测试实践

    2008-07-30 21:33:24

     

    连载  连载  载三  连载四  连载  连载六  连载七  连载八  连载九  连载十一  连载十二

    本文选自:《51Testing软件测试作品系列》之二的 QTP自动化测试实践》,本站经电子工业出版社和作者的授权,近期将进行部分章节的连载,敬请期待!

    版权声明:51Testing软件测试网及相关内容提供者拥有51testing.com内容的全部版权,未经明确的书面许可,任何人或单位不得对本网站内容复制、转载或进行镜像。51testing软件测试网欢迎与业内同行进行有益的合作和交流,如果有任何有关内容方面的合作事宜,请联系我们。


  • 51Testing丛书连载:(九) QTP自动化测试实践

    2008-07-30 21:32:10

     

            软件自动化测试工具是实现软件自动化测试必不可少的关键,因此,选择一个优秀的、适合自己的测试项目实际情况的测试工具是实现成功自动化测试的第一步。本章介绍自动化测试工具的分类,以及如何选择一个合适的自动化测试工具,并且介绍自动化测试工具的基本原理。
    3.1  自动化测试工具类型
            测试工具的种类很多,有用于管理测试的,有帮助实现测试自动化的,有开源的,有免费共享的。软件测试工具按照其用途,可大致分成以下几大类:
     测试管理工具
     自动化功能测试工具
     性能测试工具
     单元测试工具。
     白盒测试工具。
     测试用例设计工具。
            如果按测试工具的收费方式,又可分为以下几类。
     商业测试工具。
     开源测试工具。
     免费测试工具。
    3.1.1  商业测试工具
            商业测试工具的特点是需要花钱购买,但是会相对成熟和稳定,并且有一定的售后服务和技术支持。但是,由于其价格昂贵,并不是每一个企业都能负担得起。
            商业测试工具主要集中在GUI功能测试和性能测试方面,目前流行的基于GUI的功能自动化测试工具有RobotQTP、TestComplete等。各种自动化测试工具实现的功能基本相同,但是在IDE、脚本开发语言、支持的脚本开发方式、支持的控件等方面则有很多不同之处。
    3.1.2  开源测试工具
            开源软件是指软件的源代码是公开发布的,通常是由自愿者开发和维护的软件。开源测试工具是测试工具的一个重要分支。越来越多的软件企业开始使用开源测试工具。但是开源并不意味着完全的免费,开源测试工具同样需要考虑使用的成本,并且在某些方面可能要比商业测试工具的成本还要高。
            商业工具的价格在不断地提高。图3.1为WinRunner近几年的价格变化图。

    图3.1  WinRunner近几年的价格变化
            可以看到,价格在不断地增长。这对于那些中小型软件企业而言,无疑加大了测试的成本。开源测试工具相对于商业测试工具拥有以下优势:
     相对低的成本:大部分开源测试工具可免费使用,只要不做商业用途即可。
     更大的选择余地:可以打破商业测试工具的垄断地位,给测试人员更多的选择空间。
     可自己改造:源代码开放,意味着可对其进行修改、补充和完善,可对其进行个性化改造。
            虽然开源测试工具拥有一定的优势,但是,同时也存在很多不足之处,包括以下几方面。
     安装和部署相对困难:大部分开源测试工具的安装配置过程比较烦琐,需要测试人员付出一定的努力。
     易用性:开源测试工具在易用性、用户体验方面做得不够完善。
     稳定性:部分开源测试工具的稳定性不够强。
     学习和获取技术支持的难度:大部分开源测试工具不提供培训指导和技术支持服务,联机帮助和用户手册不够完善,增加了测试人员的学习难度。
    3.1.3  自主开发测试工具
            目前,很多软件测试组织其实已经具备了自己动手开发测试工具的条件:
     市场对于测试工具的接受程度在不断提高,人们对测试工具的认识不断加强和深入,对测试工具原理的理解不断提高。从脚本化到数据驱动,再到关键字驱动等,很多新的测试工具理念被引入并被广泛接受。
     由于技术的成熟,测试工具变得容易构建。软件系统现在变得更容易测试,可测试性更强,COM、XML、HTTP、HTML等标准化的接口使得测试更加容易进行。托管程序(例如Java、.NET)的反射机制使得查找定位对象,以及捕捉对象和操作对象更加容易。
             一些开源的框架可以被利用。利用开源框架平台来组合、搭建适合自己测试项目使用的测试平台和测试框架。
            自己动手开发测试工具的优势有以下方面。
     购买成本为零。
     简便:只需要开发自己需要的那部分功能。
     个性化:可自己定制需要的功能,随时修改,配置项目组成员的使用习惯。
     可扩展性:可随时增加新的功能。
     可充分利用项目组熟悉的语言开发,利用自己的技术优势。
     可使用自己熟悉的脚本语言,不需要使用商业工具提供的“厂商脚本语言”。
            然而,虽然自己动手设计和开发测试工具有很多好处,但是必须考虑随之而来的成本问题。自己开发测试工具的成本只是开发时间和人员投入的成本,以及维护的成本。当然,如果把测试工具推广到其他项目组,则也会有学习和培训成本。另外,需要考虑测试工具的实用性,不要做一个大而全的、面面俱到的、很多功能基本上不会被用到的测试工具。

    连载  连载  载三  连载四  连载  连载六  连载七  连载八  连载十  连载十一  连载十二

    本文选自:《51Testing软件测试作品系列》之二的 《QTP自动化测试实践》,本站经电子工业出版社和作者的授权,近期将进行部分章节的连载,敬请期待!

    版权声明:51Testing软件测试网及相关内容提供者拥有51testing.com内容的全部版权,未经明确的书面许可,任何人或单位不得对本网站内容复制、转载或进行镜像。51testing软件测试网欢迎与业内同行进行有益的合作和交流,如果有任何有关内容方面的合作事宜,请联系我们。

  • 51Testing丛书连载:QTP自动化测试实践

    2008-07-30 21:30:47

    8.5  使用数据驱动器来参数化测试
            为了简化测试脚本参数化的过程,QTP还提供了名为“Data Driver”的功能,可自动检测脚本中可能需要进行参数化的变量。
    8.5.1  数据驱动器的使用方法
            “Data Driver”可以帮助测试人员快速找到需要参数化的测试对象、检查点的数据。例如,对于如图8.41所示的录制脚本,选择菜单“Tools | Data Driver”,出现如图8.42所示的界面。

    图8.41 待参数化的测试步骤

    图8.42  数据驱动器
            在这个界面中,列出了测试步骤中所有可能需要进行参数化的变量。

    8.5.2  数据驱动向导
    单击“Parameterize”按钮,出现如图8.43所示的数据驱动向导。

    图8.43  数据驱动向导
    单击“下一步”按钮,则出现如图8.44所示的界面。

    图8.44  参数化选定的测试步骤
    在这个界面中的左边窗口,定位到测试步骤所操作的界面控件,在右边显示参数化的名称和数据,单击“编辑”按钮,可在如图8.45所示的界面中进一步设置参数。

    字体:        | 上一篇 下一篇 | 打印  | 我要投稿  | 每周一问,答贴有奖

    图8.45  参数化设置
    单击“OK”按钮,回到向导界面,单击“下一步”按钮,则出现如图8.46所示的界面,表明测试步骤的参数设置完成。其他测试步骤也可按类似的方式一步步地完成参数化。

    图8.46  完成参数化

    连载  连载  载三  连载四  连载  连载六  连载七  连载九  连载十  连载十一  连载十二

    本文选自:《51Testing软件测试作品系列》之二的 《QTP自动化测试实践》,本站经电子工业出版社和作者的授权,近期将进行部分章节的连载,敬请期待!

    版权声明:51Testing软件测试网及相关内容提供者拥有51testing.com内容的全部版权,未经明确的书面许可,任何人或单位不得对本网站内容复制、转载或进行镜像。51testing软件测试网欢迎与业内同行进行有益的合作和交流,如果有任何有关内容方面的合作事宜,请联系我们。




     

  • 用TestComplete实现一个关键字驱动测试框架(转载)

    2008-07-30 20:41:11

    用TestComplete实现一个关键字驱动测试框架
         最近在做使用TestComplete做一个自动化测试项目的时候,发现在TestComplete中,可以利用其中的FindChild方法来实现一个简单的关键字驱动的框架,方法如下:
    (1)在Excel编写测试关键字。
    在Excel文件中编写测试关键字,包括测试对象、测试操作、输入的参数等,如图所示:
     
    (2)编写测试脚本,读入Execl中的测试关键字。
    // 全局的变量数组,用于存储从Excel读入的测试关键字
    Var KeyWord_TestObject,KeyWord_Operation,KeyWord_Parameters;
    //.............................................................................
    // 目的:通过ADO查询Excel数据
    // 输入参数:
    //           ExcelFilePath :Excel文件的路径
    //           QueryString:查询语句
    // 返回结果:
    //           返回所有关键字数据,赋值给KeyWord_TestObject,KeyWord_Operation,KeyWord_Parameters这3个全局的变量数组
    // 注意事项:
    // 作者:陈能技
    // 日期:2008-6-3
    //.............................................................................
    Function ReadKeyWordFromExcel(ExcelFilePath,QueryString);
     Var ConStr,Connection,RS,ClassObjArray,LineIndex,ClassObject:OleVariatn;
    begin
     // 定义连接串
     ConStr := 'Provider=Microsoft.Jet.OLEDB.4.0;Data Source=%S;Extended Properties=Excel 8.0';
     ConStr := Utilities.Format(ConStr,[ExcelFilePath]);
     Connection := Sys.OleObject('ADODB.Connection');
     // 打开连接
     Connection.Open(ConStr);
     // 执行查询操作
     RS := Connection.Execute(QueryString);
     // 创建变量数组
     KeyWord_TestObject := CreateVariantArray(0,0);
     KeyWord_Operation := CreateVariantArray(0,0);
     KeyWord_Parameters := CreateVariantArray(0,0);
     LineIndex := 0;
     // 循环读入所有数据
     While Not RS.EOF do
     begin
        Inc(LineIndex);
        // 动态修改数组大小
        VarArrayRedim(KeyWord_TestObject,LineIndex-1);
        VarArrayRedim(KeyWord_Operation,LineIndex-1);
        VarArrayRedim(KeyWord_Parameters,LineIndex-1);  
        // 赋值
        KeyWord_TestObject[LineIndex-1] := RS['TestObject'].Value;
        KeyWord_Operation[LineIndex-1] := RS['Operation'].Value;
        KeyWord_Parameters[LineIndex-1] := RS['Parameters'].Value;   
        // 下一条数据
        RS.MoveNext;
     end;
     RS.Close;
     // 关闭连接
     Connection.Close;
    end;
    Procedure Test_ReadKeyWordFromExcel;
     Var I : OleVariant;
    begin
     ReadKeyWordFromExcel('D:\Code\MyTestSuite\Data\KeyWord.xls','Select * from [KeyWord$]');
     For I := 0 to VarArrayHighBound(KeyWord_TestObject,1) do
     begin
        Log.Message(VarToStr(KeyWord_TestObject[I])+ '   | '
                   + VarToStr(KeyWord_Operation[I])+' | '
                   + VarToStr(KeyWord_Parameters[I]));
     end; 
    end;
     
    (3)封装一个函数,用于根据Excel读入的测试关键字创建可用的测试对象。
    Uses CheckUIPerformance;
    //.............................................................................
    // 目的:返回当前进程中的指定测试对象
    // 输入参数:
    //           Process :进程对象
    //           TestObject:测试对象的描述
    // 返回结果:
    //           返回当前进程中的指定测试对象
    // 注意事项:
    // 作者:陈能技
    // 日期:2008-6-3
    //.............................................................................
    Function getObject(Process,TestObject);
    var
     PropArray, ValuesArray;
    begin
     PropArray := CreateVariantArray(0, 0);
     ValuesArray := CreateVariantArray(0, 0);
     PropArray[0] :='FullName';
     ValuesArray[0] := TestObject;
     // 调用 FindTestObject 函数,返回当前进程中的指定测试对象
     Result := FindTestObject(Process,PropArray,ValuesArray);
    end;
     
    这里调用了CheckUIPerformance脚本中编写的FindTestObject函数,该函数用于根据测试对象的描述信息查找指定进程中的测试对象,脚本如下:
    Function FindTestObject(Process,PropArray,ValueArray);
     var res;
    begin
     Result := False;
     // 查找指定的测试对象
     Process.Refresh();
     res := Process.FindChild(PropArray, ValueArray, 1000);
     // 返回测试对象
     if res.Exists then
     begin
        Result := res;
        Log.Message('找到测试对象: ' + res.FullName)
     end
     else
        Log.Message('未找到测试对象');
    end;
     
    (4)封装一个函数,用于根据Excel读入的测试关键字执行测试操作。
    //.............................................................................
    // 目的:执行测试操作
    // 输入参数:
    //           TestObject :测试对象
    //           Operation:测试操作的描述
    //           Parameters:测试操作对应的参数
    // 返回结果:无
    // 注意事项:
    // 作者:陈能技
    // 日期:2008-6-3
    //.............................................................................
    Function DoOperation(TestObject,Operation,Parameters);
    begin
     case Operation of
        'Keys' : TestObject.Keys(Parameters);
        'Click' : TestObject.Click;
        // 添加其它类型的测试操作的处理代码 ...
     else
        Log.Error('不支持该测试操作!');
     end; 
    end;
     
    注:这里仅仅添加了 Keys 和 Click 的测试操作。
     
    (5)关键字驱动的核心框架
    有了前面几个函数的基础,就可以写出下面一个简单的关键字驱动的核心框架:
    //.............................................................................
    // 目的:关键字驱动的核心框架
    // 输入参数:
    // 返回结果:
    // 注意事项:
    // 作者:陈能技
    // 日期:2008-6-3
    //.............................................................................
    Procedure Driver;
     Var TestObject,I;
    begin
     // 1、读入关键字
     ReadKeyWordFromExcel('D:\Code\MyTestSuite\Data\KeyWord.xls','Select * from [KeyWord$]');
     // 2、遍历关键字,创建测试对象、执行测试操作
     For I := 0 to VarArrayHighBound(KeyWord_TestObject,1) do
     begin
    //    Log.Message(VarToStr(KeyWord_TestObject[I])+ '   | '
    //               + VarToStr(KeyWord_Operation[I])+' | '
    //               + VarToStr(KeyWord_Parameters[I]));
        // 创建测试对象
        TestObject := getObject(Sys.Process('flight4a'),VarToStr(KeyWord_TestObject[I]));
        // 执行测试操作
        DoOperation(TestObject,VarToStr(KeyWord_Operation[I]),VarToStr(KeyWord_Parameters[I]));  
     end;
    end;
     
    经试验,这种方法是可以实现类似QTP的关键字驱动测试框架,但是仅仅是一个非常基础的关键字驱动测试框架,如果想把这个框架应用在实际项目中的话,还需要进一步地修改和完善,还有很多工作要做,包括:
    (1)关键字编辑器的编写。
    目前采用直接在Excel文件中填写测试关键字的方法,存在效率和可用性问题,需要创建一个类似QTP的更加好用的关键字视图编辑器。
    (2)添加更多的测试操作和方法。
    目前作为试验,仅仅添加了 Keys 和 Click 的测试操作,还有很多控件的很多测试方法需要封装,例如List控件的ClickItem、SelectItem等,另外,对测试对象的属性赋值操作、属性检查操作(类似于QTP的CheckPoint)等都需要进一步地编写框架代码来处理。
    (3)关键字代码与测试脚本之间的同步。
    仅仅依赖Excel的关键字数据来实现整个项目的自动化测试未免过于理想化了,QTP提供了很好的代码生成机制,关键字视图的数据与专家视图的测试脚本之间可以随时同步、切换,因此这个关键字驱动测试框架还缺少一个代码生成器,如何建立Excel数据与测试脚本之间的映射关系是下一步的主要工作之一。
  • 转"TestComplete的一些小技巧"

    2008-07-30 20:38:16

     

     

     

    录制用户界面操作之间的实际延迟时间

    如果你希望脚本执行时按照录制时的速度来回放,那么你需要在录制时记录用户操作之间的实际延迟时间。

     

    有两种方式记录用户操作之间的延迟:

    1、  录制low-level procedure脚本。以这种方式录制的脚本,TC除了记录鼠标和键盘的事件外,还会记录事件之间的延迟时间。所以用户操作之间的延迟能被正确地复制下来。但是要注意low-level procedure是以绝对坐标的方式录制的,因此,如果被测应用程序改变了窗体大小,这种脚本可能会回放失败。

     

    2、  你可以使用Real-time mode选项。如果激活该选项,TC会通过在脚本中插入BuiltIn.Delay的方法记录用户操作之间的实际延迟时间。

     

    Real-time mode的设置通过Tools | Options -> Engines | Recording 打开后勾选。

     

    Code Completion

    在编写脚本时,通常很难记住很多对象、方法和属性的确切名称。因此TC提供了Code Completion功能,它能帮助你节省很多查阅联机帮助文档和纠正错误拼写的时间。

     

    Code Completion窗口可通过右键显示出来,也可以使用快捷键来触发,默认快捷键是CTRL+Space,这个快捷键与中文操作系统的输入法切换冲突,所以不能生效,需要改变快捷键的设置。

     

    选择菜单Tools | Customize Keyboard ,在Categories选择Edit,然后选择Code Completion,把快捷键改成你想要的,但是又不与其它快捷键冲突的设置。

     

    Code Templates

    Code Templates,也叫Code Snippets,允许你把预先定义的代码模板插入到脚本代码中,为你节省很多敲击代码的时间。

     

    默认按快捷键CTRL+J就能展开Code Templates界面,让你可以选择需要的代码片断。默认会提供trywhile这些常用的代码框架,你也可以自己定制、增加、删除代码片断。选择菜单Tools | Options,在Panels | Code Editor | Code Templates中就可以做这些操作。

     

    Outlining

    Outlining让你可以更好地组织代码,让脚本代码的结构更加清晰、可读性更强。

     

    Outlining意味着你可以把一些代码组合成在一个区域里(block),然后可以展开或收起这个区域的代码。当展开时,你可以看到block中的所有代码,当收起时,只能看到block的第一行代码。所以Outlining让你可以把一些暂时不需要看到、不需要编辑的代码片断隐藏起来,这在代码行比较多的情况下会很有用。

     

    Outlining的使用方法很简单,只需要选中需要隐藏的代码行,右键选择Outlining | Hide SelectionOutlining | Hide by Definitions,要展开时,选择相应的Expand项或直接点代码编辑器左侧的+号即可展开。

  • 转"浅谈测试web程序的几大要点"

    2008-07-30 20:21:03

    一、功能测试

      1、链接测试

      链接是Web应用系统的一个主要特征,它是在页面之间切换和指导用户去一 些不知道地址的页面的主要手段。链接测试可分为三个方面。首先,测试所有链接是否按指示的那样确实链接到了该链接的页面;其次,测试所链接的页面是否存 在;最后,保证Web应用系统上没有孤立的页面,所谓孤立页面是指没有链接指向该页面,只有知道正确的URL地址才能访问。

      2、表单测试

       当用户给Web应用系统管理员提交信息时,就需要使用表单操作,例如用户注册、登陆、信息提交等。在这种情况下,我们必须测试提交操作的完整性,以校验 提交给服务器的信息的正确性。例如:用户填写的出生日期与职业是否恰当,填写的所属省份与所在城市是否匹配等。如果使用了默认值,还要检验默认值的正确 性。如果表单只能接受指定的某些值,则也要进行测试。例如:只能接受某些字符,测试时可以跳过这些字符,看系统是否会报错。

      3、Cookies测试

      Cookies通常用来存储用户信息和用户在某应用系统的操作,当一个用户使用Cookies访问了某一个应用系统时,Web服务器将发送关于用户的信息,把该信息以Cookies的形式存储在客户端计算机上,这可用来创建动态和自定义页面或者存储登陆等信息。

      如果Web应用系统使用了Cookies,就必须检查Cookies是否能正常工作。测试的内容可包括Cookies是否起作用,是否按预定的时间进行保存,刷新对Cookies有什么影响等。

      Session测试,Session的功能与Cookies有些类似,测试工作大体相同

      4、设计语言测试

       Web设计语言版本的差异可以引起客户端或服务器端严重的问题,例如使用哪种版本的HTML等。当在分布式环境中开发时,开发人员都不在一起,这个问题 就显得尤为重要。除了HTML的版本问题外,不同的脚本语言,例如Javascrīpt、VBscrīpt或Perl等也要进行验证。

      5、数据库测试

      在Web应用技术中,数据库起着重要的作用,数据库为Web应用系统的管理、运行、查询和实现用户对数据存储的请求等提供空间。在Web应用中,最常用的数据库类型是关系型数据库,可以使用SQL对信息进行处理。

      在使用了数据库的Web应用系统中,一般情况下,可能发生两种错误,分别是数据一致性错误和输出错误。数据一致性错误主要是由于用户提交的表单信息不正确而造成的,而输出错误主要是由于网络速度或程序设计问题等引起的,针对这两种情况,可分别进行测试。

      二、性能测试

      1、连接速度测试

      用户连接到Web应用系统的速度根据上网方式的变化而变化,他们或许是电话拨号,或是宽带上网。当下载一个程序时,用户可以等较长的时间,但如果仅仅访问一个页面就不会这样。如果Web系统响应时间太长(例如超过5秒钟),用户就会因没有耐心等待而离开。

      另外,有些页面有超时的限制,如果响应速度太慢,用户可能还没来得及浏览内容,就需要重新登陆了。而且,连接速度太慢,还可能引起数据丢失,使用户得不到真实的页面。

      2、负载测试

       负载测试是为了测量Web系统在某一负载级别上的性能,以保证Web系统在需求范围内能正常工作。负载级别可以是某个时刻同时访问Web系统的用户数 量,也可以是在线数据处理的数量。例如:Web应用系统能允许多少个用户同时在线?如果超过了这个数量,会出现什么现象?Web应用系统能否处理大量用户 对同一个页面的请求?

      3、压力测试

      负载测试应该安排在Web系统发布以后,在实际的网络环境中进行测试。因为一个企业内部员工,特别是项目组人员总是有限的,而一个Web系统能同时处理的请求数量将远远超出这个限度,所以,只有放在Internet上,接受负载测试,其结果才是正确可信的。

      进行压力测试是指实际破坏一个Web应用系统,测试系统的反映。压力测试是测试系统的限制和故障恢复能力,也就是测试Web应用系统会不会崩溃,在什么情况下会崩溃。黑客常常提供错误的数据负载,直到Web应用系统崩溃,接着当系统重新启动时获得存取权。

      压力测试的区域包括表单、登陆和其他信息传输页面等。

     三、可用性测试

      1、导航测试

      导航描述了用户在一个页面内操作的方式,在不同的用户接口控制之间,例 如按钮、对话框、列表和窗口等;或在不同的连接页面之间。通过考虑下列问题,可以决定一个Web应用系统是否易于导航:导航是否直观?Web系统的主要部 分是否可通过主页存取?Web系统是否需要站点地图、搜索引擎或其他的导航帮助?

     
       导航的另一个重要方面是Web应用系统的页面结构、导航、菜单、连接的风格是否一致。确保用户凭直觉就知道Web应用系统里面是否还有内容,内容在什么地方。

      Web应用系统的层次一旦决定,就要着手测试用户导航功能,让最终用户参与这种测试,效果将更加明显。

      2、图形测试

      在Web应用系统中,适当的图片和动画既能起到广告宣传的作用,又能起到美化页面的功能。一个Web应用系统的图形可以包括图片、动画、边框、颜色、字体、背景、按钮等。图形测试的内容有:

      (1)要确保图形有明确的用途,图片或动画不要胡乱地堆在一起,以免浪费传输时间。Web应用系统的图片尺寸要尽量地小,并且要能清楚地说明某件事情,一般都链接到某个具体的页面。

      (2)验证所有页面字体的风格是否一致。

      (3)背景颜色应该与字体颜色和前景颜色相搭配。

      (4)图片的大小和质量也是一个很重要的因素,一般采用JPG或GIF压缩;所以应尽量避免使用bmp等格式的图片

      3、内容测试

      内容测试用来检验Web应用系统提供信息的正确性、准确性和相关性。

      信息的正确性是指信息是可靠的还是误传的。

      4、整体界面测试

       整体界面是指整个Web应用系统的页面结构设计,是给用户的一个整体感。例如:当用户浏览Web应用系统时是否感到舒适,是否凭直觉就知道要找的信息在 什么地方?整个Web应用系统的设计风格是否一致?当然,对界面的整体测试并不能单靠个人直觉来评定;每个人的审美观、专业角度、系统面向的行业及用户 、甚至性别与年龄等等,都是可能导致对界面作出不同评价的因素。所以要明白在对整体界面的测试过程中,其实是一个对最终用户进行调查的过程。一般Web应 用系统采取在主页上做一个调查问卷的形式,来得到最终用户的反馈信息。

      对所有的可用性测试来说,都需要有外部人员(与Web应用系统开发没有联系或联系很少的人员)的参与,最好是最终用户的参与。

      四、客户端兼容性测试

      1、平台测试

       市场上有很多不同的操作系统类型,最常见的有Windows、Unix、Macintosh、Linux等。Web应用系统的最终用户究竟使用哪一种操 作系统,取决于用户系统的配置。这样,就可能会发生兼容性问题,同一个应用可能在某些操作系统下能正常运行,但在另外的操作系统下可能会运行失败。

      因此,在Web系统发布之前,需要在各种操作系统下对Web系统进行兼容性测试。

      2、浏览器测试

       浏览器是Web客户端最核心的构件,来自不同厂商的浏览器对Java,、Javascrīpt、ActiveX、 plug-ins或不同的HTML规格有不同的支持。例如,ActiveX是Microsoft的产品,是为Internet Explorer而设计的,Javascrīpt是Netscape的产品,Java是Sun的产品等等。另外,框架和层次结构风格在不同的浏览器中也有 不同的显示,甚至根本不显示。不同的浏览器对安全性和Java的设置也不一样。

      测试浏览器兼容性的一个方法是创建一个兼容性矩阵。在这个矩阵中,测试不同厂商、不同版本的浏览器对某些构件和设置的适应性。

      五、安全性测试

      Web应用系统的安全性测试区域主要有:

      (1)现在的Web应用系统基本采用先注册,后登陆的方式。因此,必须测试有效和无效的用户名和密码,要注意到是否大小写敏感,可以试多少次的限制,是否可以不登陆而直接浏览某个页面等。

      (2)Web应用系统是否有超时的限制,也就是说,用户登陆后在一定时间内(例如15分钟)没有点击任何页面,是否需要重新登陆才能正常使用。

      (3)为了保证Web应用系统的安全性,日志文件是至关重要的。需要测试相关信息是否写进了日志文件、是否可追踪。

      (4)当使用了安全套接字时,还要测试加密是否正确,检查信息的完整性。

      (5)服务器端的脚本常常构成安全漏洞,这些漏洞又常常被黑客利用。所以,还要测试没有经过授权,就不能在服务器端放置和编辑脚本的问题。

    六、总结

      本文从功能、性能、可用性、客户端兼容性、安全性等方面讨论了基于Web的系统测试方法。

    基 于Web的系统测试与传统的软件测试既有相同之处,也有不同的地方,对软件测试提出了新的挑战。基于Web的系统测试不但需要检查和验证是否按照设计的要 求运行,而且还要评价系统在不同用户的浏览器端的显示是否合适。重要的是,还要从最终用户的角度进行安全性和可用性测试。
  • 转"自动化测试工具介绍QTP篇"

    2008-07-29 16:38:59

    Mercury QuickTest Professional™是一款先进的自动化测试解决方案,用于创建功能和回归测试。它自动捕获、验证和重放用户的交互行为。

    Mercury QuickTest Professional为每一个重要软件应用和环境提供功能和回归测试自动化的行业最佳解决方案。

    QuickTest Professional是新一代自动化测试解决方案,采用了关键词驱动(Keyword-Driven)测试的理念,能完全简化测试的创建和维护工作。QuickTest关键词驱动方式独有之处在于,测试自动化专家可以通过一个整合的脚本和纠错环境,拥有对基础测试脚本和对象属性的完全访问权限,这些脚本和纠错环境与关键词视图(Keyword View)可以互为同步。

    QuickTest Professional同时满足了技术型和非技术型用户的需求,让各个公司有能力部署更高质量的应用,同时部署的速度更快,费用更低,风险也更小。QuickTest Professional和我们新的测试自动化系统Mercury Business Process Testing™的紧密结合,可以将非技术型的业务专家(SME, Subject-Matter Experts)引入质量流程,这一意义重大的引入可以将IT和业务更好地融合,最终建立起更出色的应用。

    有了该产品,您的QA机构可以获取多方面的优势:
            用最少的培训赋予整个小组创建成熟测试方案的能力。
            确保跨所有环境、数据包和业务流程的正确功能点。
            为开发人员全面记录和复制缺陷,使他们能更快地修复缺陷,满足最后上线期限。
            对不断变化的应用和环境展开便捷的回归测试。
            成为帮助整个机构实现高质量产品和服务、提高总收入和收益率的关键角色。

    QuickTest Professional是如何工作的
    QuickTest Professional易于操作,即使是初级的测试人员也能在短时间内对其驾轻就熟。您可以使用无需脚本的关键词视图来表现测试的每个步骤,仅由此就可创建一个测试。您还可以通过QuickTest Professional所集成的录制能力来捕获测试步骤。该产品用简单的英语以文档形式记录每个步骤,并通过活动屏幕将文档与一个集成截屏相结合。传统的脚本记录工具所生产的脚本不易修改,与此不同的是,QuickTest Professional的关键词驱动方式能让您便捷地插入、修改、数据驱动(data-drive)和移除测试步骤。

    QuickTest Professional可以自动引入检查点来验证应用的属性和功能点,比如确认输出量或检查链接的有效性。在关键词视图的每一步骤中,活动屏幕可显示被测应用在该步骤中的确切状态。您还可以为任意对象加入几种检查点,仅仅在活动屏幕中点击该对象,就可以验证该组件行为是否达到了期望值。

    然后您可以将测试数据输入数据表(Data Table),它拥有和Excel同样完善的功能特性,是一个集成的电子数据表格。您可以使用数据集并创建多种重复测试,无需编程就可以扩展测试案例的覆盖面。数据可以通过键入的方式输入或从数据库、数据表格或文本文档中导出。

    高级测试人员可以在专家视图(Expert View)中查看和修改他们的测试,在专家视图中显示了由QuickTest Professional自动生成的基于行业标准的基本VBscrīpt语言。在专家视图中所做的任何改动将自动与关键词视图同步。

    一旦测试人员运行了一个脚本,TestFusion报告将显示测试运行各方面的信息,包括:高水平的结果纵览;一个可扩展的测试脚本树状视图(Tree View),其明确指出了应用错误的发生位置;被使用的测试数据;每个步骤的应用截屏,其中并标明了所有的差异;以及通过或未通过每个检查点的详细解释。您可以将TestFusion报告和QuickTest Professional结合,从而与整个QA和开发小组分享这些报告。

    QuickTest Professional处理一些应用的新版本问题。当一个被测应用发生变化时,比如把一个”Login”按钮被改名为”Sign in”,您可以在共享对象容器(Shared Object Repository)中做一次更新,接着此次更新将扩展到所有涉及这个对象的脚本。您可以将测试脚本公布给Mercury Quality Management,使其它的QA小组成员也可以使用您的测试脚本,从而减少了重复工作。

    通过与Business Process Testing的整合,在一个基于Web的系统中,QuickTest Professional被用于实现自动化操作,使非技术型用户可以便捷地在一个完全的无脚本环境中也能够建立起测试。

    QuickTest Professional支持多种企业环境的功能测试,包括Windows、Web、.NET、 Java/J2EE、SAP、Siebel、Oracle、PeopleSoft、Visual Basic、ActiveX、Mainframe terminal emulators和Web services。

    Mercury功能测试
    那些在Mercury WinRunner®测试工具上投入大量资金,并想转入Mercury QuickTest Professional™的用户,可以使用Mercury Functional Testing™来实现这种转变。Mercury Functional Testing将QuickTest Professional和WinRunner结合成一种集成产品,它不仅可以使用WinRunner脚本,也可以使用QuickTest Professional脚本,使测试资源得到极大地利用。质量工程师可以使用Mercury Functional Testing来创建“复合脚本”测试,这些脚本是在WinRunner和QuickTest Professional中建立的。Mercury Functional Testing是WinRunner和QuickTest Professional的集成,产品间可以相互调用脚本,测试结果可以在一个共有的报告界面上呈现。

    Mercury质量中心的组成部分之一
    Mercury QuickTest Professional是Mercury质量中心(Mercury Quality Center™)的组成部分之一,Mercury质量中心集成了一整套软件、服务和最佳实践,用于自动化关键质量活动,包括需求管理、测试管理、缺陷管理、功能测试和业务流程测试。

    特点和优势
            具有行业领先的便于使用的特性,以及支持提前配置环境的功能,确保了快速的投资回报。
            可独立运行,也可以同Mercury Business Process Testing和Mercury质量中心集成。
            引进了QuickTest Professional 8.0中新一代的“零配置”关键词驱动测试技术,从而实现了快速建立测试、测试脚本更易维护,和更强大的数据驱动能力。
            使用独特智能对象识别(Unique Smart Object Recognition)来发现对象,即使对象创建不断在改变,但仍可保证无监控方式脚本执行的可靠性。
            恢复管理器(Recovery Manager)可处理不可预知的应用意外事件,实现24x7的不间断测试,赶上测试项目的最后期限。
            自动文档技术把测试文档的建立与测试脚本的建立同步。
            通过集成的数据表,可数据驱动任意对象、方式、检查点和输出值。
            为QA工程师提供全面的集成开发环境。
            通过使用QuickTest Professional和WinRunner集成的TSL资源,使您在Mercury WinRunner测试脚本上的投资得以保值。
            TestFusion报告可快速隔离和诊断缺陷。
            通过完善检查点,实现应用的全面验证。
  • TestComplete 6 试用版下载地址及注册码

    2008-07-29 10:14:00

    http://automatedqa.com/downloads/thankyou.asp?download=testcomplete60demo.exe

    试用版激活码: F9053532-624F5442-A74A0BA9-62BCAD52-2F2E0F49-151181EB-73C2

  • 【转帖】手把手教你为C盘扩容

    2008-07-27 21:31:45

     c盘空间不够用导致winxP在耳边不停唠叨也就罢了,关键是很多软件也不能正常运行了,这要求我必须采取措施解决这个问题。难道要重新对硬盘分区?不用!在Paragon PartltlonManager的帮助下,完成这件事情绝对轻而易举。
    F?!KJ|q0r6~ Ghd9l~i204028   51Testing软件测试网%ltlY[p$])l$N
      磁盘空间不足带来的烦恼 51Testing软件测试网YD^Ja'q.U p
       51Testing软件测试网"M+eUq Be
      最近,WinXP总是在提示我磁盘空间不够(如图1),问我是否需要删除这个驱动器上的旧的或者不需要的文件以释放一些空间。可是我按照提示打开:“磁盘清理器”清理一番之后,过几分钟,仍然会跳出这个提示。着实令我郁闷…
    j)ca1P(|bLo9E;n204028   51Testing软件测试网T|d9s"GAG
      后来,上网看到有介绍如何关闭“磁盘空间不足提示”的方法,于是就照葫芦画瓢,打开注册表编辑器,定位到『HKEYCURRENTUSER/SOftware/Mj crosoft/Windows/CurrentVersion/Policies/Explore』,新建一个名为“NoLowDiskSpaceChecks”的DWORD键值,并将其赋值为1。重新启动系统后,烦人的磁盘空间不足提示终于不见了。
    0z+p-CY;[d,~9X204028  
    TXk6N7WsB204028  可谁知好景不长,系统速度开始变得越来越慢,甚至有的时候还会死机,以前一直在用的很多软件也无法正常运行了。无奈之下,只有请教心目中的高于朋友,他告诉我“磁盘空间不足就需要为它扩容”,并且推荐给我一款经典的硬盘分区大小动态调整工具ParagonPartition Manager(说是可以在不损坏数据的基础上,很方便地进行磁盘分区的调整,比鼎鼎有名的Powerottost Paltltion Magic还要好用。 51Testing软件测试网a5d c Y!_ cUAh;h(T
       51Testing软件测试网(`0Cb rE
      C盘扩容五步走 51Testing软件测试网Puz L.Wu3nm
      
    f5X:v-e `|o'b!zi204028  Paragon Partition Manager虽然好用,但对于我这种并不怎么了解磁盘操作的用户来说,想要用它为c盘扩容,还是要花费不少心思。不过不论怎么说,最后终于成功了。如果你和我一样,想用Paragon PartitionManager为c盘扩容,相信我的操作会给你一些帮助。
    )N.H&^s%b0wSz:vn204028   51Testing软件测试网$wA!`3x#g[ f
      1.我的硬盘现状
    9N m\D Y6B204028  我电脑里安装的是希捷250GB硬盘。其中c盘空间为10GB(安装系统和软件),D盘空间为60GB,E盘为180GB/左右。 51Testing软件测试网%kah)cx/s)t+v A`-@
      c盘作为系统盘,由于需要安装软件,所以10GB的空间根本就入不敷出,我的构想是从D盘划分20GB到C盘。
    ,i n1e7y-g O/Y6Zy@204028  2.开始调整 51Testing软件测试网:x5qJ$RDN
       51Testing软件测试网D1Z(ec.D*V+l
      在开始为c盘扩容之前,还要跟大家交代一件事情:ParagonPartition Managel中进行的分区调整、设置并不是马上实现的,只有在你点击“应用”之后才会开始进行。所以,当你觉得某一步调整不是很满意,就可以点击上方工具栏中的“撤销”按钮来反悔(当然,也可以点击“全部撤销”重新开始设定)。
    ^J0`Dk@2B:x1u204028  step1在Paragon Partition Manager左侧的磁盘列表中选中“逻辑D”(或者在右下方的磁盘列表中选择),然后点击“调整大小”按钮(如图2)。
    (}iPB+d*s204028  step2在弹出的“调整大小/移动逻辑分区2”窗口,将鼠标移动到上方的柱状图左边缘,直到其显示为图标。此时,需要按下鼠标左键不放向右边拖动,直到前面空余出来的大小符合自己的要求(如图3)。 51Testing软件测试网,E~?f0LS
      当然,更简单的操作方法是直接在“在此之前的自由空间”框中输入需要从D盘划分到c盘的容量,比如20000(单位是MB,也就是大约20GB)。 51Testing软件测试网+~n W,Bqeo
      step3点击工具栏中的“应用”按钮使以上操作生效。
    c%kk(zV204028  step选中“扩展”分区,再次点击“调整大小”按钮(如图5)。 51Testing软件测试网H'BKNfc
      
    "^p9x8pY/@204028  在弹出的“调整大小/移动扩展分区”窗口,如“Step2”那样向右拖动,直到不能拖动为止(如图6)。当然,我们也可以直接设置“在此之前的自由空间”为前文输入的数字,不过这个数字可能会被分区软件自动进行了调整,所以大家最好掌握拖动的方式。
    1Q-r `(X8dZ204028  完成“扩展”分区大小设置后,不要忘记点击“应用”按钮使设置生效。 51Testing软件测试网sq?'CXE$H
      step5最后选中c盘,点击“调整大小”图标(如果“调整大小”不可用,则重新启动计算机再试)。此时也可以采用“Step2”的拖动方法,将鼠标放在分区柱状图右侧,出现卧图标时拖动到最右方即可。不过,最简单的方法是直接设置“在此之前的自由空间”和“再次之后的自由空间”都为0(如图7)。 51Testing软件测试网 r2}Jc!Q$_3h{MT
      再次“应用”,c盘的容量终于增大了(有时候可能需要重新启动计算机才能完成系统盘扩容)。
    :[mo/kk204028  成功标志:C盘大小成为50GB。
    N2Ah`-M&_204028  上而是我将D盘多余的空间划分到c盘.如果你想从E盘划分空间到c盘,也很简单,只要先将剩余空间转移到D盘,再按照前文所述转移到c盘即可。
  • 新手随想

    2008-07-27 20:09:47

       本人刚才开始做软件测试,想在这个行业有所成长,希望各们前辈多多指点!

  • 转"如何描述bug"

    2008-07-27 20:02:27

    测试发现的bug按照频率分为: Always,Usually,Sometimes,Once

         Always: 这类bug所要做到的就是如何把bug描述清楚

    1. 察看当前和bug相关的条件并列出
    2. 按照bug出现的步骤重复做3次以上以此来寻找最短的路径,尽量把不必要的过程过滤,当然不确定的步骤一定不能过滤
    3. 描述的时候尽量做到每个步骤最多2个动作
    4. 尽量用主动的英语句型,在遇到许多动作可以产生这个bug的时候,可以适当用被动句型,把最好重现bug的那个步骤写出来其他可放在括号中
    5. Bug现象的说明一定要描述详细,不要放在步骤中
    6. 发现bug之后的操作最好也做几个步骤(如果可以接着做的话),这样更容易发现周围的bug,同时对开发人员解bug也是有帮助
    7.尽量把bug的周围情况描述的详细些,不需要总是等到开发人员问了我们再去做

         Usually:这类bug和always一样重点就是把步骤描述全面详细且不冗杂

         Sometimes:这类bug在遇到的时候可以先和开发人员描述一下然后共同推测路径,如果可以转化为always或usually,解决就容易些了,实在重现不出来可以把自己所做的若干步骤都描述出来

         Once: 这类bug,开发人员解起来更难

    作为测试人员,所能做的就是除了上述bug的描述之外需要更加注意的:

    1. 尽量做到及时和开发人员沟通

    2. 立刻检查当前状态并做记录

    3. 把和当前bug相关的一切信息全部描述

    4. 和当前bug可能相关的信息可以放在note中,一定要详细

    此外,如果连续发生好几个bug,需要把每个bug的频率标注好,如果有外部网络或者设备等影响的尽量把这些外部环境也描述清楚,这样有助于开发人员解决问题。 

     我们的目的:“做到质量更好的同时效率更高,我们不但要发现问题还要帮助开发人员解决问题“

  • 转"用TestDirector生成的测试用例"

    2008-07-26 20:25:28

    用TestDirector生成的测试用例有两种样式:Full Page和Tabular
            TestDirector中没有关于测试用例的目的以、该用例的前提条件等字段,因此可以在客户化时增加这些字段,由于客户化字段没有Memo类型,因此,可以将用例的目的和前提条件等在描述字段中进行描述,注意事项等也可以在此描述,如果有测试数据的话,可以在描述字段中对测试数据进行描述,具体的测试数据以文本或Excel方式保存,作为该测试用例的附件。
     
    样式一:Full Page
    1.1  用例名称 : 启动客户端程序
    路径 :
    主题 :服务程序
    设计状态 : Design
    设计者 : yuanhaisong
    创建日期 : 2002-06-11
    用例类型 : MANUAL
    描述 :目的:
       1. 检查服务程序能否以设计的五种方式正确启动客户端程序
          1.1. 菜单启动
          1.2. 快捷键启动
          1.3. 鼠标双击启动
          1.4. 定时启动
          1.5. 隔时启动
     
    前提条件:
       1. 服务程序已经运行;
       2. 客户端程序尚未运行;
     
    估计开发时间 : 0
    执行状态 : Passed
    Steps :
    Step Name : Step 1
    Descrīption :运行服务程序Server.exe
    Expected Result : 1. 服务程序运行;
    2. 服务程序在系统托盘中显示为图标;
    Step Name : Step 2
    Descrīption : 1. 在服务程序图标上单击右键;
    2. 在弹出的悬浮菜单中选择【启动在线升级程序】;
    Expected Result : 1. 弹出悬浮菜单,包括【启动在线升级程序】、【启动定时服务】、【启动隔时服务】和【关闭服务程序】四个菜单项;
    2.1 如果柜台系统需要更新,则弹出窗口提示是否更新,选择“Yes”按钮则启动客户端程序进行更新,选择“No”则关闭提示窗口;
    2.2 如果柜台系统不需要更新,则弹出窗口提示不需要更新,点击“OK”按钮关闭提示窗口;
    3 服务程序下载version.txt并生成DownLoadList.ini文件到服务端程序的安装目录下的 temp 目录中;
    4 version.txt文件的内容与服务器端的version.txt文件的内容一样;
    5 服务程序根据version.txt文件的内容与本地对应的文件进行比较,将需要升级的文件生成下载清单DownLoadList.ini
    6 如果需要更新并确定要更新,则下载更新文件并解压缩到Download目录中;
    Step Name : Step 3
    Descrīption :双击服务程序图标
    Expected Result : 1 如果柜台系统需要更新,则弹出窗口提示是否更新,选择“Yes”按钮则启动客户端程序进行更新,选择“No”则关闭提示窗口;
    2 如果柜台系统不需要更新,则弹出窗口提示不需要更新,点击“OK”按钮关闭提示窗口;
    3 服务程序下载version.txt并生成DownLoadList.ini文件到服务端程序的安装目录下的 temp 目录中;
    4 version.txt文件的内容与服务器端的version.txt文件的内容一样;
    5 服务程序根据version.txt文件的内容与本地对应的文件进行比较,将需要升级的文件生成下载清单DownLoadList.ini
    6 如果需要更新并确定要更新,则下载更新文件并解压缩到Download目录中;
    Step Name : Step 4
    Descrīption :按启动服务快捷键(Ctrl + F12)
    Expected Result : 1 如果柜台系统需要更新,则弹出窗口提示是否更新,选择“Yes”按钮则启动客户端程序进行更新,选择“No”则关闭提示窗口;
    2 如果柜台系统不需要更新,则弹出窗口提示不需要更新,点击“OK”按钮关闭提示窗口;
    3 服务程序下载version.txt并生成DownLoadList.ini文件到服务端程序的安装目录下的 temp 目录中;
    4 version.txt文件的内容与服务器端的version.txt文件的内容一样;
    5 服务程序根据version.txt文件的内容与本地对应的文件进行比较,将需要升级的文件生成下载清单DownLoadList.ini
    6 如果需要更新并确定要更新,则下载更新文件并解压缩到Download目录中;
    Step Name : Step 5
    Descrīption :修改配置文件Config.ini中的定时启动时间(SpecifyTime)
    Expected Result : 1. 到启动时间后,如果柜台系统需要更新,则弹出窗口提示是否更新,选择“Yes”按钮则启动客户端程序进行更新,选择“No”则关闭提示窗口;
    2. 到启动时间后,如果柜台系统不需要更新,则弹出窗口提示不需要更新,点击“OK”按钮关闭提示窗口;
    3 服务程序下载version.txt并生成DownLoadList.ini文件到服务端程序的安装目录下的 temp 目录中;
    4 version.txt文件的内容与服务器端的version.txt文件的内容一样;
    5 服务程序根据version.txt文件的内容与本地对应的文件进行比较,将需要升级的文件生成下载清单DownLoadList.ini
    6 如果需要更新并确定要更新,则下载更新文件并解压缩到Download目录中;
    Step Name : Step 6
    Descrīption :修改配置文件Config.ini中的隔时启动时间长度(IntervalTime)
    Expected Result : 1. 每间隔隔时启动时间长度后,如果柜台系统需要更新,则弹出窗口提示是否更新,选择“Yes”按钮则启动客户端程序进行更新,选择“No”则关闭提示窗口;
    2. 每间隔隔时启动时间长度后,如果柜台系统不需要更新,则弹出窗口提示不需要更新,点击“OK”按钮关闭提示窗口;
    3. 如果尚未对上一次的提示进行操作,而在此之间,升级状态发生了变化,到新一次隔时启动时间长度后,正确显示提示信息;
    4 服务程序下载version.txt并生成DownLoadList.ini文件到服务端程序的安装目录下的 temp 目录中;
    5 version.txt文件的内容与服务器端的version.txt文件的内容一样;
    6 服务程序根据version.txt文件的内容与本地对应的文件进行比较,将需要升级的文件生成下载清单DownLoadList.ini
    7 如果需要更新并确定要更新,则下载更新文件并解压缩到Download目录中;
  • 转"如何描述bug"

    2008-07-26 19:54:07

    测试发现的bug按照频率分为: Always,Usually,Sometimes,Once

         Always: 这类bug所要做到的就是如何把bug描述清楚

    1. 察看当前和bug相关的条件并列出
    2. 按照bug出现的步骤重复做3次以上以此来寻找最短的路径,尽量把不必要的过程过滤,当然不确定的步骤一定不能过滤
    3. 描述的时候尽量做到每个步骤最多2个动作
    4. 尽量用主动的英语句型,在遇到许多动作可以产生这个bug的时候,可以适当用被动句型,把最好重现bug的那个步骤写出来其他可放在括号中
    5. Bug现象的说明一定要描述详细,不要放在步骤中
    6. 发现bug之后的操作最好也做几个步骤(如果可以接着做的话),这样更容易发现周围的bug,同时对开发人员解bug也是有帮助
    7.尽量把bug的周围情况描述的详细些,不需要总是等到开发人员问了我们再去做

         Usually:这类bug和always一样重点就是把步骤描述全面详细且不冗杂

         Sometimes:这类bug在遇到的时候可以先和开发人员描述一下然后共同推测路径,如果可以转化为always或usually,解决就容易些了,实在重现不出来可以把自己所做的若干步骤都描述出来

         Once: 这类bug,开发人员解起来更难

    作为测试人员,所能做的就是除了上述bug的描述之外需要更加注意的:

    1. 尽量做到及时和开发人员沟通

    2. 立刻检查当前状态并做记录

    3. 把和当前bug相关的一切信息全部描述

    4. 和当前bug可能相关的信息可以放在note中,一定要详细

    此外,如果连续发生好几个bug,需要把每个bug的频率标注好,如果有外部网络或者设备等影响的尽量把这些外部环境也描述清楚,这样有助于开发人员解决问题。 

     我们的目的:“做到质量更好的同时效率更高,我们不但要发现问题还要帮助开发人员解决问题“

数据统计

  • 访问量: 8950
  • 日志数: 20
  • 建立时间: 2008-07-26
  • 更新时间: 2008-10-29

RSS订阅

Open Toolbar