最新软件测试实训 软件测试实训总结(4篇)
总结是指对某一阶段的工作、学习或思想中的经验或情况加以总结和概括的书面材料,它可以明确下一步的工作方向,少走弯路,少犯错误,提高工作效益,因此,让我们写一份总结吧。什么样的总结才是有效的呢?下面是小编整理的个人今后的总结范文,欢迎阅读分享,希望对大家有所帮助。
软件测试实训 软件测试实训总结篇一
而通过这次的这次分析觉得自己的测分还存在以下的问题:1、太关注开发的内部实现逻辑。建议:将开发内部实现逻辑看成一个黑盒子,测试分析要从这个黑盒子的输入和输出上去看开发内部实现逻辑是不是有问题,而不应该先去了解开发的实现逻辑然后按照他们的思路去分析。
2、分析文档写的过于详细,甚至将用例的步骤都写了出来。建议:测试分析要从全局上去看问题,细节的东西即便是知道的,也要留给之后的用例编写人员去了解(就像系分之后的开发需要去写详细设计的道理一样),这样后面的人才会自己主动去想问题。
3、分析文档要考虑维护性问题,不要出现类似比如还款中状态为“r”这种具体的数据内容。因为我的分析是对后续用例编写人员的一个指导性的文档,所以如果侧分这么写很有可能导致用例也照着这么写,其实不管侧分和用例都不应该具体写到r这么细节,否则的话开发稍作变动我们就要相应变动我们的用例
4、没有明确测试目的。review用例的时候,没有提出每个用例需要明确一个测试目的,让别人来看这个用例的时候能明白到底是怎么回事。
总结:
1、以后写测试分析文档,依据仅仅是prd文档,必须抛开开发实现逻辑部分(即不去看系分文档),待测分出来之后,再去看系分文档,互相看看彼此考虑的是否存在遗漏的地方。等到在写用例的时候再让写用例的人和相应的开发去互相明确更细节的东西。
2、写用例我们目前都是仅仅做到对流程上的每个节点去单独分析,细到看输出的时候会关注到数据库表的一个变化。但是除了以上部分,其实还少了对整体流程的关注,需要增加业务流程的各条路径的一个覆盖,在针对路径的用例中不需要关注到数据库表级那么细。
3、在做流程路径覆盖之前应该画一个路径图,这个图的画法考虑各个入口的不同分开画流程图,分别进行路径覆盖。