发布新日志

  • WatiN中所有的接口(Interfaces)

    2008-12-18 17:25:47

         (WatiN所有的接口)

    1. IAttributeBag: 用来获取继承此接口的所有类的属性值

      String GetValue(string attributename) //返回参数中的这种属性的值。

    2. ICompare: AttributeConstraint类提供的接口, 用来对比此控件的属性是否和给出的约束属性相同, 返回波尔值。

      bool Compare(string value)

    3. ICompareElement: 用来实现控件对比的接口,和上面的接口差不多,给出控件是否和所找到的控件相同。返回波尔值。

      bool Compare(Element element)

    l         4. IDialogHandler: 用来判断是否存在此对话框的接口, 返回值为bool.

    bool HandleDialog(Window window)

    5. IEIementCollection: 获取HTML中的多个控件,返回为一个控件集

       IHTMLElementCollection Elements {get;}

    实现这个功能需要调用MSHTML接口。

    说明一下MSHTML: 是提供访问所有的动态HTML对象中的控件,并且提供访问一些脚本编写的对象模式。

    如何通过MSHTML类来访问页面上的控件: 使用IHTMLDOcument2接口指针,可以获取到HTML页面上所有的控件. 在获取这些控件后可以通过IHTMLElementCollection接口调用某种方法来对这些控件进行操作。然后就可以对这些COM控件进行事件操作。

     6. IElementContainer: 是个容器接口,提供通过不同方式获得需要查找的COM控件.Area为例说明:

        Area Area(string elementId) , Area Area(Regex elementId) , Area Area(BaseConstraint findBy)三种方法分别是通过ID、正则表达式、和约束类BaseConstraint来找到Area.

       既然能够获得这些Area控件那么就应该去找个容器来存放这些AreaAreaCollection Areas {get;}

       同样的Button, Checkbox, element, fileupload, form, label, link, RadioButton, SelectList, Table, TableCell, TableRow, TableBody, TextField, Span, Div, Image都通过这种方式来得到。

      7. IFindByDefaultFactory: 是用来默认的查找COM控件方法的接口,其它查找方法都是在此基础上继承下来的。可以通过字符串和正则表达式来获得。

        BaseConstraint ByDefault(string value) , BaseConstraint ByDefault(Regex value)

      8. IHwnd: 此接口是用来找到WindowsAPI并设置属性的接口,用来控制Window窗口的。

         IntPtr hwnd {get; }

         string WindowText { get; }

         bool  IsWindow {get; }

         bool  IsWindowEnabled {get; }

         string ClassName {get; }

          void SendMessage (int msg, int wParem, int IParen);

          IntPtr GetDlgItem(int contralid );

      9. ILogWriter: 此接口记录日志,如果你创建了自己的记录日志的类的话可以引用此接口。

         无返回值,而是写入文件中。

        Void LogAction (string message);

    10. INativeBrowser: Watin去在浏览器上查找的基础接口类, 通过几个参数找到页面上的某个控件。

        AtiveElementFinder CreateElementFinder(ArrayList tags, BaseConstraint baseConstraint, IElementCollection elements);

        AtiveElementFinder CreateElementFinder(ArrayList tags, IElementCollection elements);

        AtiveElementFinder CreateElementFinder(string tagename, string iputtypeString, BaseConstraint baseConstraint, IElementCollection elements);

        ativeElement CreateElement(object element);

    11. INativeElement 所有类型的COM控件都可以继承的基础方法接口类,

       String TextAfter { get; } , string TextBefore{ get; } , INativeElement NextSibling { get; } , INativeElement PreviousSibling { get; } INativeElement Parent { get; } ,Style Style { get; }

    string GetAttributeValue(string attributeName);void ClickOnElement();void SetFocus();void FireEvent(string eventName, NameValueCollection eventProperties);

    string BackgroundColor { get; set; } , bool IsElementReferenceStillValid();

    IAttributeBag GetAttributeBag(DomContainer domContainer);    string TagName { get; }

    object NativeElement { get; }        void FireEventAsync(string eventName, NameValueCollection eventProperties);

    12. INativeElementFinder: 找到constraintElement的基本方法类,同时包含把这两个元素转换为string的接口基本类。

    INativeElement FindFirst();

    INativeElement FindFirst(BaseConstraint constraint);

    ArrayList FindAll();

    ArrayList FindAll(BaseConstraint constraint);

    string ElementTagsToString { get; }

    string ConstriantToString { get; }

    ITextElement: 此接口类是用来支持TextField类实现控件的输入和密码的输入等。

    Int  MaxLength { get; }; bool ReadOnly { get; } , string Value { get; } , void Select ();

    Void SetValue(string value);

    String ToString (); string Name { get; }

  • WatiN中所有的控件以及控件的识别方法1

    2008-12-16 15:35:36

    WatiN的源代码中可以看到所有的控件识别设计类都是在继承了与element相关的类

    包括Element, ElementAttributeBag, ElementCollection, ElementContainer, ElementSupport, ElementTag

    首先来看Element的类可以看到它继承IAttributeBag,Elemental类中写到的方法有:

     1. Classname: Get the name of the stylesheet class assigned to this element;得到传输给此控件默认格式类的名称。返回值为string.

     2. Complete: Boolean Value, Get a value indicating whether the element is completely loaded;得到一个波尔值,查看是否此对当前控件的操作完全加载。返回值为波尔值.

     3. Enabled: Get a Value indicating whether this element is enabled.得到一个波尔值来确认当前的控件是否是可用的.返回值为波尔值.

     4. ID: Get the if of this element as specified in the HTML ,返回当前控件在此HTML页面中的识别ID, 返回值为string

     5.TEXT: Get the inner text of this element(or all the inner text of all the elements contained in this elment). 返回当前控件中的文本,或者是返回当前控件所包含的控件中的所有文本,返回值为string.

     6.TextBefore: Returns the text displayed before this element when it’s wrapped in a Label element, otherwise it returns null. 返回当前控件前面的Label的文本内容,如果当前控件前面的控件不是Label则返回null, 返回值为string.

     7. InnerHtml: Gets the inner HTML of this element. 返回当前控件的内部HTML代码。返回值不用说当然为string.

     8. OuterText: Gets the outer text, 返回外部文档,返回值为string.

        Shit,这个控件我还真不知道怎么用,呵呵。查了一下解释如下:

    InnerText:不包括标志,标志以内的纯文本  
      OuterText:
    包括标志,连标记及标志内的文本
     
      InnerHtml:
    不包括标志,标志以内的Html内容
     
      OuterHtml:
    包括标志,连标记及标志内的Html内容

     9. TagName: Gets the tag name of this element 返回当前控件的标签。返回值为string.

     10. Title: Get the title. 返回当前页面的标题。返回值为stieng.

     11. NextSibling: Gets the next sibling of this element in the Dom of the HTML page.返回当前标签在此HTML页面Dom控件中的下一个兄弟控件。返回值为控件即(element)

     12. PreviousSibling: Gets the previous sibling of this element in the Dom of the HTML page. 返回当前标签在此HTML页面Dom控件中的下一个兄弟控件,返回值为控件即(element)

     13. Parent: Gets the parent element of this element, If the parent type is known you can cast it to that type. 返回当前控件的父级控件,如果父级的控件类型知道,可以定义一个和父级同类型的变量控件。返回类型为控件(element).这个比较难理解,下面是举例:

          Div

            a id="watinlink" href="http://watin.sourceforge.net" /

                    a href="http://sourceforge.net/projects/watin" /

               Div

          上面的HTML所示第二个超链接没有id,如何点击它来实现超链接?这时可以使用Parent这个方法:

             首先定义一个变量Div,然后把这两个超链接所在的div赋值给这个Division变量。

      Div watinDiv = ie.Link(“watinlink”).Parent;

    然后去找第二个Link, 可以把第一个Link看做是Links[0],那么第二个Link就是Link[1]

     watinDiv.Links[1].Click();

     14.Style: Style is the element’s style, 返回当前控件的格式。返回类型为Style.

      15.GetAttributeValue: This method can be used is the attribute is not available as a property of the element of a subclass of the element. Need a parameter’attributeName’, this parameter should be the name of the property exposed by IE on it’s element object. The return is the value of the attribute if available, otherwise null is returned. 当控件的属性不存在或者或者属性属于此控件的一个子类时此方法可以使用。但是需要传递给此方法一个参数即属性名称(它应该是被IE暴露的一个空间实体),返回值为控件的属性值或者为null.

       16. ToString: Returns a string that represents the current object, or null.返回代表当前实体的值,如果没有则返回空。返回类型为string.

       17.Click: Click this element and waits till the event is completely finished(Page is loaded and ready). 点击当前控件然后等待,知道整个事件完成即:页面被完全加载。无返回值.

       18.ClickNoWait: Click this instance and returns immediately. Use this method when you want to continue without waiting for the click event to be finished. Mostly used when a HTML Dialog is displayed after clicking the element. 触发事件并立刻返回信息然后去判断需要如何执行,通常是在点击或者跳转页面还没完成时你需要其它操作。一般情况下是在当弹出对话框时使用这个方法。无返回值。

       19.Focus: Gives the input focus to this element. 聚焦在当前这个输入控件,我不是很明白这个方法。无返回值。

       20.DoubleClick: Doubleclicks this element. 双击当前的控件。无返回值。

       21.KeyDown, KeyPress, KeyUp 三个方法分别为按下键盘不放, 按一下键盘,和松开按键盘。很绕口. 这个应该是从.Net继承的。

       22. Blur: Fires the blur event on this element. 这个应该是和focus相反的方法。取消对这个控件的focus.

     

  • 开始实战

    2007-07-09 15:45:58

      我刚从学校把毕业证拿到手,现在到北京了。没想到今天就去面试了。太席数码,我也不知道公司怎么样。他们还问我愿不愿意做开发。本以为人家是在试我,就说我就是要做测试。后来才明白他们很缺开发的人员,而我这方面还是有一定的实力。看来我是自己把自己害了。不过我也觉得既然我选择了测试,就应该把这个做好。开发就当作兴趣吧。只要肯努力,做什么都差不多的。毕业的感觉真难受。我是看着同学一个一个走的。男人也要哭啊。算了算很多人十年后才能见面。我走的时候,在车上哭别人都看着我,不过都知道我是毕业生,真的是控制不了自己。青岛是我的伤心的地方,也是我的梦想腾飞的地方。怀念大学,怀念青岛。
  • 软件测试面试常用的英语问题

    2007-06-07 08:26:55

                              

                  软件测试面试英语

    1. What types of documents would you need for QA, QC, and Testing?
    2. What did you include in a test plan?
    3. Describe any bug you remember.
    4. What is the purpose of the testing?
    5. What do you like (not like) in this job?
    6. What is quality assurance?
    7. What is the difference between QA and testing?
    8. How do you scope, organize, and execute a test project?
    9. What is the role of QA in a development project?
    10. What is the role of QA in a company that produces software?
    11. Define quality for me as you understand it
    12. Describe to me the difference between validation and verification.
    13. Describe to me what you see as a process. Not a particular process, just the basics of having a process.
    14. Describe to me when you would consider employing a failure mode and effect analysis.
    15. Describe to me the Software Development Life Cycle as you would define it.
    16. What are the properties of a good requirement?
    17. How do you differentiate the roles of Quality Assurance Manager and Project Manager?
    18. Tell me about any quality efforts you have overseen or implemented. Describe some of the challenges you faced and how you overcame them.
    19. How do you deal with environments that are hostile to quality change efforts?
    20. In general, how do you see automation fitting into the overall process of testing?
    21. How do you promote the concept of phase containment and defect prevention?
    22. If you come onboard, give me a general idea of what your first overall tasks will be as far as starting a quality effort.
    23. What kinds of testing have you done?
    24. Have you ever created a test plan?
    25. Have you ever written test cases or did you just execute those written by others?
    26. What did your base your test cases?
    27. How do you determine what to test?
    28. How do you decide when you have ‘tested enough?’
    29. How do you test if you have minimal or no documentation about the product?
    30. Describe me to the basic elements you put in a defect report?
    31. How do you perform regression testing?
    32. At what stage of the life cycle does testing begin in your opinion?
    33. How do you analyze your test results? What metrics do you try to provide?
    34. Realising you won’t be able to test everything - how do you decide what to test first?
    35. Where do you get your expected results?
    36. If automating - what is your process for determining what to automate and in what order?
    37. In the past, I have been asked to verbally start mapping out a test plan for a common situation, such as an ATM. The interviewer might say, “Just thinking out loud, if you were tasked to test an ATM, what items might you test plan include?” These type questions are not meant to be answered conclusively, but it is a good way for the interviewer to see how you approach the task.
    38. If you’re given a program that will average student grades, what kinds of inputs would you use?
    39. Tell me about the best bug you ever found.
    40. What made you pick testing over another career?
    41. What is the exact difference between Integration & System testing, give me examples with your project.
    42. How did you go about testing a project?
    43. When should testing start in a project? Why?
    44. How do you go about testing a web application?
    45. Difference between Black & White box testing
    46. What is Configuration management? Tools used?
    47. What do you plan to become after say 2-5yrs (Ex: QA Manager, Why?)
    48. Would you like to work in a team or alone, why?
    49. Give me 5 strong & weak points of yours
    50. Why do you want to join our company?
    51. When should testing be stopped?
    52. What sort of things would you put down in a bug report?
    53. Who in the company is responsible for Quality?
    54. Who defines quality?
    55. What is an equivalence class?
    56. Is a “A fast database retrieval rate” a testable requirement?
    57. Should we test every possible combination/scenario for a program?
    58. What criteria do you use when determining when to automate a test or leave it manual?
    59. When do you start developing your automation tests?
    60. Discuss what test metrics you feel are important to publish an organization?
    61. In case anybody cares, here are the questions that I will be asking:
    62. Describe the role that QA plays in the software lifecycle.
    63. What should Development require of QA?
    64. What should QA require of Development?
    65. How would you define a “bug?”
    66. Give me an example of the best and worst experiences you’ve had with QA.
    67. How does unit testing play a role in the development/software lifecycle?
    68. Explain some techniques for developing software components with respect to testability.
    69. Describe a past experience with implementing a test harness in the development of software.
    70. Have you ever worked with QA in developing test tools? Explain the participation Development should have with QA in leveraging such test tools for QA use.
    71. Give me some examples of how you have participated in Integration Testing.
    72. How would you describe the involvement you have had with the bug-fix cycle between Development and QA?
    73. What is unit testing?
    74. Describe your personal software development process.
    75. How do you know when your code has met specifications?
    76. How do you know your code has met specifications when there are no specifications?
    77. Describe your experiences with code analyzers.
    78. How do you feel about cyclomatic complexity?
    79. Who should test your code?
    80. How do you survive chaos?
    81. What processes/methodologies are you familiar with?
    82. What type of documents would you need for QA/QC/Testing?
    83. How can you use technology to solve problem?
    84. What type of metrics would you use?
    85. How to find that tools work well with your existing system?
    86. What automated tools are you familiar with?
    87. How well you work with a team?
    88. How would you ensure 100% coverage of testing?
    89. How would you build a test team?
    90. What problem you have right now or in the past? How you solved it?
    91. What will you do during the first day of job?
    92. What would you like to do five years from now?
    93. Tell me about the worst boss you’ve ever had.
    94. What are your greatest weaknesses?
    95. What are your strengths?
    96. What is a successful product?
    97. What do you like about Windows?
    98. What is good code?
    99. Who is Kent Beck, Dr Grace Hopper, Dennis Ritchie?
    100. What are basic, core, practises for a QA specialist?
    101. What do you like about QA?
    102. What has not worked well in your previous QA experience and what would you change?
    103. How you will begin to improve the QA process?
    104. What is the difference between QA and QC?
    105. What is UML and how to use it for testing?
    106. What is CMM and CMMI? What is the difference?
    107. What do you like about computers?
    108. Do you have a favourite QA book? More than one? Which ones? And why.
    109. What is the responsibility of programmers vs QA?
    110. What are the properties of a good requirement?
    111. Ho to do test if we have minimal or no documentation about the product?
    112. What are all the basic elements in a defect report?

  • java小憩

    2007-06-06 15:27:06

                             google的一道JAVA面试题

     Consider a function which, for a given whole number n, returns the number of ones required when writing out all numbers between 0 and n.

      For example, f(13)=6. Notice that f(1)=1. What is the next largest n such that f(n)=n?

      翻译过来大体是这样:
      有一个整数n,写一个函数f(n),返回0到n之间出现的"1"的个数。比如f(13)=6,现在f(1)=1,问下一个最大的f(n)=n的n是什么?

      答案一:

    int getCountOfNumber(int number){
    int count=0;
    int length=("" + number).length();
    for(int i=0;i<=length;i++){
    int num=number%10;
    number=(number-num)/10;
    if(num*num==1) count++;
    }
    return count;
    }


      计算到:199981 用了203
      不过只计算到上边的数值就没多大意思,看看这个:
      这个是4000000000以内的结果!:
      f(0) = 0
      f(1) = 1
      f(199981) = 199981
      f(199982) = 199982
      f(199983) = 199983
      f(199984) = 199984
      f(199985) = 199985
      f(199986) = 199986
      f(199987) = 199987
      f(199988) = 199988
      f(199989) = 199989
      f(199990) = 199990
      f(200000) = 200000
      f(200001) = 200001
      f(1599981) = 1599981
      f(1599982) = 1599982
      f(1599983) = 1599983
      f(1599984) = 1599984
      f(1599985) = 1599985
      f(1599986) = 1599986
      f(1599987) = 1599987
      f(1599988) = 1599988
      f(1599989) = 1599989
      f(1599990) = 1599990
      f(2600000) = 2600000
      f(2600001) = 2600001
      f(13199998) = 13199998
      f(35000000) = 35000000
      f(35000001) = 35000001
      f(35199981) = 35199981
      f(35199982) = 35199982
      f(35199983) = 35199983
      f(35199984) = 35199984
      f(35199985) = 35199985
      f(35199986) = 35199986
      f(35199987) = 35199987
      f(35199988) = 35199988
      f(35199989) = 35199989
      f(35199990) = 35199990
      f(35200000) = 35200000
      f(35200001) = 35200001
      f(117463825) = 117463825
      f(500000000) = 500000000
      f(500000001) = 500000001
      f(500199981) = 500199981
      f(500199982) = 500199982
      f(500199983) = 500199983
      f(500199984) = 500199984
      f(500199985) = 500199985
      f(500199986) = 500199986
      f(500199987) = 500199987
      f(500199988) = 500199988
      f(500199989) = 500199989
      f(500199990) = 500199990
      f(500200000) = 500200000
      f(500200001) = 500200001
      f(501599981) = 501599981
      f(501599982) = 501599982
      f(501599983) = 501599983
      f(501599984) = 501599984
      f(501599985) = 501599985
      f(501599986) = 501599986
      f(501599987) = 501599987
      f(501599988) = 501599988
      f(501599989) = 501599989
      f(501599990) = 501599990
      f(502600000) = 502600000
      f(502600001) = 502600001
      f(513199998) = 513199998
      f(535000000) = 535000000
      f(535000001) = 535000001
      f(535199981) = 535199981
      f(535199982) = 535199982
      f(535199983) = 535199983
      f(535199984) = 535199984
      f(535199985) = 535199985
      f(535199986) = 535199986
      f(535199987) = 535199987
      f(535199988) = 535199988
      f(535199989) = 535199989
      f(535199990) = 535199990
      f(535200000) = 535200000
      f(535200001) = 535200001
      f(1111111110) = 1111111110

      有人用c写了一个,得出这些结果只用了几十毫秒!
      有更好思路的可以讨论讨论。

  • qtp的知识

    2007-06-06 15:20:56

    新手必看《自动化测试工具介绍QTP篇》
    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报告可快速隔离和诊断缺陷。
    通过完善检查点,实现应用的全面验证。
  • 测试新手

    2007-05-31 18:09:25

    Things I Tell New Testers Print E-mail
    By Randall W. Rice, CSQA, CST, CSTM

       As I have led and trained test teams over the years, there are some things that I routinely make sure I convey to new testers. Whether you are new to testing, or a seasoned professional, these are helpful things to remember.

     

    1.                  You are an inspector – You can’t guarantee quality.

     

    Many testers get sidetracked by not understanding that they assess things, not control them. There is a huge difference between the two! For example, a team may work weeks on a test and find many defects, only to see management decide to release the product with known serious defects. The team often feels demoralized and asks why they even do testing.

     

    I ask the team members if they got paid, and most of the time the answer is “yes.” I ask if they did their jobs to the best of their ability, and once again, most of the time they answer “yes.”  I then tell them, “You did your job. You tested to the best of your ability, found defects and reported them. Now, go home and relax. In fact, the only way you can fail as a tester is to fail to report a known defect.”

     

    This may not improve morale much, but it does help keep things in perspective, especially in having the ability to not take the daily frustrations of work home every night.

     

    Many testers, me included, when we first start out in testing, seem to feel personally responsible for the quality of the application or system we are testing. While the work ethic is admirable, we testers really have little control of the product quality. It is for this reason that testers do not ensure quality. The problem is that management doesn’t always see that distinction. This is seen when management asks questions like, “Aren’t we paying these people to have good software?”

     

    2.                  Defects are valuable.

     

    Each defect is an opportunity to learn and improve. We may only get one opportunity to observe a defect, so I always tell testers to be observant and not fall prey to the boredom of testing.

     

    Defect information is perhaps one of the most telling sources of project data available. However, that depends on how well we capture and convey accurate information about the defects we find.

     

    Each defect costs the organization money. If we don’t learn from them, we are wasting a lot of time and money. The leverage happens when we convert a mistake to a learning opportunity. Let’s face it – some lessons are only learned by experience.

     

    It doesn’t do any good to place blame over a defect. All blame does is lower morale and shut down communication. It’s like beating the proverbial dead horse, hoping it will come back to life!

     

    I wrote an article called “Defects are Good” which explores in more depth about the positive side of defects.

     

    3.                  Everything is fine until you report the first problem.

     

    This is where the reality of being a tester sinks in. You can plan the test, get all of the needed resources in place and it seems everyone is on your side. However, things tend to get tenser when you report that first problem.

     

    The reason for the sudden change in attitude is that now you are criticizing someone’s work. There is a pride of ownership that causes egos to be bruised and relationships to be strained. Some of this is to be expected, just be aware that attitudes may change when you start finding problems.

     

    One thing I always suggest to testers is to read some of your past defect reports as if you were the recipient. You may find that you need to be more diplomatic. (See how gently I said that?) It may not be as much fun to write a defect report without sarcasm, but it will help maintain good relationships.

     

    4.                  You can only test what you can observe.

     

    You may want to test that really creative case, but if you don’t have a way to observe the results, what’s the point? Although some applications allow you to observe a lot, there are still things you may not have access to, such as structural views, hidden objects, background processing, etc.

     

    5.                  Never forget how you get someplace.

     

    I’m not speaking about knowing why you walked into a room, but of the steps you took in testing something. It’s common for beginning testers to find a significant defect, only to fail to recreate it for resolution. Then, you’re left with the uncomfortable feeling of not knowing if you truly found a defect, or just used the application incorrectly.

     

    Some ways you can trace your steps include test scrīpts, a test log, keystroke loggers such as Spector (http://www.spectorsoft.com/) and screen video capture tools such as Hypercam (http://www.hyperionics.com/)

     

    6.                  Standards and processes are your friend.

     

    Although the idea of standards and processes may seem confining to some, they give you valuable guidance in doing your job. Don’t reject standards because they may be detailed and lengthy. Instead, use them as a guide to do your job faster and more consistently.

     

    7.                  There’s never enough time for testing.

     

    Almost every tester complains there is not enough time for testing, but the reality is there is never enough time to test anything to a degree of completeness. This is especially true when you consider software attributes, such as usability, security, compatibility, interoperability, etc.

     

    Instead of complaining about the lack of time, learn to prioritize based on risk and focus on the application objectives important to senior management. Sometimes we test more than we need to because our objectives are out of line with what the sponsors value.

     

    8.                  You can’t find all of the defects.

     

    Don’t get discouraged if a defect is found later in something you tested. You may do a very complete job and achieve a high level of defect removal, but 100% is an elusive goal.

     

    9.                  Maintain a sense of humor and perspective

     

    Being able to laugh and keep a healthy sense of balance may be your best survival mechanism. If you are in a bad situation, remember, this too will pass.

     

    10.                Strive for excellence instead of perfection

     

    New testers often get caught up in the quest for perfection with the attitude that 100% correctness is the standard. I was a victim of this as well, but in my defense, I was influenced heavily by the TQM posters of the late 80’s and articles such as “99.9% Isn’t Good Enough.”

     

    The problem with perfectionism is that it will make your progress slower, introduce fear into everything you do, cause you to become more critical of others, and generally, drive even your friends and family to the point of despair.

     

    Of course, no one wants mistakes, but they happen regardless. To think otherwise is to deny reality. Excellence is a habit that is shown in your attitude and dedication to the work you do. If you are committed to be the best, you will go the extra mile.

     

    My observation is that most people are forgiving when they see a mistake or experience a lapse in service. The thing people pay the most attention to is your response to the problem.

     

    11.              Developers are not the enemy

     

    It takes the entire project team to deliver a quality project. While it may seem at times that the developers don’t care about quality, there may be more issues than meet the eye. You will make more progress by working with developers instead of against them. Remember that good communication is a major key to successful projects (and testing). When you take an adversarial position, the communication stops and so does much of your information needed for testing.

     

    12.              Build and maintain a personal network

     

    Your personal and professional relationships are a great asset. They are a support system that can help when you have a job and when you don’t. Find a mentor and when you learn enough lessons, become a mentor to someone else.

     

    13.              Keep building your skills

     

    Your skills are what distinguish you from others. Always keep learning by attending professional meetings, obtaining certifications, and reading in the profession. I make it a goal to read at least one book a week on topics related to by personal and professional growth (testing, leadership, business, IT, etc.).

     

    One personal development guru noted that if you read 30 minutes a day on any given topic, in five years you’ll be an expert on the topic. It worked for me – try it for yourself!

     

    Another great way to stay sharp and to build a network is to stay active in some of the QA and testing forums. Some of my favorites are at http://www.stickyminds.com/, http://www.qaforums.com/, and to sound our own bell, we are starting forums at http://www.riceconsulting.com/.

     

    14.              When the going gets tough, the lazy get creative

     

    I made a sign with this saying on it and hung it on my desk when I first became a test team leader. It reminded me to let creativity be my point of leverage in problem solving.

     

    Learn to see problems in a new and creative way. You may have a good test plan, but how will you deal with changes? Flexibility is a key attribute of good problem-solving leaders.

     

    15.              Simple is not always easy.

     

    Much of what we do in testing seems simple. However, the challenge is in the consistency required to maintain the effort.

     

    Some solutions to problems may seem too simple at first, but don’t discard an idea just because is it simple and obvious. Also, don’t underestimate the effort needed to implement a simple idea!

     

    Some readers of the book I co-wrote with William E. Perry, Surviving the Top Ten Challenges of Software Testing, have commented that the challenges are simple and easy to solve. That makes me wonder why people still raise the same “people problems” year after year. I think it is easier to obtain the head knowledge than to actually implement the solutions at work.

     

    Conclusion

     

    Before knowledge, comes wisdom. You may learn a lot of testing techniques, but your ability to apply them will be limited if you don’t have the wisdom to know when to apply them and the context to understand them. One of the problems you have in starting out in just about anything is that "you don't know what you don't know." Wisdom helps you understand what you need to know to be successful.

     

    The things I have listed are things I wish I had fully realized when I first started testing. I hope they serve you well.

     

    As always, I would like to hear your comments about things you would have liked to known as a rookie tester. Just e-mail me from the contact page.

  • 我怎么就把这个用例写不好呢!!!

    2007-05-25 13:29:29

    今天我练习写个XP系统中的计算器中的减法测试用例,可是写了40个用例就晕了,不知道该怎么去接着写,头疼!!感觉乱套了,不知道哪里写了,哪里没写,唉,关键是开始没写好计划,没划好等价类,可是我就是有点晕,不知道怎么能划的让头满意。我市新人,也不知道怎么样规范,难啊〉
Open Toolbar