web功能测试点：
一、输入框
字符型输入框：
（1）字符型输入框：英文全角，英文半角，数字，空或者空格，特殊字符（共32个，特别要注意单引号，下划线，双引号，&），禁止直接输入特殊字符时，使用“粘贴”、“拷贝”功能尝试输入。
（2）长度检查：最小长度，最大长度，最小长度-1，最大长度+1，输入超长字符。
（3）空格检查：输入的字符间有空格，字符后有空格，字符前后有空格。
（4）多行文本框输入：允许回车换行，保存后再显示能够保存输入的格式，仅输入回车换行，检查能否正确保存（若能，检查保存结果，若不能，查看是否有正常提示）。
（5）安全性检查：输入字符串或脚本函数
(null、NULL、Javascript、<script>、</script>、<title>、<html>、<td>）
(<script>alert(\'abc\')</script>)、document(\'abc\')、<b>hello</b>
(https://blog.csdn.net/qq_27424375/article/details/89346020)
数值型输入框
（1）边界值：最大值，最小值，最大值+1，最小值-1
（2）位数：最小位数，最大位数，最小位数-1，输入超长值，输入整数
（3）异常值、特殊字符：输入空白（NULL）、空格或特殊字符等可能导致系统错误的字符，禁止直接输入特殊字符时，尝试使用粘贴拷贝，查看是否能正常提交、word中的特殊功能，通过剪贴板拷贝到输入框，分页符，分节符类似公式的上下标等、数值的特殊符号如∑，㏒，㏑，∏，+，-等、输入负整数、负小数、分数、输入字母或汉字、小数（小数前0点舍去的情况，多个小数点的情况）、首位为0的数字如01、02、科学计数法是否支持1.0E2、全角数字与半角数字、数字与字母混合、16进制，8进制数值、货币型输入（允许小数点后面几位）
（4）安全性检查：不能直接输入就copy
日期型输入框：
（1）合法性检查：(输入0日、1日、32日)、月输入1、3、5、7、8、10、12、日输入31、月输入4、6、9、11、日输入30、31、输入非闰年，月输入2，日期输入28、29、输入闰年，月输入2、日期输入29、30、月输入0、1、12、13
（2）异常值、特殊字符：输入空白或NULL、输入特殊字符等可能导致系统错误的字符
（3）安全性检查：不能直接输入，就copy，是否数据检验出错
信息重复
在一些需要命名,且名字应该唯一的信息输入重复的名字或ID,看系统有没有处理,会否报错,重名包括是否区分大小写,以及在输入内容的前后输入空格,系统是否作出正确处理。
二、搜索功能
若查询条件为输入框，则参考输入框对应类型的测试方法：
功能实现：
（1）如果支持模糊查询，搜索名称中任意一个字符是否能搜索到
（2）比较长的名称是否能查到
（3）输入系统中不存在的与之匹配的条件
（4）用户进行查询操作时，一般情况是不进行查询条件的清空，除非需求特殊说明。
组合测试：
（1）不同查询条件之间来回选择，是否出现页面错误（单选框和多选框最容易出错）
（2）测试多个查询条件时，要注意查询条件的组合测试，可能不同组合的测试会报错。
三、添加、修改功能
特殊键：
（1）是否支持Tab键 （2）是否支持回车键
提示信息：
（1）不符合要求的地方是否有错误提示
唯一性：
（1）字段唯一的，是否可以重复添加，添加后是否能修改为已存在的字段（字段包括区分大小写以及在输入的内容前后输入空格，保存后，数据是否真的插入到数据库中，注意保存后数据的正确性）
数据正确性：
（1）对编辑页的每个编辑项进行修改，点击保存，是否可以保存成功，检查想关联的数据是否得到更新。
（2）进行必填项检查（即是否给出提示以及提示后是否依然把数据存到数据库中；是否提示后出现页码错乱等）
（3）是否能够连续添加（针对特殊情况）
（4）在编辑的时候，注意编辑项的长度限制，有时在添加的时候有，在编辑的时候却没有（注意要添加和修改规则是否一致）
（5）对于有图片上传功能的编辑框，若不上传图片，查看编辑页面时是否显示有默认的图片，若上传图片，查看是否显示为上传图片
（6）修改后增加数据后，特别要注意查询页面的数据是否及时更新，特别是在首页时要注意数据的更新。
（7）提交数据时，连续多次点击，查看系统会不会连续增加几条相同的数据或报错。
（8）若结果列表中没有记录或者没选择某条记录，点击修改按钮，系统会抛异常。
四、删除功能
特殊键：
（1）是否支持Tab键 （2）是否支持回车键
提示信息：
（1）不选择任何信息，直接点击删除按钮，是否有提示
（2）删除某条信息时，应该有确认提示
数据 实现：
（1）是否能连续删除多个产品
（2）当只有一条数据时，是否可以删除成功
（3）删除一条数据后，是否可以添加相同的数据
（4）如系统支持批量删除，注意删除的信息是否正确
（5）如有全选，注意是否把所有的数据删除
（6）删除数据时，要注意相应查询页面的数据是否及时更新
（7）如删除的数据与其他业务数据关联，要注意其关联性（如删除部门信息时，部门下游员工，则应该给出提示）
（8）如果结果列表中没有记录或没有选择任何一条记录，点击删除按钮系统会报错。
如：某一功能模块具有最基本的增删改查功能，则需要进行以下测试
单项功能测试（增加、修改、查询、删除）
增加——>增加——>增加 （连续增加测试）
增加——>删除
增加——>删除——>增加 （新增加的内容与删除内容一致）
增加——>修改——>删除
修改——>修改——>修改 （连续修改测试）
修改——>增加（新增加的内容与修改前内容一致）
修改——>删除
修改——>删除——>增加 （新增加的内容与删除内容一致）
删除——>删除——>删除 （连续删除测试）
五、修改密码
不输入旧密码，直接改密码
输入错误旧密码
不输入确认新密码
新密码和确认新密码不一致
新密码中有空格
新密码为空
新密码格式正确
新密码格式错误
新密码为非允许字符
看是否支持tap和enter键等；密码是否可以复制粘贴；密码是否以*之类的加密符号
看密码是否区分大小写，新密码中小写，确认密码中大写
新密码和旧密码一样能否修改成功
六、注册、登录模块
注册功能：
（1）注册时，设置密码为特殊版本号，检查登录时是否会报错
（2）注册成功后，页面应该以登陆状态跳转到首页或指定页面
（3）在注册信息中删除已输入的信息，检查是否可以注册成功。
登录功能：
（1）输入正确的用户名和正确的密码
（2）输入正确的用户名和错误的密码
（3）输入错误的用户名和正确的密码
（4）输入错误的用户名和错误的密码
（5）不输入用户名和密码（均为空格）
（6）只输入用户名，密码为空
（7）用户名为空，只输入密码
（8）输入正确的用户名和密码，但是不区分大小写
（9）用户名和密码包括特殊字符
（10）用户名和密码输入超长值
（11）已删除的用户名和密码
（12）登录时，当页面刷新或重新输入数据时，验证码是否更新
七、上传图片测试
功能实现：
（1）文件类型正确、大小合适
（2）文件类型正确，大小不合适
（3）文件类型错误，大小合适
（4）文件类型和大小都合适，上传一个正在使用中的图片
（5）文件类型大小都合适，手动输入存在的图片地址来上传
（6）文件类型和大小都合适，输入不存在的图片地址来上传
（7）文件类型和大小都合适，输入图片名称来上传
（8）不选择文件直接点击上传，查看是否给出提示
（9）连续多次选择不同的文件，查看是否上传最后一次选择的文件
八、查询结果列表
功能实现：
（1）列表、列宽是否合理
（2）列表数据太宽有没有提供横向滚动
（3）列表的列名有没有与内容对应
（4）列表的每列的列名是否描述的清晰
（5）列表是否把不必要的列都显示出来
（6）点击某列进行排序，是否会报错（点击查看每一页的排序是否正确）
（7）双击或单击某列信息，是否会报错
九、返回键检查
一条已经成功提交的记录，返回后再提交，是否做了处理
检查多次使用返回键的情况，在有返回键的地方，返回到原来的页面多次，查看是否会出错
十、回车键检查
在输入结果后，直接按回车键，看系统如何处理，是否会报错
十一、刷新键检查
在Web系统中，使用刷新键，看系统如何处理，是否会报错
十二、直接URL链接检查
在Web系统中，在地址栏直接输入各个功能页面的URL地址，看系统如何处理，是否能够直接链接查看（匿名查看），是否有权限控制，是否直接执行，并返回相应结果页。
十三、界面和易用性测试
风格、样式、颜色是否协调
界面布局是否整齐、协调（保证全部显示出来的，尽量不要使用滚动条
界面操作、标题描述是否恰当（描述有歧义、注意是否有错别字）
操作是否符合人们的常规习惯（有没有把相似的功能的控件放在一起，方便操作）
提示界面是否符合规范（不应该显示英文的cancel、ok，应该显示中文的确定等）
界面中各个控件是否对齐
日期控件是否可编辑
日期控件的长度是否合理，以修改时可以把时间全部显示出来为准
查询结果列表列宽是否合理、标签描述是否合理
查询结果列表太宽没有横向滚动提示
对于信息比较长的文本，文本框有没有提供自动竖直滚动条
数据录入控件是否方便
有没有支持Tab键，键的顺序要有条理，不乱跳
有没有提供相关的热键
控件的提示语描述是否正确
模块调用是否统一，相同的模块是否调用同一个界面
用滚动条移动页面时，页面的控件是否显示正常
日期的正确格式应该是XXXX-XX-XX或XXXX-XX-XX XX:XX:XX
页面是否有多余按钮或标签
窗口标题或图标是否与菜单栏的统一
窗口的最大化、最小化是否能正确切换
对于正常的功能，用户可以不必阅读用户手册就能使用
执行风险操作时，有确认、删除等提示吗
操作顺序是否合理
正确性检查：检查页面上的form, button, table, header,footer,提示信息，还有其他文字拼写，句子的语法等是否正确。
系统应该在用户执行错误的操作之前提出警告，提示信息
页面分辨率检查，在各种分辨率浏览系统检查系统界面友好性。
合理性检查：做delete, update, add, cancel, back等操作后，查看信息回到的页面是否合理。
检查本地化是否通过：英文版不应该有中文信息，英文翻译准确，专业。
十四、兼容性测试
兼容性测试不只是指界面在不同操作系统或浏览器下的兼容，有些功能方面的测试，也要考虑到兼容性，
包括操作系统兼容和应用软件兼容，可能还包括硬件兼容
比如涉及到ajax、jquery、javascript等技术的，都要考虑到不同浏览器下的兼容性问题。
十五、链接测试
主要是保证链接的可用性和正确性，它也是网站测试中比较重要的一个方面。
可以使用特定的工具如XENU来进行链接测试。
1.导航测试
导航描述了用户在一个页面内操作的方式，在不同的用户接口控制之间，例如按钮、对话框、列表和窗口等；或在不同的连接页面之间。通过考虑下列问题，可以决定一个Web应用系统是否易于导航：导航是否直观？Web系统的主要部分是否可通过主页存取？Web系统是否需要站点地图、搜索引擎或其他的导航帮助？
在一个页面上放太多的信息往往起到与预期相反的效果。Web应用系统的用户趋向于目的驱动，很快地扫描一个Web应用系统，看是否有满足自己需要的信息，如果没有，就会很快地离开。很少有用户愿意花时间去熟悉Web应用系统的结构，因此，Web应用系统导航帮助要尽可能地准确。
导航的另一个重要方面是Web应用系统的页面结构、导航、菜单、连接的风格是否一致。确保用户凭直觉就知道Web应用系统里面是否还有内容，内容在什么地方。
Web应用系统的层次一旦决定，就要着手测试用户导航功能，让最终用户参与这种测试，效果将更加明显。
2.图形测试
在Web应用系统中，适当的图片和动画既能起到广告宣传的作用，又能起到美化页面的功能。一个Web应用系统的图形可以包括图片、动画、边框、颜色、字体、背景、按钮等。图形测试的内容有：
（1）要确保图形有明确的用途，图片或动画不要胡乱地堆在一起，以免浪费传输时间。Web应用系统的图片尺寸要尽量地小，并且要能清楚地说明某件事情，一般都链接到某个具体的页面。
（2）验证所有页面字体的风格是否一致。
（3）背景颜色应该与字体颜色和前景颜色相搭配。
（4）图片的大小和质量也是一个很重要的因素，一般采用JPG或GIF压缩，最好能使图片的大小减小到30k以下
（5）最后，需要验证的是文字回绕是否正确。如果说明文字指向右边的图片，应该确保该图片出现在右边。不要因为使用图片而使窗口和段落排列古怪或者出现孤行。
通常来说，使用少许或尽量不使用背景是个不错的选择。如果您想用背景，那么最好使用单色的，和导航条一起放在页面的左边。另外，图案和图片可能会转移用户的注意力。
十六、业务流程测试（主要功能测试）
业务流程，一般会涉及到多个模块的数据，所以在对业务流程测试时，首先要保证单个模块功能的正确性，其次就要对各个模块间传递的数据进行测试，这往往是容易出现问题的地方，测试时一定要设计不同的数据进行测试。
十七、安全性测试
SQL注入（比如登陆页面）
XSS跨网站脚本攻击：程序或数据库没有对一些特殊字符进行过滤或处理，导致用户所输入的一些破坏性的脚本语句能够直接写进数据库中，浏览器会直接执行这些脚本语句，破坏网站的正常显示，或网站用户的信息被盗,构造脚本语句时，要保证脚本的完整性。
这里写图片描述
URL地址后面随便输入一些符号，并尽量是动态参数靠后
验证码更新问题
现在的Web应用系统基本采用先注册，后登陆的方式。因此，必须测试有效和无效的用户名和密码，要注意到是否大小写敏感，可以试多少次的限制，是否可以不登陆而直接浏览某个页面等。
Web应用系统是否有超时的限制，也就是说，用户登陆后在一定时间内（例如15分钟）没有点击任何页面，是否需要重新登陆才能正常使用。
为了保证Web应用系统的安全性，日志文件是至关重要的。需要测试相关信息是否写进了日志文件、是否可追踪。
当使用了安全套接字时，还要测试加密是否正确，检查信息的完整性。
服务器端的脚本常常构成安全漏洞，这些漏洞又常常被黑客利用。所以，还要测试没有经过授权，就不能在服务器端放置和编辑脚本的问题。
十八、性能测试
连接速度测试
用户连接到Web应用系统的速度根据上网方式的变化而变化，他们或许是电话拨号，或是宽带上网。当下载一个程序时，用户可以等较长的时间，但如果仅仅访问一个页面就不会这样。如果Web系统响应时间太长（例如超过5秒钟），用户就会因没有耐心等待而离开。
另外，有些页面有超时的限制，如果响应速度太慢，用户可能还没来得及浏览内容，就需要重新登陆了。而且，连接速度太慢，还可能引起数据丢失，使用户得不到真实的页面。
负载测试
负载测试是为了测量Web系统在某一负载级别上的性能，以保证Web系统在需求范围内能正常工作。负载级别可以是某个时刻同时访问Web系统的用户数量，也可以是在线数据处理的数量。例如：Web应用系统能允许多少个用户同时在线？如果超过了这个数量，会出现什么现象？Web应用系统能否处理大量用户对同一个页面的请求？
压力测试
负载测试应该安排在Web系统发布以后，在实际的网络环境中进行测试。因为一个企业内部员工，特别是项目组人员总是有限的，而一个Web系统能同时处理的请求数量将远远超出这个限度，所以，只有放在Internet上，接受负载测试，其结果才是正确可信的。
进行压力测试是指实际破坏一个Web应用系统，测试系统的反映。压力测试是测试系统的限制和故障恢复能力，也就是测试Web应用系统会不会崩溃，在什么情况下会崩溃。黑客常常提供错误的数据负载，直到Web应用系统崩溃，接着当系统重新启动时获得存取权。
压力测试的区域包括表单、登陆和其他信息传输页面等。
备注：(
负载/压力测试应该关注什么
测试需要验证系统能否在同一时间响应大量的用户，在用户传送大量数据的时候能否响应，系统能否长时间运行。可访问性对用户来说是极其重要的。如果用户得到“系统忙”的信息，他们可能放弃，并转向竞争对手。系统检测不仅要使用户能够正常访问站点，在很多情况下，可能会有黑客试图通过发送大量数据包来攻击服务器。出于安全的原因，测试人员应该知道当系统过载时，需要采取哪些措施，而不是简单地提升系统性能。
1）瞬间访问高峰
如果您的站点用于公布彩票的抽奖结果，最好使系统在中奖号码公布后的一段时间内能够响应上百万的请求。负载测试工具能够模拟X个用户同时访问测试站点。
2）每个用户传送大量数据
网上书店的多数用户可能只订购1-5书，但是大学书店可能会订购5000本有关心理学介绍的课本?或者一个祖母为她的50个儿孙购买圣诞礼物(当然每个孩子都有自己的邮件地址)系统能处理单个用户的大量数据吗?
3）长时间的使用
如果站点用于处理鲜花订单，那么至少希望它在母亲节前的一周内能持续运行。如果站点提供基于web的email服务，那么点最好能持续运行几个月，甚至几年。可能需要使用自动测试工具来完成这种类型的测试，因为很难通过手工完成这些测试。你可以想象组织100个人同时点击某个站点。但是同时组织100000个人呢。通常，测试工具在第二次使用的时候，它创造的效益，就足以支付成本。而且，测试工具安装完成之后，再次使用的时候，只要点击几下。
采取措施：采用性能测试工具WAS、ACT，LR等协助进行测试)
十九、测试中应该注意的其他情况
1.在测试时，与网络有关的步骤或者模块必须考虑到断网的情况
2.每个页面都有相应的Title，不能为空，或者显示“无标题页”
3.在测试的时候要考虑到页面出现滚动条时，滚动条上下滚动时，页面是否正常
4.URL不区分大小写，大小写不敏感
5.对于电子商务网站，当用户并发购买数量大于库存的数量时，系统如何处理
6.测试数据避免单纯输入“123”、“abc“之类的，让测试数据尽量接近实际
7.进行测试时，尽量不要用超级管理员进行测试，用新建的用户进行测试。测试人员尽量不要使用同一个用户进行测试
8.提示信息：提示信息是否完整、正确、详细
9.帮助信息：是否提供帮助信息，帮助信息的表现形式（页面文字、提示信息、帮助文件），帮助信息是否正确、详细
10.可扩展性：是否由升级的余地，是否保留了接口
11.稳定性：运行所需的软硬件配置，占用资源情况，出现问题时的容错性，对数据的保护
12.运行速度：运行的快慢，带宽占用情况
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
App测试点（一）
2.1安全测试
2.1.1软件权限
1）扣费风险：包括发送短信、拨打电话、连接网络等
2）隐私泄露风险：包括访问手机信息、访问联系人信息等
3）对App的输入有效性校验、认证、授权、敏感数据存储、数据加密等方面进行检测
4）限制/允许使用手机功能接入互联网
5）限制/允许使用手机发送接受信息功能
6）限制/允许应用程序来注册自动启动应用程序
7）限制或使用本地连接
8）限制/允许使用手机拍照或录音
9）限制/允许使用手机读取用户数据
10) 限制/允许使用手机写人用户数据
11) 检测App的用户授权级别、数据泄漏、非法授权访问等
2.1.2安装与卸载安全性
1）应用程序应能正确安装到设备驱动程序上
2）能够在安装设备驱动程序上找到应用程序的相应图标
3）是否包含数字签名信息
4）JAD文件和JAR包中包含的所有托管属性及其值必需是正确的
5）JAD文件显示的资料内容与应用程序显示的资料内容应一致
6）安装路径应能指定
7）没有用户的允许, 应用程序不能预先设定自动启动
8）卸载是否安全, 其安装进去的文件是否全部卸载
9）卸载用户使用过程中产生的文件是否有提示
10）其修改的配置信息是否复原
11）卸载是否影响其他软件的功能
12）卸载应该移除所有的文件
2.1.3数据安全性
1）当将密码或其他的敏感数据输人到应用程序时, 其不会被储存在设备中, 同时密码也不会被解码
2）输人的密码将不以明文形式进行显示
3）密码, 信用卡明细, 或其他的敏感数据将不被储存在它们预输人的位置上
4）不同的应用程序的个人身份证或密码长度必需至少在4一8 个数字长度之间
5）当应用程序处理信用卡明细, 或其他的敏感数据时, 不以明文形式将数据写到其它单独的文件或者临时文件中。以6）防止应用程序异常终止而又没有侧除它的临时文件, 文件可能遭受人侵者的袭击, 然后读取这些数据信息。
7）当将敏感数据输人到应用程序时, 其不会被储存在设备中
8）备份应该加密, 恢复数据应考虑恢复过程的异常�通讯中断等, 数据恢复后再使用前应该经过校验
9）应用程序应考虑系统或者虚拟机器产生的用户提示信息或安全替告
10）应用程序不能忽略系统或者虚拟机器产生的用户提示信息或安全警告, 更不能在安全警告显示前,，利用显示误导信息欺骗用户，应用程序不应该模拟进行安全警告误导用户
11）在数据删除之前，应用程序应当通知用户或者应用程序提供一个“取消”命令的操作
12）“ 取消” 命令操作能够按照设计要求实现其功能
13）应用程序应当能够处理当不允许应用软件连接到个人信息管理的情况
14）当进行读或写用户信息操作时, 应用程序将会向用户发送一个操作错误的提示信息
15）在没有用户明确许可的前提下不损坏侧除个人信息管理应用程序中的任何内容Μ
16）应用程序读和写数据正确。
17）应用程序应当有异常保护。
18）如果数据库中重要的数据正要被重写, 应及时告知用户
19）能合理地处理出现的错误
20）意外情况下应提示用户
需要更多的软件测试免费资料加群QQ：706315665
2.1.4通讯安全性
1）在运行其软件过程中, 如果有来电、SMS、EMS、MMS、蓝牙、红外等通讯或充电时, 是否能暂停程序，优先处理通信, 并在处理完毕后能正常恢复软件, 继续其原来的功能
2）当创立连接时, 应用程序能够处理因为网络连接中断, 进而告诉用户连接中断的情况
3）应能处理通讯延时或中断
4）应用程序将保持工作到通讯超时, 进而发送给用户一个错误信息指示有连接错误
5）应能处理网络异常和及时将异常情况通报用户
6）应用程序关闭或网络连接不再使用时应及时关闭) 断开
7) HTTP、HTTPS覆盖测试
--App和后台服务一般都是通过HTTP来交互的，验证HTTP环境下是否正常；
--公共免费网络环境中（如：麦当劳、星巴克等）都要输入用户名和密码，通过SSL认证来访问网络，需要对使用HTTP Client的library异常作捕获处理。
2.1.5人机接口安全性
1）返回菜单总保持可用
2）命令有优先权顺序
3）声音的设置不影响应用程序的功能
4）应用程序必需利用目标设备适用的全屏尺寸来显示上述内容
5）应用程序必需能够处理不可预知的用户操作, 例如错误的操作和同时按下多个键
2.2安装、卸载测试
验证App是否能正确安装、运行、卸载以及操作过程和操作前后对系统资源的使用情况
2.2.1安装
1）软件在不同操作系统（Palm OS、Symbian、Linux、Android、iOS、Black Berry OS 6.0、Windows Phone 7）下安装是否正常。
2）软件安装后的是否能够正常运行，安装后的文件夹及文件是否写到了指定的目录里。
3）软件安装各个选项的组合是否符合概要设计说明
4)）软件安装向导的UI测试
5）软件安装过程是否可以取消，点击取消后，写入的文件是否如概要设计说明处理
6）软件安装过程中意外情况的处理是否符合需求（如死机，重启，断电）
7）安装空间不足时是否有相应提示
8）安装后没有生成多余的目录结构和文件
9）对于需要通过网络验证之类的安装，在断网情况下尝试一下
10）还需要对安装手册进行测试，依照安装手册是否能顺利安装
2.2.2卸载
1）直接删除安装文件夹卸载是否有提示信息。
2）测试系统直接卸载程序是否有提示信息。
3）测试卸载后文件是否全部删除所有的安装文件夹。
4）卸载过程中出现的意外情况的测试（如死机、断电、重启）。
5）卸载是否支持取消功能，单击取消后软件卸载的情况 。
6）系统直接卸载UI测试，是否有卸载状态进度条提示 。
2.3 UI测试
测试用户界面(如菜单、对话框、窗口和其它可规控件)布局、风格是否满足客户要求、文字是否正确、页面是否美观、文字、图片组合是否完美、操作是否友好等。
UI测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏觅功能。确保用户界面符合公司或行业的标准。包括用户友好性、人性化、易操作性测试。
2.3.1导航测试
1）按钮、对话框、列表和窗口等；或在不同的连接页面之间需要导航
2）是否易于导航，导航是否直观
3）是否需要搜索引擎
4）导航帮助是否准确直观
5）导航与页面结构、菜单、连接页面的风格是否一致
2.3.2图形测试
1）横向比较。各控件操作方式统一
2）自适应界面设计，内容根据窗口大小自适应
3）页面标签风格是否统一
4）页面是否美观
5）页面的图片应有其实际意义而要求整体有序美观
6）图片质量要高且图片尺寸在设计符合要求的情况下应尽量小
7）界面整体使用的颜色不宜过多
2.3.3内容测试
1）输入框说明文字的内容与系统功能是否一致
2）文字长度是否加以限制
3）文字内容是否表意不明
4）是否有错别字
5）信息是否为中文显示
6）是否有敏感性词汇、关键词
7）是否有敏感性图片，如：涉及版权、专利、隐私等图片
2.4功能测试
根据软件说明或用户需求验证App的各个功能实现，采用如下方法实现并评估功能测试过程：
1)采用时间、地点、对象、行为和背景五元素或业务分析等方法分析、提炼App的用户使用场景，对比说明或需求，整理出内在、外在及非功能直接相关的需求，构建测试点，并明确测试标准，若用户需求中无明确标准遵循，则需要参考行业或相关国际标准或准则。
2)根据被测功能点的特性列丼出相应类型的测试用例对其进行覆盖，如；涉及输入的地方需要考虑等价、边界、负面、异常或非法、场景回滚、关联测试等测试类型对其进行覆盖。
3)在测试实现的各个阶段跟踪测试实现与需求输入的覆盖情况，及时修正业务或需求理解错误。
2.4.1运行
1）App安装完成后的试运行，可正常打开软件。
2）App打开测试，是否有加载状态进度提示。
3）App打开速度测试，速度是否可观。
4）App页面间的切换是否流畅，逻辑是否正确
5）注册
--同表单编辑页面
--用户名密码长度
--注册后的提示页面
--前台注册页面和后台的管理页面数据是否一致
--注册后，在后台管理中页面提示
6）登录
--使用合法的用户登录系统。
--系统是否允许多次非法的登陆，是否有次数限制。
--使用已经登陆的账号登陆系统是否正确处理。
--使用禁用的账号登陆系统是否正确处理。
--用户名、口令（密码）错误或漏填时能否登陆。
--删除或修改后的用户，原用户登陆。
--不输入用户口令和用户、重复点（确定或取消按钮）是否允许登陆。
--登陆后，页面中登陆信息。
--页面中有注销按钮。
--登陆超时的处理。
7）注销
--注销原模块，新的模块系统能否正确处理。
--终止注销能否返回原模块，原用户。
--注销原用户，新用户系统能否正确处理。
--使用错误的账号、口令、无权限的被禁用的账号进行注销
2.4.2应用的前后台切换
1) APP切换到后台，再回到app，检查是否停留在上一次操作界面。
2) APP切换到后台，再回到app，检查功能及应用状态是否正常，IOS4和IOS5的版本的处理机制有的不一样。
3) app切换到后台，再回到前台时，注意程序是否崩溃，功能状态是否正常，尤其是对于从后台切换回前台数据有自动更新的时候。
4) 手机锁屏解屏后进入app注意是否会崩溃，功能状态是否正常，尤其是对于从后台切换回前台数据有自动更新的时候。
5) 当App使用过程中有电话进来中断后再切换到app，功能状态是否正常
6) 当杀掉app进程后，再开启app，app能否正常启动。
7) 出现必须处理的提示框后，切换到后台，再切换回来，检查提示框是否还存在，有时候会出现应用自动跳过提示框的缺陷。
8) 对于有数据交换的页面，每个页面都必需要进行前后台切换、锁屏的测试，这种页面最容易出现崩溃。
2.4.3免登录
很多应用提供免登录功能，当应用开启时自动以上一次登录的用户身份来使用app.
1) app有免登录功能时，需要考虑IOS版本差异。
2) 考虑无网络情况时能否正常进入免登录状态。
3) 切换用户登录后，要校验用户登录信息及数据内容是否相应更新，确保原用户退出。
4) 根据MTOP的现有规则，一个帐户只允许登录一台机器。所以，需要检查一个帐户登录多台手机的情况。原手机里的用户需要被踢出，给出友好提示。
5) app切换到后台，再切回前台的校验
6) 切换到后台，再切换回前台的测试
7) 密码更换后，检查有数据交换时是否进行了有效身份的校验
8) 支持自动登录的应用在进行数据交换时，检查系统是否能自动登录成功并且数据操作无误。
9) 检查用户主动退出登录后，下次启动app，应停留在登录界面
2.4.4数据更新
根据应用的业务规则，以及数据更新量的情况，来确定最优的数据更新方案。
1) 需要确定哪些地方需要提供手动刷新，哪些地方需要自动刷新，哪些地方需要手动+自动刷新。
2) 确定哪些地方从后台切换回前台时需要进行数据更新。
3) 根据业务、速度及流量的合理分配，确定哪些内容需要实时更新，哪些需要定时更新。
4) 确定数据展示部分的处理逻辑，是每次从服务端请求，还是有缓存到本地，这样才能有针对性的进行相应测试。
5) 检查有数据交换的地方，均有相应的异常处理。
2.4.5离线浏览
很多应用会支持离线浏览，即在本地客户端会缓存一部分数据供用户查看。
1) 在无网络情况可以浏览本地数据
2) 退出app再开启app时能正常浏览
3) 切换到后台再切回前台可以正常浏览
4) 锁屏后再解屏回到应用前台可以正常浏览
5) 在对服务端的数据有更新时会给予离线的相应提示
2.4.6 App更新
1) 当客户端有新版本时，有更新提示。
2) 当版本为非强制升级版时，用户可以取消更新，老版本能正常使用。用户在下次启动app时，仍能出现更新提示。
3) 当版本为强制升级版时，当给出强制更新后用户没有做更新时，退出客户端。下次启动app时，仍出现强制升级提示。
4) 当客户端有新版本时，在本地不删除客户端的情况下，直接更新检查是否能正常更新。
5) 当客户端有新版本时，在本地不删除客户端的情况下，检查更新后的客户端功能是否是新版本。
6) 当客户端有新版本时，在本地不删除客户端的情况下，检查资源同名文件如图片是否能正常更新成最新版本。如果以上无法更新成功的，也都属于缺陷。
2.4.7定位、照相机服务
1) App有用到相机，定位服务时，需要注意系统版本差异
2) 有用到定位服务、照相机服务的地方，需要进行前后台的切换测试，检查应用是否正常。
3) 当定位服务没有开启时，使用定位服务，会友好性弹出是否允许设置定位提示。当确定允许开启定位时，能自动跳转到定位设置中开启定位服务。
4) 测试定位、照相机服务时，需要采用真机进行测试。
2.4.8时间测试
客户端可以自行设置手机的时区、时间，因此需要校验该设置对app的影响。
--中国为东8区，所以当手机设置的时间非东8区时，查看需要显示时间的地方，时间是否展示正确，应用功能是否正常。时间一般需要根据服务器时间再转换成客户端对应的时区来展示，这样的用户体验比较好。比如发表一篇微博在服务端记录的是10：00，此时，华盛顿时间为22：00，客户端去浏览时，如果设置的是华盛顿时间,则显示的发表时间即为22:00,当时间设回东8区时间时，再查看则显示为10：00。
2.4.9 PUSH测试
1) 检查push消息是否按照指定的业务规则发送
2) 检查不接受推送消息时，检查用户不会再接收到push.
3) 如果用户设置了免打扰的时间段，检查在免打扰时间段内，用户接收不到PUSH。
在非免打扰时间段，用户能正常收到push。
4) 当push消息是针对登录用户的时候，需要检查收到的push与用户身份是否相符，没有错误地将其它人的消息推送过来。一般情况下，只对手机上最后一个登录用户进行消息推送。
5) 测试push时，需要采用真机进行测试。
2.5性能测试
评估App的时间和空间特性 ：
1)极限测试：在各种边界压力情况下，如电池、存储、网速等，验证App是否能正确响应。
--内存满时安装App
--运行App时手机断电
--运行App时断掉网络
2)响应能力测试：测试App中的各类操作是否满足用户响应时间要求 。
--App安装、卸载的响应时间
--App各类功能性操作的影响时间
3)压力测试：反复/长期操作下、系统资源是否占用异常。
--App反复进行安装卸载，查看系统资源是否正常
--其他功能反复进行操作，查看系统资源是否正常
4)性能评估：评估典型用户应用场景下，系统资源的使用情况。
5)Benchmark测试（基线测试）：与竞争产品的Benchmarking, 产品演变对比测试等。
需要更多的软件测试免费资料加我QQ：706315665
2.6交叉事件测试
针对智能终端应用的服务等级划分方式及实时特性所提出的测试方法。交叉测试又叫事件或冲突测试，是指一个功能正在执行过程中，同时另外一个事件或操作对该过程进行干扰的测试。如；App在前/后台运行状态时与来电、文件下载、音乐收听等关键运用的交互情况测试等。交叉事件测试非常重要，能发现很多应用中潜在的性能问题。
1） 多个App同时运行是否影响正常功能
2） App运行时前/后台切换是否影响正常功能
3） App运行时拨打/接听电话
4） App运行时发送/接收信息
5） App运行时发送/收取邮件
6） App运行时切换网络（2G、3G、wifi）
7） App运行时浏览网络
8） App运行时使用蓝牙传送/接收数据
9） App运行时使用相机、计算器等手机自带设备
2.7兼容测试
主要测试内部和外部兼容性
1）与本地及主流App是否兼容
2）基于开发环境和生产环境的不同，检验在各种网络连接下(WiFi、GSM、GPRS、EDGE、WCDMA、CDMA1x、CDMA2000、HSPDA等)，App的数据和运用是否正确
3）与各种设备是否兼容，若有跨系统支持则需要检验是否在各系统下，各种行为是否一致
--不同操作系统的兼容性，是否适配
--不同手机屏幕分辨率的兼容性
--不同手机品牌的兼容性
2.8回归测试
1）Bug修复后且在新版本发布后需要进行回归测试。
2）Bug修复后的回归测试在交付前、要进行全量用例的回归测试。
2.9升级、更新测试
新版版发布后，配合不同网络环境的自劢更新提示及下载、安装、更新、启劢、运行的验证测试。
1）测试升级后的功能是否与需求说明一样
2）测试与升级模块相关的模块的功能是否与需求一致
3）升级安装意外情况的测试（如死机、断电、重启）
4）升级界面的UI测试
5）不同操作系统间的升级测试
2.10用户体验测试
以主观的普通消费者的角度去感知产品或服务的舒适、有用、易用、友好亲切程度。 通过不同个体、独立空间和非经验的统计复用方式去有效评价产品的体验特性提出修改意见提升产品的潜在客户满意度。
1）是否有空数据界面设计，引导用户去执行操作。
2）是否滥用用户引导。
3）是否有不可点击的效果，如：你的按钮此时处于不可用状态，那么一定要灰掉，或者拿掉按钮，否则会给用户误导
4）菜单层次是否太深
5）交互流程分支是否太多
6）相关的选项是否离得很远
7）一次是否载入太多的数据
8）界面中按钮可点击范围是否适中
9）标签页是否跟内容没有从属关系，当切换标签的时候，内容跟着切换
10）操作应该有主次从属关系
11）是否定义Back的逻辑。涉及软硬件交互时，Back键应具体定义
12）是否有横屏模式的设计，应用一般需要支持横屏模式，即自适应设计
2.11 硬件环境测试
2.11.1手势操作测试
1）手机开锁屏对运行中的App的影响
2）切换网络对运行中的App的影响
3）运行中的App前后台切换的影响
4）多个运行中的App的切换
5）App运行时关机
6）App运行时重启系统
7）App运行时充电
8）App运行时kill掉进程再打开
2.11.2网络环境
手机的网络目前主要分为2G、3G、wifi。目前2G的网络相对于比较慢，测试时尤其要注意此块的测试。
1) 无网络时，执行需要网络的操作，给予友好提示，确保程序不出现crash。
2) 内网测试时，要注意选择到外网操作时的异常情况处理。
3) 在网络信号不好时，检查功能状态是否正常，确保不因提交数据失败而造成crash。
4) 在网络信号不好时，检查数据是否会一直处于提交中的状态，有无超时限制。如遇数据交换失败时要给予提示。
5) 在网络信号不好时，执行操作后，在回调没有完成的情况下，退出本页面或者执行其他操作的情况，有无异常情况。此问题也会经常出现程序crash。
2.11.3服务器宕机或出现404、502等情况下的测试
后台服务牵涉到DNS、空间服务商的情况下会影响其稳定性，如：当出现域名解析故障时，你对后台API的请求很可能就会出现404错误，抛出异常。这时需要对异常进行正确的处理，否则可能会导致程序不能正常工作。
2.12接口测试
服务端一般会提供JSON格式的数据给客户端，所以我们在服务端需要进行接口测试，确保服务端提供的接口并转换的JSON内容正确，对分支、异常流有相应的返回值。此块测试可以采用itest框架进行测试。最方便的是采用httpclient进行接口测试。
进行服务端测试时，需要开发提供一份接口文档。
2.13客户端数据库测试
1）一般的增、删、改、查测试。
2） 当表不存在时是否能自动创建，当数据库表被删除后能否再自建，数据是否还能自动从服务端中获取回来并保存。
3） 在业务需要从服务端取回数据保存到客户端的时候，客户端能否将数据保存到本地。
4） 当业务需要从客户端取数据时，检查客户端数据存在时，app数据是否能自动从客户端数据中取出，还是仍然会从服务器端获取？检查客户端数据不存在时，app数据能否自动从服务器端获取到并保存到客户端
5） 当业务对数据进行了修改、删除后，客户端和服务端是否会有相应的更新。
-----------------------------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------------------------------
H5页面的基本测试点
优势：
H5可以跨平台使用，开发成本相对较低
H5可随时上线就更新版本，适合快速迭代
H5可以轻量的触达用户，提供更便捷的服务
(在微信入口或者浏览器上，用户只需点开链接就可以获取我们锁提供的服务)
劣势：
H5->app的转化强依赖于浏览器
H5目前基本无法将数据存储在本地，依赖实时性数据，网络状态不好的时候卡到哭。
性能相对较低，影响用户体验
如何判断是否是H5页面：
基本上只要对那个view长按，然后看是不是有反应，比如手机震动（Android）、或者出现文字选择粘贴（Android/iOS），那么就是WebView！
如何测试H5：
1.基本功能测试：（浏览器、微信内置浏览器）
2.登陆
目前H5与native各个客户端都做了互通，所以大家在测试的时候要注意两点：
A、若客户端已登录，那么进入H5后仍然是登录状态。
B、若客户端未登录，进入H5，点击对应按钮OR链接，如果需要登录，须拉起native登录。若取消登录，是否可再次拉起登录，或者停留在的页面是否有对应的登录提示。
ps：本次测试过程中就发现，第一次点击链接，可以拉起登录，第二次却不能。
1.2 翻页
遇到翻页加载的页面，需要注意内容为1页或者多页的情况。
A、数据分页加载时，注意后续页面请求数据的正确。
ps：这个需要注意在快速操作场景中，请求页数是不是依次递增，快速操作（如第一页尚未loading出来的时候仍然继续上拉操作）时是否发出去对应的请求了。
3. 刷新与返回
A、下拉刷新是否仍然处于当前页面。
B、用户主动点击刷新按钮是否仍然处于当前页面。
C、点击返回与back键，回退页面是否是期望页面
ps：本次测试过程中就发现，mtop接口请求成功，但是data内无数据时，返回到的就是个空白页面，无法正常发送请求。
4、H5适配相关
H5的适配其实比客户端的相对来说，要少一些，手机品牌之间的差异不大，所以不用太多关注，最容易出现问题的是android2.3系统，这个要特别关注下：
A、大屏（如720*1280，重点关注页面背景是否完全撑开页面，刷新是否有抖动）、小屏手机（如320*480，重点关注下弹框样式和文案折行）
B、android2.3、android4.X随机找一个即可。
C、ios5、ios6、ios7。
5、体验相关
5.1 资源相关
A、页面中有图片的话，淘宝那边建议图片一般不大于50kb，本着一个原则，尽量缩小图片。
B、资源是否压缩、是否通过CDN加载。
C、如何保证二次发布后有效更新。
5.2 流量
A、对于一些不会变化的图片，如游戏动画效果相关图片，不需要每次都请求的东西，做本地缓存。
B、数据较多时是否做了分页加载。
5.3 页面展现时间
A、关注页面首屏加载时间。
5.4 页面提示
A、弱网络下，数据加载较慢，是否有对应的loading提示。
B、接口获取异常时，提示是否友好。
C、刷新页面或者加载新内容时页面是否有抖动。
5.5 手机操作相关
A、锁屏之后展示页面。
B、回退到后台之后，重新呼出在前台展示。
-----------------------------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------------------------------
微信APP和小程序
1.前端页面
微信Web开发者工具安装、授权测试用的微信号可预览和调试小程序...
可参考此文： 微信Web开发者工具-下载、安装和使用图解（https://www.jianshu.com/p/4d3190111eb0）
2.管理后台
配置内网测试服务器环境，通过PC端Web站点管理小程序前端的输出内容，可从开发人员获取管理账号进行测试
二、测试范围
1.权限测试
需要检查以下几种情况下微信用户访问的权限
1）未授权微信登录小程序
未授权时，一般使用一些业务功能的时候，都会弹出提醒：先授权再操作对应功能。or在提交数据到后台的时候，会提示补充相关身份信息才能提交成功
2）已授权微信登录小程序
授权微信访问小程序，意味着自己的微信账号可被小程序管理方所获取，自动以微信的身份行使业务操作权限，比如咨询、支付、数据查询等
3）同一微信号在不同手机端登录授权查看数据权限
同一微信号在不同手机微信端授权登录同一小程序之后，所能查看的数据和操作的权限都应该是同步一致的
2.功能测试
1）按功能模块测试
根据设计好的各个大类功能模块划分，然后再逐级细化，覆盖到每个功能尽可能全面的测试点
2）按业务流程测试
小程序的业务，比如咨询、支付、播放、查询、下载。把各个功能点串联起来形成完整的业务流程来检查；同一个业务，可能有不能的路径来实现，每个路径都需要覆盖检查
3）按数据流向测试
根据数据从某一端操作输入和输出流向，设计基于数据流的测试用例，输出的数据也可能成为另外一端的输入，检查输入的数据是否按照代码逻辑执行正确的输出，是否数据发生异常（无法输入；有输入却无任何输出；输出不正确；多余的输出其他信息...）
4）同一功能不同的入口有效性的检查
小程序中在首页、列表页、详细页、其他的业务功能相关页面，都有可能存在同一个功能的入口，如付费咨询、免费咨询业务中，可以直接从首页进入付费咨询入口，也可以通过免费咨询入口再切换到付费咨询入口。每一个入口路径都需要覆盖检查
5）交互性检查
一般而言，产生数据和功能交互变化的情况主要有这几个分类：前台<-->前台、后台<-->后台、前台<-->后台。前台从A1页面提交的数据，可能需要在前台A2页面查看到，也会在对应后台的B页面查到记录；后台B1页面修改or添加的数据，对应到前台的A页面产生交互变化，后台本身的不同页面之间也可能存在同一个数据的输出值
3.版本配置测试
有时候小程序一次性做了几套不相同的模板，在前端程序代码中修改配置参数，保存后重新编译，即可从一个版本切换到另一版本，同时也需要在管理后台作相应的切换，以保证前端进行数据调用
对于非公用的部分：不同版本直接的切换，需要保证彼此的功能模块和数据独立性不受干扰影响，即不同版本的管理后台所添加的数据只应该调用到各自对应模板的前台小程序中，不同版本的小程序从前台提交的数据也只会提交到各自管理后台，不应该有交差重叠
对于公用的部分：切换不同的模板，都会显示相同的内容
4.兼容性测试
1）手机操作系统
常规的手机端OS为：Android（7.x/6.x/4.x/2.x...）、IOS（11.x/10.x/9.x...）
2）微信版本
对于已上线的小程序，有可能会因为微信版本升级之后导致对部分小程序的组件支持产生冲突，手机端微信上查看的小程序页面出现样式有异常，比如出现少部分区域的黑屏，这种情况需要同步在小程序的程序包中修改一些组件再次更新
5.易用性测试
1）导航
定位到页面某个模块所在位置，回到顶部or底部，导航条的收展，导航标签的文字是否容易理解
2）功能入口
重要且常用业务的功能入口，是否在比较显眼的位置，业务操作过程是否便于大多数用户使用和查看
3）上下层级进入&返回
首页<-->列表页、列表页<-->详细页 、首页<-->详细页。不同层级之间的进入和返回实现是否有相应按键易操作
4）字体、图片、动态交互效果
字体：标签、标题、内容、动态播放字体...
图片：轮播图、背景图、封面图、触屏产生的交互图...
三、注意事项
1.上线
1）上线配置
内网测试、线上测试对应不同url接口；上线前，需要修改内网测试接口地址为正式环境使用的接口。同时还有一个配置参数的 转换设置也要关注到
2）审核
将程序包提交给微信官方进行审核，工作日审核一般0.5d-1d之内可以搞定
3）发布
微信官方审核通过后，即可发布小程序到正式环境中访问使用，通过手机微信端搜索对应小程序的名字即可搜索到
2.常用功能
1）缓存清理
微信Web开发者工具、手机端微信的缓存清理。
使用场景：数据修改后检查修改的效果，程序修改代码后检查效果等情况，可清除缓存后再检查
2）编译
更新测试版本时使用。小程序需要经过几轮的循环测试和修复，开发人员每次修复Bug完成之后会添加新的程序包给到测试人员，测试人员则需要通过微信Web开发者工具删除旧版本的项目程序，重新添加新版本的程序包，然后编译调试
3.常用操作键
新建项目：Ctr+Shift+N
保存：Ctr+S
关闭文件：Ctr+W
搜索：Ctr+F
刷新：Ctr+R
编译：Ctr+B
预览：Ctr+Shift+P
清除缓存
-------------------------------------------------------------------------------
导入导出：
1. 模板测试
1）检查模板是否可以正常下载，正常打开。
2）检查Excel模板文件和系统列表中的数据字段是否一致。
3）模板中是否对必填项做了说明和标识
4）模板中是否对字段长度的约束做了说明
5）模板中是否对特殊字段的格式做了说明
6）模板的排版是否合理，样式是否美观
2. 导入功能
导入成功
1）输入有效数据导入，看是否能导入成功
2）只填写必填项看是否能导入成功
3）最后一列后面加一列数据看是否能导入成功
4）自己手动新建excel或者对其他excel进行修改，使excel格式和模板一致，看是否能导入
5）数据中间空几行数据看是否能导入成功
导入失败
1）数据为空，导入数据为空时是否会提示“导入失败，导入模板中无任何数据”
2）必填项为空，必填项为空时是否会提示“导入失败，并说明具体某一行的某个字段为空”
3）数据不符合规则
① 所有行均存在格式不符合规则的数据，是否会提示“导入失败，并给出每一行对应的错误原因”
② 所有行均存在超出长度范围的数据，是否会提示“导入失败，并给出每一行对应的错误原因”
③ 部分符合规则，部分不符合规则
对于③，根据需求不同，可能存在下面两种情况：
a、符合规则的导入成功，不符合规则的导入失败，并给出失败行对应的错误原因
b、导入失败，并给出失败行对应的错误原因
4）模板内的数据之间存在重复
可能存在下面两种情况：
a、除重复行之外的其他数据导入成功，重复行中的第一行导入成功，后面一行导入失败，并给出失败行对应的错误原因
b、导入失败，并给出失败行对应的错误原因
5）模板内的数据与系统中已经存在的数据冲突
根据需求不同，可能存在下面两种情况：
a、除存在冲突之外的其他数据导入成功，存在冲突的行导入失败，并给出失败行对应的错误原因
b、导入失败，并给出失败行对应的错误原因
6）表头检查：包括去掉、修改、新增列、列之间切换，看数据是否能成功导入
7）导入其他格式的文件，当导入的文件格式不正确时，系统是否做出正确的判断，并给出对应的错误提示。
8）不选择导入文件：无法导入，并提示“请选择导入文件”
9）取消导入：取消导入操作成功，并不执行导入操作
10）模板内的数据存在冲突（比如：截止日期小于起始日期之内）
11）新增一行数据，然后将数据删除【如果开发判断方法有误，会认为删除的这条数据也存在】
3. 导出功能
1）导出的excel文件名是否有要求，如果有要求，是否正确。
2）导出的excel表格的格式检查，主要检查导出的excel格式是否符合预期，各字段是否正确。
3）导出全部数据功能是否正确
4）导出部分数据功能是否正确
5）选择数据为空时是否可以导出。
6）导出的数据内容是否与系统中的内容一致。
7）不同浏览器导出的文件是否一致
8）excel导出时数据的分页检查。【一般数据量较大时，开发都会分批次去取数据，分页时容易出现问题】
9）注意导出文件的排版问题，当某一字段的内容过长时，是否可以自动换行
-------------------------------------
查询：
若查询条件为输入框，则参考输入框对应类型的测试方法
1、功能实现：
（1）如果支持模糊查询，搜索名称中任意一个字符是否能搜索到
（2）比较长的名称是否能查到
（3）输入系统中不存在的与之匹配的条件
（4）用户进行查询操作时，一般情况是不进行查询条件的清空，除非需求特殊说明。
2、组合测试：
（1）不同查询条件之间来回选择，是否出现页面错误（单选框和多选框最容易出错）
（2）测试多个查询条件时，要注意查询条件的组合测试，可能不同组合的测试会报错。
用例：
默认条件查询
按各查询条件是否都能够查询出相应的值
组合查询数据
模糊查询
日期查询－测试边界值查询是否正常
日期查询－测试当存在开始日期及结束日期进行查询时，是否对其进行了逻辑判断
日期查询－测试对日期型字段查询时,是否进行了溢出控制
查询功能需自动处理输入内容两端的空格
执行查询操作后,查询条件是否能保留
是否控制了各种非法字符的查询
另一个搜索功能测试点：
--正向测试
1.搜索功能是否符合需求并正确实现。
2.检索网站中存在的数据 ，结果是否准确。
--反向测试
1.如果支持模糊查询，搜索名称中任意一个字符是否能搜索到
2.检查超长的搜索条件是否能查到
-错误测试法
1.输入当前键盘中的所有特殊字符 ，单个或组合，查看系统响应
2.输入系统中不存在的与之匹配的条件是否可以检索到。
-易用性测试
1.检查系统是否支持Enter键，tab键。
2.检查搜索结果页是否与其他页面风格统一，样式一致 。
3.检查光标置于搜索框中时，是否自动清空当前默认内容。
-安全测试法
1.输入一些弹框代码或SQL命令，检查系统响应
------------------------------------------------------------
排序功能测试点：
-正向测试
1.点击升序排列按钮，检查排序结果 （文字排序时是否按照拼音首字母，数字排序时是否皇家马德里大小）。
2.点击降序排列按钮，检查排序结果 。
-反向测试
1.反复点击排序按钮，检查系统响应。
2.按某个条件排序后，点击进入中间页，再按另一个条件进行排序，检查页面刷新。
--------------------------------------------------------
登录功能测试点：
验证登录流程判断逻辑
前端
账户名、密码、验证码 是否为空？
密码是否符合规则(特殊字符、大小写、数字、长度..)
服务端
验证码是否正确 （对应时间戳是否过期）
账户是否存在 （未注册、已注销）
密码是否正确 （记录连续输入错误次数，超过5次，账号锁定4小时。或提升验证等级，采取账号+密码+验证码+短信验证）
返回session、token
一、基本功能测试点：
输入正确的用户名和密码登录成功
输入错误的用户名密码登录失败
用户名正确，密码错误，是否提示输入密码错误？
用户名错误，密码正常，是否提示输入用户名错误？
用户名和密码都错误，是否有相应提示？
用户名密码为空时，是否有相应提示？
如果用户未注册，提示请先注册，然后进行登录
已经注销的用户登录失败，提示信息友好？
密码框是否加密显示？
用户名是否支持中文、特殊字符？
用户名是否有长度限制？
密码是否支持中文，特殊字符？
密码是否有长度限制？
密码是否区分大小写？
密码为一些简单常用字符串时，是否提示修改？如：123456
密码存储方式？是否加密？
登录功能是否需要输入验证码？
验证码有效时间？
验证码输入错误，登录失败，提示信息是否友好？
输入过期的验证能否登录成功？
验证码是否容易识别？
验证码换一张功能是否可用？点击验证码图片是否可以更换验证码？
用户体系：比如系统分普通用户、高级用户，不同用户登录系统后可的权限不同。
如果使用第三方账号(QQ,微博账号)登录，那么第三方账号与本系统的账号体系对应关系如何保存？首次登录需要极权等
二、页面测试：
登录页面显示是否正常？文字和图片能否正常显示，相应的提示信息是否正确，按钮的设置和排列是否正常，页面是否简洁壮观等。
页面默认焦点是否定位在用户名的输入框中
首次登录时相应的输入框是否为空？或者如果有默认文案，当点击输入框时默认方案是否消失？
相应的按钮如登录、重置等，是否可用;页面的前进、后退、刷新按钮是否可用？
快捷键Tab,Esc,Enter 等，能否控制使用
兼容性测试：不同浏览器，不同操作系统，不同分辨率下界面是否正常
三 、安全测试：
不登录：浏览器中直接输入登录后的地址，看是否可以直接进入
登录成功后生成的Cookie，是否是httponly (否则容易被脚本盗取)
用户名和密码是否通过加密的方式，发送给Web服务器
用户名和密码的验证，应该是用服务器端验证， 而不能单单是在客户端用javascript验证
用户名和密码的输入框，应该屏蔽SQL 注入攻击
用户名和密码的的输入框，应该禁止输入脚本 （防止XSS攻击）
错误登陆的次数限制（防止暴力破解）
考虑是否支持多用户在同一机器上登录；
考虑一用户在多台机器上登录
四、性能测试：
单用户登录系统的响应时间是否符合"3-5-8"原则
用户数在临界点时并发登录是否还能符合"3-5-8"原则
压力：大量并发用户登录，系统的响应时间是多少？系统会出现宕机、内存泄露、cpu饱和、无法登录吗?
稳定性： 系统能否处理并发用户数在临界点以内连续登录N个时的场景？
五、其它测试：
连续输入3次或以上错误密码，用记是否被锁一定时间（如：15分钟）？时间内不允许登录，超出时间点是否可以继续登录。
用户session过期后，重新登录是否还能重新返回这前session过期的页面？
用户名和密码输入框是事支持键盘快捷键？如：撤销、复制、粘贴等等
是否允许同名用户同时登录进行操作？考虑web和app同时登录
手机登录时，是否先判断网络可用？
手机登录时，是否先判断app存在新版本？
是否支持单点登录？
是否有埋点接口
------------------------------------------------------
下拉框测试点：
基本测试：
1)默认值(为空，提示选择，某一值)检查；
2)列表内容，是可变还是固定的，可变的最好要用SQL或其他方式验证正确性，不允许出现重复值；
3)列表中的排序方式，特别是选项过多时尤为重要；
4)列表过长是否提供滚动条支持，一般超过10个需要滚动条；
5)选择一个选项后是否可编辑，有的下拉菜单允许编辑选择，这还需要验证其合法性；
6)列表中文本的对齐方式，一般都是左对齐；
7)选择框的长度是否可变；
8)选择框的长度是否合适，是否会出现选择项后不能全部显示其内容；
9)下拉菜单获取焦点后，是否可以通过键盘操作，主要包括↑,↓,Home ,End ,PageUP ,PageDown等。
可编辑的下拉菜单测试：
1)插入新值，检查输入合法性，重复值要提示；插入值长度、个数是否有限制；
2)删除一个值；能否删除默认值；是否所有的预置选项可删除，是否可删除所有选项；
3)新增，删除选项后，下拉菜单内容是否能正确显示。
下拉菜单联动检查：
假设有A、B、C三个下拉菜单，A联动B，B联动C；这时需要检查：
1)A选择一个选项后，B下拉菜单内容应该是A中这一项所包括的所有内容；
2)选择B中的一个选项，C下拉菜单内容应该是B中这一项所包括的所有内容；
3)更改A中的内容，B，C菜单应该做相应改变；
4)更改B中内容，C菜单应做相应改变。
----------------------------------------------------------
添加、修改功能测试点：
1、特殊键：（1）是否支持Tab键 （2）是否支持回车键
2、提示信息：（1）不符合要求的地方是否有错误提示
3、唯一性：（1）字段唯一的，是否可以重复添加，添加后是否能修改为已存在的字段（字段包括区分大小写以及在输入的内容前后输入空格，保存后，数据是否真的插入到数据库中，注意保存后数据的正确性）
4、数据 正确性：
（1）对编辑页的每个编辑项进行修改，点击保存，是否可以保存成功，检查想关联的数据是否得到更新。
（2）进行必填项检查（即是否给出提示以及提示后是否依然把数据存到数据库中；是否提示后出现页码错乱等）
（3）是否能够连续添加（针对特殊情况）
（4）在编辑的时候，注意编辑项的长度限制，有时在添加的时候有，在编辑的时候却没有（注意要添加和修改规则是否一致）
（5）对于有图片上传功能的编辑框，若不上传图片，查看编辑页面时是否显示有默认的图片，若上传图片，查看是否显示为上传图片
（6）修改后增加数据后，特别要注意查询页面的数据是否及时更新，特别是在首页时要注意数据的更新。
（7）提交数据时，连续多次点击，查看系统会不会连续增加几条相同的数据或报错。
（8）若结果列表中没有记录或者没选择某条记录，点击修改按钮，系统会抛异常。
添加功能测试点
添加按钮
添加窗口
添加空数据
添加数据-缺少必填项
添加一条数据
添加唯一字段重复的数据
关闭功能
Tab键的使用
Tab键和Enter键联合使用
Esc键
字段长度的限制
下拉框
日期格式设置
非负整型数据
空格
确定按钮
修改功能测试点
修改按钮
Tab键的使用
Tab键和Enter键联合使用
Esc键
字段长度的限制
下拉框
日期格式设置
非负整型数据
空格
修改后取消
必填项不填的保存提示
将内容修改超过指定长度
添加唯一字段重复的数据
Html脚本限制
修改后保存
-------------------------------------------------------------------------------------
文件上传和下载测试点：
文件上传：
页面
页面美观性、易用性（键盘和鼠标的操作、tab跳转的顺序是否正确）
按钮文字正确性
说明文字是否正确
正确/错误的提示文字是否正确
提示当前位置是否正确，并且和其他页面保持一致格式
必填项的标示是否正确
功能
路径是否可以手工输入（手工输入的时候有没有限长）
上传文件超过最大值是在提交前校验还是提交后校验
上传文件格式是否全部支持（图片：gif/jpg/bmp…文档：doc/sxw/xls…压缩包：zip/rar…安装文件：exe/msi）
上传文件是否支持中文名称
文件名称的最大值、最小值、特殊字符（包含空格）、使用程序语句是否会对其造成影响、中文名称是否能正常显示
对于是否发布的设置是否正确（前台校验）
简介最大值、特殊字符、使用程序语句是否会对其造成影响
按钮
保存按钮
对输入项有错误提示后光标提示是否正确
对输入项的错误提示是否描述正确
对必添项是否进行校验
清空按钮
是否清除（或还原）了填写内容
返回按钮
是否返回上一页面
文件下载：
页面
当前位置的提示是否现实正确
页面美观性、易用性（键盘和鼠标的操作、tab跳转的顺序是否正确）
按钮文字是否正确
说明性文字是否正确
正确/错误的提示文字是否正确
功能*
右键另存为是否可以正确下载文件，并且记录下载次数
工具下载是否正确，并且记录下载次数
单击下载是提示下载还是在页面打开
直接打开是否显示正确
对于本机没有安装工具的文件是否能够打开，是否能给出正确的提示
对于直接在页面内打开的内容是否能够显示正常，页面美观性
保存到本地是否能正确显示
取消下载是否会纪录下载次数
下载次数是否被正确记录
后台没有发布的文件是否在前台可以找到并下载
后台设置了下载权限的文件是否可以被正确看到、是否可以下载
按钮
返回按钮是否回到上一页面
再补充一些其他的常见测试点：
图片上传后，图片分辨率的检查，保证图片不失真，不变形；
上传相同名称的图片，具体看需求，是对上传后的图片进行重命名，还是不允许同名；
上传过程中，是否可重复操作上传；
出于安全考虑，变种的可执行文件，进行上传，如.exe.jpg；
出于性能考虑，在服务器存放图片的目录查看，上传后的图片与原图片，大小不会发生猛烈上涨；而一般开发会对图片做适量的压缩，所以上传后的图片一般是等于或者小于原图片大小的；
上传文件名测试，检查不符合文件名规范
上传文件名类型测试，检查不同文件类型是否支持如：.rar,.mp3,avi等
上传文件大小测试，检查不同文件规格大小如：0字节文件, 1kb, 200kb, 2mb, 20mb,2g等
上传文件容错性测试：如检查覆盖同文件操作；
上传文件异常情况测试：如硬盘空间不足
上传文件速率性能测试：检查上传不同的文件在不同的网络环境响应速度，及系统资源占用
上传文件安全性测试：如上传常见木马
上传文件易用性测试：检查上传文件操作是否让用户易于学习和理解使用等
上传文件特性测试：如果支持如断点续传等一些特性
上传文件后，检查是否与源文件一致，包含目录设置等
上传文件，是否能打开等
-----------------------------------------------------------
文本框测试点：
一、文本框为字符型
•必填项非空校验：
1、必填项未输入－－程序应提示错误；
2、必填项只输入若干个空格，未输入其它字符－－程序应提示错误；
•字段唯一性校验：（不是所有字段都作此项校验，视实际项目情况而定）
1、新增时输入重复的字段值－－必须提示友好信息；
2、修改时输入重复的字段值－－必须提示友好信息；
•字段长度校验：
1、输入[最小字符数-1]－－程序应提示错误；
2、输入[最小字符数]－－OK；
3、输入[最小字符数+1]－－程序应提示错误；
4、输入[最大字符数-1]－－OK；
5、输入[最大字符数]－－OK；
6、输入[最大字符数+1]－－程序应提示错误；
•字段为特殊字符校验：
1、输入域如对某些字符禁止输入时，限制是否成功，提示信息是否友好 ；
2、中文、英文、空格，数字，字符，下划线、单引号 等所有特殊字符的组合 ；
3、所有特殊字符都必须进行测试（!~@#$^&*()_+{}|:“<>?/.,;‘[]\=-`￥……（）--：《》？、。，；’【】、=-· ）
•字段为特殊代码校验：
1、输入htm代码：比如” <font>你好</font>”；－－必须以文本的形式将代码显示出来。
2、输入JavaScript代码：比如<param name=“MovieWindowWidth” value=“320”>；－－必须以文本的形式将代码显示出来。
•多行文本框输入：
1、是否允许回车换行 ；
2、保存后再显示能够保持输入时的格式 ；
3、仅输入回车换行，检查能否正确保存；若能，查看保存结果。若不能，查看是否有正确提示 ；
4、仅输入空格，检查能否正确保存；若能，查看保存结果。若不能，查看是否有正确提示 。
二、文本框为数值型
•边界值：
1、输入[最小值-1]－－程序应提示错误；
2、输入[最小值]－－OK；
3、输入[最大值]－－OK；
4、输入[最大值+1]－－程序应提示错误；
•位数：
1、输入[限制位数]－－OK；
2、输入[限制位数+1]－－根据实际项目而定，是否自动四舍五入成限制位数，还是提示信息；
3、输入[限制位数-1]－－OK；
•异常值、特殊值：
1、输入非数值型数据：汉字、字母、字符－－程序应提示错误；
2、输入负数－－根据实际项目而定，如果不允许输入负数，必须提示友好信息；
3、字段禁止直接输入非数值型数据时，使用“粘贴”、“拷贝”功能尝试输入，并测试能否正常提交保存－－只能使用“粘贴”、“拷贝”方法输入的特殊字符应无法保存，并应给出相应提示 ；
4、全角数字和半角数字的情况－－全角数字不能保存，提示友好信息，半角数字正常保存；
5、首位为零的数值：如01＝1－－视实际项目情况而定；
三、文本框为日期型
•合法性检查：
1、日输入[0日]－－程序应提示错误；
2、日输入[1日]－－OK；
3、日输入[32日]－－程序应提示错误；
4、月输入[1、3、5、7、8、10、12月]、日输入[31日]－－OK；
5、月输入[4、6、9、11月]、日输入[30日]－－OK；
6、月输入[4、6、9、11月]、日输入[31日]－－程序应提示错误；
7、输入非闰年,月输入[2月]、日输入[28日]，比如2009.2.28－－OK；
8、输入非闰年,月输入[2月]、日输入[29日]，比如2009.2.29－－程序应提示错误
9、(闰年)月输入[2月]、日输入[29日]，比如2008.2.29－－OK；
10、(闰年)月输入[2月]、日输入[30日]，比如2008.2.30－－程序应提示错误；
11、月输入[0月]－－程序应提示错误；
12、月输入[1月]－－OK；
13、月输入[12月]－－OK；
14、月输入[13月] －－程序应提示错误；
•格式检查：
1、不合法格式：2009-09、 2009-09 -、200-2-2；
2、视具体项目而定是否合法：2009/09/01、2009.09.01 、20090901、2009-09-01 ；
•异常值、特殊值：
1、输入汉字、字母、字符－－程序应提示错误；
四、文本框为时间型
•合法性检查：
1、时输入[24时] －－程序应提示错误；
2、时输入[00时] －－OK；
3、分输入[60分] －－程序应提示错误；
4、分输入[59分] －－OK；
5、分输入[00分] －－OK；
6、秒输入[60秒] －－程序应提示错误；
7、秒输入[59秒] －－OK；
8、秒输入[00秒] －－OK；
•格式检查：
1、不合法格式：12:30:、 123000；
2、视具体项目而定是否合法：12:30、 1:3:0；
•异常值、特殊值：
1、输入汉字、字母、字符－－程序应提示错误；
2、系统中所涉及时间是否取服务器时间；
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------------------------------Hello world----------------------------------------------------
常见功能测试点：
1. 登陆、添加、删除、查询模块是我们经常遇到的，这些模块的测试点该如何考虑
1)登陆
① 用户名和密码都符合要求(格式上的要求)
② 用户名和密码都不符合要求(格式上的要求)
③ 用户名符合要求，密码不符合要求(格式上的要求)
④ 密码符合要求，用户名不符合要求(格式上的要求)
⑤ 用户名或密码为空
⑥ 数据库中不存在的用户名，不存在的密码
⑦ 数据库中存在的用户名，错误的密码
⑧ 数据库中不存在的用户名，存在的密码
⑨ 输入的数据前存在空格
⑩ 输入正确的用户名密码以后按[enter]是否能登陆
2) 添加
① 要添加的数据项均合理，检查数据库中是否添加了相应的数据
② 留出一个必填数据为空
③ 按照边界值等价类设计测试用例的原则设计其他输入项的测试用例
④ 不符合要求的地方要有错误提示
⑤ 是否支持table键
⑥ 按enter是否能保存
⑦ 若提示不能保存，也要察看数据库里是否多了一条数据
3) 删除
① 删除一个数据库中存在的数据，然后查看数据库中是否删除
② 删除一个数据库中并不存在的数据，看书否有错误提示，并且数据库中没有数据被删除
③ 输入一个格式错误的数据，看是否有错误提示，并且数据库中没有数据被删除。
④ 输入的正确数据前加空格，看是否能正确删除数据
⑤ 什么也不输入
⑥ 是否指出table键
⑦ 是否支持enter键
4)查询
精确查询：
① 输入的查询条件为数据库中存在的数据，看是否能正确地查出相应得数据
② 输入正确的查询条件以前加上空格，看是否能正确地查出相应的数据
③ 输入格式或范围不符合要求的数据，看是否有错误提示
④ 输入数据库中不存在的数据
⑤ 不输入任何数据
⑥ 是否支持table键
⑦ 是否支持enter键
模糊查询：
在精确查询的基础上加上以下一点
① 输入一些字符，看是否能查出数据库中所有的相关信息
2.设计功能测试用例
文本框、按钮等控件测试
1、文本框的测试
如何对文本框进行测试
a,输入正常的字母或数字。
b,输入已存在的文件的名称;
c,输入超长字符。例如在“名称”框中输入超过允许边界个数的字符，假设最多255个字符，尝试输入 256个字符，检查程序能否正确处理;
d,输入默认值，空白，空格;
e,若只允许输入字母，尝试输入数字;反之;尝试输入字母;
f,利用复制，粘贴等操作强制输入程序不允许的输入数据;
g,输入特殊字符集，例如，NUL及\n等;
h,输入超过文本框长度的字符或文本，检查所输入的内容是否正常显示;
i,输入不符合格式的数据，检查程序是否正常校验，如，程序要求输入年月日格式为yy/mm/dd，实际输入yyyy/mm/dd，程序应该给出错误提示
在测试过程中所用到的测试方法：
1,输入非法数据;
2,输入默认值;
3,输入特殊字符集;
4,输入使缓冲区溢出的数据;
5,输入相同的文件名;
2、命令按钮控件的测试
a,点击按钮正确响应操作。如，单击确定，正确执行操作;单击取消，退出窗口;
b,对非法的输入或操作给出足够的提示说明，如，输入月工作天数为32时，单击”确定“后系统应提示:天数不能大于31;
c,对可能造成数据无法恢复的操作必须给出确认信息，给用户放弃选择的机会;
3、单选按钮控件的测试
a,一组单选按钮不能同时选中，只能选中一个。
b,逐一执行每个单选按钮的功能。分别选择了“男”“女”后，保存到数据库的数据应该相应的分别为“男”“女”;
c,一组执行同一功能的单选按钮在初始状态时必须有一个被默认选中，不能同时为空;
4、up-down控件文本框的测试
a,直接输入数字或用上下箭头控制，如，在“数目”中直接输入10，或者单击向上的箭头，使数目变为10;
b,利用上下箭头控制数字的自动循环，如，当最多数字为253时，单击向上箭头，数目自动变为1;反之亦适用;
c,直接输入超边界值，系统应该提示重新输入;
d,输入默认值，空白。如，“插入”数目为默认值，点击“确定”;或，删除默认值，使内容为空，单击“确定”进行测试;
e,输入字符。此时系统应提示输入有误。
5、组合列表框的测试
a,条目内容正确，其详细条目内容可以根据需求说明确定;
b,逐一执行列表框中每个条目的功能;
c,检查能否向组合列表框输入数据;
6、复选框的测试
a,多个复选框可以被同时选中;
b,多个复选框可以被部分选中;
c,多个复选框可以都不被选中;
d,逐一执行每个复选框的功能;
7、列表框控件的测试
a,条目内容正确;同组合列表框类似，根据需求说明书确定列表的各项内容正确，没有丢失或错误;
b,列表框的内容较多时要使用滚动条;
c,列表框允许多选时，要分别检查shift选中条目，按ctrl选中条目和直接用鼠标选中多项条目的情况;
8、滚动条控件的测试
要注意一下几点：
a,滚动条的长度根据显示信息的长度或宽度及时变换，这样有利于用户了解显示信息的位置和百分比，如，word中浏览100页文档，浏览到50页时，滚动条位置应处于中间;
b,拖动滚动条，检查屏幕刷新情况，并查看是否有乱码;
c,单击滚动条;
d,用滚轮控制滚动条;
e,滚动条的上下按钮。
9、各种控件在窗体中混和使用时的测试
a,控件间的相互作用;
b,tab键的顺序，一般是从上到下，从左到右;
c,热键的使用，逐一测试;
d,enter键和esc键的使用;
在测试中，应遵循由简入繁的原则，先进行单个控件功能的测试，确保实现无误后，再进行多个控件的的功能组合的测试。
ps:密码输入框测试时要特别注意进行字母大写输入的测试。
查找替换操作
案例演示:打开word中的"替换"对话框
测试本功能有通过测试和失败测试两种情况
通过测试:
1,输入内容直接查找,或查找全部
2,在组合框中寻找已经查找过的内容,再次查找并确认文档的内容正确,如,已经查找过"测试用例",再次进入不用重新输入查找内容,直接在文档中搜寻就可以.
失败测试:
1,输入过长或过短的查询字符串.如,假设查询的字符串长度为1到255,那么输入0,1,2,256,255和254进行测试;
2,输入特殊字符集,如,在word中.^g代表图片,^代表分栏符,可以输入这类特殊字符测试;
替换测试大体相同.
关于编辑操作窗口的功能测试的用例:
1,关闭查找替换窗口.不执行任何操作,直接退出;
2,附件和选项测试.假如,设定"精确搜寻","向后"搜索等附件选项等等来测试;
3,控件间的相互作用.如,搜寻内容为空时,按钮"搜寻全部","搜寻","全部替换","替换"都为灰色.
4,热键, Tab键.回车键的使用.
插入操作
1)插入文件
测试的情况
a,插入文件;
b,插入图像;
c,在文档中插入文档本身;
d,移除插入的源文件;
e,更换插入的源文件的内容;
2)链接文件
测试方法:
a,插入链接文件;
b,在文档中链接文档本身;
c,移除插入的源文件;
d,更换插入的源文件的内容.
3)插入对象
要测试的内容
a,插入程序允许的对象,如,在word中插入excel工作表;
b,修改所插入对象的内容.插入的对象仍能正确显示;
c,卸载生成插入对象的程序,如,在word中插入excel工作表后卸载excel,工作表仍正常使用.
编辑操作
编辑操作包括剪切,复制,粘贴操作.
测试剪切操作的方法
a,对文本,文本框,图文框进行剪切;
b,剪切图像
c,文本图像混合剪切
复制操作方法与剪切类似.
测试时,主要是对粘贴操作的测试,方法是:
a,粘贴剪切的文本,文本框及图文框;
b,粘贴所剪切的图像;
c,剪切后,在不同的程序中粘贴
d,多次粘贴同一内容,如,剪切后,在程序中连续粘贴3次;
e,利用粘贴操作强制输入程序所不允许输入的数据.
3.界面测试用例的设计方法
1)窗体
测试窗体的方法:
a,窗体大小,大小要合适,控件布局合理;
b,移动窗体.快速或慢速移动窗体,背景及窗体本身刷新必须正确;
c,缩放窗体,窗体上的控件应随窗体的大小变化而变化;
d,显示分辨率.必须在不同的分辨率的情况下测试程序的显示是否正常;
进行测试时还要注意状态栏是否显示正确;工具栏的图标执行操作是否有效,是否与菜单懒中图标显示一致;错误信息内容是否正确,无错别字,且明确等等;
2)控件
测试方法:
a,窗体或控件的字体和大小要一致;
b,注意全角,半角混合
c,无中英文混合.
3)菜单
进行测试时要注意
a,选择菜单是否可以正常工作,并与实际执行内容一致;
b,是否有错别字:
c,快捷键是否重复;
d,热键是否重复;
e,快捷键与热键操作是否有效
f,是否存在中英文混合
g,菜单要与语境相关,如,不同权限的用户登陆一个应用程序,不同级别的用户可以看到不同级别的菜单并使用不同级别的功能;
h,鼠标右键快捷菜单
4)特殊属性
1,安装界面应有公司介绍或产品介绍,有公司的图标
2,主界面及大多数界面最好有公司图标
3,选择"帮助"->"关于"命令,应 看见相关版权和产品信息
------------恢复内容结束------------