作为测试Leader如何保证测试的质量？？？

xuminghua

请各位测试Leader级别的人指教，在测试Leader这个位置上如何去保证测试的质量，以及如何安排详细的计划？？？

tnt277

楼主你说的测试的质量 你对测试的质量的定义是什么？

xuminghua

测试质量就是说所测试过的画面，怎么保证画面的质量；比如说测试完之后，还存在很多ｂｕｇ，那这也就说明这个画面被测试完之后，质量没有得到保证！作为测试Ｌｅａｄｅｒ应该如果防止这种事情发生呢？？？

tnt277

检查测试用例的覆盖率,尽量争取大的覆盖率

没有规则的时候,先制定一些规则(也就是测试用例编写的一些条件)
对于漏掉的，可以根据情况添加到规则中

cm0214

两条线，一条把住产品没有大的问题，一条把手下培养成可堪重负的人才

hummel

个人意见:
1.测试流程,通过流程来约束,使测试质量的提高.关键还是在于提高案例的质量.
2.数据分析,对leader也很重要,不断改善测试过程.
3.以上2点我个人都不喜欢,太不符合我个人风格.哈哈哈.流水线,固定/死板的工作,是质量最高的.都不会错,而只有工具是帮你做到这点,因为工具是可控的嘛.当然这个还是根据你公司的情况或者team的能力有关系的拉.

老肥羊

關於測試結果的質量評估的前提條件
測試過程结果质量的评估并不是一件非常容易的事情,最少在现在的測試過程任务来说,測試過程任务的可观察性及其质量的可评估性并没有想象般的那么显而易见.虽然现在软件工程角度对于測試過程任务的划分来说,其可见性和观察性已经比以前的项目有着非常大的改进.但就測試過程结果本身来说,质量的评估并不是非常的容易,所以导致效率的评估也是一场空谈.对于基本相同的需求来说,測試過程的结果并不一定有一个可以很容易评定的标准,比如,是占用内存大,运行速度较快的程序比较好,还是占用内存小,运行速度较慢的程序比较好呢?
当然,这是最少在两个程序都是在可以正常运行的情况下的比较.所以有一个最低标准:可以正常运行的程序肯定要比不能正常运行的程序要好,虽然也许不能正常运行的程序有着非常优良的架构,有着非常优良的设计,有着非常好的编码习惯及有着非常好的文档,但有一点,最最重要的一点,不能正常运行,所以,尽管可以正常运行的程序在结构上要稍稍欠缺一些,在设计上可能并没有照顾到方方面面,也许编码习惯会因这个測試組成员的个人差异而有不同层次的参差不齐,或者在一定程度上文档也没有完整性,但这个程序的最大的也是最重要的部分在于可以正常运行.所以,在对于測試過程结果质量的评估的最低标准应该是測試過程结果最低限度的符合需求并且可以正常的运行.

老肥羊

关于測試過程结果质量的评估的需求标准
从另一角度来说,測試過程结果最低符合标准可以正常运行后,可以从需求角度考察測試過程结果,对于測試過程结果来说,完完全全的符合需要的情况是非常非常的少,一般情况下总会有或多或少的不合适,当然,对于測試過程结果与需求的评定方面可以从功能点考虑,当然,功能点可以适当的细,这样,才能比较容易的观察到測試過程结果与需求的偏离度.当然,可能有些时候一些功能点所占的比重并没有其它某个功能点所占的比重那么大,但一般情况下,在系统越大的时候,功能点的比重越可以看得平均,在此,相对来说,大系统的需求偏离度的判定比小系统要容易一些.当然,这是从理论的角度考察整个測試過程项目后得出的结论,尤如从5000米的高空观察中国,发现除了人驾驶着汽车朝着不同方向运动外,很难再得到其它方面的信息.所以,从高屋建甐的角度来观察測試過程结果的质量,所得出的结论只會有一定的参考性,却也不能完全作为唯一的标准.

老肥羊

从系统的整体架构方面评估測試過程质量
系统的整体架构方面来说,需要有稳定性和稳固性两个方面,对于稳定性,比较合适的比喻是一个系统的整体架构在确定之后,对于需求的变更,可以产生不同的设计的变更,也可以产生需要分析方面的某种程度的反作用力,犹如现在的建筑,当确定了钢筋混凝土结构及房屋的架构设计后,对于房屋的一些其它方面的需求比如窗户的设计或者是屋内布局的设计不影响到已经确定的房屋的架构设计,系统的架构的稳定性越好,则系统相对于需求的可变化性就越小,相对来说,则系统适应大规模的需求变动的适应性就越差,但在这种情况下,系统的稳固性越好,有利于整个測試团队的磨合及整个測試团队的前进方向的专一性及成长方式的专一性.当然,大规模的需求变更并不是不允许,大规模的需求变更可能会引发系统整体架构的剧烈变动,具体变动未知,所以说系统的架构的稳定性和稳固性与系统架构的可适应性是相斥的一个方面,简单的说,一个系统的稳定性和稳固性越好,则系统架构的可适应性就越差,可适应性越差带来的影响是架构的变更成本的上升及开发团队的重新建设或者測試团队整体方向上的变更.及測試团队中成员的学习成本的上升.当然,上面所提到的系统的架构的设计的稳定性和稳固性及适应性的关系是在大规模的变更时的一种情况,比如从JAVA团队转型为C团队.相对来说,系统的架构设计的稳定性和稳固性在其所适应范围内的,比如我们可以划一个圆圈A,在圆圈A内,这个系统架构设计的稳定性和稳固性是表现的非常好,只要是符合圆圈A内的需求如何的变动,系统的架构都能非常灵活的适应.但当出了圆圈A进入圆圈B或者圈A的范围比设计的时候要大上整整一个圈的时候,则系统的稳定性和稳固性与可适应性表现的是相斥的关系,所以总结说…在系统架构的可适应范围内,系统架构的稳定性和稳固性与可适应性是呈相辅相成的,当需求的变更超越系统架构的可适应范围,则系统架构的稳定性和稳固性与可适应性是相斥的关系,即系统的稳定性和稳固性越好,在可适应范围内,它的适应性越强,适应所做变更的成本越低,当超越了适应范围,则它的适应性越差,它所做变更所做的成本将越高.对于此,如何评估一个測試過程结果的现有系统架构的质量将会是比较困难的事情,可以考虑从写入约束和写入其适应范围的角度来做一个评估.

[ 本帖最后由 老肥羊 于 2009-2-2 15:51 编辑 ]

老肥羊

从測試团队的成长评估測試過程结果的质量
从測試团队的成长角度来评估測試過程结果的质量,是一个带有多数主观因素的评估,当測試团队中的每个人都在最合适的位置上的时候,则測試過程进程将会变得顺利和平滑,
让做系统设计的人做系统设计,让擅长处理问题的人处理问题,让擅长文档化的人做文档化工作,在这一种状态工作的,对于測試团队的整体素质提高会有一定的作用,但当測試团队有少量变更的时候,可能原来做系统设计的人被放在了处理问题的位置,而处理问题的人去做了文档化工作,文档化的人去做了系统设计,在这一种情况下,对于測試团队个人的成长是比较有利的,最少在一定程度上,接触不同的方方面面,不论是在系统设计角度,问题处理角度,还是工作文档化角度上,在做擅长的任务的时候,都会不自觉的从其它角度来考虑问题,对于測試团队的后续需求的开发和測試团队的持续性成长是有好处的,但这种情况下带来的问题是不同位置上的人的学习成本的增加及做自己并不擅长时的工作时的结果并没有做自己擅长时的结果所得到的结果那么好,所以,按同样需求的来说,从測試团队的成长评估測試過程结果的话,对于測試团队的成长应该在不影响整体需求和时间约束等各方面的情况下,达到最大限度的成长.

老肥羊

从測試的流程和过程改进评估測試過程结果的质量
測試過程结果的质量与測試团队測試这个结果时经历的流程和过程有着相当大的关系.对于測試团队的流程和过程记录将会有助于改进现有的流程和过程,在这个角度上面,測試過程结果的质量应该在一定程度上取决于流程的记录和过程记录的完整程度.如果測試团队有应用改进后的流程,或者说在开发过程中,更替过流程,来观察測試過程速度或者效率的影响及当时小范围的结果的评定,观察整个測試过程及开发过程中的流程,对于在不同的观察对象所产生的效果和结果,及对于观察对象所涉及的过程和流程进行改进的建议也应该作为測試過程结果的质量的评估标准.

老肥羊

从測試過程结果的文档建设及文档知识传递程度评估測試過程结果的质量
对于測試過程结果的文档建设来说,非常广,非常全的文档当然是有好处的,但是在现实的情况下,并没有如此大的精力和时间去建设非常广,非常全的文档.所以,择其重要性而有选择性的进行文档建设,是一个測試团队所需要的,单纯从文档建设的数量上来评估測試過程结果的质量,是很失真的一种行为,但是如何去选择文档的重要性,不同的人有不同的观点,我觉得,文档的重要性一是对于整个測試過程有帮助的,另一是对当前需求的測試過程的知识传递程度两个方面来评定文档的重要性.就此,可以比较容易的观察到整个測試過程结果的文档建设及文档知识传递程度来评估測試過程结果的质量.

zw75618

老肥羊的见解很精辟

xiaoxin36

分析的非常透彻，，学习了~~~~~~

peag

学习了

zjx01206

很好，收藏一下

msnshow

要有统一的标准，再按标准去执行，才能保证质量

鹭岛

制定严格的测试规范，测试时执行过程中，执行结果就不要跟CMMI那种规定一样写什么总结报告的，可能浪费时间，至少在测试用例上一定要过关

bjxcxjdl

北京鑫翔恒业科技有限公司
承接软件测试服务外包项目
我们团队有专业的从事多年性能测试工作的资深软件测试工程师、高级性能分析师，Oracle DBA等，以满足客户的需求。

功能测试使用的工具
测试工具 操作系统
-> WinRunner
-> QuickTest Pro
-> Robot
-> TestDirector
-> Quantity Center

功能测试服务范围：
· 单元测试
· 集成测试
· 系统测试
· 回归测试产品分类  电子商务解决方案

性能测试使用的工具
测试工具  
->LoadRunner
->WebLOAD
->Silkperformer
->JMeter
->TestDirector
->Quantity Center

性能测试服务范围
· 基准测试
· 容量测试
· 压力测试
· 负载测试
· 稳定性测试
· 异常测试

公司网址：www.911it8.com
地址：北京市海淀区中关村E世界1115A
公司传真：010-62684686
公司电话：010-62684686   15110017285 刘先生

yzwangxf

关于测试质量，要从两个方面去考虑：
1.Leader对测试资源的撑控和使用程度如何。
  （对人不能撑控，没有一套管理和考核方法，测试质量免谈）
2.业务如何去分解，特别是通过测试用例去分解，（要花一些时间），
  不能进行随机的测试。一定要想办法知道，被分解的业务点，测试覆盖多少，
  主流程和重要流程，模块被执行了多少。这只是测试面上的内容，
另外就是深度，该走的流程是否走到了底，计划中用到的测试类型是否都涉及到了。
比如：UI的操作，数据库中的数据，兼容性，稳定性等。

以上都是在实际中可操作的，并一直使用。
其他有很多，但因成本较高，并不适合。

随便写的。呵呵