📝 docs(1.0): 添加验收测试和测试类型部分

refs #3

Signed-off-by: Tony Deng <[email protected]>

SUMMARY.md

@@ -58,7 +58,7 @@
         * [6.2. 客户定义测试](ch6/6.2.md)
         * [6.3. 测试是过程的一部分](ch6/6.3.md)
         * [6.4. 多少测试才算多？](ch6/6.4.md)
-        * [6.5. 集成测试框架](ch6/6.5.md)
+        * [6.5. 验收测试](ch6/6.5.md)
         * [6.6. 测试类型](ch6/6.6.md)
         * [6.7. 职责](ch6/6.7.md)
         * [6.8. 小结](ch6/brief.md)

ch6/6.5.md

@@ -0,0 +1,9 @@
+# 验收测试
+
+客户团队负责引领系统的开发，而**验收测试则向客户演示软件是可以接受的**。
+
+这意味着客户团队应该执行验收测试。
+
+至少，**在每轮迭代结束时应该执行验收测试**。因为**每轮迭代产生的可工作的代码在接下来的迭代开发中可能遭到破坏**，所以每轮迭代都要**执行以往迭代的所有验收测试是非常重要的**。
+
+这样，每轮迭代都要花更多的时间来执行验收测试。如果可能，开发团队应该自动化部分或全部验收测试。

ch6/6.6.md

@@ -0,0 +1,24 @@
+# 测试类型
+
+测试类型有很多，客户和开发团队**共同确保系统测试涵盖了项目所需要的不同类型的测试**。
+
+对于大多数的系统来说，故事测试主要是功能性测试，用来确定应用程序是如预期一样的运行。不过，也应当考虑其他类型的测试。
+
+示例如下：
+
+- **用户交互测试**，确保所有用户交互组件如期工作
+- **可用性测试**，确保程序好用
+- **性能测试**，测量应用程序在各种负荷下的工作状况
+- **压力测试**，使应用程序在用户和事务的极限情况或其他任何让应用程序处在压力的情况下运行
+
+**测试的是缺陷，而不是覆盖率**
+
+在一个敏捷的、由故事驱动的项目中，测试并不像很多团队那样是一个对抗性的活动。发现缺陷时，不应该有“被我逮到了吧”这样的心态。
+
+在敏捷开发中，若有缺陷直到系统投产的时候才被发现，团队成员是不应该互相推卸责任的。高度协作的团队以及“我们共同负责”的心态能防范这种事情的发生。
+
+在敏捷项目中，**测试的目的是发现并消除缺陷**，所以没有必要追求100%的代码覆盖率或测试所有边界条件。我们运用我们的直觉、知识和过去的经验来指导测试。
+
+选择最合适的人来执行测试。客户应定义验收测试，但是需要开发人员和专职测试人员的帮助和信息。
+
+随着时间的推移，通过频繁的沟通和观察哪些类型的测试经常出现问题，项目中所有人都可以知道测试重点在哪些地方。