sophie2805的专栏

Web UI自动化项目初期，可能是单一的一套测试环境，代码里也只用写一套URL & Folder path & Database。随着项目的进行，很可能生产环境也想跑自动化，验证系统可用性或者做Load Test。测试环境也可能多出来几套，阿尔法，贝塔之类的。此时，hard code待测试系统的相关信息就显然不合适了，否则每次在一个新的环境里跑测试，就得改自动化项目中所有的相关信息。这样很容易漏改，

对于大型excel文件的创建，一个关键问题就是，要确保不会内存溢出。其实，就算生成很小的excel（比如几Mb），它用掉的内存是远大于excel文件实际的size的。如果单元格还有各种格式（比如，加粗，背景标红之类的），那它占用的内存就更多了。对于大型excel的创建且不会内存溢出的，就只有SXSSFWorkbook了。它的原理很简单，用硬盘空间换内存（就像hash map用空间换时间一样）。

Excel文件内容比对 -- Java Apache Poi代码结构代码运行结果测试用例工具使用前提条件待完善的点在某些项目中，报表比对是测试的一大内容。比如，在某版本下生成baseline report作为标准答案，新代码进来后，再次生成report，跟baseline report作比较，确保改动没有引入差异。报表多以excel文件形式导出，用工具进行excel文件比对十分有用。Apach...

Rally是软开行业，大概最贵，最庞大的敏捷流程管理工具了。 为什么我一个自动化测试人员，跑去做了一个Rally相关的小工具呢？故事背景是这样的，我们公司有audit 和 metrics（大公司，管的就是多…），要求每个迭代结束后，所有的story&defect得是accepted的状态，并且assign back to PO.所有defect的某些字段（比如Test Pass Fail...

Web UI自动化测试的不稳定性有两个层面：技术层面–没有构造健壮的能稳定运行的脚本非技术层面–项目原因或者用Web UI自动化企图达到不合适的目标，造成脚本频繁改动，维护成本高第一点在上一篇博文里从代码层面分析过了，今天主要说说第二点。丑话说在前面，Web UI自动化不是万金油，它不可能干掉手动测试人员。衡量好投入产出，最大化UI自动化的效用，才是王道！什么项目不适合做We

我在之前的文章里提到过有些情况不适合跑UI测试的，而适合用接口测试来覆盖，我是传送门。尺有所短，寸有所长。接口测试是UI自动化测试的一个强有力的补充。首先接口测试较UI测试效率更高，速度更快其实接口测试较UI测试稳定性更高打个比方，请求某API，正常情况下它返回一堆数据。如果走UI测试，可能需要登录>去到相应页面>把相应条件设置好>点击某按钮触发请求>等待页面响应，直至加载完成>然后去DOM

Web UI自动化对环境依赖度高，换言之，同一套代码，换个机器跑，很可能问题百出。浏览器的配置自然是重中之重，除此之外，机器的屏幕分辨率也是不可忽视的重要因素。曾经碰到一个问题：我写的一段代码，在我自己的虚拟机里跑的挺好的，但是在另外一个同事的虚拟机里，某个菜单就是选不中！debug时发现，元素都定位到了，MouseClick就是不点击该元素（插一句，如何快速发现是元素定位问题还是元素操作问题呢？看

Web UI自动化测试的不稳定性有两个层面：技术层面–没有构造健壮的能稳定运行的脚本非技术层面–项目原因或者用Web UI自动化企图达到不合适的目标，造成脚本频繁改动，维护成本高今天先说第一点。首先，Web UI自动化测试是不稳定的，哪怕脚本写的很棒！为什么？因为Web应用本身就有不稳定的情况存在。以下这些情况想必我们都经历过：点击网页上的按钮或者菜单没有响应（有时候第二次点击才有响应…）

先交代下背景，我们UI自动化有十几台机器，有一些配置文件需要放到每一台机器的某个路径下，重复性很高，很繁琐新时代的青年接受不了这种手工重复劳动，所以花了一个晚上弄了个windows batch脚本。老实说，windows batch真的很不习惯，毫无基础，每一行都是现搜索现写，如果是用Python就会便利很多，但是windows batch适用性更强，只要是个windows机器就能跑起来。脚本工作原

PDF相关测试一直都是手动进行，自动化测试介入的很少。我们项目，PDF是很重要的一块，客户经常需要将报表导出到PDF。导出的可能是表格，也可能是饼图，条图，线图。表格的话，有flat grid，有tree grid。图的话，花样就更多了，图例，坐标轴…最近的迭代有个story，希望自动化测试能够判断表格导出到PDF格式是否正确。美国那边的on-site leader说让我先探索一下，能否用iText

用Telerik测试框架有一段时间了，总体感觉这个框架对于微软系的产品有着不错的支持。比如使用Ajax的web应用,Telerik框架可以等待页面加载完成，亦或者等待某个特殊元素出现/消失，可以自动或者手动刷新DomTree，可以和Windows系统窗口互动（比如从网页上导出报表到文件并保存至指定路径）。但是用的时间长了，就发现这个框架其实还是有些小问题的，并非尽善尽美。Telerik对于基础的常

[本篇博文不包含源代码，仅涉及自动化日常工作的思路，工具构件]最近为truView hudson team做了一件事：从DB查error log并通过邮件发送至配置的收件人。Delivery Lead原本要求QA每天查询固定的5张log表，将各个表的error汇总并邮件给整个team…我发觉查询并汇总error是个挺繁琐的活儿，因为会有重复的error不停的反复出现...