在每一个用例步骤中应该包含多少信息呢？
我更偏爱于取得系统用例并将其根据业务用例分类，并且同样通过一组步骤将大量的用户交互活动分类。该组步骤解释了该步骤的目的，并且可以在某些细节在实现过程中改变的情况下保持不变。这种方法使得文档更加易懂，它将系统用例和业务用例联系起来，并且如果产品执行变化时它允许用例可以被容易的修正。
例如，在上述系统用例中的简单的步骤“运行代码复审”中，向细心的读者传递了一个非常有价值的信息，包括：
代码复审被结合在IDE中。
代码复审必须在使用中，或者“运行”。
代码复审提供了一个关于违背某套有效性标准的问题清单。
某些问题可以被迅速的修正。
代码复审将获得迅速的修正。
确保有效的测试
一旦用例被适当的设置并且开发团队就他们所扮演的角色达成共识，这些用例就成为方案中其他部分的基础。实际上，这是最好的利用它们所提供功能的方法。
工程团队建造一个开发方案，其中至少要包括：一份将要被建造的组建的清单，以及每一个组建的时间期限。清楚的描绘主用例的特性需求和实际工作特性的组件必要性之间的关系是非常重要的。
识别这些核心组件并且定义它们的用例是非常关键的步骤，它使得应用程序功能性的早期测试变成可能。如果该核心组件能够在开发周期的初期被完成，那么测试人员就能够开始为基本的规则集合撰写测试脚本并且确认该工具功能的有效性。
在我们的例子中，系统用例“运行代码复审”使得测试人员能够为该核心功能制定能够测试计划，甚至可以在代码被编写出来之间就实现这一点。测试人员还可以为主流程和可选项目创建一套手工测试脚本。
测试类型
最简单的测试形式，同时也是非常有效的一种测试形式，就是聚集一大批受过良好训练的用户来针对该应用程序的各种不同特性来进行测试和演练，并且将测试结果（发现的问题和缺陷）报告给代码开发团队。这种确认形式很简单：拥有越多的用户，就会检查出更多的缺陷。不同的用户群将用不同的方式使用该工具并且进一步增加被检查出来的问题的数量。然而，有一些与此相关的问题。直到该软件为用户使用做好准备的那一刻之前，我们都有可能没有足够的时间来开展广泛的测试计划了。不同的用户可能使用不同的产品。更重要的是，完全依靠人工是非常昂贵而且非常不可靠的。
还有更多的事情需要考虑。如果没有一个清楚的测试计划，就不可能采取同样的测试方法来对不同版本的应用程序中的相同特性加以测试。如果没有测试工具的协助，对于每一次测试我们所采取的测试步骤将会大不相同。并且，我们将会疏漏一下很少用到的，但却是潜在的重要的情节。
手动测试和回归测试
手动测试 是指以确定一个特定的系统相应为目标的一套动作。手动测试的另外一种选择就是自动测试。两者都属于功能测试的类型.自动测试意味着您使用一个专门的工具或者一批脚本来对一套应用程序组件进行测试，记录应用程序的反应，将其与想定值进行比较，从而决定测试是否成功。所有这些工作都没有人工干涉。自动操作使得您可以一遍又一遍的重复同一项测试，具有人工永远无法达到的精确性。自动操作功能测试的例子包括IBM Rational Robot以及IBM Rational Functional Tester。
回归测试，用来衡量应用程序的质量，既可以手动处理也可以自动处理。您能够从自动功能性测试或者自动开发者测试（详见下文）中聚集一组回归测试组合工具。可靠的回归测试的关键因素就是景区的再现这些测试。因此，在被称作测试脚本的文档精确的定义测试步骤，并且在每一个回归测试中严格的按照这些步骤操作是非常必要的。在此之后，您就可以放心的使用这些测试结果，既不必担心有问题报告，也不必再去衡量其质量了。
测试的成功与否同您在制定测试计划、文档化手动测试和自动测试上所投入的时间长短是有着密切的联系的。下面是一些实现有效测试的具体的建议：
根据用例制定您的测试计划。首先开始测试主用例流程，然后扩展到可选流程。正如前面所描述的，关键是保持您的用例中的适当的粒度和模块性。
通过测试计划来组织您的手动测试，通过第一批测试就开始采用一种统一的方法记录和分析测试结果。重复的、统一的操作（即使是手动的）也将会提高您工作的质量。
自动测试首先具有相对简单可行的执行路径，但是每一次运行它都需要大量的入口数据。运用现成的数据池来完成测试脚本（例如，进行数据驱动测试）。
开发者测试
将用例转换为有效的测试通常会遇到一个大的障碍：代码底层中的一大块部分直到开发周期的后期才能够提供给功能测试。因此，如果一些组件在被组装进正在运行的应用程序之前就被测试将是一件好的事情。而这正是开发者测试所符合的。
开发者测试是一套关注于提高代码质量的活动，它经常被开发者使用。开发者测试包括两个主要方面：
自动化单元和组件测试。包括代码评审，单元或组件测试，以及代码覆盖分析。
手动测试和调试。包括运行跟踪，声明，内存泄漏检测和内存用法分析，性能评测，线程分析，等等。
自动批处理测试可以使用例如JUnit工具——一种集成在IBM Rational应用程序开发器里的代码复审工具，也可以使用IBM Rational PurifyPlus提供的附加的方法来确保高质量的软件。在开发环境下找到并且修改缺陷就意味着在后来会出现更少的功能性错误。并且可以节省出更多的时间来编写代码和引介更多的自动控制。另外，拥有可靠的可重复性的自动单元测试和代码复审，可以使您收集到关于代码质量的有价值的方案，获得前面所描述的一样的好处。
对于大多数组织，实现开发者测试的主要障碍就是对所需要工具的学习曲线。通常，个体的开发者测试工具注重于软件质量中某一个相对狭窄的方面。如果团队成员不具备自动开发者测试的经验，那么如何找到合适的工具和决定采用何种类型的测试就成为呈现在我们面前的巨大的挑战。因此，开发计划不应当仅仅将时间投入到开发和调试应用程序组件上，也应当将时间和资源投入到培训、设置、分析和报告有关执行自动开发测试方面。这一初期投资将会很快的带来回报，它将使得测试团队检测更少的功能性错误。它同样也会提高团队成员理解代码原理的水平。
下面是一些关于以开发者测试为开始的建议：
如果您即将进行单元测试，那么在运行单元测试的同时开始收集代码覆盖数据，从而对整套单元测试进行完全的评估。
如果您即将开发C++应用程序，那么请您运行关键用例，并且通过工具对动态内存分配进行分析。内存恶化的问题是本地C++应用程序的一个关键的方面，也是造成许多意想不到的和难于再现的缺陷的根源。
至少在每一个合成结构中的组件内收集执行的基线，并且随时监视执行的过程。
如果您即将开发一个Java/J2EE应用程序，那么请您在一组基本测试中监视内存使用情况和内存中的对象类型。
在开始时应用一把最重要的静态分析规则，将它们应用于每一个结构中，并且不断向您的代码底部添加更多的规则。这必将会减少运行结果中出现的错误。
开发者测试并不会取代功能回归测试，手动的或者自动的。它只是通过在开发环境中检测问题，从而在整体上提高了测试的效率，因为在这时修改起来相对更加容易。
积极测试和消极测试
积极的测试将关注点放在应用程序主流程的确认上，正如用例文档中所定义和区分出的优先次序那样。消极的测试则通常关注于那些应用程序性能极限的测试方面（例如，“破坏应用程序”）。
在我看来，一份好的测试计划应当明确的关注于确认用例路径，而不是包括极限测试。通常，您可以通过数据驱动测试来对极限进行评估，数据驱动测试应用不同的数据集来对某个单一的实例进行测试，这是为了确定应用程序对于特定问题和异常而不是标准的参数集的反应。
下面我来谈我的最后一项策略。
支持市场工作
在当今这个业务驱动的动态的环境中，充分理解软件市场的情况是项目成功的关键。实际上，一个组织对于市场的理解程度甚至比交流沟通、项目计划、质量以及测试更能影响它的成功。如果其产品未满足市场的需求或者定位于错误的消费群，那么即便是良好组织的、和谐的软件开发组织也会遭遇失败。
那么如何使得那些从事工程技术的人员同从事市场营销的人员来共同合作，从而提高产品取得成功的机会呢？下面就是一些建议。
驱动beta程序和消费者参考信息
对于软件团队来说，最有效的有助于营销一件新产品的方法就是从早期的客户那里获得积极的参考信息，并且通过他们这个组织的市场营销渠道来共享这些信息。不论您的营销人员具有多么熟练的技巧或者创造能力，他们都不可能在一夜之间收集到成功的经历。让消费者自己来熟悉新工具及其如何使用是需要一定的时间的。因此，为新项目制订计划应当将相当大量的时间和资源投入到早期的采用程序上。
在项目的开端阶段，应当安排由市场营销团队、一些有代表性的人员，以及一位来自于您的目标客户群的消费者共同参加的关于新产品特性及其他一些需求的讨论。同那些提出要在您的产品中增加需求的关键的消费者建立联系，拿出一份测试版本程序的计划和时限，并且确保该计划包括了用户提到的需求并将其作为目标。通过事先交流和沟通这些需求信息，有助于您为程序设定一个正确的期望值，并且提高产品同时厂合拍的机会。通常，消费者必须通过一系列合法性检查和许可之后才能提供出一些有助于您突出新的解决方案的优势的参考信息。
早期协作
还有一个好主意，那就是在项目中尽早开始同市场营销机构的合作，因为营销人员可以帮助您得到一些创建有效用例的必要信息。由于经常同那些对当前市场心中有数的分析师打交道，他们可以帮助您确定目标客户群和市场。同时，您为功能特性和产品发布确定目标所作的工作将产生出精心准备的文档，这些文档能够帮助营销机构较早的理解产品，并且使其能够描述和促进产品的正确性。关键词就是合作。
聚集一个合作的项目团队来帮助其中的每一位成员理解那些事情需要去完成是一项非常好的措施。除了上面所提到的收集市场信息之外，协同工作的团队还应当做下列事情：
认清关键的主办者并使他们在开发计划阶段能够聚在一起（复审目标，业务目标以及用例所描述的特定细节）。这些主办者可以是外部的投资者，潜在的消费者，或者甚至是您组织中的某一个团队。
获得那些关于客户支持的要求信息，包括他们的专业水平和进行培训的需要。
从销售团队那里获得渴望实现应用的日期，关键用户以及主要关注点等信息。
收集陈述和介绍的材料来介绍本组织的其他部分介绍给该项目，从而他们可以开始一同参加工作。协作的团队成员应当在整个项目周期中夜以继日的加速实现项目的目标、计划和活动，从而他们能够继续培养和教育感兴趣的参与者。
“谈论”市场营销
“谈论”市场营销就是指如何通过媒体传递技术性的功能。有时针对目标客户群的营销努力是非常技术性的，但是在更多的情况下，这样的努力由一些根本没有技术基础的业务决策者来执行。帮助您的营销机构将特性细节转换成有意思的信息以提供给一位非技术人员的顾客的最好的方法就是，充分理解该新产品所带来的好处和价值，并且准备好将其通俗的表达出来，例如以美元的数额。
准备好为下列问题提供清楚地答案：
“为什么这个新产品或者增强版本很重要？”
“它是如何在我们的业务策略中对关键的开端提供支持的？”
“谁将从这项新性能中获益？”
“该产品如何工作？”
根据我的经验，即使是最复杂的技水性解决方案都可以通过一种相对简单的方式来加以解释，这种方式概括了解决方案及其好处后面的动机。挑战在于如何找到一个使得您的用户中的大多数人都能够理解的模型。
总结
面对全球化所带来的复杂的业务和技术要求，当今的组织不得不关注非技术性的和技术性的资源，才能够创造出成功的产品并且在激烈的市场竞争中占有一席之地。尽管没有所谓的“银弹”来保护您的软件开发组织在项目开发期间免受可能出现的挑战，但是认清楚您的组织内部不同开发部门和功能之间同步的重要性，将会为您在今后的发展中所遇到的每一次挑战做出更好的准备。
文章来源于领测软件测试网 https://www.ltesting.net/
