讲究竟什么敏捷测试海量资源

本文由简悦SimpRead转码，原文地址2013年，在本文由简悦SimpRead转码，原文地址2013年，在InfoQ发表了相同标题的文章，但这篇文章是全新而作。在回答“究竟什么是敏捷测试”之虽然我听不到你的回答，但还是先提醒你回忆一下著名的敏捷宣言和12项敏捷开发原则，带着这些回合敏捷价值观，哪些又违反了敏捷开发原则，最后我们一起来分析案例，并回答“究竟什么是敏捷测试”这个案例来自一家国内的公司，这家公司的产品主要是基于Android系统的智能终端。故事发生在年前，即2013先给大家介绍一下案例背景，公司的软件研发部门下属有四个开发部门和一个庞大的测试部门，其中，一个负责各种研发工具开发的部门也隶属于测试部门。开发人员和测试人员比例几乎是1:1，开发部门的职责是按照负责的功能模块划分的，而测试部门负责软件系统级别的所有测试，包括功能测试、性能测试、安全性测试、可靠性测试、兼容性测试等。当时采用的是传统的瀑布式开发模式，即V码编写和产品测试被明确地分成了两个阶段，如图1所示：1V1.这里所用到的工具包括：分布式的代码版本控制工具Git+代码审查工具Gerrit+持续集成工具Jenkins+自研的基于MonkeyRunner的自动化测试框架。基于Git+Gerrit+Jenkins，开发部门已经过程中，工具链没有问题，自动构建和自动部署也没有问题，问题就出在自动化测试上。一个产品的手工测试用例大概是1000个，但是能转化为自动化脚本并且放在集成环境里执行的用例，在很长时间内只有100多个，只实现了版本验证，即我们通常所说的“冒烟测试”员提交代码，触发的自动化测试达到的覆盖率非常有限，即使这个集成环境能够支持持续验证，所有人都觉得很鸡肋。就是边开发边测试，期望通过这个缩短产品开发周期。就是边开发边测试，期望通过这个缩短产品开发周期。开发部门按照ScrumTeam进行划分，按照3:1的比例招聘了测试工程师。一开始没想明白他们到底需他们在Scrumeam里的主要工作包括：手工测试；一遍遍按照开发的要求复现bug；给开发人员打位或者软件集成到一起不工作时，手工测试则没法进行。多了，无非体现在报的bug多了，测试部门看重的是需求的覆盖率，人自然减不下来。所以，在一次改组中，领导宣布所有的测试人员都转到测试部门，要求测试部门减掉相应数量的测试外包。Scrumeam可以向测试部门要求按3:1的比例配备测试人员。测试部门能够了解Scrumeam测试范围，减少了重复测试。改组之后，人数倒是减下来了，但是仍然以手工测试为主，因为组织架构的变更，开发和测试经常因为谁对开发阶段的测试说了算而争论不休，开发和测试变得更加泾渭分明，关系更紧张了。开发部门。良好的转变是：每个Scrumeam开始由一名资深测试工程师担任estOwner，负责制定程师进行开发能力的培养。一开始单元测试的覆盖率几乎是0，开发人员只管写代码和修复测试人员提交的缺陷。由于持续集成和果。开发也答应做，但是整整一年未见成效，原因是：忙，没有单元测试的经验和技能。测试部门意识到自动化的重要性，但是部门只有5%意采取末位淘汰制替换10%式，在一年之后自动化测试工程师的比例终于达到了25%化测试在API和UI测试的覆盖率终于看到明显提高，但是在整体需求覆盖率上也没有超过30%，而且单元测试的缺失依然是硬伤，没有开发人员的参与，测试总在UI层折腾，当然是事倍功半。敏捷测试的彼岸，更不用说，产品的质量和测试的效率得到显著的提升。那究竟什么是敏捷测试呢？可以肯定的是，“敏捷测试”是为了适应敏捷开发而特别设计的一套完整的软件测试解决方案。这个解决方案应该能够支持持续交付，涵盖所需的、正确的价值观、思维方式、测试流程、一系列优秀的测试实践和更合适的测试环境、自动化测试框架和工具。敏捷测试可以采用目前已有的各种测试方式、方法，以及传统测试相比侧重有敏捷测试应该具有“敏捷宣言”所倡导的价值观，为此我们可以按照“敏捷宣言”的格式，写出如下的“敏与开发协作测试胜于测试分工与测试工具可运行的测试脚本胜于写在纸上的测试用例从客户角度来理解测试需求胜于从已定义的需求来判定测试结果基于上下文及时调整测试策略胜于遵守测试计划敏捷测试强调“敏捷测试应该具有“敏捷宣言”所倡导的价值观，为此我们可以按照“敏捷宣言”的格式，写出如下的“敏与开发协作测试胜于测试分工与测试工具可运行的测试脚本胜于写在纸上的测试用例从客户角度来理解测试需求胜于从已定义的需求来判定测试结果基于上下文及时调整测试策略胜于遵守测试计划敏捷测试强调“与开发协作”、“自动化测试”、“客户思维”和“动态的测试策略调整”那我们回过头来，再看看上面的案例，至少第1、2条，他们没做到：测试人员没有得到足够的重视和“没有开发人员的参与，测试总在UI层折腾，当然是事倍功半”“触发的自动化测试达到的覆盖率非常有限人员不合格。在执行过程中，缺乏测试策略，没有强调从客户的需求出发和动态地调整测试策略。敏捷开发还有1212发的基本要求，例如：如何支撑或协助“持续不断地、尽早交付有价值的软件如何拥抱变化——“欣然面对需求变化，即使在开发后期也一样开发，并和开发紧密协作，测试才不会成为敏捷开发的“绊脚石”。基于敏