zoukankan      html  css  js  c++  java
  • [ZZ]风险驱动的测试

    http://googletesting.blogspot.com/2014/05/testing-on-toilet-risk-driven-testing.html

    Testing on the Toilet: Risk-Driven Testing

     
    by Peter Arrenbrecht

    This article was adapted from a Google Testing on the Toilet (TotT) episode. You can download a printer-friendly version of this TotT episode and post it in your office. 

    We are all conditioned to write tests as we code: unit, functional, UI—the whole shebang. We are professionals, after all. Many of us like how small tests let us work quickly, and how larger tests inspire safety and closure. Or we may just anticipate flak during review. We are so used to these tests that often we no longer question why we write them. This can be wasteful and dangerous. 

    Tests are a means to an end: To reduce the key risks of a project, and to get the biggest bang for the buck. This bang may not always come from the tests that standard practice has you write, or not even from tests at all. 

    Two examples: 

    “We built a new debugging aid. We wrote unit, integration, and UI tests. We were ready to launch.”

    Outstanding practice. Missing the mark.

    Our key risks were that we'd corrupt our data or bring down our servers for the sake of a debugging aid. None of the tests addressed this, but they gave a false sense of safety and “being done”.
    We stopped the launch.


    “We wanted to turn down a feature, so we needed to alert affected users. Again we had unit and integration tests, and even one expensive end-to-end test.”

    Standard practice. Wasted effort.

    The alert was so critical it actually needed end-to-end coverage for all scenarios. But it would be live for only three releases. The cheapest effective test? Manual testing before each release.


    A Better Approach: Risks First 

    For every project or feature, think about testing. Brainstorm your key risks and your best options to reduce them.Do this at the start so you don't waste effort and can adapt your design. Write them down as a QA design so you can point to it in reviews and discussions. 

    To be sure, standard practice remains a good idea in most cases (hence it’s standard). Small tests are cheap and speed up coding and maintenance, and larger tests safeguard core use-cases and integration. 

    Just remember: Your tests are a means. The bang is what counts. It’s your job to maximize it
  • 相关阅读:
    Java 面向对象_继承
    Java 面向对象
    使用 pykafka 进行消费
    oracle 的分页、截断查询
    Day03
    Day02 计算机的组成与编程语言
    Day01 MarkDown的使用
    Java方法的重点
    Scanner的小细节
    Java包机制和Javadoc的使用
  • 原文地址:https://www.cnblogs.com/oscarxie/p/3793707.html
Copyright © 2011-2022 走看看