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

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

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

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

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

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

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

网站测试流程、要求及测试报告

　　一个网站基本完工后，需要通过下面三步测试才可以交活。

　　一、 制作者测试，包括美工测试页面、程序员测试功能。在做完后第一时间内有制作者本人进行测试。

　　a) 页面 包括首页、二级页面、三级页面的页面在各种常用分辨率下有无错位;图片上有没有错别字;各连接是否是死连接;各栏目图片与内容是否对应等

　　b) 功能 达到客户要求;数据库连接正确;各个动态生成连接正确;传递参数格式、内容正确;试填测试内容没有报错;页面显示正确

　　二、 全面测试 根据交工标准和客户要求，由专人进行全面测试

　　也是包括页面和程序两方面，而且要结合起来测，保证填充足够的内容后不会导致页面变形。另外要检查是否有错别字，文字内容是否有常识错误。

　　三、 发布测试 网站发布到主服务器之后的测试，主要是防止环境不同导致的错误

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

　　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的频率标注好，如果有外部网络或者设备等影响的尽量把这些外部环境也描述清楚，这样有助于开发人员解决问题。

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

并发用户：并发一般分为2种情况。

一种是严格意义上的并发，即所有的用户在同一时刻做同一件事情或者操作，这种操作一般指做同一类型的业务。比如在信用卡审批业务中，一定数目的拥护在同一时刻对已经完成的审批业务进行提交；还有一种特例，即所有用户进行完全一样的操作，例如在信用卡审批业务中，所有的用户可以一起申请业务，或者修改同一条记录。

　　另外一种并发是广义范围的并发。这种并发与前一种并发的区别是，尽管多个用户对系统发出了请求或者进行了操作，但是这些请求或者操作可以是相同的，也可以是不同的。对整个系统而言，仍然是有很多用户同时对系统进行操作，因此也属于并发的范畴。

　　可以看出，后一种并发是包含前一种并发的。而且后一种并发更接近用户的实际使用情况，因此对于大多数的系统，只有数量很少的用户进行“严格意义上的并发 ”。对于WEB性能测试而言，这2种并发情况一般都需要进行测试，通常做法是先进行严格意义上的并发测试。严格意义上的用户并发一般发生在使用比较频繁的模块中，尽管发生的概率不是很大，但是一旦发生性能问题，后果很可能是致命的。严格意义上的并发测试往往和功能测试关联起来，因为并发功能遇到异常通常都是程序问题，这种测试也是健壮性和稳定性测试的一部分。

请求响应时间：指的是客户端发出请求到得到响应的整个过程的时间。在某些工具中，请求响应时间通常会被成为"TLLB"，即"Time to last byte"，意思是从发起一个请求开始，到客户端接收到最后一个字节的响应时间所耗费的时间。请求响应时间过程的单位一般为"秒"或者"毫秒"。

事务响应时间：事务可能由一系列请求组成，事务的响应时间主要是针对用户而言，属于宏观上的概念，是为了向用户说明业务响应时间而提出的。例如：跨行取款事务的响应时间就是由一系列的请求组成的。事务响应时间和后面的业务吞吐率都是直接衡量系统性能的参数。

吞吐量：指的是在一次性能测试过程中网络上传输的数据量的总和。吞吐量/传输时间，就是吞吐率。

TPS：每秒钟系统能够处理的交易或者事务的数量。它是衡量系统处理能力的重要指标。

点击率：每秒钟用户向WEB服务器提交的HTTP请求数。这个指标是WEB应用特有的一个指标：WEB应用是"请求-响应"模式， 用户发出一次申请，服务器就要处理一次，所以点击是WEB应用能够处理的交易的最小单位。如果把每次点击定义为一个交易，点击率和TPS就是一个概念。容易看出，点击率越大，对服务器的压力越大。点击率只是一个性能参考指标，重要的是分析点击时产生的影响。需要注意的是，这里的点击并非指鼠标的一次单击操作，因为在一次单击操作中，客户端可能向服务器发出多个HTTP请求。

资源利用率：指的是对不同的系统资源的使用程度，例如服务器的CPU利用率，磁盘利用率等。资源利用率是分析系统性能指标进而改善性能的主要依据，因此是WEB性能测试工作的重点。

资源利用率主要针对WEB服务器，操作系统，数据库服务器，网络等，是测试和分析瓶颈的主要参考。在WEB性能测试中，更根据需要采集相应的参数进行分析。

服务器主机地址：www.atstudy.com
用户名：user02  密码：hljasdlfnasdf
用户名：user03  密码：nlqkwernnadf