我们预防Bug的一些经验

   <p style="text-align: center;"><img src="https://simg.open-open.com/show/1d63ee91bf20138aa84cc98d6b675552.jpg"></p>    <p>1.QA全方位参与整个 <u> <strong>软件开发</strong> </u> 过程，例如当BA和开发人员kick off一个卡的时候，QA参与讨论，提出一些需要程序员自测时候可能会忘记 <u> <strong>测试</strong> </u> 的点，此外，QA往往对业务更熟悉，可以提供建议给程序员，那些业务细节不能够忽视，以防止这些地方出现 <u> <strong>bug</strong> </u> 。</p>    <p>2.当开发人员做完卡时候，需要把卡sign off给QA，在这个过程中，会在开发本地环境演示，期间如果出现缺陷，开发人员会重新把卡放到in dev列进行修复。直到开发人员本地环境都没有问题后，QA才开始正式测试。</p>    <p>3.把 <u> <strong>Jmeter</strong> </u> 的 <u> <strong>性能测试</strong> </u> 脚本加入到CI中，每次提交代码会跑一遍性能测试脚本，确保每次新代码的提交，不会破坏产品关键流程的性能。</p>    <p>4.建议团队使用代码缺陷扫描工具，避免一些通用的bug的出现。</p>    <p>5.建议团队的把 <u> <strong>单元测试</strong> </u> 覆盖率提高到一定程度，例如80%，可以减少新的功能代码对原有功能的破坏。</p>    <p>6.建议团队根据实际情况去使用BDD的方式（Cucumber）去写 <u> <strong>自动化测试</strong> </u> 用例，可以让项目的PM，BA，Dev，QA等人对业务有一致的理解，减少由于业务理解不止出现的Bug。</p>    <p>7.多写一些测试blog发布在公司内网发布，帮助开发人员了解哪些地方容易出现Bug。</p>    <p>8.我如果碰到了一些比较有趣或者通用的bug，会在团队的每天早上站会，或者下午code review时候，跟大家分享，这样大家都会知道这种类型的bug。</p>    <p>9.有些开发认为开发出的界面和设计稿有一定偏差问题不大，但是我建议界面尽量按照设计稿做，因为几个像素的偏差，一个按钮位置的不同，一块区域透明度不够等，都会造成整体美感的下降。经过和团队合作一段时间后，大家实现的界面和设计稿更加贴近或者完全一致。</p>    <p>10.建议开发把重要的，或者一些特殊的实现思路，以及一些需要别人知道的细节， <u> <strong>记录</strong> </u> 在Jira的卡中。因为敏捷团队中，文档比较少，而Jira卡中记录了这些信息后，将来任何人拿到这个卡，都能很快了解上下文和这个卡有无特殊实现等。我自己做测试时候，如果碰到一些比较有趣的卡，也会记录下测试思路和测试数据。</p>    <p>11.建议开发和QA结对测试，传递测试的方法和思路。因为在探索性测试过程中，使用结对测试的方法，可以比较有效的传递知识。</p>    <p>12.有些开发缺少横向对比同类产品的意识，因此开发出来的功能会不易使用。建议每个人都应该关心和对比同类产品的优缺点，这样才能让自己做出的功能模块来更有竞争力，更好使用。</p>    <p>13.当QA测试的非常仔细的时候，开发自测的仔细程度也会相应提高很多。例如，刚进入团队时候，有些开发自测时都很少考虑多 <u> <strong>浏览器</strong> </u> 兼容性测试，于是浏览器上经常会出现bug。我告诉大家，我每次测试都会在所有需要测试的浏览器上进行测试，而且每次出现bug后，我都会把卡挪回开发重新处理。因此在和团队一起 <u> <strong>工作</strong> </u> 一段时间后，大家在不同浏览器上自测的力度就越来越大了。</p>    <p> </p>    <p>来自：http://www.techug.com/post/some-tips-of-kill-bug.html</p>    <p> </p>