选择是适当的技术来实施测试。对于每项想要进行的测试,请考虑实施至少一个测试脚本。在某些情况下,给定测试的实施将跨越多个测试脚本。在其他情况下,单个测试脚本就能为多个测试提供实施。
实施测试的典型方法包括:以要遵循的脚本的形式编写一份文本描述(针对手动测试),以及基于脚本的编程语言的编程、捕获记录或生成(针对自动测试)。以下部分中将讨论各种方法。
对于大多数方法,我们建议您使用以下各种技术的混合,这样将能获得更有用的结果。 尽管您无需使用全部技术,但也不应限制自己只使用一种技术。
子主题:
许多测试最好手动进行,您应避免掉入尝试不适当地自动执行测试的陷阱。
可用性测试就是这样一个领域,在其中的许多情况下,手动测试是优于自动测试的解决方案。另外,需要验证软件系统的物理输出的精确性和质量的测试通常需要手动验证。作为一般的渐进做法,建议您开始特定目标测试项的第一批测试时,使用手动实施;此做法
使得测试员能了解目标项,能适应它的意外行为,并能应用人类的判断来确定接下来要执行的相应操作。
有时候,手动进行的测试将在随后自动执行并重复使用,以作为回归测试策略的一部分。
不过,请注意,对于可以通过其他方式手动进行的测试,没有必要也不值得自动执行每项这样的测试(甚至这样做也是不可能的)。自动化的确具有某些优势,例如测试执行的速度和精确性,详细测试结果的可视性和条理性,在创建和维护复杂测试方面也更有效率,但就像所有有用的工具一样,它不是能够满足您所有需求的解决方案。
自动化会带来一些劣势:在测试执行期间会缺少基本的人类判断和推理。当前可用的自动化解决方案完全没有人类所拥有的认知能力,甚至可以论证它们以后也不太可能拥有此能力。在手动测试的实施期间,可将人类推理应用到系统对激励的观察到的响应。当前自动化的测试技术及其支持工具通常具有有限的关注某些系统行为的实施的能力,并具有最基本的通过演绎推理来推断可能的问题的能力。
可以证明,大多数使用自动测试的测试员实行的方法选择为:在其最纯的形式中,此实践是以与软件编程相同的方式执行,并使用与软件编程相同的一般原则。这样,用于软件编程的大多数方法和工具对于自动测试编程通常都是可接受和有用的。
通过使用标准的软件开发环境(例如 Microsoft Visual Studio 或 IBM Visual Age)或专门的自动测试开发环境(例如随 Rational Robot 提供的
IDE),测试员可自由地控制开发环境的特性和功能,以达到最好效果。
编程自动测试的消极面与编程本身作为一般技术消极面有关。为使编程生效,必须对相应的涉及考虑某个注意事项:否则,实施将可能失败。如果随着时间的推移,开发的软件可能由不同的人员进行修改(这也是通常的情况),那么在程序开发中应考虑采用常见的风格和形式,并确保其正确使用。可以论证,与此技术的误用相关的两个最重要方面为:
首先,存在这样的风险,即测试员将全神贯注于编程环境的特性中,耗费过多时间精雕细琢优美和精致的问题解决方法,而实际上这些方案可以通过更简单的方法完成。其结果是,测试员浪费宝贵的时间于本质上属于编程的任务,这对测试和评估目标测试项实际耗费的时间不利。避免犯此毛病需要训练和经验。
其次,存在这样的风险,用来实施测试的程序代码其自身就含有由于人员错误或倏忽而引进的错误。其中一些这样的错误将很容易在实施自动测试的天然过程中进行调试和纠正,而其他一些则不能。就像在目标测试项中错误可能难以检测一样,在自动测试软件中也可能同样难以检测到错误。而且,在用在自动测试实施中的算法是基于软件实施自身使用的有缺陷的算法的场合,可能会引进错误。
这会导致错误无法检测,而隐藏在自动测试的虚假安全背后,而测试表面上是成功执行的。只要可能,请在自动测试中使用各种不同的算法,以降低此风险。
有许多测试自动化工具提供记录或捕获人与软件应用程序的交互,并生成基本的测试脚本。对于此,有许多不同的工具解决方案。大多数工具生成以某种形式的高级的通常可编辑的编程语言实施的测试脚本。最常见的设计工作在以下方式之一:
-
基于拦截从客户端硬件外围输入设备(鼠标、键盘等等)发送到客户端操作系统的输入,捕获与客户端应用程序 UI 的交互。在一些解决方案中,这是通过拦截在操作系统和设备驱动程序之间交换的高级消息而完成的,这些消息以略具有含义的方式描述交互;在其他解决方案中,这是通过捕获低级消息而完成的,通常是基于鼠标坐标或按键弹起和按键下压事件之类基于时间的运动的级别。
-
拦截在客户端应用程序和一个或多个服务器应用程序之间跨网络发送和接收的消息。这些消息的成功解释通常依赖于使用标准和公认的消息传递协议,例如 HTTP、SQL 等等。一些工具还允许捕获“基本”通信协议,例如 TCP/IP,但处理这种性质的测试脚本可能会更复杂。
尽管这些技术通常对于被纳入自动测试方法的一部分是有用的,一些专业人员却感到这些技术具有局限性。其中一个主要问题是,一些工具只是捕获应用程序交互,并不执行任何其他任务。如果不在后续的脚本执行期间另外包含捕获和比较系统状态的观察点,那么基本
测试脚本不能视为具有完整形式的测试。如果情况如此,则初始记录随后将需要用其他定制程序代码进行补充,以在测试脚本内实施观察点。
多名作者已出版了关于此问题,以及其他与使用测试过程记录或捕获作为自动测试技术相关的问题的书籍和论文。要获得对这些问题的更深入理解,我们建议您查看由以下作者完成的工作(可在因特网上获取):James Bach、Cem Kaner、Brian Marick 和 Bret Pettichord,以及 Lessons Learned in Software
Testing [KAN01]一书中的相关内容。
一些更复杂的自动测试软件使得能基于生成算法实际生成测试的各个侧重面,或者是过程侧重面,或者是测试脚本的测试数据侧重面。此类自动化可以在测试工作中充当有用的部分,但其自身不应视为一个完整的方法。Rational TestFactory
工具和 Rational TestManager 数据池生成特性是此类技术的实施示例。
|