《软件测试》第十八章 编写和追踪测试用例

The Goals of [b]Test Case Planning - 计划的目的测试用例[/b]

测试用例计划的目的是什么呢？如果你想要别人按照一定的规矩办事，那么你自己也必须首先遵守这些规矩。所以作为一个测试员，如果一拿到测试计划就坐下来疯狂的写Case，那么跟一个不看产品说明书就开始编码的程序员是一样的。我们要仔细地而且系统地去计划测试用例，为什么要这样子呢？有4个原因：
Organization - 一份好的计划可以被很好地组织起来，这样的话出来你以外的其他人就能有效地回顾你的成品
Repeatability - 如果没有一个正确的计划，那么是不可能知道我们的测试用例运行情况，而且几乎不能被重新使用，因为通常你都不知道它在哪里
Tracking - 可追踪的。有了好的计划，才能追踪项目的进度，多少case已经被执行了多少pass多少fail。各自状态如何。
Proof of testing (or not testing) - 证明已经测试过的。这个记得以前在reyrey的时候一个老外就说过，测试用例能够帮助公司避免法律的纷争。

Test Case Planning Overview - 测试用例计划概览
除了书中以前说的测试计划(Test Plan)，在它的下面会有这些：test design specification(测试设计说明书), test case specification(测试用例说明书), the test procedure specification(测试流程说明书)

Test Design - 测试设计。
这个“设计”是为产品说明书中的单独的软件功能定义测试方法的。“把测试计划中定义的测试方法提炼出来，并且识别出需要测试覆盖的对象及其相关测试。也需要识别出测试用例和测试流程，如果有需要的话完成测试的入口条件和出口条件”测试计划的目的是组织和描述那些对特定功能的测试，但是在测试设计里面是不会设计到细节的。一下列出了IEEE 829标准的一些点，这些点是一个测试计划需要包含的内容。这些都是用做参考而不是标准的：
Identifiers - 就是ID，用来跟其他相关文档做关联的。例如这个测试计划#9527对应的是#173173的测试用例。
Features to be tested - 被测试的功能。就是对被测试功能的描述~在这部分还需要识别出那些不是直接测试到的功能，例如测试一个save对话框的时候可以顺便检查UI。还有的就是要定义哪些功能是不需要测试的，不要做无用功。
Approach - 测试方法。黑盒白盒手动自动~
Test case identification - 测试用例的识别。这里不是说要有详细的测试用例，只是标明了哪些测试用例将会覆盖哪些功能的测试。具体细节不会出现在测试设计里面。
Pass/fail criteria - 通过测试和测试失败的标准。

Test Cases - 测试用例。
“对测试的实际输入以及其相应的输出进行文档记录，测试用例同时识别出任何在测试流程中可能出现的限制。”而且测试用例会跟一个或多个测试计划想关联，而通常还会跟不止一个的测试流程关联。
Identifiers - ID，用来做文档关联。
Test item - 测试项目。描述被测试的细节的功能，代码模块等等。而且还需要关联上哪些文档提及到了被测试的功能。
Input specification - 输入详述。列举出所有的输入或者执行测试用例的条件。
Output specification - 输出详述。描述测试用例的期望输出。
Environmental needs - 环境需要。是不是需要特定的硬件软件外设工具等等？
Special procedural requirements - 特殊的程序要求？
Intercase dependencies - 用例之间的相互依赖，是否有一些用例，需要在别的用例执行通过的情况下才能进行的。

Test Procedures - 测试流程。
“识别出执行所需要的步骤。测试流程是一步一步如何去执行测试用例的细节说明”
Identifiers - ID，用来做文档关联。
Purpose - 目的。
Special requirements - 特殊需求。
Procedure steps - 流程步骤。

Detail Versus Reality - 与实际的对照。
The trick is finding the right level of moderation - 这里的窍门就是找到合适的度。古人云：过犹不及。很多时候我们要做到什么样的程度，取决于每个项目不同的要求。

Test Case Organization and Tracking - 测试用例的组织与跟踪
In your head - 记载脑子里面？俗语说的好啊，好记性不如烂笔头。大家还是省点头脑风暴的时间吧。
Paper/documents - 记在文档里面有个缺点就是很难找到具体想要的东西，不过好处就是如果有个测试员的签名的话，是个很好避免法律纠纷的方法，呵呵
Spreadsheet - 电子表格。日本公司喜欢用Excel（当然啦，Excel只是其中一种Spreadsheet）。而且用的出神入化。我看我连Excel的门都没入啊。
4000
唉。
Custom database - 数据库。一种比较好的选择就是测试用例管理工具。例如QC, CC。呵呵。不过是要钱di。还是看开源的吧。

后记：其实书里面分的好细，一般公司也就是一个测试计划下来就是测试用例了，而且一般我们说的测试用例都已经包含了测试流程的内容--具体的执行步骤。我觉得任何书或者参考资料或者方法论都只是参考而不是标准，即使它们没有说能够被裁剪，但是我们也可以发挥自己的主观能动性来改造它们，让之适合我们各自的使用情况。我个人觉得就不用死扣你这公司不标准啊怎么测试用例跟测试流程都连在一起了。呵呵。做人要变通：）