LABVIEW的自动化测试之路

LabView 自动化测试之路
LABVIEW 的自动化测试之路

目录
介绍 LabView...............................................................................................................................3
迭代一: 手动测试........................................................................................................................5
设计 TestCase............................................................................................................................5
执行 TestCase............................................................................................................................7
发现的问题...............................................................................................................................7
迭代二：基于 GUI 自动化测试...................................................................................................9
执行 TestCase............................................................................................................................9
发现的问题...............................................................................................................................9
迭代三：基于系统接口自动化测试.........................................................................................10
LabView 服务端架构..............................................................................................................10
设计 TestCase..........................................................................................................................12
执行 TestCase..........................................................................................................................13
发现的问题.............................................................................................................................13
迭代四：基于模块接口自动化测试.........................................................................................14
设计 TestCase..........................................................................................................................15
重构 TestCase..........................................................................................................................17
执行 TestCase..........................................................................................................................18
后记 ............................................................................................................................................19

提示： LabView 是为了方便展示和讨论而虚构出来的一个软件产品。通过描述它的测试团
队如何对它进行自动化测试这个过程，本文向你展示了如何有效的进行自动化测试这个主题。
介绍 LabView
LabView 是一个监控实验室环境里温度和湿度的软件。它的功能很简单，当实验室的温度和
湿度超过预先设置的值，那么它会向监听者发送报警邮件或者短信。
LabView 在设计之初就设定目标为具有监控世界上任意地方的 Lab 的能力。所以它具有一个
架设在 Internet 上的 Server。同时，在每一个监控的 Lab 里，安装有一个 Agent，负责监
控实验室的环境状况，并定时向 Lab View Server 发送信息。同时它还有一个基于浏览器的
Console 提供给用户进行配置和管理工作。
对于用户，在 LabView 里叫做 Operator。 Operator 通过 Console 配置报警条件(Trigger
Condition)和相应的监听者(Listener)。Console 看起来像下面的样子。

在 Web Console 上提供了两个 GUI 控件。通过上面的控件， Operator 可以定义出发报警的
条件(所有条件都是 AND 的关系)。通过下面的控件， Operator 定义谁将会以什么样的方
式收到报警。

迭代一: 手动测试
迭代一发生在产品初步开发完成，QA 开始准备测试。
经过分析， QA 认为需要为 LabView 执行三种测试
 功能测试：针对 LabView 的功能
 Failover 测试：针对网络失效，服务器失效， Agent 失效的测试
 性能测试：针对 Agent-Server 吞吐量的测试，针对 SMS 吞吐量和 Email 吞吐量的测试
每种测试对于 LabView 的成功都很重要，但是在本文里，我们专注讨论功能测试。
设计 TestCase
步骤一
通过阅读需求文档和同开发团队讨论。QA 列出下面的表格。
Item Value Scope Comments
监控对象温度，湿度
比较方式大于，小于，等于
值 0 - 100
持续时间 0 – 65535 需求并没有定义最大持续时
间。所以开发团队并未在业
务层做限制。
触发条件数量 0-20 需求并没有定义最多支持多
少个消息接受者。但基于常
识，开发团队把消息接收者限
制为 20 个。
消息方式 SMS，Email
消息接收者数量 0 - 100 需求并没有定义最多支持多
少个消息接受者。但基于常
识，开发团队把消息接收者限
制为 100 个。
对于 Agent， QA 了解到， Agent 发送 Event 的频率是可调的，但建议设置为 1 分钟一次。
QA 认为在执行 Testcase 的时候，并不需要连接一个真正的 Agent。他们向 Dev 寻求帮助，
Dev 给了 QA 一个他们用于调试代码目的 LabViewAgent Simulator。

步骤二
QA 决定首先把所有的输入值列举出来，然后对输入值进行组合。组合结果是一个很大的
数字，所以 QA 采用正交表来设计来合理的减少 testcase 的数量。
最后他们得到了下面的表格。
基本组合
TestCase
No.
监控对象比较方式值持续时间消息方式
1 温度 Great Than 60 10 SMS
2 湿度 Less Than 10 60 Email
。。。
触发复合条件
TestCase
No.
触发条件持续时间消息方
式
1 无 10 SMS
2 湿度 GreateThan 60
温度 GreateThan 60
60 Email
。。。
多个消息接受者
TestCase
No.
触发条件持续时间消息方式消息接受者
数量
1 湿度 GreateThan 60 10 N/A 0
2 温度 GreateThan 60 60 Email 2

。。。
步骤三
基于上面的表格， QA 开始了设计 Testcase，下面是一个 TestCase 的例子
TC001: Send SMS for trigger condition of humidity great than 60% and last over 10 minutes
Steps:
1. Login LabView Console
2. Select Lab A
3. Click Add button to add a new trigger condition, and In the new added row,
a) click on radio button in column “humidity”
b) Select GreatThan (>)
c) Input 60 for “value”
d) Input 10 for “Last(min)”
4. Click Add button to add a listener, then in the new added row,
a) Select a person
b) Check on “SMS”, leave “Email” unchecked
5. Open LabView Agent simulator
a) Set Humidity Value as “61” %
b) Set Frequency as “1” minute(s)
Check Point:
1. 10 minutes later, check listener’s mail box and get an alert mail.
基于上面的分析表格， QA 设计了 30 个 TestCase。
执行 TestCase
产品每一个月 Release 一次。每一次 Release 之前，QA 都会执行回归测试，其中包括所有
的 Testcase。
所有的 TestCase 都是手动执行。
发现的问题
LabView 上线之后，市场反应非常好，客户蜂拥而至，而且他们还不断提出新的需求。
基于这种情况，一个月一次的 Release 就太跟不上步伐了，公司决定采用 Scrum 的开发模
式，把 Release 的周期减小到一周一次。
很快， QA 就感受到了压力。因为回归测试需要太多的执行时间。

因为每一次测试都必须等待足够的时间让触发条件达到给定的持续时间，而且邮件和 SMS
的处理也是异步的，需要等待一段时间才能确认成功执行。假如平均执行一个 Testcase 需
要 20 分钟，那么完成所有测试就需要 600 分钟，10 个小时。
QA 认为如果把这些 TestCase 都自动化起来，那么可以把 QA 从低效的手动测试中解放出来。

迭代二：基于 GUI 自动化测试
QA 选用了 QTT (Quick Test Tool) 作为自动化测试工具。这是一个无奈的选择，因为如果仅
仅是对于 Web 自动化，那么有很多开源且好用的工具，但如果要对 Windows 程序自动化，
那么选择就不多了。
无论怎样，自动化被认为是必须要做的事情。所以公司购买了 QTT， QA 投入了很多时间
来把所有的功能测试的 TestCase 都用 QTT 自动化起来。
执行 TestCase
在完成所有的自动化 testcase 后， QA 能够在 Release 之前把所有回归测试的 TestCase 自动
化的执行一遍。这样 QA 能投入更多的资源在新功能测试中。
在得知开发团队每天都会做一个 Build 后， QA 觉得可以把自动化执行集成到 Daily Build 过
程中。开发在每天下午 6 点之前会 Check in 所有的代码， Build 会在晚上 10 点之前完成。
QA 开发了一些脚本来安装部署自动化测试环境，在 11 点时候开始运行自动化测试， 10
个小时之后，也就是第二天早上 9 点上班时就能够得到运行结果。
在 Release 之前， QA 会挑选几个 TestCase 进行人工探索性测试。这种测试 QA 认为是必要
的，因为人的执行过程比机器的执行过程检查点多得多。这些检查点，很多并不适合写入
TestCase，比如是否文字对齐，是否某个页面加载比其他页面慢很多，等等。
发现的问题
QTT testcase 执行的不稳定性。QA 发现总会有 5~10%的 testcase 不能够通过。但手动去执
行这些 TestCase 的时候，却没有发现产品的问题。即使如此， QA 也不能简单的放过这些
失败的 TestCase，而不得不安排一个工程师每天去检查失败的 TestCase。
随着越来越多的 TestCase 加入 Regression Test，QTT 执行所有 TestCase 的时间越来越长，QA
估计，按照现在的新功能增加的速度，半年后 Regression Test 的 TestCase 数量会超过 100
个，执行时间会超过 24 小时。
QA 认为他们还需要继续提高测试效率，如果他们还想跟上产品的发布节奏的话。

迭代三：基于系统接口自动化测试
在研究中， QA 发现了“测试金字塔”这样一个概念。它来自于软件分析和设计大师 Martin
Fowler 的 Blog: http://martinfowler.com/bliki/TestPyramid.html
QA 仔细阅读了基于 Service 对 Application 进行测试的内容。并且认为从 service 来进行测试
或许是提高测试效率可行方式。
The pyramid also argues for an intermediate layer of tests that act through a service layer of
an application, what I refer to as SubcutaneousTests. These can provide many of the
advantages of end-to-end tests but avoid many of the complexities of dealing with UI
frameworks
因为基于 Service 测试对于 QA 来说是全新的测试方法，所以开始开展这样的测试之前，QA
列举出下面的问题
1. LabView 是否适合进行基于 Service 测试？
2. QA 团队是否有足够的技术能力，因为基于 Service 测试需要编码的能力。
3. 是否能够从开发团队获得足够的支持，因为基于 Service 测试需要深入产品内部，而
QA 一直以来都是把产品作为黑盒。而最熟悉产品内部的是开发团队。
4. 最后，这种测试是否经济？
LabView 服务端架构
QA 觉得首先需要从开发团队哪里获得更多系统架构信息以帮助他们做出决定。通过沟通，
QA 了解到下面的信息。
LabView Server 是一个 J2EE 程序。在 SpringFramework 上开发，部署在 Web Server 上，比
如 Tomcat。

LabView 具有三个系统接口
 Agent 通过 Restful Http 接口向系统发送 Request，系统内部有 AgentManager 模块处理此
Request。
 Operator 通过 Web Console 进行配置工作。系统内部是 AdminManager 模块负责处理相
关业务。
 系统向外部的 SMTP 和 SMS 系统发送消息，通过 SMTP 协议和 SMS 网关协议（私有）
问题 1：LabView 是否适合进行基于 Service 测试
LabView 适合基于 Service 测试。前端两个接口都是标准的。通过开源的 RestClient 或者
HttpClient 就可以和系统通讯。
后端比较麻烦一些。SMTP 虽然是标准接口，但复杂度远远超过 Http。 SMS 更是通过私有
协议通讯。
经过讨论， QA 认为可以绕开 SMTP 协议和 SMS 协议。因为测试的目的不是 SMTP 协议处
理或者 SMS 传输处理，所以可以请求开发人员在发送 Message 给外部服务器之前，向 Log
里记录响应的信息。测试时通过分析 Log 来执行相应的验证。
问题 2：QA 团队是否有足够的技术能力
了解了系统架构后， QA 觉得实施难度并不是太大。通过学习，测试工程师可以掌握相应
的技能。
问题 3：是否能够获得开发团队的支持
开发团队对于 QA 团队愿意深入了解产品去提高测试效率非常支持。他们认为如果 QA 近距
离的测试他们的代码，开发一定能从中受益。

实际上，开发团队对于以前的 QA 测试方式并不是完全理解，认为 QA 的有些测试从代码覆
盖角度来说是低效的。但开发团队对于自己不太了解的领域有足够的尊重，所以并没有提
出这个问题。开发团队任务 QA 能够自己找到问题的答案。
问题 5：这种测试是否经济
经过前面的分析， QA 觉得测试工具的开发成本并不高。完全值得一试。
设计 TestCase
QA 开发了下面的测试套件。
实际上，开发工作比 QA 预计的还要少（比 QTT 测试套件少很多），这得益于 LabView 本身
的设计和在设计中采取的折衷。比如
 LabView 使用标准的网络协议，所以可以方便的获得处理协议的工具
 QA 并没有坚持要到邮件服务器上去检查邮件来验证 Notification 功能，而是通过检
查 Log 文件

执行 TestCase
在每日的 Daily build 集成测试中，QA 执行这套基于系统 service 的测试套件。这套测试稳
定性比 QTT 高很多，不稳定性可以降低到 1%一下。
QA 认为对于 UI 的检查也是必须要的，所以挑选了 5 个 QTT testcase 在 Daily Build 的集成
测试中执行。
同迭代二，在 Release 之前， QA 会挑选几个 TestCase 进行人工探索性测试。
发现的问题
测试执行效率未能达到预期。
相对于 QTT 基于界面的测试，现在的测试节省了 GUI 操作的时间，节省了等待 email 送到
邮箱的时间。但是测试中最耗时的操作，是按照时序发送特定的 Event 序列。对于这一
点，使用基于系统接口的测试并没有提高效率。
QA 认为有必要更深入的去了解系统的模块和他们之间的关系，去探索是否有更高效测试的
可能。有了前面成功的经历， QA 相信他们的开发团队一定不会让他们失望。

迭代四：基于模块接口自动化测试
通过和开发团队的沟通， QA 发现 LabView 具有非常优秀的架构设计。他们完全可以更进
一步，对 Module 进行独立的测试。
首先开发团队在设计之初就采用 Domain Driven Design 的方式，系统内部划分了四个子
Domain (bounded context):
 AgentManager: 负责接收 Agent 发过来的监控数据
 RuleEngine：负责处理触发规则
 NotificationManager：负责发送 SMS 或 Email
 AdminManager：负责处理用户界面的请求
遵循 DDD 的设计规则，每一个 Domain 都定义有一个轻量级 Service 层。在 Service 层，
处理了 Transaction， Audit， Permission, Log。这也意味着，调用这些 Module Service 层
的接口，几乎所有业务逻辑都能够测试到。
并且考虑到未来的扩展，各个模块之间都通过消息中间件进行通讯，这意味着 Module 之
间没有强连接，完全可以隔离起来。
QA 还从开发团队获得了系统的数据处理顺序图，帮助他们更好的理解系统架构。
LabView 有两条数据处理路径。一条处理从 Agent 过来的 Event，另外一条是处理从 Console
过来的配置数据。
Agent 的 Event 处理顺序图
Console 的 Request 处理顺序图

设计 TestCase
是否需要把 LabView 部署在 Application Server 里
前面所有的测试都要求 LabView 在 Application Server 中运行起来，这是一个很大的制约。在
基于 Module 的测试中， QA 尝试探索是否可以去除这样的限制，也就是对一个 Module 进
行独立的测试。
通过和开发团队沟通， QA 了解到，对于 LabView，Application Server 最主要的作用是提供
了 Http 接口和消息中间件。那么是否能隔离 Http 接口和消息中间件对每一个 Module 进行
测试呢？
对于 Http 接口
下图显示了一个 Module 的层次。 Module 的 Interface Adapter 层用来处理和 Http 接口相关
的逻辑。比如把外部 Request 转换为 Domain 对象，或者把 Domain 对象转换为 Dto。

Interface Adapter 的下层是 Service 层。在 Service 层里， Module 定义一个或几个 Façade
接口，用来访问 Module 的业务功能。
至此， QA 能够确定，直接通过 Service 测试并没有错过任何业务逻辑。
对于消息中间件
开发团队告诉 QA， LabView 编码规则中，消息中间件接口被封装了起来。比如说，对于
AgentManager 发送 Event 到消息中间件，代码像下面的样子
DomainEventSender.publish(MonitorEvent event);
在运行时， DomainEventSender 会利用注入的 JMS 把消息发布出去。
既然产品代码并没有直接使用 JMS API，那么可用一个测试目的的 DomainEventSender （比
如 SpringFramework 本身自带的 Event 机制）。这通过修改 Spring 配置文件可以达到。
得益于 LabView 的良好设计，QA 发现在测试中完全可以绕开 Http 接口和消息中间件，对
模块进行独立的测试。也就是，并不需要把 LabView 部署在 Application Server 里就能对
LabView 的各个 Module 的业务功能进行测试。
如何加速 Event 序列？
RuleEngine 是 LabView 最核心的模块。开发团队用了复杂的设计让它运行得正确又高效。
但对于其接口来说，却是相当简单。它只有三个接口
 Process(MonitorEvent event) -> void 用于输入监控事件
 getHitList() -> List<Notification> 用于得到需要发送的 Notification，同时重置触发条件
 update(TriggerConfiguration conf) 用于更新 Trigger Condition 和 Listener List，当 Operator
通过 AdminConsole 更新之后。
在 LabView 里有一个定时 Job，每一分钟运行一次。在 Job 中会调用 RuleEngine 的 getHitList
接口，然后把所有Notification发送到Queue中。NotificationManager 会消费这些Notification。
为了加速 Event 序列，可以采取下面的方法
1. 减少 Trigger condition 中的 Last 时间。
比如把 10 分钟缩短为 1 分钟。同时 Event 发送的间隔也相应缩短，比如从 1 分钟缩短
为一秒钟。问题是这样的修改是否是合理的，毕竟和实际产品设定不一样。通过和开
发团队讨论， QA 获得的信息是“从设计角度是没有不一样的”。
虽然有风险，但QA 还是决定采取这样的方法。QA 首先完整分析了 RuleEngine 的代码，
确保这种测试不会扭曲业务功能。其次强化了每次 regression test 中针对性的测试。
结果显示，这种方法对于测试速度的提升是巨大的。可以把每个 testcase 的平均执行时
间从 15 分钟，缩短到 1 分钟。

2. 显然，测试程序并没有必要等待定时 job 执行而而得到 Trigger Condition 是否满足。
测试程序可以在发送所有 Event 后，直接调用 RuleEngine 的 getHitList 接口。
总之，就像让磁带进入快进模式一样，在测试中，QA 让系统更快的运转起来，同时小心
的确保这种加速并没有影响到对业务逻辑的破坏。
当 QA 完成对 Event 序列加速的分析和测试设计后， Dev 对 QA 的创新精神感到佩服。 Dev
认为 QA 真正完整的理解了 Event 处理的流程，无论是从功能层面还是代码层面。
重构 TestCase
原有的 TestCase 步骤是针对整个业务流程的。现在针对具体的 Module 测试， QA 发现原
有的测试步骤和检查点就不太合适。比如 TestCase 里对于 GUI 相关的描述和检查点，对于
接口测试就不能真正执行。
在深入理解了 LabView 的架构后， QA 发现，以前针对业务流程设计的 TestCase 其实有很
多冗余。比如 Trigger condition 和 Notification 并没有直接的关系，但是每一个测试 Trigger
Condition 都必须执行 Notification 的步骤，反之亦然。
所以 QA 决定对原有的 TestCase 进行重构。重构 TestCase 时，QA 总结出下面的指导原则。
1. 尽量用业务功能来描述步骤和检查点，而避免对 GUI 或其他具体事物的描述
这会带来很多好处，整套 TestCase 更清晰，易于维护，对自动化更友好。
2. 分离对业务功能的验证和对于 GUI 逻辑的验证
TestCase 应该侧重于业务功能，但是如果有值得检查的 GUI 逻辑，那么设计相应
的 TestCase，但是两种 TestCase 应该分开。
3. 如果可能，使用具体的测试数据，而不是 General 描述
比如如果要发送 Notification 给某个人，那么在 TestCase 里可以指定 Jack. 这样做的
好处是避免了潜在的歧义。但是这样也要求在设计 TestCase 之处，就对整套
TestCase 的 TestData 有完整的规划。
这并不是一次性能搞定的，所以像 Dev 重构代码一样， QA 重构 TestCase。
4. 首先设计针对 Module 的测试案例，然后在此基础上设计针对系统的测试案例
这样做的好处是，提高了 TestCase 的覆盖效率。前提是设计者要真正了解系统是
如何运作的。
5. 针对用户使用流程设计 End2End 的测试案例
前面都是通过分析方法设计 TestCase。在设计 TestCase 的时候，采用由内到外的
思维方法。而按照用户使用流程来设计 TestCase 是完全不同的思路，它跳出软件
设计，纯粹从使用角度来设计 TestCase。
通常这种 TestCase 会有很多的步骤，很多的 Checkpoint。所以，这种 TestCAse 不

应该自动化，因为自动化后执行时有较高的不稳定性。实际上，这种 TestCase
是最好的进行探索性测试的基础。
执行 TestCase
现在针对 Module 的测试套件完整执行时间少于 30 分钟。而且从覆盖率来说， QA 非常有
信心并不比以前少。
开发团队非常喜欢这套针对 Module 的测试套件，他们决定在自己的 CI 服务器上运行这些
TestCase。
QA 团队还 daily 运行大约 5 个针对系统接口的 testcase（在迭代三开发）。
当然，每个 Release 前，QA 安排了手动测试。 QA 执行 End2End 类型的 TestCase。 TestCase
并不多，所以 QA 有时间来探索每一个想法。
至于 QTT testcase， QA 团队认为完全不需要了。

后记
LabView 的 QA 团队找到了适合他们的测试方式。他们很好的利用了自动化来帮助自己，这
样他们有时间来进行探索式测试和性能测试，甚至去接触一些前沿的测试，比如安全方面
的测试。他们非常自豪他们能够拥抱变化，能够在真正了解问题后给出创新的解决方案。
当公司管理层听到他们准备抛弃 QTT 花费巨资购买的工具时，还有一些吃惊，并有一点
担心是否这是一个草率的决定。但管理层坐下来，认真听取了他们改进的历程和理解了目
前整个测试的原理. 管理层认为他们应该相信这个优秀的 QA 团队。
开发团队知道了 QA 部门会做所有基于接口的测试，无论是整个系统还是单个 Module，所
以他们可以集中在单元测试。而且在接口设计之初，他们就能从QA获得关于接口的反馈。
开发团队重视这些意见，因为他们知道 QA 是真正在使用这些接口， QA 在设计之初就在
帮助他们改善他们的设计。
到目前为止，我们可以认为 LabView 的 QA 团队成功了。这个故事结束了，但还有很多
主题值得进一步探讨。我们将在后面的文章中进一步讨论。
lifr_nj@msn.com
2014-08-25

LABVIEW的自动化测试之路

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (10)

Similar to LABVIEW的自动化测试之路

Similar to LABVIEW的自动化测试之路 (20)

LABVIEW的自动化测试之路