Monday, 8 September 2008
牛人指导
- 多了解市场营销和管理方面的，再加上BI和计算机技术．．．．．．最后结合某个行业
- BI是技术和业务相结合，为管理而服务
Below from ITPUB
从事BI领域的工作在将来应该是很有潜力的，最近这些年，BI的气氛在各个行业都在升温。但是，根据自己的特点，应该知道在BI行业，自己应该向哪个方向去发展，从宏观来说，BI分为技术路线和业务路线，管理路线应该是什么都通用的了。
搞技术包括DW架构，DM算法，ETL研究，模型设计，前端应用等等方面。可以选择自己的方向。搞业务那就是挖掘客户需求，达到“告诉客户你能给他带来什么，而不是客户要求你给他做什么”的水平应该就很不错了，搞业务就与行业很密切。一般要积累三五年经验吧。
如果能够进入DW项目组学习这是最好的入门，我觉得你从前端应该入门可能会更快，多学习一些前端工具，如Actuate报表工具,BO,BRIO,CRYSTAL等等，这样可能对你了解BI是怎么回事会更好。
Term - Regression testing
http://searchsoftwarequality.techtarget.com/sDefinition/0,,sid92_gci212884,00.html
Regression testing is the process of testing changes to computer programs to make sure that the older programming still works with the new changes. Regression testing is a normal part of the program development process and, in larger companies, is done by code testing specialists. Test department coders develop code test scenarios and exercises that will test new units of code after they have been written. These test cases form what becomes the test bucket. Before a new version of a software product is released, the old test cases are run against the new version to make sure that all the old capabilities still work. The reason they might not work is because changing or adding new code to a program can easily introduce errors into code that is not intended to be changed.
Regression testing is the process of testing changes to computer programs to make sure that the older programming still works with the new changes. Regression testing is a normal part of the program development process and, in larger companies, is done by code testing specialists. Test department coders develop code test scenarios and exercises that will test new units of code after they have been written. These test cases form what becomes the test bucket. Before a new version of a software product is released, the old test cases are run against the new version to make sure that all the old capabilities still work. The reason they might not work is because changing or adding new code to a program can easily introduce errors into code that is not intended to be changed.
How to test a datawarehouse(ZZ)
译者不详，转自这里。
http://qzone.qq.com/blog/85505526-1216539937
英文原文
http://searchsoftwarequality.techtarget.com/tip/0,289483,sid92_gci1310594,00.html
这篇文章是应一位读者关于如何测试数据仓库的问题而写。他的问题是：“在数据仓库环境下进行测试时如何处理需求与质量的关系？”虽然数据仓库的测试是 一个惊奇而神秘的过程，但实际上它与其它测试项目并无多大区别。基本的系统分析和测试过程在这里仍然有效。我们来看一下其中的几个步骤，并研究如何在数据 仓库环境中应用。
分析源文件
与其它项目一样，测试数据仓库部署时，通常都会有一份相关的说明文件。虽然这些文件对于创建基本的测试策 略非常有用，但经常会缺少一些关于测试开发与执行的详细资料。有时会有一些其它文件解释技术上的细节问题，即从源到目标的转化（source-to- target mappings）说明文件。这些文件详细说明了数据的来源、如何对数据进行操作，以及存储到哪里。如果能拿到这些文件，关于系统设计的文件在设计测试策 略时也会变得更加有用。
开发策略和测试计划
分析了各种各样的源文件后，就要开始创建测试策略。我发现从生命周期和质量的角度来看，增 量测试是测试数据仓库的最好办法。这从本质上意味着开发团队会从开发过程的早期开始，将各种小组件交付给测试团队。这个办法的主要优点是避免交付让人吃惊 的“大块”组件，可以从早期开始检验缺陷，并使调试变得简单。此外，这个方法还有助于在开发与测试周期中建立详细的过程。具体到数据仓库测试，即是对数据 获取分段表，然后是增量表、基本的历史表格、BI视图等的测试。
另一个制定数据仓库测试策略的主要问题是基于分析（analysis- based）的测试方式和基于查询（query-based）的测试方式的选择。纯基于分析的方法是让测试分析师通过分析目标数据和相关标准计算出 预期结果。基于查询的方法有相同的基本分析步骤，但更进一步，用SQL查询语言编写预期结果。这为将来建立回归测试过程节省了很大精力。如果测试是一次性 的，那么用基于分析的方式就足够了，因为通常这种方式较快一些。反之，如果企业对回归测试有持续的需求，那么基于查询的方式会更为合适。
测试的开发与执行
不管在测试执行过程之前还是之后进行测试的开发，要根据上行需求的稳定性和分析过程决定。如果情况变动比较频繁，那么早期进行的测试开发可能大部分都会被 废弃。这种场合，实时进行的整合的测试开发和执行过程通常会更有效果。不管怎样，在设计测试开发和执行过程的框架时，参考一下测试分类总是有用的。比如， 一些数据仓库的测试分类可能有：
关于作者：Baher Malek目前在财富杂志排行前100的公司任质量与测试总工程师，帮助传统的项目团队采用敏捷方法进行软件测试。Baher还经常参加IWST和WOCST研讨会并发言（即印第安纳波利斯软件测试研究小组和软件测试员开放认证研讨会，详见http://www.iwst2008.com/与http://www.freetestingcertification.com/workshops.html）。
http://qzone.qq.com/blog/85505526-1216539937
英文原文
http://searchsoftwarequality.techtarget.com/tip/0,289483,sid92_gci1310594,00.html
这篇文章是应一位读者关于如何测试数据仓库的问题而写。他的问题是：“在数据仓库环境下进行测试时如何处理需求与质量的关系？”虽然数据仓库的测试是 一个惊奇而神秘的过程，但实际上它与其它测试项目并无多大区别。基本的系统分析和测试过程在这里仍然有效。我们来看一下其中的几个步骤，并研究如何在数据 仓库环境中应用。
分析源文件
与其它项目一样，测试数据仓库部署时，通常都会有一份相关的说明文件。虽然这些文件对于创建基本的测试策 略非常有用，但经常会缺少一些关于测试开发与执行的详细资料。有时会有一些其它文件解释技术上的细节问题，即从源到目标的转化（source-to- target mappings）说明文件。这些文件详细说明了数据的来源、如何对数据进行操作，以及存储到哪里。如果能拿到这些文件，关于系统设计的文件在设计测试策 略时也会变得更加有用。
开发策略和测试计划
分析了各种各样的源文件后，就要开始创建测试策略。我发现从生命周期和质量的角度来看，增 量测试是测试数据仓库的最好办法。这从本质上意味着开发团队会从开发过程的早期开始，将各种小组件交付给测试团队。这个办法的主要优点是避免交付让人吃惊 的“大块”组件，可以从早期开始检验缺陷，并使调试变得简单。此外，这个方法还有助于在开发与测试周期中建立详细的过程。具体到数据仓库测试，即是对数据 获取分段表，然后是增量表、基本的历史表格、BI视图等的测试。
另一个制定数据仓库测试策略的主要问题是基于分析（analysis- based）的测试方式和基于查询（query-based）的测试方式的选择。纯基于分析的方法是让测试分析师通过分析目标数据和相关标准计算出 预期结果。基于查询的方法有相同的基本分析步骤，但更进一步，用SQL查询语言编写预期结果。这为将来建立回归测试过程节省了很大精力。如果测试是一次性 的，那么用基于分析的方式就足够了，因为通常这种方式较快一些。反之，如果企业对回归测试有持续的需求，那么基于查询的方式会更为合适。
测试的开发与执行
不管在测试执行过程之前还是之后进行测试的开发，要根据上行需求的稳定性和分析过程决定。如果情况变动比较频繁，那么早期进行的测试开发可能大部分都会被 废弃。这种场合，实时进行的整合的测试开发和执行过程通常会更有效果。不管怎样，在设计测试开发和执行过程的框架时，参考一下测试分类总是有用的。比如， 一些数据仓库的测试分类可能有：
- 记录计数（预期与实际对比） [Y:For CDC(A & D) is pretty good.]
- 副本记录
- 参考数据有效性[Y: Data Cleanse??]
- 参照完整性
- 错误与异常逻辑
- 增量过程与历史过程 [Y:For CDC(C) is pretty good.]
- 控制栏值与默认值
关于作者：Baher Malek目前在财富杂志排行前100的公司任质量与测试总工程师，帮助传统的项目团队采用敏捷方法进行软件测试。Baher还经常参加IWST和WOCST研讨会并发言（即印第安纳波利斯软件测试研究小组和软件测试员开放认证研讨会，详见http://www.iwst2008.com/与http://www.freetestingcertification.com/workshops.html）。
Subscribe to:
Comments (Atom)