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

我的最新日志

• 与测试工作相关

  2008-7-09

  事件过的飞快，不知不觉已经参加工作一年有余，一年下来也真正的具备了一点所谓的测试经验，测试经验得来并不难，难的是怎么在已有测试经验的上再有所提高，测试行业的门槛低，收入也低，很多公司口头上都是说重视测试，但是测试人员的待遇远远低于开发人员，这也是测试人员的悲哀，但是有一点要说明，如果没有测试人员，全凭开发人员就能够开发出没有缺陷的软件是天方夜谭。

  查看(15) 评论(0)

• 今天比较郁闷

  2007-12-12

  今天要寄点东西回学校，本来可以选择快递公司的，可是又怕快递公司的不安全（可能是我平时太小心了），最后还是选择了邮局，可是去邮局真是波折，坐错公交车，这已经不是第一次了，有的时候真是怀疑自己在外边的生活能力，很想回家那边工作，可是男朋友在这边，也许选择一个人就选择一个生活方式吧，

  查看(23) 评论(0)

• 测试其实好烦，让我说什么好

  2007-10-10

      又是一天过去了，今天跟往常一样看了一天的文档，全是英文的，看的好烦，想到以后的测试，会更烦，项目很复杂，又都是英文的，要写超多的测试用例，不知道何时才能把工作做完，最主要的做这么多工作，却得不到相应的汇报，测试还是会不受重视，咳，

  查看(40) 评论(0)

• 第一次参加UAT

  2007-10-08

    今天要第一次UAT了，以前从未参加过，所以感觉好新奇，早上好早就爬起来赶往客户那边，首先PL把系统环境搭建好，测试人员这个时候就是打杂咯，把测试用例分类，然后就是客户进行测试，哈哈，好简单。

  下午回到公司，继续写自己的测试用例。

  测试其实还不错，主要就是找错误，一般项目刚开始会有好多错误出来，一下子找出好多错误真是好兴奋，哈哈，只要是把需求搞清楚了，测试就很简单了，哈哈。

  查看(44) 评论(0)

• 测试之后还是测试，

  2007-9-28

     参加工作了，以前没有参加过工作，哈哈，以为会是一件很激动人心的事情，可是一切都来的平淡无奇，没有感觉到任何的过渡，跟想象的很不一样，觉得测试有前途就选择了测试，工作的任务就是每天读文档，最烦的是要读英文的文档，写测试用例，真是烦的要死，任务又重，每天早上爬起来就是盯着文档看，真是无聊，不过想想，做开发应该也有趣不到哪去。做这行就是会这样子，没的办法。

  查看(20) 评论(0)

• 不再做傻大姐

  2007-9-14

     现在才发现知道的东西太少，包括生活和工作上的，很多时候像白痴一样，被讥笑为外星人，哈哈，以前可以原谅自己的无知，如果继续助长自己的无知，继续无知下去将是自己所不可原谅的，无知不是可爱，是落后是可耻的，所以以后要主意咯。

  查看(20) 评论(0)

• 一位前辈工程师职业发展的忠告

  2007-8-15

  好好规划自己的路，不要跟着感觉走！根据个人的理想决策安排，绝大部分人并不指望成为什么院士或教授，而是希望活得滋润一些，爽一些。那么，就需要慎重安排自己的轨迹。从哪个行业入手，逐渐对该行业深入了解，不要频繁跳槽，特别是不要为了一点工资而转移阵地，从长远看，这点钱根本不算什么，当你对一个行业有那么几年的体会，以后钱根本不是问题。频繁地动荡不是上策，最后你对哪个行业都没有摸透，永远是新手！

  可以做技术，切不可沉湎于技术。千万不可一门心思钻研技术！给自己很大压力，如果你的心思全部放在这上面，那么注定你将成为孔乙己一类的人物！适可而止为之，因为技术只不过是你今后前途的支柱之一，而且还不是最大的支柱，除非你只愿意到老还是个工程师！

  [3]不要去做技术高手，只去做综合素质高手！在企业里混，我们时常瞧不起某人，说他“什么都不懂，凭啥拿那么多钱，凭啥升官！”这是普遍的典型的工程师的迂腐之言。

  很牛吗？人家能上去必然有他的本事，而且是你没有的本事。你想想，老板搞经营那么多年，难道见识不如你这个新兵？人家或许善于管理，善于领会老板意图，善于部门协调等等。因此务必培养自己多方面的能力，包括管理，亲和力，察言观色能力，攻关能力等，要成为综合素质的高手，则前途无量，否则只能躲在角落看示波器！技术以外的技能才是更重要的本事！！从古到今，美国日本，一律如此！

  [4]多交社会三教九流的朋友！不要只和工程师交往，认为有共同语言，其实更重要的是和其他类人物交往，如果你希望有朝一日当老板或高层管理，那么你整日面对的就是这些人 。了解他们的经历，思维习惯，爱好，学习他们处理问题的模式，了解社会各个角落的现象和问题，这是以后发展的巨大的本钱，没有这些以后就会笨手笨脚，跌跌撞撞，遇到重重困难，交不少学费，成功的概率大大降低！

  [5]知识涉猎不一定专，但一定要广！多看看其他方面的书，金融，财会，进出口，税务， 法律等等，为以后做一些积累，以后的用处会更大！会少交许多学费！！

  [6]抓住时机向技术管理或市场销售方面的转变！要想有前途就不能一直搞开发，适当时候 要转变为管理或销售，前途会更大，以前搞技术也没有白搞，以后还用得着。搞管理可以培养自己的领导能力，搞销售可以培养自己的市场概念和思维，同时为自己以后发展积累庞大的人脉！应该说这才是前途的真正支柱！！！
  [7]逐渐克服自己的心里弱点和性格缺陷！多疑，敏感，天真（贬义，并不可爱），犹豫不决，胆怯，多虑，脸皮太薄，心不够黑，教条式思维。。。这些工程师普遍存在的性格弱点必须改变！很难吗？只在床上想一想当然不可能，去帮朋友守一个月地摊，包准有效果 ，去实践，而不要只想！不克服这些缺点，一切不可能，甚至连项目经理都当不好--尽管你可能技术不错！
  [8]工作的同时要为以后做准备！建立自己的工作环境！及早为自己配置一个工作环境，装备电脑，示波器（可以买个二手的），仿真器，编程器等，业余可以接点活，一方面接触市场，培养市场感觉，同时也积累资金，更重要的是准备自己的产品，咱搞技术的没有钱 ，只有技术，技术的代表不是学历和证书，而是产品，拿出象样的产品，就可技术转让或与人合作搞企业！先把东西准备好，等待机会，否则，有了机会也抓不住！

  [9]要学会善于推销自己！不仅要能干，还要能说，能写，善于利用一切机会推销自己，树 立自己的品牌形象，很必要！要创造条件让别人了解自己，不然老板怎么知道你能干？外面的投资人怎么相信你？提早把自己推销出去，机会自然会来找你！搞个个人主页是个好注意！！特别是培养自己在行业的名气，有了名气，高薪机会自不在话下，更重要的是有合作的机会...

  [10]该出手时便出手！永远不可能有100%把握！！！条件差不多就要大胆去干，去闯出自己的事业，不要犹豫，不要彷徨，干了不一定成功，但至少为下一次冲击积累了经验，不干永远没出息，而且要干成必然要经历失败。不经历风雨，怎么见彩虹，没有人能随随便便成功

  查看(41) 评论(0)

• 常见112个测试英语面试题

  2007-8-13

  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?

  查看(210) 评论(0)

• 测试工程师的一天(收录)

  2007-8-13

  看到的文章，本人觉得很有用，就收藏了，

  1. 引言
     软件测试成为最近 IT 行业的“香饽饽”，引得很多人对软件测试跃跃欲试。可是软件测试的门槛并不低，对于没有软件测试经验的新人而言，如何尽快转入测试工作中去呢？
     了解软件测试都做些什么，具体过程是怎么进行的，可以有助于对软件测试进行初步了解，尽快进入测试工作角色。但是关于软件测试的工作流程，各种现有书籍和文章往往都描述的非常复杂，充斥着不少测试术语，使测试初学者望而生畏。
     现在让我们换一种角度看看典型的软件测试是如何进行的，暂且把软件测试过程看作一场大戏，主角就是测试工程师，按照时间顺序记录软件测试工程师一天的工作场景（假设正常工作时间 9:00 到 18:00 ）。
     2. 测试大戏开演
      时间： 9:00
      工作场景：
  •        启动工作计算机，查看收到的电子信件。
     画外音：
  •        查看收到的电子邮件（哇塞，这么多电子邮件！），理解当天的测试工作的内容和要求。
  •        测试工程师至少配置两台计算机：其中一台是日常工作用，例如，收发电子邮件等。另外还有一台软件测试用的计算机。
     时间： 9:10
     工作场景：
  •        回复电子邮件。
     画外音：
  •        回复电子邮件。如果对于安排的测试任务和要求存在任何疑问，请在回复电子邮件时列举出来。如果任务明确，回信中可以简单的说明理解测试任务了，按照测试任务要求进行测试。（正好今天有一封电子邮件分配了测试任务 A ，而且任务明确，测试文档等完整。）
  •        电子邮件有不同的优先级，任务非常紧迫的电子邮件应该优先处理，尽快回复。（面对多封邮件保持镇定，分清哪些邮件需要马上回复）
  •        并非全部的电子邮件都需要回复（抄送给自己的邮件和一般通告等不需要回复）
     时间： 9:25
     工作场景：
  •        启动用于测试的计算机
  •        根据测试要求配置操作系统、安装要测试的软件
  •        根据测试用例执行测试任务 A 。
     画外音：
  •        测试一般需要按照测试指导文档和测试用例进行。（软件测试可不是盲目的乱测一气的呀！）
  •        很多软件的测试要求在一个“干净”的计算机上测试（提示：干静的计算机是仅安装了操作系统，没有安装其他应用程序的计算机）。
  •        在进行正式测试前，需要阅读测试文档，明确测试任务（这些测试文档你找到了吗？是最新的测试文档吗？）。
     时间： 11:00
     工作场景：
  •        执行软件测试，书写软件测试 Bug 报告
     画外音：
  •        按照测试要求，尽量多找出软件的 Bug 。（什么破软件，能找出这么多 Bug ！ 反过来想，软件如果没有 Bug ，我们测试工程师不就失业了吗！）
  •        根据发现的软件 Bug ，按照客户要求写出每个 Bug 的报告（要书写明白，否则客户事后会要求你重写，很费时间，也影响公司的测试质量，是否很没有面子？）
     时间： 11:30
     工作场景：
  •        报告测试执行中的遇到了问题
     画外音：
  •        如果测试用例的步骤不明确或者测试的软件不能成功安装，无法进行下面的测试，应该及时向测试负责人报告，等待答复后进行测试。（重大问题，切莫瞒报，也别主观想当然地猜测！）
  •        如果某些测试步骤不明确，但是可以暂时跳过，请向测试负责人报告，并且继续进行下面的测试。（灵活处理，合理利用时间，时间就是金钱！）
     时间： 12:00
     工作场景：
  •        查收和回复新邮件，新邮件又来了一个新的测试任务 B ，而且要求紧急处理。
  •        暂停测试任务 A ，进行测试任务 B 。
     画外音：
  •        测试过程中，要主要定时查看是否有新邮件，特别是那些要求非常紧急的任务。（重要任务一定要优先处理，否则就是工作失职）
  •        如果新任务比较紧急，应该中断当前的测试，接着执行新任务。（为什么计划总是没有变化快，可是现实就是这样。）
     时间： 12:30
     工作场景：
  •        午餐、休息
     画外音：
  •        阳光、午餐、休息，美！（禁止在办公室玩任何电子游戏，办公室不是娱乐场所！）
     时间： 13:30
     工作场景：
  •        查收和回复新邮件
     画外音：
  •        真幸运，没有其他新任务。
  •        继续上午的任务 B 。
     时间： 14:30
     工作场景：
  •        完成新任务 B ，向测试负责人提交任务 B 的测试结果
     画外音：
  •        完成任何任务后，需要向测试负责人发送任务完成的电子邮件。（这一点很重要的，否则你做的工作再多，测试负责人也不一定很清楚）
  •        提交任务的电子邮件中，应该写明任务是否全部完成，存在什么问题，测试结果存放在什么计算机的哪个目录中。（想象测试负责人需要你提交哪些内容，最好在一封信中交待明白，完整，清楚，条理分明）
     时间： 14:40
     工作场景：
  •        发送测试任务 A 不能按期完成的电子邮件
     画外音：
  •        由于执行了新测试任务 B ，使得测试任务 A 不能按时完成，应该及早向测试负责人发送电子邮件。（如果你不主动说无法按时完成任务 A ，测试负责人就默认为你能够按时完成。而如果到了完成任务的最后期限，而你突然向测试负责人说任务还没有完成，那么我可以很负责任地告诉你：测试负责人将会很生气，后果很严重！）
  •        得到测试负责人的答复后，继续执行测试任务 A 。
  •        如果客户要求必须当天完成测试任务 A ，可能要做好加班准备（苦恼 … ）。或者请测试负责人将一部分任务分解给其他测试人员执行（呵呵，谢谢兄弟们拉我一把 ... ）。
     时间： 14:50
     工作场景：
  •        继续执行测试任务 A 。
     画外音：
  •        寻找软件 Bug （这是主要任务之一）
  •        书写 Bug 测试报告（这也是主要任务之一）
     时间： 15:30
     工作场景：
  •        查收和回复新邮件
     画外音：
  •        没有新电子邮件，呵呵！（最不喜欢在测试工作中，经常有邮件来骚扰！）
  •        继续执行测试任务 A 。
     时间： 17:00
     工作场景：
  •        参加测试小组内部会议
     画外音：
  •        经常在测试过程中，测试小组内部会召开短暂的会议。（交流很重要的，倾听和发言一个都不能少）
  •        会议内容一般是测试过程中遇到的问题，以及可能的解决办法，也包括测试进度是否与测试计划保持一致。
     时间： 17:30
     工作场景：
  •        发送当天任务完成情况的电子邮件
     画外音：
  •        当天任务完成情况的报告应该在下班前尽早发送给测试负责人，以便得到及时回复。
  •        总结当天测试任务完成的情况（全部完成还是部分完成）
  •        测试遇到的需要测试负责人或者问题客户帮助解决的问题（遇到问题一定要反映，不要什么问题都自己扛！）
  •        给出当天处理 Bug 的数量、类型和存放位置（确保测试负责人能很容易的找到这些测试结果吗？）
     时间： 17:45
     工作场景：
  •        整理当天的测试文档，
  •        做好备份
  •        个人总结
     画外音：
  •        备份当天的测试结果（有备无患！）
  •        总结测试遇到的问题和学习的新知识（好好学习，天天向上！）
  •        准备第二天的测试任务（未雨绸缪）
     时间： 18:00
     工作场景：
  •        下班
     画外音：
  •        如果不需要加班，按时回家，爽！
     3. 测试大戏背后的故事
     上面的测试场景描述基本上反映了软件测试工程师的工作情形，但是由于测试工作的复杂性、琐碎性、变化性，实际测试过程将是不断变化的。
      测试的变化性
     对于软件本地化等外包测试，测试过程和测试要求因不同客户而异，即使相同客户的不同项目，也会有些变化。另外，测试所用的测试计划、测试用例、测试 Build 版本经常变化。这是对测试工程师需要面对和正确处理的工作挑战。
      多任务同时处理
     软件测试工程师在一天的工作时间里，可能需要做多件事情（例如，测试负责人可能中间会安排新的任务），正常测试过程经常被中断，对此需要有相应的心理准备。
      及时交流
     测试过程很少是一帆风顺的，特别是不熟悉的新软件，或者测试用例没有表达清楚。这时除了自己学习和思考，还需要向测试组的其他同事请教。如果问题仍然没有解决，请及时向测试负责人反映情况，寻求帮助（提示：测试负责人积累了软件测试经验，一般问题都可以搞定，但是测试负责人也不是万能的，他们也有很多不能解决的问题，但是他们有“杀手锏” — 向客户的测试负责人寻求帮助，由于源语言是客户开发的，客户才是万能的！）。
     电子邮件是主要的交流方式
     测试过程不要一味地在测试计算机上做下去，要经常在日常工作用计算机查看和回复电子邮件，以免耽误了更重要的任务。除了电子邮件之外，也可以打电话和即时网络交流工具（ MSN 等），或者面对面与同事交流（提示：对于复杂的问题，与其来回发送多封电子邮件还说不明白，还不如打个电话或者面对面交谈更有效）。
     4. 结束语
     有人说，测试很枯燥，而且“一点技术含量都没有”。也有人说，软件测试大有前途！现在中国确的不是软件编程大师，而是软件测试大师。这些观点孰是孰非，您请自己琢磨。不过既然从事了测试行业，还是将它做好为上！

  查看(303) 评论(4)

• 测试进阶三步曲（转录）

  2007-8-13

  ，入行导读
  

  测试这个领域，入门浅，真正进入之后才会发现其博大精深，涉足6年余，才仅有点感觉，在此稍做总结，与涉入测试领域的同志共勉：
  
  阶段一：入门 1、软件工程：软件开发模式首先了解软件研发的过程，才能采取不同的测试策略。如传统的瀑布模型，就可以按V模型的方式进行测试的计划、设计和执行工作；如果是RUP方式，则测试过程就要按照历次迭代进行分阶段的测试，每次迭代的测试方法和重点会有所不同。还有很多开发模式，测试工作都需要根据不同情况进行适当调整。 2、测试理论：基本过程与方法系统测试、集成测试、单元测试以及BETA测试、验收测试等的测试依据不同，所使用的方法也不同，边界值法、等效类划分、错误推测、因果图以及条件覆盖、判定覆盖等等，方法非常多，在各阶段测试设计过程中都会用到，所以作为基础课程必须掌握。
  
  二、进阶 了解了上面两条，相当于刚学会什么叫编程语言、C语言的语法是什么，能编写HELLOWORLD小程序了，会编码不等于能编好代码，测试也是一样。掌握上面两条已经可以拿着一个产品说明书开始用产品了，进行初级的系统功能测试（勉强算测试吧：），真正要深入，还需要再学习以下内容 3、软件特性：软件产品的基本特性 首先知道一个软件必须要具有的基本特性，即一个好的软件是什么样子的，才可能去有目的的设计测试用例。ISO的一些标准中定义了软件的质量模型，functionality、reliability、usability、efficiency、maintainability、portability等，这些在真正进行测试设计前必须能够详细了解，没有这些基础，拿着简单的几份需求、设计文档进行测试是远远不够的。 4、测试设计：测试的精髓所在 要进行测试，必须要提前知道测试什么、怎么测，这时候就需要进行测试策略、方案、用例的设计了。这种设计的基础除上面提到的3个大的内容都要用到外，还要对被测对象进行重复的了解，同时要考虑是否需要驱动/桩模块/模拟环境的支持、如何来设计这些模块与环境、需要什么样的工具、用什么样的方法、用户真正使用的环境是什么等等，测试设计的能力需要在不断的实际项目操作经验中积累。
  5、测试工具－提高测试效率的手段 个人认为测试工具在测试知识领域内的重要性并不是很强，属于辅助性的一种手段，可以用来提高效率，但不能依靠它来保证产品质量。测试工具现在已是林林总总，见过的、用过的已有几十种之多，这部分的学习先从面上入手，从功能测试、性能测试、代码测试等几个领域找出几个典型工具，先了解它们能做什么、不能做什么，在测试设计时可以根据情况具体选择，在测试实施过程中再熟练掌握。 掌握上面这些内容，已经可以参与一些项目的测试了，经过一、二年的实践经验，可以说骄傲地说自己已经是个测试工程师了。
  
  
  三、高级－更全面、更系统最主要经验更丰富 测试这个领域，所谓高级是无法确定的，所以在此也不敢指导如何成为高级测试工程师，只能说前5条都很熟了以后，可以在其它一些领域进行深入探索： 6、测试流程 方法、工具是回事，真正能把这些东西连贯使用，很好的执行，还需要测试流程来保证，业界有现成的流程可参考，但也只能做参考，团队的规模、产品的领域不同流程肯定不同，制定一套完整、顺畅的流程才是让测试工作有效执行的保证。 7、系统分析 具有系统分析能力的测试工程师才能在产品早期即需求、设计阶段发现产品的问题，盲目地跟着开发需求、设计文档走地测试只能保证产品问题不多，产品没问题并不代表产品就能用、好用。 8、技术创新 测试领域没有固定的、一成不便的理论和方法，在经验积累之后，可以针对产品、环境的不同摸索出不同的流程、方法，可以设计自己的测试文档体系，也建立自己的测试工具平台，向上的空间是永无止境的。  
  
  
  
  目前业界测试工具包括商用的、免费的至少也有上百种，仅掌握一、两种测试工具如同沧海一粟，是远远不够的。测试如同编程，测试如果要做好，真正的决定因素在于测试的设计，工具只是辅助工作的一种手段而已，换句话说，测试工程师才是测试工作的主体，测试工程师的能力和素质决定了测试工作和产品的质量。测试工具象是工程师手里的双刃剑，选不好或用不好就不能提高效率、节约成本，如一些功能自动化测试工具，如ROBOT、QARUN、WINRUNNER之类的，对于新推出的产品，往往客户需求经常变化，版本间改动会很大，这时这些工具就用不上，因为每次都要重新录制脚本，下次还用不上，录制脚本的过程实际就是测试的过程，这个阶段的功能完全手工测试就可以了，而当版本成熟后，问题和改动比较少，这时后用功能自动测试工具主要目的仅是为避免因改动导致其它原正确使用的功能出问题（新增特性本身的测试还是要手工测试一遍的），但这种情况只要严格控制开发人员代码修改范围、做好代码走读（小修改的代码量很少）、测试人员做好周边相关功能的测试（这就要求测试人员对产品功能、系统结构的全面了解），完全可以避免，而且在使用这些工具过程中，测试人员还要花费时间去掌握脚本编程，有些工具仅支持几种语言和有限的控件，超出这些范围又要更换工具，这样算来，费用就远远不止十几万、几十万买一套工具了，人工成本增加不少，测试效率也未必提高。性能测试工具也很多，而且侧重点也不同，商用工具共同的特点就是奇贵，其实业界管理类软件的复杂度并不高，C/S、B/S结构的免费性能测试工具网上大把，选择一个简单好用的下载就可以了，完全没必要花重金买或用盗版的商用工具。商用性能测试工具以前用过的比较好用的也就算quantify了，用起来很简单，分析报告很细很管用，用它发现和解决了大型软件中的很多性能问题。个人认为在免费工具不能满足要求的情况下建议自己来开发性能测试工具，因为无非就测试那么几项内容，所用技术也无非就是网络编程的基础技术，这样积累下来，容易形成针对同类产品的一个实用的性能测试平台，对一个测试组就足够用了。单元测试工具建议还是必须要用的，无论商用还是免费的都可以，因为把问题扼杀在编码阶段比后期系统测试更能有效提高产品的质量。测试过程中的工具也不仅是功能、性能的自动测试，还有一些仿真工具、协议分析工具等，这些的专业性很强，可根据不同的产品来专门选择。另外，可以自行开发一些测试环境准备的小工具，对提高测试效率也是很有帮助的。总之，测试工程师要做好一个产品的测试，适当采用测试工具是必要的，但没必要完全迷信于那么一、两种测试工具，不能过分依赖测试工具，只有对各种测试工具全面了解，才能冷静、客观的去分析和选择。另外，规范开发流程、测试过程、强化测试设计的能力和素质，都是保证产品质量的有效手段。人的素质提高、作用提高了，工具的作用自然会相对减弱，企业也就会把关注点从测试工具使用转移到测试人才培养，测试工程师的地位也就会逐步得到提高了。

  查看(44) 评论(0)

我的主题

• 有苏州的测试群马？
• 大家做测试的流程是怎么的阿