查看完整版本: 6年测试工作的思考

6年测试工作的思考

6年测试工作的思考

前言
        在公司已经干了6年的测试了，干测试经理也5年了。眼看就要离开奋战了6年的岗位，还真有点儿舍不得。但没办法，该离开的时候就要离开，光伤感是没有用的。正好趁此机会把自己6年来一直想写但没写的东西写出来。这篇文件纯粹是对自己工作的回顾。由于时间仓促基本上是想到什么些什么，有点儿乱，也请大家多多担待了。只要还有些人能从中找到些儿同感，或从中得到一些帮助，一些经验，我就知足了。

什么是测试
        首先我要谈谈什么是测试。相信好多测试人员跟我一样，来公司之前也没有从事过任何测试工作。对于测试都是从零开始的。也有好多人跟我一样，从各种书上或是培训中得到过有关测试的各种定义。但不知道大家有没有净下心思考一下。什么是测试。在公司公司测试工作的定义是什么，测试的工作范围是什么。
        测试的定义根据测试技术的发展，历经了3个主要的阶段。第一个阶段，认为测试就是找产品中的bug。第二个阶段，除了找bug以外，又增加测试是对软件质量的度量这一概念。第三个阶段，明确了测试是指为了度量和提高被测试软件的质量，对测试件进行工程设计，使用和维护的并发生命周期。注意其中提高的测试件，其主要是与软件这个词进行对应。明确测试也是一种开发过程。他的工作成果就是测试件，好像平时我们所谓的测试案例、测试脚本等等都可以称为测试件。然后使用测试件去度量和提高被测试软件的质量。
        目前，在中国大部分软件企业，尤其是中小型的软件企业还停留在第一阶段。我个人觉得公司稍微好一点儿，处于一、二阶段之间。因为我们平时做的最多的一件事，还是找bug。至于测试案例和测试脚本等等，只占用工作量的很小一部分。而且我看不到大家在平时的测试工作中是完全依据测试案例进行测试的。目前测试案例等工作更多的成为了一种形式上的产物。从有些部分所有产品的测试案例在一个下午就能评审完就能看得出来。
        说到这里顺便在谈一句测试计划。目前的测试计划是作为产品计划的一部分。先明确大概发版时间，然后是各个阶段的里程碑，其中提交集成的里程碑是死的。开发需要的时间就是那么多，剩下倒推的时间就是测试的时间。这样定出的计划是否能够起到计划的作用就不好说了。现在的计划更多的是罗列联调测试的各种内容，至于时间，不说也罢。所以从中也可以开出公司的测试也就停留在一、二阶段之间。
        明确了公司测试的定义（个人理解），也就不难理解公司给测试人员的定位了。在测试人员中经常流传的一种说法就是国外测试人员的地位多么多么的高，开发就是coding。咱们公司开发比测试多拿多少多少，测试人员地位是开发序列中最低的。大家也要看看人家公司测试人员的素质，测试在开发过程中的重要性。再看看自己所从事的工作，就是找软件的bug。当然我也个人认为有经验极其丰富的测试人员对产品的贡献比开发和需求大。明确了这些，心里也就能少点儿不平衡感。

测试方法的思考
        说完个人对测试含义的理解，再说说个人对测试方案的一些思考。
        个人认为在公司6年，测试方法没有什么提高。主要还是以黑盒测试为主。中间也曾经引入过各种各种工具，但测试人员真正用起来的也就是robot。而且robot主要是进行回归测试，再加上一些人并没有真正认识到其价值，应用范围也极其有限。对整体测试效率的提升影响不大。所以目前的测试方案还主要是以需求为依据的黑盒测试。至于什么极限值了，成对测试法等等，都是建立在黑盒测试的基础上，而且从我一来公司就有相应的测试项目，只不过没有明确概念而已。
        另一个说个人觉得6年来公司测试方法没有什么提高的原因是，6年前测试是以人为主，靠得是测试人员的经验，对产品的熟悉程度，对业务的理解程度。6年后测试还是以人为主，人就是测试的主体，产品质量的保证。还没有过渡到测试案例就是测试的主体，测试案例的完整性是产品质量的保证。只要测试还是以人为本，我觉得测试的效率就不会有太大提高，产品质量的信心来源也是对相关测试人员的信任。
        我个人觉得以黑盒测试为主要的测试方法没错，而且也比较符合目前公司的测试现状。但一定要注意各种经验的总结、积累，更重要的是共享。虽然目前测试案例在测试工作过程中的地位不重要，但其毕竟是编写者的经验积累。汇总起来也是一笔可观的财富。可现在如果有人问我850的测试方案在那里，其中还有多大比例能够用在现在的产品中，在现在的测试工作中有多少以前的案例能够复用。其他产品中的测试案例中有多少是关于接口功能，有多少我可以借鉴。我不知道，这也是自己工作不到位的地方。所以我要说的作为黑盒测试为主要的测试方法，一定要注意测试经验的总结和共享。
        而且我认为一个人如果黑盒测试能做到位，做到最后培养的是一种测试的感觉。测到最后，产品你一看就能知道那里可能有问题，那里应该没什么问题。这样有重点地投入测试力量可以收到事半功倍的效果。可这是需要大量测试经验的积累的，不是我告诉你，你就知道的能力。在此前提上加强测试人员之间的横向沟通，形成经验贡献。可以较快的培养测试人员的测试感觉。
        最为测试经验积累的另一个重要方法就是加强对测试案例的要求和管理。每版测试案例不仅要包括新增功能，还需要包括上一版本中继承的案例，修改或删除上版案例中变更的内容。从而形成一份完整的关于产品所有功能点、接口、升级、年结等等各方面的测试案例。真正做到测试案例是测试的主体，从而提高测试效率，提高产品质量。

测试工具的概念和作用
        测试工具，什么叫测试工具。我认为任何能提高你测试效率的工具都可以称之为测试工具。不仅仅指robot或是loadrunner这类专门的测试工具，也不仅仅指使用各种编程工具编写的测试工具。像总账工具、eai等，即使只是帮我们导入一些常用档案，也可以节约我们的测试时间也可以称之为测试工具。
        我个人现在公司测试在测试工具开发上还很不足。在公司里一提起测试工具，大家第一个想到的可能就是robot。即使是robot应用的也不够深入。大家经常认为robot主要录制gui的脚本，跟产品界面联系紧密。每次回放成功率不高，各个版本间脚本复用率也较低。而且每次总是以各种理由将脚本录制放到最后，经常就不了了之了。最后阶段的测试任务实在太紧。我想说的是robot的应用虽然有各种各样的局限性，但其毕竟提高了测试效率。比如说安装盘验证，使用robot验证，每天都可以节约一半以上的验证时间，这就是效率。认识了它的好处，才能想尽办法解决或避免在robot使用中的各种问题。以前同事有一套robot脚本规范就很好，使用后不仅提高了回放成功率，而且回放中断后，继续回放也变得很容易。所以说使用robot后，想100%回放成功不可能，想不再进行脚本的调试也不可能。认识这两个问题后，就需要加强robot使用经验的总结和共享，有针对性地加强robot使用问题的研究，每版测试开始时针对上版robot脚本的复用问题进行研究。这样才能用好它，真得使之成为一个工具，而不是一项任务。
        一种工具也不是万能，有许多针对产品特性的测试工具。只能自己开发，大家应该积极提需求。凡是认为有可能提高测试效率的工具需求都可以提。能从网上找到现成的工具解决需求更好。不能，如果是普遍性的需求，可以专门进行开发。因为咱们产品的特性，每版间测试工具的复用度很大。从长远看就是节约开发成本，缩短开发周期。
        在现阶段加大测试工具的适用范围和力度，用好各种测试工具，可能是提高整体测试效率最快最好的方法。但一定要加大推广的力度。否则有了好的工具，没人用或用不起来也是没用。

如何看待各种规则和执行
可能大家觉得平时开发过程中有好多规则、制度。这些除了一些自己公司内根据各种情况制定的外，大部分都是跟cmm体系相关的一些规则。可以说是已经被许多软件公司验证过，可以提高开发和测试效率的规则。但好多人觉得起没有什么用，就是在浪费时间。总是以一种完成任务或是应付差事的心情去做。我觉得大家之所以觉得其没用，恰恰就是由于你去做这件事的动机不对。总以应付差事的心情去做，你就不可能真正理解这么做的目的，这样做能给你带来什么好处，你从中会得到什么收益。所以我个人认为，既然有规则，不管是公司自创的或是借鉴其他标准，都是为了解决开发过程中的问题，为了提高开发的效率，保证产品质量。也许这些规则中有这样那样的不合理，但只有你认真地去做了，才能发现其中的不妥之处，才能改进，才能更有助于你的工作。
执行也是我觉得在工作中需要进一步加强的环节。许多规则就是因为执行力度不足，才容易让一些人找到空子，应付了事。但怎样加强执行力度，还是一个需要大家一起进行探讨的问题。

沙发

有深度，有广度，学习。。。

一定好的学习

写的不错啊！我不知道该说什么啊！我们想提高自己的待遇都不行，我们公司就要测试部门写测试用例，说是开发写的，我们也不参加评审，写出来的测试用例经理说看的麻烦！我们按照测试用例生成的测试日期他说看不懂，而且我们的产品每次发包，都只是个程序，什么也没有给你 ，你的自己去问用那个数据库，那个启动包！我都晕了啊

ok

谢谢分享！sdlkfj3

要好好学习！！！

我们公司还好一点，有比较好的领导，但是只是我们水平有限，写测试用例总是达不到一定的深度

"如何看待各种规则和执行
可能大家觉得平时开发过程中有好多规则、制度。这些除了一些自己公司内根据各种情况制定的外，大部分都是跟cmm体系相关的一些规则。可以说是已经被许多软件公司验证过，可以提高开发和测试效率的规则。但好多人觉得起没有什么用，...."

规则一开始被人排斥是正常的,但过了很久还是被排斥,这不仅仅是执行力的原因.应该还有很多的问题存在.这个规则制定出来是否真的适合公司目前的项目管理方式?还是制定得太空中阁楼?
如果解决大家身边切实的问题,大家都会很受欢迎,而不是排斥的心态.建议可以去了解一下XP的操作方式.
希望能与楼主进行探讨.

我想有几种情况吧：1.规则本身有问题；2.公司环境不支持；3.人员素质有差别。在考虑市场和成本等多种因素情况下，不得不放弃规则，我认为这个比较突出吧。

LLBB分析的几点原因非常透彻.
从这里可以引出一个话题来讨论一下
1.公司在什么样的条件下可以执行规则?
2.怎样制定规则?
3.怎样执行规则?

对自己很有帮助，学习中.......

至于测试案例和测试脚本等等，我觉得影响这些的最主要因素在于公司对于项目进度的要求、对于成本的考虑，使你没有时间去做规划。

分享分享。理想，我才刚上路呢！

是啊，最重要的就是经验的分享

学习楼主，学习，再学习！！！

谢谢楼主，好好的经验要吸收，我也觉得测试技术没哈提高，我们公司测试用例有非常规范的一套范本，但是实际上测试的时候，都是开发人员拍拍脑袋就来了，找我说，你帮我测下报表，你帮我测试工资这块，基本上没什么测试用例

thanks！！学习经验！

感谢楼主能总结自己宝贵的经验给大家。写的真的很不错，很值得我们学习和借鉴。

谢谢楼主分享

" 6年前测试是以人为主，靠得是测试人员的经验，对产品的熟悉程度，对业务的理解程度。6年后测试还是以人为主，人就是测试的主体，产品质量的保证。还没有过渡到测试案例就是测试的主体，测试案例的完整性是产品质量的保证。只要测试还是以人为本，我觉得测试的效率就不会有太大提高，产品质量的信心来源也是对相关测试人员的信任。"

这点有同感。虽然我做测试的才不到3年，但是在这个问题上已经看不到一丝改进的曙光。
个人认为i，测试的质量、产品的质量，跟开发团队有很大的关系。如果你的规范没人执行，你的计划由于开发的原因经常变更，你的工作由于开发的原因要重复劳动，这样进步的步伐自然不会快。说到用例，如果没有需求文档、没有设计文档，测试人员就只能凭借自己经验以及对项目热情坚持下去，而这些额外的工作是无法用数字来统计的，也是“领导”看不见的。
越来越感觉到个人力量太微薄了，测试的改进、产品质量的改进是需要整个团队的共同努力的！我创造不了这样的团队，我改造不了这样的团队，有些心灰意冷！ ：(

好帖！谢谢！

thanks

thinking...

理解的够深刻，不知道你现在做什么工作了？

我公司测试的情况相对好一些。
测试案例是最重要的环节，以此为中心向前推动需求的明确和完善，向后指导测试执行工作。
我们测试计划的制定是基于对测试工作量和资源的评估做出来的，而不是开发给你留了多长时间。
我公司测试人员的待遇基本与开发持平，上升空间稍微小一点。

我公司还没测试呢.老板让我一人去搞测试...
要学习再学习了`~

Thanks  ,学习ing.....

舒马赫试完法拉利的新车以后提出的问题和电脑测试的结果几乎是相同的，他这也相当于一种黑盒测试吧，就像楼主说的，黑盒测试到最后看一眼就知道哪会有问题，哪没有问题。

我们公司做测试也不正规,一直做黑盒测试.
自己也没有太大的提高.很头疼呢 !

恩，学习学习

好象大家都是做黑盒测试的哈，哎
我也是，公司也没有好 的流程

就是做点，就叫你测试，也没有文档之类的

痛苦啊

看来都是刚起步呀！
谢谢分享LZ

分析的真的很不错.....................

我也是做黑盒测试的，全是手工测试，以前公司也没有测试，都是开发人员自己测，现在做测试三个多月了，感觉还是有收获的。算是入了门了。但还是有很多的东西要学习.楼主做了6年的测试，真的很佩服你。

[[i] 本帖最后由 mirror98327 于 2006-10-26 15:16 编辑 [/i]]

关于test case 的执行,可以对每天对test case 的执行情况进行统计来保证测试人员按照其执行,哪些pass,fail,以及无法执行,没有完成的case 数,另外加强 test case 的peer review,test lead 的review,BA的review保证其覆盖率,质量,肯定有些情况无法覆盖,在执行时可增加test case,可进行ad hoc  测试

顶sdlkfj2

to ccc11yyy

你说的那种改变单纯的靠某个团队也是不可能完成的，我觉得这是行业问题，不是个别现象。
我认为有需求才会有变化，国内的软件公司一直处在这个状态，踏步不前，除了本身的问题之外，跟我们的客户也有着很大的关系。
比如说：一个客户要上一个软件项目，在需求分析阶段，客户会提出各种功能上的需求和一些硬性指标，但是很少有用户（也有一些）会提出最终的软件产品要满足什么标准、规范，在提交产品的同时，要有软件质量控制的相关文档、产品总体的测试报告等。
这种情况在中小项目中应该是比较普遍的，这样就使得公司在开发项目的过程中更注重编码而忽视了质量的控制，以coding为中心的开发方式注定了是那样。只有发展到以需求为前提，以质量控制为驱动的阶段，情况才会有所好转吧.
只有软件公司不断的成熟,我们的客户也不断成熟,整个行业趋于工业化,问题也许就迎刃而解了!
(纯属个人胡侃,不要拿砖砸我^_^)

我现在在公司也只有我一个人在进行测试.测试的是应用软件.都是找bug,没有用什么测试工具.

没有好的领导,觉得有些茫然

顶..................

又学习了一遍！