6. 敏捷项目中的用户测试
就本文的目的而言，用户测试包括：
验收测试（Acceptance testing）
可用性测试（Usability testing）
使用测试（Usage testing）
6.1 验收测试
敏捷社区已经意识到了验收测试的重要性，他们已经构造了像Fit（Mugridge and Cunningham 2005）这样的工具来将验收测试自动化。自动化测试会被频繁进行，如果不是每天多次的话，至少也是每天一次。另一方面，手工用户测试一般是在每个迭代周期的结束时进行的。在每个迭代周期结束后，很多敏捷团队会把开发完的系统部署到一个用于质量保证和测试的环境中，在那里将会进行用户和系统测试。这之后，团队会继续开发系统的第N+1个版本，同时他们会收到关于第N个版本的缺陷报告。对这些缺陷报告的处理方式正如对其它的需求一样：它们会被评估，确定优先级，然后被置于一个整体的需求堆中，以便在未来的某个时间对其进行处理。
6.2 可用性测试
在敏捷项目中，可用性测试被认为是可选做的内容。我可以很确信地说，很多的用户体验设计人员会对这种想法感到不满。在可用性测试这一点上，敏捷团队和传统的开发团队没有什么区别，他们很可能无法理解可用性测试的必要性（或为达到可用性目标而采取的其它一些用户体验方面的设计技术）。真正的可用性测试需要在受控的环境下反复对很多用户进行测试。正如验收测试可以在整个开发过程中定期进行一样，可用性测试也应当如此。在敏捷项目中，可用性测试应当在每个迭代周期之后随同用户测试一起进行。当然，这是假定团队中有人具备进行可用性测试所需的技能。
在敏捷项目中，可用性测试的正式程度并非一成不变。较为“灵活”的方法是Jeff Patton提出的可用性测试。在2006年敏捷开发大会的一个工作组讨论中，Patton描述了一种使用抽象的原型来模拟系统的技术（见图四在本页最后）。在这种方法中，一个开发人员负责模拟系统。他们不允许说话，只是帮助用户在“屏幕”（即纸面原型）之间进行导航。尽管有两个用户最好，不过要至少有一个用户利用纸面原型来完成场景中描述的任务。例如，在某大学系统中，某个场景可能是要求用户来报名参加某个研讨会。用户（们）应当在他们使用系统时说出他们正在思考什么。一个或多个开发人员担任观察者，他们做记录，但是他们不应当在用户使用系统时对这些纸面原型进行修改。
较为“正式”的方法则是传统的可用性测试。在这种情况下，研究人员在可用性实验室中观察用户如何使用系统。可用性实验室一般配备有单向玻璃，这使得研究人员可以看到用户。对于开发人员来说，这通常都是一次很有价值的经历，因为他们之前往往会错误地认为自己设计的用户界面很棒。有些可用性实验室甚至还配备有摄像机，这样你就可以记录下更精确的交互过程，从而可以回放用户的使用方法，对设计进行改进，以便去支持更有效的使用方法。
此文章共有10页 上一页 1 2 3 4 5 6 7 8 9 10 下一页
文章来源：中国项目管理资源网
|
Leadge.com首页 > 知识库 
