1．应验证界面显示内容的完整性：

a) 报表显示时应考虑数据显示宽度的自适应或自动换行。

b) 所有有数据展现的界面（如统计、查询、编辑录入、打印预览、打印等），必须使测试数据的记录数超过一屏/一页，以验证满屏/页时其窗体是否有横向、纵向滚动条或换页打印，界面显示是否正常；

2．应验证界面显示内容的一致性：

a) 如有多个系统展现同一数据源时，应保证其一致性；

3．应验证界面显示内容的准确性：

a) 对于报表中的所有字段值都应该有明确的定义，对于无意义的字段值，不应该显示空，应显示“--”或“/”，表示该字段值无意义。

4．应验证界面显示内容的友好性：

a) 对统计的数据应按用户习惯进行分类、排序。

b) 某些重要信息在输入、修改、删除时应有“确认”提示信息；

c) 界面内容更新后系统应提供刷新功能。

d) 用户在退出系统后重新登陆时应考虑是否需要自动返回到上次退出系统时的界面；

5．应验证界面提示信息的指导性：

a) 在多个业务功能组成的一个业务流程中，如果各个功能之间的执行顺序有一定的制约条件，应通过界面提示用户。

b) 用户提示信息应具有一定的指导性，在应用程序正在进行关键业务的处理时，应考虑在前台界面提示用户应用程序正在进行的处理，以及相应的处理过程，在处理结束后再提示用户处理完毕。

c) 在某些数据输入界面，如果要求输入的数据符合某项规则，应在输入界面提供相应的规则描述；当输入数据不符合规则时应提示用户是否继续。

d) 在对任何配置信息修改后，都应该在用户退出该界面时提示用户保存（如果用户没有主动保存的情况下）；

6．应验证界面显示内容的合理性：

a) 在对某些查询功能进行测试时，应考虑查询条件的设置的合理性以及查询结果的互补性。如某些后台处理时间不应该作为查询条件。

b) 界面测试时，应考虑某一界面上按钮先后使用的顺序问题，以免用户对此产生迷惑。例如只能在查询成功后显示执行按钮。

c) 界面测试时，应验证窗口与窗口之间、字段与字段之间的浏览顺序是否正确；

7．界面测试时，应考虑用户使用的方便性：

a) 在某些对数据进行处理的操作界面，应考虑用户可能对数据进行处理的频繁程度和工作量，考虑是否可以进行批量操作。

8．界面测试时，应考虑界面显示及处理的正确性：

a) 界面测试时应验证所有窗体中的对象状态是否正常，是否符合相关的业务规则需要。

b) 应验证各种对象访问方法（Tab 健、鼠标移动和快捷键）是否可正常使用，并且在一个激活界面中快捷键无重复；

c) 界面测试不光要考虑合理的键盘输入，还应考虑是否可以通过鼠标拷贝粘贴输入。

d) 对于统计查询功能的查询结果应验证其是否只能通过界面上的查询或刷新按键人工触发，应避免其他形式的触发。

e) 对界面上的任何对象进行拖拉，然后进行查询、打印，应保证查询打印结果不变；

9．界面测试时，应考虑数据显示的规范性：

a) 确保数据精度显示的统一：如单价0元，应显示为0.00元；

b) 确保时间及日期显示格式的统一；

c) 确保相同含义属性/字段名的统一；

d) 对所有可能产生的提示信息界面内容和位置进行验证，确保所有的提示信息界面应居中。

1、能发现到目前为止没有发现的缺陷的用例是好的用例

其实这句话是十分有道理的，但我发现很多人都曲解了这句话的原意，一心要设计出发现“难于发现的缺陷”而陷入盲目的片面中去，忘记了测试的目的所在，这是十分可怕的。我倾向于将测试用例当作一个集合来认识，对它的评价也只能对测试用例的集合来进行，测试本身是一种“V&V”的活动，测试需要保证以下两点：

* 程序做了它应该做的事情
* 程序没有做它不该做的事情

因此，作为测试实施依据的测试用例，必须要能完整覆盖测试需求，而不应该针对单个的测试用例去评判好坏。

2、测试用例应该详细记录所有的操作信息，使一个没有接触过系统的人员也能进行测试

不知道国内有没有公司真正做到这点，或者说，不知道有国内没有公司能够将每个测试用例都写得如此详细。在我的测试经历中，对测试用例描述的详细和复杂程度也曾有过很多的彷徨。写得太简单吧，除了自己没人能够执行，写得太详细吧，消耗在测试用例维护（别忘了，测试用例是动态的，一旦测试环境、需求、设计、实现发生了变化，测试用例都需要相应发生变化）上的时间实在是太惊人，在目前国内大部分软件公司的测试资源都不足的情况下，恐怕很难实现。但我偏偏就能遇到一些这样的老总或者是项目负责人，甚至是测试工程师本身，全然不顾实际的资源情况，一定要写出“没有接触过系统的人员也能进行测试”的用例。

在讨论这个问题之前，我们可以先考虑一下测试的目的。测试的目的是尽可能发现程序中存在的缺陷，测试活动本身也可以被看作是一个Project，也需要在给定的资源条件下尽可能达成目标，根据我个人的经验，大部分的国内软件公司在测试方面配备的资源都是不足够的，因此我们必须在测试计划阶段明确测试的目标，一切围绕测试的目标进行。

除了资源上的约束外，测试用例的详细程度也需要根据需要确定。如果测试用例的执行者、测试用例设计者、测试活动相关人对系统了解都很深刻，那测试用例就没有必要太详细了，文档的作用本来就在于沟通，只要能达到沟通的目的就OK。

在我担任测试经理的项目中，在测试计划阶段，一般给予测试设计30% - 40%左右的时间，测试设计工程师能够根据项目的需要自行确定用例的详细程度，在测试用例的评审阶段由参与评审的相关人对其把关。

3、测试用例设计是一劳永逸的事情

这句话摆在这里，我想没有一个人会认可，但在实际情况中，却经常能发现这种想法的影子。我曾经参与过一个项目，软件需求和设计已经变更了多次，但测试用例却没有任何修改。导致的直接结果是新加入的测试工程师在执行测试用例时不知所措，间接的后果是测试用例成了废纸一堆，开发人员在多次被无效的缺陷报告打扰后，对测试人员不屑一顾。
这个例子可能有些极端，但测试用例与需求和设计不同步的情况在实际开发过程中确是屡见不鲜的，测试用例文档是“活的”文档，这一点应该被测试工程师牢记。

4、测试用例不应该包含实际的数据

测试用例是“一组输入、执行条件、预期结果”、毫无疑问地应该包括清晰的输入数据和预期输出，没有测试数据的用例最多只具有指导性的意义，不具有可执行性。当然，测试用例中包含输入数据会带来维护、与测试环境同步之类的问题，关于这一点，《Effective Software Test》一书中提供了详细的测试用例、测试数据的维护方法，可以参考。

5、测试用例中不需要明显的验证手段

我见过很多测试工程师编写的测试用例中，“预期输出”仅描述为程序的可见行为，其实，“预期结果”的含义并不只是程序的可见行为。例如，对一个订货系统，输入订货数据，点击“确定”按钮后，系统提示“订货成功”，这样是不是一个完整的用例呢？是不是系统输出的“订货成功”就应该作为我们唯一的验证手段呢？显然不是。订货是否成功还需要查看相应的数据记录是否更新，因此，在这样的一个用例中，还应该包含对测试结果的显式的验证手段：在数据库中执行查询语句进行查询，看查询结果是否与预期的一致。

TestComplete从Excel取值实例

qiguojie的51testing原创文章，转载请注明出处，非常感谢！

因为曾经使用过Winrunner 7.6，对其自动的数据驱动测试功能印象非常深刻（独立的一个功能模块，可以方便的从Excel中读取数据进行参数化的输入），非常的方便。刚开始接触TestComplete时就记得2点：一个是WR支持鼠标操作录制但很不好用，TestComplete对其支持就非常好；另外一个就是WR的数据驱动功能比TC的强太多。

但是数据驱动测试是自动化测试的一个应用非常多的测试类型，因此我查询了TC的帮助文件，写了一个实例出来，描述怎么才能从Excel文件中获取对应的数据。

TestComplete的简单使用步骤：
1、打开TestComplete
2、选择菜单 File - New - New Project创建一个新项目
3、选择General - Purpose Test Project，然后选择Language为Delphiscrīpt后OK
4、Select Project Items中默认，然后Finish即可
5、在Project Workspace的Project Explorer中点击脚本对应的Unit1单元文件
6、复制下面的代码到单元文件
7、保存，然后F9执行

//========================
//Author:qiguojie
//Date:2008-05-05
//scrīpt Type: Delphiscrīpt
//========================

//定义全局变量
var
     MSExcel : OleVariant;
     ExcelFile;

//声明读取值的函数
function ReadExcel(i,j):string;forward;

Procedure MyTest;
var
    i,j : Integer;
    FileName : String;
begin
    FileName := 'E:\1.xls';
    j := 1;

//检查Excel是否启动
    ExcelFile := Sys.WaitProcess('EXCEL');
    if ExcelFile.Exists then
        ExcelFile.Terminate();
    try
        MsExcel := Sys.OleObject('Excel.Application');
    except
        Log.Warning('Unable to initialize MS Excel.', '', pmHigher);
        Exit;
    end;

//打开对应Excel文件
    MsExcel.Workbooks.Open(FileName);

//循环取出10个值
    for i := 1 to 10 do
    begin
        log.message(ReadExcel(i,j));
    end;
end;

//读取值的函数实现
function ReadExcel(i,j):string;
begin   
    Result := MsExcel.Cells(i,j).Value;
end;