-
暂时没有公告
软件测试和VSTS 测试工具
发布: 2009-5-31 10:56 | 作者: 不详 | 来源: 测试时代采编 | 查看: 314次 | 进入软件测试论坛讨论
1.12Alpha Test, Beta Test
在开发软件的过程中，开发团队希望让用户直接接触到最新版本的软件，以便从用户那里收集反馈，这时开发团队会在开发过程中让特定的用户（alpha/beta用户）使用正处于开发过程中的版本，用户会用特定的反馈渠道（email, BBS）与开发者讨论使用中发现的问题，等等。这种做法成功地让广大用户心甘情愿地替开发团队测试产品并提出反馈。最近有些开发团队增加了反馈的密度，不必再等到Alpha或者Beta发布，而是不断地把一些中间版本发布出去以收集反馈，美其名曰“技术预览版本”或“社区预览版本”。
1.13Usability Test可用性测试
小燕问：作为测试人员，我们是不是也要作可用性测试?
答：测试人员，以及其他的团队成员都可以对软件的可用性提出意见，包括用bug的形式放在在TFS中。软件的可用性不神秘，就是让软件更好用，让用户更有效地完成工作。
但是我觉得“可用性测试”似乎更多地用来描述一套测试软件可用性的过程，这个过程一般不是由测试人员来主导的，而是有对软件设计及可用性有很多研究的“可用性设计师”来实行。网络上有许多关于这方面的文章，大家可以参考。
1.14Bug Bash
问：我们已经讲得太多的测试了，好像微软还有一个叫“bug bash”的活动，是啥意思？
答：简而言之，就是大家一起来找小强的活动–小强大扫除。一般是安排出一段时间（一天），所有测试人员（有时也加入其他角色）放下手里的事情，专心找某种类型的小强。然后结束时，统计并奖励找得最多的，和最厉害的小强的员工。这种活动，如果运用得好，有下面的作用：
当然，小强大扫除也有一些副作用：
- 扰乱正常的测试工作
- 如果过分重视奖励，会导致一些数量至上，滥竽充数的做法。
两个细节是：
1．一定要让“小强大扫除”有明确的目标，明了的技术支持。
2．一定要让表现突出的人介绍经验，让别人学习。
要记住，最好的测试，是能够防止小强的出现。
2 总结和思考
2.1 十八般兵器
阿毛：超总,我的脑袋好像装不下了! 听了这么多，我感觉像是身上扛着十八般兵器，累得半死，但是不知道什么时候，对哪一种敌人用哪一种兵器，能不能总结一下!
阿超：好，我们用软件开发的生命周期来说明一下不同的测试在不同阶段的使用：
远景和计划阶段：
测试只是处于计划阶段，同时要收集用户对于软件非功能性的需求，如效能，可用性，国际化等。一些“小强大扫除”的类型也可以在这个时候初步安排。
开发阶段：
开发人员要写单元测试，测试人员要写BVT。
随着软件功能的逐步完善，测试人员要进行集成测试。这时，团队可以开展对程序非功能性特性的测试，如效能/压力测试，国际化/本地化测试，安全性测试，可用性，适用性测试等。在这个时候，可以考虑分析各个模块的代码覆盖率，以增加测试的有效性。根据计划，各种类型的“小强大扫除”会以适当的频率发生。
稳定阶段：
到了一个开发阶段的尾声，这时测试团队就可以依据以前制定的验收标准，对软件逐项进行验收测试。按照测试计划，各个方面的测试都会宣布“测试完成”-所有想到的测试都做了，所有问题都发现了。在此阶段，团队也可以把软件发布给外部进行alpha/beta测试。
一般情况下，测试队伍要把迄今为止发现的所有小强都从新试一次，确保它们都在最后的版本中被清除了，没有一个“回归”出现。
发布阶段：
测试队伍要把尽可能多的测试用例自动化，并为下一个版本的测试工作做好准备。
2.2 构建的质量
1．编译失败
2．可测/不可测
3．可用/不可用
2.3 问题
2.3.1 如果连续几天都不能产生“可测”版本，怎么办？
提示：可以在下一个构建版本中限制签入的数量，只接受那些高等级的修改，在一般的做法中，导致“不可测”的小强的严重性是1，必须在下一个构建开始的时候得到改正。
文章来源于领测软件测试网 https://www.ltesting.net/
领测软件测试网最新更新
