昨天参加了一个公司产品开发流程的介绍培训, 觉得蛮有所获的. 这个应该属于我前面总结的"理解"类型的培训. 培训师口才好, 材料靓, 加上听得用心, 效果岂能不好 :).

介绍一下背景, 公司的产品不是超级复杂的,比如登月飞船(废话!), 但也不是太简单,不是手工作坊能搞定的, 也会有全球销售.

总的来说, 我觉得比较精辟的是对产品开发过程中主要角色的定义和相应的流程.

角色定义

1. 产品经理: 负责确定"做什么". 比如和销售部门一起确定需求.
2. 项目经理: 在非技术层面确保"顺利完成". 控制怎么做过程中的"计划, 资源, 预算, ...
3. 架构师:   在技术层面确保"顺利完成", 选什么样的技术, 怎么测试...

相应的流程

1. 产品经理确定做什么,
2. 架构师召集一伙人实现,
3. 项目经理保证"实现"能按时, 按量完成

是不是很简单?! 这可是整整一个下午培训的超浓缩精华啊.

补充一下, 这个产品开发流程我觉得存在的问题是"过度关注流程, 而缺少对人的关注". 对于软件开发相关的项目管理, 我觉得精细控制流程是没有市场的, 增加了成本, 最终还是流于形式. result-driven可以取代很多对于过程的控制.

参加大大小小的培训不少, 但花了若干时间和精力接受完培训后感觉有收获的, 极少极少. 绝大多数都是浪费时间. "还不如自学".

这到底是怎么回事呢? 我知道有很多人是喜欢培训的, 并且真正觉得培训很有用(即使是我觉得没有用的培训).

后来我仔细想了想, 觉得可能是这么回事. 培训从类型上, 我把它分成三种

了解 :
培训传达的知识比较明显, 或者说是一目了然的知识. 经过培训能够知道一些事情是什么样的, 比如知道所有颜色都是由"红黄蓝"三种原色组合而成,知道如何用ms painter去画一个圆.

理解 :
培训用容易理解的语言或者图表或者其他手段, 帮助你理解比较复杂的运行机理. 比如一个局域网的网关转发包的机理, 如果你仅仅读教科书干巴巴的文字"掩码,网段, 路由表, ...", 第一次理解它会杀死你好多脑细胞, 好的老师会让你轻松的理解. 对于这种类型的培训, 如果经过培训你有"恍然大悟"的感觉, 那么这个培训就到位了.

掌握 :
有一些使用的方法, 即使你知道一步一步怎么做, 也理解了背后的运行机理, 但也不一定能顺利完成,因为它比较复杂, 现实中总会出现各种各样理论上没有考虑到的情况. 比如配置一个windows domain, 配置一个oracle 数据库. 这种情况需要大量的经验和对问题的自觉(其实也来自于经验).
还有一种情况是, 一个解决问题的方法, 从道理来说很简单, 但应用场景五花八门, 遇到问题你不一定能够使用它来解决问题. 比如设计模式, 倒背如流者不一定就会用.

对于我个人来说,

• 一个培训如果只是让我"了解"某个我不知道的知识, 一般来说还是会有收获的.
• 一个培训如果是让我"理解"某个机理, 那么取决于trainer的水平,遗憾的是多数时候trainer并不太专业,真的还不如自己看书.
• 一个培训如果是让我"掌握"某种方法, 我现在明白了, 干脆就是浪费时间. 所以有句话说"没有写过10万行代码,不要说自己掌握了设计模式", 同理,没有公司会信任只有证书,没有实践经验的oracle DBA

这就是我对培训的困惑和一点思考. 刚刚从一个令人昏昏欲睡的培训中逃了出来, 写就此文.

HR告诉我们要把个人的活动同公司的商业目标对齐. 这句话说起来显得"假大空", 其实呢对我们软件测试工程师来说真正是有意义的. 关键我们要理解, 如何对齐, 在哪些方面对齐.

对一名负责任的软件工程师来说, 很自然,眼光盯在软件测试上, 想得是如何测试更全面, 更有效率, 发现更多的bug, 这没有问题, 也是必须的. 但这还不够, 我们还要把眼光放得更远一点. 从我现在的理解来说, 我觉得软件工程师的视野有这样三个层次

1. 软件测试        : 测试技术, 方法, 设计testcase的思想,方法, bug数量,...
2. 质量保证        : 缺陷趋势, 测试过程, 测试组合, 测试效率 ...
3. 成功的产品   : 用户愿不愿意买单, 能不能及时抢占市场, 和竞争对手的比较, 哪些缺陷是可以接受的 ...

刚入行的菜鸟, 仅仅关注"软件测试"本身就可以了(好好学习, 天天向上 :) );

做到资深工程师,就必须要有"软件质量保证"的概念, 但和大多数人的常识相反, 影响软件质量最大的因素不是测试,而是"开发", 开发很烂, 测试再好也是修修补补. 开发很好, 测试轻松, 发布产品的质量还高. 除了"开发", 需求收集, 用户使用习惯, 过程等等都会影响最终发布软件产品的质量. 资深软件测试工程师必须有这样视野,在工作过程中,考虑到这些影响因子, 来保证最终交付产品的质量. 有这样的视野, 在同开发,技术支持等其他team的协同中我们就能有一个清晰的立场.

更进一步. 我们再往前看. 一个公司要取得商业上的成功需要在市场上提供有竞争力的产品. 一款成功的产品, 有专门的分析指出, 取决于三个因素"质量, 功能和时机". 请注意, 软件工程师视作生命的质量, 只是成功的三个要素之一. 我总能听到来自软件测试工程师的抱怨, 如下所示. 我觉得对于这样的感受, 我们都应该仔细掂量一下,到底是确实存在问题,还是公司商业策略的需要.

• 功能加得太多, 时间太紧,来不及测试
• spec写得太差,太粗略了
• 公司只重视sales/dev,而不重视qa
• ... ...

我们看看一个软件测试工程师如果平步青云的话, 他的职业发展能是一个什么样的.

测试工程师 -> 测试leader/测试architect -> engineering manager -> CTO -> CEO

          测试       ->              质量保证        ->          成功的产品

没错, 一般来说, 在CTO和CEO的级别, "成功的产品"才是他们重点关注的. 我们作为软件测试工程师, 其实也能够具有这样的视野, 在我们的日常工作中体现出来. 把自己的活动同公司的商业目标对齐.

suppose $PrjHome is the project root directory

• download JMeter binary and JMeter source

• build up project directors as below

Note only folders making sense in this guide is listed.
<pre>
    $PrjHome
        |- src         # source code folder
        |- bin         # class files folder
        |- lib         # jars folder
        |- jmeter      # jmeter  binary copied here
             |- bin
             |- lib
                 |- ext
                 |- ...
</pre>    

• create and apply user library JMeterLibJar containing all jars in $PrjHome/jmeter/lib/*.jar

• create and apply user library JMeterJar containg all jars in $PrjHome/jmeter/lib/ext/*.jar and $PrjHome/jmeter/bin/ApacheJMeter.jar

• in Eclipse Package Explorer panel, right click on $ProjHome/JMeterJar/ApacheJMeter_core, select "Properties", click on "Java Source Attachment", then set soure for this jar.

• edit $PrjHome/jmeter/bin/jmeter.properties, find line "search_path" and set value as below

• create a scrip to launch JMeter

<pre>
    public class JMeterStart {
    
    public static void main(String[] args) {
        System.setProperty("jmeter.home", $PrjHome/jmeter);

        JMeter jmeter = new JMeter();

                jmeter.start(new String[]{});

                //if nongui. -n nongui, -t testScriptPath
        //jmeter.start(new String[]{"-n", "-t", "$Somewhere/test.jmx"});
    }
   
</pre>

• create source files of your jmeter plugin, say  FooRequest, and it's a java sampler.

• run 'JMeterStart', see JMeter window appearing. add 'thread group', then add 'java sampler', in dropdown list check  FooRequest present

 

性能测试学习之二: 要求和方法

* 新的问题
前文, 我总结了性能测试的核心有三点
1. 响应时间
2. 吞吐量
3. 可靠型(长时间运行)

特别是两个曲线图:
    响应时间与vu
    吞吐量与vu
能提供关于性能的很多信息.

当然这是一种极度简化的情况, 适合于时间,人员资源都非常有限的情况, 以最小的成本获得最多的收获. 但是在实际项目中, 情况会更复杂一些, 对性能测试的要求也更多.比如老大刚给我的一个测试项目, 他的说法是"没有时间的限制, 尽可能全面的对产品做性能测试".

"什么叫尽可能全面?"对于经验丰富的老手来说, 这样的项目做起来是很惬意的, 没有时间压力嘛. 但对于我这样的菜鸟来说, 头大..... 我首先得要把各种测试需求明确处理, 然后找出对应的测试方法. 这些东西对于我来说, 都还是一团浆糊嘛. 能不能有条理的把这些东西明确下来? 明确下来的东西够不够全面? 我真的有点头大了.

* 测试场景之分类
任意一本性能测试方面的书, 我正在看的是"应用程序性能测试的艺术"和软件性能测试过程详解和案例分析", 关于测试要求和方法都是让人眼花缭乱的. 还是为了简化问题, 从大的方面, 我觉得可以把性能测试从方向上分成两类.
    1. 面向生产现场的
    2. 面向软件开发的(这里的"开发"指产品在release客户之前的整个开发过程)
之所以分成这样两类, 是因为他们对性能测试的要求不太一样, 导致后面的测试方法, 测试过程也不一样.

* 测试方向1 --- 面向生产现场的性能测试
要求:
对于面向生产现场的性能测试, 主要的要求比较简单和明确. 那就是
    性能的验证: 验证整个产品(软件, 硬件, 网路, ...)作为一个整体 能提供满足特定的性能要求.

比如说,
    500G的后台数据, 1000个在线用户, 300个并发访问, 平均响应时间小于6秒
    500个用户在1个小时内登陆系统,所有的用户都能登录,且登录时间控制在3分钟
    24*7运行不出问题
    ...

特点:
    1) 测试环境尽量和生产环境一致. 性能需求明确.
    2) 测试的直接客户更关注商业价值,而不是产品的实现技术.

* 测试方向2 --- 面向软件开发的性能测试
要求:
对于面向软件开发的性能测试, 要求会更多样, 典型的包括
    1) 找出性能缺陷(bug)
    2) 性能regression test, 确定在build之间没有performance downgrade
    3) 得到benchmark的数据, 作为某些分析的基础.
    4) 针对某一个transaction的性能测试(只跑此transaction)
    5) 在某一个特定的硬件平台, 绘制性能曲线, 作为市场推广, 性能规划的基础.
    7) ... ...

特点:
    1) 测试环境并不一定和生产环境一致, 性能需求也不明确.
    2) 测试直接客户是公司内部部门, 他们的要求各不相同. 也就是说要可能需要提供多种性能测试数据, 满足开发, 测试, 市场等各个部门对性能测试的要求.

* 性能测试类型
在确定了性能测试的大方向后. 再看看具体有哪些测试类型. 根据性能测试的方向, 结合具体要求来能确定需要做的具体测试类型.
我总结面一些具体的测试类型. 其中基准测试(benchmark testing)和负载测试(load testing)是核心, 其他测试是扩展.
    核心测试
    --------
    1) 某个transaction的基准测试(benchmark testing)
    在没有任何性能压力下, 跑一个transaction, 得到系统最快的响应时间. 这是一个比较的基础.

    2) 某个transaction的负载测试(load testing)
    针对某一个transaction, 只运行这一个transaction, 得到其性能曲线. 这也是一个比较的基础.

    3) 某个用户流程的负载测试(load testing)
    针对某一个用户流程, 比如用户ATM机从插卡到查询到取钱到退卡的整个流程, 得到其性能曲线

    扩展测试
    --------
    4) 性能验证测试(performance validation testing)
    模拟真实环境压力的场景.验证系统能满足期望的性能要求. 一般涉及多个transaction和多个用户流程.

    5) 压力测试(stress testing)
    针对某个特定场景进行压力测试. 加压力直至系统爆掉,因为主要任务就是加压, 所有thinking time都可以为0.

    5) 可靠型测试(longevity testing or reliability testing)
    一般选择真实压力场景, 让系统跑个几天.

    6)  并发测试(concurrency testing)
    针对某个特定的模块或者transaction, 关注其在多个用户同时访问的情况下的表现和行为.

    7) 性能回归测试(performance regration testing)
    在特定的某一个软硬件平台上, 按照特定的压力运行测试一定时间. 通过比较响应时间来判断是否有performance downgrade.

    8) 其他(to be added ...)

灵光一闪, 感觉找到性能测试的门道了

＊　性能测试, 一直徘徊在门外
做QA多年了, 手工功能测试, 自动化测试做过的项目不少. 但做性能测试的项目很少.
我感觉性能测试和功能测试, 自动化测试完全不一样, 这种不一样是从测试理论到测试目的, 测试方法, 测试工具等等都不一样. 再加上性能测试本身的知识, 实践都是挺丰富的. 所以功能测试和自动化测试经验丰富, 初次面对性能测试也是两眼一抹黑, 狗咬乌龟, 无从下口.
因为不会, 所以自己对性能测试一直都感兴趣, 平时也不时关注一下相关的信息, 性能测试的书和网友写的文档也看了一些, 甚至也经历了几个性能测试相关的项目. 但感觉这些介绍都有点隔鞋瘙痒, 看完之后只是多了一些零星的知识. 自己对性能测试的理解总有在门外徘徊, 并没有真正掌握的感觉.

＊　复杂的性能测试
其中一个原因, 就是性能测试看上去比较复杂. 比如 段念的 "软件性能测试过程详解与案例分析" 把测试类型可以细分为 "性能测试, 负载测试, 压力测试, 并发测试 … …"
测试的目标也挺多, 这些目标分别来自于QA, Dev, 客户, 系统管理员… ...
过程也比较复杂, 具体可以参看书 "Web application performance testing".
计数器,报表更是五花八门, 让人眼晕.

对于任何复杂的事物, 我认为一般来说都有一个核心的东西, 核心是比较简单的, 而复杂性是来源于在核心上面加了越来越多特定方面的功能造成的. 要理解和掌握性能测试, 一定要把这些附加功能剥离, 把核心的东西找出来. 那么性能测试的核心究竟是什么呢?

＊　从简单出发
前段时间, 老大交代了一个任务就是对一个产品做性能测试. 他提出了对性能测试的要求, 比如测试结果要能评估系统的性能, 要能发现性能相关的bug, 要能给Dev提供足够的信息去分析bug, 要能测试新版本的performance downgrade, 等等. 没错,这些都是性能测试中常见的要求, 但我知道要是一开始,就打算满足所有的这些目标, 那我肯定搞不出来, 毕竟我还是性能测试的菜鸟.

所以, 我一开始定了一个最简单(可以说简陋)的目标: 跑完测试, 得到一个性能指数, 用这个指数来表示系统的性能. 具体来说就是我们定一个固定的虚拟用户的值(凭感觉), 然后统计 响应时间的平均值, 用这个值来表征系统的性能. 这个就像常见的pc上的3d性能测试样, 无论显卡性能如何, 都跑同样的test, 用同样的过程, 同样的计算指数的方法. 这真是一个简单得不能再简单的性能测试目标!.

＊　发现性能测试的核心
具体的工作是另外一个同事在做, 但我一直也在思考, 如何能让目前的性能测试更好更强大. 某天在纸上写写划划的时候, 突然脑袋里灵光一闪, 煞那间, 所有的障眼法似乎都烟消云散, 留下了三个闪闪发光的单词.
1. 虚拟用户(virtual user): 同时使用系统的用户数目
2. 响应时间(response time): 一个用户请求, 从发出到接受, 经历的时间
3. 吞吐量(throughput): 系统单位时间处理的用户请求数目

这三个量,形成了下面两个曲线. 
1. 虚拟用户与响应时间的关系曲线,
2. 虚拟用户与吞吐量的关系曲线.

一个特定系统的性能到底怎么样, 就由这两个曲线来描述; 有了这两个曲线, 你就可以回答关于性能最主要的一些问题
    这个系统最大能支撑多少用户
    用户响应时间不要超过6秒, 最多能支持多少用户
    未来半年, 用户数会增加10000, 需要加硬件吗
    你给我一个 数值, 我的系统到底性能如何?我不要看那么多的图表
    … …

发现自己找到了"性能测试的奥秘", 我按捺不足兴奋. 跑去和一个用Loadrunner做过项目的同事交流, 他肯定了我的观点, 说以前用loadrunner做项目就是这样分析的(为什么不早告诉我啊…:( ). 并且指出统计响应时间时, 一般统计按照正态分布的90%的用户的平均值(所以Jmeter的Aggregate Report里有一个90%line)...

后来同老大的交流中, 他特别强调了request的失败率. 这是一个客户关心的问题. 没有关系, 小case, 只要抓住了问题的核心, 这些附属的指标加多加少, 都不会干扰测试项目的开发, 和对系统性能的分析.

注: 刚看了"应用程序性能测试的艺术", 知道了这个原来叫 关键性能指标(KPI, Key Performance Index).它指出有三个KPI,我觉得是挺有道理的. 他们是: 可靠性, 吞吐量 和 响应时间.其中可靠性要求运行性能测试达到一定时间.

* 当前项目新的调整
分成两个子项目
1) 子项目1
首先要把测试vu平均分成n组,
当一组启动后,运行 t分钟, 获取响应的throughput和90%线内的平均值.
启动下一组,
把每一组获取的数据收集, 绘制出两张核心的曲线图

顺便牢骚一下, 当前版本Jmeter对此还没有完美的支持. 我是启动多个Jmeter实例来达到这个目的.

2) 子项目2
根据曲线图, 估计出系统性能最佳时的vu(满足response time的最大throughput的vu数目)
这个vu作为性能regression test的基础

项目还在进行中. 希望这是我进入性能测试领域的一个好的开始.

3) 子项目3
根据曲线图, 估计出系统性能最佳时的VU.
以此VU作为基础, 长时间(2~3天)连续运行测试.

* 性能趋势图

一直以来把Multiline和Dotall模式混淆了,奇怪怎么一直都没有出问题?人品？
不过出来混总是要还的，　今天和一个同事讨论一个正则表达式终于"出丑"了．然后才把二者搞清楚．

* multiline
如果regexp里出现了^或者$, 那么by default只会匹配第一行. 设置了Multiline,会匹配所有行.
比如

• regexp: /^.*AAA.*$/
• src: "abcBBBdef\nsdfAAAfff\nsdf"
• without Multiline: 匹配失败
• with Multiline: 匹配成功

所有, 在regexp里出现了^$, Multiline才有意思, 否则是没有意义的.

* dotall
默认情况下, .不会匹配换行符, 设置了Dotall模式, .会匹配所有字符包括换行符
比如

• regexp: /BBB.*AAA/
• src: "abcBBBdef\nsdfAAAfff\nsdf"
• without Dotall: 匹配失败
• with Multiline: 匹配成功

这周，新的一段职业旅程从 Wincor 开始。
套用一句老话，“一切成绩都属于过去，现在必须面对未知的将来”

就是这样一个人，热爱工作，喜欢挑战

cheers!

一名好的测试工程师一定会掌握一种强大的编辑器，就像一定会掌握一种强大的脚本语言一样。

是吗？不是吗？是吗。。。

算了，我并不想被成为一个被贴上”武断“标签的人，我改正一下我的陈述，我确定一定以及肯定的说”掌握一种强大的编辑器一定能提高你的工作效率”。

某一天我看到一位同事在putty里费劲得用没有颜色高亮，也没有任何定制的vim编辑perl script，我真为他感到可惜。开源世界为我们提供了免费的vim和emacs，而且非常周到，在几乎所有平台都有编译后的程序，这样我们无论在那个os中都可以用我们最喜欢的Editor。即使这样，有一些天天在linux下面工作得测试工程师仍然不愿意尝试好好利用他们一下。

是的，我是vim的big fan，所以容许我在这里吹嘘一下vim。确实，vim（emacs也一样）有陡峭的学习曲线。但掌握了它们编辑文档的效率，相对于notepad，会是多么大的提高！而且这个技术你可以使用一辈子，20年后可能java，perl是已经被遗忘的语言，windows也会和吞吐纸带的怪物一样放进博物馆，但我确定vim仍然会像最好的朋友一样陪伴在你的身边，只要你还在编辑文档。

甚至，我还确定，那个时候你还是会觉得vim有好多有用功能你还没有发现，还会时不时为掌握了一个新的技巧，获得一个新的插件，了解了一点新的知识而小激动一下。

在计算机世界里还有什么玩意比它更美妙？你可以使用一辈子，学习一辈子。它像朋友一样默默支持你，还像情人一样总给你一点小惊喜。

浮云散尽，我发现我的手指在hjkl上微微起舞，左手食指以迅雷不及掩耳盗铃之势按在了esc上.
welcome to VIM!

因为马上就要离开目前的公司，开始一份新的工作。所以这几天老板也没有给我安排啥任务，所以就有时间来胡思乱想，就想到了跳槽这个问题。

以前写了篇blog，鼓励大伙儿跳槽，这样能获得更好的发展。其实呢，在EMC这样有一定历史的公司，我也能见到工作了10年20年的员工。他们的经验和能力都能得到大家的尊敬，即使仍然是一个engineer，所以他们的职业发展也是成功的。所以跳与不跳并不就决定成功与否。

这个感觉有点像投资一样。有人投资风险大的项目能赚钱，有人做价值投资业能赚钱。跳与不跳关键还是看你的性格。但是就目前我对中国软件测试行业的感觉来说，不跳的风险要相对大一点。

如果你是宁愿稳定点的人，一定要看清楚目前的公司是否值得你这样做。我觉得我本质上还是一个喜欢稳定的人，曾经在一个公司呆了三年多的时间。那个时候自己和同事都觉得公司的产品有问题，但觉得这个事情和我们研发没有什么关系，那是销售的问题。所以从没有想过要跳槽什么的，直到公司破产，自己也“被跳槽”。这个事情给我的教训是要去关注公司的销售，赢利，股票，要去关注公司在未来几年在市场上的竞争优势。（巧合的是，进EMC做new hire orientation的时候，HR的manager就说要关注公司股票，没有“钱途”的公司不要去）

另外一点对喜欢稳定的人不利的是，相对有多个工作经验的人来说，在应聘的时候处于劣势。这一点对于软件测试影响特别大。为什么这样说？因为软件测试本身并没有什么理论基础，绝大部分都是经验。如果一直以来你就测试一个feature，一个产品，熟悉一个流程，你的经验如何能”丰富“起来？

Team前段时间招聘一个sennior engineer，我也面试了一些candidates，对此感受特别明显。一直测试一个产品的candidate在测试方面很明显的让人感到思路要狭窄一些。

作为软件测试，我理想中的公司经验应该包括，大公司去镀金，技术领先公司去学习先进思想和技术，外包公司去经历高强度和高压力，小公司去锻炼多面手和全面控制质量的能力，去其他行业公司的软件部门去锻炼领悟能力。。。最后找一个startup公司等着上市兑换期权退休，或者找个大公司养老。

呵呵，这就是一个软件测试工程师的职业规划。 cheers！

看了 google中国测试经理 段念 的演讲。连接在这里 http://www.infoq.com/cn/presentations/duannian-agile-test

印象最深刻倒是和agile没有关系，而是最开始一张slide里对测试定义的演化。软件测试的目的不仅仅是1）找出bug，2）证明程序可用，而是要 揭示/提高/保证 软件的质量。

所以有上进心的测试工程师们，跳出 设计testcase，执行testcase，报告bug，verify bug 这样的小舞台，把眼光放到整个产品的质量上。我们还可以
1）如果你只关注功能测试，那么把眼光也放在其他各个层面的测试，从单元到集成到系统到用户验收测试
2）如果你的任务只是执行testcase，但是觉得testcase设计有问题，那么把他们报告给你的manager
3）如果在测试中你发现开发-测试的流程有问题，有更好的方式可以改善这点，不要犹豫，drive it becoming real.
4）积极的参与单元测试，从最底层就把质量控制在自己手中
5）有空的话去和技术支持聊聊，他们会告诉你他们的烦恼，特别是用户的issues
6）还有很多很多........

没有人比我们更关心软件的质量，也没有人比我们更了解如何提高软件的质量。所以承担自己的使命，告诉自己”我们要deliver最优秀的产品“。

如果你真的这样想，也这样做，我觉得测试的天地真的很大。测试也是一个充满激情，梦想，荣誉的工作。

总之，为了更高的软件质量，为了更有效率的测试，我们有很多事可以去做，可以去improve。
更好的测试层次
更好的testcaes
更好的测试执行流程
更好的问题解决流程
更好的自动化测试
没有最好只有更好，更更好,更更更好......


如果你进入了测试这一行，成为了一名测试工程师，那么就别再
抱怨测试没有开发受重视
犹豫测试的前途与钱途
争论手工测试技术含量高还是自动化测试
也别羡慕人家在google，而我在“无名氏”公司

一句话“哥不是在测试软件，而是在。。。。实现软件测试工程师的使命”
cheers!

做出了职业生涯最艰难的决定，还是选择了离开EMC研发中心，在这里我工作了2年半。

如果你没有在EMC研发中心(内部简称COE)呆过，你不会理解这是多么艰难的决定。作为上海顶级的研发中心之一，这里绝对是来了就不想离开的工作场所，舒适的办公环境，轻松的氛围，隔三差五的技术讲座，还有不错的薪水，周到的福利，漂亮的MM，你还能要求什么呢？！。

但是。。。但是，面对一些自己不能控制的情况，如果不能平静的接受，还不如主动的离开。一个公司不会因为一个个体而改变，离开或许才是对双方更好的结果。

无论如何我要感谢COE，因为在这里我又一次大幅度的超越了自己。

cheers!相信明天会更美好

   RFint是目前team测试的项目。它的大部分testcase已经ready，并开始了manualtest。现在要开始自动测试的开发。

测试环境

    * 一台celerra cabinate，包括至少两个datamover
    * 一台clariion作为后台storage
    * 若干linux client
    * 若干solaris client
    * 若干windows client
    * 也许还有hpunix client


1. 分层
主要分成3层。

最上层(distribution runner)
    主要负责处理“在多个client上运行测试”的问题。具体包括测试程序的deploy，execution and report generation。
    用ssh/scp来处理网络通信，用nfs/cifs server来处理文件共享/交换的问题。(don't invent wheels)
    这一层用bash开发

中间层(test runner)
    中间层包装test这样一个概念。test是一系列相关testsuite/testcase的集合
    test里所有的testsuite/testcase共享相同格式的testenv, testconf
    test里所有的testsuite/testcase共享library，实现代码重用。
    中间层还向最上层提供了统一的调用接口
    中间层可以用任何合适特定test的语言开发（向上的接口基于cli）
    test的范围的划分是考验经验的。小的test更容易理解，但代码重用性低。

最下层(test logic implemenation)
   具体的testsuite and testcase， 执行实际的测试逻辑
   在testsuite层次，所有的testcase可以共享testconf，setup，cleanup和library
   一般和中间层使用相同的开发语言

1. 从自动化测试的角度，测试可以分成两种
一种是数据驱动的，这是程序擅长的。
一种是过程驱动的，这是人类擅长的。

一般regular的testcase容易数据驱动
一般negative的testcase都是过程驱动的

应该尽可能把过程驱动的testcase转化为数据驱动的testcaes。

1. 如何把过程驱动的testcae转化为数据驱动的testcase
构造更通用的测试环境，满足更多的testcase
    比如有两个关于文件copy的case，一个是在folder内部copy，一个事跨folder copy，那么构造一个多folder的环境，就能满足这两个testcase的要求

构造更丰富的操作集合，包括多个testcase中的操作
    比如一个testcase是关于文件写操作，另外一个是关于文件读操作，那么构造一个既包括文件写又包括文件读的操作集合，就能实现这两个testcase的覆盖要求

关键字驱动
    有时候，仅仅是data还不足以覆盖所有的测试。这时，可以加少量能“影响”测试逻辑的关键字(keyword)。
    比如对于文件写有“同步”和“异步”两种，那么可以加入对应的关键字。但增加这样的关键字会提高测试逻辑的复杂性，所以一定要把握好度。

通过上面的方式，可以程序擅长的方式处理更多的testcase。
   
1. 自动化测试case和手工测试case不用一一对应
由上可见，自动化的case和手工测试的case很不一样，完全不应该一一对应。

1. 写简单的程序
最上层和中间层通过cli的方式调用，它们完全是独立的。

中间层和最下层是API级的，需要小心不要让他们联系太多。现在中间层只为最下层提供testenv, testconf和common library.

1. testresult打印到testlog里
没有专门的test result文件，而是打印到testlog里。这样的好处是
    简化了log的管理，framework的代码更简单
劣势是需要另外的程序来从testlog中吧result parse出来，在重新格式化。

1. setup/cleaup在那里执行的问题
在test level有setup和cleanup，这没有什么问题，但到底是testsuite还是testcase level加入setup/cleanup，这是一个问题。

现在的方案是在testsuite level。也就是在开始运行testsuite里的testcase之前，执行setup，然后依次执行testcase。 而不是，在运行每一个testcase前都运行setup。
这样的好处是，testcase可以实现自己的setup/cleanup，但framework不负责管理他们。

过早优化是万恶之源，无论是性能优化还是代码结构优化，还是算法优化，还是其他什么乱七八糟到优化。

所以我拥护unittest,refactory, and xp.

某天和一个朋友讨论“解决问题”的话题。他也是一名工程师，所以都有很多的experience，idea可以谈论。但最后我们都同意到最关键的两点。

1）narrow down
2）have a rest

第一点很好理解。对于第二点，我抄别人的一段话作为注解。

when you are tired and depressed of doing sth after a long time researching, attempting. Leave it away temporarily, have a rest, ease your mind, then come back again.you will find you are not that familiar with it... and you have to go through it briefly so that you can continue your work, and right this activity may lead you to a way to solving this problem.

在EMC工作了2年多，我最感激的地方是我解决问题的能力提高了一大截。它对我职业影响的重要性，甚至可以等同于我入行的第一个公司Webex。解决问题能力的提高，不仅仅是解决了问题，更重要的是能极大的提升你的自信。特别是在解决棘手问题过程中建立起来的自信。

1）    永远要有“没有解决不了的问题“这样一种信念

这不是自欺欺人。即使有一个问题真的超出了你现在的能力范围，你也可以“解决它”，参考7）。

2）    充分利用资源

按求助的先后次序：同事，google，公司内部网络上的知识站点。。。

3）    清醒的头脑

先做什么，后做什么。在纸上规划好处理问题的次序。特别在时间紧的情况下，不要抓狂。

4）    联想能力

更确切说，是从各种能获取的信息中，找到解决问题的线索。比如日志，系统资源占用情况等，都可能会有蛛丝马迹。

5）    技术背景知识和经验

人不可能解决陌生的问题。解决问题不能是“瞎猫碰到死耗子“的方式。所以，解决问题的首要阶段就是熟悉背景知识。如果你具有相关的技术背景知识，那么你就可以更快的解决问题。

6）    分析能力

分析和判断更可能出问题的因素和地方。可以更快的接近问题的根源。

7）    如果你确实解决不了

能说明白为什么你解决不了。你进行了那些分析，尝试。如果可能的话，提出可行的替代方法。这样，在你的上司眼里，你其实已经解决了问题。你要知道有时候证明“这个问题我无法解决“其实也就解决了问题。

8）    如果解决了问题，一定要把过程记录下来

经验就是这样积累的。而且自己写下来的东西，印象更深刻。

隔一段时间，就有人msn加我要了解锐柯(carestream)的情况。我真的感到很奇怪，因为虽然我有几篇文章是关于锐柯的，但我实际上只在锐柯呆了区区三个月，而且已经离开锐柯快两年了，这些都在blog里有提及。怎么还有人找我了解锐柯的情况呢？ 锐柯有那么多员工，很多都是从Kodak Medical Group的时代就在这里工作了，应该有更多比我更好的渠道来了解锐柯才是。

奇怪之余，我google了一下“锐柯”，to my surprise, 我的一篇blog竟然排名第二！绝对令人难以置信的事情。由此，我能判定，锐柯是一个多么低调的公司！

技术与市场

忙碌的一周，都在做向Celerra迁移的工作。

看来Rainfinity的时代是真正结束了。在去年年底，Rainfinity作为一个独立的biz unit已经宣布结束了运作。组织结构开始调整，到现在，QAteam终于正式开始为测试Celerra的feature做准备了。

Rainfinity从产品本身来说，绝对是一个凝聚了众多优秀工程师智慧，经过千锤百炼的产品。特别是Berlin这个release，第一次在nas中统一了NFS和CIFS。它设计难度之大，我在测试过程中式深有体会。但是不幸的是，Rainfinity始终并没有像Vmware，celerra，Clarrion等这些产品线，成为EMC的中流砥柱，成为市场上的宠儿。Rainfinity瞄准了一个市场，进入了这个市场，生产出了合格的产品，占领并统治了这个市场，一切看来都很好，但问题是，市场变化的速度超出了预料，市场在快速的萎缩。没有客户的产品，无聊它的质量是多么高，也是一文不值。

作为为这个产品工作了多年的工程师，也会有些失落和可惜，有时感觉这些年辛勤付出的劳动，那些激动人心的发现bug的过程，好像也变得没有了价值。但对于EMC这样一个Result-Driven的公司来说，壮士断腕的行为从来都是进行得干脆利落，毫不犹豫的。“白猫黑猫，抓住耗子的就是好猫“。没有市场的产品，弃之也毫不为过。

工程师和CEO看问题的角度显然不一样。工程师太容易陷入产品实现技术之本身，精雕细琢，细细把玩，而不太注意了产品在市场上的表现，或者产品市场的变化和趋势。这样其实并不好。这样看问题的眼光太短浅。

在看一个产品的时候，不仅仅要从技术角度，看它的架构，质量，也要从市场角度看它的竞争力和前景。只有这样，才能选择到好的产品，好公司，自己的辛勤付出才能有最大的回报；否则纵然有千般本领，不能选择到好的产品，产品没有市场，那么也不能带来自己价值的最大化。因为EMC是一个大公司，所以东边不亮，西边亮，还可以转到另外的Team，如果是一个小公司，就这样一个独苗产品，那么这就要关门大吉了！

从这一点来说，这个事情给我一个很好的提醒。

EMC是一个很注重市场，很注重为客户带来价值的公司。即使在COE这样的研发中心也有GTM（Go To Market）这样program，帮助Engineer获得更多市场的信息，客户的反映。再加上EMC在行业内的地位，我以后应该有很多机会来锻炼自己对存储市场的分析和把握能力。

 

出现的问题
FTA的schd project是我对TA反思后的第一个项目。本来以为经过前段时间充分的总结，这个项目不会有什么问题。但是项目结束后发现，最大的问题是架构部分代码（非测试逻辑本身的代码）竟然有多次重构。

理想情况下，在开发过程中，对系统核心部分的重构应该是很少的，因为这种重构的风险非常大。FTA是一个比较小的项目，所以还能控制不出问题。如果项目比较大，或者test suite比较多，情况就不好说了。

分析原因
1）testcase定义和执行流程一开始就考虑不成熟。
framework里关于如何执行testcase部分进行了多次重构。部分原因是framework并不全是我设计，还要兼容已有的系统，所以存在束手束脚的地方。也有部分原因是我对执行过程的考虑不成熟。

总的来说，这个问题可以通过通用框架TAS的成熟在一定程度上解决。

2）开始阶段考虑的testcase种类太少
因为开始阶段考虑的testcase种类太少，所以随着新的testcase的加入，不得不修改已有的架构来适应新的需求。比如library会进一步的细分，test parameter的格式定义。。。

如何提高
将来需要注意增强分析阶段的能力。特别是在系统还未成形，只是脑袋里的一个模型的时候，如何在其基础上进行分析，判断，进化出更好的架构。这种分析的步骤是这样的
   a）细致的问题分析
   b）把实际的问题转化为脑袋里运行的“程序模型”（借助纸和笔）
   c）在这个运行过程中，找出已有架构不满足当前运行要求的地方
   d）在这个运行过程中，综合已有testcase，发现需要共享的library

进行积极的预判。在开始阶段，可能所有人都不明白到底要自动化多少caes。对于设计者来说，要从case重要性和自动化可能性的角度判断未来可能会自动化的case，并在设计之初就在一定程度上把他们考虑进去。

即使如此，我还是要再次明确”考虑得少“并不是一个绝对的错误。前面已有文章反思考虑得太多会引起的问题。所 以，这是一个需要小心平衡的事情。这需要更多的经验积累才能达到做一个项目的过程中“即不会出现overdesign，也不会频繁的重构已有的代码”

做FTA项目收获蛮多，大多数想法都在TAS里实现了。还有一些觉得重要的零散的东西，记录于下。

• 在分析testcase的时候，把所有的元素分成测试参数，测试逻辑和测试环境。
• 用关键词加相应的数据来描述一个testcase
• 把测试准备和测试验证点分成不同的方法来实现
• 把不同的验证点分成不同的方法来实现
• 每一个testcase有一个setup和clean方法来处理对环境的准备和清理
• Testcase要薄，把实际的访问代码放在library层
• 如何兼容非data-driven的testcase