对于公共模块的修改，怎么更好的保证测试全面？（08-09-08）（获奖名单已公布）
在一个大的系统中，对于公共模块的修改，测试怎么更好的保证既测试全面又不至于有太大的冗余？请各位同行踊跃发表自己的看法和提出自己宝贵的建议。
感谢会员调皮精灵提供此精彩问题！如果你也有问题想提出来和大家一起讨论，请点击此处>>
说不定下期讨论的问题就是由你提出的哦，请快快参与吧！
非常感谢各位会员积极参与，截止至9月15日24：00分，从该贴所有评论中选出部分作出精彩评论的会员予以奖励。礼品和积分将在本周内送出。
获奖名单奖项获奖名单奖励答案链接
一等奖poisson当当购物卡50元8#
二等奖goal1860300论坛积分21#
三等奖archonwang100论坛积分 6#
和这个帖子是不是一样的哟 ~~测试过程中如何应对频繁的版本变更？（08-02-29） 先占个座，看看楼下精彩回答
[ 本帖最后由 chengxq 于 2008-9-8 14:26 编辑 ] 原帖由 杀手太冷 于 2008-9-8 14:19 发表 http://bbs.51testing.com/images/common/back.gif
和这个帖子是不是一样的哟 ~~测试过程中如何应对频繁的版本变更？（08-02-29）
谢谢提醒，题目已更改． 等待看楼下的有什么高招。 倒~~，占楼位休息下。周四解答。
另，上周的问题忘了答，这次记在行事日历里了。晕~~:Q
OK，现就该问题提供初步的解答。
=============================================================================================================
要解决公共模块的测试覆盖问题和效率问题，从根本上讲，就是要解决测试分析能力的提升问题。
测试人员在进入到测试执行阶段前，需要花费大量的时间用于整理测试需求，细化需测试的需求点，阅读相关的技术框架、分离系统接口及接口间调用关系等准备工作，这是非常重要的前提，没有这些前提，就不会有测试分析，至于后面的执行，充其量不过是Monkey Testing。问题中关于公共模块修改的测试覆盖（也就是全面性和剔除冗余）也是基于此而来的。
那么，我们如何做好诸如此类的测试分析工作呢？
1. 首先，我们应该很好的通读和理解需求。这里说的通读和理解的最低要求是：明确系统的各级对象，例如一个人事管理系统，针对的是员工、组织等对象的具体管理，而这些管理关系的依托是基于各种各样的业务流程和业务规则，从开发的语言的来理解，就是对象间的关系。至于说到对象的状态、关联属性等等都是这种关系的具体体现。
2. 在理解的基础上，理清对象及对象间关系，接口与接口间关系是对需求的进一步解读（简单点，也就是说分离这些对象及其关系时，必须深入到系统设计这一层）。这一个步骤的最终目的就是为了对公共模块进行直接关系和间接关系的整理（最好能列出一张表对应变更内容），以确保对系统结构认知的细化与可跟踪性。
3. 当你把所有的内部、外部关系理清后，剩下的工作就是筛选变更所涉及的范围。在这个过程中，需要注意的间接关系的是梳理，经验丰富的测试人员会把较多注意力集中在业务流所涉及的对象或接口上，而普通的测试工程师仅关注当前的对象/关系及其直接关联对象/关系。产生这一差异，首先也是最重要的是测试工程师对业务理解的深度，其次是梳理工作的规范性（五步法分析或七步法分析），最后才是技术能力。
4. 最后的步骤当然是设计或筛选需要的测试案例。由于是公共模块，其涉及的面较广，但是在设计案例的时候可以按如下原则考虑：公共模块在所涉及的这些功能中是输入？还是过程处理？还是输出？不同的情况需要分析不同的处理方式，一般作为输入的情况，仅需要进行单元级别的测试，作为过程处理和输出的，都必须严格遵照案例至少执行一次。
5. 补充几点以上流程处理上的说明。一是要注意经常性评审，很多情况都是测试人员自说自话，从不评审或确认。这是很危险的动作，切记必须评审；二是善用不同的测试方法来规避冗余，例如公共模块测试时要有必要的测试：单元测试必须优先进行（单元测试最好是有框架 + 测试集 构成，对迭代类型开发的项目或产品有不可估量的工作量减少和质量保障作用），集成测试当然也是必不可少，其后的功能性测试及系统测试作为补充测试内容处理等等；第三，要注意选择测试案例的筛选和设计方法，很多完全雷同的测试要有规避识别的能力。这就需要测试人员具备较强的分析能力和系统认知深度。
=============================================================================================================
说了那么多，实际上这些要实现这些步骤还有一个非常重要的依赖，就是规范化的开发流程和开发文件管理模式。没有这些的支撑，要说分离公共模块，提高对变更内容的测试覆盖，降低测试冗余，提升测试效率对大多数测试工程师只能说是遥远的梦想。如果说具备了脱离其需求和设计，能自行设计符合当前系统结构与框架的公共模块关联模型，也足以说明其分析能力较之一般开发人员更胜一筹。
顺带一提，你可以尝试着从理解别人的系统设计逐步转入到系统分析与设计的领域。
[ 本帖最后由 archonwang 于 2008-9-10 12:11 编辑 ]
请各位朋友或同学放心答题
唉，上周的每周一问少了大家的兴致，还请高手继续答题呀？怎么都写这么短？ 我觉得这边对"公共模块的修改"定义的不是很好, 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~
剩下的, 明天想到再写吧~好困啊 系统中的公共模块修改，建议从以下几点开始做：
1、至少从集成测试开始着手。集成测试是保证公共模块与其他模块接口的测试，公共模块的修改，一定要完成集成测试。
2、在资源保证的情况下进行单元测试。单元测试的要求比较高，但是效果较好。但是大系统的单元测试，一般比较难落实。
3、如果没有进行单元测试，至少进行公共模块的回归测试。
4、在完成集成测试与公共模块的回归测试基础上进行系统测试。能比较好的控制系统测试的回归测试次数。
另外还有几点：
1、注重测试需求分析。
2、一定要做测试设计。
综上所述，我的应对思路是：测试范围从小到大，在保证小范围测试质量的基础上在进行大范围的系统测试。注重小范围的测试分析与测试设计，避免系统测试的多次回归。 我是测试的新人，抛砖引玉啦，说一下我的想法。
我认为公共模块有两种。一种是业务逻辑上的公共模块，主要是在业务逻辑上作为核心的模块，比如一些系统里财务模块。还有一种是技术架构上的公共模块，比如很多项目里的foundation或者comman包。这两种情况我们的处理方式有一些相同的，也有一些地方需要分别讨论。
对于前者，首先在做需求分析的时候需要特别慎重，尽可能避免后期因为需求的变更导致模块发生变化。在制定测试计划的时候优先考虑这个模块的自动化。具体到变更过程中，首先要对可能出现问题的方面进行分析，在设计变更方案，开发人员做code review的时候把变更的impact作为一个标准输出。根据开发提供的impact分析，召集相关模块的测试人员讨论和准备好测试用例（如果需要，也要准备自动化脚本），尽早估算好时间和资源，通知测试组长和项目经理。新版本从deliver到测试组之后，首先进行自动化测试，保证大的流程没有问题。然后根据测试计划来进行测试。
对于后者，我们更多关注的是技术上对各个接口的影响。在测试策略上，可以考虑尽可能早的介入到开发过程中，更多的采用白盒测试，根据设计文档由测试组准备一些自动化单元测试的用例，比如每个接口工作是否正常等等。当这些模块需要变更的时候，测试人员应该全程参与到开发过程中，从方案讨论，到code review。在开发人员改代码的时候，测试人员可以做自动化单元测试的代码。当新版本deliver到测试组之后，测试进行中需要特别关注系统出现的变化和问题，比如是不是有性能下降等等。
最后总结一下，我觉得公用模块的变更需要更多的关注和更多的资源投入。要想在少的投入下更好地保证质量，不仅仅是对测试人员本身的能力是更大的挑战，也是对项目组整体的协作能力提出了更高的要求。 回答问题建议简明扼要一 :lol ,刚刚接触.看得晕晕的... 公共模块修改,需要通知到每个开发人员或写文档更新公告.
然后与开发组沟通后采取相应措施.
网友答题友情提醒
最好就有创新性和可操作性，比较好！！！网友答题友情提醒
答题最好具有创新性、可操作性和实用性，比较好！！！ 原帖由 动力无限 于 2008-9-10 10:59 发表 http://bbs.51testing.com/images/common/back.gif答题最好具有创新性、可操作性和实用性，比较好！！！
呵呵，不知道自己的回答是否可以满足这些要求。往往自己实现过的东西，再提炼精简之下，就只剩下些自己感觉比较空洞的内容了。惭愧~~:L
好提议，顶一个呀！！
原帖由 动力无限 于 2008-9-10 10:59 发表 http://bbs.51testing.com/images/common/back.gif答题最好具有创新性、可操作性和实用性，比较好！！！
好提议，顶一个呀！！
网友对大家答题要求高是好事
原帖由 bht2000 于 2008-9-9 21:57 发表 http://bbs.51testing.com/images/common/back.gif回答问题建议简明扼要一
网友对大家答题要求高是好事，说明大家都进步了！！！
对于公共模块的修改，怎么更好的保证既测试全面又不至于有太大的冗余
需要确定的是:公共模块从开始设计到完成,肯定已做过完整的测试工作.可以说已经全面,现在再进行修改,可以考虑一下,
为什么会修改:一是需求变更,二是缺陷修复,需要回归测试,否则做为一个主体模块,不会做变更.
对需需求变更的测试工作,可以说还是需要按部就班,测试工作做一个完整的流程
对于缺陷修复引里的公共模块的修改,也就是测试人员日常的工作的一部分,至于是不是全面,是否冗余,和测试人员素质以及工作习惯有关,这是人为,但可控的因素了.
是争论引发的问题？？
前面一期答题高手如云，人气很旺，这期怎么人气就这么少？？？到底是什么原因呀？？楼主们，要求不要太高啦，很多人都打退堂鼓了，呵呵！！！
建议：版主增加奖励的人数，提高测试前辈们的答题积极性，哈哈！！！！
:victory:
页:
[1]
2
