测试用例就是把软件测试行为做一个科学化的组织和归纳，用来指导测试行为。
一般需求入基线后，测试人员开始介入项目，对需求进行分析，并根据自己对需求的理解设计出详细的测试用例。这样在测试执行时，按照设计好的过程去执行，避免由于人为的原因使测试不全面。
在设计测试用例的过程中，测试人员也可以根据自己的理解，对需求提出不同的看法，或者发现需求中某些功能描述得不够详细或者有歧义，提早发现问题，降低项目风险。
怎么写测试用例是老生常谈了，网上也有很多正式的教程，什么正交法、等价类、因果图、场景法等等，这些方法推荐都深度学习和掌握。
作为一线的测试人员，测试用例是每天都要写都要看的，每个人都会有写测试用例的方法和习惯，此处不具体展开讨论方法的优劣，只谈测试用例颗粒度的理念。
测试用例颗粒度越大，即每个用例覆盖的feature范围越大，明面上测试的工作量会变小，测试人员会有更多自由发挥时间，例如进行更多的ad hoc测试，但是会有较大的风险，项目质量将严重依赖于测试人员的能力和责任心。
测试用例的颗粒度分得越小，测试用例编写和执行的工作量就越大，测试人员容易陷入呆板的机械的执行过程，但是开发越容易复现bug，所以颗粒度需要针对不同场景，具体研发流程，采用不同策略。
比如某个项目的人员小李是远近闻名的粗心篓子，那么在测试这个项目时，设计测试用例的时候就要越细越好。
另一方面，如果测试用例写的细，开发也认真按照用例写代码（TDD），那么bug就会比较少，产品交付质量会较高，维护成本也会很大，甚至大到无法维护的成本，需要辩证的去看这个事情。
测试团队需要有一套或者多套持续维护的用例库来对应各种业务测试场景。例如当app常规发布时，需要回归主流程，这样的一套用例库不需要很多。
但是假如微信sdk发生变更时测试需要回归全部涉及到微信的场景，这样的用例库势必变得非常庞大，以上两个例子说明，常用的回归用的测试用例库是必要的，也是需要提前做功课准备的。
理论上测试用例和bug是相对应的，但有时候也会发现意外的bug，最好能跟开发同学一起排查直到最后确认问题，然后告知对方这个bug需要提交到系统中记录，让对方修复后改状态，然后再去做验证。
全部完成后将这个bug的场景补充录入到测试用例库，再根据优先级判断是否排进每次回归的用例集合以及自动化用例集合。
在项目不断迭代的过程中，也会有需求变更，那么跟随需求的不断迭代，测试用例也要及时更新，新增和删除，保持“测试用例新鲜”。
测试的时间往往是被各种紧急项目切割的支离破碎，因此需要将各种碎片时间充分利用起来，梳理测试用例或者学习一些自动化知识。
梳理测试用例的过程有点类似于打造不同的解决方案。
根据不同的场景切面，把分布在各处的测试用例整合在一起。为什么不在项目中进行这些工作呢，因为许多项目往往没有大段的时间让你去梳理测试用例，尤其是一些开发没有工作量，仅需要测试进行回归的项目。
所以，提前准备这些测试用例集合，打造你自己的测试解决方案，以备不时之需。
测试用例要尽量避免错别字，认真对待自己交付的作品，这种低级别的问题要尽量避免，尤其需要当众评审的部分，自己应该反复检查几遍，避免出现纰漏。
测试步骤的描述应该条理清晰容易理解，即使换一个人也能按照步骤去执行。最后，测试交付的产出物有测试计划、测试用例、缺陷报告、不同阶段的测试报告，这些就是测试的作品，应该力求完美，换句话说，上级领导能看到的就是这些东西，想要在职场上不断发展，这些东西必须扎扎实实的。
有了坚强，你就有了战胜一切的勇气，你就有了生命的战斗力，这才是你活下去的理由。坚强的活着，你的理想，你的追求，才有了最终成为现实的渴望。
相信梦想是价值的源泉，相信眼光决定未来的一切，相信成功的信念比成功本身更重要，相信人生有挫折没有失败，相信生命的质量来自决不妥协的信念。
与你内心最贴近的东西，切莫等闲视之。要像监守生命一样监守它们，因为一旦你丢失了它们，生活就会变的毫无意义。