摘 要：本文分析国内软件企业软件测试的组织架构、人才培养、测试自动化以及测试流程的现状，指出一些可能存在的问题以及讨论相应的解决措施。

        关键字：软件测试；组织；实施

引言

        软件测试是一个带着寻找错误的目的执行程序的过程[1]，它作为软件开发过程中不可缺少的一个质量保证环节，日益受到国内软件企业的重视。但是目前软件测试在国内还处于起步阶段，测试人员的水平参差不齐、测试过程缺乏必要的控制和管理等问题都困扰着大多数的软件企业。本文尝试着从组织架构、人才培养、测试自动化、测试流程制定等方面对软件测试在软件企业中的组织实施展开探讨。

组织架构

       测试团队的能力在很大程度上影响着软件测试的成败，一个有效的测试团队包括了技术专家和领域专家的结合。除此之外，测试团队的结构必须是合理的，各种角色和职责分工明确，测试人员各司其职，很少有职能上的交叠，也不会发生关于哪个团队成员应该完成哪项职责方面的任何不确定性[2]。测试团队的结构在各个组织内是不同的，它的深度和构成也依赖于待测试的对象和测试团队的任务[3]。在软件测试的组织架构上，目前较成规模或者比较规范的软件企业，大都采用独立设置测试部门的方式，测试部门设一名测试经理，负责测试人员的组织和管理工作；测试人员则根据项目的需要，分别安排跟进若干个开发项目，一名测试人员可能只参与一个项目的测试工作，也可能同时参与几个项目的测试工作。在参与同一个项目的测试人员中，可以设一名测试主管，该测试主管负责该项目测试工作的统筹安排，可以由测试经理兼任，也可选择经验较丰富并且有较强组织协调能力的测试人员担任。

        在此本文着重讨论一下测试人员的构成。测试人员的来源目前主要有三种：一类是原先的编程人员，由于企业或项目的安排，或者自身的选择成为了测试人员；一类是从计算机专业毕业后一直从事软件测试工作；还有一类是从其他专业转行到计算机行业从事软件测试的工作。而测试工作的构成主要可以分为三类：测试用例设计、自动化测试脚本开发和测试用例执行。上面提及的第一类人员有相对丰富的编程经验，适合从事自动化测试脚本的开发工作，而第二第三类人员有比较丰富的测试经验，适合进行测试用例的设计，测试用例的执行可由一些初级测试人员担任。当然这不是绝对的，在实际的开发过程中，除了根据测试人员的专长，还应结合其自身的兴趣进行工作的分配。因为单纯的测试执行工作相对来说还是比较机械比较枯燥的，无论从培养测试人员能力还是从留住人才方面考虑，都不应该让一个测试人员长期从事单一的测试工作，每一个测试人员应该有一个自己比较精通的方向，比如界面测试、接口测试或者安全测试，但是同时也应兼顾其他方向技术能力的培养。

人才培养

        一个理想的测试工程师的技能要求是非常高的，这些技能要求随测试种类和使用的测试工具而有所不同。针对GUI测试，测试工程师可能需要熟悉Visual Basic、MS Acess、SQL Server以及Windows操作系统；针对服务器端测试，测试工程师可能需要能够使用C、C++、SQL、UNIX以及UNIX脚本等等。由于软件测试作为一个行业在国内也还处于起步阶段，目前整个行业内真正具有成熟完备的能力的测试工程师还比较少，每个企业内部可能会有一两个或者若干个这样的测试工程师，但是仍属于少数，多数的测试工程师刚从学校毕业不久或仅有一到两年软件开发经验，那么知识的传递和技能的培训在软件测试组织中就显得尤为重要。测试人员的技能提升，有助于测试所起的作用在整个开发团队中得到平等的待遇和尊重[4]。有计划地进行知识的传递和技能的培训，有助于测试团队整体水平的提高，同时也能避免初级测试人员因为长期得不到技能上的提高而选择退出。在有些测试团队中，测试技能的传递职责由SMT（Systems Methodology and Test）团队承担。这个小组可以被看作测试团队内部的咨询人，负责提升理论和标准的知识传递、为项目引入测试工具、负责评估和培训自动化测试工具。不管采用的形式是什么，基于软件测试的复杂性或是基于测试组织稳定性的考虑，都应当重视知识传递和技能培训。

自动测试还是手工测试

        从测试执行的手段来看，软件测试可以简单地分为自动测试和手工测试。自动化测试工具能够增强测试力度——前提条件是期望是现实可行的、工具能够被正确理解、并且选择了一个与系统工程环境相兼容并且适合当前任务的测试工具[2]。采用自动化测试还是手工测试并不是一个简单的选择，它需要综合项目的性质、项目开发的流程、测试的侧重点等多方面的因素来考量。性能测试、负载测试通常采用测试工具自动地执行，而就功能测试而言，自动化测试很适合在进行产品开发的软件企业中实施，因为软件产品的开发周期相对比较长，在开发过程中能够有计划地留出比较充裕的时间进行软件测试，测试用例重复使用的次数较多；而对于进行项目开发的软件企业以及第三方的软件评测机构，则要视具体项目的周期而定，如果测试本身只留出较短的时间，在回归测试的次数不多、测试用例的复用度比较低的情况下，简单地采用手工测试会是一个比较理想的方案。需要明确的是，自动化测试仅仅是一部分的解决方案，它们并不是针对测试问题的银弹，自动化测试工具永远不能替代指导测试的分析技巧，也不能替代手工测试，它只能被视作对手工测试的一个辅助。

测试工具的选用

        自动化测试依赖的是测试工具，提起测试工具，首先想到的就是那些昂贵的商业化的通用测试工具，但实际上还有很多开源的测试工具可以使用，除此之外有的企业也有测试开发工程师编写的针对具体应用的测试工具。下面简单分析一下每种工具的应用情况。

        先说商业化测试工具。商业化的测试工具以其简单易用性受到测试工程师的欢迎，尤其是基于录制/回放的功能性能测试工具，大大地简化了测试工程师的工作；而一些复杂的测试，例如静态分析、内存检测，使用测试工具更是起到事半功倍的作用。但是大多数中小规模的软件企业没有足够的预算来购买昂贵的商业工具，另一方面测试工程师还没有全面掌握使用商业工具的技能。业界比较知名的几个测试工具厂商如MI、Sugue、Compuware公司提供的测试工具，动辄数十万、上百万，不是一般软件企业能够承受的，即便能够承受，往往也找不到适当的人选来使用，真正灵活地使用商业化工具软件，需要较强的综合能力，包括数据库的使用、脚本编程等等；除此之外，由于是通用的商业软件，不一定百分百地切合具体应用的测试需求，我们常常能在论坛上看到各式各样求助的帖子，这些关于工具具体使用的问题，即便求助于工具厂商的技术支持，也不一定能够轻松地解决，因为它需要综合工具的解决方案和具体应用的背景；另一方面，企业级的应用往往庞大而复杂，尤其是在分布式环境下，仅靠单一工具难以完成全部验证的任务。有的时候经过对工具的研究和评估，得出的结论是没有现成的工具完全地适合项目的需要，或者有现有的商用工具适合当前的应用，但是工具提供了许多超出实际需要的功能，大大增加了花费，这些情况下可以考虑使用开源工具。

        以测试Java应用为例，最典型的开源测试工具是JUnit，它提供了一个进行回归测试的框架。作为一个测试框架，JUnit并不局限于应用在单元测试中，同样也可以应用于集成测试。比如对web应用进行集成测试的HttpUnit等测试工具，同样是基于JUnit框架。基于JUnit，利用开源工具提供的高层API，我们可以构造出各种随需应变的测试，而回避底层细节。除了一些为测试而设计开发的工具，另外有一些小工具，虽然不是特别为测试而开发的，但在一定场合下也可以被使用，以简化测试过程，加快测试执行的速度。开源工具的好处不言而喻，因为是免费的，可以省去购买商业工具的昂贵预算，但实际上开源工具的优势不局限于此。相对成熟的开源工具在互联网上都有相应的技术社区，一些技术支持可以较快地在社区内得到响应，比较理想的情况下增加新功能或者是修复缺陷的请求也都能够比较快地得到响应，由于源代码公开，如果不满意工具现有的功能而不想等到下一个版本的发布，还可以自行修改以适应自身的需求。但是开源工具的劣势也同样存在，例如和商业工具相比而言还不够成熟，工具演化的前景不明，加上使用起来对测试人员技术上的要求也更高。

        如果以上的方案都不能适应当前应用的需要，那么可以考虑开发一个独立的解决方案，使用脚本或定制的工具，或者仅仅依靠手工测试。当然，开发测试工具必须经过仔细的分析以确保从长远来看不会比购买工具花费更大。有些情况下必须使用独立开发的测试工具，尤其是当软件或者软件运行的环境非常特殊，无法使用现有的工具进行测试的时候。这些情况包括：操作系统不兼容、应用程序不兼容（例如因包含第三方插件导致的被测软件与捕获/回放工具不兼容）、特殊的测试需求。

测试流程的制定

        在传统的瀑布模型的过程模型下，软件的测试是在分析、设计、编码工作全部完成后才着手进行的，瀑布模型由于许多原因已经不能适应当前大规模企业应用的开发，包括它引入测试的时机太晚，造成修复在测试中发现的问题的代价太大。当前更具有普适性的过程模型，无论是无论是UP还是XP，都强调尽早测试甚至是测试先行。从整个工业界来看，总体的趋势是在整个过程中让测试人员尽早地介入，并且更多地与业务分析和开发团队协作[4]。目前国内已经有越来越多的软件企业开始意识到软件测试的重要性，从过去那种完全没有测试或者仅由开发人员在项目收尾阶段简单验证一下大体的功能的做法，转变到成立独立的测试组或测试部门来执行测试的任务。但是在多数中小规模的软件企业中，测试组的工作仍然比较被动，“测试先行”不能得到很好的贯彻，需求分析、设计阶段都没有严格的评审，代码的可测试性也常常被忽略。

        对于测试流程的建立，测试团队常常无奈地表示管理层认为流程会浪费时间，或者当前任务繁多，还没有精力去建立一个测试流程。面对这种情况，测试人员首先应当明确自己需要的流程究竟是什么样的，如果自己都只有一个很模糊的概念，是很难说服管理层去启动这个计划的。

        一个规范化的软件测试过程通常包括：拟定软件测试计划、编制软件测试大纲、确定软件测试环境、设计和生成测试用例、实施测试以及生成软件测试报告。实际上，软件测试过程与整个软件开发过程基本上是平行进行的，从需求阶段开始测试就应当介入，需求应当首先被验证，同时一旦完成需求分析，就可以着手测试过程的设计。对整个测试过程应当进行有效的管理，明确定义测试执行周期的起始和结束、将测试环境和开发环境相隔离、实施缺陷跟踪流程、对整个测试过程进行跟踪[1]。除此之外还有许多细节上的规范需要根据企业各自具体情况制定。

小结

        以上是笔者结合自身工作中的体会对软件测试在企业中的组织和实施的一些分析和体会。软件测试在国内还处于起步阶段，但在国外有相对比较成熟的理论和实践，值得我们借鉴。相信在不久的将来，国内的软件测试能有一个飞跃的发展。

参考文献：

①Art of Software Testing, Second Edition Glenford J. Myers

②Effective Software Testing: 50 Specific Ways to Improve Your Testing,  Elfriede Dustin

③Automated Software Testing: Introduction, Management and Performance, Elfriede Dustin,Jeff Rashka, John Paul

④Q&A with Industry Experts: How Are e-Business Trends Impacting Testers and Testing Teams? Jack Wilber, Writer/Interviewer:The Rational

版权声明：51Testing软件测试网及相关内容提供者拥有51testing.com内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像。51testing软件测试网欢迎与业内同行进行有益的合作和交流，如果有任何有关内容方面的合作事宜，请联系我们。