软件测试员的思考问题方式(转)

Posted 2020-11-07 五六七

测试员有很多不同的背景，测试团队是多元化的集体，但是大多数人都同意：测试员的思考方式是不同的。怎么不同?有人说测试员是“消极”思维者。测试员会抱怨这种说法，认为自己喜欢征服，他们在报告坏消息时有一种特别的兴奋感。这是—种 普遍观点。我们提出另一种观点。测试员并不抱怨，他们提供的是证据。测试员并不喜欢征服，他们喜欢打破产品没有问题的幻觉。测试员并不喜欢发布坏消息，他 们喜欢把客户从虚假信念中解放出来。我们的观点是，按测试员的方式思考意味着实践认识论。测试运用的是认识论，不是靠傲慢或谦卑。

　　本文旨在把测试员的大脑开发成经过仔细调谐的推理机器。请记住：要用精神力量做好事，而不做坏事。

　　经验1，测试运用的是认识论

　　读者看到这个题目会说：嘿，回来!我们在这里不是要讨论对电影明星的新崇拜。请相信我们。认识论是能够帮助测试员更好测试的一个哲学分支。

　 　认识论研究如何认识所了解的东西：研究证据和推理。这是科学实践的基础。研究认识论的人有科学家、教育家和哲学家，当然还有精英级的软件测试员。学习认 识论的学生研究科学、哲学和心理学，目标是了解怎样才能改进我们的思维。我们使用的术语比经典定义要宽，以便能够更多地利用批评性思维的最新成果。将认识 论运用于软件测试，要问与以下类似的问题：

　　·怎么知道软件足够好?

　　·如果软件并不是足够好，怎样才能知道?

　　·怎么知道已经完成了足够的测试?

　　苏格拉底早在2400年前就提倡并描述了对信念的批判性观察，因此我们把他看作是最早的认识论者。直到今天，哲学家、科学家和心理学家都还在继续研究认识论。作为测试员，这就是我们的遗产。

　　经验2，研究认识论有助于更好测试

　　直接与软件测试有关的认识论问题包括：

　　·如何收集和评估证据。

　　·如何进行有效的推论。

　　·如何使用不同逻辑形式。

　　·拥有合理的信念意味着什么。

　　·形式和非形式推理之间的差别。

　　·非形式推理的常见谬误。

　　·自然语言的含义与模糊性。

　　·如何做出好的决策。

　　从来也没有研究过这些问题的很多人也能测试得很好，但是如果要做得比很好还好，就要研究这些问题。研究认识论可帮助测试员设计有效的测试策略，更好地意识到自己工作中的错误，理解自己的测试能够证明什么、不能证明什么，并编写出无懈可击的测试报告。

　　以下是三本具有很高可读性的入门书：

 ·《批判性思维的工具：心理学的元思想》(Tools of Critical Thinking：Metathoughts for Psychology)(Levy l997)。这本书是针对精神病医生写的，但是对测试员也很有用。书中每一章都是有关更好思维的不同思想。不一定把它全读完，可以挑选任何一章阅读。

　　·《思考与决策》(Thinking and Deciding)(Baron l994)。这是讨论思维世界的一本可读性很高的普通教科书,是很好的入门书。

　　· 《研究的技巧》(The Craft of Research)(Booth、Colomb和Williams 1995)。 这是一本有关批判性阅读和写作的很好的书籍，包括如何组织有说服力的论据。主要针对大学生读者。

　　经验3，认知心理学是测试的基础

　　如果说认识论告诉我们的是应该怎样思考，那么认知心理学告诉我们的是我们是怎样思考的。与测试有关的一些问题包括：

　　·人的感觉和记忆可靠性。

　　·信念从哪里来。

　　·信念如何影响人的行为。

　　·做出决策所使用的偏见和捷径。

·如何了解并分享所知道的信息。

　　·如何考虑复杂事情。

　　·在压力下如何思考。

　　·如何识别模式。

　　·如何把想法和事物分类。

　　·如何注意事物之间的差别。

　　·记忆事件中的失真。

　　·如何重新构建部分记忆的事件(例如不可再现的程序错误)。

　　从来也没有研究过这些问题的很多人也能测试得很好，但是如果要做得比很好还好，就要研究这些问题。研究认知心理学有助于理解影响测试员工作成绩的因素，以及影响人们解释自己工作方式的因素。

　　开始研究认知心理学，不能不看《旷野中的认知》(Cognition in the wild)(Hutchins 1995)。Hutchins研究海军航海团队，以及他们怎样协同工作。这本书的很多内容也都与软件项目和测试团队有关。

　　有关思考心理学的一本有用的书是《理论与证据：科学推理的能力的开发》

　　(Theory and Evidence：The Development of Scientific Reasoning)(Koslowski 1996)。在这本书中，Koslowski研究了人们如何使用因果关系理论进行系统推理。这可以解释为什么测试不只是查看外部行为，并对照简单的预期描述进行检查。

　　经验4，测试在测试员的头脑中

　 　优秀测试和平庸测试之间的差别在于测试员如何思考：测试员的测试设计选择，解释所观察到的现象的能力，以及非常令人信服地分析描述这些现象的能力。测试 的其他工作大部分是一般的办公室工作。如果看到两个测试员并排工作，不一定能看出谁的测试更好。他们工作中能够看得到的部分外表相同，这说明：

　　·很多人认为测试很容易，因为可以很容易地模仿优秀测试员的外表看得到的行为，并且他们没有好的测试的其他标准。

　　·如果要成为优秀测试员，就要学会像优秀测试员那样思考，而不是模仿他们的行为。

　　经验20，测试需要推断，并不只是做输出与预期结果的比较

　 　流行的观点认为，测试员只是执行测试用例，并对照预期结果比较执行结果。这种观点把测试看作是简单的比较活动，没有看到一些聪明人必须设计测试，并确定 预期输出。想想看，测试设计人员几乎从来没有得到过应该测试什么的权威指导，更不要说应该期望什么了。可以得到的指导是要解释的主体。在现实生活中，大多 数测试设计都是基于推断，或基于与测试员的推断有关的经验。不仅如此，这些推断还要随时间发生变化。像测试员那样思考，就是要掌握探索式推断的艺术。

　　探索式推断听起来可能像是奇怪的想法，这意味着要以一种不能事先预测的方式，通过一种思想引出另一种思想，然后再引出下一种思想。有关探索式推断的一本很好的书是《证明与反驳：数学发现的逻辑》(Proofs and Refutations：The Logic of Mathematical Discovery)(Lakatos，1976)。关于这本书需要注意的是，Lakatos如何说明数学和科学推理过程是探索式的，而不是脚本化的。甚至数学家也是积极探索地推理，而不是通过运用枯燥的公式。他们像测试员那样思考!

　　经验5，优秀测试员会进行技术性、创造性、批判性和实用性地思考

　　各种类型的思考都要考虑测试的实施。但是我们认为需要提出四种主要思考：

　　·技术性思考。对技术建模并理解因果关系的能力。这包括诸如相关技术事实的知识和使用工具并预测系统行为的能力。

　　·创造性思考。产生思想并看到可能性的能力。测试员只能以能够想象得到的方式进行测试，只能寻找猜想会存在的问题。

　　·批判性思考。评估思想并进行推断的能力。这包括在自己的思考中发现并消除错误的能力，将产品观察与质量准则关联起来的能力，以及针对特定信念或所建议的行动过程构建有说服力的测试用例的能力。

　　·实用性思考。把想法付诸实施的能力。这种能力包括诸如运用测试工具，并使测试手段和力量与项目范围适应的技能。

　 　总之，像测试员那样思考，会最终导致相信事物可能不像外表看起来那样。不管事物是怎样的，都可能有差别。我们发现，当测试过程以最具破坏性的方式失败 时，根本原因最有可能是视野狭窄。换句话说，这不是运行了一万个测试，而本来应该运行一万零一个的问题；问题是没有想象出测试的总体大纲，没有做即使有两 倍时间和资源也不会做的测试。

　　经验6，黑盒测试并不是基于无知的测试

黑 盒测试意味着产品内部知识在测试中不起重要作用。大多数测试员都是黑盒测试员。为了做好黑盒测试，就要了解用户，了解他们的期望和需要，了解技术，了解软 件运行环境的配置，了解这个软件要与之交互的其他软件，了解软件必须管理的数据，了解开发过程等等。黑盒测试的优势在于测试员可能与程序员思想不同，因此 有可能预测出程序员所遗漏的风险。

　 　黑盒测试强调有关软件的用户和环境知识，这一点并不是所有人都喜欢的。我们甚至把黑盒测试描述为基于无知的测试，因为测试员自始至终都不了解软件内部代 码。我们认为这反映出对测试团队角色的根本误解。我们不反对测试员了解产品的工作原理。测试员对产品了解得越多，了解产品的方式越多，越能够更好地测试 它。但是，如果测试员主要关注的是源代码，以及能够从源代码导出的测试，则测试员所做的工作也许就是程序员已经做过的，并且测试员关于这些代码的知识要少 于程序员。

　　经验7，测试员不只是游客

　 　测试员对产品做的大量不是测试的事，有助于测试员对产品的了解。测试员可以浏览产品，看看产品由什么组成，怎么工作。这样做有很高价值，但这不能算是测 试。测试员和游客之间的差别在于，测试员把精力放在评估产品上，而不只是见证产品。虽然不必事先预测产品应该表现出的行为，但是试验产品能力的活动还没有 成为测试，除非而且直到测试员运用某种如果问题存在就能标识的原理或过程时，这种活动才能成为测试。

　　经验8，所有测试都试图回答某些问题

　　所执行的所有测试，都是要回答有关现实的产品和应该得到的产品之间关系的某个问题。有时测试员完全没有意识到自己在回答问题。如果测试员只是在寻找明显的问题可能还好，但是在很多情况下，问题并不会闪烁着“请报告我”的提示自己跳出来。产品的有些错误行为用户可能一眼就会看出，尽管测试员可能没有注意到。在任何测试活动中，都要问自己什么样的问题应该推动自己评估测试策略，否则就会更像是游客，而不是测试员。

　　经验25，所有测试都基于模型

　 　测试员在设计测试时，头脑中可能会有一个想象的图景，也可能有功能清单或某种图表。测试员会有谁是用户、用户关心什么的一些概念。所有这些都是模型。不 管模型是什么，测试都主要基于产品模型进行，而不是实际产品。有缺点的模型会产生有缺点的测试。学会一种对产品建模的新方法，就像是学会了观察产品的一种 新方法。

　　要研究建模问题。测试员对建模艺术越精通，越能够更好地测试。有关需求分析和软件体系结构的教科书和课程会有所帮助。获得各种建模技能的一种很好方法就是研究系统的思考。请参阅《通用系统思考引论：25周年版》(An　Introduction to General Systems Thinking ：Silver Anniversary Edition)(Weinberg 2001)。

　　经验9，直觉是不错的开始，但又是糟糕的结束

　　测试员很想根据自己的直觉使用具体的测试数据，或判断具体的输出，即测试员自己知道的“本能感觉”，即使说不出来使用这些知识的合理性的理由。我们认为这是有用的感觉，但是只是在开始时更有用，而不是在其他时候。

除了直觉有很强的偏见这个事实之外，真正的问题还在于测试员试图让其他人(例如程序员和经理)认真地对待自己的错误报告和质量评估。除非这种发现是基于大家都有的直觉，否则测试员的工作建议很可能不被采用。

　　因此.我们建议把直觉用作指南，但不能用作合理性证明。当有“这是问题，因为它显然是问题”的想法时，可考虑换一种方式；“这是问题，因为我观察到产品行为与需求x、y和z矛盾，而我的客户很看重这些需求。”

　　经验10,当测试复杂产品时：陷入与退出

　　有时复杂性可能是无法抗拒的。测试员的意志可能会被击垮。因此,当要测试复杂和使人畏惧的功能集合时，可间歇进行。人的头脑具有处理复杂问题的惊人能力，但是不要指望马上就能理解复杂产品。可试着先研究复杂产品30分钟或一个小时，然后停下来干点别的。这就是陷入与退出(P1unge in and quit)法。不要担心在这段不长的时间内效率不高，如果觉得问题太多，则尽快退出。

　　这种方法的优点是,除了选择产品的一部分并研究外，绝对不需要计划。经过几个轮次的陷入与退出，就会开始明白产品的模式和轮廓，很快就会在头脑中更系统、更具体地测试和研究策略。这种方法很神奇。最终，会掌握足够的知识以设计全面的测试计划，如果认为这些计划能够完成自己的任务。

　　经验11,运用试探法快速产生测试思路

　　试探法(hcuristic)是一种经验规则，是一种基于经验做出猜测的方法。这个词源自希腊语,表示“开始发现”。试探法并不能保证得到正确的答案或最佳答案，但是很有用。最早运用试探法的著作是《如何解决它》(How to Solve it)(Polya l957)。

　　出于可能的测试用例数量是无限的，因此肯定要选出在所面临的时间和预算约束条件下有效的少量测试用例。有经验的测试员会收集并共享能够改进其猜测质量的测试试探方法。一组好的试探方法有助于很快地生成测试。以下是采用试探法测试的一些例子：

　　·测试边界。边界更有可能暴露规格说明的模糊问题。

　　·测试所有错误消息。错误处理代码与主流功能代码相比，一般比较弱。

　　·测试与程序员的配置不同的配置。程序员已经偏信自己的配置没有问题。

　　·运行比较难设置的测试。在其他条件相同的情况下，易于设置的测试更有可能已经被执行过。

　　·避免冗余测试。如果某个测试实际上是重复其他测试，就不会产生新价值。

　　为了明智地运用试探法，请注意：试探法中并没有智慧，智慧来自测试员。试探法所能够做的，只不过就是为测试员的思考提出建议。盲目使用自己并不了解的试探法并不是好的测试实践。在收集测试方法时，要了解每个方法背后的原理，以及更适用和不太适用的条件。

　　经验12,测试员不能避免偏向，但是可以管理偏向

　　测试员是有偏向的,这使得测试员选择一部分测试的可能性要比其他测试大。如果有一个很长的编辑字段，测试员也许更可能输入诸如 1111111111，而不是3287504619，因为输入字符重复的字符串，要比从0到9随机选择数字更容易。也许这是一种很小的偏向，但仍是一种偏向。更糟的偏向是，大多数测试员倾向于测试最可视的功能,不管是不是最重要的功能。此外,大多数测试员还倾向于考虑认为与自己类似的用户,倾向于使用非常简单、非常荒谬的输入，而不是具有中等复杂度的现实输入。

　　以下是一些常见偏向：

　　·同化偏向。更有可能把未来的测试结果解释为总体上证实自己对产品的看法。

　　·证实偏向。更有可能关注确实会证实自己对产品看法的测试结果。

　　·可用性偏向。如果头脑中已经想到一种用户以某种方式操作的场景，则更有可能认为这种操作更常出现。

　　·最初印象偏见。更信任所做的第一次观察。

　　·最新印象偏见。更信任所做的最近一次观察。

　　·框架效应。对错误报告的反应与措辞有很大关系，不管其真正含义如何。

　　·知名偏向。把碰巧认识的用户意见放在更重要的地位。

　　·表达偏向。期望较小的问题也许有较小的原因，而严重问题会有大原因。

　 　测试员不能避免这些偏向，因为这些偏向在很大程度上已经固化在头脑中。测试员能够做的是管理偏向。例如，只需通过研究偏向并在实践中注意，这样在思考时 就可以更好地进行补偿。多样化也可以抵御过强的偏向。如果测试员集体谈论测试问题，可以将一个测试员的偏向降低到最低限度。

根据定义，试探法也是一种偏向。使用试探法，是因为其偏向可以以比较好的方式引导测试员。

怎么样提高软件测试员自身素质培养？

　　（1）首先，应对软件测试感兴趣和对自己有自信，如果具备了这两点，那么在开发过程中不管遇到什么样的困难，我相信你一定能克服。

　　（2）善于怀疑，世界上没有绝对正确的，总有错误的地方，具有叛逆心理，别人认为不可能发生的事，我却认为可能发生。别人认为是对的，我却认为不是对的。

　　（3） 打破砂锅问到底的精神，对于只出现过一次的bug，一定找出原因，不解决誓不罢休。

　　（4） 保持一个良好的心情，否则可能无法把测试作好。不要把生活中的不愉快的情绪带到工作中来

　　（5） 做测试时要细心，不是所有的bug都能很容易的找出，一定要细心才能找出这些bug。

　　（6） 灵活一些，聪明一点，多制造一些容易产生bug的例子。

　　（7） 在有条件的情况下，多和客户沟通，他们身上有你所需要的。

　　（8） 设身处地为客户着想，从他们的角度去测试系统。

　　（9） 不要让程序员，以“这种情况不可能发生”这句话说服你，相反，你应该去说服他，告诉他在客户心里，并不是这样的。

　　（10） 考虑问题要全面，结合客户的需求、业务的流程、和系统的构架，等多方面考虑问题。

　　（11）提出问题不要复杂化，这一点和前面的有点矛盾，如果你是一新手，暂时不要管这一点，因为最终将有你的小组成员讨论解决。

　　（12） 追求完美，对于新测试员来说，努力的追求完美，这对你很好，尽管有些事无法做到，但你应该去尝试。

　　（13）幽默感，能和开发小组很好的沟通是关键，试着给你的开发小组找一个“BUG杀手”，或对他们说“我简直不敢相信，你写的程序居然到现在没有找到BUG”。

　　（14）到此是不是对测试很有兴趣呢？不过我要告诉你，测试过程中有酸甜苦辣，其中的滋味只有你知道，也许你会感到枯燥，要学会放松自己，去溜冰或做你喜欢做的事，不过，别放弃，因为你的自信告诉过你“你会是很优秀的测试员”不是吗？

　　我们常见软件测试的技巧 ：

　　软件测试虽然辛苦，但是掌握了一定的技巧之后将使你事半功倍。

　　（1） 边界测试，测试用户输入框中的数值的最大数和最小数，以及为空时的情况。

　　（2） 非法测试，例如在输入数字的地方输入字母。

　　（3） 跟踪测试，跟踪一条数据的流程,保证数据的正确性。

　　（4） 在开始测试时应保证数据的正确性，然后在从系统中找出各种BUG。

　　（5） 接口测试，程序往往在接口的地方很容易发生错误，要在此模块测试勿掉以轻心。

　　（6）代码重用测试，在开发过程中有些模块功能几乎相同，程序员在重用代码时可能忘记在原有代码上修改或修改不全面，而造成的错误。

　　（7） 突发事件测试，服务器上可能发生意外情况的测试。

　　（8） 外界环境测试，有些系统在开发时依赖于另外一个系统,当另外一个系统发生错误时, 这个系统所受到的影响的情况。

　　（9）在程序员刚修复Bug之后的地方,再找一找，往往程序员只修复报告出来的缺陷而不去考虑别的功能在修改时可能会重新造成错误。

　　（10） 认真做好测试记录在做完一天的测试记录之后,第二天再根据第一天的测试记录重复测试你会发现有未修正的错误。

　　（11） 文字测试，如果在系统中有用词不当的地方，我想这是不应该的。

　　（12）系统兼容测试，例如有些程序在IE6能运行正常，到IE5下不能运行。有些程序在WIN2000下能运行，而到WIN98却不能运行。像一些很特别的用户去使用系统，你很有可能发现BUG。

　　（13） 用户的易用性测试，往往用户的需求是不断的变化的，而其中的一部份变化的原因，是有用户操作上不方便引起的。

　　软件测试是软件开发中的重中之重，没有一点可以马虎的，在项目管理过程，我强调的时是每个过程的每一个环节都要进行测试，保证系统在每个阶段可以控制。因为软件测试中考虑的问题基本上是项目管理中考虑的问题。

　　我认为在项目管理中考虑的一些问题应该是在软件测试时有些体现，体现的内容是软件测试的一些侧重点，具体说，软件测试是事务性的，而项目管理是策略性，一些策略性的东西必须在一些事务性的事务上来实现。

下面几点给做测试的朋友参考一下：（以下观点有不赞同之处）

1。钱肯定少过开发人员，除非你工作七，八年才能拿年薪10W以上，一般的软件测试工程师很难上6K以上，开发人员工作四，五年后拿7，8K是太多数的。

2。加班的现象可以说是很普遍，周一到周五随时加班是很正常的，周末肯定有一天要加班。

3。 不管怎么样努力和用什么测试效果的数据说明，领导还是不太重视测试部，领导认为我们测试的没有什么技术含量。但是我们已经在流程上改进很大，使用测试管理 工具和自动化测试工具来提高测试生产力等等，这些努力的结果好象只有我们的老大才得分比较高，我们下面的小兵就只有吃苦的份。

4。团队合作精神比较差，都是做技术的人的通病，以为你在一间公司呆久了，就很牛B一样，说话口气难于接受，好象现在公司就是他的一样。这个问题在几间公司里面的测试队伍中得到证实。在工作之余，很少团队一起聚餐或是出外游玩的机会，好象大家就知道上班---吃中午饭--上班--吃晚饭---加班---下班回家---睡觉的简单模式。

5。人际关系和沟通技能都很重要，这一点不用我多说，大家都知道的。

6。还有一点要提醒测试人员的是：做测试容易懒惰，因为重复性的工作比较多，然后在公司呆着好好的，什么都不想学和提高了，这样容易使你在软件的测试面比较狭窄了，其实你到其他的公司面试的时候，才发现自己很多不知道，不懂的。

7。我们做测试几年了，都不想老是停留在执行测试，写测试用例，设计测试计划，写测试脚本，评审开发/测试文档上，写缺陷报告，写测试报告，管理和维护测试工具。但是上面的几点工作后，我们软件测试人员还能做些什么？

 浅谈软件测试流程

一、概述

一般而言，软件测试从项目确立时就开始了，前后要经过以下一些主要环节：

需求分析→测试计划→测试设计→测试环境搭建→测试执行→测试记录→缺陷管理→软件评估→RTM.

在进行有关问题阐述前，我们先明确下分工，一般而言，需求分析、测试用例编写、测试环境搭建、测试执行等属于测试开发人员工作范畴，而测试执行以及缺陷提交等属于普通测试人员的工作范畴，测试负责人负责整个测试各个环节的跟踪、实施、管理等。

说明：

1．以上流程各环节并未包含软件测试过程的全部，如根据实际情况还可以实施一些测试计划评审、用例评审，测试培训等。在软件正式发行后，当遇到一些严重问题时，还需要进行一些后续维护测试等。

2． 以上各环节并不是独立没联系的，实际工作千变万化，各环节一些交织、重叠在所难免，比如编写测试用例的同时就可以进行测试环境的搭建工作，当然也可能由于 一些需求不清楚而重新进行需求分析等。这就和我们国家提出建设有中国特色的社会主义国家一样，只所以有中国特色，那是因为国情不一样。所以在实际测试过程 中也要做到具体问题具体分析，具体解决。

二、测试流程

需求分析

需求分析（Requirment Analyzing）应该说是软件测试的一个重要环节，测试开发人员对这一环节的理解程度如何将直接影响到接下来有关测试工作的开展。

可能有些人认为测试需求分析无关紧要，这种想法是很不对的。需求分析不但重要，而且至关重要！

一般而言，需求分析包括软件功能需求分析、测试环境需求分析、测试资源需求分析等。

其中最基本的是软件功能需求分析，测一款软件首先要知道软件能实现哪些功能以及是怎样实现的。比如一款Smartphone包括VoIP、Wi-Fi以及Bluetooth等功能。那我们就应该知道软件是怎样来实现这些功能的，为了实现这些功能需要哪些测试设备以及如何搭建相应测试环境等，否则测试就无从谈起！

既然谈了需求分析，那么我们根据什么来分析呢？总不能凭空设想吧。

总得说来，做测试需求分析的依据有软件需求文档、软件规格书以及开发人员的设计文档等，相信管理一些规范的公司在软件开发过程中都有这些文档。

测试计划

测试计划（Test Plan）一般由测试负责人来编写。

 测试计划的依据主要是项目开发计划和测试需求分析结果而制定。测试计划一般包括以下一些方面：

1． 测试背景

a. 软件项目介绍；

b. 项目涉及人员（如软硬件项目负责人等）介绍以及相应联系方式等。

2． 测试依据

a. 软件需求文档；

b. 软件规格书；

c. 软件设计文档；

d. 其他，如参考产品等。

3． 测试资源

a. 测试设备需求；

b. 测试人员需求；

c. 测试环境需求；

d. 其他。

4． 测试策略

a. 采取测试方法；

b. 搭建哪些测试环境；

c. 采取哪些测试工具以测试管理工具；

d. 对测试人员进行培训等。

5． 测试日程

a. 测试需求分析；

b. 测试用例编写；

c. 测试实施，根据项目计划，测试分成哪些测试阶段（如单元测试、集成测试、系统测试阶段，α、β测试阶段等），每个阶段的工作重点以及投入资源等。

 

6． 其他。

测试计划还要包括测试计划编写的日期、作者等信息，计划越详细越好了。

计划赶不上变化，一份计划做的再好，当实际实施的时候就会发现往往很难按照原有计划开展。如在软件开发过程中资源匮乏、人员流动等都会对测试造成一定的影响。所以，这些就要求测试负责人能够从宏观上来调控了。在变化面前能够做到应对自如、处乱不惊那是最好不过了。

测试设计

测试设计主要包括测试用例编写和测试场景设计两方面。

一份好的测试用例对测试有很好的指导作用，能够发现很多软件问题。关于测试用例编写，请参见前面写的《也谈测试用例》一文，里面有详细阐述。

测试场景设计主要也就是测试环境问题了。

测试自动化普遍存在的七个问题

　对测试工具能够发挥作用，大家都已经了解并认可了，但是很多引入自动化测试工具的软件公司并没有能够让测试自动化发挥应有的作用，其主要原因有以下几个方面：

1. 不正确的观念或不现实的期望

　 　没有建立一个正确的软件测试自动化的观念，或操之过急，或认为测试自动化可以代替手工测试，或认为测试自动化可以发现大量新缺陷，或不够重视而不愿在初 期投入比较大的开支等。多数情况下，对软件测试自动化存在过于乐观的态度、过高的期望，人们都期望通过这种测试自动化的方案能解决目前遇到的所有问题。而 同时测试工具的软件厂商自然会强调其工具的优势、有利的或成功的一面，可能对要取得这种成功所要做出持久不懈的努力和困难却只字不提。结果，最初的期望， 便得不到实现。

2．缺乏具有良好素质、经验的测试人才

　　有些软件公司舍得花几十万元去买测试工具软件，但缺乏具有良好素质、经验的测试人才。软件测试自动化并不是简简单单地使用测试工具，还需要有良好的测试流程、全面的测试用例（Test case）等来配合脚本的编写，这就要求测试人员不仅熟悉产品的特性和应用领域、熟悉测试流程，而且很好地掌握测试技术和编程技术。

3．测试工具本身的问题影响测试的质量

　　一般不会对自动测试脚本再做大规模的测试，所以自动测试脚本的质量往往依赖于TA工程师的经验和工作态度，如果自动测试工具不能提供一种机制来保证脚本的的质量，那将直接影响到测试结果的正确性。

　　通过自动测试工具测试的Test Case是不需要再进行手工测试的，将自动测试与手工测试有效的结合，并在最终的测试报告中也体现自动测试的结果，是比较正确的做法。

4．没有进行有效的、充分的培训

　 　人员和培训是相辅相成的，如果没有良好的、有效的、充分的培训，测试人员对测试工具了解缺乏深度和广度，从而导致其使用效率低下，应用结果不理想。这种 培训是一个长期的过程，不是通过一两次讲课的形式就能达到效果。而且，在实际的使用测试工具的过程中，测试工具的使用者可能还存在着这样那样的问题，这也 需要有专人负责解决，否则的话，会严重影响测试工具的使用积极性。

5. 没有考虑到公司的实际情况，盲目引入测试工具

　 　有一点很明确，不同的测试工具面向不同的测试目的、具有各自的特点和适用范围，所以不是任何一个优秀的测试工具都能适应不同公司的需求。某个公司怀着美 好的愿望花了不小的代价引入测试工具，半年一年以后，测试工具却成了摆设。究其原因，就是没有能够考虑公司的现实情况，不切实际地期望测试工具能够改变公 司的现状，从而导致了失败。

　　例如，国内多数软件公司是针对最终用户进行项目开发--工程性质的软件，而不是产品开发。项目开发周期短，不同的用户需求不一样，而且在整个开发过程中需求和用户界面变动较大，这种情况下就不适合引入黑盒测试软件，因为黑盒测试软件的基本原理是录制/回放（虽然通过修改，形成结构化测试脚本），对于不停变化的需求和界面，可能修改和录制脚本的工作量大大超过测试实施的工作量，运用测试工具不但不能减轻工作量，反而加重了测试人员的负担。这种情况下可以考虑引入白盒测试工具，以提升代码质量。

6. 没有形成一个良好的使用测试工具的环境

　　建立良好的测试工具应用环境，需要测试流程和管理机制做相适应的变化，也只有这样，测试工具才能真正发挥其作用。例如，对于基于 GUI 录制/回 放的自动测试来说，产品界面的改变对脚本的正常运行影响较大。再者，白盒测试工具的一般在单元测试阶段使用，而单元测试在多数公司是由开发人员自己完成， 如果没有流程来规范开发人员的行为，在项目进度压力比较大的情况下，开发人员很可能就会有意识地不使用测试工具，来逃避问题。所以，有必要将测试工具的使 用在开发和测试的流程中明确起来，如在项目各个里程碑所提交的文档中，必须包含某些测试工具生成的报告，如集成测试时DevPartner工具生成的测试覆盖率报告、Logiscope生成的代码质量报告等

7．其它技术问题和组织问题

　　软件测试自动化所需要的测试脚本其维护量很大，而且软件产品本身代码的改变也需要遵守一定的规则，从而保证良好的测试脚本使用重复性，也就是说测试自动化和软件产品本身不能分离。

　 　其次，提供软件测试工具的第三方厂家，对客户的应用缺乏足够理解，很难提供强有力的技术支持和具体问题的解决能力。也就是说，软件测试工具和被测试对象 —软件产品或系统的互操作性会存在或多或少问题，加之技术环境的不断变化，所有这些对测试自动化的应用推广和深入，都带来很大的影响。

　　还有安全性的错觉，如果软件测试工具没有发现被测软件的缺陷，并不能说明软件中不存在问题，可能测试工具本身不够全面的问题或测试的预期结果设置不对。