Acceptance testing(验收测试),系统开发生命周期方法论的一个阶段,这时相关的用户和/或独立测试人员根据测试计划和结果对系统进行测试和接收。它让系统用户决定是否接收系统。它是一项确定产品是否能够满足合同或用户所规定需求的测试。这是管理性和防御性控制。
云测试是基于云计算的一种新型测试方案。服务商提供多种平台,多种浏览器的平台,一般的用户在本地用Selenium把自动化测试脚本编写好,然后上传到他们网站,然后就可以在他们的平台上运行Selenium脚本了。
软件测试到底要不要追究BUG发生的原因呢?这个问题的争议很多,有人认为寻找BUG的原因是开发的事情,软件测试只要能发现BUG就够了;还有人认为软件测试可以尽自己所能尽可能的去寻找BUG的原因。到底哪个观点正确?我个人认为这个问题是仁者见仁,智者见智,站在一个产品不同的层面看,会有不同的看法。这里所谈到的观点,也仅代表个人看法。
遇到的第一个问题是缺陷或问题的状态修改流程如何定义,为此我研究了运营部门提出问题的处理流程和处理方式,整理出如下需求。
在c++的世界里,程序设计的优雅让位于程序的稳定性、健壮性。“好程序是测出来的”这句话在C++领域里得到了充分体现。
我们将项目开发过程中各阶段活动罗列如上表,其大体的时间配比关系可视为三个阶段:设计、实现、总结。测试计划定制时,仅对最终基线需求及性能发布指标进行分析、设计及执行工作。其余测试,如:数据库升级测试、双机热备/冷备测试、容量规划测试、兼容性测试、补丁版本全覆盖集验证等,均不在基本测试计划中予以考虑。如有相应发布需要,项目经理可向测试负责人申请额外的项目配比时间。
计算机软件作为人类逻辑智慧的结晶,它可以模拟并替代人类的一些活动,替人“发号施令”。在计算机软件发展的短短几十年内,计算机软件以非常快的速度渗透到了人类社会的各个角落,比如现在我们在家上网,出门坐公交车刷卡,在工作中发电子邮件等,这些生活的背后都有大量的软件系统运行支持。
目前软件性能测试是发现软件性能问题最有效的手段,而完备有效的性能测试是最关键的,在本节中我们将从流程和技术的角度解析如何构建一个高效的性能测试模型。
在回答这个问题之前,我们首先理清思路,测试的质量首先就体现在缺陷的质量上面。就是发现了多少缺陷,缺陷的严重程度如何,缺陷发现的早晚,缺陷的分布等待,作为测试的结果直接向客户表明了测试的质量。然而测试的质量又有什么所决定呢?是测试用例,测试用例的覆盖率,测试用例的精细度,深度,直接决定了能发现缺陷的多少。所以,要在未发布之前预估缺陷的遗留情况,就要检查测试用例的覆盖情况。
功能测试不是简单的了解业务,了解下数据库表结构就可以了,有更多的方法和技巧等着我去学,如何准确掌控项目中的风险,运用高效快捷的方法做好功能测试,是我这个测试工程师的下一个里程碑。
“天下事头绪纠缠,兴一利必也生一弊。” 一句话,道破了改进难点所在。最近在项目中围绕持续集成做改进的时候,对这一点感受颇深。跌跌撞撞的一路走来。我们的持续集成的过程已经变得有些“个性化”,反过头来看我们一路的变化,非常有意思。
以前看到过有一个关于Yahoo Scrum开发组验证测试过程列表价值的讨论,例如Nokia测试,Joel测试等。有人将这些视为一个成熟敏捷模式的起点,而另外一些人也担心这将会使得敏捷变得过于教条,从而在整个过程中完全失去自我调整的成分。