界面测试标准参考
一、概述
考虑到公司产品主要是基于图形用户界面的特点，目前也没有可行的界面测试标准。在此根据以往的测试经验作了一些总结，希望能对大家在图形界面测试时起到参考作用。
文档中提到的例子以Xxxx3.1产品为主，但此标准可是用于任何GUI软件，不必包含在功能测试用例中，而是作为独立的测试标准来执行。
二、功能测试
1、常用控件测试内容
窗口
常规检查项目：
?位置与尺寸：
1)窗口的默认打开位置是自动记忆还是始终为默认位置？
2)窗口打开后尺寸是否可调？
3)窗口标题栏的最小化、最大化、关闭按钮是否都可用？
4)窗口上的控件是否能随尺寸自动布局？
5)About窗口显示正常吗？
?模式
1)窗口是模态还是非模态
2)窗口是否允许拖动？
3)窗口如果不允许拖动，又是模态的，那是否会挡住后面的内容？
4)窗口如果是非模态，是否重复操作会弹出多个？
5)窗口如果是非模态，直接关闭主窗口是否会导致异常？
?响应
1)窗口标题栏执行关闭窗口，与退出按钮执行的是同样的代码吗？
2)窗口直接按下Enter键触发的操作安全吗？是否直接关闭窗口？
3)窗口是否支持Esc键来关闭窗口？
4)窗口如果支持Esc键，则关闭时是否提示保存数据？
5)窗口使用Alt+F4键来关闭时，是否跟Esc或者关闭按钮走同一套代码？
6)窗口关闭时是否会提示保存修改的数据？
7)窗口是否只是提示性的？使用Alt + F4关闭窗口后是否影响功能使用？
8)窗口打开时，胡乱地按下键盘，会有什么结果？F1~F12功能键呢？
?刷新
1)窗口是否支持拖动？
2)窗口最小化后再打开，界面显示是否跟最小化之前一样？
3)窗口拖动时各控件的显示是否正常？
程序员经常犯的错误：
1)窗口尺寸本应是固定的，但程序员忘记做限制。比如标题栏中还有最大化按钮，
窗口可以使用鼠标拖放来改变尺寸。而界面一般都没有对改变后的尺寸做重新
布局。
2)本应弹出模态窗口，由于代码疏忽，或者由于别的功能影响，窗口只针对其上
一级父窗口是模态，而对于更上一级窗口可能变成非模态。此时关闭主窗口往
往会导致崩溃。这类问题出现很多，多见于连续有多层窗口的情况，或者对界
面整体架构做调整导致。
举例：
?Xxxx在升级工程时，会首先弹出提示信息。而这个信息本应该是模态，但却变成了非模态，此时关闭当前工程会导致开发系统崩溃。
?Xxxx在执行编译时，在IOServer未启动时编译模型会弹出提示信息，这个提示本来是模态的，但由于编译功能或其他模块的影响，该提示只针对编
译窗口（其父窗口）是模态，而对于SCADA主界面是非模态，此时操作主
界面的菜单，比如关闭工程也会导致开发系统崩溃。
?启动xxxx运行系统时，弹出的进度窗口使用Alt + F4关闭后，系统仍然启动成功。也就是用户无法停止系统启动。
3)对于非模态窗口，程序员忘记对唯一性做判断，导致重复操作打开多个窗口。
4)对于非模态窗口，程序员对于主窗口销毁时的处理不当，还没有关闭的非模态
窗口导致崩溃
5)窗口忘记屏蔽Enter键。用户以为回车键会存盘，其实是取消保存并关闭窗口。
（Enter键默认会触发界面的OnOK()方法，导致窗口关闭，可能丢失数据。）
6)窗口关闭时没有提示用户保存数据
按钮
常规检查项目：
?外观：
1)按钮上的文本是否会随着状态而改变？
2)按钮的尺寸是否跟别的按钮一致？
3)按钮是否具有鼠标自动提示功能？
4)按钮上是否带有图标？图标显示是否正常？
?响应：
1)按钮执行的操作是同步还是异步？
2)按钮是窗口的默认按钮吗？
3)按钮是否配置了快捷键？
4)按钮使能状态是否受别的功能影响？
5)按钮是否支持Tab键定位？
6)按钮被快速多次压下时，响应速度怎样？是否会导致异常？
7)按钮是否具有“应用”功能？应用后再取消保存，信息会保存吗？
程序员经常犯的错误：
1）设置了不合适的按钮作为默认按钮，比如关闭按钮。可能程序员只是图省事，使用窗口创建时自带的OK按钮，或Cancel按钮。这类问题多见于小工具开发
中，因为大型软件中一般都会对资源做提取，会检查出这类问题。
2）按钮文本随状态改变，但显示的文本与状态不匹配。
3）按钮执行的是异步操作，但没有对上一次操作是否完成做判断，导致用户连续点击按钮产生异常，严重的会导致崩溃。这项内容跟具体功能有关，与按钮控
件本身关系不大。
菜单
常规检查项目：
?外观
1)菜单使能状态是否受别的功能影响？
2)菜单状态是否为0、1逻辑状态控制？菜单是否有复选框？
3)菜单上是否会显示图片、图标等信息？是否有的菜单有图标，有的没有？
4)菜单的层次清晰吗？深度是否合适？
5)菜单按功能合理分类了吗？
6)菜单中的About窗口显示正常吗？
?响应
1)菜单栏可以被拖动吗？
2)菜单在鼠标滑过各菜单项时，在鼠标右侧是否有提示信息？
3)菜单在鼠标滑过各菜单项时，在界面的状态栏是否有提示信息？
4)菜单中所有功能都实现了吗？是否会有点击后没有任何结果的情况？
5)菜单文本是否会随着菜单状态或周围环境而改变？
6)菜单的数量是否会随着使用发生变化？
7)菜单会自动隐藏部分功能吗？
8)菜单执行会影响到别的菜单状态吗？
9)菜单功能在界面上使用别的控件能完成吗？
10)菜单设置快捷键了吗？
11)菜单快捷键有重复吗？
程序员经常犯的错误：
1）菜单使能状态与外界逻辑对应不上
2）菜单很多的情况下，快捷键设置会有重复，或跟界面某控件的快捷键重复
文本框
常规检查项目：
?外观显示
1)文本框的尺寸是否合适？是否能容纳下最大长度字符？
2)文本框中的文本字体是否合适？
3)文本框的使能是否受外界状态的影响？
4)文本框的文本背景和前景颜色是否会随数据或周围状态而改变？
5)文本框的字体是否支持特殊字符的显示？比如制表符等
?文本内容
1)文本框支持的数据是什么类型？数字、文本还是别的类型？
2)文本框只允许输入数字时，数字的取值范围是多少？
3)文本框输入非法字符是否会及时提示，并消除这一字符？
4)文本框提示数据有错误后有没有作出处理？此时保存数据会导致异常吗？
5)文本框是否支持全角字符输入？特别是数字时需要做此验证
6)文本框中使用Ctrl + V执行粘贴后，是否能及时对数据作合法性验证？
7)文本框中的内容是否被锁定？锁定是简单的灰显还是保留选择、复制的功能？
8)文本框是否屏蔽了复制和粘贴功能，只允许键盘输入？
?文本长度
1)文本框所能容纳的字符串最大长度是多少？
2)文本框当文本达到最大长度时，是禁止输入还是只提示一下？
3)文本框中内容超长的情况下执行保存会导致异常吗？
4)文本框在输入内容达到其显示范围时能否自动滚动？还是干脆禁止了输入？
5)文本框中输入英文字符与汉字是否都支持同样的长度？
6)文本框在用户输入字符时是否实时检测长度？
?密码功能
1)文本框中输入的如果是密码，当Caps Lock键处于激活状态，是否会提示用户？
2)文本框用于显示密码时，是否会显示出密码的长度？有长度信息不太安全。
3)文本框如果显示空密码，默认打开后文本框是否显示为空？
4)文本框用于显示密码时，是否支持复制粘贴？
?多行显示功能
1)文本框是否支持多行显示？
2)文本框支持多行文本的自动换行吗？
3)文本框换行是怎么实现的？Enter键还是Ctrl + Enter、Alt + Enter？
?其它功能
1)文本框是否会自动转换大小写？
2)文本框的文本变化时，是否会触发别的什么操作？比如实时查询
3)文本框有自定义的右键菜单吗？如果有，功能都是什么？
4)文本框是否支持用户自定义格式？比如设置文本颜色、字体等。
5)在文本框中执行回退操作（Ctrl + Z）是否正常？
程序员经常犯的错误：
1）文本框不限制输入长度，只是保存时验证。严格地说这不算错误，但往往就是字符串达到一定长度时，再执行保存导致系统死机或崩溃。
2）文本框在键盘输入时能验证非法字符，并禁止输入。但是用Ctrl + V执行粘贴，则没有提示，只是保存时提示错误。这类情况似乎无法避免，但也是测试人员应关注的内容，因为此时保存往往会出现连续弹出两个相同提示的现象。
3）文本框显示密码时没有掩盖密码长度。
4）文本框支持很长的文本，但当文本超过显示范围时，没有自动出现滚动条。用户需要使用键盘或鼠标来移动光标位置。
5）文本框支持换行，但需要使用Ctrl + Enter，只是在任何地方都没有做说明。一
般客户会以为不支持换行。
6）为了编程方便，对于不允许输入的文本框简单的灰显掉，用户无法从文本框中复制内容，使用很不方便。
7）文本框显示多语言时会显示不全，特别是英文
8）文本框中只允许输入数字，但清空这个文本框，直接执行保存，往往会连续弹出两个相同的提示。
列表框（ListBox、ListView）
常规检查项目：
?显示及布局
1)列表框是否支持多种显示方式（小图标、大图标、列表、详细信息）？
2)列表框是否支持鼠标点击列标题后按列排序？
3)列表框标题列缝隙在鼠标双击时应自动适应文字宽度，并显示横向的滚动条
4)列表框失去焦点时，当前选中项背景颜色会变化吗？
5)列表框失去焦点时，当前选中项如果变为浅色，是否意味着不被选中了呢？
6)列表框如果支持选中后输入，那么输入编辑框的字体跟列表字体是否一致？
?操作与响应
1)列表框单击执行什么操作？
2)列表框双击执行什么操作？一般会执行添加或查询等功能
3)列表框如果支持双击，选中一项后按下Enter键是否同样完成双击的功能？
4)列表框如果支持单击，那么不用鼠标，而使用键盘也应触发这一事件
5)列表框在鼠标左键单击或双击列表的空白处时，会出现什么结果？
6)列表框在鼠标右键单击选中项时，弹出菜单中有什么功能？
7)列表框在鼠标右键单击空白处时，弹出菜单中是否应该隐藏某些菜单？
8)列表框在鼠标慢速双击单元格时，是否会变成可输入状态？
9)列表框是否支持选中后连续操作？比如选中一条后连续移动、连续删除
10)列表框中选项如果移动，那移动到边界时会怎样？移动操作是否被禁止？
11)列表框中增加或删除行时，以前选中的项目是否还有效，还处于焦点状态吗？
12)如果列表框支持选中后输入，那么如果等输入框出来后，使用鼠标滚轮使列表
上下滚动，输入框是否会跟随移动，还是自动消失？
13)鼠标放在列表项上时，是否有列表项的信息出现？显示的信息是否完整？
?多重选择
1）列表框是否允许多项选择？（1、Shift 2、Ctrl 3、框选）
2）如果支持多选，则多选后有哪些批量操作？（复制、粘贴、删除等）
3）当各种操作使列表框选项失去焦点时，其单击操作导致的后果是否还有效？比如列表框点击后在别的控件中要显示相关内容，但失去焦点时并没有清空这些
内容，如果这个时候执行跟列表框有关的操作，是否会导致列表框找不到当前
行？
程序员经常犯的错误：
1)列表框使用了鼠标单击事件，而不是选项变化事件，导致键盘控制选中项时，
虽然被选中，但并没有执行相关联的操作。
2)列表框忘记屏蔽其控件自带的输入功能，导致鼠标慢速双击单元格或选中单元
格后变为可输入状态，但此时输入可能会导致严重的后果，比如程序崩溃
3)程序代码中并没有支持批量操作，但程序员却把列表框设置成可以多选状态。
此时用户多选后执行操作，其实只对第一项有效。
4)列表框焦点选项没有锁定，导致用户每操作一次就要重新点击一次列表，无法
实现连续操作。
5)窗口最大化或最小化，重新激活窗口后可能会导致列表框失去焦点
6)用户在列表框单击鼠标右键时，菜单状态并没有及时更新，原有列表选中项仍
然处于选中状态
7)各窗口的列表框控件中，部分实现了按列排序，部分未实现
8)只对列表框中第一列实现了鼠标点击排序，其它列无效
9)用户习惯于鼠标从右下角向左上开始框选，而此时生成的选项列表是按照被选
中顺序的，而不是用户直观看到的显示顺序。这样实现虽然不算作错误，但多
少跟用户的预期结果有些偏差。比如，执行批量复制操作，会导致粘贴后的顺
序跟原来的显示顺序正好相反。
10)执行添加或删除操作时，会触发列表刷新，导致当前选项失去焦点，此时基于
选中项的各操作可能会出现异常。
组合框
常规检查项目：
?外观
1)组合框的宽度是多少？各项目是否都能完整显示？
2)组合框的下拉高度是多少？在选项较多时查看方便吗？
3)组合框的数据来自于其它模块吗？那个模块限制的长度与组合框一致吗？
4)组合框的使能状态是否受外界状态影响？
?操作
1)组合框触发的是选项变化开始事件（鼠标点击时）还是变化完成事件（提交
后）？
2)组合框是否支持输入？输入后，其他操作需要组合框的文本时，是否能正确返
回当前文本？
3)组合框中手动输入已有的选项内容，是否同样会触发鼠标点击所做的操作？
4)组合框中手动输入已有的选项内容，再执行与选项有关的操作，能否正确定位
到选线的索引？
5)组合框选中后如果触发其它操作，那么使用键盘控制也能达到同样的效果吗？
6)组合框是否能自动记录用户输入的内容？
7)组合框的文本变化如果会触发相关操作，那使用Ctrl + V粘贴生成的文本呢，
是否也能达到这个效果？
8)组合框在鼠标选择一项后，手动修改文本内容，再执行与选项有关的操作，此
时提取的文本是修改后的还是选项内容？
程序员经常犯的错误：
1)组合框无意中设置成了界面打开时的默认选中控件，用户使用键盘时会导致选
项变化。
2)部分场合不适合开放组合框的可编辑功能，但程序员忘记屏蔽。组合框中的内
容必须合法，比如选项只有“true”和“false”，却允许手动输入，导致功能具
有歧义。
3)程序员使用的是组合框选项鼠标点击事件，这会导致使用键盘来控制选项变
化，尽管文本显示已经变化，但对应选项变化应该触发的事件没有触发。
4)程序员在组合框选项变化时保存了选项值，尽管用户手动修改了文本，程序使
用的仍然是原来的选项值。
5)组合框支持自动记录用户输入，但没有对记录的内容做重复性判断。
6)组合框支持自动记录用户输入，但关闭窗口后再打开则数据丢失。
树形控件
常规检查项目：
?外观与显示
1)树形控件是否显示图标？打开和关闭节点的图标一样吗？
2)树形控件默认的节点是什么？
?操作
1)树形控件允许使用的节点文本最长字符是多少？
2)树形控件使用的节点文本是否屏蔽特殊字符？
3)树形控件运行期间是否支持修改节点文本？
4)树形控件在使用键盘操作能否达到鼠标操作的效果？
5)树形控件是否支持节点拖放？
6)树形控件节点是否有右键菜单？各节点的右键菜单一样吗？
7)树形控件是否支持增减节点？节点数量变化是否影响原来选中的节点？
8)树形控件点击各级节点是否都有对应的触发操作？
9)树形控件支持节点双击操作吗？
10)树形控件使用右键单击节点，是否会首先触发左键单击事件？
11)树形控件最深时会有多少级？达到最深时节点选中、双击等操作正常吗？
12)树形控件根节点可以创建多少个？
13)树形控件每一级父节点下最多可以有多少子节点？
14)树形控件的各级节点名称是否要验证重复？
15)树形控件为空时，鼠标右键菜单有什么变化吗？
16)树形控件空白处在鼠标单击、双击或右键单击时，触发的操作各是什么？
程序员经常犯的错误：
1）没有屏蔽树形控件自带的编辑功能，鼠标慢速双击节点，即变为可编辑状态，但输入的内容不一定被接受
2）非叶子节点也有触发事件的情况下，程序员使用的鼠标双击事件，跟双击打开或关闭节点冲突
3）程序员使用的是鼠标点击节点事件，用户使用键盘控制焦点在各节点间移动时，没有触发操作
4）树形控件只处理了左键单击事件，而用户使用右键单击时没有首先激活左键事件，会导致当前节点信息错误，执行右键菜单产生意外。
5）树形控件在增减节点时，会丢失以前的选中项信息，原来的节点恢复成未选中状态。
选项卡
常规检查项目：
?外观
?选项卡共多少个？
?在选项卡很多时是横向排列显示还是纵向层叠？
?选项卡的标题文本能显示完整吗？
?界面打开时显示的默认选项卡是最左侧的吗？是最常用的吗？
?选项卡中的控件布局怎样？过于拥挤还是过于宽松？
?操作
1)选项卡切换时是否会自动验证数据？
2)选项卡切换时是否会自动保存数据？
3)选项卡切换如果能自动保存数据，执行“取消”关闭界面，数据还有吗？
4)选项卡如果能自动保存，那修改数据并切换后，点击“取消”操作会怎样？
5)选项卡之间有关联吗？一个选项卡中内容改变是否会影响别的选项卡？
6)选项卡之间数据的填写和操作有先后顺序吗？
程序员经常犯的错误：
1)数据在当前状态下有错误，用户又不想修改，则程序会禁止用户切换选项
卡，同时禁止保存，用户无法继续操作，只能取消保存。
2)多个选项卡之间有关联，特别是这种关联关系体现到选项卡内的控件使能，
这类逻辑往往会发生错误。
单选框
常规项目检查：
?外观
1)单选框的尺寸是否合适？过短导致文本显示不全；过长导致用户误点
?操作
1)选项变化时是否会改变界面上其它控件的状态改变？
2)选项变化是否同时支持鼠标和键盘两类操作？
3)界面上如果有多组单选框，各组之间有联系吗？是否会联动？
4)默认状态显示的单选框状态是否自动触发了对应的操作？
程序员经常犯的错误：
1）单选框使用鼠标控制还是很正常，换到键盘则会出问题，比如同时有多项被选中，键盘控制时没有触发对应的操作
2）单选框尺寸过长
复选框
常规项目检查：
?外观
1)跟单选框的尺寸问题一样，过长则会使用户误操作，过短则显示不全
?操作
1)复选框的使能状态是否受外界操作的影响？
2)复选框选项变化时是否会改变界面上其它控件的状态改变？
3)复选框能否使用键盘控制？
4)复选框有没有中间态？
也就是介于选中和未选中之间的状态，这类用法多见于一个复选框控制其
下所属的多个复选框，形成父子关系。选中或取消父框，其子框都变成跟
父框相同的状态
程序员经常犯的错误：
1)复选框尺寸过长
工具栏
常规检查项目：
?外观
1)工具栏按钮的图标能正常显示吗？
2)工具栏按钮的图标跟菜单中对应功能的图标一致吗？
3)工具栏按钮上是否显示文字？各种语言的文字都能显示完整吗？
4)工具栏按钮是否按功能做了合理的分组？
?操作
1)工具栏按钮上在鼠标进入和移出时显示的图标颜色一样吗？
2)工具栏按钮在鼠标靠近时是否会显示提示信息？提示信息长度合适吗？
3)工具栏按钮在鼠标靠近时在状态栏是否会显示按钮的相关信息？
4)工具栏可以被拖动到界面之外吗？
5)工具栏按钮的使能状态在各种情况下显示正常吗？（依照具体功能）
6)工具栏是否支持点击后显示下拉菜单？
7)工具栏的宽度是否合适，过宽会导致鼠标误拖动。
8)工具栏显示内容是否允许定制？
9)工具栏显示内容定制后是永久保存还是运行期间有效？
10)工具栏按钮定制永久保存时写入的是注册表还是配置文件？
状态栏
常规检查项目：
?外观
1)状态栏都能显示哪些信息？也就是那些操作在状态栏显示信息？
2)状态栏显示的信息里面有实时更新的吗？比如当前时间、NumLock状态
等。
?操作
1)状态栏指定的项目被双击后是否会激活一些操作？打开一些界面？
2)状态栏是否显示可以配置吗？
标签文本
常规检查项目
1)标签文本的长度能显示出最长的文本信息吗？
2)标签文本的前景、背景颜色配置合适吗？是否易于识别？
3)标签文本的前景、背景颜色会随着显示内容而不同吗？
4)标签文本如果显示超过其控件长度的信息，会有怎样的效果？
5)标签文本的对齐方式一致吗？
6)标签文本如果只用来显示固定文本，标签长度是否过长？
7)标签文本是否支持鼠标选择、复制？
8)标签文本是否有错误别字，是否有歧义？
9)标签文本使能状态是否受外界影响？
10)标签文本如果用来显示状态信息，当状态消失时，文本内容会改变吗？
11)标签文本如果用来显示状态信息，当状态变化很快时，文本更新及时吗？
12)标签文本如果用来显示状态信息，当界面处于僵死状态，文本还更新吗？ 通用对话框
常规检查项目：
?打开文件对话框
1)打开文件对话框的标题是什么？显示正确吗？
2)打开文件对话框的默认路径是什么？跟上一次打开有关吗？
3)打开文件对话框的文件类型是否显示完整？是一个扩展名还是多个？
4)打开文件对话框中输入*.*，然后选择一个非指定类型，程序会出错吗？
5)打开文件对话框输入一个不存在的文件，点击“打开”，会出错吗？
?保存文件对话框
1)保存文件对话框的标题是什么？显示正确吗？
2)保存文件对话框的默认路径是什么？跟上一次打开有关吗？
3)保存文件对话框的文件类型是否显示完整？是一个扩展名还是多个？
4)保存文件对话框中选择一个已存在文件，会有什么提示？程序会出错吗？
5)保存文件对话框中输入非法的文件名，执行保存，会怎样？
6)保存文件对话框中输入没有扩展名的文件名，能保存吗？
7)保存文件对话框中输入没有扩展名的文件名，保存的扩展名是什么？
8)保存文件对话框中输入含有非法扩展名的文件名，能保存吗？
9)保存文件对话框中输入含有非法扩展名的文件名，保存的扩展名是什么？
10)保存文件对话框出现后，“文件名”位置有默认的名称吗？包含扩展名吗？
11)保存文件对话框出现后，默认的文件名是合法的吗？
12)保存文件对话框中将路径选择到一个只读文件夹，能保存吗？
?选择路径对话框
1)选择路径对话框的标题是什么？显示正确吗？
2)选择路径对话框中有“新建文件夹”选项吗？能正常使用吗？
3)选择路径对话框打开的默认路径是什么？跟上一次打开有关系吗？
日历（待完善）
时间控件（待完善）
日期控件（待完善）
IP地址框（待完善）
2、界面控件连锁
当界面中设计了复杂的连锁关系，往往会产生混乱，特别是控件较多时。最经典的例子就是Xxxx下编辑变量的IO属性时，采集器、数据块、寄存器、数据类型、采集频率之间的连锁关系错综复杂，经常因为连锁不及时造成异常。
一方面建议设计和开发人员尽量避免这类复杂连锁的界面，另一方面无法避免这类设计时，首先要从原理上搞清楚这些连锁关系，然后通过不断尝试来探索测试。
常规检查项目：
1）一般触发连锁反应的控件有：列表框、组合框、单选框、复选框、按钮。
2）键盘能实现跟鼠标同样的控制效果
程序员经常犯的错误：
1)会忘记处理键盘操作。
2)各类连锁考虑不全，导致连锁触发过程中控件状态和显示内容错误。
3)开发和设计最初没有考虑到这种界面连锁的复杂性，随着功能的变化，逻辑限
制也在不断增加，最终导致界面过于复杂无法使用。
3、界面默认值
常规检查项目：
1)默认值尽量合法，不用使用者手动改变就可以使用
2)默认值必须安全，用户不修改默认值的情况下可以长时间使用软件，不会造成
系统资源耗竭，或数据丢失。
3)默认值尽量完整，用户不用再补充数据就可以正常使用软件。
4)打开界面后，焦点默认安放位置：
?用户必须作出修改的数据
?用户必须首先填写的数据
?用户最容易用到的功能
?执行“保存”功能的按钮
?如没有可保存的数据，则焦点应放在“关闭”功能的按钮上程序员经常犯的错误
1)默认值有数据，但是错误的数据，用户必须修改。
2)默认值关闭了用户常用的一些功能，却没有在醒目的地方提醒用户。
3)默认值没有根据用户软硬件环境自动调整，这些默认值可能会耗尽系统资源。
4、界面提示信息
常规检查项目：
1)弹出式提示需要检查：
?图标使用是否合理
?是否为模态窗口
?提示的标题是否正确？
2)提示信息的内容：
?信息是否明确？是否会引起歧义？
?如果是错误信息，是否告诉了用户错误的原因，以及采取的措施？
?提示信息的语气应中性，而不应带有任何感情色彩
?提示信息中尽量不使用感叹号
?提示信息简洁明了
?提示信息中不应使用口语化词汇，比如“么？”
?提示信息中不应使用程序员词汇，比如句柄、接口、调用等等。
程序员经常犯的错误：
1)弹出式提示框图标的滥用
2)提示信息没有正规标题，显示的是应用程序名称
3)提示中只显示操作失败，却不告诉用户为什么失败和如何补救
4)提示信息中显示数据非法，却不告诉用户合法的数据是什么样
5)提示信息中使用感叹号
6)提示信息中使用过于口语化的词汇，比如“你确定么？”
7)没有对第三方开发包异常作出处理，比如弹出提示“不支持的操作”
5、界面与其他功能交互
常规检查项目：
1)本功能的使用是否必须首先启用别的功能？
2)被测界面中的数据来自于别的什么模块？
3)本模块的数据跟数据来源模块是否有硬性关联，比如删除了数据来源，或改变
了数据来源的属性，本模块还正常吗？
4)使用当前模块的时候能否直接创建出别的模块需要的数据？
程序员经常犯的错误：
1)功能之间有关联关系，但分属于不同的界面。任何地方都没有提示出这种关联，
只是打开界面后部分功能被禁用，原因是别的配置还没做好。
2)本界面中的数据来自于别的模块，但由于两个模块对数据合法性验证不一致，
导致传递的数据不完整或不可用。
3)本界面使用需要依赖于别的界面，却无法直接进入那个界面，需要用户关闭本
界面，配置完后再回到这里。这样的设计虽不算错误，但至少说明程序员没有
考虑到这种界面切换对用户工作量的增加和理解难度的加大。
6、用户场景设计
用户场景用于捕获测试用例无法覆盖的场景，随意性较强，但这类场景最容易发现产品的细微逻辑上的错误。
常规检查项目：
1)模拟强迫症用户，反复执行同一个操作，反复查看
2)模拟健忘症用户，提供不完整的数据，或其他环境条件不具备，执行操作
3)模拟心急的用户，这类用户在执行耗时较长的操作时缺乏耐心，会关闭软件，
甚至强行杀掉进程，可能会导致用户数据丢失，乃至工程破坏
4)模拟繁忙的用户，这些用户误操作很多
5)模拟最无聊的用户，拿起鼠标在软件上一顿狂点，没有任何目的
6)模拟误删除部分文件，查看软件能否恰当的提示出这些信息
7)寻找对话框弹出层次最多的路径
8)寻找完成一项任务的所有方式，比如创建变量
9)寻找完成一项任务经历步骤最多的途径
10)利用软件完成一件综合任务，尽量用上所有功能
11)挖掘软件中最不起眼的功能，很多人都不知道的功能
12)跟踪一项数据，挖掘出跟这项数据所有的功能
13)模拟后悔的用户，即执行操作时重点关注“取消”操作
14)清空软件的所有内容，查看在这种极端情况下是否有可用的功能，这些功能很
可能就是应该禁止而未禁止的
15)从第三方软件复制一部分信息，到被测软件中粘贴，如果支持格式粘贴，可能
会有问题。
16)用户会用到各种汉字输入法，有些输入法会导致软件的脚本编辑器显示出错。
17)用户会使用各种杀毒软件，这些杀毒软件可能禁用产品的部分功能，却没有提
示。
18)用户可能根本不安装杀毒软件，已经病毒成群时还在使用产品，各种意外的都
可能出来，是考验软件健壮性的时候。
19)用户的网络环境可能比较特殊，比如有些网络内有严格的网络监控、流量限制
等，这些限制可能会影响产品的使用，特别是界面需要监测网络信息时。
20)用户的数据库可能已经非常庞大，或数据库服务器本身性能低下，我们的产品
再加上去后也会受到影响。
21)用户自己开发的OCX控件或DLL可能不规范，或者安全性做的不好，导致我们
的产品加载这些东西时无法正常运转，严重的可能会破坏用户数据。
程序员经常犯的错误：
1）忘记对用户取消操作做适当的处理，结果往往是“取消”操作未起作用，或者系统崩溃
2）软件中各项功能忽略了考虑没有任何用户数据的情况，部分功能未禁止三、性能测试
界面上的性能表现直接反映的是界面设计和开发人员的智慧。
常规检查项目：
大数据量浏览
1)预加载数据较多时，打开窗口的时间是否可以接受？
2)列表类控件（列表框、组合框、网格控件等）加载的性能
3)鼠标批量选择对象的性能
4)浏览大量数据时，能否顺畅的切换页面
5)浏览大量数据时，内存占用怎样，数据销毁后能否释放内存？
超时功能
1)界面加载时如果需要检测外界软硬件环境，这个检测有超时吗？
2)界面执行某项操作时，如果需要检测软硬件环境，这个检测有超时吗？
3)操作耗时较长时，是否进入僵死状态？
4)操作耗时较长时，有没有及时提示用户操作的进度和剩余时间？
其他性能
1)界面是否会执行多线程任务？这种任务安全吗？对界面影响怎样？
2)界面加载时，内存、CPU占用分别怎样？
3)反复打开窗口，查看GDI资源是否会上升？内存是否会上升？
程序员经常犯的错误：
1）执行多项选择时，每选择一个执行一次处理，当一次选择大量数据时性能无法满足要求
2）界面执行长时间操作时，没有适当的提示信息
3）界面执行长时间操作时，界面僵死
4）预加载列表或其他数据时，没有考虑过性能，导致窗口无法正常显示
5）执行长时间操作时，如果是异步操作，又没有对界面控件使能状态做限制，用户就可能作出某些操作，甚至关闭窗口，导致系统异常
四、易用性检查
易用性已经形成一门包含人机工程学、心理学在内的综合性学科，内容庞杂。
在此只列举出正规软件必须满足的易用性条件，至于更高的要求需要每个人需要进
行系统的学习，并且在使用过程中去体验。
易用性的作用在于缩短用户学习时间，降低用户出错的几率，让用户在使用过程中兼有愉快的体验，同时提高产品的整体形象。
1、界面信息可读性强，减少学习负担
常规检查项目：
1)图标设置尽量贴近功能，不要设计稀奇古怪的图标。
2)图标上的图案和尺寸合适，用户可以不费力的识别图标细节。
3)图标之间可识别性强，不要设计容易混淆的图案。
4)界面文字尽量贴近用户，避免使用程序员语言。比如客户需要读取数据库的一
段数据，就不要告诉客户需要创建多少“句柄”。
2、界面布局
常规检查项目：
1)Tab键能否在界面控件上顺利切换焦点，且切换顺序符合功能操作顺序。即按
照控件使用频率和控件之间的联系程度进行排序。不同的功能有不同的要求。
如果摒弃功能不谈，应满足最基本的要求：从左到右，从上到下。
2)界面上是否根据用户使用频率对各控件进行合理布局。一般最常用的功能应放
置在最显眼的位置。可根据界面位置区分重要性：左上、右上、左下、右下。
当然，对于SCADA之类的使用左侧树形结构导航的软件，不一定按照上述标准。
这时候最显眼的位置就是右侧对象浏览区，在这个区域再按照上述规则排序。
3)控件尺寸合适。主要考虑以下几方面：
a)信息显示控件能显示出常规长度的信息。比如使用文本框显示输入输出的
信息时，最大长度限制到100，用户常用长度为70，则控件至少要能完整
显示70个长度的字符，不需要用户滚动鼠标。
b)操作类控件不易过小。因为过小的控件鼠标不容易定位和点击，操控性较
差。一般软件对按钮尺寸都有严格的规定，程序员也不会擅自修改。但其
他类控件可能管理比较混乱，比如列表框、组合框等等。
4)界面布局整齐，按照功能将界面划分出区域。
5)根据功能使用频率对系统进行布局，经常用的功能放在很容易找到的位置。
6)界面上文本对齐方式一致，不要左对齐和右对齐混用。同时也要跟整个产品的
风格一致。
3、颜色方案
常规检查项目：
1)界面尽量避免使用艳丽的纯色调，对应到RGB值就是避免使用纯红（255,0,0）
纯绿（0, 255,0）和纯蓝（0,0,255）这三个颜色。因为这三类颜色视觉感官很差，
特别是配合别的背景时不易识别，还给人以不安的感觉。
2)前景颜色与背景颜色对比度合适。对比过小则不易识别，对比过大则让人觉得
不舒服。
3)界面使用颜色区分功能时，颜色种类不宜超过3，否则给人杂乱的感觉。且各
颜色应属于同一色系，比如暖色调、冷色调、温色调等。具体数值可参阅相关
资料。
对于工业自动化产品，建议使用冷色调，以蓝色为主，让用户在使用时保持平
和、冷静的心态。
程序员经常犯的错误：
1)直接使用系统提供颜色，虽不算作错误，但用户体验较差。
4、操作方便
软件系统的易用性很大程度取决与操作的方便性，所以这一部分是检查的重点。3.1.尽量精简操作步骤，让用户省事
常规检查项目：
1)完成一项任务尽量在一个界面中完成，减少切换次数。
2)完成一项任务尽量使用同一个输入设备，比如键盘或鼠标，减少鼠键的切换次
数。
3)操作如果需要外接数据支持，则要提供不离开本界面直接编辑外界数据的功
能。
4)如果客观条件限制，用户无法完成预期的任务，应尽早提示出来，免得用户填
写了大量信息，最后无法提交。
比如一些网站，查看帖子要注册用户，可等到用户填写了很多注册信息，最后
提交时网站提示“暂停注册新用户”，用户会感觉很沮丧。
5)完成一项任务，如果出现了多条错误，则应在操作完成后统一输出，而不是每
次都弹出一个提示框。当然，这样做的前提是每个提示框只是纯粹的提示，不
具备取消操作或改变执行路径的功能。
3.2.尽量增强软件的可操控性，让用户放心
常规检查项目：
1)浏览大量数据时，提供方便的查找功能。
a)列表提供根据名称排序功能
b)列表提供输入开头字符自动定位功能
c)列表提供显示条件过滤功能，让用户分类显示
d)列表内容较多时提供分页显示功能，并支持跳转到指定页
2)软件运行期间及时报告用户运行状态，包括正常信息与异常信息。
3)对于用户所做的错误配置或不合适的配置给出适当的建议。比如用户开辟缓存
时没有考虑当前内存和硬盘空间，软件应及时对这类问题给出提示，以保证不
会形成隐患。
4)对于存在潜在危险的操作应及时提示用户确认操作，比如初始化配置、删除数
据等。
5)当用户反复修改了信息，导致出了问题，系统应提供恢复成初始状态的功能。
6)可以设置自动保存配置，防止用户忙起来忘记存盘。
7)系统输出信息可控。比如日志信息，用户应可以选择输出哪些日志，而不会淹
没在信息的海洋里，找不到自己需要的东西。
8)如果操作耗时比较长，应尽早提示出来，并提供预期剩余时间，不要让用户空
等。
9)尽量提供用户配置信息的统计结果，让用户心里有底。比如用户已经创建了多
少变量，其中有多少记录历史、报警等。
程序员经常犯的错误：
1)使用假的或错误的信息避免欺骗用户。比如进度条，准确的显示进度可能开发
工作量会比较大，于是程序员就会设计一个假的进度条在那里滚动，其实进度
信息根本就是假的。
2)界面设计时没考虑到用户的易用性，单纯从代码实现的简单考虑。比如浏览列
表时算法简单，但数据量大时可操控性很差。
3)不提供给用户初始化设置的功能。
3.3.做软件擅长的事情，减轻用户记忆负担
常规检查项目：
1)记住用户输入过的信息，提供选择列表，而不是再次手动输入。
2)记住用户所做过的操作，便于日后查错。
3)记住用户经常使用的配置，作为首选项。
4)一次需要用户记忆的提供的信息单位不多于7个。
5)用户任何时候遇到疑难问题，按下F1就可以获得当前功能的帮助信息。3.4.考虑现场环境和用户特点
常规检查项目：
1)同样的功能，使用鼠标能完成，如果现场没有鼠标，能否使用键盘代替呢？
2)同样的界面，在不同分辨率下应该都能正常显示。
3)同样的界面，在不同位数（16位和32位）的颜色下都能正常显示。
4)同样的界面，在Windows系统配置不同主题时都能正常显示。
界面设计测试规范 目前流行的界面风格有三种方式：多窗体、单窗体以及资源管理器风格，无论那种风格，以下规则是应该被重视的。 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):工具栏要求可以根据用户的要求自己选择定制。
{ 项目名称} { 测试用例标题} 机构公开信息
版本历史
目录 0. 文档介绍 (5) 0.1文档目的 (5) 0.2文档范围 (5) 0.3读者对象 (5) 0.4参考文献 (5) 0.5术语与缩写解释 (5) 1. 接口－路径测试用例 (6) 1.1被测试对象（单元）的介绍 (6) 1.2测试范围与目的 (6) 1.3测试环境与测试辅助工具的描述 (6) 1.4测试驱动程序的设计 (6) 1.5接口测试用例 (6) 1.6路径测试的检查表 (7) 2. 功能测试用例 (8) 2.1被测试对象的介绍 (8) 2.2测试范围与目的 (8) 2.3测试环境与测试辅助工具的描述 (8) 2.4测试驱动程序的设计 (8) 2.5功能测试用例 (8) 3. 健壮性测试用例 (9) 3.1被测试对象的介绍 (9) 3.2测试范围与目的 (9) 3.3测试环境与测试辅助工具的描述 (9) 3.4测试驱动程序的设计 (9) 3.5容错能力/恢复能力测试用例 (9) 4. 性能测试用例 (10) 4.1被测试对象的介绍 (10) 4.2测试范围与目的 (10) 4.3测试环境与测试辅助工具的描述 (10) 4.4测试驱动程序的设计 (10) 4.5性能测试用例 (10) 5. 图形用户界面测试用例 (11) 5.1被测试对象的介绍 (11) 5.2测试范围与目的 (11)
5.3测试环境与测试辅助工具的描述 (11) 5.4测试驱动程序的设计 (11) 5.5测试人员分类 (11) 5.6用户界面测试的检查表 (11) 6. 信息安全性测试用例 (12) 6.1被测试对象的介绍 (12) 6.2测试范围与目的 (12) 6.3测试环境与测试辅助工具的描述 (12) 6.4测试驱动程序的设计 (12) 6.5信息安全性测试用例 (13) 7. 压力测试用例 (13) 7.1被测试对象的介绍 (13) 7.2测试范围与目的 (13) 7.3测试环境与测试辅助工具的描述 (13) 7.4测试驱动程序的设计 (13) 7.5压力测试用例 (14) 8. 可靠性测试用例 (14) 8.1被测试对象的介绍 (14) 8.2测试范围与目的 (14) 8.3测试环境与测试辅助工具的描述 (14) 8.4测试驱动程序的设计 (14) 8.5可靠性测试用例 (15) 9. 安装/反安装测试用例 (15) 9.1被测试对象的介绍 (15) 9.2测试范围与目的 (15) 9.3测试环境与测试辅助工具的描述 (16) 9.4测试驱动程序的设计 (16) 9.5安装/反安装测试用例 (16) 附录：评审意见 (16)
项目测试规范 编 制 ： 审 核 ： 批 准 ： 文 件 编 号 : 版 本 号 : 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.用户满意度=功能+___人机界面_____+响应时间+可靠性+易安装性+____信息____+可维护性+其他因素 2. ____人机交互（人机对话）____是指人与计算机之间使用某种语言、以一定的交互方式，为了完成任务进行的一系列信息交换过程。 3.软件界面设计分为____功能性设计界面____、____情感性设计界面____、____环境性设计界面____。 4.进行系统分析和设计的第一步是___用户分析_____。 5.使用较早，也是使用最广泛的人机交互方式是____交互方式____。 6.软件界面开发流程包括____系统分析____、____系统设计____、____系统实施____三个阶段 7.设计阶段包括界面的____概念设计____、____详细设计____、____原型建立____与界面实现以及综合测试与评估等8.VB 是以结构化___Basic_____语言为基础、以____事件驱动作____为运行机制的可视化程序设计语言。 9.菜单使用形式主要有____菜单操作____和____Tba控件操作____两种。 10.随着计算机图形技术的发展，以直接操纵、桌面隐喻以及所见即所得为特征的____图形用户界面____技术广泛被计算机系统采用。 11.在用VB 开发应用程序时，一般要布置窗体、设置控件的属性、___编写代码___。 12. 假定在窗体上有一个通用对话框，其名称为CommonDialog1,为建立一个保存文件对话框，则需要把Action 属性设置为__value__。 13. 计时器事件之间的间隔通过__interval__属性设置。 14. 语句“Print “5+65=”;5+65”的输出结果为__5+65=70__。 15. 设有下列循环体，要进行4次循环操作，请填空。 x = 1 Do x = x * 2 Print x Loop Until__x<=32__ 16. 下列程序段的执行结果为__2 3 5__。 x = 1 y = 1 For I = 1 To 3 F= x + y x = y y = F Print F; Next I 17. 以下为3个列表框联动的程序，试补充完整。 Private Sub Dir1_Change() File1.Path=Dir1.Path End Sub Private Sub Drive1_Change() Drivel.Path=File1.Path;Dir1.Path=Drivel.Path__[7]__ End Sub 18. 在下列事件过程中则响应该过程的对象名是cmdl，事件过程名是__窗口标题事件__。 Private Sub cmd1_Click() Form1.Caption=“VisualBasic Example” End Sub 19. 当将文本框的SelStar 属性设置为0时，表示选择第开始位置在第一个字符之前，设置为1时表示__[9]__。 20. 以下程序代码实现单击命令按钮Command1 时形成并输出一个主对角线上元素值为“-”，其他元素值为“+”第6*6 阶方阵。 Privas Sub Command1_Click() DimA(6,6) For I = 1 To 6 For J = 1 To 6 If I = J Then Print “-” Else __[10]__ End If Print A (I,J); Next J Print Next I End Sub 21. 字母B的KeyAscii 码值为65，其KeyCode码值___[11]__。 22. Visual Basic 中的控件分为3类：__[12]_、ActioveX 控件和可插入对象。
用户界面设计实例 ● 设计的系统名称：个人日常事务管理系统 ● 针对用户群是：广大电脑用户（有一定的电脑操作基础），officer 和广大学 生。 一、系统需求分析（The system requirement ） 针对officer 和学生们的需求分析，从我自身分析：对于我日常的安排我平 时会用专门的记事本记录和更改，对于日常各种事务可能会冲突或不变携带，现在针对这些需求，设计出符合此人群适合的一款系统来帮助人们更好的安排日程和完成工作。此系统是要面向个人的，同企业系统相比，此软件要力求操作简单，效率要高效，由于针对的人群是officer 和大学生，这些人都是年轻的一代人，对计算机和系统都比较了解，而且倾向于华丽的界面，但是该系统同时要解决高效，较少的操作较快地达到用户的需求。由于工作原因或计算机系统崩溃等用户在本机保存的日程安排等数据可能丢失的情况，同时，有些情况下可能无法连接网络，此系统应支持 1.、本机数据保存。2、可以上传到服务器数据库，用户注册可获得免费的空间，用户注册后，只要登录就能在随时随地获得自己的日程安排等信息。 二、系统功能定义（The function definitions ） 个人日程管理系统主要是提供个人时间日程安排系统软件，它具有相当方便的操作接口，让用户能够对所安排的行程一目了然，除去主要功能还附带了更多功能和小工具，安排的行程可以生成通行路线，并会根据天气预报提醒当天安排是否影响。而且用户可以注册，注册后用户有更多的服务，安排的日程数据可以保存到本地同时可以更新到服务器，这样用户就算到外地也可以随时查看自己的日程安排，同时其他功能有：时钟提醒、通讯录、效率评估等。 实现功能（主界面导航）： 个人日常事 务管理系统
软件测试规 1目的 确保软件产品质量，使产品能够顺利交付和通过验收的一项重要措施。 2适用围 适用于项目开发过程中的单元测试、集成测试、系统测试、业务测试、验收测试以及一些专项测试。 3职责 ?项目测试负责人组织编制《测试计划》、《测试方案》，指导和督促测试人员完成各阶段的测试工作。 ?项目组测试人员按照《测试计划》、《测试方案》完成所承担的测试任务，并按要求填写《问题报告及维护记录》。 ?测试经理依照确认规程和准则对工作产品进行确认，提出对确认规程和准则的修改意见 ?项目负责人组织测试环境的建立。 ?项目经理审核负责控制整个项目的时间和质量。 ?研发人员确认修改测试人员提交的bug。 4工作流程 4.1 测试依据 详细设计是模块测试的依据。因此设计人员应向测试人员提供《系统需求规格书名书》、《详细设计》、《概要设计》等有关资料。测试人员必须认真阅读，真正弄懂系统需求和详细设计。 4.2 制订《测试方案》 在测试之前，由项目负责人根据《测试计划》的要求，组织人员编制相应的《测试方案》，《测试方案》应包括以下容：
?测试目的； ?所需人员及相应培训要求； ?测试环境、工具和测试软件； ?测试用例、测试数据和预期的结果。 4.3 单元测试 项目开发实现过程中，每个程序单元（程序单元的划分视具体开发工具而定，一般定为函数或子程序级）编码调试通过后，要及时进行单元测试。 单元测试由单元开发者自己进行，使用白盒测试方法，根据程序单元的控制流程，争取达到分支覆盖。对于交互式运行的产品，不便于进行自动测试的，可以采用功能测试的方法进行。 单元测试针对程序模块，从程序的部结构出发设计测试用例。多个模块可以独立进行单元测试。 ?单元测试容包括模块接口测试、局部数据结构测试、路径测试、错误处理测试等； ?单元测试组织原则一遍根据开发进度安排对已开发完成的单一模块进行测试； ?单元测试停止标准：完成了所有规定单元的测试，单元测试中发现的bug已经得到修改。 4.4 集成测试 编码开发完成，项目组部应进行组装测试。 集成测试由项目负责人组织策划（编写测试计划、测试用例）并实施。集成测试着重对各功能模块之间的接口进行测试，验证各功能模块是否能协调工作、参数传递及功能调用是否正常。测试采用交叉方法，即个人开发的软件应由其他的项目组成员进行测试。 集成测试过程应填写《问题报告及维护记录》，测试结果应形成《测试报告》。 4.5 系统测试 在项目开发完成之后，应对整个系统软件和硬件进行系统测试。对性能、可靠性、健壮性、压力承受力等方面分别进行评价，以验证系统是否满足
界面测试规范 目前流行的界面风格有三种方式：多窗体、单窗体以及资源管理器风格，无论那种风格，以下规则是应该被重视的。 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):工具厢要具有可增减性，由用户自己根据需求定制。
如何测试一个网页登录界面 对测试人员（尤其是web测试人员）来说，测试一个网页的登录界面常常是必不可少的测试任务。网页的登录界面测试要素少不了textbox和提交按钮，如何才能更全面的设计test case呢？ 首先，你要了解用户的需求，比如这个登录界面应该是弹出窗口式的，还是直接在网页里面的？对用户名的长度、用户名的有效性（比如是不是只能是手机号、邮箱等）密码的强度（就是是不是必须多少位，大小写，特殊字符混搭）等都有哪些要求？还有比如用户对界面的美观是不是有特殊的要求？（即是否要进行UI测试）。剩下的就是设计用例了，等价类，边界值等等。 千万要记住一点，任何测试，不管测什么都是从了解需求开始的。 一个网页的登录界面的测试大致可以从以下几个方面考虑： 功能测试(Function test) 0. 什么都不输入，点击提交按钮，看提示信息。 1.输入正确的用户名和密码，点击提交按钮，验证是否能正确登录。 2.输入错误的用户名或者密码，验证登录会失败，并且提示相应的错误信息。 3.登录成功后能否能否跳转到正确的页面 4.用户名和密码，如果太短或者太长，应该怎么处理 5.用户名和密码中有特殊字符（比如空格），和其他非英文的情况 6.记住用户名的功能 7.登录失败后，不能记录密码的功能 8.用户名和密码前后有空格的处理 9.密码是否加密显示（星号圆点等） 10.牵扯到验证码的，还要考虑文字是否扭曲过度导致辨认难度大，考虑颜色（色盲使用者），刷新或换一个按钮是否好用 11.登录页面中的注册、忘记密码，登出用另一帐号登录等链接是否正确 12.输入密码的时候，大写键盘开启的时候要有提示信息。 界面测试(UI Test) 1.布局是否合理，2个testbox 和一个按钮是否对齐 2.testbox和按钮的长度，高度是否复合要求 3. 界面的设计风格是否与UI的设计风格统一 4. 界面中的文字简洁易懂，没有错别字。 性能测试(performance test) 1.打开登录页面，需要几秒
返回 编号 用例名称 测试条件 测试步骤 测试用例_预期结果 样机数量 备注 测试结果 Reliability_test_001 载重测试(硬载重） 普通手机：手机开机，整个正、反面施加70kgf的压力，承受2秒钟。 触摸屏手机：手机开机，整个正、反面施加70kgf的压力，承受2秒钟。 三防手机：手机开机，整个正、反面施加80kgf的压力，承受2秒钟 1.测试前对产品初步检查确保他们有正常的电气和机械性能 2.手机正面向上正常放置在水平测试钢台上，对手机整个正面施加规定的压力，停留两秒钟。 3.手机正面向下正常放置在水平测试钢台上，对手机整个背面施加规定的压力，停留两秒钟。 4.每完成一步对样机进行检查（检MMI），测试完成进行终检（检MMI、通话、外观……） 参考 附录---机械可靠性测试前后检查用例3 载重测试压块面积应与手机相当且压块与手机间应加垫1~2mm泡棉 测试过程中手机不能关机，测试完成后手机机械电气功能正常（重点关注LCD性能）。 Reliability_test_002 载重测试(软载重） 普通手机/触摸屏手机开机状态下，整个正面施加70kgf的压力，承受2秒钟。 1.测试前对产品初步检查确保他们有正常的电气和机械性能2.普通手机/触摸屏手机开机状态下，整个正面施加70kgf的压力，承受2秒钟。 3.测试完成进行终检（检MMI、通话、外观……） 参考 附录---机械可靠性测试前后检查用例3 软载重测试压块面积应与手机相当或大于手机，且压块为硅橡胶压头（测试压头硅橡硬度应在肖氏70±5度）。 Reliability_test_003 挤压测试 （1）0.5kgf，挤压中心点，不允许出现水印（2）10kgf，金属棒压头(杆直径8mm，压头弧半径10mm)，挤压如下位置，屏幕9个点，听筒位置，FPC位置，sensor位置，芯片上方各一次；4.5kgf，摄像头中心点；10kgf，2s，IC中心，IC两侧各5次（压头以10mm/min的速度施加力）翻盖机内屏不挤压1）试验前，对产品初步检查确保他们有正常的电气和机械性能； 2）将产品固定在测试平台上，样品与测试平台之间需要放置3mm厚的防静电皮（静电皮的尺寸要大于产品的尺寸）。产品两端用夹具固定（夹具压产品部分需要有3mm 厚的防静电皮）；3）首先用0.5kgf力，挤压中心点一次，不允许出现水印。4）按照测试力的要求，顺序测试（A1-A9，B1-B3,听筒位置，FPC位置，sensor位置，芯片上方，摄像头）； 4）每完成一次测试后需要检查产品机械功能，测试完成后要机械、电子性能及通话功能检查；参考 附录---机械可靠性测试前后检查用例6 测试过程中手机不能关机，测试完成后手机机械电气功能正常。 Reliability_test_004 弯折测试 正面、背面能承受13kgf压力，停留两秒钟后返回，正反面重复此操作各250次 1.测试前对产品初步检查确保他们有正常的电气和机械性能 2.手机开机，正面向上放置在支撑夹具上，用直径20mm的压头，13kgf压力，50-60 次/min的速度压手机中心部位。重复此操作250次。 3.手机开机，背面向上放置在支撑夹具上，用直径20mm的压头，13kgf压力，50-60次/min的速度压手机中心部位。重复此操作250次。 4.测试完成进行终检（检MMI、通话、外观……）参考 附录---机械可靠性测试前后检查用例3 两端支撑点应尽可能相互远离。每完成一步测试需检查手机机械电气功能。 Reliability_test_005 扭曲测试 开机状态下承受数值为其厚度（取mm为数值单位）的0.12倍，单位为N.m的扭矩（最大不超过2 N.m，最小不小于0.5N.m）扭曲500往复。1）试验前，对产品初步检查确保正常的电气和机械性能； 2）产品锁键盘后，听筒端装夹在设备固定的一端（夹持距离为15mm，四向固定），另一端固定在旋转一侧（夹持距离为15mm，垂直LCD面双向固定）； 3）按标准进行测试完成后，检查产品机械、电气性能。 参考 附录---机械可靠性测试前后检查用例3 1）测试中出现电池故障记录现象，更换新电池继续测试；1、北美、日本手机产品采用E标 2、其他地域的手机，由产品线在CDP时根据产品策略、定位，决策选择哪种标准 3、FP所有产品（不论发货市场和地域）:由产品线在CDP时根据产品策略、定位，决策选择哪种标准，建议选择B标Reliability_test_006 软压测试 测试压力：25kgf 测试次数：2000次（横向正面、横向反面、竖向正面、竖向反面各500次） 测试速度：电动设备10 mm/S，气动设备 15次/分钟压头：硅橡胶挤压头（肖氏70±5度） 1）试验前，对产品初步检查确保正常的电气和机械性能； 2）将产品开机锁住键盘正面朝上放置在帆布上并用布带将样品紧固（机身与固定支架的轴向垂直），进行标准压力的寿命测试； 3）将产品开机锁住键盘背面朝上放置在帆布上并用布带将样品紧固（机身与固定支架的轴向垂直），进行标准压力的寿命测试； 4）将产品开机锁住键盘正面朝上放置在帆布上并用布带将样品紧固（机身与固定支架的轴向平行），进行标准压力的寿命测试； 5）将产品开机锁住键盘背面朝上放置在帆布上并用布带将样品紧固（机身与固定支架的轴向平行），进行标准压力的寿命测试； 6）每完成一步测试后需要检查手机机械电气功能，测试完成后要检查产品通话功能； 参考 附录---机械可靠性测试前后检查用例3 开机-锁键盘/屏幕-正面向上1000次-功能检测-正面向上1000次-功能检查结束 Reliability_test_007 常温受控跌落（1）4.0寸以下产品，跌落次数2轮*（6面），0.3m +1.2m； 4.0寸（含）-4.7寸产品，跌落次数2轮*（6面），0.3m + 1m； 4.7寸（含）- 5.0，跌落次数2轮*（6面），0.3m +0.8m； （千元智能机的跌落高度定为0.3m+0.8m，2轮*6面） （2）4.0寸（含）以上产品以及千元智能机,3个新样本，进行1.2m的跌落测试，1轮*6面，不允许出现LCD IC，BGA，连接器松脱失效，其他失效不予判定。 （3）5.0寸以上的，跌落次数：2轮*（6面），0.3m +0.7m； 问题级别定义：跌落用B标的问题级别判定LCD屏裂和TP lens裂问题 （4）FP:2轮*（6面），0.3m + 1m；跌落面为大理石面 1.试验前，对产品初步检查确保他们有正常的电气和机械性能； 2.每次跌落前用吸尘器或刷子清洁测试台面； 3.跌落顺序按照测试规范进行； 4.每跌落一轮检查主要功能：电气、机械、射频、音频（音频、射频可用通话代替）； 5.每一次跌落前需检查产品结构件是否分开，如有手动恢复后测试； 参考 附录---机械可靠性测试前后检查用例13 1）设备校准： 下降速度/冲击的影响应等同于指定高度的自由落体（如1.0米，1.5M等）； 每年对设备进行检查，调整，定期校准，以维持所需的性能和精度； 定期检查跌落速度对照表，建议每6个月用高速摄影进行校验一次； 2）测试过程中，允许存在不碰到跌落夹具（不含试验台面与侧面挡板）的二次及以上碰撞； 3）跌落台面检查，如果表面存在腐蚀、凹坑应该进行更换； 4）跌落高度：指试验样品在跌落前悬挂着的时候，试验表面与离它最近的样品部位之间的高度； 5）测试需要增加UIM、SIM、T卡（真卡、假卡都可）等6）测试后立即检查，OLED显示器当时需要检查，24小时后再检查。 Reliability_test_008低温受控跌落 -10度，0.8m，1轮*6面（三防手机1.5m） 1.试验前，对产品初步检查确保他们有正常的电气和机械性能； 2.关机放进-10度的温箱中存储2小时，取出不开机进行测试跌落测试（记录放入及取出温箱的时间）； 3.将设备调到手动模式进行跌落（一台一台取出 分别在1分钟内跌落完成），每次跌落前用吸尘器或刷子清洁测试台面； 4.跌落顺序按照测试规范进行； 5.每次跌落只检查产品的机械性能，测试结束后2小时检查产品机械、电气性能； 参考 附录---机械可靠性测试前后检查用例3 1）测试不需要增加UIM、SIM、T卡（真卡、假卡都可以）等； 2）OLED显示器当时需要检查，24小时后再检查；3）其它细节参考常温受控跌落要求； Reliability_test_009 滚筒跌落 （1）10pcs样本：0.5m-100次+1m-100次，50次检查一次（2）10pcs样本1m-100次。50次检查一次 （3）（1）和（2)的ok的样本继续进行1m测试直至全部失效，上限1000次（供开发参考发现薄弱点，提升可靠性设计） 1)测试之前，全面检查； 2）开机放入测试设备内（滑盖、翻盖，打开与合上各半），转速设置，使产品直接跌落到测试地面的中心（转速设定参考值：1m（10-12次/分）、0.5m（16- 18次/分））； 3）考虑胶带的位置将力学的影响降到最低， 4） 全面检查：0、50、100、150、200、300、400、600、800、1000检查点，确保正常的电气和机械性能，测试完成后，需要对OK样本进行拆机检查。 参考 附录---机械可靠性测试前后检查用例20 1）测试前检测并清理滚筒内异物，每50次测试后，检测并清理滚筒内异物（统一吸尘器处理一下）。 测试中如果有部件脱落找不见应该停止测试，清理完设备后再继续测试； 2）滚筒设备要求同GB/T 2423.8-1995，如下图（滚动斜面部分要有白色聚四氟滑块）； 3）设备必须要接地处理，避免静电产生伤害操作员与设备； Reliability_test_010 转轴按压测试 测试力量：5kg 压力；测试速度：60mm/min； 测试位置：产品翻盖打开后背面转轴位置，每次停留时间2S，重复50次1）试验前，对产品初步检查确保正常的电气和机械性能； 2）将产品翻盖打开后背面朝上放在测试平台上（转轴中心点对准测试夹具）； 3）设置测试设备参数，按标准进行测试完成后，检查产品机械、电气性能及通话检查； 参考 附录---机械可靠性测试前后检查用例3 手工按压-功能检查 Reliability_test_011 按键耐久测试1)测试前对样机初检，保证样机机械电气功能正常，对测试前样机按键力进行测量； 2）手机开机，使用直径12（6）mm，的橡胶头模拟人手指按压手机键盘； 3）测试标准20%、40%、60%、80%寿命时，检查Keypad有无破裂，磨损，按键的烤漆是否有脱落，印刷字体是否依然清晰，按键功能是否正常； 4）测试标准60%、80%寿命时，取下产品进行全功能检查，含通话。5）测试完成后，检查样机电气功能并测量样机按键力；6）PTT按键测试瞬间按键： 测试前对样机初检，保证样机机械电气功能正常，对测试前样机按键力进行测量； 手机开机，使用直径12mm，肖氏硬度50度的橡胶头模拟人手指按压手机键盘； 每10万次需检查Keypad有无破裂，磨损，按键的烤漆是否有脱落，印刷字体是否依然清晰。按键功能是否正常； 测试完成后，检查样机电气功能并测量样机按键力； 持续按键： 测试前对样机初检，保证样机机械电气功能正常，对测试前样机PTT按键力进行测量； 手机开机，使用直径12mm，肖氏硬度50度的橡胶头模拟人手指按压手机PTT键。对PTT按键施加的按键压力为2.5kgf，保持1min后松开，共测试5000次； 每1000次需检查Keypad有无破裂，磨损，按键的烤漆是否有脱落，印刷字体是否依然清晰。按键功能是否正常； 测试完成后，检查样机电气功能并测量样机按键力；7)power键： 测试前对样机初检，保证样机机械电气功能正常，对测试前样机按键弹力进行测量 手机开机，使用直径6mm，邵氏硬度55度的硅胶点击头，点击手机Power键中心，点击头底部离power键的距离为5mm，点击力为5±1N。按0.5秒，松开时间0.5秒。 点击键万次（万次中间检查）参考 附录---机械可靠性测试前后检查用例6 要求一次测试中同时包含功能键，侧键，导航键、数字键以及其他按键 Reliability_test_012 翻盖/滑盖耐久性测试翻盖耐久： 常温翻盖耐久：手机开机以30～40次/分的速度进行翻盖，共进行7万次。 滑盖耐久： 手机开机以30～40次/分的速度进行滑盖，共进行7万次。 1.测试前对手机初检，保证手机机械电气功能正常，保证翻盖功能正常。 2.设置手机完成一次开合测试的时间为一秒，设置总开合次数为7万次。 3.每一万次检查翻/滑盖的手感，外观，手机电气功能并记录异常情况。5.测试中可用翻/滑盖的开合来控制的手机功能均应处于打开状态。参考 附录---机械可靠性测试前后检查用例10 1.手机在翻/滑盖动作中，应尽量模拟实际使用过程中的翻盖情况，在手机装夹时要采取防颤动措施。测试时以不发生明显的数次颤动弹跳现象为宜 2.翻盖测试时应让手机转轴轴心跟翻盖设备轴心重合，打开或者关闭时应让翻/滑盖依靠转轴弹力自由打开或关闭Reliability_test_013 触摸屏点击耐久测试 触摸笔垂直于触摸屏方向，以2±0.5N压力进行80 万次点击。每1万次检查一次。触摸按键位置需要 覆盖一遍 1）测试前对手机进行初检，保证机械功能和电气性能正常； 2）将手机和触摸笔装夹在测试设备上，将触摸笔垂直于触摸屏方向，以2±0.5N压力，点击触摸屏80万次。每10万次对触摸屏进行清洁，并检查手机机械和电气功能，记录检验数据； 测试完成后手机机械电气功能正常。触摸屏使用功能无异常，显示屏显示正常，触摸屏 无损伤，破裂。触摸笔头部无变形，扭曲， 损伤。3 电阻屏必须使用配套的触摸笔，电容屏的用电容头测试，2.5N压力，每10w次检查功能 Reliability_test_014 触摸屏手写耐久测试 触摸笔垂直于触摸屏方向，以250gf压力进行10万次往复。每1万次检查一次 该测试只针对电阻式触摸屏，电容式触摸屏不作要求。1）测试前对手机进行初检，保证机械功能和电气性能正常； 2）将手机和触摸笔装夹在测试设备上，将触摸笔垂直于触摸屏方向，以250gf压力，沿触摸屏的对角线，进行10万次往复的划线测试。每1万次对手机进行机械和电气功能检查并记录检验数据；测试完成后手机机械电气功能正常。触摸屏使用功能无异常，显示屏显示正常，触摸屏无损伤，破裂。触摸笔头部无变形，扭曲， 损伤。3 电阻屏必须使用配套的触摸笔 Reliability_test_015触摸笔插拔耐久测试 触摸笔与手机笔槽插拔1万次 1. 测试前保证触摸笔和手机笔插槽机械功能正常，插拔功能正常，不可有物理损坏。 2.将触摸笔从手机笔槽完全拔出，再将触摸笔完全装入手机笔槽，以上记为插拔一次，共进行1万次插拔 3.测试完成进行终检（检外观） 测试完成后触摸笔和手机笔槽机械功能正常。 触摸笔和手机笔槽不可有物理损坏，无不可恢复变形，插拔功能正常3 手工测试，1w次 Reliability_test_016 触摸笔伸缩耐久测试 将触摸笔伸缩测试10000次 1.测试前保证触摸笔机械功能正常，不可有物理损坏。2.将触摸笔伸缩测试1万次 3.测试完成进行终检（检外观、伸缩性能） 测试完成后触摸笔机械功能正常。 触摸笔不可有物理损坏，无不可恢复变形，伸缩功能正常，能正常装入手机笔槽 3 手工测试，1w次 Reliability_test_017 天线强度测试 拉力： 50N，2秒，20次；注：测试点离顶端5mm。扭力：30N.cm，2秒，20次注：测试点离顶端5mm。 侧压：20N，2秒，4个方向各5次；注：测试点离顶端5mm。 1.对样品初检，通过屏蔽盒耦合测试手机灵敏度，最大功率。 2. 取一个样品进行拉力测试：拉力大小为50N，方向为沿天线轴线向上，作用时间2秒，做20次。 3. 取一个样品进行扭力测试：在天线顶部用扭力计顺时针方向施加30N*cm的扭力，作用时间2秒，做20次。 4.取一个样品进行侧压力测试：手机正面向上，在离天线顶部约5mm处施加20N压力，作用时间2秒，4个方向各五次。 5. 测试完成后通过屏蔽盒耦合测试手机灵敏度及最大功率天线不可有物理损坏。测试前后最大功率、灵敏度不能相差超过2dB 6 Reliability_test_018 吊饰孔拉力测试 用钓鱼线悬挂，拉断吊饰孔的拉力≥10kgf并且≤30kgf 1.对手机初检，保证手机吊饰孔无破裂。 2. 将钢丝从手机吊饰孔中穿过，手机处于正常悬挂状态。 3.测量钢丝将吊饰孔拉断裂所需要的力 拉断吊饰孔的拉力≥10kgf并且≤30kgf为合格 3 Reliability_test_019 按键帽拉拔力测试 用垂直拉力将按键帽拉出,记录按键最小拔出力. 1.对样品初检，保证按键安装到整机上且功能正常； 2.将线扣用胶水粘在按键帽上，固定线扣，在速度为0.5mm/s的情况下用拉力计拉拔按键帽； 3.拉力最大达到0.7kgf. 0.7kgf，按键不允许脱胶，硅胶不允许破裂，不允许出现因为胶粘变化而产生的不可恢复的按键变形10 Reliability_test_020 插孔保护盖抗拉测试 1.2kgf的拉力，保持10秒，共进行10次 1.初检，保证手机的耳机及充电器插孔保护盖无破损。 2.打开保护盖，以1.2kgf的拉力垂直手机侧面拉保护盖的一端，保持10秒。 3.重复第2个步骤10次，完成测试。 保护盖不应断裂或从手机中被拉出。保护盖不能出现不能恢复变形 3Reliability_test_021LCD Lens硬度测试 参考镜片测试标准参考镜片测试标准 参考镜片测试标准3 Reliability_test_022 Lens拉拔力测试 一、3pcs： 拉拔力：50N,速度20mm/min 二、3pcs（试行）： （1）温度冲击：低温-40度 1h 70度 1h 共6个循环 12h，放置2小时 （2）拉拔力：50N,速度20mm/min 翻盖机内LENS不做要求 1.3pcs做温度冲击，3pcs不做温度冲击 2.3pcs温度冲击之后，在常温下放置2h之后，将6pcs手机正面朝上固定在平面上 3.拉拔lens，直至失效或者力达到50N 1.拉拔力满足要求 2.温度冲击后：LENS不脱落，翘起，lens和外壳间不允许有合缝分离，脱胶。(温度冲击后需首先检查TP lens是否有变形浮起等，再进行拉拔力） 6 Reliability_test_023 弹簧锤测试 用弹簧锤以0.2J的能量冲击手机屏幕视窗表面上的9个位置 对手机初检，保证手机功能完好，外观正常。； 2）开机放在刚性测试平台上（刚性台面厚度大于30mm）； 3）用弹簧锤从标准要求的能量冲击各指定位置1次（用钢球从标准要求的高度落下冲击各指定位置1次） 4）每次测试后，检查产品机械、电气性能 手机机械电气性能正常。触摸屏功能正常，无破裂，无不可恢复的显示异常。3 1）钢珠尺寸：直径Φ32mm，质量130g的不锈钢球2）钢珠不能存在可见的缺陷，避免尖峰撞击产品3）测试高度误差要小于±1毫米 4）跌落高度要根据手机厚度进行调整，确保跌落高度为测试高度； 5）测试位置：LCD 显示区域9个点（如图） Reliability_test_024 连接器强度测试 插头应完全插入到连接器中，按图所示的各方向，进行测试： 1.F1/F2(+/-Y) =35N（充电器）/30N（耳机） 2.F3,F4(+/-X) =35N（充电器）/30N（耳机） 3.F5(+Z) =100N F1和F2方向的测试均采用新样品测试，F3-F5方向视情况进行互用 施力点为接口到SR处15mm，测试速度：5mm/min 1.初检，保证测试样品机械、电气功能正常； 2.固定样品在规定的施力点施加规定的力 3.测试完成先进行机械、电气性能确认，在拆机检查各焊接点的机械性能手机和连接器无任何功能失效，插头插入连接器中的配合正常，拔出与插入动作正常 检查手机功能：开机、充电、用配件检查连接器功能（例如，耳机、数据线传输数据等） 在规定的力作用下连接器不能有损坏；弹片不能损坏或严重变形； 拆机检查，连接器与PCB或FPC的焊接处无裂纹； 每个方向3PCS Reliability_test_025 MicroB旋转测试 4.5N负重 90、180度、270度、360度各负重一次保持2s 1.测试前初检，保证充电器、数据线在测试前机械电气性能正常， 2.将充电器、数据线插入对应产品中， 3.如图所示在线材端50cm内附加450g的配重， 4.使产品和线材处于不同角度的状态（90、180度、270度、360度）保持2s 5.在每个角度要检查产品的连接是否会断开。 在每个角度产品和数据线之间的连接不允许有断开的现象，充电器、线材接口不允许有不可恢复的变形， 3 1.次试验只针对Micro-B的连接器。 2.每个角度的测试样品必须保证样品装配到位， Reliability_test_026 连接器耐久测试 插头应完全插入到连接器中；按图所示的F1/F2，进行测试： 测试力：F1=F2=1kgf 测试次数：2000次（往复算一次）；施力点为接口到SR处15mm 测试速度：10-15次/min 1.初检，保证测试样品机械、电气功能正常； 2.固定样品在规定的施力点施加规定的力按压连接器规定次数 F1和F2方向交替进行测试，每1000次需要进行检查 3.测试完成先进行机械、电气性能确认，再拆机检查各焊接点的机械性能 手机和连接器无任何功能失效，插头插入连接器中的配合正常，拔出与插入动作正常 检查手机功能：开机、充电、用配件检查连接器功能（例如，耳机、数据线传输数据等） 在规定的力作用下连接器不能有损坏；弹片不能损坏或严重变形； 拆机检查，连接器与PCB或FPC的焊接处无裂纹； 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 台
软件测试专业术语对照表 此术语表为国际软件测试认证委员会（ISTQB）发布的标准术语表。此国际软件测试认证委员会（ISTQB）发布的标准术语表即是以最新版的BS 7925-1标准为基础制定的国际化软件测试标准术语。 1 简介 行业界、商业界、政府及学术机构曾经花费大量精力和时间以解释和区分一些常见的软件测试专业术语以期在各社会部门或机构之间达成交流，例如：语句覆盖(statement coverage) 和条件覆盖(decision overage)；测试套件(test suite)、测试规格说明书(test specification)和测试计划(test plan)等。上述机构与专职机构定义的同名术语在含义上又往往有很大偏差。 2 范畴 本文档旨在提供概念、条款、和定义为软件测试及相关从业人员进行有效交流的平台。 3 结构 术语表中的词汇按字母顺序排列。术语如有同义词汇，本术语表解释最通用的词汇，其同义词 汇会的仅被列出，不予重复解释。例如结构测试(structural testing) 和白盒测试(white box testing)。 此类同义词在术语表中用“参见”列出，以便读者检索。“参见”往往连接着广义和狭义词或 含义重叠的词汇。 4 标准参考 至截稿日期，此标准有效版本为1.2。如所有其他标准一样，本术语表仍需根据以下相关标准的 最新版本不断修正。此标准由IEC 和ISO 成员根据目前有效的国际相关标准进行更新。 - BS 7925-2:1998. Software Component Testing. - DO-178B:1992. Software Considerations in Airborne Systems and Equipment Certification, Requirements and Technical Concepts for Aviation (RTCA SC167). - IEEE 610.12:1990. Standard Glossary of Software Engineering Terminology. - IEEE 829:1998. Standard for Software Test Documentation. - IEEE 1008:1993. Standard for Software Unit Testing. - IEEE 1012:1986. Standard for Verification and Validation Plans - IEEE 1028:1997. Standard for Software Reviews and Audits. - IEEE 1044:1993. Standard Classification for Software Anomalies. - IEEE 1219:1998. Software Maintenance. - ISO/IEC 2382-1:1993. Data processing - Vocabulary - Part 1: Fundamental terms. - ISO 9000:2000. Quality Management Systems – Fundamentals and Vocabulary. - ISO/IEC 9126-1:2001. Software Engineering – Software Product Quality – Part 1: Quality characteristis and sub-characteristics. - ISO/IEC 12207:1995. Information Technology – Software Life Cycle Processes. - ISO/IEC 14598-1:1996. Information Technology – Software Product Evaluation - Part 1: General Overview. A abstract test case 抽象测试用例参见high level test case. acceptance 验收参见acceptance testing.