测试
成本因素的介入决定了工程中设计的测试用例原则不仅仅是“测试以覆盖地址的功能”。 以下是我根据自己的工作经验总结出的其他四个原则。 我希望你在这里扔球，大家敲砖头指出来。 这些原则特别需要自动化，适用于经常运行的测试用例。
1 .单个用例涵盖最小化原则。
这个原则是所有这四个原则中的“老大”，是工程中最容易被遗忘和忽略的，或多或少地影响着其他一些原则。 举个例子吧。 测试功能a时，有三个子功能点A1、A2、A3，设计测试用例有以下两种方法。
方法1 )一个测试用例覆盖三个子功能(-Test_A1_A2_A3，
方法2 )用三个单独的用例分别覆盖三个子功能(test_a1、Test_A2、Test_A3 )
方法1适用于小规模工程，但略具规模和
测试用例覆盖边界的定义更加明确
测试结果对产品问题的指向性更强
测试用例之间的耦合度最低，彼此的干扰也低
这些优点带来的直接好处是调试、分析和维护测试用例的成本最低。 每个测试用例都必须尽可能简单，只验证想要验证的内容。 不要带任何东西进来，比如“把草扒起来打兔子”。 只会增加测试执行阶段的负担和风险。 David Astels在《Test Driven Development：A Practical Guide》书中是这样说的。 最好一个测试用例中只有一个Assert语句。 另外，由于功能点简单，覆盖了明确的测试用例，组合生成新的测试也变得容易，在Visual Studio中引入了有序测试的概念。
2 .测试用例替代产品文档的功能原则。
通常我们
没有什么能总是正确地说明产品的功能吗？ 答：当然有。 那是产品代码和测试用例。 产品代码一定实现了产品的功能，正确记述了产品当前的功能，但由于以下各种编程技术
那么只有测试用例了。 测试应该也忠实地反映了产品的功能。 否则测试用例运行将失败。 以前将测试用例作为测试用例来考虑，但实际上对测试用例的理解应该提高到另一个层次，应该发挥产品说明文档的功能。 因此，我们编写的测试用例足够详细，测试用例的组织需要调整、分主，光靠Word、Excel、OneNote这样的通用工具是不够的，需要更多的专用工具
此外，对于自动化测试用例(无论是API还是UI级别)，代码的编写也需要不同的产品代码编写样式，可读性和可描述性必须是重要的考虑因素。 测试代码中当然可以引入面向对象、设计模式等优秀的设计思想，但必须适度使用，往往面向过程的编码方式更有利于组织、阅读、描述。
3.1次投入成本和多次投入成本原则。
与其说这是评价测试用例的原则，不如说是思考问题的角度和原则。 成本始终是任何项目进行决策时必须考虑的主要因素，项目中的测试也是如此，对成本的考虑也应该客观全面地反映在设计、执行和维护测试的整个阶段。 如果热情的网络在测试中遇到左右为难的问题需要决策，从成本的角度分析一下可能会对你的决策有帮助。
测试的成本根据其时间跨度可以分为一次投入成本和多次投入成本。 例如：
所有引入一次和多次成本的思考都希望通过区分测试中不同活动对测试成本的影响，合理安排不同阶段的投资并做出正确的决策，从而最大限度地提高测试工作的效率，同时承担有限的测试成本例如，测试用例的设计和自动化是一次性投入，而当意识到测试用例的执行是多次投入的重复，应该积极考虑如何提高需要重复投入的测试执行的效率，一次投入和多次活动
例如，首要原则-在单个用例中涵盖最小化原则-是一个很好的例子。 测试a功能的三个功能点A1、A2和A3在Test_A1_A2_A3的用例中在设计和自动化实现时表面上是最简单的，但在重复执行阶段会带来很多问题。
首先，这种用例的失败分析比较复杂，需要确定哪些功能点未通过测试
其次，自动化用例的调试更加复杂。 如果是A3功能点的问题，则需要通过A1和A2后才能到达A3，增加了调试时间和复杂性。
第三，步骤很多
第四，(Last but not least )结合了不相关的功能点，降低了早期发现产品回归缺陷的可能性，这是测试工作的一大忌。 例如，如果Test_A1_A2_A3为一个
综上所述，像Test_A1_A2_A3这样的设计，减少地只是一次设计和自动化的投入，但是增加地是多次投入的测试执行的负担和风险，所以需要决策的情况下(实际上这样的决策经常发生，特别是将测试用例作为
4 .最简化测试结果分析和调试的原则。
这个原则实际上是上次“一次成本投入和多次成本投入”的原则，面向自动化测试用例的扩展和继续。 编写自动化测试代码时，请侧重于如何让测试结果得分
析和测试调试更为简单，包括：用例日志、调试辅助信息输出等。因为测试用例的执行属于多次投入，测试理论为测试工作指明了大的前进方向，在实际工程中还需要我们不断地“活化”这些理论，使理论和实践更好的契合在一起。在我看来，
论坛精华帖