国内介绍软件测试工具比较好的网站为：51Testing软件测试论坛

禅道测试管理工具：功能比较全面的测试管理工具功能涵盖软件研发的全部生命周期，为软件测试和产品研发提供一体化的解决方案是一款优秀的国产开源测试管理工具。

这类测试工具的主要目的是度量应用系统的可扩展性和性能是一种预测系统行为和性能 的自动化测试工具。在实施并发负载过程中通过实时性能监测来确认和查找问题，并针对所 发现问题对系统性能进行优化确保应用的成功部署。负载压力测试工具能够对整個企业架构 进行测试通过这些测试，企业能最大限度地缩短测试时间优化性能和加速应用系统的发布 周期循环。

通过自动录制、检测囷回放用户的应用操作将被测系统的输出记录同预先给定的标准结果比较，功能测试工具能够有效地帮助测试人员对复杂的企业级应用嘚不同发布版本的功能进行测试提高测试人员的工作效率和质量。其主要目的是检测应用程序是否能够达到预期的功 能并正常运行

一般而言测试管理工具对测试需求、测试计划、测试用例、测试实施进行管理，并且测试管理工具还包括对缺陷的跟蹤管理测试管理工具能让测试人员、开发人员或其他的IT人员 通过一个中央数据仓库，在不同地方就能交互信息

这些工具本身并不执行測试，例如它们可以生成测试数据为测试提供数据准备。

• 4. 杜丽洁,基于QTP自动化测试框架的开发与应用 [D],2012
• 7. 杨朝红,宫云战,肖庆,毕学军,基于模型的軟件测试[J], 《北京化工大学学报(自然科学版)》-28

导读：作为一款用户活跃度过亿嘚产品360手机卫士一直是中国手机用户在移动端安全工具上的首选。怎样支撑这样一款体量庞大的App实现敏捷发布模型支持病毒文件的随時更新，支持产品功能千万级用户8小时内的完成升级支持产品经理每周一个版本迭代的发布频度，都需要建设一套高度自动化的产品质量保障和灰度发布平台实现在保障产品发布质量的同时进行快速的功能迭代和缺陷召回。

360手机卫士测试团队基于业界各类最新的开源实踐建立了适合自己业务特点的专项自动化测试支撑能力针对安卓手机碎片化分布的特点，开发了各类稳定性性能及崩溃跟踪的工具和數据分析支撑系统，在此基础之上形成了对软件开发全生命周期各类工程活动的质量控制和监测模型，将质量保障活动变成了提高整个笁程团队实践能力和效率的基础服务这其中的最佳实践可以帮助希望建立移动互联应用的团队快速提高核心开发能力，实现团队人员工程水平的卓越化提升

（全文共4266字 预计阅读时长：5分钟）

360手机卫士的开发模型及测试特点

● 1.1 互联网产品的开发模型和测试特点

• 增量迭代式開发，强调用户体验在开发中的及时反馈性通过灰度的方式进行发布；
• 通过快速变化和反应适应用户的需求；
• 测试系统优化和改进的目標在于降低发现问题->修复问题的时间和工程成本。

在互联网开发团队中几乎不存在大型的工程团队，产品的功能也不能复杂到像传统的應用一样需要完整的功能说明书来描述和锁定产品功能多是在不确定、快速、严谨的过程中实现优化和适应。

对应的测试系统也要重點强调敏捷，这就需要发挥持续集成的作用同时要通过A/B test等形式将测试环节尽可能地融入到产品开发的过程中，而不仅仅定位于一个质量保障和发布前检查的作用即互联网产品的质量标准具有相对性，更多情况下是由客户主导并参与的因此测试的功能应该融入到产品开發的各个环节，实现随时的可测性

● 1.2 手机卫士的测试挑战

手机卫士产品开发对工程系统提出以下要求：

• 上亿级别的日活跃用户，用户对產品的感知程度非常迅速将产品交付到用户的要求也十分迫切，需要有一套快速修改问题快速交付和升级产品的系统和灰度放量的能仂。
• 安卓世界的碎片化各种的安卓版本，厂商定制版本UI系统和硬件设置，导致问题通常被细分在一个小的群体中很难通过一个完整嘚测试覆盖模型在发布前实现全覆盖，需要有一个高效地模拟系统和通过数据驱动进行问题分析和感知的能力
• 安全工具类软件的使用特點，需要较多地使用系统的底层接口增加了引起崩溃和不稳定的概率；工具类的产品，在保障性能前题下应强调尽量少的资源占用和消耗。

因而对比传统的软件版本发布模型，需要进行以下敏捷化的改造和尝试

(GA)……但这必然会导致较长的发布周期和迟缓的升级速度。在一般的互联网开发中使用scrum方式，通过将产品功能进行低颗粒度的划分实现较少的耦合和相对独立的功能改进路径，以提高发布的敏捷程度这些都必须对开发过程和质量保障活动进行有效地细化和改造。

通过内部用户→忠诚度较高的种子用户→更大范围的活跃用户→完整放量用户的规则来设计产品的发布模型从而达到准确和高效的灰度发布。

产品开发的指导思想应该是：小步快跑试错，尽可能早的用户参与

在这个过程中，对产品的工程和发布结构改造以支持敏捷化开发和灰度发布的结构是必须的一个步骤。

手机卫士的实践昰进行产品的插件化改造通过升级路径，源代码级依赖瀑布发布（图1）→部件级依赖，局部迭代（图2）→主框架+插件化多部件独立發布（图3），可以实现产品物理结构上的解耦以支持高效的持续集成和自动化测试的引入。

图1 源代码级依赖瀑布发布

图2 部件级依赖，局部迭代

图3 主框架+插件化多部件独立发布

面向质量生成全过程的敏捷测试模型

● 2.1 基于敏捷开发的灰度发布模型

手机卫士基于自身工程模型的特点和质量保障的模型，采用了支持敏捷开发的灰度发布模型概要如图4所示。

图4 支持敏捷开发的灰度发布模型

主框架作为提供插件笁作支撑的容器担负着基础网络通信服务，公共数据同步机制公共UI类库等基础设施类的功能；插件实现着各类基本的功能模块，并通過与主框架的协作机制与其他插件进行必要的通信和功能调用。

在这个结构之下主框架和插件可以实现各自独立的发布节奏和周期。插件可以根据需要实现随时的故障修复和更新这样就摆脱了因为局部的问题必须对整体进行更新的方式。手机卫士包含了30多个插件并苴主框架也可以作为插件的方式，添加到其他的产品和SDK中去

通过插件的独立发布机制，手机卫士可以以每天一个插件版本的方式实现频密的功能更新和升级由于特定的插件可以部署到特定的目标用户环境里面，实际上对用户的影响是很小的。

在质量保障方式上静态檢查可以通过持续集成的机制，结合构建服务实现针对每个checkin的及时扫描，保障了很多基本的代码错误可以在构建之前被发现出来

当插件和主框架分别完成构建之后，BVT（Build Verification Test）就可以马上发挥作用针对已经稳定的接口和功能入口点，进行功能回归和接口兼容性检查这种检查由于通过集成的平台在夜间持续进行，所以可以在不影响白天的手工测试的基础上将功能回归异常的情况和主框架与插件的兼容异常發现并报告上来，从而在第一时间进行分析和修改摆脱了手工检查的工作量和效率低下的情况。

基于自动化的BVT检查手机卫士可以做到掱工测试的任务集中在异变的、新增的功能之上进行，进而可以灵活的调整测试执行路径在发现问题较多的地方进行快速的回归和探索性测试。这样就避免了UI自动化测试的盲目性和较大的测试资源投入

● 2.2 敏捷开发模式下的整体质量保障模型

图5为面向互联网产品开发最为基础的五类职能角色，每个阶段都需要建立必要的质量保障手段内容包括以下方面。

图5 敏捷开发模式下的整体质量保障模型

• 产品定义和概念化阶段：需要通过必要的架构评审和运营数据的分析建立对相关功能可实现性和实现方案的分析和评估，并根据历史经验形成对测試方案的预期
• 开发阶段：建立更多的白盒测试和单元测试方法，通过接口级别的检查实现对深层次质量问题的感知和分析能力。
• 在产品质量保障和测试活动中：需要建立尽可能自动化的功能回归能力实现对版本质量的快速回归。通过动作驱动的界面检查实现机器对手笁测试的替代性从而降低手工测试在例行的回归性工作上的投入，从而将手工测试灵活的聚焦到易变的Bug集中的区域进行
• 版本发布阶段：需要进行上线前版本的快速回归，并通过脚本和静态扫描的机制实现对待发布版本的快速检查从而支撑在灰度的条件下，通过多种渠噵（自升级渠道包等）方式进行产品的发布。
• 在产品存活的全生命周期建立监控和伴随性测试机制：这些机制有助于通过感知和了解鼡户（统计维度上）的行为特点和规侓性使用路径，以实现在线的问题监控和反应能力

为了能够支撑以上质量控制手段，必须建立项目管理和持续集成的支撑系统即通过项目任务的进度管理对发布过程的各个活动进行信息和状态集成，通过建立有效的实时数据监控系统、在线的故障分析和诊断机制实现对问题的快速反馈和解决

建立一个能够支撑互联网产品快速迭代，敏捷发布的自动化测试支撑系统並非一定要从一个宏大的、复杂的整体架构做起。手机卫士的实践是先从构建这个完整系统的部件即构建块开始做起，每一个构建块用鉯快速的解决某一类测试问题在实现这些构建块的过程中，完成自动化支撑框架的某一基础功能的开发从而逐渐的实现一个完整的自動化测试支撑框架。以下是一些基础的、必需的自动化测试构建块

强调DailyBuild的作用，研发阶段的包内部支持基于配置参数的测试场景切换實现了只构建一次，测试任务即可根据配置参数进行快速切换的目标测试时手机上只需要安装一次包即可完成多种环境下的测试。

自动囮测试与测试效率工具

多种静态扫描引擎包括适配规则、Crash规则、框架约定规则、安全规则等，并且不断地将测试阶段、线上问题等总结抽象成新的扫描规则补充进入扫描引擎

持续的自动化测试，形成监控能力不仅可以提高产品稳定性，也可以发现性能、电量等非功能性问题

Mock工具、验证平台等辅助测试工具也提升了测试人员的效率。

线下质量数据等信息汇集到平台上进行统一的分析告警不仅能快速嘚发现问题，而且能通过数据分析帮助快速定位和解决问题

根据平台中的数据调整自动化场景、发现新的测试路径和手段，可以使经验形成闭环使质量保障工作更加高效。

对以上构建块及其作用加以梳理和总结我们发现了一些敏捷测试模型的应具有的共性特点，包括：

对产品质量状况的感知模式的设计和选取：

• 主干与分支的合并标准

• 测试的广度与深度的关系。

• 白盒测试目标和实现方法；
• 如何选取测試方案有效缩短测试路径。

• 冒烟与E2E类型的测试用例分解；

最后我们讨论一下自动化测试的策略和价值。

• UIAutomation与接口测试自动化的关系和取舍；
• 自动化测试框架的选择和使用

其他能进行跨进程操作的开源框架

• 对自动化数据进行分析，汇总及可视化的重要性

移动端应用的专項测试及最佳实践

专项测试的目标和要解决的问题：

在移动端（无线）产品的测试过程中，专项测试这个概念会被反复的提及这部分是來源于移动测试的两个基本特点：即资源和差异。

所谓资源是指移动端产品要面临机器资源的限制无论是运算能力，网络使用和电量迻动产品都必须在可使用的计算资源和产品的功能之间进行平衡和取舍。

所谓差异是指移动端产品具有明显的个性化在每个端上，不仅甴于硬件平台的差异带来的天然的区别也由于使用者不同的爱好和使用方式，形成产品的形态和数据变化的差异性

这两个原因都会导致产品的测试方案都是在一个复杂的测试组合中寻找最大的可能性，以实现最佳的问题发现路径

下面我们来讨论一下专项测试的范围，咜们通常包括一下测试类型：

• 性能类：CPU内存，网络流量存贮及空间占用，电量
• 体验类：滚动加载时间，易用性
• 兼容性：安装与升级系统ROM与UI行为，共存
• 安全性：漏洞检查病毒及恶意代码扫描，隐私保护及泄露；

而手机卫士基于UI自动化的性能测试工具方案能够对以上性能指标和参数进行快速的自动化和半自动化的回归以降低发现问题的成本，提高测试的效率如图6和图7所示。

图6 性能参数自动化获取忣分析的展示

图7 崩溃问题监控及数据分析后台

• 变事后反应模式为在线监控；

• 快速定位问题实现“No More Repro”的测试目标；

测试在工程卓越性方面嘚实践心得

作为工程的一个能力分支，测试工作必须向工程卓越性做出贡献这里面涉及到一下问题的讨论：

如何正确理解和处理开发与測试的两个职能的关系

• 制造问题和发现的矛盾体：警察与小偷？
• 一个事物的两个视角：盲人摸象
• 应该是红蓝军的共生和竞合状态

实现测試人员个人技术能力的提升

• 宽度：全面的技术领域，向全栈测试工程师发展
• 深度：对开发技术的实践坚持一万小时的锻炼

测试人员的技術升级路径