自己看的时候,要全部测,肯定没有时间测,开发告诉你,不是很靠谱,希望你多测。朱少民:Def我们肯定会用的,知道代码做了哪些改动,另外一个是你要知道这位同学讲的,你要知道代码之间的关系,最好有一个类的关系图,或者方法调用之间关系图,你要维护一个举证或者说一个表。一方面要知道这个表或者说这个举证所维护的类或者方法的关系图,或者函数级的更好一点。你如果不知道这个关系图的话,代码改动的地方我们比较容易知道的,至少可以让开发跟我们一起看一下代码改动哪些地方,即使不用Def的话我们也应该知道,我们最怕回归测试是什么,他改动的地方影响另外一些地方,那些地方出问题我们不能把握,这样一个关系非常重要。第二个,我们能不能建立测试用例和代码之间的关系,如果你测试用例不多,那也是可以做的,如果你有几万个测试用例,那就比较麻烦,我们看测试用例经过哪些方法、哪些类,你反过来改了哪些方法、哪些类,受到影响的方法和类,就知道测试用例和它哪些有关系的,这样选出来的用例最小,而且相对来讲最可靠、最优化,这才是又一个创新的地方。光知道原理不够,还要去实现,现在有些工具也可以帮你做事情,现在有代码覆盖率,运行艾玛或者其它一些工具,当你运行测试用例的时候,它会自动给你产生覆盖情况,如果测试用例是自动化的话,那给更方便了,每运行一个测试用例,产生一个覆盖率表,很容易建立测试用例和代码之间的关系。如果你再有一个代码类关系图,或者说方法关系图,以后的回归测试可以做得非常有效、非常快。新的理念:1、敏捷测试2、流程是次要的,团队才是根本。你用敏捷方法,相当于整个过程迭代快,测试也要快,你的敏捷测试基于许多东西实现,但是你的测试也要敏捷,也要更快,或者足够快,刚才淘宝同学讲,每个礼拜两到五次发布,如何跟上发布节奏,你的功能测试或者性能测试都要跟得上。流程是次要的,让你一个礼拜发五次的话,最基本流程是需要的,根本流程不能破坏,
全文预览
