对软件测试岗位的理解_对软件测试岗位理解 - CSDN
  • 1、你如何理解软件测试软件测试属于软件开发过程的一个环节,与软件工程一起兴起于小型软件向大型软件开发额过渡期,按照中国人所说的人体是金木水火土的说法,如果用在软件工程上,那么测试就是一个结构进行...

    1、你如何理解软件测试?

    • 软件测试属于软件开发过程的一个环节,与软件工程一起兴起于小型软件向大型软件开发额过渡期,按照中国人所说的人体是金木水火土的说法,如果用在软件工程上,那么测试就是一个对结构进行校验的作用。

    • 按照我的理解,测试是一种思想,软件测试只不过是把测试思想用在了软件的开发过程当中了,测试是一种过程,从软件开发的微观上讲,他和软件开发的可以分离的,但是又会有联系,就像俩条平行线,开发出产品,测试测产品,就是这个样子。

    • 但是关于测试思想,说来话长,所有的东西都是可以测试的,就像说话遇到杠精,不管从哪里,都是可以找一个指标对你进行抬杠。测试也是一样,但是在工作中,则需要需要最好,最快,最省成本的测试所有的可疑点。

    • 对一个项目的测试,时间上的安排多种多样,开发前,开发中,开发完成后,但是,现在一般的项目都会走一遍,每一次的测试侧重点也是不一样的。

    • 测试就像是一种免疫系统,对整个项目进行检查,比如:整体架构,对暴力的免疫力,接口的漏洞……

    2、你为什么要学习软件测试?

    没有办法的!这里的老哥多,个个都是人才,说话又好听,超喜欢在这里的!

    但是,主要原因是因为:家里穷,我想多赚钱,抢劫没有胆,偷窃没有手艺,长得不好看,富婆又不要,我能怎么办?只好当一个民工,好找一个糊口的活计,但是技术又不好,我能干的别人都能干,我干不了的别人也都可以干,我怎么办?我有没有办法让别人不去学习!

    这里,我有想到一个笑话,一个大兵迟到了,上级问他:“每一个士兵都像你这样,怎么办?”那个士兵说:“那世界就会没有战争!”

    我想:如果我们程序工作者,每一个人都不要太贪心,会的技能少一点,工作时间每天就干8小时,多一分都不干,那样,程序工作者的生活会变的更好,不想现在这个样子,加班到猝死,妈的活该!自己不去争取权利,没有程序员工会,活该被欺负到死。

    我现在已经不想再做一个程序工作者了,我感觉没有前途,上班司马脸,下班没有末班车,天天对着电脑,脑力劳动累的要死。回家没有性趣交公粮,活该被绿。工资高是高,但是没有时间享受。24/7除了睡觉时间,什么都没有?你老婆有没有出轨,你都不知道?搞什么加班?离婚之后,好像没有公司给你在介绍老婆吧!我想:可能当你离婚之后,你的加班世界又多了,老板会很高兴的!

    所以,我不喜欢做一个程序工作者!

    我要考证书,进体系,就是这个样子!

    但是世界局势就是这个样子,你看日本这个国家,这个国家的的几乎所有的企业几乎是无法盈利的,只能靠国家补贴勉强度日,当然,垄断企业除外。如果有一个人的小公司,可以盈利,那这个公司肯定是没有把员工当人看,一定把它当机器了。所以我不喜欢去日本的企业!

    我现在特别讨厌国外的一些公司,他们在弘扬加班制度,在公司加班的时间越多,你的表现就越好,真实垃圾的一批。从个人理论而言,你把你所有的时间,都奉献给力公司,那么你的生存的价值在哪里?你和这家公司的垃圾桶有什么区别?垃圾桶管装垃圾,你管写代码,劳动不分高低贵贱!都一样!这家公司可能以后会很牛逼的,但是对你个人而言,就是你个人是失败的。

    但是还是真香定理,选择了学习软件测试,只不过想要学习一下测试,万一我以后没有什么糊口的本事,还得选择这个行业啊,至少不能饿死啊!

    3、这门课程你所期待的收获有哪些?

    我就希望我能暴富,但是希望估计不大,那就只能希望,对测试有一些了解吧,至少先会使用环境再说!

    4、你如何学习这门课程,有什么学习建议?

    我没有学习过这门课程,但是我知道如何学习开车,我真的知道!

    学开车的时候,我是在驾驶座上学习的,如何踩油门,放离合器,拉手刹,这一套下来,我就可以把车开的特别好!后来我就学会了开车,特别稳。

    我想,如果我当时没有坐在驾驶座上,而是坐在副驾驶上,我应该现在还不会开车吧!因为开车这个东西,就得你亲自来做,看别人如何开车,你是永远都不会开车的。我想学习也是这一个道理。

    我特别喜欢足球,我也看一些足球的视频,在我看来,梅西踢球的水平也就是那样吧!我只是比他差一点点,所以我经常在客厅里看电视,学梅西怎么踢球,争取做一次内蒙梅西,但是我就是踢不好,这大概和我没有去球场上练习吧!

    5、你对软件测试工程师的认识?

    测试的工资不如开发的高,
    但是简单啊,找找Bug,喝喝茶,经常换几家小公司,一般年轻人的Bug也就是那几种,治疗了解余个测试的基本套路,给你配几个年轻的经验不够的开发人员,那简直是一招鲜,吃遍天下。
    但是懂测试的开发也不错。
    然后就没有了!
    了解不多。没有太多的时间查看网上的资料,先就这样。

    展开全文
  • 上一篇里我们讨论了测试的必需性,如果大家目前还在公司里做着测试工作,那就说明还是落在必需的范围里面,或者至少一段时间是吧。那接下来我们看下既然需要做测试,需要做哪些事情。基于我自己的一...

    转自:https://blog.csdn.net/superqa/article/details/21485737

    上一篇里我们讨论了测试的必需性,如果大家目前还在公司里做着测试的工作,那就说明还是落在必需的范围里面,或者至少一段时间是吧。那接下来我们看下既然需要做测试,需要做哪些事情。
    基于我自己的一些理解和观察,我试图把测试工作的层次分成三个阶段,越到后面涵盖的范围越广。这里讨论的一些做法可能更偏向于互联网方面的测试,特别是第三个阶段。

    首先我想先从一个例子开始,一个现实生活中的例子。
    对于一个城市,假设我们的工作目标是提升环境的质量,减少垃圾。那么我们可以做什么?
    首先,我们可以请很多环卫工人,出去打扫各个街道,这个马上就有了效果,环境变得更干净了。但是还不够好的地方是明天还是有很多东西需要打扫,治标不治本,只要一停下来立马回到之前的状况。
    接下来,我们往前面想一想,为什么有那么多垃圾呢?其中一个方面是很多人乱扔垃圾。所以更进步一点的方案是,对于乱扔垃圾的人有些约束或者惩罚,比如抓到了曝光或者罚钱,这样扔垃圾的人会变少。
    再然后,我们发现即使做到了上面,还是有不少垃圾,而且上面强制的方案也带来不少的反感。我们需要更深层次的思考,为什么会有那么多垃圾?是因为垃圾桶太少?设计得不合理?如果是这样,就需要从其他公共设施方面做一些改进了。

    对于我们的测试工作,也是有类似的思路,只不过细节上要考虑更多。

    第一个阶段:发现和解决bug的阶段
    这个阶段的思路基本上尽可能发现更多的bug,见一个灭一个,来两个灭一双。
      发现bug,解决后验证bug,没有任何根源性的推动,或者推动的效果不好。

    这个阶段,测试工作主要集中在发现bug,要做好这个,需要多个方面的努力,比如下面这些:
    - 更高效的发现bug,考验测试设计的能力。
       这方面有非常多的方法和技巧,以及经验,这里不细说。
    - 发现bug之后如何清晰的描述,定级,以及跟进和验证。 
       这个看似简单,但是你会发现很多测试工作做了几年的人这样的基本功还是不够扎实。也可能没有受到过很好的训练或者一直没有人指导。
    - 对业务和架构的理解能力。 
       没有这方面的能力,很难发现一些深层次的bug。而这样的能力对于快速学习和一些技术基础也有不低的要求。
    - 发现bug之后如果举一反三的尽早发现更多类似的bug。

    大家看到的很多经典的测试书籍讲的基本都是这个阶段做的事情,比如Software Testing,How We Test Software at Microsoft,以及探索性测试相关的书籍,都是专注在如何更高效的发现缺陷。

    上面这些东西都是一个业务测试人员的基本功。看似简单,但是做好并不是一件容易的事情。也许这些事情一点都不cool,不sexy,甚至去做职级评审的时候不占优势,但是对于系统质量的提升,是切切实实带来很大帮助的,其工作的价值应该得到认可。但是如果一直停留在这个阶段,就陷入到上面例子中说的扫马路的阶段,因为如果没有其他方面的改变,每次都有那么多的bug。

    不过很多时候,我们的测试停留在这个阶段也是因为现状,考虑下这样的情况:
    - 开发基本不自测,甚至没有自测的环境,特别是涉及多个系统的对接。
    - 提测后很多基本的功能都不能正常使用
    - 项目管理比较混乱,但是最终的发布日期又被老大们定死,所以测试时间常常被压缩
    而且,而且没有对于开发人员的质量方面的考核,那么很长一段时间,我们的测试将处于这个初级阶段。

    我相信目前还有不少的团队是处于这样疲于应对的情况下,不只是小公司,可能一些大公司的部分项目也是如此。随着整个研发体系的发展和深入,我们应该有更高的追求。



    第二个阶段:质量的管理
    在第一个阶段中,可能有一些人会停下来想:我们一直这样下去也不是个办法?有没有更好的做法呢?

    最直接会想到的就是,怎么让别人少丢垃圾,让本身的bug就更少一些。如果我们做的工作只是发现bug解决bug,那么就是一个消耗战。不能形成一个良性的循环,就不能持续的优化,工作的长期累积价值就体现不出来。
    这个阶段核心的思路是对缺陷做分析和考核,并做研发流程中主要问题的梳理和改善。

    常常做的事情可以从下面几个方面来看:
    1. 做质量数据的统计和分析
        收集的数据很多,常见的有:
         - 外网的bug情况,包括事故,及影响的程度
         - 测试阶段的bug数量,分布(按系统,团队,开发个人),严重程度,bug的类别等维度
         - bug的横向跨团队和系统的对比,纵向的和历史情况对比
         - 版本发布的情况,代码变更行数的情况
       从这些数据的收集中就能发现很多问题,比如问题集中在哪里,哪些模块,哪些人,哪些类别等等,以及有没有改善。

    2. 问题的追溯和对于开发的考核
       这个方面也许有一些争议,但是我还是觉得这个是一个很重要的方法。光靠观念和自觉是不够的,必需要有一定的反馈机制,就好比交规一定是配合着扣分和罚款等手段,否则记录闯红灯有什么意义呢?而且现实的来说,这些方法起到约束的作用,也是一种心理暗示,要做自己做的东西负责,也便于养成好的习惯。
        通常的考核指标涉及这些方面:
        -  编译失败次数的考核
        - 外网事故和bug的数量
        - 测试阶段的bug,特别是基础功能bug和严重bug
      粗略的列了这么多,其实可以有很多,比如配置文件改错的情况,漏提测文件的次数等等。

    这里也许有很多的讨论,但是让我们看看一个实际的例子。下图是某个系统的编译失败的情况,在11月份的时候提出要统计并公开(并无惩罚条款)编译失败的情况,包含到开发的团队和个人等明显,12月份开始出现了明显的下降并稳定了。这个图隐藏了一些细节,如果剔除其他因素只看开发代码原因的编译失败则更明显,特别是后面有惩罚机制之后,进一步下降。
         

    编译失败大幅的下降一方面是节省了大家的时间,另一方面其实也是提高了版本质量,想想如果有很多的编译失败,而且是到提交测试的阶段,这样的代码质量能好吗?是可能做过自测吗? 有了这样的机制,至少会更仔细一些。

    对于bug方面其实也是一样,如果开发在乎(或者被迫在乎)外网bug或者被测试发现的bug数量,他写代码的时候一定会更仔细,也会做些简单的自测,让提测的质量更高,提高了整个研发系统的效率,同时也是提升了质量,因为quality must be built in。

    我个人的经验,作为测试人员几乎同时面对过两个开发团队,一个有上述的考核,一个没有。表现出来的版本质量和对质量的关注完全不一样,而且前者也并没有出现开发和测试的对立,以及测试不敢提bug等负面的情况。

    3. 对于测试的考核
    除了对于开发的考核,同样也有对于测试的考核,这样也更加的公平。
    测试的考核通常考虑下面的指标:
         - 漏测:绝对数量或者漏测率
         - 版本的工作量和测试效率
         - 发布延期的情况
    如果测试有这样的压力,也需要不断努力去发现更多的bug。

    说起考核,总有人觉得这不符合智力劳动的情况,或者互联网的作风,其实不太理解为什么会这么觉得,放眼望去,有什么工作不被考核呢,sales要背quota,为什么软件开发和测试不能对自己的工作的质量负责呢?当然,具体的指标如何去定才更合理那是另一个要去考虑的。
    换个角度来看,适当的压力(不应该导致焦虑和扭曲的做法),其实是让一个人表现最好的状态。

    4. 推动开发的自测
    这个问题一向是个老大难问题。愿意自测的开发团队你不用太多的推动,不愿意做的推动也很难,或者你无法判断他有没有做自测。而且这方面,通常取决于开发负责人的观念和态度。
    如果是介于之间的,我们可以做一些事情,比如:
        - 统计测试阶段的bug中,属于开发可自测发现的比例。通过这个可以看有多少bug是不应该到测试阶段的,以及横行纵向的对比。当然这个标准要自己拿捏。
        - 给出一个自测的checklist。开发在提交前要完成这个list并正式的给出报告。这个方式我们曾经在一个项目中用过,效果不错,基本功能都通过这个保证了,前提是开发负责人认可。
        - 有一套自动化验收的用例,可以挂接到自动部署之后或者daily build。前提是我们的自动化要足够的问题,效果才会好。

    这个阶段除了业务测试的努力,也体现出了QA的价值。这里的QA是指质量管理,有的地方叫SQA,专注在质量度量和研发流程的管理上。

    到这个阶段,发现事情顺了很多,质量也有更大程度的提升,并有改善额趋势。



    第三个阶段:推动全面的质量提升
    到上面第二个阶段,我们发现质量有了一定的提升,但是还是有不少的问题,而且有些问题需要我们把思路和眼界拓宽来看。这里讨论的一些东西可能更适合互联网的产品。
    这里列一些我们可以去做的事情,受限于个人的经验,可能还很片面。

    1. 研发流程的梳理
    其实在阶段2的时候也可能有些团队已经开始做这样的事情,因为在分析质量和效率问题的时候,我们发现很多问题不单纯是代码的问题,可能还涉及研发流程的很多方面,比如:
      - 需求不清楚
      - 跨团队的配合问题
      - 代码版本管理
      - 技术方面的评审和大家的理解
    所以整个研发流程的规范和梳理,以及配合对应的需求和版本管理的系统也是非常的必要,实际中发现效果也是比较的明显。而且还有一点体会,在接手一个很混乱的状况时,这样角度的数量和调整比技术方案的引入更重要和切中要点,能从40分到60分,技术是往80分走的过程效果更明显。


    2. 提交测试前后做的一些事情
      - 代码的静态扫描
         这个方法很多的团队都在做,但是实际的效果似乎差别很多,而且ROI也很难说,不过从方法本身来说还是值得去做的,对测试人员也提出来更高的要求。
      - code review
         这个开发应该要做,特别是开发间的交叉review,非常的有帮助。不过这个也和自测一样,取决于开发负责人的态度。另外,测试也应该去做,特别是对于diff 代码的review,我们检查做了大概两个月的时间,发现还是非常的有收获。发现了一些黑盒难以发现的问题,以及开发的代码夹带,并且对于这个版本影响范围的评估也更准确。但问题是短期会花费测试更多时间,以及需要测试人员有一定的技术能力。
       



    3. 测试能力的提升
        测试阶段有很多的事情可以去做,觉得最主要的还是两个方面
         - 自动化。 越来越觉得这个是绕不开的话题,要想尽办法去做,做得更高效更全面。前面有篇blog也提到了一些轻量级的做法,业务测试的团队可以参考 http://blog.csdn.net/superqa/article/details/20644285
         - 辅助手段,比如代码覆盖率,特别是差异的覆盖率。这个大家都比较容易理解就不展开了。
         - 拓展测试的类型
         这个方面说起来有些泛,需要结合团队和业务的情况,比如安全测试,性能测试,兼容性测试等,去发现一些对于产品来说很重要的风险。
         这方面有两个前提,一是我们的基本功能质量到了一个阶段,可以让大家腾出手去拓展测试的面,另一方面我们测试人员的能力要跟得上。

    4. 发布环节的质量把控
         这个方面和传统的测试不太一样,而且了解到不同的组织做法不同,执行发布的人员可能不同,有开发,运维,专职的版本管理或者测试来做。
         在我们的实践中,发布后来都逐步收到测试这边,回头来看觉得还是有不少有帮助的地方。当然也不绝对的必须测试来做。
          - DO分离,避免了随意的发布,特别是在开发手上的时候。所有的bugfix都经过测试发布,可以更准确的度量质量(除非这个问题可以不修复,否则肯定要过发布环节)
          - 知道最近发了什么,可能的影响是什么,需要线上关注什么。
          - 灰度。 互联网产品常用的一个控制风险和节奏的手段。
          - 扩容的快速自动化检查,这方面也依赖于自动化的建设。
          - 发布过程支持灰度的控制,备份和快速的回滚。对发布系统有一定的要求,而且有可追溯性。

        

       
         发布处在整个研发流程非常关键的节点,在这个点可以做很多的控制,也能发现很多的问题,对于测试团队来说,从这里可以发现很多的问题,做很多的提升,对自己和相关的合作团队。

    5. 外网的监控
        发现发布后的问题,持续运营过程中的问题,推动优化。
        通常监控可以分几个层面,粗浅的可以分成几类:
        - 运维层面的监控,比如机器,链路,资源使用,主要组件是否正常等。
        - 业务指标的监控,比如来自点击率,BI系统等。
        - 集成在产品里面的监控代码,我们称之为模块调用监控。这个是全量的,有次数,成功率,响应时间等角度。  
        - 测试层面的自动化监控,关于在接口和功能层面。这个是采样的,但是从用户的角度来监控。
          

      以上这些监控都有对应的告警机制,可以第一时间发现问题,避免造成更大的损失。为了实现上面的监控需要做大量的工作,但是这些对于整个外网运营的质量非常的重要。

    6. 外网事故和问题的收集,跟进和反向推动
         和前面的思路一样,如果只是发现问题解决问题还是稍显被动,那么对于外网事故和问题的分析,还是有很多推动性的帮助。

    7. 用户的问题反馈和满意度
         进一步的质量不只是系统本身的质量,而是从用户角度看到的质量,有时候这个可能稍微超出一些系统层面的问题,但是因为最终的质量还是用户说了算,所以我们应该扩展下思路。收集这样的问题的渠道有很多
         - 外网问题反馈,比如来自客服系统的,用户直接的反馈,现在很多app上都有反馈的功能。
         - 论坛信息的统计收集。我了解的另一个测试团队,他们还专门开发了一个自动收集外部反馈,以及过滤分析的系统来帮助他们及时的了解外包的问题反馈。
        

    8. 运营层面的质量
      更进一步,关注运营方面的质量,跳出传统意义的质量的范畴,关注我们的业务指标,不只是做一个高质量的产品,而是做一个业务上成功的产品。
       比如下面这样的例子:
         - 商品详情页的图片的质量
         - 活动页面和详情页面价格不一致的情况
         - 运营配置的错误导致的问题,哪些是可以监控发现,哪些是可以推动运营平台的规则检查?
        
          

    每次我们的思路跳出一些框框,都会有不同的领域。有点点哲学上的意味,很多领域做到后面,其实会超出那个领域本身的范畴。就好比高性能的汽车,到后面就不得不研究空气动力学这个原本是和航空有关的东西。但是,这是否超出了本意,如果去看待,又是另一个问题。


    其实这样的三个阶段也是一个粗略的划分,并不一定要逐步的来发展,其实都是一些具体的做法和实践。以我目前经历过的实践只想到这样的层次,应该还有更高级的阶段。
    我们越到后面我们发现进一步的努力带来的提升幅度其实不大。但是很多事情也是一样,从85分到90分付出的努力可能比50到80分的努力还要大。另一个更有趣的是汽车的极速和马力的关系,家用车100马力开到180km/h是能做到的,但是超过时速300,每提升一点需要增加的马力要大得多,到400以上,车时速每再增加一公里,功率需要提升八马力。这篇文章读起来非常有意思,http://blog.sina.com.cn/s/blog_4d0109a301000ajz.html



    写到这里,我们可以跳到整个公司或者业务的层面,来思考一些对于测试更深层次的问题:
    测试团队存在的价值和意义是什么?
    只有对业务有明确的价值,业务测试,或者说整个测试团队才有存在的意义。只要业务OK,砍掉测试团队也不是不可能。我们必须时不时的跳出我们自己的思维的圈子,站在整个事业部老大的角度来思考下测试的价值和意义。
    在下一篇关于测试组织方面我们可以再讨论下这方面的内容。
      
    还有一个体会:测试的水平反应整个研发体系的能力和水平。
    如果我们的测试还专注在第一阶段,那说明整个研发还比较初级,开发和测试都是温饱的阶段。当我们的测试人员不再趴在地上盯着最基本的功能质量的时候,才有可能抬起来看看更多有价值,有帮助和有长远意义的工作,慢慢形成一个良性的循环。


                </div>
    
    展开全文
  •  软件测试需熟悉软件开发流程,重点掌握软件测试本身部分过程以及测试与各个阶段的接口,有哪些文档需要编写,编写的内容是什么。其它方面不需要很多细节都了解,那是QA和EPG的事。  2、测试人员必顺熟悉产品所...
      1、测试人员必顺熟悉软件开发流程
    

      软件测试需熟悉软件开发流程,重点掌握软件测试本身部分过程以及测试与各个阶段的接口,有哪些文档需要编写,编写的内容是什么。其它方面不需要很多细节都了解,那是QA和EPG的事。

      2、测试人员必顺熟悉产品所涉及的业务

      测试人员主要的测试还是功能测试,那怎么做好功能测试,在仔细、耐心的基础上还需要精通产品的业务。实际是往往项目组中的培训往不够的,我个人的经验是如果有条件能够参加需求调研的话是最好的。如果是产品化的产品有机会的最好去工程实施的一两次。

      3、测试人员技术的要求

      测试技术的要求我就不多说了,大家关心的可能是开发工具,我个人认为测试人员必须精通一门比较大众化语言,如C、或JAVA,否则在测试驱动化测试时,就需要开发人员协助。以前我碰到这么一个需求“在个用户同时操作,一个用户插入十万条数据、一个用户UPDATE十万条数据,一个用户删除十万条数据”如果我们自己不能写点小程序,是很受制于人。还有必须对自己项目所使用的开发工具有所了解,要做到能安装、搭建、编译、调试问题(能找到错误点)。

      4、测试人员对于工具

      现在网上测试工具很多,我看了很多人天天在说,学哪种好。我是根据测试不同需求去选一种比较大众化,适何目前情况的工具,比如果我就划分三种:测试管理、功能测试、性能测试。根据这三种去找适何的工具,学习并应用到项目里。

      5、测试人员基本素质

      这点很重要,如果一个测试人员水平很高,但是他就是不做事,那有什么用。测试人员必须具备踏实、主动、仔细、钻研的素质。

      踏实:追求好的待遇是每个人目标,但是必须对自己目前这个岗位的工作需做好,要想工作时间想个几个分钟,晚上回去想个够/

      主动:寻找BUG要拿出追女(男)友的气势出来。

    展开全文
  •  入行第5年了,最近发现自己心态上起了一些微妙的变化,如果在头三年,别人问我,软件测试到底是干啥的,我肯定会回答,就是测软件上bug的,当然,你的bug测得越多越好,甚至,你在测试时候如果没有发现Bug,你会...

    写在前沿

             入行第5年了,最近发现自己心态上起了一些微妙的变化,如果在头三年,别人问我,软件测试到底是干啥的,我肯定会回答,就是测软件上bug的,当然,你的bug测得越多越好,甚至,你在测试时候如果没有发现Bug,你会莫名的感觉焦灼甚至有点心慌,妈呀,我是不是漏测了?那时候以为,发现bug的数量和质量或许体现了测试工程师存在于这个行业的最大价值和意义。

           直到,我经历过一个项目,心路慢慢的有了些转变,因为项目上线质量和快速迭代的压力,我发现从刚开始尽管一遍又一遍的测出了很多的bug,但是项目质量仍然堪忧,项目上线仍然没有安全感,特别是上线以后,开发一句:这个怎么没测出来让我有点风中凌乱(宝宝心里苦,宝宝不说),按照我以前的理解,我自认为已经是一个合格的测试了,但是我所面临的让我思考,我是不是该从项目下游的环节往上捋捋是不是团队出了什么问题?

     

    回归项目

    首先说下项目特点,该项目迭代速度很快,平均一个月发布三次,后端相对于比较稳定,前端代码Bug率较大,其中我所碰到过以下主要几个问题:

    回归范围的不确定性

    经常出现的问题可能就是,当前端修改过一个问题后,可能会产生其他的前端问题。

    另外一个问题可能是刚开始项目交接的时候,本身该项目没有需求文档,以及产品经理,测试需求点的介入需要强依赖开发的口头沟通;

    案例:有一次,前端修改一个ini接口,开发评估自测,但是线上出现某个活动页面登录不上。

    思考:如何从测试的角度去预知前端代码的变更所造成的影响范围,从而评估出测试范围?

    目前的解决方案:

    a. 在测试阶段,让前端开发去评估的测试范围,针对项目需求在建立jira任务的时候去尽可能的给出测试版本,测试内容以及相对应的交互稿。

                    

                        图1.  完善需求

     

    b. 加强开发代码CodeReview流程,多个前端交互评审,给出评审报告;

    当然,最好的解决方案是测试人员学会前端代码,参与代码评审,从上游和开发一起做一个代码质量保证。

     

    无法把控的项目节奏

    案例:在迭代过程中,经常会面临测试节奏被打乱的情况;可能有以下几种原因:

    1.  线上Hotfix紧急上线;

    2.   在已经确定好开发计划后又新增需求;

    以上几点原因直接导致我们在项目进度上被某些突发事件打乱,无法按照预定的项目节奏走。

     

     

                           图2.某个项目迭代过程

    解决方案:

    针对Hotfix,可能确实已经相对比较紧急了;在开发给出测试范围以后,测试根据自己的经验做一些相应的回归;

    针对新增需求,各个团队人员进行相应的评估,由新增需求的人提出一个需求变更表;需要团队队员确认;

     

                             图3.需求变更风险评估表

    剑拔弩张的沟通

           开发与测试的矛盾点很大部分集中在,开发在产品质量意识上,对产品质量和测试人员有些误解,他们会认为线上如果有Bug那是因为测试人员的问题,他们没有给产品把好关,导致Bug流到了线上,然后巴拉巴拉的吐槽测试,在整个团队里面,我觉得集中突出了以下2个问题:

         1.“这个怎么没测出来?”:

        曾经经历过一次线上Bug,在和一个开发聊天的过程中,在交谈过程中他跟我抱怨“你怎么连这个都没测出来呢?我们怎么信任你的测试质量?”。说实话那句话让我心里很不爽,因为在他的意识里面把那次线上Bug的责任全部归咎到了我没有测试到位。当时直接争执了起来,“你说我测试差,我还没说你开发能力差呢?”

        尽管,我们所了解的测试其实是一个服务型的行业,有时候会是一个“背锅侠”,但是真的像开发所说的那样,线上Bug只是我们测试不到位的原因嘛?如果我们细细挖掘整个产品生产过程,事实是,“测试”这个环节是所有产品生产里面最不会产生”Bug”的环节。

           

          2.如何去看待线上问题?:

       团队面临的另外一个问题,就是对线上Bug的零容忍,这样会导致一个很直接的结果,就是一旦出现线上Bug,团队氛围会因为线上压力而变得很紧张;其次,刚开始的时候,一旦出现问题大家都会把矛头直接对准测试,并且会把目光聚焦到产品生产下游—从测试的底端去想如何去避免该类问题;

    解决方案:

    1. 如何让开发有质量保障的参与感---增加开发用例设计的参与感。

            除了一般的用例评审环节,还会增加一个用例站会评审环境,测试需要把所有的测试思路以及测试重点再进行一轮展示,全体参与查漏补缺(可能一部分原因是想说,让开发去体会测试所处的位置和难处)。

     

                           图4.  用例评审模式

     

    2.尽可能的引导团队在出现线上问题的时候从产品生产上游去解决问题。因为增加自动化回归范围这些手段来说,可能会避免这个问题,但还是无法去解决真正发生这些问题的原因,尽管这个过程中在推广这些理念的时候会和开发产生一些冲突和争执,过程比较艰辛,是一个任重而道远的过程。

     

                            图5.线上问题解决方案

     

    产品质量的困惑

            每次迭代上线,我们都会写一个测试报告,在每次报告总结里面,我们都会填写一个总结,产品质量怎么样,能不能上线等等?这些很多都是凭借我们自己的经验去判断,当有人真正问你的时候,你还真的无法说出一个一二,什么叫好,什么叫不好?

    这个项目可能会给我增加一些判定的维度方面的经验:

    •  产品质量:

           包含了我们最终在交付产品的时候,对Bug(数量+严重度+概概述),功能点(包含了功能,性能,异常是否全部覆盖),用例(是否包含了全部功能点以及执行情况,测试过程的代码覆盖率等)的一个整体产品评估。

    •  产品过程质量:

            引入这个概念,是因为一些测试经验;比如,我们在做功能测试的时候,一般我们会进行相对较全的功能回归,在第一轮回归以后,可能会出现一些问题,然后修复好以后又进行相应的冒烟,此时在回归次数增加的同时,可能也会存在一些未知的风险,比如第一轮回归完成后,第二轮修的Bug可能会影响到前面的测试功能,所以存在说回归次数和产品质量的一个风险关系;

    其次,比如我们在迭代过程中的需求挖掘,如果在刚开始需求挖掘的时候,没有挖掘出一些潜在的需求Bug,那可能后续会增加一些回归的风险,再比如开发的冒烟的通过率等等还有很多,也可以根据自己的项目经验去增加。

     

                       图6.日常迭代过程记录

    • 上线过程质量:

       主要考虑2个方面:

    • 上线过程中前后端是否相互完全隔离;
    • 上线是否采用静默升级,升级后会不会影响线上现有的功能点。

    如何提项目质量风险?

            整个测试过程中,质量保障的最后一步,我认为也是最难的一步,就是如何去预估产品所在的风险点,我曾经和开发有过一些争执的矛盾点是在于立场的不一致会对风险点的看法理解不一样,所以在写风险点的时候尽可能和开发在意见上达成一致。

    其次,除了遗漏Bug等一些质量风险,项目风险的话尽可能由“大”到“小”的去思考,“大”是指方向性,比如兼容性,安全,性能,异常等等的角度入手,“小”是结合产品所在的一些细节。

    比如,一个移动端的产品要上线,可能因为我的测试时间有限我兼容性只测了一部分,兼容性问题可能是我的一个风险点;

    再比如,后端新增一个接口或者新增一个服务 ,性能和异常这块可能要考虑是不是一个风险点。

    这些都是需要去考虑和项目经验积累的。

    写在最后:

           如果现在,项目要上线了我还没有发现bug,那种焦灼感反而由一些欣慰替代,我发现我心态的转变可能是源于我意识的转变,当别人问我,测试是干嘛的时候,我可能更偏重于,测试是一个把质量意识输出到整个团队的人,是一个流程推动者,是一个需求挖掘者,是一个质量把关者,一方面我们确实通过自己的经验和技术手段去挖掘更多的Bug,另外最重要的一方面,通过一些测试需求的挖掘,流程把控,质量意识以及测试方法的传播尽可能的去从产品生产上游去避免Bug。希望有一天,在我们的推动下,行业没有了测试人员,因为项目里人人都是测试专家。

    共勉!

     

    展开全文
  • 对于软件测试理解

    2017-06-27 09:05:08
    测试的目的:测试主要是要保证代码质量,保证发布的代码高质量的发布给客户。...常用的软件测试内容及方法: 不论是对于软件的模块还是系统而言,总有共同的内容需要测试。 1.正确性测试:正确性测试也称

    测试的目的:测试主要是要保证代码质量,保证发布的代码高质量的发布给客户。

    所以测试人员工作的目的是发现尽可能多的系统缺陷,可以叫bug或者是defect。测试不仅仅是需要测试技术,更需要职业道德

    测试的真理是,通过了测试,不代表代码就没有缺陷,通不过测试,缺陷肯定存在。

    常用的软件测试内容及方法:

    不论是对于软件的模块还是系统而言,总有共同的内容需要测试。

    1.正确性测试:正确性测试也称功能性测试,功能测试属于黑盒测试,在测试方法中相对简单,以完成代码最基本的功能为主,所以也最重要。

    基本的方法是构造一些合理的输入输出,检查是否得到输入输出。核心思想是寻找等价区间。

    还有一个方法是边界值测试

    2.容错性测试:检查程序在异常情况下的执行情况,来保证程序能够在不满足运行条件的情况下,正常结束。

     比如通过不合理的输入来引诱软件出错


    3.性能与效率测试:主要是验证软件的运行速度和对资源的利用率。

    4.*文档测试(看文档描述的功能是否都能实现)

    5.改错,测试发现出来的错误,需要让程序员去改错,否则测试工作没有意义


    如何做好测试,

    规范测试流程,提高测试用例质量,提供测试工具效率,提高测试人员对与测试重要性的认知及技能的提高

    展开全文
  • 要做好职业规划首先要想好我正在进行的培训的事情,软件测试,我也算是接触了一个月的时间,期间学写了linux系统,学习了oracle,学习了c语言,这说明软件测试不仅仅是理论的,也是需要了解it基础知识的,也就是说...
  • 软件测试岗位职责

    2019-07-22 17:15:46
    软件测试岗位职责,明确着这个岗位的技术劳工,应该做什么,你在各种招聘明细中,可以查阅到这方面的信息。简单来讲,从劳工责任的角度,工作内容实际上就是不断的找到软件中的bug,并监督开发人员修复它们。造成...
  • 工作有一段时间了,再谈谈对测试职业的看法写的不对,你也看看,别影响食欲就行;你要是觉得还过得去,就顶顶哈先说迷茫:这就是一个词,描述了现在很多做测试的人的心态,关于这个不想多说,和人的思想有关,我有个...
  • 对软件测试理解

    2017-03-08 17:21:33
    测试的目的:尽可能多的发现缺陷,比如功能...白盒测试必须由开发人员独立执行,因为测试人员无法理解代码内部逻辑。 黑盒测试:看不见的程序内部结构,按照规格来测试程序是否符合要求。黑盒测试必须由独立测试小组执
  • [原创]我对软件测试这份工作理解  初入职场也有几年,到2008年在新公司升职为测试经理,管理10几个人的小测试团队,虽然前几年工作主要是做为测试工程师,做具体的事;但是后来随着自己角色转变,需要带测试团队...
  • 对软件测试的认识

    2017-04-18 10:41:25
    但是,由于目前软件测试体系还不是很完善,测试的地位还远没有提升到一个很重要的地位,所以大多数人对软件测试的认识仍然存在着很多的误解。   1. 什么是软件测试  软件测试就是利用测试工具按照测试方案和...
  • 软件测试的一些理解

    2016-07-18 14:28:49
    现在大部分软件企业的生态链都是,软件测试属于最下游。这也决定了很多情况都必须被动接受。即使某个测试工程师理论知识丰富,辨识风险能力强,但是一个产品需求的变更就可以让他傻眼,接着很努力去适应这种节奏。...
  • 在市场需求的影响下,软件测试从业人员越来越多,但依旧有很多人对软件测试岗位并不了解。在很多人的意识里,软件测试是一个非常高深的岗位,软件测试工程师离我们非常遥远,这其实都是因为我们这个岗位不了解。 ...
  • 最近在为面试新工作做准备,所以想想整理一下软件测试的基本工作流程,大致梳理一遍,这样也便于自己在面试过程中可以沉着的面对面试管的测试工作如何进行的问题。 首先,作为测试人员需要学习并了解业务,分析需求...
  • Q:软件测试工作过程有哪几步?答:需求、计划、方案、用例、执行、总结。1、测试需求测试需求分析:分析识别测试范围,解决测什么的问题,方便测试的跟踪和管理。测试需求分析的流程:需求采集—&gt;需求分析...
  • 软件测试:在规定条件下程序进行操作,以发现错误,软件质量进行评估,包括软件形成过程的文档、数据以及程序进行测试 软件质量:软件特性的总和,软件满足规定或潜在用户需求的能力 2. 软件测试与质量...
  • 混迹于测试行业这么长时间了,一直想写一篇关于软件测试的经验分享的文章,但苦于工作原因迟迟未下笔。最近终于有了些闲余时间,遂决定把自己的心路历程及所感所想记录下来,与各位同行共勉。 软件测试究竟是做什么...
  • 1、为什么要在一个团队中开展软件测试工作?  因为没有经过测试的软件很难在发布之前知道该软件的质量,就好比ISO质量认证一样,测试同样也需要质量的保证,这个时候就需要在团队中开展软件测试工作。在测试的...
  • 软件测试工程师的人大多数都不是很清楚软件测试工程师这个岗位到底是做什么的?其实我的想法是执行用例,找缺陷,仅此而已,简单粗暴。后来,看了《Google的软件测试之道》这本书,稍微有点更改,变成了积极主动地...
  • 1、为什么要在一个团队中开展软件测试工作? 因为没有经过测试的软件很难在发布之前知道该软件的质量,就好比ISO质量认证一样,测试同样也需要质量的保证,这个时候就需要在团队中开展软件测试工作。在测试的过程...
1 2 3 4 5 ... 20
收藏数 277,208
精华内容 110,883
关键字:

对软件测试岗位的理解