构建之法阅读笔记05

Posted 键盘已坏

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了构建之法阅读笔记05相关的知识,希望对你有一定的参考价值。

第11章 软件设计与实现

图形建模和分析方法:我们要给事物建造出一个“模型”,描述事物、事物的属性、事物之间的关系(静态的)以及各个事物之间的信息传递。现在流行的UML就是用图来表示软件的事物,人,用例之间的关系。但是代码的关键依然是用智慧解决计算机问题。

代码完成就是指工程师认为所有应该写的代码都写了,所有应该实现的功能都实现了(但未必没有问题)。但是这样的软件仍然不能发布,因为还有各种各样的bug,经过测试后将关键的bug解决后才可以发布bate版。

每日构建,是软件的必备,不构建就不能调试软件的,不能找出错误。这样会大大增加后期的问题。所有熟练度技术都是在实际操作中获得的。测试出来 的bug必须要 定时修复,不然可能会导致大的错误。小强地狱——让Bug多的队员专心修复Bug,不要开发新功能

第12章 用户体验

用户体验的要素:用户的第一印象:用户和软件的第一次使用,很大程度上决定了用户对软件的评价。怎样让用户在第一次使用的时候,少花时间(或者不花时间)在对用户没有价值的部分(如配置软件的基本设置、登录、填写用户的各种属性等),而把大部分时间花在有实际价值的功能。大胆的“减法”:从用户的角度考虑问题,这需要有“同理心”。软件团队的设计师和软件工程师有“同理心,什么是同理心?就是理解别人的处境、心理、动机的能力 。用户没有那么笨。

软件用得越多,越来越好用:软件要能记住用户的选择,习惯等等,让用户不再多次选择同样的东西。

不让用户犯简单的错误:软件要有对用户可能范的错误,进行预防。

评价标准:1. 尽快提供可感触的反馈系统状态2. 系统界面符合用户的现实惯例3. 用户有控制权4. 一致性和标准化5. 适合各种类型的用户6. 帮助用户识别、诊断并修复错误7. 有必要的提示和帮助文档

第13章 软件测试

    基本名词解释及分类:Bug:软件的缺陷2.Test Case:测试用例,测试用例描述了一个完整的测试过程,包括测试环境、输入、期望的结果等。3.Test Suite:测试用例集,即一组相关的测试用例。

Bug可以分解为:症状(Symptom)、程序错误(Fault)、根本原因(Root Cause)。

1)症状:即从用户的角度看,软件出了什么问题。例如,输入(3211)时,程序出错退出。

2)程序错误:即从代码的角度看,代码的什么错误导致了软件的问题。例如,代码在输入为某种情况下访问了非法的内存地址——0X0000000C。

测试设计有两类方法:黑箱(Black Box)和白箱(White Box)。所谓黑箱/白箱,是指软件测试设计的方法,不是软件测试的方法。测试的范围由小到大,测试者也由内到外——从程序开发人员(单元测试)到测试人员,到一般用户(Alpha/Beta测试)。构建验证测试是指在一个构建完成之后,构建系统会自动运行一套测试,验证系统的基本功能。在大多数情况下,这些验证的步骤都是在自动构建成功后自动运行的,有些情况下也会手工运行。伙伴测试(Buddy Test):开发人员可以找一个测试人员作为伙伴(Buddy),在签入新代码之前,开发人员做一个包含新模块的私人构建(Private Build),测试人员在本地做必要的回归/功能/集成/探索测试,发现问题直接与开发人员沟通。通过伙伴测试把重大问题都解决了之后,开发人员再正式签入代码。效能测试(Performance Test)用户使用软件,不光是希望软件能够提供一定的服务,而且还要求服务的质量要达到一定的水平。软件的效能是这些“非功能需求”或者“服务质量需求”的一部分。压力测试(Stress Test)压力测试严格地说不属于效能测试。压力测试要验证的问题是:软件在超过设计负载的情况下是否仍能返回正常结果,没有产生严重的副作用或崩溃

 

以上是关于构建之法阅读笔记05的主要内容,如果未能解决你的问题,请参考以下文章

构建之法阅读笔记05

《构建之法》阅读笔记05

构建之法阅读笔记05

构建之法阅读笔记05

构建之法阅读笔记05

构建之法阅读笔记05