测试用例的编写需要按照一定的思路进行，而不是想到哪写到哪，一般测试机制成熟的公司都会有公司自己自定义的测试用例模板，以及一整套的测试流程关注点，当然我们自己在测试生涯中也应当积累一套自己的测试框架，所有功能性的测试都可以依据框架的思路来进行，达到事半功倍的效果。
功能测试框架可以包括：界面友好性测试、功能测试、链接测试、容错测试、稳定性测试、常规性能测试、配置测试、算法测试等等。
1.1.1 界面友好性测试
1. 风格、样式、颜色是否协调
2. 界面布局是否整齐、协调（保证全部显示出来的，尽量不要使用滚动条
3. 界面操作、标题描述是否恰当（描述有歧义、注意是否有错别字）
4. 操作是否符合人们的常规习惯（有没有把相似的功能的控件放在一起，方便操作）
5. 提示界面是否符合规范（不应该显示英文的cancel、ok，应该显示中文的确定等）
6. 界面中各个控件是否对齐
7. 日期控件是否可编辑
8. 日期控件的长度是否合理，以修改时可以把时间全部显示出来为准
9. 查询结果列表列宽是否合理、标签描述是否合理
10. 查询结果列表太宽没有横向滚动提示
11. 对于信息比较长的文本，文本框有没有提供自动竖直滚动条
12. 数据录入控件是否方便
13. 有没有支持Tab键，键的顺序要有条理，不乱跳
14. 有没有提供相关的热键
15. 控件的提示语描述是否正确
16. 模块调用是否统一，相同的模块是否调用同一个界面
17. 用滚动条移动页面时，页面的控件是否显示正常
18. 日期的正确格式应该是XXXX-XX-XX或XXXX-XX-XXXX:XX:XX
19. 页面是否有多余按钮或标签
20. 窗口标题或图标是否与菜单栏的统一
21. 窗口的最大化、最小化是否能正确切换
22. 对于正常的功能，用户可以不必阅读用户手册就能使用
23. 执行风险操作时，有确认、删除等提示吗
24. 操作顺序是否合理
25. 正确性检查：检查页面上的form, button, table, header, footer,提示信息，还有其他文字拼写，句子的语法等是否正确。
26. 系统应该在用户执行错误的操作之前提出警告，提示信息.
27. 页面分辨率检查，在各种分辨率浏览系统检查系统界面友好性。
28. 合理性检查：做delete, update, add, cancel, back等操作后，查看信息回到的页面是否合理。
29. 检查本地化是否通过：英文版不应该有中文信息，英文翻译准确，专业。
30. 背景灰度冻结
1.1.2 功能测试
1. 使用所有默认值进行测试
2. 根据所有产品文档、帮助文档中描述的内容要进行遍历测试
3. 输入判断
4. 所有界面出现是和否的逻辑，要测试
5. 异常处理
6. 敏感词
7. 根据需求文档的流程图遍历所有流程图路径
8. 根据程序内容，遍历if elif else switch的逻辑点要遍历
9. 界面各种控件测试
如对于输入框测试：
一、字符型输入框：
1. 字符型输入框：英文全角、英文半角、数字、空或者空格、特殊字符“~！@#￥%……&*？[]{}”特别要注意单引号和&符号。禁止直接输入特殊字符时，使用“粘贴、拷贝”功能尝试输入。
2. 长度检查：最小长度、最大长度、最小长度-1、最大长度+1、输入超工字符比如把整个文章拷贝过去。
3. 空格检查：输入的字符间有空格、字符前有空格、字符后有空格、字符前后有空格
4. 多行文本框输入：允许回车换行、保存后再显示能够保存输入的格式、仅输入回车换行，检查能否正确保存（若能，检查保存结果，若不能，查看是否有正常提示）、
5. 安全性检查：输入特殊字符串
（null,NULL,,javascript,<script>,</script>,<title>,<html>,<td>）、输入脚本函数(<script>alert("abc")</script>)、doucment.write("abc")、<b>hello</b>）
二、数值型输入框：
1. 边界值：最大值、最小值、最大值+1、最小值-1
2. 位数：最小位数、最大位数、最小位数-1最大位数+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，是否数据检验出错？
1.1.3 业务流程测试(主要功能测试)
业务流程，一般会涉及到多个模块的数据，所以在对业务流程测试时，首先要保证单个模块功能的正确性，其次就要对各个模块间传递的数据进行测试，这往往是容易出现问题的地方，测试时一定要设计不同的数据进行测试。
如某一功能模块具有最基本的增删改查功能，则需要进行以下测试：
1. 单项功能测试（增加、修改、查询、删除）
2. 增加——>增加——>增加（连续增加测试）
3. 增加——>删除
4. 增加——>删除——>增加（新增加的内容与删除内容一致）
5. 增加——>修改——>删除
6. 修改——>修改——>修改（连续修改测试）
7. 修改——>增加（新增加的内容与修改前内容一致）
8. 修改——>删除
9. 修改——>删除——>增加（新增加的内容与删除内容一致）
10. 删除——>删除——>删除（连续删除测试）
1.1.4 链接测试
主要是保证链接的可用性和正确性，它也是网站测试中比较重要的一个方面。
可以使用特定的工具如XENU来进行链接测试。
1.1.5 容错测试
1. 输入系统不允许的数据作为输入
2. 把某个相关模块或者子系统停掉，验证对当前系统的影响
3. 配置文件删除或者配置错误
4. 数据库注入错误数据
1.1.6 稳定性测试
1. 系统不间断运行（7*24），验证是否内存泄露、系统其他资源是否存在泄露
2. 如果很紧急上线，可以跑一晚上或者周末跑两天。
一般压力很大的情况下，数据库连接数问题、内存泄露问题会曝露的比较快但是死锁可能不能体现，所以要看系统重要性，如12306稳定性则最好7*24小时
1.1.7 常规性能测试
1. 连接速度测试
用户连接到Web应用系统的速度根据上网方式的变化而变化，他们或许是电话拨号，或是宽带上网。当下载一个程序时，用户可以等较长的时间，但如果仅仅访问一个页面就不会这样。如果Web系统响应时间太长（例如超过5秒钟），用户就会因没有耐心等待而离开。
另外，有些页面有超时的限制，如果响应速度太慢，用户可能还没来得及浏览内容，就需要重新登陆了。而且，连接速度太慢，还可能引起数据丢失，使用户得不到真实的页面。
2. 负载测试
负载测试是为了测量Web系统在某一负载级别上的性能，以保证Web系统在需求范围内能正常工作。负载级别可以是某个时刻同时访问Web系统的用户数量，也可以是在线数据处理的数量。例如：Web应用系统能允许多少个用户同时在线？如果超过了这个数量，会出现什么现象？Web应用系统能否处理大量用户对同一个页面的请求？
3. 压力测试
负载测试应该安排在Web系统发布以后，在实际的网络环境中进行测试。因为一个企业内部员工，特别是项目组人员总是有限的，而一个Web系统能同时处理的请求数量将远远超出这个限度，所以，只有放在Internet上，接受负载测试，其结果才是正确可信的。
进行压力测试是指实际破坏一个Web应用系统，测试系统的反映。压力测试是测试系统的限制和故障恢复能力，也就是测试Web应用系统会不会崩溃，在什么情况下会崩溃。黑客常常提供错误的数据负载，直到Web应用系统崩溃，接着当系统重新启动时获得存取权。
压力测试的区域包括表单、登陆和其他信息传输页面等
1.1.8 易用性测试
1. 系统界面的控件是否可以通过tab键遍历，并且顺序合理
2. 主要功能的入口和操作是否易于理解
3. 界面是否布局合理，功能是否易于查找和使用
4. 操作步骤
5. 操作习惯
6. 有足够的提示信息，且信息文字描述准确
1.1.9 兼容性测试
兼容性测试不只是指界面在不同操作系统或浏览器下的兼容，有些功能方面的测试，也要考虑到兼容性，
包括操作系统兼容和应用软件兼容，可能还包括硬件兼容
比如涉及到ajax、jquery、javascript等技术的，都要考虑到不同浏览器下的兼容性问题。
除了上面所说的这些测试以外，还有算法测试、配置测试、安全性测试等等，在工作中不断总结和分析，形成自己的功能测试框架，当你把这份工作做起来以后，对于你自己对于测试团队而言都是一份很有价值的事情，你的测试思路也会变得更全面。
测试总结：
建立整体的威胁模型，测试溢出漏洞、信息泄漏、错误处理、SQL 注入、身份验证和授权错误.
客户端验证 服务器端验证(禁用脚本调试，禁用Cookies)
1.输入很大的数（如4,294,967,269），输入很小的数(负数)
2.输入超长字符,如对输入文字长度有限制,则尝试超过限制,刚好到达限制字数时有何反应
3.输入特殊字符,如:~!@#$%^&*()_+<>:”{}|
4.输入中英文空格，输入字符串中间含空格，输入首尾空格
5.输入特殊字符串NULL,null，0x0d 0x0a
6.输入正常字符串
7.输入与要求不同类型的字符，如: 要求输入数字则检查正值,负值,零值（正零，负零）,小数,字母,空值; 要求输入字母则检查输入数字
8.输入html和javascript代码
9.对于像回答数这样需检验数字正确性的测试点，不仅对比其与问题最终页的回答数，还要对回答进行添加删除等操作后查看变化
例如：
1.输入”gfhd,看是否出错；
2.输入,看是否出现文本框；
3.输入看是否出现提示。
注意：
加粗是ok的
划横线的是还没做的
没有标记的是不用检测的。
1.输入已注册的用户名和正确的密码，验证是否登录成功；
2.输入已注册的用户名和不正确的密码，验证是否登录失败，并且提示信息正确；
3.输入未注册的用户名和任意密码，验证是否登录失败，并且提示信息正确；
4.用户名和密码两者都为空，验证是否登录失败，并且提示信息正确；
5.用户名和密码两者之一为空，验证是否登录失败，并且提示信息正确；
6.用户名和密码，如果太短或者太长，应该怎么处理（安全性，密码太短时是否有提示）
7. 用户名和密码前后有空格的处理
用户名和密码是否大小写敏感；
**
页面上的密码框是否加密显示；**
8.（不ok）输入密码的时候，大写键盘开启的时候要有提示信息。
9.登录成功后生成的Cookie，是否是httponly (否则容易被脚本盗取)
10.用户名和密码是否通过加密的方式，发送给Web服务器
11.用户名和密码的验证，应该是用服务器端验证， 而不能单单是在客户端用javascript验证
12.用户名和密码的输入框，应该屏蔽SQL注入攻击
14.（不ok）用户名和密码的的输入框，应该禁止输入脚本 （防止XSS攻击）
15.错误登陆的次数限制（防止暴力破解）
16. 考虑是否支持多用户在同一机器上登录；
17.如果登录功能启用了验证码功能，在用户名和密码正确的前提下，输入正确的验证码，验证是否登录成功；
18.如果登录功能启用了验证码功能，在用户名和密码正确的前提下，输入错误的验证码，验证是否登录失败，并且提示信息正确。
19.后台系统创建的用户第一次登录成功时，是否提示修改密码；
20.忘记用户名和忘记密码的功能是否可用；
21.如果登录功能需要验证码，点击验证码图片是否可以更换验证码，更换后的验证码是否可用；
22.刷新页面是否会刷新验证码；
23.如果验证码具有时效性，需要分别验证时效内和时效外验证码的有效性；
24.用户登录成功但是会话超时后，继续操作是否会重定向到用户登录界面；
25.不同级别的用户，比如管理员用户和普通用户，登录系统后的权限是否正确；
（不ok）26.页面默认焦点是否定位在用户名的输入框中；
27.快捷键 Tab 和 Enter 等，是否可以正常使用。
（不ok）1.用户密码后台存储是否加密；
2.用户密码在网络传输过程中是否加密；
3.密码是否具有有效期，密码有效期到期后，是否提示需要修改密码；
4.不登录的情况下，在浏览器中直接输入登录后的 URL 地址，验证是否会重新定向到用户登录界面；
不会。
5.密码输入框是否不支持复制和粘贴；
6.密码输入框内输入的密码是否都可以在页面源码模式下被查看；
7.用户名和密码的输入框中分别输入典型的“SQL 注入攻击”字符串，验证系统的返回页面；
两种方式验证 都安全
8.用户名和密码的输入框中分别输入典型的“XSS 跨站脚本攻击”字符串，验证系统行为是否被篡改；
注：该网页把用户通过GET发送过来的表单数据，未经处理直接写入返回的html流，这就是XSS漏洞所在。 这说是这篇文章的精髓所在。
9.连续多次登录失败情况下，系统是否会阻止后续的尝试以应对暴力破解；
10.同一用户在同一终端的多种浏览器上登录，验证登录功能的互斥性是否符合设计预期；
11.同一用户先后在多台终端的浏览器上登录，验证登录是否具有互斥性。
1.单用户登录的响应时间是否小于 3 秒；
2.单用户登录时，后台请求数量是否过多；
3.高并发场景下用户登录的响应时间是否小于 5 秒；
4.高并发场景下服务端的监控指标是否符合预期；
5.高集合点并发场景下，是否存在资源死锁和不合理的资源等待；
6.长时间大量用户连续登录和登出，服务器端是否存在内存泄漏。
1.不同浏览器下，验证登录页面的显示以及功能正确性；
2.相同浏览器的不同版本下，验证登录页面的显示以及功能正确性；
3.不同移动设备终端的不同浏览器下，验证登录页面的显示以及功能正确性；
4.不同分辨率的界面下，验证登录页面的显示以及功能正确性。
1.1.1、整个Web应用系统的所有页面设计风格需保持一致。
1.1.2、整个Web应用系统页面结构设计布局合理，主题和页面排版合理，无页面变形，无样式丢失，背景显示正常，背景颜色与字体颜色和背景色协调，信息显示完整。界面的线条一致，每个界面中线条对齐且一致。
1.1.3、页面文字格式统一，颜色统一，无错别字。
1.1.4、页面标点符号格式统一，所有字段后若存在冒号，需查看冒号为统一的中文冒号或英文冒号。
1.1.5、页面所有的列表页标题字是不会折行，标题字显示需统一，统一居中，或统一居左，或统一居右。
1.1.6、页面中的提示说明叙述需简明，尽量简化，并且字体显示格式一致，颜色统一。
1.1.7、页面能兼容不同的浏览器，检查页面在不同浏览器下不会发生异常。
1.1.8、页面在不同分辨率，窗口大小中展示无变形。
1.1.9、页面界面所有的展示图片需样式一致，图片需显示清晰。
1.1.10、导航菜单布局合理，导航直观，且易于用户操作。
1.1.11、页面导航与页面结构、菜单、连接页面的风格一致。
1.1.12、页面导航易于导航且直观，若有导航帮助，导航帮助需准确直观，当存在多级菜单时，菜单图标需做区分，便于用户导航，用户当前操作页面的导航菜单需高亮显示提示用户，当前操作页面的导航路径需要正确显示。
1.1.13、页面数据需要搜索栏时，搜索栏需有效直观。
1.1.14、页面按钮格式及颜色需一致。
1.1.15、页面存在必填项时，需有必填项标志。
1.1.16、页面存在表格时，表格宽度需足够，并显示完整。当表格呈现内容过多时，需有效提示便于用户操作查看，比如增加更多按钮，点击可查看更多内容，或有滚动条显示。
1.1.17、页面存在表格时，页面表格中的内容超过最长字符限制用…显示，鼠标放上去后显示全部内容。
1.1.18、页面存在列表时，当前列表若无数据时，需显示红色字体的提示语：“暂无相关记录！”。
1.1.19、页面能读取需求中需要显示数据源，且数据正确读出，并完整显示。
1.1.20、web应用系统页面中公司图标，所有权归属，系统图标显示正确，图标在不同浏览器及分辨率均能正常显。
1.2.1、页面操作友好易用。
1.2.2、页面导航菜单链接有效，点击后不会出现404，500报错。
1.2.3、页面所有的输入框都可以进行校验，超出限制时需有提示。
1.2.4、页面所有的按钮点击后有响应。
1.2.5、在对后台进行数据添加时，查看前台页面是需随后台数据一起变化，页面的数据不会溢出框外。后台增加表格内容时，根据需求出现折行或者滚动条，显示完整数据，页面不会变形。
1.2.6、页面所有的下拉框点击后有响应，下拉框数据显示正常且完整，取值正确，不会溢出框外。
1.2.7、必填项未填写时需有提示框弹出，显示提示语：xxx必填！
1.2.8、页面列表存在多条数据时，需有显示滚动或翻页功能使用户可查看完整数据。
1.2.9、页面存在搜索项时，设置查询条件，不点击查询按钮，翻页时不会改变用户行为，不会自动根据查询条件显示数据。
1.2.10、页面存在搜索项时，设置查询条件，点击查询，翻页时显示符合查询条件的数据。
1.2.11、在页面点【退出】按钮，成功退出到登录界面。
1.2.12、点击删除按钮时需有提示框弹出提示用户确定删除数据，避免误操作丢失数据。
当存在批量删除功能时，不选择任何数据，点击删除按钮需有提示。
1.2.13、页面输入项输入异常字符时需处理，不会出现系统报错，输入中文字符时需处理不会出现乱码或出错。输入非法数据时，需提示。
1.2.14、输入项输入正确数据时，输入和输出需保持一致。
1.2.15、取消操作可执行成功。
1.2.16、成功操作可根据需求在规定的时间及范围内生效。
1.2.17、窗体测试
1），窗体大小，大小要合适，控件布局合理；
2），移动窗体.快速或慢速移动窗体，背景及窗体本身刷新必须正确；
3），缩放窗体，窗体上的控件应随窗体的大小变化而变化；
1.2.18、用户图标若支持上传显示时，图片上传后显示时需统一尺寸及格式，页面不会变形，图标显示保持和其他同类图标一致。
2、文件上传测试
2.1、上传文件大小在需求限制范围内可成功上传；
2.2、上传文件大小超出需求限制范围需提示超出限制，不可成功上传；
2.3、上传文件数量在需求限制范围内可成功上传；
2.4、上传文件数量超出需求限制范围需提示超出限制，不可成功上传；
2.5、上传文件格式在需求限制范围内可成功上传；
2.6、上传文件格式超出需求限制范围需提示超出限制，不可成功上传；
2.7、上传文件名长度超出需求限制长度的文件提示超出限制，不可成功上传；
2.8、上传文件无效文件时，举例：大小为0kb的文件，不可成功上传；
2.9、上传成功的文件名称显示正确无异常；
2.10、在不同浏览器上传符合要求的文件均可成功上传；
2.11、根据需求，若上传路径支持手动输入时，输入正确的文件路径可成功上传；
2.12、根据需求，若上传路径支持手动输入时，输入错误的文件路径不可成功上传；
2.13、已被打开的文件上传，根据用户需求确定能否成功上传；
2.14、修改非法格式文件的后缀名为支持文件格式的类型，文件上传不成功；
2.15、修改合法格式文件的后缀名为不支持文件格式的类型，文件上传不成功；
2.16、上传同名文件，根据需求确定能否上传成功；
2.17、上传文件的过程中，若文件上传未完成时，可取消上传操作；
2.18、若上传文件成功后，页面存在数据保存或提交按钮时，未点击保存或提交按钮，上传文件则不显示在页面中；
2.19、上传文件允许多个时，再次上传文件，上传页面不可显示上次文件的名称，需刷新上传页面；
2.20、上传为空时，点击上传按钮，需弹出提示信息；
2.21、已损坏文件上传时，需提示，不可成功上传；
2.22、文件存储位置路径深度测试，当超出最大深度，需提示，上传文件不可成功；
2.23、文件目标服务器已满时，上传文件需提示，文件上传不成功；
3.1、可以下载成功，下载文件和上传文件大小，文件名称，格式一致；
3.2、下载文件打开内容正确，和上传文件内容一致，无乱码，无异常；
3.3、不同浏览器都可下载下载成功，文件大小，文件名称，格式，内容一致；
3.4下载未完成时，可取消下载操作；
3.5、可下载文件后台被删除时，点击下载需提示，根据用户需求而定；
附：小栗子
具体需求： 有一个登录页面， （假如上面有2个textbox, 一个提交按钮。 请针对这个页面设计30个以上的testcase.）
此题的考察目的：面试者是否熟悉各种测试方法，是否有丰富的Web测试经验， 是否了解Web开发，以及设计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.打开登录页面，需要几秒
2.输入正确的用户名和密码后，登录成功跳转到新页面，不超过5秒
安全性测试(Security test)
1.登录成功后生成的Cookie，是否是httponly (否则容易被脚本盗取)
2.用户名和密码是否通过加密的方式，发送给Web服务器
3.用户名和密码的验证，应该是用服务器端验证， 而不能单单是在客户端用javascript验证
4.用户名和密码的输入框，应该屏蔽SQL注入攻击
5.用户名和密码的的输入框，应该禁止输入脚本 （防止XSS攻击）
6.错误登陆的次数限制（防止暴力破解）
7. 考虑是否支持多用户在同一机器上登录；
8. 考虑一用户在多台机器上登录
可用性测试(Usability Test)
1. 是否可以全用键盘操作，是否有快捷键
2. 输入用户名，密码后按回车，是否可以登陆
3. 输入框能否可以以Tab键切换
兼容性测试（Compatibility Test）
1.主流的浏览器下能否显示正常已经功能正常（IE,6,7,8,9, Firefox, Chrome, Safari,等）
2.不同的平台是否能正常工作，比如Windows, Mac
3.移动设备上是否正常工作，比如Iphone, Andriod
4.不同的分辨率
本地化测试 （Localization test）
1. 不同语言环境下，页面的显示是否正确。
软件辅助性测试 （Accessibility test）
软件辅助功能测试是指测试软件是否向残疾用户提供足够的辅助功能
1. 高对比度下能否显示正常 （视力不好的人使用）
