您认为敏捷下到底要不要详细的测试用例的存在？

敏捷已经相当成熟敏捷宣言中：

个体和互动 高于 流程和工具，工作的软件 高于 详尽的文档

那么以前教科书式的case设计还有必要存在吗？

那如果没必要，敏捷下如何搞定测试测试用例形式、内容、方法呢？

参考答案：

1、我们可以先考虑以下三个问题：

（1）测试用例在软件测试中的作用

（2）测试用例给测试工程师工作中带来的优缺点

（3）测试用例为何而存在

以上三个问题，无论在哪种开发模式下，是我们都逃不掉的实际问题，所以case需要在任何开发模式下存在，其次，就是要以什么形式存在，个人建议：根据团队的规模、公司的流程、以及测试资源的多少、敏捷应用的程度等方面综合考虑，是否采用哪种形式来呈现我们的TC不是非常重要，重要的是能用20%的TC测试出80%的问题，最终保证产品的质量。

比如我们分项目：

（1）活动类项目，比如开发周期为一周的项目，我们会采用xmind进行业务的梳理，测试点的罗列。

（2）较中型的项目，整个开发周期为一个月以上的项目（当然每周会有版本完成），我们会先罗列测试点，然后转换成详细的用例操作步骤（包括：不同的前置条件、详细的操作步骤、详细的预期结果、用例的不同等级等）用例最终会导入到testlink中进行统一管理和维护。

2、既然是敏捷，那么就必须要快。开发、测试、发布快。

测试如果要快，首先要定位好每一次sprint都要清晰划分，准确理解，发现的问题跟踪管理要及时

所以关于case,个人觉得最好还是有，但是应该区别于教科书式的用例，测试用例颗粒度不应该那么细，应该是测试点的形式出现，列出有条理的测试点有助于测试，这样可以解放设计测试用例的时间，但是也不能放过系统更新的功能，用测试点的形式覆盖功能变更。

测试用例（点）应该从以下方面考虑：

（1）重点关注当前迭代版本修改的内容

（2）评估受影响的模块

（3）测试和回归测试重点系统模块

也就是说从下需求到开发完成，测试可能没有时间写测试用例。但是写测试点应该还是来得及的。测试点要覆盖新功能，以及影响到的其他模块。此外，我觉得敏捷模式下最重要的是，团队内部无论是开发还是测试，必须对业务非常非常熟悉，才能做较短的时间内拿出最有效的开发或测试方案。测试和开发要紧密配合，测试内容除功能之外，要用实际数据去跑流程，更能发现出因为时间紧而无法在功能测试中很难发现的问题。

3、从测试的角度看还是要写。

敏捷的要求其实是测试用例的自动化，传统是文档化可以被别人执行，现在是自动化执行，所以没问题，做不了自动化脚本实现，还得文档化明确哪些用例执行了，哪些用例没有执行，然后在详细点上做标记。这样也有利于自己沉淀业务知识，为以后提供参考！