作为一名Tester，无论是面试还是工作，我们都常常会遇到该问题，毕竟现在大部分接手的项目都是中小型的项目，很多又是生疏行业的系统，所以这个问题就会常常伴随我们，那么遇到这个问题该怎么办呢，现在我们就分下面几点来讨论一下。

1. 了解测试任务

我看网上有些博主一上来就让大家看资料了解系统，就是下面讲的第二点，当然这样做也行，但是会导致效率低下，就像我们上学时做阅读理解一样，最正确的做法应该是带着问题去看资料，所以我们应该一上来明确测试任务，然后带着这些测试任务的问题去看资料。

2. 从现有资料中获取信息

明确测试任务后，就可以问研发团队要该项目的所有资料了，这里面主要包括产品需求文档（PRD）、用户手册和架构图等，找出系统具备的功能、性能、安全等特性。

说到这可能有些同学就真的会老实地把这些资料全部从头到尾看完，这样可取吗？可以这样做，但是不推荐，原因有两点：

其一这样会花费大把的时间，如果遇到项目比较赶那怎么办？

另外就是资料内容那么多，全看完你能记得住？

所以我这边强调的做法是，一定要从项目经理或产品人员那里弄清该系统的主要功能和主要业务，先把大头拎出来，做到主次区分！是不是更像阅读理解了？哈哈。

3. 制定合理的测试计划

接下来我们就要制定一个稍微详细点的测试计划，注意我说的是“稍微”，因为这个时候对系统还是比较生疏的，也只能做到“稍微”，等后面谈到的几点做完再做正式测试计划。

那么这里的测试计划要明确测试的目标、范围、方法、重点事项、测试策略和时间表（在这里暂且不用太多考虑人员组织、测试风险、延期之类的）。

该测试计划只是用来进行初步测试的，尽量覆盖系统的各方面就行。

4. 进行探索性测试

我知道很多测试工程师一上来就是做这步，然后边做边去完成前面几点，这种做法看起来迅速，其实会导致效率降低，常言道“磨刀不误砍柴工”，我们还是一步一个脚印有条不紊地测试系统才能尽可能漏测。

好言归正传，怎么进行探索性测试呢，一般人的做法就是把一些主要功能点验证一下就完事了，比如登录、注册、输入、输出、提交等。诚然，这些是必做项，但我们所要做的远不止此。这些仅仅是功能测试领域的一些常规操作，我们还有很多项需要去检查：

在做功能测试我们要顺带做业务（逻辑）测试，如果主流程都跑不通，那么功能再正常有什么用？一旦发现主流程有问题，最好还是打回重做！

其次是异常（如边界）测试，别小看这项，在我们做测试时，发现一个系统的初始版本最容易出现的问题就是边界异常，所以这里就是我们探索性测试的二八原则里的二，甚至可以说是“二”里面最值得关注的。

然后是兼容性测试，如果用户没有指定浏览器就要支持主流的浏览器），如果用户指定了浏览器那么只需要关注那些浏览器即可。

然后是性能测试，看用户的性能要求，如果没有性能要求则自己评估要达到的最低性能。即使项目没有明确提出性能要求，我们也要做最起码得把关，否则到时候性能出了问题赖到我们头上也好自证清白。

最后还要兼顾一下安全测试，比如对于一些常见的如SQL注入、跨站请求伪造（CSRF）、跨站点脚本（XSS）。

测试过程中，要记录所有发现的问题，并生成详细的测试报告，这样可以清晰地概述测试结果、解决方案和问题的优先级。

5. 进行迭代测试

根据上面测试得到的结果对原先制定的测试计划进行调整，这个时候就要制定正式的测试计划，在探索性测试的基础上看看是否有漏测，记录之前发现的疑问和风险，再次明确测试的重点，优先级，然后在开始正式对系统测试。

6. 多和研发团队中成员沟通

软件研发需要团队协作，切忌孤军奋战，虽然测试的展开主要靠自己，但是一旦遇到问题，还是要及时与产品、研发保持沟通，及时告知领导测试进度和测试过程遇到的问题，这样有助于促进问题的解决。

千万不要觉得自己是测试，就为了树立非常专业的形象而羞于开口请教，这样是得不偿失的，作为过来人，我是有过好几次这样的经历的。

当然还是那句话，可以请教但是最好是真的搞不懂再去，不要一遇到问题就问别人，这样只会招人烦。

更多软件测试相关推荐：

软件测试更多干货文章

软件测试就业培训

            作者:有房车的直男  文章来源：51testing软件测试   网版权归原作者所有

            上文内容不用于商业目的，如涉及知识产权问题，请权利人联系博为峰小编(021-64471599-8103)，我们将立即处理