编者按：

　　随着社会的不断发展，开源软件运动正不断地改变着软件行业的开发模式、运营方法，当然也改变着软件测试的方法，借助开源软件测试工具可以构造一个完整的测试解决方案，从单元测试、功能测试到性能测试，从Web页面测试到VoIP/Telephony等一些多媒体应用的测试，甚至涉及测试的管理平台和缺陷跟踪系统，它覆盖整个测试工作领域。小编这次从51Testing网站中，适当的整理了一下开源测试工具的文章，希望大家能更加了解它的应用。

　　整理的一些常见的开源测试工具

　　白盒测试工具

　　linux c/c++内存泄露分析软件：http://valgrind.org/

　　c/c++单元测试：http://code.google.com/p/googletest/

　　http://code.google.com/p/googlemock/

　　xCover是一个C/C++语言的代码覆盖分析库：http://www.xcover.org/

　　UseMon是一个开源实时性能检测代理工具，能够嵌入JVM提供监控程序运行能力，包括异步运行情况，只需要花费很小的代价，并且能够在生产环境中使用。UseMon提供了以下功能：http://code.google.com/p/usemon/

　　Clover是一个基本的Java代码覆盖测试分析工具http://www.atlassian.com/software/clover/

　　DbUnit使您可以容易地执行JDBC查询并获取它们的值。使用DbUnit JDBC包装器而不是纯粹的JDBC有几个理由：http://www.dbunit.org/

　　JDepend一个开放源代码的可以用来评价Java程序质量的优秀工具：http://www.clarkware.com/software/JDepend.html

　　代码覆盖率检查工具Coberturahttp://cobertura.sourceforge.net/

　　Java程序性能分析工具VisualVMhttps://visualvm.dev.java.net/

　　性能测试框架p-unit，p-unit是一款开放源码的性能测试框架，和JUnit不同，JUnit关注的是测试案例的正确性，而p-unit不仅关注测试案例的正确性，还收集测试案例的性能参数，http://p-unit.sourceforge.net/

　　GroboUtils使得扩展Java测试变得可能。它包括用在Java不同方面测试的多个子项目。在GroboUtils中最常被到的工具是:多线程测试(multi-threaded tests),整体单元测试(hierarchial unit tests),代码覆盖工具(code coverage tool)。http://groboutils.sourceforge.net/

　　白盒测试工具CodeCover, CodeCover是一个免费的白盒测试工具，主要测试代码、分支、循环、MC/DC覆盖。支持为每个测试用例生成独立的报表，目前支持的语言有Java和COBOL。http://codecover.org/

　　Fluint是一个Flex单元测试工具，对于Flex单元和集成测试，“Fluint”非常简洁。它是为编写Flex2或Flex3应用的开发者提供的测试框架，无论这些应用是通过Adobe Flash Player在浏览器中部署的，还是通过Adobe AIR在桌面上部署的。http://code.google.com/p/fluint/

　　Memtest86+是一款免费开源的内存测试软件,测试准确度比较高,内存的隐性问题也能检查出来!也是一款基于Linux核心的测试程序.http://www.memtest.org/

　　JMemProf基于Web的内存剖析工具.JMemProf允许你撷取应用程序在运行时内存剖析信息.http://oss.metaparadigm.com/jmemprof/

　　mmapper可以用来访问机器的任何资源，可直接读写内存总线中的任何物理地址、I/O端口、PCI空间配置等http://sourceforge.net/projects/memmapper/

　　测试环境搭建工具：

　　虚拟机软件：www.xen.com

　　集成测试（接口测试）工具：

　　TCP协议测试工具：http://code.google.com/p/tcpjunk/

　　网络协议分析软件：http://www.wireshark.org/

　　JAMon（Java应用程序监视器)是一个免费的，简单，高性能，线程安全的Java API.它让开发者可以方便地监控软件。JAMon用来测定程序的性能瓶颈，程序与用户的互动性和程序的可量测性。JAMon收集概要的统计数据比如执行时间（总的，平均的，最大的，最小的等），并发程序请求等。JAMon把这些统计数据以报表的形式展示出来。

　　http://jamonapi.sourceforge.net/

　　Iperf 是一个网络性能测试工具。Iperf可以测试TCP和UDP带宽质量。Iperf可以测量最大TCP带宽，具有多种参数和UDP特性。Iperf可以报告带宽，延迟抖动和数据包丢失http://iperf.sourceforge.net/

　　......

　　专题入口：http://www.51testing.com/zhuanti/kygj.html

　　为什么要使用开源测试工具？

　　作为一个开源测试工具的推崇者，我经常被问到这个问题。许多测试工程师对商业测试工具情有独钟，总觉得商业测试工具既好用又强大，而开源测试工具功能弱，缺陷多，而且不好用。对开源测试工具的偏见一方面来自于商业测试工具的宣传，另一方面，也来自部分测试工程师在使用开源测试工具过程中的心态。

　　在本人所在的组织中，公司内使用的绝大多数测试工具或多或少都有开源测试工具的影子，从开源测试工具在本组织的应用中看来，使用开 源测试工具带来的优势非常明显：

　　1. 极低的License费用：这个是显而易见的一个优点。设想，如果公司需要对Web应用进行上万并发的性能测试，使用LoadRunner等商业 测试工具的费用绝对不是一个小数字；

　　2. 更高的集成度：大多数商业测试工具本身也号称提供了自己的“完整解决方案”，但商业测试工具往往只能覆盖测试中一部分的领域，对于集成测试或是针 对应用的接口测试方面，商业测试工具很难提供企业需要的好的解决方案。这样一来，这部分企业自己建立的自动化测试工具就很难被集成到商业测试工具形成的 “测试框架”中。而采用开源测试工具解决方案的话，这个问题根本就不是问题；

　　3. 更适合企业需要：出于商业利益的考虑，商业测试工具总是试图覆盖“最大的用户群体”，因此商业测试工具往往是那种“谁都可以用”，但“在哪里都不 是特别好用”的那一类工具，反之，开源测试工具在这方面具有显然的优势；

　　4. 更适合提高企业的测试技术水平：许多开源测试工具中都体现和非常值得学习的测试思想和方法，由于开源本身的特性，这些思想和方法是非常容易通过对 开源测试工具的研究来进行学习和掌握的。

　　以JMeter这个工具为例，我在许多场合下向测试工程师推荐这个性能测试工具，的确也有一些测试工程师尝试了这个工具，但从他们那里，我得到的反馈往往是：“为什么这个工具的界面这么难看？”，“为什么这个工具没有xx功能（与商业测试工具相比）？”，“为什么这个工具没有漂亮的文档？”。许多人在第一印象上便认为，这个工具比不上商业测试工具，然后就弃之如敝屐。实际上真是这样吗？我所在的组织的性能测试几乎完全依赖于JMeter，通过在 JMeter上扩展的图表功能，支持集群等功能，通过少量的代码，JMeter可以生成比商业测试工具更加漂亮，更加有价值的图表，而且，更重要的是，100%适合我们自己的环境需要。

　　当然，除了看到开源测试工具的优点，我们也应该看到开源测试工具的不便之处。与商业测试工具相比，开源测试工具在产品的用户交互性，易用性，易学习性方面显然 不是那么好（当然，在我看来，这方面不是测试工具的重点）。因此，要在组织中使用和引入开源测试工具的话，对组织中的成员，组织环境是有一定的要求的。

　　就本人的经验而言，许多目前的开源测试工具，例如Mantis、Testlink、JMeter、Selenium/Webdriver、 xUnit等都已经是非常成熟的测试工具，拥有了大量的使用者，也有许多成功的应用实例，本人的实践已经充分证明了这些工具在实际工作中能够带来的收益： 即使只是简单的使用开源测试工具去完成某个特定的任务，或是用来搭建公司内部的测试管理平台，也能从这些工具中受益不少；更何况开源测试工具拥有众多的开 发者，处于不断的完善和提高中，具有良好的扩展性，给你充分修改和改造的自由，从这个角度来说，如果你拥有足够的资源，想要打造属于自己的测试平台，开源 测试工具绝对是一个好的平台。

　　专题入口：http://www.51testing.com/zhuanti/kygj.html

　　一个好的测试用例是每个人都能执行的测试用例，不管你是否是测试人员，不管你是否了解整个软件的工作流程，你都能顺利的执行完测试用例，并对这个测试用例覆盖到的功能点有了大概的了解。

　　好的测试用例的设计相当了软件开发中的详细概要设计，要写出好的测试用例首先要对所测试的软件很熟悉，熟悉软件的每个功能点和系统的整个业务流程。其次，对整个测试用例有个好的规划，理清主线，功能点的在哪个地方被覆盖都是需要考虑的。最后，需要良好的心态，写测试用例是个繁琐的过程，测试用例不是随随便便就能写出来的，好的测试用例更需要你在写的过程中不断去理清思路，并把每个功能点都恰当的写进去。

　　测试用例的规划：

　　用例的规划非常的重要，它决定整个测试用例的思路、风格、覆盖率。即对整个测试用例的成败都有直接的响。对测试用例的规划我个人总结出两条思路：一条是用例的线性规划，另一条是功能点覆盖型。这两条思路的侧重点各不相同，各有优缺点。线性的测试用例的要点是在理清每一条思路，即以业务线和流程线为主，每一条线都是一个流程，然后把功能点穿插到每条线里去。把每条业务流程比作竖线，功能线比作横线，那么功能点就是横线和竖线的节点，这样整个用例就是一张大网，我们可以随时向网中添加横线或竖线，使得覆盖率不断增加，“漏网之鱼”越来越小。

　　另一种思路是功能点覆盖型。在设计之前把要整套软件的功能点理清楚，这当然是非常的难的。但我们可以参考系统设计的功能流程图，软件的需求来进行分析和提取。还有一点就是测试人员的经验来完善所需要的功能点。这种思路的重点是把每个功能点都要在设计中体现出来，以功能点覆盖为主，不管工作的业务流程。也就是说是按照各个功能模块进行划分的，分模块进行用例的设计。

　　两种思路相辅相承，各有各的优点。在实际的执行过程中，有时以业务流程来编写比较容易，有时以功能模块编写比较容易。一个是以线为主，一个是以块为主。

　　测试用例的设计：

　　规划好测试用例的整体思路之后，就是测试用例的具体设计设计了。用例的设计的格式主要由测试环境，准备数据，前置条件，用例ID，预期输入值，期望输出结果，测试执行结果和优先级等几个部分组成。其余的还有一些统计页，打印输出的模板等。个人认为用excel设计比较简便，excel可以有多个页面，一个页面为统计测试结果和用例维护，一个为测试用例的主页面，还有一个页面可以放一些打印后的模板。这样的设计有利于用例的维护。

　　用例的预期输入值和操作步骤是用例设计最重要的部分。设计好这两个部分对经后测试用例的执行至关重要，特别是操作步骤的描述，要描述清楚每一步的操作步骤，这样才能让测试的执行者准确操作，不会产生歧义。用例所写的每一句话都应该清晰的，没有歧义的，否则就会出现用例维护时，其他测试人员看不懂你写的是什么，测试用例执行的时候，看着很费力，达不到文中刚开始的要求。

　　测试用例的维护：

　　每个测试用例都要在经后执行的过程中去维护修改，使得测试用例的覆盖率不断提高。特别的测试用例的第一个版本时，需要维护的量是非常大的。我们可以边测试边修改测试用例，也可以根据需求添加测试用例。每维护一次测试用例，就必修记录下你修改的内容，以便于经后的阅读和别人的维护。

　　以上是我近期对于测试用例设计的理解，也是我近期工作的一个总结和体会，测试用例设计是一门高深的技术，也是软件测试的重要组成部分，我们需要经验来不断提升用例的质量，设计出好的测试用例。

本文转载自51Testing软件测试网，查看更多：http://www.51testing.com/html/news.html

　　关于软件测试这东西，玩了四年，仍然没有摸透它的脾气。

　　有人说，软件测试是为了发现更多的缺陷，也有人说，软件测试是为了保证产品的质量。都没错啊，一个是从职责的角度来看，一个是从控制的角度来看。

　　软件测试，其实就是一个验证的过程，测试人员竭尽所能的折腾一套软件，看它是否符合客户要求的标准，是否能经得起折腾，借以评价产品的质量好不好。不就是这样吗？：-）

　　常规的测试理论是遵循了V模型中的V&V过程，也就是Validation and verification。Validation是对客户需求的验证，比如通常所说的验收测试、Beta测试。Verification指的是软件过程中每一次确认活动，包括客户需求确立以后的每一阶段关键产物的评审与测试。

　　按照V模型的概念，我们将软件过程分为了客户需求、需求规格、概要设计、详细设计、编码、系统测试这几个关键的阶段。每一个阶段都会有相关的评审与测试，因此，以客户需求为主要依据的测试，我们称之为验收测试，着重于用户需求的验证，通常由客户来做；以需求规格为主要依据的测试，被称为系统测试，着重于对产品综合能力的验证，通常由专业的测试人员来做；以概要设计为依据的测试叫做集成测试，着重于对各级别的接口所进行的验证，通常会由编码人员与测试人员一起完成；以详细设计为依据的测试就成为了单元测试，着重于对代码的最小级别进行验证，通常由编码人员实现。看到这样的一个规则，我们很容易理清，每一个测试阶段，所要测试的对象是不同的，而相应的依据一旦通过了评审，便可以着手进行该项测试的准备。

　　相对于之前的每一个关键阶段而言，测试阶段的执行顺序刚好相反。编码阶段只能执行单元测试，只有单元测试通过了，才可以对单元与单元之间进行集成，测试它们之间的接口，这被称之为集成测试。当软件所有的模块完成之后并且通过了集成测试，那么就可以进入系统测试阶段了。这个时候，测试人员摩拳擦掌，跃跃欲试，不找出Bug不罢休。

　　然而，到底每一个测试阶段的测试工作是怎样开展的呢？这样的一个过程，我们称之为测试管理过程。每一个测试阶段，都会包括测试计划、测试设计、测试执行这三部分，有些人会把它划分得更细，比如获取测试需求、测试实施、搭建测试环境等。

　　测试计划并不是单纯的写一个时间表，它是当对应的作为测试依据的文档定格之后（通常我们叫做基线化）就开始做的，最主要的目的是要告诉你的项目组成员，你要做什么（明确测试目的）？对什么来做（明确测试对象及测试需求）？怎么做（制定测试策略）？要使用什么来做（确定测试资源）？何时做（安排测试进度）？需要注意跟控制什么（估计测试风险，使用规避手段）？

　　测试设计是要在测试计划通过了评审之后才做的，主要的产物是测试用例，是将你的测试策略升级为详细的步骤，对你确定的测试对象进行验证，应该要出现的理想结果是什么。当执行测试的时候，人们依据这份文档，会发现实际的结果与预期的不一样，于是便把它判定为缺陷。辅助的测试设计产物还包括测试环境的搭建、测试脚本、测试使用的数据等。关于测试脚本，是要衡量开发成本与预期收益的，不可以为使用了自动化的测试就是测试高手，这是个极其严重的误区。测试脚本的目的是要提高你的测试效率，怎样设计还是依赖于一个人的测试水平，如果片面的追求编程技能，把这认为是测试技能的提高，那么你不用做测试了，去做开发吧。在单元测试跟集成测试过程中会使用较多的测试脚本，是因为这些代码的复用率极高，几乎编码过程中的每天都会执行N遍。而系统测试阶段，由于测试重点不同，测试脚本的复用率也远远达不到前两个阶段的效果，自然就更要慎重了。要知道，一个常规的80/20法则，描述了一个事实，就是80%的缺陷是手工测试出来的，只有20%的缺陷是使用自动化测试得到的。你花费了两个月的时间去做了一套测试脚本，却只需要执行四五遍，发现的缺陷也寥寥可数，毕竟测试中的很多验证点是程序无法实现的。那么，如果使用两个月的人工测试，收到的效果会是天壤之别。你会选择哪一种方式呢？

　　测试执行是在必备的代码实现之后才可以做的。拿着文档做设计，却不在真正的环境中执行，就变成了纸上谈兵的赵括。因此，你可以说测试设计是最重要的，我毫不反对，但是，测试执行却是最关键的。只有这个时候，你才能了解软件的质量如何，存在多少问题，需要怎样修复。在这时，才是我们经常说的测试阶段（单元测试阶、集成测试阶段、系统测试阶段）。测试阶段中，缺陷管理变成了重中之重，缺陷的追踪与控制成为弥补软件缺陷、控制产品质量的最直接有效的手段。

　　在测试的每个环节都会产生相应的文档：测试计划、测试用例、测试报告，这三份文档成为最基本的资源。一份文档的好坏，关键不在于文笔怎样，而是能否清晰的表达你的意图，并让所有的人员能够了解，使得你所做的工作是可见可控的，不会出现较大的偏差。因此，写文档不是随便完成任务那么简单，它融入了你全部的思想、你的技能、你的沟通水准，是站在一定的高度上来完成的。即使你是个捉虫能手，但你不会写文档，不会把自己的思路清晰的表达出来，这至少能表明你不是个优秀的测试人员。

　　我绝对不赞同一个测试新手去写什么测试计划、测试用例。他能把测试报告、缺陷描述写清楚就不错了。试想，谁也不是天生的文档高手，必然是经过千锤百炼、日益积累而成的。先要学会测试，能从测试中找到很多的缺陷，知道测试应该是怎样一种过程，再开始进行文档的修炼。

　　我并不认为一个测试人员一开始写测试计划/用例的时候，就能够根据用户需求/需求规格/概要设计/模块设计这类的文档，写出好的东东。毕竟在国内，大多数技术类文档并不是很过关的。因此，我觉得要练习写，就要从一个你比较熟悉的已经成形的软件开始练起。此时你不需要去假想一个软件应该是怎样，而是针对一个实际的软件开始操作，记录你的操作跟你的结果，把它变为你的测试用例。测试计划更不消说，自然是要在你熟悉这套软件，知道怎样去测它的基础上来完成的。

　　经过了这样一个锻造，你会明白要怎样展现自己的思路，在新项目中，根据分析或设计文档，你只要考虑它具体实现的是什么，然后根据你的测试思想，你的撰写经验，来完成一份较高质量的测试文档。

　　任何一种理论都有着它存在的意义，任何一种开发模式也有它生存的理由。对于测试，也是相同。理论上，测试的设计一定会在它所依据的文档通过了评审以后才开始，可是，到那时你又该如何确定这些文档能为你所用呢？

　　当我们从一片混乱，到开始一个正规的测试流程时，我们或许并没有可以借鉴的经验，只能凭着理论带给我们的指导，一步步摸索前进。那么，在实际的过程中，我们如何来进行这场软件过程的革命呢？

　　......

本文转载自51Testing软件测试网，查看全文：http://www.51testing.com/html/21/n-243521.html

　　程序员与软件测试在工作流中是上下游的关系，而且工作上联系紧密，沟通上难免出现各种各样的问题。笔者作为管理软件行业的一个程序员，也算是和软件测试人员打过多年交道。希望能从程序员的角度出发，为软件测试人员提一点建议。

　　首先，我们一起来看一下程序员们最不愿意从软件测试人员口中听到哪些话？

　　1、XX，又发现了一个严重BUG！

　　（尼玛，文案错误也要算C级BUG吗？尼玛，1号BUG和2号BUG是同一个问题，你提两遍C级？要不要哥把你提的BUG在JIRA里都置成NotaBUG）

　　2、我提的BUG怎么不清楚了？上次提的问题到现在都没有改！

　　（尼玛，你提的BUG里面，截图有木有？操作环境有木有？好容易写点文字描述又不加标点！有木有！我只能按我自己的理解改喽！）

　　3、XX，你到我这来看一下，我这测出个问题！XX，过来，又有问题。。XX，又有问题。。

　　（泪。。能不能让哥安安静静写2个小时的程序，程序员很忌讳碎片化的时间，思路都木有了啊。。又要重新想啊。。）

　　开发和测试是项目进程中至关重要的两个环节，程序员与测试人员若能相亲相爱，一定是PM们最愿意见到的事情。然而不同角色的人员在共同完成项目的过程中，实现天衣无缝的合作总是很有挑战的事情。诚然，这些挑战可能是由于参与人员的能力问题，这无可避免。但我更愿意相信，沟通不畅、习惯不佳、缺乏换位思考等因素才是最常见的。测试人员在实际的工作中如果能够注意以下内容，相信一定会成为程序员喜欢的测试。

　　1、份内之事做到专业

　　（1）提交BUG要描述清楚。注明操作步骤、测试环境、描述清楚正常现象和BUG现象的差异。

　　（2）BUG级别设定不要全凭主观看法，应该和产品、开发人员沟通后，确定一套评价标准，客观评估。

　　（3）尽量避免提出重复BUG，两个不同页面的相同问题应归为一个BUG的两次出现。更深层面的相同BUG原因，可以多和工程师沟通了解。

　　2、沟通之中互相理解

　　（1）最终程序员的工作方式，不要一发现问题就找程序员，编码过程中思路被打断对程序员来说是很痛苦的事情。可以收集多个问题后统一找程序员处理，或是在即时通讯工具上留言，看程序员的时间安排，给他几分钟时间缓冲，在其方便的时候沟通。

　　（2）测试最怕“NotaBUG”，程序员怕的是“C级BUG”和“重开”。设C级和置重开时慎重一些，不确定的可以先和程序员沟通过再提。

　　3、功夫在诗外

　　（1）熟悉业务、了解客户，对于测试人员来说也是非常重要的。测试人员不要机械的去验证功能和需求文档的差异。对业务和客户的了解能够帮助你更好的设计用例、定位问题。

　　（2）多和程序员沟通，了解开发思路。了解开发思路能够帮助测试人员找到测试步骤的盲点，更容易测出真正的问题。这样的沟通，也会帮助开发人员检验开发思路的正确性，更好的提高项目团队的效率。

　　如果项目团队里有一个这样的测试人员，任何一个离开项目的程序员都会怀念他的。

　　当然，程序员们也不能被惯坏了，一味的要求别人如何配合自己。在项目中换位思考，互相理解也同样是程序员应该注意的事情。做相亲相爱的一家人，才能携手并肩，一起向前！

本文转载自51Testing软件测试网，查看更多：http://www.51testing.com/html/news.html

　　编者按：

　　在软件测试中，系统测试是针对整个产品系统进行的测试，目的是验证系统是否满足了需求的定义，找出与需求规格不符或与之矛盾的地方，从而提出更加完善的方案。系统测试不仅包括需测试的软件，还要包含软件所依赖的硬件、外设甚至包括某些数据、某些支持软件及其接口等。

　　小编从51Testing网站中，适当的整理了下系统测试这一部分的文章，希望能对大家以后的学习会有所帮助。

　　【关于系统测试流程的改进与思考】

　　看了经理的EMAIL，谈到我社系统上线有时存在测试不完善导致的错误，我周末这两天回去也想了很多，也和一些做软件开发的朋友交流看法，知道了我们国内大部分企业对软件测试还不是很重视，由于时间、成本的压力，很多测试流程也都是敷衍了事。但是我们农联社是一个庞大的金融机构，网点众多，每日的交易量成千上万，也意味着我们的一段代码一天会被运行了千万次，对于我们的信息系统来讲，稳定是最重要的因素，必须保证我系统的开发的质量。

　　经过这两天的思考，结合以前学习过的相关知识，我说说我的一些看法，希望对我们的测试工作有帮助。

　　1、设计测试用例时，加大在边界值范围的测试强度，因为软件较容易在数据域的边界出现错误。

　　2、通过输入无效的或非正常的数据，测试系统在错误异常情况下的处理能力。

　　3、在单元测试时全面覆盖所有路径。除了保证对关键路径的覆盖，还应该覆盖所有逻辑判断路径，保证所有“真”、“假”情况的路径都能被测试到。

　　4、发布程序时可以考虑下是否先以小部分分社为试点，运行一段时间，看看有没有存在一些未发现的问题，及时改正之后再在全市所有分社推广。

　　5、随着业务的发展，在未来条件允许的情况下，或许我们可以考虑成立一个专门的测试小组，负责软件开发的质量监管工作。通过专业的测试人员，编写测试用的驱动模块和桩模块，对代码的质量和性能进行深入全面的测试。

　　关于规范测试流程，我这几天翻阅了一些相关的材料，在软件开发的测试流程上，现在比较流行也比较可靠的是“V”模型。

　　在测试用例的设计上采用测试先行的方法，即软件开发每做完一个环节，就编写设计的测试方案。需求分析过程结束后，便开始设计验收测试，主要以黑盒测试为主，结合需求分析结果，用于检验系统的系统功能是否达到要求。在开发前期设计测试用例，可以更好的明确开发需求，规范开发思路，把握开发的方向。然后再进行下一环节的开发——概要设计。概要设计相对应的是集成测试的设计，在这个阶段以黑盒测试和白盒相结合，主要用于检验系统各个模块之间的接口以及模块功能是否达到要求。最后是详细设计，与单元测试相对应，主要以白盒测试为主，测试人员主要也是开发人员本身，检验该模块单元内的代码以及所有逻辑路径。

　　“V”测试模型的好处是设计测试用例的工作可以在软件开发的前期就介入到整个开发过程中来，有很多问题可以在开发前期被发现，可以规避开发风险，降低改正缺陷的成本。但是，“V”模型也存在着一些局限性：

　　“V”模型依赖于开发文档的准确性，完整性和实时性，文档是测试用例的设计依据，所以，该模型对开发文档提出了较高的要求。由于业务需求的不确定性和易变性，当需求改变的时候，与之相关联的测试文档也必然需要做相应的修改。这提高了文档维护的复杂性。

　　但是，开发文档是软件工程的核心，它的准确性，完整性和实时性也是保证软件开发质量的内在要求，它贯穿于需求，设计，开发，测试，维护整个软件周期，是不同阶段开发人员相互沟通的桥梁，也是所有开发人员共同遵守的一个开发规范，所以，加强完善文档管理，有利于保证我们农信信息系统的开发质量，把握开发进度，控制开发成本。

　　我刚参加工作不久，许多地方还需要向同事学习，实践经验也还不是很充足，对于我社综合业务系统的了解还不是很充分，所以以上所说的，难免有一些疏漏和错误，还请各位指正。希望通过我们的努力，能让我们的系统运行得更好，更稳定，更好的为农信的发展服务。

　　专题入口：http://www.51testing.com/zhuanti/xtcs/xtcs.html

　　【经验共享：如何做好系统测试】

　　一套软件做完了，在给客户上线之前，我们自己要进行完整的系统测试，这个工作听起来好象没什么，但其实是很不好做的，这要求测试人员要熟悉业务、熟悉系统的各个功能项、还要有一套完整的测试方法。我们软件销售部从开始做系统分析工作，现在又开始担当系统测试的角色了，没办法，公司人手不够，只能担当多种角色了。不过对于我们来说也有一定好处，系统分析设计是我们做的，现在做好的系统由我们来测试，一是我们对业务比较熟悉，二是对我们来说也是一种自我的检验，检验一下自己设计的系统是否合理，为以后更好的系统分析打好基础。

　　好了，言归正传，讲一下我们在测试工作中的一点体会吧，写出来一面为自己理一下思路，二也是为自己做工作的一个总结。

　　一、测试之前要充分掌握业务流程

　　首先，在进行系统测试之前，要知道系统的业务流程，也就是说要清楚每项业务间发生的前后顺序。只有知道了业务的先后顺序，你的测试数据才能继续在ERP系统功能间流转，否则，无法进行各项业务的全面覆盖测试。

　　其次，还要明白每一项业务中的详细流程和各个环节涉及的角色，一项比较复杂的业务其详细流程往往比较多，只有了彻底掌握了这项业务，才能对当前业务环节进行全方位的测试。比如：订单管理中，销售业务员创建了一个销售订单，还要经过主管审核，方可执行订单，订单执行完毕后关闭订单。

　　二、了解业务流程对应的ERP系统的功能

　　对整个业务有了总体的认识，再把业务分块，在ERP中找出相应的模块与业务对应起来。只有把业务和REP功能完全对应上了，才能说有可能对ERP系统进行全面的覆盖测试。

　　三、系统功能集中测试和测试方法

　　找到与具体业务对应的ERP子系统，根据当前业务的流程与角色，对ERP子系统进行集中测试。测试还要讲求方法，尽量做到全覆盖测试，其中注意几点：

　　1）按正常场景进行测试

　　根据业务流程，按着正常的顺序，用正确的测试数据测试系统；检查系统的结果是否与预期的结果相同，如果结果相符，表示当前系统模块符合业务逻辑；否则，系统有问题，将错误信息记录到BUG报告中，及时提交开发部门。

　　2）测试异常场景

　　根据业务流程，输入异常的测试数据测试系统，查看系统提示哪些异常信息，并查看是否有异常判断，如果有，则表示系统做过异常考虑处理，否则表示系统漏掉了当前异常情况，需要提示开发部门，添加当前异常情况的考虑处理。

　　3）特殊数据的处理

　　根据业务流程，在输入测试数据时，输入边缘数据、空值等特殊字符，查看系统是否做了数据录入范围和要求的判断，如果没有，表示系统遗漏数据范围和录入要求的考虑，需要提示开发部门，添加相应数据范围和要求的处理。

　　......

　　专题入口：http://www.51testing.com/zhuanti/xtcs/xtcs.html

　　大会简介

　　大会亮点

　　1、软件，无所不在
　　软件早已遍布我们生活的任何角落，从身边的信用卡、身份证、手机，到街边小店的收款机、商品的二维码，再到汽车、高铁和飞机，软件的智慧“软”化了一个冷冰冰的世界，让一切更加和谐。

　　2、站在巨人肩上，把握开发趋势
　　如何使世界变“软”？大会云集IBM在国内外的开发精英，助您站在巨人的肩膀，看清业界潮流走势，高效高质量地建设“软”世界！

　　3、掌握技术方案，分享行业实践
　　有行业最新理念、有领先的技术方案、有丰富的行业实践……从理论到实践，一次大会尽揽无余！

　　4、精彩讲座，专家互动
　　每个分会场不仅安排了相关主题专家的演讲，还将分别针对四个不同主题开辟专家咨询咖啡区，随时开放答疑。

　　5、重量级嘉宾现身
　　什么是软件的经济学？如何进行大规模的敏捷开发过程？如何在“云”中开发和测试？业界重量级学者将亲临现场，为您化繁为简、娓娓道来。不要错过与大师面对面提问、探讨的好时机！值得一提的是，大师还将现场签名售书，详解技术人员英语沟通的奥秘！

　　6、Rational 全球认证考试
　　直接上机一展身手！前100名注册者免费认证考试！开启全球软件开发管理的就业之门！

　　7、生动演示、亲身体验
　　本次大会将全面展现IT、系统和主机开发方面的解决方案和最佳实践，聆听演讲、观看演示之余，您还可以选择不同需求，在体验区尝试解决方案的全过程！

　　8、重要合作伙伴解决方案的全线展示区
　　避免走错路、走重复路，从成功实践者身上获得真经，稳扎稳打、加速企业自身的方案实施进程。

　　9、热卖区 （图书、产品和解决方案）
　　了解行业内的年度最佳技术著作、热门产品展示、分享最新解决方案，与业界发展保持同步。

　　大会议程

　　北京大会议程
　　时间：2011年 8月 26日
　　地点：北京国际饭店会议中心（北京建国门内大街9号）
　　报名参加大会>>
　　主会场（8:00 - 9:00 签到）
　　分会场一：协作生命周期管理
　　分会场二：流程、组合、产品及项目管理和企业架构管理
　　分会场三：变更、配置和版本管理
　　分会场四：需求定义和管理
　　分会场五：建模、架构和构造管理
　　分会场六：系统工程和智慧行业解决方案
　　分会场七：全面质量管理专场
　　分会场八：客户成功案例分享
　　分会场九：企业现代化解决方案专场
　　分会场十： Jazz 解决方案专场
　　分会场十一：汽车行业专场
　　分会场十二：敏捷开发专场

　　上海大会议程
　　时间：2011年 8月 30日
　　地点：上海龙之梦丽晶大酒店（上海长宁区延安西路1116号）
　　报名参加大会>>
　　主会场（8:00 - 9:00 签到）
　　分会场一： Jazz 解决方案专场
　　分会场二：IT 应用开发管理专场
　　分会场三：系统工程管理专场
　　分会场四：创新与敏捷专场
　　分会场五：客户成功案例分享专场

　　编者按：游戏测试作为软件测试的一部分，它具备了软件测试所有的一切共同的特性：测试的目的是发现软件中存在的缺陷。软件测试都是需要软件测试人员按照产品行为描述来实施。产品行为描述可以是书面的规格说明书，需求文档，产品文件，或是用户手册，源代码，或是工作的可执行程序。

　　不少人把这项工作看成是空手套白狼的好事——玩游戏还能拿钱！实际上并非如此。虽然游戏测试员确实能从工作中得到乐趣，但是它仍然是一份严肃的工作，远不像人们想象的那样轻松。

　　51Testing网站中也有不少人围绕这个话题展开讨论，小编从中将关于游戏测试的一系列文章进行归纳整理，形成本专题，供新人们参考，高人们讨论。

【游戏测试从零开始】

　　很早就想写这个帖子了，但是种种原因总是想下笔的时候缺不止从何谈起，这里给各位想加入游戏测试的兄弟姐妹一点方向。

　　作为一个游戏爱好者从小就有一个梦想就是如果天天和游戏打交道该有多好啊，可是父母常常告诉你游戏不好，玩游戏玩物丧志，如果有一天你可以堂堂正正说我就是靠游戏吃饭呢？

　　游戏测试就是这样一个”低门槛”的测试工作，但是正是因为大家都觉得门槛低，所以这份工作往往被很多人误解，并且在寻找这样的工作的时候处处碰壁！

　　游戏公司需要测试人员么？缺，非常缺，但是绝大多数人却并不适合去做这样的职位，为什么呢，我们先来看看一个大家眼里的游戏测试工作是怎么样的.

　　游戏测试工作

　　小张是一家游戏公司的测试人员，每天工作都很忙，一天正好有空，小张和几个朋友出来吃饭，聊着聊着就说道工作了，小张简单的介绍了一下工作的情况

　　9：30 -12：00 玩游戏

　　12：00-13：00 午饭休息时间

　　13：00 -18：00继续玩游戏

　　19：00 – 加班还是玩游戏

　　1周5天天天如此，周末还经常加班.

　　其他人都羡慕的说，你工作舒服啊，天天打游戏就可以了，玩游戏还有钱赚。小张只能苦笑

　　游戏测试的实质

　　是不是游戏测试工作就和大家平常玩游戏一样呢？

　　只需要反复执行被测试对象，就可以发现游戏中的问题所谓的BUG，然后通过某种方式提交给开发人员，工作就完成了。

　　如果你简简单单把游戏测试当作游戏的过程那么就大错特错了。如果这样就算你如何如何全力的去运行一个游戏，你仍然无法去确保一个游戏不会被玩家批评。例如cs游戏，为什么一颗手雷无法炸死玩家？作为一个想入门进入游戏测试行业的你，应该能够准确的回答这个问题。 是不是作为一个游戏测试人员，你做为一个玩家努力的去发现游戏中的问题（你个人感觉的问题），你所做的就是正确的提高了游戏品质呢？

　　否，先来想想刚才的问题，作为cs中的一个手榴弹的设置，为什么一颗手雷丢不是玩家，甚至将手雷丢在脚下也无法将玩家杀死，顶多只能伤95HP，这违反了正常的逻辑，作为一款仿真类游戏，为什么会有如此不仿真的情况发生？那么这个一个bug么？而在这个游戏中缺正是因为这种情况才避免了一个bug，很难想像在一局游戏中特别是在iceworld这样的小地图中，5发手雷丢出，一方获胜。为了确保整个游戏的平衡，在设计这个游戏的时候已经将这种情况考虑，从而得到一个95伤害上线的设计，来确保游戏的平衡性。

　　作为一个游戏测试人员对于你来说游戏已经不是一个娱乐的东西，而是一个设计好的逻辑代码，你需要做的并不是通过执行去感受好不好玩，而是要去验证整个游戏中所有的触发条件是否正确设计并且可以触发。

　　什么是一个好玩的游戏？为什么老早的fc游戏经常比现在的某某大作更留下深刻的印象，游戏的可玩性在于整个游戏的设定，而在现在，随着硬件条件的升级，设计人员可以通过更加直接的方法来提现游戏，但是如果没有一个好的设定，游戏也就成了一个高科技渲染的泡沫了，除了玩的时候觉得效果很好，音乐很好，本身游戏却没给人带来一些印象。而且花了大量的注意力在效果上是，其实降低了游戏的可玩性，在某些方面TV Game比PC Game好玩了不少，除了某些必须使用鼠标键盘和网络的游戏。

　　TV Game游戏的开发有很多便利之处，更多的是因为竞争的对手都是知名大公司，如果你无法创作出一个优秀的游戏，更本就没有销量的，Square公司在FF前正是如此，几乎面临倒闭才出现了这种国名大作。对于相同起跑线的TV Game唯一占领市场的方法只有提高游戏品质

　　PC Game 几乎无限的空间和完整公开的开发平台是其闪亮之处，更加优秀的效果和操作可能是PC Game的法宝，但是正是因为这点游戏性呢？说道FIFA可能很多玩足球游戏的都会想到实况，而实况在很多方面都超越了FIFA，并且实况成为了最近各大游戏比赛的比赛项目，极品飞车和GT或者山脊的比较，相信在克服了图像效果进入ps3时代後，山脊的感觉可以甩掉nfs吧。

　　那么大家可以想到另外一个问题了如何测试cs中的ak弹道是否正确？

　　......

　　专题入口：http://www.51testing.com/zhuanti/yxcs/yxcs.html

【揭开游戏测试员的职业生活】

　　游戏测试员（videogametester）是许多着迷于电视游戏、电脑和互联网的人们追求的一种职业。从第一人称射击（FirstPersonShooter/FPS）到虚拟现实类游戏（VirtualRealityGame/VR）等各种游戏的制作都须要游戏测试员的参与。不少人把这项工作看成是空手套白狼的好事——玩游戏还能拿钱！实际上并非如此。虽然游戏测试员确实能从工作中得到乐趣，但是它仍然是一份严肃的工作，远不像人们想象的那样轻松。

　　如果你和你的朋友或者家人想成为游戏测试员，本文将揭开游戏测试员的真实生活，澄清与这项工作有关的谣言。

　　1.游戏测试员并不是总在玩游戏

　　游戏测试的核心任务跟玩游戏取乐完全是两码事，测试员在整个游戏测试过程中重复进行单调的测试工作，来检测游戏的臭虫（bug）。举个例子，游戏测试员的一项普通测试工作可能是操作角色与游戏中所有的非玩家角色（NPC/Non-playerCharacter）对话，然后记录对话内容。另一项常见的工作是计算游戏过程中所有出现过的咒语数目，或者调整玩家在游戏不同阶段控制界面。

　　测试员的日常工作进度都由所属的项目组组长安排，并受其监督；因此，测试员很少有机会干预或者改变测试内容。工作中，测试员必须准确地跟踪游戏进程以便研究和记录游戏的任何臭虫或瑕疵（Glitch）。

　　此外，测试员基本上无权选择测试哪款游戏。即便你是一个战略游戏迷，喜欢星际争霸、魔兽争霸，你可能每天面对的是体育游戏，或者给幼儿设计的游戏。

　　不管测试何种游戏、完成何种任务，测试员很可能长时间重复同样的游戏过程。所谓的“游戏”很快就变成了乏味的“工作”。

　　2.从事游戏测试是一个进入游戏产业界的极好的途径

　　对于想成为富有激情、充满干劲的游戏设计师、美工和程序员的年轻人来说，首先成为一名游戏测试员也许是开创事业的绝好途径。不过，工作中测试员一般很少有机会与游戏制作团队交流。然而，开朗、外向的性格还是能让你有机会结识的你想认识的人物。跟所有入门级的工作一样，游戏测试以外的上层职业空间非常广阔。但是留给你寻找机会的时间非常有限，并且你很难仅仅依靠这个职位获得更大的发展。

　　尽管如此，测试仍然是进入游戏产业界最好的入门职业之一。通过它，你能了解游戏开发的全过程，还能遇到你职业生涯中的“贵人”。游戏测试的学习曲线上升很快，一个渴望成功的测试员，能在几周之内理解许多制作和开发过程。通过勤奋和刻苦的工作，少数测试员能赢得令人垂涎的地位；同时游戏测试的经验也能让你的简历在竞争中脱颖而出。

　　一位专注于工作的测试员还可以在管理、培训和测试领域取得进一步的发展，游戏测试的从业经验让你在竞争游戏制作和开发职位时占得先机。

　　3.大多数测试员的收入并不高，但确实有一些测试员能赚很多钱

　　测试职位的工资一般都极低——9-12美元/小时。某些项目要求超长的工作时间，达到每周60到80小时；这通常意味着加班工资和双倍的加班时间。此外，测试员是按项目需要临时招聘的，这极大地限制了从业者的收入前景。所有这些的结果是，不管工作表现如何，测试员在测试工作的间隔总要经受数周的失业。

　　虽然游戏测试员能拿到一份体面的薪水，但是求职者应该注意在间断的任务之间的失业时间，短则几天，长则数月。

　　4.铁杆游戏迷并不能成为最好的测试员

　　游戏测试员的核心工作内容是发现、重现特定类型的臭虫。了解、熟悉各种类型的游戏当然有助于测试员完成这项工作，但这并不意味着测试员必须玩过大量游戏是——某些最优秀的测试员在入行以前甚至没有碰过任何游戏。

　　新手观察游戏的角度跟老手或者游戏设计师不同，他们经常会发现后者永远无法发现的臭虫。另一方面，铁杆游戏迷更关心游戏的整体性能和游戏体验，而不是一些“不起眼”臭虫。而实际中，测试员应该具有以下的职业素质：强烈的职业道德，卓越的沟通能力，良好的口语和文档表达能力，耐心和细心。换句话说，游戏测试要求你对所有的游戏一视同仁，而不是成为战略游戏或者第一人称射击游戏的铁杆粉丝。

　　5.大多数游戏测试员都善于与人交往，而且在工作中容易相处

　　游戏测试员并不是你想象中的游戏疯子；他们不会整天衣着不整地沉迷于游戏，也不会在桌子上堆满饮料罐子。

　　不可否认，总是有一些测试员是游戏疯子；但是所有的行业中都有“疯子”，况且这些人都做不了太久。这是因为测试员的成功须要良好的沟通技能。更重要的，许多臭虫很难靠个人的力量发现，这时测试员需要与同事一起来发现这些臭虫。而且，测试员必须准确地将臭虫向同事描述清楚，以便他们能有效地解决出现的问题。

　　最好你需要在狭小的工作间里进行长时间的工作。这时，你的同事就成了你的朋友和家人。每天13到14个小时的工作，你有大把的时间跟同事相处，因此你必须与他们交流。最终你必然疏远了自己的家人和朋友，因为他们并不了解你的工作；作为回报，同事会给你莫大的支持。

　　6.游戏测试工作充满了乐趣

　　期望越大，失望也越大。游戏测试可能会让很多寄予厚望的人们大失所望，毕竟这是一份工作而不是单纯的游戏。然而，它对某些人来说仍然是一项充满乐趣的职业。首先工作环境很轻松，而且周围都是与你志趣相投的家伙，这能弥补长时间的工作带来的影响。再想想休息时间跟大家一起玩最新的8人游戏，或者享受一款从未发售过的小游戏长时间的工作会让人沮丧。即使跟新认识的朋友一起也同样是一种享受。

　　正如上文所述，如果愿意花时间研究游戏、了解游戏的工作方式，那么你能从游戏测试获得体面的薪水，同时得到其他有益的收获。因此，如果你热爱游戏，喜欢解决难题，能忍受长时间的工作，并且对工作环镜没有太多的要求，那么你也许应该考虑考虑成为一名游戏测试员。

　　专题入口：http://www.51testing.com/zhuanti/yxcs/yxcs.html

　　随着国内软件测试行业的逐渐发展，有越来越多的软件企业更加重视软件测试，并已经形成了一套基本的软件测试流程。但是软件测试所起的作用还没有人们期望那样显著，因此，就需要继续加大投入对软件测试的关注程度，对软件测试过程进行持续的改进。以下是本人在工作中的一些体会，介绍软件测试过程中需要注重和改进的几个环节，与大家分享。

　　1、计划与风险

　　项目计划对项目过程的实施有着直接的指导作用，它的重要性是不言而喻的。我经历过一些成功的项目，给我感受最深刻的就是计划的充分性，以及根据项目过程中遇到的各种新情况，对计划的及时变更做出反应的能力；我也经历过一些失败项目，由于项目计划的不合理或混乱无序，经常会带来严重的项目风险、以及开发成本，造成项目不断延期、产品质量无法保证。对于软件测试来说，测试计划也是指导后续测试工作的基础，在测试的计划中，不仅需要明确测试的目的、测试的资源、测试的人员等等，更重要的是需要详细明确并估计出在整个测试活动的任务和风险，比如：

　　测试需要做哪些工作？

　　整个测试活动估计需要多少工作日？

　　充分估计测试计划、测试设计、测试执行、测试分析评估这些阶段分别需要多少个工作日？

　　估计的测试用例规模是多少？

　　估计的测试进度时间又如何？

　　在测试过程中，可能会遇到哪些方面的问题？

　　可能存在的风险又有哪些？等等。。。。。。

　　只有对过程中各任务的进行更详细的计划，才有利于在测试过程中对项目进度的把握有一个明确的目标；同时，风险策略的制定，也有利于对及早对测试过程中可能遇到的问题做出分析，以便在问题出现时能够尽可能的减少规避风险的成本。

　　2、评审

　　在测试过程中的每个阶段结束前，都会输出一些资源，文档、用例 等等…，这些资源往往是下一个测 试阶段或软件开发的下一个环节执行的依据，比如：测试报告，测试人员在完成测试并提交测试报告之后，测试报告里说明已经没有未解决的问题了，那么是不是就应该结束测试呢？我们又如何来保证测试报告的准确性、充分性呢？这就需要组织参与项目的一些重要成员，项目经理、开发负责人、测试经理、QA等等对测试报告进行评审。评和审是结合在一起的，每个角色根据自己对项目的了解，从各自角度来审核测试报告的充分性，对质量风险发表各种见解。最终，对报告的规范性也要进行考察。评审也有会议评审、在线评审等等好几种方式，可以根据实际项目情况，对不同的项目、不同的文档、资源采用不同的方式评审。最后一点需要补充的是，对于测试发现的问题，一般是有争议的问题，需要有评审。对于紧急的问题，一般采用在线方式由专家裁决；另外，也最好根据实际情况组织会议评审来对一定规模的问题统一评审。

　　3、文档

　　文档的编写对于测试人员来说是一个十分重要的任务，深入的、充分的投入测试的测试人员能写出高质量的测试文档。所以，测试文档的质量，往往反映了测试人员执行测试的广度和深度。而在文档的编写方面，首先必须形成统一规范；另外，针对不同项目的测试，可以适当对文档标题、内容进行简化。总之，文档模板一旦形成，必须严格遵守。

　　在编写测试文档过程中需要注意的几个问题：文档中描述的测试数据必须准确；必须详细描述出测试的环境；测试报告中必须详细描述测试的充分性、测试质量评价；等等。。。。。。这里不再一一列举。

　　4、方法与策略

　　测试方法和测试策略，测试的重中之重。这也是我个人非常乐于思考的，方法和策略的意义在于如何用最有效的办法、花最少的成本、在有限的资源情况下尽可能以最高的质量的完成测试项目，并根据项目中遇到的突发情况，不断制定新的策略。

　　测试的策略一般要求从全局方面对测试的阶段、每个阶段的测试类型进行考虑、定义，比如：需要做哪些方面的测试？测试的顺序是怎样的？功能测试如何进行？性能测试何时进行等等。而测试的方法更多是体现在一个具体的测试中，采取怎样的测试思路。另外，在测试过程中，对资源的协调也非常关键，需要能保证测试资源充分利用，每个测试人员都有适度并且相当的工作量。

　　在以往工作中，常常会进行交叉测试，这里予以介绍：测试往往是一个长期的重复性工作，对于测试人员来说，一个测试人员一般长期从事一种产品或一个特性的测试，长期如此，测试人员往往会出现测试反感腻味倦怠。因此，适当的采用交叉测试，让两个或多个测试人员相互学习对方业务领域的知识、并执行测试，既有利于减少测试人员的倦怠心里，使测试人员有一种新鲜感，也可能发现出前测试人员未发现的问题，也起到了互相监督的作用。

　　5、总结测试经验

　　在测试的过程中，测试人员应该及时总结发现的错误并归类，标明经常容易出错的地方，将意见提交项目经理，审核后，制定出一份统一标准并提供给开发人员，这样就可以提前避免错误、避免重复错误和重复测试，提高测试效率。不仅如此，项目结束后的各项总结报告将是项目的后期维护或二次开发的宝贵参考资料。

　　另外，测试过程中，也可以将自己所负责特性、产品的体会、心得写出来，做为测试指导书，以便有新员工加入时，使其迅速上手。

　　6、缺陷分析、度量

　　对测试活动过程中发现的缺陷进行分析、度量，寻找软件开发过程中存在的问题，并持续改进开发过程，提高质量。缺陷的分析、度量从时间上分为两个方面，首先是在软件开发过程中发现的缺陷进行分析、度量；然后就是，对软件产品发布后，对用户提出缺陷进行统计、分析。

　　对测试过程中的缺陷需要分版本，并按不同模块、问题级别，对缺陷进行各种统计，并比较子版

　　本统计数据之间的差异，CQ在这方面已经提供了比较强大的统计功能，这里不再赘述。进行分析，是因为开发修改后导致该模块不稳定，引发大量新问题；还是因为前期测试出现漏测（设计漏测、执行漏测）；或者是版本合入新增需求的功能导致。然后根据问题原因，提供改进建议。下面对几个参数进行说明：

　　TFVUD 是用户发现缺陷数（ Total Field Valid Unique Defects ）：即由用户发现的经过了确认的、非重复的、非用户错误操作的、非建议类型的所有缺陷；（总数、按模块统计）

　　PDD 是测试发现缺陷数（ Post Development Defects ）：即在开发完成后的测试周期中发现的缺陷数，但它不包括那些向用户发布后发现的缺陷；（分别按模块、级别、时间 统计）

　　DDR是开发缺陷率（Developer Defect Ratio）：一定周期内缺陷总数与代码行数的比率。

　　本文转载自51Testing软件测试网，查看更多：http://www.51testing.com/html/news.html

　　软件测试的重要性现在已经被人们广泛认识和了解，近两年，众多的软件公司开始将软件测试外包出去，由第三方专业的测试公司进行软件测试，客观地测试和报告软件Bug。有独立的软件测试第三方的出现，好处就是能严格地掌控软件质量，减少维护成本。由于涉及代码的保密性，几乎所有软件外包测试都是“黑盒测试”。所谓“黑盒测试”，是指已知产品所应具备的功能，通过测试来检测每个功能是否都能正常使用。在测试时，完全不考虑程序内部结构和内部特性的情况下，测试者只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息，并且保持外部信息（如数据库或文件）的完整性。

　　软件测试职业发展状况

　　由于我国IT业劳动力成本相对较低，因此一些国际大公司如微软、IBM等，纷纷把“黑盒测试”外包出去，交给国内专业的软件测试公司来做，主要对其产品进行本地化测试和功能性测试。我国软件外包测试行业虽起步较晚，但发展迅速，已有多家专门从事这方面的测试公司，规模比较大的有文思创新、博彦科技、天海宏业等。

　　目前国内测试人才奇缺，调查数据表明，现在软件测试岗位上从业技术人员有三万多名，而具备五年以上从业经验的资深软件测试工程师不超过一万人，软件测试人才的缺口超过20万，在未来5～10年中，这一数字还将继续增大。软件测试职业前景非常广阔，有两年工作经验的软件测试人员，月薪一般都能够达到4000～5000元左右。

　　揭开“黑匣子”中的秘密

　　笔者在一家软件外包测试公司工作，每日的工作就是对软件进行本地化测试。根据分配的测试任务和提供的测试文档进行软件测试，找出软件中的缺陷。所谓本地化测试，是指对已经本地化的软件进行测试，主要检查针对特定目标区域性或区域设置的产品本地化质量，它只能在产品的本地化版本上进行。在测试之前需要根据测试文档的要求，搭建好相应的软硬件测试环境。通常测试中至少需要两台计算机，一台为工作机，用来查看测试脚本、文档；一台为测试机，用来做测试，运行测试脚本。

　　本地化测试中主要的Bug类型包括功能性和可用性两方面，其中前者指影响产品的功能以及不能实现设计要求的功能，后者则涉及到影响UI（User Interface）的可用性问题，主要包括字符显示不完整、不正确，以及组件大小和位置引起的布局错误等。

　　在测试中如果发现Bug，就要及时提交软件缺陷报告给开发人员。测试人员还要随时追踪软件缺陷报告的状态，一旦开发人员修改了软件中的Bug，还要再对Bug进行重新测试，验证Bug已正确修复。当天的测试工作结束前，要填写每日测试报告，提供测试完成的进度信息，反映测试中发现的问题，并把报告提交给项目经理。

　　看似简单的测试工作其实并不轻松。每天要完成测试的脚本数量相当多，而且在测试过程中会遇到各种意想不到的困难和问题。有些问题是测试人员对软件产品不熟悉及对测试脚本不理解造成的，还有些则是测试脚本同测试产品相脱节造成的。这就需要测试人员有良好的沟通能力和团队精神，并且向有经验的测试工程师请教学习。当测试出现问题时，与其他测试人员多进行交流，大家集思广益，问题往往就会得到很好的解决。

　　作为一名优秀的测试人员，要善于利用各种途径不断提高自己的业务知识水平。软件外包测试工作并不像外界宣传的那样枯燥乏味，它是一项充满挑战性的工作。通常测试的都是自己先前没有接触过软件产品，需要在最短的时间内熟悉它并且能够操作及应用。测试中，不是所有的Bug都能很容易地找出，一定要耐心和细心才能找出这些Bug。每当发现软件中的一个Bug，自己就会很有成就感，只有当你真正投入到测试之中的时候，你才会发现其中的乐趣。

本文转载自51Testing软件测试网，查看更多：http://www.51testing.com/html/news.html

　　在软件开发过程中，单元测试和编码共属实现阶段，编码完成并编译通过后才开始进行单元测试。进行动态的单元测试前要先对程序进行静态分析和代码审查。这是因为：第一，使用动态测试技术要准备测试用例，进行结果记录和分析，工作量大，发现错误太多会降低动态测试效率；第二，目前的动态测试技术局限性比较大，有相当类型的错误靠动态测试是难以发现的。因此，先使用静态分析和代码审查技术，能充分地发挥人的判断和思维优势，检查出对机器而言很难发现的错误。典型的包括代码和设计规格的一致性，代码逻辑表达式的正确性。这些检查在动态测试阶段将会是非常繁琐而又非常困难的；第三，有些错误在动态测试时是无法检查的；第四，使用代码审查技术，一旦发现错误，就知道错误的性质和位置，调试代价较低；第五，使用静态分析方法一次就能揭示一批错误，并且随后就可以立即纠正错误。

　　由于单元测试针对程序单元，而程序单元并不是一个独立可运行的程序，因此，在考虑测试模块时，同时要考虑到它和外界其他模块的联系，用一些辅助模块去模拟与被测模块关联的其他模块。这些模块分为两种：

　　● 驱动模块。相当于所测模块的主程序。它接收测试数据，把这些测试数据传送给被测模块，最后再输出实测结果。

　　● 桩模块。由被测模块调用，用以代替由被测单元所调用的模块的功能，返回适当的数据或进行适当的操作使被测单元能继续运行下去，同时还要进行一定的数据处理，如打印入口和返回等，以便检验被测模块与其下级模块的接口。

　　驱动模块和桩模块为程序单元的执行构成了一个完整的环境。如图下所示。驱动模块用以模拟被测单元的上层模块，测试执行时由驱动模块调用被测单元使其运行，桩模块模拟被测单元执行过程中所调用的模块，测试执行时桩模块使被测单元能完整闭合地运行。

　　驱动模块和桩模块在软件开发结束后就不使用了，但是为了单元测试，两者都要进行开发，但是不需要与最终产品以其交付用户。因此驱动模块和桩模块的设计要尽量简单，避免因其错误而干扰被测单元的运行及测试结果判断。实际上许多程序单元不能用简单的驱动模块和桩模块进行充分的单元测试，完全的测试可以放到组装测试时再进行。

　　如果一个模块要完成多种功能，可以将这个模块看成由几个小程序组成，必须对其中的每个小程序先进行单元测试要做的工作，对关键模块还要做性能测试。

　　在单元测试中，测试用例的设计与测试集合的准备是至关重要的。首先要构造测试用例的运行环境，即确定用例运行的前提条件，明确被测模块/单元所需的程序环境（全局变量赋值或初始化实体），启动测试驱动，设置桩，调用被测模块，设置预期输出条件判断，最后恢复环境 （包括清除桩）。然后，设计黑盒测试用例，即接口测试用例。第一步设计基本功能测试用例，证明被测单元至少在某种正常情况下能够运行了；第二步设计功能正面测试用例，找出被测单元对于设计要求的正确输入可能做出的不正确处理；第三步设计功能反面测试用例，找出被测单元对于设计要求的错误输入可能做出的不正确处理；最后一步设计性能测试用例，找出单元对于设计要求的性能可能做不到的错误。最后，设计白盒测试用例，即覆盖测试用例，找出单元内部控制结构和数据使用可能存在的问题。注意，在进行白盒测试期间，不要匆忙地删除所发现的死代码或者冗余代码，因为这很可能导致错误的产生。因为在测试别人代码的时候，很可能由于测试用例不够，或者没有对被测程序整体结构的把握，而出现错误理解。

本文转载自51Testing软件测试网，查看更多：http://www.51testing.com/html/news.html