转载请标明出处，原文地址：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等多种开发语言。
【常见的自己主动化測试架构（方法论）】
模块驱动測试、数据驱动測试、keyword驱动測试（“表格驱动測试”或“操作名測试”）、混合自己主动化測试、基于模型測试。
【模块驱动測试】
（1）来源于这样一种编程策略，即屏蔽组件的内部实现。仅提供组件的对外抽象接口。如此下层的測试组件发生变动时，对上层自己主动化測试案例来说是透明的。
（2）使用独立的小脚本来相应待測试的模块、零件和子功能。
这些不同层级的小脚本依照一定规则组合成更大级别的測试，如此就实现了一个特定功能的自己主动化測试案例。
（3）模块驱动測试引入了抽象和封装的原则，目的是提升自己主动化測试的可维护性和可扩展性。
【数据驱动測试】
（1）測试脚本与測试数据放在同一个測试架构中，提供可重用的測试逻辑，目的是降低測试维护工作量和改善測试覆盖率。
（2）測试输入数据和測试结果数据都会被存储在一个或者多个数据源、数据库中。数据存储格式和数据组织方式依赖于详细实现。
（3）測试数据与測试逻辑分离，当測试数据发生改变时。不会影响測试逻辑。
同一个測试逻辑能够针对不同数据来进行測试，提高了測试逻辑的使用效率和可维护性。
【keyword驱动測试】
（1）也被称为“表格驱动測试”或“操作名測试”，将自己主动化測试的创建过程分为两个不同的阶段：设计阶段和实现阶段。
（2）设计阶段定义keyword：对象、行为、数据、检查点等。
（3）实现阶段依赖于详细使用的測试工具，自己主动化測试引擎提供设计阶段定义的keyword。类似于“check”或“enter”，測试人员基于这些keyword来编写測试案例。測试案例运行时会有一个驱动程序来读取这些keyword，并运行对应的代码。
（4）长处：
A、在一个较长软件维护周期内。显著降低维护工作量。使得：測试案例简洁、測试案列可读性高、測试案列易于改动、新的測试案列能够非常方便地复用已经存在的keyword
B、keyword能够跨越多个測试案例进行复用。
C、不依赖与某种语言或者某个工具。
D、让员工集中精力在自己所擅长的地方，如：（设计）測试案列的构建须要专业领域知识-而不须要太多编程測试工具知识；（实现）keyword的实现须要丰富的測试工具、编程-而不须要太多的专业领域知识。
E、能够对自己主动化測试划分抽象层级
（5）缺点：
A.创建自己主动化測试须要更长的时间
B.须要更长的学习、掌握周期
【混合自己主动化測试】
（1）该架构由核心数据驱动引擎、功能函数组件，以及支持库所构成，由其它自己主动化測试框架综合发展起来的。成功的自己主动化測试框架通常融合了“keyword驱动測试”和“数据驱动測试”。
（2）既拥有測试逻辑与測试数据相互分离的长处，又集成了keyword驱动的先进架构。
（3）这一架构会使得数据驱动脚本更加简洁。并降低执行时意外失败的可能性。
（4）该架构能够实现一些纯粹的“keyword驱动測试”难以实现的自己主动化測试任务。
【基于模型測试】
（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
