软件测试用例的基本要素包括测试用例编号、测试标题、重要级别、测试输入、操作步骤、预期结果，下面逐一介绍。

　　用例编号： 测试用例的编号有一定的规则，比如系统测试用例的编号这样定义规则： PROJECT1-ST-001 ，命名规则是项目名称＋测试阶段类型（系统测试阶段）＋编号。定义测试用例编号，便于查找测试用例，便于测试用例的跟踪。

　　测试标题： 对测试用例的描述，测试用例标题应该清楚表达测试用例的用途。比如 “ 测试用户登录时输入错误密码时，软件的响应情况 ” 。

　　重要级别： 定义测试用例的优先级别，可以笼统的分为 “ 高 ” 和 “ 低 ” 两个级别。一般来说，如果软件需求的优先级为 “ 高 ” ，那么针对该需求的测试用例优先级也为 “ 高 ” ；反之亦然，

　　测试输入： 提供测试执行中的各种输入条件。根据需求中的输入条件，确定测试用例的输入。测试用例的输入对软件需求当中的输入有很大的依赖性，如果软件需求中没有很好的定义需求的输入，那么测试用例设计中会遇到很大的障碍。

　　操作步骤： 提供测试执行过程的步骤。对于复杂的测试用例，测试用例的输入需要分为几个步骤完成，这部分内容在操作步骤中详细列出。

　　预期结果： 提供测试执行的预期结果，预期结果应该根据软件需求中的输出得出。如果在实际测试过程中，得到的实际测试结果与预期结果不符，那么测试不通过；反之则测试通过。

一套完整的测试应该由五个阶段组成：

　　1．测试计划

　　首先，根据用户需求报告中关于功能要求和性能指标的规格说明书，定义相应的测试需求报告，即制订黑盒测试的最高标准，以后所有的测试工作都将围绕着测试需求来进行，符合测试需求的应用程序即是合格的，反之即是不合格的；同时，还要适当选择测试内容，合理安排测试人员、测试时间及测试资源等。

　　2．测试设计

　　将测试计划阶段制订的测试需求分解、细化为若干个可执行的测试过程，并为每个测试过程选择适当的测试用例（测试用例选择的好坏将直接影响到测试结果的有效性）。

　　3．测试开发

　　建立可重复使用的自动测试过程。

　　4．测试执行

　　执行测试开发阶段建立的自动测试过程，并对所发现的缺陷进行跟踪管理。测试执行一般由单元测试、组合测试、集成测试、系统联调及回归测试等步骤组成，测试人员应本着科学负责的态度，一步一个脚印地进行测试。

　　5．测试评估

　　结合量化的测试覆盖域及缺陷跟踪报告，对于应用软件的质量和开发团队的工作进度及工作效率进行综合评价。

　　显然，黑盒测试只有严格按照步骤进行，才可能对应用程序的质量进行把关。然而，如果没有一种优秀的测试工具的帮助，单纯凭借手工测试，不但将耗费大量的人力、物力和财力，而且有很多测试工作是难以实现甚至是无法实现的。

在有些组织里，程序员几乎会把一半的测试bug返回给测试组，因为那些错误不可再现、没有发现错误、同设计要求一致，或者错误报告根本无法操作。如果错误报告有如此高的返回率，基本可以认为是过程崩溃，需要立即解决：因为编写这些报告浪费了时间；会影响程序员和测试人员之间的团队凝聚力；最糟糕的是失去改进产品质量的机会。

　　有些错误总是不可再现的或提出质疑的。有些错误只是间断地在模糊的或极端的条件下表现出来。有时候，测试环境和程序员之间的不一致会导致“在我的系统上工作良好”的反应。在需求不清楚的项目中，在一定的测试条件下，对“正确”行为的观点可以存在合理的不同。有时候，当真正的问题在于糟糕的测试过程、测试数据或不正确的测试用例时，测试人员可能错误解释测试测试结果和报告错误。

　　为了防止这类问题，要提交好的测试bug，作为一个好的测试人员，必须遵循以下八个步骤：

　　1) 结构：无论你是做探索性的或是描述性的、手工的或自动的测试，都要认真仔细的测试；

　　2)再现：尽量三次再现故障。如果问题是间断的，那么最好报告问题发生的概率；例如，每3次出现一次，每3次出现2次等；

　　3) 推广：确定系统其他部分是否可能出现这种错误，以及使用不同的数据是否可能出现这种问题，特别是那些存在严重影响的问题。

　　4)总结：简要描述客户或用户的质量体验和观察到的一些特征。

　　5)压缩：精简任何不必要的信息，特别是冗余的测试步骤。

　　6)去除歧义：使用清晰的语言，尤其要避免使用那些有多个不同或相反含义的词汇。

　　7)中立：公正地表达自己的意思，对错误及其特征的事实进行描述，避免夸张或忽略的语句，引起过度的注意力或忽视。

　软件缺陷管理之缺陷严重等级分类

　　A类——严重错误，包括：

　　1.由于程序所引起的死机,非法退出

　　2.死循环

　　3.导致数据库发生死锁

　　4.数据通讯错误

　　5.严重的数值计算错误

　　6.需求未实现

　　7.文档与软件不符、文档严重不足、系统文档关键错误

　　B类——较严重错误，包括：

　　1.功能不符

　　2.数据流错误

　　3.程序接口错误

　　4.轻微的数值计算错误

　　C类——中等错误。包括：

　　1.程序非正常终止但可通过其它输入来避免

　　2.系统边界错误

　　3.显示报表错误

　　4.数据处理、需求理解错误

　　5.系统文档一般错误

　　D类——一般性错误，包括：

　　1.界面错误(详细文档)

　　2.打印内容、格式错误

　　3.简单的输入限制未放在前台进行控制

　　4.删除操作未给出提示

　　5.系统操作不方便

　　E类——较小错误，包括：

　　1.辅助说明描述不清楚

　　2.显示格式不规范、查询报告格式错误

　　3.长时间操作未给用户进度提示

　　4.提示窗口文字未采用行业术语

　　5.可输入区域和只读区域没有明显的区分标志

　　6.系统处理未优化

　　F类——测试建议（非缺陷）

　Always: 这类bug所要做到的就是如何把bug描述清楚

　　1． 察看当前和bug相关的条件并列出

　　2． 按照bug出现的步骤重复做3次以上以此来寻找最短的路径，尽量把不必要的过程过滤，当然不确定的步骤一定不能过滤

　　3． 描述的时候尽量做到每个步骤最多2个动作

　　4． 尽量用主动的英语句型，在遇到许多动作可以产生这个bug的时候，可以适当用被动句型，把最好重现bug的那个步骤写出来其他可放在括号中

　　5． Bug现象的说明一定要描述详细，不要放在步骤中

　　6． 发现bug之后的操作最好也做几个步骤(如果可以接着做的话)，这样更容易发现周围的bug，同时对开发人员解bug也是有帮助

　　7．尽量把bug的周围情况描述的详细些，不需要总是等到开发人员问了我们再去做

　　Usually：这类bug和always一样重点就是把步骤描述全面详细且不冗杂

　　Sometimes：这类bug在遇到的时候可以先和开发人员描述一下然后共同推测路径，如果可以转化为always或usually，解决就容易些了,实在重现不出来可以把自己所做的若干步骤都描述出来

　　Once： 这类bug，开发人员解起来更难

　　作为测试人员，所能做的就是除了上述bug的描述之外需要更加注意的：

　　1． 尽量做到及时和开发人员沟通

　　2． 立刻检查当前状态并做记录

　　3． 把和当前bug相关的一切信息全部描述

　　4． 和当前bug可能相关的信息可以放在note中，一定要详细

　　此外，如果连续发生好几个bug，需要把每个bug的频率标注好，如果有外部网络或者设备等影响的尽量把这些外部环境也描述清楚，这样有助于开发人员解决问题。

　　我们的目的：“做到质量更好的同时效率更高，我们不但要发现问题还要帮助开发人员解决问题“