2016年上半年研究过一段时间infer，最难的是安装到ubuntu上各种依赖环境要解决，最后在公司的java代码上跑出来30多个可能存在空指针的代码段，并提交给研发处理。在使用过程中，我发现了一个infer的bug，并提交到infer的github上，该问题在：https://github.com/facebook/infer/issues/442
当然我的大部分提交都阵亡了，研发看了存在空指针可能的地方，告诉我代码确实会有空指针出现的可能，但是基于业务逻辑，是不会有问题的，由于鄙人对java不是很懂，难以识别代码，一股废了九牛二虎之力后，轻易的就消逝的感觉萦绕心间。下面把别人安装infer的文章转过来，以表纪念。

所有内容可以参考：infer官网
本文转自：http://www.jianshu.com/p/4667e36aadea

About Infer

Infer 是一个静态分析工具。Infer 可以分析 Objective-C， Java 或者 C 代码，报告潜在的问题。
任何人都可以使用 Infer 检测应用，这可以将那些严重的 bug 扼杀在发布之前，同时防止应用崩溃和性能低下。

Infer特性

Android 和 Java

Infer 可检查 Android 和 Java 代码中的 NullPointException 和 资源泄露。

iOS

除了以上，Infer 还可发现 iOS 和 C 代码中的内存泄露，内存泄露，内存泄露。
Infer适用范围

包括 Facebook Android 和 iOS 主客户端，Facebook Messenger， Instagram 在内的，以及其他影响亿万用户的手机应用，每次代码变更，都要经过 Infer 的检测。

Infer优点

1:效率高，规模大，几分钟能扫描数千行代码；
2:支持增量及非增量分析（后边会解释）
3:分解分析，整合输出结果。（infer能将代码分解，小范围分析后再将结果整合在一起，兼顾分析的深度和速度）

Infer捕捉的bug类型

C/OC中捕捉的bug类型

1:Resource leak
2:Memory leak

通常的查找元素方法

1
2
3
4
5
6
7

browser.find_by_css('h1')
browser.find_by_xpath('//h1')
browser.find_by_tag('h1')
browser.find_by_name('name')
browser.find_by_text('Hello World!')
browser.find_by_id('firstheader')
browser.find_by_value('query')

方法返回的结果是一个list，通过以下方法可以返回第一个、最后一个或指定位置的元素。

1
2
3

first_found = browser.find_by_name('name').first
last_found = browser.find_by_name('name').last
second_found = browser.find_by_name('name')[1]

All elements and find_by_id

A web page should have only one id, so the find_by_id method returns always a list with just one element.

Finding links

If you need to find the links in a page, you can use the methods find_link_by_text, find_link_by_partial_text, find_link_by_href or find_link_by_partial_href. Examples:

1
2
3
4

links_found = browser.find_link_by_text('Link for Example.com')
links_found = browser.find_link_by_partial_text('for Example')
links_found = browser.find_link_by_href('http://example.com')
links_found = browser.find_link_by_partial_href('example')

As the other find_/* methods, these returns a list of all found elements.
You also can search for links using other selector types with the methods find_by_css, find_by_xpath, find_by_tag, find_by_name, find_by_value and find_by_id.

已经开始实践过一些selinum的自动测试，发现要维护好一个简单的case消耗的精力远远大于获得的回报。但是这个值得（技术能力）深入学，工具无好坏优劣之分，只有适合不适合。在网上看了很多关于自动化测试的文章，现摘录一二：

以下内容引自：2014年自动化的个人感想
自动化技术的应用场所
1、功能回归测试、冒烟测试。
2、数据精度要求高的测试，数据计算、比较、统计测试。
3、简单重复的大批量测试，测试组合众多，需要测试覆盖。
4、疲劳测试。
5、接口、底层、代码测试。
6、其他不便于进行手工的测试。
PPT解读： 自动化测试 是个较大的范畴，所有不用手工进行操作通过程序驱动的测试都可以理解为自动化测试。从技术层面来讲，但凡被技术实现的东西都可以被技术模拟和测试。在人们实践的过程中，自动化技术应用的领域会越来越广，测试也是一样，自动化本身不会去约束方式和行为，自动化能够做什么会超出我们的想象。
为什么需要测试框架
1、降低实现门槛。
2、统一技术风格。
3、量化测试成果。
4、底层前端分离。
PPT解读： 没有测试框架也可以实现自动化。每个测试人员技术背景不尽相同，擅长的语言、脚本、实施的技术水平参差不齐，没有框架约束技术实现和风格，他人的维护难度会很大，不利于大家朝同一个技术方向进行分享和交流。 框架本身已经封装了很多实际需要的接口和工具，测试人员不需要花费大量的精力再度开发，集中精力快速实现测试需求本身。统一的结构不仅多人可以同时维护一个项目，也便于测试结果的分析和汇总，众多项目的批量运行。框架和项目的分离，使双方各自影响的范围得到有效控制，便于项目单点维护和迁移。开发需要框架，同样测试开发作为一种开发活动也需要框架。
自动化效果体现
1、测试前置效果体现
2、测试范围效果体现
3、Daily Test 和批量执行效果体现
4、其他指标
PPT解读： 1、接口和单测可以通过BUG数量进行衡量。这个阶段所发现的BUG含金量更高，修复的成本更低，更有价值。此外代码行数、用例数量、代码覆盖率也可以很好的统计测试实际的效果。
2、自动化可以解决以往手工不能进行的测试，比如大数据量、中间件、随机数据等测试，可以列举由于引进自动化而增加的各种测试类型。
3、100个用例执行一次体现不了什么，但是100个用例在后续的两个月里执行了100次，所替代的人工就是很可观的。自动化项目坚持每日BUILD，一方面可以及时发现问题，维护更新用例。另一个方面每日测试的汇总数据也是自动化测试效果的展示。可以通过邮件、报告进行测试项目和用例的数据汇总，如果达到一定的量级还是很震撼的。
4、自动化还有代码行数，编译次数等指标。放在部署有平均部署时间，放在数据有平均一次生成数据量等。前端自动化不宜用BUG数量来衡量，因为主要选取的相对比较稳定的业务线和模块。

以下内容引自：QA请勿忘初心
大部分QA或者tester，仍然以UI自动化为重心。之所以反对盲目的UI自动化测试，因为变化频繁的UI设计，极低投入产生比，都应该让我们重新思考下UI自动化的价值。
我们需要一个实施UI自动化正确的方式：
能不用UI自动化测试就不用，梳理业务主线，只保留用户操作最频繁，交互最多的场景。
根据面向对象设计的原则，构建适合项目的UI自动化框架，无论自己编写框架，还是采用开源框架。
尽量采用独立测试数据，确保运行测试不受影响。例如采用mock数据库或者每次运行时还原测试数据库。

作为一个QA，我们不仅要检测项目中存在问题，也要改进团队的实践活动，更重要的是预防问题的发生。
每次bugbash或相应迭代完成后，要分析统计，找出产生缺陷的环节，并采取措施防止问题再现。例如每次release或者bug bash之后,我可以按照功能模块与bug类型进行统计划分，分析统计bug的成因，例如某次迭代我们bug数量激增，经调查，发现我们对某些模块的前端代码进行了重构，但缺乏相应的单元测试与集成测试，造成了我们没有及时发现bug。之后我们就对应的采取措施防止问题再现。
总结分析报告，及时反馈这些信息给团队。总结分析是一个长期的任务，每次bug数量的变动，都会直接体现整个团队上次迭代的开发质量，例如bug数量减少了，可以鼓励成员再接再厉。或者某几次迭代某些模块bug成上升趋势，那么就需要组织团队一起讨论问题根源，采取措施防止问题重现。