自動化心得報告

學長教學

今天很榮幸由許學長來教我們PLC，因為在五專的時候就知道學長機電整合很厲害，但是一直沒能夠親自看到，所以一直很期待，雖然今天學長只教我們基本認識PLC程式設計、實習盤的接線，五專時已經學過一次，

所以當學長在教的時候我很快就能懂，可是在學長的教學過程中，讓我了解，即使自己會但要去教別人的時候也是一門學問，因為有些是概念上的東西，要教別人時必須要讓人淺顯易懂，像當我聽完一次，同學請我教他們的時候，我就有點不知要從哪的點教起，由其是在講解的時候同學很容易概念沒通就聽不懂，在教學上真的很辛苦，能體會到老師和學長在教我們的時候真的不簡單。很開心今天可以上到許學長教的課很不一樣的感覺。

校外參訪

很開心已經很久沒有校外參訪，當知道這次去參訪FESTO其實我

還蠻期待，因為在去參訪

前老師安排過一次

FESTO的演講，讓我有初

步的了解這家公司，所以

很期待去看看那家公司在做的東西，今天一到的時侯看到異於其他家公司的外表真的很有意思，簡約的外表很乾淨很明亮，我很喜歡。

接下來在聽簡報當中聽到經理獎的一句

話讓我思考很久，就是他覺得畢業後最好快

點找工作，如果在念研究所當完兵就又浪費兩到三年，當事業要開始自己的年紀就快要退休，所以希望我們在讀書時候趕快訓練技能，畢業後趕快找工作先有工作經驗，這段話讓我有很多疑問，而我自己是因為覺得讀研究所是我能有更強的能力才能選擇更好的工作，這也才能讓自己更快提升自己的能力，所以我畢業後才選擇繼續升學，真的需要讓自己好好思考。

再來畢業的學長幫我們介紹FESTO的元件，真的讓我大開眼界，有些原件的設

計真的讓

我想不到，也讓我對於自動化設備的運用有更多想法。接下來是由外國人為我們解說運用FESTO的元件來自做的移動載具，在聽解說時真的只聽得懂幾個單子，也只能配合他的手是來猜測，其實還蠻有趣的。

而在參觀工廠

時讓我一個疑惑

終於有答案，就是

無桿氣壓缸到底是哪裡驅動他，原來是在氣壓缸的的一個角或邊有個缺口，裡面是一個活塞，可以左右移動。

聽完FESTO

公司整個介紹真的讓我對

自動化設備越來越有興趣，也很希望未來自己也可以投入這些設備的研發。

才在想說想要看看有什麼其他運用，老師就帶我們到隔壁鉅綸設備公司參觀，剛開始看到這家工廠，我就在想這些機台到底在做甚麼，經過解釋和解釋和操作後，終於知道

原來是在

做剝線和

上線頭的

自動化機

器，可是在當下我有產生一個想法，他們只有做剝線的機器沒有做別的嗎?

詢問後

他說其實只專做這個就很有搞頭，就已經算是一個產業，所以基本上只要專研這項設備就可以了，當下真的讓我學到很多，原來專做一項設備就可以開一家公司。後來我又有一個疑問，在當場沒看到這些設備的加工機器，那這些零件是哪來，那這些零件是否都有經過計算?所以我又問了，老闆告訴我這些零件很多都是委外去製作和一些現成的零件，而每項零件都是有經過模擬和計算後，而且在設計除了考量結構還必須考量成本，所以看到有些零件上都有洞，那都是為了減低成本所弄得。

經過這兩家參訪

後真的學習到很多希望下次也可以有這樣的參訪。

第二篇：开发自动化测试脚本的技巧和心得(转载)

开发自动化测试脚本的技巧和心得（转载）

作者在本文中描述了一些构建更易维护的和健壮的自动化测试脚本的技巧。作者给那些使用自动化测试工具并且为将来测试工作 而建立自动化测试脚本库的测试人员提供了有价值的远见。本文提供了许多在文档化测试脚本，调试测试脚本，执行测试脚本的同行评审和同步测试脚本方面的建 议。

增量式调试脚本

录 制测试脚本，和其他的软件开发成果一样，会变得非常大。为了可以成功的回放，需要调试几百行的代码，为了参数化的数据驱动测试脚本，它可能包含了几个数据 集。常见的调试测试脚本方法是首先录制所有的业务流程和需求，然后测试人员回放测试脚本以验证并纠正问题。测试人员继续调试脚本直到它和可以一（或多）组 数据集一起成功地回放。 当 测试脚本有成百的代码行，验证点，分支的逻辑，错误处理，参数和数据在多个已录制的业务流程之间的相关性时，调试并且解决测试脚本中的问题变得特别的乏味 和难以处理。对于调试那些复杂且又冗长的测试脚本，一个更加容易管理的方法是录制脚本的一部分并且在录制测试脚本的其他部分之前分开调试他们。在测试单个 的部分后，你可以决定测试脚本的一部分如何和另一部分工作和数据如何从一个已录制的流程流向其他的流程。在测试脚本的所有部分都录制后，测试人员就可以回 放整个测试脚本，并确保脚本同一个或多个数据集一起从头到尾被正确地回放了。

举个例子，我录制并自动化了一个执行了以下业务流程的复杂的测试脚本：

1. 检查在货仓中的库存

2. 执行一次MRP运行

3. 补充库存

4. 挑出一些要发送的货物并且进行发货

5. 确定交货需要移交的订单

6. 验证发送的货物到达了它们的目的地。

这个测试脚本有一些代码行，参数，验证点和需要象一个整体一样工作的数据相关性。首先我录制了每一个单独的流程并且验证 了他们分别可以成功的回放。然后我将所有录制好的流程集成尾一个大的测试脚本并且验证它同多个数据集一起能够成功的回放。如前面所述，一个关键的目的是确 信在继续录制整个测试脚本的剩余部分之前每一个已录制的流程可以成功的回放。我没有录制所有提及的流程（从1到6）并把它们排列一起回放，而不首先验证所 有的流程可以作为单独的流程成功的回放。

这部分是为了避免等待调试脚本，直到整个测试脚本录制好。

测试脚本的同步

测 试工具会用比终端用户手工按键快的多的速度回放已录制的测试脚本。接着由于应用程序可能不够快地显示数据或从数据库取出数值以允许测试脚本正确地回放，这 可能会击垮所测试的应用程序。当测试地应用程序不能响应测试脚本时，脚本执行会突然中断，然后需要用户干涉。为了同步所测试应用程序和回放中地测试脚本， 测试小组在已录制的测试脚本中引入了人为的等待时间。为了放慢测试脚本的执行，嵌入在测试脚本中的等待时间是最任意的且通过试验和错误最佳估计。等待时间 主要的问题是它们要不是等的太长就是不够长时间。

例 如，测试人员或许注意到对于所测试的应用程序测试脚本回放得太快。他可能打算放慢它几次直到测试脚本执行和测试的应用程序相同步。这个技巧可以会造成相反 的结果－甚至失败－如果在测试执行时，由于外部的因素（例如网络有延迟或系统维护）导致应用程序

运行比新引入的等待时间更慢。在这种情况下，每次测试人员 将不得不不断的猜测一个新的合理的等待时间。用等待时间放慢脚本不是十分科学的，并且对于创建强健的，在没有用户干涉情况下能够成功运行的自动化测试脚本 没有什么帮助。

如果有可能的化，测试人员应该避免引入人为的等待时间或任意的sleep变量以使测试脚本和应用程序同步。

"While"语 句或嵌套的"loops"语句是用于同步需要同步点的测试脚本且不管所测试程序的响应时间都可以成功回放的正确的技术。在测试脚本种插入嵌套的loops 或“while”语句也可以减少在测试脚本回放时用户的干涉。例如，我插入"while"语句在录制好的测试脚本里，不断按Enter键直到创建了一个计 划中的协议，不管所测试应用程序要花多长时间产生协议。测试脚本不依赖所测试应用程序的响应时间工作。

已签核，通过了同行评审

作为测试准备审核标准的一部分，测试脚本应该被正式的接受并且在开始测试循环之前被批准。SMEs， 业务分析人员和开发人员都应该参与到批准已录制的测试脚本中。编写已自动化的测试脚本的测试人员应该证明测试脚本可以成功的在QA环境中回放，如果有可能的话，可以带上多种数据集。

录制、回放隐藏的对象

脚本可能被录制为增加或是双击表格中一个字段或字段位置没有被固定的一个数组的值。如果表格或数组中字段的位置从开始录制时就不断地变化，脚本可能在回放时会失败。测试脚本经常在回放中失败就是因为那些没有显示或在屏幕中可见的对象的位置发生了改变。 为了回放那些位置敏感或位置受变更影响的脚本，有必要用功能性增强脚本，例如“向下滚屏”，“下一页”或“查找”。包含这些实用性功能可以确保需要回放的隐藏对象将可以被识别，增加或是双击而不顾其在矩阵，表格，显示的屏幕上的位置。

举 个例子，我曾经录制果一个脚本，在最初录制时它需要向下滚屏两次来查找一个可以在表格中输入的空字段。当我在几个星期之后回放它时，我不得不向下滚屏四次 来查找空字段，而不是相之前录制的两次。接着脚本失败了，因此我在脚本中嵌入了逻辑判断以指导脚本向下滚屏需要的次数来查找一个空字段。我通过在一个 “while”循环中放置一个“下一页”（"next page"）功能实现了这个目的，它可以驱动脚本不停的“下一页”（page down）直到找到空字段。

安排重运行脚本/储存执行日志

为了绕过测试工具不能在安排测试脚本重运行的局限，测试人员可以通过可以支持多种命令行选项的NT的scheduler安排测试脚本。测试百年应该将执行日志存储在一个共享的驱动盘或针对审核的测试结果的测试管理工具中。

为关键的脚本创建自动的消息通知

可以用错误处理程序逻辑增强测试脚本，当错误发生时它可以不断的发送错误信息给无限设备或email地址。一些测试脚本是关键性的业务并且可能在午夜批量地运行。正确并成功运行这些关键性业务的测试脚本会作为其他自动化任务的一个依赖或者前提条件。 通常也包括在关键业务脚本中一旦出现失败时自动发送消息通知的逻辑。

编制文档

为了使测试脚本可重用并且更容易维护，文档化所有和执行测试脚本，测试脚本的头文件，任何执行测试脚本的特殊条件相关的信息，例如：

1. 为了关闭书本调整所测试应用程序中的日期

2. 更新任何需要唯一数据的字段

3. 为了环境判断模式（context sensitive）/ 模拟模式（analog） /位图录制，调整

显示器设置

4. 列出所有有依赖的测试脚本

5. 指出为了执行脚本需要的权限级别或用户的角色

6. 在什么条件下脚本会失败，以及重新运行脚本的绕行方法

7. 需要在脚本运行过程中打开或关闭的应用程序

8. 指明数据的格式，例如，欧洲日期格式VS美国日期格式，等等

此外，脚本中需要包含一个描述（例如，它是干什么用的）和特别用途（例如，回归测试）的文件头。脚本的文件头应该包括脚 本的作者，所有者，创建和修改日期，脚本可以追溯到的需求识别符，脚本所支持的业务范围，脚本中的变量和参数数量。在测试脚本中提供这些信息使以后的测试 工作中的脚本的执行，修改和维护更容易些。

实行测试脚本的版本控制

许多公司花好几万英镑购买测试工具，但是却忽略了测试工具的副产品－录制好的测试脚本。为了公司构建中的自动化测试脚本的库和存储库，强烈建议对自动化测试脚本实行版本控制。版本控制帮助追踪测试脚本中的变更，并可维护同一测试脚本的多个版本。

坚持测试脚本命名标准和存储

测试脚本应当遵循项目公认的命名标准，并且应该存储在指定的库中，例如一个共享的驱动盘或测试管理工具中。

测试经理应当指明包括如下方面的测试脚本命名标准：

1. 项目的名称（例如，GSI代表着Global SAP Implementation）

2. 版本号（例如，即将发布或部署的版本号）

3. 主题或测试种类（例如，SC代表安全测试，LT代表负载测试）

4. 有序的测试用例编号

5. 标题或将要测试的功能（例如，来自外部供应商的采购业务）

遵循这些技巧使测试人员能够为他们的组织构建更强健的测试脚本。当然，开发可维护的测试脚本最大化自动化测试工具的效 益。当自动化测试脚本用在以后的测试工作中，减少了完成一个测试循环所需要的时间时，公司就可以意识到自动化测试工具带来的投资回报（ROI）。以上的技 术将帮助公司构建符合这些目标的测试脚本。