TA的每日心情 | 无聊 3 天前 |
---|
签到天数: 1050 天 连续签到: 1 天 [LV.10]测试总司令
|
每当写测试用例时我都感觉到我在做文员?
码着码着一双发现BUG的眼睛就闭上了 ~
从业测试行业多年,至今编写测试用例不下少数,总体对自己编写测试用例不是很满意,百度检索与同事切磋学习总结以下内容分享给大家:
01 先简要说下个人之前梳写用例错误点
那么我们为什么要花费大量的时间用在写测试用例上面呢?这里只简述我自己在工作中觉得编写测试用例对我自己有所帮助观点:
1.通过编写用例反推程序在设计上是否存在逻辑错误
2.编写测试用例能够有效提高功能测试覆盖率
3.编写测试用例能够加深你对业务熟悉程度
4.编写测试用例能够让支援版本测试同学快速执行有效的测试
5.编写测试用例能够让测试部内部人员相关交叉学习他人的编写方法
6.锻炼锻炼自己的语言组织能力,一份好的测试用例当然是所有人都看的懂!
所以大家不要小看这个编写测试用例!!!
02 这里我们一起将编写测试用例有效方法小小的码一码(大家可取其有用,舍之无用之处)编写测试用例的三个切入点:
1.设计前:
a.先有用例设计,由迭代放远到从整个产品名出发,(这里可以用Xmind梳理相关结构)
确定此迭代目前的测试范围、测试目标;然后根据目前该版本开发的新特性做相关旧功能衍生(有改动的,涉及到数据结构改变的等)测试点都不能放过;
b.确认好以上内容后,再细化范围到具体对象>>>具体功能,确定设计用例技术和测试方法,再来编写用例(使用excel根据每个细分功能模块编写测试用例;优先级由主到次)
2.编写中:
通过编写过程思想发散想象>>>通过实际场景反推程序有哪些已知错误设计等(对应测试用例做上标记)>>>项目组内部反馈>>>进行确认>>>需求文档更新补充修改测试用例
3.执行后:
测试执行后>>>通过Bug反推>>>修改补充用例>>>继续执行Case
三者相结合才会产出一份完美有效的测试用例:理论>>>实践>>>理论过程
03最后简要补充一下编写测试用例几点规范:
- 标题:一句完整的话(不超过30个字符)
- 条件:条件明确(系统是否存在是否需要拟造或第三方备注清楚)
- 步骤:步骤完整(从登录>>>到意向执行流程)
- 预期:预期简洁(肯定句)
总结:测试用例是测试设计的一个产出物,它直接体现测试设计的思想,一份漂亮的测试用例不仅仅是设计思路的优秀体现,更是便于流转和执行,具有可读性、传递性。也充分体现你个人的思维、测试相关熟练程度、很加分!
|
|