测试人员眼中的app版本迭代过程中的问题

测试人员眼中的app版本迭代过程的问题

    --记一次app新版本的开发测试过程

1. 前言

　　自从8月初入职当前的公司以来，在这一期的版本迭代过程中，第一次独立承担app部分的全部测试设计及需求跟踪，从头至尾跟踪了需求分析到开发测试上线的整体过程,和曾经做过的各种测试类型相比，它没有想象的那么好，也没有想象的那么坏。应了那句老话，梨子好不好吃，自己尝了才知道。

　　经历完整个迭代之后，感慨良多。在这里梳理整个过程，以测试的角度来分析整个迭代过程，作为以后工作的参考。

2. 简介

　　2.1 项目及公司简介

　　公司属于传统药店行业向移动互联网医疗行业转型，在移动互联网方面属于创业阶段。当前迭代项目为预计的更新版本，主要完成app的部分功能优化。

　　2.2 团队架构 

　　　　有PMO、产品设计中心、技术研发中心三个一级部门，在项目中的角色及人员分配为

　　　　　　PMO-项目经理(1人)

　　　　　　产品设计中心-产品经理*2/UI/UE(4人)　

　　　　　　技术研发中心-前端(app(Android(6人)/iOS(6人))/H5(4人))/后端(6人)/后台(2人)/运维(2人)/测试(6人)，共32人

　　　　注：除app外，还有三个微信端(不同的用户角色)，但是不在作者负责范围内，不在本文档中进行相关说明。

　　2.3 迭代周期

　　　　需求分析及设计：11.23-11.26

　　　　开发：11.30-12.7

　　　　测试：12.8-12.15

　　　　上线：12.16凌晨

3. 迭代过程中的问题

 　　3.1 总是处于变更中的需求

　　　　第一次变更 - 11.25

　　　　在本次迭代开始之前，有两个单独的需求已立项，这两部分较为独立，重要性也是较高的。

　　　　凡事总有但是，但是，这两个需求在已完成需求和原型，马上进入开发设计时被砍掉了，原因是公司商务及其他领导层经过评估后认为不适宜此时完成该项目，具体完成时间不定。在砍掉这部分后，产品经理根据项目情况重新调整需求内容，再次进行全项目范围（项目经理、产品、开发测试）的技术评审和排期。技术评审过程中，又进行了细微的变更。正式需求范围于11.26完成并进入正式的开发过程。

　　　　第二次变更 - 12.2

　　　　测试用例初版完成。以xmind格式进行用例评审，在评审过程中又一次发现了之前没有明确的部分，经过讨论，得出了部分结论(之所以说部分是因为后续发现当时得出的结论实际是个草稿，后续还有多次细化)。另外本次评审还发现了部分不明确的需求，产品 开发 测试三方意见不一致的需求，都一并得出了结论。

　　　　第三次变更 - 12.9 早

　　　　测试第一版已发布。在初步的轮测试过程中，发现许多不确定的部分，与产品经理多次沟通后获得了统一的结论，于12.9进行了需求更新

　　　　第四次变更 - 12.10 晚

　　　　测试已进行至第三天，微信端的某个需求变更需要在app端进行对应，之前是考虑完全不影响，但是后台接口发生了变更，实际对app端产生了影响。综合考虑后重新给出了相应需求，此部分变更并不小，后期的压力较大。

　　　　第五次变更 - 12.15 上线前

　　　　上线前当天晚上，测试已完成，交付产品验收。在验收过程中，产品和UI又临时提出了几个界面显示问题，开发临时修改后当晚正常上线。

　　3.2 坎坷的开发

　　　　iOS

　　　　开发组长在提交测试之前专门请测试组吃饭，保证本版本中实际缺陷不超过20个，一定给测试组降低压力。在实际提交测试之前，还发动开发人员按照测试用例进行走查。实际测试过程中，发现缺陷113个，有80%都是测试用例中可以发现的部分，10%为之前版本遗留缺陷，剩余10%为测试用例设计未覆盖的部分。

　　　　有个需求未按时提交测试，该开发人员未出差至广州，一直与作者通过电话沟通相关需求的实现细节，在2天后提交测试，仍然发现了大量的缺陷。

　　　　iOS在本期迭代中发现闪退缺陷6个，有的非常明显，进入功能项就闪退，有的需要17步操作才能发现，还有的复现条件很特殊，需要特殊情况才可以。

　　　　Android　　

　　　　安卓组长在迭代过程中另外接了一个特殊项目，需要单独跟踪。同时他给自己分配了一个本期项目的任务，但是一直没有开始执行，一直到12.13才加班完成，12.14提交测试，好在这部分没有发现严重问题。

　　　　但是，新版本安卓包在用户更新后，进行关键操作时导致app闪退，究其原因，是本期安卓组进行了底层db层重构，SQLite的表中某个字段发生了变更，在查看历史数据时导致app闪退。

　　3.3 在沟通中前行的测试

　　　　在整个的版本迭代过程中，测试就在不断的沟通中前进：和产品经理确认需求细节、和UI确认实现细节、和开发确认什么时候提交测试\什么时候解决问题\具体的需求细节是什么\这部分需求是不是这样\到底是不是缺陷\缺陷具体怎么复现、安卓和iOS端的测试相互确认实现是否一致\谁的才是正确的...等等等等。

　　　　在整个版本过程中，根据需求的变更情况，测试用例经历了多次更新。

　　　　在测试用例评审过程中，发现了一个较大的交互设计遗漏。

　　　　升级测试的下载安装和缓存数据验证部分有测试遗漏，导致安卓上线后出现了闪退问题。

4. 后记

　　想当初，老子的队伍刚开张，拢共十几个人七八条枪　　--京剧《沙家浜》选段

　　新项目的团队6月份才成立，团队成员来自各式各样的公司。刚刚成立的团队总是有各种各样的问题：从业人员的专业水平参差不齐、团队人员的配合程度有待进一步完善，由于项目紧张，整体的沟通管理方式、项目的开发管理过程没有统一的定义。总之各种各样你能想到的问题都会存在，不过这都不是最难解决的，最难的是这个团队是否有解决问题的动力和决心。这是唯一令人安心的地方，我们的产品、设计、开发、测试、运维和我们的项目管理人员都在努力的为了完成项目目标而努力，每一次项目迭代后都会讨论目前存在的问题而进一步分析，后续改进。

　　根据目前项目的实际情况，下一个迭代将会进行进行重构和界面的改版，新的版本将会以全新的面目展现在用户面前，希望我们可以成功。