今天深圳金融沙龙刚好有一个 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 = 上海紫竹国家高新技术产业开发区

表象上看，是入库时主键值重复了，导致报错

从背后看，我猜测是没有做好并发时的事务处理，两个并发同时处理一个业务，导致重复。

谢谢支持

赞~

哈哈，这个也是我们研发老大推荐我才知道的。公司内部对于新技术响应还是挺快的。

坚持每周一篇，赞！

可以看看：
https://stackoverflow.com/questions/21058230/how-to-assert-a-dict-contains-another-dict-without-assertdictcontainssubset-in-p

怎么是起哄，这段总结真的很赞嘛

总结很赞！

赞。

不过为啥会和多线程共享变量有关？

不能。需要用其它工具。

appium 只能帮你截图。

180s 可能还是有点短，我一般是 7200s 。

最近和其它公司的同学交流，有一点很感慨，大公司相比小公司，在这类基础设施建设上做得好很多，可以节省很多时间，而且降低大部分人的学习成本。

不过随着 jenkins 和开源社区的持续改进，相信这些开源软件最后会做得不输于大公司的基础平台。然后接下来就是人员和团队意识和能力提升的问题了。

现在有新手区了。