最近老大让整理svn上开发提交代码等一些变更日志,今天整理出来一份,主要包含版本号,修改人,修改时间,修改的备注,以及modified or add 具体代码的路径下的.java。
老大期望的结果:表明修改了哪个模块,影响范围,针对哪些bug.
简单来说:总结通性的东西(开发会复用代码),某一地方代码的改动,是否会牵扯到其他页面的修改。
今天老大说的探索性测试:
以后每次开发打完版本之后,先将log拿出来分析,开发动了哪些代码,根据开发动的模块,进行测试。简单来说,以log为指引,驱动测试方向。
开发传授java代码里面每个文件代表的含义及作用,只记住了
文件结尾:bean(定义做什么)、
serviceimpl(具体实现)、
service和condition(定义了是什么)
map(数据库)
web/consume
API
自己得去研究一下每个路径下的文件。
以下源自网络:
https://mp.weixin.qq.com/s/F8shR_e9KNSGM7LYw9gfLg
01 关于探索性测试:
1、探索性测试不是自由测试,而是需要有一定的方法来指导;这里就像一个旅行者来到一个完全陌生的城市一样,如果没有一个地图或者旅游指南的话,那么可能就会在这个城市漫无目的的转了。
2、探索性强调测试人员的主观能动性,抛弃繁杂的测试计划和测试用例设计过程,强调在碰到问题时及时改变测试策略。
02 探索性测试的目标:
1、理解应用程序如何工作,它的接口看起来怎么样,它实现了哪些功能;(找到软件切入点)
2、强迫软件展示其全部能力;(满足所有的功能上的需求)
3、找到缺陷;(树立明确的目的,而不是漫无目的寻找影子)
03 常见的探索性测试:
1、自由探索性测试:类似于自由测试,效果跟经验有很大关系。
2、基于场景的探索性测试:这里跟我们上一章分享的基于场景的用例设计方法很类似。
3、基于策略的探索性测试:这里我们主要是根据对产品的熟悉程度和经验来进行有针对性的测试,目的是很快的发现软件存在的风险
4、基于反馈的探索性测试:这里是指我们在探索性测试的过程中通过分析当前的质量以及前面的测试情况来指导后面的探索性测试。
当然, 一个比较好的效果就是我们能够将这些方法结合起来,从而达到效果的最大化。
下面介绍一下基于旅行者的探索性测试方法吧(以下内容来自于探索式软件测试这本书籍,详细方法大家可以去看看)。
我们可以将软件的测试比做是去一个城市的旅游。那么我们如何快速的去到我们想去的地方呢?一个办法就是我们对这个城市很熟悉。另外一个办法就是找一个导游或者一份地图,用来指导我们去在这个城市旅游。
对于软件测试来说,我们同样需要对被测软件很熟悉,同时也需要一份测试地图或者测试指南,来帮助我们更好的探索性测试。
拿到地图后,我们可以根据地图将城市按照功能分为各种区域,比如:商业区,历史区,娱乐区,旅游区,旅馆区,破旧区等。而每个区域对应软件相应的功能。比如:
商业区:对应软件包装上面的对应特性,类似我们的需求。
历史区:上一个版本遗留下来的代码、问题或则曾经出现多次bug的功能或者特性。
旅游区:对应产品的新特性,能够去更好的吸引新的用户。
娱乐区:对应软件的辅助特性和功能,可以做完补充测试。
旅馆区:对应软件内部的一些交互,不一定是由用户来触发的。
破旧区:对应软件的历史稳定的代码,一般很少人去接触
网友评论