我是如何做软件测试项目的【转载】

sylsc

我是如何做软件测试项目的
上一篇 / 下一篇  2013-08-28 23:48:48 / 个人分类：经验之谈
查看( 34 ) / 评论( 0 ) / 评分( 0 / 0 )
最近公司刚完成了一个比较大的项目-单品页模块化，即使用现在比较流行的Twitter Bootstrap进行前端开发。说其大是因为工作量大，开发前期投入约80人日，包括前端开发及PHP开发，且不包括修复bug的时间，测试投入约48人日，同时也是非常重要的项目，直接关系到转化率，稍有差池就会导致转化率的下降。而我有幸成为该项目的测试负责人，此文即介绍我自己是如何带这个项目的。

1. 人员分工合理，老人带新人
其实这次项目中，人员分配是3个老人（工作也不到2年），2个新人（工作不到1年），2个实习生，加上我自己共8个人负责功能相关测试。通过把功能及测试内容进行拆解，并对子功能评估工作量，测试难度及影响范围，与参与的人中最熟悉的人一起评估大概工作量，结合项目计划，投入参与的人员，制定出最终的测试工作量评估，当然，在评估的时间上加上buffer时间将风险得以降低。秉承以下原则进行分配工作：
1）最核心的内容让最熟悉的人来做；
2）新人负责边缘一点的功能，边做边学；
3）在其中挑出一个能承担较多的人，以减少“巴士因素”；
4）其中1个或2个人工作内容相对少点，方便灵活调配去协助其他人；
5）让细心的人做更多页面测试，让逻辑思维强的人做更多业务逻辑性测试，充分发挥各自优点。

2. 做好计划，一切心中有数
一份好的计划具有指导意义，可以回答何时能发布的问题。所以为了制定一份靠谱的计划，需要充分理解项目内容，项目人员情况，其余版本代码合并时间及可能的风险，需要进行哪些内容的测试，何时开展性能测试，需要做怎么样的兼容性覆盖，哪些功能需要做安全性测试等等。其实我觉得可能并不一定要撰写一份完整的长篇计划文档，只要在一两页能列出以上内容，说明了测试计划最关键部分，其余的都是形式。

3. 严格控制其余需求加入及本需求变更
影响项目计划的三大杀手锏：开发未按时提交代码，开发质量差及需求变更。需求变更可能会导致对之前的代码架构重设计，测试人员重新测试，严重影响项目计划，在进行该项目时，就与项目管理及PM达成一致，为了保证按时上线，控制其余需求加入，并不再对本次需求进行优化，保证该项目的优先级，预计的项目人员及项目资源。

4. 明确测试用例，做好评审
任何一个项目，一份考虑较周全的用例可以大大降低项目风险，增强测试人员乃至整个项目组的信心。这个项目也毫不例外，因为没有新的业务逻辑及功能，所以前期我们只需整理之前的用例，并再次与开发人员及PM评审，并列出冒烟测试用例，而它将作为冒烟测试运行之用例，也用于开发人员自测使用，毕竟是经过评审过的，所以大家都认可。

5. 保持测试与开发环境独立
开发环境与测试环境的独立其实并不是从这个项目开始的，而是一直以来都是这么做的。毕竟每一轮次代码及环境的稳定性会影响到所有测试人员的进度，谁都不想让开发人员在测试环境任意调试，修改配置，或直接进行开发，如果遇上非要在测试环境来复现某个问题时，也要等到环境没人用时进行。这么做也是为了让我们每一轮次的测试结果都是可信的，而不会因为环境的变化，让刚才测试通过的用例又执行失败，让刚刚报的一个bug突然变成了NOT A BUG。

6. 每轮次冒烟测试，督促提高开发质量
每一轮次的系统测试，都要进行冒烟测试，同时越到项目后期，越要提高冒烟标准。这么做的意义也是为了督促开发人员多自测，让团队一起为产品质量及发布齐心协力。所以，在一开始冒烟测试时，可能就把影响流程性的会block其他很多case（比如10条及以上）的case作为冒烟测试用例，因为第一轮次的测试都是覆盖性的，而往后，可能就是多回归信心不太足的模块，回归bug等，那么，在后期的冒烟测试时，对于多次反馈仍未修复的较严重的bug和bug重灾区的核心功能及流程也有必要作为冒烟测试范围。每一轮次的测试结果都在邮件中抄送给各个团队负责人及CTO，开发团队每个Q进行的绩效考核也将考虑冒烟的情况，督促提高开发质量。而且若因开发质量不够好冒烟测试不通过而导致的项目延期，则不再属于测试团队的责任。

7. 汇总以往出现过的严重或典型缺陷，在该项目验证
每一次较大型的发布，都让测试人员颇为担心，害怕出现遗漏bug，但是总会有未考虑周全之处，每次大型发布之后，或是被公司内部的人发现或是被我们的用户发现，我们需要对以往的经验进行总结，汇总出以往项目从眼皮底下溜走的bug，他们发生的原因及如何避免，这些都是教训及经验谈。在这个项目中，一样是把之前遗漏过的bug告诉大家，一定多加注意。

8. 进行每日项目会议，掌握项目进展情况
每天抽出半小时，把大家召集到一起，了解每个人的进度，遇到的问题，让大家积极发言，进行头脑风暴，这个时候的碰撞往往能事半功倍，我也会把我自己的想法告诉给大家，哪些功能间需要加强协调测试，比如在UI上有交互的，在某一个标签处显示2个内容而恰好属于不同人测试，在数据上都有读取或修改的，让功能间有依赖的人多沟通，测试时多考虑相互间的影响等等，会上统一集中的帮助大家解决问题或提供解决问题的思路。我觉得每日会议可以让大家更像一个团队作战，而不是单打独斗，各干各的，最后乱成一团糟。

9. 注意风险控制，了解缺陷影响范围
项目越往后，bug数量越收敛，而给我们最大的障碍可能就是我们不够了解缺陷影响范围，不懂得回归bug时还需要测试些什么，这却正是测试新人最大的挑战。仅仅是测试bug里说的这情况吗？大多数时候肯定不够，老生长谈如何判断功能间的依赖：
1. 有关输入：这些功能会不会处理同样的输入？
2. 有关输出：这些功能会不会在界面上显示在同一个区域？会产生同一个输出吗？
3. 有关数据：是否会操作同样的数据？是读取还是修改？
如果上面三点中有一个答案是会，那么他们之间肯定就有依赖！
同样，你也可以通过咨询开发人员，这个bug改动会影响到哪些地方，对于熟悉公司业务及代码的人来说，也可以通过diff两个版本间代码差异获得答案。

10. 合版后明确回归范围
这里的回归跟上面的回归其实是有差异的，因为上面的只针对bug而言，这里的回归就涉及到该产品其他正在进行的项目内容。因为公司进行多个项目多个分支并行开发，在进行该项目时，有别的项目已完成并发布上线，那么该版本发布前需要合并这些项目的代码。有些情况下会出现未正常合并或合并过程中未正确处理好冲突，或在业务需求层面上就有相互影响的情况，这就需要有针对性的进行回归。

对于未合并的，让对应项目参与者运行下冒烟的case就知晓结果了；对于有冲突的，让合并代码的开发人员告知冲突的代码功能是什么，在业务流程回归之外重点关注下对应的功能；对于业务层面，就需要对每个项目内容充分熟悉了解影响到的地方，明确需求具体内容，触发条件，处理过程及结果，有侧重点的进行验证。