向各位前辈,同辈讨教测试用例的编写案例

[qilaryaya]

我尝试写过一些,感觉就象写操作过程,不理想!
向各位诚心请教.

[haor]

hi,qilaryaya，请允许我首先向你问声好！
这东东我也从没写过，不过看得倒不少，我所看到的测试用例大致包括系统测试范围、测试流程、测试路径、测试数据要求和预期结果要求等。也不知道我说这些对不对题，有兴趣也可以大家再一起探讨一下。

[dbbdggdbbdgg]

http://www.umlchina.com/book/book.htm

上提到的书：

面向对象系统的测试

去买。

[cbc]

测试用例主要是把输入和预期输出写出来就可以了，
测试用例的编写是整个测试工作的核心，
其输入工件一般是用例规约，补充规约，实施构件等
另外测试用例要可以执行，必须转化为具体可实施的测试过程

[am2000]

哪位大虾有没有软件测试方案啊。参考参考！

[Last_Dodo]

Mccabe and Associate has the best testing tool but very expensive ($20+k/user). Rationale has a product called TestRobot. I have seen the demo. It was very impressive.

[fita]

撰写测试用例只是测试设计过程多个步骤的其中一步，不知道你所谓的测试用例编写是指写出测试用例一步还是整个测试的设计过程，很多公司都认为在测试之前只要写个测试用利就行了，其实测试之前的设计应分为下面几个步骤：
1、确定测试需求
很重要的一步，很多人常常没做，就是先要确定要测试什么，要达到的目的是什么。
2、针对测试需求写测试用例
有了测试需求参照，测试用例就很好设计
3、编写测试脚本
把多个测试用例组合成一个测试脚本，用于分派工作，这也很重要，应为很多测试用例里需要做的步骤都是重复的，如果能把这些测试用例连接起来一次执行，将节省很多测试时间。

测试脚本值做好了，才是执行测试过程，测试完了，总结出测试报告，Bug报告等.

我为我们公司整理了一个测试流程的文档，以后可以给大家看看，不过你们看了要给我回应意见哦。

[qilaryaya]

To fita(天外飞仙):
好啊，等你的文档。

[qilaryaya]

过写的朋友可否发个文档给我，保证不外流。我的邮件地址：[e-mail]

[yql1024]

[e-mail] 能否给我一份

[ylg007]

To fita(天外飞仙):
我对此已期待很久，解渴啊。
[e-mail]

[james_qian]

fita(天外飞仙),能否给我一份，谢谢
[e-mail]

[wxfeng]

fita(天外飞仙),能否也给我一份，谢谢
[e-mail]

[wilddragon]

期待答案

[wilddragon]

支持一把

[wilddragon]

支持支持

[Jack_Loo]

好久没有看见这样的好文章了。

[qilaryaya]

很感谢fita(天外飞仙)　
可否发些案例给我呢？
还有一个问题请教：如果做纯手工的测试，测试用例是否需要编写呢？
信箱： [e-mail]

[yaner]

to fita(天外飞仙） 正在四处寻找，能否也给我一份？真的是非常感谢！！！
email:[e-mail]

[fita]

我这个流程早就发过了，这里再抄一遍：
如何进行测试设计
名词解释
测试需求(Test Requirement)
测试需求指的是对于需要通过测试验证的一个方面进行简要的描述，测试需求着重描述测试要验证什么，要达到什么目的。
测试用例(Test Case)
测试用例描述一次测试的有关数据，包括测试的环境，输入的数据和期望的输出结果
测试脚本(Test Script)
测试脚本是对测试步骤的一个书面的描述，脚本供测试人员实际进行测试时使用。
测试设计步骤
以下列出的步骤是对于一个需要测试的产品特性进行测试设计的步骤，如果要测试一个新的产品，则应对于其要测试的每一个功能特性采用下面的步骤进行。
1、 根据需求规格列出测试需求
参照产品的需求规格说明或与开发人员讨论，了解要测试的产品特性，并依据规格描述列出对应的测试需求
2、 根据不同的输入数据情况增加测试需求
根据不同情况下的输入数据，列出对应的测试需求，输入数据应包含以下几种情况：
l 正常情况下的平均值
l 边界情况下的输入值，如允许的最大输入值和最小的输入值
l 超出边界情况下的输入值
l 非法的输入值
l 可能导致错误情况的输入值
3、 列出每个测试需求的测试类型。对于还没有测试需求对应的测试类型，根据需要增加测试需求。
测试类型包括以下一些类型：
l 兼容性测试 与以前版本产品是否一致
l 配置测试 在不同的环境配置下，是否正常操作
l 一致性测试 产品特性是否必须符合某个外部的标准
l 错误情况测试 在发生错误的情况下，例如系统内存用尽，产品是否能正确处理错误
l 安全性测试 是否有安全保密上的要求
l 本地化测试 是否要在不同的语言版本下使用
l 性能测试 执行的速度如何
l 恢复性测试 发生异常中断，系统崩溃，产品是否能正确恢复
l 可靠性测试 在长时间运行情况下，产品能否稳定运行
l 压力测试 大数据量、大访问量情况下测试
l 可用型测试 操作是否符合用户习惯，用户是否能理解
l 文档帮助测试 按照文档和帮助文件里描述的步骤操作，是否能正确完成任务
l 真实情况测试 模拟用户进行真实情况下的操作，完成一个任务

4、 为测试需求设计测试用例
操作步骤如下
1) 对每个测试需求设计对应的输入数据和期望的输出结果
2) 表明进行测试需要的安装环境和要使用的测试工具
3) 把相互之间没有冲突的测试用例合并成，但不要将太多的测试用例合并，一个合并后的测试用例最多对应3个的测试需求
4) 如果好几个测试用例使用了一样的输入数据，则进行修改，使每个测试用例输入的数据都不一样

5、 把测试用例分类并制作测试脚本
根据测试用例设计操作的步骤，并编写测试脚本，编写测试脚本应遵循以下规则：
l 把使用相同环境配置和测试工具的测试用例组合到一个测试脚本中执行
l 一个手工测试的脚本的测试时间掌握在2到3个小时，避免某个测试脚本无法在一天内完成。
l 如果此阶段产生任何新的测试主意，把它们加入到测试脚本中
l 在测试脚本开始注明对应的测试需求，让测试执行者了解测试的目的和重点
在设计完成后，可以形成下面的测试设计表：
测试设计表
测试需求 测试类型 测试环境 输入 期望输出 测试用例编号 测试脚本编号