zoukankan      html  css  js  c++  java
  • 一个工作5年的软件测试员工的对软件测试的理解和总结【精品文章】

    原文:http://www.cnblogs.com/jwentest/p/7435461.html

    背景

    工作五年了,一直是做测试。认识了很多人大牛,也接触到很多新人,从他们身上看到了很多,自己的过去,自己的未来(当然很多是自己达不到的高度)。

    做这测试这一行的,很多人都追求技术:自动化+性能,往往忽略测试流程,或者说是项目管理流程。

    想法

    流程是要结合团队来看的,换句话来说就是case by case,没有标准,适合团队/业务的流程就是好流程;

    Part1

    待过做中国移动项目的传统行业,测试流程一套一套的,需求评审 -- 开发详细设计评审 -- 用例评审 -- 提测评审 -- 测试执行 -- 报告输出 -- 安排上线 -- 线上验收,很多会议是需要产研测全部参加的,时间投入很大,这原因是因为项目/业务迭代周期是一个月上一次版本,有足够的时间去做这些,当测试全流程介入的时候确认能发现很多问题,这里就引入一个词:质量前移 ,比较好理解,不是在测试执行才发现问题,而是将问题前移,移到需求评审,设计评审,用例评审中去,这一步做的好的就是测试的一个方向:业务专家 ,看项目/产品的高度达到了产品高度,从全局去考虑测试用例场景,对业务非常熟悉,提升影响力,开发/产品会来咨询你业务知识;

    Part2

    回想起唯品会的流程,有很多值得借鉴的地方。

    唯品会的流程,核心是火车发布制,项目安排是每个星期发布一个版本,也就是每个星期只有一趟车,项目想上线的话,就需要在指定时间上车,意思就是在规定时间开发测试打包完毕。整个项目的流程就是按照这个火车开车时间来排期规划。(当然你要问到很多线上问题怎么办?紧急项目怎么办? 春运不是也有临时车次这个说法吗?)

    在互联网行业的话,迭代速度明显加快,都是你追我赶的节奏,但很多流程也是必须有的。

    需求评审会根据需求大小来看是否开展的,小需求的话,就直接是一份文档查阅就完事了的。

    在唯品会的时候,所在团队有点做的比较好,就是提测环节,我们要求开发提测有输出,要求他们整理功能点:新增/修改了哪些功能,改动了哪些文件,自测点,自测结果,静态代码检查,单元测试是否全部通过,这些也是测试的一种职责,项目的保证不单单只是测试的事情,测试有义务/责任从整个项目流程中去提升质量。

    提测过后,测试要经过冒烟测试,这个冒烟首先要检查开发的输出是不是包含了上面提的那些,测试有权利直接打回这次提测,阻塞主流程的问题也要打回,冒烟不通过。冒烟不通过的项目代码质量堪忧;

    功能测试,测试人手一台测试机器,将项目部署在自己的环境进行功能测试,(这里讲一句,唯品会这方面确实壕,而开发是整个团队公用一套开发环境,哈哈哈)

    回归测试,功能测试完毕后,需要开发合并代码到master(最终上线的分支),由于多个项目并行,可能存在代码合并问题,需要重新再回归一轮,这个环境可以验证主干用例,也可以用自动化去验证 ,这里还有一个code review环节;

    这里需要单独提一点,代码权限控制,开发合并代码后,是没有push代码的权限了的,代码权限控制在测试手中,这个时候需要修改代码,原因为功能测试遗漏,或者是合并代码错误,可以做一个统计;

    预发布测试,回归OK后,打包部署到预发布环境,这个环境都是生产的数据库了的,重点校验配置(配置文件,DB...)是否OK,到了这里也有很多测试不通过的情况,可以做统计数据;

    上线验收,提供给运维最终的包,做上线验收

    唯品会一些细节的流程做的比较好,上线前会有小组的上线评审,这个环节的话,需要说明这个项目有什么功能;会不会对线上旧功能造成什么影响;存在什么风险;是否可以线上验收,若有怎么验收,如果没有什么做监控;回滚方案是什么,集思广益

    需求评审 -- 用例评审 -- 提测 --  冒烟测试 -- 功能测试 --  回归测试 -- 预发布测试 --  线上验收 -- 数据监控

    Part3

    现在的UC,没有火车发布制度,项目并发更多,很多都是今天提测明天上线的节奏,更加敏捷。一些关键流程的缺失会带来一些风险,但核心点不变,质量前移和监控,这就是看到过一篇文章提到的左移和右移。

    团队也在慢慢加强流程这块东西了的,质量的保证是整个团队的事情,测试有业务和责任去提升质量,这里的质量部分是从项目流程去提升的

    小结

    测试,不是找bug,应该称为质量保障,其中的手段就是你职业规划的路线。

    管理,也估计是很多人想走的路线吧,很多人觉得在一家公司混久点就能走上管理层,但我发现在管理层混的好的,都是业务专家,都是会为人处世的,有项目整体风险意识的,当然也需要一定的机遇;

    技术,这条路是很多测试同学在走的或者想走的,想搞自动化,想搞性能,因为技术的提升意味着工资的提升,学好一门语言是非常重要的

    不管是做什么的,自身掌握了稀有资源,待遇自然上去了的。

    回到这次的主题:流程,工作经验的优势就要凸显出来,以过往经验结合现有团队情况,制定流程,或者对现有流程提出建议;

    1. 质量迁移,测试提前介入,从需求端发现问题,带着问题去开需求评审,怼产品/需求;

    2. 合并代码回归测试,跟开发沟通后,不要直接上线,需要重新过一遍;

    3. 上线评审,思考上线依赖,风险,旧数据/功能影响,回滚方案;

    虽千万人,吾往矣!
  • 相关阅读:
    tile38 复制配置
    The Guardian’s Migration from MongoDB to PostgreSQL on Amazon RDS
    tile38 一款开源的geo 数据库
    sqler sql 转rest api 的docker 镜像构建(续)使用源码编译
    sqler sql 转rest api javascript 试用
    sqler sql 转rest api redis 接口使用
    sqler sql 转rest api 的docker image
    sqler sql 转rest api 的工具试用
    apache geode 试用
    benthos v1 的一些新功能
  • 原文地址:https://www.cnblogs.com/zidonghua/p/7435911.html
Copyright © 2011-2022 走看看