如何做好系统测试
目录
1 目的... 2
2 目标读者... 2
3 说明... 2
4 Part1 项目各阶段工作... 2
4.1 需求调研阶段... 2
4.2 项目启动阶段... 2
4.3 项目开发阶段... 3
4.4 集成和系统测试阶段... 3
4.5 项目上线... 4
4.6 运维阶段... 4
5 自我提升... 5
5.1 总结学习... 5
5.2 保持好奇心... 5
6 bug预防工作... 6
7 需要开发人员配合的工作... 6
7.1 数据库更新要求... 6
7.2 代码提交问题... 6
7.3 bug做解释... 7
本文旨在分享自己的测试心得，探讨如何作出高质量的系统测试工作，为测试员提供工作指导。对项目管理者来说，可以参考本文档评估测试工作量，检查测试员的工作质量。
初、中级测试工程师。项目管理者。
提高产品质量，是涉及全员、全流程的管理，在实际操作中困难重重。而本文此次只探讨四个方面，以后再陆续跟大家探讨其他流程。
为便于给读者建立和巩固测试技能体系，便于依据本文开展测试工作，本文按照项目发展阶段进行论述。
该阶段项目经理会跟客户进行需求调研，中间会开会讨论客户的需求，并进行评审。此时测试人员就需要进行参会讨论。这个阶段，测试人员工作主要是：
u 理解需求，特别是思维导图和业务流程图VISIO；
u 理解项目背景，这有助于制定测试计划，安排测试重点；
u 理解公司的业务，这点很重要，如果能从客户业务层面提出问题，会得到客户深深的认可；
u 找类似产品和行业背景参考。
制定测试计划
在项目启动会为止，项目经理已经需求调研完毕，且完成了开发任务排期。这时测试经理或者主管即需制定测试计划。。。公司现在的项目来看，测试时间是没法由测试自己选择的，所以，只能配合项目在既定的时间内提高测试质量吧。测试计划中的重点：
u 划分各个阶段的时间安排（单元测试阶段、集成阶段、系统测试阶段、回归阶段等）
u 测试工作安排（测试的内容，如功能测试、性能测试、兼容性测试、数据完整性测试、排他性测试等安排）
加深业务理解
加深业务的理解，根据需求说明书绘制系统测试visio图。要点：根据数据流向，绘制完整数据流，注意限制条件。
设计测试用例
根据《需求规格说明书》和Axure原型图进行测试设计。工作要点：
u 根据《测试工作指南》、《测试框架》和《测试用例库》编写功能测试用例；
u 根据《web安全测试规范》裁剪安全测试用例；
u 根据《APP测试用例大纲》裁剪APP测试用例；
u 准备测试数据
该阶段开发人员按照WBS进行开发，测试人员按照开发计划进行测试（功能测试阶段）。测试工作要点：
u 整理测试过程中遇到的系统疑问，记录到《XX系统业务疑问与解答》中；
u 填写《每日测试记录》并汇报；
u 重点检查需求实现的一致性，其次检查《GUI测试指南》；
u 整理并提交《每日测试报告》；
测试原则：遵循优先保证系统逻辑走通的原则。但测试过程中发现的bug，无论大小都提交到禅道中。
集成测试和系统测试的区别：
集成测试重点关注各个功能模块的数据联动、传输是否正确。系统测试在此基础上，还需要关注软件的安全性、稳定性、兼容性、性能等。
实际工作中，限于项目周期，一般会将两者结合测试。
为提高测试的质量和效率，将测试工作分为四轮执行，每轮测试工作的重点如下：
第一轮测试：
u 关注流程是否走通？主要关注正常流程和场景，即需求中定义的流程和场景。
第二轮测试：
u 存在性测试；
u 排他性测试
u 连续点击测试；
u 数据完整性测试；
u 安全性测试；
u 兼容性测试；
第三轮测试：
u 存在性测试（深度排查）；
u 探索式测试；
u 安全性测试（深度排查）；
u 兼容性测试（深度排查）；
u 性能测试
第四轮测试：
u 对外接口测试
u 需求变动测试（系统测试阶段末期，一般客户会查看系统并提出部分修改意见，此时重点关注新需求）
测试汇报工作：
u 在该阶段需每周提交《阶段性测试工作汇报》，汇报该阶段中系统发现的问题、bug发现趋势、bug状态等。
u 在系统测试结束后提交《系统测试报告》，评价系统是否具备上线资格。
配合项目组，准备系统验收资料，如《UAT测试报告》。
bug是测不完的，特别是急于上线的项目，可能漏测得bug更多。所以运维阶段需要注意收集项目上线后反馈的问题，建立《系统运维问题跟踪表》 。对运维阶段发现的bug总结分析原因，在下个项目中重点关注。
以上是作为一个测试员的基本工作，如果想真正做好系统测试工作，还有更重要的工作要补充。
正所谓温故而知新，平时把《黑盒测试框架》多看看。
好奇心就是多问问为什么，质疑精神就是要敢于质疑系统设计不合理，举一个较典型的例子。
这是一个分销系统的页面，图一是店铺管理中的上架商品列表，图二是下架商品列表页面，图三是选择商品的页面。实现的逻辑是，在选货页面（图三）选择商品上架，之后选择的商品会显示到上架商品列表（图一），可以对上架商品进行下架和删除的操作。 商品下架后显示到下架商品列表里。而把商品从上架或下架列表中删除后， 商品回归到选货页面。
测试这个页面时，习惯性的问自己，这个页面显示什么数据，为什么这么显示？然后就找到了一个有争议的地方：即选货页面（图三）是不显示下架商品的。为什么觉得有争议呢？ 因为假设我是一个用户，我把商品下架后，可能以后我都不会再主动关注已下架的商品，而在这个时间已下架的商品若有特殊的变动，我也难易得知（因为我更多的会去看选货页面）。 这样一来，日日顺商城做的一些推广可能就传到不到分销商那里。毕竟，商品数据还是不少的。
不过反过来说基于该分销平台的特点，可能会让用户 不会做下架的操作---预测大多数用户都会把全部商品选择上架，所以选货页面不加载下架的商品对应用影响并不大。
这个地方的争议，无论怎么实现，可以说是公说公有理婆说婆有理，不一定哪一种是最好的。
不过拿这个例子来讲，就是要为了说明如果测试过程中不多做思考，不多问一些为什么，不敢质疑系统的话，很多bug就会被漏测！
多数测试员做的质量保障方面的工作都是事后的补救工作（检测），bug预防是让测试员充分发挥事前和事中的的质量控制作用。
bug预防的必要性显而易见，bug越到后期发现，修改的成本越高，所以防患于未然肯定要优于亡羊补牢。
bug预防的方法主要是通过制定开发规范和测试规范。开发规范方面有《UI规范》、《编码规范》、《数据库规范》，其他包括《安全性开发规范》、《性能调优指导》、《兼容性开发规范》，并完善技术复用库（设计、组件、类库、代码）。 测试规范方面有《功能界面的检查指南》、《BUG管理规范》、《测试工作流程规范》、《安全性测试规范》，涵盖BS架构和APP，后续需要完善的是性能和自动化（自动化能解决的问题）方面的测试技术。
除了上面说的这些规范，每个项目测试过程中发现bug之后，也会通过分析找到具体原因和解决方案，做一些总结归纳，尝试建立该类问题的预防方法，补充到流程规范中，贯彻到全公司，最后监督执行。（世界级大公司对待bug的态度，谷歌的绩效考核，考核该类bug在本项目中出现的比率是不是比上一个项目小了，考核测试员在bug预防方面做得工作）
软件测试体系：
二、测试流程
版本发布控制制度。
三、测试规范
测试员工作的依据（检查标准），包括了bug分级标准，界面设计规范和web安全测试规范。
四、测试框架
工作指南（测试要点，或者说一个功能要做哪些测试）
五、开发框架
输入验证的完善等。
每次项目启动会，我都会对 项目团队的成员要求以下三点：
开发后期，数据库改动较少。这个时候对数据库结构的改动都用脚本执行。并在发版时一并发送测试员。---曾经多次遇到因为数据库改动不规范，导致测试时间增加，项目拖期的项目事故。
在bug预防中提过，代码集成要慎重。建议由条件的时候做一下code review，避免出现功能倒退等严重项目事故。同时发版和禅道上的bug要对应，因为测试人员会检查发版时间之前的bug。
bug解决后，在禅道可以做个解释。如此一来测试人员可以积累定位bug根源的经验，在之后的项目中，遇到类似的项目可以直指根源，给开发人员提供检查思路，缩短开发人间排查问题的时间。
我在文章里留了很多文件，这里保存不上。有想要的我给你word版。