可用性测试方法包括哪些(可用性测试方法包括哪些方面)

Web应用系统的测试与传统的软件测试很不一样，那么Web的应用系统测试和软件测试有什么不一样呢？我们可以通过以下的内容区看一下他们之间的区别。

面向Web应用系统的测试与传统的软件测试不同，不仅需要检查和验证是否按照需求规格说明书的要求运行，而且还要测试Web应用系统在不同浏览器上显示是否符合要求，与不同的数据库连接是否有效、更重要的是在性能、安全性、可用性等方面功能测试性能测试安全性测试配置和兼容性测试可用性测试链接测试链接是Web应用系统用户界面的主要特征，它指引着Web用户在页面之间切换，以完成Web应用系统的功能测试重点链接是否正确链接页面是否存在是否有孤立的页面(没有链接指向的页面)表单测试表单(Form)是指网页上用于输入和选择信息的文本框、列表框和其他域，实现用户和Web应用系统的交互，当用户给Web应用系统管理员提交信息时，需要使用表单操作，如用户注册、登录、信息提交、查询等测试重点表单控件的正确性提交信息的完整性、正确性是否有错误处理Cookie测试Cookie通常标识用户信息，记录用户状态。

使用Cookie技术，当用户使用Web应用系统时，能够在访问者的机器上创立一个叫做Cookie的文件，把部分信息(访问过的页面、登录用户名、密码等)写进去，来标识用户状态。

如果该用户下次再访问这个Web应用系统，就能够读出这个文件里面的内容，正确标识用户信息如果Web应用系统使用了Cookie，必须检查Cookie是否能正常工作，是否按预定的时间进行保存内容设计语言测试在Web应用系统开发初始，根据软件工程的要求用文档的形式确定Web应用系统使用哪个版本的HTML标准，允许使用何种脚本语言及版本，允许使用何种控件，这样可以有效的避免Web应用系统开发过程中出现设计语言问题。

其他测试数据库测试面向任务、业务逻辑的测试探查性测试回归测试速度测试：对于最终的Web应用系统用户而言，最关心的性能问题是访问Web应用系统页面时，多长时间才能显示出来所需要的页面通常情况下，响应时间不超过5秒有些Web应用系统有超时限制，如果响应时间太慢，用户可能还没来得及浏览内容，就需要重新登录了影响响应时间的原因有很多应用程序服务器需要从数据库的大量数据中检索信息服务器硬件影响(CPU、内存)所访问页面文件大小网络连接带宽负载测试负载测试是为了测量Web应用系统在一定负载情况下的系统性能，通常得出的结论是Web应用系统在一定的硬件条件下可以支持的并发用户数目或者单位时间数据(或事件)的吞吐量。

在进行负载测试前，需要定义标准用户(活动用户)的概念，定义执行典型的系统流程，定义负载测试执行总时间，定义抓取哪些事务的平均响应时间，定义用户可以接受的平均响应时间(通常为5秒)测试时，增加用户数量，平均响应时间就会增加，当达到用户可以接受的平均响应时间这个临界点，即是此系统可以支持的并发用户数压力测试对Web系统进行压力测试，类似于普通机械、电子产品进行的破坏性试验。

方法是实际破坏Web应用系统，测试系统的反应压力测试是测试系统的限制和故障恢复能力，也就是测试Web应用系统会不会崩溃，在什么情况下会崩溃，崩溃以后会怎么样。

在Web应用系统性能测试过程中，常常将压力测试和负载测试结合起来。

在负载测试的基础上，增大负载量，直到系统崩溃实施性能测试需要注意测试工具灵活使用性能测试计划的制定由于数据库安全性导致的Web应用系统安全性问题Access数据库文件被下载用户重要信息没有经过加密而存于数据库中确认操作系统安全性，避免因操作系统漏洞导致Web应用程序的安全性问题Web应用系统多采用登录的方式，产品发布时提供默认的管理员用户名和密码确保应用系统实际应用中可修改默认管理员帐号和密码用户名和密码设置要求(长度、大小写敏感、复杂度)允许错误登录的次数是否可以不登录而直接浏览某个页面保证日志文件记录了Web应用系统的主要操作过程，并可根据日志文件追查到系统使用情况;同时还需要保证日志文件本身的安全性、完整性，防止被入侵者删除、获得当Web应用系统采用了SSL等加密技术之后，需要确认加密、解密后信息传递的正确性和完整性需要确认Web应用系统是否有超时设置，如有，则保证在超时设置时间内，如果未操作Web应用系统，当再次访问系统，需要重新登录了解安全漏洞信息，避免Web应用系统中出现的漏洞被入侵者利用;及时升级补丁程序，提高系统安全性Web应用系统多采用分布式体系结构，服务器端通常包括Web服务器组件、数据库服务器组件等。

服务器还可能运行在不同的操作系统上，并且这些组件、操作系统等还可以有不同的配置方法，所以针对服务器的兼容性测试往往工作量较大针对客户端浏览器的配置和兼容性测试是必不可少的，并且占据了Web应用系统客户端配置和兼容性测试的大部分时间典型的应用服务器：Web服务器：通过MSIIS、BEAWeblogic、IBMWebsphere、Tomcat、SunJ2EEApplication、Apache等中间件、插件，提供Internet/IntranetWeb服务，实现与众多客户之间的数据交换和共享数据库服务器主要提供数据库查询、处理的平台，通过Oracle、SQLServer、Informix、DB2、Sybase、MySQL等中大型的数据库管理系统来构建实时通信服务器提供数据实时通信、消息传递等服务，如MSN、Yahoomessage和ICQ等专用服务器服务器端配置和兼容性测试内容Web服务器数据库服务器防火墙操作系统硬件兼容性

可用性测试方法包括哪些方面

1、高级、复杂的研究方法都是由基础的研究方法组成。如同理心地图包含了访谈、观察法、电话、邮件等基础研究方法，综合性的信息、数据来源。

2、学会成体系的使用这些研究方法，考虑不同研究方法的优缺点。如同理心地图，需要多种研究方法按照一定顺序使用，用户访谈+实地研究+电话访谈+问卷调查，再整合。

3、不同的研究方法，采集的信息相似或相同。如同理心地图会研究用户的心理、行为；用户旅程图也关注用户的心理、行为；基础研究方法的观察法、用户访谈、专家评估也会考察心理、行为。

4、关于一些研究方法的量网上存在分歧。

关于人数或市场规模，如可用性测试有人建议5-6人，有人建议更多，没有一个准确的建议数字；关于时长，与组织或研究人员的经验、整合能力有关系，有人需要2天，有人需要2个月。

5、大部分的研究方法是定性研究，定性的研究会缺少数据衡量标准。所以，存在同一个研究对象不同人得出的结论会有偏差，越专业的人得出的结论越客观，接近真相。所以看到别人的研究报告时，需要辩证的看待。

6、大部分研究方法是针对用户、少量针对产品，所以设计、产品、高层对用户有一个深入的了解。

7、文章整体是启发式的介绍。目的是对设计研究有一个认识，使用时需查看更专业、详细的资料。

根据设计阶段的不同，可用性评估方式可以被分为两大类：形成性评估和总结性评估。它们目标不同，因此执行它们的方法和时机也不同。

目的：发现尽可能多的可用性问题，通过修复可用性问题实现软件可用性的提高。告诉我们设计在哪方面做得好、哪方面不好、及其原因。

时机：产品流程早期，整个设计过程中

方法：启发式评估、可用性认知走查、可用性测试……。

可用性测试：确定用户在设计界面上要完成的任务，让被测试的用户出声思考，观察他们的行为，理解他们何时感到困惑或犯错，此时的目的是了解哪部分做得好、哪部分需要改进、原因。

此时测试用户数量不需很多——5个就够了。

了解了设计里需要改进的地方，重做该设计，改善用户体验，在整个产品设计中通过迭代让产品体验变得更好。

目的：横向评估多个版本或者多个产品，输出评估数据进行对比。产品整体的可用性或满意度如何；产品与竞品的不同；产品的可用性与给定标准相比如；不同迭代版本之间的差距。

不适用于：想快速了解如何改进产品

时机：产品完成时，拥有了代表性的大样本量的用户。

用户不受帮助地使用产品完成任务，并在给定的度量表中写下评分体验。

度量表：满意度、可用性、净推值……（Mark，为了评分可靠，需要较多数量、有代表性的样本。如果产品还没有上线，就需要提前预估用户群体）。

根据被测试群体的不同，可以分为两类：一类分为面向专家的方法和一类面向用户的方法。

群体：主要由UX、UI、前端等专家参与，专家充当鉴定官，将自己放在用户的角色情境中。

方法：认知过程走查法，启发式评估法（包括尼尔森启发式评估十原则、施耐德曼的八项黄金法则、IBM的设计原则……）。

群体：召集目标用户进行测试，通过用户反馈或操作得出数据。

方法：问卷调查过程，焦点小组，可用性测试，发声思考法。

（焦点小组focusgroup和用户访谈userinterview的区别是，focusgroup是多个用户针对主题讨论，用户访谈是一对一的。

用户访谈可以在前期调查或者用户测试后进行访谈。

在此期间，研究人员向用户询问有关感兴趣的主题，例如系统的使用、行为和习惯等的问题，目的是了解该主题。

）。

用户测试usertest

可用性评估UsabilityEvaluation。

可用性测试Usabilitytest