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