我一直在试验XP中的一些概念，如下所示：
到目前为止一直很好，直到我有一个重要的残余：
如果没有任何代码，我如何设计我的测试用例？我有什么基础来设计它们？从简单的假设？从最初的要求？
或者这是UML图和“分析阶段”适用的地方吗？
只是不得不问，因为在我读过的一些XP书中，几乎没有讨论任何图表工具（有一个建议我想出了伪代码和某种流程图......但它确实不帮我写我的测试）
答案 0 :(得分：6)
敏捷流程通常是基于纸张的，但这会产生一些在企业环境中可能不正确的基本假设。
即使您的团队已经分发，您仍然可以使用笔和纸（使用彩色扫描仪）或白板（使用便宜的数码相机）。以这种方式捕获图像比尝试使用更专业的软件工具更敏捷，因为您倾向于专注于解决问题，而不是驱动工具或调整视觉呈现。
如果没有任何代码，我如何设计我的测试用例？ 我有什么基础来设计它们？ 从简单的假设？从最初的要求？
如果您足够幸运，可以从最初要求和与“现场客户”讨论的用户故事开始。
这个想法是你在代码之前编写测试，以便你知道什么时候完成。从开始编写测试到测试运行和通过的点，代码可能无法正确运行，甚至无法编译。这类似于传统的“测试最后”开发，除了代码被破坏的时间往往更短，并且保证最后有一个测试。
它改变了“我接下来要编写什么代码？”的动机。 “接下来要写什么测试？”只要您对要做的事情有一个基本的了解，第二个问题就更容易回答。
答案 1 :(得分：5)
如何设计我的测试用例 还没有任何代码吗？从何而来 我必须设计它们吗？从 简单的假设？从最初开始 要求？
要编写测试，您不需要任何代码。您知道您的输入，并且您知道您的预期输出。因此，您可以设计一个测试用例来实现它。
我认为UML和XP之间没有任何紧密关系。 UML用于设计软件，XP是您开发该软件所遵循的过程。所以请尽可能澄清问题。
答案 2 :(得分：5)
测试用例来自初始要求。它们指定了你要构建的内容，那么测试还来自哪里呢？
您可能会发现一种有用的技术是将一个特征分解为三个元素：给定，何时，然后。 给定是初始数据，当是程序调用时，然后是期望的结果。关键是，您无法分析的任何要求可能不正确，或者至少需要进一步的细节。
Google测试团队非常喜欢这种方法，并在博客上发表了大量博客。 Find out more.
答案 3 :(得分：2)
XP没有“分析阶段”。
您不需要使用带有XP的图表工具，但如果您选择使用它，则无法阻止您。
您想要建模什么？
听起来您想要描述问题域（即用于分析的建模）而不是记录实现。 XP不像传统方法那样工作，其中一位专家做“分析”而另一位做“编码”。在XP中，分析师可能是一名开发人员，与业务中的某个人一起工作，共同打破用户故事并对其进行估算。
您通常不会开始记录测试用例 - 我们在代码中编写自动化测试，无论是代码还是可执行规范，例如JBehave或cucumber。它与绘制图表的努力差不多，但投资回报率更高。