zoukankan      html  css  js  c++  java
  • 对测试这事的一些看法

    4年的测试职业经历让我对测试【这件事】和【做这件事的人】有了较明朗的认识。

    【测试这件事】

    既然是一件事,那么就几个问题:

    目的是什么?

    目的就是保证被测系统的质量。这没什么可说的,测试的职责就是这个,一切都围绕这个主题进行。

    干些什么?

    说到干些什么,这里就出现了很多工作,不同的组织环境里有不同的工作,我见过大概分为下面几种:

    1.质量管理工作

      我把质量管理工作排到第1位是因为这是对下面测试工作的一个整体规划和测试工作的先决保证。具体会在下面说明。

    2.测试需求分析

      这件事的定位很模糊。其意义就是对已知需求进行分拆,拆到可以用某个单位去衡量某个功能点的程度。如果您的单位

      有专门做这件事,说明贵公司的测试工作很有前途,这件事就是指导测试工作的核心。

      例如:某个有查询功能页面,可以分为:单独查询条件查询、组合条件查询、有结果查询,分页查询、无结果查询等

    3.测试用例编写

      测试用例在我看来必不可少,请不要将他作为一种形式上的存在,测试用例应当用基线管理起来,它能体现被测系统

      当前时间点上的完成程度,是项目经理度量项目进度的一个最直观最可靠的看板。而我们测试工作的节奏结合测试用

      例反映出的情况来调整,才是最科学合理的。而不是各自感觉上的结论。测试用例这件事真可以拿出来单独说一说,

      在这里就简单说下我自己的感受。

      测试用例粒度:如果有专门做测试需求分析,那么测试用例的粒度由测试需求分析来决定。如果没有,则完全靠编写

             测试用例的人来控制,通常都是数个人一起写,带来的结果就是粒度不均。结果呢,就是导致系统的

             质量无法控制和保证。

      测试用例详细程度:一般测试基本分为:输入、步骤、预期结果。在不同的项目中要求的详细程度不同,我认为输入

             与预期结果必须写,而且要写的非常清楚。这两项决定了测试用例的测试目的。而步骤的详尽程度则

             可以根据实际需要来写,但必须将决定测试目的的关键操作写清楚。

      测试用例的管理:测试用例一定要管理起来,什么是管理?就是创建、评审、执行、变更、归档。创建不用说了,评

             审这件事其实非常有必要,只有测试用例的质量过关,那么被测系统的质量才有保证。执行,测试用

             例的执行不是一次性工作,在各个测试执行阶段(集成测试、系统测试、回归测试、验收测试)中每

             次执行都要对测试结论有记录。保证不漏测。变更,测试用例的变更肯定是非常频繁的,如果不更新

             测试用例,版本迭代后,它就没有价值了,因为被测系统已经变了。归档,归档的重要性就在于重用

             ,某些测试案例是可以重用的,利用起来能减少不少工作量。

    4.测试执行(去被测系统中寻找不符合需求的地方)、提交缺陷

      测试执行,这件事没什么好说的,测试工作的大多时间再做这件事。其实,只要上面的几件事情做好了,这件事根本

      就是最简单、最无脑的。否则这件事就是最不靠谱的,最难做的。试想几个人没有任何计划和目标在被测系统中瞎点

      瞎用,质量保证从何说起?

      提交缺陷、跟踪缺陷:好了,体现测试工作成果的事来了。其实这件事只能大概的表明当前被测系统的情况,至于什

      么测试工作的绩效,开发工作绩效请不要从这里来看,它对这类指标没有反映。缺陷没什么好说的,与测试执行一样

      只要前面的事情做好了,这些都不是事。这也体现了8/2原则,做20%的事就能决定剩下80%的事儿。

    这些事由谁来做?

      将事儿和人对应起来说明下我的经验:

      质量管理工作:需要一个测试经验丰富、有管理知识技能的人。

      测试需求分析:需要一个测试经验丰富、有很强业务分析能力(两个方面:跨行业新业务的分析能力、已有的业务知

      识)、熟悉软件工程(架构、开发、数据库等知识,这方面越强越好)、很好的表达沟通能力。可以说,测试需求分

      析工作的担当人是测试工作的灵魂人物,说他是项目组的核心层人物也不过分,因为质量是软件的核心,而质量保证

      的核心就是这个人。其实和需求分析师很像,但现在需求分析人通常与客户接触的多,转化出的需求通常不会太详尽

      而这个测试需求分析人工作正是对需求分析人的成果再次细化和检查。

      测试用例编写:其实说了上面的测试需求分析人,这里就很明显了。如果没有测试需求分析人,那么测试团队所有测

      试人的素质都要提高到测试需求分析人的程度才能保证质量,哪边合算一眼就出来了。而且项目从来都是一把手工程,

      这么多高素质的人,究竟听谁的?

      测试执行:这个环节没有测试经验的人也能担当,这也是被国内IT行业认为最没有技术含量的环节。也确实如此,就

      像一般招聘要求中那样,耐心、细心即可担当。

    测试人的发展

      我认为测试人有3条路走:

      第1条:管理岗——测试人要走到这里,需要全面提高自己,管理、技术、沟通、经验一个都能少。

      第2条:技术牛人——两个方向:性能测试;自动化测试;

           性能测试:需求面比较低,而且真正的性能需求要求的人员素质非常高,说要求架构师的素质也不为过。

           自动化测试:需求面呈上升趋势,而且这也是未来测试发展的需要。现在不是有个职位叫开发测试吗。而且薪

           酬和开发已经平起平坐了。

      第3条:销售——这个比较奇葩了,但也未尝不是一条好路。如果你有很好的社交能力,再加上你对本公司产品的熟悉

           程度,相信做一个销售也是很好的选择。

    至今困扰我的问题

      公司策略与项目资源的约束是测试工作无法正确开展的根源,对于这种情况如何才能将测试工作做到科学合理?还是说

    尽人事听天命?

  • 相关阅读:
    mojo 接口示例
    MojoliciousLite: 实时的web框架 概述
    接口返回json
    centos 6.7 perl 版本 This is perl 5, version 22 安装DBI DBD
    centos 6.7 perl 5.22 安装DBD 需要使用老的perl版本
    商业智能改变汽车行业
    商业智能改变汽车行业
    读MBA经历回顾(上)目的决定手段——北漂18年(48)
    perl 升级到5.20版本
    Group Commit of Binary Log
  • 原文地址:https://www.cnblogs.com/zzzhuxf/p/3461923.html
Copyright © 2011-2022 走看看