测试人员的挑战(转载)

g_win

[align=center]测试人员的挑战
Jack Wilber
作家/记者
2005 年 3 月[/align]
***简介***
本访谈分两部分，业界分析师就关于电子商务趋势是如何影响测试团体这个问题交换了意见。这些专家来自广泛的开发团队--项目经理、分析师、测试人员--可能没有人会比测试人员更加感受到当前这种趋势带来的冲击了吧。测试人员的任务就是使用非常有限的资源、面对马上就要结束的项目期限，确保复杂应用程序的质量。

作者记录了三名受人尊敬的测试专家和分析师的看法与观点：Theresa Lanowitz，Gartner公司的研究执行官；Hung Nguven，LogiGear公司的董事长和CEO；以及Sam Guckenheimer，IBM的自动化软件质量高级技术执行官。在访谈的第一部分中，他们交流了测试人员所面对的挑战，以及迎接挑战所需要的技术、技能和策略。第二部分集中了讨论有关架构变更是如何影响测试和自动化测试工具的问题。

***技能***
让我们先从讨论技能开始吧。在过去的两三年中，分布式应用程序的爆炸式发展是如何影响测试人员所需的有效的技能和领域知识的呢？

Hung Nguyen，LogiGear：我认为这种发展带来的影响是巨大的。在过去，在测试环境中要进行的所有事情都是非常独立的。您拿到了一套交付的产品，开始运行安装程序，然后进行测试。但是，当使用更加分布式的，或者电子商务的模型时，测试人员就要面对两个主要的问题了。第一个问题，在技术方面，所有的事情都发生了变化。由于您的系统可能使用分布于各个地方的组件，一些是您的团队开发的，一些是第三方组件，所以您无法控制您的环境。这样，仅仅是了解环境并且弄清如何进行有效地测试就是一个很大的技术挑战。

第二个问题，在业务方面，规则也有所改变。过去，用户购买软件包，安装后就可以使用。现在您的用户可能购买软件包，或者他们可能仅仅使用您的电子商务基础设施进行业务交易。所以，在业务的基础上，测试人员还需要进行学习才能有效地工作。例如，考虑性能方面，这只是测试的一个角度。在新环境中，测试人员需要了解非功能性的问题，例如，什么是性能？我如何才能得出"合理的"响应时间，并且对其进行测试呢？这些都是他们在功能方面不总是能够看到的。另一个要考虑的方面就是进行安全的测试。测试人员需要询问，我如何才能知道我的用户是否受保护或者业务是否受保护呢？这些正是测试的灰色区域，因为几乎没有几个测试人员知道如何有效地进行这种测试。

我们已经开始意识到要使测试有效地进行，您需要具备技术技能。因为该领域还不是那么的成熟，我们的测试团队中还有不懂技术的人员。目前，在业务逻辑和用户级，这是无可厚诽的。但是您也需要弥补技术方面的缺陷。直到所有人都了解到我们需要技能熟练的人员进行工作时，我还认为测试人员，会非常不幸地，一直处于发展不充分的状态，并且平均起来挣得较少。在理想情况下，技能熟练的测试人员与开发人员所了解的技术知识应该差不多，因此理应拿到同等的报酬，或者与他们的能力相匹配--而且管理层应该了解这个道理。如果工资结构有所改变，为将更多的天才人员转变为混和工程师添加了预算的话，那么更多的开发人员就会有兴趣成为一名测试工程师。

Theresa Lanowitz, Gartner：即使我们已经看到了分布式应用程序的爆炸式发展，我们还没有看到技能方面的爆炸性发展，对于开发人员或者测试工程师来说都是如此。使用许多分布式应用程序的话，应用程序就是业务。突然间，企业的应用程序都是面向客户的，在传统企业中的IT组织现在都负责创建创造利润的产品，而不只是应用程序。

但是技能并没有什么发展；实际上，我认为它们还有所减退，因为越来越多的企业都匆匆忙忙地创建这些面向客户、利润驱动的产品，他们无法找到技术足够熟练的人员，所以他们常常雇佣那些没什么经验的人员。回到1999年和2000年，我们看到了许多这样知名的网站以失败告终。在大概相同的时候，您听到过许多有关测试工具的大肆宣传，说它们是如何地易于使用，您不必了解技术就可以使用它们。但是我认为这样传达了错误的信息；您确实需要具有技术技能以完成我们所希望的对应用程序的测试。

而且，分布式应用程序只会变得越来越复杂。从发展的角度看，您可以知道使用大型机应用程序的用户是谁，您也可以了解使用了什么样的架构。然后出现了客户端-服务器应用程序，后来又进入了Internet世界，而现在有了无线的应用程序。为了从测试的角度处理这种新出现的复杂情况，您就需要使用熟练的质量工程师--就是那些既了解过程又明白质量工程内容的人。

公司都了解这个情况，但是几乎没有哪家公司愿意这么做。通过调查，我们知道让职工具有坚实的技术技能是企业最关心的问题。不过，他们最不可能做的一件事就是花钱进行培训。所以，这是一个一直存在的问题。

另一个问题就是测试常常是开发组织需要削减预算时首先要考虑的事情，测试人员也可能被认为是入门级的角色，或者将测试看作是您在成为一名开发人员之前，首先要接受的岗位。正如Hung指出的那样，测试人员确实没有被给予与专业人员同等的关注和应有的尊敬。所以，组织常常重复地出现相同的问题，因为他们还做得不够，核心测试人员还不具备原理性的知识。

Sam Guckenheimer, IBM Rational：所以，我们正在讨论的就是，以前人们认为不需要具备关于正在进行测试的软件的深入技术知识，也可以进行测试，但是当面对分布式应用程序时--尤其是在Web上的应用程序--这个假设就站不住脚了。Hung的一本有关测试基于Web应用程序的书极好地解释了这一观点。测试人员需要知道技术是如何影响他们所发现的错误和风险的种类的。他们需要理解技术问题--例如部署拓扑--就像理解他们进行测试的技术所内在的错误种类一样。甚至要了解一些细节，例如在应用服务器上bean管理和容器管理持久性之间的差异--所有这些问题都对会影响到您将要发现的错误的种类。现在的测试人员需要了解技术以及相关领域，同时也要掌握通用的测试技巧。

例如，假设您在浏览器中看到一条错误信息"404-Page not found"。这种错误可能是由于一个损坏的链接引起的，或者也可能是由于某些服务不存在。一名优秀的测试人员不仅仅应该对不存在的服务产生疑问，而且也应该能够肯定他的这种怀疑--例如，通过查看其他与该服务有关的页面来判断。这是分离判断错误的关键技术。

另一项技能最近也受到了广泛的关注，也就是测试人员是否具备一名优秀探索者的能力。从历史角度来看，测试所要进行的许多内容都已经被高度脚本化，并且进行了周密的计划，但是，实际上，优秀的测试人员应该是优秀的探索者。他们可以发现可能作为提示的东西，而且知道如何在此基础上进一步探索。这些提示可能非常简单，例如某个页面的加载时间惊人地漫长。一名优秀的测试人员会怀疑，这意味着什么呢？而且知道接下去应该采取什么策略。James Bach 编写了一些有关探索性测试的最佳资料，而且对该主题也进行了深入的运用。我认为这当然是一种关键的技能，也是测试团队需要具备的技能。

***压力***
多年来，组织不断地努力"更快地、更好地、更节省地"开发软件，测试人员的存在只是保证要实现"更好地"这个方面。现在，测试人员是不是要承受更大的压力解决"更快地"和"更节省地"这两方面问题呢？

Theresa Lanowitz：我们真正在谈论的其实是使用了多年的选择三角形：预算、日程还是质量。您的问题认为测试人员的存在就是为了保证"更好地"这个方面；但是他们确实能够做到吗？请考虑一下，测试工程师已经被强迫赋予了一种角色。在传统的瀑布式开发中，测试仅仅在应用程序将要付诸使用之前的一个很短的时间段内才开始进行。测试工程师实际上从没有在开发过程中使用过用例或者测试用例。而且如果开发期间的日程安排有所顺延，那么测试工程师就遭殃了。我认为测试人员并不总是能够保证"更好"。

如果要保证"更好"，测试人员实际上就需要成为客户的代言人。而且我不认为他们会受到尊重，拥有足够的时间，使用优秀的工具，或者甚至没有正确的文化背景来支持。组织总是更加关心更快与更节省，而不是更好，而且常常只有发生了灾难性的或者接近灾难性的事件，才会使大部分人意识到他们的开发能力并不是像假设的那样优秀。在过去几年中，我们经历过所有那些高知名度的运行中断和网站故障，我们一次又一次地感受到历史在重演。

在预算内准时地创建高质量的应用程序，这需要那些非常严谨的组织才行--在管理和过程两方面都很严谨。但是这种文化氛围还没有在业界中流行起来。

这种文化需要什么样的基石呢？熟练的职业人员；可以文档化并且重复的过程和过程；强大的工具和服务。人们常常认为工具将会是万能的，但是事实并非如此。如果您的目的是要较快地发布，那么您可能就要牺牲质量，而且可能会超过预算。这就是在.com蓬勃发展时我们所看到的。但是真实的情况是比较悲观的，您即无法真正地加快面世时间，而且由于超时，新项目开发的费用也会失去控制，超过维护费用，而且使您无法准时将正确的产品推向市场。

Hung Nguyen：我认为，这个问题可以追溯到缺乏对于测试团队的预算。管理层常常想要创建质量更好的产品--我没有遇到过意见相左的人--那么这就需要更好的过程、使用更先进的开发方法学和更好的测试策略。但是，如果您看一看大部分的业务预算，就会发现没有为测试留出余地；这都归咎于研发或者开发。所以，在组织中没有为测试留下一席之地，也没有业务策略和管理级的预算，但是测试人员仍然承担全部的责任，要确保系统运行正常。

另一个问题就是，几乎不存在什么可靠的度量方法来表示以前您已经作了多少工作，所以也就无法追溯判定您是工作得更好了还是更差了。如果您的产品中出现一个巨大的故障，那么千夫所指的是哪里呢？首先就是测试，但是最后所有人都会收到责备，没有人可以为单独一件事情负责。我认为这是从管理层角度出发所面临的最大问题。如果您想要"更好"，那么您必须提升测试和质量工程的可见度，而且您可以通过提高预算来完成，这是很有效的。应该让测试人员与开发人员合作来弄清如何完成工作。测试预算可以是开发预算的百分之几，或者优选方案，应该为业务预算的百分之几，实际的数值还在争论中，但是肯定是要制定计划的。我们将资金分配于市场、销售和研发，那么为什么没有测试的份呢？

"更节省地"开发也并不是件容易的事。工具和过程当然可以有所帮助。培训，尤其是如何有效地使用工具，也会有所帮助。实际上，这又回到了我们刚才讨论过的技能问题上来。寻找优秀的测试培训是个问题；严肃的、基于技能的软件测试课程数量是有限的。我绞尽脑汁只想到目前在美国惟一一个开设良好培训的例子，是由Florida技术学院提供的，Cam Kaner和James Whittaker进行讲授。California大学在Berkeley 与Santa Cruz Extension、LogiGear 与 SQE所进行的课程也是提供有用软件测试课程有限的几个的例子。除了这些，我认为也存在巨大的技能鸿沟，在大学级别上，增加更多的教育课程会是一个好办法。例如Rational的公司一直都在开发支持新技术的工具，但是测试人员需要在更广阔的环境中对其进行了解。工具只是解决问题的方法。要想有效地使用它们，我需要知道我已经出现了问题，这个问题是如何定义的，而且存在很多的方法来解决它。这才是我所谈论的教育的类型。

Sam Guckenheimer：实现更快与更节省的关键是在开发周期内使用迭代的开发过程使测试不断向前，这样，在发现缺陷时，才可能更节省地、更轻松地修复。不过，我不认为测试人员已经进行了良好的培训能够使用迭代的过程进行工作。项目经理也可能没有进行良好的培训以考虑测试的角色；那就是为什么我们向Rational Unified Process和Rational大学培训中加入大量内容并且还要持续进行扩展以展示测试人员是如何进行迭代工作的原因。

但是，即使您并没有进行迭代式开发--如果您在使用瀑布方法--也适用相同的概念：为了节省时间和金钱，首先要把测试作为基础。在早期迭代中，您首先想要检验技术条件并且在简单的测试中进行功能级的测试，然后逐渐上升到复杂场景和配置测试，在稍后的版本中又进行多变量的混和测试。理想情况下，您会不断积累自动化测试方法，但同时您也需要不断地进行优化。例如，对于接口的自动化测试是绝对关键的，而且应该在任何时候不断地进行。但是在用户的场景中，可能会在可用性、测试反馈或者设计变更方面有所变化，您也需要肯定、清楚地了解您测试的内容是什么，以及当应用程序在测试发生变化的状态下您如何进行优化测试。

非常重要的一点就是要了解不同级别测试的强大威力，而不认为测试只是在已完成的系统GUI上进行操作。作为测试人员，我们需要仔细地理解单元测试和交互测试，什么样的测试种类才算恰当以及在哪里进行测试。

***过程变更***
让我们来更多地讨论一下过程吧。在测试人员与扩展开发团队的其余人员协同工作时会出现什么样的变更阻止前进的步伐呢？敏捷的开发过程提倡进行测试为先的设计和单元测试。测试团队现在是否在更深入地进行代码级和模型驱动的测试呢？

Sam Guckenheimer：我们来一次回答这些问题，首先从测试人员与扩展开发团队协同工作开始吧。我坚信测试人员必须与开发人员紧密合作；他们应该一起工作，同时进行迭代过程。我认为市场中大概有一半的公司正在以这种方式进行工作。另一半则认为测试人员应该比较独立，他们中的大部分将测试外包。从我的观点来看，您这样做就丢掉了测试的一半好处。您雇佣人员来发现错误，但是您并没用创建出以不断的和探索性的学习为基础的过程。如果您的测试人员与开发人员工作联系比较紧密的话，那么在过程中都会有所收获，而且也都会为创建出更好的产品而贡献力量。如果您将测试放手交给外包测试人员或者项目之外的测试团队的话，他们能够发现一些机械的错误同时进行报告，但是真正以迭代的方式发展产品或过程的能力却会受到限制。

下面就是有关"敏捷开发过程"问题的部分。发展式开发的概念是极限编程（XP）的基础，极限编程已经发展成为一种敏捷的活动。在敏捷开发中进行测试还没有被明确地定义，对于它应该包括的内容有许多观点。我倾向于使用Brian Marick 与Bret Pettichord所使用的定义，基于6个原则--实际上他们称其为口号--都是从实践得出的。一个原则就是您应该以实现技术说明书的方式开发测试；本质上，测试就是面向设计说明书的。因此，Rational Unified Process所称的用例实现都是通过测试完成的。您在软件创建的同时进行探索性测试，您要不断进行迭代和优化，主要关注于为可测试性而设计。我认为，这些都是伟大的实践，而且许多测试人员已经开始注意到它们了。

测试人员已经在源代码级就更深入地进行测试了吗？这里，这个命名会有点让人犯晕。在一个组织中被称为测试人员的人可能在另一个组织中被称为开发员，反之亦然。在大多数组织中，测试人员并不是直接从源代码阶段就开始进行测试，除非他们与开发人员配对工作。我认为这样是恰当的，因为开发人员应该为源代码的质量负责。很久以来我们就已经知道测试源代码的最佳人选就是编写源代码的人，而且Rational也提供了强大的工具支持开发人员进行测试活动。

模型驱动的测试也会带来另一个问题。模型提供了一种伟大的方法，进行文档化系统、可视化系统行为并且在团队中以一种易于理解的、减少复杂度的方式沟通共享的工作。使用模型进行测试的好处正在成指数地增加，而且呈现出一种奇妙的趋势。模型驱动的测试包括很多的内容。一个就是可以专门为测试而开发模型，与源代码开发分离开来，这可以作为一种创建大量测试的方法。（Microsoft 的Harry Robinson在他维护的网站中体现了这重意思：[url]www.model-based-testing.org[/url]）。

从另一方面来讲，Rational 的观点就是，模型驱动的测试意味着模型描述了测试状态下的软件--其结构和行为。相同的模型可以捕获对所要进行测试的内容的定义，也可以捕获测试的结果。我们正在努力为模型驱动测试的发展做着贡献。例如，Rational Test RealTime以UML顺序图的形式表示了测试状态下软件的行为。我们的模型驱动开发的概念与在OMG工作组进行的用于UML测试简档的工作相一致。如果UML测试简档被OMG所采用，我预言我们会看到使用模型进行结果可视化和定义测试的急速发展。

我们还没有讨论测试人员与分析师协同工作的方式问题。在这两个角色之间一直都存在一种关系，即使在最明显的"瀑布"过程中（比如IEEE 829），人们也可以了解测试需求。建模不断地发展为分析和开发的实践，这将分析师和开发人员紧密地联系在一起，因为它将帮助开发人员使用级别不断增加的技术条件将需求转换为设计。另一方面，它也会允许他们以不断增加的抽象度将设计可视化。起初，测试人员并没有被考虑进该循环中，但是仍然享受到了这些益处。确实，当他们意识到模型不仅仅会描述构思，而且也会捕获实际系统行为时，他们就体会到了其中的妙处。人们频繁地克扣模型中的用例实现方式，但是如果团队能够将应用于结构上的相同类型的反复工程应用到行为上去的话，这种情况即将改变。那也就是我们正在前进的方向。如果您使用了Rational Test RealTime，那么您就会发现，在序列图中的值正是您通过捕获系统行为而得到的。

Theresa Lanowitz：过程，包括早期测试的方法，对于任何取得成功的组织来说都是很关键的，但是许多人并没有意识到这一点。两三年前，Gartner 听到许多的组织说："我们开发这套应用程序就是为了[适合您最需要的垂直行业]，而且我们想将其转变为商业产品。我们的计划就是把它卖到行业中的其他公司去，并且使我们脱离母组织。"但是，当我们探讨了作为一家商业软件公司所需要的条件时，他们就会退缩。我们没有看到任何成功脱离的案例。但是，实际上，企业确实需要能够并且也愿意表现得像商业软件公司那样。他们需要了解创建周期、需求和日程；他们需要能够与工程组进行沟通的产品经理等等。目前，我们还没有看到企业组织全部都采取了这种更加结构化的行为。

要实现这种改变，就需要建立起支持它的文化。资深人员常常告诉我，管理层并不想要过程，因为那样会占用太多的时间。要建立一个优秀的过程，您必须理解它应该包括什么内容，并且在整个过程采用的最初阶段保持对其的管理，贯彻完整的原则。您也必须记住，最终目标是为了准时并且在预算内发布高质量的人们所公认可以作为产品的应用程序。除非组织中从上到下每个人都重视产品质量，否则组织就会以一种混乱或者无法发挥作用的模式运行。

应该牢记编写代码实际上仅仅是任何项目开发中的一小部分内容，这一点是很重要的。识别正确的架构，开展恰当的过程，确保您遵守企业已经建立的标准--这些都是很关键的事。

对于进行源代码级的测试，开发人员现在正在编写更多的单元测试，这是值得肯定的。一些确实不错的工具已经在市场上出现，这些工具都可以帮助开发人员创建单元测试。不过，我仍然认为，随着时间的过去，测试人员需要变得更加地懂得技术，而且组织需要进行更大的投资培训测试人员，使其跟上技术的发展。那么，随着测试人员技能的不断成熟，组织就会更加公平地对待和尊敬测试部门。测试人员肯定也会更多地参与进代码级的测试中。

对于模型驱动的测试，UML为此做了很大努力。如果您编写了测试用例，那么您就已经编写出测试用例了。如果您能够将一个优秀与稳定的过程完全集成入您的软件开发生命周期中，那么这就是一件很值得肯定的事。

Hung Nguyen：当然，测试人员与开发团队的其余人员的融合程度随公司的不同变化幅度很大。一家公司可能使用并不是很懂技术的测试工程师，但是他们应用了很棒的过程，完全能够使测试、开发与业务团队协同工作一起探讨需求和特性，并且全部将其文档化。但是，在整个行业的范围内，这种情况肯定会发生改变，测试人员会更早地参与过程，并且与业务分析师和开发团队进行更多的合作。

让开发团队在源代码级考虑其代码的可测试性并且考虑进行单元测试是很好的。但是如果您看看要进行测试的阶段--需求级、源代码级、接口级、组件级以及集成测试所在的系统级--测试人员在源代码级、接口级和组件级的表现都不够理想。在接口（API）级，合作进行得还不错，但是在源代码级，就仍然是开发人员的事情了；测试人员还需知道如何才能在那个环境中发挥作用。

例如，Rational Purify属于一种开发人员经常使用的动态工具，这是很好的。但是，要想进行更广泛的测试，您就需要执行更多的代码，而开发人员没有时间这样做。所以，一种明智的办法就是将开发团队与过程相集成，并且也让测试人员在测试过程中使用Rational Purify。同样地，让开发人员先进行一遍单元测试，然后再让测试人员进行一遍测试，这样做也是可以的。虽然可能由于缺少对测试过程的学习，我们仍然将代码级的测试看作主要是开发人员的活动，但是我们确实需要填平开发人员与测试人员之间的沟壑。但是测试人员仅仅需要运行测试，记录所有的错误，然后把结果发送给开发人员；他们甚至不需要解释这些结果所包含的意义。

我认为模型驱动的测试在测试设计和分析方面扮演了很重要的角色。例如，Rational Quality Architect能够创建基于模型和依赖性的测试。如果您发现了错误，您实际上就可以使用模型来缩短推算出故障的路径。所以，模型驱动的测试就是进行测试设计和生成的关键因素，也可以作为自动化故障分析与精确定位问题的知识基础。

***故障的代价***
人们常常讨论把过程作为一种减少软件故障的方式。很多著述也记录了与面向公众的电子商务站点有关的故障的代价在不断地增加。业务的变更很大程度上影响了测试实践吗？

Theresa Lanowitz：绝对如此。当使用电子商务时，故障并不仅仅意味着人们将不能使用该软件；这还是有关公众形象的问题。因为使用这些应用软件的人都没有技术基础，也因为软件的应用范围正在逐渐增大，所以软件必须是能够防止错误操作的。您的用户并不具备丰富的经验，所以您仅仅有一次机会。如果他们想要使用什么--例如Web服务--而它根本就无法执行或者工作，那么他们就不会继续进行，只会转向其他的站点。这就直接说明了需要将产品（例如Web服务）的质量提高这一问题。

Sam Guckenheimer：我认为故障代价的增加已经使管理层更加意识到测试和质量的重要性。幸运的是，我们已经超越了这个阶段，也即一些以前的网站忽略了质量，而完全关注速度问题。因为我们经历了那么多高知名度网站的故障，所以管理层变得越来越精明，越来越仔细。

Hung Nguyen：我不认为故障带来的高代价确实是一个新问题；我们以前就已经面对过这个问题了。它确实会影响测试人员；它给我们施加了压力，使我们更有效地发现错误。但是这个问题与质量保证过程更加紧密相关。我们该如何实施更好利用人员和技术的质量过程呢？我们该如何使QA与开发团队协同工作以开发更好的实践呢？在电子商务故障的环境下，我们现在进行测试的方式与曾经进行测试的方式有所不同了。我们不会停止工作，知道产品已发布；我们持续地进行着测试。这也是为什么一个新的监理市场已经兴起的原因，我们正在使用机制来提醒我们注意故障。

目前，公众也受到了更好的教育。他们明白如果他们付了钱，那么您就必须提供优秀的产品。他们可以进行选择；行业内的竞争如此的激烈，如果您无法提供优秀的、高质量的产品，那么他们就会离你而去。

这些故障也造成了一个非常积极的结果，管理层已经开始从金钱的角度看待质量问题了。他们正在告诫他们的开发组织："我并不关心你称它是高质量或者低质量的产品。如果它让我的站点关闭两分钟，那就会花费我一百万美元，我不想这类事情发生。所以，你回去应该弄清如何才能不让这类事情发生。"而且管理层也知道如果他们给测试小组提供相当的预算，那么测试小组就应该负起责任。当您制定年预算时，会想要把测试置于列表的顶部，因为这是获取高质量软件的主要途径。最终，那将赋予测试人员权力、责任和义务。

leo_wangxy

鉴定完毕，属于好帖！

chenxi8320

学习中，收藏了

ia_victory

在学校的时候去实习还是比较能学到东西的，现在都有些后悔，当初怎么就没有去找个单位实习，浪费了四年的时光……

wensy

我知道你想说明test对项目的重要性或许这些公司也明白

但是预算与时间，矛盾与进程等，有诸多的不理想总是在困扰测试的发展

尽管这样 我还是对未来抱有乐观的态度

983221wy

好帖！

qwdingyu

谢谢你的介绍，会好好看的

xingzunxi

优秀的帖子

李逍遥

收藏!

yangxp2006

我也收藏

nkillers

阅!~~~~~~~~~~~~

jokie

[font=宋体][color=Pink]希望大家能够交我这个朋友！我的QQ：215143066，MSN:jickllyloveshe@hotmail.com
欢迎加入我的群！26526836

[/color][/font]

walker_lai

好东西

国国国

good!thanks!

yyjzxyghj

收藏！！

mYp-maY

收藏先，感谢lz

ringboo

先晕一个！sdlkfj1
本人认为只要是让我看得晕晕的就是好贴！

wujp_652

一个女测试工程师的成长 3


我们买的房子就涨了一万，由于位置好，之后房价一直飞涨，现在每平方已经涨了600元。

　　现在虽然收入也可以，工作离家挺近，同事关系也不错，但是还想换工作。刚毕业是人生的第一次冲刺，第二次换工作我和老公的收入有突破，现在是想第三次冲刺，看自已还能不能有所突破。
　其实在辞职之前我就找到了工作，辞职后离正式上班还有几天时间，呆在家里好好休整了一下，那几天是最闲散的几天，呆在家里舒服极了。这几年的经历让我明白了许多事情，其实人一生中就那几个时期最难，挺过去，一切也就过去了。有个同学，毕业后准备自已在沈阳闯一闯，人不够勤奋，又不太走运，总是很不顺，最后掉队离开沈阳回了老家。现在和我一起毕业，在北京、上海、深圳、沈阳等地的同学混得都还可以，大部份有家有房了，如果她当年不掉队，现在也应该不错。所以给自已定了目标之后，就不要轻易放弃，给自已个机会，认认真真的做好它。在大集团期间，经历了形形色色的人和事，拿我们老板来说吧，他根本不是做事情的人，整天想融资，到处找合作伙伴，只想把他的蛋糕做大，谈他的企业多有前景，其实他所谓的前景都是空的，到现在为止，已经有两家大集团的大笔资金被他套牢。他不关心生产，不关心开发，不关心质量，所以想做点事情的人，一定不要给这样的老板打工，它乘载不了你太多梦想。以前自已象个学生，对年长的同事或是上司都象对老师一样的尊敬，其实没有必要，到了社会上人人都是平等的。以前接到工作只会说“行”，其实很多时候你可以说不行的，当你加班加点做了职责之外的工作时，大多数时候，人家会认为你工作不够饱满才有时间做别的。有些事不必直来直去，很多时候**可以通幽的，遇到事情要多换几个角度来思考。有时在一个地方人家对你一开始的印象就定了格，很难改变，这时你就该考虑换工作了。没有十分的把握就不要和你老板谈加薪，差不多的时候就换换环境……

　　由于原来这家公司从没有过测试这一岗位，我刚过来时测试组只有我一个人。头一个项目是我自已做的测试，从计划到分析报告，领导挺满意，这是对于我的第一个考验。第二个考验就是为全体开发人员做测试培训，以前只是测试，从来没给谁做过培训，很紧张。于是我对自已这此年的工作经验做了一个总结和提炼，买了本书（关于测试的书极少，就那么一本书还有点实际内容）加紧攻读。做过多少培训我记不清了，每一次都压榨着我的潜能。效果还不错，因为我的东西来源于实践。很快领导为我组建了测试组，开始的时候有四个人，两个是关系单位领导的子女，一个是原来的程序员，还有一个是从别的部门调过来的学计算机应用的。我的队伍战斗力其实很差。关系单位的子女要特殊照顾，就不用多说了，大家明白的；程序员在我来之前对测试经理的位置早已垂涎，根本不配合我的工作；剩下的那一个让我最报以希望的整天稀里糊涂，不务正业，干不了什么。测试组就这样的配置，还没上阵，一群残兵，而且没得商量。

　　领导对我的个人能力还是充分的给予肯定的，试用期本来定的是三个月，在一个月的时候，就通知我被正式录用了。半年内涨了两工资。这让我很有动力，而且有了前所未有的成就感，第一次有了想做好一件事情，做出点成就的想法。

　　领着我那支队伍打天下，真是难啊！测试一个项目基本上70%的BUG是我找出来的。真累！一坐在电脑前，我的大脑就处于高速运转状态，晚上回家满脑子都是程序上的事，有几次还失眠了。公司的程序用的是PB和JAVA还有JSP做的，数据库是ORACLE，我就得加紧熟悉这些开发上用到的东西，因为做测试如果对所测系统的开发语言和数据库没有一个良好的熟悉程度根本做不好。我为组里的测试员做培训都数不清了，我是很诚心的想把我的经验与别人分享，从ISO9000到测试方法，到开发语言。效果不明显，那个有开发经验的程序员不屑于听，其他三个人总是听不懂。最后我投降了，顺其自然吧！还好领导能体谅我的难处，因为他也清楚我这支队伍是没有战斗力的队伍。半年后，测试组的状况才有所好转。
开发人员都很尊重我的意见，这让我很欣慰。一次测试一个刚毕业的程序员做的程序，错误很多，我看出他很着急，我想起自已刚毕业时的情景，就鼓励他说：“不用急，别人刚来的时候还不如你做得好呢，有错误是正常的。慢慢了解咱们的开发规范就好了。”在工作中能扶持别人的时候我尽量去扶持，因为大家都不容易，特别是家在外地的。

　　其实测试是有技巧的，很想有时间写点东西把自已的经验做个总结，但总是很忙。我们部门一开始有七个女生，被戏称为七仙女，现在只剩下三个了。以前在大集团的时候要求形象，穿套装，还化妆，现在公司不要求这些，我就什么舒服穿什么。牛仔裤、运动鞋、运动装是我的最爱。有一回和同事说：“我以前还化化妆，现在越来越不注意自已的形象了。”我同事说：“化妆给谁看，每天对着电脑，窝在那时，即使你脸上粘个饭粒都没有人看。”呵，差不多吧。和我一起毕业的同学现在有做行政的，有做销售的，原来没看出什么差距，现在从事的行业不同，而且已毕业快六年了。据她们说，如果没化妆出门就象没带脸一样不自信，她们很注意自已的形象，很时尚。而我呢，穿得很随意，基本上象个大学生。呵，有时会很忙，忙得一天头都抬不起来，都快记忘了自已是女的了。今天穿上久违的高根鞋，突然觉得应该注意一下形象，买几套时尚一点的衣服了。

　　经过半年的努力，测试组基本上能发挥功效了，总算做了一件事情。在以前的公司时，我是老员工，工作中的问题很容易形成默契，测试组的人很听我的。而到了新公司不一样了，以前的管理方式总是受挫。这使我明白了一个道理，给你的下属分配工作的时候，只要说明让他做什么，怎么做就可以了，不必再象以前那样带有征求意见的语气，不要再加上“行不行”这句话。很多东西都是看起来容易做起来难，原来管理工作也有那么多学问。人与人之前的关系根本不象计算机语言的布尔值只有0和1，只有对或错那么简单。现在我成熟了，明白了人力资源优化的道理和方式。我在测试组负全责的日子，让我知道，有多大权力就有多大责任。还有一些只可意会不可言传的东西。

　　后来这个公司也要过ISO9000，这回我只想认认真真的把它做好，不再是任务，而是我的一个作品。这个公司做的9000是完全面向软件的，所以对软件工程的东西要求得很细。我自已买书，了解软件工程和配置管理的东西，实践经验虽然差，但应付9000外审一点问题都没有。给我们做培训的老师没做过软件行业9000的指导，呵呵，她还要向我请教呢。初审很顺利的通过了，复审合格。呵呵，经过这两次做9000，我对质量管理的认识有了一个新的高度。学到了很多很多东西，特别是从工作中培养出来的一些意识和思想很重要。呵呵，说实话，真的很累。

　　总的来说一切很顺利，我得到了足够的重视，虽然薪水低了点，但工作得很舒心，经常很有成就感。
　　说说我老公。我老公很支持我，在一起久了，有了很多的默契。每天下班他都在车站等我，对于恋爱了近10年，结婚也有三、四年，很难得。我同学和朋友都羡慕得不得了。老公每次发奖金都领我出去购物，尽可能的给我买好东西，我挑便宜的买他还不乐意。真是个大傻瓜，想替他省钱都不干。老公在公司也得到了足够的重视。老公以前不爱说话，不善交际，没太多的朋友，在工作中培养了他的交际能力，也有了不少新朋友。变得自信了许多，技术也越来越好。老公很勤奋，自修计算机网络自考，因为网络方面一直比较欠缺。

　　不能说一切都好，日子安逸就没有烦恼了，除非你无思无欲，那怎么可能，我们都是凡人。呵呵，而且我和老公还都是上进的大好青年。呵呵.....

　　当你的能力在提高，而公司给你的空间和待遇和你的能力不匹配时，我们就会有想法。我就是这样，我老公也是。三年来我的能力成倍的增长。有一阵子没什么项目，很闲。对于我来说也是一件好事，可以安心看一下书了，我只有短暂的开发经历，而且不是作为主力，是帮忙的。我很想做开发，很想尝试，我认为我能行，从技术到经验我都很自信。我找到我们头，说了我的想法，可事情办得不好，让对方以为我有野心，一段时间里对我心有介蒂，提防我走。其实我本意是想有一个开发的经历，因为有些事情不是身在其中很难真正知道本质，我是相通过拥有一段真正的开发经历来提高我的测试能力。我热爱测试这份工作。直到现在为止，开发组无论多忙，我无论多闲，都不会让我去做开发。我只有自已给自已创造机会了，经常自已做一点小东西。

　　想起一句话：人得自已成全自已。

　　正在我手头没什么项目，想法滋生的时候，我的老东家（之前的那一家合并大集团公司）给我打来电话，要我回去。给我打电话的是以前比较要好的同事，现在她得到重用，负责一个大项目，在公司内部权力纷争中，她想找一个信得过的人和她做主力，把持核心技术，她想到了我。回去待遇优厚，可以做我心宜已久的开发。这一回我犹豫了，是回去还是维持现状呢？一想到以前我在那家公司所受的苦，就感不寒而栗。再想想回去是作为主力队员，而且那是心宜已久的职位和待遇，着实具有诱惑力。思考良久，最后决定就留在这里。第一，好马不吃回头草，当时走就是不满那狭隘管理；第二，本人不具备溜须拍马的能力，在那边屡屡被压制不就是因为不会媚上欺下吗；第三，现在的公司总的来说做得挺开心，同事关系好，技术不保密，能接触到我想接触的东西，这在很多公司是很难得的。第四，这家公司人员的学习氛围好。第五，回去等于后退。第六，不想参与那些权力纷争，无聊，做技术就好好做技术。
　　2004年这一年我都很闲，让我有很多时间做自已想做的事和思考一些东西。学了点JAVA，呵呵，一开始就看《JAVA编程思想》，书太厚了，看了一半没看完就没有那么多闲功夫了。同事说建议我要学JAVA先从JSP入手，呵呵，我当时没听，都说挺难，但依我看还可以，还看得懂。最后找了本JSP的书翻了几页，看了JAVA之后果然有种居高临下的感觉。自已想做个网站，网页设计已经做得差不多了，就忙了起来，没什么空闲，不加班就算好的了，每天的时间安排的满满的。
　　
　　同事说你若真的想做开发，就换一家公司重新来做，让我去应聘JSP程序员。“我说，我现在还没学得怎么样呢，可以吗？”他说，“没事，现在完全可以说你有经验的，必要时可以来点善意的谎言。”可我没有勇气那样做，因为现在和刚毕业时的心态不一样了。呵，从来也得讲诚信啊！再说现在做得好好的，也没有勇气去冒那么险。

　　其实我一直很努力，比我周围的女性朋友努力。也挺累的，可是我无法放缓自已的步子，或者说我更迷恋那种阶段性的成就感带来的愉悦，我总是不断的给自已定目标。其实女人要做出成就要比男人付出的更多，特别是象我这样一个不太聪明的女人，庆幸的是我有一个好老公，虽然不太会赚钱，但他很支持我，很体贴我。

　　多年的媳妇熬成了婆，从毕业算起，入行快六年了，从一开始我把前辈们尊称为哥哥姐姐，到现在，刚毕业的小弟小妹叫我什么什么姐，思想上有了很大的变化。凭我现在的智商看来，纵然是活到老学到老，人不能总是一味的向前，总是要停下来的。活到老学到老的“学”是一种自然状态的学，而我现在的“学”有时也是很无奈的。我其实很矛盾，很想停下来欣赏一下风景，可是入了这行更体现这句话“逆水行舟，不进则退”，很多时候你学，都不一定赶得上潮流，对于大多数人来说你学是为了与发展行业状态保持一致，你若是不学，那就可怕了。虽然如此，我还是很喜欢IT，因为常做常新，它总是让你保持旺盛的生命力，呵呵，其实有时是被迫的。
　　
　　现在感觉很疲惫，总结了一下是因为做技术形成了这样一种惯性，当没有新东西要学，当工作中没有新发现的时候就会感到腻烦，所以疲惫。呵呵，可是要做新东西，有新东西要学呢，还是累。就是很矛盾，越来越矛盾。

　　现在进入工作的疲倦期,我知道,遇这种情况,只有换个环境才能再次激发我的潜能和创造力

厍仕杰

看了n遍 不累

Jamson

哇噻! 像小说,不过还是多不错的哈  辛苦了!