敏捷测试的必由之路...

敏捷测试的必由之路敏捷测试的必由之路敏捷测试的必由之路敏捷测试的必由之路

分层测试分层测试分层测试分层测试

@吴穹Adam

© 2011 Agilean China

内容提要

• 正确的质量观


质量观

• 质量是开发人员的神圣责任，而不仅仅是测试人员

的责任

–The burden of quality is on the shoulders of

those writing the code. Quality is never “some

tester’s” problem.

• 只有将开发和测试完全地混合在一起，不分彼此，

才能够真正获得好的质量

–Quality is achieved by putting development and

testing into a blender and mixing them until one

is indistinguishable from the other.


内容提要


• 什么是分层测试

© 2011 Agilean China 5

分层测试的基本思想 - 净水器模型

开发测试

风险1 风险2 风险3 风险4

集成测试

验收测试

• 为什么要分层测试为什么要分层测试为什么要分层测试为什么要分层测试？？？？

–分层才能保证快速反馈分层才能保证快速反馈分层才能保证快速反馈分层才能保证快速反馈，，，，而不是都等到最后才反馈而不是都等到最后才反馈而不是都等到最后才反馈而不是都等到最后才反馈

–恰当的分层测试可以降低总测试成本恰当的分层测试可以降低总测试成本恰当的分层测试可以降低总测试成本恰当的分层测试可以降低总测试成本


内容提要



• 分层测试案例一 – 谷歌如何分层测试


测试类型

• 小测试

– Small tests cover a single code unit in a completely faked environment.

• 中测试

– Medium tests cover multiple and interacting code units in a faked or real

environment.

• 大测试

– Large tests cover any number of code units in the actual production environment with

real resources.


测试类型


测试类型


测试类型

• 谷歌采用70/20/10原则: 70% 小，20% 中，10% 大

–Projects at Google are encouraged to maintain a healthy

mixture of test sizes among their various test suites.

–Overinvesting in end-to-end automation often ties you to a

product’s specific design


内容提要




• 分层测试案例二 – 企业信息系统如何测试


.do

.screen

ModelAndViewHttpServletRequestHttpServletResponse

Web层层层层

Action

XXXController

DataBinder&Validator

DispatcherServlet

web-context.xml ApplicationController

biz-context.xml

Service

BO

业务层业务层业务层业务层EJB Call

DAO

sqlmap-config.xmlsqlmap-mapping.xml

Oracle

集成层集成层集成层集成层

Package

SAO

外部系统外部系统外部系统外部系统

EJB Call

Quartz Job

风险分析

No need to testSimpleLogic

ComplexLogic

Config Files

ViewResolver

View(*.jsp)


分层测试策略(例子）

开发者测试（DT）单领域测试

（IDIT）

集成测试

（AT）

测试粒度 Service, Package,

Job,…单个子系统多个子系统

关注的风

险

一个模块内的逻辑功

能错误

单个子系统的功能

是否正确

多个子系统的集成

问题

执行环境开发者本机开发集成测试环境 Staging环境

测试类型 Out-Container In-Container In-Container

数据库 N/A 测试数据类生产数据


ViewResolver

View(*.jsp)

.do

.screen


Web层层层层

Action

XXXController


DispatcherServlet

web-context.xml ApplicationController

biz-context.xml

业务层业务层业务层业务层EJB Call


Oracle


Package


EJB Call

Quartz Job

针对Service的开发者测试（方案一、 MockDB方案）


ComplexLogic

Config Files

Service

BO

DAOSAO

OtherService


.do

.screen

Quartz Job

单领域验收测试


ComplexLogic

Config Files

Oracle

Package



biz-context.xml

业务层业务层业务层业务层



Web层层层层

XXXController


DispatcherServlet

web-context.xml

Service

BO

SAO DAO

EJB Call

Action

ApplicationController

EJB Call

ViewResolver

View(*.jsp)


.do

.screen

Quartz Job

跨领域验收测试


ComplexLogic

Config Files

Oracle

Package



biz-context.xml

业务层业务层业务层业务层



Web层层层层

XXXController


DispatcherServlet

web-context.xml

Service

BO

SAO DAO

EJB Call

Action

ApplicationController

EJB Call

ViewResolver

View(*.jsp)


内容提要





• 分层测试中的关键技术难点

–开发者测试当中的难点


开发者测试的难点

• 开发者测试的难点在于测什么，其次才是怎么测？

–问题1：什么是合适的被测单元？

–问题2：如何找到合适的被测单元？

–问题3：如何提高被测单元的可测试性？

–问题4：何时停止开发者测试？


问题1：什么是合适的被测单元？

• 开发者测试的常见误区

–对最小单元进行测试

• From Wikipedia:

–A unit is the smallest testablesmallest testablesmallest testablesmallest testable part of an application.

In procedural programming a unit may be an individual

function or procedure.


开发者测试的基本思想

• 针对易于测试的单元，模拟所有输入值所有输入值所有输入值所有输入值，检查所有输出所有输出所有输出所有输出是

否符合预期

• 测试用例基本格式:

–构造测试输入值；

–驱动被测对象执行；

–对比返回值和期望返回值；

被测对象被测对象被测对象被测对象

输入输入输入输入输出输出输出输出

属性属性属性属性属性属性属性属性

输出输出输出输出输入输入输入输入

其他方法其他方法其他方法其他方法


开发者测试的成本曲线

• 启示

–开发者测试粒度并非越小越好；

–开发者测试粒度过小，将导致打桩成本急剧提升，迫使开发人员偷

工减料（省略打桩，忽略输出检查），导致开发者测试名存实亡；

–因此，找到正确粒度的单元是开发者测试成功的第一步。

工

作

量

工

作

量

工

作

量

工

作

量

单元小单元小单元小单元小小小小小

打桩成本打桩成本打桩成本打桩成本成本成本成本成本

甜点甜点甜点甜点


问题1：什么是合适的被测单元？

• 软件工程的万有定律

–高内聚高内聚高内聚高内聚、、、、低耦合低耦合低耦合低耦合

• 适合测试单元的标准：

–高内聚、低耦合

–由1-3个开发人员完成，最好是1个

–不直接访问网络、数据库、文件系统；


问题2：如何找到合适的被测单元？

• 开发者和架构师一起，从完整系统角度一起找到合适的测

试目标


问题2：如何找到合适的被测单元？

• 开发者测试的困境实际上是架构的困境

–在许多组织中，架构往往停留在概念层面；

–实现往往与这个概念架构严重脱节；

–开发人员无法获得帮助以确定适当的模块以便进行测试；


25

问题3：如何提高被测单元的可测试性？

• 为了保证开发者测试成功，许多系统需要进行必要的重构

Very difficult to test This is much easier to test

If you cannot do unit testing, it means there is something wrong with the structure


问题4：何时停止开发者测试？

• 覆盖率分析是开发者测试的指路明灯，利用覆盖率分析来

改进开发者测试用例


问题4：何时停止开发者测试？

• 不要忙目追求开发者测试的覆盖率指标，应关注综合覆盖

率指标

• 主要逻辑风险被有效覆盖即可停止开发者测试


开发者测试的若干最佳实践

• 必须Assert所有有效输出，这样才能保证开发者测试的有

效性；

• 为了能够Assert输出，需要初始化必要的输入值，注意输

入也可能来自数据库，外部系统等，因此，可能需要Mock

技术进行隔离；

• 开发者测试用例需要做到彼此独立，一个失败不影响别的

测试用例；

• 应使用Junit 4、TestNG的参数化测试技术或Feed4J来分离

测试数据和测试流程；


单领域验收测试的难点

• 单领域验收测试的难点在于：

–问题1：如何编写出可维护的测试用例？

–问题2：如何隔离外部系统？

–问题3：如何控制数据库输入？

–问题4：何时结束单领域验收测试？


内容提要







–单领域验收测试的难点


问题1：如何编写出可维护的测试用例？

• 如何编写出可维护的测试用例是基于界面的验收测试所必

须解决的问题！

–首先，最好选择一个好用的测试框架，测试框架可以封装一些测试

人员不需要关注的细节，使他们可以更关注于测试本身；

–其次，测试用例的分层是实现可维护性的有效手段；


问题1：如何编写出可维护的测试用例？

• 测试框架是一条捷径

–定义一种统一的方式来书写和组织测试用例（测试步骤，测试数

据与期待返回值）；

–集成不同的测试驱动技术,屏蔽测试驱动技术的细节；

–控制测试用例的执行过程；

–生成测试报告和测试日志；


测试用例的层次架构（实例）

测试用例测试用例测试用例测试用例 =测试流程模板 + 测试数据

测试流程模板测试流程模板测试流程模板测试流程模板 =测试流程构件的排列

测试流程构件测试流程构件测试流程构件测试流程构件 =测试流程步骤的排列

测试流程步骤测试流程步骤测试流程步骤测试流程步骤 =界面交互细节

• 分层实现的测试案例可以真正做到消除测试用例当中的分层实现的测试案例可以真正做到消除测试用例当中的分层实现的测试案例可以真正做到消除测试用例当中的分层实现的测试案例可以真正做到消除测试用例当中的

冗余冗余冗余冗余，，，，屏蔽实现细节屏蔽实现细节屏蔽实现细节屏蔽实现细节，，，，使测试用例易于维护使测试用例易于维护使测试用例易于维护使测试用例易于维护；；；；


问题2：如何隔离其他外部系统？用Mock系统！

1. Mock系统还是针对一个接口的

2. Mock系统需要提供一个途径允许测试

用例远程创建一个Mock对象，Mock对

象的创建由内置的Mock框架提供

3. Mock系统需要提供一个途径允许测试

用例远程调校一个Mock对象，具体调

校行为由内置的Mock框架提供，Mock

系统主要是转发

测试用例测试用例测试用例测试用例

接口接口接口接口

Mock系统系统系统系统

被测系统被测系统被测系统被测系统

2.2.2.2.创建创建创建创建

3.3.3.3.调较调较调较调较

6.6.6.6.检测结果检测结果检测结果检测结果

4.4.4.4.注入注入注入注入

5.5.5.5.测试测试测试测试

调用调用调用调用


问题2：如何隔离其他外部系统？用Mock系统！

4. 将Mock系统注入被测系统

• 在EJB之间不需要直接注入，主要是在

JNDI里面用Mock系统来替代被Mock的

系统即可

5. 执行测试

6. 检测结果

• Mock系统需要提供一个途径允许测试

用例远程激活Mock框架的检测功能，

检测预期是否达成，不达成则可以在

本地抛出异常

测试用例测试用例测试用例测试用例

接口接口接口接口

MockMockMockMock系统系统系统系统

被测系统被测系统被测系统被测系统

2.2.2.2.创建创建创建创建

3.3.3.3.调较调较调较调较

6.6.6.6.检测结果检测结果检测结果检测结果

4.4.4.4.注入注入注入注入

5.5.5.5.测试测试测试测试

调用调用调用调用


问题3：如何控制数据库输入？

• 首先需要有一个测试专用的、小数据量的基准库

• 这个简单的要求对于需要高龄、复杂系统而言也是非

常不容易达到的；

• 保持基准库的方式有若干种方式：

• 测试用例执行后，执行反冲；

• 测试执行前，执行初始化动作；


问题4：何时结束单领域验收测试？

• 应从几个角度来衡量单领域验收测试：

• 对领域内需求的覆盖度

• 综合覆盖率（即将开发者测试和单领域验收测试的覆盖

率数据合并）

• 单领域验收测试不会解决跨领域集成风险；


内容提要









内容提要








• 敏捷测试的工作模式


Scrum Process FrameworkScrum Process FrameworkScrum Process FrameworkScrum Process Framework

ProductOwner

ScrumMaster

Developers, Testers, ..+ Manager/Lead

ReleaseReleaseReleaseReleasePlanPlanPlanPlan

MeetingMeetingMeetingMeeting

ReleaseReleaseReleaseReleaseArch DesignArch DesignArch DesignArch DesignWorkshopWorkshopWorkshopWorkshop

SprintSprintSprintSprintPlanPlanPlanPlan

MeetingMeetingMeetingMeeting

SprintSprintSprintSprintReviewReviewReviewReview

SprintSprintSprintSprintRetrospectiveRetrospectiveRetrospectiveRetrospective


迭代过程中的测试（A-TDD)


内容提要








• 敏捷测试的工作模式

• 敏捷测试之路


测试能力成熟度









Date post:	18-Aug-2020
Category:	Documents
Upload:	others
View:	19 times
Download:	0 times

敏捷测试的必由之路...

Documents