- 测试反模式:有效规避常见的92种测试陷阱
- (美)Donald G.Firesmith
- 2813字
- 2021-04-03 21:47:10
前言
市面上有许多关于系统和软件测试的好书,大多数测试人员的书架上可能已经有好几本了。似乎讲测试如何做的书籍并不少见,而且这些书中全是针对如何测试软件依赖系统(software-reliant system)的优秀建议。包括测试计划、许多不同类型的测试、测试如何融入开发周期、测试用例设计(包括测试用例选择和测试完成标准)、测试工具和环境,以及其他许多有趣有用的话题。
我们花了大量的时间和精力做测试,虽然如此,我们交付的系统即使没有上百个遗留的缺陷,也会有几十个。除了作为测试人员,我也参与过众多的内部以及独立的系统和软件开发项目的技术评估(ITA),包括测试组织和项目。在每一种情况下,无论我是测试团队还是评估团队的一员,我总是会观察到一些明显的测试问题。更具体地讲,我观察到测试人员和开发人员一遍又一遍地掉进同样的陷阱中。显然,关于如何做的书籍虽然非常有用,但不足以使测试变得高效或有效。
我因忍受和观察这些经常发生的测试陷阱而经历的无奈导致了这本书的出现。如果许多讲“如何做”的书籍是不够的,那么显然现在是时候尝试不同的方式:一本“如何不做”的书。
你可以将这本书看成测试反模式的目录和信息库:要避免的陷阱;如何减少其负面后果;如果不能避免它们,那么在陷入的时候如何逃脱。就像博物学家的野生动物手册,让本书成为你对进入充满了测试错误的危险世界并了解它的居民(人们已经发现的许多弄糟测试的创造性的方式)的指南。
范围
本书的讨论范围是测试,这是几种常用于确认系统满足其利益相关者的需要和验证该系统符合其指定需求的方法之一。虽然存在其他方法(例如,审查、演示、评审、分析、模拟、重用和认证),并且可以用类似的方法来记录,但它们超出了本书的讨论范围。
本书主要讨论软件依赖系统的测试,这个系统往往是子系统、硬件、软件、数据、设备、材料和人员的异构聚合。这里的测试包括纯软件应用程序和组件的测试。为简单起见,我将使用术语系统来表示异构系统、软件应用程序,以及它们的架构、设计和实施组成部分。
本书中的陷阱主要适用于生产重要的系统和软件应用的大中型项目,至少需要准严格的测试程序和过程。陷阱不一定适用于生产相对不重要的系统或软件程序的非常小而简单的项目:不是商业性、任务性、安全性或保密安全性上关键的;将仅用于内部利益相关者和开发人员密切合作;将使用一次并不再维护;将不会被投入运行的原型。这种系统通常可以用非常不正式和松散的方式进行充分的测试。一些陷阱只适用于测试有显著硬件的系统,因此这些陷阱不(主要)适用于测试纯软件应用程序。
目标读者
本书主要写给测试人员和他们的技术经理,旨在帮助大家识别并避免潜在的测试相关的陷阱。
本书也写给所有系统开发和维护的利益相关者,他们需要更好地理解在准备测试和实际测试过程中什么可能会出错。这些利益相关者包括客户和用户代表、项目经理和技术领导、需求工程师、架构人员和设计人员、实施人员、维护人员和专业工程师(如配置管理人员、质量工程师、可靠性工程师和人员因素工程师)。
最后,本书也是为测试课题专家写的,无论是学者还是顾问,只要他们对“测试中什么会出错”有更有条理、更全面了解的需要。
如何使用本书及其内容
本书的主要目的是提供你所需要的信息,以:
·避免陷入任何经常发生的测试陷阱。
·当已经陷入了一个或多个测试陷阱时,能够识别。
·从陷阱中逃脱,同时尽量减少由此产生的负面后果。
本书提供了经常发生的测试陷阱的详细信息,并且它可以用于:
·提高对于经常发生的测试陷阱的理解和沟通
·作为测试人员和测试利益相关者的培训材料
·以下情况时,用作清单[1]:
·制定和评审组织或项目的测试过程或战略
·制定和评审测试计划文档,如:
·测试和评估总计划(TEMP)、系统测试计划(STP)或测试策略文件(TSD)
·计划文档(如系统工程管理计划(SEMP)和系统开发计划(SDP))的测试部分
·测试计划介绍(例如用于培训和状态报告)
·测试维基、SharePoint网站和应用程序生命周期管理(ALM)工具库
·评估承包商方案的测试相关的部分
·评估测试计划文档、测试说明和测试结果(质量控制)
·评估实际执行的测试过程(质量保证)[2]
·识别测试风险和适当的风险缓解方法
·将测试陷阱进行分类,用于数据收集、分析和报告
·无论是在项目过程中,还是在项目结尾,如项目回顾中,帮助识别测试领域潜在需要的改进
本书结构
本书结构如下。
·前言
·前言首先简要介绍了这本书,然后描述了本书的讨论范围和目标读者。接着,就如何最佳地使用这里提供的信息提出了简单的建议。最后,感谢本书的许多技术评审人员,没有他们,这本书不会有现在的一半好。
·第1章
·第1章定义这本书中最重要的概念:测试、缺陷和测试陷阱。其中介绍了系统工程V模型,用来解释不同类型的测试如何与项目的工作产品相关联。强调了为什么测试是非常重要的,同时也解释了为什么测试有一些重大的局限性。最后,介绍了对测试陷阱如何进行分类和记录,以便能更容易地找到并理解它们。
·第2章
·第2章识别并总结了92种经常发生的测试陷阱。第2章的目的是为每一种陷阱提供非常概要的简介,使读者能够轻松寻找并识别出与他们的情况相关的陷阱。
·第3章
·第3章提供了经常发生的测试陷阱的详细描述。具体而言,每种陷阱记录成:名字、描述、可能出现之处、典型症状、潜在的负面后果、潜在原因和相关的规避陷阱或限制后果的建议。第3章的主要目的是用做一个方便的参考,一旦发现相关的陷阱,通过内容部分或第2章确定。因此,我建议读者像阅读模式书籍中的模式一样阅读本章:通过快速浏览获得对陷阱的基本了解,然后根据需要细读单个陷阱的详细描述。
·第4章
·第4章是最后一章,提供了陷阱的整体总结,然后简单地介绍了未来可能使测试陷阱分类更加有用的研究。
·附录
·附录从术语表和缩略语列表开始。为了使单个陷阱的描述相对较短(特别是对于有经验的测试人员,他们会识别出大部分的陷阱),附录C为那些可能希望额外信息的人提供了大量注释。注释在文中用方括号内的数字[#]进行标注。随后是本书相对较短的参考文献。最后的附录是可以用于计划测试和评估测试项目及组织的检查清单。
致谢
我要感谢350多位测试人员、测试课题专家(SME)和自愿审阅本书各个版本草稿的来自46个国家的学者们。我特别要感谢以下在审阅手稿的不同草稿中多次提出出色的审阅意见和建议的个人:
虽然每位审稿人的意见和建议中的绝大多数都以这样或那样的形式融入了本书中,但这并不意味着每位审稿人一定同意书中的所有内容。此外,我理所当然地会为从勤奋的审稿人身边溜过并最后进入本书的任何错误负责。
我要感谢John Foreman,他是SEI研究员和管理团队成员,提供给我完成稿件所需的资金和时间。
最后,我要感谢Addison-Wesley出版社的策划和制作团队对于出版本书的大力支持。特别值得一提的是Bernard Goodwin(我的组稿编辑)和Vicki Rowland(她修改手稿并对内容和格式创建了非常高的一致性)。他们与我就本书的封面和内容有多轮密切合作,从而使得我们非常愉快地完成了这本书的出版。
[1] 注释用方括号标注([#]),在附录C中解释。