目前我们设计的测试用例只是表面上的呈现，对测试指导的作用不是很大，我们思想里也认为测试用例编写只是在熟悉系统的过程，在测试时测试用例会被我们撇在一边。个人总结一下原因和改进方法：

1.       没有合适的规范：

大家都是来自不通的公司，在编写测试用例时可能会带着以前的习惯，我们也没有在现在的项目中找到明确且合适的规范，于是只是根据自己以前的经验复制，但这些有时候并不适合我们目前的项目。比如在测试UUM时，个人自己就犯着以前不好的测试思维和习惯。

改进方法：

指定合理的规范，统一大家思维，有待讨论。

2.       功能与业务分离：

这个是在测试ES-iVision存在的问题，在测试系统时可能只关注了功能而没有整体业务的把握测试，只注重了某个功能表单上单一的测试，而整个业务可能才是我们测试的重点。

改进方法：

功能用例和业务用例分开组织编写。A）功能用例依据需求界面描述，根据等价类、边界值、错误推断编写，必要时建立数据库，存放测试数据，而这些测试用例都与业务无关。并且可以利用资源找到相关的测试用例，来补充我们设计的不足。B）业务测试用例关注的是表单的执行路径，执行后在系统上产生的一系列反应。这个可依据需求在开发前或与开发同时进行。但此业务功能必须是开发确认正确的。

PS:

以前我们在业务这块有场景测试用例。如发文流程中有多流程时，分场景测试流程。

3.       测试跟不上变化：

开发人员在开发时可能会对需求进行调整，这个问题是在测试UUM时系统管理角色需求就进行调整，所以我们被动的只能跑在开发的后面，我们也做了许多不必要的工作。

改进方法：

有问题及时与开发讨论，走在开发前面调整我们测试用例，测试进度。

4.       发布前轮询很多版本：

某一产品在经过几轮测试后，在发布前可能会为一两个bug要轮询很多版本，在轮询时测试人员不可能再把所有功能、业务全部再过一遍，但是我们此时会对发布版本没有信心，而再走一遍浪费时间精力。

改进方法：

用用例标明测试优先级。这个是在oa1.9中用到的，但可能在后期执行时没有执行。所有在编写测试用时标示优先级，把系统的重点划分出来，在发布前多次轮询版本中只要检查优先级高的就可。

5.       用例审核力度不够：

编写的测试用例无人评审，这也是我们在编写测试用例的随意性、懒惰性滋生，草草了事，没有覆盖全部功能点、业务点。导致产品在发布后存在意想不到的缺陷。

改进方法：

测试用例编写完成后增强评审，先是小组里讨论，然后再外部评审。

6.       易忽略问题：

在执行设计测试用例执行测试，我们可能会忽略很多问题，如系统有安装包的安装测试、界面上一些细节什么的。

改进方法：

在晚上查找相关文档，附件《易忽略的问题》是我看到的，参考。

找到新的工作，但是怎么却高兴不起来。

在现在的公司工作了快2年呢，同事们的关系是非常好，舍不得离开。

舍不得离开这里，就这么难过~~~

但是自己已经决定，只能面对。

面对新的开始，新的领导同事，更多的是新的压力。

希望到了新公司后，同事们相处愉快，工作愉快。

上周四，也就是2008-01-24号晚上，和往常一样从公司回家，在公车站等车时候，我的NOKIA小7被偷。郁闷啊，那是07年五一才买的，一致保养的很好，到现在就和新机一样。很是心疼啊，关键的是手机里有我收藏很久的东西，包括照片，短信，电子书等。更重要的是通讯录，满满的全是好朋友，有一些是大学的同学，平时很少联系，但在过节的时候还会发信息问候的，这些该死的小偷。

干吗要让我遇见这样的事呢，我宁可遇到抢劫的，干不过他把东西拿走，至少知道是谁，现在什么都不知道。

手机被偷，对我来说偷的不止是手机本身，还是手机里的信息，通讯录中的号码，那些都是亲情有些甚至是爱情的号码！！

小偷们啊，你们什么时候才能终止你们这些无耻的行径，对于你们你们拿到手机后就能安心入睡吗~~