1.控件测试
1.1.文本框:接受用户输入的数据，或者显示数据
默认值测试：
固定值还是数据库or配置项给定的值输入验证；
在输入框里填写了值，点界面刷新时，是显示输入值还是默认值；
操作限制：
不限制复制粘贴操作，输入验证；
限制复制粘贴操作，输入验证；
输入不符合格式的数据，例如年月日格式、文件名；
必填项非空校验
必填项未输入－－程序应提示错误；
必填项只输入若干个空格，未输入其它字符－－程序应提示错误；
字段唯一性校验：（不是所有字段都作此项校验，视实际项目情况而定）
新增时输入重复的字段值－－必须提示友好信息；
修改时输入重复的字段值－－必须提示友好信息；
字段长度校验：
输入[最小字符数-1]－－程序应提示错误；
输入[最小字符数]－－OK；
输入[最小字符数+1]－－OK；
输入[最大字符数-1]－－OK；
输入[最大字符数]－－OK；
输入[最大字符数+1]－－程序应提示错误；
字段为特殊字符校验：
输入域如对某些字符禁止输入时，限制是否成功，提示信息是否友好（利用复制粘贴强制输入不予许输入的数据） ；
中文、英文、空格，数字，字符，下划线、单引号 等所有特殊字符的组合 ；
所有特殊字符都必须进行测试（!~@#$^&*()_+{}|:“<>?/.,;‘[]\=-`￥…&hellip；（）--：《》？、。，；&rsquo；【】、=-&bull； ）；
字段为特殊代码校验：
输入html代码：比如&ldquo； 你好&rdquo；、&ldquo；NULL&rdquo；－－必须以文本的形式将代码显示出来；
输入JavaScript代码：比如－－必须以文本的形式将代码显示出来；
多行文本框输入：
是否允许回车换行 ；
保存后再显示能够保持输入时的格式 ；
仅输入回车换行，检查能否正确保存；若能，查看保存结果。若不能，查看是否有正确提示 ；
仅输入空格，检查能否正确保存；若能，查看保存结果。若不能，查看是否有正确提示 ；
空格位置：
前含空格；
中含空格；
后含空格；
1.2.按钮：
按钮功能是否实现（添加，删除，修改，取消，保存等等）；
对可能造成数据无法恢复的操作必须给出确认信息，给用户放弃选择的机会；（删除、关闭）
通过点击按钮有弹出框或者弹出窗体需要对弹出的窗体或弹出框进行测试，所弹出的窗体是否与按钮功能一致；
按钮的可用与否逻辑上是否正确；
对按钮测试需要考虑按钮对齐，字体大小，颜色，重复功能按钮等界面测试的要素；
对非法的输入或操作给出足够的提示说明；
1.3.单选按钮：
一组单选按钮不能同时选中，只能选中一个；
逐一执行每个单选按钮的功能, 存入数据库是不是选项值。分别选择了&ldquo；男”&ldquo；女&rdquo；后，保存到数据库的数据应该相应的分别为&ldquo；男”&ldquo；女&rdquo；；
一组执行同一功能的单选按钮在初始状态时必须有一个被默认选中，不能同时为空；
选项是否有排列顺序；
选项名和选项值是否符合要求；
刷新页面后，选中的值／默认的值是否掉了；
1.4.up－down：
直接输入数字或用上下箭头控制，如，在&ldquo；数目&rdquo；中直接输入10，或者单击向上的箭头，使数目变为10；
利用上下箭头控制数字的自动循环，如，当最多数字为253时，单击向上箭头，数目自动变为1；反之亦适用；
直接输入超边界值，系统应该提示重新输入；
输入默认值，空白。如，&ldquo；插入&rdquo；数目为默认值，点击&ldquo；确定&rdquo；；或，删除默认值，使内容为空，单击&ldquo；确定&rdquo；进行测试；
输入字符。此时系统应提示输入有误；
1.5.组合列表框：
条目内容正确，其详细条目内容可以根据需求说明确定;
逐一执行列表框中每个条目的功能；
检查能否向组合列表框输入数据；
1.6.复选框：
能否同时选中；
能否部分选中；
能否都不被选中；
能否被清空；
1.7.下拉框（列表框）：
测试方法：
条目内容正确；根据需求说明书确定列表的各项内容正确，没有丢失或错误；
列表框的内容较多时要使用滚动条；
列表框允许多选时，要分别检查shift选中条目，按ctrl选中条目和直接用鼠标选中多项条目的情况；
逐一执行列表框中每个条目的功能；
检查能否向组合列表框输入数据；
内容：
检查默认值，有的默认空，有的是非空；
检查约束。有时它的内容是根据其他要素变化的，比如城市的下列框的内容，是根据省份变化而联动的；或者根据登录者的权限不同，下拉列表的内容也不一样；
布局：
宽度，有时它会根据内容的长短自动控制宽度；
高度应合适；
易用：
检查是否至此后TAB和上下箭头；
下拉框里面有很多选项像省份可以划分下等价类，两个字的，三个字的，四个字的。。。每个等价类测一个，然后再把某些省份里面奇怪的市单独拉出来做组合测试内容的显示；
1.8.滚动条：
滚动条的长度根据显示信息的长度或宽度及时变换，这样有利于用户了解显示信息的位置和百分比，如，word中浏览100页文档，浏览到50页时，滚动条位置应处于中间；
拖动滚动条，检查屏幕刷新情况，并查看是否有乱码；
单击滚动条；
用滚轮控制滚动条；
滚动条的上下按钮；
1.9.日期控件文本框：
正常操作：
有默认项还是没有；
选择日期后是否正确回显到页面上，并且格式正确；
通过左右按钮进行年和月的选择，是否正确；
通过下拉框直接选择年和月，是否正确；
控件选择完日期后，输入框是否选择正确；
是否可以手工修改输入框；
点击clear 按钮是否可以正确清空输入框日期；
点控件的 close 按钮不修改日期，返回页面；
刷新界面后，输入框的日期是否没有变化；
手工输入操作：
输入框可不可以手工输入；
输入日期的格式正确，不能用其他格式；
输入字母，文字，特殊字符后，提示失败；
提示方式（限制输入：无限制输入然后即时用提示框or label，无限制输入：当焦点离开后用提示框or label，点其他按钮提示）；
1.10.命令按钮：
测试方法：
点击按钮正确响应操作。如，单击确定，正确执行操作；单击取消，退出窗口；
对非法的输入或操作给出足够的提示说明，如，输入月工作天数为32时，单击&rdquo；确定&ldquo；后系统应提示:天数不能大于31；
对可能造成数据无法恢复的操作必须给出确认信息，给用户放弃选择的机会；
如果有键盘快捷键，使用快捷键后，正常执行功能；
特殊操作：
快速点击两次按钮，是否只有一次有效；
点击按钮后，点刷新，是否只有一次有效；
点击按钮后，右键点后退，是否只有一次有效；
点击按钮后，按钮会不会改变状态；
是否设置Enter键/快捷键操作（设置的快捷键与Windows自带的快捷键有没冲突）;
1.11.翻页：
总页数和当前页显示正确，并且可以根据数据的记录数实时显示（实时显示页面变化？记得一般系统要刷新后才能显示页面变化）。（默认显示数据根据系统设计一般有“显示所有数据”和“不显示数据”两种。）;
逐一执行翻页控件中的每个按钮，并且能够正常操作。（主要按钮一般有：第一页，前一页，后一页，最后一页。（当前页，页面总数，跳到第？页 go））
如果可以自己输入页数，检查页面跳转是否正确；比如总页数为10页，输入11后点GO，是否仍然停留在当前页（或者提示输入错误），还可以尝试输入普通字符或者特殊字符后点GO，页面是否显示正常，不会有脚本错误；
页面显示数据数目是否能配置，能配置的话配置与实际显示是否符合；
1.12.上传：
通过Browse按钮选择文件；
如果文件限制类型（exe,rar,doc,pdf,xls,jpg,gif,bmp,png 等）和大小（100k,512k,1M,5M,2M,5M），要逐一测试限制条件是否正确，并且给出了明确的提示；
检查实际上传后是否能够正确下载，如果是图片是否能够正确显示；
如果没有特殊要求，应该保持上传文件的名字是否和保存后的文件名字一致；
1.13.树控件的测试外观操作：
项目中的所有树是否风格一致：
树结构的默认状态是怎样的。比如默认树是否是展开，是展开几级？ 是否有默认的焦点？默认值是什么?展开的节点图标和颜色？
验证展开节点时页面上树结构的连线是否显示正确；
如果显示节点超过页面边界是否有规定；
节点和叶子显示的文字规定多长要折行；
节点和叶子显示的文字不能有乱码；（输入中文，特殊字符）
执行操作：
点某个节点时，是否只展开下一级的节点和显示该级的叶子还是显示下一级全部的；
点页面刷新时，树结构是否按照要求变化，树结构是否保存现状还是默认状态；
数据操作：
树结构上数据是否正确；
树结构上的节点和叶子是否排序正确；（升序还是降序）
树结构排序是按照数据库中得记录顺序排序还是按照程序数组的顺序；
执行了某一操作或数据 有变化后，树结构是否回到默认状态，还是按现任状态保持展开；
执行了某一操作或数据有变化后，修改后的数据是不是在正确得位置上，状态是否正确，排序是否正确；
1.14.各种控件在窗体中混和使用时的测试：
控件间的相互作用；
tab键的顺序，一般是从上到下，从左到右；
热键的使用，逐一测试；
enter键和esc键的使用； 在测试中，应遵循由简入繁的原则，先进行单个控件功能的测试，确保实现无误后，再进行多个控件的的功能组合的测试；
密码输入框测试时要特别注意进行字母大写输入的测试；
2.界面测试
2.1.易用性：
按钮名称应该易懂，用词准确，屏弃没楞两可的字眼，要与同一界面上的其他按钮易于区分，能望文知意最好。理想的情况是用户不用查阅帮助就能知道该界面的功能并进行相关的正确操作；
易用性细则：
完成相同或相近功能的按钮用Frame框起来，常用按钮要支持快捷方式；
完成同一功能或任务的元素放在集中位置，减少鼠标移动的距离；
按功能将界面划分区域块，用Frame框括起来,并要有功能说明或标题；
界面要支持键盘自动浏览按钮功能，即按Tab键、回车键的自动切换功能；
界面上首先要输入的和重要信息的控件在Tab顺序中应当靠前,位置也应放在窗口上较醒目的位置；
同一界面上的控件数最好不要超过10个，多于10个时可以考虑使用分页界面显示；
分页界面要支持在页面间的快捷切换，常用组合快捷键Ctrl+Tab；
默认按钮要支持Enter及选操作，即按Enter后自动执行默认按钮对应操作；
可写控制项检测到非法输入后应给出说明并能自动获得焦点；
Tab键的顺序与控件排列顺序要一致，目前流行总体从上到下，同时行间从左到右的方式；
核取方块和选项框按选择几率的高底而先后排列；
核取方块和选项框要有默认选项，并支持Tab选择；
选项数相同时多用选项框而不用下拉清单框 ；
界面空间较小时使用下拉框而不用选项框；
选项数较少时使用选项框，相反使用下拉列表框；
专业性强的软件要使用相关的专业术语，通用性界面则提倡使用通用性词语；
2.2.规范性：
通常界面设计都按Windows界面的规范来设计，可以说：界面遵循规范化的程度越高，则易用性相应的就越好。小型软件一般不提供工具厢；
规范性细则：
常用菜单要有命令快捷方式；
完成相同或相近功能的菜单用横线隔开放在同一位置；
菜单前的图标能直观的代表要完成的操作；
菜单深度一般要求最多控制在三层以内；
工具栏要求可以根据用户的要求自己选择定制；
相同或相近功能的工具栏放在一起；
工具栏中的每一个按钮要有及时提示信息；
一条工具栏的长度最长不能超出屏幕宽度；
工具栏的图标能直观的代表要完成的操作；
系统常用的工具栏设置默认放置位置；
工具栏太多时可以考虑使用工具箱；
工具箱要具有可增减性，由用户自己根据需求定制；
工具箱的默认总宽度不要超过屏幕宽度的1/5；
状态条要能显示用户切实需要的信息，常用的有：目前的操作、系统状态、用户位置、用户信息、提示信息、错误信息等，如果某一操作需要的时间较长，还应该显示进度条和进程提示；
滚动条的长度要根据显示信息的长度或宽度能及时变换，以利于用户了解显示信息的位置和百分比；
状态条的高度以放置五号字体为宜，滚动条的宽度比状态条的略窄；
菜单和工具条要有清楚的界限;菜单要求凸出显示，这样在移走工具条时仍有立体感；
菜单和状态条中通常使用5号字体。工具条一般比菜单要宽，但不要宽的太多，否则看起来很不协调；
右键快捷菜单采用与菜单相同的准则；
2.3.帮助设施：
系统应该提供详尽而可靠的帮助文档，在用户使用产生迷惑时可以自己寻求解决方法；
帮助设施细则：
帮助文档中的性能介绍与说明要与系统性能配套一致。(我们的系统帮助文档都是系统的祖先时期的说明，让人困惑)；
打包新系统时，对作了修改的地方在帮助文档中要做相应的修改；
操作时要提供及时调用系统帮助的功能。常用F1；
在界面上调用帮助时应该能够及时定位到与该操作相对的帮助位置。也就是说帮助要有即时针对性；
最好提供目前流行的联机帮助格式或HTML帮助格式；
用户可以用关键词在帮助索引中搜索所要的帮助，当然也应该提供帮助主题词；
如果没有提供书面的帮助文档的话，最好有打印帮助的功能；
在帮助中应该提供我们的技术支持方式，一旦用户难以自己解决可以方便的寻求新的帮助方式；
2.4.合理性：
屏幕对角线相交的位置是用户直视的地方，正上方四分之一处为易吸引用户注意力的位置，在放置窗体时要注意利用这两个位置；
合理性细则：
父窗体或主窗体的中心位置应该在对角线焦点附近；
子窗体位置应该在主窗体的左上角或正中；
多个子窗体弹出时应该依次向右下方偏移，以显示窗体出标题为宜；
重要的命令按钮与使用较频繁的按钮要放在界面上注目的位置；
错误使用容易引起界面退出或关闭的按钮不应该放在易点击的位置。横排开头或最后与竖排最后为易点位置；
与正在进行的操作无关的按钮应该加以屏蔽(Windows中用灰色显示，没法使用该按钮)；
对可能造成数据无法恢复的操作必须提供确认信息,给用户放弃选择的机会；
非法的输入或操作应有足够的提示说明；
对运行过程中出现问题而引起错误的地方要有提示，让用户明白错误出处，避免形成无限期的等待；
提示、警告、或错误说明应该清楚、明了、恰当；
2.5.美观与协调性：
界面应该大小适合美学观点，感觉协调舒适，能在有效的范围内吸引用户的注意力；
美观与协调性细则：
长宽接近黄金点比例，切忌长宽比例失调、或宽度超过长度；
布局要合理,不宜过于密集，也不能过于空旷，合理的利用空间；
按钮大小基本相近，忌用太长的名称，免得占用过多的界面位置；
按钮的大小要与界面的大小和空间要协调；
避免空旷的界面上放置很大的按钮；
放置完控件后界面不应有很大的空缺位置；
字体的大小要与界面的大小比例协调, 通常使用的字体中宋体9-12较为美观，很少使用超过12号的字体；
前景与背景色搭配合理协调，反差不宜太大，最好少用深色，如大红、大绿等。常用色考虑使用Windows界面色调；
如果使用其他颜色，主色调要柔和，具有亲和力与磁力，坚决杜绝刺目的颜色；
大型系统常用的主色有"#E1E1E1"、"#EFEFEF"、"#C0C0C0"等；
界面风格要保持一致，字的大小、颜色、字体要相同，除非是需要艺术处理或有特殊要求的地方；
如果窗体支持最小化和最大化或放大时，窗体上的控件也要随着窗体而缩放；切忌只放大窗体而忽略控件的缩放；
对于含有按钮的界面一般不应该支持缩放，即右上角只有关闭功能；
通常父窗体支持缩放时，子窗体没有必要缩放；
如果能给用户提供自定义界面风格则更好，由用户自己选择颜色、字体等；
2.6.菜单位置：
菜单是界面上最重要的元素，菜单位置按照按功能来组织；
菜单测试细则：
菜单通常采用“常用--主要--次要--工具--帮助”的位置排列，符合流行的Windows风格；
常用的有“文件”、“编辑”，“查看”等，几乎每个系统都有这些选择，当然要根据不同的系统有所取舍；
下拉菜单要根据菜单选项的含义进行分组，并且按照一定的规则进行排列，用横线隔开；
一组菜单的使用有先后要求或有向导作用时，应该按先后次序排列；
没有顺序要求的菜单项按使用频率和重要性排列，常用的放在开头， 不常用的靠后放置；重要的放在开头，次要的放在后边；
如果菜单选项较多，应该采用加长菜单的长度而减少深度的原则排列；
菜单深度一般要求最多控制在三层以内；
对常用的菜单要有快捷命令方式；
对与进行的操作无关的菜单要用屏蔽的方式加以处理，如果采用动态加载方式——即只有需要的菜单才显示——最好；
菜单前的图标不宜太大，与字高保持一致最好；
主菜单的宽度要接近，字数不应多于四个，每个菜单的字数能相同最好；
主菜单数目不应太多，最好为单排布置；
菜单条是否显示在合适的语境中？
应用程序的菜单条是否显示系统相关的特性（如时钟显示）；
下拉式操作能正确工作吗？
菜单、调色板和工具条是否工作正确？
是否适当地列出了所有的菜单功能和下拉式子功能？
是否可能通过鼠标访问所有的菜单功能？
相同功能按钮的图标和文字是否一致？
是否能够用其他的文本命令激活每个菜单功能？
菜单功能是否随当前的窗口操作加亮或变灰？
菜单功能是否正确执行？
菜单功能的名字是否具有自解释性？
菜单项是否有帮助，是否语境相关？
在整个交互式语境中，是否可以识别鼠标操作？
如果要求多次点击鼠标，是否能够在语境正确识别？
如果鼠标有多个按钮，是否能够在语境中正确识别？
光标、处理指示器和识别指针是否随操作恰当地改变？
2.7.独特性：
如果一味的遵循业界的界面标准，则会丧失自己的个性.在框架符合以上规范的情况下，设计具有自己独特风格的界面尤为重要。尤其在商业软件流通中有着很好的迁移默化的广告效用；
测试细则：
安装界面上应有单位介绍或产品介绍，并有自己的图标；
主界面，最好是大多数界面上要有公司图标；
登录界面上要有本产品的标志，同时包含公司图标；
帮助菜单的“关于”中应有版权和产品信息；
公司的系列产品要保持一直的界面风格，如背景色、字体、菜单排列方式、图标、安装过程、按钮用语等应该大体一致；
3.文档测试
3.1.哪些文档需要测试：
国家有关计算机软件产品开发文件编制指南中共有 14 种文件，可分为 3 大类；
开发文件：可行性研究报告、软件需求说明书、数据要求说明书、概要设计说明书、详细设计说明书、数据库设计说明书、模块开发卷宗；
用户文件:用户手册、操作手册，用户文档的作用：改善易安装性；改善软件的易学性与易用性；改善软件可靠性；降低技术支持成本；
管理文件：项目开发计划、测试计划、测试分析报告、开发进度月报、项目开发总结报告；
3.2.用户文档测试的方法：
技术校对；
功能测试；
其他辅助方式；
3.3.文档测试要点：
文档的读者群；
文档的术语；
文档的正确性；
文档的完整性；
文档的一致性；
文档的易用性；
样例与示例；
文档的语言；
印刷与包装质量等等；
3.4.文档测试的过程：
文档测试主要是查看文档并且进行相关的交流讨论；
3.5.文档测试与静态测试的关系：
静态测试只针对代码；
文档测试也用于设计文档；
静态测试与单元测试一样，是检查代码在功能上的正确性；针对代码的文档测试更注重代码与设计的一致，而代码在功能上的正确性则更多的由针对设计的文档测试来保证；
3.6.文档测试与评审的区别：
评审人的范围比较广，可以包括主管、项目经理、其他开发人员等；
评审的时间相对较短；
评审的随意性较大，系统性不强，评审人从各自的角度提出意见；
文档质量较差时，评审人很难提出实质性的意见；
3.7.总体设计的验证点：
检查需求中规定的功能点如何实现；
需求中列出的所有功能点都能实现；
检查需求中规定的性能指标如何保证；
需求中列出的所有性能指标都能保证；
检查普遍性的功能点（强壮性、容错性、安全性）如何实现；
系统部分失效（断线重连、断线重启）；
异常的输入数据；
异常业务量（零负荷、超负荷）；
非法入侵；
检查普遍性的性能指标（可靠性、稳定性）如何保证；
业务处理能力；
业务预期响应时间；
最大支持用户数；
检查模块定义是否正确；
模块的功能描述明确；
模块与模块的关系与现实关系一致；
3.8.概要设计的验证点：
检查功能点（包括接口）如何实现；
界面的输入项齐全；
界面的输入项的数据类型、输入方式正确；
界面的输出项齐全；
界面的输出项的数据类型、输出方式正确；
接口的输入参数齐全；
接口的输入参数的数据类型正确；
接口的输出参数齐全；
接口的输出参数和返回值的数据类型正确；
接口的输出参数和返回值能反映异常情况；
本模块与其他模块的通讯与总体设计一致；
算法和流程正确；
检查性能指标如何保证；
算法和流程高效；
检查类定义是否正确；
类的功能描述明确；
类不可以再分为两个类；
类与类的关系与现实关系一致；
没有使用友类；
......；
3.9.详细设计的验证点：
检查类实现是否正确；
输入正常的数据并经过正常的处理能得到正常的结果；
输入异常的数据或处理过程中出现的异常能在输出参数或返回值中反映，或抛出异常；
检查类实现是否容易理解；
函数或方法用于正常处理的逻辑分支（循环和分支语句的个数）不会过多（最好5个以内，尽量不超过10个）；
函数或方法的代码行不会过多（最好30行以内，尽量不超过60行）；
代码的验证点；
检查设计中规定的类和方法是否正确定义；
类齐全；
方法齐全；
输入参数齐全；
输入参数的数据类型正确；
输出参数齐全；
输出参数和返回值的数据类型正确；
检查代码中的算法和流程是否与设计一致；
设计中的流程分支有对应的代码分支；
代码中不存在多余的分支；
设计中描述的步骤有对应的代码；
设计中描述的步骤有对应的注释；
检查纠错机制是否完善；
调用函数或方法前有检查输入参数的合法性；
调用函数或方法后有检查输出参数和返回值的合法性；
指针操作前有检查指针是否为空；
检查异常处理机制是否完善；
函数或方法可能抛出的所有异常都有处理；
未知的异常也有处理；
检查数据初始化有否进行；
局部变量有初始化；
类属性有初始化；
全局变量有初始化；
内存申请后有初始化；
检查代码的可读性、可修改性；
文件名、类名、属性名、方法名、变量名、常量名等等命名符合规范；
代码的缩进符合规范；
代码的注释符合规范；
类的声明符合规范；
各种特定的值被定义为常量；
函数或方法的输入参数和输出参数没有被作为工作变量使用；
3.10.用户文档的验证点：
读者对象——主要是文档的内容是否能让该级别的读者理解；
术语——主要是检查术语是否适合读者；
内容和主题——检查主题是否合适、是否丢失、格式是否规范等；
图标和屏幕抓图——检查图表的准确度和精确度；
样例和示例——是否与软件功能一致；
拼写和语法；
文档的关联性——是否与其它相关文档的内容一致，例如与广告信息是否一致；
4.兼容性测试
4.1.兼容性测试含义：
兼容性测试是指要测试的软件在不同的硬件平台上、不同的应用软件之间、不同的操作系统中、不同的网络环境中是否可以正常的运行、有无异常的测试过程。即是通常说的软件的可移植性；
4.2.兼容性测试分类：
浏览器兼容性测试：主要是指的B/S架构中，与浏览器各种内核之间的兼容性问题，检查要测试的软件在不同浏览器上Web页面的样式和元素的展示效果以及交互是否正常；主流浏览器：windows下，IE 9以上、FireFox、Chrome。Mac下，Safari、Chrome、Firefox；
屏幕尺寸和分辨率兼容性测试：检查要测试的软件在不同分辨率下能否正常显示；
操作系统兼容性测试：检查要测试的软件在不同的操作系统下功能是否正常，显示是否正确等；主流操作系统：windows系列、Mac OS X系列、UNIX/Linux系列、Android系列、IOS系列；
不同设备型号兼容性测试：针对于APP，由于移动设备型号众多，则需要测试要测试的APP在主流设备上能否正常运行，会不会出现崩溃的现象；
软件本身能否向前或向后兼容：主要指的是能否兼容不同版本的数据；
测试软件能否与其他相关的软件兼容，例如杀毒软件，文字处理软件，办公软件之间的兼容性；
被测软件与标准外设的兼容，例如打印机；
程序与运行支撑平台版本之间的兼容性，例如是否可以兼容不同的JDK版本，或不同的framework版本等；
程序与应用服务器之间的兼容性：是否支持不同的应用服务器产品，或支持同一应用服务器的不同版本；
不同的网络环境中的兼容性；
数据库之间的兼容性：不同的数据库之间的数据迁移问题；
不同版本程序数据文件之间的兼容性：同一数据库在不同版本的软件上是否能够迁移；
整机的兼容性，例如在本机能安装使用，在其他配置机器能否正常使用；
其他软件的数据兼容性：即别的软件中的数据文件能否经进行处理；
低版本软件生成的文件，高版本软件是否能够打开；
如果是C/S系统，能否支持低版本的客户端程序访问高版本的服务器端或者是否支持高版本的服务器端程序访问低版本的服务器端；
如果是C/S系统，是否允许不同版本的客户端与同一个服务器进行通信；
如果是C/S系统，是否允许不同版本的客户端之间进行通信；
当前软件系统生成的文件或数据是否可以在其他软件中被打开；
是否支持同时安装或运行两个不同版本的软件；
不同版本的软件系统是否能够支持以往的数字证书或硬件加密狗等安全校验文件；
新版本的系统是否和老的应用插件相兼容；
5.易用性测试
5.1.易用性测试的基本概念：
易用性（Useability）是交互的适应性、功能性和有效性的集中体现。易用性属于人体工程学的范畴，人体工程学（ergonomics）是一门将日常使用的东西设计为易于使用和实用性强的学科；
5.2.易用性包括：
易理解性；
易学习性；
易操作性；
吸引性；
依从性；
5.3.优秀UI具备的七个要素：
符合标准和规范；
直观；
一致；
灵活；
舒适；
正确；
实用；
5.4.易用性测试与UI测试：
ＵＩ测试（又称“用户界面测试”）：用于与软件交互的方式称为用户界面或UI；是软件面向用户的主大门，直接影响到用户对软件系统的映像，及后期的使用等；但是，对其的测试仅仅是易用性测试的一个方面，是一个包含的关系；
分清了一件事物的这两个方面，在分析的时候会避免将所有的问题都归结于易用性问题；
5.5.易用性测试验证点：
控件名称应该易懂，用词准确，无歧异；
常用按钮支持快捷方式；
完成同一功能的元素放在一起；
界面上重要信息放在前面；
支持回车；
界面空间小时使用下拉列表框而不使用单选框；
专业性软件使用专业术语；
对可能造成等待时间较长的操作应该提供取消；
对用户可能带来破坏性的操作有回到上一步的机会；
根据需要自动过滤空格；
主菜单的宽度要接近；
工具栏图标与完成的功能有关；
快捷键参考微软标准；
提供联机帮助；
提供多种格式的帮助文件；
提供软件的技术支持方式；
6.安装测试
6.1.安装测试验证点：
安装程序名称为Setup；
选择不同的安装模式安装；
安装在不同的磁盘和路径；
安装过程中有上一步、下一步的选项；
在硬件资源不足下安装；
C/S系统，安装服务端和客户端的顺序；
在笔记本上安装；
在安装前后检查注册表及安装文件或文件夹；
安装时提供Key的输入；
安装后再次安装；
卸载后再次安装；
开始菜单、桌面快捷方式能够打开系统；
软件能够使用；
安装的目录和内容是否正确；
通过添加/删除卸载；
通过自带的卸载程序卸载；
卸载前后检查注册表信息、文件、文件夹、图标；
卸载正在使用的软件；
卸载时突然中断；
6.2.编写软件安装测试用例：
软件在不同操作系统下安装的过程；
软件安装后是否能够正常运行，安装后的文件夹以及文件是否到了指定的目录里；
软件安装各个选项的组合是否符合概要设计说明；
软件安装向导的UI测试；
软件安装过程是否可以取消，单击“取消”按钮后，写入的文件是否如概要设计说明处理；
软件安装过程中意外情况的处理是否符合需求（如死机、重启、断电等）；
安装过程是否可以回溯（即是否可以点上一步重新选择）；
6.3.编写软件卸载测试用例：
直接删除安装文件夹卸载的提示是否与概要设计说明一致；
测试使用系统自带的添加删除（以WindowsXP为例）程序卸载的情况；
测试软件自带的卸载程序；
测试卸载后文件是否全部删除，包括安装文件夹、注册表、系统环境变量；
卸载过程中出现意外情况的测试（如死机、断电、重启）；
卸载是否支持取消功能，单击“取消”按钮后软件卸载的情况；
软件自带卸载程序的UI测试；
如果软件有调用系统文件，当卸载文件时，是否有相应地提示；
6.4.编写软件升级测试用例：
测试升级后的功能是否与需求说明一致；
测试与升级模块相关的模块功能是否与需求一致；
升级安装意外情况的测试（如死机、断电、重启）；
升级界面的UI测试；
不同系统间的升级测试；
6.5.安装测试又可以分为：
全新安装，待安装的软件包是完整的，包含了所有的文件；
升级版本安装，部分文件构成的软件包；
补丁式安装，很小的改动或很少文件的更新，软件版本不变；
系统运行环境改变，性能调优，只改参数，没有软件文件的变化；
声明：本文部分内容可能来源或整理自网络，如有侵权，请联系删除