对于所有团队来说,要测试的内容与测试内容是什么相反,这是一个重要问题。测试就结束了,选择如何确定测试代码库的不同部分的优先级可能很困难。
进行优先级排序的最佳方式取决于您的代码库和团队的目标。不过请务必注意,虽然编写大量可覆盖大量代码的小测试(例如单元测试,位于测试金字塔底部)只需很少的时间和带宽,但并不一定能降低项目的总体风险。
您可以根据应用、网站或库的主要用例来选择要先测试的内容。这可以通过对网站的关键部分(构成用户体验的基础组件)编写组件测试来实现。例如,如果某个网站允许用户上传和管理时序数据,则相应开发者应设想并测试用户执行这些任务的不同方式。
另一种确定优先级的方法涉及获得最多的信息。如果您的代码库中有“危险”、旧版或编写不当的承载负载部分,而您的团队中无人喜欢处理该部分,则围绕它构建测试以使其行为更加一致,这样您进一步忽略它或重构它来解决问题之前,这种做法非常有用。这就像是一栋已经遭到谴责,但仍然容纳着您的数据中心的建筑物的基架。
维度
我们引入了测试金字塔或其他测试形状的概念,但这些测试往往只呈现一个测试维度:从小范围、简单的单元测试到复杂、广泛的测试(单元测试、集成测试与端到端测试)。
不过,一些可能的测试类型列表非常长,并不代表复杂程度,而是代表了测试目标或技术。例如,冒烟测试是另外一种测试,其本身可以是单元测试、端到端测试或其他测试,但旨在让测试人员整体确信被测项目处于有效状态。对于一个小组件或整个网站,目视测试也非常有用。
您的代码库具有独特的要求。例如,在代码库中基于单个功能保持一致可能要重要得多,那就是编写不同类型的测试以确保其正常运行。需要测试的新功能很少是单个组件、函数或方法,其对项目的影响可能会以不同的规模分布。
您的测试优先顺序可能取决于您的业务需求。高技术系统可能需要进行复杂的单元测试,以确认独特算法能否正确执行,而高度交互的工具可能侧重于视觉测试或端到端测试,以确认复杂的触摸输入能否引发正确响应。
您的测试方法
请尝试专注于测试代码库的用例,而不考虑其规模。想象一下用户可能会如何使用项目的任何部分,这可能表示单个组件、较低级别的函数或高级的端到端用例。(如果您发现测试无法与被测代码完美互动,这也会揭示您的抽象中任何规模的缺陷。)
每个测试用例都有明确定义的目标非常重要。大型“全包型”测试可能非常繁琐,就像在非测试代码中一样。
关于测试驱动型开发的补充
测试驱动开发 (TDD) 是一种独特的测试方法(与扩缩或类型正交),因为它涉及编写至少一开始会失败的测试。这适用于手动测试和自动测试:您可以描述想要实现的目标,找出当前解决方案或代码中缺少的方面,然后将失败测试用作解决方案的指导。
当然,在开始构建之前,测试假设的应用或组件中的每个可能场景没有意义。TDD 有其专属之处,随着代码库变得越来越复杂,TDD 也非常有用。
在修复 bug 时,TDD 也是一种很好的做法。如果您能将 bug 的重现情况标准化,便可运用到最初会失败的自动化测试中。在您修复 bug 后,测试会通过,您无需手动确认即可确定修复是否成功。
不透明与透明框
这是指测试系统任何部分的方式。如果它是不透明的,那么您就无法看到内部(例如,在使用类的公共接口时),而不是检查其内部。
除非您有明确的理由,否则最好从不透明的框测试开始,以便根据组件的使用方式来设计测试,而不会因组件的内部运行方式而分心。如果您仅依赖于代码路径的“公共”接口(不一定对用户公开,但可能对代码的其他部分公开),您可以自由重构和改进该代码,因为您知道测试会检测出任何更改。
将“透明框”代码提高不透明的一种方法是引入可配置元素,例如代码依赖项的抽象或用于观察状态的回调,而不是引入该状态与其他系统紧密耦合。这会使代码的分离性更强,并允许您提供“测试”版本。或者,您也可以模拟您的代码与其他系统交互的位置。