第六章测试工具及自动化
6.1简介
测试经理在工具和自动化方面必须考虑到得一些一般概念
6.2选择工具
通过成本收益分析来仔细调查该工具在预期使用年限内得所有成本
6.2.1开源工具
在选择开源工具之前，需对测试团队得实际需求进行周密分析
使用开源工具得好处：用户通常可对工具进行修改或扩展
使用开源工具得弊端：修改内容越多，会导致复杂度和花费越高
开源工具得准确性不能被证实，商业工具可以证明其准确性和对特定任务得适用性
6.2.2定制工具
开发定制工具得好处：该工具可满足团队得确切需要，并能在团队所妖气得环境下高效得运行
注！在计划对其他项目发布工具前，先评审使用工具得目的/目标/收益和潜在确定很重要
在考虑开发定制工具时，还必须考虑可能产生得负面问题
定制工具必须有充分得文档以便其他人员能对其进行维护
定制工具也需要进行设计和测试，以保证他们按照预期运行
6.2.3投资回报
引入测试工具对团队有附加值，且为组织带来投资正回报
在购买工具前应进行成本-收益分析
分析中投资回报需考虑重复成本和临时成本，其中一些是费用成本，另一些是资源或时间成本，以及可能降低工具价值得风险
临时成本包括内容：
- 定义对工具的需求以达到目标和目的
- 进行评价和选择正确工具和工具的供应商
- 采购/调整或开发工具
- 进行初始的工具培训
- 将该工具与其他工具集成
- 采购支持工具所需的硬件/软件
重复成本包括得内容：
1.持有工具
许可和支持费用
工具本身得维护费用
由工具创建得工件的维护
持续的培训和辅导
2.将工具移植到不同的环境
3.调整工具以适应未来的需求
4.改进质量和过程确保已选工具的最佳使用
经理在分析投资汇报时，还应当考虑下列风险
- 组织的不成熟（并未准备好使用该工具）
- 该工具创建的工件可能难以维护，需要根据待测软件的改变持续更新
- 减少测试分析师在测试任务中的介入可能降低测试的价值（例如，只运行自动化脚本，可能会降低缺陷发现的有效性）
- 减少重复性工作
- 缩短测试周期（如通过自动化回归测试）
- 降低测试执行脚本
- 增加某些类型的测试（如回归测试）
- 减少不同测试阶段的人为错误，如：
- 使用数据胜场工具生成更有效的测试数据
- 使用比较工具对测试结果进行更准确的比较
- 使用脚本工具输入更正确的测试数据项
- 获取测试信息的工作量减少，如：
- 工具生成的报告和度量数据
- 复用测试资源，如测试用例/测试脚本/测试数据
- 增加没有工具就无法完成的测试（如性能测试/负载测试）
- 测试人员通过实现测试自动化和组织测试，证明自身对复杂工具的理解和应用。从而提升了测试人员的地位
团队获得的总投资回报通常是使用所有工具的作用
工具需要共享信息，共同协作
建立一个长期/全面的测试工具策略
6.2.4选择流程
经理如何选择测试工具：
- 对于业务来说，投资正回报率是必须的
为了能在投资中获得最高价值，组织应当确保这些工具的互操作性--可能包括测试工具和非测试工具的交互操作
在某些情况下，要实现互操作性，必须改善流程和工具使用的衔接能力，这可能需要一段时间来实现
- 对于项目而言，工具必须是有效的（如，在进行人工测试时避免错误，如避免数据输入时的录入错误）
工具可能需要很长时间才能获取投资正回报率
在很多情况下，投资回报可能在第二次版本发布时或维护阶段才出现，而不是在最初实施自动化的项目中
测试经理应当从应用的整个生命周期考虑投资回报
- 对于使用工具的人来说，该工具必须支持项目组成员，让他们更有效/更高效的完成自己的任务
必须考虑学习区县，确保使用者能够在最小的压力下快速的学会使用工具
在初次引入某个测试工具时，需要对使用者进行培训和指导
选择测试工具的流程：
- 评估组织的成熟度/成熟性
- 识别工具的需求
- 评估工具
- 评估供应商或服务支持商（开源工具/定制工具）
- 识别为使用工具进行训练和辅导的内部需求
- 考虑目前测试团队的测试自动化技能，评估培训需求
- 估算成本-收益
对于每个类型工具在哪个测试阶段使用，经理应考虑下列功能
- 分析
- 这个工具是否能”理解“给定的输入
- 工具对于目的是否适用
- 设计
- 此工具是否能根据现有信息帮助设计测试件（例如，根据需求生成测试用例的测试设计工具）
- 能否自动生成设计
- 能否以可维护和可使用的格式生成或部分生成实际的测试件代码
- 能否自动生成必要的测试数据（如：基于代码分析生成数据）
- 数据及测试选择
- 工具如何选择所需数据（如：使用哪组数据执行哪个测试用例）
- 工具能否接受人工或自动输入的选择准则
- 工具能否根据已选的输入来决定如何过滤产品数据
- 工具能否根据覆盖准则来决定需要执行哪些测试（如：提供一组需求后，工具能否顺着可追溯性来决定需要执行哪些测试用例）
- 执行
- 工具能否自动运行，还是需要人工介入
- 工具如何停止和重启
- 工具能否”领会“关联事件（如，当缺陷报告中测试用例已关闭，测试关联软件是否能自动更新测试用例状态）
- 评估
- 工具如何判断它是否收到了合适的结果（如，工具将使用测试准则来决定响应的正确性）
- 工具具备什么样的错误恢复能力
- 工具能否提供充分的记录和报告
6.3工具生命周期
工具的生命周期经理四个阶段，经理需对四个阶段进行管理：
- 获得
工具的获得必须从选择工具开始
在决定引入某个工具后，测试经理应当指定一人（通常是测试分析师或技术测试分析师）来管理工具
此人应当决定工具的使用时机和方式，创建的工件如何存储/明明规则等
应当事前决定好这些内容，而不是等到用工具了临时去决定，做决定的时间不同，最终的投资回报率会有显著的差异
通常需要对工具的使用者进行培训
- 支持和维护
需要对工具进行持续的支持和维护
维护工具的责任也许在工具管理员身上，或是分配到一组特定的工具团队上
如果工具需要与其他工具一起运行，那么应考虑数据交换和合作进行
还需要考虑工具的备份/恢复和输出
- 演变
必须考虑到转换
随着时间的推移，环境/业务需求或供应商问题都可能要求对工具本身或其用途进行大的改动。如，工具供应商也许会要求对工具进行更新，但这可能导致与其他工具合作的的问题
由于业务原因导致必要的环境变动也可能会导致工具的问题
工具的运行环境越复杂，变更越会破坏其作用
根据工具在测试中扮演的角色，测试经理也许需要组织在出现突发事故时能保证服务的连续性
- 退役：
工具总有它的使用寿命
工具所支持的功能需要被替代，数据需要进行保存和归档，当一个工具步入生命周期的尽头时，转换到新工具的机会和收益已经超越了成本和风险时，它将会退役
6.4工具度量
测试经理可设计和收集客观的度量
度量信息来自于技术测试分析师和测试分析师
不同的工具可捕捉宝贵的实时数据，又能减少数据收集的工作量
测试经理可使用这些数据来管理整体的测试工作
不同的工具侧重于不同类型数据的收集，如：
- 测试管理工具可提供多种度量
从需求到测试用例及自动化脚本的可追溯性允许进行覆盖范围的度量
任何时间都可获取目前可用的测试/计划的测试及当前执行的状态（通过/失败/跳过/中断/排队中）的快照
- 缺陷管理工具可提供关于缺陷的丰富信息：目前状态/严重度和优先级/在系统中的分布等
其他富有启发性的数据如缺陷的引入和发现阶段/缺陷逃脱率等，能帮助测试经理推动过程改进
- 静态分析工具可发现和报告可维护性问题提供帮助
- 性能工具可提供在系统可扩展性方面有价值的信息
- 覆盖工具可帮助测试经理链接系统实际进行过测试的比例
应该再工具的选择过程中就定义工具的报告需求
这些需求必须再工具配置过程中恰当的实现来确保通过工具追踪的信息能以干系人易理解的方式进行汇报
第六章需要掌握知识点
6.2工具的选择
- 描述选择开源工具时需要考虑的管理问题
- 描述决定定制工具时需要考虑的管理问题
- 对一个给定的情况作出评估，来指定选择工具的计划，包括风险/成本和收益
6.3工具生命周期
阐述一个工具生命周期的不同阶段
6.4工具度量
阐述如何通过使用工具来改进度量的收集和评估