软件测试学习体会Vol29

1、软件测试学习体会Vol 29如何有效减少测试用例数目在测试过程中，测试人员经常需要将测试对象的各种输入参数进行组合之后进行测试。有时候，将各种输入参数进行组合，得到的测试用例数目将是非常庞大的。由于测试时间和成本的限制，无法对测试对象输入值的所有组合进行测试。下面是某个网站测试的要求：-案例描述：开始-某网站需要支持不同的浏览器：IE5.0、IE5.5、IE6.0、Netscape6.0、Netscape6.1、Netscape7.0、Mozilla1.1和Opera7；不同的插件：RealPlayer、MediaPlayer或者没有任何插件None；不同的客户端操作系统：Windows95、

2、Windows98、WindowsME、WindowsNT、Windows2000和WindowsXP；不同的Web服务器软件：IIS、Apache和WebLogic；不同的服务器端操作系统：WindowsNT、Windows2000和Linux。这种情况下，需要针对不同的组合进行测试：8种浏览器3种插件6种客户端操作系统3种Web服务器软件3种服务器端操作系统如果考虑所有参数不同取值的组合，那么需要设计和执行的测试用例的数目是1296(8 x3 x6 x3 x3=1296)。-案例描述：结束-在软件测试过程中，这种类型的组合是非常普遍的。每种情形都可能有庞大的组合需要进行测试，假如不对它们进

3、行测试，可能会存在较大的风险；而如果对所有组合进行测试，测试时间和资源又不允许。测试人员在面对这种情况的时候，可以采用以下几种常用的策略：尝试测试所有输入的组合，延期项目，导致的后果可能是失去产品的市场。选择一些容易设计和执行的测试用例，而忽略其是否能够提供产品质量的信息。罗列所有的组合，并随机选择其中的子集进行测试。采取特殊的测试技术，选择能发现大部分缺陷的子集进行测试。如果采用最后一个策略，那么使用结对测试技术是一个很好的选择。采用结对测试的技术，测试并不针对输入值的所有组合进行测试，而只是针对所有输入值的两两组合。结对测试技术可以显著地减少测试用例的数目，同时保证较高的测试质量。下面是应

4、用结对测试技术减少测试用例数目的例子：假如软件系统有四个不同的输入参数，每个参数有3个不同的输入值，得到的完全组合数目是34即81。假如采用结对测试的技术，只需要9个测试用例即可覆盖所有参数的两两组合。假如软件系统有13个不同的输入参数，每个参数有3个不同的输入值，得到的完全组合数目是313即1594323。假如采用结对测试的技术，只需要15个测试用例即可覆盖所有参数的两两组合。假如软件系统有20个不同的输入参数，每个参数有10个不同的输入值，得到的完全组合数目是1020。假如采用结对测试的技术，只需要180个测试用例即可覆盖所有参数的两两组合。结对测试技术能够发现所有的单模式失效(Singl

5、e-mode Fault)和双模式失效(Double-mode Fault)。但是，结对测试并不一定适合于发现测试对象中的多模式失效(Multimode Fault)。单模式失效：失效是由单个参数引起的，只要针对所有独立参数进行测试，就能够发现该失效。双模式缺陷：失效是由两个参数共同引起的，必须针对所有参数的两两组合进行测试，才能够确保发现此类缺陷。多模式缺陷：失效是由三个或三个以上参数共同引起的，采用结对测试技术也可能发现多模式缺陷，但是不能保证测试的充分性。下面的几个数据可以说明结对测试技术的有效性：根据AT&T在对其基于局域网的邮件系统进行的测试中，应用结对测试技术得到的1000条测试用

6、例比其原有的1500条测试用例多发现了20%的缺陷，而测试工作量却减少了50%。National Institute of Standards and Technology在一项对医疗设备测试所进行的15年追踪中发现，有98%的软件缺陷可以通过结对测试技术发现。根据对Mozilla网页浏览器的缺陷分析显示，76%的缺陷可以通过结对测试技术发现。具体的结对测试，可以通过不同的测试技术来得到，包括正交矩阵(Orthogonal Arrays)的方法、James Bach提供的Allpairs方法，也可以通过分类树方法。表1得到的测试用例是通过Allpairs方法实现的，详细的内容以及其他测试技术的

7、实现方法，可以参考软件测试设计原著。图1使用Allpairs得到的测试数据假如测试数据列表中的某个参数的取值以开头，那么说明该参数取值已经有两两组合了。以开头的参数取值，可以用该参数的任何其他取值来代替，而不会影响其两两组合的覆盖率。因此，可以将以开头的参数取值，用更关键的或者经常使用的参数值来代替。同时，使用Allpairs得到的测试数据中，还罗列了所有的两两组合，并且统计了每个两两组合出现的次数，以及每个测试用例所包含的两两组合数。从上面的结果可以看到：通过采用合适的测试技术，测试用例数目原来需要1296个，而目前只需要48个进行覆盖，测试用例数目减少了96%。前面已经提到了，结对测试可以

8、发现所有的单失效模式和双失效模式的缺陷，而实践过程中，大部分的失效是单失效模式和双失效模式，多失效模式占的比例很少。因此，通过采用合适的结对测试，可以大大降低测试用例数目，减少测试工作量，同时可以实现较好的测试覆盖率，保证测试质量。=分割线=分割线=测试过程关键点简析1、如何进行选型测试有单位提出，如何进行选型测试，尤其是对自己不熟悉的领域。我单位专家作出如下解答：选型测试是我中心最具有代表性的测试服务，也是最难的一种。因为在测试的时候所有软件要采用相同的标准和规范，还要评出名次。进行选型测试一定要是自己熟悉的领域，这是基本条件。对于自己不熟悉的领域根本无法开展选型测试。因为选型测试要知道该领

9、域的规则与标准，这是测试的基础。其中标准可以采用行标、国标、企标。在定分的时候也要非常慎重，可以先制定标准，然后制定权重。2、自动化测试有软件厂家提问，自动化测试真的有用吗?而且他一般在软件完成后才能开展，可能导致工期滞后；对于性能测试，怎么采用自动化测试?而且在实际的应用中，界面如果修改，原来的代码就不能用了，这些问题如何解决?我单位专家作出如下解答：自动化测试有其应用的条件与限制。一般大家都觉自动化测试脚本的开发是自动化测试的主要成本。但通过分析发现，软件需求的改变导致测试脚本、操作的改变，所以要重新进行自动化脚本的修改，这实际上是回归测试的时候需要修改自动化测试脚本，是测试脚本维护的工作

10、。所以，我们发现自动化测试的成本是比较高的，需要回归测试超过一定数量才能产生效率，而且需要每次回归测试的不同版本软件变动不大。自动化测试对与测试工程师的要求也比较高。也就是说如果时间够、人员素质够高、回归测试超过一定次数才可以采用自动化测试。自动化测试的复用率较低，开发成本高。如果流程复杂，采用自动化测试就是自讨苦吃。如果非要采用自动化测试，建议先把复杂流程切分成小的模块。但是在这个过程中往往又出现接口问题，等于人为的增加测试困难。总之，自动化测试有其应用场合，而且如果是软件项目而不是软件产品，就不要采用自动化测试了。但是自动化测试领域也不是没有研究的需要，可以先研究自动化测试的框架。我单位另

11、一专家作出如下解答：在进行性能测试的过程中，可以先规划功能点；其次要对系统有一个很好的了解，还要收集如用户访问习惯、主要性能点等方面的问题；最后要进行故障定位，如果做到精准定位，光用loadrunner是不够的。3、白盒测试有代表问，需不需要成立白盒测试组，专门进行白盒测试。我单位专家作出如下解答：白盒测试主要应用于军工、航天、嵌入式开发。白盒测试分为静态测试、动态测试。对于白盒测试，其自动化水平已经较高，很多测试内容可以使用工具，只有接口测试需要人工测试。从原则上讲需要成立白盒测试组，但是对人的要求高，成本也高，需要自己的公司管理层权衡利弊进行决策。4、功能测试人员与代码有厂家代表问功能测试

12、人员是否需要了解软件代码方面的知识。我单位专家作出如下解答：1)测试和开发进行融合是必然的，像IBM这样的大厂商，在购买其软件时也要提供服务质量保证工具，也就是说测试工具已经开始绑定软件产品了；其次可信的开发必然导致测试的消失。2)我们做功能测试的方法与步骤也来越来越先进。从原来不做案例到现在进行测试计划、测试案例的编写等；尤其是了解被测软件的代码，肯定对测试有作用。3)功能测试中对于流程的覆盖可以在白盒测试中完成。所以如果了解软件代码，那么在白盒测试中进行一些测试就可以解决功能测试的许多难点。5、性能测试需求的收集有同学问性能测试的需求如何收集?我单位专家作出如下解答：性能测试需求的收集是性

13、能测试很重要的一步，该工作包括以下几个部分的内容：1)需求文档的收集。性能测试需求的很大一部分来源于各种开发文档，包括用户需求说明书、用户手册，甚至项目合同。2)对系统的了解。进行性能测试还应该知道被测项目的系统框架，所应用的技术，客户端与服务器端的通信模式等方面的内容。这些内容对性能测试所采取的策略有所帮助。3)需要调研被测系统在正式上线后的基本使用群体的数量级。4)测试点的收集。首先要大致了解用户能够接受的响应时间；其次要了解用户的习惯；在测试之前还要根据之前的调研结果，估计并准备基础数据。性能测试强调测试过程的两头重要性，即：案例分析与结果分析。案例分析就是上面的内容；结果分析就是对性能

14、数据的分析以及对性能故障的排查。6、第三方测试结果时效有厂商代表询问，作为第三方测试机构，测试完成后并提交报告后，测试结果一直有效吗?稳定运行一段时间后，功能性能没有大的质量问题?我单位专家作出如下解答：1)对于一次测试结果，只是对软件系统在当时的测试环境下的状态有效，是一个时间段的结果。2)功能、性能如果只进行一次测试，不能足以说明产品质量。一个产品从生产到运行，至少要进行半年、3至4轮的测试，才能保证上线后的质量。所以我们强调持续的、及早进行测试。3)在测试的时候要尽量模拟真实环境或者在真实情况下进行，这样才比较有效。很多测试是在模拟环境下进行的测试，有可能在上线后由于一些配置的改变而产生

15、很大的改变。7、如何测试软件一个时间段的稳定性有厂商代表提出，合同中要求软件在试用一个月内稳定运行，这种情况如何测试。我单位专家作出如下解答：1)疲劳测试测试软件一天24小时在要求的数据流量下持续的状态，这个测试是可以满足上面的要求的，机器的强度远远大于人。该测试一般使用LR。2)一个月稳定性的测试是可以换算成短时间内的疲劳测试的，不需要真进行一个月测试，可以遵照疲劳强度的模型换算要测的时间与强度，而且测试结果是可信的。8、测试的绩效考核有厂商代表问，如何做测试绩效的评估与考核。我单位专家作出如下解答：这是一个综合的问题。1)可以通过bug缺陷数的比率，而不是单纯的bug数。这是一个定量的指标

16、。2)可以通过有效工时进行统计，这是一个定性的指标。3)可以通过个人技能、客户满意度、客户对项目评价等进行考核，这也是定性的指标4)可以通过测试的覆盖率、bug探测率、bug遗留率等进行衡量5)可以通过测试设计阶段(案例)数量与其有效性、实施阶段发现问题数等进行衡量通过这些定性、定量的综合指标，再根据每个单位的不同情况，可以完成对测试工程师的考核。对于性能测试工程是的绩效，可以通过角色来进行考核。下面是分类。1)性能测试角色，其中有区分：设计人员、执行人员2)性能测试与故障诊断人员在进行考核时，可以通过角色与工作量相结合进行。9、异常测试的把握有厂商代表提问如何进行异常测试，有什么依据，要考虑

17、哪些方面。我单位专家作出如下解答：异常测试是案例的重要来源，他可以通过以下几方面收集：1)业务异常。该类异常对于不同软件的可继承性不是很强。2)标准异常。该类异常对于不同软件有一定可继承性。3)经验异常。该类异常对于不同软件的可继承性很强。4)操作异常。该类异常对于不同软件的可继承性很强。在实施的时候，可以设计异常用例库，积累经验，业务操作上分行业、分领域，纯操作角度上是可以复用的。其中嵌入式的检测和诊断难度是最大的，这需要专业的知识，需要开发人员才能进行相关工作。以上问题都是软件测试工作中极具代表性的难点与疑问，也许答案远不止上面的文字。但是通过这次研讨会的讨论，可以说为这些问题的解决打开了

18、一个良好的开端。希望通过这些意见和建议，能够激发有关测试工作的改进与发展热潮，并带动相关测试技术与理论的不断创新。作为国内权威的第三方测试机构，这是我们的希望，这也将是每个测试从业者的梦想。=分割线=分割线=功能测试自动化的投入和产出测试自动化，对于系统性能测试、负载测试等效果是明显的，而且我们也不得不为之。我们知道，没有测试工具进行负载模拟，要通过手工测试完成系统测试任务，几乎是不可能的。但在功能测试中，情况就大不一样了。手工测试在功能测试中的优势还是比较大的，工具本身并没有想象力和灵活性，而人对界面美观性、逻辑合理性，容易作出判断。所以功能测试自动化主要的应用在回归测试中，而且产品的界面(

19、UI)和功能变化较大，自动化的脚本(Script)维护成本较大，投入和产出往往变成我们最关心的问题，在功能测试中实现测试自动化究竟是否合算?举个例子：假如一个功能测试用例，手工运行需要10分钟，而为此测试用例开发脚本需要4个小时，即240分钟，那么意味着这个测试脚本要被运行24次收回成本，如果在加上测试脚本的维护工作量(10%)，需要重复运行40-50次，才收回成本。如果在产品的一个版本中要进行2-3轮测试(一般是需要的)，这个产品需要发布15-20个版本才收回成本。所以业界常说，产品发布7个版本才收回成本。如何降低成本、可以相对增加产出或者说更快地收回成本?关键是提高脚本开发速度、提高脚本运

20、行的稳定性和降低维护脚本的工作量，主要方法有：-选择较好的、更适合的测试工具-选择适宜自动化的模块-尽量将脚本写成数据驱动的脚本，这一点很重要。-多录制脚本，然后结构化脚本。我们知道，不是所有的模块都可以变为数据驱动方式，这时就要抽象出脚本的结构，进行有效的组合，包括分层，形成有效的层次性。-测试和脚本开发合二为一，效率更明显下表也部分说明了这个问题。也希望得到您更好的想法。结构成本收益净收益No Automation000 Recording and Playback 8.3112.7 Data-drivenstructure using data pools 8.4189.6 Framew

21、ork structure 9.8155.2 Framework/data-driven(hybrid)structure focusingon views of the application and using data pools 11.6197.4=分割线=分割线=敏捷测试和传统测试的区别敏捷宣言是：我们正通过实践和帮助他人来揭示开发软件的更好方法。经由这项工作，我们估量：个体和交互胜于过程和工具可工作的软件胜于面面俱到的文档客户协作胜于合同谈判响应需求胜于遵循计划即，尽管右栏条目有其价值，但我们更看重左栏条目。敏捷开发也有了很多敏捷的方法：比如：Crystal，XP，SCRUM.对传

22、统的开发模式和测试模式提出了巨大的挑战。传统的测试模式基于如下的一些理念：1.测试是质量的最后保护者2.严格的变更管理3.预先的计划和细节的准备4.重量级文档5.严格的各阶段测试入口和出口标准6.回归测试阶段重量级的自动化测试7.企图流程改善和执行8.测试团队和开发团队是可分割的那么对照传统的测试模型，敏捷测试颠覆了以上观念：1.测试是质量的最后保护者-开发和测试人员是紧密合作，大家都有责任对软件负责2.严格的变更管理-变更是可接受的，拥抱变更3.预先的计划和细节的准备-计划随时进展时常调整4.重量级文档-只需要绝对必要的文档5.严格的各阶段测试入口和出口标准-各迭代之间已经没有明显的入口和出

23、口标准6.回归测试阶段重量级的自动化测试-所有阶段都需要自动测试，每个人都需要做，是项目集成的一部分7.企图流程改善和执行-流程不再需要严格执行8.测试团队和开发团队是可分割的-团队合作是无缝隙合作=分割线=分割线=状态转换测试的灵魂：N-Switch根据状态转换树设计测试用例，首先需要将状态转换图转化为状态转换树，将可能具有无限多状态循环的状态转换图转化为不含循环的相应数目状态的状态转换树。在转换过程中，需要覆盖所有的状态，并且需要包含状态转换图中的所有转换。根据测试强度的不同，除了0-Switch之外，有时候还需要满足N-Switch的要求。N-Switch是由TSUN S.CHOW在19

24、78年提出的，他将N-Switch定义为程序图中长度为n+1的连续的边或弧线(通常在状态图中表示循环)的序列。所以单独的一条边(或者转换)就是一个0-Switch，两条连续的边的序列就是1-Switch。下面以图1所示的状态机分别说明0-Switch和1-Switch的概念和区别。图1所示的状态机示例，其中圆圈表示状态，带箭头的边表示转换，同时为每个转换定义了一个英文字母的标识。图1状态机示例图1)0-Switch针对0-Switch，状态转换图转化为状态转换树的基本规则或者步骤如下：步骤1：将初始状态或者开始状态作为状态转换树的根，根在整个状态转换树中的层次是1。步骤2：假设当前生成状态转换

25、树的层次为K，那么从左到右检查所有层次为K上的节点；将该节点对应的所有下一个可能的状态作为它的子节点，状态之间的转换作为两个状态的边。步骤3：重复步骤2，直到一个位于层次K上的节点出现在层次J上，且J小于等于K，那么这个节点就成为最终的叶节点，而无需继续生成其子节点；或者节点的状态是结束状态，也不需要针对该节点继续进行状态转换。根据0-Switch的定义，该状态机对应的所有的0-Switch为：a、b、c、d、e、f。同时根据上面0-Switch状态转换树生成规则，生成的状态图如图2所示。2)N-Switch再来看一下1-Switch。根据1-Switch的定义，该状态机对应的所有1-Swit

26、ch为：ab、ac、bb、bc、cd、ce、dd、de、ea、ef、fd、fe。1-Switch状态转换树的生成规则是在0-Switch状态转换树基础上，再增加一个层次，即针对0-Switch状态转换树的所有叶节点，把每个叶节点可能的下一个状态作为该节点的子节点。这里需要注意的是，只需要增加一个层次既可。生成后的1-Switch的状态转换图如图3所示。图3 1-Switch状态转换图示例假如1-Switch还是无法满足测试的强度，那么，可以根据上面的思路，继续增加一个层次，使之达到2-Switch。但是，需要注意的是，测试强度的增加，是以指数形式增加测试用例为代价的。这两者之间的平衡，是测试人

27、员采用什么样的测试强度的时候必须考虑的。=分割线=分割线=软件测试过程分解拿到一个软件进行测试，需要一系列的动作、计划、文档，来完成测试任务。当然测试不是一个很简单的过程，不是说随便测测就可以满足用户或者开发团队的需要。测试有一定的过程，需要采用各种测试技术、方法。下面我们就说明这个过程。测试需求阶段：我们首先要对软件有个大体的了解：这个软件是什么行业的、涉及什么领域、采用什么技术、规模有多大、实现了什么功能等。这些问题可以通过口头的询问，也可以通过详细读取项目的用户需求说明书与用户手册来得到。进行了这些大体的了解，我们需要根据实际的情况、限制制定测试的范围。这里我们可以先按照系统功能实现的各

28、种角度进行业务功能模块风险等级的划分。评判标准如下：1.功能类型A高级-数据计算/验证；B中级-数据修改；C低级-数据显示2.业务影响A高级-合法性；B中级-错误信息；C低级-无3.使用频度A高级-非常频繁/大量；B中级-经常；C低级-极少4.受影响客户的数量A高级-大量/重要；B中级-组/群；C低级-很少总之，对于核心流程、业务功能点，它的风险等级总是比较高的，这就决定在进行测试的时候他是优先级高的。然后我们就可以通过客观原因的限制最终指定我们的测试的范围。这些客观原因包括：时间、资源、人员限制、成本等。当然，还有些特殊的需求会影响我们的测试范围，比如：用户或开发组要求着重测试一个不是很重要

29、的模块等。但是一般情况下，我们都是优先所有资源对优先级高的模块进行测试，然后再测试优先级别低的模块。当然测试的充分程度也是我们需要考虑的问题，我们不可能进行完全测试，但是我们究竟要测的有多细使我们事先应该有考虑的，即使不写在文档上，也要贯彻到测试组长与测试工程师的头脑中。在划定测试的范围后，我们就需要选择测试的测试的实现方法，我们是在真实系统测试还是搭建测试环境?我们要搭建环境是需要仿真呢还是只要程序能运行不影响测试就行了。这也跟实际的情况有关。当然能够在真实环境进行测试是最好的了，比较真实。但是有时候往往不行，比如银行系统等。所以需要搭建环境的情况会很多。一般主要测试软件的可用性，环境不用很

30、苛求。但是如果需要硬件很多或者测试其性能、可靠性等，就需要比较接近真实的环境了。然后我们就可以根据用户手册形成我们的需求文档了。测试需求和测试案例很像，只是颗粒度粗细的问题，而且测试需求没有数据，测试案例就要提供数据了。形成基本稳定的需求文档后，测试介入需求评审，以便了解需求的相关内容以及测试工作的可行性分析(软件可测试性)。项目经理制定项目计划，测试部门测试经理/测试团队负责人制定测试计划，项目组测试人员阅读相关测试需求文档，如果存在疑问或者发现需求缺陷及时与需求人员沟通，如果是需求缺陷，可以将相关问题可以记录到bug管理工具以便进行跟踪。设计阶段：在设计阶段，研发部门进行软件的概要设计、详

31、细设计以及必要的单元测试工作；测试部门进行功能、性能测试用例的设计(用例不仅仅包括用例本身，还包括测试数据)，测试所需软、硬件资源申请、准备。但是在实际上测试案例的编写是这一阶段的主要内容。首先我们要通过各种测试方法来使我们的案例的编写更加可行与有效。对于庞大的系统，我们往往无从入手。在这种情况下我们要先找到突破口。比如：象erp这种软件，流程性比较强，显然一个一个模块测试是不明智的，他的模块之间需要有数据流的流动才能运转，这是可以采用场景法确定数据流的大致情况。有些软件有明确的但是复杂的各种输入(原因)，他们会导出许多复杂的输出，这个时候应用因果图方法理清因、果之间的关系。但是光用这两个方法

32、显然是不够的，针对每一个输入，有无数种情况，我们要用等价类的方法把无限测试变为有限测试。当然边界值、错误测试都是很有用也必要的测试案例的补充。对于数字类型、日期类型等域的测试要格外注意。整个测试过程中应该检查错别字与提示的格式风格是否统一。对于一个软件，如果没有很明确的流程，也不需要使用因果图、场景法等方法。但是它依然需要等价类、边界值与错误输入等技术。对于这类软件我们可以分模块来进行功能的扫菜单方式组织案例的编写。在这个测试中，查询是一个比较特殊的地方。因为如果做到完全测试，那是肯定不可能的。所以我们要分析比较常用的查询条件与查询符号的组合，并问询用户或相关人员经常使用的查询条件，来进行部分

33、测试。实际上设计案例也是测试内容的一部分，通过各种方法和经验可以找到可能的测试步骤，设计流程与数据。设计案例也是整个测试最关键的部分，在进行测试案例的设计的时候，要贯彻我们在前期进行需求、设计的决定。而且这个测试案例库可以被复用，在测试过程中也可以不断进行补充。在设计案例的时候，还要注意各个模块之间的联系，比如有些软件模块中，进行了参数设置后，导致添加、修改模块界面中相应下拉菜单的内容消失。这就是一个模块的操作影响了另一个模块。当然在设计案例的时候易用性也要作为功能测试的一个重要部分，尤其是对于有些行业，如政府机关、金融等，易用性都很重要。还要根据行业的不同突出一些测试用例，如安全性、可靠性等

34、。有人提倡自由测试，就是没有测试计划、测试案例随意的测试。这种测试可以测出极少数比较随意、个性化的问题，这是写案例可能达不到的。但是只进行自由测试是不可取的，因为其没有计划性，所以无法实现测试覆盖的满意程度。进行对比发现，两个不同的测试工程师，对同一模块进行测试，一个人进行自由测试，一个人按照案例测试，同样是一天时间，前一个人发现了12个问题，后一个测出了57个问题。当然测试、测试案例的编写是需要动脑子的，也需要很多经验。有经验的测试工程师一看到界面就会敏感的感觉到这个软件那里问题会比较大，那些输入、操作可能会导致严重错误，这是一个长期积累的过程。如果有条件，用例编写完成以后，需求、研发的主要负责人、测试部门项目组相关成员组织对用例进行评审，以验证当前用例是否能够达到覆盖需求相应测试功能、性能点。测试阶段：按照测试计划，按部就班的执行测试案例，是这阶段的主要工作。但是在这个阶段还是有些事情要特别注意。比如：1.每次开发组提交新版本时，必须提交相关的报告给测试负责人