Test Driven Development(测试驱动开发)有别于传统技术人员开发常常一头钻进去撰写代码,TDD 鼓励在
接收到功能需求时优先思考如何测试,譬如网站登入功能必须区分用户是否曾经注册、登入失败显示的讯
息、失败次数过多时(可能是攻击行为)的措施等,TDD 常常拿来跟 User Story(用户叙述)一起使用,经由整
体思考测试流程后再投入程序开发,减少开发途中遗漏重要功能。
BDD
Behavior Driven Development (行为驱动开发)是一种敏捷软体开发的技术,它鼓励软体项目中的开发者
、QA和非技术人员或商业参与者之间的协作。主要是从用户的需求出发,强调系统行为。BDD最初是由
Dan North 命名,它包括验收测试和客户测试驱动等的极限编程的实践,作为对测试驱动开发的回应,这
篇文章是 Dan North 本人对于 BDD 提出的实例。
ATDD
Aceptance Test Driven Development (验收测试驱动开发)
TDD基本上只跟开发人员有关,如果对功能需求理解错误,还是会浪费不少时间资源,所以用户/PM、RD、
QA需要坐下来一起讨论制定验收 Test Case (测试案例),ATDD的重点不在 How (如何完成功能),而是
What (要达到什么功能),更重要的是测试案例是使用者最后要验收的方式,所以使用者要看的懂,这也
是本实验介绍 Robot Framework 的主因。
4. 测试案例(Test Cases)
测试案例一般依照 User Story 撰写,一如验收系统功能的精神是在不知道系统的介面及实作细节的前提下,
用户或 QA 一样知道系统该做什麽。因此,把系统功能步骤以自然语言的描述方式留在 test case 层级,实
作细节留在 关键字 / 库,并把常用的实作细节抽出来方便重複引用。注意测试案例是循序由上执行到下,
所以测试案例之间的状态跟资料会影响到测试结果。