自动化开发测试的一些理论依据及经验总结(2015)

转载请标明出处，原文地址：http://blog.csdn.net/w565911788/article/details/47660625

【测试深度】

（1）纵向测试，功能性需求->隐藏性需求，前台功能->中间件->后台程序, 接口->协议->代码->架构设计

（2）TDD、DDD、ATDD、BDD、CI：针对设计开发流程的方法论，要求开发人员能从用户的需求出发，具有测试意识，自顶向下良好设计习惯

=> 易混淆：功能深度相关测试点

【测试广度】横向测试，功能、性能、安全、兼容性、可靠性、易用性、数据库

=> 易混淆：功能广度相关测试点

冒烟测试、随机测试、安装测试

本地化测试、国际化测试

白盒测试、黑盒测试、灰盒测试

回归测试、验收测试、接受测试、动态测试

自动化测试、探索测试、深度测试

静态测试、单元测试、集成测试 、系统测试

健全测试、衰竭测试

负载测试、强迫测试 、压力测试 、性能测试

可用性易用性测试、卸载测试 、恢复测试

安全测试、兼容性测试

比较测试、可接受性 、边界条件、等价划分、因果图

强力测试、装配安装 、隐藏数据

基于设计、文档测试 、域测试、接口测试、协议测试

逆向测试、非功能性测试、极限测试

【测试效率（自动化）】自动化测试实施，持续集成，测试工具开发，测试流程、测试架构设计。

测试开发和自动化测试：测试中的开发，开发测试工具、测试脚本，一样需要良好编程习惯、使用框架模型、工具API，是具有自测、持续集成和开发理论意识的测试人员。

=> 提升效率和避免人为过多参与，自动比手动更可靠。（如：我们自动化组约定脚本方法名规范为小写字母加下划线，即便都不会用PascalCase和camelCase但也不能相信人为约定可以完全规范，不如写个脚本在持续集成时检查方法名等规范，不通过就算build failed不进行后续操作，手工review太浪费时间，这就是自动化对效率和可靠性的意义。）

=> 阶段状态：“原始蒙昧(纯手工) => 辅助工具参与 => 高效工具高度参与 => 部分功能过程自动化 => 全面全过程自动化 => 高效高度自动化 => 自优化智能自动化”

【测试的流程】

测试需求分析，然后设计测试方案和制定测试计划，然后进行测试用例设计和具体的测试执行，然后是问题的跟踪解决和测试报告输出。后续：测试总结和改善、历史测试结果的管理和分析挖掘。

【开发过程最常见的两个问题】

（1）需求和开发脱节：

A. 用户想要的功能没有开发

B. 开发的功能并非用户想要

C. 用户和开发人员所说语言不同

=> 解决方案：

A. 使用BDD和ATDD可以解决需求和开发脱节的问题，都是从用户的需求出发，保证程序实现效果与用户需求一致

B. 这个过程可以使用基于BDD的自动化测试工具Cucumber[kjukAmbl]（黄瓜）

（2）开发和测试脱节：

A. 开发和测试被人为割裂

B. 从开发到测试周期过长

C. 测试自动化程度低

=> 解决方案：

A. 开发的"全过程"都要贯穿测试：单元测试，集成测试和系统测试

B. 测试需要自动化

C. 所有测试通过，开发才算完成

D. 持续集成，保证每一次集成系统都能运行

【CI持续集成（ContinuousIntegration）】

（1）持续提交代码(Check-in) ：一天之中多次提交

（2）持续构建代码 (Build)：保证在任何时刻代码是可以继续开发的

（3）持续部署代码(Deploy)：保证始终有一个可以部署的版本

（4）持续测试代码 (Test): 每次提交均执行单元测试，每天一次或数次集成测试, 每天一次或数次系统测试

（5）持续集成工具：Jenkins

【TDD测试驱动开发（Test-DrivenDevelopment）】

（1）测试驱动开发是敏捷开发中的一项核心实践和技术，也是一种设计方法论。TDD的原理是在开发功能代码之前，先编写单元测试用例代码，测试代码确定需要编写什么产品代码。

（2）TDD的基本思路就是通过测试来推动整个开发的进行，但测试驱动开发并不只是单纯的测试工作，而是把需求分析，设计，质量控制量化的过程。

（3）TDD首先考虑使用需求（对象、功能、过程、接口等），主要是编写测试用例框架对功能的过程和接口进行设计，而测试框架可以持续进行验证。（持续集成）

（4）主要针对设计开发流程的方法论，要求具有测试意识、自顶向下良好设计习惯的开发。

【ATDD验收测试驱动开发（AcceptanceTest Driven Development）】

（1）同属于TDD，作为开发人员的职责，通过单元测试用例来驱动功能代码的实现。

（2）在准备实施一个功能或特性之前，首先团队需要定义出期望的质量标准和验收细则，以明确而且达成共识的验收测试计划（包含一系列测试场景）来驱动开发人员的TDD实践和测试人员的测试脚本开发。

（3）TDD基础上更进一步，要求开发人员从用户的需求出发，强调如何实现系统以及如何检验。

【BDD行为驱动开发（BehaviorDriven Development）】

（1）行为驱动开发是一种敏捷软件开发的技术，它鼓励软件项目中的开发者、QA和非技术人员或商业参与者之间的协作。

（2）主要是从用户的需求出发，强调系统行为。BDD最初是由Dan North在2003年命名，它包括验收测试和客户测试驱动等的极限编程的实践，作为对测试驱动开发的回应。

（3）常见工具Rspec、Cucumber等，Cucumber 是一个能够理解用自然语言描述的测试用例的支持行为驱动开发（BDD）的自动化测试工具，用Ruby编写，支持Java和·Net等多种开发语言。

【常见的自动化测试架构（方法论）】

模块驱动测试、数据驱动测试、关键字驱动测试（“表格驱动测试”或“操作名测试”）、混合自动化测试、基于模型测试。

【模块驱动测试】

（1）来源于这样一种编程策略，即屏蔽组件的内部实现，仅提供组件的对外抽象接口。如此下层的测试组件发生变动时，对上层自动化测试案例来说是透明的。

（2）使用独立的小脚本来对应待测试的模块、零件和子功能。这些不同层级的小脚本按照一定规则组合成更大级别的测试，如此就实现了一个特定功能的自动化测试案例。

（3）模块驱动测试引入了抽象和封装的原则，目的是提升自动化测试的可维护性和可扩展性。

【数据驱动测试】

（1）测试脚本与测试数据放在同一个测试架构中，提供可重用的测试逻辑，目的是减少测试维护工作量和改善测试覆盖率。

（2）测试输入数据和测试结果数据都会被存储在一个或者多个数据源、数据库中，数据存储格式和数据组织方式依赖于具体实现。

（3）测试数据与测试逻辑分离，当测试数据发生改变时，不会影响测试逻辑。同一个测试逻辑可以针对不同数据来进行测试，提高了测试逻辑的使用效率和可维护性。

【关键字驱动测试】

（1）也被称为“表格驱动测试”或“操作名测试”，将自动化测试的创建过程分为两个不同的阶段：设计阶段和实现阶段。

（2）设计阶段定义关键字：对象、行为、数据、检查点等。

（3）实现阶段依赖于具体使用的测试工具，自动化测试引擎提供设计阶段定义的关键字，类似于“check”或“enter”，测试人员基于这些关键字来编写测试案例，测试案例执行时会有一个驱动程序来读取这些关键字，并执行相应的代码。

（4）优点：

A、在一个较长软件维护周期内，显著减少维护工作量，使得：测试案例简洁、测试案列可读性高、测试案列易于修改、新的测试案列可以很方便地复用已经存在的关键字

B、关键字可以跨越多个测试案例进行复用。

C、不依赖与某种语言或者某个工具。

D、让员工集中精力在自己所擅长的地方，如：（设计）测试案列的构建需要专业领域知识-而不需要太多编程测试工具知识；（实现）关键字的实现需要丰富的测试工具、编程-而不需要太多的专业领域知识。

E、可以对自动化测试划分抽象层级

（5）缺点：

A.创建自动化测试需要更长的时间

B.需要更长的学习、掌握周期

【混合自动化测试】

（1）该架构由核心数据驱动引擎、功能函数组件，以及支持库所构成，由其他自动化测试框架综合发展起来的，成功的自动化测试框架通常融合了“关键字驱动测试”和“数据驱动测试”。

（2）既拥有测试逻辑与测试数据相互分离的优点，又集成了关键字驱动的先进架构。

（3）这一架构会使得数据驱动脚本更加简洁，并减少运行时意外失败的可能性。

（4）该架构可以实现一些纯粹的“关键字驱动测试”难以实现的自动化测试任务。

【基于模型测试】

（1）目前只适合于功能不太复杂的软件系统，适合于采用“基于模型设计”的软件系统，在这种架构下，会有一个成熟的测试模型来描述测试数据的所有方面，以及测试案例和案例执行环境。通常这一测试模型是全部或者部分从待测试系统功能模型中提取出来的。

（2）测试模型描述了待测试系统的抽象行为，因此从测试模型中可以派生出功能测试案例。这些测试案例构成了抽象测试案例集，不过抽象测试案例集不能直接在待测试系统上执行。

（3）真正可以执行的测试案例集（可以与待测试系统进行交互），是从抽象测试案例集派生出来的。有些基于模型测试的测试工具，支持从模型（包含足够信息）产生可执行测试案例集，

（4）从模型派生出案例，可以有很多种方式，因此测试很多时候是依靠经验去尝试，并没有固定的最佳方法。

（5）需要事先收集“测试需求、测试目标，用户用例"因为他们包含待测试系统模型的信息。测试案例集是从模型而非代码派生出来的，因此基于模型测试可以被视为某种黑盒测试。

【如何提高测试质量】

=> 理论实施：

（1）应用敏捷软件测试等管理方法流程结合CMMI模型、ISO9126模型等对全过程质量进行管理

（2）制定合适的测试流程规范；

（3）制定合理的测试计划；

（4）设计合适的测试方案；

（5）编写的测试用例覆盖到所有的需求；

（6）对测试执行过程进行监控；

（7）使用工具管理测试发现的缺陷；

（8）对缺陷进行统计分析，指导过程改进。

=> 措施：

（1）开展更加深入的测试，功能、接口、协议、白盒、数据库

（2）开展更加全面的测试，功能、性能、安全。。。

（3）更加高效的测试，自动化测试的应用

（4）全团队协作，产品、开发、测试、运维

（5）测试总结和改善、历史测试结果的管理和分析挖掘

=> CMMI能力成熟度模型（20多个过程域，过程改进和能力评估）

（1）连续式：不完整、1已执行、2可重复管理、3已定义、4量化管理级、5优化级

（2）阶段式：初始级、2可重复管理级、3已定义级、4量化管理级、5优化级

=> 经典ISO/IEC9126软件质量模型

（1）三个不同的角度:外部质量、内部质量、使用的质量

（2）质量的6个类型：功能性、可靠性、易用性、效率、可维护性、可移植性

转载请标明出处，原文地址：http://blog.csdn.net/w565911788/article/details/47660625