前言:
本篇文章主要是讲述以精益敏捷开发的思维, 经由表格式的测试用例, 使团队成员能更高效的协作,更即时的能识别出不清楚的需求◦
本文:
精益敏捷开发 V.S. 传统的软件工程开发:
相较于传统的软件工程; 如: 面向对象的开发模式, 精益敏捷开发更强调的是 “团队中各不同角色间的协同合作” 与 “团队成员的自主性”◦
所以, 在实施精益敏捷开发的团队, 假如, 在写文档的过程中, 无法使团队中各不同的角色间协同合作, 则团队便极有可能, 还是在用传统软件工程的思维与作法在实施精益敏捷开发◦如此的作法, 显然将无法激发起团队成员的自主性, 更糟糕的是, 还极有可能使团队在实质上, 依旧是停留在低效的瀑布式开发模式◦
精益敏捷开发的作法:
精益敏捷开发是以测试驱动需求; 以测试用例审视需求是否已明确? 是否已可进行设计/开发?
所以, 精益敏捷开发的重点工作之一便是, 如何能经由团队的协作进行测试用例设计, 以激发起成员的自主性, 进而能即时的识别出不清楚的需求, 以能有效的降低项目开发的风险◦
精益敏捷开发为提升“团队协作” 与 “成员的自主性”, 主要的作法之一便是: 采用 “表格式” 的测试用例◦
如下例; User Story: Check Out CD◦
“我是 CD 出租店的店员, 我期望能经由 User Story: Check Out CD, 纪录客户出租 CD 的资料, 并能打印出收据, 请客户签字◦”
针对User Story: Check Out CD, 我们设计了“表格式” 的测试用例, 这其中包括:
1. 输入数据表 (Given)
|
Customer Data | |
|
Name |
ID |
|
James |
007 |
|
CD Data | |||
|
ID |
Title |
Rented |
Rental Period |
|
CD2 |
Home Land |
No |
2 |
2. 业务规则表 (Rule)
|
每个客户至多可租 3 片 CD | |
|
客户目前所租的 CD |
是否可再租 |
|
CD2, CD3 |
Yes |
|
CD2, CD3, CD4 |
No |
3. 业务运算表 (Calculation)
|
计算客户 CD 归还日期 | |||
|
Start Date |
Rental Days |
Due Date? |
Note |
|
2011/1/21 |
2 |
2011/1/23 |
|
|
2012/2/28 |
3 |
2012/3/2 |
Leap Year |
|
2010/12/31 |
4 |
2011/1/4 |
New Year |
4. 操作过程/ 事件表 (When)
|
Check out CD | ||
|
Enter |
Customer ID |
007 |
|
Enter |
CD ID |
CD2 |
|
Press |
Submit |
|
|
Check |
Message |
Check out CD Successfully |
|
Start Date |
|
2011/1/21 |
5. 预期结果 (Then)
|
CD Data | ||||
|
ID |
Title |
Rented |
Customer ID |
Rental Due |
|
CD2 |
Home Land |
No |
007 |
2011/1/23 |
|
Receipt | ||||
|
Customer ID |
Customer Name |
CD ID |
CD Title |
Rental Due |
|
007 |
James |
CD2 |
Home Land |
2011/1/23 |
结论:
1. “表格式” 的测试用例, 使得团队中的各不同的角色; 如:使用者, 需求分析人员, 开发人员, 测试人员, 均可面对面, 或以远程接入的方式, 共同协作, 使测试用例的设计更加的完备◦
2. “表格式” 的测试用例, 使得团队成员可经由无法确认的 “栏位”, 便可识别出不清楚, 不明确的需求◦
所以, “表格” 使团队得以协作◦
“栏位” 使团队得以识别出不清楚, 不明确的需求◦
方法很简单, 却很实用且很轻量级◦
欢迎你来试试!
精益敏捷开发与表格式测试用例
本文探讨了精益敏捷开发模式下表格式测试用例的应用,通过具体案例展示了如何利用这种测试方法促进团队协作,提高需求清晰度,并有效降低项目风险。
81

被折叠的 条评论
为什么被折叠?



