测试用例
说简单其实挺简单的，大家都可以写～
但是，其实也挺难的
没多少人能写的很好～
大家都是用什么方式去写测试用例？
其实都可以，适合自己公司就好
可以是excel
可以是word
也可以用工具，如testlink、zentao等
适合自己公司就好
根据老徐的了解，很多公司都是用excel来写测试用例；
那么，用例模板就很重要了，你公司的测试用例模板包含哪些元素？
怎么去着手写用例？
首先，必须要熟读测试理论，至少要知道测试用例设计常用的方法
回复“入门书籍”，先补充下测试理论
什么思路去写用例？
写用例，入口在产品需求
如何把产品需求，转变成测试需求？
先把需求分解成测试点（可以用脑图去梳理思路）
然后再把测试点，细化拆解成具体的测试用例（当然，很多公司是不需要细化到测试用例，直接测试点就OK，具体看公司情况）
你的用例也许毫无价值，简直就是浪费时间，做的都是无用功！
很多同学，可能还在纠结，每个功能到底多少条用例才合适，我应该用什么模板写测试用例，我的测试用例是否覆盖度够...
然而，老徐要讲的是：你的1000条用例，抵不上有用的两条测试点！
为何老徐会抛出这个观点？
也许针对某个功能，你绞尽脑汁，综合运用各种用例设计方法、想象各种可能性、然后非常细致的设计你所能想到的测试用例，花了几天时间，可能会有1000条左右；然而，可能漏掉一些重要的点、老徐关注的某些点并没有涉及到。而且，你花了几天去设计的测试用例，实际测试中并没有按照用例去执行，也没有时间去按照用例执行测试...
为什么会突然写这个主题？
其实很早前就想写，如果没记错，老徐之前写过关注测试用例的这类观点，至少在QQ群说过，多少人记得就不得而知了～
之所以写这个主题，实在是，是时候有必要跟大家正式谈论下这个话题了；最近，老徐一直在参与公司几个测试团队的用例评审会议，会给出一些建设性的建议；发现很多同学写的用例非常充实「可以说很详细」，然而一些非常重要的测试点却被遗漏，如果是这样的测试思路交付的产品老徐是很没安全感的～
那么问题来了，如何用更少的测试点，尽可能的考虑充分各种可能性呢？
跟什么因素有关呢？
答：用例方法、经验、需求理解等等
OK，想知道自己的测试点梳理是否有问题？自己作为一个功能测试是否合格？
完成这个实操就知道了（关注此公众号后，点击菜单互动社区，去完成实操题，直接发帖说说你的测试点，并联系老徐查看～）
老徐提到的测试点，你是否接触过、实际工作中是否实践过？用什么工具去写的？后台留言～
可以看看老徐之前的文章测试用例设计~思路分析
老徐观点：
如果公司只有你一个Tester，真没必要写测试用例了，写测试点吧，提取关键要素～
如果你们的需求老是频繁变化，写测试点吧；因为你的测试用例的更新速度完全跟不上需求的变化速度，每天都在改用例～
如果你们的节奏控制的非常紧凑，完全没时间严格按照测试用例执行，写测试点吧，提取关键要素
如果团队的整体Tester技能均衡，测试点已经能够保证充分覆盖了，写测试点吧，测试用例的意义不大～
如上的观点，并不是代表大家都去写测试点，不用写测试用例了，看每条的前提条件～
没有需求文档，最头疼的问题是不知道开发的产品应该是个什么样，要完成哪些功能，达到什么指标。有哪些细节需要注意的。大家只是口头沟通，过段时间，谁都不知道谁说了什么。
下面几个步骤应该也许有用：
1、首先可以查找其他相关文档。比如产品策划书、Feature List，不可能什么文档都没有吧。我们可以收集一切相关的文档来帮助理解所要测试的产品需要完成的目标。
2、尽量多参加该项目组内的会议。比如需求讨论、设计讨论、计划讨论等会议，尽管没有白纸黑字的文档，但讨论过程中也能让你加深对产品的理解。
3、咨询相关人员。经过以上两个过程，应该对产品有了一个初步的理解，花点时间自己把大致的功能点整理一下，遇到不明确的、有疑问的，可以咨询项目负责人或者相关市场人员，他们应该对整个产品心中有数。
这里有一个前提是，在对产品有了初步了解后，才有针对性的去咨询，否则在什么都不知道的情况下。
第一，对方没有耐心和时间向你介绍整个产品；
第二，对于对方的讲解，估计最多也只能了解个大概，不能很好理解。
4、召集相关人员，对你整理的结果进行讨论。整理以上几步得出的结论，总结成文档，发给相关人员，包括项目负责人、市场部代表、开发人员等，让他们帮助评审check，根据意见对文档不断进行补充完善。当最后通过评审后，这个文档就可以当作依据来设计你的测试用例了。
当然，如果是一款已经上线的产品，可以多去使用产品。有不懂的记录下来，问产品经理。如果没有产品经理，问测试同事。如果公司在职的测试也没有（就你一个测试），问开发同学。
也可以去看历史Bug。通过历史Bug，可以了解到一些你需要关注的东西。