终于忙完了考试（不要问我成绩，我仅给一个浅浅的笑），小酋又可以撸起袖子继续加油码字聊测试了。看到这些天又有几十位朋友关注公众号，小酋瞬间干劲满满，腰也不酸了，头也不晕了，打字也更利索了。
闲话少谈，小酋今天要带大家一起思考关于测试用例的几个问题。
NO.1：测试用例该写还是不该写？
该问题特别容易在项目时间赶、测试时间短、测试需求散的情况被提出来。
测试时间这么赶！还写用例，杀了我吧…
测试时间本来就不多，就1天，写用例？铲铲，不干～就不干！
需求都不完整（或者干脆口口相传），那测试也不写用例，需求写好再说～
省略若干不写的理由，这些都是“伤心”的理由……
那小酋，你说写不写？
我要大声的说出来：写！
作为一名专业的测试员，用例是必须要写的。但是，我们可以调整方式方法～
用“思维导图+测试点”的方法简化用例就不错。当然，每个团队、个人也可以根据具体的专业技能、经验情况决定简化的方式。简化的原则是：写的快、执行快、大家能明白（不要出现：你永远不懂我用例，像白天不懂夜的黑）。
其次，“测试左移”。这个东东不是新话题了，可以看看小酋前面写的文章《软件测试左移、右移和DevOps小结》，应该能给你带来些许启发。
（以上仅个人愚见，如果有人能说服领导，说服项目兄弟，测试不用写用例，我觉得很NB，大牛不妨秀一下。）
NO.2：测试用例是自己写的，所以执行测试时不用看用例？
这在测试中很普遍。觉得用例就是自己写的，那执行时就不用看用例了。
以小酋现身说法：我可能记忆确实太渣，如果不对着用例执行，对于稍显复杂的业务常会出现遗漏。经过小酋再三尝试，终于在自己“渣”记忆的打击下，每次认认真真的对着用例执行。并且，会对执行过的用例进行标识（成功的、失败的、未实现的、阻塞的）。
原则上我也要求自己的搭档如此执行。这样即能避免遗漏，又能使我掌握整个项目的测试进度、测试情况，并能据此做出一些应对措施（如：是否需要加班？开发转测质量如何？是否需要申请更多的测试资源？测试能否按预期交货？测试策略是否需要做调整？）。
过目不忘，我不需要也不重要，做一个傻子多么好^_^
NO.3：测试用例该不该维护？
测试用例执行完就丢，洒脱。这似乎是很多测试团队常见的做法，包括小酋自己也存在这样的情况。
但是，记住，用例作为测试最重要的一项劳动产出，为了价值最大化，是应该维护的。至少，用例“有用”（这里的有用，是指对后面迭代测试或兄弟项目高价值部分）的部分是这样。
什么是有用的部分？
小酋认为：重要（主要）功能部分，基础用例部分。
重要（主要）功能部分很容易明白，就是优先级，需求等级高的部分用例。
基础用例：这更多指通用用例。如登录、注册通用功能；样式、交互检查等统一要求的用例。这些用例往往适用于公司多个项目，每次只需要做少量的调整即可使用。
不要推开我，不要扔下我，我觉得你还需要我。
NO.4：“极速迭代checklist”是什么东西？
这是小酋随便取的一个名字，如有雷同，纯属巧合。
极速迭代checklist是针对试验室环境、生产环境各制作一个回归测试list，原则是保证主要、高频使用功能点被覆盖。可以是手动执行的，也可以是自动化执行的。
不晓得大家有没有这样的经历：
因为某个意向不到的高频功能突然失灵导致出现线上事故，紧急撤下修复重发。
测试环境一切OK，但到了线上就突然抽风了。
开发人员一再保证这是个小改动，不需要迭代测试，产品也同意不测立马上线，但到线上还是捅了娄子，出问题啦~
小酋经过两三次惨痛的教训后，决定强忍着头上锅儿的压力，理出两份checklist，把最重要、最高频使用、最容引发“血泪”的测试点分别列入两份checklist，原则是：选的点要准、执行速度要快、时间要控制在30分钟内（可以自己衡量，但不建议超过1个小时，失去了极速的意义）。
自此，锅儿少了，小酋再也不用每次发版后时时刻刻战战兢兢地防着锅从天降。
哪怕后面出现问题，我们也可以说：不是你的错，也不是我的错，这是很难规避的祸。
希望大家都想想这些问题，如果有想不明白的，可以给小酋留言，让我们一起继续想。让我们把一个人思想上的孤单，变成一群人思想上的狂欢。
最后，如果大家觉得的好，有钱的捧个钱场（只为突出后句^_^），没钱的捧个人场，看后分享下，小酋下次送碗“泪牛满面”答谢各位客官~
关注小酋微信公众号 ceshibuluo （51ste软件测试部落），更多精彩内容等着你~