多测师-多培养一些优秀的测试工程师
网站地图 |   收藏本站   |   

17727591462

测试设计、测试执行该不该由不同的人执行?

发布日期:2022-01-14 09:16:20 作者:多测师 浏览次数:

  把测试设计和测试执行分开,是错误的做法,不仅增加了沟通成本,而且不能保证测试设计和执行的质量。一方面,测试人员通过测试执行可以更好地理解功能、产品、业务等,从而进一步完善测试设计。另方面,测试设计长期脱离测试的执行,对产品、特性的理解也会退化,自然对测试设计有不良影响。

  有人说,我们有大量外包人员,他们流动快,主人翁意识不强,只能执行。你希望把他们当作测试工具、按部就班地执行测试用例吗?作为外包人员也乐意成为测试工具吗?如果是这样,为什么不直接写成自动化测试脚本?让工具执行还更靠谱、更快、成本更低。

  至于认证,你懂,一般只是一种政绩工程,或者是为了项目投标用。如果你要投标,要做外包,为了证明自己,写出规范的测试用例来交差,那就继续下去。

测试设计、测试执行该不该由不同的人执行?

  今天,你如果是用敏捷开发模式,有了用户故事就是有了用户行为,只要追加“场景”,列出需要验证的测试场景,类似BDD的GWT描述。虽然测试场景还不是测试用例,不能执行,但离测试用例也就差一步,即加上测试数据,而这时测试数据可以自动生成。所以,在敏捷开发模式中,主要为每个用户故事给出场景列表,这个也容易评审,越简单的东西,一旦有问题,就越容易发现。越简单的东西,维护的成本也就越低。

  如果你不是用敏捷开发模式,而是用传统的开发模式,我倒是希望你画一张业务流程图,标上业务规则、业务角色,针对这个进行测试,更能保证业务覆盖,而业务覆盖才是最根本的。咱们一切工作都是为了业务,测试就是为了会更好地保障业务的质量。当我们谈覆盖率,实际包含了三个层次的覆盖率:代码、功能/非功能特性、业务。单元测试侧重代码覆盖率,而系统测试侧重功能/非功能特性覆盖。非功能特性,性能、安全性、可靠性等会单独去考虑,即我们常说的专项测试,而功能测试,完全可以被业务覆盖而覆盖,即E2E业务覆盖更彻底。

  今天来做测试,依旧建议新功能用探索式测试,就根本不写测试用例。而回归测试彻底实现自动化,也根本不写测试用例(千万不要先写测试用例,再翻译成测试脚本,这样更浪费时间!),直接写测试脚本。

如需了解更多测试技术信息请关注:https://www.duoceshi.cn/jswz/深圳多测师软件与技术服务有限公司


查看更多 >>

推荐阅读