一． 测试过程中的优点

　　1. 对需求的测试

　　测试人员在获得需求后，对需求进行正确性，一致性，完整性，可理解性等的检查，将检查过程中发现的问题都记录下来，然后在需求评审之前一到两天统一汇总到需求人员手中，需求人员对测试人员的问题进行解答，在进行需求评审会议的时候，需求人员在讲解完需求后，再针对测试提交的问题进行解答，解答完问题后，评审人员根据之前的情况再提问需求人员，这样可以提高评审会议的效率，同时，测试人员在检查需求，以及参与需求评审的时候，对需求的理解就会更深入。

　　2. 测试风险的估计及应对

　　写在测试计划中的测试风险，一定要有明确的可执行的应对方法。否则，如果在测试过程中出现了风险防范中列举的风险，但是没有可执行的方法，可能会严重影响到测试工作，最常见的的，比人测试人员的离职会不会对整个项目测试工作造成影响，有没有可以预防的方法，因为，新招聘一个测试人员参与项目，不但会严重影响到测试进度的，还可能出现因为交接不充分而出现测试遗漏。

　　3. 测试时间安排

　　测试计划中，测试时间安排是最重要的一个方面，要将测试时间安排的最合理主要有两个方面，一个是测试人员的能力，一个是测试工作量的估算，能力决定了测试人员擅长或者不擅长的方面，分配测试工作的时候，应该量体裁衣，每个测试工作人员做自己最擅长的部分，对于能力较弱的，可以分配一些简单的测试工作，但是量可以多一点。另一个方面是测试工作量的估算，它决定了测试时间安排的合理与否，测试项目可以分为好几个测试阶段，每个测试阶段的测试内容可以分为不同的测试任务，而每个测试任务又可以分为测试子任务，不能再分的测试子任务才能作为一个独立的测试任务，估算该测试任务需要花费的时间，在估算测试工作量的时候，还要考虑缓冲，测试工作量如果估算的十分精确，一定要有缓冲时间，因为，人不可能完全按照计划工作。

　　4. 测试用例评审

　　测试用例评审之前，主持人要做好准备工作，向测试用例提前发送给邀请的对象，同时在会议开始之前准备好会议室，电脑等，在测试用例评审过程中，因为测试用例很多，不能一一都过，最重要的是，测试人员在测试评审的时候，讲解清楚每个测试用例，或者每组测试用例是用来验证什么的，以及这些测试用例执行后能够发现哪些类型缺陷，讲解清楚自己的一个测试思路。

　　5. 测试汇报进度

　　从测试进入项目开始，测试人员最好是每天能够汇报当天的进度以及以后一两天的工作安排，汇报对象为测试组成员，测试经理，而测试经理则将每个人的汇报汇总后，发邮件给需求，开发，这样，一方面督促测试人员做好自己的工作，令一方面，也可以让其他项目相关人员了解测试人员的工作进度，更好的做好前提工作，因为测试人员的工作基本上是依赖于需求和开发的。

　　6. 测试环境管理

　　测试环境最好是有测试人员管理，这样，一方面可以锻炼测试人员的能力，更重要的是可以杜绝开发随便修改测试环境中的数据。保证测试环境的独立性。

　　7. 版本控制

　　如果测试人员测试的版本，每个版本之间是迭代开发完成的，则需要针对每个版本都做冒烟测试，对每个版本都要根据测试策略做完整的测试。如果每个版本提交比较频繁，测试人员只针对重要的版本进行测试，但针对每个版本都应该做版本验证测试，以免遗留有重要的缺陷。

　　一、功能测试

　　1、链接测试

　　链接是Web应用系统的一个主要特征，它是在页面之间切换和指导用户去一些不知道地址的页面的主要手段。链接测试可分为三个方面。首先，测试所有链接是否按指示的那样确实链接到了该链接的页面；其次，测试所链接的页面是否存在；最后，保证Web应用系统上没有孤立的页面，所谓孤立页面是指没有链接指向该页面，只有知道正确的URL地址才能访问。

　　链接测试可以自动进行，现在已经有许多工具可以采用。链接测试必须在集成测试阶段完成，也就是说，在整个Web应用系统的所有页面开发完成之后进行链接测试。

　　2、表单测试

　　当用户给Web应用系统管理员提交信息时，就需要使用表单操作，例如用户注册、登陆、信息提交等。在这种情况下，我们必须测试提交操作的完整性，以校验提交给服务器的信息的正确性。例如：用户填写的出生日期与职业是否恰当，填写的所属省份与所在城市是否匹配等。如果使用了默认值，还要检验默认值的正确性。如果表单只能接受指定的某些值，则也要进行测试。例如：只能接受某些字符，测试时可以跳过这些字符，看系统是否会报错。

　　3、Cookies测试

　　Cookies通常用来存储用户信息和用户在某应用系统的操作，当一个用户使用Cookies访问了某一个应用系统时，Web服务器将发送关于用户的信息，把该信息以Cookies的形式存储在客户端计算机上，这可用来创建动态和自定义页面或者存储登陆等信息。

　　如果Web应用系统使用了Cookies，就必须检查Cookies是否能正常工作。测试的内容可包括Cookies是否起作用，是否按预定的时间进行保存，刷新对Cookies有什么影响等。

　　4、设计语言测试

　　Web设计语言版本的差异可以引起客户端或服务器端严重的问题，例如使用哪种版本的HTML等。当在分布式环境中开发时，开发人员都不在一起，这个问题就显得尤为重要。除了HTML的版本问题外，不同的脚本语言，例如Java、Javascrīpt、 ActiveX、VBscrīpt或Perl等也要进行验证。

　　5、数据库测试

　　在Web应用技术中，数据库起着重要的作用，数据库为Web应用系统的管理、运行、查询和实现用户对数据存储的请求等提供空间。在Web应用中，最常用的数据库类型是关系型数据库，可以使用SQL对信息进行处理。

在使用了数据库的Web应用系统中，一般情况下，可能发生两种错误，分别是数据一致性错误和输出错误。数据一致性错误主要是由于用户提交的表单信息不正确而造成的，而输出错误主要是由于网络速度或程序设计问题等引起的，针对这两种情况，可分别进行测试。

　　二、性能测试

　　1、连接速度测试

　　用户连接到Web应用系统的速度根据上网方式的变化而变化，他们或许是电话拨号，或是宽带上网。当下载一个程序时，用户可以等较长的时间，但如果仅仅访问一个页面就不会这样。如果Web系统响应时间太长（例如超过5秒钟），用户就会因没有耐心等待而离开。

　　另外，有些页面有超时的限制，如果响应速度太慢，用户可能还没来得及浏览内容，就需要重新登陆了。而且，连接速度太慢，还可能引起数据丢失，使用户得不到真实的页面。

　　2、负载测试

　　负载测试是为了测量Web系统在某一负载级别上的性能，以保证Web系统在需求范围内能正常工作。负载级别可以是某个时刻同时访问Web系统的用户数量，也可以是在线数据处理的数量。例如：Web应用系统能允许多少个用户同时在线？如果超过了这个数量，会出现什么现象？Web应用系统能否处理大量用户对同一个页面的请求？

　　3、压力测试

　　负载测试应该安排在Web系统发布以后，在实际的网络环境中进行测试。因为一个企业内部员工，特别是项目组人员总是有限的，而一个Web系统能同时处理的请求数量将远远超出这个限度，所以，只有放在Internet上，接受负载测试，其结果才是正确可信的。

　　进行压力测试是指实际破坏一个Web应用系统，测试系统的反映。压力测试是测试系统的限制和故障恢复能力，也就是测试Web应用系统会不会崩溃，在什么情况下会崩溃。黑客常常提供错误的数据负载，直到Web应用系统崩溃，接着当系统重新启动时获得存取权。

　　压力测试的区域包括表单、登陆和其他信息传输页面等。

　　三、可用性测试

　　1、导航测试

　　导航描述了用户在一个页面内操作的方式，在不同的用户接口控制之间，例如按钮、对话框、列表和窗口等；或在不同的连接页面之间。通过考虑下列问题，可以决定一个Web应用系统是否易于导航：导航是否直观？Web系统的主要部分是否可通过主页存取？Web系统是否需要站点地图、搜索引擎或其他的导航帮助？

　　在一个页面上放太多的信息往往起到与预期相反的效果。Web应用系统的用户趋向于目的驱动，很快地扫描一个Web应用系统，看是否有满足自己需要的信息，如果没有，就会很快地离开。很少有用户愿意花时间去熟悉Web应用系统的结构，因此，Web应用系统导航帮助要尽可能地准确。

　　导航的另一个重要方面是Web应用系统的页面结构、导航、菜单、连接的风格是否一致。确保用户凭直觉就知道Web应用系统里面是否还有内容，内容在什么地方。

　　Web应用系统的层次一旦决定，就要着手测试用户导航功能，让最终用户参与这种测试，效果将更加明显。

　　2、图形测试

　　在Web应用系统中，适当的图片和动画既能起到广告宣传的作用，又能起到美化页面的功能。一个Web应用系统的图形可以包括图片、动画、边框、颜色、字体、背景、按钮等。图形测试的内容有：

　　（1）要确保图形有明确的用途，图片或动画不要胡乱地堆在一起，以免浪费传输时间。Web应用系统的图片尺寸要尽量地小，并且要能清楚地说明某件事情，一般都链接到某个具体的页面。

　　（2）验证所有页面字体的风格是否一致。

　　（3）背景颜色应该与字体颜色和前景颜色相搭配。

　　（4）图片的大小和质量也是一个很重要的因素，一般采用JPG或GIF压缩。

　　3、内容测试

　　内容测试用来检验Web应用系统提供信息的正确性、准确性和相关性。

　　信息的正确性是指信息是可靠的还是误传的。例如，在商品价格列表中，错误的价格可能引起财政问题甚至导致法律纠纷；信息的准确性是指是否有语法或拼写错误。这种测试通常使用一些文字处理软件来进行，例如使用Microsoft Word的"拼音与语法检查"功能；信息的相关性是指是否在当前页面可以找到与当前浏览信息相关的信息列表或入口，也就是一般Web站点中的所谓"相关文章列表"。

　　4、整体界面测试

　　整体界面是指整个Web应用系统的页面结构设计，是给用户的一个整体感。例如：当用户浏览Web应用系统时是否感到舒适，是否凭直觉就知道要找的信息在什么地方？整个Web应用系统的设计风格是否一致？



　　对整体界面的测试过程，其实是一个对最终用户进行调查的过程。一般Web应用系统采取在主页上做一个调查问卷的形式，来得到最终用户的反馈信息。

　　对所有的可用性测试来说，都需要有外部人员（与Web应用系统开发没有联系或联系很少的人员）的参与，最好是最终用户的参与。

　　四、客户端兼容性测试

　　1、平台测试

　　市场上有很多不同的操作系统类型，最常见的有Windows、Unix、Macintosh、Linux等。Web应用系统的最终用户究竟使用哪一种操作系统，取决于用户系统的配置。这样，就可能会发生兼容性问题，同一个应用可能在某些操作系统下能正常运行，但在另外的操作系统下可能会运行失败。

　　因此，在Web系统发布之前，需要在各种操作系统下对Web系统进行兼容性测试。

　　2、浏览器测试

　　浏览器是 查看(1251) 评论(0) 收藏 分享 管理

首先，不要假设说明书上的所有内容都是正确的，也不要等到程序发布以后再根据程序去理解需求说明书，然后去设计测试。你手上有需求说明书，你就要努力的去理解他，因为这是你这个时候的工作，如果你在理解需求说明书的时候有困难，你可以寻找相关的人来帮助你，可能是需求说明书的作者，也可能是项目经理，或者是相关的程序员，只要你在这个时候寻求帮助，他们肯定会乐意帮助你的。在这个时候，你就要首先弄明白需求说明书的内容，因为，你后面的测试工作的展开，比如测试需求，测试用例，测试计划都是依照需求说明书的，如果你不理解测试用例，你就不能准确估算你的测试工作量，你也不能详细的设计你的测试策略，还有你的测试用例。

其次，努力获得和你要测试的项目相似的已经成型的系统，然后认真去研究它。可能你的项目没有详细的需求规格说明书，但是这个项目可能是以前系统的升级，或者只是做了很好的改动，或者，这个项目是根据现有市场上的已有产品的优化，无论怎么样，都可能会找到和现有系统类似的项目或者产品，这些可能项目经理可能会准备好，那么询问项目经理，得到它们然后，仔细研究它们。

当你得到了和你将要测试的系统类似的已经成熟的产品，就对她进行详细的检查，不是说让你去测试它，而是检查已有系统，然后确定你的产品会以一个什么样的形式组织，会怎样设计整个框架，彼此会有哪些联系。通过检查熟悉后，你进可以确定你将要测试的系统有哪些功能，以此来正确估算你测试需要花费的时间。同时，通过检查熟悉，你可以通过对比，确定你现有的关于你产品的信息是否对测试是足够的，如果缺少，怎么去获取，以次来确定你测试需要的资源。通过检查，你也可以确定产品质量相关的内容，确定哪些质量问题是测试的重点，哪些是bug高发区，以次来确定测试重点。检查还有利于你组织测试用例，针对系统的特点设计有效的，高覆盖率的测试用例

以上就是关于理解测试需求的一些讨论和方法，欢迎朋友们提出你们的看法和意见。

说明：本文是关于测试基础知识的一些拓展。

摘要：很多时候，我们没有完全理解需求说明书就匆忙开始了我们的测试工作，本文主要说明了如果对需求说明书不理解会导致的严重后果，以及如何有效的理解需求说明书。

 

现在你开始进入一个项目进行你的测试工作了，你参加了需求评审会议，知道了些项目的背景，得到了项目的需求说明书，从需求说明书开始你的测试工作。

或许你觉得你手上的需求说明书很差，你不想去看，你觉得你可以在系统真正出来以后，根据系统，你可以很容易的设计出测试用例，或者，你可以不用测试用例就能进行测试。如果你这么想，那么你肯定不会去设法理解需求说明书，也不会对你将要测试的需求说明书描述的系统有完整的，清晰的认识，或许你依旧可以根据模板做出测试计划，设计出测试用例，你的这些测试准备工作，可能也会通过评审，因为公司的评审并不严格或者其他的原因。好了，你这样做了，你知道这样做会有什么后果吗？

你也知道的，需求说明书是产生bug的主要原因，很多缺陷都可以追踪到需求说明书的不完整，不正确，变动多上面，那么你对需求说明书没有认真的检查，你肯定会遗漏很多的缺陷，你大概也知道如果在项目后期修改bug的费用比修改在需求说明书中的缺陷要高多少吧。

你没有理解需求说明书，对程序很多功能都没有详细的考虑，你能保证你看着系统就可以完全理解整个系统，大概不能吧，很多细节的内容，你还是需要对照需求说明书去理解，可是，你在检查需求说明书的时候都不去认真看它，现在，要测试了，测试任务可能很紧，你还会去看它吗，你看它的时候能够理解吗？肯定不能，那么你就要有人来明确告诉你系统是怎么回事。

好了，这个时候，你可能会求助产品经理，可能会求助项目经理，可能会求助程序员，但是，你要知道，如果你有很多的问题去问，你没有这么多时间，他们也没有这么多时间，你的问题能全部解决么？就算你的问题不多，可是你在这个时候去问他们关于需求的问题，你觉得他们会乐意解答吗？他们会认为，你没有做好你本来应该做好的事情，他们会对你敷衍，因为这不是他们这个是要的工作，他们这个时候的工作是编码或者是解决bug或者是其他，但绝对不是回答你关于需求的问题。

你的问题很大程度上不会被完整，准确的解决，可是你还是要测试，因为这是你的工作。因为你对整个系统的理解存在问题，你肯定会遗漏很多的测试点，你也会报告很多的无效bug，你还会无法判断你测试到的现象是系统特色还是bug，你知道这个时候你会有哪些问题么？

你遗漏了bug，会导致系统的不稳定，或许严重的，会导致整个系统的崩溃，你的工作没有做好，领导会找你的责任。你报告了许多无效的bug，开发人员对你的能力开始怀疑，对你的信任开始降低，你报告的bug他们不再关注，你会有很多未解决的bug等着你去跟踪。你无法判断你测试到的现象是系统特色还是bug同样会导致前面的两个问题。现在，你知道你的问题的严重性了吧。

以上所有的问题，仅仅是你在本来应该做事情的时候想当然的认为在以后可以解决而没有做，测试没有任何的假设，该你做什么你就应该做什么。

那么，如果你对需求说明书不了解，或者说明书不够详细，或者你认为需求说明书很差，你该做什么。

首先，不要假设说明书上的所有内容都是正确的，也不要等到程序发布以后再根据程序去理解需求说明书，然后去设计测试。你手上有需求说明书，你就要努力的去理解他，因为这是你这个时候的工作，如果你在理解需求说明书的时候有困难，你可以寻找相关的人来帮助你，可能是需求说明书的作者，也可能是项目经理，或者是相关的程序员，只要你在这个时候寻求帮助，他们肯定会乐意帮助你的。在这个时候，你就要首先弄明白需求说明书的内容，因为，你后面的测试工作的展开，比如测试需求，测试用例，测试计划都是依照需求说明书的，如果你不理解测试用例，你就不能准确估算你的测试工作量，你也不能详细的设计你的测试策略，还有你的测试用例。

其次，努力获得和你要测试的项目相似的已经成型的系统，然后认真去研究它。（待续）

软件质量介绍

   软件质量定义：

      软件产品满足规定的和隐含的需求的能力

      与计算机软件优秀程度的特性相关的内容

      软件产品满足给定需求的性质和特性

软件质量特性：

     功能性   可靠性   易用性   效率  易维护性  可移植性

软件缺陷和错误的分类：（待完善）

缺陷类 型编号	缺陷类型	描述
10	F-功能	如逻辑,指针,循环,递归,功能等缺陷
20	G-语法	拼写、标点符号、打字
30	A-赋值	如声明、重复命名，作用域
40	I-接口	与其他组件、模块或设备驱动程序、调用参数、控制块或参数列表相互影响的缺陷
50	B-联编打包	由于配置库、变更管理或版本控制引起的错误
60	D-文档	需求、设计类文档
70	U-用户接口	人机交互特性：屏幕格式，确认用户输入，功能有效性
80	P-性能	不满足系统可测量的属性值，如：执行时间，事务处理速率等
90	N-标准	不符合各种标准的要求，如编码标准、设计符号等
100	E-环境	设计、编译、其他支持系统问题

错误和缺陷产生的原因：（待完善）

隐藏错误的估计方法：

撒播模型：N=（n / m）*M

回归模型：

 配置管理

   配置项：配置管理的基本,包括软件过程中产生的程序，描述计算机程序的文档和数据

   基  线：可以提供给其他软件项目人员查看的一组相关的SCI的集合，基线的建立标志着一组开发活动完成

   版本管理：目的是为软件项目中的文档更新留下记录，供相关人员查看。通过为每一次更新标记一个版本来达到这个目的

   基线管理

       产品基线：产品达到一定功能后，与之相应版本的软件产品、用户手册以及提供给用户和其他开发组织的文件的一种集合。

       开发基线：完成某个开发过程以后，将改过程定义为一个基线。开发基线的内容即开发活动所完成的工作产品

系统测试和确认测试的区别：以前总是认为是在系统测试的时候进行确认测试，通过看文档了解到，确认测试主要是测试软件的功能是否正确，系统测试是在特定系统环境下进行软件测试，是系统的确认测试的一部分。也就是说，确认测试主要是测试软件的功能及其他特性是否正确，即是否满足需求规格。而系统测试是将通过确认测试的软件置于特定的运行环境下进行软件功能和性能的测试，是系统的确认测试的一部分。

软件质量定义：

    软件产品满足规定的和隐含的需求的能力

    与计算机软件优秀程度的特性相关的内容

    软件产品满足给定需求的性质和特性

正交试验设计法

      从大量的实验点中挑选出适量的、有代表性的点，应用依据伽罗瓦理论导出的“正交表”，合理地安排实验的一种科学的实验设计方法。

     试验指标：判断试验结果优劣的标准

     因    子： 有可能影响到试验条件的指标

而影响实验因子的，叫做因子的水平（或状态）。

测试方法

功能测试：

针对需求规格的功能测试属于高级测试，通常采用黑盒测试方法，包括即等价类划分，边界值分析，因果图分析、错误猜测等。

针对设计文档的功能测试属于低级测试，通常采用白盒测试方法，包括语句覆盖、条件/判定覆盖、路径覆盖等。

  WEB测试

   表示层测试：

l                内容测试。包括整体审美、字体、色彩、拼写、内容准确性和默认值

l          Web站点结构。包括无效的链接或图形。

l          用户环境。包括web浏览器版本和操作系统配置

业务层测试：

Ø         性能测试。测试的目的在于检查应用系统是否满足书面的性能规格说明（通常定义为响应时间和吞吐率）

Ø         数据有效性测试。测试的目的在于发现从客户那里采集到的数据的错误。

Ø         事务测试。测试的目的在于发现事务处理过程中的错误，事务测试必须有据可依，即具备书面文档详细定义事务的构成。

数据层测试：

查看(910) 评论(0) 收藏 分享 管理

1．         决定BUG严重性的时候，可以根据该被测对象在整个系统中充当的角色，实现的功能来判定如果该对象出现错误会对整个系统产生什么样的影响，对产生的影响打分，可以设定1－10分，每两分为一个层次可以依照如下划分：

ü          Blocker：阻碍开发和/或测试工作

ü          Critical：逻辑错误，丢失数据，内存溢出

ü          Major： 主要的功能缺陷？

ü          Minor： 次要的功能缺陷？

ü          Trivial：产品外观上的问题或一些不影响使用的小毛病，如菜单或对话框中的文字拼写或字体问题等等，页面交互性问题

2．         决定BUG优先级的时候，可以先假设不修复该Bug，出现的这些问题会产生哪些影响，然后判定这些影响的严重性来判定bug的优先性。

3．         容易产生Bug的情况

ü          虽然在开发过程中，软件需求通常都会发生改动，但是，如果某一部分的软件需求频繁发生变动，那么就会导致和这部分软件需求相关的编码和设计频繁变动，那么在测试中，这部分编码设计实现的产品出现bug的可能性就很大。

ü          如果根据测试需求设计的某个测试用例描述的业务非常复杂，并且和其他的业务之间也有非常复杂的关系，那么可以判定设计和编码实现也会非常复杂，那么该部分出现bug的可能性也非常大

ü          如果在开发的过程中，大量使用了第三方的组件，或者从别的软件中移植了大量的代码，那么和这些第三方的组件和代码相关部分出现bug的可能性就很大，尤其是这些第三方组件使用者很少而且没有通过严格的认证的情况下。

4．         于测试的工作用时间的估算，可以参照公司过去的经验，根据公司以前的测试计划或测试报告，查看和目前从事的测试对象相仿的产品，查看测试该产品的参与者有多少，工作用时多少，单位效率如何，根据这些可以大致的估算出工作用时来，但是，并不是说估计的工作用时就能保证完全正确，因为在实际的工作当中会出现很多意外的情况，而且，工作用时的估计也需要有丰富的工作经验，所以，如果工作用时估计不精确，也是可以接受的。

5．         功能性测试需求表述的是对于系统中描述的功能性行为有哪些地方需要测试，这部分内容可以在项目早期就通过对软件需求规约和用例的分析获得，一般来说，一个明确要求的功能性特性可以生成一条测试需求，用例中基本流或基本流通某些备选流的组合也可以生成一条测试需求，另外，如果用例之间有相关性和依赖性，这多个用例间的不同联系也可以分别生成一条测试需求。

6．         如何根据频频变更的软件需求确定测试需求

        采用的是软件需求的版本化管理，指在一个软件产品进行新版本的迭代时，尽早确定这个版本中所包含的需求。 就自己某前测试的项目ODD，来说，这个项目没有软件需求，因为这个项目是对现有产品的升级，是基于现有产品进行开发的，因为Mymiles方面的新要求，或者房源查询数据接口的变化，这个项目的软件需求发生了很大的变动，在已经测试的B9，B10版本中有包含的某些功能可能在新版本中会取消，在新版本中又会添加新的功能。在这种情况下，作为这个项目的测试人员，就应该尽早确定这次新版本中包含的需求，然后和上次测试的版本进行比较，哪些内容是新增的，哪些内容是被调整过的，哪些内容是在新版本中取消的等等，当确定了这些内容以后，也就获得了新的软件需求，然后再确定测试需求。

7．         测试需求的整理

        测试需求的整理是明确现在要“测什么”，软件需求确定以后，根据软件需求规约，软件需求用例，从文档对软件特性和软件业务流程的描述中获得软件所设涉及的业务的一个基本认识，比如用户的实际业务是怎么进行的？实现这些业务需要什么约束条件，这些约束条件对实现业务的影响是什么？多个业务之间是否存在相互的关系，如果存在相互的关系，这些相互关系对处于这些关系中的业务又什么影响等。通过这些业务的分析，可以获得最初的一些测试需求。等开发部门的架构设计文档和详细设计文档出来以后，可以根据这些文档，对已有的测试需求进行增补，在执行测试的时候，如果发现在测试需求中没有包含的内容，则对这部分内容，也要整理添加到测试需求当中。

8．         测试需求的可测试性

测试需求的可测试性指的是，对于一条软件需求或者一个需要实现的特性，必须存在一个可以明确预知的结果，并且可以通过设计一个可以重复的过程来对这个明确的结果进行验证，即，要保证所有的需要实现的需求在最终实现后，都可以用某中方法来明确的判断是否符合需求文档中的要求。

9．         测试用例设计的有效功能

有效功能是指在被测应用所设计的实际业务中，当用户在原始状态下进行工作时，整个业务流程对用户来说具有实际意义的功能，当把这个功能单独从计算机软件还原到用户的原始手工状态时，它的完成可以作为用户实际业务的一个阶段性结束的标志，而不是一旦从这个业务流程中独立出来就没有了意义。而在该业务完成以后，可以为其他用户或业务提供所需要的信息。比如，财务软件中，用户填写一张会计凭证的是，它利用软件的功能，从备选会计科目中选择一个会计科目，这个功能就不是一个有效功能，因为在原始状态下，这个功能对用户来说没有什么实际的意义。但是，添加会计凭证这个功能就是一个有效功能。

对于相互之间存在数据或状态依赖的有效功能，要注意将他们剥离到不同的测试用例中。

10．  试用例常用设计方法

Ø         填写操作列表：将在软件上操作的步骤记录下来，包括所有被操作的项目和相应的值，这种方法的又是在于可以清晰的表达对于一条确定的测试用例的测试思路。比如可以利用操作步骤设计测试用例，测试常见的用户登录框用户正常登录功能、

Ø         填写测试数据矩阵：将被操作项作为矩阵的一个字段，而矩阵中的一条条记录，则是这些字段的值，利用这个方法，可以存放测试数据，特别是操作步骤相同，知识赋予属性的值不同的情况，比如可以利用测试数据矩阵，编写测试用例，将用户不能输入错误用户名和密码的情况以数据记录的形式存放在测试矩阵中。

11．  测试用例的设计并不是简单的把在应用程序上具体的操作的繁琐的步骤记录下来，因为通过这样的方式设计的测试用例，维护起来是十分庞大和复杂的，当需求中软件的某个特性发生变动时，为这个特性每个可能的值设计的测试用例都要进行修改，可以想象，修改这样的测试用例是多么的困难。所以，在测试用例设计的时候，要关注测试思想，而不是关注测试步骤，将测试者应该遵循的操作过程单独描述，然后，将针对这个测试用例的输入数据和输出数据单独写出来，这样，就不用再对原本多个用例中重复出现的操作步骤过程再次描述，可以把更多的精力放在测试数据的设计和准备上。当软件需求发生变更时，只需要对操作过程维护一次，再添加或调整测试数据就可以了

12．  准备有效的测试数据

        准备有效的测试数据，要从这个业务流程中最下游的业务开始考虑，找到实现它的所有输出所需要的所有输入，包括那些它所不能接受或无法处理的输入。当然，这些输入都来自于它的之间的上游业务。继续这种方法向上迭代，找出实现它的直接上游业务的所有输出所需要的所有输入。直至到达整个业务流程的最上游，也就是启动整个业务流程的第一个业务。

        对于测试用例的执行顺序的安排，同样是充分利用了多个业务之间的相关性和依赖性，再执行测试用例时，尽可能的将存在相互对照意义或者直接联系的内容安排再一个顺序中执行，并尽量在执行一个测试用例的时候检查更多的内容。

13．    描述bug主题时，应当根据实际情况，简要的描述出自己的操作和希望被重视的现象，不应该包含自己对异常表现出现的原因的推测和猜想。

14．  不能假设开发人员对他们开发的程序都十分熟悉，在提交bug的是，一定要说明白是哪个模块的哪个功能，出现了哪种类型的错误，并且，如果需要，应该把需求种关于该部分的描述写出来。