般是放在系统完成后进行测试
但今天却常常听到资深开发人员劝导新人们:“测试是开发
第步”这句话如何理解呢？如果从日本人发明巴克质量管理方式去理解大概是指每个环节交给下级时都应该进行测试
有些测试对后面操作没有太大影响如图片不漂亮菜单不合理布局很难看的类；而另些却直接让下级无法开始工作象用例不清晰；用例自相矛盾；组件内部
；框架不合理等等固然级级把关可以把质量提高到至少个档次以上；但就每个环节而言仍然是在开发最后阶段所以看来本人水平还是不到家\"测试是开发第步\"难以理解唯可理解就是规范标准先行文档先行文档规范标准化总应该是在编码以前这也是QA主要内容；大概这还多少算解释得通这样测试和规范标准两样东西就重合起来了从严格角度看测试就是测试规范标准归入规范标准还是从模块(项目)后测试开始理解吧；所以所有有关编程和文档、设计规范标准内容本人全部不纳入测试讨论范围或者说我们重点放在QC上而不是着眼于规范标准QA尽管那也非常重要 单元测试(Unittest):是针对模块组件或思路方法
测试在本人操作中般是开发员工作范围内测试；在具备组件接口规范标准情况下般需要做个测试工具模拟
环境编写测试例子通过断点情况监视模块实际工作是否正常股采用这种方式开发单功能模块质量都是非常高但是如果没有统模块规范标准那么开发和测试工作量接近比；但如果模块是按统标准开发那么同套测试套件就可以用到各个模件上从而节省了测试时间本人认为这属于开发部门工作范围内测试和QA/QC部门没有什么大关系事实上在这层次用例也不是QC可以做到和理解 白箱测试:在理解内部流程
情况下针对逻辑流程设计测试例子目是找出极限边缘以及内在逻辑单元测试中白箱测试比例很高(原因不难理解还有谁比作者自已更理解模块构造流程？) 黑箱测试:这是QC部门
主要工作黑箱测试主要在于编写测试例子不过在实际操作中都是把最不懂技术成员分配做测试最高技术水平就是会用VSS所以也就别指望编什么测试例子所谓黑箱测试常常是对着菜单按钮这个按下去噢有东西出来了对打个勾——其实这时侯例子就是个个按下去然后看看有没有输出而且只限于界面方面内在部分和边缘情况大概是不用指望但据作者所知在CMM达到 4以上国外软件Software公司中黑箱测试是对软件Software评价最主要方式通过合适测试例子除了最常见可用性测试外还包括压力测试和怪用测试(Monkeytest) 压力测试:评价
个系统极限可以承受压力是多少同时在超负荷后响应情况；同时在极限状况下些平时不太出现bug也会浮现出来所以这个测试作者认为不应该单独由QC部门进行而应该由开发部门和QC部门联合进行理想系统在极限测试状况下就算响应不及也不至于当机并在负荷恢复正常后段时间内可以恢复正常运转这时当初对windows恶评原因的:象网站WebSite旦超出100-200个concurrent,windows不但罢工还死掉了；不得不重启系统(当然windows任意硬重启都能死鱼翻生大多数情况下吧也属种难能可贵优点)；而linux在超出负荷后般情况下下降曲线不至于太明显——不过这也不是绝对作者就发现旦linux在极限状态下进入内存抖动时死相和windows差不了多少；所以内存不至于耗干是linux可*性能超过windows重要原因 回归测试；在修改其中
个模块后看其他模块有什么问题作者认为这个测试是过程化
观念产物在模块化软件Software中相互耦合程度低而且服从统调动协议是不是修改真是自家里事情和他人(模块)没有半点相干 整体测试:把区别
模块连结后看看联合工作情况如何这实际上是对接口协议测试作者认为是可以作为接口互动部分设计部分工作没有必要摆出来作为流程的同理还有系统测试反正最后整个系统运行起来是什么情况看似大但如果前面已经做到好好这里如果出问题那才叫怪呢！ Alpha测试:放任内部成员胡作非为
测试； Beta测试:让全世界
坏人都胡作非为测试 过了这
关后大概应该可以了吧？？在欧洲美国日本规范标准软件Software公司大概是可以了但在中国可不见得许多时侯业务需求人员会蹦出来说:“不是这个样子！”早时侯他不知上那里去了！或者“加上另个什么功能吧？”早时侯他大概是睡觉了大家伙儿前面做事情就冲这两句话就全废了,全部事情得从中间某个环节重来这才叫恶梦这时和其顺着他们老哥胡说 8道跑不如找出合同来条条地仔细颁下去
最新评论