测试用例漫谈
一点小的经验总结，拿出来大家讨论一下。1.什么是测试用例
测试用例是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求的描述，是判定的依据，也是软件测试的核心。所以，不能没有测试测试，测试用例也不能没有预期结果
2.测试用例的来源是什么
所谓来源，也可以认为是输入，测试用例的主要来源是以下方面：用户需求分析文档和需求验证文档、系统设计文档、概要设计文档、详细设计文档，已成界面，相关行业的规范等等，这些可以参考W模型中的定义，此外，测试用例中还需要考虑以下方面：以前版本中发生的错误、某些可能需求分析中可能遗漏的地方（如破坏性测试用例）。同时，测试用例也应该进行细分，如，功能测试用例，性能测试用例，单元测试用例等等。还有一部分应该来自和自己团队和开发人员的讨论，适当的头脑风暴以及评审是很重要的。
3.测试用例的格式是什么
作为一个测试用例并没有标准格式，但是至少应该包含以下信息：测试用例编号，测试用例优先级别，测试用例名称，测试用例所属类型，所属产品，所属版本，测试目的，测试前置条件，测试执行步骤，预期结果，实际结果，备注。
对于预期步骤中，应该适当的详细描述，从而保证任何一个对此产品略有了解的人员都能执行。
4.测试用例怎么维护
这里牵涉到测试用例的保存问题，在目前国内很多公司中，都还是把测试用例保存在Word文档中，如果仅一个工程师使用的话，或许还行，但是如果多人进行测试，任何一个任在对测试用例进行修改，删除等等行为的时候，可能就会引起冲突从而导致信息的丢失和不全。纵然可以使用版本管理软件进行管理，但是，这个毕竟是非文本的，在冲突的时候，版本管理软件也无能为力。同时，Word的统计性也很糟糕，比如总共有多少case，执行了多少，正确的多少，错误的多少，都需要靠人去数，实在是很笨的方法。也有一些公司使用了Excel，在统计上有比较大的进步，但是仍旧不容易进行版本管理。
在市场上，有MI公司的TD等软件，确实是不错的选择，集中式数据库管理的方式把上述的两个问题都解决了，只是留下了一个问题：钱的问题。这个问题也很大。
还有一种解决方案就是使用论坛写Case，在维护上不错，但是统计上有缺陷，可以自己再做一些二次开发，从而达到目的。我也曾经自己试着用ASP开发了一个测试用例管理系统，虽然和TD相比差距很大，不过也能解决上述的两个问题，只是在Case的维护上还有一些硬伤，但是养成良好习惯的话，应该还是能有一些方便的。
6.测试用例怎么和产品关联
其实这里也是和用例的维护有关系，因为同一个产品，版本在不停的变化，功能也在不停的变更，对于同一个case，可能在上个版本有效，这个版本无效，也可能是上个版本无效，这个版本有效。在数据库中维护的时候，不可能所有的case都重复添加N次，每次仅对应一个版本，这种做法非常的不理智，而且也同样会引起维护的问题。正确的方法是，在数据库中有一张表放所有的case，这些case都用功能大项来进行分类，每个case都有唯一的id，用另外一张表维护所有的产品，然后产品里面有一个属性用来存本产品的所有的caseid。
7.测试用例的执行和记录
在一般情况下，测试用例是根据版本，进行一轮一轮的执行的，所以应该在测试用例管理中，根据每轮执行的情况进行记录，比如结果描述中就应该存在，第一轮，CASE错误，实际结果为XXX，上报了BUGXXX，并给一个链接到bugzilla或者类似的管理系统中去。如果有自动化执行系统，则需要采集日志，以便分析之用。对于条件不满足的case，可以置为未执行状态，在每轮执行完毕后，应该生成相关统计，如执行了多少case，未执行多少，正确的多少，错误的多少，上报了bug多少。 楼主真是解释的很详细了，要是能有一个例子就更好了，不过还是多谢了！支持一下！ 1.个人觉的用例应该分类型的.比如功能测试的用例\性能测试的用例\单元测试用例......不同类型的用例格式可以不同 ,但要素必须全面.什么编号\测试目的\预置条件\级别\输入\预期输出...
2.甚至不同项目的用例格式完全可以不同,还是一句话,格式可以不同,但要素必须全面 呵呵
最重要的是方便,可以提高维护和执行的效率. 不应该一个模板套到底,有时候你会觉得写起来很累
3.关于 试用例的执行和记录个人觉得用例中关键字设置 要和BUG的描述联系起来考虑. 有些公司把执行记录和用例完全融合在一起 比如说实际结果\测试结果 是否通过\执行人\执行日期等等 如果你BUG中描述的够详细.那么用例中有些字段可以省略比如实际结果 sdlkfj2 好文章，支持一下
页:
[1]
