技术开发 频道

开源软件测试模型

    5.2 开发准则

    l 可支持性

    产品技术支持工作的经济性如何?

    l 可测试性

    产品测试工作的有效性如何?

    l 可维护性

    产品构建、纠错或功能增强的经济性如何?

    l 可移植性

    移植或在其他环境下重用产品相关技术的经济性如何?

    l 可定域性

    以其他语言发布产品的经济性如何?

    六、测试技术选择

    需求:包括产品元素、质量准则、测试环境和参考资料,从总体上表达了受益人的愿望以及各种资源限制。完整需求的获得决非易事,并随着受益人经验的增加或环境的改变而处于连续变化当中。参考资料是任何可用作需求来源的文档或实体,包括显式参考(由受益人明确指定)和隐式参考(任何其他未指定的有用资料)。

    定义测试预期:测试预期是用于判定一个测试通过与否的策略,测试的主要任务之一就是根据产品真实需求来确定测试预期,受到测试目标的影响。

    定制测试模型:根据项目特点构造一个测试模型——描述将采用何种测试方法,以及该方法相配合的测试“覆盖”内容。比如:采用基于风险的测试方法时,同时应制定相应的风险领域列表。在后面罗列一些通用测试技术以供选择使用。

    选择覆盖范围:确定产品的哪些部分必须被测试,哪些可暂不考虑。

    配置系统:为测试工作准备产品和平台,确保系统处于开始测试的正确状态。

    操作系统: 为系统提供必需的输入和控制以执行测试,对于某些测试类型可能需要特殊工具支持。

    观察系统:监控系统操作过程中的输出或任何其他相关结果。对于哪些隐含变量或微妙结果的观察可能需要特殊工具支持。

    评估结果:利用测试预期来评估测试结果,需要时执行附加的测试以验证评估。及时反馈评估结果给开发人员,必要时应调整测试计划。

    附录:通用测试技术

    每种测试技术是一种创建测试的方式,其种类难以胜数。以下给出一些简单、实用的通用测试技术,每种技术既可以通过所谓“快速但不洁(quick and dirty)”的方式执行,也可以更为正式地执行,还可以相互结合(比如基于风险的回归测试等)。

    域测试——依据等价类和边界值对产品不同域测试

    1. 确定要测试的域;

    2. 分析每个域的限制和特性;

    3. 确定要测试的域组合;

    4. 应用所选择的测试策略。

    例如,穷尽值,典型值,边界值,随机值,非法值。

    容量测试——在“超负荷”状态下使用系统

    1. 选择要“超负荷”测试的条目和功能;

    2. 确定与其相关的数据和平台元素;

    3. 选择或生成用来运行测试的具有挑战性的数据和平台配置。

    例如,很大或复杂的数据结构,高负载,长时间运行,大量测试用例,低内存条件

    线索测试——按照某种逻辑顺序对系统进行测试

    1. 定义测试程序或高层测试用例,将多个测试按照一个接一个的方式结合在一起;

    2. 不要在测试之间重置系统;

    3. 将时间因素考虑进来;

    4. 与其它技术结合。

    例如,用户线索,容量线索,基于风险的线索。典型情况下,线索测试通过“场景”来定义。所谓“场景”,就是一步一步的详细指令序列,它描述了哪些数据要输入哪些字段,以及要按下什么按钮等。一般应包含:(1)该场景使用的数据描述(2)描述该场景的前提:那些动作必须在之前执行;(3)动作序列描述:如,按下“确认”按钮,在用户号字段内输入456等;(4)预期结果描述;(5)与某功能有关的场景可能要跨越“几天”时间:数据进入系统后可能今天后结果才有效,后续动作也才能执行。“场景”应当覆盖系统所有应完成的功能。

    用户测试——模拟真实用户的操作方式、数据

    1. 确定用户分类;

    2. 确定每一类用户要做什么、如何做以及怎样评价;

    3. 获得真实的用户数据,或让真实用户进行测试;

    4. 否则,系统化地模拟真实用户的行为(注意:不要误以为自己就是真实用户)。

    回归测试——对于变更及影响部分的重复测试

    1. 确定哪些产品元素发生变更;

    2. 确定哪些元素受到这些变更的影响;

    3. 选择测试内容,比如最近修复的错误,以前修复的错误,新代码,敏感代码,或所有代码。

    基于风险的测试——依据产品潜在风险的高低确定测试重点,首先发现重大错误

    1. 分析测试环境、产品元素和质量准则以确定各种风险源;

    2. 将测试集中在具有潜在高风险的领域;

    3. 利用测试结果来精练风险分析结果;

    4. 注意不要完全忽视低风险领域——因为风险分析结果可能是错误的。

    声明测试——验证每一个与产品有关的声明

    1. 确定那些包括产品声明(显式的和隐式的)的参考资料;

    2. 分析每一个声明,澄清模糊的声明;

    3. 验证每个声明;

    4. 如果是利用显式的规格说明进行测试,保证它与产品本身保持一致。

    探索式测试——在不断探索的过程中(迭代和并发行为)进行测试设计和执行

    1. 产品探索,发现和记录产品目标、功能、处理的数据类型和潜在不稳定域;

    2. 测试设计,确定产品操作、观察和评估的策略;

    3. 测试执行,操作产品,观察结果,并使用这些信息形成产品应如何工作的假设;

    4. 启发式规则,利用各种指导性原则帮助决定应做什么;

    5. 可评审的结果,探索式测试是一个结果导向的过程,应确保测试结果可被评审以资证明。

0
相关文章