昨天测试的一个单子，发现需求很不清晰。

1、需求文档很不清晰，其实这个文档不能算需求文档，这是一份内部培训时，售前和工程对系统提出的要求和改进的记录。
既然是现场记录，难免很简略、也不是很清晰。这种文档应该先经过领导审核，并整理变成需求文档，而不能直接放在TD中做为这个任务单的需求文档。
比如：
     “ 12.超时预约工单如何自动提醒营销人员 ？”  ----这是用户提出的问题，在本次开发任务中我们用什么方式解决用户的问题呢？需求文档应该给予说明，测试才知道测试什么。
   “13.报表：营销任务排序” ----应该具体指明是查询条件，还是报表数据字段

2、开发人员在该文档上做了三种颜色的标记，但是并没有注明三种颜色各代表什么意思。

3、开发人员并没有完完全全根据需求来开发，需求文档中“2.黑名单审核界面，增加黑名单添加人姓名、工号” ，但开发出来的界面，只有姓名，没有工号，这是比较简单的需求，但开发正确率才50%。

总结：测试不仅要测出功能项的BUG，也要对开发人员、及项目组长的工作过程中的缺陷大胆指出，大家相互提出不足，才能进步。

在一个单中，开发人员update XX这张表时没有加where 条件，结果把所有记录都给update了，结果维护页面报错。这种BUG非常危险，会导入所有表单的页面都报错。

总结：以后测试过来中，都要检查一下脚本中有update 和delete 的地方，看看是否加了where 条件！将这个测试步骤养成习惯。

今天测试很有成就感，测试到了很多有用的BUG，XX是在在用系统AA上做修改的，由于当时设计AA的时候没考虑到多个公司的问题，因此这次新增了XX这家公司就出现很多跟问题。

另外，今天还发现了写更新先剩余时长（当前可用时长  — 上一通通话时长）是在编号/密码验证的那个服务里面，也就是每次调用一次这个服务都会执行一次（当前可用时长  — 上一通通话时长）这个操作，导致剩余时长不正确。
更新先剩余时长放在编号/密码验证时更新本来就有点不符合逻辑，这样的逻辑容易出BUG，应该在通话结束后马上更新会更好，数据也会更实时，不过像开发组长反馈了，但目前还无法实现通话结束后马上更新，暂时按这种处理逻辑。

我做测试半年了,这半年主要是做用手工做功能测试,期间学到很多功能测试的知识.

但我自己觉得还不够,而且发现目前的状态很难再突破什么,我想接下去这段时间如果有空,想跟开发人员学学开发,从开发中提高自己的测试水平,但我不知道这样的想法对不对.

请大家给予指导.

目前,公司只采用手工功能测试,平常就是结合数据库对系统功能进行测试,没用什么测试工具,

这样做是不是很不好,测试一定要用测试工具才能更好的找到BUG吗?但公司规模不大,用测试工具不太可能,好像用

目前的手工测试也够用了