case 之间不要做成相互依赖的。 如果一定要相互依赖，也要确保相互依赖的 case 在一台机器上有序的运行

是的，我们目前还是处于 POC(Proof of Concept) 阶段。对于搭建私有云的客户还是需要到场地内建模并做各种测试以证明符合客户需求。以后要尝试 POT(Proof of Technology)。直接从产品的各个维度提供业界认可的权威报告。这个被老大列在了今年的计划当中。

可怜我司就是做平台的。。。。所以我还是得硬着头皮去造数~~~ 最近跟某行合作。他们直接对测试用例，性能测试和测试数据提出了要求~。ToB 的业务想卖出去就是费事~~，我们还得派人去场地内在他们的环境上跑一遍性能测试以证明我们的产品能够支持他们的需求。

主要是维护起来是个噩梦。本来业务变化就很大，不仅要改 case 还得改框架，我觉得维护成本太高。 为了能让不会写代码的人使用。要封装的东西太多，例如如何让不懂代码的人调试和 debug？光这一项就够让我头疼了。又例如我还被要求过提供一个酷炫的 UI。总之各种坑。

恩？ 没更新头像的不是不能发帖了么？ bug 了？

python 的 json 模块不能搞这些事么？

没有。。。。测试类型不一样。。。我这边是做数据测试。所以才用这玩意。你不做这种测试就随便看看了解一下就行了。。。

额，最近在家比较闲

恩，如果单从以后你面试的角度来看的话。 其实接触服务端的东西反而会给你加分的。创业公司人手少，本就不会区分的那么严格。 一线大厂也都喜欢有能力 own 一整个模块的。 所以我觉得如果为了以后的发展来考虑的话，反而应该多接触接触后端的东西。

额，这个话题不用匿名的。有疑问挺好的一事儿。做服务端也挺好的，可以丰富你的经历。 而且现在很多公司的测试不分客户端服务端的。 就是一个人全做。多学点没啥坏处的。

额，为什么你一定认为测试开发是脱离了业务的呢~~~ 而且我也不太明白为什么你这么认定技术与业务是对立的~~~可能你没有碰到靠谱的技术人吧。我觉得其实不管什么职位，技术都是用来服务业务的。要求技术好，是因为技术越好越能服务业务。 就像我们招开发要招技术好的，招运维要招技术好的。为什么到了测试就一定得招技术不好的？难道测试已经不属于技术部门了么？技术好的人有能力让产品质量更好，有能力把技术转换成生产力提高效率。所以我们为什么要这么抵触技术 这么个东西呢？有了技术这么个东西，测试人员可以一键部署一整套产品环境，可以无人值守的维护整个团队几十上百的测试环境。 有了技术这么个东西，持续集成跑起来，可以提前发现 N 多个 bug。有了技术这个东西，devops 走起来，一键出包部署。有了技术这个东西，自动化测试走起来，原来要执行几天的测试现在可能只要几小时。所以我们不要排斥技术这个东西。而是要排斥不能服务于业务的技术。 如果要问我再工作中用到了多少技术， 我可以这么说，我要是变成一个不懂技术的人，我现在立马失业。 因为我现在 90% 以上的任务是没有技术做不了的。

恩恩，有用就好， 我也是最近在学习这些。所以记录一下学习的过程

谢谢支持哈~

你查查怎么装这个插件吧。。。。。

py.test --alluredir report

你先别管 IDE，你用命令行跑一下命令。 排除一下 IDE 的问题，看看是不是 allure 没装好

额，不知道在哪看版本，这玩意还没用熟呢

降级的。 现在 pytest 的 allure 有 bug 只支持 2.9.0 以下版本

问题 1：我是直接用 IDE 装的模块
问题 2：我记得是平级的

好奇怪。。。。我这里好好的。。。。。。。

现在是什么错误？ IDE 提示找不到那个装饰器么？

奇怪啊，你用的什么 IDE，我用 pycharm 没碰见这个问题

额，真没想到都这么久了还有人回复。 其实这个东西我现在已经不用了，也是有一些缺点的。 但我还是跟你说说吧。 这个东西其实就是个 page object 的加强版。只对页面元素做定义的。case 里不用它的