庖丁解牛之QA篇

一个简单的test case模版解析

2008-02-15T00:22:00.000-08:00

|---------------------------------------------------------|
|                  Test Case                              |
|---------------------------------------------------------|
| Test Case ID:                                           |
|                                                         |
| Test Description:                                       |
|                                                         |
| Revision History:                                       |
|                                                         |
| Date Created:                                           |
|                                                         |
| Function to be tested:                                  |
|---------------------------------------------------------|
| Environment:                                            |
|                                                         |
| Test Setup:                                             |
|                                                         |
| Test Execution:                                         |
|                                                         |
| 1.                                                      |
|                                                         |
| 2.                                                      |
|                                                         |
| 3.                                                      |
|---------------------------------------------------------|
|                                                         |
| Expect Results:                                         |
|                                                         |
| Actual Results:                                         |
|---------------------------------------------------------|
| Completed:                                              |
|                                                         |
| Signed Out:                                             |
|---------------------------------------------------------|

test case id用来标示一个test case，就是case的名字，
没有什么好说的

test description是对case的一些详细说明，比如这是个
invoice功能的边界测试，或者更加详细...

revision history用来记录版本信息，一般说来
test case没有必要保留所有版本，但是每次修改
留下足印是一个好习惯

date created显然就是用来记录创建日期和创建人的

function to be tested这个应该填写function list
之中的function id，是一个分类字段，可以很快的sort
出来同一个function的所有test case

environment环境指的是该case适应的测试环境，
比如这个case只是适用于win2000，我们就填写
win2000

test setup是测试的准备条件，可以等同于
pre-condition

test execution这个是核心，具体的纪录要执
行的每一步骤

下面两个框框里的应该是纪录执行结果的
expected results是预期
actual results是具体执行结果
completed是测试执行完成时间
signed out用来记录执行者

给一个sample
|---------------------------------------------------------|
|   Test Case ID: 1001                                    |
|   Test Description: Verify A function                   |
|   Revision History: v1.0                                |
|   Date Created: 2/15/08 1.0 - 屠夫                      |
|   Function to be Tested: A                              |
|---------------------------------------------------------|
|   Environment: Windows 2000                             |
|   Test Setup: N/A                                       |
|   1. Open the program                                   |
|   2. Run A                                              |
|   3. ...                                                |
|---------------------------------------------------------|
|   Expected Result: something lar                        |
|   Actual Results: Pass                                  |
|                                                         |
|   Completed: 2/15/08 1.0                                |
|   Signed Out: 屠夫                                      |
|---------------------------------------------------------|

每次执行都可以打印或者在线填写一份，或者
在添加一个测试的版本，然后可以不断的扩展下去
撇出对test cases的管理来说，这个
test case模版还是挺简单和也蛮好用的，
如果要管理好test cases，那就要给每个case添加
属性以满足自己的管理需要，比如加一个是否auto
的属性，标示这个case将会有自动化脚本。

关于test strategy和test tactics

2008-02-12T22:49:00.000-08:00

论坛上总是见到有人把unit testing, system testing等等当成是strategy，的确这些测试类型是测试策略的重要组成部分，但是却不能简单把这些当成是策略，策略是什么呢，我会说策略是你想达到目标的路线图，如果你想发布产品，你应该做这些这些，是些what，但是不是简单的what，是在特定context下的赋予目标和限制的what，好的策略是多个dimension的平衡，最常见的制约当属schedule和resource了，good enough多半时候是一个好的指导思想，软件可没有十全十美。
当策略制定之后，test tactics也就是how的部分，一个题目有很多种解体方法，但是这只是局部问题了，所以在这里成为是战术性的，战略则具备全局观念。

V model还是W model

2008-02-12T17:12:00.000-08:00

V model已经出现很长时间了，不同的软件开发阶段对应有各自的测试，分别是
业务需求对应 uat
系统需求对应 system testing
概要设计对应 integration testing
详细设计对应 unit testing
什么是w model呢？先看图

在原有基础之上增加了preparation和debug，更加完整的体现了整个开发过程，也为测试准备工作正名，将测试准备和测试执行正式分成两个独立的任务，更加科学。

Test Model三要素

2008-02-11T19:42:00.000-08:00

test org.要不断改进，必须要有一个相对稳定的test model，基于一个相对稳定的test model我们才可以对我们的现状作出可靠而相对稳定的评估，改进也能够step-by-step的不断前进，建立测试模型的三要素：
1、测试环境test environment
2、测试过程process to test a single software project
3、测试能力tester competencies

test environment测试环境包含有很多，比如culture, mission, goal, strategy, tool等等，
process是日常测试的procedure和standard，
tester competencies是完成任务所要具备的能力，

如果我们测试的目标mission只是为了满足requirement doc.的需要，一切会相对简单，而要让stakeholder满意是困难而有挑战的工作，要让stakeholder满意，首先你要知道怎样才能让stakeholder满意，只有这样你才能
让stakeholder满意的管理，推荐使用ITIL，建立相关的SLA，首先要学会把无形的东西量化，也只有量化之后才能够去评测，这有点像学生的考试制度了，残酷异常，话说回来，process可以量化，人却是万万不可量化的东西，一旦人也需要量化的时候，整个process出产的东西已经毫无创新可言了，取而代之的是现代化的流水线作业，是资本家需要的是用模具生产出来的大量的工业产品，不是人的创造了。在没有现代生产线的那些小软件公司也自然成为民间手工艺人，偶尔才会有些火花蹦出来......

所有种种环节构成了具体测试的上下文，知己知彼，才能百战百胜，了解自己身处的position是很重要的。画鱼骨头找出对自己所属环境重要的dimension，为这些战略性的指数建立相应的dashboard，作为测试管理人员应该时刻关注这个dashboard，而为了达到这些战略性的指标，我们需要做的具体的更加细分的指标，也就可以相应叫做的战术指数了，同样为这些指数建立相应的dashboard，这是日常工作的monitoring了。应该确保在确定条件下，即某些战术性指标达到时，战略指标也即达到。否则要尽快做出调整。

小试牛刀

2008-02-10T22:47:00.000-08:00

做了多年的开发工作，测试对于屠夫来说也算是副业了，却很不幸的成为了现在的主业，挂个名而已，三年的qa生活也没有写过几个test case。不过总算对测试也算是有些认识，在这里也可以小试牛刀一下。