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

lsekfe

转自：博客园 作者：虫师

功能测试的重点在哪儿？

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

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

　　需求很重要，好吧！能得到一份完整或不变的需求对测试人员来说应该是一件很幸福的事儿？因为我们少去很多麻烦。好吧！假如一下我们得到了这么一份需求。那我们是不是根据需求就开始对系统进行测试了呢？那么这时开发人员还没把产品整出来，那我们做什么呢？要不想想我们测试什么吧！？或怎么对系统进行测试，做哪些验证。这就引出来一个东东。叫“测试用例”。

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

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

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

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

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

性能测试水很深！

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

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

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

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

为什么要做自动化测试？

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

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

什么项目适合自动化？

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

那么它的找bug能力呢？

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

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

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

---

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

测试人员是否要懂代码？

懂是必须的，更客观的说法，看下图：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　相信这也是开发人员热议的一个话题，最典型的就是拿微软与谷歌来比较，微软的测试人员与开发人员的比例是2：1 ，而谷歌测试人员与开发人员的比例为1：10 ；同样是两个牛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对他们造成的损失是不可估量的。当然微软一开始也没意识到测试的重要性，那都是在血和累的教训中逐渐总结出来的。

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

haitianle

一年经验就这么深入

发了可突然

其实测试做久了做产品也不失为一个很好的选择。
有技术懂产品当然是很好、很好的事情