zoukankan      html  css  js  c++  java
  • 关于测试流程的一些总结

    做了将近一年的功能测试,现在转入到了自动化测试来。

    功能测试自己做的算不上很精,但基本的流程还算清楚。

    功能测试给我的感觉就是--不受重视。最起码测试人员没有受到重视。

    听到最多的就是,产品都会做,产品都能取代你们。

    说这话肯定是不懂测试的人。至少肯定不是我一人碰到这种不受重视的待遇。

    痛定思痛,行,我学代码去,学自动化去,学更多的技术去。只要工作闲下来,俺就去学,报培训班,自学两者兼有,看测试理论书籍,学测试工具,

    总而言之,言而总之,不虚度光阴,不混日子。更不能被人看不起,为未来,为安全感 ,为可观的收入,自己不能停止学习的脚步。

    上述这些话并没有抱怨,测试人员自身的技术水平决定了自己是否能得到重视。其实测试这个岗位,说得再重要都不为过。不是因为自己做这个,而是岗位决定的。(如果没有中纪委,官员就会不自觉。如果没有廉政公署,警员就敢明目张胆的勒索。如果没有测试,开发就敢不按规范来,反正自己觉得自己开发出来的肯定没有什么大问题,是按照需求来的。哈哈。一个优秀的 开发人员是在测试人员的督促下,慢慢提高自己的规范,提升自己的技能。这话真不假。当然他想成为优秀的开发人员,不然,就会和测试人员扯犊子了。)

    多话不说了,自己总结一下一年多来,对测试流程的概述。

    首先,产品立项(会有聚会活动的。通常大吃一次)

    等产品人员出文档。(测试这个时候可以先想一下测试计划,测试需要的硬件资源登记,软件工具准备。等准备工作要做起来)

    产品人员文档出出来后,先进行评审,也就是通常说的需求澄清。(需求文档也是一个不断完善的过程,这也是为什么后期需求会变更,开发要骂人的原因,有时也是客户的原因,临时变更)

    一个系统的成败,产品需求的采集能影响至少50%,我做过一个失败的系统,就是因为产品需求采集的原因,导致项目最后失败,当然,产品也被除名了。)

    其次,需求澄清时,产品,开发,测试,运营,客户等全部到场。评审产品规格书。这个时候,测试要小心,要逐字逐句的揣摩,要理解。配合需求说明书的还有产品原型。这是个好东西,根据它

    测试非常容易就画出思维导图。这个过程,是讨论,修改,再讨论,再修改的过程。直到大家都接受为止。现实大部分是客户能接受,不管研发的死活,只要能开发出来,不管难易。理论与现实总有差距。

    再次:需求澄清了,都开始干活了。开发出计划,出时间表,测试出计划,出方案。

    测试这时,要画思维导图,要写测试大纲,测试方案,接着就是测试用例。当然,先分工。具体到每个测试人员到系统的某个具体模块。

    测试经理收到各个测试人员的方案,导图,用例后,接着就是经常性的评审,分工,再评审,再修改。直到OK为止。

    再接着:测试人员的用例 评审通过后,就等着开发人员出模块了。出一个测试一个。直到下一个模块的出现。

    此时的开发改BUG的积极性不高。开发大部分喜欢在全部模块或大部分模块出来后,系统出现了雏形后,开发 再统一改BUG,前提是不要有一,二级BUG。

    如果这时开发非常配合,改了BUG后,测试人员就回归测试,跑个小集成之类的。发现一个提一个。(这时不要找到一个BUG就大声叫出来,表现的兴高采烈的样子,估计开发听到后,一定会横眉冷对你的。这个时候的开发人员重心放在开发新模块上,根本不愿意来配合你改BUG,一听到自己开发的模块出现了BUG,心里都是不爽的。)

    随着新模块开发出来越来越多,测试人员的工作量就直线上升了。重复提BUG,每天就是“点,点,点”,心里也是很枯燥的。(这个时候如果会自动化,就体现了工具的 价值)

    最后:开 发人员开发完了全部的模块,测试人员就要进行大规模的集成测试(公司测试人员多的话,活还能 及时干完,如果人少,测试就要苦逼了。),刚开发出来的系统,刚做前几次集成测试时,每 天不提十几个BUG,好像都不正常了。只有经过了多轮测试,每天发现的BUG数才能下降。如果经过了多轮测试,每天发现的BUG数还没有下降,或者原来没有的模块也出现了BUG,或者,改过的BUG回归通过了,又出现了。这个时候,就要反思开发人员的开发水平了,或者开发人员版本管理方面是不是出现 了问题,或者测试环境是不是有问题了。

    不去反思的话,BUG是测试不完的。或者还要考虑业务流程是否符合设计的需求了。(如果是这样,问题就大了。)

    再最后:BUG也改的差不多了,没有一,二级BUG了,至少是没有发现,3,4级BUG也控制在BUG总数的5%以内了,(当然BUG等级定义要清晰,这样才不会提高,降低BUG的严重程度)。

    再做最后上线前回归测试吧。加班,加班,再加班,这个时候的项目组要加班到很晚,而且要持续一周左右。

    等客户来验收了,有需求文档,合同,用例 来验收吧。来付款吧。

    一切顺利的话,大家都好。开庆功会。否则,挨屌是少不了的。(我以前公司开发同事的口头禅--不求有功,但求不被屌。哈哈,太没自信了。)

    上述的流程是概述,也有时不按这样的规范来。实际中,改了又改,测了又测。再改,再测。例如敏捷开发,真的很类似于边做边改的。哪有什么需求文档给你来参照。完全就是产品嘴上得来的信息。一周一两个功能模块的开发。以这样的进度。没有时间,毕竟时间就是生命。当然,测试的时间就更少了。

    测试前要搭建测试环境,测试结束后要写测试报告。这俩步不能漏了。

  • 相关阅读:
    隐藏TabControl的标签 上海
    最近写的一个存储过程 上海
    DBUS 介绍 上海
    存储过程 几个小例子 上海
    C# BHO 上海
    EXEC和sp_executesql的区别 上海
    office文档转换成mht文档(准备、原理篇) 上海
    Dictionary 排序 上海
    .Net 开源资源 上海
    Geant4.9.5.p01 in ubuntu12.04 OpenGL driver.
  • 原文地址:https://www.cnblogs.com/star12111/p/7546687.html
Copyright © 2011-2022 走看看