这两天翻了好多测试大咖们写的博客，一直想找到属于我的那个答案：测试到底该怎么进行？

这应该是仁者见仁，智者见智，或许这个问题真的没有一个标准的答案，就像不同的人对不同的幸福生活的定义一样，只能是有一个大概的模板，你只能提取共性，但必须是属于你个人的。

测试到底该怎么进行？要回答这个问题，个人觉得真的比较难，它涉及到你公司的测试现有的测试规范，而不同的公司，流程是不一样的；它又涉及到你的测试团队，测试团队人员之间的配合度、默契度，为什么要说默契度呢？因为当一个项目涉及 N 个系统时，不同测试人员负责的系统可能不同，这就要求人员之间富有默契的配合；它还涉及到你现有的测试工具、测试框架等。

一定程度上，谁可以说 “我的答案一定准确”，这是有点牵强的，你只有你自己的一套规范，属于你的，但这在一定程度上已经足够了。

下面我来说说我对于这个问题的答案，不能说是答案，只是我个人的一点见解：

在某各项目或某项功能开发之前，一般公司都会有个项目评审，做得较好的公司会在项目评审之前，给到各个要参加人员一份初期的项目描述文档，但并不是说所有公司都是这样，有些可能评审之前并不会给出项目描述文档，而是在评审时直接讨论；也并不是所有的公司评审时都会拉上负责这个项目的测试人员一起参与评审，这就看测试在公司的相对地位了，作为测试人员的你，没有参加需求评审，也不要感到意外。当然，如果 “有幸” 参加了公司的项目评审，那你可以直接提出自己对于项目描述的疑惑，对项目设计可能存在的缺陷提出自己的建议。

评审之后，产品应该会根据讨论的结果对项目描述文档进行完善，给出一份具体的需求文档，而作为测试的我们，拿到需求文档后，该怎么往下走？（也并不是所有的公司产品会给到测试需求文档）大家都会说：分析需求文档，而作为我们到底又该怎么分析？这里说说我个人的看法：

1.明确该项目具体是干嘛？上线的目的何在？

2.该项目设计到的功能？ 可以细分为哪些功能？

3.该项目的具体流程是什么？流程中每一步可能会发生什么？

4.列出各功能的测试点。

5.测试用例的设计，数据的准备。关于测试用例，如果只是对于只上线一次的项目，或是上线后项目基本不会改动，又或时间不允许的情况下，个人觉得就没必要写用例了。

这里可能会有用例评审，但是并不是每家公司都有，用例评审的集大家的思想于一体，对用例的完善，可以得到更高的覆盖率。

6.该考虑怎么执行？用什么工具执行？对于功能性测试，我们只要通过前端页面进行执行就是，再保证功能正常的情况下，再考虑浏览器或手机型号的兼容性了；对于接口测试的话，我们就得进行工具的选择了：是用 postman，或是 jmeter，或是其他，这个就得根据接口的协议类型，以及自己对工具的熟悉程度了，有些接口是需要自己写一个模拟客户端发起请求的，比如 Hessian 接口等；对于性能测试、安全测试，也涉及到工具的选择，当然主要是你对可能引起性能问题的场景的设计了，可以用 LoadRunner 或 Jmeter 或其他，这个本人很少实践过，模拟过一些并发。

执行过程中，设计到一个主要问题就是：bug 的提交。有些可能使用 QC，有些可能用禅道、有些可能是 readmine 等，工具不是目的，怎么减少沟通的成本是关键。对于发现的 bug，作为测试最好有自己的一套记录方式，提交的 bug 产生过程对开发要描述清楚，在开发修改完 bug 后，对测试来说，什么时候进行再次验证？又是一个值得深思的问题。时间把握不好，自己会陷入一个可悲的循环：开发每完成一个 bug，提交一次版本，你就回归一次。想想看，这是多么痛苦的一件事。我一直在想，到底该怎么控制回归这个度？是不是得与开发约定，给回归定一个次数，超过这个度，彼此反思，谁应该为此负责？（肯定找开发了，发了这么多版本竟然还有错。）

7.测试执行结束，我们还得回过头来，思考一下，可能自己遗漏的某些功能点。

8.测试完成之后，最好自己写一个测试报告之类的，总结一些自己这次测试的方法、测试的流程等是否可以改进？自己对测试数据的制造，是否可以优化？是否可以写一个存储过程，为下一次复用？

9.上线验证问题，在上线之前，应该准备上线需要或者是可以验证的功能所需的数据，上线之后，是否有 bug 存在？为什么还会存在 bug？是自己测试的疏忽，还是其他原因？如果是自己的疏忽，反思一下，自己为什么会遗漏了？总结教训，反思自己的错误。

以上就是个人对于这个问题的粗陋见解，欢迎各位指正，谢谢。