测试场景标准库

测试场景标准库一、 一般测试场景二、 过滤条件测试场景三、 结果表测试场景四、 窗口测试场景五、 数据库测试场景六、 上传功能测试场景七、 发送电子邮件测试场景八、 excel导出场景九、 性能测试场景性能测试相关术语十、安全性测试场景测试场景标准库一、一般测试场景所有必填字段都应校验并用星号"午标注验证错误提示信息应在正确的位置合理显示所有的错误信息都应用相同的CSS样式显示（如：红色）一般性的确认信息应该用错误消息意外的CSS样式显示（如：绿色）提示信息应是有意义的下拉字段的第一个条目应是空白或“请选择”之类的文本删除页面中的任何记录信息都应要求确认如果页面支持记录的添加/删除/更新功能，那么页面中应提供"全选”和"全不选"所有记录的选择项数量值应该显示正确的货币符号应提供默认页面排序重置按钮功能应将页面所有字段设置为默认值所有的数值都应正确地格式化输入字段应检查最大字段值，输入的字段值超过指定的最大值则不被接受或不被存储到数据库检查所有输入字段中输入特殊字符的情况使用标准的字段标签，如：一个接受用户姓名的字段标签可以被定义为"姓名"检查添加/编辑/删除操作后页面中信息记录的排序功能检查超时功能，超时的值应是可配置的，操作超时后检查应用程序的行为是否合理检查Cookies在应用程序中的使用检查可下载文件是否指向了正确的文件路径所有的资源键应该可以在配置文件或数据库中配置，而不是写死资源键的命名应始终谩循标准惯例验证所有的web页面标记（验证HTML和CSS的语法错误）以确保它符合标准应用程序崩溃或不可用页面应该重定向到错误页面在所有页面中检查文本的拼写和语法错误检查数字输入字段中输入字符的情况，应提示合适的校验信息如果字段允许输入数值，应该检查输入员数的情况检查数星字段值带有小数的情况检查页面中所有按钮的功能用户连续点击提交按钮时不能重复提交页面信息在任何计算中都应处理除以0的情况应正确处理输入数据前后的空格二、 过滤条件测试场景用户应能够使用页面中的所有参数过滤结果精确搜索功能应根据用户选择的所有搜索参数加载搜索页面当页面中至少需要一个过滤条件才能执行搜索操作时，必须保证用户没有设置任何过滤条件提交查询时能显示合适的错误提示信息当页面中至少有一个过滤条件是非强制的时，用户提交查询后那些非强制过滤条件使用默认搜索条件查询相关结果过滤条件设置为无效值时应显示合适的校验信息三、 结果表测试场景当结果页面加载时长超过默认时长时，应该显示"页面加载中"之类的提示信息检查结果表中获取的数据是否满足所有的搜索条件结果总数都应在结果表中显示使用的搜索条件应该在结果表中显示结果表中的值应该按照默认列排序排序列应该显示排序的图标结果表中的结果正确且包含所有指定的列对支持排序的列，应能进行升序和降序排序操作结果表中的行列间距合理当结果多于每页默认显示的结果数时应正确分页检查上一页、下一页、首页和末页分页功能结果表中无重复的记录检查所有的列是否都可见，必要时启用水平滚动条检查数据动态列（列值由其他列计算得来的列）对于报表结果表，应检查行汇总和列汇总的值对于报表结果表，应检查有分页的情况下用户切换分页时的行汇总值检查显示列是否使用了正确的符号，如：％（百分号）应该显示在百分数计算结果中检查结果表中的数据是否启用了日期范围四、 窗口测试场景检查默认窗口的大小是否正确检查子窗口的大小是否正确检查默认焦点是否放在了页面中的某个字段上（一般来说，焦点放在页面中第一个可输入的字段上）检查关闭父窗口或开着的窗口时是否会关闭子窗口当子窗口开着时，用户不能使用或更新父窗口或子窗口后面窗口的字段值检查窗口最小化、最大化和关闭功能检查窗口是否能重设大小检查父窗口和子窗口的滚动条的功能检查子窗口中的"取消"按钮的功能五、 数据库测试场景页面提交成功时检查数据是否正确地保存在数据库中检查不接受空值的列值数据应根据表设计被存储在单个或多个表中索引名称应按照标准如IND_＜表名＞_＜列名〉表应该有主键应对表中的列给出相应的描述信息（除了诸如创建时间、创建人等审计列）应该为每个数据库的添加/更新操作添加日志应该为需要的表创建索引检查是否只有操作完全成功后才将数据提交到数据库中一旦事务失败数据应该回滚数据库名称应按照应用程序类型命名，即测试,UAT,沙箱，现场（尽管这不是一个标准，但对数据库维护是很有帮助的）数据库逻辑名称应根据数据库名称命名（这不是标准但又有利于数据库维护）存储过程不应该以前缀"sp_”命名检查表审计列的值（如创建日期、创建人、更新日期、更新者、已删除、删除日期、删除者等等）填充正确检查输入数据保存时是否未被截断，在页面中显示的字段长度和数据库的字段长度应该是相同的检查包含最小、最大和浮点的数值字段检查数值字段含有负值（接受和拒绝两种情况）检査单选按钮和下拉列表正确地保存在数据库中检查数据库字段设计的数据类型和数据长度是否正确检查所有的表约束条件如主键、外键等是否正确实现测试存储过程和触发器的样本输入数据输入数据的首尾空格应在数据保存到数据库之前被自动隐去主镶列不允许为NULL值六、 上传功能测试场景检查图片上传路径检查图像上传和修改功能检查各种扩展图像文件的上传（例如JPEG、PNG、BMP等）.检查文件名中含有空格或其他可用特殊字符的图片的上传检查重复名称图片上传图片尺寸大于最大允许值，上传时应该显示适当的错误消息.检查上传的图片文件类型外的其它文件时（例如txt、doc、pdf、exe等等），应该显示适当的错误消息检查如果上传的图片满足指定的高度和宽度（如果有定义的话）则可以成功上传，否则不能上传上传大尺寸图片时应显示上传进度条检查上传过程中的取消按钮是否有效检查文件选择对话框中的文件列表是否只显示支持文件类型检查上传多个图像的功能上传后检查图像质量，图像质量不应该改变检查用户是否能够使用/查看上传的图像七、 发送电子邮件测试场景.所有电子邮件模板应该使用css标准要验证电子邮件地址后再发送电子邮件特殊字符在邮件正文模板应妥善处理特定语言的字符（例如：俄文、中文或德文字符）应在电子邮件主体模板中妥善处理电子邮件主题不能空占位符字段中使用电子邮件模板应该替换为实际的值如｛姓｝｛名｝应该替换为所有收件人正确的名字和姓氏如果报告有动态值包含在电子邮件的正文中,报告数据应正确计算电子邮件发送者的名字不能为空应该在不同的电子邮件客户端（如：Outlook,Gmail,Hotmail,Yaho。邮件等）检查电子邮件检查发送电子邮件功能使用TO、CC和BCC字段.检查纯文本邮件检查HTML格式的电子邮件查看邮件页眉和页脚相应的公司LOGO,隐私政策和其他槌接检查带附件的电子邮件发送检查给一个、多个或者联系人组发送电子邮件检查回复电子邮件地址是否正确检查发送大量的电子邮件八、excel导出场景.文件输出时应该有适当的文件扩展名导出Excel文件的文件名应该按照标准，例如：如果文件名使用时间命名，它应该在导出文件的时候妥善换成实际时间当Excel文件包含日期列时需要检查导出的日期格式检查数字格式的数值或货币值，格式应该和页面显示的相同导出的文件应该有适当的列名称默认页面排序应体现在导出文件中Excel文件数据应正确格式化包括页眉和页脚文本、日期、页码等所有页面的值检查数据在页面上显示的文件与导出Excel文件是是否一样检查使用分页时的导岀功能检查导出按钮图标是否根据导出的文件类型正确显示，如：导出的是.xls文件，则显示Excel文件对应的图标.检查大文件的导出功能12.检查页面包含特殊字符的导出功能，检查这些特殊字符是否正确地导出到Excel文件±传后检查图像质量，图像质量不应该改变检查用户是否能够使用/查看上传的图像九、性能测试场景1.检查页面加载时间是否在可接受范围内检查页面加载缓慢的链接检查在轻度、正常、中度和重度负载环境下所有操作的响应时间检查数据库存储过程和触发器的性能检查数据库查询执行时间检查应用程序的负载测试检查应用程序的压力测试在峰值负载条件下检查CPU和内存的使用情况性能测试相关术语并发(Concurrency)/并行(Parallelism):如果CPU是8核的，理论上同一时刻CPU可以同时处理8个任务。当有8个请求同时进来时，这些任务被CPU的8核分别处理，它们都拥有CPU资源并不相互干扰，此时CPU是在井行地处理仟务。如果是单核CPU,同时有8个请求进来时，请求只能排队被CPU处理，此时8个请求是并发的，因为它们同一时刻进来，而处理是一个一个的。所以并发是针对一个对象(单核CPU)发生多个事件(谓求)，并行是多个对象(多个CPU核)同时处理多个事件(请求)。同理，当请求多于8个，那么也可以在多核CPU前形成并发的情况。我们常听到的"并发用户数"并不是像本例中的8个请求，比如一个系统有200个用户，即使他们都在线，也不能代表他们都操作了业务，用户可能仅仅是上去看一下信息然后挂机，所以通常听到的"并发用户数"并不能作为真实的性能测试需求，而应该以产生的业务量(交易量/请求数)为性能需求。负载：模拟业务操作对服务器造成压力的过程，比如模拟100个用户进行订单提交。负载的产生受数据的影响，我们常说量变引起质变，比如查询100条与查询100万条数据的响应时间很可能有差异。性能测试(PerformanceTesting):模拟用户负载来测试在负载情况下，系统的响应时间、吞吐量等指标是否满足性能要求。负载测试(LoadTesting):在一定软硬件环境下，通过不断加大负载(不同虚拟用户数)来确定在满足性能指标情况下的承载极限。简单地说，它可以帮助我们对系统进行定容定量，找出系统性能的拐点，给出生产环境规划的建议。这里的性能指标包括TPS(每秒事务数)、RT(事务平均响应时间)、CPUUsing(CPU利用率)、MemUsing(内存使用率)等软硬件指标。从操作层面上来说，负载测试也是一种性能测试手段，比如配置测试就需要变换不同的负载来进行测试。配置测试(ConfigurationTesting):为了合理地调配资源，提高系统运行效率，通过测试手段来获取、验证、调整配置信息的过程。通过这个过程我们可以收集到不同配置反映的不同性能，从而为设备选择、设备配置提供参考。压力/强度测试(StressTesting):在一定软硬件环境下，通过高负载的手段使服务器资源(强调服务器资源，硬件资源)处于极限状态，测试系统在极限状态下长时间运行是否稳定，确定是否稳定的指标包括TPS、RT、CPU使用率、Mem使用率等。稳定性测试(EnduranceTesting):在一定软硬件环境下，长时间运行一定负载，确定系统在满足性能指标的前提下是否运行稳定。与上面的压力/强度测试区别在于，稳定性测试负載并不强调是在极限状态下，着重的是满足性能要求的情况下系统的稳定性，比如响应时间是否稳定、TPS是否稳定、主机是否稳定。一般我们会在满足性能要求的负载情况下加大1.5〜2倍的负裁量进行测试。TPS：每秒完成的事务数，有时用QPS(每秒查询数)来代替，通常指每秒成功的事务数，这是性能测试中重要的综合性性能指标。一个事务是一个业务度量单位，有时一个事务会包括多个子操作，但为了方便统计，我们会把这些子操作计为一个事务。比如一笔电子支付操作，在后台系统中可能会经历会员系统、账务系统、支付系统、会计系统、银行网关等，但对于用户来说只想知道整笔支付花费了多长时间。RT/ART(ResponseTime/AverageResponseTime):响应时间/平均响应时间，指一个事务花费多长时间完成(多长时间响应客户请求)，为了使这个响应时间更具代表性，会统计更多的响应时间然后取平均值，即得到了事务平均响应时间(ART),通常我们说的RT是代指平均响应时间。PV(PageView):每秒用户访问页面的次数，此参数用来分析平均每秒有多少用户访问页面。Vuser虚拟用户(VirtualUser):模拟真实业务逻辑步骡的虚拟用户，虚拟用户模拟的操作步骡都被记录在虚拟用户脚本里。Vuser脚本用于描述Vuser在场景中执行的操作。场景(Scenario):性能测试过程中为了模拟真实用户的业务处理过程，在测试工具中构建的基于事务、脚本、虚拟用户、运行设置、运行计划、监控、分析等一系列动作的集合，称之为性能测试场景。此场景中包含了待执行脚本、脚本组、并发用户数、负载生成器、测试目标、测试执行时的配置条件等。简单地说，就是把若干个业务的性能测试脚本组织成一个执行单元，对执行单元进行一揽子的配置来保证测试的有效执行。比如负载测试时，我们可以设置一种图1・7所示的阶梯形负载增长场景。300200100思考时间(ThinkTime):模拟正式用户在实际操作时的停顿间隔时间。从业务的角度来讲，思考时间指的是用户在进行操作时，每个请求之间的间隔时间；在测试脚本中，思考时间体现为脚本中两个请求语句之间的间隔时间。标准差(Std.Devia