51Testing软件测试论坛

标题: 对于公共模块的修改，怎么更好的保证测试全面？（08-09-08）（获奖名单已公布） [打印本页]

作者: 默默巫 时间: 2008-9-8 10:44
标题: 对于公共模块的修改，怎么更好的保证测试全面？（08-09-08）（获奖名单已公布）
在一个大的系统中，对于公共模块的修改，测试怎么更好的保证既测试全面又不至于有太大的冗余？

请各位同行踊跃发表自己的看法和提出自己宝贵的建议。

感谢会员调皮精灵提供此精彩问题！如果你也有问题想提出来和大家一起讨论，请点击此处>>
说不定下期讨论的问题就是由你提出的哦，请快快参与吧！

非常感谢各位会员积极参与，截止至9月15日24：00分，从该贴所有评论中选出部分作出精彩评论的会员予以奖励。礼品和积分将在本周内送出。

获奖名单
奖项	获奖名单	奖励	答案链接
一等奖	poisson	当当购物卡50元	8#
二等奖	goal1860	300论坛积分	21#
三等奖	archonwang	100论坛积分	6#

作者: 杀手太冷 时间: 2008-9-8 14:19
和这个帖子是不是一样的哟 ~~ 测试过程中如何应对频繁的版本变更？（08-02-29）

作者: chengxq 时间: 2008-9-8 14:25
先占个座，看看楼下精彩回答

[ 本帖最后由 chengxq 于 2008-9-8 14:26 编辑 ]

作者: 默默巫 时间: 2008-9-8 15:46

原帖由 杀手太冷 于 2008-9-8 14:19 发表
和这个帖子是不是一样的哟 ~~ 测试过程中如何应对频繁的版本变更？（08-02-29）

谢谢提醒，题目已更改．

作者: 新手笑哈哈 时间: 2008-9-8 16:09
等待看楼下的有什么高招。

作者: archonwang 时间: 2008-9-8 16:16
倒~~，占楼位休息下。周四解答。

另，上周的问题忘了答，这次记在行事日历里了。晕~~

OK，现就该问题提供初步的解答。
=============================================================================================================

要解决公共模块的测试覆盖问题和效率问题，从根本上讲，就是要解决测试分析能力的提升问题。
测试人员在进入到测试执行阶段前，需要花费大量的时间用于整理测试需求，细化需测试的需求点，阅读相关的技术框架、分离系统接口及接口间调用关系等准备工作，这是非常重要的前提，没有这些前提，就不会有测试分析，至于后面的执行，充其量不过是Monkey Testing。问题中关于公共模块修改的测试覆盖（也就是全面性和剔除冗余）也是基于此而来的。

那么，我们如何做好诸如此类的测试分析工作呢？
1. 首先，我们应该很好的通读和理解需求。这里说的通读和理解的最低要求是：明确系统的各级对象，例如一个人事管理系统，针对的是员工、组织等对象的具体管理，而这些管理关系的依托是基于各种各样的业务流程和业务规则，从开发的语言的来理解，就是对象间的关系。至于说到对象的状态、关联属性等等都是这种关系的具体体现。
2. 在理解的基础上，理清对象及对象间关系，接口与接口间关系是对需求的进一步解读（简单点，也就是说分离这些对象及其关系时，必须深入到系统设计这一层）。这一个步骤的最终目的就是为了对公共模块进行直接关系和间接关系的整理（最好能列出一张表对应变更内容），以确保对系统结构认知的细化与可跟踪性。
3. 当你把所有的内部、外部关系理清后，剩下的工作就是筛选变更所涉及的范围。在这个过程中，需要注意的间接关系的是梳理，经验丰富的测试人员会把较多注意力集中在业务流所涉及的对象或接口上，而普通的测试工程师仅关注当前的对象/关系及其直接关联对象/关系。产生这一差异，首先也是最重要的是测试工程师对业务理解的深度，其次是梳理工作的规范性（五步法分析或七步法分析），最后才是技术能力。
4. 最后的步骤当然是设计或筛选需要的测试案例。由于是公共模块，其涉及的面较广，但是在设计案例的时候可以按如下原则考虑：公共模块在所涉及的这些功能中是输入？还是过程处理？还是输出？不同的情况需要分析不同的处理方式，一般作为输入的情况，仅需要进行单元级别的测试，作为过程处理和输出的，都必须严格遵照案例至少执行一次。
5. 补充几点以上流程处理上的说明。一是要注意经常性评审，很多情况都是测试人员自说自话，从不评审或确认。这是很危险的动作，切记必须评审；二是善用不同的测试方法来规避冗余，例如公共模块测试时要有必要的测试：单元测试必须优先进行（单元测试最好是有框架 + 测试集构成，对迭代类型开发的项目或产品有不可估量的工作量减少和质量保障作用），集成测试当然也是必不可少，其后的功能性测试及系统测试作为补充测试内容处理等等；第三，要注意选择测试案例的筛选和设计方法，很多完全雷同的测试要有规避识别的能力。这就需要测试人员具备较强的分析能力和系统认知深度。

=============================================================================================================

说了那么多，实际上这些要实现这些步骤还有一个非常重要的依赖，就是规范化的开发流程和开发文件管理模式。没有这些的支撑，要说分离公共模块，提高对变更内容的测试覆盖，降低测试冗余，提升测试效率对大多数测试工程师只能说是遥远的梦想。如果说具备了脱离其需求和设计，能自行设计符合当前系统结构与框架的公共模块关联模型，也足以说明其分析能力较之一般开发人员更胜一筹。

顺带一提，你可以尝试着从理解别人的系统设计逐步转入到系统分析与设计的领域。

[ 本帖最后由 archonwang 于 2008-9-10 12:11 编辑 ]

作者: 云里雾里 时间: 2008-9-8 16:24
标题: 请各位朋友或同学放心答题
唉，上周的每周一问少了大家的兴致，还请高手继续答题呀？怎么都写这么短？

作者: poisson 时间: 2008-9-8 23:17
我觉得这边对"公共模块的修改"定义的不是很好, QA拿到一个新版本,应该都会收到开发的release notes, 包括fix了哪些bug, 可能影响的functions,然后QA Lead决定测试策略和范围, 同时,测试策略在不同的时期还是不一样的, 所以这个问题的前提不清,势必要很长了..

1. 最简单也是最复杂的做法是automation~但是这个要基于coding的稳定性,软件在开发过程中,代码变动性大, 需求也可能随时改变(我们那个软件是一直在改需求,可能是个例外吧,,). 所以, 这边提到的公共模块的修改, 要做automation就要有前提了, 比如总的结构不变, 界面不变, and so on.

2. 不能满足做automation的条件, 并且时间比较紧的时候
在制定test schedule的时候, 测试经验丰富并了解系统的QA lead就会从release note上知道,哪块功能会有影响, 这个时候,就应该把相关的功能都测了, 并且为high priority. 而剩下的功能可以是low priority的测试,至于力度,就取决与测试时间.
1) Work with BA, DEV, & PM, 根据risk或者potential loss来选择high priority tasks, 进行risk测试
2) Ad hoc testing, 我们项目有个用户常用操作的workflow图, 所以先把basic workflow跑了, 保证customer在现实环境中的操作没问题, 剩下的再把之前选的high priority的测了,再是low的
3) 有个test cost curve图-根据cost of testing / loss due to untected defects /testing time来决定什么时候stop test (cost > loss的时候), 也就是制定optimum test的策略

3. 时间比较宽松
建议还有full regression吧, 但是上面提到的optimum test还是要考虑的,想要了解的朋友可以一起讨论下这个topic~

剩下的, 明天想到再写吧~好困啊

作者: woodcraft 时间: 2008-9-9 12:07
系统中的公共模块修改，建议从以下几点开始做：
1、至少从集成测试开始着手。集成测试是保证公共模块与其他模块接口的测试，公共模块的修改，一定要完成集成测试。
2、在资源保证的情况下进行单元测试。单元测试的要求比较高，但是效果较好。但是大系统的单元测试，一般比较难落实。
3、如果没有进行单元测试，至少进行公共模块的回归测试。
4、在完成集成测试与公共模块的回归测试基础上进行系统测试。能比较好的控制系统测试的回归测试次数。

另外还有几点：
1、注重测试需求分析。
2、一定要做测试设计。

综上所述，我的应对思路是：测试范围从小到大，在保证小范围测试质量的基础上在进行大范围的系统测试。注重小范围的测试分析与测试设计，避免系统测试的多次回归。

作者: deanaa 时间: 2008-9-9 16:15
我是测试的新人，抛砖引玉啦，说一下我的想法。
我认为公共模块有两种。一种是业务逻辑上的公共模块，主要是在业务逻辑上作为核心的模块，比如一些系统里财务模块。还有一种是技术架构上的公共模块，比如很多项目里的foundation或者comman包。这两种情况我们的处理方式有一些相同的，也有一些地方需要分别讨论。
对于前者，首先在做需求分析的时候需要特别慎重，尽可能避免后期因为需求的变更导致模块发生变化。在制定测试计划的时候优先考虑这个模块的自动化。具体到变更过程中，首先要对可能出现问题的方面进行分析，在设计变更方案，开发人员做code review的时候把变更的impact作为一个标准输出。根据开发提供的impact分析，召集相关模块的测试人员讨论和准备好测试用例（如果需要，也要准备自动化脚本），尽早估算好时间和资源，通知测试组长和项目经理。新版本从deliver到测试组之后，首先进行自动化测试，保证大的流程没有问题。然后根据测试计划来进行测试。
对于后者，我们更多关注的是技术上对各个接口的影响。在测试策略上，可以考虑尽可能早的介入到开发过程中，更多的采用白盒测试，根据设计文档由测试组准备一些自动化单元测试的用例，比如每个接口工作是否正常等等。当这些模块需要变更的时候，测试人员应该全程参与到开发过程中，从方案讨论，到code review。在开发人员改代码的时候，测试人员可以做自动化单元测试的代码。当新版本deliver到测试组之后，测试进行中需要特别关注系统出现的变化和问题，比如是不是有性能下降等等。
最后总结一下，我觉得公用模块的变更需要更多的关注和更多的资源投入。要想在少的投入下更好地保证质量，不仅仅是对测试人员本身的能力是更大的挑战，也是对项目组整体的协作能力提出了更高的要求。

作者: bht2000 时间: 2008-9-9 21:57
回答问题建议简明扼要一

作者: david0306 时间: 2008-9-10 10:30

,刚刚接触.看得晕晕的...

作者: juexing 时间: 2008-9-10 10:47
公共模块修改,需要通知到每个开发人员或写文档更新公告.
然后与开发组沟通后采取相应措施.

作者: 动力无限 时间: 2008-9-10 10:57
标题: 网友答题友情提醒
最好就有创新性和可操作性，比较好！！！

作者: 动力无限 时间: 2008-9-10 10:59
标题: 网友答题友情提醒
答题最好具有创新性、可操作性和实用性，比较好！！！

作者: archonwang 时间: 2008-9-10 12:14

原帖由 动力无限 于 2008-9-10 10:59 发表
答题最好具有创新性、可操作性和实用性，比较好！！！

呵呵，不知道自己的回答是否可以满足这些要求。往往自己实现过的东西，再提炼精简之下，就只剩下些自己感觉比较空洞的内容了。惭愧~~

作者: 望川 时间: 2008-9-10 13:50
标题: 好提议，顶一个呀！！

原帖由 动力无限 于 2008-9-10 10:59 发表
答题最好具有创新性、可操作性和实用性，比较好！！！

好提议，顶一个呀！！

作者: 爱吃鱼的月亮 时间: 2008-9-10 16:21
标题: 网友对大家答题要求高是好事

原帖由 bht2000 于 2008-9-9 21:57 发表
回答问题建议简明扼要一

网友对大家答题要求高是好事，说明大家都进步了！！！

作者: zhyb_2008 时间: 2008-9-11 10:52
标题: 对于公共模块的修改，怎么更好的保证既测试全面又不至于有太大的冗余
需要确定的是:公共模块从开始设计到完成,肯定已做过完整的测试工作.可以说已经全面,
现在再进行修改,可以考虑一下,
为什么会修改:一是需求变更,二是缺陷修复,需要回归测试,否则做为一个主体模块,不会做变更.
对需需求变更的测试工作,可以说还是需要按部就班,测试工作做一个完整的流程
对于缺陷修复引里的公共模块的修改,也就是测试人员日常的工作的一部分,至于是不是全面,是否冗余,和测试人员素质以及工作习惯有关,这是人为,但可控的因素了.

作者: 思渝 时间: 2008-9-11 12:52
标题: 是争论引发的问题？？
前面一期答题高手如云，人气很旺，这期怎么人气就这么少？？？到底是什么原因呀？？

楼主们，要求不要太高啦，很多人都打退堂鼓了，呵呵！！！

建议：版主增加奖励的人数，提高测试前辈们的答题积极性，哈哈！！！！

作者: goal1860 时间: 2008-9-11 15:26
其实很多测试的问题都是由于系统本身设计造成的。比方说，一个高耦合的系统总是牵一发而动全身，你让别人怎么区分公共模块？公共包的接口老是改，你让调用这些接口的模块怎么维护？开发特别是设计人员经常忽视软件的"可测试性",因为这在客户角度可见度很低。为什么我们要求测试贯穿始终？就是要所有人从需求开始到发布自始至终重视所有提交工件的“可测试性”。
好，解决这个问题以后我们可以从测试的角度来看看有什么策略可以采用，先从常规手工测试开始。
1。假定公共模块改变了实现方式但不改变签名接口，这个好办，单元测试就可以搞定。个人始终认为完整高质量的一套单元测试套件对于保证产品的质量是至关重要的。只要原有的单元测试100%通过了，我们就有理由信任现在的代码依然可靠。风险：低
2。单个公共模块的接口有改变，但不影响其它模块的接口。建议做全套单元测试，从索引中找到所有有调用关系的模块，做集成测试，回归测试。风险：中
3。多个公共模块同时有变动，常见于大规模的系统重构，如应用新的设计模式。这种变动万不得已是不建议的，因为风险太大。真的有了这种情况只能根据实际情况尽可能全面地重新测试。建议设计测试用例的时候一定要按严重度分级，测试时从高到低往下做，降低潜在的损失。同时建议为用例和代码模块建索引，有了代码变动相关联的测试用例就要升级为高优先级。风险：高
4。对于新的公共模块，在进行了较好的单元测试和接口测试以后，可以在优先级最高的测试用例中做全面的系统测试，对于其他测试用例可以当作第三方模块（假定无缺陷)来处理。风险：高

再说自动化测试，通常我们并不特别重视自动化测试的执行开销，因为经常是在夜里执行。所以我们不太在乎冗余度，但是极端重视用例的覆盖度和独立性。举个例子，对于业务对象我们常做的操作是C(增)R(读)U(写)D(删)，那从自动化的角度来说典型的测试场景就是：
1. C->validation
2. C->R->validation
3. C->U->validation->R->validation
4. C->D->validation
5. C->U->validation
6. C->D->C->validation
很容易看出冗余度是很高的。

作者: archonwang 时间: 2008-9-11 15:47
标题: 回复 21# 的帖子
很同意楼上的这些做法，觉得这个问题需要解决的核心还是要解决设计问题。测试在后方所作的工作再多也仅仅是作为设计的辅助。如果没有良好的意识和流程，很难纠正之前过程执行的具体问题。测试尽早介入只能说是一种权宜之计，毕竟，具备系统分析和评审能力的测试人员数量很少。

作者: huguxiang 时间: 2008-9-11 15:52
标题: 回复 1# 的帖子
方法一：.列出调用了公共模块的界面，逐个检查测试，最简单直接的办法。
方法二：找一个具有代表性的调用了公共模块的界面，认真测试。
方法三：这个公共模块的修改如果是只修改了后台代码，则注重模块与模块之间的逻辑测试；如果是修改了数据库，则注重数据库相关的表的字段数据类型等的测试，等等，修改什么测试什么具有针对性。

作者: 鬼城 时间: 2008-9-11 17:50
标题: 好提议，赞一个！！

原帖由 动力无限 于 2008-9-10 10:59 发表
答题最好具有创新性、可操作性和实用性，比较好！！！

好提议，赞一个！！可是真正实施难度较大呀！！

作者: mashuai8060 时间: 2012-3-22 14:06
能不能简单的用汉语阐述呢？要么，你全用英文，多些专业名词，也让我们开开眼界。讨厌汉语夹杂英语！！！！！！非常讨厌！！！！！！！

作者: 浩月三元里 时间: 2012-6-15 01:02
标题: 评论
楼主说的有道理啊

作者: 浩月三元里 时间: 2012-6-20 01:36
标题: 评论
恩恩很好..

作者: rockbody 时间: 2012-8-10 15:40
确实有点晕晕的

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)