功能体验测试最好是与研发同步。Web测试提供测试环境，产品设计团队通过配置host即可访问测试环境，随时能看到开发进展情况。对客户端的开发，则每天定时合并代码到trunk并提供daily build版本，产品设计团队及时下载体验，并在下班前将体验问题通过工作群告知研发人员，以便研发人员第2天及时改进。这样可以及时纠偏，减少研发憋大招。这个地方看似很小的工作习惯改变，但是会产生天壤之别的结果。所谓敏捷开发，也体现在这些协作细节里。

　　(3)性能测试

　　性能测试关注软件完成特定功能的响应速度、稳定性和运维成本消耗。主要是为了优化系统容量、可扩展性、系统稳定性、资源利用率等指标。

　　性能测试一般采用压力测试的方法，通过给系统加载一定负荷的业务压力，让系统持续运行一段时间(一般为7×24小时)，检测系统是否能稳定运行。

　　性能测试方案模板(大纲部分)

　　性能测试主要步骤如下：

　　A)罗列主要用户场景及相应负载量

　　重点针对可能出现性能瓶颈的场景，逐项分解和预估负载量。

　　为了让系统抗压能力更大一些，一般都会多预估一定比例的负载量，以防出现意外情况。

　　B)识别稳定性的主要性能指标

　　然后根据每个场景的负载量，分解每个后台服务、APP、web端所需关注的系统指标，比如响应时间、CPU、内存使用率等。

　　C)单元性能测试与改进

　　在准备好测试环境后，使用测试工具对每个接口按照合法输入格式进行压力测试，确保在目标负载量都不会导致出现问题。比较常用的压力测试工具是Loadrunner。

　　如果系统出现响应延迟或崩溃的情况，则需要运维和研发快速迭代。然后再次测试，直到系统性能指标达标为止。

　　D)客户端兼容性测试

　　Web界面的兼容性测试，可以直接用Chrome内置开发工具即可完成。

　　APP兼容性测试，最好借用第三方工具(例如Testin云测)，提交APP后，Testin云测将会部署APP到数百款手机，然后自动输出兼容性稳定性报告。也可以根据测试工程师提供的测试用例，针对每款手机批量进行功能和体验测试。

　　E)整体系统测试与改进

　　当每个场景下的单元测试完成后，再针对整个系统进行完整的压力测试。

　　同样，如果出现响应延迟或崩溃的情况，则需要运维和研发快速迭代，找到出问题的后台接口或前台模块进行优化，直到系统性能指标达标为止。

　　(4)数据初始化运营

　　数据初始化首先是数据库工程师根据产品和运营人员的需求，对基础数据进行完善和补充，以达到能用户能正常使用的状态。

　　比较麻烦的是以往旧系统的数据迁移，由于旧系统和现有系统的字段，类型，日期格式，数字格式等差异，需要抽丝剥茧一层层把数据注入到对应的数据表里，特别是表间关系需要继续保留下来。

　　然后是运营人员通过运营后台，手动修改部分有问题的数据。

　　(5)产品内部测试

　　测试工程师完成所有测试用例的测试工作，研发人员将所有必须完成的Bug修正修正完成，其他待修正bug完成转需求后，就可以启动产品内部测试了。

　　内部测试首先可以针对产品相关的所有员工，包括产品、研发、运营、市场、运维等各个角色。这个过程一方面是为了收集产品缺陷反馈，同时也是让相关人员有参与产品改进的机会，让大家能荣辱与共。同事对于产品的容忍度比用户要高得多，就算产品做得很烂，他们都会坚持着把产品所有功能都用一遍，而真实用户很可能看到一个不好的体验点转身就走。因此产品经理一定要高度重视同事反馈，同事发现每个的缺陷，都一定会导致大量用户流失。

　　员工反馈的问题如果是之前没有发现的缺陷，就需要尽快改进修正。如果对当前版本影响不大，就可以放到以后版本Bug转需求，并记录下反馈人信息和详细沟通结论。

　　等员工完成内测后，产品经理可以将产品内部测试版发到核心用户群里，以有奖测试的形式刺激大家提交缺陷。如果线上反馈不够深入，可以由UER调研小组邀请用户当面沟通交流，找到更深入的缺陷。这些问题汇总提交到Bug列表中，可以马上修正的尽快修正，可以放下个版本的Bug转需求。

　　9、发布上线阶段

　　发布环境的搭建，包括预发布环境、生产环境、灰度发布环境的准备等工作。

　　而正式上线的工作，则包括数据库上线、程序文件上线等工作。