已经进入2013的一到两个月了，我们决定在新的一年里，制定在余下的10个月如何提高大家的管理流程的方法。在接下来的5天，我们将列出50个改进思路，你可以考虑实施。下面为大家列出前10个：
1、查看报告
测试管理工具捕获数据的主要目的之一是为了让你可以了解你的项目中的各个方面，例如进步、资源利用、和目标。如果您目前正在创建的报告不会触发必
要的修改，那么你应该开始质疑这些报告的目的。也许是时候开始问自己和其他参与人，这样的信息真的会帮助您的开发和QA 项目。
2、为你的团队找一个行政助理
与许多其他职业一样，QA 工程师和经理日常都要完成很多管理任务。
这就可能需要人力资源，利用齐心协力的做月度报告。
问问你自己如果这些类型的任务能够找人来承担，它会不会更有效率（无论是在时间和成本）？你永远不知道他们甚至可能比你做的更好！而你能很好的利用你的时间和精力。
3、改善项目估算
估计的工作量参与QA 项目是我们的工作的一部分。即使我们承认这是一个“how long is a piece of string” 问题，我们要知道项目经理对整个项目生命周期中这类信息的要求。如果你一直在捕捉这类信息（如平均时间执行一组），那么通过这些记录对工程的回归测试部分所花费的时间比你认为的还要简单。即使这小块信息，如果你将它用于将来的项目也能增加你的资源需求的可信度。
4、集成需求管理
同时根据需求创建 testcase 仅仅是QA 拼图中一个重要的部分。如果你的测试人员发现用其他测试管理工具更容易实现他们要求的，那么他们更容易创建有意义的测试。永远不要低估一个小case。对一个新的需求用你的测试管理工具可以使生产力大幅提高。
我们越容易完成的任务， QA 工程师才可能有更多的能量和精力投入开发新产品。
5、让您更多的支持合同
当我们开始使用新的测试管理解决方案，我们将毫不犹豫地从工具供应商呼吁支持团队。然而，随着我们的使用的工具被取代，我们开始寻找解决我们遇到的问题。有时似乎比通过花几个小时或者寻求工程师帮助更容易解决问题。所以我们从未真正开始考虑过解决这些问题，而是满足于低效的变通方法，成本我们的时间、精力和金钱。找出那些问题和寻求改善他们。呼吁支持团队使用您的测试管理工具来帮助你找到解决和提高效率的方法。
6、内部支持
你上次是什么时候被意识到在你的团队中已经有人已经熟悉掌握了这个工具？ 你上次是什么时候在你的团队或者问任何人，他们有问题吗？我们假设，如果一切都是安静的，一切都是好的。这并非总是这样的。
在你的团队中提名有丰富的经验的人作为一个内部支持资源。你会惊奇地发现很多人开始呼吁，内部支持的人。
7、捕获数据
我们都开始用伟大的思想来捕获和记录数据和复杂的业务流程和复杂的数据输入表单。在团队中这种热情很快减弱。因此，人们要么开始输入错误数据或他们开始绕过这个过程。问问你自己如果这个过程或这个特定的块数据确实需要捕捉。我们真的报告和作用于这些数据？如果不是本它，让你的生命QA工程师更容易（和更富有成效）。
8、由第三方审核
不管我们喜欢与否，我们都会定位在我们的方式在某种程度上。我们被锁在一个沟，我们很少拉自己。这是人的本性。现在你可能会有一个奇妙的想法，他是朝着正确方向的常规做法，它是否由于公司的其他方法？有时它值得有人在用一个新的视角来审视你的方法是好。这是非常罕见的，人们发现他们做的是完美的。我们都能从别人在某个点学到新东西。为什么不看看有新的东西可以学习，看看第三方可以帮助你让那些改进？
9、升级到最新版本
有多少公司已经实施了一个测试管理工具和从未腾出时间去升级到最新版本？必须有不少。太容易就凑合一下我们有。你真的了解在你的过程一个过时的版本是阻碍你前进，创造效率低下吗？花一个小时来找出哪些功能已经实现在以后的版本那些新的或改进的功能可以带给您的团队什么好处。
10、看动态代码检查工具
太容易认为游戏只有手动和自动化测试。不要忽视其他工具，如静态代码分析工具。虽然，也许你已经避免了因为你没有技能在你的团队来实现这样一个工具。如果你没有足够的能力为什么不配对测试人员与开发人员，让他们实现他们之间的静态代码检查工具呢？测试和开发可能看起来几英里远，但出人意料的是，有效的一个好的开发/测试配对可以。
在创建非静态内部类时，经常会遇到“No enclosing instance of type * is accessible. Must qualify the allocation with an enclosing instance of type *(e.g. x.new A() where x is an instance of *).”这样的报错，其实原因只有一点，内部类是依赖于外部类存在的，所以在使用非静态内部类时，要求先实例化外部类才可以使用内部类。关于非静态内部类，我们可以把它理解成外部类的成员变量，我们在使用一个类的非静态成员变量时要求先对类进行实例化，然后通过对象来调用这个类的非静态成员变量。这里非静态内部类同外部类的关系，就如同非静态成员变量同类的关系一样。所以在使用非静态内部类时，要求先实例化外部类。
下面我给出例子来分析一下：
package com.csc.innerclasstest;
/**
*
* @author csc
*
*/
//外部类
public class OuterClass { /**
* @param args
*/
public static void main(String[] args) {
InnerClass innerClass = new InnerClass();
innerClass.say();
System.out.println("I am in OuterClass!");
}
//定义一个内部类
private class InnerClass{
private void say() {
System.out.println("I am in InnerClass!");
}
} } |
上面的代码的第16行将会报出“No enclosing instance of type OuterClass is accessible. Must qualify the allocation with an enclosing instance of type OuterClass (e.g. x.new A() where x is an instance of OuterClass).”这样的编译错误。错误的原因如上面红色字体所述。
解决方法一：将非静态内部类转换成静态内部类，即在上面程序的第21行的“Private”后面加上“Static”即可。
解决方法二：先实例化外部类，然后通过外部类来调用内部类的构造函数，代码如下：
package com.csc.innerclasstest;
/**
*
* @author csc
*
*/
//外部类
public class OuterClass { /**
* @param args
*/
public static void main(String[] args) {
//实例化外部类
OuterClass outerClass = new OuterClass();
//通过外部类引用内部类
InnerClass innerClass = outerClass.new InnerClass();
innerClass.say();
System.out.println("I am in OuterClass!");
}
//定义一个内部类
private class InnerClass{
private void say() {
System.out.println("I am in InnerClass!");
}
} } |
上面代码的16行先进行了外部类的实例化，第18行通过外部类来引用内部类，这样就不会出现“No enclosing instance of type OuterClass is accessible. Must qualify the allocation with an enclosing instance of type OuterClass (e.g. x.new A() where x is an instance of OuterClass”这个编译报错了。
本文转载自：http://blog.csdn.net/caoshichao520326/article/details/8961297
谈到
测试人员的发展，首先再回过头来看看整个项目期间测试人员做的事情或者说能够做的事情吧以及需要具备的对应的能力吧！
1、版本或者产品的规划阶段：作为一个测试人员，这个时候可以从一个更高的角度对产品的规划提出自己的想法，来更好的帮助产品取得成功。
需要具备的能力或者知识：对于产品的商业理解以及整个行业和市场的理解都比较深入，实际上这个时候我们可以将自己看成是一个产品经理
2、版本的需求阶段：测试人员已经能够开始做需求阶段的缺陷预防，保证需求是能够满足用户的原始需求，并且整个需求都是非常清晰和合理的，版 本后期没有需求不合理或者需求不清晰的问题
需要具备的能力或者知识：对于客户的使用场景非常清楚，能够在客户角度上面思考问题；有自己的一套需求分析的方法，最好是模型或者checklist之类的；非常好的分析能力，能够通过需求文档分析到可能潜在的问题
3、设计阶段：测试人员开始做设计阶段的缺陷预防，能够对于研发的整个设计方案非常清楚，能够根据研发设计文档里面的业务逻辑图自己能够站在测试的角度来画出一份让测试人员更加容易理解的业务逻辑图，并且能够发现研发在设计方案上存在的一些问题，并且指导研发进行修改
需要具备的能力或者知识：比较深入的业务背景知识；熟悉开发使用的语言；业务分析和转换的能力；
4、编码阶段：测试人员开始编写单元测试、接口测试用例、测试工具或者自动化测试用例，并且开始思考后面如何去更好的测试（更高的效率，更好的保证质量），并且帮助研发提前做好编码阶段的缺陷预防，甚至做得测试驱动开发
需要具备的能力或者技能：熟悉开发使用的编码语言、能够对开发的代码进行静态走读、熟悉开发使用的编码语言的单元或者接口测试方法和框架、具备测试工具开发的能力、具备自动化的能力，良好的代码分析能力和用例设计能力
5、测试阶段：测试人员开始制定测试策略和测试计划、执行测试用例、发现和定位bug、跟踪和回归bug，质量分析，有效的探索性测试等等，目的是花更短的时间来更好的保证质量
具备的能力或者技能：制定策略和计划的能力、执行能力、分析和排查问题的能力，业务的理解能力，对代码的熟悉程度，模块的质量分析能力等等！
ok，总结下上面用到的一些能力和技能，以及每种能力对自己的帮助
1、产品的商业理解能力--产品经理（马云、马化腾、周鸿祎等都是这样的人）
2、需求的分析能力和市场的理解能力--也是向产品经理方向发展
3、业务背景知识--能够让自己在该领域走的更远
4、开发使用的编程语言--这个应该是自己深入到代码级别一个比较基础的东西，对于自己对代码进行测试是非常有帮助的
5、业务的分析能力---养成这样的习惯后会有一套自己的分析方法，对于自己在测试领域的发展的很有帮助的，现在测试界的一些公共测试技术里面就有包含这些
6、单元测试能力--这个让自己走向白盒测试工程师是很有帮助的，也是能够让自己跟开发走的更紧点
7、接口测试能力--应该是向单元测试的一个过渡，能够让自己更好的接触到业务逻辑
8、自动化开发能力和工具开发能力--这个就不用说了，现在已经有专门的自动化人员和工具开发人员了
9、用例设计和测试分析能力--测试人员一个很基本的能力，但是真正做好的其实比较少，如果用例设计的质量很高的人其他方面的能力肯定很不错，而且有了自己的一套方法后对于自己在测试领域的发展是很有帮助的，需要不断的总结和分析，将经验抽象为方法或者模型
10、执行能力--测试人员（应该是所有的工作）都需要具备的一个能力吧，如果做好的话其实对自己的帮助也是比较大的
11、发现bug的能力--这个时候对于测试人员的发散思维很重要（个人觉得是衡量真正的测试人员一个比较最重要因素，没有之一），有些测试人员就是能够沉迷于此
12、定位bug的能力--其实这应该是测试人员一个很基本的技能，但是我们都是交给研发去做了，如果将前期的工作做起来的话，我们是应该具备这样的能力的
13、分析和排查问题的能力--分析能力是测试人员一个非常重要的能力，一个好的测试人员总是能够根据目前的一些现象发现一些本质上面的东西，并且有自己的解决问题的方法
14、制定策略和计划的能力--这个发展方向应该是项目经理或者管理方向吧，但是对于测试人员也是很有帮助的，对于自己从一个整理上面理解问题很有帮助
当然，以上这些能力测试人员不用每一项都掌握的非常熟练，可以根据职业发展方向归纳为如下几项：
1、产品经理
2、白盒测试工程师（叫开发测试工程师其实更加合适）
3、自动化开发工程师
4、资深的测试工程师或者测试专家（可能需要包括以上超过10个技能并且能力都要达到一定级别）
5、项目经理
其他的几点就不说了，这里重点说下达到资深的测试工程师或者测试专家（其实就是测试界的大牛）级别需要的一些条件吧！这个也是笔者一直比较欣赏的一个职业，可是目前这方面的人确实比较少，很多人半路走上了管理岗位，笔者就是一个例子！
1、看下自己是否真的适合这样的职业（很享受去发现一些bug，特别是经过自己思考后发现的一些别人没有发现的bug），这个可以在刚进入测试行业就看出来
2、一个好的平台：从目前来看，很多公司是没有办法给一个测试人员提供学习以上能力的机会的，建议是能够尽量找到这样的一个平台（当然也需要不断的证明自己是一个人才）
3、在一线测试呆尽量长的时间，并且反复磨练自己上面的一些能力（没有最高只有更高），这就是所谓的十年磨一剑，这样需要很大的勇气，但是在这个浮躁的行业里面做到坚持实际上是很难的，很多人都是耐不住寂寞的。如果你做到了你就赢了
4、不断的积累的和总结（总结是自己获得经验一个非常宝贵的方法，也是让自己进步更快的一个方法）
5、开始将自己的一些方法抽象出来，形成一些比较通用的方法，并且不断的尝试运用到实践中，证明这个方法是ok的，形成一些理论
6、完善，实践，推广，再完善，再实践，再推广.....相信这个时候，你已经是数一数二的高手了，再加上自己的一些推销自己的方法，提升自己的品牌意识，剩下的就不用说了，当然，学习无止境..........
版权声明：本文出自 pengyongbo 的51Testing软件测试博客：http://www.51testing.com/?181625
原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。
013 已经悄然来临，新年就来个新吐槽，主要是针对
测试行业的，有些个人观点和大家一起分享。
这里事先声明，没有对与错，只有适合还是不合适，纯粹是个人的观点。
1、整体的测试行业
其实说实话测试这个行业一直处于叫的高但实质并不高，说俗点就是薪水其实一般般的状态。我个人觉得有下面的几个原因：
1）纯技术能力不强
2）公司对测试定位不高
3）公司对测试没有正确的理解
2、测试技术方面
对于测试技术来说，无非就是手工功能，自动化功能、性能、安全、自动化框架、单元测试一堆乱七八糟的东西，我们自己冷静的想想真的需要这么多吗？每个技术对于我们真的有用吗？
无非就是这些原因，黑的白的大家都心知肚明，这个东西不是你想改变就能改变的，需要一定的动力才可能会有效，这个真的随命。
个人觉得，真不需要这么多，我一直觉得一个人的价值的多少和他所掌握的技术并没有多大关系。
我就拿一个简单的例子，单元测试来说。真的所有公司都需要这种测试吗？我的回答是NO。个人觉得任何技术，尤其是你在商业化公司里，技术都是为产品，或者说是为需求服务的，你想想，如果你在一个互联网公司，一天的需求就变化n 次，你单元的了吗？你有这精力吗？
当然我们不排除像百度、腾讯这样大公司有这样的人力、精力来做这个，但中国有几个这样的大公司？所以用适当的技术做适当的事情，给公司带来最大的投入产出比才是最实用的。
当然，我并不是否认单元测试的存在，对于一些政府类产品，军工类产品，这样的东西本身需求就不会有大变动，而且涉及到安全机密的敏感信息，做单元测试当然需要，这个是有意义的。
所以，我个人觉得，一个人的价值在于能给产品或部门或公司带来多大的性价比，而不是单纯的技术多牛逼。适合的才是最好的，这句话说的一点都没错，有时候最好的未必适合。
3、测试职位方面
对于这个，我个人觉得腾讯在职位划分方面做的比较好，我们无非能看到，测试工程师，测试开发工程师，系统测试工程师、性能测试工程师、自动化测试工程师、安全测试工程师、测试主管、测试经理、测试总监等等这样的职位我个人一直觉得，不是你做性能测试或自动化测试就多牛逼牛逼，做功能测试就 多不行，我觉得这是中国人传统思维导致的。其实我想大家不难发现很多公司的测试经理他们的技术能力并不强，但他们的组织、划分、管理、需求的把握能力却很 强，所以我一直觉得单纯的以技术为资本很难有大的发展，看看现在的ceo 等等有多少是纯技术出生的？？？？？很少吧。我不否认有，但这样的小概率事件，我觉得常人还是不要尝试好了。
我之前读过郎咸平说经济的那本书，里面就分析了诸葛亮草船借箭的典故，我觉得分析的太有道理了，建议大家去看看，完全和我们正常人的分析不一样，也赤裸裸的揭穿了中国人崇拜牛人，英雄的这种情节。
4、测试流程方面
其实对于一个公司或一个部门而言，流程的规范与适用性是很重要，技术应该服务于我们的产品、流程，单纯意义上的技术独立对于商业化的公司而言没有多大的 意义。我们不需要照搬任何公司的流程，应该借鉴他们的流程改为适合自己的东西，这不丢人，也不可耻。就好比，很多人都骂腾讯的“盗版”，我恰恰相反，我很 欣赏，当然不是说欣赏他们的这种行为，我是欣赏人家腾讯能把你做的东西变的更好，更贴近用户，这就是人家的价值，自己抓不住用户就去怪别人，很搞笑，就像 郭德纲相声里说的讽刺同行那几个段子一样。
5、各种企业中的测试岗位 岗位无非还是上面说的那些，我这里是想讲讲外企。很多人想进入外企，但其实现在很多都是假外企，说白了就是在国外注册的，或者是以国外公司的名义做那种外包，这都是挂着羊头卖狗肉的，就是看重了中国的便宜劳动力，这种企业现在太多了。
另外就是，日、韩、欧美，这几个大的外企分类了，我先声明纯属个人观点，我没有亲自经历过所有的外企，有的是通过朋友知道的，观点这个东西完全 是根据个人的思维和观念产出的，所以你大可不必较真我的观点，赞同就顶一个，不赞同就笑一个，不需要破口大骂，这是很弱智的表现。
上面说的这三种外企，他们的文化差异非常的大，所以我们选择外企的时候真的需要好好考虑，不是所有的外企都适合自己。至于他们有什么风格，自己去百度吧，我就不说太多了。
6、面试与薪水
面试我经历的真不算少了，这点我不谦虚，因为我个人不太爱找关系，一般都是评自己能力去应聘，万不得已才找找比较硬的关系。我们现在的面试流 程，大致都是N轮，还有什么笔试啊什么的，个人感觉真无聊，笔试能看出能力吗？成天就问问算法啊什么的，傻子都倒背如流了，何必呢？个人觉得面试一个人应 该关注他的思维、他的个性、他的观点、他的潜在能力，这样的人是有培养和发展前景的，说白点高手面试就是一种投资，不要整那些有的没的，有意思吗？还有就 是轮次，现在的企业都很精明，一般都不会一次告诉你结果，因为他们在做对比，如果他们对比了一圈发现你是性价比高的，难听点就是廉价劳动力，那么他们才会 和你谈，所以企业很鄙夷，咱们也不用那么伟大，玩点手段，强势点，没什么不好，低声下气何必呢？
薪水这方面，我一直觉得我们80后就是很实在很苦逼的一代，当然除了那些有背景有关系的，我们普通老百姓的孩子，就是实在，要钱方面太保守了， 严重成为廉价劳动力。首先我说明，我没那么高尚，我就是俗人一个，基本的生活保证我们是需要争取的，是有权力的，不要把自己想的多么伟大，就像《家的n次 方》里面的台词一样，面子是别人给你的，不是你自己给自己的，一个道理。现实就是残酷的，不要憧憬太多的美好，美好永远都是残酷后积累出来的。
现在很多刚毕业的孩子，要价那个高啊，我曾经碰到过的没什么经验，开口就是上万，我就崩溃了，突然觉得这个世界确实是疯了。我没有诋毁的意思， 只是觉的我们确实应该根据自己的价值来要钱，不能轻易的贬低自己，这恰恰是80 后一代范的错误。我目前的能力+潜在的能力就值这个数，那就要这个数，没有什么好不好意思的。
7、其他
个人觉得30 岁之前应该跟对人、做对事，这是第一，其二才是挣的钱，可惜我明白的这个道理有点晚了，如果早几年明白可能会有很大的不同。
我们没有必要刻意的去羡慕其他人，就好比你是互联网行业的，他是传统行业的，本来就属于不同行业，行业特点极度的不一致，就没有可比性嘛，所以不必羡慕啊。
另外，个人觉得如果你想体现自己的价值，创业型的企业或高速发展的企业或是企业平均年龄很年轻的会比较适合，一个毛毛孩想去大公司体现你的价值，除非你有后台，不然太难了，不过你要想体验权力斗争可以去试试，保证你爽的不知道东南西北了。
小结
其实还有很多想写的想说，但写的写的就忘了，呵呵，现在已经属于提笔忘字的境界了，就唠叨到这吧，再次声明，纯属个人观点，没有任何比较、诋毁的意思，赞同的顶，不赞同的您就当看一乐。
最后祝大家新年发大财吧！
“意识决定行动，行动决定结果”是管理学中众所周知的名言。做
测试的前几年，笔者并没有这个意识，也没有主动地去思考过这个问题，但随着一个个项目任务、一桩桩事件的历练，慢慢感悟到这句话也适合对测试
工作境界的理解。“心态决定命运”，“态度决定一切”，有很多名家学者都写过这方面的书籍，基本上已成了我们不可否认的真理了，但是要真正应用在自己的工作
生活中，恐怕就不那么简单了。诚然，测试工作，除了需要拥有过硬的测试技术外，还必须有正确的测试心态，也正是这些心态意识左右着你的日常工作。不同的心态反映了不同的测试境界高度，最终体现出不同的结果。
围着Bug转， 是测试三重境界中的第一重。概括起来，它又可以分为三个阶段，第一，发现Bug；第二，定位Bug；第三，关闭Bug。这三个阶段对测试人员的要求不仅在 技术上需要逐层递进，在综合素质上也提出更高的要求。三个阶段之间环环相扣。直到Bug的生命周期结束。围着Bug转的三个阶段对测试人员的要求及Bug 被发现到关闭的生命周期示意图。如图2-5所示。
图2-5 围着Bug转的三个进阶图
谈到围着Bug转的的三个阶段，不禁想起中国近代著名学者王国维在《人间词话》中提到的人生的三重境界：“昨夜西风凋碧树，独上高楼，望尽天涯路”。“衣带渐宽终不悔，为伊消得人憔悴”。“众里寻他千百度，蓦然回首，那人却在灯火阑珊处”。
细细思量，感觉它们之间亦有异曲同工之处。
第一重“昨夜西风凋碧树，独上高楼，望尽天涯路”是说“古今之成大事业、大学问者，首先要树立明确的目标，即使长路漫漫，也下定决心将这条长路走下去。 这是一个人在孤独之中寻找理想、寻找生命的落脚点的痛苦时刻”。围着Bug转的第一阶“发现Bug”，同样首先必须有明确清晰的目标，找Bug的过程是漫 长的，反反复复、枯燥无味是工作的特点，但是为了达到目标“长路再漫漫，也得坚持走下去”，直到找到一堆堆的Bug。特别是对一些偶现的严重Bug，重现 Bug的过程真如大海捞针，但是坚持就是胜利。笔者曾经在经历的一个项目中，花了近1个月的时间去重现与解决一个严重问题，最后在与开发人员的紧密合作 下，终于找到问题的根源。
第二重“衣带渐宽终不悔，为伊消得人憔悴”是说“执着的追求、忘我的奋斗，直至憔 悴消瘦，连衣服都变得宽大，这一切努力都是为了心中的梦想”。对应软测中围着Bug转的第二阶“定位Bug”。这一阶段不仅在技术上提出了更高的要求，还 要有刻苦钻研、穷追到底、不撞南墙不回头的执著精神，直到把问题的原因搞清楚才罢休。在国内目前的测试领域，大部分公司这一步并没有要求测试人员来做，但 是在国外，特别是一些知名的大公司，如在微软， 几乎所有的测试人员都拥有深入调试程序的技能。它除了包含以最短路径重现问题，还要分析问题的可能结果（例如分析Bug会影响到哪些模块），甚至给开发人 员提出解决方案。显然，这一步要求测试人员要比开发人员具有更高的设计分析能力、代码调试能力、解决问题的能力。读者朋友，看到这里，对一些测试专业网上 常看到的“测试人员是否要懂编程”这一问题已释然于怀了吧。
第三重“众里寻他千百度，蓦然回首，那人却在灯 火阑珊处”。这一阶段是指经过不断磨炼，多次的失败，某一时刻忽然灵犀一点，领悟真谛，发现自己想要的东西原来就在自己的身边或领悟后的心里。在旁人看 来，他的“蓦然回首”是如何偶然而幸运，但其背后的用功之勤、平时的积累之深，又岂是常人所能坚持，所能想象的呢？这时候，世俗目标是否已经达到已不再重 要，重要的是灵魂的解放和心灵的归属。对应围着Bug转的第三阶“关闭Bug”，如果仅从字面理解，很简单，不就是开发解决了Bug，回归Bug，然后把 Bug关闭。如果是这样，笔者认为这种观念仍属于第一阶。第三阶的关闭Bug，是指测试人员提交一个Bug后，要有主动意识推动开发人员解决问题，并协助 他们解决，只有问题解决了，软件的质量才得以提高，测试人员的最终目的才能达到。提交的有些问题严格来说，它不属于Bug，而是一种设计缺陷，此时测试人 员该怎么办呢？需主动召集相关专家进行其影响面的风险分析，并跟进此问题的整个解决过程，如果风险点涉及其他专业的更改（如嵌入式软件涉及硬件、机械等方 面的知识），可能需要专门成立一个专项问题解决团队，以全面解决此问题，直到各专业方向的问题解决到位，回归验证完成，此Bug方能关闭。站在Bug的生 命周期角度分析，一个Bug由被发现的起点，走到被关闭的终点，才是一个合理的、完整的过程，如图2-6所示。但是要达到这一层，很可能有一大部分的工作 已完全脱离了纯软件测试层面的工作，可是测试的最终目标不就是给用户一个高质量、信得过的产品吗？我们需要有这样的大气胸怀，才能把产品的测试工作做得更深远、更宽阔。
接下来结合案例对围着Bug转的三个阶段分别进行介绍。
一、判断题： 1、软件测试的目的是尽可能多的找出软件的缺陷。（T）
2、Beta 测试是验收测试的一种。（T）
3、单元测试能发现约80%的软件缺陷。（T）
4、代码评审是检查源代码是否达到模块设计的要求。（F）
5、自底向上集成需要测试员编写驱动程序。（T）
6、负载测试是验证要检验的系统的能力最高能达到什么程度。（F）
7、测试人员要坚持原则，缺陷未修复完坚决不予通过。（F）
8、代码评审员一般由测试员担任。（T）
二、选择题（不定项）：
1、下列关于alpha 测试的描述中正确的是：（AD）
A．alpha 测试需要用户代表参加
B．alpha 测试不需要用户代表参加
C．alpha 测试是系统测试的一种
D．alpha 测试是验收测试的一种
2、测试设计员的职责有：（BC）
A．制定测试计划
B．设计测试用例
C．设计测试过程、脚本
D．评估测试活动
3、测试结束的标准是什么？（ABCD）
A．用例全部测试。
B．覆盖率达到标准。
C．缺陷率达到标准。
D．其他指标达到质量标准
4、10%3=？（A）
A.1
B.3
C.0
D.10
5、是一道关于try catch finally的程序题
正常情况无论走try还是catch下走都会走finally
但是在try中有个System.exit（0）所以不会走finally，已经用程序证实过。
三、填空
对面向过程的系统采用的集成策略有____、____两种（自顶向下、自底向上）
四、简答题 1、白盒测试有几种方法 ？
白盒测试方法分为：静态测试和动态测试
静态测试方法：
1、编码标准与准侧
2、走查
3、审查
4、评审
动态测试方法：语句覆盖 、判定覆盖 、条件覆盖 、判定-条件覆盖 、 条件-组合覆盖 、路径覆盖 、条件组合-路径覆盖
2、软件的缺陷等级应如何划分？
A类—严重错误，包括以下各种错误：
1）由于程序所引起的死机，非法退出
2）死循环
3）数据库发生死锁
4）因错误操作导致的程序中断
5）功能错误
6）与数据库连接错误
7）数据通讯错误
B类—较严重错误，包括以下各种错误：
1）程序错误
2）程序接口错误
3）数据库的表、业务规则、缺省值未加完整性等约束条件
C类—一般性错误，包括以下各种错误：
1）操作界面错误（包括数据窗口内列名定义、含义是否一致）
2）打印内容、格式错误
3）简单的输入限制未放在前台进行控制
4）删除操作未给出提示
5）数据库表中有过多的空字段
3、写一个简单的Singleton出来。
Singleton模式主要作用是保证在Java应用程序中，一个类Class只有一个实例存在。
public class Singleton {
private Singleton(){}
//在自己内部定义自己一个实例，是不是很奇怪？
//注意这是private 只供内部调用
private static Singleton instance = new Singleton();
//这里提供了一个供外部访问本class的静态方法，可以直接访问
public static Singleton getInstance() {
return instance;
}
} |
原帖地址：http://bbs.51testing.com/thread-962796-1-1.html
版权声明：本文由会员 赵佳乐SMILE 首发于51Testing软件测试论坛九周年庆活动。
原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。
当你套用Athrun、Robotium等框架，针对自己的项目写完了一堆
自动化测试脚本后，在Eclipse之外怎么让它们可以持续性地跑起来并展现报告呢？
据我了解，方便的方法大致有两个：其一，利用Hudson（或Jenkins）持续集成系统；其二、利用Testin或东软易测云等第三方云测试平台达成。
本文以Hudson在Windows系统的环境搭建为例。
一、安装篇
1、安装JDK，推荐1.6版本
这个一般做Android的开发、测试都会装了，但要注意配好环境变量，即将jdk的bin目录加到Path里，将jdk目录加入JAVA_HOME
2、安装ant
http://ant.apache.org/bindownload.cgi，解压到本地合适目录，如D:\apache-ant-1.8.4
3、安装tomcat
http://tomcat.apache.org/download-70.cgi，解压到本地适当目录，如D:\apache-tomcat-7.0.30
4、安装hudson
http://java.net/projects/hudson/downloads/directory/war，将下载到的war包更名为 hudson.war（这个名字关系到访问的URL地址，也可以是别的），拷贝到tomcat的\webapps目录下，如D:\apache- tomcat-7.0.30\webapps
至此，只要启动tomcat/bin/startup.bat，就可以在浏览器里用http://127.0.0.1:8080/hudson对hudson服务进行访问了。
二、配置篇
打开hudson配置界面（主页 - 系统管理 - 系统设置）
1、配置好JDK，名称任意，JAVA_HOME填准确。
2、配置好ANT，名称任意，ANT_HOME填准确。
3、拉到最下面，邮件通知部分，SMTP、用户默认邮件后缀、系统管理员邮件都按照公司实际情况配好，Hudson URL填成http://本机IP:8080/hudson/，这样同局域网内的其他用户就可以访问你配置的Hudson服务了。
同时点开Advanced，勾选"使用SMTP"，使用你在公司域内的邮箱地址和密码，SMTP端口一般选择默认的25，Charset填写"UTF-8"，这样测试结果才会以你的邮箱发出给相关人。
打开hudson插件界面（主页 - 系统管理 - 管理插件 - 可选插件）
搜索以下几个插件并安装：
1、Hudson Subversion Plug-in，顾名思义，SVN插件。
2、JUnit Attachments Plugin，junit测试报告附件插件。
3、Android Emulator Plugin，如果要用Android模拟器来测试的话，这个是要装上的。
4、Hudson GIT plugin，如果团队是用Git来同步代码的话，那这个也装上。
5、Email-ext plugin，邮件发送定制插件。Hudson默认只在构建失败（或从失败转向成功）后发送提醒邮件；使用这个插件可以定制发送邮件的不同情景。
其它都按需安装喽。
新建任务 - 主项目（被测项目）打包任务
1、构建一个自由风格的项目，名称合适取。
2、Source Code Management部分，选Subversion，Repository URL里面填写你主体项目的SVN地址，其它选默认就行了。
3、Build trigger部分，勾选Build periodically可以使版本定时构建，语法和Unix的crontab一样。勾选Poll SCM则是定期去SVN或CVS的workspace去检查，如果有更新更构建。
4、Build Environment部分，如果是用模拟器来测试的话，就勾选"Run an Android emulator during build"。
5、Build部分，最关键的部分来了。
Ant version：选Default就行；
Targets：要应用的ant target名称，也可以是名称列表（多个名称用空格分隔），如果什么都不写的话，就是build脚本中的默认那个任务；
Build File：有时候我们未必用ant默认找的build.xml来编译，那就用这个选项来自定义脚本路径和名称，如build4test.xml；
Properties：这里用来写build脚本运行时需要的一些参数。其效果等同于在项目的workspace下建一个ant.properties 文件，然后在build脚本里加入<property file="ant.properties" />。其实说起来肯定是后一种方法更灵活，但有时为了安全起见（比如不把key.store.password泄漏出去），就把这些属性写在 Hudson服务端。（事实上这些属性都记录在该项目的config.xml里）
Java Options：这个不常用，可以点击输入框旁的问号参看帮助。
这个部分肯定是要和项目的build脚本结合起来的，所以build脚本的编写也是关键的地方。Ant脚本的内涵很深，用的好的话它可以完成的 事情超乎你想象，有必要下工夫研究一下。这里Google已经帮咱们写好了一个功能很强大的build脚本，如果没有特殊的定制需求，我们可以直接引用它 里面的target。这个脚本是在Android_SDK目录/tools/ant/下的build.xml，里面有三个很重要的 target：debug, release, install。
debug是用debug key打包，速度相对较快，测试时建议选用。release是用release key打包，速度齁慢，发布版本时必然打的是release包。另外测试时打release包还有个好处是利于和已发布版本的包进行覆盖安装。 install顾名思义很容易理解，但前提是debug或release任务已经得到应用。因为我们要构建包用于自动化测试，所以这里建议用的 target组合是debug install，即在上面说的Targets部分填入"debug install"。
用"android update project -p 项目路径"命令可以帮你在project目录下建立一个build.xml，当然你完全可以根据项目的需要自己定制Build脚本，要引用Google现 成target的关键是在build脚本里加入这样一句话：
| <import file="${sdk.dir}/tools/ant/build.xml" /> |
当然sdk.dir这个property需要提前定义好。
6、构建完成后操作：因为主项目构建完成后需要启动测试项目的构建，所以在Build other projects里面填写测试项目（如果还没建好就等建好了回头再来填）
其它的像Publish JUnit test result report和E-mail Notification等选项都要在测试项目中定义，所以这里就不勾选了。
新建任务 - 测试项目打包与执行任务
1、1-4步基本是相通的，不再赘述。
2、第5步，用ant完成debug install后，因为要执行测试，所以我们需要定义一个用于测试的任务。可以用类似下面的代码：
<target name="gotest" depends="stormtestinstall">
<echo message="Start Testing======================================="/>
<exec executable="adb" failonerror="true">
<arg value="shell"/>
<arg value="am"/>
<arg value="instrument"/>
<arg value="-w"/>
<arg value="-e"/>
<arg value="class"/>
<arg value="com.storm.smart.athtest._AllTestSuite"/>
<arg value="com.storm.smart.test/pl.polidea.instrumentation.PolideaInstrumentationTestRunner"/>
</exec>
<echo message="End Testing=========================================="/>
</target> |
这样的话我们可以在Targets输入框填入debug install gotest，即先打debug包，再安装，再执行测试。
3、测试完成后，我们需要把测试报告从手机里拷贝出来，这里用一个bat来完成：点击"Add build step"，选择"Excute Windows batch command"，在输入框内填入（pull-test-result.bat)。这个bat的内容类似下面这样：
adb root
adb shell mount -o remount rw /
adb pull /data/data/com.storm.smart/files/com.storm.smart.athtest-TEST.xml |
4、构建完成后操作：首先我们需要把拿到的xml初始报告文件格式化成友好的格式，然后将结果邮件通知给相关人员。
对应地，勾选"Publish Junit test result report"项，在Test report XMLs里填入*-TEST.xml；勾选"E-mail Notification"，填入相关人邮箱，按需勾选子选项即可。
至此，整个配置告一段落。
这一讲，我们将在
SilkTest 中使用类和对象。众所周知，面向对象的程序比面向过程的程序结构清晰，易于维护。所以对于大型的
测试框架，我们应该尽可能使用面向对象的语言来编写。SilkTest 所使用的4Test 脚本语言是一个非常面向对象的编程语言，它提供了绝大多数面向对象的机制，使用它能够轻松构建OO 的脚本。
下面我们希望能够用SilkTest 来操作计算器，先按数字1 ，然后打印这时结果框中的数值，然后再按键C 清零，再次打印结果框中的数值。为此，我们新建一个脚本Cal.t ，它的内容如下：
[-] winclass Calculator //1
[ ] String sResult //2
[-] Void ClearResult() //3
[ ] 计算器.C.Click() //4
[-] void GetResult() //5
[ ] sResult = 计算器.CalResult.GetText() //6
[-] Void ClickNum1() //7
[ ] 计算器.N1.Click() //8 [ ] window Calculator Cal //10 [-] testcase CalSetAndClear() //11
[ ] 计算器.SetActive() //12
[ ] Cal.ClickNum1() //13
[ ] Cal.GetResult() //14
[ ] Print(Cal.sResult) //15
[ ] Cal.ClearResult() //16
[ ] Cal.GetResult() //17
[ ] Print(Cal.sResult) //18 |
各行代码的意义如下：
行1：用关键字winclass 定义一个类Calculator （注意定义对象用winclass 关键字）
行2：定义Calculator 类中的一个String 类型的数据成员sResult ，用它来保存结果框的值
行3/4：定义Calculator 类的一个成员函数ClearResult，它的返回值是void，即不返回值。它的职责就是点一下计算器的C键，将结果清零
行5/6：定义Calculator 类的一个成员函数GetResult，它的返回值是void，即不返回值。它的职责就是获取计算器的结果框的值，将其赋给成员变量GetResult
行7/8：定义Calculator 类的一个成员函数ClickNum1，它的返回值是void，即不返回值。它的职责就是点一下计算器的数字键1
行10：在类的外面，我们定义了一个对象Cal，它的类是我们刚刚定义的Calculator类（注意定义对象用window 关键字）
行11：开始一个testcase
行12-18：激活计算器，点击数字键1，得到计算器的结果值，打印该值，将计算器清零，再次获取结果值，然后打印该值。
执行一下，你的case 最终应该打印两行，分别是
1.
0.
本文转载自：http://www.zengyuetian.com/
相关链接：
SilkTest入门快打1-录制回放
SilkTest入门快打2-编写脚本测试
SilkTest入门快打3-函数与原生Verify函数
SilkTest入门快打4-appstate
SilkTest入门快打5-深入appstate
mock在
单元测试中已经众所周知。现今我们有各种功能强大而又好用的mock框架，可以很方便的解除单元测试中各种依赖，这大大的降低了编写单元测试的难度。而测试驱动开发（TDD）更进一步将mock作为一种设计手段，来辅助识别出元素之间交互的接口和职责。
那么在功能测试(这里提到的功能测试指的是用户级测试)这个层次，是否有必要使用mock呢？如果有必要又将如何构建呢？或者说是否有可能像单元测试中那样构建一个通用的mock server系统呢？本文将根据我的实践经历，向大家介绍一个通用mock server系统的主要组成部分以及设计思路。
Why
现今的业务系统很少孤立存在，它们或多或少需要使用兄弟团队或是其他公司提供的服务，这为我们的联调和测试造成了麻烦。对于这种情况，我们常见的解决方 案是搭建一个临时的server，模拟那些服务，提供数据进行联调和测试。这就是mock server的雏形。一般来讲，搭建这种mock server系统比较简单，不过它的功能也比较简单，而且往往需要针对不同的接口重复开发。那有没有可能像单元测试中使用的mock框架那样构建一个通用 的mock server系统呢？
How
观察单元测试中的mock框架，我们会发现一般使用mock的流程是：
init mock //创建mock对象
config mock //设置mock期望
setup mock //将mock对象设置给被测对象
call //调用被测接口，被测接口里的代码会调用mock对象
verify //验证
拿mockito举例：
User expected = new User(“admin”, “12345”);
//init
UserDAO dao = mock(UserDAO.class);
//config
when(dao.findByName(“admin”)).thenReturn(expected);
//setup
UserService service = new UserService(dao);
//call
User actual = service.login(“admin”, “12345”);
//verify or assert |
借鉴这种做法，我么就可以构建一个简单的mock server系统，接下来的内容中，我们会在这个mock server的基础上演化出比较完善的版本。
版本1（简单的模拟值）
假设我们需要mock的是HTTP接口。我们的mock server提供一个配置接口（对应着上面的config mock步骤），测试运行之前调用配置接口将需要mock的HTTP接口URL以及需要返回的值传递过去，mock server内部建立url 到返回值的关联（这里就类似存在一个哈希表一样）。Mock server还提供另外一个接口供被测系统调用。这是一个通用的接口，所有原先指向真实服务的地址全部被指向到该接口（可以通过修改配置或修改系统 hosts文件）。当该接口被调用时会寻找刚才建立的url 到返回值的关联，并将mock的值返回。这样一个非常简单的mock server就构建出来了，对于一些简单的联调场景基本够用。这个时候我们的mock server的原理图如下面所示：
版本2（提供调用参数的查询）
有了第一版的mock server，对一些只需要模拟值的场景是够用了。但是，mock的作用仅限于此么？想想单元测试中的mock。在单元测试中mock框架除了能够为被测 系统构建输入值外，还能捕获到被测程序传出的值，然后对这些值进行校验。举一个实际的例子：在我们的系统中经常需要向用户发送短信，为了对发送的短信功能 以及短信内容进行验证，在没有mock之前我们可能真的需要向真实手机发 送短信，然后验证。这不仅降低了测试效率，也增加了不少不可控因素。为此我给mock server添加第三个接口：query接口。在被测系统调用mock接口时，mock会记录下被测系统传递给mock接口的参数值，然后测试中可以调用 query接口查询到记录的值，在测试中可以对其断言，而且这里记录下的调用记录还可以作为日志提供出来，提高系统的诊断能力。这样我们的mock server的结构就变成：
版本3（可以根据参数模拟）
现在我们的mock server已经可以提供类似verify的功能了，但实际上它还不能算一个真正的mock。它也不能处理哪怕稍微复杂一点的情况。在实际中，我们经常需 要针对不同的参数返回不同的值。举个简单的例子：我们mock一个支付接口，对于订单号123我们期望支付成功，对于订单234期望支付失败。这就引入了 我的mock server的两个核心组件：extractor和matcher。Extractor组件主要用于从调用的参数上提取出参数值，然后转换成 key/value的格式提供给后续的环节使用；因为请求的参数格式多种多样（json，xml等），extractor 为此提供了统一的接口。
Matcher组件的作用是在拿到extractor传递过来的key/value值后利用一些匹配器匹配到具体设置的期望上，所有匹配到的调用会返回 对应的值。也就是说mock server内部不再是简单的映射了。后面再介绍DSL部分的时候会介绍matcher使用的语法。这样我们的mock server结构就演化成下图：
版本4（提供多种协议的支持）
估计有人在抱怨，说了这么多这个mock server还只能mock HTTP接口啊，我们的系统中存在HTTP接口，RPC接口，SMTP接口等等。这是mock server中协议组件的职责。协议组件是mock server的入口，它提供多种协议的服务，并且解析出协议包数据，然后将数据交给extractor组件；除此之外，协议组件在收到上层的返回值后，会 按照协议的格式返回给被测系统 。利用一些开源的类库，我们可以很容易对一些通用协议提供支持，但对一些私有的二进制协议如果没有现成的库支持，要重新开发成本很大，不过我们可以从客户 端来解决这个问题，这在后续的文章中会有介绍。
版本5（模拟行为）
基本上一个功能还算完善的mock server成型了。但这就够了么？对于要模拟各种场景的测试还远远不够。我们很多接口有回调的功能，我们通常还需要模拟接口超时的情况，而对于一些支付 相关的接口经常需要对参数进行加密解密，而且这些情况都需要是可配置的。有没有发现，前面我们介绍的所有实际上都是mock值。也就是我们设置一些值，然 后调用的时候将值返回。但是很多时候我们不仅需要mock值，更要mock行为。这样我们有了mock server中最核心的组件：命令执行引擎（好牛的名字，其实就那样）。在设置mock的时候我们不再是设置一个值，而是设置一个预定义命令组合成的流水 线（即按照类似下面xml的配置一步一步执行，并且可以将上一步的执行结果传递给下一步）：
<delay>1000</delay>
<callback url=http://localhost/callback.do>{“ret”:”true”}</callback>
<return>{“ret”:”true”}</return> |
上面的流水线被命令执行引擎解析执行后就是按顺序执行对应的DelayCommand, CallbackCommand以及ReturnCommand命令了，具体命令就不介绍了。采取这种方式给我们mock server带来了很大的灵活性：只需要简单的扩展一个子命令，就可以扩充mock server的行为。比如mock某网关接口时需要使用MD5加密，只需要扩展一个MD5Command(下面代码中的$result表示前一步骤 <md 5 />加密后的结果)：
<md5 />
<return>$result</return> |
DSL
现在我们的mock不仅可以mock值了，对于各种行为的模拟也得心应手。但是要使用方便，还要提供便于使用的接口。Mock server提供两类接口：针对自动化测试的DSL，以及针对手工测试使用的管理界面。这里主要介绍这种DSL（因为我们的测试用例是使用xml编写，转 换成编程语言也很容易）：
<mock service=”http:/test.json” matcher=”hasKey($param.orderNo)”>
<delay>1000</delay>
<md5 />
<return>$result</result>
</mock> |
service是对被mock的服务的描述，比如对于SMTP，我们可以这样定义: service="smtp:9000"。这个表示在9000端口上监听smtp协议。而matcher即前面介绍的matcher组件所使用的各种匹配 器，用于匹配被测系统调用mock server时传递的数据。比如上面的例子表示的就是如果被测系统调用http接口/ticket.jsp，并且参数里包含orderNo则延迟1秒钟， 然后返回一个json值 。
总结
前面几节介绍了一个比较完善的通用mock server从简到繁演化的设计思路，希望可以为想要构建类似设施的读者提供一个参照。
这个mock系统包含两个主要部分：mock admin和mock server。Mock admin是管理界面，主要提供监控（可以在界面上实时看到被测系统与mock server交互）以及手工测试时的配置界面。 Mock server即前面介绍的主体，其架构如上图所示。Mock server包含几个核心组件：协议、extractor、matcher、命令执行引擎、存储（即mock server中使用的各种数据的存储）。Mock server提供三类接口：配置、被mock接口（各种服务，通过协议组件提供）、查询。
原文：http://www.infoq.com/cn/articles/auto-test-mock-server
背景：我们
测试团队包括业务测试团队和测试工具开发部门（测试规划部），近期，部门在讨论
自动化测试考核的细节。我们的目标：通过工具提高
工作效率（提效），解决手工测试无法覆盖的问题（有无）。讨论的内容包括如何通过自动化
测试用例的个数和比例对测试设计和工具开发人员进行考核；工具的使用、推广和工具需求的责任如何划定等等。下面是关于个人观点的邮件内容摘录。
各位好：
如果我认识我的观点正确，我会尽快提出来。大家在这样的base上讨论，成效会更多一些！
关于自动化测试用例个数/比例：
我们对自动化测试目标的理解完全一致：自动化的目标是提效和有无；自动化测试用例个数/比例的高低绝对不是我们的目标，也不是我们达到目标的手段和途径。如果开始的理解出错，只能一错再错，按个数和比例进行考核行不通！
软件测试或 者测试工具开发的衡量，犹如衡量商品的价值。基本上没有人按商品的长宽高、重量、数量、体积等衡量商品的价值，如果有的话，那是送快递的（快递也不直接考 核商品本身的价值）。工具和商品具有很大的相似性，都是凝结在其内在的无差别的人类劳动，对他们的衡量只能采用社会必要劳动时间！
具体来说，TestLink上很多测试用例只有标题，而总数有数千个。这种有数量而没有内涵，完成这些数量只需要简单的复制粘贴，不需要很多工作时间。如果这样的做法可以获取很高的考核分数，只能往错误的方向上引导团队，久而久之会导致不良的工作风气。
用例的个数和比例只能用在日常工作的进度报告上，不能用在绩效考核上；只能定性，不可定量。而绩效考核的内容则应该在员工付出的努力、付出努力而产生的成效等等！
在实施上，我建议：
对于业务测试，从功能模块复杂度，人力资源/工作量评估等进行衡量。
对于测试研发，工具研发的难易程度，工作量等进行考虑。
社会必要劳动时间意味着，不同员工的工作效率有差别，同样的工作量的价值也是不一致的，建议参考IBM/华为的PBC绩效考核方式及其关联的员工级别制度。细节需要完善。
关于工具的使用和需求的提出：
100%的测试团队的责任。
1、使用 我们的工具都是专业工具，不像剃须刀和发卡那样简单易用，都需要专业知识，并需要耐心的付出精力。任何以工具不好用为借口的员工都有没有静心使用工具或能力不足的嫌疑。
如果测试团队采取低效的方式进行工作，而规划部有现成的工具并组织培训推广过，测试团队的绩效考核应该被扣分。
2、需求
如果测试团队采取低效的方式进行工作，而不能主动向规划部提出需求，且规划部可以改进所述的工作方式时，测试团队的绩效考核应该被扣分。
关于工具的研发和培训推广：
100%的测试规划部的责任。
1、研发
规划部负有研发的责任。在熟悉的知识领域，尽快完成研发，满足测试团队的需求。在不熟悉的领域，需要调研学习，并尽快完成研发，满足测试团队的需求。
2、培训推广
规划部负有培训推广的责任。开发的工具必须展现出来并进行积极的培训。藏在深闺无人知，只能自己把玩的工具，应该扣绩效考核的分数。
本文转载自：http://loggingselenium.com/?p=350