BS通用测试点.docx
《BS通用测试点.docx》由会员分享，可在线阅读，更多相关《BS通用测试点.docx（26页珍藏版）》请在冰豆网上搜索。
BS通用测试点
B/S程序通用测试点
测试内容
测试点
页面显示
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、页面元素通用测试点
对页面元素最基本的测试点
1、对于必须输入的内容需要和非必输项需要明显的区分开来；
2、对于需要设置的内容的描述需要准确、易懂、符合行业表达习惯；
3、对于设置选项需要提供Tab键切换，对于操作需要支持Enter键确认。
4、页面功能容错性必须良好，对于操作需要有完善的警告、提示、出错处理机制。
页面元素
测试点
文本输入框
1、输入内容应有长度限制，超出限定长度应给出准确提示信息；
2、不允许为空的输入项在不输内容的情况下应反馈准确提示信息；
3、输入框的大小应该和输入内容相匹配，和界面布局相匹配；
4、综合运用等价类和边界值分析的方法确定输入内容长度进行测试。
数字输入框
1、不允许输入字符或汉字，不允许输入特殊字符；
2、应该根据允许输入的数据范围锁定输入长度；
3、综合运用等价类和边界值分析的方法确定具体测试数据。
按钮
1、按钮应该美观，大小合理，按钮上的内容位置应居中；
2、按钮和整个页面风格保持一致，布局位置合理；
3、功能操作的确认、重置、取消按钮应该在所有输入控件下方的合适位置；
4、鼠标指针移动到按钮上时应该自动变为手形（也可同时变化按钮背景色）。
下拉列表框
1、下拉列表中的选项内容是否正确，包括确定选项的下拉列表，从数据库中获取数据的下拉列表，或既有确定
选项又从数据库中获取数据几种情况；
2、下拉列表中选项内容应该根据拼音或是否常用进行排序；
3、下拉列表中的选项太多的情况下应该提供输入功能，并自动根据输入内容过滤出对应选项，方便选择操作。
选择框
1、选择框中的选项内容是否正确，包括确定选项的下拉列表，从数据库中获取数据的下拉列表，或既有确定选
项又从数据库中获取数据几种情况；
2、需提供Shift键和Ctrl键选择选项的功能；需提供全选和全取消的功能；
3、对于已经选择的选项不应该再出现在被选列表中，而应该出现在已选择列表中，反之亦然；
4、对于有顺序要求的选择设置操作需要提供顺序调整功能。
5、选择框布局、前景、背景色应该美观合理，应该和所在界面，及整个系统的风格、色调保持一致。
输入域
1、输入域要美观、漂亮，大小合理，和整个页面的布局融为一体；
2、输入域中输入内容时需提供自动换行功能，超出输入域长度或宽度时需要有滚动条可以操作。
3、输入域中文字的默认字体、大小、颜色需和整个页面保持一致。
4、输入域中可输入内容应有长度限制，综合运用等价类和边界值分析的方法确定输入内容长度进行测试。
编辑控件
1、控件上各功能按钮的图标应该符合大众的使用习惯，按钮大小应符合页面环境；
2、鼠标放到按钮上时应该有准确的提示或说明信息；
3、各编辑功能可以正确影响被编辑内容的显示效果，可以正确保存或回退。
单选框
同一组单选框只能选择其中某一个选项，需要默认选择第一个选项。
复选框
1、存在比较多复选选择框需设置的情况下，需要提供复选框的全选、反选、全不选的功能；
2、同一个页面不应该出现太多的复选框；如果有太多的选项，考虑其他实现方法，比如选择框；
3、树状复选框选中上层结点会自动选中所有下层结点，反之亦然；选中下层结点会自动选中该结点对应的上层结点，
去掉下层结点的勾选不影响上层结点的选择。
日期时间控件
1、日期时间控件需要和页面风格保持一致，大小合理，界面美观；
2、日期时间应该可以选择设置，同时也可以手工输入来进行设置；
3、设置内容可以正确返填到对应的输入框中。
4、日期设置中如果默认了日期，日期一般需要从服务器获得。
5、如果相关功能是根据时间段控制的话，程序需要控制起始时间不能大于结束时间。
树形结构
1、树形结构结点的展开收缩时树的刷新，及结点对应内容的刷新应正确及时；
2、树形结构应该控制最多有3层，否则会造成操作不方便。
3、树形结构应该和整个界面风格保持一致；
4、编辑树形结构的结点后树形结构刷新显示正确（树形结构不会自动收缩起来等）。
弹出窗口
1、弹出窗口的风格应该和系统风格保持一致，弹出窗口界面布局应该合理美观；
2、弹出窗口应该屏蔽最小化和最大化按钮，只保留关闭按钮；
3、弹出窗口的显示位置应该合理美观，且允许拖动。
页面导航
1、导航按钮风格和应用系统的页面结构、菜单、链接的风格是否一致；
2、图片按钮导航或按钮导航应该可以准确切换到对应功能；
3、鼠标置于导航按钮上时应该显示成特殊的鼠标指针，且导航按钮应该高亮显示。
窗口标题
1、系统主窗口的标题显示内容应该是当前系统的名称，屏蔽掉其他无关的内容，严禁出现与系统登陆和程序路径
相关的信息；
2、弹出的操作功能窗口的标题为对应功能名称，屏蔽掉其他无关的内容；
3、提示信息弹出框标题直接显示为“提示”，警告和错误提示框的标题显示为“警告”和“错误”，界面图标选
择合适图标。
内容列表
1、根据页面空间合理确定每页显示的内容行数，在内容超出行数的情况下合理提供翻页（上翻、下翻、首页、末页）
及跳转页面的功能；
2、内容不足一页及没内容的情况下不显示翻页及页面跳转功能按钮；
3、新增、修改内容列表某条内容后应该定位到对应页面的对应内容上；
4、删除内容列表某条内容后应该定位到当前页面的第一条内容上，如果该条内容删除后对应页面没有内容则定位到
上一页面内容列表中第一条内容上。
表格
1、表格边线颜色应该符合整个界面的配色方案，表格大方美观；
2、表格边线一般要比内部线条稍粗一点；
3、表格中内容显示要求：
表头内容统一加粗居中，内容长度不等的列统一水平靠左垂直居中，内容长度相等的列需
要居中显示。
4、表格中不允许出现按钮链接，统一使用字符串链接。
超级链接
1、超级链接的文字颜色应该和所在页面普通文字的颜色区分开，但要融入整个页面的配色方案；
2、当鼠标指针移动到超级链接上时应自动变为手形（也可同时变化链接的背景色），且可以通过单击打开链接对应
的界面或文件。
3、鼠标指针在普通文本显示区域决不能随便变化鼠标指针的形状。
3、相关功能通用测试点
功能
测试点
新增
1、新增功能应该不允许新增对应数据表主键内容重复的数据；
2、新增功能是否正确保存数据到对应的数据表中的正确字段；
3、新增功能不会影响数据库中已经存在的数据。
4、新增成功或失败都应该反馈准确的提示信息。
5、新增时应该自动处理掉输入内容两端的空格。
修改
1、修改功能是否正确修改数据库中对应表的对应字段的数据；
2、修改功能应该不允许修改数据库中对应表的对应记录的主键数据；
3、修改功能不会影响数据库中与对应修改数据无关的数据，不会新增数据（除非新增处理是作废原记录并新增记录）。
4、修改成功或失败都应该反馈准确的提示信息。
5、修改提交时应该自动处理掉输入内容两端的空格。
删除
1、删除功能操作时必须提供删除确认步骤；
2、删除功能会正确删除数据库中对应的记录；
3、删除功能不会删除删除数据以外的任何数据。
4、删除成功或失败都应该反馈准确的提示信息。
5、根据条件删除数据的功能必须是精确条件删除。
查询
1、查询功能需要区分实现精确查询和模糊查询功能；
2、查询功能需自动处理输入内容两端的空格；
3、模糊查询需屏蔽掉SQL语句中用到的通配符；
4、查询效率应该可以符合平常使用要求。
文件下载、打开
1、文件下载应该可以选择文件的存储目录，下载过程需要有进度条跟踪显示，可调用Windows的下载控件；
2、文件应该可以在客户端直接打开；
3、文件下载保存时应该自动选择对应的正确文件格式和默认文件名，允许对文件重命名，一般情况下应不允许修改
文件的保存格式。
4、鼠标置于下载链接上时应该显示为特殊的鼠标指针，该指针符合大众的使用习惯。
打印预览及打印
1、打印预览看到的文件效果和文件打印出来的效果应该是一致的；
2、文件多页的情况下打印预览应提供翻页的预览功能；
3、文件打印时应该可以设置布局和选择纸张。
文件/报表导出
1、文件或报表导出后格式应该符合客户的格式要求，可以直接打开文件；
2、报表导出后需要验证导出的报表数据的正确性；可以和查询数据进行比较来验证；
3、文件导出保存时应该自动选择对应的正确文件格式和默认文件名，允许对文件重命名，一般情况下应不允许修改
文件的保存格式。
文件上传
1、对于文件上传需要提供浏览本地文件的功能；最好可以提供上传文件的预览功能；
2、上传文件时间稍长的情况下需要提供过程进度条；
3、文件上传后应该加密保存到服务器的特定目录下，只有解密后才可以正确查看（暂不测试文件加密解密）；
4、文件上传成功或失败都应该反馈准确的提示信息。
权限控制
1、系统相关功能应该只有当操作员具有对应权限时才能使用；
2、新增、修改、删除等改变已有数据的功能需要具有操作权限才能进行；
3、查询数据需要具有数据的查询权限才能进行；
4、对于分层控制的权限，具有上层权限自然就拥有了下层权限。
创建好的情景测试用例的十六种方法
1）写出系统中对象的生存轨迹。
对象是如何创建的，它发生了什么，怎么用它怎么修改它，怎么和它交互，什么时候它被毁坏或是移除？
2）列出可能的用户，分析他们的兴趣和目的。
3）考虑一下不利的用户，他们为什么会滥用你的系统？
4）列出系统事件。
系统是怎么处理他们的？
5）列出特殊事件。
系统是怎么调节这些事情发生的？
6）列出好处点，然后创建点对点流程一项一项去检查。
7）看看用户试图完成的特殊执行，例如关掉一个正在发请求的页面。
什么是期望的数据，输出，显示等。
8）那些表单是和用户交互的？
针对他们试试增删改查功能。
9）采访客户，了解用户最常遇到的挑战和系统失败的例子。
10）在用户旁边看其操作，看看他们具体是怎么做的。
11）去试试竞争产品，看看相似系统是怎么做的。
12）了解以前做这个产品的人对它的抱怨，或者他的竞争者对它的不满。
13）创建一个假的业务。
把它看成是真的，处理数据。
14）试着从一个竞争的应用程序或者前面人用过的系统中转换真实数据。
15）看看竞争程序中的输出。
你是如何在你的应用程序中创建这些报告，对象，任何东西的？
16）查看序列：
用户（或者系统）依照一定的顺序做一个典型的任务X，为了达到完成任务X的目的，最常见的子任务的序列是什么？
情景测试的风险
1）其他的测试方法更适合在测试的早期进行，代码不稳定的时候。
<1>一个场景很复杂，将会涉及很多功能。
如果第一个功能被破坏了，其他的测试将不能进行。
一旦这个功能被修复，后面一个被破坏的功能又会阻碍测试。
<2>在场景测试之前，每个功能模块的测试是分开的，这样一旦他们出现，就可以很有效的暴露问题所在。
2）场景测试并不能用来做程序覆盖测试
<1>它主要关注点通过一系列的用户场景来覆盖所有的功能或者需求。
简单的语句覆盖率不能用这种方式达到。
3）重复使用场景可能没有很强的立足点，效率比较低。
<1>归档以及重复使用场景看上去是高效的做法，因为我们在创建一个好的用户场景上花费了很多工作。
<2>场景经常会暴露出设计的缺陷，我们很快可以知道什么是测试对设计的帮助。
<3>情景测试会暴露一些代码错误，因为他们连接了很多功能和很多数据。
为了覆盖更多的关联，我们需要创建新的测试。
<4>做回归测试，要用单一的功能测试或者单元测试，而不是情景测试。
一、对软件测试的误解
1、如果发布出去的软件有质量问题，那是软件测试人员的错。
2、软件测试技术要求不高，至少比编程容易多了
3、软件测试随便找一个能力差的人就能做。
4、软件测试是测试人员的事，与开发人员无关。
5、设计-实现-测试，软件测试是开发后期的一个阶段
二、如何理解软件测试
软件测试是一种有效的提高软件质量的手段，但即使在投入上有所保证，测试也不能百分为百发现所有质量隐患。
况且软件质量并不仅仅是测试出来的。
很多人认为软件测试就是运行一下软件，看看结果对不对。
但实际上，如何在有限的投入下，提高软件测试的效率和产出是一件很见功底的事。
好的测试人员不仅要掌握各种测试技术，还要具备丰富的编程经验和对BUG的敏感。
测试的复杂之处，除了测试技术问题之外，还有测试管理问题。
测试不是可有可无，随心所欲的。
规范化的软件开发需要对软件测试早做计划，分配必要的时间，人力和财力等资源，并将其作为项目管理的一个部分加以控制和协调。
开发和测试是软件项目相辅相成的两个过程，人员间的交流，协作和配合是提高整体效率的重要因素。
软件产品开发完毕，再进行测试的观念是有悖于生命周期理论的。
软件产品质量问题越晚发现，修复的代价越大。
一些常识和经验之谈
测试能提高软件的质量，但是提高质量不能依赖测试。
测试只能证明缺陷存在，不能证明缺陷不存在。
“彻底地测试”难以成为现实，要考虑时间、费用等限制，不允许无休止地测试。
我们应当祈祷：
软件的缺陷在产品被淘汰之前一直没有机会发作。
测试的主要困难是不知道如何进行有效地测试，也不知道什么时候可以放心地结束测试。
每个开发人员应当测试自己的程序（份内之事），但是不能作为该程序已经通过测试的依据（所以项目需要独立测试人员）。
80-20原则：
80％的缺陷聚集在20％的模块中，经常出错的模块改错后还会经常出错
测试应当循序渐进，不要企图一次性干完，注意“欲速则不达”。
三、软件测试的定义
软件测试是为了发现错误而执行程序的过程
软件测试是根据软件开发各阶段的规格说明和程序的内部结构而精心设计一批测试用例（即输入数据及其预期的输出结果），并利用这些测试用例去运行程序，以发现程序错误的过程。
四、软件测试的对象
软件测试不等于程序测试。
软件测试贯穿于软件定义和开发的整个期间。
需求分析，概要设计，详细设计，以及程序编码等各个阶段所得到的文档，包括需求规格说明，概要设计规格说明，详细设计规格说明以及源程序，都是软件测试的对象。
软件生存各个阶段间的确认和验证
软件配置：
包括软件需求规格说明、软件设计规格说明、源代码等；
测试配置：
包括测试计划、测试用例、测试驱动程序等。
实际上，在整个软件工程过程中，测试配置只是软件配置的一个子集。
测试工具：
为提高软件测试效率，可使用测试工具支持测试工具。
例如：
测试数据自动生成程序、测试结果分析程序等。
五、测试的目的
测试是程序的执行过程，目的在于发现错误；
一个好的测试用例在于发现至今未发现的错误；
一个成功的测试是发现了至今的错误的测试。
六、测试的种类
名称
说明
黑盒测试
基于软件需求，而不是基于软件内部设计和程序实现的测试方式。
白盒测试
基于软件内部设计和程序实现的测试方式。
单元测试
主要测试软件模块的源代码。
一般由开发人员而非独立测试人员来执行，因为测试者需要懂得该单元的设计与程序实现，测试者可能需要编写额外的测试驱动程序。
集成测试
将一些“构件”集成一起时，测试它们能否正常运行。
这里“构件”可以是程序模块、客户机－服务器程序等等。
功能测试
测试软件的功能是否符合功能性需求，通常采用黑盒测试方式。
一般由独立测试人员执行。
系统测试
测试软件系统是否符合所有需求，包括功能性需求与非功能性需求。
一般由独立测试人员执行，通常采用黑盒测试方式。
回归测试
指错误被修正后或软件功能、环境发生变化后进行的重新测试。
回归测试的困难在于不好确定哪些内容应当被重新测试。
验收测试
由客户或最终用户执行，测试软件系统是否符合需求规格说明书。
名称
说明
负载测试
测试软件系统的最大负载，超出此负载软件可能会失常。
压力测试
概念上与负载测试相似，叫法不同。
性能测试
测试软件在各种状况下的性能，如在正常或最大负载下的状况。
易用性测试
测试软件是否易用，主观性比较强。
一般要根据很多用户的测试反馈信息，才能评价易用性。
安装与反安装测试
测试软件在“全部、部分、升级”等状况下的安装/反安装过程。
恢复测试
测试该系统从故障中恢复过来的能力。
安全性测试
测试该系统防止非法侵入的能力。
兼容性测试
测试该系统与其它软件硬件兼容的能力。
比较测试
通过与同类产品比较，考察该系统的优点、缺点。
Alpha测试
一种先期的用户测试，此时系统刚刚开发完成。
Beta测试
一种后期的用户测试，此时系统已经通过内部测试，大部分错误已经改正，即将正式发行。
七、测试的分类与比较
测试方式
白盒测试：
关心软件内部设计和程序实现，主要测试依据是设计文档
黑盒测试：
不关心软件内部，只关心输入输出，主要测试依据是需求文档
测试阶段
单元测试、集成测试、系统测试、验收测试。
是“从小到大”、“由内至外”、“循序渐进”的测试过程，体现了“分而治之”的思想。
单元测试的粒度最小，一般由开发小组采用白盒方式来测试，主要测试单元是否符合“设计”。
集成测试界于单元测试和系统测试之间，起到“桥梁作用”，一般由开发小组采用白盒加黑盒的方式来测试，既要验证“设计”又要验证“需求”。
系统测试的粒度最大，一般由独立测试小组采用黑盒方式来测试，主要测试系统是否符合“需求规格说明书”。
验收测试与系统测试非常相似，主要区别是测试人员不同，验收测试由用户执行。
开发与测试的V型关系
如果软件开发过程采用严格的瀑布模型，那么开发与测试有“V”型的对应关系。
测试内容
接口与路径测试。
功能测试、健壮性测试、性能测试、用户界面测试、安全性测试、压力测试、可靠性测试、安装/反安装测试…
测试阶段
主要依据
测试人员、测试方式
主要测试内容
单元测试
系统设计文档
由开发小组执行白盒测试
接口测试、路径测试
集成测试
系统设计文档
需求文档
由开发小组执行白盒测试和黑盒测试
接口测试、路径测试、功能测试、性能测试
系统测试
需求文档
由独立测试小组执行黑盒测试
功能测试、健壮性测试、性能测试、用户界面测试、安全性测试、压力测试、可靠性测试、安装/反安装测试
验收测试
需求文档
由用户执行黑盒测试
黑盒测试与白盒测试的比较
测试方式
特征
依据
测试人员
测试驱动程序
黑盒测试
只关心软件的外部表现，不关心内部设计与实现。
软件需求
任何人（包括开发人员、独立测试人员和用户）
一般无需编写额外的测试驱动程序
白盒测试
关注软件的内部设计与实现，要跟踪源代码的运行。
设计文档
由开发人员兼任测试人员的角色
需要编写额外的测试驱动程序
问题1：
有了“黑盒”测试为什么还要“白盒”测试？
黑盒测试只能观察软件的外部表现，即使软件的输入输出都是正确的，却并不能说明软件就是正确的。
因为程序有可能用错误的运算方式得出正确的结果，例如“负负得正，错错得对”，只有白盒测试才能发现真正的原因。
白盒测试能发现程序里的隐患，象内存泄漏、误差累计问题。
在这方面，黑盒测试存在严重的不足。
问题2：
由于单元测试要写测试驱动程序，非常麻烦，能否等到整个系统全部开发完后，再集中精力进行一次性地单元测试呢？
如果这样做，在开发过程中，缺陷会越积越多并且分布得更广、隐藏得更深，反而导致测试与改错的代价大大增加。
最糟糕的是无法估计测试与改错的工作量，使进度失去控制。
因此为图眼前省事而省略单元测试或者“偷工减料”，是“得不偿失”的做法。
问题3：
如果每个单元都通过了测试，把它们集成一起难道会有什么不妥吗？
集成测试是否多此一举？
要把N个单元集成一起肯定靠接口耦合，这时可能会产生在单元测试中无法发现的问题。
例如：
数据通过不同的接口时可能出错；几个函数关联在一起时可能达不到预期的功能；在某个单元里可以接受的误差可能在集成后被扩大到无法接受的程度。
所以集成测试是必要的，不是多此一举。
问题4：
在集成测试的时候，已经对一些子系统进行了功能测试、性能测试等等，那么在系统测试时能否跳过相同内容的测试?
不能！
因为集成测试是在仿真环境中开展的，那不是真正的目标系统。
再者，单元测试和集成测试通常由开发小组执行。
根据测试心理学的分析，开发人员测试自己的工作成果虽然是必要的，但不能作为成果已经通过测试的依据。
问题5：
既然系统测试与验收测试的内容几乎是相同的，为什么还要验收测试？
首先是“信任”问题。
对于合同项目而言，如果测试小组是开发方的人员，客户怎么能够轻易相信“别人”呢?
所以当项目进行系统测试之后，客户再
升级会员 