主讲：五娃、老徐
主要内容：测试用例、时间管理
一、测试用例的设计
1.测试用例的定义
定义：测试用例（Test Case）是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求
2.测试用例的好处
（1）测试用例的编写能有效地、快速的熟悉了解待测产品
（2）测试用例的编写、执行的数量，可以评估需求的覆盖程度。
（3）测试用例的细化程度，可以作为阶段性工作排期的一个依据
（4）测试用例的输出可以将人为因素的影响减小，例如编写测试用例的人不能操作执行工作，那么依据用例文档，其他可以进行执行操作。
总结：思路清晰、避免漏洞、跟进测试进展、历史参考、避免重复性
3.何时开始设计测试用例
（1）当需求文档定版后，就可以进行测试点的提炼，开展测试用例的编写。
（2）需求变更：作出评估，确定影响范围；用例是一个迭代更新的过程
4.如何设计测试用例
（1）将产品文档中或者需求文档中的原则（规则）转换为每个用例的检查点
（2）单个用例最小化原则，一条用例只做一件事
（3）先从单个用例或者功能点开始入手
（4）借助一些用例设计方法、如等价类、边界值、因果图
（5）兼容性：如浏览器兼容性、操作系统兼容性等
PS：
（1）设计用例时，一定要注意数据库中数据正确性用例的验证。（数据库用例：与数据库数据对比）
（2）设计用例时，要考虑关联模块的问题。（如：多人合作，模块关联的地方漏测，导致风险）
5.实际工作中设计的测试用例
（1）先根据需求文档匹配模块与角色的关系，即Usecase
（2）输出流程图，流程图的输出是对整个产品脉络的一个熟悉
（3）依照usecase图和流程图、业务规则、以及设计用例方法，输出测试用例
（4）思考：
①用例的评审与更新？
所有用例必须评审，评审完必须有更新，否则说明评审过程不走心
②所有项目都需要写测试用例？
中、大型项目，必须写测试用例
③用例越详细越好么？
最好的用例是任何人都能看懂，不一定是越细越好
编写用例的工具，根据实际情况选择
6.案例分析
.....
【用例·个人感想】
1.关于设计测试用例的指导原则
与工作中现行的规范吻合，很庆幸得到官方认可。
2.关于测试用例最小化
联想到一个前提：测试用例简化。测试用例简化，即把测试逻辑和测试数据分离，把用例中的一些输入、输出等作为参数单独列出，使测试用例逻辑清晰，数据与逻辑的关系明了，易于理解。
【样例：登录】
3.测试用例编写和执行的工作量评估，感觉是一个痛点。
目前是根据需求、测试经验的累积（项目经验+对测试人员能力的把握）来评估。感觉这样的不确定性很大。
是否有规范的、可计量的评估方法？
4.关于用例图+业务流程图
在一些有权限模块的项目会使用这种分析方法。以后工作中需要强化。
5. 关于测试用例的评审
并非每个项目都严格落实。以后工作中需要逐步落实，使得质量风险和责任风险得到把控。
6.是否必须写用例？
依据项目计划的排期和项目需求，时间允许就必须写，时间紧急只罗列测试点。
7.用例的颗粒度？
取决于测试计划的排期。时间多，尽量颗粒度小一点，覆盖率也会大一点。
二、时间管理落地实战
1.老徐如何管理时间的？
2.分享几个现在就可用的方法
（1）上班时间不聊QQ、微信
（2）下班前，把当天工作任务完成
（3）下班前，梳理第二天工作任务
（4）每日事项，按优先级排序（紧急、重要）
（5）利用碎片时间处理琐事（如回复邮件）
（6）利用碎片时间提升（看书、看好文）
（7）不在纠结在某件事上，学会放下
（8）充分利用上班前、睡觉前的时间（写技术博客）
3.祝好，一切皆缘。
4.作业：每天时间是怎么度过的？听完之后，准备怎么做？
【时间管理·个人感想】
每天时间：
（1）上班时间，干活时，控制不住要去聊天（纯净水）
（2）讨论完正事，控制不住要去聊天（为建立友好关系）
（3）下班时间，内心是崩溃的
（4）上下班=2小时，午休1.5小时
（5）家里琐事=2.5小时
（6）百人计划任务2小时（写的多、学的少，相当尴尬）
解决：
主要解决上班聊天造成的低效问题。
（1）要去点聊天窗口的时候，妄想“打手”（意志驱动）
（2）不登陆微信（微信都是纯净水，QQ只用于工作），只通知闺蜜上Q（缓冲期，给点甜头）
（3）手机关机（残忍）
（4）不带手机（暴力）
感谢五娃、老徐分享
