论系统测试技术及应用

原创 微笑的蚂蚁人 开源测试联盟 今天
论系统测试技术及应用

摘要：
2017 年 7 月，我作为项目负责人，参加了某银行的统计数据发布系统建设项目，该项目合同金额 200 万元，合同工期为半年，该系统的主要目标是为该行建设企业级的数据统计、分析、发布平台，实现定制化的数据应用、分析、展示功能；实现灵活的综合查询分析、明细数据查询、固定报表展示、移动设备数据展示、风险分析、自助取数等功能，达到 “统一数据来源、统一数据口径、统一数据出口” 的数据管理目标。
本文结合本人在该项目中的实践， 讨论了我们在单元测试、功能测试、集成测试和性能测试中针对应用系统和 ETL 指标加工采取的不同的测试措施和策略，并重点讨论了性能测试的类型和在如何在项目中实践这些性能测试类型。

正文：
某银行在各项经营活动中积累了大量数据资源，这些数据除了支持银行生产业务流程运转之外，也越来越多地被用于支撑监管报送、精准营销、战略决策、风险控制、绩效考核等运营管理和决策过程的数据分析需求。为了满足业务部门和管理人员不断增长的报表数据需求，为决策分析提供依据，反映全行业务发展情况，识别和监测风险状况，迫切需要规划和建立科学、规范、易于扩展、灵活性强的统计数据发布平台，进一步完善全行报表体系，降低该行报表开发成本和难度，缩短报表开发周期，规范报表使用流程，降低管理与维护复杂度，实现统计数据集中及统计报表统一、规范管理。
2017 年 7 月，我作为项目负责人，参与并主导了该银行的统计数据发布平台项目，该项目合同金额 230 万元，实施周期为半年。本项目产品架构基于 JAVA 开发的 BS 架构，数据库平台是 oracle11g，中间件为 weblogic，报表展现工具采用国内知名的 SMARTBI 产品，调度工具为国内产品 TASKCTL,数据采集工具采用开源的 Kettle。
我们在 IBM 完全生命周期测试模型的基础上，根据本项目的具体特点和要求，结合成本效率进行了裁剪，形成本项目的测试策略、总体测试计划和详细测试计划，并得到了行方技术部门的认可。整体划分为单元测试、功能测试、集成测试、性能测试和验收测试。验收测试主要由行方业务人员进行，因此本文重点讨论前面 4 个阶段的测试。
一、单元测试阶段
分为应用系统测试和 ETL 开发单元测试。
应用系统测试由于是用 java 开发，所以采用了 JUNIT 进行单元测试，由于本项目是基于标准产品的二次开发，类的数量不多，因此我们要求开发人员对每个新开发的类都要写对应的测试类，测试通过后需要写单元测试报告，并要求组内人员交叉检查执行。
ETL 开发是采用 perl 脚本 + 存储过程的方式进行开发，单元测试阶段主要采用公司自主研发的 ETL 开发自动化测试工具，通过进行一定的配置，可对 ETL 脚本进行自动化运行，可进行空值检查、主键重复检查等。
二、 功能测试阶段
由于本系统既要在 pc 端展示，同时也需要在移动端进行展示，因此要求应用系统的功能测试主要通过编写一份测试案例，能在多个终端执行。我们使用公司自主研发的基于 STAF 自动化测试框架的测试工具进行功能测试，确保页面功能在跨平台，如 PC 端、手机安卓端、手机苹果端都能运行正常，并确保在各个终端的链接跳转都是符合预期的。
三、集成测试阶段
集成阶段，需要将每个 ETL 作业配置在调度工具上，因此集成测试阶段主要测试调度作业是否按照各种串行、并行机制分别运行，确保依赖作业的先后顺序执行。
本阶段另一个测试重点是测试数据加工的准确性。主要采用以下几种测试手段：1、每个字段的值域范围测试，譬如某个指标的历史波动范围在 100 万~300 万之间，那么加工后的指标就不应该超过这个范围。2、借助于业务经验，采用总分比对的方式。银行一般有两本账，分户账和汇总账，通过按照机构、科目分类从明细汇总后，应当和现有的总账指标一致。以上测试时都可用公司自主研发的 ETL 测试工具，在上面配置校验规则后进行测试执行。另外，测试数据的完整性是确保数据准确性的关键所在，因此我们在测试案例编写过程中便同步进行测试数据的申请。
对于信息类系统，数据指标的正确性是重中之重，以往项目中，由于对数据准确性测试不充分，导致试运行阶段不断返工，不仅增加了开发人月投入，还导致了验收期的延长。
四、性能测试
性能测试的目的是验证软件系统是否能够达到用户提出的性能指标，同时发现软件系统中存在的性能瓶颈，并优化软件，最后起到优化系统的目的。具体来说，包括以下四个方面。（1）发现缺陷：软件的某些缺陷与软件性能密切相关，针对这些缺陷的测试一般需要伴随着性能测试进行。（2）性能调优：与调试不同，性能调优并不一定针对发现的性能缺陷，也可能是为了更好地发挥系统的潜能。（3）评估系统的能力：软件性能测试不仅需要测试软件在规定条件下是否满足性能需求，往往还需要测试能够满足性能需求的条件极限。（4）验证稳定性和可靠性：在一定负载下测试一定的时间，是评估系统稳定性和可靠性是否满足要求的唯一方法。
性能测试类型包括： 基准测试：在给系统施加较低压力时，查看系统的运行状况并记录相关数做为基础参考； 负载测试：是指对系统不断地增加压力或增加一定压力下的持续时间，直到系统的某项或多项性能指标达到安全临界值， 例如某种资源已经达到饱和状态等； 压力测试：压力测试是评估系统处于或超过预期负载时系统的运行情况，关注点在于系统在峰值负载或超出最大载荷情况下的处理能力；稳定性测试：在给系统加载一定业务压力的情况下，使系统运行一段时间，以此检测系统是否稳定。 并发测试：测试多个用户同时访问同一个应用、同一个模块或者数据记录时是否存在死锁或者其他性能问题，
项目实际中，我们采用 RoadRunner 作为性能测试工具。基准测试方面，我们主要测试系统在用户登录数处于非月初正常水平下，系统的各项运行指标。将各项指标进行记录作为参考。在月初，系统用户数会有一个激增的过程，主要是因为月初为各业务部门进行数据统计报送的高并发期，因此需要基于这个用户数量再加上未来 5 年内该行业务部门统计人员增加的预估情况进行负载测试和压力测试，我们要求系统的负载测试能至少 10 个工作日的时间，压力测试要求系统运行的各项指标不能低于基准测试的指标的 80%。这些基准指标中，我们重点关注数据查询响应效率指标，要求 1 千万级记录数以下的表查询响应时间为 1 秒以内，1 千万级~3 千万级记录数的查询响应时间为 3 秒以内,3 千万~6 千万为 6 秒以内。同时，在测试过程中，还要及时发现 ELT 作业运行时间超过基准指标的作业进行整改，避免了这些作业在上生产后由于运行缓慢导致整体时间窗口延长。
2017 年 12 月，本项目历时半年，在双方项目领导的大力支持下，在双方项目组成员的共同持续奋战下，项目最终成功实施完成并顺利验收，客户的高层领导在手机移动端看到了准确数据组织的业务指标，而且界面美观、功能流畅，因此高度认可，于是客户的科技部门给我们公司发来了表扬信，并与公司快速签约项目的二期建设。本项目的成功有很大程度上得力于采用了科学测试技术、测试方法的应用，测试取得了不错的效果，有力保障了项目的质量，但是仍然有不足的地方，具体存在以下几方面：开发人员测试观念不过强，虽然要求进行单元测试，但是开发人员没有很好的执行，导致在集成测试阶段发现较多问题。公司自主研发的测试工具在配置上不够灵活，无法快速配置大量测试案例，这也是开发人员没有很好执行的原因之一。测试案例的准备方面，有些数据准备的不够完备。
我们从实践中领会到测试确实可以在保证软件质量方面起到很大的作用，但同时我们也认识到测试中还有很多领域和知识点需要继续研究和实践，新技术的发展对测试也提出了新的要求和挑战，需要我们继续研究探索。