起一个好名字，意味着赋予事物一个承载意义、期望与身份的符号，并借此为其未来的发展铺设一条充满可能性的道路。它不仅仅是一个称呼，更是一种深远的祝福、一个无声的预言、一个身份认同的起点，其象征未来的意义体现在以下几个方面： 1. 承载期望与愿景： 个人： 父母给孩子取名，往往寄托着对孩子未来的期望（如“志远”、“嘉慧”、“安然”）、对品德的期许（如“仁杰”、“守信”、“思齐”）、对人生状态的祝愿（如“乐康”、“欣悦”、“安宁”）或对家族传承的延续（如特定的字辈、纪念先祖）。 企业/品牌： 一个好的公司或品牌名称，需要体现其核心价值（如“诚信”、“创新”）、市场定位（如“高端”、“亲民”）、行业特性（如“迅捷”、“稳健”）以及未来的发展蓝图（如“环球”、“未来”、“领航”）。 项目/活动： 名称需要清晰传达项目/活动的目标（如“曙光计划”、“春风行动”）、核心理念（如“和谐共生”、“智慧未来”）以及想要实现的积极影响。 2. 塑造第一印象与身份认同： 名字是“第一张名片”： 一个恰当、响亮、富有内涵的名字能迅速在他人心中建立积极的初步印象，激发好奇心和好感度。这为未来的互动和关系建立打下了基础。 定义身份核心： 名字是个人、组织或事物最核心的身份标识。它帮助确立“我是谁”、“我们代表什么”。一个强大的名字能强化内部成员的归属感和自豪感，也帮助外界快速理解其本质。 3. 蕴含潜力与可能性： “名正则言顺”： 一个寓意积极、方向明确的名字，仿佛为未来的发展指明了一个方向。它像一个无形的灯塔，引导着个体或组织朝着名字所蕴含的美好愿景努力。 激发内在动力： 一个充满力量和希望的名字，本身就能对拥有者（人或组织）产生积极的暗示和心理激励，鼓励其努力去“配得上”这个名字所代表的品质和未来。 4. 象征连接与传承： 连接过去与未来： 名字常常承载着历史（家族姓氏、文化典故）、当下（时代特征、父母心境）和对未来的展望。它像一个纽带，连接着起源和归宿。 建立情感纽带： 一个被用心赋予、饱含深情的名字，能建立起拥有者与命名者（如父母与孩子）之间深厚的情感联系。这份情感是未来关系的重要基石。 传承价值： 名字中蕴含的价值观（如勇敢、智慧、仁爱）或精神（如探索、坚韧、合作）是希望在未来得以延续和发扬光大的。 5. 在市场中建立差异化与价值： 品牌资产的核心： 在商业领域，一个好的名字是品牌最核心的无形资产之一。它帮助在拥挤的市场中脱颖而出，建立独特的品牌形象，承载品牌承诺，并最终影响消费者未来的购买决策和忠诚度。一个有远见的名字能为品牌未来的价值增长奠定基础。 总结来说，“起一个好名字意味着什么，象征着未来”的核心在于： 意味着： 深思熟虑地注入期望、定义身份、赋予意义、建立连接、并期望其成为未来发展的重要助力。 象征着： 一个充满希望的起点、一个有待实现的蓝图、一种无形的引导力量、以及一份承载着祝福与责任的传承。 它是对未来潜力的一种具象化表达和积极召唤。 因此，起名绝非随意之举，而是一项面向未来的、充满创造力和责任感的仪式。一个好的名字，如同一颗精心挑选的种子，蕴含着破土而出、茁壮成长、最终绽放出美好未来的无限可能。它既是当下的承诺，也是通往未来的第一声回响。

店名测试打分免费测试？店名测试打分免费测试吉凶！

投稿用户 • • 周易起名 • 阅读 416
宝宝取名 公司取名 商标取名 立即取名 店铺取名

朋友们，我来了~

今天这一章还是讲测试，基于属性的测试（Property-Based Testing）。其实我感觉叫随机验证测试更通俗易懂一点。

我们日常自己测试的时候，会有一个问题，就是我们既是裁判，也是球员。因为我们的程序就是顺着我们的思路写的，测试也是按照同样的思路来测试的。所以，我们可能通常很难测出我们自己写出来的bug。

解决这个问题的一个办法，就是把测试交给其他人。这也是测试这个岗位存在的意义之一。但是，如果我们把测试交给了其他人，上一章提到的，对测试的思考可以帮助更好地设计程序，这个好处就不存在了。

基于属性测试

解决这个问题的办法就是，把其他人，换成我们的计算机，让计算机来帮我们自动测试。

之前关于契约或者合约（Contract）那一章中，提到了要给程序制定一个合同，规定了输入的规则、输出的规则、以及不变量（比如给一个数组排序，进去和出来的数组长度应该是不变的）。

那么合约和不变量在这里统称为属性（property），很抽象是不是？个人觉得它的定义并不重要，举个例子就懂了。

比如我们要验证一个list的排序，我们可以验证这两件事：1.输入和输出的list长度是否相等；2.是不是list里的每一个都比它前面一个大。

用python写出来就是这样：

from hypothesis import given
import hypothesis.strategies as some

@given(some.lists(some.Integers()))
def test_list_size_is_invariant_across_sorting(a_list):
original_length = len(a_list)
a_list.sort()
assert len(a_list) == original_length

@given(some.lists(some.text()))
def test_sorted_result_is_ordered(a_list):
a_list.sort()
for i in range(len(a_list) – 1):
assert a_list[i] <= a_list[i + 1]

更重要的是，它利用了hypothesis这个模块，@given(some.lists(some.integers()))会让它在运行的时候，利用随机的数值把同样的方法运行100次。它会把出现错误的情况记录下来。

对数器

之前在学习算法的时候，也接触到了一个叫做对数器的概念，其实和这里的基于属性测试，基本上是一件事情。

就是为了验证我们的算法A写对了，我们先写一个绝对正确的算法B，不管效率，只管正确。然后用同样的数据同时跑算法A和算法B。当然也是随机跑很多次啦。如果两个出现了不同的结果，那就说明算法A写错了。

思路基本相同，只不过，相对来说，可能这个基于属性测试更严谨一点，比如，同样是排序算法，我用我写的冒泡排序算法来验证我的选择排序算法，万一，我的冒泡排序也写错了呢？但是，如果我直接从根本上解析出排序（正序）就是后一个比前一个大，显然是更不容易出问题的，其实也能更进一步地锻炼我们寻找根本问题的能力。

当然啦，严格意义上来说，比较后一个比前一个大，这个本身也是一种算法。

实话说，要思考清楚有哪些属性是要测试的，这件事本身就充满了难度。如果你平时没有这个习惯，突然让你想，你会大脑一片空白的，就像是刚学编程那会，遇到了一个需求完全不知道从哪里下手的那种感觉。坦白的说，我现在就是这种状态，想必这也是需要刻意练习的。

这种随机大量测试的方式，可以帮助我们测出一些边界值，测出一些我们想不到的情况。往往最容易出问题的地方也是在边界值的地方。就跟开车似的，车开起来了，通常都没什么问题，但是起步可能会熄火，停车可能会倒不进去。

Java的相关框架

关于这个基于属性测试的框架，我随手搜了一搜，Python有的，没理由咱们Java没有，对不对？

一、找到两个github上开源：

1.https://github.com/HypothesisWorks/hypothesis-java

2.https://github.com/quicktheories/QuickTheories

二、找到一个都已经有自己网站的（虽然也有github）：

https://jqwik.net/

三、还有一个直接是JUnit家的JUnit-Quickcheck（感觉上这个更香一点）

https://github.com/pholser/junit-quickcheck

我还没来得及仔细研究，朋友们可以先自行研究起来~

另一个实例

书中其实还提到了另外一个更加实际一点的例子，但我个人觉得那算不上bug，它和实际的需求有关系。这边简单提一下吧，或许你也有不同的见解。

大概就是有一个仓库类，它可以存放各种货品，不同货品有各自的数量，大概是这样一个结构吧：List<Map<String,Integer>>。然后我们可以查询某个货品是否有库存、查询某个货品还剩多少库存、可以从中取出某个数量的货品。

代码如下：

class Warehouse:
def __init__(self, stock):
self.stock = stock

def in_stock(self, item_name):
return (item_name in self.stock) and (self.stock[item_name] > 0)

def take_from_stock(self, item_name, quantity):
if quantity <= self.stock[item_name]:
self.stock[item_name] -= quantity
else:
raise Exception("Oversold {}".format(item_name))

def stock_count(self, item_name):
return self.stock[item_name]

仓库的初始化是这样的：

wh = Warehouse({"shoes": 10, "hats": 2, "umbrellas": 0})

然后，同样用了hypothesis来做批量测试，然后在调用take_from_stock( item_name='hats', quantity=3)这样一组数据的时候报错了。

作者说，在in_stock我们不应该只判断库存是不是大于0，而是要判断它有没有包含我们要拿取的货品数。代码应该改成这样：

def in_stock(self, item_name, quantity):
return (item_name in self.stock) and (self.stock[item_name] >= quantity)

反正我是觉得这不算个bug吧，毕竟在真正获取货品的时候，就报错了呀。要看我们对于in_stock这个方法本身的要怎么定义咯，是只需要知道它还有没有库存，还是需要知道它有没有我需要的库存。

虽然实际需求中，后者可能性更大，但是在take_from_stock方法里报错，又有什么问题呢？（又或者，作者只是想举个例子，是我太较真了）

尾声

基于属性的测试是对于单元测试的补充，对于单元测试的思考，可以让我们思考代码实现的其他方式。基于属性的测试，可以让我们更加清晰，我们的方法能干什么不能干什么，同时，也消除一些意外的情况。

如果，你还没有把这两种测试用起来，现在就赶紧用起来吧~

本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 673862431@qq.com 举报，一经查实，本站将立刻删除。
如若转载，请注明出处：https://www.bbqim8.com/archives/25944
赞 (0)
投稿用户
0
上一篇 2022年11月19日 am8:29
下一篇 2022年11月19日 pm12:29

相关推荐