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
很容易看出冗余度是很高的。

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

回复 21# 的帖子

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

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

回复 1# 的帖子

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

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

好提议，赞一个！！

原帖由 动力无限 于 2008-9-10 10:59 发表 http://bbs.51testing.com/images/common/back.gif
答题最好具有创新性、可操作性和实用性，比较好！！！


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

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

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

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

评论

楼主说的有道理啊http://www.bo-tm.com/1.jpg

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

评论

恩恩很好..http://0595ask.com/1.jpg

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

确实有点晕晕的
页: 1 [2]
查看完整版本: 对于公共模块的修改，怎么更好的保证测试全面？（08-09-08）（获奖名单已公布）