diff --git a/ch6/README.md b/ch6/README.md
new file mode 100644
index 0000000..ff40768
--- /dev/null
+++ b/ch6/README.md
@@ -0,0 +1,37 @@
+# 6. 用户故事验收测试
+
+![ATDD](images/atdd.jpg)
+
+写验收测试的好处有很多，其中之一就是很多客户和开发人员讨论的很多细节可以通过验收测试记录下来。
+
+比起写冗长的需求列表，像“系统应该...”可以用测试来充实很多用户故事的细节。
+
+一种比较好的观点提出，测试是一个两步流程：
+
+- 第一，将测试要点记录在故事卡的背面，任何时候发现新的测试，都可以记录到故事卡的背面
+- 第二，将测试要点编程全面的测试，这些测试可以用来掩饰故事已正确、完整的实现
+
+比如，一个记录在故事卡背面的测试要点的例子，“公司可以用信用卡支付发布工作的费用”，这个故事卡的背面可能一下这些测试要点：
+
+- 用Visa信用卡、万事达信用卡和运通卡测试。（通过）
+- 用大莱卡测试。（失败）
+- 用正确的、错误的和空的卡测试
+- 用过期的信用卡测试
+- 测试不同的交易金额（包括超出信用卡额度限制）
+
+这些测试要点记录了客户提出的一些假设。
+
+> 假定在招聘网站的例子中的客户写了一个故事“求职者可以查看指定工作的详细信息”。
+>
+> 客户和开发人员讨论这个故事，确定一些需要显示的一些工作信息 -- 职位名称，描述，工作地点，薪水范围，如何申请等等。
+>
+> 然而，可以了解并不是所有公司都会提供所有这些信息，所以他希望网站能够自动处理未填的数据。
+>
+> 比如，没有提供薪水信息，客户甚至不希望提供“薪水范围”标签出现在屏幕上。
+>
+> 这应该在一个测试里反映，因为程序员可能会假定系统发布工作模块要求所有工作都提供薪水信息。
+
+**验收测试也提供了确认故事是否被完整实现的基本标准**。有了这样的标准，我们就知道什么时候某件事算是做完了，这是避免了花太多或太少的时间和精力的最好方法。
+
+> 举个生活的例子，我妻子烤蛋糕时，她的验收标准就是在蛋糕里插一根牙签。如果牙签拿出来是赶紧的，那么蛋糕就算是做好了。
+> 而我则是将手指插入蛋糕，然后尝尝，以此来验收测试她做的蛋糕。
\ No newline at end of file
diff --git a/ch6/images/atdd.jpg b/ch6/images/atdd.jpg
new file mode 100644
index 0000000..e471c9f
Binary files /dev/null and b/ch6/images/atdd.jpg differ