第二章软件测试理论‘j技术基础 测试过程中,测试人员应当依据经验、常识等进行判断,某个和测试用例描 述的期望结果不完全一致的实际结果应判定为通过还是失败。 在测试执行过程中,测试人员对于测试用例的态度应尊重但不迷信。虽 然测试用例是经过仔细编写和详细评审的,但错误依旧难免。因此,作为测 试执行者,不应进行机械测试,而应多动脑,能够站在用户、设计人员的角 度看问题,这样不但可以发现一些测试用例中可能存在的问题,还能发现更 多测试用例中没有涵盖到的缺陷。 2.2功能测试测试用例设计与编写原则 上一节详述了基于测试用例的功能测试流程。本节将从更为细节的方面—— 编写功能测试的测试用例应当遵循的原则方面进行阐述。 测试种类繁多,针对不同类型的测试,测试用例的设计方式完全不同。如: 性能测试的测试用例中,需设计大量的测试运行场景,准备相应的性能指标表格 供测试人员填写,并进行数据分析。 本章着重探讨的是功能测试中使用的测试用例,为避免混淆,方便叙述,后 续未说明的测试用例均指功能测试的测试用例,有特殊需要之处将进行特别说 2.2.1测试用例设计原则如前文所述,测试用例是测试人员执行测试时的重要参照标准。因此,测试 用例必需使测试人员能够明确理解,并能够依据测试用例的描述执行测试。为此, 一个设计良好的测试用例应当包括如下几个关键字段: 1.用例编号(TestCaseIndex) 一个软件项目可能拥有数量庞大的测试用例。应根据项目设计一个良好 的用例编号体系,如:PROJECT—MODULE—FUNCTION—INDEX,那么通过用例 编号,便可对测试用例进行快速定位,查询时事半功倍。 2.用例名称(TestCaseName) 用例名称的编写应使用最精简的文字,描绘出用例的全貌。编写良好的 用例名称如同书籍的目录,能够帮助阅读者整理思路,定位用例。 3.前置条件(Precondition) 复杂T作流软件自动化测试方法的研究 第一二章软件测试理论与技术基础 前置条件指测试执行者在执行测试用例的操作步骤前,必须完成的准备 工作。常见的前置条件有:系统的配置、权限的设置、数据的准备、前置工 序的执行等。 4.测试步骤(TestStep) 测试用例中,每个操作均可设计为一个步骤。一个测试用例由一个或多 个测试步骤组成。常见可将测试步骤分为正常步骤和容错步骤。 正常步骤指普通用户为了实现正常功能,进行的普遍的、正确的、系统 期待的操作。正常步骤描述的操作通常在需求文档中会有明确的说明,也是 程序需要实现的主要功能。 容错步骤指用户有意或无意进行的一些错误的、甚至于有破坏性的操作。 对此类错误操作,系统应有足够的容忍性,进行一些友好的提示、阻止或处 理,而不是产生异常。 需求文档中,通常会对正常步骤进行明确定义。因此,正常步骤是严谨 的,甚至是唯一的,编写者的发挥空间非常狭小。容错流程恰恰相反。一个 思维活跃、经验丰富的测试人员在编写容错步骤时,能够考虑到各类不同的 容错步骤,其编写出的测试用例也是全面、广泛而又犀利的。容错流程的编 写深度与广度能够很好的反映编写者的技术实力。 综上,一个编写良好的测试用例中应该包括两部分内容:描述准确的正 常步骤,以及广泛深入的容错步骤。 5.步骤描述(Description) 步骤描述是测试步骤的主体,是测试人员执行测试时的重要阅读对象。 因此,测试步骤必须表述详细,描述清晰,用语必须规范、严谨而又客观。 最基本的要求是能够使其他人理解,并能J下确的执行编写者期望的操作。 6.期望结果(Expected Results) 期望结果是执行测试时,测试者所进行比对的标尺,是一个测试步骤是 否通过的标准答案。期望结果必须要保证其正确性。错误的期望结果带来的 后果是严重的,不在此赘述。 7.实际结果(ActualResults) 实际结果供测试人员在运行测试时填写观察到的实际结果。填写的内容 同样需做到规范、严谨与客观。 8.测试结论(TestResult) 与实际结果类似,测试结论供测试人员运行测试时填写。 若实际结果与期望结果两者一致,或虽然不一致,但在可接受范围内, 则可以认为该步骤是通过的,测试结论应置为Passed;若两者不一致,且无 法接受,则应将结果置为Failed。 11 复杂丁作流软件自动化测试方法的研究 第二章软件测试理论‘j技术基础 综上,一份基本的测试用例模板可如表2.1所示进行设计: 用例编号用例名称 ‘步骤编号}正常步骤 !正常步骤 ’容错步骤容错步骤 期望结果实际结果 测试结论 .测试用例编写原则上一节探讨了测试用例的字段设计,本节将继续深入阐述几个测试用例编写 中需要遵循的原则,总结为如下五点: .正确性 正确性是测试用例编写中的最基本原则。测试执行时,测试者的操作是 基于测试用例的。因此,一旦测试用例存在错误,将对测试者产生误导,影 响测试判断的准确性,从而产生缺陷误报或缺陷遗漏。 2.可读性 前文对于这点已进行较为详细的阐述。由于测试用例面对的读者众多, 因此,一个优秀的测试用例的最基本要求是能够让他人理解,不会因为表述 上的问题产生歧义。 3.完整性 完整性是对正确性的补充。完整性要求测试用例能够覆盖到整个软件项 目的每个模块、每个功能、每个细节。完整性缺失的测试用例,后果或比缺 复杂1二作流软件自动化测试方法的研究 第-二章软件测试理论‘j技术基础 失正确性的测试用例更为严重。正确性的缺失影响的通常是一个功能点,而 完整性的缺失则会影响整个模块。 4.可执行性 可执行性是指用户能够按照测试用例中的测试步骤描述,进行测试的执 行。为此,步骤描述必须清晰完整,测试用例的拆分设计也必须思路清晰, 结构合理。 5.一致性 一致性指依据测试用例的描述执行测试时,操作与产出结果应是一致的。 测试用例应减少操作者的主观性,增加操作的确定性。这样才能让功能测试 的结果更为客观,让后续的回归测试结果更为精确。避免因为测试者的变更, 导致测试结果的改变。 一个设计良好的测试用例应当符合以上五点。前两点更多针对编写者的编写 技术与细心程度,而后三点则更多与用例的设计方法有关,因此,后文对测试用 例设计方法的论述中,将着重以后三点作为评定标准,比较设计方法的优劣。 2.2.3测试用例的常见编写方法 理论上,黑盒测试只有采用穷举输入测试——把所有可能的输入都作为测试 情况考虑,才能查出程序中所有的错误。事实上,测试情况有无穷多个,不仅要 测试所有的合法输入,还要对那些不合法但有可能的输入进行测试,穷举测试是 不可能的。因此,必须引入一些测试用例编写技术,以减少用例的重复性、冗余 性,减少用例数量,从而进行有针对性的测试。 常见的用测试用例设计方法包括等价类划分法、边界值分析法、错误推测法、 因果图法、判断表驱动法、正交试验设计法等。 等价类划分法将程序的输入域划分成若干部分,并从每个部分中选取少数具 有代表性的数据作为测试用例。每一类的代表性数据在测试中的作用等价于这一 类中的其他值,比较常见的等价类划分法可以将测试用例划分为有效等价与无效 等价类。 边界值分析法是通过选择等价类边界值进行测试用例编写的方法。边界值分析法不仅应重视输入条件的边界,也必须考虑输出域边界。 错误推测设计方法是基于经验和直觉推测程序中所有的可能存在的多种错 误,从而有针对性地设计测试用例。此类设计方法比较依赖于设计者自身的经验, 更多的用于容错流程的设计。 13 复杂工作流软件自动化测试方法的研究 第二章软件测试理论与技术基础 因果图方法是从自然语言书写的程序规格说明的描述中找出因(输入条件) 和果(输出或程序状态的改变),并使用状态、约束等约定记号与方法,将各个 因果之间的关系使用图案来进行表现。 判定表可通过因果图来进行转换。转换的具体方法较为复杂。基本思路是从 因果图中的“果"开始,逐层回溯,直到能够完全覆盖完图中的逻辑。 正交试验设计法是使用已经编写完毕的正交表格来安排试验,并进行数据分 析的一种方法,目的是用最少的测试用例达到最高的测试覆盖率。 测试用例的设计方法多种多样,在实际项目中,一定需要结合不同的项目、 不同的情景来进行相应的测试用例设计。后文将结合这些常见技术,针对基于复 杂工作流的软件项目进行讨论,并提出最终的编写方案。 2.3自动化测试与自动化测试工具 2.3.1自动化测试 在流程性的测试中有相当多的机械劳动。如流程审批类的工作,测试者需要 不断切换用户登录,并进行审批。 针对此类重复度高、机械性的测试工作,可引入自动化测试。自动化测试可 以代替人工测试中机械、重复的部分,能够让人参与到更多需要智慧、需要灵活 应变的测试活动中。 自动化测试与人工测试是互补的——由人T_N试提供深度,由自动化测试提 供广度,相辅相成。由于基于工作流的软件非常需要广度支持,且这类流程往往 相对机械化,因此,引入自动化测试的概念是合理的。 2.3.2 自动化测试工具介绍与比较 自动化测试工具有很多,常见的列举如表2.2所示。 表2-2目前常见的自动化测试工具 Winrunner Quicktestpro Xrunner 14 针对本文探讨的软件自动化测试项目,挑选工具的重要评判标准有如下几 1.工具成熟性 15 复杂T作流软件自动化测试方法的研究 第二章软件测试理论‘j技术基础 成熟性指工具是否有着足够广泛的使用度,是否经历过足够的时间考验, 是否经过足够实践的检验。 由于WOA软件自动化测试项目并非一个短期的、试验性的项目,而是一 个需要长期进行并推广的项目。因此,冷门或是新颖的工具并不合适此项目。 此类工具的稳定性以及未来的发展性没有保障。对于长期的软件自动化测试 项目,风险过大。 2.资料全面性 由于在软件自动化测试项目的进行过程中,必然会遇到各类问题。若工 具的资料不够全面,没有足够好的产品服务,没有强大的社区交互支持,那么,每次问题的解决过程都将变得非常艰苦,容易造成时间的大量浪费。项 目进度难以评估,成本难以控制。 3.工具对象识别能力 虽然自动化工具未必是基于GUl(GraphicUser'sInterface,用户图形界面) 进行的,但基于GUI进行的自动化测试有其明显的好处——能够更好的模拟 真实的用户操作。不但可以测试到底层的问题,还能测到表层问题,如页面 的JS错误等。 因此,一个自动化测试工具的识别对象能力非常重要。一个优秀的自动 化测试工具应当拥有良好的控件识别机制,并有快速准确的识别能力。