每每提及大数据部门的测试，总是给人很神秘的感觉。测试团队究竟是如何开展测试的呢？借此机会跟大家分享下。
目前，大数据部测试组共对接4个研发团队和1个产品团队。覆盖产品线近20多个，累计测试用例达3万多条，累计提交bug4800多个，基本覆盖大数据平台的所有数据线，不仅保证了每周至少两次的迭代版本的99%以上的准确率，同时还保证了整个平台各产品的平稳运行。
图中是目前测试组所覆盖的业务产品线，以上所有产品线质量的校验跟传统的测试是基本一致的，遵循：需求调研+分析---->测试策略计划制定---->测试用例编写--->执行测试----->线上验证测试----->测试总结的流程；整个流程的执行与产品和开发团队的支持和配合是分不开的，产品原型评审+技术架构评审+测试用例评审+提测报告+上线报告，这一系列的会议及模板建立起来才有助于整个流程的持续执行。
1、需求调研+分析
这是测试介入的第一个环节。可能很多人会疑惑需求调研分析也要测试介入么?答案是肯定的，测试若不清楚需求的背景现状是无法真正做好测试、保证产品质量的。
举例来说，一个改版项目，为什么要改版？即改版的初衷，老版的痛点，新版的亮点，功能逻辑新老会不会有冲突，老版数据新版如何展现，新老版本之后是共存还是老版要下线，共存的话，老版上是否能查到新版数据，同理在新版上老数据如何查询使用，都需要深入到细节。除这些基础功能数据外，新增功能所要解决的问题，带来的优势是什么，作为测试人员需要考虑的更加全面深入。
总的来说就是：需求分析的越透彻，后续的工作就越顺利。这个步骤是需要产品、开发、测试相互补充辅助完成。
2、测试策略计划制定
通过开发的技术架构评审会，测试会了解开发的架构逻辑，表结构设计，开发排期，从而制定测试策略方法，测试重点，测试工具选用，测试排期，风险预估等
3、编写及评审测试用例
· 测试用例需要覆盖所有的测试场景：
正常的，异常的、功能逻辑的，接口的、性能的等等.
· 测试用例的目的:
从来就是为了更好执行测试，更好的保证执行测试时的高覆盖率和高通过率，绝对不是为了写用例而写用例。
· 测试工具的选择遵循两个重要标准：
（1）清晰展现测试思路和逻辑
（2）方便快速评审及执行测试。
目前我们所使用的的用例管理工具是matrix+easytest+freemind+excel，根据不同的需求场景，选择不同的工具， 测试用例的评审，需与产品、开发等项目参与人员一起评审，保证测试场景全面覆盖，避免有遗漏或错误。在用例平台上，每个小功能的详细逻辑都可以在用例中找到最初的定义（所以测试对整个平台功能逻辑的烂熟于心，并不仅是有脑可依，而是有据可依）。
4、用例执行测试
执行测试包括两部分:
第一部分主要针对每周平均两次的迭代版本测试，在短时间内快速完成并保证高效的通过率，所以这种类型的执行测试以手工测试为主工具为辅。
第二部分是定期执行部分, 该部分的执行测试周期是根据实际业务需求定义的（每天，每周、每月等）,主要依赖工具执行。用来做web、接口的功能测试和性能测试，包括selenium+git+idea、easytest、jmeter、beyondcompare这类工具分别设置了不同的执行周期，定期的进行全产品线的回归测试，进一步保证产品功能逻辑及接口功能的正确及可用性。
5、线上验收测试
上线后，第一时间针对上线更新内容进行线上回归测试(尤其是部分功能或者bug，只能在线上环境回归测试的)，并且快速反馈给开发和产品，做出决策；上线验证完成后，根据实际上线结果（成功或回滚或存在遗漏问题）向项目所有成员发送上线测试报告;
6、测试总结
项目总结部分主要分三大块：文档整理、技术总结、项目概况综述。
· 文档整理
文档整理是针对项目所涉及的环境数据、业务数据等实际场景做项目后的总结整理。
· 技术总结
技术总结主要是针对项目中用到的工具技术，所遇到的难点或新的突破和改进。
· 项目概况综述
项目概况综述包括需求覆盖率、需求遗漏变更率、开发自测通过率、开发bug反复率、用例覆盖率、问题遗漏率、项目bug类型及数量统计等。
通过以上三项的整理总结，分析并找出测试工作需要优化和改进的技术或流程，给出解决方案并应用于后续测试工作中。
在之后的测试过程中我们也将继续深入到数据处理底层中，并且寻找或研发更加适合大数据测试的策略、方式、工具，继续的摸索和总结下去，相信我们会越做越好。
相关推荐：
