这个应该是字体库没有下载到。你用 chrome 的 dev tools（F12 那个）看看有那个请求没有成功？

解决方法，可以试试清空缓存让它重新下载。

不好意思，没有这么做过，不是很清楚。建议你单独发一个贴询问下，或者自己尝试一下？

飞哥 v5 ！身体好点了吗？

好赞

好方法，有些低端手机确实容易过充。买个试试。

单个反斜杠表示转义，需要双反斜杠表示反斜杠。

建议先看下 python 简明教程，熟悉一下一些基础概念，要不磕碰会比较多。

@Robert.jiang 转一下微信公众号上一位热心同学的留言：

我也想学习下怎么将报表自动化测试，请问一下您这个代码，我可以将我的条件，按照这个参数文件来编写代码即可吗？请问如果刚拿到一个报表，怎么样从头开始搭建呢？求指教

请问需要添加哪些类啊，求完整代码，谢谢

我还在想前面读取数据库数据，到这里循环查询，怎么去执行？

这个是 bootstrap 自带的样式，直接调 css 会和它本身的响应式布局设计有所冲突，现在的改法都是在宽度不足以显示全部内容的时候，隐藏部分不重要的内容。

@Lihuazhang 已重新提交 pr ，麻烦审核下：
https://github.com/testerhome/homeland/pull/70

经确认，问题还没修复，宽度为 768-992 px 时会出现 2 行，重启讨论。

你说的对，确实应该交由提交 bug 的同学关闭是最合适的。我已经重开了那个帖子的讨论了。

这次是我们疏忽了，本地测试时导航栏内容和线上有些差异，所以有一种场景还是存在问题，当宽度为 768-992 的时，宽度不足以在一行内显示完毕所有内容，出现双行。

目前已经在修复中，修复提交后我会在原来 bug 的帖子里回复一下。

PS：帖子作者本身应该也是可以重开讨论的，在右侧导航栏有个 “开启” 按钮，点击即可开启讨论。

飞哥每周一篇，好有毅力，佩服。

最近开始用一个国内开源的 easy_mock ，感觉功能也挺不错的，建议楼主可以试用下，看能不能找到一些灵感。

今天深圳金融沙龙刚好有一个 topic 关于接口用例设计的，我引用过来下：

模型：

• 可靠性：参数容错、异常状态修复（timeout 或死锁）、CAP（分布式系统一致性）
• 功能性：业务功能、幂等（多次及并发调用结果一致）、事务测试、共享数据线程安全
• 易用性：设计（粒度合适、restful 需要关注风格及 get、head 方法安全，不修改资源）、错误提示（无堆栈）、文档
• 安全性：XSS、CSRF、加密、SQL 注入、错误信息脱敏
• 单接口性能：并发响应时间、资源耗用（例如通过资源分页降低资源耗用）、非并发响应时间

检查点：

• 返回值及返回码的正确性
• 数据库对应表信息是否一致
• 中间件及关联系统的状态和数据

另，我目前还没见过专职的接口测试工程师，服务端测试工程师倒是见过，但工作内容肯定不仅是接口测试。

我觉得你想搜集的这些点，第 1、2、3、4 点，应该到开发、产品、老板聚集社区里问比较合适。

最后一点，个人觉得测试工程师还可以推动质量前移和后移。前移比如参与技术方案设计、代码 review 、单元测试把关；后移比如线上数据监控及预警、线上巡检、线上异常集中点分析及推进改进方案。

只要和质量搭边的，都可以去做。质量不是测出来的，是设计和持续改进出来的。

额，这个有点误导呀。stf local 主要是便于开发调试用的便捷启动命令，正式环境应该要逐个逐个组件部署，才能做到高可用且具备良好的伸缩性：https://github.com/openstf/stf/blob/master/doc/DEPLOYMENT.md

题目说的是 “正确搭建方式”，内容却都是开发用的便捷命令，公司账号体系接入、多电脑设备支持也没提到，感觉不大对。。。

如果你有多个环境，或者频繁需要启用一个临时环境时，用 docker 维护起来方便很多，也更容易确保环境配置的一致性。docker 本身的一个目标是开发、测试、生产都采用相同的配置，减少因为环境差异（如服务版本、系统版本等）引起的问题和风险。

如果是固定环境，或者环境数量少，我觉得差异不大。开箱即用这个特性用到的频率并不高。

从你的情况看，如果 tomcat 的配置不常改，而且两个环境每次上线是按顺序使用的（如用完第一个肯定会用第二个，固定顺序），那么用不用 docker 差异不会太大。但如果两个环境是相互独立，每次上线只会用其中一个，建议用 docker 便于确保两个环境的一致性，否则后面某个环境版本滞后，要升级到最新版会很痛苦。。。

谢谢反馈，已收到。这个是 css 响应式布局参数设置的问题，我们会尽快处理。

非常前沿的见闻，加精让更多人可以看到和了解到。

iOS 真机和模拟器用的包是不通用的。Object-C 或者 swift 都没有像 java 那样的跨平台特性。

如果是纯黑盒，个人偏向于第二种，实际上可以覆盖的场景比你想象的全。

至于数据量和线上差异很大这个问题，建议当做是另一个问题来解决。甚至可以考虑申请线上数据来作为你的测试数据源，确认数据量大时的表现。

相信只要你有心去找，总能找到一些错误信息的。

据我所知，windows 系统里面应用崩溃都会有日志记录，里面会给到你一些便于定位问题和用搜索引擎寻找答案的线索。

很赞的功能!

1. 对于反馈量不多，但一直时有发生的，内部环境无法重现的，方向可以考虑往线上信息收集靠拢。可以考虑加埋点日志，甚至针对这个地方进行堆栈信息回传，方便排查。
2. 如果某个机型普遍反映卡顿，且用户占比较大，别省钱了，赶紧买这个机型仔细测试吧。

我勒个去，google 了一下，里面的缩写竟然还真的能搜出点东西。。。

zizhupark = 紫竹国家高新技术产业开发区
shzizhupark = 上海紫竹国家高新技术产业开发区