软件测试技术教程 教学课件 作者 徐光侠 韦庆杰 第十章 软件测试自动化.pptVIP

软件测试自动化 概 况 10.1 手工测试与自动测试 10.2.1 自动测试的周期 6.6 单元测试环境 6.6 单元测试环境 在讨论W字模型时，不能将其解释为出现在特定阶段内的所有活动都应该同时开始和结束。例如，图10-2中的“设计”、“测试设计”、“自动测试设计”和“针对测试包的测试设计都出现在同一个阶段(在图中并排给出)。针对产品和自动测试的这些活动可以在不同时间开始和结束。W字模型只是保证活动的流程，并没有限定起止时间。产品开发和自动测试可以有独立的进度计划，并作为两个不同的项目进行处理。 不需要同时开始和结束的另一个理由是，在很多公司中，要由同一个测试团队测试产品和开发测试包。在这种情况下，显然进度是不同的，活动的起止时间取决于由可用的资源和其他依赖关系决定的项目进度。 对于公司内有专门的自动测试团队的情况，自动测试进度可以独立于产品的发布。每次产品发布对应一些(经过测试的)可交付产品。这样，可以使用最新开发的测试包测试产品的当前发布版本。 10.2.2 自动测试的成本 10.2.3 合理选择自动测试的导入时机 10.3 自动测试的方案选择  10.3.1 确定自动化的对象和范围          在产品开发过程中，需求的变更是很常见的。对于这种情况，要自动化的对象是很容易确定的。自动化应该考虑需求不变或没有变更的部分。需求变更一般会影响场景和新特性，不会影响产品的基本功能。在自动化时，要首先考虑产品的这类基本功能，以便用做“回归测试”和“冒烟测试”的基础 。 有些类型的测试本身自动进行自动化。例如：压力、可靠性、可伸缩性和性能测试这些类型的测试要求在大量不同的计算机上以一定的持续时间运行测试用例，比如48小时等。让数百个用户天天使用产品简直就是不可能的，他们既不愿意承担重复性工作，也不可能找到那么多有所需技能的人群。属于这些类型测试的测试用例是自动化的第一候选者。 回归测试是重复性的。这些测试用例在产品开发各个阶段要执行多次。由于这些测试用例具有重复性，因此自动化从长远看会显著节省时间和工作量。此外，正如本章已经提到过的，所节省的时间可以有效地用于即兴测试和其他更具创造性的测试。 功能测试这类测试可能需要复杂的设置，因此可能需要当前还没有普遍具备的特殊技能。利用专家的技能一次性自动化这些测试用例，使技能不那么高的员工也可以马上运行这些测试用例。 在产品开发场景中，很多测试需要重复，如果考虑了定期增强和维护发布版本，好的产品会有很长的生命期。这就提供了自动化测试用例在发布周期内多次执行的机会。根据一般经验，如果测试用例在不久的将来，比方说一年内需要执行至少10次，如果自动化工作量不超过执行这些测试用例的10倍，那么就可以考虑自动化这些测试用例。当然，这只是根据经验，具体选择哪些测试用例还有很多因素需要考虑，例如是否具备所需的技能、在强大的发布日期压力下是否有设计自动化测试脚本的时间、工具的成本、是否有所需的支持等。 作为自动化范围的总结，就是要选择自动化那些能够以最少的时间延迟换得最大投回人报的工作。 在开始自动化前，需要花很大的精力取得管理层的承诺。自动化一般要耗费大量工作量，也并非一次性活动。自动化的测试用例还需要维护，直到产品退出市场。由于开发和维护自动化工具需要大量的工作量，因此取得管理层的承诺是一项很重要的活动。由于自动化在很长时间内都需要投入，因此管理层的批准是按阶段按部分进行的。所以，自动化工作应该集中于已经存在管理层承诺的区域。 投入回报也是需要认真考虑的一个方面。自动化工作量估计要向管理层提供预期投入回报的明确结论。在启动自动化时，关注点应该放在好的排列组合区域上。这使自动化能够用较少的代码覆盖较多的测试用例。另外，自动化应该首先考虑需要较短时间，易于自动化的测试用例。有些测试用例没有能够预先确定的预期结果，这类测试用例需要很长时间自动化，应该放在自动化的后期阶段。这可以满足管理层寻求自动化快速投入回报的要求。 为了符合“重要事情优先做”的原则，重要的是要首先自动化产品的关键和基本功能。为此，所有测试用例都要根据客户预期分为高、中、低优先级，自动化要从高优先级的测试用例入手，然后覆盖中、低优先级需求的测试用例。 10.3.2 选择自动测试的方案和脚本编写方法 采用什么样的自动化测试方案，需要考虑以下几个方面的因素： ●项目的影响：自动化测试能否对项目进度、覆盖率、风险有积极的作用，或者让开发更敏捷？ ●复杂度：自动化是否容易实现（包括数据和其他环境的影响）？