请教各位老司机:
本人现在在用一个公司内部的测试工具,这个工具不具备 Wait until UI change 的功能,需要手工设置 wait time,我觉得非常不方便不效率啊,就想跟上层建议加入这个功能。但是领导的意思是要想加入必须有拿得出手的数据来证明这个功能确实有加入的必要。我想请问一下各位,有什么好的建议能说服我的老板,我们的工具需要这个功能吗?我们现在主要做稳定性和 App 兼容性测试。
没啥必要,除非你为了测试用例的通过。比如一个控件,加载下在 5 秒到 10 秒之间,那么你设置个 10 秒。超过 10 秒就是问题。但是如果你用 wait until 等到了 20 秒,这样用例是通过了,但是意义没有了。
#1 楼 @lihuazhang 但是手机在使用过一段时间后会变慢吧,如果这个时间我定义不好,可能这次过了,下次就过不了。如果定义的时间过长,一开始手机反应很快的时候,又感觉浪费了时间,降低了执行的效率。这个平衡点不好把握。比如一条测试用例,点击某一个按钮,一开始的反应时间是 0.5 秒,跑 100 遍后可能就变成了 2 秒。我们的测试需要连续执行几千遍用例,这个时间我就算不好了
#2 楼 @james88233 首先这个时间,不是说每一步都一定会等那么久,只是最长会等那么久,其次这个时间是多少,这个取决于 你们对这个操作的性能要求,
#3 楼 @kuroky 对的 这个是 time out 的时间 我希望我的测试可以有一个灵活的判断机制,可以在一个区间范围内自由执行 0.5 秒-2 秒内反应过来了都算成功 2 秒以上才判定失败,现阶段我只能定死了要么 0.5 秒要么 2 秒之后再执行下一个动作,如果下一个动作的控件找不到,就报错,这显得很不直观
#4 楼 @james88233 我觉得你作为一个测试很不错!前置条件写的很详细:我们现在主要做稳定性和 App 兼容性测试; 那么就可以解释成: 单个步骤执行过程中,有可能碰到接口网络问题响应缓慢,所以在 2s-40s 不等,所以我们就需要设置为 40s。 如果一个用例保护 20 个接口的调用,甚至其中接口的调用是嵌套的。 不算用例的执行时间,就需要 20*40=800s,一共 100 个用例,需要运行两百次才能判断是否稳定。 则运行耗时为 100*200*800s=16000000s。 如果加入你说的那种机制,则平均下来,需要等待可能在 5s,那么就节约耗时 8 倍。 所获收益也就翻三番。 向领导解释清楚问题的原因以及后续优化之后的预期,也是工作内容之一,好好体会吧。
#5 楼 @pighero001 谢谢您的指导。我认为做自动化测试,尤其是稳定性的测试,一定的压力是必要的。不能说为了测试用例的执行通过率,过度地提高等待的时间。这样的话如果被测试设备执行一个动作耗时 0.5 秒,却等待了 2 秒再执行下一个操作,就等于休息了 2 秒的时间,这对于测试来说我认为不够严谨,也会 miss 掉一些由于内存释放不及时产生的故障。其实我自己的概念自动化测试应该在条件允许的范围内无限接近真实用户的操作。 更新一下后续哈,我和领导汇报了各位坛友的想法,然后得到的回复是这样的:Wait until UI change 这样的方法在目前的测试领域,必须要通过打 jar 包或者其他形式嵌入到被测设备中才能执行。对于我们目前的产品来说,是不符合产品规范的。因为我们的产品就是要在不改变被测设备本身的前提下进行测试
#4 楼 @james88233 怎么会一定要等 0.5 秒或者 2 秒才会执行下一步你,你用 WebDriverWait 啊这个是智能的