首先是测试用例数据的来源，测试用例中的数据来源于需求，规范的需求人员会将用户的准确信息汇总传达给项目组的开发和测试人员（当然需求不准确是另一回事），测试人员需要验证的是开发的实现是否符合需求的预定目标。在项目开始的时候，开发人员着手设计框架和编码，我们测试人员则排计划和准备测试用例。刚开始的时候觉得没有需求文档一切行动就像失去目标一样。有时需求文档确实跟不上进度，测试人员是不是就不用工作等着呢？完全不是。其实测试人员获取该产品的详细信息有很多渠道，文档只是一种其中一种文字化、实例化的方式，比较规范。测试人员完全可以和开发、团队Leader沟通、交流，将自己对这个系统的含糊不清的地方一一明确，这样既可以弥补需求文档不足带来的不便，也加深测试人员对该系统的理解。对于需求文档有遗漏的地方，测试人员可以通过需求评审（由客户、需求、开发、测试一起讨论）进一步明确需求。
其次是编写用例了。个人编写用例的习惯是用例能够覆盖这个系统的功能点即可。用例设计的元素一般由ID、名称、所属功能模块、测试前置条件、输入数据、执行步骤、期望结果和备注组成，当然为了规范执行，一般情况下还会加上执行人、执行时间和执行结果。譬如设计一个创建对象或者子节点的用例，个人在测试步骤中只会写“正常登陆系统后，点击创建对象功能，输入对象名称，提交保存。”期望结果就是对象能够准确无误的创建。这样一看，好像少了点东西，对，边界值检查（包括空值检查、最大值和超过最大值检查以及特殊字符检查甚至同名检查）。个人觉得边界值检查的方法确实好，能够发现很多缺陷（前人总结的真理）。不过经过权衡后，我还是没有将这些譬如“输入超过20个字符检查”、“不输入任何值检查”、“输入相同名称检查”等字样写在用例里。为什么？
声明一下，我并不是反对用例写的很详细，我只是觉得上述内容填写（又叫过度设计）对测试用例来说没有必要，有点本末倒置。一来简介版的用例可以很小，很方便维护，同时后续需求变更后很容易修改甚至不用修改；二来给用例执行者最大的自由（我不反对将编写该用例时自己想到的闪光点写在里面），对于熟练的测试工程师来说，看到输入框的第一反应就是不输会怎么样，超过了会怎么样，不满足你的要求你会怎么样，可能是自然反应吧（我就是这样，已经掉进这个沟里了），对于新手，我可能会加一行“注意边界值”，可能做我的新手可能比较“倒霉”哈，我一不会告诉你用例设计的方法，二不会告诉你用例执行思路，前者我认为是有志干这行的必修课，必须自己主动掌握，我仅能带你入门而已，至于后者则靠自己不断测试不断总结，每个人都不一样，找到那个最适合自己的。还有一个不好的地方就是太详细的用例给人的感觉就是我不需要思考了，反正设计者已经想得很详细了，导致编写用例的时候绞尽脑汁，执行的时候完全可以被程序替代了。那样也很难发现这个系统的隐藏的缺陷了。当然对于在设计阶段就想的很详细的用例来说，不会因为测试人员的疏忽而导致潜在缺陷被遗漏，毕竟用例规范了测试人员的行为。
用例编写过程中不明白的问题可以先记录下来，在用例编写完成后，将所有不明白的地方汇总，提交需求确认，待确认后补充对应的内容。
测试人员的工作是规范别人（需求、开发）的工作，我们自己的工作也必须规范，必须接受项目组其他人员的检查，用例评审就是一个很好的方式，需求、开发和测试在一起讨论达成最后的结果。测试人员负责修补其中不满足的地方。
接下来就是执行用例的习惯了，个人喜欢在执行之前通读该功能模块的所有用例，然后统计下需要测试的功能点，对执行的顺序初步排序，这样可以能提高效率，不至于顾此失彼。譬如有6个用例，分别是对对象的增、改、删和对对象关系的增、改、删，编写用例时的一般按照这个顺序下来，执行的时候如果这样的话那明显增加了工作量，改成对象的增、改完成后执行对象的关系，关系执行完成后删除对象。既完整的执行了用例、测试了功能，又能做到效率最大化。
记得一位资深的工程师说过：在一个产品的迭代两轮过后，不加入新功能的情况下，仅凭用例是很难发现问题的。而实际过程中也确实如此，正是有鉴于此，个人比较倾向测试用例只要设计的能够完整覆盖系统的功能点即可，至于新手的执行的问题，测试用例是为了规范测试人员的工作，将无限的测试工作有限化，并且方便管理和复用，好像并不具备新手入门手册这个功能（可以通过其他方式解决，不必在测试用例中过分迁就他们）。
权且一家之言，不对之处欢迎讨论。
