李玉鹏: zentao？呵呵
王春生: testcase, testsuit, testplan, build.
王春生: 我觉得这些概念好像没有一个软件给理顺的。不知道你怎么看？testlink我觉得也乱乱的。
王春生: bugfree2里面没有suite和plan的概念。
李玉鹏: suit是一堆caes的集合
李玉鹏: 关键plan怎么理解
李玉鹏: 或者可以从目前的问题出发，我们如果只有testcase的概念的话，会有哪些解决不了的问题
王春生: 我理解的plan应当是针对某一个build，选择某些case，形成一个testplan，然后交由某些人来执行。
王春生: 这里面几个要素，case, build, tester。
李玉鹏: 一个build会不会对应多个plan
王春生: suite应当是用来筛选测试用例，方便组织使用的。
王春生: 我想这个应该是一对多的关系吧。
李玉鹏: 嗯，me too
李玉鹏: testlink里貌似有case版本号的概念
李玉鹏: 之前是这样的，不知道现在如何
王春生: 或者讲，testplan应当有run的概念。
李玉鹏: testplan里可能对应多个run
李玉鹏: 还是一个run
王春生: 一个build对应一个plan，一个plan会有多次run
王春生: 这样关系会不会要更加顺一些？
李玉鹏: 一个plan对应多个suit/
李玉鹏: 一个suit对应多个或一个case？
王春生: plan和suite应该是两个纬度的东西。
王春生: 在组织plan的case的时候，需要利用到suite来进行筛选。当然，plan也可以完全覆盖若干个suite
王春生: suit肯定包含多个case，一个case也可以属于多个suite
李玉鹏: 但plan也可以直接对应case吧
李玉鹏: 就选几个case
李玉鹏: 难道还是要先归入到一个suit中？
王春生: plan和suite没有直接的关系。
王春生: 我理解的suite更多的是平时写用例，组织用例用的一个手段。而testplan则侧重于执行。
李玉鹏: 那suite组织的原则是什么
王春生: 无所谓，权利在每个人手里面。
王春生: 每个人都可以有自己的一套suite.
王春生: 当然也应该有公共的suite
李玉鹏: 我觉得可以弱化suite的概念
李玉鹏: 这个可有可无
李玉鹏: 用户自己选择
李玉鹏: 一个人接到一个测试任务，就是建立一个plan，选些case，然后run，生成结果，就ol了
李玉鹏: 至于选case的时候用不用suite都无关紧要
李玉鹏: 另外一种plan就是定时的那种
李玉鹏: 做dailybuild
李玉鹏: 这应该是testlink里case有version概念的原因
李玉鹏: 不过我觉得加入version，不如分成两个case来的容易
李玉鹏: case之间没必要关联那么强
王春生: version的概念应该是比较小的,只是一个case。
王春生: 我现在还没有太考虑version
李玉鹏: 比如你运行dailybuild的时候，可能是运行case的version1
李玉鹏: 而在内部测试一个新build的时候，可能运行的是case的version2
王春生: 加入version的概念也可以，力度可以更细。
李玉鹏: 但我觉得caseversion之间产生区别了，包括运行步骤和运行数据可能都发生变化了，是否可以考虑干脆分成两个case？
李玉鹏: 这样更清晰
王春生: caseid + version，对于程序来讲，已经是两个东西了。不过对于使用者来讲，他所关注的是最新的状态。分成两个case反而不好。
王春生: 等于是很多历史的东西也会呈现在列表中。
王春生: 使用version的话，列表中呈现的只是每一个case的最新状态。
李玉鹏: 但是这样的话，你plan里的case就要附加version的概念
王春生: 对。
李玉鹏: 我觉得比较麻烦呵
李玉鹏: 而且要保存所有历史的状态
李玉鹏: 有更好些，但存储和展示麻烦点
王春生: 这个到不会麻烦。因为testplan是动态的过程。每次新建plan，肯定是使用最新版本的case。这个时候用户可以不用关心版本的概念。
李玉鹏: 不一定啊，可能也用老case的
李玉鹏: 因为线上回归和线下测试的build可能是不一样的
李玉鹏: 甚至会有3种或者以上的情况
李玉鹏: 呵呵，算法这边就差不多
李玉鹏: 你可以问问davy
王春生: 你线上回归的build，按理plan应该早已经建好了才对。
李玉鹏: 不是，可能是紧急fixbug
王春生: 回归的时候，是对plan的又一次run而已。
王春生: 哈哈，case也要开分支拉。
李玉鹏: 而这个plan你是新建的
李玉鹏: 但又要选择以前的case
王春生: 这个时候的plan，可以从之前的plan拷贝一份，回归plan 应该是之前正常测试plan的一个子集。
王春生: 再加上针对bug的若干新case。这个时候不矛盾。实在不行了，完全可以新建一个用例。
李玉鹏: 那不如新建plan来的快嘛
李玉鹏: 总之引入version会给自己的系统设计带来一些麻烦
王春生: 这种情况应该还是比较特殊的吧。
王春生: 如果出现了，还是可以应对这种情况的。
李玉鹏: 嗯
李玉鹏: 可以把自动化运行考虑进去
李玉鹏: 哈
王春生: 使用version应该可以应对绝大多数的情况。实在不行，还可以新开case的嘛。
王春生: 自动化运行你是指哪些方面？
李玉鹏: 那其实version主要就是看历史
王春生: api?
李玉鹏: 就是自动去跑plan呗
李玉鹏: 嗯，或者批量导入什么的，因为大多数测试人员都不像自己运行完一遍，还要再去系统里写一遍吧，至少我不想:P
王春生: zentao框架后面我会增加一个功能，你看到的任何一个界面，将扩展名改为.xml，json，都可以直接获得这个页面的所有变量信息，这个就是api
李玉鹏: 这是view吧，我指的是insert数据
王春生: 有这套机制，通过api操作zentaopms很容易的。
王春生: insert数据的话，看表单页面就知道需要提交哪些数据了。
李玉鹏: 嗯，那就好，api权限的话还是像原来一样吗？
王春生: 一样的。每个人使用自己的账号和密码登录。权限和web界面一样。
王春生: 总结一些,case, version, suite, plan, run, result
李玉鹏: buil
李玉鹏: build
王春生: 对。
李玉鹏: 一个build对应多个plan
李玉鹏: 一个plan对应多个case（含version信息）
王春生: 一个build对应一个plan吧，一个plan可以跑多次。
李玉鹏: 嗯？
李玉鹏: 关键你怎么界定plan
王春生: plan，计划嘛，是没有执行的东西.
李玉鹏: 比如这个build的功能测试和性能测试是否放到一个plan里？
王春生: 那就是build对应多个plan，每个plan可以run多次。
李玉鹏: 一个plan跑多次，没必要每次都跑性能的
李玉鹏: 嗯嗯
李玉鹏: 清楚些了
王春生: 咱们这里说的plan和通常所说的测试计划文档应该不是一码子事。
王春生: 因为这个plan，肯定是有了build之后才可能创建的。应该是项目后期，进入测试阶段之后的事情。
李玉鹏: 嗯，是要具体执行的
李玉鹏: 你觉得前期的计划文档主要用来做啥
王春生: 通常所说的那个测试计划，和这个我想应当属于两个不同的概念。
王春生: 说实话，我到现在也没有搞清楚，hoho
李玉鹏: 如果容易混淆，可以考虑不叫plan
李玉鹏: 想不到太合适的词啊，job？
王春生: testtask?
李玉鹏: task？
王春生: haha
李玉鹏: 可以task是plan的一次具体执行吧
李玉鹏: 执行叫run？
王春生: 对。
李玉鹏: 哦
王春生: 嗯。这个关系可能会比较好一点。
李玉鹏: build->task->case(s)->run->result
王春生: product->projects->builds->tasks->cases->runs->results
李玉鹏: 嗯
王春生: 应该是这样一个关系。
李玉鹏: product->projects->builds->tasks->cases(version)->runs->results
王春生: ->bugs
王春生: 哈哈.
李玉鹏: product->projects->builds->tasks->cases(version)->runs->results->bugs->report ?
王春生: 嗯。要有。不过应该往前放。
李玉鹏: 差不多了吧
王春生: 统计的话，应该是按照buikd, tasks, runs来进行。
李玉鹏: 嗯
王春生: 这些是宏观的概念，统计的是results和bugs
李玉鹏: report跟这些耦合不紧，可以再发挥
王春生: 嗯，差不多了。今天咱们两个的讨论会载入史册，hoho。
李玉鹏: 汗
王春生: 回头整理一些，发到网上。
李玉鹏: 还好吧，其实也没太多新概念啊
王春生: 微软里面似乎也没有理清这些关系的嘛。
李玉鹏: 嗯，微软不够敏捷 :P