测试用例相关：概念、测试需求、开发版本、注意事项、前人经验、理论概念

题外记

上周五遇到一件很幺蛾子的事，我和研发两个人测试同一个bug，用的是一样的环境--他的环境是我发给他的，结果是不一样。反复确认重现的操作步骤，无解。
还是跟他，验证修复文件是否可行，我这边和项目这边验出来怎么都是不行，可是研发这边测出来是好用的。
头痛好久，反复确认，偶然发现研发用的数据库不是我发给他的数据库。差异大抵在此了。一样的Jboss版本，一样的war包，调用的数据库不一样，出来的结果未必一样了，切记之。

什么是测试用例?
*一个测试用例是一个文档，描述输入、动作、或者时间和一个期望的结果，其目的是确定应用程序的某个特性是否正常的工作。一个测试用例应当有完整的信息，如：测试用例ID号，测试用例名字，测试用例的目的，测试条件、输入数据需求、步骤和期望结果。

*指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。

*管理软件的测试用例更趋于是针对软件产品的功能、业务规则和业务处理所设计的测试方案。对软件的每个特定功能或运行操作路径的测试构成了一个个测试用例。

如何判断测试用例的好坏？
*测试用例的好坏可以有几个方面。第一，是否独立于具体的实现；第二，是否可以比较方便的指导实现工作；第三，是否比较容易维护。

*能发现多错误的，发现至今为止没有发现的bug的用例是好的用例，这句话未必正确。因为，测试不是解决问题，测试用例的好坏不是指单个的用例，而是用例的覆盖度，单个用例再好，所有用例的覆盖度不够，那测试工作还是失败的。所以测试工作除了关注用例设计，更重要的是测试范围的圈定，方法的运用，然后用例的设计会是自然而然的事情。当然，用例的覆盖率也应该是从单个开始的，在一开始肯定有很多不清楚的内容，所以用例中很多的内容无法填写，所以我们应该默认用例的书写是个迭代的过程，不同阶段完成不同的内容，执行之前全部完成可以了。

*很多时候发现用例在很多输入输出方面的设计基本都是雷同的，这个可以考虑测试用例的“复用”。其实雷同也是正常的。

关于测试需求
*对于“有时候不知道结果的情况下如何预测结果”，如果需求无法明确，或者说需求不够明确，则对于该需求的测试用例设计应该推迟，并及时同需求人员进行交流，尽快将需求准确的定义下来。

*测试用例不会平白无故的被设计出来，它是有目的和前提的。测试用例是用来指导具体测试实现的，包括自动化脚本的实现和手工测试步骤的实现。对于测试用例对测试需求的覆盖，不是测试用例编写的目的，而是对测试工作的要求——是要求测试用例设计人员的阶段性工作的结果必须符合一定的要求的。测试用例本身是无法保证覆盖需求的。

*对于一个产品来说，它的开发和测试都不是一次性的，随着开发版本的迭代，测试工作也将继续进行下去，同时，我们对每个版本的测试范围都是不同的。注意，这里有一个关键，也是测试范围圈定的出发点——软件需求的确定。那么怎样来明确软件的需求呢？——版本。如果希望工作的进度和内容可以明确的定义下来，首先要考虑版本的确定——软件需求的版本确定。通过软件需求的版本控制，可以明确每个不同版本的产品中所实现的特性，哪些特性将在以后的版本中实现。这里重点提到的是对于需求也需要使用版本的概念来进行管理。既然某个版本的软件需求已经确定，那么接下来的开发工作可以在这个需求版本划定的范围内开展。

*测试需求是需要测试的内容，它的来源有很多方面。
1.在需求阶段，软件需求规格说明书和用例中对于软件的描述、业务规则的描述可以整理出早的测试需求，这部分测试需求将完全来源于软件需求，是当前阶段测试工作的一个基础。
这个时期我们有一个非常非常重要的工作，我们将尝试着进行需求文档的检查。这里，对于需求文档的检查主要是两个方面：
（1）检查需求文档描述的正确性，测试人员要对于真实的系统所涉及的业务非常熟悉，比如一个简单的财务软件，那么测试人员本身要对会计工作熟悉，财务制度熟悉，在检查需求文档的时候不要迷信所谓的“都是用户真实的需求”，这里存在两个问题，一是用户是否真的能正确地描述自己的需求，二是需求人员是否真的能正确地理解需求。另外，还有一个用户的需求是否符合行业规范的问题，如果不符合，那么是否要确认——这里存在一个隐患，用户可能会在开发的后期突然要求他们自己要走行业规范，让你的需求变动，所以要事先明确好。
（2）检查需求文档描述的准确性。主要是考虑文档中是否存在描述的模糊的地方，对于自己不清楚的问题一定要明确。这个时候是要保证需求的可测试性——保证需求是可以完全为测试工作服务的。再说的具体一点，要保证所有的软件需求都是可以用某种方法来明确的判断是否符合要求的。如果对于某个需求，无法获得一个明确的判断标准，则应该请需求人员对需求进行修改或补充——一个缺乏准确定义的需求，我们可以认为开发人员也无法准确的实现或者实现一个错误的需求，如果在应用程序交付测试时才发现这个问题，带来的后果因项目而异了。
2.随着开发工作的开展，开发部门的架构设计以及详细设计也将陆续提交，这时候，我们可以根据设计文档来对原来的需求进行增补。注意，这里我们对于设计文档中提到的内容要有选择的采用，只有符合软件需求规格说明书或用例中已经定义的部分才可以用来调整我们的测试需求。而同软件需求不相符的部分，则需要同设计人员和需求人员一起讨论，确定下以哪一个为准，然后调整测试需求。这部分工作其实已经包含了对设计的检查，我们将继续努力尽早的发现缺陷出现的征兆。
3.在应用程序交付后，测试部门开始执行测试。这时很有可能通过一些我们根据测试需求设计的测试用例所没有包含的方法会找到一些缺陷，那么，这部分方法我们也应该整理到测试需求中。

*对于一个持续发展的公司或者持续开发的产品，它的所有东西都是要不断积累的。对于测试需求，不仅仅是在一个版本的开发过程中，在不同的阶段进行迭代，在产品的整个生命周期中的不同版本间也是不断迭代的。

*明确了测试需求，测试用例的考虑也变成自然而然的事情了。我们可以根据不同阶段已经确定下来的那些测试需求来进行测试用例的设计，然后随着开发过程的继续，在测试需求增补或修改后不断的调整测试用例。如果我们从产品的整个生命周期来看，会发现其实根本没有测试工作终结和测试需求&测试用例维护结束的时候，因为一个版本的结束是下一个版本的开始。从这个大的范围来看，我们的测试需求和测试用例将永远的不断迭代下去。