huayuQA的博客

在开始讨论这个话题之前，我想先举一个真实的例子:   有一对夫妻住在同一个房子里， 但相互之间不沟通,或者说他们之间没什么好沟通的。 他们只有在重大事情发生的时候才用简讯沟通。 否则他们都太忙于自己的生活， 也没有时间去打扰（照顾）对方。 长年累月下去会发生什么？ 一次挫折、些许挫折、表面的愤怒、一次爆发就会发生。 只有更多的沟通、更少的争执、一些认同和相互之间的鼓励才能使一段关系更加稳固。

REST是什么？REST架构方式描述了六种设计准则。这些用于架构的设计准则，最早是由Roy Fielding在他的博士论文中提出并定义了RESTful风格。（详见http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm）六个设计准则分别是： - 统一接口 - 无状态 - 可缓冲 - C-S架构 - 分层系统

资源命名除了适当地使用HTTP动词，在创建一个可以理解的、易于使用的Web服务API时，资源命名可以说是最具有争议的和最重要的概念。当资源被很好的命名，这个API是非常直观并且易于使用的。如果命名的不好，同样的API会感觉很笨拙并且难以使用和理解。下面是一些当你需要为你的新API创建资源URL时的小技巧。从本质上讲，一个RESTFul API最终是简单URI的集合，HTTP调用这些URI、JSON或

REST快速提示（根据上面提到的六个原则）不管在技术上是不是RESTful的，这里有一些类似REST概念的建议。遵循它们，可以实现更好、更有用的服务：使用http动词表示一些含义任何API的使用者能够发送GET、POST、PUT和DELETE请求，它们很大程度明确了所给请求的目的。同时，GET请求不能改变任何潜在的资源数据。测量和跟踪仍可能发生，但只会更新数据而不会更新由URI标识的资源数据。合理的

返回表征正如前面提到的，RESTful接口支持多种资源表征，包括JSON和XML，以及被封装的JSON和XML。建议JSON作为默认表征，不过服务端应该允许客户端指定其他表征。对于客户端请求的表征格式，是否使用文件扩展名风格格式、query-string参数等来组成Accept 头，这是个问题。理想情况下，服务端可以支持所有的这些方法。但是，现在行业内更倾向于使用一种类似文件扩展名的格式说明。因此，

定义幂等性毫无疑问，这与听起来的正好相反，这些与某些功能紊乱的领域无关。来自维基百科： 在计算机科学中，术语幂等用于更全面地描述一个操作，一次或多次执行该操作产生的结果是一致的。根据应用的上下文，这可能有不同的含义。例如，在方法或者子例程调用具有副作用的情况下，意味着在第一调用之后被修改的状态也保持不变。从REST服务端的角度来看，由于操作（或服务端调用）是幂等的，客户端可以用重复的调用而产生

查询，过滤和分页在大数据集方面，从带宽的角度来说，限制返回的数据量是很重要的。而从UI处理的角度来说，限制数据量也同样重要，因为UI通常只能展现大数据集中的一小部分数据。在数据集的增长速度不确定的情况下，限制数据默认返回量是是很有利的。以推特为例，要获取某个用户的推文（根据个人主页的时间轴），在请求没有特别指定的情况下将只会返回20条记录，尽管系统最多可以返回200条记录。除了返回数据量的限制外，如

服务版本管理通过内容协商支持版本管理以往，是通过URI本身的版本号来完成版本管理的，客户直接在他们请求的URI中表明他们想要的资源的版本号。事实上，许多“大人物”如Twitter、Yammer、Facebook、Google等经常在他们的URI里使用版本号。甚至API管理工具（如WSO2）在暴露的URL里要求版本号。面向REST原则，版本管理技术飞跃发展。因为它没有拥抱HTTP规范中内置的头部系统，

HTTP动词Http动词的主要遵循“统一接口”规则，并提供给我们对应于基于名词的资源的动作。最主要或者最常用的http动词（或者方法，正如它们被恰当地如此称呼）有POST、GET、PUT和DELETE。这些分别对应于创建、读取、更新和删除(CRUD)操作。也有许多其他的动词，但是使用频率比较低。对于使用较少的方法OPTIONS和HEAD使用得比其他动词更经常些。GET使用http的GET方法来检索（

本文主要读者该最佳实践文档适用于对RESTful Web服务感兴趣的开发人员，该服务为跨多个服务的组件提供了较高的可靠性和一致性。按照本文的指导，可快速、广泛、公开地为内外部客户采用。本文中的指导原则同样适用于工程师们，他们希望使用这些依据最佳实践原则开发的服务。虽然他们更加关注缓存、代理规则、监听及安全等相关方面，但是该文档能作为一份涵盖所有种类服务的总指南。另外，通过从这些指导原则，管理人员了解

安全服务器确认给定的请求是从服务已知的某人（或者某个系统）给出的，且请求者是他自己所声明的那个人，这样的过程叫做认证。然而授权却是去确认请求者得到了执行被请求的操作的允许。本质上，这个过程是像这样的：客户端发出一个指令，在X-Authentication头中包含认证令牌，或者在请求中包含令牌查询串参数。服务器证实了授权令牌的存在，使其生效（有效且未过期），并且基于内容去分析或者加载认证主体。服

缓存和可伸缩性通过支持系统层级消除检索请求数据的远程调用，缓存提高了系统的可扩展性。服务通过在响应中设置头标志来提高缓存能力。不幸的是，缓存相关的头在HTTTP1.0中与HTTP1.1中不同，因此服务器要同时支持两种版本。下表表示的是支持GET请求缓存的必要最小头集合，并带有适当值的描述。 Http头文件 描述 例子 Date 响应返回的日期和时间（RFC1123格式）。 Da

HTTP状态码以下是大多数由RESTful服务或API返回的常用HTTP状态码，并带有它们普遍用法的简短总结。其他HTTP状态码偶尔使用，但是更专业或更先进。多数服务套件只支持这些常用的状态码，甚至只支持子集，从而维护良好。200 (OK) – 通常的成功状态。表示成功的最常见代码。201 (CREATED) – （通过POST或PUT）产生成功的创建。 设置定位头，以存储指向最新创建的资源的链接。

附加资源书籍RESTful API设计规则： REST API Design Rulebook，Mark Masse, 2011, O’Reilly Media, Inc.RESTful Web服务： RESTful Web Services, Leonard Richardson and Sam Ruby, 2008, O’Reilly Media, Inc.RESTful Web服务食谱：

定义幂等性毫无疑问，这与听起来的正好相反，这些与某些功能紊乱的领域无关。来自维基百科：在计算机科学中，术语幂等用于更全面地描述一个操作，一次或多次执行该操作产生的结果是一致的。根据应用的上下文，这可能有不同的含义。例如，在方法或者子例程调用具有副作用的情况下，意味着在第一调用之后被修改的状态也保持不变。从REST服务端的角度来看，由于操作（或服务端调用）是幂等的，客户端可以用重复的调用而产生相同的结

REST快速提示（根据上面提到的六个原则）不管在技术上是不是RESTful的，这里有一些类似REST概念的建议。遵循它们，可以实现更好、更有用的服务：使用http动词表示一些含义任何API的使用者能够发送GET、POST、PUT和DELETE请求，它们很大程度明确了所给请求的目的。同时，GET请求不能改变任何潜在的资源数据。测量和跟踪仍可能发生，但只会更新数据而不会更新由URI标识的资源数据。合理的

修订记录 日期 版本 描述 2012.02.10 初稿 初始版本。 2012.04.24 v1.0 最初正式（非草稿）版本。 2012.05.29 v1.1 从API最佳实践任务组获得反馈后，修改了部分拼写错误和不当用词。 2012.08.02 v1.2 更新版本信息，修改了部分拼写错误和不当用词等。本文主要读者该最佳实践文档适用于对RES

在软件项目中，最重要的就是测量质量，成本， 项目和流程的有效性。如果没有测量，项目不能算真正的完成。 这篇文章，我们将会结合例子和图表—学习软件测试度量和测量指标以及怎样在软件测试流程中使用它们。   这里有一句名言：“我们无法测量我们不能控制的东西”。  其中， 可控制的项目指

计算指标的定义和公式：1.测试用例执行的百分比：这个指标是用来获取测试用例的执行状态的百分比。 用例执行百分比=（执行的用力个数/总的用例个数） *100所以从上面的数据可得， 用例执行百分比=（ 65/100） *100=65%2.没执行用例的百分比：这个指标是用来获取待测试用例的执行状态的百分比。 未执行的测试用例的百分比=（未执行用例/总的用例个数） *100所以从上面的数据可得， 中

发表于2013年3月26日  这篇文章是我和迈克尔·波顿共同撰写的。我们几乎每一句话都花了好几个小时去讨论。同时感谢伊恩麦科华特做的快速审查和注解。   测试和工具的使用是人类起源时就带有的2个特性（虽然不是只有这2个特性，但一定是人类许多特性中的其中2个）。 然而测试依赖头脑又有不确定性，所以工具的使用会比较开放。工具渗透进每一个接触到的领域并改变了这些领域。因此，几百上千年来引起我们更多

许多公司都在尝试建立一种工作流程，这种工作流程能使得测试人员即使在匆忙之中仍知道如何开始、进行并结束测试工作，这种现象在中小型企业中尤为常见。   项目经理和测试经理尝尝迫使测试团队尽快完成任务，在这种压力下， 有的人采用系统化的方法来执行测试工作但无法完成任务；有的人想利用捷径快速执行测试工作但质量没有保障。因此，这成为了工作中的一道难题。   本文将从实际出发出一些具体的解决方案。快捷

测量开发速度  你想知道在当前迭代版本中自己的表现如何吗？常用的方法就是通过燃尽图来看：   上图中有五天的工作时间，假设我们能完成该迭代版本中的十个关键功能点。图中的每个点的数值代表每天结束时待完成的需求。绿色线表示一种理想的状态：每天都固定完成两个功能点。而红色线则表示我们实际工作完成情况，或者说是真实的开发速度。   这幅图并不是在任务板上的图片，但我们团队通常会拿A4纸为每

任务板  我记得有天早上：我到达办公室时,却发现我们的scrum 负责人准备了一个临时任务板、A4纸、透明胶带。我不知道他在做什么。与往常的每天早上一样,我准备了一壶咖啡,就只是等着看。   当完成时,一个白色的板被放置在墙上。它有几个列,演变成一个矩形。几个彩色的便签布满在看板上。“那已经是两年前的事了。   这个看板呈现出我们现在所使用的精益管理流程。记住,敏捷是改变和适应变化

Scrum是最经常使用的一种敏捷技术。它不是编码相关的;相反,它更侧重于组织和项目管理。如果你有空,让我告诉你关于我所工作的团队,和我们团队如何采用Scrum技术。一个小故事Scrum的根源实际上早于敏捷时代。  Scrum的根源实际上早于敏捷时代。第一次提到这种技术可以追溯到1986年,由 Hirotaka Takeuchi 和 Ikujiro Nonaka为商业产品开发所提出的

6. 限制规则  如在第4节D段提到的： RERAM可以回放Google Play（谷歌应用版） 中前100的应用中的86个。然而, 仍然有14款应用我们无法回放。这些应用可以分为两类: 请求 Android 传感器服务类和包含动态或随机元素类（如图表6中显示的元素）。我们现在来讨论下它们不能回放的原因有哪些：  请求 Android 传感器服务：一些需要传感器输入的应用RERAM不会记录。比如我们

3. 方法概述  本章节主要介绍技术以及该方法优于其他录制回放工具的关键点。谷歌提供了Android软件开发工具包（SDK），包含各种工具来帮助应用程序开发人员开发、测试和调试。RERAN的开发也用到该工具。   如图4展示的高级视图，可在手机上通过安卓终端模拟器（android app市场下可下载）录制回放，也可从一台计算机通过USB连接到手机来实习录制或回放。Android调试桥（ADB），通

4. 实现细节和性能  本节提供RERAN的细节实现和环境配置,以及评估其性能。A. 物理设备  用于开发回放工具的Android设备是摩托罗拉Droid仿生手机,双核的ARM cortex - a9 1 ghz的处理器。手机发布于2011年9月8日，Android版本2.3.4，Linux内核版本2.6.35。B. 测试环境  没有蜂窝服务;因为没有使用与它相关的操作,如发短

2. Android 输入  本节中，我们将介绍Android应用不同类型的输入，以及它们是如何以事件的形式展示给用户看。  A. 用户触摸屏操作   智能手机应用程序的区别有部分是用户通过触摸屏进行的操作引起的不同表现。我们简要描述几个常见的：  按下-释放（点击）：主要的输入是简单的按压，也就是用户轻敲屏幕并快速的放开，例如：点击一个按钮或点击屏幕上的键盘进行输入文本   按下

5. 回放功能  已经有无数的程序可以回放记录。在本节，我们阐述几个场景关于REMAN的记录和回放如何有利于开发者和研究人员。A. 通过轨迹回放的重复性  RERAN可以以完全相同的方式回放一组特定会话的输入事件就像一开始记录的那样。相比之下，如果一个用户手动的重复一个会话企图去重复先前的相同操作，由于人为的误差和不一致的运行时间，和原先的操作相比可能会存在不一致和异常。这可能会导致不

REST是什么？REST架构方式描述了六种设计准则。这些用于架构的设计准则，最早是由Roy Fielding在他的博士论文中提出并定义了RESTful风格。（详见http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm） 六个设计准则分别是：统一接口无状态可缓冲C-S架构分层系统按需编码以下是这些设计

日期/时间处理如果没有妥善地、一致地处理好日期和时间的话，这将成为一个大麻烦。时区问题总是能轻易发生，并且由于日期在JSON中只是字符串的，所以如果格式是未知的、不一致的、未指定的，那么分析日期便成了一个问题。在接口内部，这些（时间的）服务应该被存储、运行和缓存，例如UTC或GMT时间戳。这将减轻日期和时间上的问题。Body内容中的时间序列化有一个简单的方法可以解决这些问题–在字符串中始终用一些相同