测试用例经验

--用例由哪些元素组成？
　　标题，优先级，预置条件、编号、预期结果，操作步骤

--用例设计方法
　　涉及参数校验；页面字段；输入数据。等价类（类：代表值），边界值（是等价类的补充），正交表，错误推断，判定表，场景法（业务流程图，模块流程图，覆盖流程，用户角度的流程），因果图，如何发散思维

--设计好的测试用例，吃透需求分析，知道用户想要什么样的产品。

　　思路清晰，尽可能发散，按照类别来分类，从整体到局部。用例规范，

 

--用例需要评审，项目组测试工程师（内审），（外审）开发：产品师开发做的，最有评审资格。

　　测试目的的唯一性
　　测试目的明确性
　　测试目的简洁性

 

搭建测试环境事项
　　根据环境搭建文档：DB，服务器，代码包（mt.war）。SVN工具进行资源共享
--开发和测试的环境分开

　　注意前提条件和特殊说明

　　测试用例要全部执行

　　不要忽视任何偶然现象（闪退）

　　加强测试过程记录

　　提交缺陷时与开发的关系处理

　　及时更新测试用例

　　缺陷产生原因
　　需求，设计，编码，其他
　　追踪来源
　　（二八定理）

　　抗药性-》交叉测试

--并非所有的缺陷都要修复
　　1.修复的风险太大
　　2.没有足够的时间
　　3.下一版本修复

--所有未修复的bug都出于“挂起”状态

　　缺陷包含要素
　　BugID
　　Bug标题
　　附件-》抓包/日照/图片
　　复现步骤
　　路径
　　指派给/抄送给 开发
　　状态
--New --Open --Fixed --Rejected
--Reopen --Closed --Deferred --Assigned Open --Hangs

new->open->fixed->closed
fixed->Reopen->fixed
　　注意：不同的bug管理工具，bug状态定义不同。
　　如禅道：激活、已解决、

--严重程度
　　致命：软件无法运行，或者软件的主要功能丧失，或者很大可能性会造成严重不良后果。（不会发现致命bug）

　　严重：软件的次要功能丧失，或者主要功能在一些特定情况下会出错，比如金额计算等。（业务/流程/功能缺失：10%-15%）

　　一般：软件在某些情况下会出错，但是造成的后果影响不大。

　　轻微：在某些情况下会出错，但是造成的后果影响很小（提示信息/用户体验/建议）

--优先级
注释

测试报告包含哪些内容？
　　3.1.1数据统计
　　3.1.2遗留bug情况
　　3.1.3测试风险
　　3.1.4测试对象评估
　　3.1.5测试结论

问题
--测试过程中有哪些输入/输出件?(参考资料/交付件)
　　参考资料：
　　　　《用户需求说明书》《概要设计说明书》《详细设计说明书》《用户手册》等
　　交付件：
　　　　《测试计划》《测试用例》《bug清单》《测试报告》

--测试的启动条件/什么时候可以开始测试？
　　1.测试用例已写完并评审
　　2.测试环境已经准备好

--测试什么时候可以结束/版本达到公司上线的标准是什么？
　　1.测试用例已执行完成，100%的覆盖到需求
　　2.所有bug基本已得到解决，除非遗留几个比较轻微不影响用户使用的bug
　　3.经过几轮测试后，版本质量已稳定，达到公司上线标准

　　4.测试计划包含哪些内容？

评审给你提过哪些问题：有些场景没有覆盖到，烟的条和烟的包

　　5.用例评审，将流程细化分解为功能点，通过用例一一覆盖

　　6.具体情况具体分析，用例背景，项目阶段

测试用例设计经验

　　专注一个点的测试

　　发散思维

　　把握关键点

日期三条用例：昨天，今天，未来
日期过渡太长。普通情况不测试

时间有限，抓住重点

附件：两条用例，限制条件测试用例

冒烟：借还款

下拉框：第一条，最后一条，中间一条
金融一一测试

转载于:https://www.cnblogs.com/zsjlovewm/p/10535949.html