数据库和数据库进程应作为独立的子系统测试。这种测试应不使用测试目标的用户界面作为数据界面而测试该子系统。需要执行对数据库管理系统(DBMS)的深入研究,以确定可能存在的支持下表中确定的测试的工具和技术。
技术目标:
|
试验独立于用户界面的数据库访问方法和进程,这样您可以观测和记录不正确运转的目标行为或数据损坏。
|
技术:
|
调用每个数据库访问方法和进程,通过有效和无效的数据或数据请求为每一个设置种子。
检查数据库以确保数据已经像预想的那样填充,并且所有数据库事件已正确发生,或复审返回的数据以确保为正确的原因而检索到正确的数据。
|
预测:
|
概述一项或多项可以由该技术用于精确观察测试结果的策略。该预测将以下两者的元素结合在一起:一、可以用于观察的方法;二、表示可能成功或失败的特定结果的特征。理想的情况下,预测将是自我验证的,允许自动化测试对测试通过或失败做出初始评估,但是,要注意降低在自动化结果确定中内在的风险。
|
所需的工具:
|
该技术需要以下工具:
测试脚本自动化工具
基本配置映像程序和恢复程序
备份和恢复工具
安装监视工具(注册表、硬盘、CPU、内存等)
数据库 SQL 实用程序和工具
数据生成工具
|
成功标准:
|
该技术支持所有关键数据库访问方法和进程的测试。
|
特殊注意事项:
|
测试可能需要 DBMS 开发环境或驱动程序以在数据库中直接输入或修改数据。
应手动调用进程。
应使用小型或将大小调整到最低限度的数据库(记录数有限)来增加任何不可接受的事件的可视性。
|
测试目标的功能测试应专注于对可以直接跟踪到用例或业务功能测试的任何需求以及业务规则。这些测试的目标是验证正确的数据验收、处理和检索以及适当的业务规则实施。这种测试基于黑匣技术;即,通过图形用户界面(GUI)与应用程序交互并分析输出或结果,验证应用程序及其内部进程。下表确定了为每个应用程序建议的测试的大纲。
技术目标:
|
试验测试目标功能(包括导航、数据输入、处理和检索)以观察和记录目标行为。
|
技术:
|
试验每个用例场景的个别用例流或功能和特性,使用有效和无效的数据,以验证:
当使用有效数据时,预期的结果发生
当使用无效数据时,显示相应的错误或警告消息
正确应用了每条业务规则
|
预测:
|
概述一项或多项可以由该技术用于精确观察测试结果的策略。该预测将以下两者的元素结合在一起:一、可以用于观察的方法;二、表示可能成功或失败的特定结果的特征。理想的情况下,预测将是自我验证的,允许自动化测试对测试通过或失败做出初始评估,但是,要注意降低在自动化结果确定中内在的风险。
|
所需的工具:
|
该技术需要以下工具:
测试脚本自动化工具
基本配置映像程序和恢复程序
备份和恢复工具
安装监视工具(注册表、硬盘、CPU、内存等)
数据生成工具
|
成功标准:
|
该技术支持测试以下各项:
所有关键用例场景
所有关键特性
|
特殊注意事项:
|
确定或描述影响功能测试的实施和执行的那些项或问题(内部或外部)。
|
业务周期测试应模拟随着时间流逝而对 <Project Name> 执行的任务。应确定一个时间段(例如一年),并且应执行将在一年的时间段内进行的事务和任务。这包括所有每日、每周、每月的周期,以及与日期相关的事件(例如记录簿)。
技术目标:
|
按照所需的业务模型和时间表试验测试目标和后台进程,以观察和记录目标行为。
|
技术:
|
测试将通过执行以下操作模拟若干业务周期:
用于测试目标的功能测试的测试将进行修改或增强,以增加执行每个功能的次数,模拟在指定的时间段内若干不同的用户。
所有与时间相关或与日期相关的功能将使用有效和无效的日期或时间段执行。
所有在定期时间表上发生的功能将在相应的时间执行或启动。
测试将包括使用有效和无效数据验证以下各项:
当使用有效数据时,预期的结果发生。
当使用无效数据时,显示相应的错误或警告消息。
正确应用了每条业务规则。
|
预测:
|
概述一项或多项可以由该技术用于精确观察测试结果的策略。该预测将以下两者的元素结合在一起:一、可以用于观察的方法;二、表示可能成功或失败的特定结果的特征。理想的情况下,预测将是自我验证的,允许自动化测试对测试通过或失败做出初始评估,但是,要注意降低在自动化结果确定中内在的风险。
|
所需的工具:
|
该技术需要以下工具:
测试脚本自动化工具
基本配置映像程序和恢复程序
备份和恢复工具
数据生成工具
|
成功标准:
|
该技术支持所有关键业务周期的测试。
|
特殊注意事项:
|
系统日期和事件可能需要特殊的支持任务。
需要一个业务模型来确定相应的测试需求和过程。
|
用户界面(UI)测试验证用户与软件的交互。UI 测试的目标是确保 UI 通过测试目标的功能向用户提供相应的访问和导航。此外,UI 测试确保了 UI 功能内的对象和预期一样并符合公司(或行业)标准。
技术目标:
|
试验以下各项以观测和记录标准符合情况和目标行为:
在测试目标中反映业务功能和需求的导航,包括窗口到窗口、字段到字段,以及访问方法的使用(Tab 键、鼠标移动、加速键)。
可以试验窗口对象和特征,例如菜单、大小、位置、状态和焦点。
|
技术:
|
为每个窗口创建或修改测试以验证每个应用程序窗口和对象的正确导航和对象状态。
|
预测:
|
概述一项或多项可以由该技术用于精确观察测试结果的策略。该预测将以下两者的元素结合在一起:一、可以用于观察的方法;二、表示可能成功或失败的特定结果的特征。理想的情况下,预测将是自我验证的,允许自动化测试对测试通过或失败做出初始评估,但是,要注意降低在自动化结果确定中内在的风险。
|
所需的工具:
|
该技术需要测试脚本自动化工具。
|
成功标准:
|
该技术支持对将由用户广泛使用的每个主要屏幕或窗口的测试。
|
特殊注意事项:
|
并不是定制和第三方对象的所有属性都可以访问。
|
性能概要分析是一种性能测试,它度量和评估响应时间、事务速率和其他与时间相关的需求。性能概要分析的目标是验证性能需求已经实现。实施和执行性能概要分析是为了将测试目标的性能行为作为条件(例如工作负载或硬件配置)的函数进行概要分析和调整。
注意:下表中的事务指“逻辑业务事务”。这些业务被定义为预期系统的一个参与者要使用测试目标执行的特定用例,例如添加或修改给定的合同。
技术目标:
|
在以下条件下试验指定的功能事务或业务功能的行为,以观察和记录目标行为和应用程序性能数据:
正常预期工作负载
预期最差情况工作负载
|
技术:
|
使用为功能或业务周期测试而开发的测试过程。
修改数据文件以增加事务数,或修改脚本以增加在每个事务中发生的迭代数。
脚本应在一台机器上运行(最好的情况是将单一用户、单一事务作为基准),并应在多个客户端重复(虚拟或实际,请参阅下面的“特殊注意事项”)。
|
预测:
|
概述一项或多项可以由该技术用于精确观察测试结果的策略。该预测将以下两者的元素结合在一起:一、可以用于观察的方法;二、表示可能成功或失败的特定结果的特征。理想的情况下,预测将是自我验证的,允许自动化测试对测试通过或失败做出初始评估,但是,要注意降低在自动化结果确定中内在的风险。
|
所需的工具:
|
该技术需要以下工具:
测试脚本自动化工具
应用程序性能概要分析工具,例如 Rational Quantify
安装监视工具(注册表、硬盘、CPU、内存等)
资源约束工具;例如,罐装燃料
|
成功标准:
|
该技术支持测试以下各项:
单一事务或单一用户:成功模拟事务脚本,而不会由于测试实施问题而失败。
多个事务或多个用户:成功模拟工作负载,而不会由于测试实施问题而失败。
|
特殊注意事项:
|
综合性能测试包括在服务器上有后台工作负载。
可以用于执行这种操作的有若干方法,包括:
直接向服务器“驱动事务”,通常以结构化查询语言(SQL)调用的形式。
创建“虚拟”用户负载来模拟多个客户端(通常是数百个)。远程终端仿真工具可以用于完成此负载。此技术也可以用来将“流量”装入网络。
使用多个实际客户端,每一个都运行测试脚本,以对系统施加负载。
应该在专用机器上或在专用的时间执行性能测试。这可以实现完全控制和精确度量。
用于性能测试的数据库应为实际大小或等比例地缩放。
|
负载测试是一种性能测试,使测试目标经历不断变化的负载以度量和评估测试目标在这些不同的工作负载下持续正常运转的性能行为和能力。负载测试的目标是确定和确保系统在超过预期的最大工作负载时正常运转。此外,负载测试还评估性能特征,例如响应时间、事务速率和其他与时间相关的问题。
注意:下表中的事务指“逻辑业务事务”。这些事务被定义为系统用户预期要使用应用程序执行的特定功能,例如添加或修改给定的合同。
技术目标:
|
试验变化的工作负载条件下指定的事务或业务案例,以观察和记录目标行为和系统性能数据。
|
技术:
|
使用为功能或业务周期测试开发的事务测试脚本作为基础,但是请记住除去不必要的交互和延迟。
修改数据文件以增加事务数,或修改测试以增加每个事务发生的次数。
例如,工作负载应包含每日、每周和每月峰值负载。
工作负载应可同时代表平均负载和峰值负载。
工作负载应可同时代表瞬时峰值和持续峰值。
这些工作负载应在不同的测试环境条件下执行。
|
预测:
|
概述一项或多项可以由该技术用于精确观察测试结果的策略。该预测将以下两者的元素结合在一起:一、可以用于观察的方法;二、表示可能成功或失败的特定结果的特征。理想的情况下,预测将是自我验证的,允许自动化测试对测试通过或失败做出初始评估,但是,要注意降低在自动化结果确定中内在的风险。
|
所需的工具:
|
该技术需要以下工具:
测试脚本自动化工具
事务负载时间安排和控制工具
安装监视工具(注册表、硬盘、CPU、内存等)
资源约束工具;例如,罐装燃料
数据生成工具
|
成功标准:
|
该技术支持工作负载仿真的测试,即成功模仿工作负载,而不会由于测试实施问题而失败。
|
特殊注意事项:
|
负载测试应在专用机器上或在专用的时间执行。这可以实现完全控制和精确度量。
用于负载测试的数据库应为实际大小或等比例地缩放。
|
压力测试是一种性能测试,实施并执行它的目的在于理解系统如何由于边界条件或超出预期的容差而失败。这一般包括资源不足或资源争用。资源不足条件揭示了测试目标如何失败,这在正常的条件下不明显。其他缺陷可能源自对共享资源(如数据库锁或网络带宽)的争用,尽管一些此类测试通常都在功能和负载测试中进行。
注意:下表中引用的事务指逻辑业务事务。
技术目标:
|
在以下压力条件下试验测试目标功能,以观测和记录以下目标行为,该目标行为确定并记录系统未能持续正常运转的条件:
服务器上可用内存很少或没有可用内存(RAM 和持久存储空间)
实际最大的连接或模拟的客户端数,或物理上能够连接或模拟的客户端数
对相同数据或帐户执行相同事务的多个用户
“超负荷”事务量或混合(请参阅上面的“性能概要分析”)
|
技术:
|
使用为性能概要分析或负载测试而开发的测试。
要测试有限的资源,应在一台单一的机器上运行测试,并且服务器上的 RAM 和持久存储空间应该减少或限制。
对于剩余的压力测试,应使用多个客户端,运行同一测试或互补测试以生成最坏情况的事务量或混合。
|
预测:
|
概述一项或多项可以由该技术用于精确观察测试结果的策略。该预测将以下两者的元素结合在一起:一、可以用于观察的方法;二、表示可能成功或失败的特定结果的特征。理想的情况下,预测将是自我验证的,允许自动化测试对测试通过或失败做出初始评估,但是,要注意降低在自动化结果确定中内在的风险。
|
所需的工具:
|
该技术需要以下工具:
测试脚本自动化工具
事务负载时间安排和控制工具
安装监视工具(注册表、硬盘、CPU、内存等)
资源约束工具;例如,罐装燃料
数据生成工具
|
成功标准:
|
该技术支持压力仿真的测试。系统可以在一个或多个定义为压力条件的条件中成功仿真,并且可以在该条件仿真期间或之后捕获对导致的系统状态的观察。
|
特殊注意事项:
|
向网络施加压力可能需要网络工具通过消息或数据包向网络施加负载。
用于系统的持久存储应临时减少以限制可供数据库增长的空间。
同步客户端对相同记录或数据帐户的同时访问。
|
容量测试使测试目标经历大量的数据,以确定是否达到导致软件失败的极限。容量测试还确定测试目标在给定的时间段内可以处理的持续最大负载或容量。例如,如果测试目标是处理一组数据库记录以生成报表,则容量测试要使用一个较大的测试数据库,并要检查软件是否正常运转并生成正确的报表。
技术目标:
|
在以下高容量场景下试验测试目标功能以观察和记录目标行为:
连接或仿真的最大(实际的或物理可能的)数目的客户端,所有客户端都在长期的时间段中执行相同的最坏情况(性能)业务功能。
已达到最大数据库大小(实际或缩放),并同时执行多个查询或报告事务。
|
技术:
|
使用为性能概要分析或负载测试而开发的测试。
应使用多个客户端,运行同一测试或互补测试以在很长的时间段中生成最坏情况的事务量或混合(请参阅“压力测试”)。
创建最大的数据库大小(实际、缩放或以代表性数据填充),并使用多个客户端在很长的时间段中同时运行查询和报告事务。
|
预测:
|
概述一项或多项可以由该技术用于精确观察测试结果的策略。该预测将以下两者的元素结合在一起:一、可以用于观察的方法;二、表示可能成功或失败的特定结果的特征。理想的情况下,预测将是自我验证的,允许自动化测试对测试通过或失败做出初始评估,但是,要注意降低在自动化结果确定中内在的风险。
|
所需的工具:
|
该技术需要以下工具:
测试脚本自动化工具
事务负载时间安排和控制工具
安装监视工具(注册表、硬盘、CPU、内存等)
资源约束工具;例如,罐装燃料
数据生成工具
|
成功标准:
|
该技术支持容量仿真的测试。大量的用户、数据、事务或其他方面的容量下的系统使用可以成功仿真,并且可以捕获在容量测试持续时间内对系统状态更改的观察。
|
特殊注意事项:
|
哪段时间可以被视为如上所述的高容量条件的可接受时间?
|
安全性和访问权控制测试专注于安全性的两个关键方面:
应用程序级别的安全性,包括对数据或业务功能的访问权
系统级别的安全性,包括登录或远程访问系统
基于您想要的安全性,应用程序级别的安全性确保了参与者被限制到特定的功能或用例,或它们被限制到对他们可用的数据。例如,可能允许每个人输入数据和创建新帐户,但仅经理可以删除它们。如果具有数据级别的安全性,测试可以确保“用户类型一”可以看到所有的客户信息(包括财务数据),但是“用户类型二”只能看到同一客户端的统计数据。
系统级别的安全性确保了仅授权访问系统的那些用户能访问应用程序,且只能通过适当的网关访问。
技术目标:
|
在以下条件下试验测试目标以观察和记录目标行为:
应用程序级别的安全性:参与者仅可以访问向其用户类型提供许可权的那些功能或数据。
系统级别的安全性:仅允许具有系统和应用程序访问权的那些参与者访问系统和应用程序。
|
技术:
|
应用程序级别的安全性:确定并列出每个用户类型以及每个类型具有许可权的功能或数据。
为每个用户类型创建测试,并通过创建特定于每个用户类型的事务而验证每个许可权。
修改用户类型并对相同的用户重新运行测试。在每种情况下,验证那些添加的功能或数据被正确提供或拒绝。
系统级别的访问权:请参阅下面的“特殊注意事项”。
|
预测:
|
概述一项或多项可以由该技术用于精确观察测试结果的策略。该预测将以下两者的元素结合在一起:一、可以用于观察的方法;二、表示可能成功或失败的特定结果的特征。理想的情况下,预测将是自我验证的,允许自动化测试对测试通过或失败做出初始评估,但是,要注意降低在自动化结果确定中内在的风险。
|
所需的工具:
|
该技术需要以下工具:
测试脚本自动化工具
“黑客”安全性违规和探测工具
操作系统安全性管理工具
|
成功标准:
|
该技术支持:为每个已知参与者类型测试受安全性设置影响的相应功能或数据。
|
特殊注意事项:
|
必须与相应的网络管理员或系统管理员复审或讨论系统的访问权。此测试可能不是必需的,因为这可能是网络管理或系统管理的一个功能。
|
故障转移和恢复测试确保:测试目标可以从各种硬件、软件或网络故障(这些故障会造成不当的数据丢失或数据完整性问题)中进行故障转移和恢复。
对于那些必须保持运行的系统,故障转移测试确保在出现故障转移情况时,备用系统或备份系统会正确“接管”出现故障的系统,而不会丢失任何数据或事务。
恢复测试是一种对抗性的测试过程,其中应用程序或系统暴露在极端条件或仿真条件下以产生一个故障,例如设备输入/输出(I/O)故障或无效的数据库指针和键。调用恢复过程,并且监视和检查该应用程序或系统以验证应用程序或系统是否正常,并且已实现数据恢复。
技术目标:
|
模拟故障条件并试验恢复过程(手动和自动)以将数据库、应用程序和系统恢复为预想中的已知状态。以下类型的条件包含在测试中,以观测和记录恢复之后的行为:
客户端电源中断
服务器电源中断
通过网络服务器的通信中断
DASD(直接访问存储设备)和 DASD 控制器中断、通信或电源丢失
周期不完整(数据过滤过程中断,数据同步过程中断)
无效的数据库指针或键
数据库中无效或损坏的数据元素
|
技术:
|
已为功能和业务周期测试创建的测试可以用作创建一系列事务以支持故障转移和恢复测试的基础,主要用于定义要运行来测试恢复是否成功的测试。
客户端电源中断:关闭 PC 电源。
服务器电源中断:模拟或启动服务器的关闭电源过程。
通过网络服务器中断:模拟或启动网络的通信丢失(物理断开通信线路或关闭网络服务器或路由器的电源)。
DASD 和 DASD 控制器中断、通信或电源丢失:模拟或物理消除与一个或多个 DASD 或 DASD 控制器的通信。
一旦达到上述条件或仿真条件,应执行其他的事务,并在达到第二个测试点状态时,应调用恢复过程。
测试不完整的周期利用与上述相同的技术,除了数据库进程本身应异常终止或过早终止。
测试以下条件需要达到一个已知的数据库状态。 若干数据库字段、指针和键应在数据库内手动和直接地损坏(通过数据库工具)。应使用应用程序功能和业务周期测试中的测试执行其他事务,并应执行完整的周期。
|
预测:
|
概述一项或多项可以由该技术用于精确观察测试结果的策略。该预测将以下两者的元素结合在一起:一、可以用于观察的方法;二、表示可能成功或失败的特定结果的特征。理想的情况下,预测将是自我验证的,允许自动化测试对测试通过或失败做出初始评估,但是,要注意降低在自动化结果确定中内在的风险。
|
所需的工具:
|
该技术需要以下工具:
基本配置映像程序和恢复程序
安装监视工具(注册表、硬盘、CPU、内存等)
备份和恢复工具
|
成功标准:
|
该技术支持测试以下各项:
一个或多个模拟的灾难,包括应用程序、数据库和系统的一种或多种组合。
一个或多个模拟的恢复,包括处于已知所需状态的应用程序、数据库和系统的一种或多种组合。
|
特殊注意事项:
|
恢复测试是具有高度侵略性的。断开电缆的过程(模拟电源或通信丢失)可能不适合或不可行。可能需要替代方法,例如诊断软件工具。
需要来自系统(或计算机操作)、数据库和连网组的资源。
这些测试应在数小时之后运行或在孤立的机器上运行。
|
配置测试在不同的软件和硬件配置上验证测试目标的操作。在多数生产环境中,客户端工作站、网络连接和数据库服务器的特定硬件规格都是不同的。客户端工作站可以装入不同的软件(例如,应用程序、驱动程序等),并在任何时间,都可以有使用不同资源的许多不同组合处于活动状态。
技术目标:
|
在所需的硬件和软件配置上试验测试目标,以观察和记录在不同配置下的目标行为并确定配置状态的更改。
|
技术:
|
使用功能测试脚本。
或者作为测试的一部分,或者在测试开始之前,打开和关闭各种非测试目标相关软件,例如 Microsoft® Excel® 和 Microsoft® Word® 应用程序。
执行选定的事务以模拟与测试目标和非测试目标软件交互的参与者。
重复上述过程,将客户端工作站上的可用常规内存降到最低。
|
预测:
|
概述一项或多项可以由该技术用于精确观察测试结果的策略。该预测将以下两者的元素结合在一起:一、可以用于观察的方法;二、表示可能成功或失败的特定结果的特征。理想的情况下,预测将是自我验证的,允许自动化测试对测试通过或失败做出初始评估,但是,要注意降低在自动化结果确定中内在的风险。
|
所需的工具:
|
该技术需要以下工具:
基本配置映像程序和恢复程序
安装监视工具(注册表、硬盘、CPU、内存等)
|
成功标准:
|
该技术支持测试在预期的、受支持的部署环境中运行的目标测试项的一种或多种组合。
|
特殊注意事项:
|
需要什么非测试目标软件?什么非测试目标软件是可用的?什么非测试目标软件可以在台式机上访问?
通常使用哪些应用程序?
这些应用程序在运行什么数据;例如,是在 Excel 中打开的一个较大的电子表格还是 Word 中的 100 页的文档?
整个系统的网件、网络服务器、数据库等也需要记录为此测试的一部分。
|
安装测试有两个目的。第一个是确保该软件不管是正常条件还是异常条件,均可在不同条件下(例如新的安装、升级、完全或定制安装)进行安装。异常条件包括磁盘空间不足、缺少创建目录的特权等。第二个目的是验证软件一旦安装就可以正确运转。这通常意味着运行为功能测试开发的多个测试。
技术目标:
|
试验在以下条件下将测试目标安装到每个所需的硬件配置,以观察和记录安装行为和配置状态更改:
新安装:新机器,先前从未安装过 <项目名称>
更新:先前安装过 <项目名称> 同一版本的机器
更新:先前安装过 <项目名称> 较旧版本的机器
|
技术:
|
开发自动或手动脚本以验证目标机器的条件。
新的:从未安装 <project Name>
已安装相同版本或较旧版本的<project Name>
启动或执行安装。
使用预定义的功能测试脚本的其中一部分运行这些事务。
|
预测:
|
概述一项或多项可以由该技术用于精确观察测试结果的策略。该预测将以下两者的元素结合在一起:一、可以用于观察的方法;二、表示可能成功或失败的特定结果的特征。理想的情况下,预测将是自我验证的,允许自动化测试对测试通过或失败做出初始评估,但是,要注意降低在自动化结果确定中内在的风险。
|
所需的工具:
|
该技术需要以下工具:
基本配置映像程序和恢复程序
安装监视工具(注册表、硬盘、CPU、内存等)
|
成功标准:
|
该技术支持测试在一个或多个安装配置中安装所开发的产品。
|
特殊注意事项:
|
应选择哪些 <project Name> 事务来组成一个可信度测试(在该测试中,<project Name> 应用程序已成功安装,并且没有缺少任何主要软件组件)?
|
|