最近有几个在做开发的同学问我是怎么做测试的，或者怎么对一个系统进行测试。
这个问题看似简单，其实范围很广，特别是在不知道公司业务和系统的情况下，无法给一个正确的答复。
如果我告诉你就是做功能性能安全测试，那其实是在敷衍你。就像你问我怎么能考一百分，我回答把全部题做对就可以了。
开发自测现在逐渐成为提测的一个前提，大部分开发同学对此已经不陌生。
但很多公司仍面临没有测试同学、部分内部系统没有测试同学对接或者公司测试文化不够普及的问题，这时候开发同学就需要自己进行全部测试，但是又无从下手。
一是开发同学可能只知道自己负责的那一个模块功能，不知道整个系统的流程，另一个可能是不明白除了把正常功能验证完，还需要关注什么。
你了解这个行业吗
每个公司都有所在的行业，就算是外包公司，你做的项目也会有一个行业归属。金融证券、教育平台、市政平台、电商等等，每个行业的业务不同。
如果你觉得你只是负责敲代码的，为什么要了解行业知识呢，这些由业务人员知道不就好了嘛，业务人员给我们提什么需求就做什么啊。
其实不管什么岗位，结合行业知识可以帮助你更快更好地了解需求背景，同时可以让你主动挖掘和补充隐含的需求。
比如你现在接手一个教师系统，需要新增在线编辑试卷的功能，然后你唰唰唰就完成了。
如果你稍微了解这个行业、了解其他相似系统会有什么功能，你会想到：
- 这个试卷应该是和其它文件一样可以关联到某个课件中的；
- 或者这个试卷是不是应该要有下载的功能比较合理；
- 如果想直接引用别的试卷的某个题可以吗？
那其实设计方式就不全一样了。而如果在后期已经提测甚至验收完再发现这些问题再来调整，那代码就会被改的很丑，严重的话可能需要重新设计。
你了解系统功能吗
因为每个开发同学通常对自己负责的那个模块较为熟悉，比如我负责写一个提供数据的接口，我要提供xxx数据出去，当没有这个数据的时候我返回了400，未找到该数据。
然后调用方A的设计是，获取该接口返回，当收到空的时候返回未找到数据，当收到其它结果的时候返回系统异常。
而这个调用方A还有调用方B，是一个注册模块，调用方B用不存在的账号请求A时居然收到了系统异常，这是不符合逻辑的。
这个例子可能不是很合适（对于有详细接口文档的项目来说可能就不会出现这类问题），但是这里想说明你需要知道你提供的每个接口、模块、功能是怎么被调用的，是起一个什么作用，以及一个完整流程是怎样的。
如果每个模块的开发都只关注自身，那么当整个流程被串起来的时候就是一场灾难。
所以在进行自测时，不应只关注本身这个实现，而要结合整个的系统进行分析和运行。
你写单元测试了吗
对开发同学来说最基本的测试，就是单元测试。但是很多开发会抗拒，觉得单元测试的作用微乎其微。
单元测试的作用在这里就不强调了，但是当你对原代码进行了重构，要一项一项检查是否对其他功能模块有影响时，这个成本是巨大的，而且容易遗漏，而有单元测试的话你只需要运行单元测试即可。
虽然写这样的单元测试本身的成本已经是很大的，但是这是可以无限次被使用的，和每一次重构的未知和风险相比，哪里一个的成本低呢。
代码有通过静态扫描吗
静态代码扫描可以在不运行项目的情况下快速分析和验证代码，识别导致系统故障、可靠性差、系统漏洞或不安全条件的严重漏洞或错误。很多现成的静态代码扫描工具可以利用，一些可以通过编译但是不符合规范的问题可以通过这样的方式检查出来。
你以为的检查点
为什么明明同一个场景，开发同学自己执行的时候没有问题，测试同学却可以发现问题呢，是开发同学操作失误吗？
不，是因为测试同学关注的检查点更详细，除了直观的结果，还包括运行过程中的日志、数据库中插入/修改的数据以及其它间接流程。
当你知道哪些数据需要重点关注，你才能用完整的检查点去确认这个场景是否能算通过。
有现成的自测用例
现在很多测试同学会给开发同学提供自测用例，这是一个很好的开始。
对没有自测意识的开发同学来说，可能需要以通过自测用例作为提测的门槛之一，来不断强化他们的质量意识；对没有测试思维的开发同学来说，这提供了一个思路和方向。
自测用例通常就是重要功能及本次新增/修改的功能，关于如何执行，一是可以借助造数据工具或者脚本，二是由测试同学提供支持，但是最终的希望是开发同学能够独自完整地进行自测。
持续集成
随着持续集成持续交付的推广和实施，越来越多的项目已经在提交代码后自动运行验收测试脚本，这对项目来说是效率极高的。
不仅缩短了从提交到有初步结论的时间，还降低人为操作失误的风险。
开发同学终于不需要为如何进行自测而烦恼了，但是验收测试脚本其实是由开发、测试、产品同学共同完成的，验收测试标准、场景、实现方式等不是由哪一方自行决定和完成的。
如果没有较为完善的自动化验收测试脚本，首先可以把造数据脚本利用起来，其次让业务方提供完整详细的验收标准，再由技术同学将其写成脚本并进行利用。
其它
还有一个有助于开发同学发现缺陷，提高代码质量的方式是结对code review。
让你去检查你自己的代码可能因为习惯而发现不了问题，但是找同事跟你一起review，在相互学习的同时他能发现和指出你遗漏、出错的点。
总结
所以开发同学是可以通过增加自测场景覆盖，结合测试、用户的视角补充测试点，以及结对测试来发现更多的bug，使开发自测做到位。
开发和测试的角色从来不是对立的，开发同学需要进行自测，确保主要功能的实现，测试同学才能有足够的时间和精力去挖掘隐含缺陷、异常情况，以及进行其它类型的测试。
测试同学需要在自测点、测试脚本上给开发同学提供支持，提高开发同学的自测效率。
这样才能使团队的研发效率提高，并且快速交付高质量产品。
下面是配套资料，对于做【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴我走过了最艰难的路程，希望也能帮助到你！
最后： 可以在公众号：伤心的辣条 ！ 免费领取一份216页软件测试工程师面试宝典文档资料。以及相对应的视频学习教程免费分享！，其中包括了有基础知识、Linux必备、Shell、互联网程序原理、Mysql数据库、抓包工具专题、接口测试工具、测试进阶-Python编程、Web自动化测试、APP自动化测试、接口自动化测试、测试高级持续集成、测试架构开发测试框架、性能测试、安全测试等。
学习不要孤军奋战，最好是能抱团取暖，相互成就一起成长，群众效应的效果是非常强大的，大家一起学习，一起打卡，会更有学习动力，也更能坚持下去。你可以加入我们的测试技术交流扣扣群：914172719（里面有各种软件测试资源和技术讨论）
喜欢软件测试的小伙伴们，如果我的博客对你有帮助、如果你喜欢我的博客内容，请 “点赞” “评论” “收藏” 一键三连哦！
好文推荐
转行面试，跳槽面试，软件测试人员都必须知道的这几种面试技巧！