第十二章 用户体验
12.1 用户体验的要素
用户的第一印象
从用户的角度考虑问题
软件服务始终都要记住用户的选择(长期的使用只会使软件更好用)
短期刺激 长期影响
不让用户犯简单的错误
注重用户体验和质量
情感设计
12.3 评价标准
对于一个软件的用户界面,我们有没有什么评价标准呢?可以参考费茨法则(Fitts law)、Nielsen启发式评估十条原则以及其他经验。下面是邹欣老师在自身实践的基础上总结的一些原则:
-
尽快提供可感触的反馈系统状态
-
系统界面符合用户的现实惯例(Familiarity,Avoid Surprise)
与用户沟通,软件系统要使用用户语言而不是开发者语言,所用的概念要贴近生活实际,而不是用学术概念或开发者的概念。我们说的生活实际,最好是目标用户的实际生活体验。
- 用户有控制权
操作失误可回退,要让用户可以退出软件(很多软件都没有退出菜单,这是导致用户反感的一大原因)。用户可以定制显示信息的多少,还可以定制常用的设置。
- 一致性和标准化
在软件中,对同一事物和同类操作的表示用语,各处要保持一致。例如,某词典软件有“帮助用户收集生词并且背诵生词”的功能。这个功能要有明确一致的称呼,不能混杂着叫“单词本”、“生词本”、“Word List”、“Word Book”、“单词文件”……等等。
-
适合各种类型的用户
-
帮助用户识别、诊断并修复错误
-
有必要的提示和帮助文档
不需要文档,用户就能使用自如,当然更好,必要时还可以提供在线帮助。如果软件和用户的工作相关(而不是简单的游戏),那么基本的提示和帮助文档还是很有必要的,而且也要提供便利的检索功能。文档要从用户的角度出发描述具体步骤,并且不要太冗长。
第十三章 软件测试
13.1 名词解释
Bug :软件的缺陷
Test Case :测试用例。测试用例描述了一个完整的测试过程,包括测试环境、输入、期望的结果等
Test Suite :测试用例集。即一组相关的测试用例
13.2 Bug解释与实例
①Bug可以分解为:症状(Symptom)、程序错误(Fault)、根本原因(Root Cause)
症状:即从用户的角度看,软件出了什么问题
程序错误:即从代码的角度看,代码的什么错误导致了软件的问题
根本原因:错误根源,即导致代码错误的根本原因
②Bug例子
症状:用户报告,一个windows应用程序有时会有在启动时报错,继而不能运行
程序错误:有时候一个子窗口的handle有空,导致程序访问了非法内存地址,此为代码错误
根本原因:代码并没有确保创建子窗口,因此子窗口的handle变量有时会在访问时处于未赋值状态(为空),导致出现代码错误
13.3测试方法
①黑箱:指的是设计测试的过程中,把软件系统当做一个“黑箱”,无法了解或使用系统的内部结构及知识。一个更准确的说法是行为测试设计,即从软件的行为,而不是从内部结构出发来设计测试
②白箱子:指的是在设计测试的过程中,设计者可以“看到”软件系统的内部结构,并使用软件的内部结构及知识来选择测试数据及具体的测试方法。
第十四章 质量保障
14.1 软件质量
软件 = 程序 + 软件工程
软件(质量) = 程序(质量) + 软件工程(质量)
14.2 软件质量的保障与软件的测试
软件测试:运用一定的流程和工具,验证软件能实现预先设计的功能和特性,工作的流程和结果通常是可量化的
软件质量的保障工作:软件团队为了让软件达到事先定义的质量标准而进行的所有活动,包括测试工作
第十五章 稳定和发布阶段
15.1 从代码完成到发布
第一步:开发者提交参加会诊的Bug和修改方案,以及伙伴测试结果。开发者必须向与会者报告的是:
Bug是什么危害是什么,如果不修复,有何后果用户会有什么变通办法是否经过代码复审,是否经过伙伴测试
第二步:会议决定是否同意修改方案
决定哪些缺陷必须现在就进行修复,哪些可以推迟到下一个里程碑。会诊应该对每一个修复选择下列处理方式。
Must——必须修复,缺陷很严重,修复方案可行,相关的测试都通过More Info——需要更多的信息No——不能接受,可能是推到下一个里程碑,可能是提出的解决方案不符合要求Like——可能,不一定必须修复,但是解决方案相对比较安全。在更复杂的项目中,可以考虑引入这一个中间的状态“Like”(在相对简单的系统中,这个选项可以不用)。如果在今天的会诊中有“Must”,那么处于待命状态的“Like”修复就可以一起集成到代码库中。如果没有“Must”级别的修复,那么“Like”级别的修复就只能处于“待命”状态,直到以后出现了“Must”级别的修复为止
第十六章 IT行业的创新
影响产品竞争的各种因素
产品行业的因素
这是影响产品发展的最重要的因素,2012年流传着一句俗话——“站在风口上,连猪都可以飞起来”,就是说明产业发展的成长期(竞争产品少,市场空间大,用户容忍度强)能给产品提供巨大的助力。相反,如果是在一个产业的衰落期进入这个产业(例如,在2008年做小灵通手机业务,在2013年进军网络团购市场,等等),那么就会面临巨大的发展阻力。公司和市场因素
公司在目前目标用户中的品牌号召力如何?公司的现有市场能力如何?现有的市场能力能帮助打开新的领域么?从传统的产品开发角度来看,“市场”总是在产品之后才出现,而且和“产品开发”似乎没有直接的联系。但是从长期来看,产品的质量就是最有效的市场能力,产品经理往往就是市场经理。团队执行因素
根据产品特性的不同(基础软件、企业管理软件、行业通用软件、办公软件、互联网服务软件、移动应用软件等),商业模式不同,团队的战略也会不一样。在正确的时间,有正确的产品,却执行了错误的策略,或者不能做出决定,那么产品也会失败。执行力的一个有效衡量标准是一个决定需要多少次会议才能达成。一些团队对市场展现的机会往往陷入过度的分析和评价,力争要弄清所有情况再动手,最后的结果是动不了手。这是“分析麻痹”(Analysis Paralysis)。产品的价值因素
产品给用户带来什么价值,这是和“软件工程”最相关的内容。考虑新产品或产品的新功能时,团队要问:我们给用户带来了什么价值,这个产品是提供了独家的价值,还是“人有我也有”的价值?这个价值足以让本产品和目前市场上已有的产品区分开么?我们怎么能进一步放大产品差异性?让我们越来越领先,或者让用户觉得我们很领先?我们是否在非差异化功能上花费了太多时间和资源?
第十七章 人、绩效和职业道德
①RASCI模型
R:Responsible,负责把具体事情做好
A:Accountable,对任务负全责,有批准的权利
S:Support,对任务提供支持,辅助任务的完成
C:Consulted,咨询,拥有完成项目所需的信息或能力的角色
I:Informed,知会者,应该事后及时通知结果的角色
②团队合作的阶段:
(1)萌芽阶段,就像小苗破土而出,柔弱但充满希望
(2)磨合阶段,就像一个人的青少年时期,充满了对个人、同伴和团队的疑惑和冲突
(3)规范阶段,从磨合阶段毕业,进入规范阶段的团队,成员们意识到光争吵时没有用的,大家还是要协同作战
(4)创造阶段,经历了萌芽、磨合、规范阶段,现在团队终于可以创造一些有意义的东西
③不管从事哪一个职业,不管你是属于哪个岗位上的,都必须具有职业道德,软件工程师同样也需要
标签:阅读,测试,用户,笔记,构建,产品,软件,Bug,修复 From: https://www.cnblogs.com/lmyy/p/17366429.html