发布新日志

  • 没有管理经验的测试人员如何胜任测试经理一职(转)

    2009-02-25 23:31:31

    中层经理人不论是作为一名执行者、还是一名领导者,都必须通过别人来完成任务。要做个“服众”的经理人,应该有意识地提高以下八项能力:

    1. 领悟能力
    做任何一件事以前,一定要先弄清楚上司希望你怎么做,然后以此为目标来把握做事的方向,这一点很重要,千万不要一知半解就开始埋头苦干,到头来力没少出、活没少干,但结果是事倍功半,甚至前功尽弃。要清楚悟透一件事,胜过草率做十件事,并且会事半功倍。

    2. 计划能力
    执行任何任务都要制定计划,把各项任务按照轻、重、缓、急列出计划表,一一分配部属来承担,自己看头看尾即可。把眼光放在部门未来的发展上,不断理清明天、后天、下周、下月,甚至明年的计划上。在计划的实施及检讨时,要预先掌握关键性问题,不能因琐碎的工作,而影响了应该做的重要工作。要清楚做好20%的重要工作,等于创造80%的业绩。

    3. 指挥能力
    无论计划如何周到,如果不能有效地加以执行,仍然无法产生预期的效果,为了使部属有共同的方向可以执行制定的计划,适当的指挥是有必要的。
    指挥部属,首先要考量工作分配,要检测部属与工作的对应关系,也要考虑指挥的方式,语气不好或是目标不明确,都是不好的指挥。而好的指挥可以激发部属的意愿,而且能够提升其责任感与使命感。要清楚指挥的最高艺术,是部属能够自我指挥。

    4. 控制能力
    控制就是追踪考核,确保目标达到、计划落实。虽然谈到控制会令人产生不舒服的感觉,然而企业的经营有其十分现实的一面,有些事情不及时加以控制,就会给企业造成直接与间接的损失。但是,控制若是操之过急或是控制力度不足,同样会产生反作用:控制过严使部属口服心不服,控制不力则可能现场的工作纪律也难以维持。要清楚最理想的控制,就是让部属通过目标管理方式实现自我控制。

    5. 协调能力
    任何工作,如能照上述所说的要求,制定完善的计划、再下达适当的命令、采取必要的控制,工作理应顺利完成,但事实上,主管的大部分时间都必须花在协调工作上。协调不仅包括内部上下级、部门与部门之间的共识协调,也包括与外部客户、关系单位、竞争对手之间的利益协调,任何一方协调不好都会影响执行计划的完成。要清楚最好的协调关系就是实现共赢。

    6. 授权能力
    任何人的能力都是有限的,作为高级经理人不能象业务员那样事事亲历亲为,而要明确自己的职责就是培养下属共同成长,给自己机会,更要为下属的成长创造机会。孤家寡人是成就不了事业的。部属是自己的一面镜子,也是延伸自己智力和能力的载体,要赋予下属责、权、利,下属才会有做事的责任感和成就感,要清楚一个部门的人琢磨事,肯定胜过自己一个脑袋琢磨事,这样下属得到了激励,你自己又可以放开手脚做重要的事,何乐而不为。切记成就下属,就是成就自己。

    7. 判断能力
    判断对于一个经理人来说非常重要,企业经营错综复杂,常常需要主管去了解事情的来龙去脉因果关系,从而找到问题的真正症结所在,并提出解决方案。这就要求洞察先机,未雨绸缪。要清楚这样才能化危机为转机,最后变成良机。

    8. 创新能力
    创新是衡量一个人、一个企业是否有核心竞争能力的重要标志,要提高执行力,除了要具备以上这些能力外,更重要的还要时时、事事都有强烈的创新意识,这就需要不断地学习,而这种学习与大学里那种单纯以掌握知识为主的学习是很不一祥的,它要求大家把工作的过程本身当作一个系统的学习过程,不断地从工作中发现问题、研究问题、解决问题。解决问题的过程,也就是向创新迈进的过程。因此,我们做任何一件事都可以认真想一想,有没有创新的方法使执行的力度更大、速度更快、效果更好。要清楚创新无极限,唯有创新,才能生存。
     
     
    领导力更需提升

    一个部门经理提高完成任务执行力的过程,其实也就是提高自身对部门员工领导力的过程。因为要提高执行部门的执行力,不是光靠经理一人所能完成的,而是要靠带领部门所有员工的共同努力才能完成的。
     
    如果你是测试员或是高级测试员,有志转向管理发展,那么需要加强以下几点:

    1. 测试计划的编写(要结合测试的项目,能以此来控制和确定测试所需人员,设备及时间来管理测试时间)

    2. 要熟悉BUG跟踪工具及软件测试流程.(如: TD, Bugzilla, CQ等)

    3. 要熟悉配置管理工具. (如: CVS, VSS等)

    4. 要熟悉自动化工具.(例如:WinRunner, QTP, Robot, RFT, Automation等,能结合录制完的脚本编写代码)

    5. 要熟悉压力及性能测试工具.(例如: LoadRunner, webload, silkperformance等,能结合相关数据,分析出性能瓶颈)

    6. 要熟悉或精通一门语言. (例如: Java, C++)

    7. 要熟悉数据库.(例如: Oracle, DB2, SQLServer, MySQL)

    8. 要熟悉主流操作系统. (例如: HP Unix, IBM AIX, Sun Solaris, Red Hat Linux, SuSE Linux, Windows)

    9. 能用英文流利的和老外交流以及往来Email.

    10. 语言表达能力强,表达问题清晰明了.

    11. 沟通能力强,能和上级/开发经理很好的达成测试相关/BUG事宜.

    12. 学习技术的能力要强,能快速上手一个新的技术.

    13. 乐于与人交流.
     

    用于承担责任


    表率

        春秋晋国有一名叫李离的狱官,他在审理一件案子时,由于听从了下属的一面之辞,致使一个人冤死。真相大白后,李离准备以死赎罪,晋文公说:官有贵贱,罚有轻重,况且这件案子主要错在下面的办事人员,又不是你的罪过。李离说:“我平常没有跟下面的人说我们一起来当这个官,拿的俸禄也没有与下面的人一起分享。现在犯了错误,如果将责任推到下面的办事人员身上,我又怎么做得出来”。他拒绝听从晋文公的劝说,伏剑而死。

        正人先正己,做事先做人。管理者要想管好下属必须以身作则。示范的力量是惊人的。不但要象先人李离那样勇于替下属承担责任,而且要事事为先、严格要求自己,做到“己所不欲,勿施于人”。一旦通过表率树立起在员工中的威望,将会上下同心,大大提高团队的整体战斗力。得人心者得天下,做下属敬佩的领导将使管理事半功倍。
     
     

    说到底,对上提高执行力、对下就要提升领导力。

    那么,怎样才能提升领导力呢?除了提高以上八项能力之外,还有最重要的两点:

    1. 学会用老板眼光看企业。
    在老板看来,管理很简单,就是两件事:一是扩大业务范围,增加业务收人;另一件事就是降低管理成本,控制运作费用。其实这两件事,最终是一件事,收入减去成本,减去费用,就是利润。所以归根到底老板是看利润的,利润要从管理中来。

    2. 从被领导中学习领导。
    在领导人看来,领导也很简单,就是两件事:一是用人,内圈用德、外圈用才,用人所长、容人所短;二是激励,解人之难、记人之功,通过正面激励,引导下属往前跑,通过负面激励,推着下属往前走。要知道,任何领导都是从做下属开始的,谁都不可能一步登天当领导。在每个人的成长过程中,你会经历大大小小许多领导,只要你用心学习,不管是好领导、还是坏领导,你都可以从正反两方面学到经验和教训,这对你将来当好领导是十分珍贵的。
     
     
  • 如何有效降低测试轮次(转)

    2009-02-25 23:25:44

     软件测试的轮次多少,大多数情况取决于项目大小、开发软件质量和测试效率有关。在项目确定的情况下,谈谈我们团队的做法,希望同行继续补充指正:

      1、让研发团队的领导重视测试:

      测试经理作为测试部门的老大,让公司领导重视测试,明白测试给项目带了的价值,那是义不容辞的责任。如何说服公司的领导,让公司的研发总监重视,这一点非常关键。只要这一点做好了,测试才会变得很轻松、愉快。如果公司的领导都不重视测试团队,只看重开发团队,即时测试部门发现了一大堆问题,公司领导也觉的很正常,不在乎,何谈降低测试轮次?如果公司研发领导很重视每轮的测试报告,自然开发部门不敢怠慢,代码的质量肯定要高得多,降低测试的轮次简直就是轻而易举的事情。

      2、测试团队和开发团队的独立性:

      国内很多的研发团队都不是很重视测试团队,很多情况下都是开发部门的经理说了算,什么时候测试?什么时候结束?都是如此,这就让测试团队的成员非常郁闷,很无赖,经常是抱怨居多。在这种情况下,多数时候,项目为了赶进度,项目经理和开发经理急了。为了尽快发现问题,只要开发了几个新功能和修复了几个Bug,也就安排大量测试人员立马验证,这样反反复复,版本平凡发布,测试效果极差,软件质量也得不到保证。如果测试部门和开发部门独立以后,发布版本测试都必须通过沟通来解决。你说开发部门的经理“说测试就测试”的想法,说了还能算吗?呵呵!!我们公司很多时候,在测试版本不符合要求时,要送测试部门进行测试,都是开发部门的经理和项目经理给我们测试部门的老大说好话,拍马屁,老大高兴了,我们方才开始测试,否则一切按流程行事,他们也没有办法。保持部门的独立性和平等性,同样重要。

      3、细化送测标准,建立完善的测试规范:

      测试经理在编写测试计划的时候,就应该考虑如下的问题:开发部门开发完成到什么时候我们可以开始接受测试?如果这点测试经理不明白,后面重复测试平凡发布版本,不是什么新鲜事。目前,我们公司的做法是:测试经理编写详细的测试规范,在规范中明确规定了软件版本的送测标准(如:某个独立模块的功能点完成了多少百分比,才能够开始测试等等,都要写成一个标准)。测试规范制定完毕后,开会评审让项目经理、开发经理和测试经理达成一个一致的建议,后面测试的时候就按测试规范中的标准执行就可以了。严格把握软件的送测标准,也能够有效的减少测试的次数。

      4、测试部门建立详尽的预测试标准:

      如果被测试软件符合送测标准以后,开发部门才能够请求测试部门进行测试。测试部门接受到开发部门的配置表以后,在服务器上取下测试的版本,编译、部署后,安排部分项目核心人员,对部分主要的功能进行预测试,如果预测试通过了,就可以开始测试。如果预测试不通过,就打回开发部门修改好后再预测试,直到预测试通过为止。同时,我们也要制定严格的软件测试结束标准,来把好质量关,避免一味的追求减少测试轮数,而忽视质量,结果自然可想而知。建立详尽的预测试标准,这样也能够减少测试的轮数。

      5、保持测试和开发独立的测试环境:

      大部分的项目硬件都非常昂贵,现在很多的公司为了节省成本,开发和测试环境都在同一台机器上。开发人员就在测试机器上开发,这样混乱的测试环境,导致很多测试出来的Bug有可能不能够重现,开发人员对不成功重现的Bug就要求列为无效的Bug,弄得测试的兄弟们递交Bug都胆战心惊的。测试人员为了重新 Bug不得不另取以前的版本,重新编译后,再测试,这样做无意识又增加了测试的轮次。后来测试环境和开发环境分开了,虽然在同一台机器上,数据库都分开了,测试数据再也不会被开发人员修改了,在测试出现的问题,一般在开发那边都能够出现。后来为了保护测试组里成员的利益,我也去掉了绩效考核中“对无效的 Bug”的考核项,大家终于可以放心的提缺陷了。

      6、重视单元测试,提高被测软件质量:

      很多时候,测试部门和开发部门单元测试比较马虎或应付客户了事,测试的时间短,留下了很多缺陷。到了后面每轮系统测试的时候,才被发现,加之项目进度的压力,给公司也带来了较大的经济负担。加大单元测试的力度,力争尽早发现并修复缺陷,同样也是减少测试轮次的一种好方法。

    本文出自51Testing软件测试网,感谢会员zhuzx在每周一问(08-08-18)中的精彩回答。
    http://bbs.51testing.com/forum-157-1.html

      7、重视测试用例的评审,提高测试用例的质量:

      就目前来说,很多的公司都不是很规范。一种情况:变更了软件需求,相应的测试用例,没有及时增加,测试人员测试时,完全凭个人的理解和经验,想到哪里就测到哪里,随便测试。在这种情况下,不同的人在不同的时间测试时,就会发现并提出不同的缺陷,这样混乱的测试就导致测试轮数较多,效率自然低下。另外一种情况就是测试人员设计测试用例的水平不高,测试用例质量较差,导致测试反复进行,也测试不出Bug。这就要求测试部门主管,加大测试用例评审的力度,力争以最少的测试用例,测试出较多的Bug。

      8、部门员工进行模块交叉测试,避免漏测提高测试效率:

      测试主管在安排测试的时候,也要注意“用人之长,避人之短”。测试启动阶段,要对这个系统集中培训,让测试部门的成员对整个系统达成一致意见,最好在第一轮测试时,尽可能发现较多缺陷,开发人员尽早修复。第二轮测试就可以进行模块交叉测试。一方面我们可以避免个人原因造成的漏测试,另外一方面也可以利用每个人不同的思维方式,很容易发现其它模块的缺陷,避免多次重复测试,提高测试人员的积极性。测试效率提高了,发现的问题多了,后面测试的轮次自然要减少。

      9、加强项目成员的管理,定期报告发现缺陷的情况,增加督促力度:

      加强项目成员的管理,同样能够减少版本的发布和测试的轮次。测试人员每天都编写测试日志,邮件抄送给项目部成员和公司领导报告每天测试情况,加强不同层次的领导对开发人员的督促力度。这就对应了第一条,如果公司领导不重视测试,也就无所谓。如果公司领导很重视测试结果,马上作出反应,给各个部门的经理施加压力,软件质量被重视了,自然测试版本减少。如果哪个开发人员开发的模块每天都有很多缺陷,开发人员自然很不光彩,毕竟大家都很要面子,开发人员也敢轻而易举,开发的模块功能不测试就直接扔给测试部。这也是一种有效的方法,当然也可以把缺陷的数量、严重程度作为开发人员的绩效考核标准,提高开发人员的“质量意识”,缺陷自然很少。我们公司就是这样做的,一般在2到3个版本时,就很难发现缺陷,测试人员也相互看看其它成员发现的缺陷,一旦有的测试人员发现了较多的Bug,发现缺陷很少的测试人员很急,比较有个比较吗?特别是测试半天都没发现 Bug的测试人员,就经常给我讲自己测试过程中的苦衷,我也很理解他们,多给他们鼓励鼓励。

      10、严格控制需求变更的流程,减少后期的需求变动:

      在项目开发中,经常碰到这样的情况,客户代表中有产品部、科技部、业务部等等部门的人员,很难通过某个客户代表户讲清需求。客户代表,随着对开发系统的不断深入了解,有可能客户不断的提出新的需求,或者说是不断修改需求,所以对于需求的变更,我们一定要有一个严格的标准流程。通过开发方和客户的评审后,再编写相应需求文档,最后开始开发。很多时候,繁琐的需求变更流程和领导的多级审批签字,并且需求的变更请求,也有相关的记录,很多客户都怕承担需求变更带来风险。也让业务人员觉得变更比较麻烦,不得不放弃需求的变更。严格控制需求的变更流程,做到有效的需求变更,这也许是一种减少测试版本的方法。

  • 测试度量(转)

    2009-02-25 23:23:56

       度量的目的

    度量活动首要考虑的是目的,测试中的度量一般有如下目的:

    a)     判断测试的有效性

    b)     判断测试的完整性

    c)     判断工作产品的质量

    d)     分析和改进测试过程

     

    1.2   度量内容

       度量的数据构成一个层次化的体系,就是度量框架。框架的上层是度量指标(Factor),下层是直接度量(Metrics)。度量指标表示产品或过程的特征,需要从直接度量计算而来。而直接度量是可以直接收集到的数据。下面分别说明系统测试中需要测量的度量内容,注意区分其中的度量指标和直接度量。

     

    1.2.1进度(时间)度量

    a)     计划的测试开始、结束时间

    b)     实际的测试开始、结束时间

    c)     执行测试用例的时间。

    1.2.2成本度量

    1.     计划投入测试的工作量(人时)

    2.     计划投入测试的资金

    3.     实际投入测试的工作量(人时)

    4.     实际投入测试的资金

    5.     评审投入的工作量(人时)

    6.     缺陷修正成本(提交缺陷、研究缺陷、改正缺陷、验证等所需时间)

    7.     累积测试时间。对每一个发布的版本,累积测试时间等于该版本在演变过程中经历的所有测试的测试时间之和。包括完整测试、验证测试和回归测试。 

     

    1.2.3规模度量

    1.     被测对象的规模(功能点、代码行(有效代码行,注释行)等)

    2.     系统需求数目

    3.     测试用例数目(总用例数、计划执行数、实际执行数)

     

    1.2.4测试质量(效率)度量

    1  测试覆盖率

        a)需求覆盖率:需求覆盖率=至少被测试用例覆盖一次的需求数/系统总需求数     b)测试用例覆盖率:测试用例覆盖率=计划执行的测试用例数/测试用例总数

        c)测试用例执行率: 测试用例执行率=实际执行的测试用例数/计划执行的测试用例数

         d)测试用例通过率:测试用例通过率=(实际执行的测试用例数-测试执行不通过的测试用例数)/实际执行的测试用例数

     

    2  缺陷检测率对某一版本,某一个环节(阶段)的缺陷检测率=(A/AB)*100%。

    其中:

    A:测试人员查找出的不包括重复缺陷的数量。

    B:用户(包括下一环节的部门)报告的不包括重复缺陷的数量。

     

    3  测试过程能力

    单位缺陷开销=测试投入的工作量(人时)/缺陷总数

     

    1.2.5产品质量度量

    1.     版本发布前缺陷数

    2.     版本发布后缺陷数

    3.     评审发现的缺陷数

    4.     缺陷修正率:缺陷修正率=发布前已修正的缺陷数/发布前已知的缺陷总数。

    5.     缺陷密度:千行代码缺陷率=测试和评审中发现的缺陷数/被测目标的代码的规模(KL

  • 软件质量定义

    2009-02-25 00:35:01

    软件质量定义:

    51Testing软件测试网#cFm6M!Jmd(e

    软件测试是为了检验软件存在的缺陷,为了软件提供更好的质量保证。51Testing软件测试网J~+qyO C8N;p|*PY

    51Testing软件测试网 J k&G,|WA]0[

    那么质量是怎么定义的呢?怎么样的才算好的质量呢?51Testing软件测试网"q\:?q#l

    c*UA&jc%_0


    s Xw({7A6{3z:~#S0

    b@ Ue}0

    AN7zs$B4Q)T(C2B0H0——最好的产品是用户不用说明书就能使用的产品;51Testing软件测试网}1T([h9L~L

    51Testing软件测试网1^ i"G QTl?&`2o3Z

    ——好员工是能站在企业角度考虑问题的员工;51Testing软件测试网E|p C*iAl

    51Testing软件测试网4S @mCQ3WD(p&[v w

    ——最好的服务是能让顾客有宾至如归感觉的服务;

    3?Nn3|C051Testing软件测试网 HLW8X!vl0A[


    ISO是这样定义的:质量是实体基于实体特性满足需求的程度

    x I B-Q8B0

     软件质量的三个层次(由低到高):

    `H@J(rW0
    • 符合需求规格:满足了开发者明确定义的目标;
    • 符合用户显示需求:符合用户明确说明的目标;
    • 符合用户实际需求:满足用户明确的和隐含的需求。

     影响软件质量的因素:51Testing软件测试网-l,S\W!Mps

    软件质量的提高是一个综合的因素。51Testing软件测试网w+_6rjv

    • 流程:是软件产品开发过程的规范。好技术不如好流程
    • 技术:什么是真正的技术?编码?架构?设计?
    • 组织:是员工职位、工作的安排等。它是流程执行的保障
    • 进度及成本

    软件质量管理体系:

    流行的软件质量管理体系有:ISO9000、CMMI/CMM、六西格玛51Testing软件测试网y4{n Ftg E3i.\

     ISO9000:2000的管理八项原则:

    1. 以顾客为中心:满足顾客的需求、期望才能保证组织的存在;
    2. 领导作用:好的组织离不开好的领导;
    3. 全员参与:真正创造效益的是员工;
    4. 过程方法:一个好的流程规范是产品质量的最重要保证
    5. 管理的系统方法:采用好的方法提高效率、有效性
    6. 持续改进:可持续发展战略
    7. 基于事实的决策方法:能达到量化每一个过程
    8. 互利的供方关系:双赢
     八项质量管理原则的意义:
    • 质量管理的理论基础;
    • 概括了一般性的规律;
    • 提供理论依据;
    • 遵循的原则;

     CMMI(Capability Maturity Model Integration)/CMM(Capability Maturity Model):

    CMMI/CMM除了能评估软件承包商开发软件的能力,还能协助软件组织改进过程、提高过程能力。51Testing软件测试网'V9q#XJ8g1A g R"T

    CMMICMM的集成和综合,集成了CMM-SW、CMM-SE、CMM-IPT、CMM-SA51Testing软件测试网~p,Wf$c6w4Rd

    实施CMMI/CMM有什么必要呢?

    0lH$i;E6r~0
    • 业界的实施标准
    • 业界的一种交流语言
    • 国内企业获取国际订单的门槛
    • 向下采购的保障:如软件外包公司的承包评价
    • 降低软件风险的有力手段

    CMMI/CMM五个级别51Testing软件测试网\/|G!y(|&ub\V"J:p

    1. 初始级不可预测的,有能工作的团队;
    2. 可重复级有大概的流程,不过过程可重复,有组织;
    3. 已定义级软件过程标准已文档化,有组织(SEPG)来管理标准并实施此标准,定义标准过程,保证过程的标准型和一致性;
    4. 已管理级能预定量化的目标,保证效率和质量,量化过程并采集过程数据来控制过程,是可预测的过程;
    5. 优化级改进过程,预防弱点,改进新技术。

    t},p;K5{8S0
     
    关键过程区域:KPA(key process area)

    过程域:指的是事情的某一方面,也是其中一方面。下面列举了CMM各等级里面的关键过程域。51Testing软件测试网 [0I6}!j W5jR

      CMM2:可重复阶段:51Testing软件测试网PV*V [1|2sNoV1r

      需求管理:requrement management51Testing软件测试网 yO0`'nB8w`2{)ct

      软件项目计划:software project planning

    C}#iU1z-M$ro0

      软件项目跟踪和监督:software project tracking oversight51Testing软件测试网4^ ZzsQCH)F\;s

      软件子合同管理:software subcontract management51Testing软件测试网#WP,N&g w0}

      软件质量保证:software quanlity assurance

    #p#oA9EA@O0

      软件配置管理:software configuratione management

    *c.~1o`s!m*b,Jj0

      CMM3:已定义阶段:

    ;S6v0DK\O/n2o*S0

      组织过程焦点:organization process focus51Testing软件测试网0Y ?]W$C

      组织过程定义:organization process definition51Testing软件测试网9A0f@b ri+w

      培训大纲:training program

    K }-|,^ c$i/M Y,_0

      集成软件管理:intergrated software management51Testing软件测试网J0` `lo r4\

      软件产品工程:software product engineering51Testing软件测试网Q D)f'x f3M

      组间协调:intergroup coordination

    X,XQTj/\ i0

      同行评审:peer review51Testing软件测试网)R:b}m}"K

      CMM4:已管理阶段:51Testing软件测试网1@{6NuTStd.\

      定量管理过程:quantitative process management51Testing软件测试网'n?H-CUohw

      软件质量管理:software quality management51Testing软件测试网6Bo,_1J _9I$n4g;u

      CMM5:优化阶段:

    Fb$]"[fh,Y0

      缺陷预防:defect prevention51Testing软件测试网6e8b,j,~D

      技术改革管理:technology change management51Testing软件测试网;}gx1{DVZ

      过程更改管理:process change management51Testing软件测试网JpS:JB0`b6W

    CMMI/CMM的用途:
    • 评估组用来识别组织的强处和弱点;
    • 评估组用来识别选择不同的业务承包商的风险和监督合同;
    • 管理者用来了解组织的能力并提高能力成熟度所进行的活动;
    • 技术人员和过程改进组的指南
    ISO9001与CMM的关系
    • 相似点:强调管理、过程、规范化和文档化
    • 不同点:CMM只针对软件;而ISO9001还包括硬件、流程材料和服务
    • 联系:CMM 2级与ISO9001强相关;CMM的每个关键过程域至少与ISO9001弱相关

    (更多CMM资料请点击:http://baike.baidu.com/view/8110.htm51Testing软件测试网^A1fu3Dh(U.H

    六西格玛(6σ)管理法

    特点:51Testing软件测试网 ^;XsX _#]Gf

    • 以质量为主线,以客户需求为中心,利用事实和数据的分析,改进组织的业务流程能力,灵活的、综合性的管理方法体系
    • 要求企业从外部客户角度来看待企业内部的各种流程
    • 利用客户的要求来建立标准,设立产品与服务的标准和规格。并以此来评价企业流程的有效性和合理性
    • 通过提高企业流程的绩效来提高产品质量服务的质量和企业整体竞争力
    • 塑造一流的企业文化

    六西格玛(6σ)水平利用事件概率积分来衡量产品的绩效和企业的水平。

    @e6Z0_Y5F%UN0
    • 6个西格玛=3.4失误/百万机会―意味着卓越的管理,强大的竞争力和忠诚的客户
    • 5个西格玛=230失误/百万机会-优秀的管理、很强的竞争力和比较忠诚的客户
    • 4个西格玛=6,210失误/百万机会-意味着较好的管理和运营能力,满意的客户
    • 3个西格玛=66,800失误/百万机会-意味着平平常常的管理,缺乏竞争力
    • 2个西格玛=308,000失误/百万机会-意味着企业资源每天都有三分之一的浪费
    • 1个西格玛=690,000失误/百万机会-每天有三分之二的事情做错的企业无法生存

    六西格玛(6σ)管理原则

    +A5~/^)K4Vzq4C0
    • 注重客户
    • 注重流程
    • 全员参与
    • 以防为主
    • 事实依据的决定
    • 持续和突破性改进

    六西格玛(6σ)改进区域51Testing软件测试网(o t.js?faq%NQ

    • 周期时间(流程个速度,回应能力)
    • 输出物的变差(产品和服务的直通率,缺陷成本降低,客户满意度提升)
    • 营运效率(更低成本)
    六西格玛(6σ)的实施方法:DMAIC过程
    • D(Define )—— 定义/界定:提出问题,确定目标
    • M(Measure)—— 量测:收集资料,查找原因
    • A(Analyze)—— 分析:研究资料,确定原因
    • I(Improve)—— 改进:优化解决
    • C(Control)—— 控制:推进控制
    六西格玛(6σ)管理组织结构:是成功实施6σ的重要保证。

     领导51Testing软件测试网i GXQ4X/}kO

    推动

    !jmaf/x0

    管理

    ,q e9N_tl$Bg0

    执行51Testing软件测试网WQeS^ J

    配合

    "gk4NHO eV0

    委员会

    cp+FU|1nN@e7@0

    倡导者51Testing软件测试网~6XmA ]

    全职工作者51Testing软件测试网I:jN/i A]_y:c0b4Z

    基层领导者

    +W*ze{&`y,D0

    兼职和员工

    S$rGK5S;h v u0

     

    1N4a(Qq;@(eX;Z2w+io0

     

    CY E}9f B0

    主黑带

    Kze+y?0wC)F P!}:~0

    黑带51Testing软件测试网k(s K t0K?D

    绿带

    lP,iJ!q$tX)EJ0
    51Testing软件测试网qEC+qx(I,D

    软件质量模型

    质量模型:一组特性及特性之间的关系,提供规定质量需求和评价质量的基础。51Testing软件测试网jOJ6^XrXx

    外部和内部质量

    • 功能性:软件提供满足明确和隐含需求的功能的能力
      • uH \8V8GIb0适合性:为指定的任务和用户目标提供一组合适的功能的能力。(手机的通话功能)51Testing软件测试网~2d(|k)b ~C'm

      • 51Testing软件测试网}'KhZGGn{

        准确性:提供所需精度的正确或相符的结果或效果的能力。(计算结果一致)

        DYO1M&^D4x9xZs?0
      • _X6o'p F q0互操作性:与一个或更多规定系统进行交互的能力。(word打印功能可以跟多种打印机搭配)51Testing软件测试网 ]Q\7n g"U

      • a&B&e/p r2fy0保密安全性:保护信息和数据的能力。(帐号密码的安全)

        ^%N Jq)_E.Y0
      • t YOLw3xX9bUx L0功能性的依从性:软件产品遵循与功能性相关的标准约定或法规以及类似规定的能力。(行业标准等)

        w~/TCyo-q2p0
    • 可靠性:软件产品维持规定的性能级别的能力
      • 2EF s4}1ifT0成熟性:为避免由软件中错误而导致失效的能力。(小错误不会影响软件正常工作)51Testing软件测试网](WA mQ0s"R-k+w

      • 51Testing软件测试网2[$@|2y'} B3Q5s$_%V+S

        容错性:软件出现故障或者违反指定接口的情况,软件维护规定的性能的性能级别的能力。(输入框输入错误的提示)

        {8g"l,@vMV0
      • *y+mkzsnfWk0易恢复性:在失效的情况下,重建规定的性能级别并恢复受影响数据的能力。(计算机死机重启)

        en}o1rI e0
      • l6Q-eq9Eq j1{;JE`0可靠性的依从性:软件产品遵循与功能性相关的标准约定或法规以及类似规定的能力。(行业标准等)51Testing软件测试网i s'Uwl6hR'H

    • 易用性:软件产品被理解、学习、使用和吸引用户的能力
      • 51Testing软件测试网#c*i8oGY8B9D!S v

        易理解性:用户理解软件是否合适的,以及用于特定任务和环境的能力。(用户知道软件是做什么的)51Testing软件测试网9GK+{ a9SE T

      • 51Testing软件测试网&c!J Xh'G(r~(kb;|:[

        易学性:用户学习和应用的能力。(用户不依赖于产品说明)

        Is-M'J;v'j0W'V&|0
      • 0FHN4Q*x-PA0易操作性:用户能操作和控制软件的能力。(操作简单、快捷)51Testing软件测试网.c F3J7?6dL

      • wb(i1t4n4_h0吸引性:吸引用户的能力。(游戏吸引玩家的能力)51Testing软件测试网F3O4E ?#f0gt

      • 51Testing软件测试网 Rs,?u f7J+j6|

        易用性的依从性:软件产品遵循与功能性相关的标准约定或法规以及类似规定的能力。(行业标准等)51Testing软件测试网/?:OJ%f*_r+v4O:l1K

    • 效率:相对使用资源的数量,提供适当性能的能力
      • 3Fi'}I9{8W*?8?,[0GYA0时间特性:软件执行过程中,适当的响应和处理时间以及吞吐率的能力。(系统响应时间)

        '|6H&u7AWG C8Y0
      • D7zc.P `HA8tX0资源利用性:使用合适的资源和类别的能力。(消耗内存量)

        ,eL:}Y7i bp0
      • \D%f nj3b0效率的依从性:软件产品遵循与功能性相关的标准约定或法规以及类似规定的能力。(行业标准等)

        q!g&Te%]S0
    • 维护性:软件产品可被修改的能力。包括修正、改进、功能变化的适应
      • $TG4[&T7\A0易分析性:诊断软件出现缺陷原因或识别修改部分的能力。(简单知道为什么出错)

        9]%P,Q0j&I&Q"}0
      • 51Testing软件测试网2B5QC5M]@ b8U:D&~

        易改变性:指定的修改可以被实现的能力。(升级简单)51Testing软件测试网U+^;} W0f3H*x K

      • 7j5[3i jN\ k0易测试性:被修改的软件能被确认的能力。(能简单识别软件被修改)

        ,C5}2W:Oyy0
      • (}6R:CI-H4Zt0维护性的依从性:软件产品遵循与功能性相关的标准约定或法规以及类似规定的能力。(行业标准等)51Testing软件测试网,Y2z}}f|,r8Q

    • 可移植性
      • 51Testing软件测试网$\_5SR OHe3bw

        适应性:软件适应不同的制定环境的能力。(软件适应多操作系统51Testing软件测试网2`Z"e#|s y![,ZG#~

      • h2`e F:w:~:k*ij:X }0易安装性:软件被安装的能力。(用户安装向导)

        _,jph(O0
      • z R A3Z?a5H0g~)B0共存性:在公共环境中同与其分享公共资源的其他独立软件共存的能力。(与其他软件同时可运行)51Testing软件测试网I*W_vp\ R

      • 51Testing软件测试网{W'_ q'G d+?7GR

        易替换性:替换相同用途的指定软件产品的能力。

        &G `z.Q1L/f&@5T#^0
      • 7Jp.@'Z%D2Gb4VE0可移植性的依从性:软件产品遵循与功能性相关的标准约定或法规以及类似规定的能力。(行业标准等)51Testing软件测试网hT,Ix x.|

    软件质量活动:

    主要的软件质量活动

    • 软件质量保证(SQA software quality assurance)
    • 测试
    SQA和测试的关系
    • SQA从流程方面保证软件的质量
    • 测试从技术方面保证软件的质量
    • 两者缺一不可
    SQA的主要工作范围
    • 指导并监督项目按照过程实施
    • 对项目进行度量、分析,增加项目的可视性
    • 审核工作产品,评价工作产品和过程质量目标的符合度
    • 进行缺陷分析,缺陷预防活动,发现过程的缺陷,提供决策参与,促进过程改进
    质量管理PDCA循环
    • P(plan)计划:计划设计
    • D(do)执行:实施执行
    • C(check)检查:检查检测
    • A(act)改进:纠正措施

    51Testing软件测试网(UW.jz~?'W(Z2u

    软件度量

    概念:

    度量:对事物属性的量化表示。51Testing软件测试网iUP2~l4p

    软件度量:对软件范围的测度,包括软件系统、构件或生命周期过程具有的某个给定属性的度的一个定量测量。51Testing软件测试网psH ^C#L yI8h#N

    目的:

    • 提高软件生产率,缩短产品研发周期,降低研发成本、维护成本
    • 提高软件产品质量,提高用户满意度
    • 为组织持续改进提供量化的指标和反馈

    作用:

    • 理解:通过度量,获得对过程、产品、资源的理解,确定以后预测的基线和模型。是其他作用的基础。
    • 预测:根据理解确定的模型,根据已知要素推算、估计其他要素,以便合理分配资源、合理定制计划。
    • 评估:分析活动与计划的符合度,确定偏差,以便控制执行。
      • 开发活动和计划的符合程度
      • 产品质量
      • 新技术的影响
    • 改进:根据量化的信息,帮助识别要因、查找问题的根源,以及提高产品质量和过程效率的方法;与以前的量化信息比较,验证方法的有效性。

    过程(五步法):

    这是以个循环的过程,不断改进的过程。是PDCA发展。51Testing软件测试网"[;T;I2X }L

    1. 识别目标(identify goal)
    2. 定义过程(define process)
    3. 收集数据(collect data)
    4. 分析数据(analyze data)
    5. 改进过程(improve process)

    分类:

    四个基本度量项

    J3C*G&XC8kj0
    • 规模(size):工作产品的大小
    • 工作量(effort):完成各软件工作产品和活动所用人时/人天
    • 进度(schedule):各软件工作产品和活动开始和结束的时间
    • 质量(quality)-缺陷(defect):各软件工作产品和活动中产生的缺陷数
    规模度量:

    ——SRS文档页数51Testing软件测试网'^3k] _A2B4a XQ x

    ——HLD文档页数51Testing软件测试网 Sn7W ^%V)x

    ——LLD文档页数

    k UL@I(Mm ~I0

    ——代码量(KLOG)51Testing软件测试网"`m(UN$]2P

    ——UT用例数51Testing软件测试网8ASYd} e

    ——IT用例数

    }&eP3t-];A2f0

    ——ST用例数

    t,]tTV$j0

    ……51Testing软件测试网Q b-\ FEML

    工作量度量:

    ——SRS所用人时数51Testing软件测试网(~ W-L+|-Xq/{:T

    ——HLD所用人时数51Testing软件测试网9oOM0[4t

    ——LLD所用人时数

    9~%OF&L0q~/p0

    ——编码所用人时数

    5Rth$a\#T.s*n/s0

    ——测试(UT、IT、ST)计划所用人时数51Testing软件测试网`T7[f9P;o

    ——测试(UT、IT、ST)方案所用人时数51Testing软件测试网4\)hD1L9L7d&q Q0]*l h

    ——测试(UT、IT、ST)用例所用人时数51Testing软件测试网x#o&Z TB

    ——测试(UT、IT、ST)执行所用人时数51Testing软件测试网g:{"l`B0Ks%[ R

    ……

    Y-M8F${;DtMg0
    进度度量:

    ——SRS阶段开始时间、结束时间

    V!g:uQ:Z H%T0

    ——HLD阶段开始时间、结束时间

    u H W;e3A$A0

    ——LLD阶段开始时间、结束时间51Testing软件测试网/k|Qn0r

    ——编码阶段开始时间、结束时间

    rc"f@ DX.{![0

    ——测试(UT、IT、ST)计划阶段开始时间、结束时间

    :u |T W:c0{0

    ——测试(UT、IT、ST)方案阶段开始时间、结束时间51Testing软件测试网LVVC2h]7s

    ——测试(UT、IT、ST)用例阶段开始时间、结束时间

    :o _o$b)pn0

    ——测试(UT、IT、ST)执行阶段开始时间、结束时间51Testing软件测试网8_fa@$Q{ v

    ……

    |9K w6u^6w1cE0
    缺陷度量

    ——SRS评审发现缺陷数51Testing软件测试网 aN[Ns)L_I

    ——HLD评审发现缺陷数

    F&t c:[Q _e2L0

    ——LLD评审发现缺陷数

    Q!hlXB0

    ——编码评审发现缺陷数

    /]S'Gz'A{0

    ——UT发现缺陷数

    ${B L+d!A0

    ——IT发现缺陷数51Testing软件测试网C.m8u+[TqlcGcZ

    ——ST发现缺陷数51Testing软件测试网ct Zg#^K&?

    ……

    (?UW*vLw+e0
    其他度量指标:

    缺陷密度:

    D%wM5j SLX4O0

    研发活动发现的缺陷密度51Testing软件测试网^P:|i@J ]-XJ6R

    研发活动引入的缺陷密度

    -hd\ j!L0

    工作产品的缺陷密度

    #AU1OYtggk0

    生产率:

    ]v2z%G}(v_0

    阶段文档生产率:页/人天、页/人时51Testing软件测试网hjXJ |

    编码生产率:KLOG/人天

    u$]:E%|NH)F0

    用例生产率:用例/人天

    ;[r"eAl+U5e0

    测试用例执行效率:执行用例数/人天51Testing软件测试网 f&t%oac V9znX

    用例密度:用例数/KLOG

    ?g$? Q6U/yK:g/~0r0

    ……51Testing软件测试网f4P^?Z6H%@n

    实际和计划的对照比较、总结分析、查找原因、改进完善,达到一个持续发展的过程。

  • 浅谈质量体系建立的步骤(转)

    2009-02-24 16:46:39

    建立、完善质量体系一般要经历质量体系的策划与设计,质量体系文件的编制、质量体系的试运行,质量体系审核和评审四个阶段,每个阶段又可分为若干具体步骤。

      一、质量体系的策划与设计

      该阶段主要是做好各种准备工作,包括教育培训,统一认识,组织落实,拟定计划;确定质量方针,制订质量目标;现状调查和分析;调整组织结构,配备资源等方面。

      (一)教育培训,统一认识

      质量体系建立和完善的过程,是始于教育,终于教育的过程,也是提高认识和统一认识的过程,教育培训要分层次,循序渐进地进行。

      第一层次为决策层,包括党、政、技(术)领导。主要培训:

      1.通过介绍质量管理和质量保证的发展和本单位的经验教训,说明建立、完善质量体系的迫切性和重要性;

      2.通过ISO9000族标准的总体介绍,提高按国家(国际)标准建立质量体系的认识。

      3.通过质量体系要素讲解(重点应讲解“管理职责”等总体要素),明确决策层领导在质量体系建设中的关键地位和主导作用。

      第二层次为管理层,重点是管理、技术和生产部门的负责人,以及与建立质量体系有关的工作人员。

      这二层次的人员是建设、完善质量体系的骨干力量,起着承上启下的作用,要使他们全面接受ISO9000族标准有关内容的培训,在方法上可采取讲解与研讨结合,理论与实际结合。

      第三层次为执行层,即与产品质量形成全过程有关的作业人员。对这一层次人员主要培训与本岗位质量活动有关的内容,包括在质量活动中应承担的任务,完成任务应赋予的权限,以及造成质量过失应承担的责任等。

      (二)组织落实,拟定计划

      尽管质量体系建设涉及到一个组织的所有部门和全体职工,但对多数单位来说,成立一个精干的工作班子可能是需要的,根据一些单位的做法,这个班子也可分三个层次。

      第一层次:成立以最高管理者(厂长、总经理等)为组长,质量主管领导为副组长的质量本系建设领导小组(或委员会)。其主要任务包括:

      1.体系建设的总体规划;

      2.制订质量方针和目标;

      3.按职能部门进行质量职能的分解。

      第二层次,成立由各职能部门领导(或代表)参加的工作班子。这个工作班子一般由质量部门和计划部门的领导共同牵头,其主要任务是按照体系建设的总体规划具体组织实施。

      第三层次:成立要素工作小组。根据各职能部门的分工明确质量体系要素的责任单位,例如,“设计控制”一般应由设计部门负责,“采购”要素由物资采购部门负责。

      组织和责任落实后,按不同层次分别制定工作计划,在制定工作计划时应注意:

      1.目标要明确。要完成什么任务,要解决哪些主要问题,要达到什么目的?

      2.要控制进程。建立质量体系的主要阶段要规定完成任务的时间表、主要负责人和参与人员、以及他们的职责分工及相互协作关系。

      3.要突出重点。重点主要是体系中的薄弱环节及关键的少数。这少数可能是某个或某几个要素,也可能是要素中的一些活动。

    [NextPage]

      (三)确定质量方针,制定质量目标

      质量方针体现了一个组织对质量的追求,对顾客的承诺,是职工质量行为的准则和质量工作的方向。

      制定质量方针的要求是:

      1.与总方针相协调;

      2.应包含质量目标;

      3.结合组织的特点;

      4.确保各级人员都能理解和坚持执行。

      (四)现状调查和分析

      现状调查和分析的目的是为了合理地选择体系要素,内容包括:

      1.体系情况分析。即分析本组织的质量体系情况,以便根据所处的质量体系情况选择质量体系要素的要求。

      2.产品特点分析。即分析产品的技术密集程度、使用对象、产品安全特性等,以确定要素的采用程度。

      3.组织结构分析。组织的管理机构设置是否适应质量体系的需要。应建立与质量体系相适应的组织结构并确立各机构间隶属关系、联系方法。

      4.生产设备和检测设备能否适应质量体系的有关要求。

      5.技术、管理和操作人员的组成、结构及水平状况的分析。

      6.管理基础工作情况分析。即标准化、计量、质量责任制、质量教育和质量信息等工作的分析。

      对以上内容可采取与标准中规定的质量体系要素要求进行对比性分析。

      (五)调整组织结构,配备资源

      因为在一个组织中除质量管理外,还有其他各种管理。组织机构设置由于历史沿革多数并不是按质量形成客观规律来设置相应的职能部门的,所以在完成落实质量体系要素并展开成对应的质量活动以后,必须将活动中相应的工作职责和权限分配到各职能部门。一方面是客观展开的质量活动,一方面是人为的现有的职能部门,两者之间的关系处理,一般地讲,一个质量职能部门可以负责或参与多个质量活动,但不要让一项质量活动由多个职能部门来负责。目前我国企业现有职能部门对质量管理活动所承担的职责、所起的作用普遍不够理想总的来说应该加强。

      在活动展开的过程中,必须涉及相应的硬件、软件和人员配备,根据需要应进行适当的调配和充实。

      二、质量体系文件的编制

      质量体系文件的编制内容和要求,从质量体系的建设角度讲,应强调几个问题:

      1.体系文件一般应在第一阶段工作完成后才正式制订,必要时也可交叉进行。如果前期工作不做,直接编制体系文件就容易产生系统性、整体性不强,以及脱离实际等弊病。

      2.除质量手册需统一组织制订外,其它体系文件应按分工由归口职能部门分别制订,失提出草案,再组织审核,这样做有利于今后文件的执行。

      3.质量体系文件的编制应结合本单位的质量职能分配进行。按所选择的质量体系要,素,逐个展开为各项质量活动(包括直接质量活动和间接质量活动),将质量职能分配落实到各职能部门。质量活动项目和分配可采用矩阵图的形式表述,质量职能矩阵图也可作为附件附于质量手册之后。

      4.为了使所编制的质量体系文件做到协调、统一,在编制前应制订“质量体系文件明细表”,将现行的质量手册(如果已编制)、企业标准、规章制度、管理办法以及记录表式收集在一起,与质量体系要素进行比较,从而确定新编、增编或修订质量体系文件项目。

    [NextPage]

      5.为了提高质量体系文件的编制效率,减少返工,在文件编制过程中要加强文件的层次间、文件与文件间的协调。尽管如此,一套质量好的质量体系文件也要经过自上而下和自下而上的多次反复。

      6.编制质量体系文件的关键是讲求实效,不走形式。既要从总体上和原则上满足 ISO9000族标准,又要在方法上和具体做法上符合本单位的实际。三、质量体系的试运行

      质量体系文件编制完成后,质量体系将进入试运行阶段。其目的,是通过试运行,考验质量体系文件的有效性和协调性,并对暴露出的问题,采取改进措施和纠正措施,以达到进一步完善质量体系文件的目的。

      在质量体系试运行过程中,要重点抓好以下工作:

      1.有针对性地宣贯质量体系文件。使全体职工认识到新建立或完善的质量体系是对过去质量体系的变革,是为了向国际标准接轨,要适应这种变革就必须认真学习、贯彻质量体系文件。

      2.实践是检验真理的唯一标准。体系文件通过试运行必然会出现一些问题,全体职工立将从实践中出现的问题和改进意见如实反映给有关部门,以便采取纠正措施。

      3.将体系试运行中暴露出的问题,如体系设计不周、项目不全等进行协调、改进。

      4.强信息管理,不仅是体系试运行本身的需要,也是保证试运行成功的关键。所有与质量活动有关的人员都应按体系文件要求,做好质量信息的收集、分析、传递、反馈、处理和归档等工作。

      四、质量体系的审核与评审

      质量体系审核在体系建立的初始阶段往往更加重要。在这一阶段,质量体系审核的重点,主要是验证和确认体系文件的适用性和有效性。

      1.审核与评审的主要内容一般包括:

      (1)规定的质量方针和质量目标是否可行;

      (2)体系文件是否覆盖了所有主要质量活动,各文件之间的接口是否清楚;

      (3)组织结构能否满足质量体系运行的需要,各部门、各岗位的质量职责是否明确;

      (4)质量体系要素的选择是否合理;

      (5)规定的质量记录是否能起到见证作用

      (6)所有职工是否养成了按体系文件操作或工作的习惯,执行情况如何。

      2.该阶段体系审核的特点是:

      (1)体系正常运行时的体系审核,重点在符合性,在试运行阶段,通常是将符合性与适用性结合起来进行;

      (2)为使问题尽可能地在试运行阶段暴露无遗,除组织审核组进行正式审核外,还应有广大职工的参与,鼓励他们通过试运行的实践,发现和提出问题;(3)在试运行的每一阶段结束后,一般应正式安排一次审核,以便及时对发现的问题进行纠正,对一些重大问题也可根据需要,适时地组织审核;

      (4)在试运行中要对所有要素审核覆盖一遍;

      (5)充分考虑对产品的保证作用;

      (6)在内部审核的基础上,由最高管理者组织一次体系评审。

      应当强调,质量体系是在不断改进中行以完善的,质量体系进入正常运行后,仍然要采取内部审核,管理评审等各种手段以使质量体系能够保持和不断完善。

  • 质量保证工程师(QA)岗位职责(转)

    2009-02-24 16:42:07

    质量保证工程师(QA)岗位职责

    一、工作摘要

    负责所分配项目质量保证计划的制订、项目开发过程中的质量保证的审计、组织阶段评审(含技术评审,决策评审,里程碑评审)、项目风险识别、预警。研发流程的执行监督、反馈、数据收集。运用规范的流程引导项目全员参与。对不符合项进行报告/追踪解决。负责度量数据的收集、文档维护、培训支持等。

    二、工作职责

    No.

    类别

     

     

    1

    项目质量保证

    制订具体项目的质量保证计划及执行

    Ø        根据公司质量目标及项目实际情况,制订项目的质量保证计划,计划应当明确定义开发各阶段的质量保证活动和项目质量目标;严格执行质量保证计划。

    Ø        依据质量保证计划审计项目是否按照过程要求执行了相应活动,是否按照过程要求产生了相应工作产品,并对工作成果的合理性进行审计;并按时提交项目的质量报告。

    Ø        对不符合项有权发出不符合问题报告,并要求项目组分析原因采取措施预防再次发生,同时跟踪直到验证解决。

    2

    评审

    评审的组织

    Ø        根据项目计划,适时组织项目阶段评审(含技术评审,决策评审,里程碑评审);

    Ø        审核评审材料的正确性、前后关联性、规范性;

    Ø        评审结果形成报告,提交相关领导审核,OA上提交;

    Ø        跟踪直至所有评审中发现的缺陷已被关闭;

    3

    风险控制

    项目风险识别、预警

    Ø        识别项目风险,组织进行风险等级评估以及可能会对项目的影响,督促项目经理采取风险预防措施;

    Ø        督促项目经理更新项目进度计划,使其包含与所采用的风险措施

    Ø        监督项目风险预防或缓解措施的执行;

    Ø        定期对已识别的项目风险组织重新评估以确定风险状态是否已发生变化。

    4

    度量数据

    参与项目考核和产品效益考核

    Ø        根据考核制度收集项目过程绩效数据,并对项目奖考核、产品效益奖考核提供考核数据,形成记录;

    Ø        按项目类型,逐步建立不同类型项目的过程能力基准数据(进度计划达成率,生产率、工作量分布等);

    Ø        分析过程能力基准数据的变化,度量过程改进实际效果

    5

    研发流程

    研发流程的执行监督、反馈、数据收集

     

    Ø        研发流程,发现存在的问题并及时反馈,识别流程优化的机会点并提出可行的优化解决方案;

    Ø        搜集项目组反馈,不断根据公司发展改进优化现有流程。

    Ø        定期向流程组提供项目中流程执行情况及有关数据;

    6

    质量事故

    负责产品研发质量事故的原因调查

    Ø        对于研发过程中,因人为因素造成产品出现严重质量事故,由QA进行跟踪调查,分析其根本原因,并向组织通报质量事故。QA在下次执行同类项目时,及早提醒项目经理采取预防措施。

    7

    文档维护

    项目文档维护管理

    Ø        妥善存放项目开发过程中的管理文档;

    Ø        阶段评审通过的项目资料提交配置管理工程师入基线库;

    Ø        项目验收后的纸质开发文档列文档清单后提交文控中心存档;

    8

    培训支持

    相关培训支持

    Ø        对外提供项目管理、质量保证、项目管理工具方面的培训

  • 基于测试用例进行测试管理(转)

    2009-02-12 11:57:23

    对于产品来说,如何通过黑盒测试来保证产品的质量是一件很艰苦的事,手工测试人员一遍遍的进行测试,最大程度的发现产品中的缺陷。个人认为,在黑盒测试中,测试的核心工作内容应围绕着测试用例来进行。下面为个人对“基于测试用例进行测试管理”的一些认识。

      我们都知道,测试,不管是白盒,黑盒,功能或性能测试都离不开测试用例,可以怎么说,测试用例是一切测试的基础,也是测试的核心地区。测试用例设计的好与坏,完善与不完善都直接影响到测试的效果,产品的质量保证。下图为一个简单测试用例中心图,大家可以自行扩展,进行添加或删除。

      

      图:测试用例中心

      上图完全是与测试用例为核心进行管理,下面进行解释:

      1、软件测试的几个关键过程可以通过中间一列进行表示出来,一般测试人员在进行参与项目测试时,首先应该由测试负责人根据软件需求进行测试需求提起,然后通过测试需求来确定项目测试的目标和缺陷判定标准。测试策略是根据测试需求来制定详细规划,最后分发到各个编写测试用例人员手中进行测试用例编写。在进行测试用例评审过程中,可以发现测试用例为中心管理第一点好处,测试用例编写反应出测试人员对需求的理解程度。通过“需求——测试用例”,逐渐达到熟悉软件需求和用例完善。

      2、再看第二点,执行测试用例发现软件缺陷,通过图中的“软件缺陷——测试用例”,也构成一个小循环,执行人员在执行测试用例时,能发现测试人员编写用例水平情况,完善程度。而测试用例也能让软件缺陷被发现越多,提供给开发人员的缺陷描述越准确。这也就是第二点好处。

      3、“软件缺陷——测试需求”可以看成一个大循环,通过对需求的理解可以设计出测试用例,通过执行测试用例可以发现软件缺陷,反过来也一样,通过软件缺陷可以反应出测试用例是否完善,也能反应出需求的不完善,促进项目产品的功能越来越完善。

      4、通过编写测试用例效率,执行测试用例速度情况,都能看出一个测试人员对业务知识的掌握情况,掌握越多,编写用例肯定比较完善,执行人员也能快速执行用例发现问题。通过测试用例编写与执行情况,可以促进业务知识方面进行培训,这是第四点,“业务知识——测试用例”的循环。

      5、测试用例是测试人员进行的一项测试工作,也是耗时最长,需要消耗精力最多的测试工作,如何保证后续产品能快速测试并且能保证产品质量,这就需要进行回归测试,可以使用自动化测试进行,但对于没有进行自动化测试的公司来说,从测试用例中挑选一批高质量的回归测试用例,在每次新版本中,进行快速回归测试也是一种不错的做法。

      6、当然即使进行自动化测试,也还是需要进行编写自动化测试用例,开始的测试用例如果编写完善,详细的话,一些用例可以直接做为自动化用例,这样也提高了测试效率,第六点。

      7、而对于测试部门来说,测试知识库的积累显的至关重要,完善的知识库,不但可以让新员工快速对公司产品测试上手,测试用例库是一个最好的积累,新员工可以通过阅读用例快速掌握产品功能,业务知识,常用的测试手段,用例书写方法等。而且对一些测试技巧也能很好的提高。

      8、测试用例知识库的积累还能使迭代开发的项目,减少很多书写测试用例的时间,对于新项目,可以进行项目测试用例的迁移整理,修改。而不是重新书写新的测试用例,,,第8点。

      9、测试绩效考核,一些公司通过编写测试用例数量,执行用例数量,发现缺陷效率等来进行,这些都和测试用例有关。所以说,测试用例的好与坏,不仅直接影响到测试效率,而且影响到测试人员的绩效效率。

      上面只是介绍一些和测试用例挂钩方面,下面说一些具体做法:

      测试用例编写:

      在测试负责人分配测试用例编写计划后,最好由业务知识熟悉的员工进行用例编写,每周进行一次用例评审,直到测试用例编写完成。

      测试用例维护:

      其实基于测试用例进行测试管理的重点就在“测试用例的维护”,好的维护才能保证用例的有效性,实施性。一般测试用例维护最好在每周组织测试人员,对测试用例进行维护和更新。一般用例需要改变会有以下几种原因:

      1、软件需求的改变——这个应该遵循“需求变更控制”进行管理,相应的用例变更。

      2、测试人员对需求的理解错误——导致设计的用例错误

      3、开发人员的设计文档进行变动——用例修改更新

      4、测试用例的遗漏——测试用例补充

      5、版本发布后,用户反馈的缺陷——重现缺陷,补充或修改用例。

      通过上面每周组织测试人员进行用例更新维护,用例库会在软件产品的更新中不断的完善,也就让测试用例的覆盖逐渐的完善了。最后当项目结束后,就能得到一份完善的用例库。至于用例库的管理,可以参照公司对应的“配置管理实施”。

      总之,“基于测试用例进行测试管理”——关键就是测试用例的维护,要保证测试用例与产品功能一致性。

    版权声明:原创作品,允许转载,转载时请务必以超链接形式标明文章原始出处作者信息本声明,否则将追究法律责任。

    本文出自hjjlearning的51Testing软件测试博客:http://www.51testing.com/?18049

  • SQA测试过程(转)

    2009-02-12 11:45:29

    测试生命周期

      测试计划 → 测试设计 → 测试开发 → 测试执行 → 测试评估

      测试计划就是定义一个测试项目的过程,以便能够正确的度量和控制测试。

      第一部分:测试计划

      测试计划的问题:

      1、测试计划经常是等到开发周期后期才开始实行,使得没有时间有效的执行计划;

      2、测试计划的组织者可能缺乏Client/Server测试经验;

      3、测试的量度和复杂性可能太大,没有自动化工具,很难计划和控制。

      测试策略:

      测试策略描述测试工程的总体方法和目标。描述目前在进行哪一阶段的测试(单元测试、集成测试、系统测试)以及每个阶段内在进行的测试种类(功能测试性能测试、压力测试等)。

      测试策略包括

      1、要使用的测试技术和工具;

      2、测试完成标准;

      3、影响资源分配的特殊考虑例如测试与外部接口或者模拟物理损坏、安全性威胁。

      测试计划最关键的一步就是将软件分解成单元,写成测试需求。

      测试需求有很多分类方法,最普通的一种就是按照商业功能分类。把软件分解成单元元件有几个好处:

      1、测试需求是测试设计和开发测试用例的基础,分成单元可以更好地进行设计;

      2、详细的测试需求是用来衡量测试覆盖率的重要指标;

      3、测试需求包括各种测试实际和开发以及所需资源。

      怎样估计测试工作量:

      1、效率假设:即测试队伍的工作效率。对于功能测试,这主要依赖于应用的复杂度,窗口的个数,每个窗口中的动作数目。对容量测试,主要依赖于建立测试所需数据的工作量大小。

      2、测试假设:为了验证一个测试需求所需测试动作数目。

      3、应用的维数:应用的复杂度指标。例如要加入一个记录,测试需求的维数就是这个记录中域的数目。

      4、所处测试周期的阶段:有些阶段主要工作都在设计,有些阶段主要是测试执行。

      测试资源:

      1、人力资源

      测试经理

      为测试项目提供总体方向。开发测试计划、征集并监督测试人员、申请系统资源、监视并汇报工作进程、测试评估、测试需求的分解。

      测试工程师 ---- 设计和开发

      设计:对被测软件的详细了解、分解测试需求的技能、选择在C/S环境下用来验证测试需求的技术。

      开发:熟悉SQA、VB、和脚本语言。

      测试工程师 ---- 执行

      负责测试执行和记录结果。需要能够安装系统,网络知识,初始化数据库其他初始条件。重要的是诊断能力。

      测试系统管理者

      每个测试项目必须指定一个专人负责管理SQA Suite。包括在服务器上安装存储库,安装打印机连接,执行备份,以及其他维护工作。管理者必须高度熟悉SQA,网络工作经验。

      2、系统资源

      安装SQA Suite的硬件和软件环境

      数据库服务器

      该服务器必须专用于 测试工作,能够重置某些初始值,包括系统日期和时间等。

    写测试计划的步骤:

      1、确定工程

      收集下列信息

      文档 已创建(是/否) 版本/日期

      需求详述

      功能详述

      项目计划

      设计详述

      原型

      用户手册

      定义新的工程,Adminà New Project。

      确定软件的结构,用Assetsà Software Structure选项定义软件结构。

      2、定义测试策略

      测试策略项 例子

      测试阶段 系统测试

      测试类型 功能测试

      测试技术 75%用SQA Suite自动测试,25%手工测试

      完成标准 95%测试用例通过并且最高级缺陷全部解决

      特殊考虑 测试必须在上午进行

      3、分解软件,写测试需求

      分析各种信息

      反复检查并理解各种信息,和用户交流,理解他们的要求。可以按照以下步骤执行:

      1)确定软件提供的主要商业任务

      2)对每个商业任务,确定完成该任务所要进行的交易。

      3)确定从数据库信息引出的计算结果。

      4)对于对时间有要求的交易,确定所要的时间和条件。这些条件包括数据库大小、机器配置、交易量、以及网络拥挤情况。

      5)确定会产生重大意外的压力测试,包括:内存、硬盘空间、高的交易率

      6)确定应用需要处理的数据量。

      7)确定需要的软件和硬件配置。通常情况下,不可能对所有可能的配置都测试到,因此要选择最有可能产生问题的情况进行测试,包括:最低性能的硬件、几个有兼容性问题的软件并存、客户端机器通过最慢的LAN/WANF连接访问服务器。

      8)确定其他与应用软件没有直接关系的商业交易。包括:

      管理功能,如启动和推出程序

      配置功能,如设置打印机

      操作员的爱好,如字体、颜色

      应用功能,如访问email或者显示时间和日期。

      9)确定安装过程,包括定置从哪安装、定制安装、升级安装。

      10)确定没有隐含在功能测试中的户界面要求。大多界面都在功能测试时被测试到。还有写没有测到,如:操作与显示的一致性,如使用快捷键等;界面遵从合理标准,如按钮大小,标签等。

      把需求组织成层次图

      4、估计测试工作量

      ∑(每个测试的时间*每个需求的测试的数目*测试需求的的数目)

      (测试设计、开发、…)

    5、确定资源

      人力资源

      职位                    姓名         特殊责任/说明

      测试经理

      测试工程师

      设计/开发(可以多人)

      测试工程师

      测试执行(可以多人)

      测试系统管理员

      系统资源

      系统                     名称/类型

      数据库服务器

      网络/子网

      服务器名称

      数据库名称

      SQA 测试存储库

      网络/子网

      服务器名称

      客户测试机

      包括专门的配置需求列表

      测试开发的PC机列表

      6、创建工程调度表

      任务         相关工作量(天)

      整个SQA过程          38

      测试计划             12

      确定项目             1

      定义测试策略

      决定测试需求

      估计工作量

      确定资源

      调度测试活动

      生成测试计划文档

      测试设计              7

      分析测试需求

      指定测试过程

      指定测试用例

      查看测试需求的覆盖率

      测试开发              12

      建立测试开发环境

      录制和回放原型过程

      开发测试过程

      测试和调试测试过程

      修改测试过程

      建立外部数据集合

      重新测试并调试测试过程

      测试执行               6

      设置测试系统

      执行测试

      验证测试结果

      调查突发结果(unexpected result)

      生成缺陷日记

      测试评估               1

      回顾测试日记

      评估测试需求的覆盖率

      评估缺陷

      决定是否达到测试完成的标准

    7、书写测试计划

      1)介绍

      目的

      背景

      测试范围

      项目文件列表

      2)测试需求

      3)测试策略

      ◇ 测试类型

        ● 功能测试

        ● 用户界面测试

        ● 性能测试

        ● 压力测试

        ● 容量测试

        ● 配置测试

        ● 安装测试

      ◇ 工具

      4)资源

      人力资源

      系统资源

      5)调度

      6)文档

      软件元件

      测试特性(Assets)

      测试日记

      缺陷报告

      第二部分:测试设计

      测试设计的问题

      1、不做测试设计,测试过程也是胡乱建立的。

      2、测试设计不详细,不是基于可量度的测试策略,例如测试计划覆盖一个集合或者测试需求的一个子集。

      3、测试过程没有采用最好的技术来检验Windows C/S结构的测试需求

      测试用例的选择规则

      1、选择与测试需求的实质部分最相关的测试用例。

      2、选择的测试用例应该不容易应用程序的改变的影响。

      下面是选择测试用例的几点具体规则:

      1、商业函数

      商业函数一般与数据库有关,要测试数据库的变化,有几种方法:

      1)如果数据库的的改变会反映在一个列表框中,那么就要选择验证列表框内容的测试用例。

      2)还可以检查交易完成后的确认对话框。可以检查对话框的标题。图象比较也可以检查确认对话框,但图象比较容易受其他因素影响。

      3)修改脚本,SQA Basic提供了强大的数据库支持。

      2、域的验证

      各种不同的域选择相应的测试用例。

      3、用户界面测试

      对象状态测试用例

      4、性能标准

      等待状态测试用例

      5、压力下的操作

      6、访问控制

      Object state test case

      7、配置测试

      不能选择图象测试用例(也分辨率有关)和文件测试用例(与驱动器有关)

      8、安装选项和验证

      对象状态用例和窗口存在用例,文件存在用例。

      书写测试设计的步骤

      生成测试需求报告
         ↓
      指定测试过程
         ↓
      指定测试用例(可选)
         ↓
      回顾测试覆盖率

    第三部分:测试开发

      输入:被测软件、基于测试需求的测试设计

      输出:测试过程和测试用例

      目标:

      1、创建可以重用的测试过程和测试用例

      2、维护测试过程、测试用例与相关测试需求的一一对应。

      测试开发的问题:

      1、测试开发很乱,与测试需求或测试策略没有对应性

      2、测试过程不可重复或不可重用

      3、测试过程被作为一个编程任务来执行,导致脚本太长,不能满足软件移植性的要求。

      错误处理——当测试过程发生错误时,有几种解决办法:

      1、跳转到别的测试过程

      2、调用一个能够清除错误的过程

      3、退出过程,启动另一个

      4、退出过程和应用程序,重新启动启动Windows,在失败的地方重新开始测试

      测试开发的步骤

      1、设立开发环境

      SQA Suite

      连接到SQA存储库

      启动SQA Baisc或VB

      被测软件

      等等

      2、录制和回放原型过程

      原型过程指出所有未知窗口控制,使得他们都能象标准窗口那样动作或者没有特别的动作,把他们都划归为Generic类型。通过这个过程,SQA Robot就知道该怎样处理应用中的特殊控制。

      1、把recording option 中的Define Unknown Object as Type Generic选项设置为off

      2、使用的过程标识符要可以被覆盖,或者能被删掉。因为这只是个原型,用来教SQA Robot 录制的过程

      3、录制测试过程和测试用例

      1、录制模块测试过程和与测试需求最低层对应的测试用例;

      2、录制初始化过程;

      3、录制导航过程,把前面的过程串起来;

      4、测试和调试测试过程

      5、修改测试过程(可选)

      6、建立外部数据集合

      如果测试过程是用来循环一套输入和输出数据,就需要建立数据集合。

      7、重复测试和调试测试过程,回到4

    第四部分:测试执行

      测试执行的问题

      1、自动化测试没有有效的利用,使得手工测试太多。

      2、测试结果的捕获没有系统性,而且没有查看或调查

      3、缺陷报告必须用手工加入缺陷跟踪系统

      错误分类

      1、测试用例失败

      正常错误

      2、脚本命令失败

      当测试过程不能不能执行录制过程中的某个功能时,回产生这种错误,如鼠标单击按钮或选择菜单项等。它也能指示是缺陷还是测试过程的设计问题。

      3、致命错误

      导致测试停止,这种情况最好重起Windows。

      具体步骤:

      1)建立测试系统

      2)准备测试过程

      3)运行初始化过程

      4)执行测试

      5)从终止的测试恢复

      6)验证预期结果

      7)调查突发结果

      8)记录缺陷日记

      第五部分:测试评估

      测试评估的目标

      1、量化测试进程

      2、生成缺陷和测试覆盖率的总结报告

      测试评估的问题

      1、没有把测试覆盖率作为报告测试进程的根据,使得不知测试是否结束;

      2、没有做缺陷评估,缺陷评估是量度软件可行性的重要指标;

      3、不使用专门的软件工具进行数据输入任务和相应的评估活动,使得这些任务变得繁重累人。

      测试覆盖率

      评估测试完成多少的标准

      缺陷评估

      评估软件质量的重要指标,通常评估模型假设缺陷的发现是呈泊松分布的;严格的缺陷评估要考察在测试过程中发现缺陷的间隔时间长短。评估要估计软件当前的可靠性并预测随着测试的继续进行,软件可靠性会怎样提高。

      SQA Suite 提供四种形式进行缺陷评估:

      1、缺陷分布报告可以生成缺陷数量与缺陷属性的函数。如测试需求和状态。

      2、缺陷趋势报告可以看出缺陷增长和减少的趋势;

      3、缺陷年龄报告展示一个缺陷处于某种状态的时间长短

      4、测试结果进度报告展示测试过程在被测应用的几个版本中的执行结果以及测试周期。

      具体步骤

      1、回顾测试日记

      2、评估测试需求的覆盖率

      3、分析缺陷

      4、决定是否达到完成测试的标准,没有满足标准时

      1)再测试

      2)降低标准

      3)确定软件的一个满足标准的子集,看是否可以发布。

  • 测试用例制定的原则

    2009-02-11 23:40:40

    测试用例要包括欲测试的功能、应输入的数据和预期的输出结果。测试数据应该选用少量、高效的测试数据进行尽可能完备的测试;基本目标是:设计一组发现某个错误或某类错误的测试数据,测试用例应覆盖方面:

      1、 正确性测试:输入用户实际数据以验证系统是满足需求规格说明书的要求;测试用 例中的测试点应首先保证要至少覆盖需求规格说明书中的各项功能,并且正常。

      2、 容错性(健壮性)测试:程序能够接收正确数据输入并且产生正确(预期)的输出, 输入非法数据(非法类型、不符合要求的数据、溢出数据等),程序应能给出提示 并进行相应处理。把自己想象成一名对产品操作一点也不懂的客户,在进行任意操作。

      3、 完整(安全)性测试:对未经授权的人使用软件系统或数据的企图,系统能够控制的程度,程序的数据处理能够保持外部信息(数据库或文件)的完整。

      4、 接口间测试:测试各个模块相互间的协调和通信情况,数据输入输出的一致性和正确性。

      5、 数据库测试:依据数据库设计规范对软件系统的数据库结构、数据表及其之间的数据调用关系进行测试。

      6、 边界值分析法:确定边界情况(刚好等于、稍小于和稍大于和刚刚大于等价类边界值),针对我们的系统在测试过程中主要输入一些合法数据/非法数据,主要在边界值附近选取。

      7、 压力测试:输入10条记录运行各个功能,输入30条记录运行,输入50条记录运行。。。进行测试。

      8、等价划分:将所有可能的输入数据(有效的和无效的)划分成若干个等价类。

      9、错误推测:主要是根据测试经验和直觉,参照以往的软件系统出现错误之处。

      10、效率:完成预定的功能,系统的运行时间(主要是针对数据库而言)。

      11、可理解(操作)性:理解和使用该系统的难易程度(界面友好性)。

      12、可移植性:在不同操作系统及硬件配置情况下的运行性。

      13、回归测试:按照测试用例将所有的测试点测试完毕,测试中发现的问题开发人员 已经解决,进行下一轮的测试。

      14、比较测试:将已经发版的类似产品或原有的老产品与测试的产品同时运行比较,或与已往的测试结果比较 。

      说明:针对不同的测试类型和测试阶段,测试用例编写的侧重点有所不同。

      1、 其中第1、2、6、8、9、13项为模块(组件、控件)测试、组合(集成)测试、系统测试都涉及并重点测试的方面。

      2、 单元(模块)测试(组件、控件)测试:重点测试第5项。

      3、 组合(集成)测试:重点进行接口间数据输入及逻辑的测试,即第4项。

      4、 系统测试:重点测试第3、7、10、11、12、14项。

      5、 其中压力测试和可移植性测试如果是公司的系列产品,可以选用其中有代表性的产品进行一次代表性测试即可。

      6、 GMPS基础测试用例设计完成后,其他的测试项目只编写设计与之不同部分的测试用例。

      7、 对于每个测试项目测试的测试用例不是一成不变的,随着测试经验的积累或在测试其他项目发现有测试不充分的测试点时,可以不断的补充完善测试项目的测试用例。

  • 测试执行的用例选择原则(转载)

    2009-02-11 23:39:03

    “抢钱原则”——你面对飘洒满地的纸币,有100元,50元,10元,5元,2元,1元,5毛,2毛,1毛。 各种面值。大家抢钱的时候,都是先挑选100元的抢走,然后找50元的,选择的顺序很清晰,都是从面值大到面值小。这就是“抢钱”原则。

      测试执行的时候,大家面对是一堆用例,这些用例起到的作用也是不同的,那么如何保证我们在有限的时间执行的用例是最有效的,最有价值的。

      尤其是无法全部执行用例的时候,势必有裁剪的时候,我们需要有很好的用例执行的优选原则。

      我们要应用抢钱原则,选择好最有价值的用例优先执行。那么,如果搞清楚什么样的用例最有价值,就OK。

      用例价值大的用例主要有三个方面的因素:1 容易发现的故障的用例;2 用户最常用的场景;3 如果泄露,用户的生气程度大的。

      1、容易发现故障的用例

      1) 性能相关的用例—上游的环境受限,所以这个部分比如容易发现故障

      2) 边界值相关用例—边界引发的故障比例最高

      3) 开发部在集成测试最不容易做到的用例,比如场景复杂度高的

      2、用户最常用的场景

      1) 比如局内呼叫,做主叫,做被叫,短消息,预付费,彩铃等多是最常用的业务,这些业务如果出现问题,只有回退版本了。

      2) 配置管理的号码分析,动态管理的查看链路状态,告警查看

      3、如果泄露,用户生气程度大的

      1) 比如无法拨打电话 > 可拨打,单通 > 可以正常通话,无回铃音 > 可以正常通话,回铃音有杂音

      2) 无法出话单 > 话单内参数错误

      如上的仅仅是一些实例,没有复杂的算法模型来排序用户行为。

      总之:拿到用例,一定要先分析出最有价值的用例,再开始执行。如果拿到用例,平铺直叙的执行。 那咱不就成了抢钱时候先抢毛票的傻子了?

    版权声明:原创作品,允许转载,转载时请务必以超链接形式标明文章原始出处 、作者信息和本声明,否则将追究法律责任。

    本文出自gracehjd的51Testing软件测试博客:http://www.51testing.com/?92844

我的栏目

我的存档

数据统计

  • 访问量: 5480
  • 日志数: 11
  • 建立时间: 2009-02-11
  • 更新时间: 2009-02-25

RSS订阅

Open Toolbar