#11 楼 @calkevin dict 个编辑还是很方便的，格式和结构都很清晰，和 xml 一样方便，就是读取更便利

把他们区分开来，全部放在一个 json 中，然后获取，可以分为 header 部分，body 部分，params 部分，预期结果部分，这个 json 体里的东西你可以灵活设置，然后到时候按照设置的 key 取取你想要的 value 即可。

如果请求的格式是 json，那就用 json 格式管理起来

#16 楼 @jihabur 过了试用期，考核在 B 及以上就可以。

全员持股落地，正在授权执行中，感兴趣，看好的同仁们，这儿欢迎你们：)

#11 楼 @gaopeng1106 呵呵，为了解决半夜起来充电，半天找不到正反的问题，这是个典故。
你的使用心情我理解，没电没线的时候想借都没有，因为还没有普及。

#7 楼 @haiquan180 十分感谢，我已经反应给他们了。

#5 楼 @haiquan180 造成困扰，实在抱歉，类似问题你可以关注下乐迷论坛，进行提问。或者打售后电话解决。

#3 楼 @xdlhy 东四环朝阳公园桥东乐视大厦

#11 楼 @lihuazhang 呵呵，谢谢，一开始还真是有点抗拒的。用上了还感觉很高大上，心境不一样了又 ：0

#7 楼 @monkey
#6 楼 @lihuazhang
写完了，请审核

@monkey

@monkey 改完了，看看还有哪要改。

#4 楼 @xhk1 只支持隔行，改进下吧，不认缩进格式。

#3 楼 @chenhengjie123 我本身有排版的，可是保存后就成这个样子了.............
我再看看。

只能表示同情，这种情况下，对方如果连测试也是半瓶子的话，就更难了.....

#27 楼 @james88233 这个主要看你们自己开发的工具，如果该工具是为你们公司的项目特别定制的话，或许使用起来可操作性和准确性都能高点，不过最终看你们的工具的能力了：）

#24 楼 @james88233 你的问题楼下的 chenhengjie123 基本已经回答了。这里我再说两句：1.你们公司自己开发录制脚本的工具，现在市面上已经有开源的了，如果真走录制，这些就够了，为何会另外投入精力去做，而且开源的都已经经历好多人的使用测试了；
另外即使是录制的脚本，你也要在此基础上进行修改，增加判断点，到时候开发出来的能不能很好符合你们测试的需求呢？

所以建议是：如果录制工具用开源的，口碑不错的，调研下；如果你们的工具开发团队很强大，建议他们开发测试框架，给出 sample，你们之负责按照 sample 编写测试用例的脚本就可以了，所有函数，判断，规则，报告都有框架团队给出，这样你们就不会被录制的 ui 层的东西来阻碍实际开发，也可以用你的 testsense 更多地关注在用例脚本的实现上。

#8 楼 @lihuazhang 补充第三种，1 和 2 的结合，这条路是可以走的。

#7 楼 @james88233 不是愿意干的人少，而是又时变化太快来不及更新，此时建议考虑下文档的内容优化和展现形式是否可以更直观而不单单是一大堆文字，可以用图表解决，结构展示，流程显现。

#6 楼 @james88233 录制脚本的形式是简单，可是实现会复杂，其实编码不难，正如你领导说的有了测试 sence，你只需要将它转换成 code 就可以了，当然不是所有的都可以转换。
如果精力允许，还是建议学习下编程，不需要多，一个就够，而且最好在实际工作中应用，这样学的最快

#5 楼 @lihuazhang 严重同意，人人都应有质量意识，不应该只是质量部门或者测试部门的。