2.3.2. 一个典例测试用例
程序：一个程序接受 3 个整型输入。 3 个整型值代有表三角形的 3 条边。根据这 3 个值，程序要确定出这个三角形是不等边三角形、等腰三角形还是等边三角形。
完整的测试用例：
测试用例的目的 注释
有效的不等边三角形 诸如 1 、 2 、 3 和 2 、 5 、 10 之类的测试用例不能保证“是”答案，因为不存在这样的三角形
有效的等边三角形
有效的等腰三角形 1 ， 1 ， 2 类测试用例不能计算在内，因为不存在这样的三角形
测试用例是有效的等腰三角形，从而就包括了两个等边的 3 个置换 例如： 3 、 3 、 4 ; 3 、 4 、 3 和 4 、 3 、 3
一个边是 0
一个边是负值
3 个大于 0 的整数，并且 2 个数的和与第 3 个数相等 如果程序认为 1 、 2 、 3 表示不等边三角形，则是一个 BUG
在上面测试中至少有 3 个测试用例，这样你便可以尝试 3 种排列。其中 1 个边的长度等于另外 2 个边和的长度
3 个大于 0 的整数，并且 2 个数的和小于第 3 个数 如： 1 、 2 、 4 和 12 、 15 、 30
在上面测试中至少有 3 个测试用例，这样你可以尝试 3 种排列 如： 1 、 2 、 4 ; 1 、 4 、 2 和 4 、 1 、 2
所有的边为 0
非整数值
输入数据的个数错误 如输入 2 个或多于 3 个数
是否规定了每一个测试用例的预期输出
(摘录自《软件验证与确认的非常好的管理方法》)
2.4. 测试流程
测试的流程对于实际情况有两种 :
2.4.1. 开发小组程序员之间的联调
程序员之间的联调多发生在多个子系统构成的大系统或一个系统由多人根据功能分工编写的情况下。
测试流程一般由业务发起点的功能编写者发起测试，到达业务的终止点为结束。
具体形式如下：
起始点的开发者发起业务后，添写纸质的联调测试书，明确发起的内容，送到下一个处理环节的程序员处。
相应的下一环节程序员，进行相应的处理。处理完毕后，添加联调测试书中相应的部分或在联调测试书中签字说明已经完成相应的处理，再送下一处理环节的程序员处，通过这种类似层层审批的方式到达最终点，完成内部联调流程。
内部联调是对于每个程序员所编程序的测试，由于分工及技术水平的不同，一般容易产生每个程序员工作量及进展难于把握 的情况，所以对于联调测试期人员分工要进行灵活调动的方式。
2.4.2. 测试小组同程序开发小组的工作形式
1. 程序人员自我测试后提交项目经理请求测试验收，项目经理文字或其他方式通知测试负责人准备提交测试，测试负责人到程序员处当场进行初验(程序员当场演示)，记录当场发现的 BUG 数(推荐每个程序员的办公桌前有一个 初验 BUG 数表 ，每次初验 BUG 数记录在文件内， 周报时通报 每周最高和最低的人员及 BUG 数，，最终测试期阶段初验 BUG 数据影响程序人员考核，用来加强程序人员进行初验前的自验重视程度)
2. 初验合格，程序员把项目文件(源程序包)及 EXE 文件(或安装程序包)打包在一个 ZIP 文件。发送给内部文件管理员或项目规定的测试文件存放目录，否则程序员进行修改后并重复第 1 步。
3. 文件管理员进行本次测试的版本文件归档后，文件管理员再通知测试负责人要进行测试的文件所存放的位置。
4. 测试负责人取相应的系统进行测试， 记录测试过程 ，最终提交测试结果形成 BUG 列表，传达给项目经理 , 项目经理审查后再传送给程序员。
5. 程序员根据 BUG 列表进行相应的程序修改，并对 BUG 列表文件进行更新，发送给项目经理，项目经理审核后再传送给测试负责人。
6. 重复第 1 步，后期的测试中测试人员将对原测试错误进行跟踪审查。
测试负责人及文件管理员可以是专人也可由项目经理或系统分析员兼任。
如果使用最终用户作为测试人员，千万注意，过多的 BUG (特别是对于金额的误差)的发现，会使用户对系统有恐惧心理，认为将来给他们的程序是一个大炸弹。所以在提交前，必须进行严格的自验。对于 BUG 的必需严肃的对待，不然将影响用户对系统的信心。对于由于不严谨产生严重的 BUG ，必须进行必要的批评(周会或小组会议)，使程序员加强自身的检查。
2.4.3. 测试小组工作要求
1 、 BUG 列表的提交及数据提交
A) 要求记录所有的 BUG 。
B) 重大 BUG 可即时提交由项目组解决，但必须作好 BUG 记录，并继续其它的测试 ( 除不能进行测试以 外 ) 。
C) 对于某些测试人员认为要进行的测试，若进行不了，应作 BUG 提交。
D) 数据的记录应详细，所作的所有操作关键数据均应记录。
