一、绩效考核的原则：smart原则
Specific——明确性
     所谓明确就是要用具体的语言清楚地说明要达成的行为标准。明确的目标几乎是所有成功团队的一致特点。很多团队不成功的重要原因之一就因为目标定的模棱两可，或没有将目标有效的传达给相关成员。

     BadCase：
     在2015年Q1目标制定时，测试技能目标是“提高测试设计能力”，这样简单的看没有什么问题如果仔细来看，这个目标很不明确，提高测试设计能力方法有很多例如：掌握了解测试设计方法、加强测试敏感度等，提高测试设计能力这个目标制定是失败的

      改进方案：
      修改后的测试能力目标设定为：完成三次B级模块测试用例设计，这样就很明确了。

Measurable——可衡量性
      衡量性就是指目标应该是明确的，而不是模糊的。应该有一组明确的数据，作为衡量是否达成目标的依据。

      如果制定的目标没有办法衡量，就无法判断这个目标是否实现。比如领导有一天问“这个目标离实现大概有多远？”团队成员的回答是“我们早实现了”。这就是 领导和下属对团队目标所产生的一种分歧。原因就在于没有给他一个定量的可以衡量的分析数据。但并不是所有的目标可以衡量，有时也会有例外，比如说大方向性 质的目标就难以衡量。

     badCase：
     2015年Q1目标设定时，衡量固定渠道包自动化完成情况时，写的是高质量完成固定渠道包自动化脚本，其实这个标准是不可衡量的，什么是高质量？无法进行评定
     改进方案：
     修改后的衡量标准为：固定渠道包自动化脚本能够运行且没有BUG，这样的衡量标准是有办法衡量的。

Attainable——可实现性
       目标是要能够被执行人所接受的，如果上司利用一些行政手段，利用权利性的影响力一厢情愿地把自己所制定的目标强压给下属，下属典型的反映是一种心理和行为 上的抗拒：我可以接受，但是否完成这个目标，有没有最终的把握，这个可不好说。一旦有一天这个目标真完成不了的时候，下属有一百个理由可以推卸责任：你看 我早就说了，这个目标肯定完成不了，但你坚持要压给我。
   
      “控制式”的领导喜欢自己定目标，然后交给下属去完成，他们不在乎下属的意见和反映，这种做法越来越没有市场。今天员工的知识层次、学历、自己本身的素 质，以及他们主张的个性张扬的程度都远远超出从前。因此，领导者应该更多的吸纳下属来参与目标制定的过程，即便是团队整体的目标。

      定目标成长，就先不要想达成的困难，不然热情还没点燃就先被畏惧给打消念头了。

     问题：
     在计划制定时，没有自己去评估工作量就将其写入计划中，导致的就是一个季度过完后，计划没有完成

     改进方案：
     切合实际的制定自己能力范围内的计划，就算是要学习一门编程语言也是一样，不能一口吃一个胖子。

Relevant——相关性

      目标的相关性是指实现此目标与其他目标的关联情况。如果实现了这个目标，但对其他的目标完全不相关，或者相关度很低，那这个目标即使被达到了，意义也不是很大。

      因为毕竟工作目标的设定，是要和岗位职责相关联的，不能跑题。比如一个前台，你让她学点英语以便接电话的时候用得上，这时候提升英语水平和前台接电话的 服务质量有关联，即学英语这一目标与提高前台工作水准这一目标直接相关。若你让她去学习六西格玛，就比较跑题了，因为前台学习六西格玛这一目标与提高前台 工作水准这一目标相关度很低。

Time-bound——时限性

      目标特性的时限性就是指目标是有时间限制的。例如，我将在2005年5月31日之前完成某事。5月31日就是一个确定的时间限制。没有时间限制的目标没 有办法考核，或带来考核的不公。上下级之间对目标轻重缓急的认识程度不同，上司着急，但下面不知道。到头来上司可以暴跳如雷，而下属觉得委屈。这种没有明 确的时间限定的方式也会带来考核的不公正，伤害工作关系，伤害下属的工作热情。

      实施要求：目标设置要具有时间限制，根据工作任务的权重、事情的轻重缓急，拟定出完成目标项目的时间要求，定期检查项目的完成进度，及时掌握项目进展的变化情况，以方便对下属进行及时的工作指导，以及根据工作计划的异常情况变化及时地调整工作计划。

      总之，无论是制定团队的工作目标，还是员工的绩效目标，都必须符合上述原则，五个原则缺一不可。 制定的过程也是对部门或科室先期的工作掌控能力提升的过程，完成计划的过程也就是对自己现代化管理能力历练和实践的过程。
二、绩效考核的内容：
   1.从问题出发，根据问题制定行动方案，对目标制定衡量标准。
   2.绩效考核的内容：除了完成既有的测试项目(我称之为固有职责)，还可以添加一些提高方面的目标。例如，在我的测试团队中先后经历过这几种目标：
         a.固有职责+知识沉淀
         b.固有职责+突破(技术突破或者个人问题解决)+创新
         c.固有职责+影响力+创新   （目前是这个衡量体系）
  附一张组内的绩效考核表格

Club模块的需求： Ongo用户可以添加Club，同时邀请别人加入这个Club，Club member 可以是邮箱或者Ongo 用户。
功能测试用例如下：

描述	期望结果	实际结果
输入Club Name 和 任意Ongo用户或者有效的邮箱，点击Create button	Club创建成功
输入Club Name 和 任意Ongo用户或者有效的邮箱，点击canel button	Club panel 关闭
Club Name 不输入任何字符或者输入空格，点击create button	提示Create name 不能为空
Club name 输入一个特上的字段，如果255个字符，点击点击create button	提示Club name 长度的限制
输入Club Name，并输入一个没有注册的用户	提示该用户不是Ongo 用户
输入Club Name，并输入一个无效的邮箱，例如没有@符号	提示该邮箱无效
Club创建成功后，点击Club panel	Club 创建者和Club member 都能看到这个Club
Club 创建成功后，点击Manage Club	Mange Club panle显示，并显示View Club member, invite member 和 edit Club name
点击View Club member	Club member 展开，同时列出Club 所有的Member 包括Club 创建者
点击Club member 后面的Remove 按钮（只有Club创建者能看到这个按钮）	该Club member从Club中移除
点击invite Club member	Invite Club member 展开
输入Ongo 用户或有效的有效，点击invite button	Club member 邀请成功
输入Ongo 用户或有效的有效，点击canel button	Invite Club member 折叠
输入非Ongo 用户点击Invite button	提示该用户不存在
输入无效的邮箱，	提示有效不存在
添加重复的Club member	提示不能重复添加Club member
输入空格，并点击Invite button	提示不能为
点击 edit Club Name	Edit Club Name 展开
清空Club name,点击 Update button	提示Club Name不能为空
edit club name, 点击 Update Button	Club Name及时更新
edit club name, 点击 canel Button	Edit Club Name 折叠且Club name 没变
输入一个超长的Club name,点击Update button	提示Club name 长度限制

界面测试有以下几点需要注意：

1. 页面布局合理；
2， 界面颜色看着舒服；
3， 提示信息的颜色同样，正确的信息要绿色，错误的提示信息要红色；
4， 提示信息要有好，并准确

IPad 上的App 的测试

1．    安装App

    在IPad 上安装任何App，都需要一个认证文件，意思就是说，要想在IPad 上运行某一程序，IPad 必须认识它才行

        2.   IPad 的屏幕可以旋转，所以要测试在旋转的过程中，App是否能正常运行

        3.   在测试App 的时候，经常会碰到App 用着用着就会崩溃，在这种情况下，就要把IPad 上的log 同步到    PC上，查看到底是因为IPad内存不足还是App本身有严重问题

         4. 在iPad 上只能通过滑动屏幕来移动页面，所以要测试在滑动的过程中，能否到正确的页面。

          5. 更新App， App的新版本能否顺利的安装

          6. App 当要输入数据的时候，键盘是否能及时出现，出现后，键盘上显示是否正确

          7. 退出App，这个App在IPad上的资源是否能释放

1.      

C/S

1.           C/S要有安装/卸载测试，包括服务器端的安装/卸载和客户端的安装/卸载，其次是客户端能否顺利的和服务器端连接上。B/S不需要这方面的测试。

2.       B/S必须要在浏览器上测试，所以浏览器的种类和浏览器相关的Cookies等的设置也属于测试点，在测试的时候都要考虑。而C/S不需要这个。

3.       B/S 要求有性能测试，就是如果同时有500个人访问，软件会不会反应太慢，软件会不会突然死掉之类的。而C/S对这方面要求一般，因为每人机器上都有客户端，有些工作不用在服务器端完成，不用一直不停的访问服务器端

4.       B/S 的安全型测试要比C/S的高，因为B/S的程序谁都可以访问，这样就扩大了它的危险性，而C/S只能有客户端才能用，就限制了使用者的范围，同时也降低了它的危险性

5.       C/S 软件如果有补丁包的话，还要对补丁包的更新进行测试。B/S 没有这方面的测试。

具体到每一个模块的测试，都是一样的，都要进行功能，界面的测试。

对于每一个做测试的人员来说，写bug是天天要干的事，也是测试员的基本技能要求。可是如何写出“漂亮的”bug 那？

何为“漂亮的bug”呢？个人觉得应该包括以下三方面：

1.       根据bug 步骤能重现bug

2.       程序员看到你的bug, 心情没有变糟糕

3.       程序员看到你的bug 后，基本上95%知道问题出在什么地方了。

关于第一点，很简单，这也是bug 的最基本要求。就是把我们的操作步骤一步一步列出来就可以了。

关于第二点，应该也不是很难，就是bug描述要越简单越好，不要写的太长，能用3步说清楚决不要写5步，不仅是程序员不想看，就连自己验证bug的时候也会觉得，这个bug 怎么这么麻烦呀。这和我们说话一样，一个字能表达的，千万不要用一句话，会觉得很啰嗦。

关于第三点，可能就有点难度，一个是要靠经验，而另一个是要懂一点开发。经验可以告诉我们这个问题通常是由什么引起的；开发基础知识让我们了解这应该和那个模块用的是同一个类，这个模块有问题，另一个模块会不会也有问题那。我们有了这些经验就可以在写bug 的时候，写一些比较关键的步骤，不必要的步骤可以省去。还有就是有时候我们会觉得，应该是同一个类下的内容，为什么在一个模块是好的，在另一个有问题，在这种情况下，bug中不光要描述问题的重现步骤，还要说一下在其他的模块是好的。这样有助于程序员排查问题。