时间飞逝，岁月如梭，2015/11/25号寄以厚望的用户版1.4.3和专家版1.0终于准备上线了。每次发布版本的前两天都是非常紧张的节奏，大家也是拿出了十二分的劲头在拼，上线结果也尽在掌控中。
现在将用户版1.4.3和专家版1.0的测试结果汇报如下：本次测试组总共收到27个测试包，当前禅道上仍处于未解决一级bug还有2条：
1. 手机内存不足时，打开安卓用户版APP会停止运行。（15%的机率，涉及到首页的架构）
2. CRM提现金额与APP端不符。其他等级状态的bug有152条，分布如下：
11/25版本迭代我们测试组做了如下努力：1. 编写详细的专家版测试用例，与项目经理、产品组对接了理解有误的部分需求，并订正修改。
2. 简单的输出了需求中基本功能的思维导图。
3. 按照开发日报及时调整测试计划，跟进主要功能的持续修改。
4. 推动TDD模式的测试开发方式。
5. 推进用户版与专家版的联测，发动开发人员与产品交互一起找bug。
11/25版本迭代我们存在的问题：
1. 仍然是上线前又开启了边改bug边回归的模式。这种模式对于测试来说，我们是拒绝的。由于之前忙着开发新功能，遗留大部分的bug在上线前开始统一改，结果就是边回归边测试，效果不理想。
2. TDD测试模式为了适应快速开发模式，导致我们在短短一个月测试了20来个版本，我们要求可测试的版本是模块逻辑可走通的，此前版本按照项目经理输出的日报排的测试计划，虽然计划延期比较少，但是发布的测试包模块并没有真正的达到100%完成度，所以测试结果并不那么理想。
3. iOS与Android交叉测试不够此项问题的出现是由于测试机器过少，研发与测试在同时间段均需要测试机，导致测试到最后，发现部分iOS与Android实现的功能不一致。4. 团队人员对自己开发的功能不重视有不少初期发现的bug修改后，在后期又经常反复的出现，或者是修改一个bug却引发其他多个bug，致使后期的每一个版本都不敢保证模块功能的正确性，需多次花费时间验证和回归。
下一版改进的方式：
1. 时间的问题排计划的时候请各位开发能好好估量一下自己完成模块的时间，也应实事求是的汇报模块的完成度。我们可测试的标准是项目经理日报上的完成度。
2. TDD模式TDD模式保证了项目在研发中，每个工种在项目周期内的工作尽量并行。这种模式要求每个人员对自己的工作进行较准确的评估，以保证其他部门的无误配合，也是目前最适合我们的测试开发模式。我们需要做的努力就是合理的评估工作时间，每一个模块或功能完成后，相关开发人员能自觉及时的将测试包放至svn上，以便让需要配合的部门能主动的介入到当前项目中。
3. 测试机型过少的问题目前已经在采购，此问题在下一版本的研发阶段会有较大改善。
4. Bug描述与有效沟通之前赶时间，禅道上有些bug描述得比较简短，结果得不偿失，增加了很多沟通成本。下一版本中，每一个bug要求把步骤和期望描述准确，每一偶现或必现的问题都尽量附上截图，开发人员疑惑的bug也及时沟通还原助理解。
这两天在看《不懂项目管理，还敢拼职场》这本书，里面介绍了合理评估时间的方法有“最乐观的时间*1.5”，我们目前的迭代进度做不到如此评估，但是也不可以改为 “恰恰好的时间*0.8”，这样子做的结果就是夜夜加班，质量保证不了的情况下，实现的效果也未达标。
最后给大家来碗鸡汤：人要学会爱自己，何为爱自己？把自己想象成自己的父母，爱人，儿女，你不想让他们做的坏事情，你自己也不要做，这就叫爱自己！
愿我们都少加通宵班，好好爱自己！
测试人员
