营销二期项目的一些感想

近期完成了对店铺营销二期的搭配套餐部分的测试工作，由于是本人第一次参与一个项目的完整测试工作，因此不管是从项目流程还是测试工作在项目中所起的作用方面，都有了新的认识。

搭配套餐是店铺营销二期中的一个卖家用于商品营销的手段，由于一期已完成了搭配套餐的主要功能，这期所做的是对之前搭配套餐功能的优化工作。

首先当然就是熟悉UC，根据UC中的描述，结合流程图来了解搭配套餐的基本功能和主流程操作。搭配套餐主要分为卖家搭配套餐设置和买家浏览搭配套餐。在熟悉UC的过程中，对几个主要的界面以及相关的业务规则有了比较全面的认识。在这个过程中，我了解到对UC的熟悉就是把开发对项目的理解转化为测试人员对这个项目的理解，关注每一个动作所产生的后果，抽象出需要注意的功能点，来为后面的测试工作做好准备。这个过程中的UC评审是十分关键的，通过评审，让测试人员充分了解开发人员所写的UC的各个地方的用意，避免因为误解而引起的后续对测试工作所造成的延误，同时也是对开发对PRD理解是否正确的一次讨论过程。所以在UC评审时要及时对理解比较模糊的部分提出疑问，在起点阶段确保工作正确的进行。

对UC有了一定的熟悉之后，就开始了测试需求设计。包括系统UC用例图，测试需求框架图，项目交互图，角色交互图以及流程图。这些需求设计阶段产出的文档，简单的说就是测试对需求理解的书面形式，为后面的测试用例编写提供便利。接下来就是以需求设计为指导，编写项目测试TC，根据每个功能点，尽量考虑每一种情况，增加TC的覆盖率。由于有了前面的需求设计，因此可以将功能点进行分类划分，因此清晰了编写TC所对应的功能点。完成TC编写后就是进行TC评审，目的就是将测试人员对项目的理解以书面形式来让开发确认，并对所编写的TC是否达到了对功能点的覆盖进行讨论，通过UC评审和TC评审，达到了开发和测试之间的双向确认，为项目能正确进行提供了保障。

在这些准备工作完成后，待开发提交代码，就开始了项目的测试工作，包括冒烟，三轮测试，预发布测试以及发布后测试。在测试工作中要及时向开发反应所发现的问题，根据测试用例来执行测试，提高项目各方之间的合作，以期能更有效的完成测试工作。

在整个项目测试过程中，目前的流程有以下几个优点：

1、在项目的前期准备阶段比较充分，需求认识的每个阶段都会进行一次评审，开发和测试之间在开始阶段的交流比较充分，通过互相确认来达到认识上的正确性。

2、每个阶段都有书面形式的产出，确保了各个阶段的成果都有比较明确的表达形式，且为以后的工作提供了查询的依据。

3、各个角色分工明确，资源安排合理，各个角色进入项目的时间恰到好处。比如我和碧钗分别进行满就送和搭配套餐的测试，在这个过程中并没有因为功能有部分交叉而造成分工的不明确。

4、每一轮都以上一轮的工作为前提，实现了很好的衔接，不会造成流程上的混乱。并可以根据实际情况调整流程的安排，又具有很好的灵活性。

 

而在测试过程中，个人觉得也有以下不便的地方：

1、在需求阶段太过于依赖UC的描述，其它参考的资料并不多，无法对项目由一个较全面的认识，因此一些本可以避免的理解上偏差会较多的出现在UC评审上，UC评审的效率还能在这点上进一步提高。

2、前期的准备阶段和后期的测试阶段时间比例有些问题，由于测试并非是单独的工作，需要开发修改完问题再进行测试，因此时间上应充分考虑开发修改和测试验证的总时间。这次本需3轮的测试调整到只进行了2轮，跟没有规划好测试时间也有很大的关系。

3、由于测试发现问题需要开发进行修改才能验证，因此在开发修改的这段时间除了测试其它功能点外，可以考虑再增加一点其它的内容。特别是在测试的后期，功能点已基本测试完成的情况下，这段时间没有很好的利用，以及开发提交代码前的这段时间也可以更好的利用，来更好地提升项目的进度。

4、由于项目环境或者其它功能的变动，造成已经测试的功能点需要反复验证，并且很多时候是无法明确的判断哪些功能点会因为这次的变动而受影响，在增加工作量的同时也拖缓了项目的进度。因此需要项目组各成员间有一个明确的规范，达成更佳的共识。比如印象最深的是一次发现了一个会随机出现的bug，由于重现的概率不定，因此给排查造成了很大的麻烦。最后才发现是由于测试环境中的IC接口因为容灾的考虑，有两套相似的系统，而由于代码没有都发到两套系统上，在程序随机调用了两个IC接口的情况下，造成程序随机的出现bug。

5、相互交换测试未做充分。