讨论：交叉测试的适用场景条件及对测试人员的要求
项目背景：项目处于广度和深度不断快速扩展阶段，系统模块和模块之间的逻辑关联性较强。举例说明：创建订单到支付，分别会在用户端，商户端，管理后台端产生数据，涉及订单、账单、物流、发票等各类功能模块， 功能链路较长。
交叉测试策略推行原因：
测试小组起初因为担心成员负责模块固定，假设成员中有人请假，其他人无法快速对接工作。便开始推行交叉测试策略（原话是这么表诉，实际做法就是每个迭代都让不同的成员负责不同的模块）
推行一段实际后，生产问题时有。个人认为可能跟交叉测试策略执行原因有部分关系。理由如下：
1、功能熟悉要求：
项目广度、深度不断扩展的情况下，执行交叉测试需要测试人员对功能整体达到一定的了解程度，才能评估好版本迭代的影响范围
2、测试人员要求：
测试人员可能只会针对当前迭代版本需求进行了解、验证。了解以往需求意味着额外的工作量，测试人员容易“偷懒”
此外也产生了一些扯皮过程，如同一个功能模块，前后多人负责测试过，出现问题时，无法找到具体负责人员。 最近版本的测试人员会认为问题早就存在了，不是他的漏测导致的。定位到具体个人了，又会让成员产生工作情绪
我认为：为了避免一些问题，采取策略，进而引发了其他问题，这是策略推行过程中会遇到的情况，需要及时去调整。
思考认为：可能需要另一些策略来辅助交叉测试策略的执行。局限于经验和理论，仅想到了需要测试人员在版本迭代后，撰写一份业务功能书，固定模板描述业务功能的执行过程，测试点，细节注意点。
我想跟大家请教的点有以下几个：
1、大家在各自的项目中，是否有推行交叉测试，具体如何实施，适用场景，条件如何
2、如果是为了避免这种情况（测试小组起初因为担心成员负责模块固定，假设成员中有人请假，其他人无法快速对接工作），大家在项目中是怎么处理的
3、测试小组中大家是采用什么方法，促进测试成员对项目的整体熟悉程度
页:
[1]
