在目前的测试环境下，大多公司不具备书本(理论)上所讲的那些测试条件与开发条件，以及管理模式。
如何能在有限的测试资源下，通过对测试的过程改进，使得测试效率最优化呢？

我这儿有一个测试过程：
大多数公司的测试，是在软件集成时或集成以后，让测试介入，进行黑合测试。
在测试前，测试人员准备：测试计划和检查列表。关于检查列表（Checklist）主要罗列了软件的功能，是否要加入操作流程呢？
测试时，测试人员主要依据检查列表进行测试，不提供和记录测试用例，只记录BUG；
测试完一个版本，报告一次测试结果，对测试中发现的BUG进行粗略统计，叙说主要功能上的缺陷；
测试一段时间(几个版本)后，进行交换测试（更换个人的测试模块，进行测试）；
测试完成后，由指定测试人员善后（验证由用户反馈回来的BUG）。

通过交流，期在有限测试资源与环境下，能找到有操作可行性的、更好的测试过程。

说一下自己的感觉：成本比较高，但是效率不一定上去，尤其是进行交换测试（更换个人的测试模块，进行测试），使用罗列检查表的好处是清晰明了，但是最大的缺陷可能就是遗漏，虽然主要罗列了软件功能，然而无法保证完备性及可以确定的有效性在文档齐备的情况下，有好的测试用例不仅可以避免掉很多的预期BUG，也可以同时提高测试效率，在实际测试过程中，不一定需要进行交换测试，除非是关键模块或代码（但据我所知，交换测试的情况比较少－－可能是见识浅薄了点^_^"）。

怎么样才能写出比较好的测试用例啊？我是新手，还望各位大佬不吝赐教。

写测试用例固然好，也能知道测试的大概覆盖率，但不可避免的是在时间上会变的更紧迫。大部分公司没有详细设计，也没有用户界面设计，一切都是等开发出来才能知道，你告诉我测试用例怎么写出来？
所以楼主的写CHECKLIST还是比较广泛，也是可以说很实际的。

我同意楼主的。毕竟不规范的公司占多数。

采取checklist和交换测试的方法，是个折中或者说不得以而为之的方法，正如WZB521所说由于时间关系以及开发的具体情况，测试人员只能出checklist,而交换测试的主要目的是为个尽可能的避免archonwang所担心的事发生“遗漏缺陷”，每一个测试人员在测试时关注的焦点可能不一样，希望通过这一过程，尽可能的避免遗漏缺陷。
另外还需要说的一点是，在大部分公司里，大多需要发挥测试人员个人能力进行测试，也就是说，测试人员的能力决定了测试的效果。在不可能提供完备的test case 的情况下，测试人员的能力将决定测试的质量。而既使提供了完备的test case 不同的测试人员可能发现不同的问题。 在测试执行这一过程中我们无法避免人为的主观因素。
test case 所描述的大部分case，只要对产品熟悉的测试人员，应该都能设计得出。基于这两点，一要充分发挥测试人员的个人能力，二测试人员可以独立设计出大部分的test case, 才有了不写test case 的想法，而直接让测试人员列出checklist 进行测试。其实有了checklist对于测试或者说设计testcase将是件非常容易的事。已经知道了要检察的功能，设计case将very easy.

即使是有了CHECKLIST，那对于具体的测试点，也要列举大量的数据来进行验证或检查，到头来还是回到了测试用例的准备阶段。
不过楼主的点子倒不失为一个好的借鉴方法。
单算上CHECKLIST的设计（由经验丰富且熟悉业务的高级测试工程师进行设计）确实能减少时间，但算算数据以及其他的准备，效率也不是提升很大，而且项目的后期风险却提高了不少，如此说来岂不是以小失大？
补充一点的是：对于关键部分（模块）或业务流还是应当设计相当的用例来进行测试。

回答楼上takiro的一些问题并作一些说明：
1、用例的设计这个过程其实并没有cancel掉，在测试执行时如果仅有checklist没有test case 如何执行呢？执行的测试又是什么呢？只不过这些个testcase是没有再写出来并记录下来。
2、写出一个产品的checklist是相对比较容易的，而testcase就不一定那么容易了。更有可能在有了testcase 之后，测试人员只会照着做，而不会发挥自已的能力去做更多的事。
3、数据准备的问题在测试执行时，如果交由一个人去完成，可能是很花时间，不过，如果没有给定testcase，数据的问题自然会分配给每一个参与测试的人员，这样每个人所花的时间，可能会相对少一点。而数据由测试人员来准备，对提高case的执行效率应该有帮助。
4、风险的问题这里不好多说，原本资源就有限，而任何测试过程都有风险。
5、主要操作流程是否要列出，确实是个有待商榷的问题。不过至少要虑到这几个因素：a.测试人员可能对操作流程已经非常熟悉，列了也是白列；b.如果没列出主要操作流程，在有新的测试人员加入测试时，可能会遗漏；c.对主要操作流程的认定可能会有争议（但这不会有太大的影响）。

另我也很想知道大家现在的测试过程，是否可以说来分享分享？

我想关于主要操作流程是否要列出的问题，应该是由公司决定吧，其实对于公司来说应该是希望留下这种文档的，因为日后有这方面的同事流动的时候，公司也不至于突然就没人能接手继续工作。
反而觉得test case应该是必须写下来的东西，应该对以后的回归测试等都有好处。

一般的公司checklist都没怎么留下来,基本上都是按作系统的操作流程,以测试人员的个人能力和对系统的了解程度来开展测试,对发现的bug和缺陷却会形成报告留下来.一是展示工作业绩;二是为了方便开发人员修改;三是为了回归测试做准备.

就NIO所说：CHECKLIST也只是对用例的一个补充 或者说是在时间不充裕的情况下的一种用例设计参考形式
但这样根据CHECKLIST随意设计数据进行测试 往往效果不好 只是根据测试结果来进行BUG的记录 测试步骤或是分析都无法很好地进行（开发人员或质量保证人员无法复用 弄来弄去能搞明白的就只有测试人员一个人。） 这样看也只是‘有了这 丢了那。。’

takiro应该是有自已的想法的，可以说说你们在测试的时候所采用的测试过程么？

另：
1、“这样根据CHECKLIST随意设计数据进行测试 往往效果不好”——这样的说法，应该说是很不负责任的，效果好不好应该有个比较才能得出，takiro在没有事实基础的情况下，这么说可能太牵强了。
2、没有开发人员以及市场人员的帮助，应该很难成形checklist吧. 开发人员虽不必使用checklist， 不过看懂checklist应该没有问题吧。

谢谢各位老大，受益非浅啊！
我现在的公司就是在不设计用例的时候让测试人员发挥最大的个人能力，感觉总是有些不太妥贴，不知道能否完整的测试到每一点。

路过喔~~

[ Last edited by Nio on 2005-8-12 at 18:04 ]