发布新日志

  • 查询界面测试

    2011-02-22 17:07:39

    查询界面测试要点:

    1.各种条件组合能否相应查询出相应结果

    2.各种查询条件都为空或为初始状态时能否查询出全部结果

    3.哪些条件可支持模糊查询

    4.查询条件有时间控件,查询结果有没有包括所设置时间,

    5.查询页面如果有重置按钮,能否将查询条件回到初始化

  • 改善用户操作的几点建议

    2011-02-22 16:38:23

    改善用户操作的几点建议     

       测试人员测试目的之一是让软件功能最大程度符合需求,满足用户的需要,一个应用软件他的最终目的应该都是帮用户解决问题、为用户服务,因此评价一个软件的好坏,其实最高权威人士应该是最终用户,最终用户用了软件后觉得好用,能帮他解决问题,能为他服务,那么他会觉得这是个好软件。因为测试人员在执行测试的时候应该多站在最终用户的角度来思考,除了发现BUG外,能给开发人员提出一些改善软件操作的点子,比如:让软件的操作更简便,这样可以节省用户时间;又如:改善界面的布局,缓解用户的视觉疲劳。影响用户评价是“好软件”还是“烂软件”的很重要因素,往往是软件的这些“表面”的东西。

       这里谈谈,测试人员在测试的时候,从哪些方面向开发人员提出改善软件的操作及界面。
    1、提供批量的功能,节省用户操作时间。
    对于数据量比较大的列表,用户一条条去操作数据必然会很浪费时间,而且久了会觉得该功能很烦、不好用。如果能给用户提供批量的功能,比如:批量修改、批量删除、批量导入,将大大节省用户时间,用户会很高兴,越来越依赖你的软件。

    2、把重点信息集中在同一页面,而非多个弹出窗口。
    对于用户使用频繁的功能,程序尽量少用windows.open,尽量把相关的信息放在同一页面,这样用户可以在同一个页面关注他想要的信息,而不是多个窗口间切来切去,显得很乱。原因如下:
        1)弹出窗口比较慢,多弹一个窗口会让用户多花等待时间;
        2)相比在同一窗口操作,用户操作时鼠标从一个窗口移到另一个窗口,显得麻烦、慢、乱,同一窗口中可节省用户操作时间;
        3)弹出窗口多了,用户得很费力的移动窗口。
         windows.open慎用,适用于使用比较少的功能模块,比如后台维护类的模块。

    3、尽量在界面上隐藏不必要的信息,当用户需要时再展开,这样界面显示简洁,又能重点突出。
         比如:在界面上弄个“更多”按钮,一进页面只展示用户常关注的信息,只有点击更多时才展示其他信息。

    4、界面上各个控制突出重点:比如查询界面,把查询输入框设置得比较大而显眼,这样做的好处:
        1)可输入很多查询文字
        2)输入区域大了,用户需将光标移入输入框时,可点的范围就大(容易将光标定位在输入框)

    5、对于信息展示类的页面,可采取“摘要”的方法,标题下面显示摘要,这样用户可以方便的通过浏览摘要了解大概内容。

  • 需求不清晰

    2010-02-24 15:38:59

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

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

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

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

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

     

  • update 脚本的BUG

    2010-02-24 15:34:11

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

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

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

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

  • 先从事一段时间的开发

    2008-12-12 14:27:32

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

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

    请大家给予指导.

  • 公司测试状况

    2008-10-16 16:06:03

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

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

    目前的手工测试也够用了

Open Toolbar