• 鲁棒是Robust的音译，也就是健壮和强壮的意思。它是在异常和危险情况下系统生存的关键。比如说，计算机软件在输入错误、磁盘故障、网络过载或有意攻击情况下，能否不死机、不崩溃，就是该软件的鲁棒。所谓“鲁棒...

鲁棒是Robust的音译，也就是健壮和强壮的意思。它是在异常和危险情况下系统生存的关键。比如说，计算机软件在输入错误、磁盘故障、网络过载或有意攻击情况下，能否不死机、不崩溃，就是该软件的鲁棒性。所谓“鲁棒性”，是指控制系统在一定(结构，大小)的参数摄动下，维持其它某些性能的特性。根据对性能的不同定义，可分为稳定鲁棒性和性能鲁棒性。以闭环系统的鲁棒性作为目标设计得到的固定控制器称为鲁棒控制器。
计算机科学中，健壮性(英语：Robustness)是指一个计算机系统在执行过程中处理错误，以及算法在遭遇输入、运算等异常时继续正常运行的能力。 诸如模糊测试)之类的形式化方法中，必须通过制造错误的或不可预期的输入来验证程序的健壮性。很多商业产品都可用来测试软件系统的健壮性。健壮性也是失效评定分析中的一个方面。
这是我在PRML上截的一段话，说T分布比高斯分布有更好的鲁棒性
we see that Student’s t-distribution is obtained by adding up an infinite number of Gaussian distributions having the same mean but different preci-sions. This can be interpreted as an infinite mixture of Gaussians (Gaussian mixtures will be discussed in detail in Section 2.3.9. The result is a distribution that in gen-eral has longer ‘tails’ than a Gaussian, as was seen in Figure 2.15. This gives the t-distribution an important property calledrobustness, which means that it is much less sensitive than the Gaussian to the presence of a few data points which are outliers. The robustness of the t-distribution is illustrated in Figure 2.16, which compares the maximum likelihood solutions for a Gaussian and a t-distribution. Note that the max-imum likelihood solution for the t-distribution can be found using the expectation-maximization (EM) algorithm. Here we see that the effect of a small number of  Figure 2.16 Illustration of the robustness of Student’s t-distribution compared to a Gaussian. (a) Histogram distribution of 30 data points drawn from a Gaussian distribution, together with the maximum likelihood fit ob-tained from a t-distribution (red curve) and a Gaussian (green curve, largely hidden by the red curve). Because the t-distribution contains the Gaussian as a special case it gives almost the same solution as the Gaussian. (b) The same data set but with three additional outlying data points showing how the Gaussian (green curve) is strongly distorted by the outliers, whereas the t-distribution (red curve) is relatively unaffected. outliers is much less significant for the t-distribution than for the Gaussian. Outliers can arise in practical applications either because the process that generates the data corresponds to a distribution having a heavy tail or simply through mislabelled data. Robustness is also an important property for regression problems. Unsurprisingly, the least squares approach to regression does not exhibit robustness, because it cor-responds to maximum likelihood under a (conditional) Gaussian distribution. By basing a regression model on a heavy-tailed distribution such as a t-distribution, we obtain a more robust model.

展开全文
• 三、总结与展望     通篇介绍了通用性接口健壮性扫描的方案，基本能够自动化解决部分接口通用性问题，整个过程无需人工干预，节省了不少人工成本，提高了应用的健壮性等。主要表现在： 1.自动化获取基线用例 2....

一、背景
1.1 业务背景
随着公司业务的快速发展，需求越来越多、迭代越来越快，在有限的测试人员和时间投入的前提下，如何做好质量防控，如何提高测试效率，是大家持续思考的问题。
公司业务越来越复杂，应用越来越多，接口越来越多，接口的参数也越来越多，如何做好接口测试？如何做全接口的每一个参数的测试？
在测试过程中，测试人员主要面临以下问题：
测试人员都把精力放在核心的业务测试上。很少腾出时间来关注接口的各种参数类型的测试。接口越来越多、接口参数也越来越多，很难做到每个接口、每个参数的穷尽测试。针对接口参数设计的测试用例，用例数量通常都很多，如果只靠人工投入，会大大增加测试人员的时间成本，降低测试效率。测试人员核心关注点在正常的业务数据上，非正常业务数据相关的逻辑很少考虑周全，比如最大值、最长字符、特殊值等。
面对以上的问题，如果所有的测试都靠人工来完成，那将是很大的一笔人工和时间开销。是否可以自动化构造测试数据来自动化部分测试类型，将是本文解决的问题。
1.2 本文解决的问题
为了解决上述问题，本文介绍了通用性接口健壮性扫描方案。本方案也为质量保证、高效测试奠定了基础。
该方案重在忽略业务之间的差异，主要解决了以下问题：
建立通用的规则来生成测试用例解决通用性接口测试问题，比如边界值、最大值等全自动化生成、执行测试用例，整个过程无需人工参与，节约成本根据特定的产品规则，解决产品上的共性问题
二、系统设计
测试的执行过程一般分为三步：生成测试用例、测试用例执行、测试结果分析。通用性接口健壮性扫描主要围绕这三个过程展开。主要分为以下几个核心流程：
1.数据源数据拉取及处理：该步骤基于各种平台，比如网关、流量回放等，主要为了获取基线测试用例。2.用例规则模型建立与用例生成算法制定：制定通用性用例规则模型，同时也扩展了自定义用户规则模型，根据对应的算法，比如字段的Empty与非Empty，字段的NULL与非NULL，特殊值制定等比如字符型参数最长字符，数值型参数最大值、最小值以及通用性的特殊值等，生成用例数据。3.用例执行：根据基线测试用例，会获取到对应的服务、方法、测试环境。根据2的模型与算法，生成所有的用例数据，然后进行接口的调用及记录执行结果。4.结果分析：通用性接口健壮性扫描方案，对结果也是进行无业务逻辑的通用性的结果分析。这里包括结果规则模型的确定与结果分析，剥离出有问题的测试用例结果并自动反馈。
整体流程图如下：

2.1 数据源解析
整个设计的基础是基于基线测试用例。为了获取基线测试用例数据，需要建立数据源拉取策略。数据源来源于以下平台：网关平台、流量回放平台等。
网关层数据的数量巨大，如果拉取数据量过多，会导致拉取时间过长，很容易失败。同时如果多个应用或者多个线程同时拉取，很容易出现并发问题导致数据源拉取失败。
为了避免大量的无效数据源数据拉取，首先建立数据源数据拉取策略，争对性的拉取数据。同时为了避免数据量过多而导致拉取数据失败，设置了每30min拉取一次数据，如果本次拉取失败，则任务重试N次，成功则停止拉取，N次失败后在不在拉取。
获取数据源后，即可对数据源进行解析。通过数据源数据，解析出对应的应用、服务、参数类型、接口参数等，通过接口参数来获取基线用例数据。因为整个公司的应用很多，所以，根据配置策略，只解析在系统里配置过的应用数据，过滤掉没有配置过的应用的数据。下面是整个数据源的拉取与解析流程图。

网关平台的数据源只包含网关层的信息，并不能获取到后端的服务信息。我们的调用是基于dubbo服务的调用，所以还需要通过有赞网关平台，查询并获取到对应的dubbo服务的名称、方法、参数类型、返回值类型等信息。然后根据网关的参数，组装成dubbo服务的接口参数，最后把这些数据进行持久化存储。
为了丰富基础用例数据，后续会接入多种平台，获取更多的数据源数据。
2.2 用例数据生成算法模型
本篇文章的核心在于建立通用性用例数据生成的算法模型。核心流程如下：

首先建立基本的算法模型，主要包括基本的规则以及按照规则生成用例数据的算法。同时还扩展了用户自定义规则，根据用户自定义规则来生成对应的用例数据。
下面简单举例NULL规则生成的数据用例过程：
比如

class ParentObject{

Integer paattr1;

String paattr2;

SubObject paattr3;

}

class SubObject{

Integer sbattr1;

String sbattr2;

}

public RetType testMethod(ParentObject  parentObject){}

上述方法的基线用例为：

{
"paattr1":3,
"paattr2":"parentobjectnullcases",
"paattr3":{
"sbattr1":100,
"sbattr2":"subobjectnullcases"
}
}

根据NULL规则，会生成如下的测试用例：

用例1：
{
"paattr2":"parentobjectnullcases",
"paattr3":{
"sbattr1":100,
"sbattr2":"subobjectnullcases"
}
}

用例2：
{
"paattr1":3,
"paattr3":{
"sbattr1":100,
"sbattr2":"subobjectnullcases"
}
}

用例3：
{
"paattr1":3,
"paattr2":"parentobjectnullcases",
"paattr3":{
"sbattr2":"subobjectnullcases"
}
}

用例4：
{
"paattr1":3,
"paattr2":"parentobjectnullcases",
"paattr3":{
"sbattr1":100
}
}

上述的NULL规则用例生成具有很好的通用性。EMPTY规则生成和NULL类似。特殊值类型的规则制定，尤其是特殊值的制定，除了使用通用性的数据规则之外，如Double.MAX_VALUE，Integer.MAX_VALUE等，还可以使用业务上的通用性特殊数据。具体如何制定特殊值，需要根据业务来分析。
特殊值规则制定好之后，则根据参数类型，用指定的特殊值去替换，生成对应的测试用例。假设这里指定如下特殊值：Integer.MAX_VALUE与String.maxLength("AAA.........")。最后生成的用例如下：
用例1：
{

"paattr1":Integer.MAX_VALUE,
"paattr2":"parentobjectnullcases",
"paattr3":{
"sbattr1":100,
"sbattr2":"subobjectnullcases"
}
}

用例2：
{
"paattr1":3,
"paattr2":"parentobjectnullcases",
"paattr3":{
"sbattr1":Integer.MAX_VALUE,
"sbattr2":"subobjectnullcases"
}
}

用例3：
{
"paattr1":3,
"paattr2":"String.maxLength("AAA.........")",
"paattr3":{
"sbattr1":100,
"sbattr2":"subobjectnullcases"
}
}

用例4：
{
"paattr1":3,
"paattr2":"parentobjectnullcases",
"paattr3":{
"sbattr1":100,
"sbattr2":"String.maxLength("AAA.........")"
}
}
上述两种都是通用的规则算法，实际应用中远不止这些，有很多需要根据业务规则来确定规则模型。自定义算法模型就是根据用户自定义规则来生成对应的数据用例，增加了模型建立的灵活性。每个模型都有各自对应的生成算法，每个模型需要实现generateCases方法即可。总的获取所有模型用例算法流程如下：
public List<Cases> caseGenerate(){

for(AlgorithmModel  algorithmModel: algorithmModels){

baseCase = getBaseCase();

caseTmpList = algorithmModel.generateCases();

}

return cases;

}
2.3 用例执行
数据用例生成后，即可进行用例的执行。为了和数据源拉取任务错开，也是每隔30MIN执行一次，但是执行的时间段数据比日志拉取的时间早30min。比如数据源拉取时间为当前时间的前30min，则用例执行的时间为当前时间的前60Min。主要是为了避开数据源拉取任务的数据还没拉完，导致用例漏执行。具体执行流程如下：

根据算法模型生成的用例数据量一般都比较大，为了加速执行过程，采用多任务执行。服务调用可能会出现失败情况，如果失败，则根据补偿机制来重试，最终确保每个数据用例都能执行完成。补偿机制过程如下：

2.4 结果分析
通篇最难的是如何进行结果分析，即如何判断执行的结果是有问题的。主要有两种情况：1）返回success的接口实际上是错的不符合预期的；2）返回非success的接口实际上是正确的符合预期的。所以结果判断规则的制定特别重要，直接关系到结果判断的准确性，即整个方案的可行性。
目前争对方案能解决的问题，主要制定两种类型的错误提炼规则：一、判断错误提示不合理；二、判断后端执行结果不合理。
1) 错误提示不合理
问题背景：商家在使用我们的产品的时候，会报一些错误。但是有些错误，商家会看不懂，不明白其中的意思，比如下图的错误提示。

解决方案：为了解决此类问题，展示给商家的更友好的错误提示，提炼了错误提示不合理的规则，自动判断接口返回结果不符合规则的用例。
这种规则的前提是基于接口返回的结果是非success。如何确定呈现给商家的错误提示不合理，需要测试、开发、产品人员一起确定出来“什么样的提示规则是合理的、商家易理解的”。比如呈现给商家的错误提示遵循一定的格式，呈现给商家的错误文案里一定不能包括专业性的词汇、不能包括一连串的英文、数字、不能包括传参对象的属性名称，呈现给商家的错误提示文案必须是完整的一个句子等等。根据这些规则，制定代码提炼错误的规则，即可准确判断出接口错误提示是否合理。
2) 后端执行结果异常
问题背景：商家在使用我们的产品的时候，系统会出现不可预知的异常，这些异常都是代码逻辑错误导致的。这类异常提示一般都有明显的特征，比如服务器错误、业务异常、远程调用异常等。

解决方案：为了解决此类问题，抽取了几千条结果数据，这些测试数据基本覆盖了大部分的应用。争对这些数据，找出这类错误的结果提示，制定成一个规则集合。满足规则集合的则认为是有问题的用例。
这种规则的制定，需要采集各个应用的大量的结果数据，找出这类型错误的提示，加入到规则集合中。一旦抛出这种错误，我们就认定用例结果一定是异常的、不合理的。这种规则的集合，需要持续性的维护，并且需要制定好开发规范。后续开发遵循这种规范，不能随手拈来一个错误提示。
三、总结与展望
通篇介绍了通用性接口健壮性扫描的方案，基本能够自动化解决部分接口通用性问题，整个过程无需人工干预，节省了不少人工成本，提高了应用的健壮性等。主要表现在：
1.自动化获取基线用例2.自动化生成用例数据，这个数据量更丰富，数据更完善，基本能够覆盖所有场景的接口参数数据，做到穷尽测试3.自动执行用例，输出结果4.自动进行结果分析，判断出有问题的用例5.自动生成jira，自动推送给开发修复6.开发修复后可以人工点击重试，既可验证修复结果，无需重新构建用例，无需人工去调用。
此方案忽略了业务之间的差异，扫描出的是通用性的逻辑问题。对于结果分析，还存在一定的弊端。比如期望结果是非success的，但是返回的结果却是success的。这种还没有确定的规则去挖掘出这类型的问题。因此，后续还有无限的提升空间。
后续可以朝着这几个方向优化：
1）做到业务关联性     目前是忽略了业务的差异性，但是还有很多和业务相关的通用问题，暂时还无解决方案。是否可以建立业务关联性，来解决更多的问题。
2）结果精确性规则提炼     目前的规则制定，都是在有限的用例测试样例数据上提炼出来的。制定完善的规则，需要更多的测试数据来分析。同时，也需要良好的开发规范来保障后续提示遵守这个规则。这两者是相辅相成、相互促进、相互完善的。
3）解决“返回success的接口实际上是错的不符合预期的”问题     返回success的接口实际上是错的不符合预期的，目前这类问题还无法判断。
4）基线用例持续性完善
最初的基线用例数据可能只覆盖了大部分的参数，但是并不能保证覆盖到全部参数。因此基线用例的完善也是需要一个规则来持续性优化。
结合现在的设计，最终未来呈现出的方案会包括以下核心的流程：

最后打个小广告：

有赞新零售测试团队长期招人
期待你的加入～
如果你也是聪明、皮实、有要性的小伙伴 如果你对零售、SaaS有更多想法
欢迎投递简历：wangchenghui@youzan.com 加入我们，一起enjoy

或点击【阅读原文】投递简历
end


‍
‍‍
‍

展开全文
• 1.6.3 健壮性Web的多平台环境对程序有特别的要求，因为程序必须在各种系统中可靠地执行。因此，在设计Java时，使其具备创建健壮程序的能力被提到了高优先级的地位。为了获得可靠性，Java在一些关键领域进行了限制，...

1.6.3 健壮性
Web的多平台环境对程序有特别的要求，因为程序必须在各种系统中可靠地执行。因此，在设计Java时，使其具备创建健壮程序的能力被提到了高优先级的地位。为了获得可靠性，Java在一些关键领域进行了限制，从而迫使程序员在程序开发中及早地发现错误。同时，使程序员不必再担心会引起编程错误的许多最常见的问题。因为Java是强类型化的语言，它在编译时检查代码。当然不管怎样，在运行时也检查代码。许多难以跟踪的bug，在运行时通 常难以再现，这种情况在Java中几乎不可能产生。因为使编写好的程序在不同的运行条件下，以可预见的方式运行是Java的关键特性之一。 为了更好地理解Java是多么健壮，分析程序失败的两个主要原因：内存管理错误和未处理的异常(即运行时错误)。在传统的编程环境中，内存管理是一件困难、乏味的工作。例如，在C/C++中，程序员必须手动分配和释放所有动态内存。有时这会导致问题，因为程序员可能会忘记释放以前分配的内存，或者更糟糕的是，试图释放程序其他部分仍然在使用的内存。Java通过为您管理内存的分配和释放，可以从根本上消除这些问题(事实上，释放内存完全是自动的，因为Java为不再使用的对象提供了垃圾回收功能)。传统环境中的异常情况通常是由“除0”或“没有找到文件”这类错误引起的，并且必须使用既笨拙又难以理解的结构对它们进行管理。Java通过提供面向对象的异常处理功能在这个领域提供帮助。在编写良好的Java程序中，所有运行时错误都能够并且应当由程序进行管理。

展开全文
• 健壮性(Reliability)即便系统发生了某些错误(包括硬件故障，软件bug和人误操作等)，系统仍旧保持正常运行。对于一个数据系统而言，健壮性通常是指:整个系统的运行结果符合设计开发者的预期;可以在一定限度内容忍，在...

健壮性(Reliability)
即便系统发生了某些错误(包括硬件故障，软件bug和人误操作等)，系统仍旧保持正常运行。
对于一个数据系统而言，健壮性通常是指:
整个系统的运行结果符合设计开发者的预期;
可以在一定限度内容忍，在最大程度内避免操作人员的误操作;
系统的运行性能能够满足常见用户场景和预计数据吞吐量下的需求;
系统防止越权行为和其他的用户不合法操作;
...
上面这个列表显然不完整，一个健壮的数据系统需要面对不同用户在不同使用场景下的不同考验。满足上面列表里的要求可以简单看作是满足里“即便在某些条件不满足的情况下(例如部分服务器宕机、大量数据请求、存在恶意用户等等)，系统依旧可以运行”。所以，健壮性通常表现在系统容错(fault-tolerant)方面。也就是说在错误发生时候的处理机制而非尽力去避免错误的发生，为了演练处理机制的效果，有的时候甚至需要去主动触发错误(比如说Netflix著名的Chaos Monkeys)。当然，这并非说避免错误完全没有用(比如说设置登陆密码，密钥等措施防止恶意越权攻击等)。
可扩展性(Scalability)
在一定程度内的负载增长不会影响应用预期表现的能力。
描述负载：下面是Tweet中的一个例子(数据来自于2012年11月)。
Tweet中发推(Post tweet类似微博中发微博的操作)的动作频率是4.6k/s，峰值会超过12k/s。
Tweet中阅读时间线(Home timeline类似微博中阅读自己微博的操作)的动作频率会达到300k/s。
简单的12k/s的写入操作并不会带来太大的冲击(相对于tweet的服务器数量而言)，真正的挑战是：多对多的复杂用户关注网的情况。结合这种情况，有两种实施方式：
发推的动作就简单的往全局推文表里插入数据，当用户阅读时间线时，首先从关注关系表中获取该用户所有的关注人，再按关注人去推文表中获取所有推文，再按时间顺序将推文排序展示。这种方式最容易想到，实施起来也最方便:
SELECT tweets.*, users.* FROM tweets
JOIN follows ON follows.followee_id = users.id
WHERE follows.follower_id = current_user

常见关系数据库设计实现
为每个用户维护一个形如队列的缓存，就像是收件箱一样的作用：当有人发推的时候，同时将这条推文插入到发推人的所有关注者的队列缓存中，阅读时间线的时候直接拉取队列缓存。

队列缓存设计实现
在实际生产环境当中，tweet首先尝试使用第一种方法来实现，但是这种方式在用户读取时间线的时候可能会很慢(考虑到会有一个人关注许多人和一个人被许多人关注的情况)。
那么第二种方法有没有什么问题呢？第二种方法的问题在于在发推操作的时候还需要做许多额外工作：平均一条推文会被75个人在时间线中看到，所以4.6k/s的发推写入操作还需要附带有345k/s的队列缓存写入操作(考虑更极端的情况，有的人有将近1亿的关注者，也就是说，他的一次发推操作需要有将近1亿次队列缓存写入操作)。
权衡两种方式的利弊，tweet现有模式是：对于大多数用户采用方式2来提升阅读时间线的响应速度，对于拥有大量粉丝的人，采用方式1以减少大量的队列缓存写入操作。所以，在阅读时间线的时候，实际上是两种操作获取结果再合并的产物。
在可扩展性方面的尝试常常涉及到分布式系统(强烈推荐课程CS 6.824)方面的内容。
可维护性(Maintainability)
我们或多或少要和遗留系统打交道，而你负责的系统也总将作为遗留系统而被他人维护。
可运维(Operability)
系统不应当只是对于用户友好，对于开发者和运维团队而言也应该是友好的。
系统的运行维护需要做到以下几点：
对于系统内部的操作运行做监控；
减少外部系统强依赖；
人机交互友好，最大限度降低误操作可能，并有良好的文档；
有一定自愈功能；
最小惊喜原则，产品行为符合大多数人预期；

展开全文
• JDBC概述：就是提供了使用java程序连接，操作数据库的一系列的API，不同的数据库厂只要根据各自的JDBC API提供各自的实现即可。java 应用程序--->JDBC API -->JDBC 的驱动 --->数据库2....
• 专注分享Linux后台服务器开发，包括C/C++，Linux，Nginx，ZeroMQ，MySQL，Redis，fastdfs，MongoDB，ZK，流媒体，CDN，P2P，K8S，Docker，TCP/IP，协程，DPDK等等健壮性:健壮性具体指的是系统在不正常的输入或不正常...
• 系统健壮性设计 代码评审 烂代码 如何评估你将要面对的代码是否是一堆烂代码，可以从以下两个方面评估 人的视角： 维护者脏话的频率高，且内容丰富； 存在动粗的可能性 面向离职编程 代码的视角： 不遵守代码...
• 概念：健壮性测试（Robustness Testing）又称为容错性测试（Fault Tolerance Testing），用于测试系统在出现故障时，是否能够自动恢复或者忽略故障继续运行。 内容： 对关键进程或线程杀死，然后观察系统行为； 对...
• 功能测试。即测试软件系统的功能是否正确，其依据是需求文档，如《产品需求规格说明书》。...健壮性测试。即测试软件系统在异常情况下能否正常运行的能力。健壮性有两层含义：一是容错能力，二是恢复能力 ...
• 参考资料：http://blog.csdn.net/io_field/article/details/52189972一、Monkey测试原理：Monkey是Android中的一个命令行工具，可以运行在模拟器...Monkey测试是一种为了测试软件的稳定性、健壮性的快速有效的方法。...
• 如何保持自动化脚本的健壮性 使用robotframework编写自动化脚本，如何保持脚本的健壮性是一个值得深入思考的事情，依据本人经验，特总结了几点。 1、wait系列 最常用的是Wait Until Element Is Visible，其实还有...
• 代码健壮性： 处理异常的代码.首要追求健壮性. 就是程序必须能从异常中自我恢复.由于代码多数时间跑的是"正常"逻辑,少数情况下才不得不处理"异常",所以"异常"处理的代码中,首要任务是健壮,跑不死,而高效性则是次要的...
• 请完成下列Java程序：建立一个Applet程序，包括创建一个画布构件、一个面板构件，面板构件上包含3个按钮，用来设置画布和面板的背景颜色，这3个按钮(Red、Green、Blue)分别控制画布和面板背景色改变为3原色，即红、...
• 浅析软件测试的强弱和健壮性
• 增加程序健壮性有两个办法： with open 上下文管理器 with open('a.txt',encoding='utf-8')as file2: data = file.read() 异常处理 异常也是一个类 异常捕获过程： 异常类把错误消息打包到一个对象 然后该对象会...
• 知识点 组件是如何分类的 Vue 和 React 封装组件模式 怎样才是一个好的可扩展、通用的、健壮性组件 思考讨论，提出问题 组件是如何分类的 业务组件 通用组件（非业务组件） UI组件 1627627583874_8398E85B-D83D-430...
• ## app健壮性测试

千次阅读 2021-12-14 17:10:25
app健壮性测试
• 健壮性与鲁棒性 系统的健壮性指系统在1.异常情况下、2.特殊环境、3.超时情况 系统依然能稳定运行的能力 鲁棒性:形容词robust:强健的，强壮的，耐用的，坚固的，富有活力的。 健壮性与鲁棒性是否一样? 应该是一样的...
• java代码性能优化，提高健壮性骐骥一跃，不能十步；驽马十驾，功在不舍。提高代码的质量，优化性能，贵在坚持！如果用功去清除代码的“坏味道”，并坚持做好积累，不仅能提高自己的编码水平，也能使代码变得"精白无...
• 文章目录面向正确性与健壮性的软件构造健壮性正确性Error类一些典型错误Exception类Runtime异常其他异常Checked异常、Unchecked异常Checked异常：Unchecked异常：总结Checked异常的处理机制 面向正确性与健壮性的...
• 系统健壮性设计 1.entity作为传入的参数，不单要进行非空校验，而且要进行具体参数的校验， 2.根据id查询获得users对象，要判断users是否为空 3.注释//生成用户列表 很模糊，要注释成为 生成属于这个角色的...
• 要明确各状态下收到该通知时处理的妥当，并且明确这些设计。 需要考虑起动处理时各模块消息的同步问题。例如，优先级高的A模块启动后，发送消息给后B模块，考虑如果此时B模块未启动的处理情况。 对于Backup的数据...
• 目录代码评审烂代码健壮性和鲁棒性构建健壮性系统负载均衡容灾能力数据健壮性代码健壮性失败的架构思维混沌工程 代码评审 烂代码 人的视角 维护者脏话的频率高、维护者脏话的类型丰富、存在打架斗殴的可能性、面向...
• 一：概述 1.测试中会执行的场景： 在测试前端（APP、RN）页面时，除了功能以外，还会考虑数据返回不同内容后前端是否可以正常展示，例如：后台返回正常数据（1条内容、多条内容、带筛选项、带搜索内容、订单（待支付...
• 针对公司app的健壮性测试之前一直是使用monkey，后面发现了字节开源的fasbot_android 故上手测试一下，整体使用感觉不错 记录一下使用的过程 开源地址：https://github.com/bytedance/Fastbot_Android 1.首先...
• 系统的健壮性设计（四） 面向失败设计 测试健壮性 分支覆盖 混沌工程 混沌原则 混沌工程的流程
• 代码中 "健壮性" 的理解 所有源码中都会有一堆健壮性处理 健壮性：代码在出现预期之外错误情况下的应对能力。 就好比如我们身体很strong，但是不代表我们不会生病，只要我们身体够strong，即使生病了也能快速抵抗...
• 健壮性更多相关问题一些农村父母外去打工，留在家里的孩子有的不上学，有的上网，有的贪玩在水里溺死2012新疆一级建造师考试成绩查询时间？2012新疆一级建造师考试合格标准及证书申领要求？2012陕西一级建造师考试...

...