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的正确性的时候其实也就检查了一遍系统了。

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

原文地址:https://www.cnblogs.com/poppyp/p/3357045.html