测试用例（浅谈）

我们先要进行软件测试用例的分析和设计，然后写出软件测试的内容，最后按照软件测试写作方法，落实到文档中，写的好的测试用例不仅方便自己和别人查看，而且能帮助设计的时候考虑的更周全，因此测试用例的写作和测试用例的设计一样，也是非常重要的。

 
如何编写测试用例？——测试用例的内容
　

1、用例编号

2、测试项目，测试某个模块的功能点或者性能指标

3、重要级别

4、测试标题

5、预置条件（包含测试环境配置）

6、操作步骤

7、测试输入，准备好的测试数据（可能不需要）

8、预期输出

9、测试目标；分为功能测试，性能测试、易用性测试、压力测试等

10、测试方式；手动还是自动

11、测试用例设计人员和测试人员

12、测试日期

 

测试用例注意事项：

1使用最有可能发现错误的用例

2用例不重复、不冗余

3选取一组相似测试用例中最有效的

4灵活运用测试用例模板

 

如何执行测试用例？

1、清晰且准确理解用例，不带半点含糊

2、执行用例不能走样

3、执行用例要看实际结果与预期输出是否一致

4、测试过程还要保持整体观察

5、执行测试用例中，收集好发现的bug,不能有遗漏

 

测试用例

什么是测试用例？

【测试用例（Test Case）是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求，是软件测试人员需要具备的基础能力。】

定义： 

（1）Test case是为特定目的而设计的一组测试输入、执行条件和预期结果

（2）通过大量的测试用例来检验软件 的运行效果，它是指导测试工作进行的依据

编写测试用例的根本目的？

目的： 是有效找出软可能存在的缺欠，为达到这个目的，需要分享被测试软件的特征，运用有效的测试方法，使用较少的测试用例，同时满足合理的测试需求覆盖，达到少花时间多办事的效果

设计测试用例的基本准则？

定义：

（1）测试用例的代表性

能代表病覆盖各种合理的和不合理的，合法与非法，边界和越界的，以及极限的输入数据，操作和环境设置等

（2）测试结果的可判定性

测试结果的正确性是可以判定的，每个测试用例都有对应的期望结果

（3）测试结果的可再现性

对同样的测试用例，系统的执行结果是相同的

 

好用例的标准：

/是否可以发现Bug

/是否够高效

/是否够经济

/是否有足够的扩展性

——————————————————————————————————————————————————————

测试用例的意义  测什么？如何测?如何衡量？

/理清思路，避免遗漏

/跟踪测试进展

/历史参考

/重复性

 

测试用例的优点

/组织性

/重复性

/功能覆盖

/跟踪

/测试确认

 

测试用例的用途

/核实需求

/监督过程

/评估结果

/准确回归

/防止遗漏

/提高效率

/缩短周期

 

测试用例的设计依据

/需求文档

/设计文档

/遗留系统相关文档

/与相关人员讨论

/探索式测试 把产品当做产品说明书来对待

 

测试用例更新与维护

/需求变更，功能变化，测试用例需要更新

/测试用例需要细化和不断完善

/通过测试实践检验测试用例并添加、修改、删除测试用例

测试用例要经过正式、有效的评审

利用工具来维护测试用例

————————————————————————————————————————————————————

测试用例开始设计最优时间

 当根据客户的需求整理出项目需求分析文档时，我们就可以根据需求文档来编写测试用例了。但是，一般我们（国内大多小公司）项目需求文档都非常“简陋”，所以，很难根据需求文档设计测试用例。

 我们只有等到项目开发人员把项目开发出来，给我们系统文档、部署环境、数据库结构（如果系统牵涉到数据库的话），我们根据这些文档来设计测试用例。

 

融入探索性测试思维

 完全的执行测试用例时一件非常枯燥的事情，个人在执行测试用例时会做一些，其它的非常规性的操作，看系统是否会有相应的处理和提示。

 测试优先级的划分：

1、测试时间和资源有限，可能无法执行所有的测试用例，穷尽 测试是不可能的

2、首先执行最重要的测试用例或优先测试用户最需要的功能，尽快尽早发现可能多的bug

3、测试用例优先级的划分和测试执行顺序的确定，取决于项目的特征，应用领域和客户的要求

4、即使测试过早结束，也要保证在时刻测试工作能达到最好的效果

二、测试优先级的划分细则

1、使用频率或失效的概率

2、失效的风险

3、失效的可见性

4、需求的优先级

5、质量特性

6、开发人员的角度

7、测试对象的复杂性

8、高项目风险的失效

9、缺陷的集群效应