入职以来一直用的测试管理管理平台是由前平台组经理禅道系统，一直延用至今。
刚数了下纪录在禅道系统由我创建的测试用例有266条，也许这对一个有三年半测试经验的测试工作者来说不算多，可真正的原因是当你的工作范围就在这熟知的区域内，有时候书写测试用例对你来说，可能就是一种浪费时间，尤其遇到那种着急上线的活动或者项目。但是，最开始书写测试用例对以后的测试工作有着至关重要的作用，它能帮助你树立起一个对产品从书面到立体的了解，从表面到细节的熟知，真正测试起来，你就会知道哪里需要注意什么，哪里需要多一做一份限制测试。
我书写的测试用例涵盖项目、活动以及平稳的维护后台。测试用例怎么写我就不多说了，一搜一大把，比我说的都要专业。我只说我在写测试用例过程中的一些做法和想法。
关于新项目，我每次要做的就是和产品沟通，单独找一间屋子，我不会打断她（他），听他关于项目的设计理念以及思路，从产品模型去了解产品的功能，这个时候，我只会问产品人员关于他说或者描述的一些我没有在脑海里建立模型的地方，会议结束我会立即阅读需求文档，有时候一百多页的需求文档可能会花上我整整一天的时间去阅读，可是这些时间的花费是值得的，因为你只有去阅读需求文档了，才会去了解产品细节，把脑海当中刚刚和产品沟通时建立的那些模型一点点丰满起来。然后就是划分功能区域了，根据不同的功能实现，将产品划分成一个个小的模块，再分模块去根据子功能去写用例。
关于活动，由于是游戏网站，一般活动被我划分为投票类、发号类、抽奖类、选秀类、调查类、微博类、基于这些基本种类，没一个种类写一些公共的测试用例，没接到一个需求，会按照类别去对号入座，当然，主要是大环境下，这些开发人员接到的都是一些这样的需求，我有时候在想，这是一种懒办法，可是到底是我们懒，还是开发懒，抑或是那些提需求的市场天天抄写个相似的需求就扔过来开发、测试。当然，有时候不能对号入座的，会根据活动的特殊性另行划分测试用例类别，继续别写测试用例。
关于维护的一些平台，每个开发手里都有要去维护别人开发的东西，那这个时候就需要测试去跟进这些维护，每维护一次，测试一次，当然，这些维护的地方会事先根据维护要求写入测试用例，这样测试的时候就能做到心中有数，而不是因为维护一点就要去测试整个系统，会根据维护的情况测试维护点影响到的点和面。
版权声明：本文出自 victoria0428 的51Testing软件测试博客：http://www.51testing.com/?15019255
原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。
