敏捷宣言：

        个体和交互比过程和工具更有价值；

        能工作的软件比全面的文档更有价值；

        顾客的协作比合同谈判更有价值；

        及时响应变更比遵循计划更有价值。

(满有趣的，虽然心中有点抗拒，但我觉得从某方面来说是有效的，只是如果能用不太规范的手段来达到规范的结果呢？这是个学问吧)

测试用例的粒度

        测试用例可以写得很简单，也可以写得很复杂。最简单的测试用例是测试的纲要，仅仅指出要测试的内容，如探索性测试（Exploratory Testing）中的测试设计，仅会指出需要测试产品的哪些要素、需要达到的质量目标、需要使用的测试方法等。而最复杂的测试用例就像飞机维修人员使用的工作指令卡一样，会指定输入的每项数据，期待的结果及检验的方法，具体到界面元素的操作步骤，指定测试的方法和工具等等。 

        测试用例写得过于复杂或过于详细，会带来两个问题：一个是效率问题，一个是维护成本问题。另外，测试用例设计得过于详细，留给测试执行人员的思考空间就比较少，容易限制测试人员的思维。 

(同意，有时候觉得写case是个很无效的过程，尤其是反复在写一些很熟悉的case（也许反复做这个工作的我就有问题）)

        测试用例写得过于简单，则可能失去了测试用例的意义。过于简单的测试用例设计其实并没有进行“设计”，只是把需要测试的功能模块记录下来而已，它的作用仅仅是在测试过程中作为一个简单的测试计划，提醒测试人员测试的主要功能包括哪些而已。测试用例的设计的本质应该是在设计的过程中理解需求，检验需求，并把对软件系统的测试方法的思路记录下来，以便指导将来的测试。 (这里有我点不赞同，如果不理解需求，如何能写出高效的用例呢？只能说在设计的过程中加深理解)

......

要把测试用例当成“活”的文档（Effective Software Testing : 50 Specific Ways to Improve Your Testing（这是什么？） – Elfriede Dustin），因为需求是“活”的、善变的。因此在设计测试用例方面应该把敏捷的“及时响应变更比遵循计划更有价值”这一原则。 

        不要认为测试用例的设计是一个阶段，测试用例的设计也需要迭代，在软件开发的不同的阶段都要回来重新审视和完善测试用例。 (同意，设计用例不应该是一个阶段，那是否很细致的划分阶段本身就有问题呢？)