测试工程师的2009年度总结与10年计划(一)

2009年已经结束了，这1年，我主要从事数据仓库的测试工作。

　　大大小小的项目测试了有5个左右，发现bug的数量也有20多个。

　　比较数据仓库测试与传统的web应用项目测试，这2者之间有很多不同。

　　首先，测试对象不一样。

　　之前测试web应用项目，涉及的对象主要是应用项目，包括项目的各个功能模块，web页面。采用的纯黑盒的测试。不需要了解代码。

　　但是数据仓库不一样，对象主要是数据。对数据进行测试。由于公司etl抽取采用的procedure的形式，

　　没有借助工具，所以测试人员需要对sql相当的熟悉。包括简单以及复杂的sql编写，且还需要了解sql性能调优方面的问题。简单的说就是对sql，以及存储过程进行测试。

　　其次，侧重点不一样。

　　web应用项目关注模块的功能是否实现，是否符合需求。且要求比较严格，甚至对页面的布局也都很严格。

　　但是数据仓库的测试是没有严格的界面的，数据的展现往往是通过报表。测试不用花很多时间在报表的布局方面。而是重点关注展示的各个指标是否正确。另外由于数据仓库数据的来源有很多渠道，数据量往往也是T级别的。因此存在一些脏数据，在数据仓库中，如果脏数据没有达到一定的比例，那也是允许的。

　　其次，面对的数据量不一样。

数据仓库的数据量往往是T级别。在数据仓库测试中，不可能对每一条数据进行准确性的验证，采用比较多的方式是抽样以及手工造数据集。

　　3，测试方法不一样。

　　web应用项目多数是黑盒测试与自动化测试相结合的测试方法。

　　而数据仓库则是基于查询的测试。在web应用项目中，对于预期结果是可以很准确的定义出来的，

　　但是在数据仓库测试中，预期结果一般以算法的形式展现，即sql的形式，预期结果基于sql来展现，做到数据变化，结果不变。

　　目前我们采用的最多的测试方式是：标准数据集的构造+预期结果sql+实际结果sql+实际结果与预期结果比对

　　4，黑的程度不一样。

　　功能测试可以说完全是黑盒测试。而数据仓库测试，至少在我们公司目前来说，测试人员需要查看源码，相当于灰盒测试。

　　5,测试分析用例的编写不一样。

　　经过几个项目的实践，数据仓库的测试用例与web应用项目的用例编写还是有些不一样的。

　　例如：web应用项目用例通常需要大量文字描述每一步骤。但是数据仓库测试，我觉得重点在于测试分析。弄清楚源表，目标表，以及之间的映射关系，就可以了。

　　用例的展现通常是一些sql和存储过程。另外做好数据仓库的测试，重点在于要有全面的数据集，对业务的理解也很重要。因为数据仓库分析的是很长一段时间的数据，多数是为前台网站提供运营支持，或提供商业智能分析。如果对业务理解不深刻，就很难确认需求的必要性以及指标算法的准确性。

　　

　　通过之前测试的项目，我总结了一下数据仓库etl测试的一些公用测试点(包括etl常规检查与业务逻辑检查)：

　　ETL常规检查：

　　1.程序是否能顺利编译通过，是否能执行

　　2.程序是否能重复调度

　　3.程序是否能支持回滚

　　4.程序的错误处理机制是否完整

　　5.程序执行是否存在性能问题

　　6.数据趋势稳定性检查

　　

　　业务逻辑检查：

　　1.记录平衡验证，验证执行结果中的记录条数是否符合业务需求的记录条数

　　2.度量平衡验证，验证执行结果中可累加度量（如金额）的总量是否符合需求，

　　 边界值是否符合需求，枚举值是否符合需求

　　3.数据有效性验证。数据抽样检测，抽取具有代表意义的数条记录，验证程序是否符合需求

　　4.参照完整性验证(A,B表之间的关联关系)。

　　5.唯一性检查。

　　 主键是否重复(cookie_id,member_id是否重复)

　　6.重复性检查(是否存在相同的记录)。

　　7.随机性验证。