
课程咨询: 400-996-5531 / 投诉建议: 400-111-8989
认真做教育 专心促就业
掌握扎实的软件测试技术才能够在日益竞争严重的社会下生存下来,而本文我们就通过案例分析来简单了解一下,软件测试程序员知识图谱分析。
因为系统知识在实际工作中的应用真的很重要,却又是很多人容易忽略的地方,特别是当大家把关注点都集中在需求上的时候,往往就只看到显式需求了。
下面我接着要说的是,如何在关注需求的同时,还能进行系统知识的提炼,从而在编写用例过程中有系统知识来辅助输出。
我目前了解到关于系统知识使用上的不足,主要是因为很多人没有区分开哪些是开发实现逻辑,哪些是系统知识。
比如前面那个获取系统版本的例子中,对RtlGetVersion结果进行处理,是本次代码实现逻辑,而对于RtlGetVersion本身是系统API,对于系统API我们去查看API文档说明进行了解,基本不需要测试点覆盖,但是对于自己开发代码的实现逻辑却是需要充分的覆盖。
那么从经验积累的角度看,我们需要在了解完需求后,有意识的区分哪些是本次开发修改的逻辑,哪些是调用的系统接口。
不同的实现方式,对应不同的测试覆盖率的要求,需要挖掘的点和挖掘的方向也不同。
还是拿上面这个例子来说,如果只是按需求实现的角度去看,那么根本挖掘不到系统版本号的判断逻辑,也根本不会想着去了解GetVersion和RtlGetVersion的区别,也就不会有对应的测试点出来。
类似这样的知识点每个需求中都可以涉及很多,能不能把它们进行充分合理的提炼就是我们能力的体现了。
不过,也有很多人确实每次项目都进行了提炼,但是之后有新项目涉及类似的逻辑时,还是没有关联上,等到别人提醒,才会恍然大悟的说自己也知道这个点,问题是,如果知道的东西用不上,那和不知道有啥区别?
所以这里我要再强调一下体系化,就是我们吸收过来的系统知识,一定要分门别类的进行体系化的归纳总结。
体系化的好处是,等需要用到某个知识点的时候,可以极其方便快捷的按照固定路径进行知识的搜寻和提取。
其实和我们用脑图写测试点是一个道理,一个东西如果庞大到强记忆无法覆盖的程度,一定要进行体系化梳理。
当然,体系化不是目的,体系化之后的快速准确的输出才是目的。
以上,通过自己的实际经验,把测试过程中涉及的系统知识按照输入和输出两部分进行了简要说明,不知道你在实际项目中,涉及系统知识的地方多不多?是否有进行过系统知识和业务逻辑的分离?欢迎留言说说你的看法。
【免责声明】本文系本网编辑部分转载,转载目的在于传递更多信息,并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题,请在30日内与管理员联系,我们会予以更改或删除相关文章,以保证您的权益!更多内容请加danei0707学习了解。欢迎关注“达内在线”参与分销,赚更多好礼。