我之所以在《软件测试自动化的探索与管理》一文中将软件开发成熟度作达到一定程度为自动化实施的一个前提条件,是因为自动化测试所依赖的还是没有自动化情况下的测试体系建设水平。不过总有人愿意自我麻痹:我们现有的测试工作做得遇到瓶颈了,需要通过自动化来提高我们测试工作的效率和精确度。我曾在微薄上和吴博士争论到底是否需要建设好产品用例库再去做自动化,无论大家认同与否,我觉得在做测试自动化之前有几件事情是要好好反省一下自己有没有做好:
测试完整性——测试人员或者说参与自动化测试的人是否熟悉整个系统的全部逻辑?
测试复用性——测试需求或者说补丁需求在持续地、周期性地追加或变更,测试人员设计出的测试用例是否每次版本发布之后就失去作用?
测试探索性——测试人员是否能够在测试过程中不断修改和补充测试用例来让测试更加完善?
测试经济性——测试人员有没有能力使用最小的数据矩阵去完成所有当前版本的需求的测试?
测试效率性——测试人员最快能够在多少小时之内完成整个版本很多个SRS的一轮测试执行?
测试有效性——测试人员是否在每一个必须的测试检查点上做了足够的检查?
这些方面如果没有考虑清楚或者没有做好,我觉得还是不要妄谈测试自动化了,因为手动测试做的不好,自动化测试的设计必然也不会很优秀。因此造成的自动化负担为长期的测试工作带来的效益很小,但是花费很大,是很不值得的。我们的出发点应该是软件质量,而并非只是为了节省时间或者人力,如果说人力、进度和质量这三者需要一个平衡点,那么自动化测试在忽略质量的时候,这铁三角一个都得不到。就像朱少民老师提到的软件测试的8组关系、13项原则、21个关键域,看起来很学院风,但其实也只是测试经验的提炼而已,我们也可以有自己的测试关注点总结。如果我们在日常的测试工作中接到任意一个或者一组需求都能够考虑到这因素,那说明我们的质量意识是已经养成了的,我们的基础工作做得好才能稳定地保证我们的软件质量。在能够保证质量或以保证质量为前提的情况下,再去考虑效益的提高才能使铁三角稳固,重复建设的灾难才不会重演。