我之前写过几篇原创的关于自动化测试的思考和总结,今天整理资料的时候发现这篇文档,涉及到实施自动化测试的切入,自动化测试的适应范围,自动化测试的环境,自动化测试的开展,甚至自动化测试的风箱评估等等,这篇文档系统的阐述了这些重要内容,给自动化测试的开展提供了一些理论方面的指导,跟我的前面几篇文档有异曲同工之处,可以做为一个补充和参考.
软件测试自动化，从计算机这一庞大学科发展至今，最根本的意义是解决手工劳动的复杂性，成为替代某些重复性行为模式的最佳工具。
1. 提高测试效率和降低测试成本
2. 将重复性强的测试由手工转为可以独立开来自动实现的。
3. 实现快速的回归测试，提高新版本发布的速度和质量，尤其是不能适应目前流行的迭代开发，回归测试频度高、工作量大，人工的测试很难对新的迭代版本作出快速评估。
4. 自动测试可以避免，人工测试容易犯的错误：错误测试、漏测试、多测试和重复测试等
5. 典型的应用，例如多用户并发注册、并发交易请求和并发交易应答，这种情况用人工测试几乎是办不到的，而自动测试却很容易。
6. 对于很常用的功能性边界测试测试，人工测试非常耗费时间，而自动测试很快且准确。
可以说，实施测试自动化是软件行业一个不可逆转的趋势，如果在这个领域走在了前列，无论从企业的核心竞争力还是个人的工作技能来说，都有巨大的优越性。
自动化测试能大大降低手工测试工作，但决不能完全取代手工测试。完全的自动化测试只是一个理论上的目标，实际上想要达到 100% 的自动化测试，不仅代价相当昂贵，而且操作上也是几乎不可能实现。一般来说，一个 40-60% 的利用自动化的程度已经是非常好的了，达到这个级别以上将过大的增加测试相关的维护成本。
测试自动化的引入有一定的标准，要经过综合的评估，绝对不能理解成测试工具简单的录制与回放过程。实际上，从实现成熟度来说，自动化测试分五个级别：
| 级别 | 说明 | 优点 | 缺点 | 用法 |
| 一级 | 录制和回放 | 自动化的测试脚本能够被自动的生成，而不需要有任何的编程知识 | 拥有大量的测试脚本，当需求和应用发生变化时相应的测试脚本也必须被重新录制 | 当测试的系统不会发生变化时，实现小规模的自动化 |
| 二级 | 录制、编辑和回放 | 减少脚本的数量和维护的工作 | 需要一定的编程知识；频繁的变化难于维护 | 回归测试时，用于被测试的应用有很小的变化 |
| 三级 | 编程和回放 | 确定了测试脚本的设计，在项目的早期就可以开始自动化的测试 | 要求测试人员具有很好的软件技能，包括设计、开发 | 大规模的测试套件被开发、执行和维护的专业自动化测试 |
| 四级 | 数据驱动的测试 | 能够维护和使用良好的并且有效的模拟真实生活中数据的测试数据 | 软件开发的技能是基础，并且需要访问相关的测试数据 | 大规模的测试套件被开发、执行和维护的专业自动化测试 |
| 五级 | 使用动作词的测试自动化 | 测试用例的设计被从测试工具中分离了出来 | 需要一个具有工具技能和开发技能的测试团队 | 专业的测试自动化将技能的使用最优化的结合起来 |
自动化测试能提高测试效率，快速定位测试软件各版本中的功能与性能缺陷，但不会创造性的发现测试脚本里没有设计的缺陷。测试工具不是人脑，要求测试设计者将测试中各种分支路径的校验点进行定制,没有定制完整，即便事实上出错的地方，测试工具也不会发觉。因此，制订全面、系统的测试设计工作是相当重要的。
自动化测试能提高测试效率，但对于周期短、时间紧迫的项目不宜采用自动化测试。推行自动化测试的前期工作相当庞大，将企业级自动化测试框架应用到一个项目中也要评估其合适性，因此决不能盲目的的应用到任何一个测试项目中，尤其不适合周期短的项目，因为很可能需要大量的测试框架的准备和实施而会被拖跨。
实施测试自动化必须进行多方面的培训，包括测试流程、缺陷管理、人员安排、测试工具使用等。如果测试过程是不合理的，引入自动化测试只会给项目团队带来更大的混乱。
那么应该具备什么样的条件才可以引入自动化测试呢，才可以最大可能的减少引入风险，并能够可持续性的开展下去呢？
第一，从项目规模上来说，没有严格限制。无论项目大小，都需要提高测试效率，希望测试工作标准化，测试流程正规化，测试代码重用化。所以第一要做到的，就是从公司高层开始，直到测试部门的任何一个普通工程师，都要树立实施自动化测试的坚定决心，不能抱着试试看的态度。一般来说，一个这样的软件开发团队可以优先开展自动化测试工作：测试与开发人员比例合适，比如1：3到1：5，开发团队总人数不少于10个。
第二，从公司的产品特征来说，一般开发产品的项目实施自动化测试要比纯项目开发要优越些。但决不是说做纯项目开发不能实施自动化测试，只要软件的开发流程、测试流程、缺陷管理流程规范了，自动化测试自然水到渠成。
第三，从测试人员个人素质和角色分配来说，除了有高层重视外，还应该有个具有良好自动化测试背景和丰富自动化测试经验的测试主管，不仅在技术方面，更重要的是在今后的自动化测试管理位置起着领导的作用。还要有几个出色的开发经验良好的测试人员，当然也可以是开发工程师，负责编写测试脚本、开发测试框架,还有一些测试执行者，他们要对软件产品业务逻辑相当熟练，配合测试设计者完成设计工作，并在执行自动测试时，敏锐的分析和判断软件缺陷。
综合分析上述三个条件，就可以决定是否推行自动化测试；但是为了减少实施风险，还要预测到其他潜在的风险，做好事先解决问题规避风险的思路。
资金风险，虽然有些项目具备实施自动化测试的条件，但还是要引入自动化测试后组织结构调整等方面的成本估算是很必要的。
自动化测试对软件功能类型的切入点的风险，开发的产品业务和功能是否需要自动化测试？包括白盒自动化测试、功能自动化测试和性能自动化测试。
软件自动化测试切入方式的风险，一定要将自动化测试与手工测试结合起来使用，不合理的规划会造成工作事倍功半。首先，对于自动化测试率的目标开始是 20/80 （20% 的自动化测试和 80% 的手工测试），当这些目标都实现了，再将自动化测试率提高。
时间估算，在评估完前面几项指标后，需要估算实施测试自动化的时间周期，以防止浪费不必要的时间，减少在人员、资金、资源投入上的无端消耗。虽然到测试自动化步入正轨以后，会起到事半功倍的效果，但前期的投入巨大，要全面考虑各种因素，明确实施计划并按计划严格执行，才能最大限度降低风险。
工作流程变更风险，测试团队乃至整个开发组织实施测试自动化，或多或少会因为适应测试工具的工作流程，带来团队的测试流程、开发流程的相应变更，而且，如果变更不善，会引起团队成员的诸多抱怨情绪；所以应该尽量减少这种变更，并克服变更中可能存在的困难。
五、什么条件下使用自动化测试
一般在这样的条件下使用自动化测试
l 具有良好定义的测试策略和测试计划（知道要测试什么，知道什么时候测试）
l 对于自动化测试你拥有一个能够被识别的测试框架和候选者
l 能够确保多个测试运行的构建策略
l 多平台环境需要被测试
l 拥有运行测试的硬件
l 拥有关注在自动化过程上的资源
如下条件下是宜采用手工测试：
l 没有标准的测试过程
l 没有一个测试什么、什么时候测试的清晰的蓝图
l 在一个项目中，测试责任人是一个新人，并且还不是完全的理解方案的功能性和或者设计
l 整个项目在时间的压力下
l 在团队中没有资源或者具有自动化测试技能的人
| 测试阶段 | 描 述 | 备 注 |
| 单元测试/ 组件测试 | 这个测试工作通常是开发人员的职责，很多不同的方法能够被使用，比如"测试先行"，它是一个测试框架，开发人员在编写代码前编写不同的单元测试，当测试通过时，代码也被完成了。 | 通过使用正式的单元测试，不仅能够帮助开发人员产出更加稳定的代码，而且能够是软件的整体质量更加的好。 |
| 集成测试 | 这里的测试工作集中在验证不同的组件之间的集成上。 | 这种类型的测试通常是被测试系统的更加复杂测试的基础，大量的边缘测试被合并以制造出不同的错误处理测试。 |
| 系统测试 | 这种测试是通过执行用户场景模拟真实用户使用系统，以证明系统具有被期望的功能。 | 这里不需要进行自动化的测试。安装测试、安全性测试通常是有手工完成的，因为系统的环境是恒定不变的。 |
| 其它两种非常重要的测试 | ||
| 回归测试 | 回归测试实际上是重复已经存在的测试，通常如果是手工完成的化，这种测试只在项目的结尾执行执行一到两次。 | 这里完全有潜力应用自动化的测试，能够在每次构建完成后执行自动化的回归测试，以验证被测试系统的改变是否影响了系统的其他功能。 |
| 性能测试 | 性能测试包括以下不同测试形式： - 负载测试 | 使用自动化的测试工具，通过模拟用户的负载实现的高密集度的性能测试。 |
0 Comments:
Post a Comment