从事测试马上两个月了,图片表情的白盒测试以及远距离调频的黑盒&灰盒测试第一轮测试完成,在此总结一下需要深刻体会的内容,或者是部分的测试点,后续会慢慢增加:
时间低效率的原因与解决:
1:
问题:
测试,主要的内容是发现问题,但是之前的并改正不再是重点,一时间从开发到测试,这个思路尚未完全转换,不过也因为这个导致花费大量时间加班去弥补两者转换所导致的任务延迟。
解决:
发现问题,最多重试一次,复现的话就记录下来作为BUG,不能重现标记下来,最后随机测试一遍,这样尽可能的避免阻塞性BUG问题,最终的BUG必须在至少两次结果一致的时候才能算数。
2:
问题:
测试过程中,发现XXX功能的发送数据包失败,找了很久的原因,发现依赖于另外一个进程:云服务,虽然最终原因有待商榷,但是这不应该在中途才注意依赖关系。
解决:
在做测试的时候,要问清楚到底依赖哪些模块、服务,测试各个模块、服务之间的通信也是非常重要的。
3:
黑盒白盒的顺序
问题:
在做黑盒测试的时候,遇到不解或者问题总是首先想去代码中找问题原因,找解决原因,会比较浪费时间
解决:
应该更多的是看需求文档、问开发实现环节,或者将问题留下,在最后做回归测试的时候集中解决,但是留下的时候一定在问题不好复现的情况下,能复现一定要及时高速开发改正,整体上,要先黑盒,问题留下,之后白盒。
4:
问题:
纯粹按照黑盒的测试点去找,点极其的多
解决:
根据具体的功能,测试比较核心、容易出错、重点部分,不用的内容,最后有时间再做
5:
问题:
流程图的正确与否对结果的有着很大的影响,而开发给的流程图、以及产品给的需求很有可能是最初的版本,画准确的流程图比较费时间
解决:
开发讲解,尽可能的将实现思想讲解
6:
问题:
总是遇到相同的测试过程,测试的结果不一致,导致各种重复操作找原因确认确实是BUG,后来一点点发现,部分是因为,每次执行测试的时候,环境的初始化出现问题,比如有些数据包没有清空,有些进程没有全部关闭等等。白盒测试的时候也发现过因为初始环境不同造成结果不用,那个是过于想要让随意一个数据包测试的时候都没问题,而误解了测试其实是需要测试特殊的用例的。
解决:
每次都要初始化初始环境。
7:
问题:
在想测试用例的时候,需要设计数据,对于输入法内部的数据的种类、逻辑关系不熟悉,设计黑盒例子比较费劲
解决:
多将一些比较有代表的数据保存:
微软神仙:启动云服务
漫天大雪:系统合成二元