测试空间旗下大头针出品
今天的107答辩了,加班加点的日子终于过完了。在项目实训的过程中,每一位组员都积极主动,勇于承担,互帮互助。平时都自愿加班加点做项目。还记得很久前对这些学员的要求:信心,耐心,坚持。看这帮小子的精神状态,每个人都做到了所要求的了。(不再夸了,自个学生也不能使劲夸呀!),加油,路就在前方,加油107.
下面简单摘取了一些答辩中的片段:
赵老师:
1.大功能模块下包含了很多的子模块,你为这些子模块设计了很多的用例。而当你执行测试时,发现这个大模块根本就不能用,你该怎么办呢?
既然大模块不能用,那这个模块下的子模块都是不能测试的了,我们不能为每一个子模块都提一个bug,那样是不合理的。我们应该做的就是把为这个模块设计的用例都标记为未执行。其实用例有两种分类:1.执行:又分为:通过和不通过。2.未执行。那当我们遇到这样的情况的时候,就标记用例为未执行。
2.遇到组员中途退出怎么处理?
1.把组员未完成的模块直接砍掉。
2.接过组员未完成的任务,其他组员主动承担。
在企业中,我们应该选择后者。
3.测试总结报告中的缺陷报告应该以什么来分类?
1.以人来分类
2.以缺陷的严重程度来分类
3.以缺陷的优先级来分类
你们选择的是以人来分类,这样做是大错特错的。我们做测试的,测试的软件,测试的结果是为了反映软件的质量状态,而不是我们每个人的成果展览。你们做完测试最终的目的是为了说明你们所测试的模块具体的质量是否达到了要求。这个是你们应该做的。显然后两种分类更合理。
4.当张同学做总结报告时,PPT上出现了这样一个环节:通过我们的工作日志,反映出来我们这7天的工作完成情况都在93%以上,我感到我们组的工作基本上完成了预期的工作。
赵老师:我感觉你们组根本就没有完成任何工作。你说你们组平均每天都完成工作的93%,这就意味这你们组每一天的工作都没有完成,7天整合起来,总得结果就是没有完成任务。假设你们第一天完成了既定任务的90%,那么第2天的工作应该完成的是第2天既定任务的110%。因为你要把第一天未完成的任务先做完才可以。(厉害,厉害!)
5.发现问题肯定要提交bug报告,哪怕是在熟悉软件的过程中。我们是测试软件,不是比赛。我说现在比赛开始,你才开始提交bug,这个肯定是不行的。
6.提醒一下:答辩前各个组员应该自我介绍一下,台下的老师可能不知道你的名字。(胡老师的确是不知道)
7.工作量重复的问题。当你测试的时候,发现你所测试的大的模块下有几个子模块是其他组员的,这时候你怎么办?
难道还要把这个子模块的功能重新测试一边吗?当然不用,你只需要确保在这个大模块下的子模块能够在点击后正确打开就可以了。至于这个子模块的测试,交由其他组员负责就行了。
徐老师:
1.当看到测试总结报告里,有些工作不是按照计划来执行的时候,徐老师说:
计划是用来执行的,不是用来当摆设的。所以一定按照测试计划中的安排去做以后的测试工作。
2.测试《另存为。。》这个功能,你考虑到另存为到不同的存储介质了吗?比如说软盘,U盘等等。考虑磁盘满的情况了吗?考虑到存储到不同网络路径了吗?我们不但要考虑到正常的最常用的情况,而且在测试时我们尽可能的把问题想的更全面。
胡老师:
1. 看到第二组的缺陷严重程度分为A类,B类。。。?
缺陷的严重程度不应该分类,而应该分级。类是并列的概念,而级是层次的概念。严重程度肯定是分级别的。
2. 当看到答辩PPT没有页码时?
PPT应该标注页码,这样老师提问题时,可以很快找到相应的PPT.
3.bug是有群集现象的,这个你注意到了没有?
4.用例写了不少,但用例评审环节做了没有啊?(台下无语,好像是没做)
耿同学:
如何更合理的设计测试用例,以及从整体把控所测试的模块,使测试更合理性,这是我们要思考的事情。(耿同学的思考还是比较有深度)
李同学:
以后实训之前是否应该给我们有关本项目的前一届学长所做过的经典测试用例案例和缺陷报告案例。(采纳,你们这次做的可以成为模板了)
还有实训机房能否多开个窗户,在我们实训期间,组员们反映机房不通风,头太晕了。(李同学的建议不错,可能实现起来有点困难)
趣味对话:
张同学:实训后,才发现《高效设计测试用例》这本书太重要了。
赵老师(TC老师):可惜你一半的可都没有上。(哈哈,拍到马腿了!)