概念:测试级别
测试在不同阶段或级别的工作中被应用于不同类型的目标。通常由那些在设计和执行测试方面最有技能的角色,在技术最适合每个级别的测试的位置上,来区分这些级别。确保在这些不同的工作间保持重点的平衡是很重要的。
开发人员测试 
开发人员测试表示最适合开发人员团队承担的测试设计和实施的某些方面。这与“独立测试”是对立的。在大多数情况下,最初在设计和实施测试的开发人员测试团队中发生测试执行,但是让开发人员按这样的方法创建他们的测试,使它们可供独立测试团队执行,这是一种很好的做法。
传统上认为开发人员测试主要与单元测试相关。虽然某些开发人员也执行可变级别的集成测试,但是这在很大程度上取决于文化和其它环境问题。我们建议:开发人员测试应该比单独测试独立单元有更大的覆盖面。
独立测试 
独立测试表示最适合独立于开发人员团队之外的某个人员执行的测试设计和实施。您可考虑这个特点是一个超集,它包含“独立验证和确认”。在大多数情况下,最初在设计和实施测试的独立测试团队中发生测试执行,但是独立的开发人员应创建他们的测试,使它们可供开发人员测试团队执行。关于独立测试在开发人员测试中的不同目标,Boris Beizer 给出了以下说明:
“独立测试的目的在于提供一个不同观点,进而提供不同的测试;此后在开发人员可能遇到的更为丰富[...]的环境中执行这些测试。”[BEI95]
独立涉众测试 
对独立测试的另一看法是:它代表了基于不同涉众的需求和关注的测试。因此,它被称为“涉众测试”。这是一个重要的特点,它有助于涵盖比传统上所考虑的更为广泛的涉众关注,在稍具总括意思的“客户”中扩充进技术支持人员、技术培训人员和销售人员等涉众,作为对客户和最终用户的补充。
作为最终的注释,RUP 中 XP 的客户测试概念与该独立测试分类相关。
单元测试 
单元测试着重于验证软件最小的可测试元素。通常,单元测试被应用于在实施模型中代表的组件,以验证控制流和数据流被覆盖并且它们在正常运行。实施者在开发单元时执行单元测试。在实施规程中描述单元测试的详细信息。
集成测试 
执行集成测试来确保:当实施模型中的组件结合以执行用例时,这些组件处于正常运作状态。测试目标是实施模块中的一个包或一组包。通常,被结合的包来自不同的开发组织。集成测试将揭示包接口规范中的不完整或错误。
在某些情况下,开发人员做出的假定是:其它团队(例如独立测试人员)将执行集成测试。这种情况将为软件项目带来风险,最终为软件质量带来风险,这是因为:
- 集成区域是软件故障的共同点。
- 独立测试人员通常使用黑匣技术执行集成测试,且集成测试一般涉及较大的软件组件。
更好的方法是:将集成测试作为开发人员和独立测试人员的共同责任,但是使每个团队的测试工作策略不至于有显著的重叠。重叠的确切本性根据单个项目的需求而定。我们建议您发展一种环境,在该环境下,开发人员和独立系统测试人员可共享单一的质量理念。关于其它信息,请参阅概念:开发人员测试。
系统测试 
传统情况下,在软件作为整体运行时执行系统测试。迭代的生命周期允许更早地执行系统测试(一旦实施了组成合理的用例行为子集,就执行系统测试)。通常,测试目标是系统的端到端的功能元素。
验收测试 
用户验收测试是部署软件前的最后一个测试行动。验收测试的目标在于验证软件已准备就绪,最终用户可使用该软件来执行特定功能和任务(构建软件正是为实现这些功能和任务)。关于其它信息,请参阅概念:验收测试。
验收测试存在其它观念,这些观念的一般特点是从一个组或团队到另一个组或团队的传递。例如,执行工作版本验收测试以接受某个新的软件工作版本从开发到独立测试的移交。
关于测试级别顺序和时间安排的注释 
传统情况下,认为单元测试是在作为测试第一阶段的迭代的早期实施的:在执行后续阶段之前所有的单元都需要通过测试。但是,在迭代的开发流程中,该方法作为一般规则是不合适的。更好的方法是:确定查找错误最有潜能的单元、集成和系统测试,然后基于最大风险和支持环境的结合,实施和执行这些测试。
|