• Tuna项目总结


        从8.19—9.13日一共四周的时间,我在Tuna项目组进行的我的第一次正式工作,以及学习。在此,我对这个阶段的工作及学习进行一个总结,主要分为对流程的理解和对自动化测试的应用两个方面。

        在总结着两点之前,说明一下我的工作部分,这个项目中,我主要负责Employee Management和All Resumes的查询,以及员工信息预览页面、简历预览页面这四个模块的用例的设计、执行和缺陷的报告及跟踪。在这个项目当中,自己收获了不少。

    一、流程

    8月19日开S1、S2 meeting,因为是接的继续完成就项目,所以S1、S2meeting一起开了。主要内容是PM依据PES为大家讲解项目的需求。

    当天会后分到了每个人的测试任务,下午开始看PES,根据PES来设计场景,之后两天都是写着四个功能的自动化测试case,约花了4个小时写case,10个小时调试case。

    21日四点开了S3 meeting,主要是对STD、测试用例、PES进行评审,提出改进意见以及评判是否通过,确认了进入S4阶段。

    22日发布第一版,之后五天的时间对其进行的测试,除了测试我所属的部分,其他功能部分也和大家进行了交换测试。这期间主要还是进行的手工测试,另26号的时候PES有变动,所以对自动化的case也进行了修改和调试。

    29日发布第二版,王丹负责冒烟测试,通过后我开始进行回归测试,对原bug进行关闭和打回,之后两天首先对我负责的部分进行测试,测试完成后开始跑主流程。

    9月2日发布第三版,蔚娟负责冒烟测试,通过后我开始进行回归测试,对原bug进行关闭和打回,然后开始跑主流程,对主流程整体进行手工测试。

    3日下午,王四虎review Tuna的专案,未通过。3日下午发布第四版,之后一天的时间进行测试,未找到bug。

    4日开了S4 meeting,未参加,阅读会议记录后了解,主要内容是在原有的基础上做了些细节上的变更,另外增加了报表的新需求。于是S4 meeting未通过,项目继续。

    5日下午收到新增的需求,我被分派到HR List的报表测试。此后两天先是与PM进行需求的沟通,然后书写手工测试用例。

    10日发布第五版,新增了报表部分,对该版本主要针对报表部分进行了测试。

    11日发布了第六版。对第五版进行测试的时候发现自己在对报表测试的设计方面有不足,只考虑到了数据的正确性,没有考虑到变更数据后数据的正确性。11日首先修改了case,新增了进行on board、edit、transfer、quit操作后对数据的检查,也就是新增了场景。Case修改完后就在新版本上进行测试。

    13日开始发现功能错误已不多,而主要问题是基础数据有很多错误,所以不再发布新版本,而是在RD的服务器上直接进行测试,并主要是检查基础数据。

    这四周里,S3阶段耗时2天,S4阶段耗时17天。

    二、自动化测试

    首先,反省一下我写自动化case时的方法。我最初写case的时候对于用例格式的认知有错误,是先写大场景,然后写出页面上所需检查内容的obj,obj写好后再去写checkpoint,因为我们所拿到的范本是用function表的checkpoint来引用obj表单的名称,所以我认为这样会减少一些工作量,更方便一些。

    但事实上是,页面上每个元素都是定义了多种不同属性的,而我们需根据checkpoint的需要去调试obj究竟选用哪个属性,以使测试更流畅的进行。因而开始的时候我的测试用例写完了,但往往跑不通的地方很多,最后又需要花费大量的时间去调试case。后来在王丹的指导下改正了写法,由“场景—checkpoint—obj”来设计书写,根据前面使用的obj属性来思考后面的使用方法来避免错误,才使后来的书写省去了很多时间。

    然后,对于这个项目,因为涉及到的数据变动很多,也有很多地方如进行search后只能检显示出的结果值是否正确,而不能检查是否有正确值没有显示出来,也比如导出的报表的检查在目前是无法用自动化来进行测试的。所以自动化测试主要是作为辅助手段来进行的测试,主要测试还是靠的手工操作。

    ---------------------------------------------------------分界线------------------------------------------------------------

    2013.10.8

        之前因为思考不够,项目也没有完结,所以对于自动化测试部分没有写太多。现在补充一点吧。

        我认为目前公司使用的自动化测试方法更适用于回归测试部分,因为目前公司的流程感觉并不完善,可能因为是内部项目,所以需求是一直在改,到了S4阶段后还改了好几次,不仅是新增需求,也对原本的需求进行了更改,甚至是初期的Q&A没有做好,所以测试的时候QT和RD的想法根本不一致。

        好像说的不清楚,这么说吧,目前写case的方法是先把步骤和expected result写出来,然后等系统做出来后,再根据页面的属性去填写的obj。目前的问题是:

        1、PES和流程图给得比较晚,Q&A也不明确,写case的时候其实expected result不清晰,只能等程序做出来了之后再填写上去。那么,也就是在自动化测试时其实我们已经手工测试检查了一遍了。

        2、需求的变更有时候也包括页面结构的变更,所以每测一次的时候又得重新修改case。而因为修改后的case无法在先前的版本上调试,只能等新版本出来后再调试,所以在调试case的时候其实就已经跑了一遍了,而人工检查case的正确性的时候其实也就检查了一遍系统了。

     (嘛,就酱紫。所谓敏捷,其实公司到底做到了多少呢? 哔——————

  • 相关阅读:
    集合框架学习笔记<二>
    Notepad++ Emmet安装方法教程
    vi 常用命令行
    iOS应用架构谈 view层的组织和调用方案
    搭建ssh框架项目(二)
    eclipse安装主题插件(Color Theme)
    eclipse安装properties插件
    Eclipse安装SVN插件
    搭建ssh框架项目(一)
    J2SE基础小结
  • 原文地址:https://www.cnblogs.com/poppyp/p/3357045.html
Copyright © 2020-2023  润新知