开发的自测宝典

2011年11月25日 由 yanyue 留言 »

常常会听到说开发自测之后主流程都走不通，常常会遇到测试同学对着开发自测的结果直摇头，常常会自己心里觉得开发自测之说不靠谱。

不知道这个现象是不是普遍，不过却很让测试同学头痛。以开发自测为主的项目，结果测试同学还是投入大量的时间去执行测试，来保证项目质量。说开发冒烟自测通过再提交测试，结果测试同学冒烟测试时仍不通过。

有过几多次吐血经历之后，有了一些小小的经验，貌似可以提高开发自测质量。

提供测试用例，尤其要标注冒烟用例。因为开发在做测试时往往是遵循自己开发的思路来执行，很可能遗漏一些场景及步骤，所以提供测试用例，开发就可以根据用例来进行执行。

有了用例结果提交的代码还是冒烟不通过，怎么办！！看开发同学执行一个冒烟用例，要了解为什么开发根据用例来执行用例还会出现冒烟不通过，是不理解用例还是用例写的不到位。

提供测试数据给开发同学。开发同学可能只了解自己开发模块的相关业务，对于准备测试数据确实不是开发同学的强项，而且开发同学准备的测试数据往往会按照代码逻辑来准备。所以测试同学可以站在用户的角度准备测试数据来进行测试更容易发现问题。

测试同学把关边缘用例。可能开发同学比较奔放吧，要不然咋体现测试同学比较细心呢。有些边缘业务还是需要测试同学自己把关，尤其是应用间有交互的模块，需要多关注。

测试同学参与验证bug，执行相关模块用例。我想测试同学在验证bug的时候常说的一句就是“还是有问题”，这个很难让人淡定，所以最好还是测试同学参与一起验证BUG。因为已经发现的问题，再未被解决发布到线上，这个就比较悲剧。还有个现象就是修复了一个BUG引发新的问题，测试同学会本身有一种惯性测试的特点——就是测试关联模块，这点可以比较好的避免新问题的遗漏。

让开发执行引发bug的用例。这个不知道有没有效果，本身这点的出发点是为了让开发可以bug身上找出灵感，想想代码的其他地方有没有缺陷或者漏洞。

最后一点是兼容性的测试。这个是跟前端关系很大，前端出现的很多BUG就是兼容性bug了。提醒前端同学在自测的时候要注意兼容性问题，目前要求测试的浏览器有IE6，7，8；firefox；chrome。

差不多使上这些绝招，相信开发的自测会变得靠谱起来的。