2022-01-05 11:40:54|已浏览：170次
定义
在规定的条件下对程序进行操作，以发现程序错误，衡量软件质量，并对其是否能满足设计要求进行评估的过程。
测试就是发现错误而执行程序的过程。
原则
保证测试的覆盖度，但是穷举测试是不可能的。
所有的测试都应该追溯到用户。
越早测越好，测试过程与开发过程应该是互相结合的。
测试的规模 从小到大，从单元测试到系统测试。
不能为了便于测试而擅自修改程序。
既应该测试软件能做什么，也应该测试软件不能做什么。
度量
测试覆盖率
缺陷发现率
测试成功率（或者说用例通过率）
显式条件：
项目风险
项目经费
隐含条件：
老板们从当前的测试结果已经获得了足够的信心,或者彻底摧毁了信心。只要他们还在犹豫咱就得继续干活。
测试的原则
测试只是展示缺陷
测试只能表明缺陷存在,却不能证明没有缺陷。测试能降低未发现缺陷留存的概率,却 不能证明软件是绝对正确的。 正如某些数学命题,你可以穷举 1-n,证明其正确,却依然无法证明对于 n+1 仍然正确。
穷尽测试是不可能的
测试所有的输入和条件组合是不可能的,除非是极其简单的情况。可以取而代之的是基 于风险和优先级的测试。 当不懂装懂的老板要求你彻底测试一个软件的时候,这是你反驳的最好支持,当然要说 的委婉一点
早期测试
要较早发现缺陷,就要在软件周期尽可能早的时候开始测试,而且要专注于已定义的测 试目标。 尽早开始测试!这句话估计早就把大家的耳朵磨起茧了。为什么要早?因为越早发现问 题,解决的代价就越小。
缺陷簇生
要对缺陷发现率高的模块投入更多的测试。少量的模块往往隐藏了大部分的缺陷。 这不仅仅是所谓的物以类聚。缺陷发现率高的模块往往于需求不清,设计不当,编码复 杂度高等内在原因关联,所以从风险的角度来看必然较高,多花些时间绝对值得。
杀虫剂悖论
相同的测试再重复多次后就无法再找到缺陷了。要克服“杀虫剂悖论”,测试用例要不断评审修改,不断添加新的和不同的测试,就有可能找到更多缺陷。 随着对系统的加深理解,必然会有更多的测试用例产生。另外缺陷本身也是新用例的很好来源。
测试是上下文相关的
测试在不同上下文环境中的执行是不同的。比方说安全关键系统 (safety critical system)和电子商务网站的测试方法就有很大不同。 这个原理相对难理解。这里其实强调的是不能用相同的态度和手段来测试不同类型的系 统。安全关键系统的概念要到高级大纲中才出现,指的是对系统安全要求苛刻的系统, 较之一般的电子商务系统的测试要求更为严苛。
无错谬论
假如建立的系统不稳定或不能满足用户需要和期望,那么发现和修复缺陷就毫无帮助了。 缺陷数量往往用来评估某软件的质量,但要是系统本身背离了用户要求,那就算缺陷再 少也没用,因为没有人会去用它。所以测试时要注意验证(verification)和确认(validation)的区别。需求规格说明和其他文档只是需求的不完全载体。文字说明必然有遗漏和偏差, 而各人的理解更有可能出错。要不断通过各种途径保证所生产的的确就是用户需要的。 常用的方式就是邀请领域专家或用户尽可能多地参与到开发活动来,特别是需求评审和演示(Demo)。
测试做到什么程度并没有一个固定答案。只要满足两个显式条件和一个隐含条件就要一直进行。
本文由培训无忧网千锋教育专属课程顾问整理发布，希望能够对想学习软件测试培训的同学有所帮助。更多软件测试培训课程欢迎关注培训无忧网软件测试培训培训频道或添加老师微信：15033336050
注：尊重原创文章,转载请注明出处和链接 https://www.pxwy.cn/news-id-12722.html 违者必究！部分文章来源于网络由培训无忧网编辑部人员整理发布,内容真实性请自行核实或联系我们，了解更多相关资讯请关注软件测试频道查看更多，了解相关专业课程信息您可在线咨询也可免费申请试课。关注官方微信了解更多：150 3333 6050
