易用性（Useability）是交互的适应性、功能性和有效性的集中体现。
人体工程学（ergonomics）是一门将日常使用的东西设计为易于使用和实用性强的学科。
在 2003 年颁布的 GB/T16260-2003(ISO 9126-2001) 《软件工程 产品质量》质量模型中，提出易用性包含易理解性、易学习性和易操作性；即易用性是指在指定条件下使用时，软件产品被理解、学习、使用和吸引用户的能力。
（ 1 ）易理解性；（ 2 ）易学习性；（ 3 ）易操作性；（ 4 ）吸引性；（ 5 ）依从性。


易用性测试包括针对应用程序的测试，同时还包括对用户手册系统文档的测试。通常采用质量外部模型来评价易用性。包括如下方面的测试：
（ 1 ）易理解性测试；
（ 2 ）易学性测试；
（ 3 ）易操作性测试；
（ 4 ）吸引性测试；
（ 5 ）易用的依从性测试。


易用性测试方法有：静态测试；动态测试；动态和静态结合测试。

人体工程学的主要目标是达到易用性。
1、用户界面测试
用于与软件交互的方式称为用户界面或UI。
2、优秀UI的构成
软件测试员要负责测试软件的易用性，包括其用户界面。
记住，软件测试员不需要去设计UI，只需要把自己当作用户，然后去找出UI中的问题。
优秀UI具备的七个要素：
（1）符合标准和规范
最重要的用户界面要素是软件符合现行的标准和规范——或者有真正站得住脚的不符合的理由。
注意：如果测试在特定平台上运行的软件，就需要把该平台的标准和规范作为产品说明书的补充内容。像对待产品说明书一样，根据它建立测试用例。
这些标准和规范由软件易用性专家开发。它们是经由大量正规测试、使用、尝试和错误而设计出的方便用户的规则。
也并非要完全遵守准则，有时开发小组可能想对标准和规范有所提高。
平台也可能没有标准，也许测试的软件就是平台本身。
在这种情况下，设计小组可能成为软件易用性标准的创立者。
（2）直观
用户界面是否洁净、不唐突、不拥挤？
UI的组织和布局合理吗？
有多余功能吗？
帮助系统有效吗？
（3）一致
如果软件或者平台有一个标准，就要遵守它。如果没有，就要注意软件的特性，确保相似的操作以相似的方式进行。
快捷键和菜单选项
术语和命名
听众
诸如OK和Cancel按钮的位置。
（4）灵活
多种视图的选择：
状态跳转
状态终止和跳过
数据输入和输出
（5）舒适
软件使用起来应该舒适，不能给用户工作制造障碍和困难。
恰当；
错误处理；
性能。
（6）正确
要测试正确性，就是测试UI是否做了该做的事。
注意：市场定位偏差、语言和拼写、不良媒体、WYSIWYG（所见即所得）。
（7）实用
是否实用事优秀用户界面的最后一个要素。
3、为有残疾障碍的人员测试：辅助选项测试
辅助选项测试（accessibility testing）也就是为有残疾障碍的人测试。
残疾有许多种：视力损伤、听力损伤、运动损伤、认知和语言障碍。
（1）法律要求：
开发残疾人可以使用的用户界面的软件有一些法律规定。在美国，有3条法律：
美国公民残疾人条例（ADA）声明
居民条例第508款
通信条例第255款
（2）软件中的辅助特性
软件可以有两种方式提供辅助。
最容易的方式是利用平台或者操作系统内置的支持。
如果测试的软件不在这些平台上运行，或者本身就是平台，就需要定义、编制和测试自己的辅助选项。
注意：如果正在测试产品的易用性，一定要专门为辅助选项建立测试用例。
如windows系统，提供了：粘滞键，筛选键，切换键，声音卫士，声音显示，高对比度，鼠标键，串行键。
4、总结
总之，不要让易用性测试的模糊性和主观性阻碍测试工作。易用性测试的模糊和主观是固然的，即使设计用户界面的专家也会承认有的地方是这样的。

系统测试是在将软件产品交付给客户使用之前完成的最终产品测试。此测试一般在完成开发和功能验证测试之后进行。某些入口标准用来确定对于系统测试的代码准备状态（举例来说 ， 回归状态，缺陷后备，等等）。必须达到这些标准，从而正式地开始系统测试并要求结果。

在一般的系统测试中，目标是用类似客户的配置在高压下对系统进行类似客户的工作量（举例来说，多平台、多软件版本，等等）。 正式的系统测试执行包含压力、寿命期运行、内存泄漏分析、多应用程序、复杂且各种各样的拓扑、高可用性及中断测试、混合的版本测试、全平台测试、产品集成测试，及文档测试。

本文介绍了团队所采用的将一组系统测试子集作为敏捷开发环境的一部分，并与代码开发活动并行的方法。我们将展示出我们的方法可以交付更好的系统测试应用程序，让实验方法将包含与代码开发并行的系统测试子集的价值和效率最大化，并提高团队的沟通和技能。这些成功 导致 （led） 了在完整的系统测试开始时改进了的完整的 软件验证团队（ SVT ） 的加速的时间，以及改进了的产品质量的预期好处。

在六个迭代中，系统测试核心团队与开发团队并行工作。这能够让传统的系统测试应用程序的子集的开发和执行在每个迭代的过程中执行。该并行导致了此处描述的各个方面的成功。

敏捷的过程实现模型

在开发的一年之后，使用现有的瀑布实践并交付开放的 alpha 和 beta，我们的项目转换了工具，并实现敏捷的开发模型。整个团队需要将敏捷的开发原则作为“现场实验”，从而满足特定客户的需求。第一个迭代是过渡的，通常着重于交付在瀑布开发模型下开发了几个月的代码。当第一个迭代开始时，整个团队包括大约五十五个人，包括设计人员、开发人员、测试人员、信息开发人员和客户交付团队。

迭代 1 用作过渡的迭代，用于完成已经处于开发中的可交付件。敏捷开发过渡适当地启动，并且带有对前一或两个迭代的适度的开发承诺。主要的焦点在于在团队和集成的过程之间构建并交流新的项目和人与人之间的文化，例如，并行的早期系统测试，这将会用于在新的环境中令团队成功。

九个系统测试人员（整个系统测试团队的子集）在先前的瀑布开发周期中兼职参与。在开发代码的过程中，他们关注构建技术技能、计划、测试案例开发，和应用程序单元测试。这样做，他们练就了项目所用的技术中的技能，但没有获得内行的经验。

当转变为敏捷开发时，九个系统测试人员中的五个全职参与项目。因此，在第一个迭代之前，系统测试团队已经了解了新技术，创建了测试应用程序，并且像团队一样一起工作。这些早期的测试及开发活动令敏捷周期的开始有更高的生产率。

系统测试团队参与的目的

五个系统测试人员面临的挑战是确保代码质量足以达到在任一已知的迭代中开发的功能的 beta 级交付。为了迎接这个挑战，他们决定在每个迭代中运行传统的系统测试应用程序开发和执行的子集，预期最终的迭代进行一组更复杂的具体客户的，基于场景的测试。系统测试团队与项目的高级架构师会面，并一起为了增强和执行选择一个现有的系统测试应用程序。然后，该应用程序将用于在迭代过程中的压力和寿命期运行，并且在最终的迭代里大量地使用。目的是在项目最终在世界范围内交付时，系统测试人员有限且同时的参与会为最终的完全的系统测试迭代建立起坚固的基础。

项目和迭代的时间线

迭代有六个星期之久。表 1 显示了一般的迭代规划，以及为每个星期计划的具体的系统测试活动。在迭代的第 1 周中，高级架构师提出建议的候选功能列表。该列表主要基于具体客户的需求，并且通过用例进行描述。该列表可在线访问，以便在迭代进行中，所有的团队成员都可以改进用例。每个团队成员都会审查候选的列表，并与团队成员和高级架构师一起讨论设计及问题，并且在周末提交在迭代结束时（是否）要交付的功能。每天举行一个小会。高级架构师每天都出席大部分小会议，并且在所有迭代过程中都与全部团队成员在一起。

如前面所提到的，最后的迭代计划着重于在开发迭代中不能实现的最终的缺陷清理和复杂的测试。为了提高稳定性，最后的迭代没有新的功能。六个迭代完成了。同时，在最后的迭代中，大量的开发人员需要加入系统测试团队成员中，通过提供对测试执行和调试的辅助来完成最终的迭代。其余的开发人员会处理缺陷。这意味着在较早的迭代中的开发阶段里，一些开发人员需要为了最后的迭代而培训系统测试的知识。

表 1：每个迭代的活动：开发和系统测试

周	开发	系统测试活动
1	开始 设计 团队承诺	决定并提出迭代承诺，包括：根据在迭代中交付的新功能，定义压力测试的测试应用程序的提高及选择。
2	开发/测试	与高级架构师一起审查测试应用程序设计的增强。 开始应用程序增强的开发和单元测试。 利用可用的驱动程序开始回归测试。
3-4	开发/测试 审查开发/测试结果	继续应用程序增强的开发和单元测试，及回归测试。 创建测试场景并准备必要配置的机器。开发/提高自动化脚本。
5	高优先级的缺陷，没有新的功能	压力运行新的功能。在连续的迭代中增加压力/负载。 对新的功能驱动程序进行回归。 打开缺陷，带补丁执行，提供追踪，并检验缺陷。培训开发人员加入 SVT 的工作。 用额外的细节改进测试场景，并追踪进展。
6	审查系统测试结果 打包 演示 了解的经验 交付	继续与第 5 周同样的活动。 参与演示的计划、准备及执行。 提出系统测试结果。 为所了解的经验提供输入。
每天	功能测试的回归	对当前的驱动程序进行回归。