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

（嘛，就酱紫。所谓敏捷，其实公司到底做到了多少呢？ 哔——————