1. 没有合适的规范：
大家都是来自不通的公司，在编写测试用例时可能会带着以前的习惯，我们也没有在现在的项目中找到明确且合适的规范，于是只是根据自己以前的经验复制，但这些有时候并不适合我们目前的项目。比如在测试UUM时，个人自己就犯着以前不好的测试思维和习惯。
改进方法：
指定合理的规范，统一大家思维，有待讨论。
2. 功能与业务分离：
这个是在测试ES-iVision存在的问题，在测试系统时可能只关注了功能而没有整体业务的把握测试，只注重了某个功能表单上单一的测试，而整个业务可能才是我们测试的重点。
改进方法：
功能用例和业务用例分开组织编写。A）功能用例依据需求界面描述，根据等价类、边界值、错误推断编写，必要时建立数据库，存放测试数据，而这些测试用例都与业务无关。并且可以利用资源找到相关的测试用例，来补充我们设计的不足。B）业务测试用例关注的是表单的执行路径，执行后在系统上产生的一系列反应。这个可依据需求在开发前或与开发同时进行。但此业务功能必须是开发确认正确的。
PS:以前我们在业务这块有场景测试用例。如发文流程中有多流程时，分场景测试流程。
3. 测试跟不上变化：
开发人员在开发时可能会对需求进行调整，这个问题是在测试UUM时系统管理角色需求就进行调整，所以我们被动的只能跑在开发的后面，我们也做了许多不必要的工作。
改进方法：
有问题及时与开发讨论，走在开发前面调整我们测试用例，测试进度。
4. 发布前轮询很多版本：
某一产品在经过几轮测试后，在发布前可能会为一两个bug要轮询很多版本，在轮询时测试人员不可能再把所有功能、业务全部再过一遍，但是我们此时会对发布版本没有信心，而再走一遍浪费时间精力。
改进方法：
文章来源于领测软件测试网 https://www.ltesting.net/