今天就分几个阶段给大家讲讲我对整个泛质量管理解决方案的理解，然后看看大家有没有一些共鸣。
先说一下移动测试的现状和问题。我们现在在做移动测试，因为移动测试本身机器比较多，比较碎片化。另外，APP的业务逻辑也没有PC端那么简单。可能我们写了很多脚本，花了很多功夫，但是发现下个版本来的时候，大部分都没用，要么重写，
要么手动点击，这其实是一个非常痛苦的过程。
主要有四个问题。首先是我们在发布之前进行移动测试和回归测试。正常情况下，我们三周做开发，一周做测试，测试后修改bug，然后发布，基本上就是这个流程。我们只在发布前关注了这一点。其实在研发阶段，这个点是空白的，还是需要我们手动去摸。这还不够。后面我会讲我们的解决方案如何帮助您提高效率和解决问题。 .
第二点是整个过程比较被动。现在我们提出了一些错误。开发者可能觉得这个问题价值不大，不会修复，但是客户打电话给我们客服说问题很严重，我不能再用了，特别是客户是VIP的时候，我们会认真地，非常努力地解决这个问题。这反映了一个问题。在我们的APP上线后，当用户有一些严重的投诉时，他们可以推动我们进行很多改进。那么我们应该有一个更好的监控系统吗？当用户发现问题时，我们可以第一时间知道有多少人有问题，问题有多严重，应该立即解决吗？由一组指标支持。
我们需要做在线监控和离线测试。能够发现程序问题非常重要。这里有一点，就是需要定义问题。我们知道崩溃是个问题，大家都懂，但性能是个问题，不好理解。例如，我启动时间是一秒，他的启动时间是三秒。不确定是哪个问题。这取决于我们的业务。当真正的用户觉得有问题的时候，那就是问题，所以这时候，我们就需要有一套标准。这个APP到了2.5秒就会不合格，因为用户已经受不了了。这还有一点，没有数据支持帮助你感知线上问题。
最后一点是我们做了很多测试活动。有一个非常不好的地方。我们做测试的时候，我们会聘请一些外包的学生做测试项目，但是业务经验是基于人的，这是非常困难的。不好，一旦这个人走了，我们要找另一个人，让他熟悉一下这个业务，这是一件很不好的事情，但是有没有办法一个人做好，他可以不断地把自己的测试方法和测试技术沉淀在这个平台上，后面的人能很好地利用前面人积累的经验来保证质量，这也是一个问题。
延伸阅读
上一篇
下一篇