对于公共模块的修改，怎么更好的保证测试全面？（08-09-08）（获奖名单已公布）

默默巫 · 发表于 2008-9-8 10:44:54

在一个大的系统中，对于公共模块的修改，测试怎么更好的保证既测试全面又不至于有太大的冗余？

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

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

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

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

rockbody · 发表于 2012-8-10 15:40:01

确实有点晕晕的

浩月三元里 · 发表于 2012-6-20 01:36:51

恩恩很好..

浩月三元里 · 发表于 2012-6-15 01:02:24

楼主说的有道理啊

mashuai8060 · 发表于 2012-3-22 14:06:48

能不能简单的用汉语阐述呢？要么，你全用英文，多些专业名词，也让我们开开眼界。讨厌汉语夹杂英语！！！！！！非常讨厌！！！！！！！

鬼城 · 发表于 2008-9-11 17:50:53

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

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

huguxiang · 发表于 2008-9-11 15:52:39

方法一：.列出调用了公共模块的界面，逐个检查测试，最简单直接的办法。
方法二：找一个具有代表性的调用了公共模块的界面，认真测试。
方法三：这个公共模块的修改如果是只修改了后台代码，则注重模块与模块之间的逻辑测试；如果是修改了数据库，则注重数据库相关的表的字段数据类型等的测试，等等，修改什么测试什么具有针对性。

archonwang · 发表于 2008-9-11 15:47:37

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

goal1860 · 发表于 2008-9-11 15:26:18

其实很多测试的问题都是由于系统本身设计造成的。比方说，一个高耦合的系统总是牵一发而动全身，你让别人怎么区分公共模块？公共包的接口老是改，你让调用这些接口的模块怎么维护？开发特别是设计人员经常忽视软件的"可测试性",因为这在客户角度可见度很低。为什么我们要求测试贯穿始终？就是要所有人从需求开始到发布自始至终重视所有提交工件的“可测试性”。
好，解决这个问题以后我们可以从测试的角度来看看有什么策略可以采用，先从常规手工测试开始。
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
很容易看出冗余度是很高的。

思渝 · 发表于 2008-9-11 12:52:13

前面一期答题高手如云，人气很旺，这期怎么人气就这么少？？？到底是什么原因呀？？

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

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

zhyb_2008 · 发表于 2008-9-11 10:52:27

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

爱吃鱼的月亮 · 发表于 2008-9-10 16:21:56

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

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

望川 · 发表于 2008-9-10 13:50:52

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

好提议，顶一个呀！！

archonwang · 发表于 2008-9-10 12:14:04

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

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

动力无限 · 发表于 2008-9-10 10:59:42

答题最好具有创新性、可操作性和实用性，比较好！！！

动力无限 · 发表于 2008-9-10 10:57:11

最好就有创新性和可操作性，比较好！！！

juexing · 发表于 2008-9-10 10:47:20

公共模块修改,需要通知到每个开发人员或写文档更新公告.
然后与开发组沟通后采取相应措施.

david0306 · 发表于 2008-9-10 10:30:53

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

bht2000 · 发表于 2008-9-9 21:57:58

回答问题建议简明扼要一

deanaa · 发表于 2008-9-9 16:15:10

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