谈软件测试---一年测试工作总结

简介:

  这篇总结推迟了好久,一直想在工作一年之后写一篇总结,由于各种琐事以及感觉想法的不成熟,一推再推。这两天尤为强烈,不管怎样都应该把这一年多测试工作学到的知识和想法记录下来。

     软件测试行业在国内发展时间较短,每个公司对软件测试公司的定位和工作内容也不经相同。本人只在一个公司从事测试工作并时间不长,如有偏见欢迎指正,不胜感激。^_^!!

 


个人对功能、性能、自动化三个方面测试的认识



功能测试的重点在哪儿?

 

  说一下本人对功能测试的理解,关于功能测试重点在对被测系统的了解上。至于测试方法:等价类划分、边界值、错误推测、因果图....等测试方法很容易理解。把这些方法应用到系统功能测试中也不难,关键是如何应用?这里又引出了一个东东,叫“需求文档”?一个系统不是你想测什么就测什么?也不是你认为它是bug它就是bug的。

例如:一个登录,用户名没区分大小写,我是用小写注册的,但是登录时,我用的大些却可以登录,这算一个bug吗?不是个人认为的是或不是的,要根据需求来判定。

   需求很重要,好吧!能得到一份完整或不变的需求对测试人员来说应该是一件很幸福的事儿?因为我们少去很多麻烦。好吧! 假如一下我们得到了这么一份需求。那我们是不是根据需求就开始对系统进行测试了呢?那么这时开发人员还没把产品整出来,那我们做什么呢?要不想想我们测试 什么吧!?或怎么对系统进行测试,做哪些验证。这就引出来一个东东。叫“测试用例”。为什么要写测试用例?http://www.cnblogs.com/fnng/archive/2011/09/10/2173149.html 在我的另一篇博文里有讲。

想做好功能测试要做好四点:

1. 非常了解被测试系统,各个功能和各个业务逻辑。

2. 需求文档,如果你不知道怎么测,那你一定没看需求文档

3. 测试方法的学习,方法不难理解,如何运用到项目中是关键

4. 测试用例,在上面三点的基础上写用例,一个用例可以体现出你对上面三点的掌握程度

 

性能测试水很深!

  很幸运刚进公司老大就让我对公司系统做性能测试,那时学了几天JMeter LoadRunner掌握一些基本操作就以为自己会做性能测试了,在此自我鄙视一下自己的无知。其实,性能测试的重点不在性能测试工具的学习上。天天看到群里有人问,LR怎么用?又录制不了脚本了。脚本回放有错。如何设置XXX?为什么高手能用树叶杀人呢?一般的小罗罗都在抢屠龙刀,倚天剑。以为得到了屠龙刀就是最牛B的人了。

  当然,你也通过分析系统的压力点、LR录制脚本,设置用户,做压力,分析结果,整理测试报告。完成了性能测试的整个过程。那么我说这个性能测试报告是有效的,但它不一定是有用的。

  为什么说是有效的:因为在性能测试报告中,你把测试环境、测试工具、测试方法、测试结果都描述的很清楚。那么这次性能测试就是有效的。在你所在的环境中,你是测出了这样的效果。并未掺假,全部真实的记录。

  为什么说它不一定是有用的,你了解系统架构么?知道数据库、中间件、前端程序的运行方式和处理机制么?了解网络协议么?了解操作系统么?熟悉开发系统的语言么?如java  JVM的内在机理知道么?这些都是系统运行的一部分,都在影响着系统的性能。如果不了解这些,你如何做出有价值的有参考意义的性能测试。如果你的性能测试没有参考意义,那不是自已在逗自己玩么。

《我眼中的性能测试工程师》http://qa.taobao.com/?p=8308 

 

 

为什么要做自动化测试?

 

  貌似好多人都在热追自动化测试,貌似自动化测试比手工测试先进牛B。本人对自动化测试也没什么实际经验,只是对QTPselenium浅学了两下。这里也讨论两三句。

自动化测试无非就是用工具代替人对系统进行验证,它如何知道怎么验证。这个要你一步一步教它。所以,自动化前期的投入很大。

什么项目适合自动化?

  需求变动小、项目周期长、可复用性高。如果不满足这三个条件,你要掂量一下是否要对项目引入自动化。

那么它的找bug能力呢?

  我所了解在我的手工测试中,相当一部分bug并非我按照用例测出来的。有统计它只能找出来30%bug70%还是要靠手工测试。那投入那么大,找bug能力都不强。为什么还有那么多公司试水,做自动化测试主要是在加入新的功能后保证已经功能的正确性。

那么测试人员要不要学自动化测试呢?

  我犹豫了很久还是觉得要。自动化测试毕竟是软件测试的一个趋势。从测试人员的自我技能的提升也一个方向。至于公司是否真的需要自动化测试,自动化测试是否得到很好的收益就另说的了。

 


下面是个人对一些问题的看法。

 

 

测试人员是否要懂代码?

 

懂是必须的,更客观的说法,看下图:

上图是根据自己的理解所画,根据你所做的测试工作不同,所要掌握的测试知识的多少不同。

我确认一点代码也不懂的测试人员,工作细心,认真的执行测试用例,也能把测试工作做好。那么你的发展方向在那里?你说可以做需求分析人员、质量管理人员。貌似在偏离软件测试工作。想成为一个软件测试高手,懂代码是必须的,我没见过哪位测试高手或专家对代码是一窍不通的。

不懂开发的人员更能从用户的角度测试?

见某测试人员云云,他们公司招测试人员专招非计算机不懂开发的测试人员来测试,公司的意思是这样的人更能站在用户的角度上去 测试软件。好吧!我不想再阐述测试人员不光只是测试界面的工作,也许你们公司就只测界面。我一直不理解有为什么懂了计算机懂了开发就不能站在用户的角度上 去测试。非专业的人可以从非专业的角度和思路去非常规的测试点。我认为他也有可能找一些不是bugbug去给开发人员添乱。

 

测试人员为什么被“小看”?

 

可能和上个问题有关,看到好多测试人员在抱怨工资比开发人员低。被开发人员鄙视,不被公司重视。我想有相当一部分人不是学软件测试专业的吧!?好点的是从培训机构出来的,还有些是计算机专业开发知识不够硬,转做软件测试的。还有一些是与计算机专业无关的也能来做软件测试。

不得不说一般的测试工作伸缩性较大,如:功能测试,懂计算机的人员能做,不懂计算机的人员按装测试用例也可进行。但你让他开发个功能试试。不懂编程,肯定做不了。我只想学测试工作入门容易精通难,如果想做一个不被“小看”的测试人员只有提高自己的技术。

如果,你但找出了bug而且提出现这个bug的原因以及告诉开发人员到哪个地方去修复它。我想你会得到开发人员的尊重。如果,你能发现一个深入系统发现一个系统潜在的bug。而你这个bug有可能会公司造成重在损失。由于你的发现挽回了这些损失,那我想你会得到上司的尊重。

 

测试人员的目标是白盒测试?

 

  好多测试人员把做白盒测试看为测试人员的终极目标。认为做白盒的测试人员是最牛的。

  我们来分析一下一个常规的流程,一个开发人员需要了解需求,根据需求编写某一功能代码。那么白盒测试人员要对开发人员的 功能代码进行单元测试。那么他也需要了解这个功能需求,了解被测功能代码,写白盒测试用例,他还需要保证测试用例代码的准确性,覆盖率等等。这个过程的成 本是很高的。

  我不否认有Junit Qunit等测试框架可以提高测试效率。那么我们经过白盒测试的功能代码是没有问题的,就能保证整个系统没有bug了。答案是否定的。那么我们后续还要进行集成测试,接口测试、安全测试,这样算下来测试成本要远远高于开发成本。对于测试团队来说,不管是整体技术能力还是人员数量都要求很高。

对于一般公司的成本与收益来讲,白盒测试由开发人员完成。因为没有人比自己更了解自己所开发的代码。那么开发人员如何做好对自己功能代码的单元测试?往下看

 

测试人员与开发人员的比例

 

  相信这也是开发人员热议的一个话题,最典型的就是拿微软与谷歌来比较,微软的测试人员与开发人员的比例是21 ,而谷歌测试人员与开发人员的比例为110 ;同样是两个牛X公司,为什么会存在这么大的差异呢?我想不会有人会认为谷歌的测试人员比微软的牛得多,谷歌一个测试人员可以干微软二十个人的工作。

公司对测试人员的定位不同

  微软的测试员人叫“软件测试开发工程师”,加上了“开发”二字,就不单单的测试黑盒那点事儿了。他们要做的事情儿很多。他们要设计测试计划、开发测试自动化软件、debug、调查研究问题。他们的测试工程师要与开发工程师一起,从产品定义(product definition)到产品开发(product development)再到产品维护(product servicing),在整个产品生命周期中,不断贡献各种建议、测试文档以及测试数据。这么庞大的工作量,不是少数测试人员能够胜任的。

http://www.cnblogs.com/fnng/archive/2011/09/06/2169206.html

  那么谷歌呢?他们的测试人员又做些什么。在Google,质量并不等于测试。“质量不是被测试出来的”,他们将测试与开 发融合,做为一个开发人员,你必须对保证自己的所做工作的质量。我的感觉有点“全民皆兵”,一个全民皆兵的民族只能被全部消灭,不可能被打到。一个“全民 皆测”的软件公司还有什么质量是保证不了的。当你上则所的时候,会发现墙上写着“今天,你测了吗?”哈哈!!

http://www.aqee.net/how-google-tests-software-part-three/

 

国内的测试国情

 

为什么国内与国外同样都是测试人员,差距咋就那么大呢?这与我们国内的测试行业“国情”有关。微软是做什么产品的,一个严重的bug对他们造成的损失是不可估量的。当然微软一开始也没意识到测试的重要性,那都是在血和累的教训中逐渐总结出来的。

反观国内,有几家公司是做微软那种产品的,如果你们公司是给政府做项目的,因为某些单位做某些项目是为了让“上面”拨款。其 实,这某些单位用不用这个系统就另说了,只要上面检查的时候有这个东西就成。你们懂的!!国内的大多数公司做的都是一些一般的项目,质量要求不高,营收入 不高,能预算到测试的费用就更少了。所以,测试人员属于配菜,不是主食。有测试人员大谈后期维护成本可能存的风险。贪图眼前利益的大有人在。淡定!国情! 国情!

 

入测不深,思绪凌乱,不知所言。

目录
相关文章
|
人工智能 搜索推荐 数据管理
探索软件测试中的自动化测试框架选择与优化策略
本文深入探讨了在现代软件开发流程中,如何根据项目特性、团队技能和长期维护需求,精准选择合适的自动化测试框架。
621 11
|
测试技术 持续交付
探索软件测试中的自动化测试策略
随着软件开发周期的加速和市场需求的不断增长,传统的手动软件测试方法已难以满足现代软件开发的高效性和准确性要求。本文旨在探讨自动化测试在软件测试中的重要性、实施策略及其对提高软件质量的影响。通过分析自动化测试的优势与挑战,以及提供实用的自动化测试工具和框架选择指南,旨在帮助读者理解并应用自动化测试以提升软件开发效率和产品质量。
|
机器学习/深度学习 人工智能 监控
软件测试中的自动化测试策略与最佳实践##
在当今快速发展的软件行业中,自动化测试已成为确保软件质量和加速产品上市的关键工具。本文将探讨自动化测试的重要性,分析不同类型的自动化测试工具和框架,并深入讨论实施自动化测试的最佳实践。通过案例研究和数据分析,我们将揭示如何有效整合自动化测试到软件开发生命周期中,以及它如何帮助团队提高测试效率和覆盖率。 ##
339 1
|
Java 测试技术 API
探索软件测试中的自动化测试框架
本文深入探讨了自动化测试在软件开发中的重要性,并详细介绍了几种流行的自动化测试框架。通过比较它们的优缺点和适用场景,旨在为读者提供选择合适自动化测试工具的参考依据。
|
数据管理 测试技术 持续交付
软件测试中的自动化测试策略与最佳实践
在当今快速迭代的软件开发环境中,自动化测试已成为确保软件质量和加速产品上市的关键手段。本文旨在探讨软件测试中的自动化测试策略,包括选择合适的自动化测试工具、构建有效的自动化测试框架以及实施持续集成和持续部署(CI/CD)。通过分析自动化测试的最佳实践,本文为软件开发团队提供了一系列实用的指南,以优化测试流程、提高测试效率并减少人为错误。
586 4
|
监控 测试技术 定位技术
探索软件测试中的自动化测试框架选择与实施###
本文不概述传统意义上的摘要内容,而是直接以一段对话形式引入,旨在激发读者兴趣。想象一下,你是一名勇敢的探险家,面前摆满了各式各样的自动化测试工具地图,每张地图都指向未知的宝藏——高效、精准的软件测试领域。我们将一起踏上这段旅程,探讨如何根据项目特性选择合适的自动化测试框架,并分享实施过程中的关键步骤与避坑指南。 ###
293 4
|
测试技术 持续交付 数据安全/隐私保护
软件测试的艺术与科学:探索自动化测试框架
在软件开发的世界中,测试是确保产品质量的关键环节。本文将深入探讨自动化测试框架的重要性和实现方法,旨在为读者揭示如何通过自动化测试提升软件测试效率和准确性。我们将从测试的基本概念出发,逐步引导读者了解自动化测试框架的设计和实施过程,以及如何选择合适的工具来支持测试活动。文章不仅提供理论知识,还将分享实用的代码示例,帮助读者将理论应用于实践。无论你是测试新手还是经验丰富的开发者,这篇文章都将为你打开一扇通往更高效、更可靠软件测试的大门。
278 1
|
数据可视化 测试技术 API
软件测试中的自动化测试框架选择与实践
在当今快节奏的软件开发环境中,自动化测试成为了确保软件质量和加速交付的关键。本文将探讨自动化测试的重要性,并比较几种流行的自动化测试框架,包括Selenium、Appium和TestComplete。文章还将提供一些最佳实践和案例研究,以帮助读者更好地理解和实施自动化测试策略。
|
敏捷开发 前端开发 Java
软件测试中的自动化测试框架选择与实践
在当今软件开发生命周期中,自动化测试已成为提升软件质量和开发效率的关键手段。本文旨在探讨自动化测试框架的选择标准及其在实际项目中的应用实践。通过对主流自动化测试框架的分析比较,结合具体案例,本文将阐述如何根据项目需求和团队特点选择合适的自动化测试工具,并分享实施过程中的经验教训。
352 1
|
Java 测试技术 API
软件测试中的自动化测试框架选择与应用##
在快速迭代的软件开发周期中,选择合适的自动化测试框架对于提高软件质量和开发效率至关重要。本文探讨了当前流行的几种自动化测试框架的特点和适用场景,旨在为软件开发团队提供决策依据。 ##