现状和问题
- 开发插件的功能A的时候随手建立场景, 测试插件的功能A. 测试通过后,测试场景就被丢掉.
- 发现插件的功能A有bug时, 修改代码, 然后随手建立场景, 测试bug. 测试通过后,测试场景就被丢掉.
- 添加功能B, 测试功能B通过后, 在使用的时候发现之前的功能A却产生了bug, 应该是在添加功能B的时候产生的bug.
- 在开发人员流动大的公司里, 一个开发人员离职了, 他所开发的代码交接给后续的开发人员.
后续开发人员很难了解原先代码的设计思路和细节, 同时在添加新功能时难免会引入bug.
一个可行的解决方法:
- 在开发过程中, 每增加一个新功能, 都应该写相应的testcase.
- 在开发过程中, 开发人员自己如果经常执行这些testcase(回归测试), 那么就能保证修改的代码不引入新的bug
- 一个开发人员离职了, 他所开发的代码交接给后续的开发人员. 后续开发人员看testcase,了解插件的功能如何使用.
在添加新功能的时候, 把之前所有的testcase都执行一遍, 就能保证之前的功能没有问题. 如果有问题的话, 也能构及时发现.
新的问题:
- 一个插件可能有大大小小十几个功能, 全部测试下来可能要十几分钟. 每次修改一下代码都要花这十几分钟做回归测试的话,
一天下来也写不了多少代码. 这样的开发效率太低.
解决方法:
- 做自动化测试. 把原先手动测试的工作让程序来做.
关于automation
框架
- 自己写
- 使用python unittest
如何写testcase
有了测试框架之后, 还需要有testcase. 才能让自动化测试真的有效. 关于如何写好testcase, 这里有一写个人的经验.
- testcase里一般使用unittets.assert()来测试某个变量的值是否等于正确的值.
- 如何比较数组
比如, 如果要测试一个deform插件. 需要判断变形后的点的坐标是否正确. unittets.assert()不能比较list类型, 所以需要我们自己写.
要比较normal, nv等数据, 也需要这么做.
- 如果要测试一个shader该怎么写testcase? 怎么判断物体上的每个像素的值都是正确的呢?
可以把第一次渲染出的图片保存, 作为正确的图片(参考图片), 以后每次渲染出的图片和参考图片做比较. 我简称这种方法为"参考图比较".
其实, 对于判断vertex position, normal, nv 都可以用这种方法做回归测试.
测vertex position的话, 渲染一张图就能看得出点的坐标是否正确;
测vertex normal的话, 给mesh赋一张材质,渲染一张图就能看得出点的normal是否正确;
测vertex uv的话, 给材质赋一张checker纹理,渲染一张图就能看得出点的uv是否正确;
怎么样? 是不是觉得这个方法非常酷? 事实上, 如果你沿着这条路走下去的话, 你会发现实际上这是个无比大的坑! 但幸好这个坑还是有出路的.
所以, 我的建议是, 尽量不用"参考图比较"的方法, 而使用数组比较position, normal, nv这些值. 但如果要测试shader的话, 除了"参考图比较"的方法之外, 我没有想到更好的方法.
下面说一下"参考图比较"的方法, 以及会遇到哪些问题:
- 图片格式
备选项: jpg, exr, png, bmp, ...
以下是我选择图片格式的依据:
- 图片文件尽可能小.
- 方便查看. 比如, 我双击图片就可以查看, 如果能直接在文件管理器里浏览其缩略图就更好了.(所以, exr格式被剔除)
- 跨平台. (bmp在linux不太好, 所以被剔除)
似乎jpg, png都是不错的选择. 但jpg是有损压缩. 为了避免压缩导致图片不一致, 我最终还是选择png格式.
- 如何比较两张图片是否一致
- 用什么渲染器来渲染参考图
备选项:mayaSoftware, mentalray, arnold,
- 最好是maya自带的渲染器, 因为使用起来方便.
- 所以, 似乎mayaSoftware是首选. 但如果你用这个渲染器, 会发现每次渲染的图片都不一致(虽然人眼不出差异). 出来的图片根本不适合做参考图.
- 其次, mentalray每次渲染的图片是一致的. 但是, 相同maya版本, 不同平台下, mentalray渲染的图片有时会不一致. 更糟糕的是, 不同maya版本的mentalray渲染的图片差异很大.
为什么? 因为mentalray在不断的更新, 比如采样的方法变了, 渲染出的图片肯定就不一样了.
- 如何制作testcase的maya文件
- 批量更新testcase的maya文件, 是一件非常痛苦的事情
运行自动化测试的一些技巧
