功能界面测试规范
功能（系统集成）和界面测试规范要求
目录 (1)
一、功能测试 (2)
二、GUI 测试 (3)
三、具体测试标准要求 (4)
1、焦点转移问题： (4)
2、数字格式： (4)
3、输入文本框类型控件的测试： (4)
4、下拉列表的检测： (5)
5、必填项的测试： (5)
6、非必填项的测试： (5)
7、时间的测试： (5)
8、边界值的检测： (5)
9、保存操作的测试： (6)
10、删除操作的测试： (6)
11、修改操作的测试： (6)
12、查询操作的测试： (6)
13、分页显示的测试： (7)
14、工作流程的测试： (7)
15、系统自动生成项的测试： (7)
16、重复某项操作的测试： (7)
17、权限的问题： (7)
18、链接测试： (8)
19、关于统一性的测试： (8)
20、关于计算或统计方面的测试： (8)
21、唯一性测试： (8)
22、窗口最大化、最小化、关闭、确定按钮、
取消按钮的测试 (8)
23、打印或签章测试： (8)
24、提示信息的测试： (8)
一、功能测试
功能测试就是对产品的各功能进行验证，根据功能测试用例，逐项测试，检查产品是否达到用户要求的功能。常用的测试方法如下：
1、输入框进行输入测试。包括中文字符、英文字符、数字字符、特殊字符、及几种字符的
组合。
2、对界面可操作按钮进行测试。包括【新增】/【添加】【保存】【取消】【删除】【查询(简项查询/高级查询)】【制作文书】【呈请审批】【打印】【退出】等等。同时需要对鼠标右键的菜单进行测试。
3、数据保存测试。将以上1 和2 进行组合。
4、必要条件控制测试。在做了3 时将必要条件（如：a、必填项（黑粗体表示）不可为空b、身份证类型和证件号码判断c、日期限制）联合起来验证。
5、页面链接检查：每一个链接是否都有对应的页面，并且页面之间切换正确。
6、相关性检查：删除/增加一项会不会对其他项产生影响，如果产生影响，这些影响是否都正确。
7、字符串长度检查：输入超出需求所说明的字符串长度的内容，看系统是否检查字符串长度，会不会出错（测试时只要看是否有截取长度的功能，过长的字符比如256个输入保存，是否会报错）。
8、字符类型检查：在应该输入指定类型的内容的地方输入其他类型的内容（如在应该输入整型的地方输入其他字符类型），看系统是否检查字符类型，会否报错。
9、标点符号检查：输入内容包括各种标点符号，特别是空格，各种引号，回车键\n，看系统处理是否正确。
10、检查带出信息的完整性：在查看信息或列表框选择的信息或者更新信息后，查看所填写的信息是不是全部带出，带出信息和添加的是否一致。（比如地址选择控件，选择了长长的地址信息，是否都带入地址文本框，在保存后，是否地址信息都完整的保存）。
11、信息重复：在一些需要命名，且名字应该唯一的信息输入重复的名字或ID，看系统有没有处理，会否报错，重名包括是否区分大小写，以及在输入内容的前后输入空格，系统是否作出正确处理。
12、检查删除功能：在一些可以一次删除多个信息的地方，不选择任何信息，按”删除”，看系统如何处理，会否提示；然后选择一个和多个信息，进行删除，看是否正确处理。
13、检查添加和修改是否一致：检查添加和修改信息的要求是否一致，例如添加要求必填的项，修改也应该必填；添加规定为整型的项，修改也必须为整型。
14、检查修改重名：修改时把不能重名的项改为已存在的内容，看会否处理、报错。同时也要注意，会不会报和自己重名的错。
15、重复提交表单：一条已经成功提交的纪录，back （上一步）后再提交，看看系统是否做了处理。
16、检查多次使用上一步或上一页键的情况：在有上一步/下一步或上一页/下一页的地方，一直点到头再点回到开始，重复多次，看会否出错或按钮失效。
17、查询检查：在有查询功能的地方输入系统存在和不存在的内容，看查询结果是否正，如果可以输入多个查询条件，可以同时添加合理和不合理的条件，看系统处理是否正确。
18、输入信息位置：注意在光标停留的地方输入信息时，光标和所输入的信息会否跳到别的地方。
19、上传下载文件检查：上传下载文件的
功能是否实现，上传文件是否能打开。对上传文件的格式有何规定，系统是否有解释信息，并检查系统是否能够做到。
20、必填项检查：应该填写的项没有填写时系统是否都做了处理，对必填项是否有提示信息，如在必填项名称中加粗显示。
21、快捷键检查：是否支持常用快捷键，如Ctrl+C Ctrl+V Backspace 等，对一些不允许输入信息的字段，如选人、选地址、选日期对快捷方式是否也做了限制。
22、回车键检查：在输入结束后直接按回车键，看系统处理如何，会否报错。
23、日期约束检查：比如接警日期小于报警日期，保存时是否校验提示；处警日期小于接警日期，保存时是否检验提示；日期上限小于日期下限，保存时是否检验提示。
24、关联控件检查：比如选择了证件类型，证件号码为空，保存时是否提示处理；选择了身份证类型，证件号码不合法，是否检验身份证号并提示处理；录入了身份证号码后，出生日期保存时是否检验并提示处理。
25、菜单深度一般要求最多控制在三层以
内。
26、工作流程的测试，要求满足业务流程的要求，分为主业务流、次业务流或异常流的测试。
二、GUI 测试
1.窗体是否能够基于相关的输入或菜单命令适当的打开
2.窗体是否能够改变大小、移动和滚动；固定大小的窗体在IE6、IE7下是否都能完整显示，在宽屏、窄屏显示器下是否都能完整显示。
3.窗体的数据是否能够利用鼠标、功能键、方向箭头和键盘操作
4.当窗体被覆盖并重新调用后，窗体是否能够正确再生
5.窗体相关的功能是否可以操作
6.是否显示相关的下拉菜单、工具条、滚动条、对话框、按钮、图标和其他控制，既能正确显示又能调用
7.显示多窗体时，窗体名称是否能够正确表示
8.活动窗体是否能够被反显加亮或明显区
分显示
9.多用户联机时所有窗体是否能够实时更新
10.鼠标无规则点击时是否会产生无法预料的结果
11.窗体声音及提示是否符合既定编程规则
12.窗体是否能够被关闭
13.窗体控件的大小、对齐方向、颜色、背景等属性的设置值是否和程序设计规约相一致
14.窗体控件布局是否合理、美观
15.窗体控件TAB 顺序是否从左到右，从上到下
16.窗体焦点是否按照编程规范落在既定的控件上
17.窗体画面文字（全、半角、格式、拼写）是否正确
18.鼠标有多个形状时是否能够被窗体识别（如漏斗状时窗体不接受输入）
三、具体测试标准要求
1、焦点转移问题：
（1）使用Tab 键测试焦点转移；
（2）当保存时如果提示“有未输入的必填”项回到页面后，
（3）焦点应转移到未输入的必填项中最靠前的一项上
2、数字格式：
（1）如果对数字格式有限制则看是否符合限制
（2）格式没有限制时，所有输入数据的小数点位数应该一致
3、输入文本框类型控件的测试：
（1）空值测试
（2）空格测试：前面输入空格，中间输入空格，末尾输入空格和全部输入空格，程序是否进行处理，保存成功后，数据库中的数据是否与页面显示的一致
（3）长度测试（最大字符，一次输入大于256的字符观察处理情况，可以输入后再拷贝到
记事本上进行比对，看是否有截断处理，如果无截断处理，点击保存是否报错。）
（4）类型测试（如果有类型要求，一般是整形与字符型的转换测试）
（5）特殊字符的测试（NUL及\n等，另外像；;’”><,｀‘：“［”｛、\|｝］+=)-(_*&&^%$#@!~,.。?/）
（6）关于文本框录入为数字时的测试：
对数字长度有没有限制，输入1 位数，2 位数，加负号，字母或汉字，等等有没有提示信息
（7）关于文本框录入数字型小数点的测试：
录入整数加小数点、小数点加整数和单独的小数点，录入负数，保存时系统是否有提示，是否成功
（8）关于文本框填写不符合条件的信息保存确认后清空与否的测试：
比如在文本框中录入不符合条件的数据（类型不符合或者超多等），保存确定后只
要清空错误的数据即可
（9）文本框内容的合理性：
如果是输入正数的文本框，（如：补偿金额）还要判断是否为负数。
(10) 文本框大小写问题：要求数据唯一性时是否区分大小写
4、下拉列表的检测：
（1）检查列表中的内容是否漏选，重选；如果列表中的数据要求从其他页面或者数据库中或字典中获得的，就要检查是否与该页面中的数据一致。
（2）下拉列表的控件是否支持清空再选择，当清空时在页面中的有效表现
（3）下拉列表的控件是否有多选提示，比如至少必须选择两个，至多选择5个等等提示，以及实际操作的吻合性（比如选择少于两个时，保存时会有选择两个的提示）。
（4）下拉列表框支持代号输入选择的要求，比如输入1表示选择男性。
（5）下拉列表框具有很多个选择项时的上下滚动条，或上一级选项/下一级选项的切换。
5、必填项的测试：
（1）必填项要求加粗显示或是有明显的标识（如红色加*）
（2）检查必填项是否提示必须输入（一般是通过保存事件或输入焦点的移动或页面的切换进行触发）
（3）对于不支持手动录入的必填项，是否支持下拉控件选择或第三方控件的录入，下拉控件的选择方式，要检查是否有提供选择的项（字典加载的数据）；另外当必填项不支持手动录入时，还要检查系统是否能自动赋值（比如点击添加/新填按钮时，就能自动调出用户信息；或是点击查看详细，就能将关联数据自动带过来）
6、非必填项的测试：
（1）非必填项都支持空值或默认值保存；
（2）非必填项的数据录保存后，一样能存入数据库及在页面呈现
（3）非必填项的控件都具有清除已选或已录入数据的功能，比如日期控件支持清空或手动清
除文本框的信息进行保存，清除的数据修改保存后不再显示原有的数据。
7、时间的测试：
（1）注意要清楚当前系统时间（服务端系统时间）
（2）起始时间不可大于终止时间
（3）检查日期为空时程序的反应。
（4）数据库中的日期是否能够正确显示在页面上
（5）输入错误日期时程序的反应。
（6）如果有输入日期不得大于当前日期的限制，则是否通过
（7）如果有输入日期不得小于当前日期的限制，则是否通过
（8）业务时间的先后关系，比如报案时间、接警时间、处警时间、出警时间、到案时间、结案时间等等的先后关系。哪个时间必须要大于哪个时间，要进行校验测试。
8、边界值的检测：
（1）输入条件规定了值的范围
（2）应取刚达到这个范围的边界的值作为测
试输入数据
（3）以及刚刚超越这个范围边界的值作为测试输入数据
（4）输入条件规定了值的个数
（5）最大个数
（6）最小个数
（7）比最小个数少一
（8）比最大个数多一
9、保存操作的测试：
（1）保存成功/失败后检查数据库
（2）检查必填项，各个必填项未输入时的提示要求
（3）保存成功/失败是否有相应的提示信息，或者有明显的特征表示（比如保存成功，保存按钮变灰不再可操作）
10、删除操作的测试：
（1）删除提示成功/失败后看查看数据库
（2）删除时是否有确认对话框（点是或否，确认是否对应正确的删除操作）
（3）删除成功/失败是否有提示信息（至少删除失败有相应提示）
（4）确定是逻辑删除，还是物理删除；物理删除是否已经把数据库中的数据删除掉，逻辑删除是否改变了标志位（在页面上提现不出来，需要到数据库表中查询验证）。
（5）单条数据删除测试和多条数据删除测试，检查删除操作的有效性。
11、修改操作的测试：
（1）修改提示成功后看数据库中的记录是否已经修改
（2）对于没有修改按钮也没有提供专门修改页面的业务功能，保存按钮就具有修改功能，当手动修改已录入的数据，再次提交保存后，数据就相应的修改，通过页面查询或数据库中的记录来检验是否已经修改。
12、查询操作的测试：
（1）查询到的记录是否与数据库中的记录相符，主要确认库中是否有待查的数据
（2）检查组合查询时，查询结果是否正确
（3）查询列表下如果可以查询纪录的详细信息，检测查询条件范围是否改变
（4）查询到的记录，有关联详细信息，要检
查关联信息的吻合性，如果有深度关联的页面功能，还要一一检查其所有的关联信息。
（5）查询条件中有日期这一项的查看是否有默认值及其值是否符合要求
（6）查询条件中有时间段或其它范围段组合的查询条件，还要检查其默认查询段，是否会影响查询性能（比如默认查询一年内的数据，在性能考虑和业务考虑上就是不合理的）
13、分页显示的测试：
（1）检查是否能够正常分页显示
（2）检查是否能够正常前进或后退
（3）检查是否能够正确选择一页的显示记录数
（4）检查是否能够正确选择显示第x 页（5）检查点击到最后一页后，是否还能回到第一页，并支持重复来回点击
（6）检查第一页到最后一页，是否界面显示统一，列标题风格一致，列排序功能有效（分页多的情况下，只要检查第一页和最后一页以及中间的某一页）。
（7）无论是否有分页数据存在的情况，都要
检查其排序功能是否有效，排序是否正确（一般通过列排题点击就具有排序功能），点击排序时是否报对象错误。
14、工作流程的测试：
（1）每个模块的工作流程是否可以正常运行（2）每个模块的工作流程过程是否与详细设计要求的一致（或符合用户业务要求）（3）不按正常的工作流程操作是否可以正常运行（比如没有处罚审批，就允许直接出处罚通知书）
15、系统自动生成项的测试：
（1）应该自动生成数据的地方是否自动生成了数据（比如文书报表制作）
（2）系统自动生成的数据是否符合详细设计的要求（比如文书报表格式）
（3）自动生成数据的该条信息是否可以正常使用（如文书报表中的内容有效性和正确性）（4）自动生成数据后系统是否可以正常运行
16、重复某项操作的测试：
(包括按钮、某个流程，如重复保存、重复措施
或重复处罚等操作)
（1）某项操作重复进行时是否正确运行（2）某项操作重复进行后再进行其他操作是否正确
（3）某项操作重复进行后再进行其他操作系统是否正常运行
17、权限的问题：
（1）用户登录测试（账号密码测试、PKI登录、注册）
（2）检查具有不同权限的用户登录时，是否具有跟其权限相符合的操作；检查没有权限的用户是否具有相应的权限
（3）检查不同权限的用户（不同用户组的测试），是否都能完成指定的业务流程
18、链接测试：
（1）将鼠标按到链接上然后移动一下再放开鼠标页面是否会出错。
（2）当链接打开一个新页面时检查页面初始化状态是否有异常情况。
（3）是否存在空页面，是否存在不用登录就能访问的页面。
19、关于统一性的测试：
（1）页面对于同样的成功或者失败的提示信息是否统一（包括标点符号的统一）
（2）页面对于专业术语和相同的操作用语是否统一
（3）相同的操作过程是否统一，输入和输出的统一，界面风格是否统一
20、关于计算或统计方面的测试：
查看计算或统计结果是否正确，进行增删改数值操作后其值是否进行相应正确改变
21、唯一性测试：
（1）要求数据唯一并且是逻辑删除时，是否允许与已删除的记录重复
（2）要求唯一性的数据，在两人（或两人以上）同时操作时是否能正确地执行
22、窗口最大化、最小化、关闭、确定按钮、取消按钮的测试
23、打印或签章测试：
（测试前要求先检查打印机的安装和签章系统的部署）
界面设计测试规范 目前流行的界面风格有三种方式：多窗体、单窗体以及资源管理器风格，无论那种风格，以下规则是应该被重视的。 1:易用性： 按钮名称应该易懂，用词准确，屏弃没楞两可的字眼，要与同一界面上的其他按钮易于区分，能望文知意最好。理想的情况是用户不用查阅帮助就能知道该界面的功能并进行相关的正确*作。 易用性细则： 1):完成相同或相近功能的按钮用Frame框起来，常用按钮要支持快捷方式。 2):完成同一功能或任务的元素放在集中位置，减少鼠标移动的距离。 3):按功能将界面划分局域块，用Frame框括起来,并要有功能说明或标题。 4):界面要支持键盘自动浏览按钮功能，即按Tab键的自动切换功能。 5):界面上首先应输入的和重要信息的控件在Tab顺序中应当靠前,位置也应放在窗口上较醒目的位置。 6):同一界面上的控件数最好不要超过10个，多于10个时可以考虑使用分页界面显示。 7):分页界面要支持在页面间的快捷切换，常用组合快捷键Ctrl+Tab 8):默认按钮要支持Enter及选*作，即按Enter后自动执行默认按钮对应*作。 9):可写控件检测到非法输入后应给出说明并能自动获得焦点。 10):Tab键的顺序与控件排列顺序要一直，目前流行总体从上到下，同时行间从左到右的方式。 11):复选框和选项框按选择几率的高底而先后排列。 12):复选框和选项框要有默认选项，并支持Tab选择。 13):选项数相同时多用选项框而不用下拉列表框。 14):界面空间较小时使用下拉框而不用选项框。 15):选项数叫少时使用选项框，相反使用下拉列表框。 16):专业性强的软件要使用相关的专业术语，通用性界面则提倡使用通用性词眼。 2：规范性： 通常界面设计都按Windows界面的规范来设计，即包含“菜单条、工具栏、工具厢、状态栏、滚动条、右键快捷菜单”的标准格式，可以说：界面遵循规范化的程度越高，则易用性相应的就越好。小型软件一般不提供工具厢。 规范性细则： 1):常用菜单要有命令快捷方式。 2):完成相同或相近功能的菜单用横线隔开放在同一位置。 3):菜单前的图标能直观的代表要完成的*作。 4):菜单深度一般要求最多控制在三层以内。 5):工具栏要求可以根据用户的要求自己选择定制。
软件测试中的43个功能测试点 功能测试就是对产品的各功能进行验证，根据功能测试用例，逐项测试，检查产品是否达到用户要求的功能，针对web系统我们有哪些常用测试方法呢？今天我们一起来了解了解~~ 1. 页面链接检查 每一个链接是否都有对应的页面，并且页面之间切换正确。可以使用一些工具，如：LinkBotPro、File-AIDCS、HTMLLink Validater、xenu等工具。LinkBotPro不支持中文，中文字符显示为乱码；HTMLLink Validater只能测试以Html或者htm结尾的网页链接；xenu无需安装，支持asp、do、jsp等结尾的网页，xenu测试链接包括内部链接和外部链接，在使用的时候应该注意，同时能够生成html格式的测试报告。 2.相关性检查 功能相关性：删除/增加一项会不会对其它项产生影响，如果产生影响，这些影响是否都正确，常见的情况是，增加某个数据记录以后，如果该数据记录某个字段内容较长，可能会在查询的时候让数据列表变形。 3.检查按钮的功能是否正确 如新建、编辑、删除、关闭、返回、保存、导入、上一页、下一页、页面跳转、重置等功能是否都正确。常见的错误会出现在重置按钮上，表现为功能失效。 4.字符串长度检查 输入超出需求所说明的字符串长度的内容，看系统是否检查字符串长度。还要检查需求规定的字符串长度是否都正确，有时候会出现，需求规定的字符串长度太短而无法输入业务数据。 5.字符类型检查 在应该输入指定类型的内容的地方输入其他类型的内容（如在应该输入整型的地方输入其他字符类型）看系统是否检查字符类型。 6.标点符号检查 输入内容包括各种标点符号，特别是空格，各种引号，回车键。看系统处理是否正确。常见的错误是系统对空格的处理，可能添加的时候，将空格当作一个字符，而在查询的时候空格被屏蔽，导致无法查询到添加的内容。
软件测试中的43个功能测试点软件测试 功能测试就是对产品的各功能进行php?name=%D1%E9%D6%A4">验证，根据功能测试用例，逐项测试，检查产品是否达到用户要求的功能。针对web系统的常用测试方法如下： 1. 页面链接检查：每一个链接是否都有对应的页面，并且页面之间切换正确。可以使用一些工具，如LinkBotPro、File-AIDCS、HTML Link Validater、Xenu等工具。LinkBotPro不支持中文，中文字符显示为乱码;HTML Link Validater只能测试以Html或者htm结尾的网页链接;Xenu无需安装，支持asp、do、jsp等结尾的网页，xenu测试链接包括内部链接和外部链接，在使用的时候应该注意，同时能够生成html格式的测试报告。如果系统用QTP进行自动化测试，也可以使用QTP的页面检查点检查链接。 2. 相关性检查：功能相关性：删除/增加一项会不会对其他项产生影响，如果产生影响，这些影响是否都正确，常见的情况是，增加某个数据记录以后，如果该数据记录某个字段内容较长，可能会在查询的时候让数据列表变形。 数据相关性：下来列表默认值检查，下来列表值检查，如果某个列表的数据项依赖于其他模块中的数据，同样需要检查，比如，某个数据如果被禁用了，可能在引用该数据项的列表中不可见。 3. 检查按钮的功能是否正确：如新建、编辑、删除、关闭、返回、保存、导入，上一页，下一页，页面跳转，重置等功能是否正确。常见的错误会出现在重置按钮上，表现为功能失效。 4. 字符串长度检查: 输入超出需求所说明的字符串长度的内容, 看系统是否检查字符串长度。还要检查需求规定的字符串长度是否是正确的，有时候会出现，需求规定的字符串长度太短而无法输入业务数据。 5. 字符类型检查: 在应该输入指定类型的内容的地方输入其他类型的内容(如在应该输入整型的地方输入其他字符类型),看系统是否检查字符类型。 6. 标点符号检查: 输入内容包括各种标点符号,特别是空格,各种引号,回车键。看系统处理是否正确。常见的错误是系统对空格的处理，可能添加的时候，将空格当作一个字符，而在查询的时候空格被屏蔽，导致无法查询到添加的内容。 7.特殊字符检查：输入特殊符号，如@、#、$、%、!等，看系统处理是否正确。常见的错误是出现在% ‘" 这几个特殊字符 8. 中文字符处理: 在可以输入中、英文的系统输入中文,看会否出现乱码或出错。 9. 检查信息的完整性: 在查看信息和更新信息时,查看所填写的信息是不是全部更新,更新信息和添加信息是否一致。要注意检查的时候每个字段都应该检查，有时候，会出现部分字段更新了而个别字段没有更新的情况。
项目测试规范 编 制 ： 审 核 ： 批 准 ： 文 件 编 号 : 版 本 号 : v1.0 秘 密 等 级 ：普通级 发 出 部 门 : 颁 发 日 期 : 年 月 日 发 送 至 ： 抄 送 ： 总 页 数 ： 页 附 件 ： 主 题 词 ：
文件更改历史更改日期版本号更改原因
目录 1编写目的 (4) 2测试团队构成 (4) 2.1职责 (4) 2.2角色划分 (4) 3工作流程及规范 (5) 3.1计划与设计阶段 (5) 3.1.1成立测试团队 (5) 3.1.2测试预通知 (5) 3.1.3召开测试启动会议 (5) 3.1.4编写测试计划文档 (6) 3.1.5设计测试用例 (6) 3.2实施测试阶段 (7) 3.2.1实施测试用例 (7) 3.2.2提交报告 (7) 3.2.3回归测试 (8) 3.3总结阶段 (8) 3.3.1编写测试报告 (8) 3.3.2测试工作总结 (9) 3.3.3测试验收 (9) 3.3.4测试归档 (10) 3.4缺陷跟踪 (10) 4缺陷类型定义 (11) 5测试标准 (12) 6争议处理 (12) 7标准文档 (12)
1编写目的 本文档是测试团队的日常工作规范，主要侧重测试工作流程的控制，明确软件工程的各阶段测试团队应完成的工作。测试技术和策略等问题不在本文档描述范围内。 2测试团队构成 2.1职责 测试是软件开发过程中的重要组成部分，肩负着如下责任： ?在项目的前景、需求文档确立基线前对文档进行测试，从用户体验和测试的角度提出自己的看法。 ?编写合理的测试计划，并与项目整体计划有机地整合在一起。 ?编写覆盖率高的测试用例。 ?针对测试需求进行相关测试技术的研究。 ?认真仔细地实施测试工作，并提交测试报告供项目组参考。 ?进行缺陷跟踪与分析。 2.2角色划分 在人力资源有限的情况下，一个团队成员可能会同时承担多个角色。
第1部分系统测试方案
1.1 测试目标 通过功能及测试，采用多种测试方法，使系统达到以下目标： 测试已实现的产品是否达到设计的要求，包括：各个功能点是否以实现，业务流程是否正确。 系统的性能达到需求说明书的指标范围内，保证系统7*24小时的稳定运行。 Bug数和缺陷率控制在可接收的范围之内。 1.2 测试策略 1．功能测试：测试系统基本功能实现是否正常，是否实现需求说明书中的所有功能，其中包括导航，数据输入，处理和检索等功能； 2．集成测试：检测需求中业务流程，数据流程的正确性； 用户界面测试：通过测试进行的浏览可正确反映业务的功能和需求，这种浏览包括窗口与窗口之间、字段与字段之间的浏览，以及各种访问方法（Tab键、鼠标移动、和快捷键）的使用窗口的对象和特征（例如，菜单、大小、位置、状态和中心）都符合标准； 3．性能评测：对响应时间、事务处理速率和其他与时间相关的需求进行评测和评估。性能评测的目标是核实性能需求是否都已满足需求说明书的指标范围内； 4．负载测试：将使测试对象承担不同的工作量，以评测和评估测试对象在不同工作量条件下的性能行为，以及持续正常运行的能力； 5．安全性和访问控制测试：侧重于安全性的两个关键方面：应用程序级别的安全性，包括对数据或业务功能的访问。系统级别的安全性，包括对系统的登录或远程访问； 6．故障转移和恢复测试：确保测试对象能成功完成转移，并能从导致意外数据损失或数据完整性破坏的各种硬件、软件可网络故障中恢复； 7．配置测试：核实测试对象在不同的软件和硬件配置中的运行情况。 1.3 测试工具和测试环境 1.3.1 测试工具 在缺陷管理方面，将采用MI公司的Bug管理工具TestDirector8.0进行Bug的管理。 TestDirector 是业界第一个基于Web的测试管理系统,它可以在您公司内部或外部进行全球范围内测试的管理。通过在一个整体的应用系统中集成了测试管理的各个部分，包括需求管理，测试计划，测试执行以及错误跟踪等功能，TestDirector极大地加速了测试过程，提高效率。 在性能测试方面，将采用MI公司的性能测试工具LoadRunner8.0进行性能测试。 LoadRunner 是一种预测系统行为和性能的负载测试工具。通过以模拟上千万用户实施并发负载及实时性能监测的方式来确认和查找问题，LoadRunner 能够对整个企业架构进行测试。通过使用LoadRunner ，企业能最大限度地缩短测试时间，优化性能和加速应用系统
web测试基本点 2011-07-02 22:33:17| 分类：软件测试 | 标签：web测试 |举报 |字号大中小订阅 1、界面测试通用测试点 测试 内容 测试点 页面显示1、浏览器窗口标准或最大时页面元素显示是否正确，是否美观，窗口大小变化时页面刷新是否正确； 2、电脑显示屏是宽屏或标屏下页面元素显示是否正确，是否美观； 3、用户常用的几种分辨率下页面元素显示是否正确，是否美观。 4、字体的大小要与界面的大小比例协调, 通常使用的字体中宋体9-12较为美观，很少使用超过12号的字体。 5、前景与背景色搭配合理协调，反差不宜太大，最好少用深色，如大红、大绿等。 6、页面弹出式提示界面必须大小合理，布局美观，符合系统风格。 页面布局1、布局要合理,不宜过于密集，也不能过于空旷，合理的利用空间。 2、相关页面元素的外形是否美观大方，大小是否合适，位置和页面的风格是否协调。 3、页面相关说明性文字的位置是否正确合适，鼠标定位在需说明的控件上时相关提示信息位置是否合理。 页面风格1、同一系统中不同页面的整体风格是否一致，是否美观； 2、各页面背景、色调是否正确，是否美观，是否适合应用环境。 3、主色调要柔和，具有亲和力与磁力，坚决杜绝刺目的颜色。 易用性1、按钮名称易懂，用词准确，屏弃多义性字眼，要与同一界面上的其他按钮易于区分，能望文知意最好。 2、对于完成同一功能的控件需要集中放置；Tab键的顺序与控件排列顺序要一致，目前流行总体从上到下， 同时行间从左到右的方式。 3、默认按钮要支持Enter及选操作，即按Enter后自动执行默认按钮对应操作。 4、页面要支持键盘自动浏览按钮功能，即按Tab键、回車鍵的自动切换功能。 5、页面输入控件的选择要合理合适，同一界面复选框不能出现太多，下拉列表选项也不宜太多。 6、常用菜单功能需提供操作快捷键，快捷键的定义应符合大众操作习惯。 7、页面存在工具栏的，工具栏需要设置默认停靠位置，工具栏长度不能太长，工具栏上的按钮需提供提示信息，工具栏功能可以用户自行定制。 友好性1、对于需要等待的操作，如果时间稍长就应该提供进度条显示。 2、菜单深度一般要控制在三层以内，树状结构类似。 3、滚动条的长度要根据显示信息的长度或宽度能及时变换，以利于用户了解显示信息的位置和百分比。 4、对用户操作需要反馈足够的信息，例如提示、警告、或错误，信息表达应该清楚、明了、恰当、准确。 特殊字符~ ， ` , ! , @ , # , $ , % , ^ , & , * , ( , ) , ; , | , \ , / , < , > , , , . , { , } , [ , ] , ' , " 。一般的输入框中需要屏蔽上面列举的特殊字符，使其不能输入。
软件测试规 1目的 确保软件产品质量，使产品能够顺利交付和通过验收的一项重要措施。 2适用围 适用于项目开发过程中的单元测试、集成测试、系统测试、业务测试、验收测试以及一些专项测试。 3职责 ?项目测试负责人组织编制《测试计划》、《测试方案》，指导和督促测试人员完成各阶段的测试工作。 ?项目组测试人员按照《测试计划》、《测试方案》完成所承担的测试任务，并按要求填写《问题报告及维护记录》。 ?测试经理依照确认规程和准则对工作产品进行确认，提出对确认规程和准则的修改意见 ?项目负责人组织测试环境的建立。 ?项目经理审核负责控制整个项目的时间和质量。 ?研发人员确认修改测试人员提交的bug。 4工作流程 4.1 测试依据 详细设计是模块测试的依据。因此设计人员应向测试人员提供《系统需求规格书名书》、《详细设计》、《概要设计》等有关资料。测试人员必须认真阅读，真正弄懂系统需求和详细设计。 4.2 制订《测试方案》 在测试之前，由项目负责人根据《测试计划》的要求，组织人员编制相应的《测试方案》，《测试方案》应包括以下容：
?测试目的； ?所需人员及相应培训要求； ?测试环境、工具和测试软件； ?测试用例、测试数据和预期的结果。 4.3 单元测试 项目开发实现过程中，每个程序单元（程序单元的划分视具体开发工具而定，一般定为函数或子程序级）编码调试通过后，要及时进行单元测试。 单元测试由单元开发者自己进行，使用白盒测试方法，根据程序单元的控制流程，争取达到分支覆盖。对于交互式运行的产品，不便于进行自动测试的，可以采用功能测试的方法进行。 单元测试针对程序模块，从程序的部结构出发设计测试用例。多个模块可以独立进行单元测试。 ?单元测试容包括模块接口测试、局部数据结构测试、路径测试、错误处理测试等； ?单元测试组织原则一遍根据开发进度安排对已开发完成的单一模块进行测试； ?单元测试停止标准：完成了所有规定单元的测试，单元测试中发现的bug已经得到修改。 4.4 集成测试 编码开发完成，项目组部应进行组装测试。 集成测试由项目负责人组织策划（编写测试计划、测试用例）并实施。集成测试着重对各功能模块之间的接口进行测试，验证各功能模块是否能协调工作、参数传递及功能调用是否正常。测试采用交叉方法，即个人开发的软件应由其他的项目组成员进行测试。 集成测试过程应填写《问题报告及维护记录》，测试结果应形成《测试报告》。 4.5 系统测试 在项目开发完成之后，应对整个系统软件和硬件进行系统测试。对性能、可靠性、健壮性、压力承受力等方面分别进行评价，以验证系统是否满足
移动互联网App测试点包括： 1.安全测试 1)软件权限 -扣费风险：包括发送短信、拨打电话、连接网络等 -隐私泄露风险：包括访问手机信息、访问联系人信息等 -新增风险项 2)开发者官方权限列表信息比对分析 2.安装、运行、卸载测试 验证App是否能正确安装、运行、卸载，以及操作过程和操作前后对系统资源的使用情况，主要包括： 1)检测软件是否能正确安装、运行、卸载； 2)安装、卸载、更新错误报告； 3)其他辅助信息： -位置和文件夹是否合理； -组件是否正确注册或删除； -评估操作前后，CPU、Memory（内存占用）、Storage（磁盘占用）等系统资源的使用情况。3.UI测试 测试用户界面(如菜单、对话框、窗口和其它可视控件)布局、风格是否满足客户要求，文字是否正确，页面是否美观，文字，图片组合是否完美，操作是否友好等。 UI测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。确保用户界面符合公司或行业的标准。包括用户友好性、人性化、易操作性测试。 4.功能测试 根据软件说明或用户需求验证App的各个功能实现，采用如下方法实现并评估功能测试过程： 1)采用时间、地点、对象、行为和背景五元素或业务分析等方法分析、提炼App的用户使用场景，对比说明或需求，整理出内在、外在及非功能直接相关的需求，构建测试点，并明确测试标准（若用户需求中无明确标准遵循，则需要参考行业或相关国际标准或规则）。 2)根据被测功能点的特性列举出相应类型的测试用例对其进行覆盖，如：涉及输入的地方需要考虑等价、边界、负面、异常或非法、场景回滚、关联测试等测试类型对其进行覆盖。 3)在测试实现的各个阶段跟踪测试实现与需求输入的覆盖情况，及时修正业务或需求理解错误。 5.性能测试 评估App的时间和空间特性 1)极限测试：在各种边界压力情况下（如电池、存储、网速等），验证App是否能正确响应。 2)响应能力测试：测试App中的各类操作是否满足用户响应时间要求 3)压力测试：反复/长期操作下，系统资源是否占用异常； 4)性能评估：评估典型用户应用场景下，系统资源的使用情况。 5)Benchmark测试（基线测试）：与竞争产品的Benchmarking, 产品演变对比测试等。 6.中断测试 针对智能终端应用的服务等级划分方式及实时特性所提出的测试方法，如：App在前/后台运行状态时与来电、文件下载、音乐收听等关键运用的交互情况测试等。 7.兼容测试 主要测试内部和外部兼容性，包括：与本地及主流App是否兼容； 检验在各种网络连接下(WiFi、GSM、GPRS、EDGE、WCDMA、CDMA1x、CDMA2000、HSPDA等)，App的数据和运用是否正确；
软件测试中常见的功能测试检查点 Functional testing (功能测试)，也称为behavioral testing（行为测试），根据产品特征、操作描述和用户方案，测试一个产品的特性和可操作行为以确定它们满足设计需求。本地化软件的功能测试，用于验证应用程序或网站对目标用户能正确工作。使用适当的平台、浏览器和测试脚本，以保证目标用户的体验将足够好，就像应用程序是专门为该市场开发的一样。功能测试也叫黑盒子测试或数据驱动测试,只需考虑各个功能，不需要考虑整个软件的内部结构及代码.一般从软件产品的界面、架构出发，按照需求编写出来的测试用例，输入数据在预期结果和实际结果之间进行评测,进而提出更加使产品达到用户使用的要求。 功能测试常见检查点如下： 1.页面链接检查：每一个链接是否都有对应的页面，并且页面之间切换正确。 2.相关性检查：删除/增加一项会不会对其他项产生影响，如果产生影响，这些影响是否都正确。 3.检查按钮的功能是否正确：如update、cancel、delete、save等功能是否正确。 4.字符串长度检查：输入超出需求所说明的字符串长度的内容，看系统是否检查字符串长度，会不会出错。 5.字符类型检查：在应该输入指定类型的内容的地方输入其他类型的内容(如在应该输入整型的地方输入其他字符类型)，看系统是否检查字符类型，会否报错。 6.标点符号检查：输入内容包括各种标点符号，特别是空格、各种引号、回车键。看系统处理是否正确。 7.中文字符处理：在可以输入中文的系统输入中文，看会否出现乱码或出错。 8.检查带出信息的完整性：在查看信息和update信息时，查看所填写的信息是不是全部带出，带出信息和添加的是否一致。 9.信息重复：在一些需要命名，且名字应该唯一的信息输入重复的名字或ID，看系统有没有处理，会否报错，重名包括是否区分大小写，以及在输入内容的前后输入空格，系统是否作出正确处理。
软件测试流程规范 一、通读项目需求设计文档 1.测试的准备阶段； 2.仔细阅读《软件需求规格说明书》； 3.根据测试手册，做前期的测试准备； 二、明确测试任务的范围 ⑴功能测试；⑵界面测试；⑶接口测试；⑷容错测试；⑸负载测试； ⑹安全测试；⑺性能测试；⑻稳定性测试；⑼配置测试；⑽安装测试； ⑾恢复测试；⑿文档测试；⒀可用性测试； 三、学习理解被测试软件 由开发人员组织讲解所要执行测试的软件或者产品，测试人员必须认真理解拿到手中待测试的软件或者产品。 四、制定测试计划 “工欲善其事，必先利其器”。软件测试必须以一个好的测试计划作为基础。作为测试的起始步骤和重要环节。测试计划应包括：产品基本情况调研、测试策略、测试大纲（功能模块的测试、详细测试、高级测试）、测试内容（界面测试、测试需求说明）、测试人力资源配置、测试计划的变更、测试硬件环境、测试软件环境、测试工具、测试进度计划表、问题跟踪报告、测试通过准则、测试计划的评审意见等。另外还包括测试计划的目的、测试对象信息、测试计划使用的范围及测试参考文档。 1.项目简介； 对产品（项目）的一个了解和概述，主要对产品（项目）功能的简述。 2.测试背景； 产品在那种情况下开始研发，执行测试，交待为何而测试产品的背景。 4.测试类型（方法）；（黑盒测试） ⑴功能测试；⑵界面测试；⑶接口测试；⑷容错测试；⑸负载测试； ⑹安全测试；⑺性能测试；⑻稳定性测试；⑼配置测试；⑽安装测试； ⑾恢复测试；⑿文档测试；⒀可用性测试； 5.测试资源；
6.测试策略\测试需求\测试任务\测试点； 针对测试需求定义测试类型、测试方法以及需求的测试工具等。 ①对于每种测试，都应提供测试说明，并解释其实施的原因。 ②制定测试策略时所考虑的主要事项有：将要使用的技术以及判断测试何时完成的标准。 ③下面列出了在进行每项测试时需考虑的事项，除此之外，测试还只应在安全的环境中使用已 知的、有控制的数据库来执行。 ④不实施某种测试，则应该用一句话加以说明，并陈述这样的理由。例如，“将不实施该测试。 该测试本项目不适用”。 No工作内容开始时间结束时间责任人提交的结果备注 五、设计测试用例 测试用例的主要来源为：1）需求说明书及相关文档2）相关的设计说明（概要设计，详细设计等）3）与开发组交流对需求理解的记录（可以是开发人员的一个解释）4）已经基本成型的UI（可以有针对性地补充一些用例） 从所得到的资料中，分解出若干小的“功能点”，理解“功能点”，编写相应的测试用例。 项目名称程序版本功能模块名用例编号编制人编制时间 论坛 功能特性 测试目的 参考信息 预置条件特殊规程说 明 参考信息 测试用例 基本流 序号名称说明1 2 备选流 序号名称说明1 2 相关的用例无 测试场景 序号名称说明
测试用例检查点 上一篇/ 下一篇 2009-03-18 11:07:25 / 个人分类：测试人生 查看( 125 ) / 评论( 0 ) / 评分( 0 / 0 ) 一、环境配置测试 （1）网络连接是否正常 （2）网络流量负担是否过重 （3）软件测试平台是否可选 （4）如果（3），是否在不同的软件测试平台进行软件测试 （5）所选软件测试平台的版本（包括Service Pack）是否正确 （6）所选软件测试平台的参数设置是否正确 （7）所选软件测试平台上正在运行的其它程序是否会影响测试结果 （8）画面的分辨率和色彩设定是否正确 二、代码测试 A．静态测试 （1）同一程序内的代码书写是否为同一风格 （2）代码布局是否合理、美观 （3）程序中函数、子程序块分界是否明显 （4）注释是否符合既定格式 （5）注释是否正确反映代码的功能 （6）变量定义是否正确（长度、类型、存储类型） （7）是否引用了未初始化变量 （8）数组和字符串的下标是否为整数 （9）的数组和字符串的下标是否在范围内（不“越界”） （10）进行数组的检索及其它操作中，是否会出现“漏掉一个这种情况” （11）是否在应该使用常量的地方使用了变量（例：数组范围检查）（12）是否为变量赋予不同类型的值 （13）（12）的情况下，赋值是否符合数据类型的转换规则 （14）变量的命名是否相似 （15）是否存在声明过，但从未引用或者只引用过一次的变量 （16）在特定模块中所有的变量是否都显式声明过
（17）非（16）的情况下，是否可以理解为该变量具有更高的共享级别 （18）是否为引用的指针分配内存 （19）数据结构在函数和子程序中的引用是否明确定义了其结构 （20）计算中是否使用了不同数据类型的变量 （21）计算中是否使用了不同的数据类型相同但长度不同的变量 （22）赋值的目的变量是否小于赋值表达式的值 （23）数值计算是否会出现溢出（向上）的情况 （24）数值计算是否会出现溢出（向下）的情况 （25）除数是否可能为零 （26）某些计算是否会丢失计算精度 （27）变量的值是否超过有意义的值 （28）计算式的求值的顺序是否容易让人感到混乱 （29）比较是否正确 （30）是否存在分数和浮点数的比较 （31）如果（30），精度问题是否会影响比较 （32）每一个逻辑表达式是否都得到了正确表达 （33）逻辑表达式的操作数是否均为逻辑值 （34）程序中的Begin…End和Do…While等语句中，End是否对应 （35）程序、模块、子程序和循环是否能够终止 （36）是否存在永不执行的循环 （37）是否存在多循环一次或少循环一次的情况 （38）循环变量是否在循环内被错误地修改 （39）多分支选择中，索引变量是否能超过可能的分支数 （40）如果（39）,该情况是否能够得到正确处理 （41）子程序接受的参数类型、大小、次序是否和调用模块相匹配 （42）全局变量定义和用法在各个模块中是否一致 （43）是否修改了只作为输入用的参数 （44）常量是否被做为形式参数进行传递 B 动态测试 （1）测试数据是否具有一定的代表性 （2）测试数据是否包含测试所用的各个等价类（边界条件、次边界条件、空白、无效）（3）是否可能从客户那边得到测试数据
手机可靠性测试规范 1. 目的 此可靠性测试检验规范的目的是尽可能地挖掘由设计，制造或机构部件所引发的机构部分潜在性问题，在正式生产之前寻找改善方法并解决上述问题点，为正式生产在产品质量上做必要的报证。 2. 范围 本规范仅适用于CECT通信科技有限责任公司手机电气特性测试。 3. 定义 UUT (Unit Under Test) 被测试手机 EVT (Engineering Verification Test) 工程验证测试 DVT (Design Verification Test) 设计验证测试 PVT (Product Verification Test) 生产验证测试 4. 引用文件 GB/T2423.17-2001 盐雾测试方法 GB/T 2423.1-2001 电工电子产品环境试验(试验Ab：低温) GB/T 2423.2-1995 电工电子产品环境试验(试验Bb：高温) GB/T 2423.3-1993 电工电子产品环境试验(试验Ca：恒定湿热) GB/T 2423.8-1995 电工电子产品环境试验(自由跌落) GB/T 2423.11-1997 电工电子产品环境试验(试验Fd: 宽频带随机振动) GB 3873-83 通信设备产品包装通用技术条件 《手机成品检验标准》XXX公司作业指导书 5. 测试样品需求数 总的样品需求为12pcs。 6. 测试项目及要求 6.1 初始化测试 在实验前都首先需要进行初始化测试，以保证UUT没有存在外观上的不良。如果碰到功能上的不良则需要先记录然后开始试验。在实验后也要进行初始化测试，检验经过实验是否造成不良。具体测试请参见《手机成品检验标准》。 6.2 机械应力测试 6.2.1 正弦振动测试 测试样品： 2 台
GUI测试规范 修订历史
目录 1.目的 (3) 2.GUI测试标准 (3) 2.1规范性 (3) 2.2合理性 (3) 2.3一致性 (4) 2.4界面定制性 (5) 3.其他归入GUI测试的测试点 (5) 4.GUI测试点汇总表格 (6)
1.目的 本文档定义了GUI测试规范，适用于所有产品及项目的GUI测试。遵照本规范，测试人员在编写GUI测试用例时，只编写一条测试用例即可：检查GUI，将不在Case管理系统中进行具体的扩展。以此来减少测试人员对与GUI测试用例的编写时间，而将重点放在产品功能和业务流程的检查上面。 GUI测试中归入了一些功能性检查。测试人员在提交bug时，根据具体情况上报为界面错误还是功能性错误。 本文档适用于所有测试人员。 2.GUI测试标准 2.1规范性 测试点1：便于用户操作。用户使用起来能够建立起精确的心里模型，使用熟练了一个界面后，切换到另外一个界面能够很轻松的推测出各种功能。 测试点2：使用户感觉到统一、规范。在使用软件的过程中愉快轻松的完成操作，提高对软件的认知。 测试点3：降低培训、支持成本，不必花费较多的人力对客户进行逐个指导。 2.2合理性 界面的合理性是指界面是否与软件功能相融洽，界面的颜色和布局是否协调等。 测试点4：界面布局。 ●屏幕不能拥挤，采用统一的控件间距。 ●控件按区域排列。以视觉效果和效率来组织这些区域。 ●有效组合。逻辑上相关的控件应当加以组合以表示其关联性，反之，任何不相关的 项目应当分隔开。在项目集合间用间隔对其进行分组，或者使用方框划分各自区域。 ●窗口缩放时，控件位置、布局。 ?固定窗口大小，不允许改变尺寸 ?改变尺寸的窗口，在窗口尺寸发生变化时控件的位置、大小做出相应的改变 ?改变尺寸的窗口，在窗口改变尺寸时增加相应在的纵向、横向滚动条，以方便 用户使用窗体上的控件 测试点5：界面颜色搭配。
一、功能测试 功能测试就是对产品的各功能进行验证，根据功能测试用例，逐项测试，检查产品是否达到用户要求的功能。常用的测试方法如下： 1、输入框进行输入测试。包括中文字符、英文字符、数字字符、特殊字符、及几种字符的组合。 2、对界面可操作按钮进行测试。包括【新增】/【添加】【保存】【取消】【删除】【查询(简项查询/高级查询)】【制作文书】【呈请审批】【打印】【退出】等等。同时需要对鼠标右键的菜单进行测试。 3、数据保存测试。将以上1 和2 进行组合。 4、必要条件控制测试。在做了3 时将必要条件（如：a、必填项（黑粗体表示）不可为空 b、身份证类型和证件号码判断 c、日期限制）联合起来验证。 5、页面链接检查：每一个链接是否都有对应的页面，并且页面之间切换正确。 6、相关性检查：删除/增加一项会不会对其他项产生影响，如果产生影响，这些影响是否都正确。 7、字符串长度检查：输入超出需求所说明的字符串长度的内容，看系统是否检查字符串长度，会不会出错（测试时只要看是否有截取长度的功能，过长的字符比如256个输入保存，是否会报错）。 8、字符类型检查：在应该输入指定类型的内容的地方输入其他类型的内容（如在应该输入整型的地方输入其他字符类型），看系统是否检查字符类型，会否报错。 9、标点符号检查：输入内容包括各种标点符号，特别是空格，各种引号，回车键\n，看系统处理是否正确。 10、检查带出信息的完整性：在查看信息或列表框选择的信息或者更新信息后，查看
所填写的信息是不是全部带出，带出信息和添加的是否一致。（比如地址选择控件，选择了长长的地址信息，是否都带入地址文本框，在保存后，是否地址信息都完整的保存）。 11、信息重复：在一些需要命名，且名字应该唯一的信息输入重复的名字或ID，看系统有没有处理，会否报错，重名包括是否区分大小写，以及在输入内容的前后输入空格，系统是否作出正确处理。 12、检查删除功能：在一些可以一次删除多个信息的地方，不选择任何信息，按”删除”，看系统如何处理，会否提示；然后选择一个和多个信息，进行删除，看是否正确处理。 13、检查添加和修改是否一致：检查添加和修改信息的要求是否一致，例如添加要求必填的项，修改也应该必填；添加规定为整型的项，修改也必须为整型。 14、检查修改重名：修改时把不能重名的项改为已存在的内容，看会否处理、报错。同时也要注意，会不会报和自己重名的错。 15、重复提交表单：一条已经成功提交的纪录，back （上一步）后再提交，看看系统是否做了处理。 16、检查多次使用上一步或上一页键的情况：在有上一步/下一步或上一页/下一页的地方，一直点到头再点回到开始，重复多次，看会否出错或按钮失效。 17、查询检查：在有查询功能的地方输入系统存在和不存在的内容，看查询结果是否正，如果可以输入多个查询条件，可以同时添加合理和不合理的条件，看系统处理是否正确。 18、输入信息位置：注意在光标停留的地方输入信息时，光标和所输入的信息会否跳到别的地方。 19、上传下载文件检查：上传下载文件的功能是否实现，上传文件是否能打开。对上传文件的格式有何规定，系统是否有解释信息，并检查系统是否能够做到。
Q/GSXH.Q. 质量管理体系第三层次文件1004.03-2001 可靠性试验规范
拟制：审核：批准： 海锝电子科技有限公司版次：C版 可靠性试验规范 1. 主题内容和适用范围 本档规定了可靠性试验所遵循的原则，规定了可靠性试验项目，条件和判据。 2. 可靠性试验规定 2.1 根据IEC国际标准，国家标准及美国军用标准，目前设立了14个试验项 目（见后目录〕。 2.2 根据本公司成品标准要求，用户要求，质量提高要求及新产品研制、工艺 改进等加以全部或部分采用上述试验项目。 2.3 常规产品规定每季度做一次周期试验，试验条件及判据采用或等效采用产 品标准；新产品、新工艺、用户特殊要求产品等按计划进行。 2.4 采用LTPD的抽样方法，在第一次试验不合格时，可采用追加样品抽样方 法或采用筛选方法重新抽样，但无论何种方法只能重新抽样或追加一次。 2.5 若LTPD=10％，则抽22只，0收1退，追加抽样为38只，1收2退。 抽样必须在OQC检验合格成品中抽取。 3．可靠性试验判定标准。
环境条件 (1)标准状态 标准状态是指预处理, 后续处理及试验中的环境条件。论述如下: 环境温度: 15~35℃ 相对湿度: 45~75% (2)判定状态 判定状态是指初测及终测时的环境条件。论述如下: 环境温度: 25±3℃ 相对湿度: 45~75% 4．试验项目。 目录 4.1 高温反向偏压试验------------------------------------ 第4页4.2 压力蒸煮试验------------------------------------ 第6页4.3 正向工作寿命试验------------------------------------ 第7页4.4 高温储存试验------------------------------------ 第8页4.5 低温储存试验------------------------------------ 第9页4.6 温度循环试验------------------------------------ 第10页4.7 温度冲击试验------------------------------------ 第11页4.8 耐焊接热试验------------------------------------ 第12页4.9 可焊性度试验------------------------------------ 第13页4.10 拉力试验------------------------------------ 第14页
软件测试基本流程与规范 1目标 制定完整且具体的测试路线和流程，为快速、高效和高质量的软件测试提供基础流程框架。 最终目标是实现软件测试规范化，标准化。 2测试流程说明
3测试需求分析 测试需求是整个测试过程的基础；确定测试对象以及测试工作的范围和作用。用来确定整个测试工作（如安排时间表、测试设计等）并作为测试覆盖的基础。而且被确定的测试需求项必须是可核实的。即，它们必须有一个可观察、可评测的结果。无法核实的需求不是测试需求。所以我现在的理解是测试需求是一个比较大的概念，它是在整个测试计划文档中体现出来的，不是类似的一个用例或者其他. ·测试需求是制订测试计划的基本依据，确定了测试需求能够为测试计划提供客观依据； ·测试需求是设计测试用例的指导，确定了要测什么、测哪些方面后才能有针对性的设计测试用例； ·测试需求是计算测试覆盖的分母，没有测试需求就无法有效地进行测试覆盖； 3.1测试方法与规范 3.1.1测试方法 随着软件技术发展，项目类型越来越多样化。根据项目类型应选用针对性强的测试方法，合适的测试方法可以让我们事半功倍。以下是针对目前项目工程可以参考的测试方法： ?β测试（beta测试）--非程序员、测试人员 β测试，英文是Beta testing。又称Beta测试，用户验收测试（UAT）。 β测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场，Beta测试不能由程序员或测试员完成。 当开发和测试根本完成时所做的测试，而最终的错误和问题需要在最终发行前找到。这种测试一般由最终用户或其他人员完成，不能由程序员或测试员完成。?α测试（Alpha测试）--非程序员、测试人员 α测试，英文是Alpha testing。又称Alpha测试. Alpha测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试，Alpha测试不能由该系统的程序员或测试员完成。 在系统开发接近完成时对应用系统的测试;测试后，仍然会有少量的设计变更。这种测试一般由最终用户或其他人员来完成，不能由程序员或测试员完成。?兼容性测试 --测试人员 兼容性测试是指测试软件是否可以成功移植到指定的硬件或者软件环境中，例如在B/S项目中各个不同浏览器之间的测试。 ?用户界面测试-UI测试--测试人员 用户界面测试，英文是User interface testing。又称UI测试。 用户界面，英文是User interface。是指软件中的可见外观及其底层与用户交互的部分（菜单、对话框、窗口和其它控件）。
功能测试问题及答案 1、下面的哪个不能被称作是测试的目标？ D A、为了发现软件中的错误、 B、为了给出决策者们需要发布系统的风险信息、 C、为了阻止缺陷正被引入到代码中、 D、为了证明软件是正确的 2、什么是测试设计? A A) 一个文档用以详细说明一个测试条目的测试条件和详细的测试方法 B) 一个文档用以描述范围，方法，资源和指定的测试活动的时间安排 C) 一个文档用以详细说明一组测试执行的动作 D) 设计和执行一个测试的原因或目标 3、下面的哪个不应该被包含在一个缺陷描述报告里? C A) 缺陷的严重级别和优先级别 B) 缺陷的简要描述 C) 引起缺陷的单个人的责任 D) 这个缺陷的当前状态 4、用户验收测试的焦点主要在? C A) 性能测试 B) 压力测试 C) 正式接受性测试 D)
负载测试 5、以下哪个不是系统测试的类型? C A) 回归测试 B) 结构测试 C) 静态测试 D) 非功能性测试 6、以下哪一项可以提供UAT测试范围的正式文档? B A) Project testing strategy项目的测试策略 B) UAT测试设计 C) UAT 测试计划 D) UAT 测试条件 7、测试用例和脚本的开发矩阵报告中包含的信息被定义在? D A) UAT测试计划 B) UAT 测试时间安排 C) UAT 测试设计 D) 测试矩阵计划 8、哪种覆盖是最强控制流覆盖标准? D A) 语句覆盖 B) 判定覆盖 C) 判定/条件覆盖 D) 混合条件覆盖
9、在整个测试生命周期里，哪个阶段修复缺陷会造成我们最高的成本? D A) 需求阶段 B) 设计阶段 C) 编码阶段 D) 版本上线阶段10、下面哪个是不正确的缺陷状态? A A) 新建一个再打开状态的缺陷 B) 修复一个再打开状态的缺陷 C) 澄清一个被拒绝的缺陷 D) 重新测试一个关闭的缺陷多选题 1、以下描述哪些是正确的 (AB ) A)不可能对一个程序进行完整的测试 B)测试不能证明缺陷是不存在的 C)发现的缺陷越多，存在的缺陷越多 D)软件测试可以证明软件的质量 2、一个测试用例由哪几部分组成 (ABC ) A) 测试输入 B) 执行条件 C)期望结果 D) 优先级 3、在选择需要自动化执行的用例时，需要检查哪些项? BCD A) 高优先级别的UAT测试用例 B)
界面测试规范 目前流行的界面风格有三种方式：多窗体、单窗体以及资源管理器风格，无论那种风格，以下规则是应该被重视的。 1：易用性： 按钮名称应该易懂，用词准确，屏弃没楞两可的字眼，要与同一界面上的其他按钮易于区分，能望文知意最好。理想的情况是用户不用查阅帮助就能知道该界面的功能并进行相关的正确操作。 易用性细则： 1):完成相同或相近功能的按钮用Frame框起来，常用按钮要支持快捷方式。 2):完成同一功能或任务的元素放在集中位置，减少鼠标移动的距离。 3):按功能将界面划分局域块，用Frame框括起来,并要有功能说明或标题。 4):界面要支持键盘自动浏览按钮功能，即按Tab键的自动切换功能。 5):界面上首先应输入的和重要信息的控件在Tab顺序中应当靠前,位置也应放在窗口上较醒目的位置。 6):同一界面上的控件数最好不要超过10个，多于10个时可以考虑使用分页界面显示。 7):分页界面要支持在页面间的快捷切换，常用组合快捷键Ctrl+Tab 8):默认按钮要支持Enter及选操作，即按Enter后自动执行默认按钮对应操作。 9):可写控件检测到非法输入后应给出说明并能自动获得焦点。 10):Tab键的顺序与控件排列顺序要一直，目前流行总体从上到下，同时行间从左到右的方式。 11):复选框和选项框按选择几率的高底而先后排列。 12):复选框和选项框要有默认选项，并支持Tab选择。 13):选项数相同时多用选项框而不用下拉列表框。 14):界面空间较小时使用下拉框而不用选项框。 15):选项数叫少时使用选项框，相反使用下拉列表框。 16):专业性强的软件要使用相关的专业术语，通用性界面则提倡使用通用性词眼。 2：规范性： 通常界面设计都按Windows界面的规范来设计，即包含―菜单条、工具栏、工具厢、状态栏、滚动条、右键快捷菜单‖的标准格式，可以说：界面遵循规范化的程度越高，则易用性相应的就越好。小型软件一般不提供工具厢。 规范性细则： 1):常用菜单要有命令快捷方式。 2):完成相同或相近功能的菜单用横线隔开放在同一位置。 3):菜单前的图标能直观的代表要完成的操作。 4):菜单深度一般要求最多控制在三层以内。 5):工具栏要求可以根据用户的要求自己选择定制。 6):相同或相近功能的工具栏放在一起。 7):工具栏中的每一个按钮要有及时提示信息。 8):一条工具栏的长度最长不能超出屏幕宽度。 9): 工具栏的图标能直观的代表要完成的操作。 10):系统常用的工具栏设置默认放置位置。 11):工具栏太多时可以考虑使用工具厢。 12):工具厢要具有可增减性，由用户自己根据需求定制。