软件测试中什么是可用性测试
可用性测试的概念是：让一群具有代表性的用户对产品进行典型操作，同时观察员和开发人员在一旁观察，聆听，做记录。
可用性有五个指标，分别是易学性、易记性、容错性、交互效率和用户满意度。
可用性测试适于解决的问题：
1） 确定测试产品的可用性水平
2） 与预期目标、与竞争对手、与老版设计相比的可用性水平
3） 比较不同方案，确定哪个方案更加可行
4） 现测试产品的可用性问题
软件可靠性测试，可用性测试的定义，有什么区别
软件可靠性测试是指：为了评估软件在规定的寿命期间内，在预期的使用、运输或储存等所有环境下，保持软件功能可靠性而进行的测试。
软件可用性测试是指：是对软件“可用性”进行评估，检验其是否达到可用性标准。目前的可用性评估方法超过20种，按照参与可用性评估的人员划分，可以分为专家评估和用户评估；按照评估所处于的软件开发阶段，可以将可用性评估划分为形成性评估和总结性评估。形成性评估是指在软件开发或改进过程中，请用户对产品或原型进行测试，通过测试后收集的数据来改进产品或设计直至达到所要求的可用性目标。形成性评估的目标是发现尽可能多的可用性问题，通过修复可用性问题实现软件可用性的提高，总结性评估的目的是横向评估多个版本或者多个产品，输出评估数据进行对比。
软件可靠性测试，可用性测试的定义，有什么区别
软件可靠性测试是指：为了评估软件在规定的寿命期间内，在预期的使用、运输或储存等所有环境下，保持软件功能可靠性而进行的测试。
软件可用性测试是指：是对软件“可用性”进行评估，检验其是否达到可用性标准。目前的可用性评估方法超过20种，按照参与可用性评估的人员划分，可以分为专家评估和用户评估；按照评估所处于的软件开发阶段，可以将可用性评估划分为形成性评估和总结性评估。形成性评估是指在软件开发或改进过程中，请用户对产品或原型进行测试，通过测试后收集的数据来改进产品或设计直至达到所要求的可用性目标。形成性评估的目标是发现尽可能多的可用性问题，通过修复可用性问题实现软件可用性的提高，总结性评估的目的是横向评估多个版本或者多个产品，输出评估数据进行对比。
网站的可用性测试 主要包括哪些方面
转载，非原创网站的测试包括：
一：性能测试
（1）连接速度测试。用户连接到电子商务网的速度与上网方式有关，他们或许是电话拨号，或是宽带上网！
（2）负载测试。负载测试是在某一负载级别下，检测电子商务系统的实际性能。
也就是能允许多少个用户同时在线！可以通过相应的软件在一台客户机上模拟多个用户来测试负载。
（3）压力测试。压力测试是测试系统的限制和故障恢复能力，也就是测试电子商务系统会不会崩溃！
二：安全性测试
它需要对电子商务的客户服务器应用程序、数据、服务器、网络、防火墙等进行测试！用相对应的软件进行测试！
｛上面的测试是针对电子商务的，在电子商务书上找到的，那个测试一般普通的网站就是二方面。
1.基本测试
包括色彩的搭配，连接的正确性，导航的方便和正确，CSS应用的统一性
2.技术测试
网站的安全性（服务器安全，脚本安全），可能有的漏洞测试，攻击性测试，错误性测试。 ｝
网站的评估主要对以下方面：网站界面,产品展示,在线支付,在线客服,线下产品配送。更重要的是目标消费者可以很方便快捷的找到该网站,从而进行电子商务活动.让客户找到该电子商务网站。是否网站有一个搜索引擎!或是把自己的网站添加到一些大的分类目录上。再就是让目标客户记得你网站的名字(最终效果--品牌效果)并直接进去！个好的电子商务网站是看它是否经过搜索引擎优化了.
软件测试中什么是可用性测试
可用性是指软件是否能够正常使用，不能出现系统宕机影响使用的情况
可用性测试的注意事项
你测试的是产品，而不是使用者
对一些用户而言， 测试有负面的涵义。我们要努力确保他们不认为测试是针对他们。我们要让他们明白，他们正在帮助我们测试原型或网站。事实上，我们可以不使用“测试”这个术语。相反，我们是邀请参加者为我们提供帮助， 勇于尝试原型 。 当用户难以完成任务时，我们应该改变网站，而不是改变用户。同时我们还应该思考该网站能在多大程度上符合那些典型用户的的目标，而不是关注用户在这个任务做的多好。
更多地依靠用户的表现，而不是他们的偏好
通过测试我们可以测量到用户的表现，以及他们的偏好。用户的表现包括是否成功完成，所用时间，产生的错误等等。偏好包括用户自我报告的满意度和舒适度 。 一些设计人员认为，如果他们的设计能迎合用户的喜好，用户在该网站上就会有良好的表现。但证据并不支持这一点。事实上，用户的表现以及他们对产品的偏好并非一一对应。一项研究发现，约有百分之七十的用户同意表现和喜好有联系。也就是说，他们在喜爱的网站上表现良好，在不喜欢的网站上表现欠佳。 然而，还有相对比较大比例的人（ 30 % ）认为 ，用户的表现以及他们对产品的偏好并非一一对应。他们在不喜爱的网站上可能表现良好，在喜欢的网站上也可能表现不佳。 关于人们为什么会对自己表现欠佳的网站给出较高的评价有多种解释。他们可能会把表现不佳归结到自己，而不是网站。或者说，他们可能担心给一个较低的评价会伤害网站设计者，也就是我们的感情。或者说，他们可能并没有完成任务，却自认为成功完成了，他们并没有意识到问题所在。基于所有这些理由，我们建议你：更多地依靠用户的表现，而不是他们的偏好。
把你掌握的测试结果应用起来
可用性测试不仅仅是用于核对项目进度的一个里程碑，你要知道，当最后一个参与者完成任务的时候，可用性测试还没有结束。整个团队必须仔细研究结果，设定优先次序，基于结果对或者网站原型进行修改。
基于用户体验，找出问题的最佳解决方法
制造任何产品，包括大部分网站和软件，需要考虑许多不同的用户的工作方式、体验、问题以及需要。大多数项目，包括设计或修改网站，都要处理时间、预算和资源等方面的限制。平衡各个方面对大部分项目来说都是一个重大的挑战。 在你权衡利弊时，最好优先开发那些能使最多用户完成任务的网站或软件。有研究表明，产品推出后，用于支持失败客户的花费远远高于开发时对产品修正所付出的花费。 你需要认真考虑假定用户、使用场景以及可用性测试的结果，试图找出针对不同客户需求的理想解决方法。找不到最好的解决方法，用户就不能够顺畅地完成任务。有证据表明，即使用户延长使用时间在一个不太完美的产品界面完成任务，也远不及在一个更好的产品界面带来的成功感。
如何进行可用性测试和用户研究
可用性测试是一种操作性较强的迭代设计方法。关于迭代设计，还有一种说法叫“MVP"（Minimum Viable Product，最低可行产品），即快速推出产品，后续不断改进。
这能有效地降低产品研发周期，快速占领市场，快速获得客户反馈。
很多人对设计的误解，认为设计师都是些不食人间烟火，深夜案头苦思冥想闭门几个月最终憋出来一个惊世设计方案，而当灵感枯竭时则颓废懒散无所事事的人，
认为设计依赖于捉摸不定的灵感而无法进行项目时间管控。这种观点更多地认为设计就是临门一脚的结果。事实上，假如脱离了中场组织和调整，缺少了必要的控球倒脚，临门一脚往往无果而终。
设计更多是过程，沟通过程。可用性测试提供了这样一种简单直接的沟通方式。通过这种方式获得用户反馈，并以此为设计依据迅速调整产品功能乃至产品方向。
如能秉持这种设计即沟通的理念，自然不会将可用性测试仅仅看做是一种无奈之选。
小到一个图标的辨识，页面导航，功能使用，大到某项业务的办理，都可以拿来做可用性测试。
测试对象的选取也没有过多要求，任何不相关的同事，朋友，甚至路人都可以被请来参加你的可用性测试。除了专业度很高的比如业务处理等，一般性的操作对是否具有真正用户资质的要求并不高。
原因在于，可用性测试最大的作用是发现明显的可用性问题（不要怀疑设计师的水平，有太多设计失败案例是源于看起来简单愚蠢之极的错误），而这些问题多数跟专业无关，只跟常识有关。
具体操作也很简单，无需拘泥于测试地点，准备材料，等等，一张纸一枝笔足够矣。
这里操作关键的点在， 1. 场景代入，2. 观察和倾听。
场景代入是指让被试者知道大概的背景，比如这个软件功能是做什么的，谁会是使用者等，但不告诉具体如何操作（有点小白鼠的意思）。
观察，靠的不仅仅是眼睛，而是心。只有清楚自己要借助测试得到什么，才能不错过转瞬即逝的细节。这要求主试者本人对设计有较深的理解。
其他的工作则是为了确保可用性测试顺利进行。比如前期需要邀请，需要准备任务清单，提问清单，需要记录的设备工具，还有一点小意思。
但真正影响可用性测试质量的只取决于主试者自身的经验和水平。
链接：http://www.zhihu.com/question/20418124/answer/25583970
来源：知乎
软件测试中系统测试的类型有哪些
系统测试包括恢复测试、安全测试、压力测试。具体如下：
1、恢复测试
恢复测试作为一种系统测试，主要关注导致软件运行失败的各种条件，并验证其恢复过程能否正确执行。在特定情况下，系统需具备容错能力。另外，系统失效必须在规定时间段内被更正，否则将会导致严重的经济损失。
2、安全测试
安全测试用来验证系统内部的保护机制，以防止非法侵入。在安全测试中，测试人员扮演试图侵入系统的角色，采用各种办法试图突破防线。因此系统安全设计的准则是要想方设法使侵入系统所需的代价更加昂贵。
3、压力测试
压力测试是指在正常资源下使用异常的访问量、频率或数据量来执行系统。在压力测试中可执行：如果平均中断数量是每秒一到两次，那么设计特殊的测试用例产生每秒十次中断；在虚拟操作系统下，产生需要最大内存量或其它资源的测试用例，或产生需要过量磁盘存储的数据。
扩展资料：
系统测试的目标和原则：
1、 确保系统测试的活动是按计划进行的；
2、 验证软件产品是否与系统需求用例不相符合或与之矛盾；
3、 建立完善的系统测试缺陷记录跟踪库；
4、 确保软件系统测试活动及其结果及时通知相关小组和个人。
5、原则是测试机构要独立；要精心设计测试计划，要进行回归测试；测试要遵从经济性原则。
参考资料来源：百度百科-系统测试
软件测试：测试设计应该包含什么内容？？？？？谢谢
你说的测试设计 有点模糊，可以描述的清楚一点吗？
测试设计中需要考虑的22种测试类型 --
黑盒测试：不基于内部设计和代码的任何知识，而是基于需求和功能性。
白盒测试：基于一个应用代码的内部逻辑知识，测试是基于覆盖全部代码、分支、路径、条件。
单元测试：最微小规模的测试；以测试某个功能或代码块。典型地由程序员而非测试员来做，因为它需要知道内部程序设计和编码的细节知识。这个工作不容易作好，除非应用系统有一个设计很好的体系结构; 还可能需要开发测试驱动器模块或测试套具。
累积综合测试：当一个新功能增加后，对应用系统所做的连续测试。它要求应用系统的不同形态的功能能够足够独立以可以在全部系统完成前能分别工作，或当需要时那些测试驱动器已被开发出来; 这种测试可由程序员或测试员来做。
集成测试：一个应用系统的各个部件的联合测试，以决定他们能否在一起共同工作。部件可以是代码块、独立的应用、网络上的客户端或服务器端程序。这种类型的测试尤其与客户服务器和分布式系统有关。
功能测试：用于测试应用系统的功能需求的黑盒测试方法。这类测试应由测试员做，这并不意味着程序员在发布前不必检查他们的代码能否工作(自然他能用于测试的各个阶段)。
系统测试：基于系统整体需求说明书的黑盒类测试；应覆盖系统所有联合的部件。
端到端测试：类似于系统测试；测试级的“宏大”的端点；涉及整个应用系统环境在一个现实世界使用时的模拟情形的所有测试。例如与数据库对话，用网络通讯，或与外部硬件、应用系统或适当的系统对话。
健全测试：典型地是指一个初始化的测试工作，以决定一个新的软件版本测试是否足以执行下一步大的测试努力。例如，如果一个新版软件每5分钟与系统冲突，使系统陷于泥潭，说明该软件不够“健全”，目前不具备进一步测试的条件。
衰竭测试：软件或环境的修复或更正后的“再测试”。可能很难确定需要多少遍再次测试。尤其在接近开发周期结束时。自动测试工具对这类测试尤其有用。
接受测试：基于客户或最终用户的规格书的最终测试，或基于用户一段时间的使用后，看软件是否满足客户要求。
负载测试：测试一个应用在重负荷下的表现，例如测试一个 Web 站点在大量的负荷下，何时系统的响应会退化或失败。
强迫测试：在交替进行负荷和性能测试时常用的术语。也用于描述象在异乎寻常的重载下的系统功能测试之类的测试，如某个动作或输入大量的重复，大量数据的输入，对一个数据库系统大量的复杂查询等。
性能测试：在交替进行负荷和强迫测试时常用的术语。理想的“性能测试”(和其他类型的测试)应在需求文档或质量保证、测试计划中定义。
可用性测试：对“用户友好性”的测试。显然这是主观的，且将取决于目标最终用户或客户。用户面谈、调查、用户对话的录象和其他一些技术都可使用。程序员和测试员通常都不宜作可用性测试员。
安装/卸载测试：对软件的全部、部分或升级安装/卸载处理过程的测试。
恢复测试：测试一个系统从如下灾难中能否很好地恢复，如遇到系统崩溃、硬件损坏或其他灾难性问题。
安全测试：测试系统在防止非授权的内部或外部用户的访问或故意破坏等情况时怎么样。这可能需要复杂的测试技术。
兼容测试：测试软件在一个特定的硬件/软件/操作系统/网络等环境下的性能如何。
比较测试：与竞争伙伴的产品的比较测试，如软件的弱点、优点或实力。
Alpha 测试：在系统开发接近完成时对应用系统的测试；测试后，仍然会有少量的设计变更。这种测试一般由最终用户或其他人员员完成，不能由程序员或测试员完成。
Beta 测试：当开发和测试根本完成时所做的测试，而最终的错误和问题需要在最终发行前找到。这种测试一般由最终用户或其他人员员完成，不能由程序员或测试员完成。