发表于: 2017-09-02 23:58:13

1 1039


今日完成:下午网上看网页的常用测试点以及关于测试点 测试用例的讨论,我觉得还是有一些特殊的用例数据没考虑到 一些地方如列表的测试的测试功能点也不完善。看来我还得改我的测试点和用例。嗯 已经改了好几次了 还得继续啊


收获:坚持写测试点吧,刚开始学的话确实可以写的细致些。在不断写的过程一定可以整理自己的思路,更加熟悉需求。下面是我总结的一些注意点:

        1 熟读需求或者玩透软件操作 这是大前提

        2从一个大的模块开始 参照需求、软件 拆解功能点 

        3 扩充测试点 细化为用例 可借助一些方法 如场景 边界 等价类 因果图等

       4 测试点后用例之前要从头到尾检查一遍 

       5还可以在第二天睡醒后只看测试点在检查一遍(相比第4步,这时头脑比较冷静 清新 更容容易发现一些深层次逻辑问题)若果你的测试点有逻辑 条理的支撑 这时间只看测试点就能比较详尽知道软件模块要干嘛 有哪些重要实现

      6用例不一定每条都得跟测试点对应 有些事重复的 可灵活处理

      7测试点是需求覆盖率的一个重要依据 保证少遗漏 写的测试点背后一定有着某种逻辑在支撑 而不是看需求想着一处写一处 顺着思路把重要 主干的写出来 细枝末节或实在不太清楚的先简单带过后面补充(不要让它打断思路) 犹如倒过来的一棵树 先摸清主干和主要支干 你就大概知道它啥形状了

     8没有对比就没有伤害 更体现不出差距 多看别人的测试点和用例 你就就知道自己怎么样 别人怎能样 然后该干嘛干嘛

好吧 以上也算是回答了任务4深度思考的1问和2问 至于3问测试用例的精确度 我觉得有3个方面

1人家看得懂 能执行

2能减少漏测

3根据时间 进度 用例优先级 重要级别作适当变化

好吧 我觉得说了当没说 好像是废话 可有时好像确实是这感觉 废话它又不是废话 


后面计划 改测试点用例 看其他人的


返回列表 返回列表
评论

    分享到