网站嵌入js,开互联网公司网站是自己建吗,wordpress还是帝国cms对比,本地网站搭建软件引言
测试用例设计的最基本要求#xff1a;覆盖住所要测试的功能。这是再基本不过的要求了#xff0c;但别看只是简单的一句话#xff0c;要能够达到切实覆盖全面#xff0c;需要对被测试产品功能的全面了解、明确测试范围(特别是要明确哪些是不需要测试的)、具备基本的测…引言
测试用例设计的最基本要求覆盖住所要测试的功能。这是再基本不过的要求了但别看只是简单的一句话要能够达到切实覆盖全面需要对被测试产品功能的全面了解、明确测试范围(特别是要明确哪些是不需要测试的)、具备基本的测试技术(如等价类划分等)等。
那么满足了上述这条要求是不是设计出来的测试用例就是好的测试用例了呢?
答案在理论上是但在实际工程中还远远不是。之所以理论和实际会有这样的差别是因为在理论上不要考虑的东东而在实际工程中是不得不考虑的 - 成本。这里的成本包括测试计划成本、测试执行成本、自动化测试用例、测试自动化成本测试分析成本以及测试实现技术局限、测试环境的Bug、人为因素和不可预测的随机因素等引入的附加成本等。
由于成本因素的介入决定了工程中设计好的测试用例原则不只有“覆盖住所要测试的功能”这一条下面是我根据自己的工作经验总结出的其它四条原则在这里抛砖引玉希望大家拍砖和指正。这些原则特别是针对那些需要被自动化并且是要被经常执行的测试用例。 同时在这我也准备了一份软件测试视频教程含接口、自动化、性能等需要的可以直接在下方观看或者直接关注VX公众号互联网杂货铺免费领取
软件测试视频教程观看处 软件测试工程师大忌盲目自学软件测试真的会毁终生能救一个是一个...... 1. 单个用例覆盖最小化原则
这条原则是所有这四条原则中的”老大“也是在工程中最容易被忘记和忽略的它或多或少的都影响到其它几条原则。下面举个例子来介绍假如要测试一个功能 A它有三个子功能点 A1A2 和 A3可以有下面两种方法来设计测试用例
方法1 用一个测试用例覆盖三个子功能 -Test_A1_A2_A3
方法2 用三个单独的用例分别来覆盖三个子功能 - Test_A1Test_A2Test_A3
方法1适用于规模较小的工程但凡是稍微有点儿规模和质量要求的项目方法2则是更好的选择因为它具有如下的优点
测试用例的覆盖边界定义更清晰测试结果对产品问题的指向性更强测试用例间的耦合度最低彼此之间的干扰也就越低
上述这些优点所能带来直接好处是测试用例的调试、分析和维护成本最低。
每个测试用例应该尽可能的简单只验证你所要验证的内容不要“搂草打兔子”捎带着把啥啥啥啥都带进来这样只会增加测试执行阶段的负担和风险。David Astels在他的著作《Test Driven DevelopmentA Practical Guide》曾这样描述最好一个测试用例只有一个Assert语句。此外覆盖功能点简单明确的测试用例也便于组合生成新的测试在Visual Studio中就引入了Ordered Test的概念。
2. 测试用例替代产品文档功能原则
通常我们会在开发的初期(Scrum每个Sprint的头两天)用Word文档或者OneNote的记录产品的需求、功能描述、以及当前所能确定的任何细节等信息勾勒将要实现功能的样貌便于团队进行交流和细化并在团队内达成对产品功能共识。假设我们在此时达成共识后描述出来的功能为A随着产品开发深入团队会对产品的功能有更新的认识产品功能也会被更具体细化在一个迭代或者Sprint结束的时候最终实现的功能很可能是A。如此往复在不断倾听和吸收用户的反馈修改产品功能多个迭代过后原本被描述为A的功能很可能最终变为了Z。
这是时候再去看曾经的Word文档和OneNote页面却仍然记录的是A。之所以会这样是因为很少有人会去(以及能够去)不断更新那些文档以准确反映出产品功能当前的准确状态。不是不想去做而是实在很难!这里需要注意早期的Word或者OneNote的文档还是必要的它至少能保证在迭代初期团队对要实现功能有一致和准确的认识。
就没有什么东西能够一直准确地描述产品的功能了吗?
答案当然有那就是产品代码和测试用例。产品代码实现了产品功能它一定是准确描述了产品的当前功能但是由于各种编程技术如面向对象、抽象、设计模式、资源文件等等使得产品代码很难简单地就能读懂往往是在知道产品功能的前提下去读代码而不是反过来看代码来了解功能。好的代码会有详细的注释但这里的注释是对实现代码的解释和备注并不是对产品功能的描述。
那么就只有测试用例了测试也应该忠实反映了产品功能的否则的话测试用例就会执行失败。以往大家只是就把测试用例当作测试用例而已其实对测试用例的理解应该再上升到另一个高度它应该是能够扮演产品描述文档的功能。这就要求我们编写的测试用例足够详细、测试用例的组织要有调理、分主次单靠Word、Excel或者OneNote这样通用的工具是远远无法完成的需要更多专用的测试用例管理工具来辅助例如 Visual Studio 2010引入Microsoft Test Manager。
此外对于自动化测试用例(无论是API或者UI级别的)而言代码在编写上也应该有别产品代码编写风格可读性和描述性应该是重点考虑的内容。在测试代码中当然可以引入面向对象、设计模式等优秀的设计思想但是一定要适度使用往往面向过程的编码方式更利于组织、阅读和描述。
3. 单次投入成本和多次投入成本原则
与其说这是一条评判测试用例的原则不如说它是一条思考问题的思维角度和原则。成本永远是任何项目进行决策时所要考虑的首要因素项目中的测试也是如此对成本的考虑也应该客观和全面的体现在测试的设计、执行和维护的整个阶段中。当你在测试中遇到一些左右为难的问题需要决策时尝试着从成本角度去分析一下也许会对你的决策有所帮助。
测试中的成本按其时间跨度可以分为单次投入成本和多次投入成本。
例如编写测试用例可以看作是单次投入成本因为编写测试用例一般是在测试的计划阶段进行(Scrum每个Sprint的开始阶段)的虽然后期会有小的改动但绝大多数是在一开始的设计阶段就基本上成型了;自动化测试用例也是如此它也属于是一次性投入;测试用例(包括手工和自动化测试用例)的执行则是多次投入成本因为每出一个新版本Build时都要执行所有的测试用例(或者进行BVT测试仅执行高优先级的测试用例)、分析测试结果、调试失败测试用例、确定测试用例的失败原因(产品缺陷、测试用例缺陷、测试框架缺陷还是随机问题导致了测试用例的失败)以验证该版本整体质量是否达到了指定的标准。
之所有要引入单次和多次成本的思考是希望能够通过区分测试中不同活动对测试成本的影响从而进行帮助我们合理布局在不同阶段的投入和做出正确的决策以保证在有限可负担测试成本的前提下最大限度地有效开展测试工作。例如当我们意识到了测试用例的设计和自动化属于是一次性投入而测试用例的执行则是反复多次的投入时就应该积极思考如何能够提高需要反复投入的测试执行的效率在一次投入和需要多次活动需要平衡时优先考虑多次投入活动的效率其实这里是有很多工作可以做。
例如第一条原则-单个用例覆盖最小化原则 - 就是一个很好的例子测试A功能的3个功能点A1A2和A3从表面上看用Test_A1_A2_A3这一个用例在设计和自动化实现时最简单的但它在反复执行阶段会带来很多的问题
首先这样的用例的失败分析相对复杂你需要确认到底是哪一个功能点造成了测试失败
其次自动化用例的调试更为复杂如果是A3功能点的问题你仍需要不断地走过A1和A2然后才能到达A3这增加了调试时间和复杂度;
第三步骤多的手工测试用例增加了手工执行的不确定性步骤多的自动化用例增加了其自动执行的失败可能性特别是那些基于UI自动化技术的用例;
第四(Last but not least)将不相关功能点耦合到一起降低了尽早发现产品回归缺陷的可能性这是测试工作的大忌。
例如如果Test_A1_A2_A3是一个自动测试用例并按照A1-A2-A3的顺序来执行的当A1存在Bug时整个测试用例就失败了而A2和A3并未被测试执行到。如果此时A1的Bug由于某些原因需要很长时间才能修复则Test_A1_A2_A3始终被认为是因为A1的Bug而失败的而A2和A3则始终是没有被覆盖到这里存在潜在的危险和漏洞。当你在产品就要发布前终于修复了A1的Bug并理所当然地认为Test_A1_A2_A3应该通过时A2和A3的问题就会在这时爆发出来你不得不继续加班修复A2和A3的问题。不是危言耸听当A2/A3的代码与A1的Bug修复相关时当你有很多如此设计的测试用例时问题可能会更糟…
综上所述Test_A1_A2_A3这样的设计减少地仅是一次性设计和自动化的投入增加地却是需要多次投入的测试执行的负担和风险所以需要决策时(事实上这种决策是经常发生的尤其是在设计测试用例时)选择Test_A1_A2_A3还是Test_A1、Test_A2和Test_A3请务必要考虑投入的代价。
4. 使测试结果分析和调试最简单化原则
这条原则是实际上是上一条- 单次投入成本和多次投入成本原则 - 针对自动化测试用例的扩展和延续。在编写自动化测试代码时要重点考虑如何使得测试结果分析和测试调试更为简单包括用例日志、调试辅助信息输出等。因为测试用例的执行属于多次投入测试人员要经常地去分析测试结果、调试测试用例在这部分活动上的投入是相当可观的。有时候测试框架提功能的一些辅助API等就可以帮助很好实现这个原则。
例如Coded UI Test就提供了类似的API详见 - VS 2010 测试功能学习(18) – Coded UI Test三个必知的函数来辅助基于Coded UI框架实现的自动化测试用例有更好的调试体验。 测试理论为测试工作指明了大的前进方向在实际工程中还需要我们不断地“活化”这些理论使理论和实践更好的契合在一起。在我看来软件工程项目不论成败和好坏对我们每个参与者都是无比宝贵的。作为有心人从中我们体会到很多书本上不曾提到过的东西只要不断地去观察、体会和总结你会有更多自己的认识、理解和发现。有很多人写书称赞代码之美、测试之美其实工程项目也是很美只是看你能不能更客观地去看待它。
总结
PS这里分享一套软件测试的自学教程合集。对于在测试行业发展的小伙伴们来说应该会很有帮助。除了基础入门的资源博主也收集不少进阶自动化的资源从理论到实战知行合一才能真正的掌握。全套内容已经打包到网盘内容总量接近500个G。如需要软件测试学习资料关注公众号互联网杂货铺后台回复1整理不易给个关注点个赞吧谢谢各位大佬 这些资料对于做【软件测试】的朋友来说应该是最全面最完整的备战仓库这个仓库也陪伴我走过了最艰难的路程希望也能帮助到你凡事要趁早特别是技术行业一定要提升技术功底。
