发布新日志

  • 软件测试面试常用的英语问题

    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?

  • 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.

Open Toolbar