web经常使用模块测试用例

一些经常使用模块的测试用例 1、登陆　　二、添加　　三、查询　　四、删除 1、登陆 ①用户名和密码都符合要求（格式上的要求） ②用户名和密码都不符合要求（格式上的要求） ③用户名符合要求，密码不符合要求（格式上的要求） ④密码符合要求，用户名不符合要求（格式上的要求） ⑤用户名或密码为空 ⑥数据库中不存在的用户名，不存在的密码 ⑦数据库中存在的用户名，错误的密码 ⑧数据库中不存在的用户名，存在的密码 ⑨输入的数据前存在空格 ⑩输入正确的用户名密码 之后按[enter]是否能登录 2、添加 ①要添加的数据项均合理，在界面保存成功后，检查数据库中是否添加了相应的数据：select查询 ②留出一个必填数据为空 ③按照边界值等价类设计测试用例的原则设计其余输入项的测试用例：数据组合测试 ④不符合要求的地方要有错误提示 ⑤是否支持table键 ⑥按enter是否能保存 ⑦若提示不能保存，也要察看数据库里是否多了一条数据 3、删除 ①删除一个数据库中存在的数据，而后查看数据库中是否删除（界面删除一条数据，查看数据库中是否删除） ②[url=]删除一个数据库中并不存在的数据，看是否有错误提示，而且数据库中没有数据被删除[/url]file:///C:/Users/ADMINI~1/AppData/Local/Temp/msohtmlclip1/01/clip_image005.gif A.输入条件的约束有如下4类： ① E约束（异）：a和b中至多有一个可能为1，即a和b不能同时为1。 ② I约束（或）：a、b和c中至少有一个必须是1，即 a、b 和c不能同时为0。 ③ O约束（惟一）；a和b必须有一个，且仅有1个为1。 ④ R约束（要求）：a是1时，b必须是1，即不可能a是1时b是0。 B.输出条件约束类型 输出条件的约束只有M约束（强制）：若结果a是1，则结果b强制为0。 5. 采用因果图法设计测试用例的步骤： 1) 分析软件规格说明描述中, 那些是缘由(即输入条件或输入条件的等价类),那些是结果(即输出条件), 并给每一个缘由和结果赋予一个标识符。 2) 分析软件规格说明描述中的语义，找出缘由与结果之间, 缘由与缘由之间对应的关系，根据这些关系,画出因果图。 3) 因为语法或环境限制, 有些缘由与缘由之间,缘由与结果之间的组合状况不可能出现，为代表这些特殊状况, 在因果图上用一些记号代表约束或限制条件。 4) 把因果图转换为断定表。 5) 把断定表的每一列拿出来做为依据,设计测试用例。 网站测试的主要方面 1[url=]功能测试[/url] 对于网站的测试而言，每个独立的功能模块须要单独的[url=]测试用例[/url]的设计导出，主要依据为《需求规格说明书》及《详细设计说明书》，对于应用程序模块须要设计者提供基本路径测试法的测试用例。 ● 连接测试 连接是Web应用系统的一个主要特征，它是在页面之间切换和指导用户去一些不知道地址的页面的主要手段。连接测试可分为三个方面： 1）测试全部连接是否按指示的那样确实连接到了该连接的页面； 2）测试所连接的页面是否存在； 3）保证Web应用系统上没有孤立的页面，所谓孤立页面是指没有连接指向该页面，只有知道正确的URL地址才能访问。 连接测试能够自动进行，如今已经有许多工具能够采用。连接测试必须在集成测试阶段完成，也就是说，在整个Web应用系统的全部页面开发完成以后进行连接测试。 Xenu------主要测试连接的正确性的工具 惋惜的是对于动态生成的页面的测试会出现一些错误。 ●表单测试 当用户给Web应用系统管理员提交信息时，就须要使用表单操做，例如用户注册、登录、信息提交等。在这种状况下，咱们必须测试提交操做的完整性，以校验提交给服务器的信息的正确性。例如：用户填写的出生日期与职业是否恰当，填写的所属省份与所在城市是否匹配等。若是使用了默认值，还要检验默认值的正确性。若是表单只能接受指定的某些值，则也要进行测试。例如：只能接受某些字符，测试时能够跳过这些字符，看系统是否会报错。 要测试这些程序，须要验证服务器能正确保存这些数据，并且后台运行的程序能正确解释和使用这些信息。 B/S结构实现的功能可能主要的就在这里，提交数据，处理数据等若是有固定的操做流程能够考虑自动化测试工具的录制功能，编写可重复使用的脚本代码，能够在测试、回归测试时运行以便减轻测试人员工做量。 咱们对UM子系统中各个功能模块中的各项功能进行逐一的测试，主要[url=]测试方法[/url]为：边界值测试、等价类测试，以及异常类测试。测试中要保证每种类型都有2个以上的典型数值的输入，以确保测试输入的全面性。 ●Cookies测试 Cookies一般用来存储用户信息和用户在某应用系统的操做，当一个用户使用Cookies访问了某一个应用系统时，Web服务器将发送关于用户的信息，把该信息以Cookies的形式存储在客户端计算机上，这可用来建立动态和自定义页面或者存储登录等信息。 若是Web应用系统使用了Cookies，就必须检查Cookies是否能正常工做并且对这些信息已经加密。测试的内容可包括Cookies是否起做用，是否按预约的时间进行保存，刷新对Cookies有什么影响等。 ●设计语言测试 Web设计语言版本的差别能够引发客户端或服务器端严重的问题，例如使用哪一种版本的HTML等。当在分布式环境中开发时，开发人员都不在一块儿，这个问题就显得尤其重要。除了HTML的版本问题外，不一样的脚本语言，例如[url=]Java[/url]、JavaScript、 ActiveX、VBScript或Perl等也要进行验证。 ●数据库测试 在Web应用技术中，数据库起着重要的做用，数据库为Web应用系统的管理、运行、查询和实现用户对数据存储的请求等提供空间。在Web应用中，最经常使用的数据库类型是关系型数据库，能够使用SQL对信息进行处理。 在使用了数据库的Web应用系统中，通常状况下，可能发生两种错误，分别是数据一致性错误和输出错误。数据一致性错误主要是因为用户提交的表单信息不正确而形成的，而输出错误主要是因为网络速度或程序设计问题等引发的，针对这两种状况，可分别进行测试。 2性能测试 网站的性能测试对于网站的运行而言异常重要，可是目前对于网站的性能测试作的不够，咱们在进行系统设计时也没有一个很好的基准能够参考，于是创建网站的性能测试的一整套的测试方案将是相当重要的。 网站的性能测试主要从三个方面进行：链接速度测试、负荷测试（Load）和压力测试（Stress）.链接速度测试指的是打开网页的响应速度测试。负荷测试指的是进行一些边界数据的测试，压力测试更像是恶意测试，压力测试倾向应该是导致整个系统崩溃。 ●链接速度测试 用户链接到Web应用系统的速度根据上网方式的变化而变化，他们或许是电话拨号，或是宽带上网。当下载一个程序时，用户能够等较长的时间，但若是仅仅访问一个页面就不会这样。若是Web系统响应时间太长（例如超过5秒钟），用户就会因没有耐心等待而离开。 另外，有些页面有超时的限制，若是响应速度太慢，用户可能还没来得及浏览内容，就须要从新登录了。并且，链接速度太慢，还可能引发数据丢失，使用户得不到真实的页面。 ●负载测试 负载测试是为了测量Web系统在某一负载级别上的性能，以保证Web系统在需求范围内能正常工做。负载级别能够是某个时刻同时访问Web系统的用户数量，也能够是在线数据处理的数量。例如：Web应用系统能容许多少个用户同时在线？若是超过了这个数量，会出现什么现象？Web应用系统可否处理大量用户对同一个页面的请求？ ●压力测试 负载测试应该安排在Web系统发布之后，在实际的网络环境中进行测试。由于一个企业内部员工，特别是项目组人员老是有限的，而一个Web系统能同时处理的请求数量将远远超出这个限度，因此，只有放在Internet上，接受负载测试，其结果才是正确可信的。 进行压力测试是指实际破坏一个Web应用系统，测试系统的反映。压力测试是测试系统的限制和故障恢复能力，也就是测试Web应用系统会不会崩溃，在什么状况下会崩溃。黑客经常提供错误的数据负载，直到Web应用系统崩溃，接着当系统从新启动时得到存取权。 压力测试的区域包括表单、登录和其余信息传输页面等。 采用的[url=]测试工具[/url]： 性能测试能够采用相应的工具进行自动化测试，咱们目前采用以下工具 ab -----Apache 的测试工具 OpenSTA—开发系统测试架构 3 接口测试 在不少状况下，web 站点不是孤立。Web 站点可能会与外部服务器通信，请求数据、验证数据或提交订单。 ●服务器接口 第一个须要测试的接口是浏览器与服务器的接口。测试人员提交事务，而后查看服务器记录，并验证在浏览器上看到的正好是服务器上发生的。测试人员还能够查询数据库，确认事务数据已正确保存。 ●外部接口 有些 web 系统有外部接口。例如，网上商店可能要实时验证信用卡数据以减小欺诈行为的发生。测试的时候，要使用 web 接口发送一些事务数据，分别对有效信用卡、无效信用卡和被盗信用卡进行验证。若是商店只使用 Visa 卡和 Mastercard 卡， 能够尝试使用 Discover 卡的数据。（简单的客户端脚本可以在提交事务以前对代码进行识别，例如3 表示 American Express，4 表示 Visa，5 表示Mastercard，6 表明Discover。）一般，测试人员须要确认软件可以处理外部服务器返回的全部可能的消息。 ●错误处理 最容易被测试人员忽略的地方是接口错误处理。一般咱们试图确认系统可以处理全部错误，但却没法预期系统全部可能的错误。尝试在处理过程当中中断事务，看看会发生什么状况？订单是否完成？尝试中断用户到服务器的网络链接。尝试中断 web 服务器到信用卡验证服务器的链接。在这些状况下，系统可否正确处理这些错误？是否已对信用卡进行收费？若是用户本身中断事务处理，在订单已保存而用户没有返回网站确认的时候，须要由客户表明致电用户进行订单确认。 4 可用性测试 可用性/易用性方面目前咱们只能采用手工测试的方法进行评判，并且缺少一个很好的评判基准进行，此一方面须要你们共同讨论。 ●导航测试 导航描述了用户在一个页面内操做的方式，在不一样的用户接口控制之间，例如按钮、对话框、列表和窗口等；或在不一样的链接页面之间。经过考虑下列问题，能够决定一个Web应用系统是否易于导航：导航是否直观？Web系统的主要部分是否可经过主页存取？Web系统是否须要站点地图、搜索引擎或其余的导航帮助？ 在一个页面上放太多的信息每每起到与预期相反的效果。Web应用系统的用户趋向于目的驱动，很快地扫描一个Web应用系统，看是否有知足本身须要的信息，若是没有，就会很快地离开。不多有用户愿意花时间去熟悉Web应用系统的结构，所以，Web应用系统导航帮助要尽量地准确。 导航的另外一个重要方面是Web应用系统的页面结构、导航、菜单、链接的风格是否一致。确保用户凭直觉就知道Web应用系统里面是否还有内容，内容在什么地方。 Web应用系统的层次一旦决定，就要着手测试用户导航功能，让最终用户参与这种测试，效果将更加明显。 ●图形测试 在Web应用系统中，适当的图片和动画既能起到广告宣传的做用，又能起到美化页面的功能。一个Web应用系统的图形能够包括图片、动画、边框、颜色、字体、背景、按钮等。图形测试的内容有： （1）要确保图形有明确的用途，图片或动画不要胡乱地堆在一块儿，以避免浪费传输时间。Web应用系统的图片尺寸要尽可能地小，而且要能清楚地说明某件事情，通常都连接到某个具体的页面。 （2）验证全部页面字体的风格是否一致。 （3）背景颜色应该与字体颜色和前景颜色相搭配。 （4）图片的大小和质量也是一个很重要的因素，通常采用JPG或GIF压缩。 ●内容测试 内容测试用来检验Web应用系统提供信息的正确性、准确性和相关性。 信息的正确性是指信息是可靠的仍是误传的。例如，在商品价格列表中，错误的价格可能引发财政问题甚至致使法律纠纷；信息的准确性是指是否有语法或拼写错误。这种测试一般使用一些文字处理软件来进行，例如使用Microsoft Word的“拼音与语法检查”功能；信息的相关性是指是否在当前页面能够找到与当前浏览信息相关的信息列表或入口，也就是通常Web站点中的所谓“相关文章列表”。 ●总体界面测试 总体界面是指整个Web应用系统的页面结构设计，是给用户的一个总体感。例如：当用户浏览Web应用系统时是否感到温馨，是否凭直觉就知道要找的信息在什么地方？整个Web应用系统的设计风格是否一致？ 对总体界面的测试过程，实际上是一个对最终用户进行调查的过程。通常Web应用系统采起在主页上作一个调查问卷的形式，来获得最终用户的反馈信息。 对全部的可用性测试来讲，都须要有外部人员（与Web应用系统开发没有联系或联系不多的人员）的参与，最好是最终用户的参与。 5 兼容性测试 须要验证应用程序能够在用户使用的机器上运行。若是您用户是全球范围的，须要测试各类操做系统、浏览器、视频设置和 modem 速度。最后，还要尝试各类设置的组合。 ●平台测试 市场上有不少不一样的操做系统类型，最多见的有Windows、Unix、Macintosh、Linux等。Web应用系统的最终用户究竟使用哪种操做系统，取决于用户系统的配置。这样，就可能会发生兼容性问题，同一个应用可能在某些操做系统下能正常运行，但在另外的操做系统下可能会运行失败。 所以，在Web系统发布以前，须要在各类操做系统下对Web系统进行兼容性测试。 ●浏览器测试 浏览器是Web客户端最核心的构件，来自不一样厂商的浏览器对Java，、JavaScript、ActiveX、 plug-ins或不一样的HTML规格有不一样的支持。例如，ActiveX是Microsoft的产品，是为Internet Explorer而设计的，JavaScript是Netscape的产品，Java是Sun的产品等等。另外，框架和层次结构风格在不一样的浏览器中也有不一样的显示，甚至根本不显示。不一样的浏览器对安全性和Java的设置也不同。 测试浏览器兼容性的一个方法是建立一个兼容性矩阵。在这个矩阵中，测试不一样厂商、不一样版本的浏览器对某些构件和设置的适应性。 采用测试工具： 经过白盒测试或者黑盒测试导出的测试用例，采用相应的工具进行测试，能够采用OpenSTA进行测试，此测试工具能够采用不一样的浏览器进行测试。 ●视频测试 页面版式在 640x400、600x800 或 1024x768 的分辨率模式下是否显示正常? 字体是否过小以致于没法浏览? 或者是太大? 文本和图片是否对齐? ●Modem/链接速率测试 是否有这种状况，用户使用 28.8 modem下载一个页面须要 10 分钟，但测试人员在测试的时候使用的是 T1 专线? 用户在下载文章或演示的时候，可能会等待比较长的时间，但却不会耐心等待首页的出现。最后，须要确认图片不会太大。 ●打印机测试 用户可能会将网页打印下来。所以网页在设计的时候要考虑到打印问题，注意节约纸张和油墨。有很多用户喜欢阅读而不是盯着屏幕，所以须要验证网页打印是否正常。有时在屏幕上显示的图片和文本的对齐方式可能与打印出来的东西不同。测试人员至少须要验证订单确认页面打印是正常的。 ●组合测试 最后须要进行组合测试。600x800 的分辨率在 MAC 机上可能不错，可是在 IBM 兼容机上却很难看。在 IBM 机器上使用 Netscape 能正常显示，但却没法使用 Lynx 来浏览。若是是内部使用的 web 站点，测试可能会轻松一些。若是公司指定使用某个类型的浏览器，那么只需在该浏览器上进行测试。若是全部的人都使用 T1 专线，可能不须要测试下载施加。（但须要注意的是，可能会有员工从家里拨号进入系统） 有些内部应用程序，开发部门可能在系统需求中声明不支持某些系统而只支持一些那些已设置的系统。可是，理想的状况是，系统能在全部机器上运行，这样就不会限制未来的发展和变更。 6 安全测试 Web应用系统的安全性测试区域主要有： ●目录设置 Web 安全的第一步就是正确设置目录。每一个目录下应该有 index.html 或 main.html 页面，这样就不会显示该目录下的全部内容。若是没有执行这条规则。那么选中一幅图片，单击鼠标右键，找到该图片所在的路径“…com/objects/images”。而后在浏览器地址栏中手工输入该路径，发现该站点全部图片的列表。这可能没什么关系。可是进入下一级目录 “…com/objects” ，点击 jackpot。在该目录下有不少资料，其中有些都是已过时页面。若是该公司每月都要更改产品价格信息，而且保存过时页面。那么只要翻看了一下这些记录，就能够估计他们的边际利润以及他们为了争取一个合同还有多大的降价空间。若是某个客户在谈判以前查看了这些信息，他们在谈判桌上确定处于上风。 ●登陆 如今的Web应用系统基本采用先注册，后登录的方式。所以，必须测试有效和无效的用户名和密码，要注意到是否大小写敏感，能够试多少次的限制，是否能够不登录而直接浏览某个页面等。 ●Session Web应用系统是否有超时的限制，也就是说，用户登录后在必定时间内（例如15分钟）没有点击任何页面，是否须要从新登录才能正常使用。 ●日志文件 为了保证Web应用系统的安全性，日志文件是相当重要的。须要测试相关信息是否写进了日志文件、是否可追踪。 ●加密 当使用了安全套接字时，还要测试加密是否正确，检查信息的完整性。 ●安全漏洞 服务器端的脚本经常构成安全漏洞，这些漏洞又经常被黑客利用。因此，还要测试没有通过受权，就不能在服务器端放置和编辑脚本的问题。 目前网络安全问题日益重要，特别对于有交互信息的网站及进行电子商务活动的网站尤为重要。目前咱们的测试没有涵盖网站的安全性的测试，咱们拟定采用工具来测定。 工具以下 SAINT------- SecurityAdministrator’s Integrated Network Tool 此工具可以测出网站系统的相应的安全问题，而且可以给出安全漏洞的解决方案，不过是一些较为常见的漏洞解决方案。 7 代码合法性测试 代码合法性测试主要包括2个部分：程序代码合法性检查与显示代码合法性检查。 ●程序代码合法性检查 程序代码合法性检查主要标准为《intergrp小组编程规范》，目前采用由SCM管理员进行规范的检查，将来指望可以有相应的工具进行测试。 ●显示代码合法性检查 显示代码的合法性检查，主要分为Html、JavaScript、Css代码检查，目前采用HTML代码检查------采用CSEHTML Validator进行测试JavaScript、Css也能够在网上下载相应的测试工具。 8 文档测试 ●产品说明书属性检查清单 1）完整.是否有遗漏和丢失，彻底吗？单独使用是否包含所有内容 2）准确.既定解决方案正确吗？目标明确吗？ 有没有错误？ 3）精确、不含糊、清晰.描述是否一清二楚？ 仍是自说自话？容易看懂和理解吗？ 4）一致.产品功能能描述是否自相矛盾，与其余功能有没有冲突 5）贴切.描述功能的陈述是否必要？有没有多余信息？功能是否原来的客户要求？ 6）合理.在特定的预算和进度下，以现有人力，物力和资源可否实现？ 7）代码无关.是否坚持定义产品，而不是定义其所信赖的软件设计，架构和代码 8）可测试性.特性可否测试？测试员创建验证操做的测试程序是否提供足够的信息？ ●产品说明书用语检查清单 1）说明。 对问题的描述一般表现为粉饰没有仔细考虑的功能----可归结于前文所述的属性.从产品说明书上找出这样的用语，仔细审视它们在文中是怎样使用的.产品说明书可能会为其掩饰和开脱，也可能含糊其词----不管是哪种状况均可视为软件缺陷. 2）老是，每一种，全部，没有，从不.若是看到此类绝对或确定的，切实认定的叙述，软件测试员就能够着手设计针锋相对的案例. 3）固然，所以，明显，显然，必然.这些话意图诱使接受假定状况.不要中了圈套. 4）某些，有时，经常，一般，惯常，常常，大多，几乎.这些话太过模糊.“有时”发生做用的功能没法测试. 5）等等，诸如此类，依此类推.以这样的词结束的功能清单没法测试.功能清单要绝对或者解释明确，以避免让人迷惑，不知如何推论. 6）良好，迅速，廉价，高效，小，稳定.这些是不肯定的说法，不可测试.若是在产品说明书中出现，就必须进一步指明含义. 7）已处理，已拒绝，已忽略，已消除.这些廉洁可能会隐藏大量须要说明的功能. 8）若是...那么...（没有不然）.找出有“若是...那么...”而缺乏配套的“不然”结构的陈述.想想“若是”没有发生会怎样. 相关的测试工具 ·        OpenSTA 主要作性能测试的负荷及压力测试，使用比较方便，能够编写测试脚本，也能够先行自动生成测试脚本，然后对于应用测试脚本进行测试。 ·        SAINT 网站安全性测试，可以对于指定网站进行安全性测试，并能够提供安全问题的解决方案。 ·        CSE HTML Validator 一个有用的对于HTML代码进行合法性检查的工具 ·        Ab（Apache Bench） Apache自带的对于性能测试方面的工具，功能不是不少，可是很是实用。 ·        Crash-me Mysql自带的测试数据库性能的工具，可以测试多种数据库的性能 黑盒测试用例设计 黑盒测试（Black-box Testing，又称为功能测试或数据驱动测试）是把测试对象看做一个黑盒子。利用黑盒测试法进行动态测试时，须要测试软件产品的功能，不需测试软件产品的内部结构和处理过程。 采用黑盒技术设计测试用例的方法有：等价类划分、边界值分析、错误推测、因果图和综合策略。 黑盒测试注重于测试软件的功能性需求，也即黑盒测试使软件工程师派生出执行程序全部功能需求的输入条件。黑盒测试并非白盒测试的替代品，而是用于辅助白盒测试发现其余类型的错误。 黑盒测试试图发现如下类型的错误： 1）功能错误或遗漏； 2）界面错误； 3）数据结构或外部数据库访问错误； 4）性能错误； 5）初始化和终止错误。 1、黑盒测试的测试用例设计方法 · 等价类划分方法 · 边界值分析方法 · 错误推测方法 · 因果图方法 · 断定表驱动分析方法 · 正交实验设计方法 · 功能图分析方法 等价类划分： 是把全部可能的输入数据，即程序的输入域划分红若干部分（子集），而后从每个子集中选取少数具备表明性的数据做为测试用例。该方法是一种重要的，经常使用的黑盒测试用例设计方法。 1） 划分等价类： 等价类是指某个输入域的子集合。在该子集合中，各个输入数据对于揭露程序中的错误都是等效的。并合理地假定：测试某等价类的表明值就等于对这一类其它值的测试。所以，能够把所有输入数据合理划分为若干等价类，在每个等价类中取一个数据做为测试的输入条件，就能够用少许表明性的测试数据。取得较好的测试结果。等价类划分可有两种不一样的状况：有效等价类和无效等价类。 有效等价类：是指对于程序的规格说明来讲是合理的，有意义的输入数据构成的集合。利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能。 无效等价类：与有效等价类的定义恰巧相反。 设计测试用例时，要同时考虑这两种等价类。由于，软件不只要能接收合理的数据，也要能经受意外的考验。这样的测试才能确保软件具备更高的可靠性。 2）划分等价类的方法：下面给出六条肯定等价类的原则。 ① 在输入条件规定了取值范围或值的个数的状况下，则能够确立一个有效等价类和两个无效等价类。 ② 在输入条件规定了输入值的集合或者规定了“必须如何”的条件的状况下，可确立一个有效等价类和一个无效等价类。 ③ 在输入条件是一个布尔量的状况下，可肯定一个有效等价类和一个无效等价类。 ④ 在规定了输入数据的一组值（假定n个），而且程序要对每个输入值分别处理的状况下，可确立n个有效等价类和一个无效等价类。 ⑤ 在规定了输入数据必须遵照的规则的状况下，可确立一个有效等价类（符合规则）和若干个无效等价类（从不一样角度违反规则）。 ⑥ 在确知已划分的等价类中各元素在程序处理中的方式不一样的状况下，则应再将该等价类进一步的划分为更小的等价类。 3）设计测试用例：在确立了等价类后，可创建等价类表，列出全部划分出的等价类： 输入条件 有效等价类 无效等价类 而后从划分出的等价类中按如下三个原则设计测试用例： ① 为每个等价类规定一个惟一的编号。 ② 设计一个新的测试用例，使其尽量多地覆盖还没有被覆盖地有效等价类，重复这一步。直到全部的有效等价类都被覆盖为止。 ③ 设计一个新的测试用例，使其仅覆盖一个还没有被覆盖的无效等价类，重复这一步。直到全部的无效等价类都被覆盖为止。 边界值分析法 边界值分析方法是对等价类划分方法的补充。 （1）边界值分析方法的考虑： 长期的测试工做经验告诉咱们，大量的错误是发生在输入或输出范围的边界上，而不是发生在输入输出范围的内部。所以针对各类边界状况设计测试用例，能够查出更多的错误。 使用边界值分析方法设计测试用例，首先应肯定边界状况。一般输入和输出等价类的边界，就是应着重测试的边界状况。应当选取正好等于，刚刚大于或刚刚小于边界的值做为测试数据，而不是选取等价类中的典型值或任意值做为测试数据。 （2）基于边界值分析方法选择测试用例的原则： 1）若是输入条件规定了值的范围，则应取刚达到这个范围的边界的值，以及刚刚超越这个范围边界的值做为测试输入数据。 2）若是输入条件规定了值的个数，则用最大个数，最小个数，比最小个数少一，比最大个数多一的数做为测试数据。 3）根据规格说明的每一个输出条件，使用前面的原则1）。 4）根据规格说明的每一个输出条件，应用前面的原则2）。 5）若是程序的规格说明给出的输入域或输出域是有序集合，则应选取集合的第一个元素和最后一个元素做为测试用例。 6）若是程序中使用了一个内部数据结构，则应当选择这个内部数据结构的边界上的值做为测试用例。 7）分析规格说明，找出其它可能的边界条件。 错误推测法 错误推测法： 基于经验和直觉推测程序中全部可能存在的各类错误， 从而有针对性的设计测试用例的方法。 错误推测方法的基本思想： 列举出程序中全部可能有的错误和容易发生错误的特殊状况，根据他们选择测试用例。例如， 在单元测试时曾列出的许多在模块中常见的错误。 之前产品测试中曾经发现的错误等， 这些就是经验的总结。 还有， 输入数据和输出数据为0的状况。 输入表格为空格或输入表格只有一行。 这些都是容易发生错误的状况。 可选择这些状况下的例子做为测试用例。 因果图方法 前面介绍的等价类划分方法和边界值分析方法，都是着重考虑输入条件，但未考虑输入条件之间的联系， 相互组合等。考虑输入条件之间的相互组合，可能会产生一些新的状况。 但要检查输入条件的组合不是一件容易的事情， 即便把全部输入条件划分红等价类，他们之间的组合状况也至关多。所以必须考虑采用一种适合于描述对于多种条件的组合，相应产生多个动做的形式来考虑设计测试用例。 这就须要利用因果图（逻辑模型）。 因果图方法最终生成的就是断定表。 它适合于检查程序输入条件的各类组合状况。 利用因果图生成测试用例的基本步骤： （1） 分析软件规格说明描述中， 那些是缘由（即输入条件或输入条件的等价类），那些是结果（即输出条件），并给每一个缘由和结果赋予一个标识符。 （2） 分析软件规格说明描述中的语义。找出缘由与结果之间，缘由与缘由之间对应的关系。 根据这些关系，画出因果图。 （3） 因为语法或环境限制， 有些缘由与缘由之间，缘由与结果之间的组合状况不不可能出现。为代表这些特殊状况， 在因果图上用一些记号代表约束或限制条件。 （4） 把因果图转换为断定表。 （5） 把断定表的每一列拿出来做为依据，设计测试用例。 从因果图生成的测试用例（局部，组合关系下的）包括了全部输入数据的取TRUE与取FALSE的状况，构成的测试用例数目达到最少，且测试用例数目随输入数据数目的增长而线性地增长。 前面因果图方法中已经用到了断定表。断定表（DECisionTable）是分析和表达多逻辑条件下执行不一样操做的状况下的工具。在程序设计发展的初期，断定表就已被看成编写程序的辅助工具了。因为它能够把复杂的逻辑关系和多种条件组合的状况表达得既具体又明确。 断定表驱动分析方法  断定表一般由四个部分组成。 条件桩（ConDItion STub）：列出了问题得全部条件。一般认为列出得条件的次序可有可无。 动做桩（Action Stub）：列出了问题规定可能采起的操做。这些操做的排列顺序没有约束。 条件项（Condition Entry）：列出针对它左列条件的取值。在全部可能状况下的真假值。 动做项（Action Entry）：列出在条件项的各类取值状况下应该采起的动做。 规则：任何一个条件组合的特定取值及其相应要执行的操做。在断定表中贯穿条件项和动做项的一列就是一条规则。显然，断定表中列出多少组条件取值，也就有多少条规则，既条件项和动做项有多少列。 断定表的创建步骤：（根据软件规格说明） ① 肯定规则的个数。假若有n个条件。每一个条件有两个取值（0，1），故有种规则。 ② 列出全部的条件桩和动做桩。 ③ 填入条件项。 ④ 填入动做项。等到初始断定表。 ⑤ 简化、合并类似规则（相同动做）。 B.Beizer 指出了适合使用断定表设计测试用例的条件： ① 规格说明以断定表形式给出，或很容易转换成断定表。 ② 条件的排列顺序不会也不影响执行哪些操做。 ③ 规则的排列顺序不会也不影响执行哪些操做。 ④ 每当某一规则的条件已经知足，并肯定要执行的操做后，没必要检验别的规则。 ⑤ 若是某一规则获得知足要执行多个操做，这些操做的执行顺序可有可无。 黑盒测试的优势 一、基本上不用人管着，若是程序中止运行了通常就是被测试程序CRASh了 二、设计完测试例以后，下来的工做就是爽了，固然更苦闷的是肯定crash缘由 黑盒测试的缺点 一、结果取决于测试例的设计，测试例的设计部分来势来源于经验，OUSPG的东西很值得借鉴 二、没有状态转换的概念，目前一些成功的例子基本上都是针对PDU来作的，还作不到针对被测试程序的状态转换来做 三、就没有状态概念的测试来讲，寻找和肯定形成程序crash的测试例是个麻烦事情，必须把周围可能的测试例单独确认一遍。而就有状态的测试来讲，就更麻烦了，尤为不是一个单独的tEStcase形成的问题。这些在堆的问题中表现的更为突出。 黑盒测试（功能测试）工具的选择 那么，如何高效地完成功能测试？选择一款合适的功能测试工具并培训一支高素质的工具使用队伍无疑是相当重要的。尽管现阶段存在少数不采用任何功能测试工具，从事功能测试外包项目的软件服务企业。短时间来看，这类企业盈利情况尚可，但长久来看，它们极有可能被自动化程度较高的软件服务企业取代。 目前，用于功能测试的工具软件有不少，针对不一样架构软件的工具也不断推陈出新。这里重点介绍的是其中一个较为典型自动化测试工具，即Mercury公司的WinRunner。 WinRunner是一种用于检验应用程序可否如期运行的企业级软件功能测试工具。经过自动捕获、检测和模拟用户交互操做，WinRunner能识别出绝大多数软件功能缺陷，从而确保那些跨越了多个功能点和数据库的应用程序在发布时尽可能不出现功能性故障。 WinRunner的特色在于： 与传统的手工测试相比，它能快速、批量地完成功能点测试；能针对相同测试脚本，执行相同的动做，从而消除人工测试所带来的理解上的偏差； 此外，它还能重复执行相同动做，测试工做中最枯燥的部分可交由机器完成； 它支持程序风格的测试脚本，一个高素质的测试工程师能借助它完成流程极为复杂的测试，经过使用通配符、宏、条件语句、循环语句等，还能较好地完成测试脚本的重用；它针对于大多数编程语言和Windows技术，提供了较好的集成、支持环境，这对基于Windows平台的应用程序实施功能测试而言带来了极大的便利。 WinRunner的工做流程大体能够分为如下六个步骤： 1．识别应用程序的GUI 在WinRunner中，咱们能够使用GUI Spy来识别各类GUI对象，识别后，WinRunner会将其存储到GUI Map File中。它提供两种GUI Map File模式： Global GUI Map File和GUI Map File per Test。其最大区别是后者对每一个测试脚本产生一个GUI文件，它能自动创建、存储、加载，推荐初学者选用这种模式。可是，这种模式不易于描述对象的改变，其效率比较低，所以对于一个有经验的测试人员来讲前者不失为一种更好的选择，它只产生一个共享的GUI文件，这使得测试脚本更容易维护，且效率更高。 2．创建测试脚本 在创建测试脚本时，通常先进行录制，而后在录制造成的脚本中手工加入须要的TSL（与C语言相似的测试脚本语言）。录制脚本有两种模式： Context Sensitive和Analog，选择依据主要在因而否对鼠标轨迹进行模拟，在须要回放时通常选用Analog。在录制过程当中这两种模式能够经过F2键相互切换。 只要看看现代软件的规模和功能点数就能够明白，功能测试早已跨越了单靠手工敲敲键盘、点点鼠标就能够完成的阶段。而性能测试则是控制系统性能的有效手段，在软件的能力验证、能力规划、性能调优、缺陷修复等方面都发挥着重要做用。 3．对测试脚本除错（debug） 在WinRunner中有专门一个Debug TOOlbar用于测试脚本除错。能够使用step、pause、breakpoint等来控制和跟踪测试脚本和查看各类变量值。 4．在新版应用程序执行测试脚本 当应用程序有新版本发布时，咱们会对应用程序的各类功能包括新增功能进行测试，这时固然不可能再来从新录制和编写全部的测试脚本。咱们能够使用已有的脚本，批量运行这些测试脚本测试旧的功能点是否正常工做。能够使用一个call命令来加载各测试脚本。还可在call命令中加各类TSL脚原本增长批量能力。 5．分析测试结果 分析测试结果在整个测试过程当中最重要，经过分析能够发现应用程序的各类功能性缺陷。当运行完某个测试脚本后，会产生一个测试报告，从这个测试报告中咱们能发现应用程序的功能性缺陷，能看到实际结果和指望结果之间的差别，以及在测试过程当中产生的各种对话框等。 6．回报缺陷（defect） 在分析完测试报告后，按照测试流程要回报应用程序的各类缺陷，而后将这些缺陷发给指定人，以便进行修改和维护。 经常使用的功能测试方法 功能测试就是对产品的各功能进行验证，根据功能测试用例，逐项测试，检查产品是否达到用户要求的功能。经常使用的测试方法以下： 一、页面连接检查：每个连接是否都有对应的页面，而且页面之间切换正确。 二、相关性检查：删除/增长一项会不会对其余项产生影响，若是产生影响，这些影响是否都正确。 三、检查按钮的功能是否正确：如update， cancel，delete， SAve等功能是否正确。 四、字符串长度检查： 输入超出需求所说明的字符串长度的内容，看系统是否检查字符串长度，会不会出错。 五、字符类型检查： 在应该输入指定类型的内容的地方输入其余类型的内容（如在应该输入整型的地方输入其余字符类型），看系统是否检查字符类型，会否报错。 六、标点符号检查： 输入内容包括各类标点符号，特别是空格，各类引号，回车键。看系统处理是否正确。 七、中文字符处理： 在能够输入中文的系统输入中文，看会否出现乱码或出错。 八、检查带出信息的完整性： 在查看信息和update信息时，查看所填写的信息是否是所有带出。，带出信息和添加的是否一致 九、信息重复： 在一些须要命名，且名字应该惟一的信息输入重复的名字或ID，看系统有没有处理，会否报错，重名包括是否区分大小写，以及在输入内容的先后输入空格，系统是否做出正确处理。 十、检查删除功能：在一些能够一次删除多个信息的地方，不选择任何信息，按”delete”，看系统如何处理，会否出错；而后选择一个和多个信息，进行删除，看是否正确处理。 十一、检查添加和修改是否一致： 检查添加和修改信息的要求是否一致，例如添加要求必填的项，修改也应该必填；添加规定为整型的项，修改也必须为整型。 十二、检查修改重名：修改时把不能重名的项改成已存在的内容，看会否处理，报错。同时，也要注意，会不会报和本身重名的错。 1三、重复提交表单：一条已经成功提交的纪录，back后再提交，看看系统是否作了处理。 1四、检查屡次使用back键的状况： 在有back的地方，back，回到原来页面，再back，重复屡次，看会否出错。 1五、search检查：在有search功能的地方输入系统存在和不存在的内容，看search结果是否正确。若是能够输入多个search条件，能够同时添加合理和不合理的条件，看系统处理是否正确。 1六、输入信息位置： 注意在光标停留的地方输入信息时，光标和所输入的信息会否跳到别的地方。 1七、上传下载文件检查：上传下载文件的功能是否实现，上传文件是否能打开。对上传文件的格式有何规定，系统是否有解释信息，并检查系统是否可以作到。 1八、必填项检查：应该填写的项没有填写时系统是否都作了处理，对必填项是否有提示信息，如在必填项前加* 1九、快捷键检查：是否支持经常使用快捷键，如Ctrl+C Ctrl+V Backspace等，对一些不容许输入信息的字段，如选人，选日期对快捷方式是否也作了限制。 20、回车键检查： 在输入结束后直接按回车键，看系统处理如何，会否报错。 Web测试中的界面测试用例设计 1、文本框、按钮等控件测试 　　一、文本框的测试 　　如何对文本框进行测试： 　　a、输入正常的字母或数字; 　　b、输入已存在的文件的名称; 　　c、输入超长字符。例如在“名称”框中输入超过容许边界个数的字符，假设最多255个字符，尝试输入256个字符，检查程序可否正确处理; 　　d、输入默认值，空白，空格; 　　e、若只容许输入字母，尝试输入数字;反之，尝试输入字母; 　　f、利用复制，粘贴等操做强制输入程序不容许的输入数据; 　　g、输入特殊字符集，例如，NUL及\n等; 　　h、输入超过文本框长度的字符或文本，检查所输入的内容是否正常显示; 　　i、输入不符合格式的数据，检查程序是否正常校验，如程序要求输入年月日格式为yy/mm/dd，实际输入yyyy/mm/dd，程序应该给出错误提示。 　　在测试过程当中所用到的测试方法： 　　a、输入非法数据; 　　b、输入默认值; 　　c、输入特殊字符集; 　　d、输入使缓冲区溢出的数据; 　　e、输入相同的文件名; 　　二、命令按钮控件的测试 　　测试方法： 　　a、点击按钮正确响应操做。如单击肯定，正确执行操做;单击取消，退出窗口; 　　b、对非法的输入或操做给出足够的提示说明，如输入月工做天数为32时，单击“肯定”后系统应提示：天数不能大于31; 　　c、对可能形成数据没法恢复的操做必须给出确认信息，给用户放弃选择的机会; 　　三、单选按钮控件的测试 　　测试方法： 　　a、一组单选按钮不能同时选中，只能选中一个; 　　b、逐一执行每一个单选按钮的功能。分别选择了“男”、“女”后，保存到数据库的数据应该相应的分别为“男”、“女”; 　　c、一组执行同一功能的单选按钮在初始状态时必须有一个被默认选中，不能同时为空。 　　四、up-down控件文本框的测试 　　测试方法： 　　a、直接输入数字或用上下箭头控制，如在“数目”中直接输入10，或者单击向上的箭头，使数目变为10; 　　b、利用上下箭头控制数字的自动循环，如当最多数字为253时，单击向上箭头，数目自动变为1;反之亦适用; 　　c、直接输入超边界值，系统应该提示从新输入; 　　d、输入默认值，空白。如“插入”数目为默认值，点击“肯定”;或删除默认值，使内容为空，单击“肯定”进行测试; 　　e、输入字符。此时系统应提示输入有误。 　　五、组合列表框的测试 　　测试方法： 　　a、条目内容正确，其详细条目内容能够根据需求说明肯定; 　　b、逐一执行列表框中每一个条目的功能; 　　c、检查可否向组合列表框输入数据。 　　六、复选框的测试 　　测试方法： 　　a、多个复选框能够被同时选中; 　　b、多个复选框能够被部分选中; 　　c、多个复选框能够都不被选中; 　　d、逐一执行每一个复选框的功能。 　　七、列表框控件的测试 　　测试方法： 　　a、条目内容正确：同组合列表框相似，根据需求说明书肯定列表的各项内容正确，没有丢失或错误; 　　b、列表框的内容较多时要使用滚动条; 　　c、列表框容许多选时，要分别检查shift选中条目，按ctrl选中条目和直接用鼠标选中多项条目的状况; 　　八、滚动条控件的测试 　　要注意一下几点： 　　a、滚动条的长度根据显示信息的长度或宽度及时变换，这样有利于用户了解显示信息的位置和百分比，如word中浏览100页文档，浏览到50页时，滚动条位置应处于中间; 　　b、拖动滚动条，检查屏幕刷新状况，并查看是否有乱码; 　　c、单击滚动条; 　　d、用滚轮控制滚动条; 　　e、滚动条的上下按钮。 　　九、各类控件在窗体中混和使用时的测试 　　a、控件间的相互做用; 　　b、tab键的顺序，通常是从上到下，从左到右; 　　c、热键的使用，逐一测试; 　　d、enter键和esc键的使用。 　　在测试中，应遵循由简入繁的原则，先进行单个控件功能的测试，确保实现无误后，再进行多个控件的的功能组合的测试。 　　ps：密码输入框测试时要特别注意进行字母大写输入的测试。 2、查找替换操做 　　案例演示：打开word中的“替换”对话框。 　　测试本功能有经过测试和失败测试两种状况： 　　经过测试： 　　a、输入内容直接查找、或查找所有; 　　b、在组合框中寻找已经查找过的内容、再次查找并确认文档的内容正确，如已经查找过“测试用例”、再次进入不用从新输入查找内容、直接在文档中搜寻就能够。 　　失败测试： 　　a、输入过长或太短的查询字符串。如假设查询的字符串长度为1到255，那么，输入0、一、二、25六、255和254进行测试; 　　b、输入特殊字符集。如在word中^g表明图片、^表明分栏符、能够输入这类特殊字符测试;替换测试大致相同。 　　关于编辑操做窗口的功能测试的用例： 　　a、关闭查找替换窗口。不执行任何操做、直接退出; 　　b、附件和选项测试。假如设定“精确搜寻”、“向后”搜索等附件选项等等来测试; 　　c、控件间的相互做用。如搜寻内容为空时、按钮“搜寻所有”、“搜寻”、“所有替换”、“替换”都为灰色。 　　d、热键、Tab键。回车键的使用。 　　插入操做 　　一、插入文件 　　测试的状况： 　　a、插入文件; 　　b、插入图像; 　　c、在文档中插入文档自己; 　　d、移除插入的源文件; 　　e、更换插入的源文件的内容。 　　二、连接文件 　　测试方法： 　　a、插入连接文件; 　　b、在文档中连接文档自己; 　　c、移除插入的源文件： 　　d、更换插入的源文件的内容。 　　三、插入对象 　　要测试的内容： 　　a、插入程序容许的对象、如在word中插入excel工做表; 　　b、修改所插入对象的内容。插入的对象仍能正确显示; 　　c、卸载生成插入对象的程序、如在word中插入excel工做表后卸载excel、工做表仍正常使用。 　　编辑操做 　　编辑操做包括剪切、复制、粘贴操做。 　　测试剪切操做的方法 　　a、对文本、文本框、图文框进行剪切; 　　b、剪切图像; 　　c、文本图像混合剪切。 　　复制操做方法与剪切相似。 　　测试时，主要是对粘贴操做的测试方法是： 　　a、粘贴剪切的文本、文本框及图文框; 　　b、粘贴所剪切的图像; 　　c、剪切后，在不一样的程序中粘贴; 　　d、屡次粘贴同一内容，如剪切后，在程序中连续粘贴3次; 　　e、利用粘贴操做强制输入程序所不容许输入的数据。 3、界面测试用例的设计方法 　　一、窗体 　　测试窗体的方法： 　　a、窗体大小，大小要合适，控件布局合理; 　　b、移动窗体。快速或慢速移动窗体，背景及窗体自己刷新必须正确; 　　c、缩放窗体，窗体上的控件应随窗体的大小变化而变化; 　　d、显示分辨率。必须在不一样的分辨率的状况下测试程序的显示是否正常。 　　进行测试时还要注意状态栏是否显示正确，工具栏的图标执行操做是否有效，是否与菜单懒中图标显示一致;错误信息内容是否正确、无错别字且明确等等。 　　二、控件 　　测试方法： 　　a、窗体或控件的字体和大小要一致; 　　b、注意全角、半角混合; 　　c、无中英文混合。 　　4、菜单 　　进行测试时要注意： 　　a、选择菜单是否能够正常工做、并与实际执行内容一致; 　　b、是否有错别字; 　　c、快捷键是否重复; 　　d、热键是否重复; 　　e、快捷键与热键操做是否有效; 　　f、是否存在中英文混合; 　　g、菜单要与语境相关、如、不一样权限的用户登录一个应用程序、不一样级别的用户能够看到不一样级别的菜单并使用不一样级别的功能; 　　h、鼠标右键快捷菜单。 　　特殊属性 　　a、安装界面应有公司介绍或产品介绍、有公司的图标; 　　b、主界面及大多数界面最好有公司图标; 　　c、选择“帮助”->“关于”命令、应看见相关版权和产品信息。 代替测试用例的检查表 2004年末在大连出差的时候，帮一个项目作测试，顺便写下这个检查表，这个检查表对测试的初学者积累经验比较有用，实际对于有经验的测试人员尤为对于测试业务管理信息系统，基本上大量的测试不须要再编写测试用例，固然对业务流程、复杂逻辑仍是要设计详细的测试用例的。若是你测试的系统是有大量人机交互的业务管理信息系统，并且你又比较懒惰，那就能够使用这个检查表检查了。 所以我总结了这类系统中经常使用的测试的检查项，供当时项目组的测试人员使用，如今再次整理出来发于博客。 1 针对测试组长或测试经理 1.1测试管理工做检查表： 1. 检查每轮测试开始时测试环境是否准备好（包括软件硬件、测试基本数据等）； 2. 确保测试环境（数据和程序）与开发分离，除了测试组以外其余人不能更新测试环境的数据和程序； 3. 每轮测试根据上一轮的状况和整体测试计划作分工调整； 4. 检查case库的填报状况，抽查执行过的case； 5. 检查BUG提交状况，抽查提交的BUG是否规范； 6. 天天晚上统计BUG状况，填写天天的BUG报告； 7. 根据天天的测试状况，决定是否开发组要发布新的BUILD； 8. 每轮测试结束后填写测试总结。 2  下面是针对测试执行人员的： 2.1输入、编辑功能的验证检查点： 1. 必输项是否有红星标记，若是不输入提示是否跟相应的Label对应，提示的顺序是否跟Form输入域的排列次序一致； 2. 输入的特殊字符是否能正确处理：`~!@#$%^&*()_+-={}[]|\:;”’<>,./?；