或许这篇东西应该项目结束的时候出现的，一直在忙，现在有空就来写了。

    之前五月的状态，一直在推着后端程序猿和前端程序猿赶着debug和甲方在确定摇摆不定的需求，或者说推动他们自己去确定那些需求，免得又临时才发现问题，又提交回来再改设计稿和代码。

     然而这个五月带着一种焦虑感，就是那种你知道现在剩下是测试、debug和验收了，但你不知道怎么执行呀!而且我们程序猿就那么几个，进度又加快不了，加班的话，怨气会加重，不加班的话，项目就这样缓慢的，而且甲方那边，又不上心地去测试！测试了然后又乱提需求，而一些需求又是没有在整体架构的考虑上，最后只得去磨嘴皮了。所以说PM都有焦虑吧→_→。

     第一次做测试部分，每次做新的东西，难免有拖延症╮(╯▽╰)╭。好吧，放松下，毕竟整个app的功能改动我都参与其中了。首先拿出之前整理关于功能架构的思维导图和excel文档，尝试根据功能框架用excel写了200多个测试用例，包括后台和APP与PAD三端联调，一级功能，二级功能，测试数值，测试步骤和犯错用例，这个时候需要沉下心来慢慢写，大概用了几个晚上的吧，反正我记得最后完成，我是广州回来长沙的高铁上完成的。接着晚上拿着I6和5s工程机测试，白天就交给前端和后端，他们看不懂的话，再一起沟通，但很多时候，我都是陪在他们身边，了解这个bug怎么来，这个bug具体应该怎么解决。晚上撸用例，白天再反馈，晚上再撸回验收，如此迭代。

     有测试文档的好处是，内测的安卓版本就省事很多了，可以转交给别人去测试了。不过后来发现我想的简单了，由于涉及后台设置，所以测试文档还是去加一些具体的测试用例。╮(╯▽╰)╭

     这过程遇到几个问题：

      一、我这边的测试用例只是根据功能流程的，若涉及交互测试的时候，我只能按照我记忆的交互形式去写了。这个本来是交互设计师来写的，但只能由我来写了。不过还好，交互大多没有问题。

      二、关于测试反馈，每个测试不是只发布过去就行了，还需要解决反馈。程序猿解决了并非真的解决了，只是他们认为解决了，还是需要你来根据场景去测试，根据经验，一定再去测试！！不过这里面涉及程序猿对于产品功能的自我测试，他们写完代码懒得去测试了。 说回我遇到的问题，程序猿在我给的文档里面的反馈形式不一致，导致我这边又需要再统一整理，再去测试功能，所以我觉得理想的测试反馈是可以像纯银（蝉游记的leader）那样可以在tower（一些团队内部的沟通协作工具）上面操作，晚上根据功能模块布置好测试bug，@不同的人，他们完成了就打钩给我吧。然而他们并不习惯去登陆一个网站去操作，因为他们解决看得不直观，操作又麻烦。的确tower上面的功能还可以更完善些，让他们一打开就直观地看到测试步骤和测试效果。还有他们觉得，那些协作工具不靠谱，执行不下去。╮(╯▽╰)╭那目前还是按照现有的方式去执行吧，做好反馈给我。

      三、测试文档的变更，有时测试时不只是修改，有些是功能缺漏，有些是需求变更参杂其中。目前我是这样分的，大类按照测试文档、需求更改文档（只包含大功能和小功能+改动点），每个文档里面包含前端和后台两大块的改动，每个文档按照日期以示不同版本；而之前我是记录在evernote里面，然后分享给他们，然后我这边的反馈，就在evernote划掉，只不过后来每天都有，发现挺零散的，就整理成文档，现在养成在客户那听到的需求用锤子便签记录，放到evernote上，然后整理成word和excel保存。

        四、过程中的一些bug反复出现，也是极为蛋疼的，毕竟拿去给甲方做测试的时候，都不想出现一些简单bug吧。这个只能期待程序猿的代码排查能力提高了。╮(╯▽╰)╭

对了，还有五月份整理了几份功能说明文档，对于我这个理科狗来说，一开始我是拒绝的，后来想想，好吧，是锻炼！就写上了！在这个过程中，从产品使用者的角度去写这份文档，梳理架构和功能点，不错不错~

中间想过办法去提高效率，人力资源在固定的情况下，沟通是主要的成本，也就是信息的传递，也就是要提高效率的话，信息的精确性越高，越减少后续的沟通成本。对此我将测试用例步骤具体化，bug出现的场景具象和条件化，并制作成excel清单，信息的锤炼其实也是PM的基础技能之一。对于甲方也是如此，也是借用文档这个媒介，但还得帮甲方想多一步，设计好具体的用例数值，让他们更容易上手熟悉。但这个过程中，文字还是不足以让他们熟悉的，还得加上现场培训操作。毕竟他们总会蹦出一些你不知道的提问，可以帮你完善考虑漏洞。

当然，整个信息传递也可以像大多数的线上教育产品一样，也可以像一个讲师边录制操作视频边讲解，当然结合ppt，也可以制作一个有爱的场景操作动画。

但这方式可能更加适合接下来的餐饮项目，给那些学历不高的员工去看，现在这个项目的操作者，有着他们的经验和学历，而且使用频次不多，所以综合考虑下，还是文档+现场讲解吧。

期间想过这其中的工作职责应该谁来写，从产品的最初状态到现在这个形态，融合了产品经理、甲方、程序猿和设计师的意志，原型图肯定是对不上了，而现在这个阶段，只能由我来上了！

所以总的看来，要作为一个推动者的角色，去PUSH其他人去按照流程去做好自己部分的工作。

从工作技能点来看的话，增长点有三：1、产品测试能力和流程规范；2、文档撰写能力；3、产品讲解能力；

前天第一次提交APP，然后也是各种摸索，所以啊，有些事情尽早做的话，起码还有预调的时间。还是上柱香保佑下能审核通过吧。。。。